33024 Commits

Author SHA1 Message Date
Linus Torvalds
be54864552 s390:
* fix a latent bug when the kernel is compiled in debug mode
 
 * two small UCONTROL fixes and their selftests
 
 arm64:
 
 * always check page state in hyp_ack_unshare()
 
 * align set_id_regs selftest with the fact that ASIDBITS field is RO
 
 * various vPMU fixes for bugs that only affect nested virt
 
 PPC e500:
 
 * Fix a mostly impossible (but just wrong) case where IRQs were
   never re-enabled
 
 * Observe host permissions instead of mapping readonly host pages as
   guest-writable.  This fixes a NULL-pointer dereference in 6.13
 
 * Replace brittle VMA-based attempts at building huge shadow TLB entries
   with PTE lookups.
 -----BEGIN PGP SIGNATURE-----
 
 iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmeDrZkUHHBib256aW5p
 QHJlZGhhdC5jb20ACgkQv/vSX3jHroMX/wf/VPTDn+T0EcWBduH+hJ/g0uxM0TqM
 vHmoL8sXrH9yVrqcdlOVXDc9R6h7q44cuOM/ZPBZuR4QAJqcL7b9KDDQWyOphzQt
 U6rKDbnDZyEAC5Ti586qncKGoEv7vgL2LOVW5MUyyYzyWAKmNs2HNSIQkKmDEPiQ
 KXWMhtncC3x+TbesbwMxwE/F94M7PFVynaoODH/dY8C7ZsPykIBRuUz4WSE/411b
 Dy8TOYyesPg4pCT8YASHCt8PIwwBUXpEUfhEqElOGM4I3rOfWXFe1w1VyizXLyO5
 lULZ3zfP6+jlWxbz9Nyvb5rSRJO8a6PfmqhsbFavGQau0u/3AR2cLTA92w==
 =UpHe
 -----END PGP SIGNATURE-----

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull kvm fixes from Paolo Bonzini:
 "The largest part here is for KVM/PPC, where a NULL pointer dereference
  was introduced in the 6.13 merge window and is now fixed.

  There's some "holiday-induced lateness", as the s390 submaintainer put
  it, but otherwise things looks fine.

  s390:

   - fix a latent bug when the kernel is compiled in debug mode

   - two small UCONTROL fixes and their selftests

  arm64:

   - always check page state in hyp_ack_unshare()

   - align set_id_regs selftest with the fact that ASIDBITS field is RO

   - various vPMU fixes for bugs that only affect nested virt

  PPC e500:

   - Fix a mostly impossible (but just wrong) case where IRQs were never
     re-enabled

   - Observe host permissions instead of mapping readonly host pages as
     guest-writable. This fixes a NULL-pointer dereference in 6.13

   - Replace brittle VMA-based attempts at building huge shadow TLB
     entries with PTE lookups"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: e500: perform hugepage check after looking up the PFN
  KVM: e500: map readonly host pages for read
  KVM: e500: track host-writability of pages
  KVM: e500: use shadow TLB entry as witness for writability
  KVM: e500: always restore irqs
  KVM: s390: selftests: Add has device attr check to uc_attr_mem_limit selftest
  KVM: s390: selftests: Add ucontrol gis routing test
  KVM: s390: Reject KVM_SET_GSI_ROUTING on ucontrol VMs
  KVM: s390: selftests: Add ucontrol flic attr selftests
  KVM: s390: Reject setting flic pfault attributes on ucontrol VMs
  KVM: s390: vsie: fix virtual/physical address in unpin_scb()
  KVM: arm64: Only apply PMCR_EL0.P to the guest range of counters
  KVM: arm64: nv: Reload PMU events upon MDCR_EL2.HPME change
  KVM: arm64: Use KVM_REQ_RELOAD_PMU to handle PMCR_EL0.E change
  KVM: arm64: Add unified helper for reprogramming counters by mask
  KVM: arm64: Always check the state from hyp_ack_unshare()
  KVM: arm64: Fix set_id_regs selftest for ASIDBITS becoming unwritable
2025-01-12 12:04:53 -08:00
Paolo Bonzini
5c99a684c9 KVM/arm64 changes for 6.13, part #3
- Always check page state in hyp_ack_unshare()
 
  - Align set_id_regs selftest with the fact that ASIDBITS field is RO
 
  - Various vPMU fixes for bugs that only affect nested virt
 -----BEGIN PGP SIGNATURE-----
 
 iI0EABYIADUWIQSNXHjWXuzMZutrKNKivnWIJHzdFgUCZ3Cfbxccb2xpdmVyLnVw
 dG9uQGxpbnV4LmRldgAKCRCivnWIJHzdFuc4AQDcDPzJAmtA2xem+JOTPwTOl4Fk
 TKDfwes3zZ/42/BA8wEA2X4vKcSwQTujdCpRrRiQvegn3pcT4V9oo9TB0kzjoQU=
 =KEa8
 -----END PGP SIGNATURE-----

Merge tag 'kvmarm-fixes-6.13-3' of https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD

KVM/arm64 changes for 6.13, part #3

 - Always check page state in hyp_ack_unshare()

 - Align set_id_regs selftest with the fact that ASIDBITS field is RO

 - Various vPMU fixes for bugs that only affect nested virt
2025-01-12 12:50:39 +01:00
Arnd Bergmann
5391c5d8e6 Fixed card-detect on one board and some missing properties added.
-----BEGIN PGP SIGNATURE-----
 
 iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmeAXgAQHGhlaWtvQHNu
 dGVjaC5kZQAKCRDzpnnJnNEdgfi3CACZduWgY5wxOLWeXBFhGRjeVpld0fM7EYdO
 VTuMgIjQTDo8pi+uGmP49HP/Uz9w4YxTbhAT5lBwdBnHs0SrTMWUZcp6R146ihbc
 IQ5SogUdK0WpvaRk0hnntZ1kzbje8xP2O0wwPLi7pf+gDgNvzbnMQzba4n010KII
 eM2yzQJ78szoNa4WfO8q8U4J2mNEjzdNX0bNw9CqUIvQxB7ndhnAlkIlZghisAXq
 WSd4w/EG0hXbd17KNR1/ZnyPzxyu1z2/2RS71Up4c35fYn0a57x6kqdzSyuNMbuF
 jwlR7wBW9FTWb/iMRhYo4ACx5DAutZytpr5RjmLVtSzEbZqdE1MP
 =8yDt
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmeBVvsACgkQYKtH/8kJ
 Uic6UQ/+KqYxW6yca/l3NfRz8v+LzCAQyUFTM7VJnfsVmkg4A2SimrKbt93OWJXU
 MFoPDI9SwNrrq7yFSSxuzEfdoROIfxEK1JBUXSFDTdWU1uqGJfsTAMEINoR0uCC1
 A21qNz4Tr8S9nYpgvaQCssH88HM736QkPiwhS1cTZHHaduU585a4ycDqCZSXYdj7
 nUM0SD6sJ6K8UN32hj7eD+sYIV/plSHIdybAlcpUNRR/GLLTxoReb7fkDeXVBHkE
 NhS1L1T3XWXfHJJZLZhVA1gJmpicUBJeX4UgbVeNV97F4UxJL4JcU7B2kdJppl/9
 W5awxVA3ANC7jB94N+hY58MOA+qfcCwLIL3NsyPjghS61XGMRGRw02EI0WymO9Zg
 puD0NVvH8SMQ1n/5ryrlCoEdDbjc2H/P+v2VmohY+oPzThsjrcy4CpQVGS2nOAAx
 3SlUqUxYz97YeewR9D3wunpFtfm5grlBG17Xfzf8SK5J5MoDbl3QGSvxojlsz7+p
 piQjyntdzPUbsIQGMUpn0FVHDRjPhE2AotacHTmgJXEcFf1C6d1f9VrR8WTEXmhQ
 uFrsk3bslVXV4mlHMAhA+z2OvwPRaeOziFk2r9k/XE+hdbut29CQpUZbTwO/Rqn8
 bgj80v5dZMac+u1FcA1lcs7FUTDCiLvFPbNor31FMmsd3KmxgDU=
 =aKk7
 -----END PGP SIGNATURE-----

Merge tag 'v6.13-rockchip-dtsfixes1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes

Fixed card-detect on one board and some missing properties added.

* tag 'v6.13-rockchip-dtsfixes1' of https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
  arm64: dts: rockchip: add hevc power domain clock to rk3328
  arm64: dts: rockchip: Fix the SD card detection on NanoPi R6C/R6S
  arm64: dts: rockchip: rename rfkill label for Radxa ROCK 5B
  arm64: dts: rockchip: add reset-names for combphy on rk3568

Link: https://lore.kernel.org/r/2914560.yaVYbkx8dN@diego
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-01-10 18:20:59 +01:00
Arnd Bergmann
00f63a0f5f i.MX fixes for 6.13:
- Add fallback for i.MX8QM ESAI compatible to fix a dt-schema warning
   caused by bindings update
 - Fix uSDHC1 clock for i.MX RT1050
 - Enable SND_SOC_SPDIF in imx_v6_v7_defconfig to fix a regression caused
   by an i.MX6 SPDIF sound card change in DT
 - Fix address length of i.MX95 netcmix_blk_ctrl
 -----BEGIN PGP SIGNATURE-----
 
 iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmdyX50UHHNoYXduZ3Vv
 QGtlcm5lbC5vcmcACgkQUFdYWoewfM7Yhgf/YFbJU/RQ/FW3Bp/ZGu8HA/gfW0gM
 s1Zv/vfydHXXiecPLWx9+TUuk0JtVPjgijzmCTbBhM1he+HcCQy72aoFY+ttDhKj
 MOSOnHdFYroB/ydsPQ+RlqPkPj36zysH7iWR/sZ5d3/Vfo/3q6dxvkG5SfdilO/i
 cGwXvQRuovRea70zdT7VOww8vdaagvaik+wrLYTGyh94pth7SDP/Z09prvzYApO5
 EigO39meVA+r65vYRYYtgPRkcsE+ZpGM5E4sTEy7xWmvTxz5VC9NhnoWy7XeNSVh
 ku9wXAxE2O5HQp5dxx+rMZUDetZ0VM7BJXHNBCHSqNJzdHY28/NymVtT7w==
 =lwDB
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmeARf8ACgkQYKtH/8kJ
 UidqKg//f0y3prnNbWF6KTZ7Rk8vVEoVgXDKO2cBMTxI8ofRwxQD0TCQ8hr19fOW
 Wa+KKUC4LMDzSYvreQMZP/y8anuetjVj+0UQ+GkpGUiBcSwq4EWoomDwFMHT1lRR
 82FcBpWJ6zfRrf0l0kcsHu+2+T3Z/Oxt4YHiXC2WK4gMZHeTcmGEG2gweLjqxlvm
 KwLgD9RAGh11ab3LfMHriZLUZX9P4/MNAZ+QRmyBXHizgEaSdIhLCYAyYfDoX5Oy
 kqHIz9U8YtfyVLqS7PMlFidQW6DPmP7abwmnEqZZughmDDmv+p7FBZs3qHhm7zVa
 94/YNpS7BT7Ucvib9oM8cpR/yrVLL39TbV3ycKvfo8q1Rm2ooouaVD3+8nbk6f9M
 qCi1qkEyjeB3a/7+IbyhQkSyqaEeQLF6n4PwzBenF50VzSQA2I7WJg1Mp437GHgh
 wLU8XAFMCDLzvkqSTJTObtYY61S+n1pnWgKHQm67NatDeMhC+nx9eyRxHI7zsek2
 IvQBTBxErXfTf7MIBM2WNDbwqqUPpmwn5LWmnSj7kYHuRXHOvc4+41UXOfUCNQG3
 MqzKXq0SbuoMkG6rh27YDjfE6WjXeuwkXOUbULvNc2Nd8q5ppx07kOEcrHUPlY0b
 6mhDb2oIo9f8Ps6Ujx6KWpz/S3cuUo+ANku4b56JAR0UobeoA3w=
 =gT/D
 -----END PGP SIGNATURE-----

Merge tag 'imx-fixes-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes

i.MX fixes for 6.13:

- Add fallback for i.MX8QM ESAI compatible to fix a dt-schema warning
  caused by bindings update
- Fix uSDHC1 clock for i.MX RT1050
- Enable SND_SOC_SPDIF in imx_v6_v7_defconfig to fix a regression caused
  by an i.MX6 SPDIF sound card change in DT
- Fix address length of i.MX95 netcmix_blk_ctrl

* tag 'imx-fixes-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
  ARM: dts: imxrt1050: Fix clocks for mmc
  ARM: imx_v6_v7_defconfig: enable SND_SOC_SPDIF
  arm64: dts: imx95: correct the address length of netcmix_blk_ctrl
  arm64: dts: imx8-ss-audio: add fallback compatible string fsl,imx6ull-esai for esai

