- 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
-----BEGIN PGP SIGNATURE-----
iF0EABECAB0WIQQYqXDMF3cvSLY+g9cLBhiOFHI71QUCYRvo7gAKCRALBhiOFHI7
1bmWAJ9PI7D21ZLkSrwwuiwh/e1KpTsYcgCeODbCcOQis4VTK2vU6r+plVXLLzc=
=Mae4
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmEdAWMACgkQmmx57+YA
GNleEQ/+LYx9PbjfMFMNAOyEDQa5ypWIuL2DqHbHFZw7UOGBcUeiDlge3kLFvYtB
JeVOS54Lk85JhxgKBLeIRZ8Nhb+JNKPXbSIz4nqEb7CEvimgRMeePxSfSwyVEi3x
6xqrkXjii9clbbf1UGVTR3XPQITl7M9l7F4yj5kGft7Qt5lHbZPdn733EhnP81cG
HgrcpEviD7Y8jg+nySesenunnnWo82ZsJ/0igCYgRL+cMMDPLXWuPS86Ws0xEuyj
TEh6HR1IlzYr1V9EB7Ra0dFIms4/wDSAwzHItFw08QJs0sirqAnO0vOUETaLH6AX
xUJgvUB+hzmJKlXEwimQYTK14o2Dd8BDgko8FHK/fPE61Is551UmTjxLM0m80baL
4te8/f5h3Lo5oWfbcew8CjUJHRbOc+ZIlmQ8QztrSn6oM4JvFOjSn46aBWkagSfC
0FoeSoCmIhZoPnIOmgdlW+g60qdTeXqbqPUKsS4YTj4ZZYTULWO4I3DlLGNI303p
Z/uv0mLaHXy6TeUWs2519pF1QQ7GDKgATDXflpz9rgp2Veochd8dcDKXGGKyaT1J
P6CWvwJDauo4zMi9M+eQsqn6Vz30jiCndJOEQiMgLQNvCJpq9L1SZqCuQ1iVCPKK
gZfCT6kMdJHrMUGzYaHRc/LaaakWv+UYPtU6r333GtYRdKnZz9w=
=VEgZ
-----END PGP SIGNATURE-----
Merge tag 'mvebu-dt64-5.15-1' of git://git.kernel.org/pub/scm/linux/kernel/git/gclement/mvebu into arm/dt
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>
- New machines
* Facebook's Cloudripper
* Facebook's Elbert
* Facebook's Fuji
All three carry the description of "Facebook's next generation switch
platform with an AST2600 BMC integrated for health monitoring
purpose."
They share a 128 MB SPI NOR flash layout that is also used by some
older platforms.
* Inspur's NF5280M6, an x86 platform server with an AST2500-based BMC
- SGPIO updates including AST2600 support
- GPIO descriptions for the IBM AST2600 machines
- Pinctrl fix
- Updates to Facebook's AST2500 based machines
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE+nHMAt9PCBDH63wBa3ZZB4FHcJ4FAmEbYpcACgkQa3ZZB4FH
cJ5MQA//acXKEAKZgQ9op7wanVrQH37BkvFBkn02vwKWHJXt7tIXMlf19yeOSMsL
BIR4wPzWLCrK0Jy5R5AxSYcPosibjWZFKHPtgk9JfS2LHF11agYe+zTgBLkXgQbe
jVcraSaUOJ19on8iuYz50zhzcj5P0vlCN49dORcn0Ey0zw1Wnf6+D+//VcnlFaSt
6+vHGUyviMiQ8Ws6G0b1ZoWiM9mEDyLxUGVD+Qe/P5E/49ClkzowWswcBUcOgRmS
G/nHmPTWmxDKk8KAXPzijnbbxUmueepvv96Fbfvg8VEFP/alAEKKnn2QpTUF6kbi
y9IL1ryR8fzJS57HhEJ5O+l//+N0pvPlfsaLt4ZchZOBG9+zmbwOL3Q//qZ3/Ca2
vEUMp59f8uB8/coM3dzyuMWEPbn5nEuNAVDH8PVTcJsVxGSNHHHfb09ISmWGWacA
F8e6jAJVFkhf5xeoHV7qmf1l1VDwOCm3Fsgp1jGARZrK89sZmOlV5rgO7IIe7Swh
Y+itv+EOu8T1bJ+fs0eXLMUnGR/dw8OUmRIsgXnKCYAAPrjLfg8zusQfpr6mfMUA
tXpYxQqqVw+XXCtGewAoF3PHwuOcRxQbAJn1v4QrzYNseteJqoryzcMEZrZcocKQ
JwNQTJZyQ2OitRPHOnnTzLqgE5sV/PFHdzGpFgmPjfUkT/4Y+L0=
=GIHt
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmEdALkACgkQmmx57+YA
GNkzaBAAsDX3tqMQIo/U8o80Puwb7ZoupCxygmivhDSLaFtcvn/k14YT3Qi8JG/a
1NUSXi+YsM1du0QS3BI0bMrWIyLtj/7q2785UlyMOUS2DXukUuGLWMVTXmPOHh99
7N77IQuC/HB/qPiDm76V6Ax6ax6FVY4LQKXlur3z2MM5ZP2PbaLK2CG1VmZuH/gv
qVNFz1bQVjJ2j3iegGt3+bb1uaZshTX0S7PFrvvI0UmUjlfm9oKfGgYepFb6Rfi5
lQ1MP475qBMPWE/UIQ4hsg49PxOXKP9PsuW6+hK23GbgNoI2esgnJBG5mwzkWz+S
/H+2zeldljKQ1COBu0WztRQqDJTVphOlgbSRkQpYC6UJvXWs7XDrzrIXlLfu7gmn
FTPpQ2d+k+eTP2P2VHh2tgUDbf+OBftZvrad/2RW2WzFVrGd5oDt/kdXAxcOxC7i
fC2VKl9ban2xg1WBFgRUaH1t5OiUv7FaW3k2yFfkCSmbSY6OJSoUAMhhs3XuCW3T
nNCDRj6kew1qhl3zSUweGsZ3DdjctTr6ab1TFZd0BsGUl/7FQ5ycNx/LGafH2GtC
NCUxjK4ZSKddy7ROjyqwBH4zmevLbJz/ae+RbWKUh0aJcDC50LlWuH0dcFO2jlLx
yMcW71TqipL0BcTh6nfK1dJMbqrBOeQhTKC7NGcOZ9D2T+xu79g=
=Y4SA
-----END PGP SIGNATURE-----
Merge tag 'aspeed-5.15-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc into arm/dt
ASPEED device tree updates for 5.15
- New machines
* Facebook's Cloudripper
* Facebook's Elbert
* Facebook's Fuji
All three carry the description of "Facebook's next generation switch
platform with an AST2600 BMC integrated for health monitoring
purpose."
They share a 128 MB SPI NOR flash layout that is also used by some
older platforms.
* Inspur's NF5280M6, an x86 platform server with an AST2500-based BMC
- SGPIO updates including AST2600 support
- GPIO descriptions for the IBM AST2600 machines
- Pinctrl fix
- Updates to Facebook's AST2500 based machines
* tag 'aspeed-5.15-devicetree' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/bmc: (23 commits)
ARM: dts: aspeed: p10bmc: Add power control pins
ARM: dts: aspeed: cloudripper: Add comments for "mdio1"
ARM: dts: aspeed: minipack: Update flash partition table
ARM: dts: aspeed: Add Facebook Fuji (AST2600) BMC
ARM: dts: aspeed: Add Facebook Elbert (AST2600) BMC
ARM: dts: aspeed: Add Facebook Cloudripper (AST2600) BMC
ARM: dts: aspeed: Common dtsi for Facebook AST2600 Network BMCs
ARM: dts: aspeed: wedge400: Use common flash layout
ARM: dts: Add Facebook BMC 128MB flash layout
ARM: dts: aspeed-g5: Remove ngpios from sgpio node.
ARM: dts: aspeed-g6: Add SGPIO node.
dt-bindings: aspeed-sgpio: Add ast2600 sgpio
dt-bindings: aspeed-sgpio: Convert txt bindings to yaml.
ARM: dts: aspeed: ast2500evb: Enable built in RTC
ARM: dts: aspeed: tacoma: Add TPM reset GPIO
ARM: dts: rainier, everest: Add TPM reset GPIO
ARM: dts: aspeed: wedge100: Enable ADC channels
ARM: dts: aspeed: galaxy100: Remove redundant ADC device
ARM: dts: aspeed: wedge40: Remove redundant ADC device
ARM: dts: aspeed: Enable ADC in Facebook AST2400 common dtsi
...
Link: https://lore.kernel.org/r/CACPK8XdWRBb9cuDWGQPfK8R8TsZuydJQHsL4_e2w=HvCKAMogg@mail.gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
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.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmEa7+IbHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FAlsP/0ANjr6SLBWDZ5fAv/7a
Fz26/VeZwjnZ0uzCAmsfjDfzShPuZLoDw1WzoU2Tqj1YGk6TZsResjBHAeVTHfbI
oTPVONqgumjOhVsGUKIWtYOybeO5+byOREZGR+bxGjGnhLsNwvcMsR6fplL6w+x/
/fqF+hzRmiVVvD61eH2r8r6mXlnmT27kS7NeJAYFOh1YQmsEK1HKs6e2tbV00ftb
bEWgcAmXSwpJ+0aSb4JN54DS7/LFFGBB9kVC65pJJpAkcsCT74QP0kY28iNLn9Qk
Yb/ueSFXHT/mdlhsYGZWZk7p9Wr6P/Wpyr3WM3hJDjwSQXF7LkaI78afbbVFNWsW
p529sEZa3z21vLDddSd/BVh32es4bu3Fnl/mPk4csrqWFOkvjHsOYD+hBgri+GBP
a0lwOSDngIAZQrD8dRo5z5SrjAIkTRTwws8BGj/dD0NjgFDWPeveIlmr7miSHK6c
9ljK28WLajrLNOcnwqA5guCXe5zOP34I+CgVMdC5MfsbKds1u7X5i+ioiRUS0g7j
3GpwN05+QNGEm5GVmvjCTaRNRK2sL8jBUakJifzfdp5wYWY9BngB8v8xDkYwI9v0
ozM0MzvwWX+2bqGR7teUcAZeA/0aDQqRZd1mxE2UkhDs12iBLX8NxDV+kFvk0XPi
/foS/qsmiIiuvuoTAeGVXecM
=GGZW
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmEc/xgACgkQmmx57+YA
GNlG1Q//R10RiavcIYs2uJql1C3TgCxb8I0pKqVjuYi01f7XtyhcwNS/fbZ0kRcV
Cjdza+owaWxnsBuNS5IocdRzRckqeCoRzvAKjZoSkgAuEIYLWyi8sC5YF5ilELhX
NfekAo/I12iDgu0Zt5g481sWBwc1qzCcC9BvS1Nd3tsbBgl45XhM6pk1+zpV4avi
U8JqRNgbsJ66+y/cy5VGWavB0OCmDP46hmnf9t2OmPBuZ+lVLy98WvLikS42HUq6
prnpLh1q81jaVTghpydHyJ/Z/12uwxySc17B7cAYtcbUyqsgaG2st6wDwWBlq+4y
vz81tDEpdEM1w4tGzKtmi+bribn0ftATYbfW6NdYMo0tEp7wWSOpPBqjeC/O1xm9
/pVuN2l9FB/iJAkYQoeuY3Sj/WF1KVZ0/OkcG/ZR048DdsMG8LOVH4xcaTBbaPtb
3oPgXUDk0mnSdDQs6mFPxt9gJR6SKsPUDdjSwuPbX1UIlSjnmgvlwx22wIMw0TBR
x9TyxHMOPnsrHmplatbKFyGvmGOgCiKKF3gEYBZB76QOy1qjMxcWpH2sNgrDK08z
WIjz2nybDVAOkEXrRYL3gmsSWCBJcyEIJDGqWXshtN3iCw9k3V+KFbC6X1q/0atv
otGv8aGclP8Cuvxm2tD7O+rUAIa6pEJyrz67i431++/DVFDAy6A=
=lQQn
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-for-5.15' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
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>
- 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
-----BEGIN PGP SIGNATURE-----
iQFEBAABCgAuFiEEPxTL6PPUbjXGY88ct6xw3ITBYzQFAmEWlToQHHdpbGxAa2Vy
bmVsLm9yZwAKCRC3rHDchMFjNGdHB/9iz9jooiYm2LcK1BKiKAnr4TRr80eI8/xu
sbj3khN+faN2M1n05up8FHSKGa7973Bu8wXBvKgUH5gFFWoiKBUoTYWoZKu4Sxre
2WfSRrsZ9yQd6+exK80ex9wkkLrK0kXYJrUzVaicQFCz6pKRvnj77+8qmzTCJDeV
18JuA3Y5nonwxaBfmToHj4hoPZi6jTiR0Q/MMG88FfR4Bv46Ef6cpv+EEgL3PNmd
kstRBbha8Dketo4VXiHSGHZ9sn6CqYbZ0IkTdctrJbApI2DZW0H9SlBYKJSodXB3
4pNJADQZXiot79CtXEjiGNunBBFJUnJTFEGdmaFfOAJqTmW38mjV
=9PBi
-----END PGP SIGNATURE-----
Merge tag 'arm-smmu-updates' of git://git.kernel.org/pub/scm/linux/kernel/git/will/linux into arm/smmu
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>
To parallel the sysfs behaviour, merge the new build-time option
for DMA domain strictness into the default domain type choice.
Suggested-by: Joerg Roedel <joro@8bytes.org>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: John Garry <john.garry@huawei.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/d04af35b9c0f2a1d39605d7a9b451f5e1f0c7736.1628682049.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
When passthrough is enabled, the default strictness policy becomes
irrelevant, since any subsequent runtime override to a DMA domain type
now embodies an explicit choice of strictness as well. Save on noise by
only logging the default policy when it is meaningfully in effect.
Reviewed-by: John Garry <john.garry@huawei.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/9d2bcba880c6d517d0751ed8bd4960853030b4d7.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>
In preparation for the strict vs. non-strict decision for DMA domains
to be expressed in the domain type, make sure we expose our flush queue
awareness by accepting the new domain type, and test the specific
feature flag where we want to identify DMA domains in general. The DMA
ops reset/setup can simply be made unconditional, since iommu-dma
already knows only to touch DMA domains.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/31a8ef868d593a2f3826a6a120edee81815375a7.1628682049.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Promote the difference between strict and non-strict DMA domains from an
internal detail to a distinct domain feature and type, to pave the road
for exposing it through the sysfs default domain interface.
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/08cd2afaf6b63c58ad49acec3517c9b32c2bb946.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>
iommu_dma_init_domain() is now only called from iommu_setup_dma_ops(),
which has already assumed dev to be non-NULL.
Reviewed-by: John Garry <john.garry@huawei.com>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/06024523c080364390016550065e3cfe8031367e.1628682049.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
Now that everyone has converged on iommu-dma for IOMMU_DOMAIN_DMA
support, we can abandon the notion of drivers being responsible for the
cookie type, and consolidate all the management into the core code.
CC: Yong Wu <yong.wu@mediatek.com>
CC: Chunyan Zhang <chunyan.zhang@unisoc.com>
CC: Maxime Ripard <mripard@kernel.org>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Jean-Philippe Brucker <jean-philippe@linaro.org>
Reviewed-by: Lu Baolu <baolu.lu@linux.intel.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/46a2c0e7419c7d1d931762dc7b6a69fa082d199a.1628682048.git.robin.murphy@arm.com
Signed-off-by: Joerg Roedel <jroedel@suse.de>
The symbol isn't needed outside of i915.ko.
Fixes: b30edfd8d0 ("drm/i915: Switch to LTTPR non-transparent mode link training")
Fixes: 264613b406 ("drm/i915: Disable LTTPR support when the DPCD rev < 1.4")
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210816071737.2917-1-jani.nikula@intel.com
(cherry picked from commit d8959fb338)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
ADL-P supports stream splitter on pipe B in addition to pipe A. Update
the sanity check in intel_ddi_mso_get_config() to reflect this, and
remove the check in intel_ddi_mso_configure() as redundant with
encoder->pipe_mask. Abstract the splitter pipe mask to a single point of
truth while at it to avoid similar mistakes in the future.
Fixes: 7bc188cc2c ("drm/i915/adl_p: enable MSO on pipe B")
Cc: Uma Shankar <uma.shankar@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Swati Sharma <swati2.sharma@intel.com>
Reviewed-by: Swati Sharma <swati2.sharma@intel.com>
Tested-by: Swati Sharma <swati2.sharma@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210812132354.10885-1-jani.nikula@intel.com
(cherry picked from commit f6864b27d6)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform
despite Wa_14010685332 original sequence,
thus blocks entry to deeper s0ix state.
The Tweaked Wa_14010685332 sequence fixes this issue, therefore use tweaked
Wa_14010685332 sequence for every PCH since PCH_CNP.
v2:
- removed RKL from comment and simplified condition. [Rodrigo]
Fixes: b896898c73 ("drm/i915: Tweaked Wa_14010685332 for PCHs used on gen11 platforms")
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20210810113112.31739-2-anshuman.gupta@intel.com
(cherry picked from commit 8b46cc6577)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
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>
kfree(NULL) is safe, so remove unnecessary null pointer checks before
calls to kfree. Reported by checkpatch.
Signed-off-by: Michael Straube <straube.linux@gmail.com>
Link: https://lore.kernel.org/r/20210818085809.31451-1-straube.linux@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove including <linux/version.h> that don't need it
Acked-by: Michael Straube <straube.linux@gmail.com>
Signed-off-by: Cai Huoqing <caihuoqing@baidu.com>
Link: https://lore.kernel.org/r/20210818095331.3422-1-caihuoqing@baidu.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
struct hfa384x_wpa_data ends with a flexible array, but it is allocated
on the stack. This means it can never hold any data. Disable the
memcpy() calls in and out of the structure, since it must always be
zero. This could never have worked.
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Igor Matheus Andrade Torrente <igormtorrente@gmail.com>
Cc: linux-staging@lists.linux.dev
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210818081937.1668775-1-keescook@chromium.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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>
PHY initialization for USB is required on linux boot or when
gt lane is changed from the current one and it is applicable
on PLL lock too.
Signed-off-by: Piyush Mehta <piyush.mehta@xilinx.com>
Link: https://lore.kernel.org/r/20210818084311.2643986-1-piyush.mehta@xilinx.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
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>
