mvebu dt64 for 5.15 (part 1)
- DTS updates for Marvell Armada CN913x platforms
+ Add support for Armada CN913x Development Board topology "B"
+ Add support for Armada CN913x Reference Design boards (CRB)
+ Fixes the NAND partitioning scheme in DTS eliminating gap between
consecutive partitions
+ Fix 10Gb ports PHY mode names
- Extend PCIe MEM space on Armada 37xx: useful for some combination
of PCIe cards where the initial 16MB was not enough
* tag 'mvebu-dt64-5.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu:
arm64: dts: marvell: armada-37xx: Extend PCIe MEM space
arch/arm64: dts: change 10gbase-kr to 10gbase-r in Armada
arm64: dts: add support for Marvell cn9130-crb platform
dts: marvell: Enable 10G interfaces on 9130-DB and 9131-DB boards
arm64: dts: cn913x: add device trees for topology B boards
Link: https://lore.kernel.org/r/878s10ypxe.fsf@BL-laptop
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
ARM64: DT: HiSilicon ARM64 DT updates for 5.15
- Address a PCI bus range warning of the hi3660 SoC
* tag 'hisi-arm64-dt-for-5.15' of git://github.com/hisilicon/linux-hisi:
arm64: dts: HiSilicon: hi3660: address a PCI warning
Link: https://lore.kernel.org/r/611B9BE9.8050904@hisilicon.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Qualcomm ARM64 updates for v5.15
SDM660 and SDM630 was concluded to be similar enough that they should be
merged, and the derivative SDM636 was added to the bunch. The combined
platform gained support for GPU, DMA, I2C, IMEM, display, power-domains,
SDHCI, thermal, USB, interconnects, VADC, WLED and audio remoteproc. The
Sony Xperia "Ganges" platform was similarly merged with "Nile", got
cleaned up and gained touchscreen, USB, volume keys and uSD support.
IPQ6018 gains USB2 and PCIe support and a few minor fixes. IPQ8074
gains SCM, PRNG and Crypto support and a DT style update of the PCIe
nodes.
MSM8916 gains Coresight STM support. The Xiaomi Redmi 2 is introduced,
with touchscreen, notification LED and IMU support. MSM8996 gains
support for GPU cooling and v3.0 of the SoC, which is used to introduce
support for the Sony Xperia X Performance, XZ and XZs phones.
SC7180 finally gains DisplayPort support and LPASS is updated
accordingly. A number of fixes are introduced and with the newly
introduced DRM aux bus in place Trogdor's panel is moved under the eDP
bridge. SC7280 gained USB, eMMC, SD-card, QFPROM and IPA support, the
new IDP2 board was added.
SM6126 (aka Snapdragon 665) was introduced, together with the Sony
Xperia 10II phone with support for framebuffer, USB, eMMC and volume
keys.
SM8150 gained inline crypto support for UFS enabled, CPU opp-tables was
introduced to scale DDR and L3 frequencies and SPI nodes where added, in
addition to a number of smaller fixes.
SM8250 gained a number of minor fixes and had its serial engines wired
up to use the GENI wrappers' DMA engines.
SM8350 had wakeup-parent defined for the TLMM gpio node and I2C13 was
introduced.
SDM845 display clocks was corrected and Lenovo Yoga C630 got IPA enabled
and now has working LTE connectivity.
Additionally a number of minor fixes throughout to correct DT validation
warnings.
Lastly v5.14-rc3 is merge in to resolve the merge conflicts caused by
the USB maintainer deciding to fix a regression in his tree.
* tag 'qcom-arm64-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (114 commits)
arm64: dts: qcom: sm8250: assign DSI clock source parents
arm64: dts: qcom: sdm845-mtp: assign DSI clock source parents
arm64: dts: qcom: sdm845: assign DSI clock source parents
arm64: dts: qcom: sc7180: assign DSI clock source parents
arm64: dts: qcom: sc7280-idp: Add device tree files for IDP2
dt-bindings: arm: qcom: Document qcom,sc7280-idp2 board
arm64: dts: qcom: sm8350: fix IPA interconnects
arm64: dts: qcom: sc7180: define ipa_fw_mem node
arm64: dts: qcom: sc7280: enable IPA for sc7280-idp
arm64: dts: qcom: sc7280: add IPA information
arm64: dts: qcom: sc7180-trogdor: Move panel under the bridge chip
arm64: dts: qcom: ipq8074: add PRNG node
arm64: dts: qcom: ipq8074: add crypto nodes
arm64: dts: qcom: sm8350: add qupv3_id_1/i2c13 nodes
arm64: dts: qcom: ipq6018: Add pcie support
arm64: dts: qcom: pm8150b: Add DTS node for PMIC VBUS booster
arm64: dts: qcom: sm8150: add SPI nodes
arm64: dts: qcom: msm8916: Enable CoreSight STM component
arm64: dts: qcom: sc7280: Add qfprom node
arm64: dts: qcom: sc7280: Fixup the cpufreq node
...
Link: https://lore.kernel.org/r/20210816231223.586597-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Arm SMMU updates for 5.15
- SMMUv3
* Minor optimisation to avoid zeroing struct members on CMD submission
* Increased use of batched commands to reduce submission latency
* Refactoring in preparation for ECMDQ support
- SMMUv2
* Fix races when probing devices with identical StreamIDs
* Optimise walk cache flushing for Qualcomm implementations
* Allow deep sleep states for some Qualcomm SoCs with shared clocks
Allocating and enabling a flush queue is in fact something we can
reasonably do while a DMA domain is active, without having to rebuild it
from scratch. Thus we can allow a strict -> non-strict transition from
sysfs without requiring to unbind the device's driver, which is of
particular interest to users who want to make selective relaxations to
critical devices like the one serving their root filesystem.
Disabling and draining a queue also seems technically possible to
achieve without rebuilding the whole domain, but would certainly be more
involved. Furthermore there's not such a clear use-case for tightening
up security *after* the device may already have done whatever it is that
you don't trust it not to do, so we only consider the relaxation case.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/d652966348c78457c38bf18daf369272a4ebc2c9.1628682049.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The sysfs interface for default domain types exists primarily so users
can choose the performance/security tradeoff relevant to their own
workload. As such, the choice between the policies for DMA domains fits
perfectly as an additional point on that scale - downgrading a
particular device from a strict default to non-strict may be enough to
let it reach the desired level of performance, while still retaining
more peace of mind than with a wide-open identity domain. Now that we've
abstracted non-strict mode as a distinct type of DMA domain, allow it to
be chosen through the user interface as well.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: John Garry <john.garry@huawei.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/0e08da5ed4069fd3473cfbadda758ca983becdbf.1628682049.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Eliminate the iommu_get_dma_strict() indirection and pipe the
information through the domain type from the beginning. Besides
the flow simplification this also has several nice side-effects:
- Automatically implies strict mode for untrusted devices by
virtue of their IOMMU_DOMAIN_DMA override.
- Ensures that we only end up using flush queues for drivers
which are aware of them and can actually benefit.
- Allows us to handle flush queue init failure by falling back
to strict mode instead of leaving it to possibly blow up later.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/47083d69155577f1367877b1594921948c366eb3.1628682049.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
IO_PGTABLE_QUIRK_NON_STRICT was never a very comfortable fit, since it's
not a quirk of the pagetable format itself. Now that we have a more
appropriate way to convey non-strict unmaps, though, this last of the
non-quirk quirks can also go, and with the flush queue code also now
enforcing its own ordering we can have a lovely cleanup all round.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/155b5c621cd8936472e273a8b07a182f62c6c20d.1628682049.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Since iommu_iotlb_gather exists to help drivers optimise flushing for a
given unmap request, it is also the logical place to indicate whether
the unmap is strict or not, and thus help them further optimise for
whether to expect a sync or a flush_all subsequently. As part of that,
it also seems fair to make the flush queue code take responsibility for
enforcing the really subtle ordering requirement it brings, so that we
don't need to worry about forgetting that if new drivers want to add
flush queue support, and can consolidate the existing versions.
While we're adding to the kerneldoc, also fill in some info for
@freelist which was overlooked previously.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/bf5f8e2ad84e48c712ccbf80fa8c610594c7595f.1628682049.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
This fixes improper iotlb invalidation in intel_pasid_tear_down_entry().
When a PASID was used as nested mode, released and reused, the following
error message will appear:
[ 180.187556] Unexpected page request in Privilege Mode
[ 180.187565] Unexpected page request in Privilege Mode
[ 180.279933] Unexpected page request in Privilege Mode
[ 180.279937] Unexpected page request in Privilege Mode
Per chapter 6.5.3.3 of VT-d spec 3.3, when tear down a pasid entry, the
software should use Domain selective IOTLB flush if the PGTT of the pasid
entry is SL only or Nested, while for the pasid entries whose PGTT is FL
only or PT using PASID-based IOTLB flush is enough.
Fixes: 2cd1311a26 ("iommu/vt-d: Add set domain DOMAIN_ATTR_NESTING attr")
Signed-off-by: Kumar Sanjay K <sanjay.k.kumar@intel.com>
Signed-off-by: Liu Yi L <yi.l.liu@intel.com>
Tested-by: Yi Sun <yi.y.sun@intel.com>
Link: https://lore.kernel.org/r/20210817042425.1784279-1-yi.l.liu@intel.com
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20210817124321.1517985-3-baolu.lu@linux.intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
A PASID reference is increased whenever a device is bound to an mm (and
its PASID) successfully (i.e. the device's sdev user count is increased).
But the reference is not dropped every time the device is unbound
successfully from the mm (i.e. the device's sdev user count is decreased).
The reference is dropped only once by calling intel_svm_free_pasid() when
there isn't any device bound to the mm. intel_svm_free_pasid() drops the
reference and only frees the PASID on zero reference.
Fix the issue by dropping the PASID reference and freeing the PASID when
no reference on successful unbinding the device by calling
intel_svm_free_pasid() .
Fixes: 4048377414 ("iommu/vt-d: Use iommu_sva_alloc(free)_pasid() helpers")
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Link: https://lore.kernel.org/r/20210813181345.1870742-1-fenghua.yu@intel.com
Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
Link: https://lore.kernel.org/r/20210817124321.1517985-2-baolu.lu@linux.intel.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Syzbot reported uninit-value in asix_mdio_read(). The problem was in
missing error handling. asix_read_cmd() should initialize passed stack
variable smsr, but it can fail in some cases. Then while condidition
checks possibly uninit smsr variable.
Since smsr is uninitialized stack variable, driver can misbehave,
because smsr will be random in case of asix_read_cmd() failure.
Fix it by adding error handling and just continue the loop instead of
checking uninit value.
Added helper function for checking Host_En bit, since wrong loop was used
in 4 functions and there is no need in copy-pasting code parts.
Cc: Robert Foss <robert.foss@collabora.com>
Fixes: d9fe64e511 ("net: asix: Add in_pm parameter")
Reported-by: syzbot+a631ec9e717fb0423053@syzkaller.appspotmail.com
Signed-off-by: Pavel Skripkin <paskripkin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently, the declaration of fill_imix_distribution() is dependent
on CONFIG_XFRM. This is incorrect.
Move fill_imix_distribution() declaration out of #ifndef CONFIG_XFRM
block.
Signed-off-by: Nick Richardson <richardsonnick@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add gfp_t mask as an input parameter to mem_cgroup_charge_skmem(),
to give more control to the networking stack and enable it to change
memcg charging behavior. In the future, the networking stack may decide
to avoid oom-kills when fallbacks are more appropriate.
One behavior change in mem_cgroup_charge_skmem() by this patch is to
avoid force charging by default and let the caller decide when and if
force charging is needed through the presence or absence of
__GFP_NOFAIL.
Signed-off-by: Wei Wang <weiwan@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
fq qdisc requires tstamp to be cleared in the forwarding path. Now ovs
doesn't clear skb->tstamp. We encountered a problem with linux
version 5.4.56 and ovs version 2.14.1, and packets failed to
dequeue from qdisc when fq qdisc was attached to ovs port.
Fixes: fb420d5d91 ("tcp/fq: move back to CLOCK_MONOTONIC")
Signed-off-by: kaixi.fan <fankaixi.li@bytedance.com>
Signed-off-by: xiexiaohui <xiexiaohui.xxh@bytedance.com>
Reviewed-by: Cong Wang <cong.wang@bytedance.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
VLAN TCI is a 16 bit field which includes Priority(3 bits),
CFI(1 bit) and VID(12 bits). Currently ntuple filters support
installing rules to steer packets based on VID only.
This patch extends that support such that filters can
be installed for entire VLAN TCI.
Signed-off-by: Subbaraya Sundeep <sbhatta@marvell.com>
Signed-off-by: Sunil Goutham <sgoutham@marvell.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 09e856d54b ("vrf: Reset skb conntrack connection on VRF rcv")
fixes the "reverse-DNAT" of an SNAT-ed packet over a VRF.
This patch adds a test for this scenario.
Signed-off-by: Lahav Schlesinger <lschlesinger@drivenets.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Saravana Kannan says:
====================
Clean up and fix error handling in mdio_mux_init()
This patch series was started due to -EPROBE_DEFER not being handled
correctly in mdio_mux_init() and causing issues [1]. While at it, I also
did some more error handling fixes and clean ups. The -EPROBE_DEFER fix is
the last patch.
Ideally, in the last patch we'd treat any error similar to -EPROBE_DEFER
but I'm not sure if it'll break any board/platforms where some child
mdiobus never successfully registers. If we treated all errors similar to
-EPROBE_DEFER, then none of the child mdiobus will work and that might be a
regression. If people are sure this is not a real case, then I can fix up
the last patch to always fail the entire mdio-mux init if any of the child
mdiobus registration fails.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
When registering mdiobus children, if we get an -EPROBE_DEFER, we shouldn't
ignore it and continue registering the rest of the mdiobus children. This
would permanently prevent the deferring child mdiobus from working instead
of reattempting it in the future. So, if a child mdiobus needs to be
reattempted in the future, defer the entire mdio-mux initialization.
This fixes the issue where PHYs sitting under the mdio-mux aren't
initialized correctly if the PHY's interrupt controller is not yet ready
when the mdio-mux is being probed. Additional context in the link below.
Fixes: 0ca2997d14 ("netdev/of/phy: Add MDIO bus multiplexer support.")
Link: https://lore.kernel.org/lkml/CAGETcx95kHrv8wA-O+-JtfH7H9biJEGJtijuPVN0V5dUKUAB3A@mail.gmail.com/#t
Signed-off-by: Saravana Kannan <saravanak@google.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Marc Zyngier <maz@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If we are seeing memory allocation errors, don't try to continue
registering child mdiobus devices. It's unlikely they'll succeed.
Fixes: 342fa19644 ("mdio: mux: make child bus walking more permissive and errors more verbose")
Signed-off-by: Saravana Kannan <saravanak@google.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Marc Zyngier <maz@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The whole point of devm_* APIs is that you don't have to undo them if you
are returning an error that's going to get propagated out of a probe()
function. So delete unnecessary devm_kfree() call in the error return path.
Fixes: b601616681 ("mdio: mux: Correct mdio_mux_init error path issues")
Signed-off-by: Saravana Kannan <saravanak@google.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Marc Zyngier <maz@kernel.org>
Tested-by: Marc Zyngier <maz@kernel.org>
Acked-by: Kevin Hilman <khilman@baylibre.com>
Tested-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