Link: https://lore.kernel.org/r/Z3Jf9zbv/xH3YzuB@dragon
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-01-09 22:56:15 +01:00
Arnd Bergmann
627522c8bf Qualcomm Arm64 DeviceTree fixes for v6.13
Revert the enablement of OTG support on primary and secondary USB Type-C
 controllers of X1 Elite, for now, as this broke support for USB hotplug.
 
 Disable the TPDM DCC device on SA8775P, as this is inaccessible per
 current firmware configuration. Also correct the PCIe "addr_space"
 region to enable larger BAR sizes.
 
 Also fix the address space of PCIe6a found in X1 Elite.
 -----BEGIN PGP SIGNATURE-----
 
 iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmd3UBEVHGFuZGVyc3Nv
 bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3FYPMP/RAdO4vAnJ034xLLOp0R/hpAFVew
 /WOZf4WgHwjmC89VEp95zabxMB3oWn6Wdk7mKN/+NTcKHs7cMLQ/d8aVX67mlomG
 i0q757Wzgm2GSioHbeKQ9me/rNOCRgpx8ZUZEjC64FraE/1s8Be2zTLqyX2xfUoz
 PMpPEUlI51IPk6vUv/aU4U1uqqTZBQINIZ7hmMei8B0FwVs9cDx/uUsGccz2AgWA
 i776PHKmBg8EhaJJxaXKuXl84qH7B3XrlzOTWmx2eLIUVAiId3kscsCxkJLxHlPp
 jWiN0TBB8sRa7q8wDVfjKOg0rBjtpTFVrdcVGTU7/Ub8aHI3YGpD4LnqBx91YqXF
 wa7ZhdTVdsroCSJvLG0c2cgmRm6ZfaPpOtw4x2KgrZkhPGpVInftEmHVm5uSSwhx
 M+D2RoGESj1mQhcJ72Kuqmrd1C8UQtF4JkDAY+5vOHf+ixt0QjAtd6URh0n9WlEl
 GYZvVSzHqv+fwpzkRJljiNrVK3c6/1TtEWIdm+c/jeSo02D2m/AAHJwb/nSlI875
 6aOKFeVGf1IT2k5cu4cMhtpJpnkwNKz1uJfc8O5gOjYTGvLzFKFYv0nekfvCMbOS
 fPheUn4RAtCohSkAUB8OVFkF04iH2J/o6npiM1GPbaC61rrL/3ylhVRqzIw5Hmkz
 G8XTFXyiABPXFls2
 =MuLc
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmeARa0ACgkQYKtH/8kJ
 UieF2g//WDchFn0Wk4WjeQh93kDP7JIlkmEXmCq+hfVF6fX+4ONRRhJTtH2Eacrf
 mhmf+tkbc9Yy3xLuvcoZafhhq2pXvtUYa/iR86XB0oYXhYuvbcE0cICNGod8V92G
 ZHEj5KBnU/U3vyD8d3iy5aliy44bqH9Powl63YfD8XdAbLXh8CrXeILsIZsV04WU
 8fWz0/NYyst3Jtjc/HEK7CrZi4jO4mU4AncnSZn6qh7R9FPK8i5NyEpak0+ZnOcl
 FIJM0EfGJbESLxCOHUkkrcBiKTzBAKh8ej1xiYpfBoNOF7DtS7XlF0pXPFuyrguW
 MjKJl5JXppLRSEurv76iHFwUAVgtwVJ3o0dcaPCfiErcO+68JWm0+J4v5irAzBG/
 s6FSePdZZI/p1ghQPs8ZAe1H9BB5jK5KNfrsE3vgKhwFf7in5/afgdestg+YYnJc
 fRSwU8FkrZ7pQ0QXPyjr4CRjCugnuBnIU+v5Ad9BRY26BGSnyQwVbO6K/4b6MH/p
 n1dSyl+2DvpAFBA+/9ZkRbfF/xBN97TvF0RN+mPwNB5v1OhNhi83lnk96EQ+WSJp
 QuSN0GmTQuzxg4yiA+VZDrUncJaGVdwBAuO2tQgpc+LXXon2n/dMiDDirhEgj8e3
 /oQSPyg63CB+nfgWuvu/Kc4mJTbXuhsTBQ/2dP2RTyiQ09TbZQY=
 =rNWN
 -----END PGP SIGNATURE-----

Merge tag 'qcom-arm64-fixes-for-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/fixes

Qualcomm Arm64 DeviceTree fixes for v6.13

Revert the enablement of OTG support on primary and secondary USB Type-C
controllers of X1 Elite, for now, as this broke support for USB hotplug.

Disable the TPDM DCC device on SA8775P, as this is inaccessible per
current firmware configuration. Also correct the PCIe "addr_space"
region to enable larger BAR sizes.

Also fix the address space of PCIe6a found in X1 Elite.

* tag 'qcom-arm64-fixes-for-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
  arm64: dts: qcom: sa8775p: fix the secure device bootup issue
  Revert "arm64: dts: qcom: x1e80100: enable OTG on USB-C controllers"
  Revert "arm64: dts: qcom: x1e80100-crd: enable otg on usb ports"
  arm64: dts: qcom: x1e80100: Fix up BAR space size for PCIe6a
  Revert "arm64: dts: qcom: x1e78100-t14s: enable otg on usb-c ports"
  arm64: dts: qcom: sa8775p: Fix the size of 'addr_space' regions

Link: https://lore.kernel.org/r/20250103024945.4649-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2025-01-09 22:54:53 +01:00
Peter Geis
3699f2c43e arm64: dts: rockchip: add hevc power domain clock to rk3328
There is a race condition at startup between disabling power domains not
used and disabling clocks not used on the rk3328. When the clocks are
disabled first, the hevc power domain fails to shut off leading to a
splat of failures. Add the hevc core clock to the rk3328 power domain
node to prevent this condition.

rcu: INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 3-.... }
1087 jiffies s: 89 root: 0x8/.
rcu: blocking rcu_node structures (internal RCU debug):
Sending NMI from CPU 0 to CPUs 3:
NMI backtrace for cpu 3
CPU: 3 UID: 0 PID: 86 Comm: kworker/3:3 Not tainted 6.12.0-rc5+ #53
Hardware name: Firefly ROC-RK3328-CC (DT)
Workqueue: pm genpd_power_off_work_fn
pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : regmap_unlock_spinlock+0x18/0x30
lr : regmap_read+0x60/0x88
sp : ffff800081123c00
x29: ffff800081123c00 x28: ffff2fa4c62cad80 x27: 0000000000000000
x26: ffffd74e6e660eb8 x25: ffff2fa4c62cae00 x24: 0000000000000040
x23: ffffd74e6d2f3ab8 x22: 0000000000000001 x21: ffff800081123c74
x20: 0000000000000000 x19: ffff2fa4c0412000 x18: 0000000000000000
x17: 77202c31203d2065 x16: 6c6469203a72656c x15: 6c6f72746e6f632d
x14: 7265776f703a6e6f x13: 2063766568206e69 x12: 616d6f64202c3431
x11: 347830206f742030 x10: 3430303034783020 x9 : ffffd74e6c7369e0
x8 : 3030316666206e69 x7 : 205d383738353733 x6 : 332e31202020205b
x5 : ffffd74e6c73fc88 x4 : ffffd74e6c73fcd4 x3 : ffffd74e6c740b40
x2 : ffff800080015484 x1 : 0000000000000000 x0 : ffff2fa4c0412000
Call trace:
regmap_unlock_spinlock+0x18/0x30
rockchip_pmu_set_idle_request+0xac/0x2c0
rockchip_pd_power+0x144/0x5f8
rockchip_pd_power_off+0x1c/0x30
_genpd_power_off+0x9c/0x180
genpd_power_off.part.0.isra.0+0x130/0x2a8
genpd_power_off_work_fn+0x6c/0x98
process_one_work+0x170/0x3f0
worker_thread+0x290/0x4a8
kthread+0xec/0xf8
ret_from_fork+0x10/0x20
rockchip-pm-domain ff100000.syscon:power-controller: failed to get ack on domain 'hevc', val=0x88220

Fixes: 52e02d377a72 ("arm64: dts: rockchip: add core dtsi file for RK3328 SoCs")
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20241214224339.24674-1-pgwipeout@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-09 16:22:49 +01:00
Anton Kirilov
95147bb42b arm64: dts: rockchip: Fix the SD card detection on NanoPi R6C/R6S
Fix the SD card detection on FriendlyElec NanoPi R6C/R6S boards.

Signed-off-by: Anton Kirilov <anton.kirilov@arm.com>
Link: https://lore.kernel.org/r/20241219113145.483205-1-anton.kirilov@arm.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2025-01-08 13:18:05 +01:00
Jie Gan
8a6442ec34 arm64: dts: qcom: sa8775p: fix the secure device bootup issue
The secure device(fused) cannot bootup with TPDM_DCC device. So
disable it in DT.

Fixes: 6596118ccdcd ("arm64: dts: qcom: Add coresight nodes for SA8775p")
Signed-off-by: Jie Gan <quic_jiegan@quicinc.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20241219025216.3463527-1-quic_jiegan@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-12-25 22:05:40 -06:00
Linus Torvalds
48f506ad0b soc: fixes for 6.13, part 2
Two more small fixes, correcting the cacheline size on Raspberry Pi 5
 and fixing a logic mistake in the microchip mpfs firmware driver.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmdnPmkACgkQYKtH/8kJ
 UicYsw//V/P84VpktPuSbZ4Uy41ns35DNmkSmZRGl5qTjTND6yjdl1ZkngzhHfC5
 7yrq6OcHseErfUsv4OKpRYtsmSEl/hJcVKQTKP3m9qZ+TCpym0bmQc+pbnbNtwXI
 1Um9Y5QL0yKw60elNW4ysJ+vUGlgMBIQG0gtz4aNu0BeLR2pEbs+WsodTm0z5Z8j
 AptHtB2Z1+ODM+uxJ44sVEd+uyC8cc3u8yWgMKNXVTPbI9xGm7IOoXb95rJGyFid
 WLgyU7ZDvPOMUwwbsp87bY0PUP8fQpMrxqnz51/TbzJiMs1U6Ikmg4imIPjAemh0
 yb+8sH8M1mY8nV4efP/W5BEftGo1fc1yrzlEkb0Bgds10Ys4ra2JI/s5QJ7VOAY9
 pZ/ajSiGjQ9elvd/es4KKbKwDnlccw77TaauKEkTyD6ZVmNZR7/s8IZ2/Zy//k3A
 2bXP07GSgSH7Z5FUB3ExlDWRGoqjmzF9z8D7x3/MTL1pmWImXfDcclzAA5lj9yhM
 /LkploVbEcZ5ArV7oISu7GUfrxsxLNgobzEVUt2iRylw18YZJFFcvTlez5R0n4Zg
 fMiVW+fhpun5FJkGDL3B/BU2c+RUkL0RiIwElnUOBRXIrRyI4XjCTbw9vnPKZxHk
 XQkV+OZzlogq3TdtHqJ94Nwt3UKzSSMF4aAVOvcAzusHjMnyBdk=
 =UZKA
 -----END PGP SIGNATURE-----

Merge tag 'soc-fixes-6.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

Pull SoC fixes from Arnd Bergmann:
 "Two more small fixes, correcting the cacheline size on Raspberry Pi 5
  and fixing a logic mistake in the microchip mpfs firmware driver"

* tag 'soc-fixes-6.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  arm64: dts: broadcom: Fix L2 linesize for Raspberry Pi 5
  firmware: microchip: fix UL_IAP lock check in mpfs_auto_update_state()
2024-12-21 15:45:06 -08:00
Linus Torvalds
499551201b Fix a sparse warning in the arm64 signal code dealing with the user
shadow stack register, GCSPR_EL0.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEE5RElWfyWxS+3PLO2a9axLQDIXvEFAmdlufgACgkQa9axLQDI
 XvHS9Q//WmBcPgp99ZgmHwV4x9VZz4lBiZphBp2+WYNmYFjkEcNDggs8nWs+JwgR
 Y1isI5fLEuNYCqjoejtT5iPY3i9YAtiOtq8J7xnlZ35r3Ycur28f4C28ZxQnpHGH
 xaFO7deNTGhUkLvHaxIDxAyu8iHcJL+Q4XwuuTozedHPGwCHb5uyYHZB1fvYTrB0
 x4yxJDBehsN9x/xQPNYlaaXpYG3i0as/1DQod7kKIDckxnGOOk1s1sTPPMTsOMAv
 W9xvUPUmzoRvn7nH1ErT7X3O8LzbACy6RDg1iGzdMINTuLDDM9n55i2tl0TToqqq
 9h5IQ7ZSsPPixrPGarSZMhKnRKLHd0psFwfzhaWdPSGn4MHQInhkIP4vK05ycpxc
 E3AzbQMTb8ABVwW57XeJYnJJ28wY2QvQp0mm96xjSHfhYwafx4heTAM/4jzw5ZwC
 JsIbQsy603Ir7JhSV3rNozAUPI8GdQzXBYZ5PtW0AIbyJHAWP2R+/Q5kGK2IJd7a
 T5fzCLNSd0u7soY/4J856HYsDYw0SC0f6ua9BbaIC99vOlG9PhO/MJIkr+FsPeQq
 O3zH/xg/LGWQYudAoXYJhY6YuQ18mpdMw++/cNci2wWdhApf2sQLrhkO1Kz1numd
 WDDO13hyQZQMeulTeTrkS0teQmhuVeGvgb3vxLJzYi4OIEr8Iv4=
 =sJbw
 -----END PGP SIGNATURE-----

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

Pull arm64 fix from Catalin Marinas:
 "Fix a sparse warning in the arm64 signal code dealing with the user
  shadow stack register, GCSPR_EL0"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64/signal: Silence sparse warning storing GCSPR_EL0
2024-12-20 14:10:01 -08:00
Arnd Bergmann
a31ffd6ed5 This pull request contains Broadcom ARM64-based SoCs Device Tree fixes
for 6.13, please pull the following:
 
 - Willow corrects the L2 cache line size on the Raspberry Pi 5 (2712) to
   the correct value of 64 bytes
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmdhy2AACgkQh9CWnEQH
 BwQFtBAAjcQLt3FMZlMaUD4ypPwwbSENG/gIO5YPQNaxYXpuSIKUu1xCfu8WsbdS
 gJqJ6LTGslvy3wN19wnPEblA0SdKafNsoFdbINbihQ+vkZalIqpqDYuoFTn8OoQ1
 wO6VUT//LWFV/Xco/U1ELYKyu2Xr4fSnT5d87AE97V3ChrsftR2yLZuTuhLD30Fk
 gGPFlxqm/dMEjRu19kWfme2jsESQewjFeje6wT8QwpOIoDxtaZa9OrbBvZ+6es5i
 Oe10shORMR5igSeJyqneic3aH+We1D8LkCRStEbhais5PqZyRv88c52vjftPaBA+
 FNvYCGZz8wNxbYY/G3v0EdakjzenqIvXb4OGL1c6rfXZ7SSaeieZuvAvpwtgPjma
 mJmE1BkFzatYQ/OXY63a+6ox9GMjMx2gPMtJTahPejW/Sp8EmpNFbWSHYDvw0bZD
 qQ07kr2uiTxpz/Oq7EaYN2SWdGHs06sThbrU3oI7/aAO6bfpG8cRDqEwgdbqZxKd
 RT9p6x3HpBBlq0/qV33vTBJQzw5D5Hm6DFG14QffSStiIewiOP4aegtQRQFxHoqr
 5TiWcPooDV+NGQ/aLCh8aioUQ69WnyfqEYQhBGpH9jJKrnmb9BgW1dl7J6X0xE4P
 f4sKZYJAdltHyfSdXsC91Eb8xAKtGJDQ3luXycloQXh8koiyrBw=
 =24Xv
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmdloyMACgkQYKtH/8kJ
 Uie33A/+Lnq3Vd+gWGkng9fmvv/1B4aw7jqLm95aYYmm4ydX3iOadqqZRxlr2150
 k3Utu0GygjkHlDPbMSZKFj8yPTu0o2L1aZTtDDpij3S/AGuogmypJlsLUQyDrDyq
 mFk+D8uxazu2tMjMHAL8nJ3GyOODw7rPuTp324MM5T8GC4FKeknicjHzN6KPlfsD
 L+4sWjlpGt1YQVb4uW2DEy7BAmPYpY5Pnl7Sh+YYzMa3ZIfru2PaFzdbqol/pbUZ
 Qusws8kcnoFLpT3KFpzNTYAwYKaMcNBRmoQLZZCAiH+GeT6FEK8B0mOwax0qDX8U
 Eiu3BmkCgjuYcIm1NQ8zZohQsKTtUt0FSu0auzU0t+Xq+jG5M9P6DqHMEFeBoi7T
 T9d0VsYB6BQ8240e8tGRNMAYuVLozPuL+BAdlF9ITrmw8JzthtVqZO/CRGiyODcg
 3QvHZYArOMeZElHBHNdZEcPhnVHQ+cgdmL/4TZe2UHfqavG0Mhl4tnRU7e+nBjVN
 f7IuuySYuultBp3uwW8WueccICz0N99nmVaQ5HoqtKOfOrnGOoU77rewg6QkTYhp
 AIpFTGpwzE8y6/NOP7B3urNOTOYHe8Kiui2WfHt3M0cZdi+qlJn+3EtotCLcFHOY
 NLITkaGXeLoIumaZTvB4g7aiPFxXBbFVlINVjUwBzd2RGf5Yw9M=
 =tew5
 -----END PGP SIGNATURE-----

Merge tag 'arm-soc/for-6.13/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux into arm/fixes

This pull request contains Broadcom ARM64-based SoCs Device Tree fixes
for 6.13, please pull the following:

- Willow corrects the L2 cache line size on the Raspberry Pi 5 (2712) to
  the correct value of 64 bytes

* tag 'arm-soc/for-6.13/devicetree-arm64-fixes' of https://github.com/Broadcom/stblinux:
  arm64: dts: broadcom: Fix L2 linesize for Raspberry Pi 5

Link: https://lore.kernel.org/r/20241217190547.868744-1-florian.fainelli@broadcom.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-12-20 18:02:27 +01:00
Mark Brown
926e862058 arm64/signal: Silence sparse warning storing GCSPR_EL0
We are seeing a sparse warning in gcs_restore_signal():

  arch/arm64/kernel/signal.c:1054:9: sparse: sparse: cast removes address space '__user' of expression

when storing the final GCSPR_EL0 value back into the register, caused by
the fact that write_sysreg_s() casts the value it writes to a u64 which
sparse sees as discarding the __userness of the pointer.

Avoid this by treating the address as an integer, casting to a pointer only
when using it to write to userspace.

While we're at it also inline gcs_signal_cap_valid() into it's one user
and make equivalent updates to gcs_signal_entry().

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202412082005.OBJ0BbWs-lkp@intel.com/
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20241214-arm64-gcs-signal-sparse-v3-1-5e8d18fffc0c@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-20 14:12:04 +00:00
Johan Hovold
7db0ba3e6e Revert "arm64: dts: qcom: x1e80100: enable OTG on USB-C controllers"
This reverts commit f042bc234c2e00764b8aa2c9e2f8177cdc63f664.

A recent change enabling role switching for the x1e80100 USB-C
controllers breaks UCSI and DisplayPort Alternate Mode when the
controllers are in host mode:

	ucsi_glink.pmic_glink_ucsi pmic_glink.ucsi.0: PPM init failed, stop trying

As enabling OTG mode currently breaks SuperSpeed hotplug and suspend,
and with retimer (and orientation detection) support not even merged
yet, let's revert at least until we have stable host mode in mainline.

Fixes: f042bc234c2e ("arm64: dts: qcom: x1e80100: enable OTG on USB-C controllers")
Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/all/hw2pdof4ajadjsjrb44f2q4cz4yh5qcqz5d3l7gjt2koycqs3k@xx5xvd26uyef
Link: https://lore.kernel.org/lkml/Z1gbyXk-SktGjL6-@hovoldconsulting.com/
Cc: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20241210111444.26240-4-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-12-19 12:44:30 -06:00
Johan Hovold
2e5e1a7ea6 Revert "arm64: dts: qcom: x1e80100-crd: enable otg on usb ports"
This reverts commit 2dd3250191bcfe93b0c9da46624af830310400a7.

A recent change enabling OTG mode on the x1e81000 CRD breaks suspend.
Specifically, the device hard resets during resume if suspended with all
controllers in device mode (i.e. no USB device connected).

The corresponding change on the T14s also led to SuperSpeed hotplugs not
being detected.

With retimer (and orientation detection) support not even merged yet,
let's revert at least until we have stable host mode in mainline.

Fixes: 2dd3250191bc ("arm64: dts: qcom: x1e80100-crd: enable otg on usb ports")
Reported-by: Abel Vesa <abel.vesa@linaro.org>
Cc: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20241210111444.26240-3-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-12-19 12:44:30 -06:00
Oliver Upton
e96d8b80af KVM: arm64: Only apply PMCR_EL0.P to the guest range of counters
An important distinction from other registers affected by HPMN is that
PMCR_EL0 only affects the guest range of counters, regardless of the EL
from which it is accessed. Ensure that PMCR_EL0.P is always applied to
'guest' counters by manually computing the mask rather than deriving it
from the current context.

Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20241217175611.3658290-1-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-12-18 13:22:25 -08:00
Oliver Upton
d3ba35b69e KVM: arm64: nv: Reload PMU events upon MDCR_EL2.HPME change
MDCR_EL2.HPME is the 'global' enable bit for event counters reserved for
EL2. Give the PMU a kick when it's changed to ensure events are
reprogrammed before returning to the guest.

Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20241217175550.3658212-1-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-12-18 13:22:25 -08:00
Oliver Upton
adf8623b3f KVM: arm64: Use KVM_REQ_RELOAD_PMU to handle PMCR_EL0.E change
Nested virt introduces yet another set of 'global' knobs for controlling
event counters that are reserved for EL2 (i.e. >= HPMN). Get ready to
share some plumbing with the NV controls by offloading counter
reprogramming to KVM_REQ_RELOAD_PMU.

Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20241217175532.3658134-1-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-12-18 13:22:25 -08:00
Oliver Upton
e22c369520 KVM: arm64: Add unified helper for reprogramming counters by mask
Having separate helpers for enabling/disabling counters provides the
wrong abstraction, as the state of each counter needs to be evaluated
independently and, in some cases, use a different global enable bit.

Collapse the enable/disable accessors into a single, common helper that
reconfigures every counter set in @mask, leaving the complexity of
determining if an event is actually enabled in
kvm_pmu_counter_is_enabled().

Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20241217175513.3658056-1-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-12-18 13:22:25 -08:00
Quentin Perret
985bb51f17 KVM: arm64: Always check the state from hyp_ack_unshare()
There are multiple pKVM memory transitions where the state of a page is
not cross-checked from the completer's PoV for performance reasons.
For example, if a page is PKVM_PAGE_OWNED from the initiator's PoV,
we should be guaranteed by construction that it is PKVM_NOPAGE for
everybody else, hence allowing us to save a page-table lookup.

When it was introduced, hyp_ack_unshare() followed that logic and bailed
out without checking the PKVM_PAGE_SHARED_BORROWED state in the
hypervisor's stage-1. This was correct as we could safely assume that
all host-initiated shares were directed at the hypervisor at the time.
But with the introduction of other types of shares (e.g. for FF-A or
non-protected guests), it is now very much required to cross check this
state to prevent the host from running __pkvm_host_unshare_hyp() on a
page shared with TZ or a non-protected guest.

Thankfully, if an attacker were to try this, the hyp_unmap() call from
hyp_complete_unshare() would fail, hence causing to WARN() from
__do_unshare() with the host lock held, which is fatal. But this is
fragile at best, and can hardly be considered a security measure.

Let's just do the right thing and always check the state from
hyp_ack_unshare().

Signed-off-by: Quentin Perret <qperret@google.com>
Acked-by: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20241128154406.602875-1-qperret@google.com
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-12-18 13:21:37 -08:00
Willow Cunningham
058387d9c6 arm64: dts: broadcom: Fix L2 linesize for Raspberry Pi 5
Set the cache-line-size parameter of the L2 cache for each core to the
correct value of 64 bytes.

Previously, the L2 cache line size was incorrectly set to 128 bytes
for the Broadcom BCM2712. This causes validation tests for the
Performance Application Programming Interface (PAPI) tool to fail as
they depend on sysfs accurately reporting cache line sizes.

The correct value of 64 bytes is stated in the official documentation of
the ARM Cortex A-72, which is linked in the comments of
arm64/boot/dts/broadcom/bcm2712.dtsi as the source for cache-line-size.

Fixes: faa3381267d0 ("arm64: dts: broadcom: Add minimal support for Raspberry Pi 5")
Signed-off-by: Willow Cunningham <willow.e.cunningham@maine.edu>
Link: https://lore.kernel.org/r/20241007212954.214724-1-willow.e.cunningham@maine.edu
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
2024-12-17 11:03:22 -08:00
Qiang Yu
fb8e7b33c2 arm64: dts: qcom: x1e80100: Fix up BAR space size for PCIe6a
As per memory map table, the region for PCIe6a is 64MByte. Hence, set the
size of 32 bit non-prefetchable memory region beginning on address
0x70300000 as 0x3d00000 so that BAR space assigned to BAR registers can be
allocated from 0x70300000 to 0x74000000.

Fixes: 7af141850012 ("arm64: dts: qcom: x1e80100: Fix up BAR spaces")
Cc: stable@vger.kernel.org
Signed-off-by: Qiang Yu <quic_qianyu@quicinc.com>
Reviewed-by: Johan Hovold <johan+linaro@kernel.org>
Link: https://lore.kernel.org/r/20241113080508.3458849-1-quic_qianyu@quicinc.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-12-16 14:32:00 -06:00
Johan Hovold
1fb5cf0d16 Revert "arm64: dts: qcom: x1e78100-t14s: enable otg on usb-c ports"
This reverts commit 1a48dd7b9ac809d1bd0fd2fef509abba83433846.

A recent change enabling OTG mode on the Lenovo ThinkPad T14s USB-C
ports can break SuperSpeed device hotplugging. The host controller is
enumerated, but the device is not:

	xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
	xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 3
	xhci-hcd xhci-hcd.5.auto: hcc params 0x0110ffc5 hci version 0x110 quirks 0x000080a000000810
	xhci-hcd xhci-hcd.5.auto: irq 247, io mem 0x0a800000
	xhci-hcd xhci-hcd.5.auto: xHCI Host Controller
	xhci-hcd xhci-hcd.5.auto: new USB bus registered, assigned bus number 4
	xhci-hcd xhci-hcd.5.auto: Host supports USB 3.1 Enhanced SuperSpeed
	hub 3-0:1.0: USB hub found
	hub 3-0:1.0: 1 port detected
	hub 4-0:1.0: USB hub found
	hub 4-0:1.0: 1 port detected

Once this happens on either of the two ports, no amount of disconnecting
and reconnecting makes the SuperSpeed device be enumerated, while
FullSpeed device enumeration still works.

With retimer (and orientation detection) support not even merged yet,
let's revert at least until we have stable host mode in mainline.

Fixes: 1a48dd7b9ac8 ("arm64: dts: qcom: x1e78100-t14s: enable otg on usb-c ports")
Cc: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: Abel Vesa <abel.vesa@linaro.org>
Link: https://lore.kernel.org/r/20241206172402.20724-1-johan+linaro@kernel.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-12-16 14:31:32 -06:00
Linus Torvalds
f44d154d6e soc: fixes for 6.13
There are three small fixes for the soc tree:
 
  - A devicetee fix for the Arm Juno reference machine, so allow more
    interesting PCI configurations
 
  - A build fix for SCMI firmware on the NXP i.MX platform
 
  - A fix for a race condition in Arm FF-A firmware
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmdgNf4ACgkQYKtH/8kJ
 Uid99g/9Eve2yPqK+nAqlfFs20NE/cDvdaQ9n2Z+rU5igpvrqR62rBVG2v7AuFHZ
 w8Awl2iB57y1XdCxG8FE0wQ+TloiN+aLwgmbUh2st2fTjmPh6KgGq6jsGbvDli07
 WrlH4PxxMm8axO2HwEWiSLsQBpeoqYvgO+6GDW5eXLtsbr6VuFNBoD6ExC/YVqsQ
 kCdHG+WrjA+rZyXjYZqlAknLaldLEplVPmh9riZEcdYh02QE5VXU53+ctUtYZENU
 VGM/638YAlnCANKYH9u5e8YmL2RgiLLNS63xSdO0krv/gCEor3txKvcG6Cie+76d
 n0bOu13kWdcJbrt0+wVR6ILCffAurhxZZ6L3Q+iSqJ0as/eBXeZtBKYyEl5w6vZf
 X32TkPmx3cvCTZG8Vs+0e4JlC/5wiPrPCTdQSStTckp7FDEs9sttEpeZWenYJNQY
 7hVFj2Nx8SFv0JCB9N68CJB1KkhhRkAqNq6aKymTNJZLxAd72xJm3sOlDmOPRJ43
 9j6LwQ6panUk49WNRklwuL0YajcX1jTS/MRHQfKtVCOfBD05A0BaQEDeAUeYfq2V
 rCFphvZn315fv6h1XLP0LkBTOJ0f+3X+0GcwtMUX8TC/AJXPnKHAuZKmujmVH8Uh
 mtfvVlUuvnw73LM/QlyAaG/D9Tj2wHtN2HNtTaGl6CY6zdeznRw=
 =+t0h
 -----END PGP SIGNATURE-----

Merge tag 'soc-fixes-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc

Pull SoC fixes from Arnd Bergmann:
 "Three small fixes for the soc tree:

   - devicetee fix for the Arm Juno reference machine, to allow more
     interesting PCI configurations

   - build fix for SCMI firmware on the NXP i.MX platform

   - fix for a race condition in Arm FF-A firmware"

* tag 'soc-fixes-6.13' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
  arm64: dts: fvp: Update PCIe bus-range property
  firmware: arm_ffa: Fix the race around setting ffa_dev->properties
  firmware: arm_scmi: Fix i.MX build dependency
2024-12-16 10:10:53 -08:00
Linus Torvalds
81576a9a27 ARM64:
* Fix confusion with implicitly-shifted MDCR_EL2 masks breaking
   SPE/TRBE initialization.
 
 * Align nested page table walker with the intended memory attribute
   combining rules of the architecture.
 
 * Prevent userspace from constraining the advertised ASID width,
   avoiding horrors of guest TLBIs not matching the intended context in
   hardware.
 
 * Don't leak references on LPIs when insertion into the translation
   cache fails.
 
 RISC-V:
 
 * Replace csr_write() with csr_set() for HVIEN PMU overflow bit.
 
 x86:
 
 * Cache CPUID.0xD XSTATE offsets+sizes during module init - On Intel's
   Emerald Rapids CPUID costs hundreds of cycles and there are a lot of
   leaves under 0xD.  Getting rid of the CPUIDs during nested VM-Enter and
   VM-Exit is planned for the next release, for now just cache them: even
   on Skylake that is 40% faster.
 -----BEGIN PGP SIGNATURE-----
 
 iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmdcibgUHHBib256aW5p
 QHJlZGhhdC5jb20ACgkQv/vSX3jHroOQsgf+NwNdfNQ0V5vU7YNeVxyhkCyYvNiA
 njvBTd1Lwh7EDtJ2NLKzwHktH2ymQI8qykxKr/qY3Jxkow+vcvsK0LacAaJdIzGo
 jnMGxXxRCFpxdkNb1kDJk4Cd6GSSAxYwgPj3wj7whsMcVRjPlFcjuHf02bRUU0Gt
 yulzBOZJ/7QTquKSnwt1kZQ1i/mJ8wCh4vJArZqtcImrDSK7oh+BaQ44h+lNe8qa
 Xiw6Fw3tYXgHy5WlnUU/OyFs+bZbcVzPM75qYgdGIWSo0TdL69BeIw8S4K2Ri4eL
 EoEBigwAd8PiF16Q1wO4gXWcNwinMTs3LIftxYpENTHA5gnrS5hgWWDqHw==
 =4v2y
 -----END PGP SIGNATURE-----

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm

Pull kvm fixes from Paolo Bonzini:
 "ARM64:

   - Fix confusion with implicitly-shifted MDCR_EL2 masks breaking
     SPE/TRBE initialization

   - Align nested page table walker with the intended memory attribute
     combining rules of the architecture

   - Prevent userspace from constraining the advertised ASID width,
     avoiding horrors of guest TLBIs not matching the intended context
     in hardware

   - Don't leak references on LPIs when insertion into the translation
     cache fails

  RISC-V:

   - Replace csr_write() with csr_set() for HVIEN PMU overflow bit

  x86:

   - Cache CPUID.0xD XSTATE offsets+sizes during module init

     On Intel's Emerald Rapids CPUID costs hundreds of cycles and there
     are a lot of leaves under 0xD. Getting rid of the CPUIDs during
     nested VM-Enter and VM-Exit is planned for the next release, for
     now just cache them: even on Skylake that is 40% faster"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86: Cache CPUID.0xD XSTATE offsets+sizes during module init
  RISC-V: KVM: Fix csr_write -> csr_set for HVIEN PMU overflow bit
  KVM: arm64: vgic-its: Add error handling in vgic_its_cache_translation
  KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden
  KVM: arm64: Fix S1/S2 combination when FWB==1 and S2 has Device memory type
  arm64: Fix usage of new shifted MDCR_EL2 values
2024-12-15 09:26:13 -08:00
Kevin Brodsky
a3b4647e2f arm64: signal: Ensure signal delivery failure is recoverable
Commit eaf62ce1563b ("arm64/signal: Set up and restore the GCS
context for signal handlers") introduced a potential failure point
at the end of setup_return(). This is unfortunate as it is too late
to deliver a SIGSEGV: if that SIGSEGV is handled, the subsequent
sigreturn will end up returning to the original handler, which is
not the intention (since we failed to deliver that signal).

Make sure this does not happen by calling gcs_signal_entry()
at the very beginning of setup_return(), and add a comment just
after to discourage error cases being introduced from that point
onwards.

While at it, also take care of copy_siginfo_to_user(): since it may
fail, we shouldn't be calling it after setup_return() either. Call
it before setup_return() instead, and move the setting of X1/X2
inside setup_return() where it belongs (after the "point of no
failure").

Background: the first part of setup_rt_frame(), including
setup_sigframe(), has no impact on the execution of the interrupted
thread. The signal frame is written to the stack, but the stack
pointer remains unchanged. Failure at this stage can be recovered by
a SIGSEGV handler, and sigreturn will restore the original context,
at the point where the original signal occurred. On the other hand,
once setup_return() has updated registers including SP, the thread's
control flow has been modified and we must deliver the original
signal.

Fixes: eaf62ce1563b ("arm64/signal: Set up and restore the GCS context for signal handlers")
Signed-off-by: Kevin Brodsky <kevin.brodsky@arm.com>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20241210160940.2031997-1-kevin.brodsky@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-13 14:13:27 +00:00
Mark Rutland
65ac33bed8 arm64: stacktrace: Don't WARN when unwinding other tasks
The arm64 stacktrace code has a few error conditions where a
WARN_ON_ONCE() is triggered before the stacktrace is terminated and an
error is returned to the caller. The conditions shouldn't be triggered
when unwinding the current task, but it is possible to trigger these
when unwinding another task which is not blocked, as the stack of that
task is concurrently modified. Kent reports that these warnings can be
triggered while running filesystem tests on bcachefs, which calls the
stacktrace code directly.

To produce a meaningful stacktrace of another task, the task in question
should be blocked, but the stacktrace code is expected to be robust to
cases where it is not blocked. Note that this is purely about not
unuduly scaring the user and/or crashing the kernel; stacktraces in such
cases are meaningless and may leak kernel secrets from the stack of the
task being unwound.

Ideally we'd pin the task in a blocked state during the unwind, as we do
for /proc/${PID}/wchan since commit:

  42a20f86dc19f928 ("sched: Add wrapper for get_wchan() to keep task blocked")

... but a bunch of places don't do that, notably /proc/${PID}/stack,
where we don't pin the task in a blocked state, but do restrict the
output to privileged users since commit:

  f8a00cef17206ecd ("proc: restrict kernel stack dumps to root")

... and so it's possible to trigger these warnings accidentally, e.g. by
reading /proc/*/stack (as root):

| for n in $(seq 1 10); do
|     while true; do cat /proc/*/stack > /dev/null 2>&1; done &
| done
| ------------[ cut here ]------------
| WARNING: CPU: 3 PID: 166 at arch/arm64/kernel/stacktrace.c:207 arch_stack_walk+0x1c8/0x370
| Modules linked in:
| CPU: 3 UID: 0 PID: 166 Comm: cat Not tainted 6.13.0-rc2-00003-g3dafa7a7925d #2
| Hardware name: linux,dummy-virt (DT)
| pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
| pc : arch_stack_walk+0x1c8/0x370
| lr : arch_stack_walk+0x1b0/0x370
| sp : ffff800080773890
| x29: ffff800080773930 x28: fff0000005c44500 x27: fff00000058fa038
| x26: 000000007ffff000 x25: 0000000000000000 x24: 0000000000000000
| x23: ffffa35a8d9600ec x22: 0000000000000000 x21: fff00000043a33c0
| x20: ffff800080773970 x19: ffffa35a8d960168 x18: 0000000000000000
| x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
| x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000
| x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000
| x8 : ffff8000807738e0 x7 : ffff8000806e3800 x6 : ffff8000806e3818
| x5 : ffff800080773920 x4 : ffff8000806e4000 x3 : ffff8000807738e0
| x2 : 0000000000000018 x1 : ffff8000806e3800 x0 : 0000000000000000
| Call trace:
|  arch_stack_walk+0x1c8/0x370 (P)
|  stack_trace_save_tsk+0x8c/0x108
|  proc_pid_stack+0xb0/0x134
|  proc_single_show+0x60/0x120
|  seq_read_iter+0x104/0x438
|  seq_read+0xf8/0x140
|  vfs_read+0xc4/0x31c
|  ksys_read+0x70/0x108
|  __arm64_sys_read+0x1c/0x28
|  invoke_syscall+0x48/0x104
|  el0_svc_common.constprop.0+0x40/0xe0
|  do_el0_svc+0x1c/0x28
|  el0_svc+0x30/0xcc
|  el0t_64_sync_handler+0x10c/0x138
|  el0t_64_sync+0x198/0x19c
| ---[ end trace 0000000000000000 ]---

Fix this by only warning when unwinding the current task. When unwinding
another task the error conditions will be handled by returning an error
without producing a warning.

The two warnings in kunwind_next_frame_record_meta() were added recently
as part of commit:

  c2c6b27b5aa14fa2 ("arm64: stacktrace: unwind exception boundaries")

The warning when recovering the fgraph return address has changed form
many times, but was originally introduced back in commit:

  9f416319f40cd857 ("arm64: fix unwind_frame() for filtered out fn for function graph tracing")

Fixes: c2c6b27b5aa1 ("arm64: stacktrace: unwind exception boundaries")
Fixes: 9f416319f40c ("arm64: fix unwind_frame() for filtered out fn for function graph tracing")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Kees Cook <keescook@chromium.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20241211140704.2498712-3-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-12 16:23:15 +00:00
Mark Rutland
32ed120568 arm64: stacktrace: Skip reporting LR at exception boundaries
Aishwarya reports that warnings are sometimes seen when running the
ftrace kselftests, e.g.

| WARNING: CPU: 5 PID: 2066 at arch/arm64/kernel/stacktrace.c:141 arch_stack_walk+0x4a0/0x4c0
| Modules linked in:
| CPU: 5 UID: 0 PID: 2066 Comm: ftracetest Not tainted 6.13.0-rc2 #2
| Hardware name: linux,dummy-virt (DT)
| pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : arch_stack_walk+0x4a0/0x4c0
| lr : arch_stack_walk+0x248/0x4c0
| sp : ffff800083643d20
| x29: ffff800083643dd0 x28: ffff00007b891400 x27: ffff00007b891928
| x26: 0000000000000001 x25: 00000000000000c0 x24: ffff800082f39d80
| x23: ffff80008003ee8c x22: ffff80008004baa8 x21: ffff8000800533e0
| x20: ffff800083643e10 x19: ffff80008003eec8 x18: 0000000000000000
| x17: 0000000000000000 x16: ffff800083640000 x15: 0000000000000000
| x14: 02a37a802bbb8a92 x13: 00000000000001a9 x12: 0000000000000001
| x11: ffff800082ffad60 x10: ffff800083643d20 x9 : ffff80008003eed0
| x8 : ffff80008004baa8 x7 : ffff800086f2be80 x6 : ffff0000057cf000
| x5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800086f2b690
| x2 : ffff80008004baa8 x1 : ffff80008004baa8 x0 : ffff80008004baa8
| Call trace:
|  arch_stack_walk+0x4a0/0x4c0 (P)
|  arch_stack_walk+0x248/0x4c0 (L)
|  profile_pc+0x44/0x80
|  profile_tick+0x50/0x80 (F)
|  tick_nohz_handler+0xcc/0x160 (F)
|  __hrtimer_run_queues+0x2ac/0x340 (F)
|  hrtimer_interrupt+0xf4/0x268 (F)
|  arch_timer_handler_virt+0x34/0x60 (F)
|  handle_percpu_devid_irq+0x88/0x220 (F)
|  generic_handle_domain_irq+0x34/0x60 (F)
|  gic_handle_irq+0x54/0x140 (F)
|  call_on_irq_stack+0x24/0x58 (F)
|  do_interrupt_handler+0x88/0x98
|  el1_interrupt+0x34/0x68 (F)
|  el1h_64_irq_handler+0x18/0x28
|  el1h_64_irq+0x6c/0x70
|  queued_spin_lock_slowpath+0x78/0x460 (P)

The warning in question is:

  WARN_ON_ONCE(state->common.pc == orig_pc))

... in kunwind_recover_return_address(), which is triggered when
return_to_handler() is encountered in the trace, but
ftrace_graph_ret_addr() cannot find a corresponding original return
address on the fgraph return stack.

This happens because the stacktrace code encounters an exception
boundary where the LR was not live at the time of the exception, but the
LR happens to contain return_to_handler(); either because the task
recently returned there, or due to unfortunate usage of the LR at a
scratch register. In such cases attempts to recover the return address
via ftrace_graph_ret_addr() may fail, triggering the WARN_ON_ONCE()
above and aborting the unwind (hence the stacktrace terminating after
reporting the PC at the time of the exception).

Handling unreliable LR values in these cases is likely to require some
larger rework, so for the moment avoid this problem by restoring the old
behaviour of skipping the LR at exception boundaries, which the
stacktrace code did prior to commit:

  c2c6b27b5aa14fa2 ("arm64: stacktrace: unwind exception boundaries")

This commit is effectively a partial revert, keeping the structures and
logic to explicitly identify exception boundaries while still skipping
reporting of the LR. The logic to explicitly identify exception
boundaries is still useful for general robustness and as a building
block for future support for RELIABLE_STACKTRACE.

Fixes: c2c6b27b5aa1 ("arm64: stacktrace: unwind exception boundaries")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Aishwarya TCV <aishwarya.tcv@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20241211140704.2498712-2-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-12 16:23:05 +00:00
Paolo Bonzini
3154bddf8c KVM/arm64 fixes for 6.13, part #2
- Fix confusion with implicitly-shifted MDCR_EL2 masks breaking
    SPE/TRBE initialization
 
  - Align nested page table walker with the intended memory attribute
    combining rules of the architecture
 
  - Prevent userspace from constraining the advertised ASID width,
    avoiding horrors of guest TLBIs not matching the intended context in
    hardware
 
  - Don't leak references on LPIs when insertion into the translation
    cache fails
 -----BEGIN PGP SIGNATURE-----
 
 iI0EABYIADUWIQSNXHjWXuzMZutrKNKivnWIJHzdFgUCZ0+mZhccb2xpdmVyLnVw
 dG9uQGxpbnV4LmRldgAKCRCivnWIJHzdFuKcAQDnFcLru8MVor4zjloe25oPPeuW
 iBocGpgKwJMioHrAdwEAoq8v0eqfxrUpwr5KJ7iN9CTo9oANJYhVACC8jPHEowI=
 =fLPh
 -----END PGP SIGNATURE-----

Merge tag 'kvmarm-fixes-6.13-2' of https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD

KVM/arm64 fixes for 6.13, part #2

 - Fix confusion with implicitly-shifted MDCR_EL2 masks breaking
   SPE/TRBE initialization

 - Align nested page table walker with the intended memory attribute
   combining rules of the architecture

 - Prevent userspace from constraining the advertised ASID width,
   avoiding horrors of guest TLBIs not matching the intended context in
   hardware

 - Don't leak references on LPIs when insertion into the translation
   cache fails
2024-12-10 08:50:55 -05:00
Arnd Bergmann
90386e1ba4 Armv8 Juno fix for v6.13
Just a single fix updating the PCIe bus address range to accommodate
 the full ECAM window of 256MB available on most of the recent versions
 of RevC FVP models.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmdRh6oACgkQAEG6vDF+
 4piVWQ/6Akpv99sbqwa401L43kwdCnmubRXxO+IPFVPVAsVUPTO9OCPfohSixlAy
 JXgIW1lusN//J1y4UFIfMjcqCdUA0itFJHsWIYCLzwoaHo/B/IRZps0eTNiY1WF9
 XZMEgkb9/6ccd8TAa66L88AIjr/VZQpDSqoVJ2Pe8txckjJDlftwRro/KJmuU6go
 /2rqfeNIgN2rRiqlPpMcsz3BktCcQ2hYOu1tGpX6zPr4fBg1epX/Zi5WiUZjm0RR
 VWqP+R5anf9iXpC37Wek51/ixEXm2I9NFYSTg1LNU/tI1xqGwReE8dLxmHHOJoWW
 bcGApJhwV8CQEgm0JzeKz62Qi/l4LbDGfU2irajtuwG6F2rF/2LD6U+EMsHLrqDN
 SnNedBSE7bclTEZv02X5SZfKf20LQbaTtMo74Y/uEoERd9/nVKR4bj28ZPc4olm8
 klNQqpITlyJZ2xcLx1qs7kx9MK2ztYPmyzXHco7jByRDhfr0mWojXUfeEgWjnLQT
 0xpicb31f+ewhLeKE9zC0RT2z15Sz7z49aXsbU43LxkneLNLBbJbyi3fOlTiSVqd
 BzjoQOKwzrBg0dz4H3yqEV17/9kSrtFOWnEtf3eS7j/wFI/VbvgIgtKHHEbBLWhR
 w8QShUzOWReI78lazjYEV6ZXPD2q0PZWhgHDWyNjW6uvrLoM/9o=
 =j1a9
 -----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmdXBxEACgkQYKtH/8kJ
 Uicc7A/8C0ACMtnzT/bx28j5XHofkhoq8VaCmdbX3H04r/EMKXypChO2I3R56FPx
 ydX8HefAdkiQOgGVdcHrZ+x8/vyCCXxSRqyjgb+Yt+GGzse6TN952Oz8NptCkW74
 5v917V7Am9E0va1U9E1rpIhU+eCT6JzoD5xXK1d+0g52koZE4JtAv9DdS3Jjm/VV
 3GpcdLsSdG1csrkhKVnApSsY/Q6Tv3+G9olJ7qWY1NnWU916JZD/fJRL2wTL60id
 uHr6ja0dqAo6A0+ztbEkhnv3ccOaPwDG9a/gORhDQf/TvLE7Ef/qAzHmUF8cJCv5
 x2SHKL7lRyIb3Nn7RNq1PptPZw8FyCLprvuhrlDHa5LWO1Thj1iAlKrvJMTqYihy
 dzOKcRNZVmL9tX0xHW4RMDyl+P1rqsUhJOT5+/OWZRWPYV0AcwF0aquGqvrdaRR+
 30uX+KQ+otLzbKkyUtKOKGlhUWwg8zIXFCjO1TqhBUgxrzZLnY5aFmqNGB1IkA5A
 QmQH+oFWxktiEBjZ6KnCDUwEsDbfuT9l0+qhuVLXFDwBV2XShIZQYewrrymBYeA8
 I+I5hd4J+9zsVKLU3+Nj/+GavD0M4bGdF46NRWixheGga4La2MkCNNMC6dLqm8f1
 UQIlLu7LQ67xUDvqIdbyI8iUnyIsJhMpgTD/AglmUsRqBVIJKgY=
 =enl+
 -----END PGP SIGNATURE-----

Merge tag 'juno-fix-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/fixes

Armv8 Juno fix for v6.13

Just a single fix updating the PCIe bus address range to accommodate
the full ECAM window of 256MB available on most of the recent versions
of RevC FVP models.

* tag 'juno-fix-6.13' of https://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  arm64: dts: fvp: Update PCIe bus-range property

Link: https://lore.kernel.org/r/20241205114302.708433-1-sudeep.holla@arm.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2024-12-09 16:04:48 +01:00
Wei Fang
c5b8d2c370 arm64: dts: imx95: correct the address length of netcmix_blk_ctrl
The netc_blk_ctrl is controlled by the imx95-blk-ctl clock driver and
provides relevant clock configurations for NETC, SAI and MQS. Its address
length should be 8 bytes instead of 0x1000.

Fixes: 7764fef26ea9 ("arm64: dts: imx95: Add NETCMIX block control support")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-12-09 16:27:05 +08:00
Frank Li
c70812cb28 arm64: dts: imx8-ss-audio: add fallback compatible string fsl,imx6ull-esai for esai
The ESAI of i.MX8QM is the same as i.MX6ULL. So add fsl,imx6ull-esai for
esai.

Signed-off-by: Frank Li <Frank.Li@nxp.com>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Fixes: adf7ea48ce05 ("ASoC: dt-bindings: fsl-esai: allow fsl,imx8qm-esai fallback to fsl,imx6ull-esai")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2024-12-09 15:53:53 +08:00
Linus Torvalds
f3ddc438a2 arm64 fixes for 6.13-rc2:
- MTE/hugetlbfs:
 
   - Set VM_MTE_ALLOWED in the arch code and remove it from the core code
     for hugetlbfs mappings
 
   - Fix copy_highpage() warning when the source is a huge page but not
     MTE tagged, taking the wrong small page path
 
 - drivers/virt/coco:
 
   - Add the pKVM and Arm CCA drivers under the arm64 maintainership
 
   - Fix the pkvm driver to fall back to ioremap() (and warn) if the
     MMIO_GUARD hypercall fails
 
   - Keep the Arm CCA driver default 'n' rather than 'm'
 
 - A series of fixes for the arm64 ptrace() implementation, potentially
   leading to the kernel consuming uninitialised stack variables when
   PTRACE_SETREGSET is invoked with a length of 0
 
 - Fix zone_dma_limit calculation when RAM starts below 4GB and ZONE_DMA
   is capped to this limit
 
 - Fix early boot warning with CONFIG_DEBUG_VIRTUAL=y triggered by a call
   to page_to_phys() (from patch_map()) which checks pfn_valid() before
   vmemmap has been set up
 
 - Do not clobber bits 15:8 of the ASID used for TTBR1_EL1 and TLBI ops
   when the kernel assumes 8-bit ASIDs but running under a hypervisor on
   a system that implements 16-bit ASIDs (found running Linux under
   Parallels on Apple M4)
 
 - ACPI/IORT: Add PMCG platform information for HiSilicon HIP09A as it is
   using the same SMMU PMCG as HIP09 and suffers from the same errata
 
 - Add GCS to cpucap_is_possible(), missed in the recent merge
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEE5RElWfyWxS+3PLO2a9axLQDIXvEFAmdTQW4ACgkQa9axLQDI
 XvGLUQ/+MEiCFytDsSIQsGMaCpRCcrNX3dzhgekjTSiS+iPRTGjhHPMxAgnKgtim
 U6MIdxItS5bvFKWQC/VmA3V+EtMy+9uwfQOy7MbG+wIzwlg48Pn2MjgmheSxhftO
 0x+lUB+5ELU9KxL0KV+WNCE5l/iBpzcSG+Uj3iqc5rPuYHxa8npekd/KVba42zGY
 QqZ75yCW5EQwyuSZve8SSMqyHNgZHNgwzhs0aRr3ZwccqE9eMKpcEv5wxbl6raGB
 Qr4HG+c3w4rQFBsj+9Zs/f5G45uZ+pM55aAVLSihhCdq51/oXXPajOWMP3tV6ke+
 hHXm4buxgIR2CWeCXp8n/H7S3OQIj4uFqmaFIGxv0+0OTemUBIEg8kAtqVcnxSXY
 hk00J5yMurDik1hhud21ZHaJaELwWAwpisVCjYBblUGOoH9uH062gb02CGWv3lSe
 hrzYohhi7IAPzDzK339Q3HVr5PZOGagoBS2B1ptX2f6rrPITIuB2rW+lzNDuuBSX
 twHcdZzmSgl2zmFu4D3ql5Oa2ewLMiOn0Z96Esz5y9f74jbLh9ynU7QyRZM0MioS
 V6te7HanJ17zMK6S2thj7qsewqV6N4lcWd7M5ZclK29F8qcW5OWuKn5njFQT7K4s
 QDI0+1uYaSMcWoDAXNVXZf3oKMJDy1LeG+UXGyP5b0AQJrqYrWQ=
 =zZ4I
 -----END PGP SIGNATURE-----

Merge tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

Pull arm64 fixes from Catalin Marinas:
 "Nothing major, some left-overs from the recent merging window (MTE,
  coco) and some newly found issues like the ptrace() ones.

   - MTE/hugetlbfs:

      - Set VM_MTE_ALLOWED in the arch code and remove it from the core
        code for hugetlbfs mappings

      - Fix copy_highpage() warning when the source is a huge page but
        not MTE tagged, taking the wrong small page path

   - drivers/virt/coco:

      - Add the pKVM and Arm CCA drivers under the arm64 maintainership

      - Fix the pkvm driver to fall back to ioremap() (and warn) if the
        MMIO_GUARD hypercall fails

      - Keep the Arm CCA driver default 'n' rather than 'm'

   - A series of fixes for the arm64 ptrace() implementation,
     potentially leading to the kernel consuming uninitialised stack
     variables when PTRACE_SETREGSET is invoked with a length of 0

   - Fix zone_dma_limit calculation when RAM starts below 4GB and
     ZONE_DMA is capped to this limit

   - Fix early boot warning with CONFIG_DEBUG_VIRTUAL=y triggered by a
     call to page_to_phys() (from patch_map()) which checks pfn_valid()
     before vmemmap has been set up

   - Do not clobber bits 15:8 of the ASID used for TTBR1_EL1 and TLBI
     ops when the kernel assumes 8-bit ASIDs but running under a
     hypervisor on a system that implements 16-bit ASIDs (found running
     Linux under Parallels on Apple M4)

   - ACPI/IORT: Add PMCG platform information for HiSilicon HIP09A as it
     is using the same SMMU PMCG as HIP09 and suffers from the same
     errata

   - Add GCS to cpucap_is_possible(), missed in the recent merge"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: ptrace: fix partial SETREGSET for NT_ARM_GCS
  arm64: ptrace: fix partial SETREGSET for NT_ARM_POE
  arm64: ptrace: fix partial SETREGSET for NT_ARM_FPMR
  arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL
  arm64: cpufeature: Add GCS to cpucap_is_possible()
  coco: virt: arm64: Do not enable cca guest driver by default
  arm64: mte: Fix copy_highpage() warning on hugetlb folios
  arm64: Ensure bits ASID[15:8] are masked out when the kernel uses 8-bit ASIDs
  ACPI/IORT: Add PMCG platform information for HiSilicon HIP09A
  MAINTAINERS: Add CCA and pKVM CoCO guest support to the ARM64 entry
  drivers/virt: pkvm: Don't fail ioremap() call if MMIO_GUARD fails
  arm64: patching: avoid early page_to_phys()
  arm64: mm: Fix zone_dma_limit calculation
  arm64: mte: set VM_MTE_ALLOWED for hugetlbfs at correct place
2024-12-06 13:47:55 -08:00
Mark Rutland
d60624f72d arm64: ptrace: fix partial SETREGSET for NT_ARM_GCS
Currently gcs_set() doesn't initialize the temporary 'user_gcs'
variable, and a SETREGSET call with a length of 0, 8, or 16 will leave
some portion of this uninitialized. Consequently some arbitrary
uninitialized values may be written back to the relevant fields in task
struct, potentially leaking up to 192 bits of memory from the kernel
stack. The read is limited to a specific slot on the stack, and the
issue does not provide a write mechanism.

As gcs_set() rejects cases where user_gcs::features_enabled has bits set
other than PR_SHADOW_STACK_SUPPORTED_STATUS_MASK, a SETREGSET call with
a length of zero will randomly succeed or fail depending on the value of
the uninitialized value, it isn't possible to leak the full 192 bits.
With a length of 8 or 16, user_gcs::features_enabled can be initialized
to an accepted value, making it practical to leak 128 or 64 bits.

Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length or partial write, the
existing contents of the fields which are not written to will be
retained.

To ensure that the extraction and insertion of fields is consistent
across the GETREGSET and SETREGSET calls, new task_gcs_to_user() and
task_gcs_from_user() helpers are added, matching the style of
pac_address_keys_to_user() and pac_address_keys_from_user().

Before this patch:

| # ./gcs-test
| Attempting to write NT_ARM_GCS::user_gcs = {
|     .features_enabled = 0x0000000000000000,
|     .features_locked  = 0x0000000000000000,
|     .gcspr_el0        = 0x900d900d900d900d,
| }
| SETREGSET(nt=0x410, len=24) wrote 24 bytes
|
| Attempting to read NT_ARM_GCS::user_gcs
| GETREGSET(nt=0x410, len=24) read 24 bytes
| Read NT_ARM_GCS::user_gcs = {
|     .features_enabled = 0x0000000000000000,
|     .features_locked  = 0x0000000000000000,
|     .gcspr_el0        = 0x900d900d900d900d,
| }
|
| Attempting partial write NT_ARM_GCS::user_gcs = {
|     .features_enabled = 0x0000000000000000,
|     .features_locked  = 0x1de7ec7edbadc0de,
|     .gcspr_el0        = 0x1de7ec7edbadc0de,
| }
| SETREGSET(nt=0x410, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_GCS::user_gcs
| GETREGSET(nt=0x410, len=24) read 24 bytes
| Read NT_ARM_GCS::user_gcs = {
|     .features_enabled = 0x0000000000000000,
|     .features_locked  = 0x000000000093e780,
|     .gcspr_el0        = 0xffff800083a63d50,
| }

After this patch:

| # ./gcs-test
| Attempting to write NT_ARM_GCS::user_gcs = {
|     .features_enabled = 0x0000000000000000,
|     .features_locked  = 0x0000000000000000,
|     .gcspr_el0        = 0x900d900d900d900d,
| }
| SETREGSET(nt=0x410, len=24) wrote 24 bytes
|
| Attempting to read NT_ARM_GCS::user_gcs
| GETREGSET(nt=0x410, len=24) read 24 bytes
| Read NT_ARM_GCS::user_gcs = {
|     .features_enabled = 0x0000000000000000,
|     .features_locked  = 0x0000000000000000,
|     .gcspr_el0        = 0x900d900d900d900d,
| }
|
| Attempting partial write NT_ARM_GCS::user_gcs = {
|     .features_enabled = 0x0000000000000000,
|     .features_locked  = 0x1de7ec7edbadc0de,
|     .gcspr_el0        = 0x1de7ec7edbadc0de,
| }
| SETREGSET(nt=0x410, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_GCS::user_gcs
| GETREGSET(nt=0x410, len=24) read 24 bytes
| Read NT_ARM_GCS::user_gcs = {
|     .features_enabled = 0x0000000000000000,
|     .features_locked  = 0x0000000000000000,
|     .gcspr_el0        = 0x900d900d900d900d,
| }

Fixes: 7ec3b57cb29f ("arm64/ptrace: Expose GCS via ptrace and core files")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20241205121655.1824269-5-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-05 18:05:51 +00:00
Mark Rutland
594bfc4947 arm64: ptrace: fix partial SETREGSET for NT_ARM_POE
Currently poe_set() doesn't initialize the temporary 'ctrl' variable,
and a SETREGSET call with a length of zero will leave this
uninitialized. Consequently an arbitrary value will be written back to
target->thread.por_el0, potentially leaking up to 64 bits of memory from
the kernel stack. The read is limited to a specific slot on the stack,
and the issue does not provide a write mechanism.

Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
contents of POR_EL1 will be retained.

Before this patch:

| # ./poe-test
| Attempting to write NT_ARM_POE::por_el0 = 0x900d900d900d900d
| SETREGSET(nt=0x40f, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d
|
| Attempting to write NT_ARM_POE (zero length)
| SETREGSET(nt=0x40f, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0xffff8000839c3d50

After this patch:

| # ./poe-test
| Attempting to write NT_ARM_POE::por_el0 = 0x900d900d900d900d
| SETREGSET(nt=0x40f, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d
|
| Attempting to write NT_ARM_POE (zero length)
| SETREGSET(nt=0x40f, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_POE::por_el0
| GETREGSET(nt=0x40f, len=8) read 8 bytes
| Read NT_ARM_POE::por_el0 = 0x900d900d900d900d

Fixes: 175198199262 ("arm64/ptrace: add support for FEAT_POE")
Cc: <stable@vger.kernel.org> # 6.12.x
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20241205121655.1824269-4-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-05 18:05:33 +00:00
Mark Rutland
f5d7129184 arm64: ptrace: fix partial SETREGSET for NT_ARM_FPMR
Currently fpmr_set() doesn't initialize the temporary 'fpmr' variable,
and a SETREGSET call with a length of zero will leave this
uninitialized. Consequently an arbitrary value will be written back to
target->thread.uw.fpmr, potentially leaking up to 64 bits of memory from
the kernel stack. The read is limited to a specific slot on the stack,
and the issue does not provide a write mechanism.

Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
contents of FPMR will be retained.

Before this patch:

| # ./fpmr-test
| Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d
| SETREGSET(nt=0x40e, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d
|
| Attempting to write NT_ARM_FPMR (zero length)
| SETREGSET(nt=0x40e, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0xffff800083963d50

After this patch:

| # ./fpmr-test
| Attempting to write NT_ARM_FPMR::fpmr = 0x900d900d900d900d
| SETREGSET(nt=0x40e, len=8) wrote 8 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d
|
| Attempting to write NT_ARM_FPMR (zero length)
| SETREGSET(nt=0x40e, len=0) wrote 0 bytes
|
| Attempting to read NT_ARM_FPMR::fpmr
| GETREGSET(nt=0x40e, len=8) read 8 bytes
| Read NT_ARM_FPMR::fpmr = 0x900d900d900d900d

Fixes: 4035c22ef7d4 ("arm64/ptrace: Expose FPMR via ptrace")
Cc: <stable@vger.kernel.org> # 6.9.x
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20241205121655.1824269-3-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-05 18:04:06 +00:00
Mark Rutland
ca62d90085 arm64: ptrace: fix partial SETREGSET for NT_ARM_TAGGED_ADDR_CTRL
Currently tagged_addr_ctrl_set() doesn't initialize the temporary 'ctrl'
variable, and a SETREGSET call with a length of zero will leave this
uninitialized. Consequently tagged_addr_ctrl_set() will consume an
arbitrary value, potentially leaking up to 64 bits of memory from the
kernel stack. The read is limited to a specific slot on the stack, and
the issue does not provide a write mechanism.

As set_tagged_addr_ctrl() only accepts values where bits [63:4] zero and
rejects other values, a partial SETREGSET attempt will randomly succeed
or fail depending on the value of the uninitialized value, and the
exposure is significantly limited.

Fix this by initializing the temporary value before copying the regset
from userspace, as for other regsets (e.g. NT_PRSTATUS, NT_PRFPREG,
NT_ARM_SYSTEM_CALL). In the case of a zero-length write, the existing
value of the tagged address ctrl will be retained.

The NT_ARM_TAGGED_ADDR_CTRL regset is only visible in the
user_aarch64_view used by a native AArch64 task to manipulate another
native AArch64 task. As get_tagged_addr_ctrl() only returns an error
value when called for a compat task, tagged_addr_ctrl_get() and
tagged_addr_ctrl_set() should never observe an error value from
get_tagged_addr_ctrl(). Add a WARN_ON_ONCE() to both to indicate that
such an error would be unexpected, and error handlnig is not missing in
either case.

Fixes: 2200aa7154cb ("arm64: mte: ptrace: Add NT_ARM_TAGGED_ADDR_CTRL regset")
Cc: <stable@vger.kernel.org> # 5.10.x
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20241205121655.1824269-2-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-05 18:03:25 +00:00
Robin Murphy
f00b53f161 arm64: cpufeature: Add GCS to cpucap_is_possible()
Since system_supports_gcs() ends up referring to cpucap_is_possible(),
teach the latter about GCS for consistency with similar features.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/416c7369fcdce4ebb2a8f12daae234507be27e38.1733406275.git.robin.murphy@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-05 17:15:38 +00:00
Catalin Marinas
cf3b16dae4 arm64: mte: Fix copy_highpage() warning on hugetlb folios
Commit 25c17c4b55de ("hugetlb: arm64: add mte support") improved the
copy_highpage() function to update the tags in the destination hugetlb
folio. However, when the source folio isn't tagged, the code takes the
non-hugetlb path where try_page_mte_tagging() warns as the destination
is a hugetlb folio:

  WARNING: CPU: 0 PID: 363 at arch/arm64/include/asm/mte.h:58 copy_highpage+0x1d4/0x2d8
  [...]
  pc : copy_highpage+0x1d4/0x2d8
  lr : copy_highpage+0x78/0x2d8
  [...]
  Call trace:
   copy_highpage+0x1d4/0x2d8 (P)
   copy_highpage+0x78/0x2d8 (L)
   copy_user_highpage+0x20/0x48
   copy_user_large_folio+0x1bc/0x268
   hugetlb_wp+0x190/0x860
   hugetlb_fault+0xa28/0xc10
   handle_mm_fault+0x2a0/0x2c0
   do_page_fault+0x12c/0x578
   do_mem_abort+0x4c/0xa8
   el0_da+0x44/0xb0
   el0t_64_sync_handler+0xc4/0x138
   el0t_64_sync+0x198/0x1a0

Change the check for the tagged status of the source folio so that it
does not fall through the non-hugetlb case. In addition, only perform
the copy (for the full folio) if the source page is the folio head and
warn if the destination folio is already tagged, for symmetry with the
non-hugetlb case.

Fixes: 25c17c4b55de ("hugetlb: arm64: add mte support")
Reported-by: Sasha Levin <sashal@kernel.org>
Cc: Yang Shi <yang@os.amperecomputing.com>
Cc: David Hildenbrand <david@redhat.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/Z0STR6VLt2MCalnY@sashalap
Link: https://lore.kernel.org/r/20241204175004.906754-1-catalin.marinas@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-05 11:25:44 +00:00
Catalin Marinas
c0900d15d3 arm64: Ensure bits ASID[15:8] are masked out when the kernel uses 8-bit ASIDs
Linux currently sets the TCR_EL1.AS bit unconditionally during CPU
bring-up. On an 8-bit ASID CPU, this is RES0 and ignored, otherwise
16-bit ASIDs are enabled. However, if running in a VM and the hypervisor
reports 8-bit ASIDs (ID_AA64MMFR0_EL1.ASIDBits == 0) on a 16-bit ASIDs
CPU, Linux uses bits 8 to 63 as a generation number for tracking old
process ASIDs. The bottom 8 bits of this generation end up being written
to TTBR1_EL1 and also used for the ASID-based TLBI operations as the
upper 8 bits of the ASID. Following an ASID roll-over event we can have
threads of the same application with the same 8-bit ASID but different
generation numbers running on separate CPUs. Both TLB caching and the
TLBI operations will end up using different actual 16-bit ASIDs for the
same process.

A similar scenario can happen in a big.LITTLE configuration if the boot
CPU only uses 8-bit ASIDs while secondary CPUs have 16-bit ASIDs.

Ensure that the ASID generation is only tracked by bits 16 and up,
leaving bits 15:8 as 0 if the kernel uses 8-bit ASIDs. Note that
clearing TCR_EL1.AS is not sufficient since the architecture requires
that the top 8 bits of the ASID passed to TLBI instructions are 0 rather
than ignored in such configuration.

Cc: stable@vger.kernel.org
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20241203151941.353796-1-catalin.marinas@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-05 11:24:38 +00:00
Aneesh Kumar K.V (Arm)
4f776d81bf arm64: dts: fvp: Update PCIe bus-range property
These days, the Fixed Virtual Platforms(FVP) Base RevC model supports
more PCI devices. Update the max bus number so that Linux can enumerate
them correctly. Without this, the kernel throws the below error while
booting with the default hierarchy

  |  pci_bus 0000:01: busn_res: [bus 01] end is updated to 01
  |  pci_bus 0000:02: busn_res: can not insert [bus 02-01] under
  |		[bus 00-01] (conflicts with (null) [bus 00-01])
  |  pci_bus 0000:02: busn_res: [bus 02-01] end is updated to 02
  |  pci_bus 0000:02: busn_res: can not insert [bus 02] under
  |		[bus 00-01] (conflicts with (null) [bus 00-01])
  |  pci_bus 0000:03: busn_res: can not insert [bus 03-01] under
  |		[bus 00-01] (conflicts with (null) [bus 00-01])
  |  pci_bus 0000:03: busn_res: [bus 03-01] end is updated to 03
  |  pci_bus 0000:03: busn_res: can not insert [bus 03] under
  |		[bus 00-01] (conflicts with (null) [bus 00-01])
  |  pci_bus 0000:04: busn_res: can not insert [bus 04-01] under
  |		[bus 00-01] (conflicts with (null) [bus 00-01])
  |  pci_bus 0000:04: busn_res: [bus 04-01] end is updated to 04
  |  pci_bus 0000:04: busn_res: can not insert [bus 04] under
  |		[bus 00-01] (conflicts with (null) [bus 00-01])
  |  pci 0000:00:01.0: BAR 14: assigned [mem 0x50000000-0x500fffff]
  |  pci-host-generic 40000000.pci: ECAM at [mem 0x40000000-0x4fffffff]
  |		for [bus 00-01]

The change is using 0xff as max bus number because the ECAM window is
256MB in size. Below is the lspci output with and without the change:

without fix
===========

  |  00:00.0 Host bridge: ARM Device 00ba (rev 01)
  |  00:01.0 PCI bridge: ARM Device 0def
  |  00:02.0 PCI bridge: ARM Device 0def
  |  00:03.0 PCI bridge: ARM Device 0def
  |  00:04.0 PCI bridge: ARM Device 0def
  |  00:1e.0 Unassigned class [ff00]: ARM Device ff80
  |  00:1e.1 Unassigned class [ff00]: ARM Device ff80
  |  00:1f.0 SATA controller: Device 0abc:aced (rev 01)
  |  01:00.0 SATA controller: Device 0abc:aced (rev 01)

with fix
========

  |  00:00.0 Host bridge: ARM Device 00ba (rev 01)
  |  00:01.0 PCI bridge: ARM Device 0def
  |  00:02.0 PCI bridge: ARM Device 0def
  |  00:03.0 PCI bridge: ARM Device 0def
  |  00:04.0 PCI bridge: ARM Device 0def
  |  00:1e.0 Unassigned class [ff00]: ARM Device ff80
  |  00:1e.1 Unassigned class [ff00]: ARM Device ff80
  |  00:1f.0 SATA controller: Device 0abc:aced (rev 01)
  |  01:00.0 SATA controller: Device 0abc:aced (rev 01)
  |  02:00.0 Unassigned class [ff00]: ARM Device ff80
  |  02:00.4 Unassigned class [ff00]: ARM Device ff80
  |  03:00.0 PCI bridge: ARM Device 0def
  |  04:00.0 PCI bridge: ARM Device 0def
  |  04:01.0 PCI bridge: ARM Device 0def
  |  04:02.0 PCI bridge: ARM Device 0def
  |  05:00.0 SATA controller: Device 0abc:aced (rev 01)
  |  06:00.0 Unassigned class [ff00]: ARM Device ff80
  |  06:00.7 Unassigned class [ff00]: ARM Device ff80
  |  07:00.0 Unassigned class [ff00]: ARM Device ff80
  |  07:00.3 Unassigned class [ff00]: ARM Device ff80
  |  08:00.0 Unassigned class [ff00]: ARM Device ff80
  |  08:00.1 Unassigned class [ff00]: ARM Device ff80

Cc: Sudeep Holla <sudeep.holla@arm.com>
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Conor Dooley <conor+dt@kernel.org>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
Message-Id: <20241128152543.1821878-1-aneesh.kumar@kernel.org>
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
2024-12-05 10:28:26 +00:00
Keisuke Nishimura
be7e611274 KVM: arm64: vgic-its: Add error handling in vgic_its_cache_translation
The return value of xa_store() needs to be checked. This fix adds an
error handling path that resolves the kref inconsistency on failure. As
suggested by Oliver Upton, this function does not return the error code
intentionally because the translation cache is best effort.

Fixes: 8201d1028caa ("KVM: arm64: vgic-its: Maintain a translation cache per ITS")
Signed-off-by: Keisuke Nishimura <keisuke.nishimura@inria.fr>
Suggested-by: Oliver Upton <oliver.upton@linux.dev>
Acked-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20241130144952.23729-1-keisuke.nishimura@inria.fr
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-12-03 16:22:10 -08:00
Marc Zyngier
03c7527e97 KVM: arm64: Do not allow ID_AA64MMFR0_EL1.ASIDbits to be overridden
Catalin reports that a hypervisor lying to a guest about the size
of the ASID field may result in unexpected issues:

- if the underlying HW does only supports 8 bit ASIDs, the ASID
  field in a TLBI VAE1* operation is only 8 bits, and the HW will
  ignore the other 8 bits

- if on the contrary the HW is 16 bit capable, the ASID field
  in the same TLBI operation is always 16 bits, irrespective of
  the value of TCR_ELx.AS.

This could lead to missed invalidations if the guest was lead to
assume that the HW had 8 bit ASIDs while they really are 16 bit wide.

In order to avoid any potential disaster that would be hard to debug,
prenent the migration between a host with 8 bit ASIDs to one with
wider ASIDs (the converse was obviously always forbidden). This is
also consistent with what we already do for VMIDs.

If it becomes absolutely mandatory to support such a migration path
in the future, we will have to trap and emulate all TLBIs, something
that nobody should look forward to.

Fixes: d5a32b60dc18 ("KVM: arm64: Allow userspace to change ID_AA64MMFR{0-2}_EL1")
Reported-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Oliver Upton <oliver.upton@linux.dev>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20241203190236.505759-1-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
2024-12-03 16:21:08 -08:00
Mark Rutland
8d09e2d569 arm64: patching: avoid early page_to_phys()
When arm64 is configured with CONFIG_DEBUG_VIRTUAL=y, a warning is
printed from the patching code because patch_map(), e.g.

| ------------[ cut here ]------------
| WARNING: CPU: 0 PID: 0 at arch/arm64/kernel/patching.c:45 patch_map.constprop.0+0x120/0xd00
| CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 6.13.0-rc1-00002-ge1a5d6c6be55 #1
| Hardware name: linux,dummy-virt (DT)
| pstate: 800003c5 (Nzcv DAIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : patch_map.constprop.0+0x120/0xd00
| lr : patch_map.constprop.0+0x120/0xd00
| sp : ffffa9bb312a79a0
| x29: ffffa9bb312a79a0 x28: 0000000000000001 x27: 0000000000000001
| x26: 0000000000000000 x25: 0000000000000000 x24: 00000000000402e8
| x23: ffffa9bb2c94c1c8 x22: ffffa9bb2c94c000 x21: ffffa9bb222e883c
| x20: 0000000000000002 x19: ffffc1ffc100ba40 x18: ffffa9bb2cf0f21c
| x17: 0000000000000006 x16: 0000000000000000 x15: 0000000000000004
| x14: 1ffff5376625b4ac x13: ffff753766a67fb8 x12: ffff753766919cd1
| x11: 0000000000000003 x10: 1ffff5376625b4c3 x9 : 1ffff5376625b4af
| x8 : ffff753766254f0a x7 : 0000000041b58ab3 x6 : ffff753766254f18
| x5 : ffffa9bb312d9bc0 x4 : 0000000000000000 x3 : ffffa9bb29bd90e4
| x2 : 0000000000000002 x1 : ffffa9bb312d9bc0 x0 : 0000000000000000
| Call trace:
|  patch_map.constprop.0+0x120/0xd00 (P)
|  patch_map.constprop.0+0x120/0xd00 (L)
|  __aarch64_insn_write+0xa8/0x120
|  aarch64_insn_patch_text_nosync+0x4c/0xb8
|  arch_jump_label_transform_queue+0x7c/0x100
|  jump_label_update+0x154/0x460
|  static_key_enable_cpuslocked+0x1d8/0x280
|  static_key_enable+0x2c/0x48
|  early_randomize_kstack_offset+0x104/0x168
|  do_early_param+0xe4/0x148
|  parse_args+0x3a4/0x838
|  parse_early_options+0x50/0x68
|  parse_early_param+0x58/0xe0
|  setup_arch+0x78/0x1f0
|  start_kernel+0xa0/0x530
|  __primary_switched+0x8c/0xa0
| irq event stamp: 0
| hardirqs last  enabled at (0): [<0000000000000000>] 0x0
| hardirqs last disabled at (0): [<0000000000000000>] 0x0
| softirqs last  enabled at (0): [<0000000000000000>] 0x0
| softirqs last disabled at (0): [<0000000000000000>] 0x0
| ---[ end trace 0000000000000000 ]---

The warning has been produced since commit:

  3e25d5a49f99b75b ("asm-generic: add an optional pfn_valid check to page_to_phys")

... which added a pfn_valid() check into page_to_phys(), and at this
point in boot pfn_valid() will always return false because the vmemmap
has not yet been initialized and there are no valid mem_sections yet.

Before that commit, the arithmetic performed by page_to_phys() would
give the expected physical address, though it is somewhat dubious to use
vmemmap addresses before the vmemmap has been initialized.

Aside from kernel image addresses, all executable code should be
allocated from execmem (where all allocations will fall within the
vmalloc area), and so there's no need for the fallback case when
CONFIG_EXECMEM=n.

Simplify patch_map() accordingly, directly converting kernel image
addresses and removing the redundant fallback case.

Fixes: 3e25d5a49f99 ("asm-generic: add an optional pfn_valid check to page_to_phys")
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Thomas Huth <thuth@redhat.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20241202170359.1475019-1-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-03 18:05:42 +00:00
Yang Shi
56a708742a arm64: mm: Fix zone_dma_limit calculation
Commit ba0fb44aed47 ("dma-mapping: replace zone_dma_bits by
zone_dma_limit") and subsequent patches changed how zone_dma_limit is
calculated to allow a reduced ZONE_DMA even when RAM starts above 4GB.
Commit 122c234ef4e1 ("arm64: mm: keep low RAM dma zone") further fixed
this to ensure ZONE_DMA remains below U32_MAX if RAM starts below 4GB,
especially on platforms that do not have IORT or DT description of the
device DMA ranges. While zone boundaries calculation was fixed by the
latter commit, zone_dma_limit, used to determine the GFP_DMA flag in the
core code, was not updated. This results in excessive use of GFP_DMA and
unnecessary ZONE_DMA allocations on some platforms.

Update zone_dma_limit to match the actual upper bound of ZONE_DMA.

Fixes: ba0fb44aed47 ("dma-mapping: replace zone_dma_bits by zone_dma_limit")
Cc: <stable@vger.kernel.org> # 6.12.x
Reported-by: Yutang Jiang <jiangyutang@os.amperecomputing.com>
Tested-by: Yutang Jiang <jiangyutang@os.amperecomputing.com>
Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
Link: https://lore.kernel.org/r/20241125171650.77424-1-yang@os.amperecomputing.com
[catalin.marinas@arm.com: some tweaking of the commit log]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-03 17:22:39 +00:00
FUKAUMI Naoki
2ddd93481b arm64: dts: rockchip: rename rfkill label for Radxa ROCK 5B
on ROCK 5B, there is no PCIe slot, instead there is a M.2 slot.
rfkill pin is not exclusive to PCIe devices, there is SDIO Wi-Fi
devices.

rename rfkill label from "rfkill-pcie-wlan" to "rfkill-m2-wlan", it
matches with rfkill-bt.

Fixes: 82d40b141a4c ("arm64: dts: rockchip: add rfkill node for M.2 Key E WiFi on rock-5b")
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: FUKAUMI Naoki <naoki@radxa.com>
Fixes: 82d40b141a4c ("arm64: dts: rockchip: add rfkill node for M.2 Key  E WiFi on rock-5b")
Link: https://lore.kernel.org/r/20241128120631.37458-1-naoki@radxa.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-12-03 00:28:23 +01:00
Chukun Pan
8b9c12757f arm64: dts: rockchip: add reset-names for combphy on rk3568
The reset-names of combphy are missing, add it.

Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Fixes: fd3ac6e80497 ("dt-bindings: phy: rockchip: rk3588 has two reset lines")
Link: https://lore.kernel.org/r/20241122073006.99309-1-amadeus@jmu.edu.cn
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
2024-12-03 00:25:39 +01:00
Peter Zijlstra
cdd30ebb1b module: Convert symbol namespace to string literal
Clean up the existing export namespace code along the same lines of
commit 33def8498fdd ("treewide: Convert macro and uses of __section(foo)
to __section("foo")") and for the same reason, it is not desired for the
namespace argument to be a macro expansion itself.

Scripted using

  git grep -l -e MODULE_IMPORT_NS -e EXPORT_SYMBOL_NS | while read file;
  do
    awk -i inplace '
      /^#define EXPORT_SYMBOL_NS/ {
        gsub(/__stringify\(ns\)/, "ns");
        print;
        next;
      }
      /^#define MODULE_IMPORT_NS/ {
        gsub(/__stringify\(ns\)/, "ns");
        print;
        next;
      }
      /MODULE_IMPORT_NS/ {
        $0 = gensub(/MODULE_IMPORT_NS\(([^)]*)\)/, "MODULE_IMPORT_NS(\"\\1\")", "g");
      }
      /EXPORT_SYMBOL_NS/ {
        if ($0 ~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+),/) {
  	if ($0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/ &&
  	    $0 !~ /(EXPORT_SYMBOL_NS[^(]*)\(\)/ &&
  	    $0 !~ /^my/) {
  	  getline line;
  	  gsub(/[[:space:]]*\\$/, "");
  	  gsub(/[[:space:]]/, "", line);
  	  $0 = $0 " " line;
  	}

  	$0 = gensub(/(EXPORT_SYMBOL_NS[^(]*)\(([^,]+), ([^)]+)\)/,
  		    "\\1(\\2, \"\\3\")", "g");
        }
      }
      { print }' $file;
  done

Requested-by: Masahiro Yamada <masahiroy@kernel.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://mail.google.com/mail/u/2/#inbox/FMfcgzQXKWgMmjdFwwdsfgxzKpVHWPlc
Acked-by: Greg KH <gregkh@linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2024-12-02 11:34:44 -08:00
Yang Shi
49ccf2c3ca arm64: mte: set VM_MTE_ALLOWED for hugetlbfs at correct place
The commit 5de195060b2e ("mm: resolve faulty mmap_region() error path
behaviour") moved vm flags validation before fop->mmap for file
mappings.  But when commit 25c17c4b55de ("hugetlb: arm64: add mte support")
was rebased on top of it, the hugetlbfs part was missed.  Mmapping
hugetlbfs file may not have MAP_HUGETLB set.

Fixes: 25c17c4b55de ("hugetlb: arm64: add mte support")
Signed-off-by: Yang Shi <yang@os.amperecomputing.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20241119200914.1145249-1-yang@os.amperecomputing.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
2024-12-02 11:48:14 +00:00
Manivannan Sadhasivam
e60b14f47d arm64: dts: qcom: sa8775p: Fix the size of 'addr_space' regions
For both the controller instances, size of the 'addr_space' region should
be 0x1fe00000 as per the hardware memory layout.

Otherwise, endpoint drivers cannot request even reasonable BAR size of 1MB.

Cc: stable@vger.kernel.org # 6.11
Fixes: c5f5de8434ec ("arm64: dts: qcom: sa8775p: Add ep pcie1 controller node")
Fixes: 1924f5518224 ("arm64: dts: qcom: sa8775p: Add ep pcie0 controller node")
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20241128145147.145618-1-manivannan.sadhasivam@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
2024-12-01 21:58:36 -06:00
Linus Torvalds
a14bf463e7 i2c-for-6.13-rc1-part3
core: add of based component probing
 
 Some devices are designed and manufactured with some components having
 multiple drop-in replacement options. These components are often
 connected to the mainboard via ribbon cables, having the same signals
 and pin assignments across all options. These may include the display
 panel and touchscreen on laptops and tablets, and the trackpad on
 laptops. Sometimes which component option is used in a particular device
 can be detected by some firmware provided identifier, other times that
 information is not available, and the kernel has to try to probe each
 device.
 
 Instead of a delicate dance between drivers and device tree quirks, this
 change introduces a simple I2C component probe function. For a given
 class of devices on the same I2C bus, it will go through all of them,
 doing a simple I2C read transfer and see which one of them responds. It
 will then enable the device that responds.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAmdMOCwACgkQFA3kzBSg
 KbaLWQ//e+29c9Trh+Typ6YCknuCFmM12xNUEPgce93EldERZjfCsdlHEchJnjEe
 RX5Mw+UxT7NqFUD6G2YQQw35LMj/PDws4Q/q3OwAvurj2PqoKEGIbdTxUEbGrLtT
 aYRUjGoqjPk3gAkqfKEQp8X8bvqKJfQ/xeXcZyy7Ij8xPU1LC/W6So4vpZA7oZkZ
 UfwrUXu2NM/DKfLATeSH3vnlBrrpco9BdjImDanP8BpuYHQ0aNt7IToDytd3/rLZ
 WKQPbHqVzzBUHm8Tf+DTyeVtII/ID078z+RW7htPrzPtzhVu2DN56w3z7/+EsVIy
 XKb1PiJo5HlFev4gxhIcUgf8L5JYE8MyU8eeRWAcDObiBYVcSP34P7Xoykczjuq9
 22IFNSdaqMVdigo9v4p7U99fVjoi3oUqIVsSb2HkmND8bPw3+jtyq1GxTFvTeOw8
 EVJGuGjYrPiko26zNgK/WZaumpB+fsH7uRioSb1ejlSQk0BcNv4YqjYaMx9aT7Xj
 +zF7luuxpkWTkPCjk57GX55K/BFzkA9jhJdKqjImBS+Q9Rn3k5bHyRdNPUDIeWs0
 Yl5dhg6QbLHyuPC2R/hJiV6X4uFloH9+Oh99T3lLzcVNc2mllPQDN9F4I8q5nWB8
 Eq5U95fnegfdVkiWnbNCnTCux/mypm35Gx46BffTiAJL2U9pSIE=
 =MAxU
 -----END PGP SIGNATURE-----

Merge tag 'i2c-for-6.13-rc1-part3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux

Pull i2c component probing support from Wolfram Sang:
 "Add OF component probing.

  Some devices are designed and manufactured with some components having
  multiple drop-in replacement options. These components are often
  connected to the mainboard via ribbon cables, having the same signals
  and pin assignments across all options. These may include the display
  panel and touchscreen on laptops and tablets, and the trackpad on
  laptops. Sometimes which component option is used in a particular
  device can be detected by some firmware provided identifier, other
  times that information is not available, and the kernel has to try to
  probe each device.

  Instead of a delicate dance between drivers and device tree quirks,
  this change introduces a simple I2C component probe function. For a
  given class of devices on the same I2C bus, it will go through all of
  them, doing a simple I2C read transfer and see which one of them
  responds. It will then enable the device that responds"

* tag 'i2c-for-6.13-rc1-part3' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux:
  MAINTAINERS: fix typo in I2C OF COMPONENT PROBER
  of: base: Document prefix argument for of_get_next_child_with_prefix()
  i2c: Fix whitespace style issue
  arm64: dts: mediatek: mt8173-elm-hana: Mark touchscreens and trackpads as fail
  platform/chrome: Introduce device tree hardware prober
  i2c: of-prober: Add GPIO support to simple helpers
  i2c: of-prober: Add simple helpers for regulator support
  i2c: Introduce OF component probe function
  of: base: Add for_each_child_of_node_with_prefix()
  of: dynamic: Add of_changeset_update_prop_string
2024-12-01 13:38:24 -08:00