IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
* arm64/for-next/perf:
perf: hisi: Fix use-after-free when register pmu fails
drivers/perf: hisi_pcie: Initialize event->cpu only on success
drivers/perf: hisi_pcie: Check the type first in pmu::event_init()
perf/arm-cmn: Enable per-DTC counter allocation
perf/arm-cmn: Rework DTC counters (again)
perf/arm-cmn: Fix DTC domain detection
drivers: perf: arm_pmuv3: Drop some unused arguments from armv8_pmu_init()
drivers: perf: arm_pmuv3: Read PMMIR_EL1 unconditionally
drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process
drivers/perf: xgene: Use device_get_match_data()
perf/amlogic: add missing MODULE_DEVICE_TABLE
docs/perf: Add ampere_cspmu to toctree to fix a build warning
perf: arm_cspmu: ampere_cspmu: Add support for Ampere SoC PMU
perf: arm_cspmu: Support implementation specific validation
perf: arm_cspmu: Support implementation specific filters
perf: arm_cspmu: Split 64-bit write to 32-bit writes
perf: arm_cspmu: Separate Arm and vendor module
* for-next/sve-remove-pseudo-regs:
: arm64/fpsimd: Remove the vector length pseudo registers
arm64/sve: Remove SMCR pseudo register from cpufeature code
arm64/sve: Remove ZCR pseudo register from cpufeature code
* for-next/backtrace-ipi:
: Add IPI for backtraces/kgdb, use NMI
arm64: smp: Don't directly call arch_smp_send_reschedule() for wakeup
arm64: smp: avoid NMI IPIs with broken MediaTek FW
arm64: smp: Mark IPI globals as __ro_after_init
arm64: kgdb: Implement kgdb_roundup_cpus() to enable pseudo-NMI roundup
arm64: smp: IPI_CPU_STOP and IPI_CPU_CRASH_STOP should try for NMI
arm64: smp: Add arch support for backtrace using pseudo-NMI
arm64: smp: Remove dedicated wakeup IPI
arm64: idle: Tag the arm64 idle functions as __cpuidle
irqchip/gic-v3: Enable support for SGIs to act as NMIs
* for-next/kselftest:
: Various arm64 kselftest updates
kselftest/arm64: Validate SVCR in streaming SVE stress test
* for-next/misc:
: Miscellaneous patches
arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer
arm64: module: Fix PLT counting when CONFIG_RANDOMIZE_BASE=n
arm64, irqchip/gic-v3, ACPI: Move MADT GICC enabled check into a helper
clocksource/drivers/arm_arch_timer: limit XGene-1 workaround
arm64: Remove system_uses_lse_atomics()
arm64: Mark the 'addr' argument to set_ptes() and __set_pte_at() as unused
arm64/mm: Hoist synchronization out of set_ptes() loop
arm64: swiotlb: Reduce the default size if no ZONE_DMA bouncing needed
* for-next/cpufeat-display-cores:
: arm64 cpufeature display enabled cores
arm64: cpufeature: Change DBM to display enabled cores
arm64: cpufeature: Display the set of cores with a feature
Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly
byte-swap NOP when compiling for big-endian, and the resulting series of
bytes happened to match the encoding of FNMADD S21, S30, S0, S0.
This went unnoticed until commit:
34f66c4c4d5518c1 ("arm64: Use a positive cpucap for FP/SIMD")
Prior to that commit, the kernel would always enable the use of FPSIMD
early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of
FNMADD within the kernel was not detected, but could result in the
corruption of user or kernel FPSIMD state.
After that commit, the instructions happen to trap during boot prior to
FPSIMD being detected and enabled, e.g.
| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
| Hardware name: linux,dummy-virt (DT)
| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : __pi_strcmp+0x1c/0x150
| lr : populate_properties+0xe4/0x254
| sp : ffffd014173d3ad0
| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000
| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008
| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044
| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005
| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000
| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000
| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000
| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000
| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a
| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8
| Kernel panic - not syncing: Unhandled exception
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
| Hardware name: linux,dummy-virt (DT)
| Call trace:
| dump_backtrace+0xec/0x108
| show_stack+0x18/0x2c
| dump_stack_lvl+0x50/0x68
| dump_stack+0x18/0x24
| panic+0x13c/0x340
| el1t_64_irq_handler+0x0/0x1c
| el1_abort+0x0/0x5c
| el1h_64_sync+0x64/0x68
| __pi_strcmp+0x1c/0x150
| unflatten_dt_nodes+0x1e8/0x2d8
| __unflatten_device_tree+0x5c/0x15c
| unflatten_device_tree+0x38/0x50
| setup_arch+0x164/0x1e0
| start_kernel+0x64/0x38c
| __primary_switched+0xbc/0xc4
Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is
either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked
commit.
Closes: https://github.com/ClangBuiltLinux/linux/issues/1948
Link: 1379b15099
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Cc: stable@vger.kernel.org
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20231025-disable-arm64-be-ias-b4-llvm-15-v1-1-b25263ed8b23@kernel.org
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This enables the Qualcomm PMIC-based USB Type-C port manager, found in
e.g. SM8250, and hence RB5, as well as the Type-C DisplayPort altmode
support to get display working on the same.
-----BEGIN PGP SIGNATURE-----
iQJJBAABCAAzFiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmU5aeEVHGFuZGVyc3Nv
bkBrZXJuZWwub3JnAAoJEAsfOT8Nma3Fr88P/iz5rBsGlI4/OyaSAPnlsByVQmla
pmDIWwAYEy/CWaDrCTe86NT/KnIOBHGbtwoqhuBsZWKSFGcQuK0Ays9naxqmInXx
FgPgM+hG7oG2l0Szs7bSA95xjQmVCpgveD+r6imx2tR8ajJDgktfz3JSZgSI+Dmr
iDLtUMJhVnEWpFney6hZgpdhg/0ggzhA9A7f1OU7g5sZBTh0w5QcsbVHtfj1j3YU
gB4cttLchmY4xhistvcqG9uLpvtoSAWru1TIbZIXXP9f2BEvi0oXQBM8Sym4sPkv
4F20Ny6kkt/CUynCq42F/yl2dGSuuHMUCWkfEHXcsKCO3/76HbzDznNPCFFOXxb5
gPnTO9OaeXNxrfhDaZ5JpiC+557U1HLZPPbdaQRTdR5Nap3Jy4n0Tghj/8Cpe6AA
MUZrJ82ZYfzATtdILSSkeXr58DCl9kDIK+rp+I/afeuLCY5W/C765lSsWVq8mQbS
DKb6Nkc+IkNIFCXH/IKILChz//NV/tWqKHU1i1ZDzN/5mm3HtwGPlr6ZGYMb18XQ
bRHaawJCn5Z2TJVNOAlHOymuyCxWVPaflG0STpPvfvRs5Lp4HPJLf+T/BIuBZcHH
gnAeKU7Zrb4HG9OdObuJklh88Q1jm1KH4MxTwabTH3QXoSX1VqowK+KMf+WcLkbo
pY7PG224X9jRai05
=zcki
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmU6hSwACgkQYKtH/8kJ
UifXLg//Q0qNA3HuYbgiLX1/TCBAzxh65VPFniRAaXjoADRnzcELRq6lBz+hwXBw
lHAe+Ycc+QL7pLTU4gQvWqsZglooxBc915L1e9lIYBDERZFYn7PISY6WIze7t8T9
4QN3s+lewTwMXZqvZLwzGTyOfBLphx8bMV/ItQKHfje5onh9ZdMGUOwdEFwFU3+d
iIQ2l0TyisBXM1bSe3P5Q2H4batbKCPzkQU1pBr8GESfftHx79+8+pMB8BgCy2V/
H4Ets8nH7SGwGVJlJKg30n/Hi8W9cb3hbCpn55IirTkIKyUL4q/sCIPkkXbyCryd
kHVubroJI86HzVKm01SY/ze0NkECGZsBMGbMBHAoC55Bc77syvdTW+8bPivABpLA
mcLZJZYykdZme7bq6toWsuidC5+GgHLMfuI9xImCynIyDsbyoiZbuJkQiKZ/4eA+
HViWJT+lQkytA3OQKhYlRYtuu/As6TK9JxO2OipSyuivwDOIQV2QCKLily8IIkdx
RLROnye4R4TjXh+pAic2swSM+1Av7JC/AX6TzZdoJPCWM8yf9KGlGK0d7A7jY8Dq
qy7JwF0SVZvnzUxV8ASHSjZ0KzUJY538KUCX534w95F6fjW9QG/fvdud/t7YnzSx
vQFqRZX1k1ni+ELqFtRKDYiAz5ejY6gVwENnuPIzvUNOlc8cWLc=
=piQJ
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-defconfig-for-6.7-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into soc/defconfig
Few more ARM64 defconfig updates for v6.7
This enables the Qualcomm PMIC-based USB Type-C port manager, found in
e.g. SM8250, and hence RB5, as well as the Type-C DisplayPort altmode
support to get display working on the same.
* tag 'qcom-arm64-defconfig-for-6.7-2' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: enable DisplayPort altmode support
arm64: defconfig: enable CONFIG_TYPEC_QCOM_PMIC
Link: https://lore.kernel.org/r/20231025191841.1015192-1-andersson@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Support for DFI (DDR performance monitoring) for rk3588, rk3568 and an
enable-fix for rk3399 as well as some small fixups for the RGB30 handheld
(non-existent uart and better vpll frequency).
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmU4G4wQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgUs1B/9TgdZjfgHQyJXzDLGp/RDBumYK/sVz7hyE
OCMaWL2gH6P0HFC2DlAoNshyRmSLg7zUb6jzyB9efoKoCRlVbobyyrLxxzyp2eHY
YdHnSoG0wbWrj8mVMhI97Qz8dz0q6+EHJQhyl/puk42HJXXY89i4mJ6tbBO0J0kl
eNShVFB6vbLO6Ylc0h9pjz1Z/Cdg82Y6WfaHSyKt2OmRWUZRqJfGOw4Mx3D+tcs8
6/W5GAhAf5YHAAQDHRMs8seMDzHEne8Wv0h0ckIFnT6mmDbmsT7Kfabhs0oZ0gG1
L8RsGKIkK9P4UClJvZRDSF5Bz9wOm9sdsJQCQhck+/imcVO0fib/
=jpev
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmU5hJoACgkQYKtH/8kJ
UifPZQ//Uo5nYMsgLK3XVxUZbvIa6tFDnuMGpnIhOrCiVHdm1hCGc89RmDz/QcZP
0NbgtnZ0olq7Hie0Xu/Oi1m1b/m9T3yvUx0BfoSNeKhC+TVhsssXzeL0Ktvaf0ph
YumLuCcCsCCam4kTg0PbQmL9Zjgc0s+kvwG5UD1syD/W/+EPMPyfKSF1J85BgY/F
RnsoC+K2xD5XHHD0reFo+boQWBcWNU5bXIFd84zNDtABIsmBDpZyko3rAMFk1agO
oeLQiTjwOuBPeeCfqzrCnlSS8A/ypDokO4wa1py+n448SZ0VBRCiTRsEgwPLbq4w
IryRxfEjTpNzAN9CQL7NuWV2mzEff5XyuJn8CY243Fb9k44feilmzDFCB9HnYmVv
eY2MeJwymcYP4UvXUwKef2NAefPS4+fdX6kO3zGZZ/Z7zRRLWASme5iCD4nALGws
f8VUA/mFOLuqfpVyxOPYqwY64Ep78L3iQoS+jTT995meTj0oPLd8AHH/hXERRCR4
7pmLILccR5F6Nuhvs1vQ+y66/S8gHhGX9r/toFIRO4PSs5IcS+2EIYOhmfBr7141
PAk446oXU3AU8YK26IbH4LJWNayyQGU03NHUYjhX0jII2S6LQaKt3yxX0uuYLJsB
JE7hg4jZ7OFRt+t9hTsPOD/beQa1I2sf9jsoOV8GAC2Tt4tNeWs=
=Dtda
-----END PGP SIGNATURE-----
Merge tag 'v6.7-rockchip-dts64-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into soc/dt
One new board the Turing RK1 system on module.
Support for DFI (DDR performance monitoring) for rk3588, rk3568 and an
enable-fix for rk3399 as well as some small fixups for the RGB30 handheld
(non-existent uart and better vpll frequency).
* tag 'v6.7-rockchip-dts64-2' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: dts: rockchip: Add Turing RK1 SoM support
dt-bindings: arm: rockchip: Add Turing RK1
dt-bindings: vendor-prefixes: add turing
arm64: dts: rockchip: Add DFI to rk3588s
arm64: dts: rockchip: Add DFI to rk356x
arm64: dts: rockchip: Always enable DFI on rk3399
arm64: dts: rockchip: Remove UART2 from RGB30
arm64: dts: rockchip: Update VPLL Frequency for RGB30
Link: https://lore.kernel.org/r/2777623.BEx9A2HvPv@phil
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Second round of few DT updates for K3 platforms. These have been in
linux-next for a few days without issues. Most of the additions is for
newer AM62P SoC dtsi bringing support on par with rest of AM62x family.
New features:
AM62P SoCs:
Support for wide range of peripherals such as eMMC/SD,
CPSW Ethernet, OSPI, etc similar to AM62
J721s2/J784s4/AM69 SoCs:
Display support via DP and HDMI interfaces and associated SerDes support
AM654 EVM/IDK:
ICSSG/PRU based industrial Ethernet support
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEEyRC2zAhGcGjrhiNExEYeRXyRFuMFAmU38AsQHHZpZ25lc2hy
QHRpLmNvbQAKCRDERh5FfJEW45EpB/0SH8k9dYfeRW10tWUegSlR0ed+qlEef/M2
t6uLMD5XFK97pKhqUYt1SXJA7ggN0OPI8NzAV+0geL2aG47AHBArK+2fiPs/MjQp
aGvSD/PQL85UO9pYgels2XMCm73uYLkEb5INpHr02X/q5EJsAdqIPA5seIQeurED
aETbVjpEmFxwJQAIwOkLGW6dep8neP1JiNaZWk1GkN+7OK+HHyHrCtlC/StWJaYx
fS8FYNICvX6lZTx97HntemvrW0aIxgVZfbM4DQuMYlKIG7Iktw8yqwkdTtxEChKE
b9ysFmSLk1pjWMPhyfZAAUMrbhliys4fFQ4DL6pPjhoea8kXqLum
=jiTd
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmU5hEUACgkQYKtH/8kJ
UieUoA//XUFrdPl4valIb/tQnoP8rSDBwL5TTYRqG3jHBV2Z3h+MlQ0QGaIYppF3
JHHllfjnk1sobOynFUYgydSxw9mG9R2rP3GJUs3eVaxyYFpstWiffgt3LkxITnnT
j1KQPtBtzK3Lc633wwExOJ7EzNwy++SskFwpoBFMJMiFfspGg1DBKMmHstdVZMrF
wyq6fQEh/FoS63hdS/5XWRCS+vpcz9hQp1J9BEVXTdYQsJgVl+68kt3d20ORBgQD
TY/yMpHXGiSs7TOERjDEaTviG11UInYbNBXFl5geqvM4dQVPLTiABOqlCCXrW56C
984VUhjc4YUjCfocKXOlW6dOOO3uy/W1u3Si59nlLwWimlUDGK7H9UNUI4T+jp99
9Vr2Y8qxcJAgCT03Vs4qQ7yZ6r+7ynk7J6xf7tBNaLb5xZLm77PZzm2cqy5zh5JK
GYW6Ajh/PMsy+sttdLW2k/txlOHlJoFP4GIrFnME7Sra2FzF3fJKnbWIq6bedT6z
q8DxP9jnAkwA15XsBLu9oVE76LoB8MwNzNSBVxI9ElNsaZnsg/qVa7lMo2Jkm2Yc
67b5mLTVsmjC6p6yOzHdUhahWiqhypicSlXnvHBprFFLv63KSMJP6RhJ3t/xCSWG
J0PpTNyYGvUnZNILWjrMvz7ojcmf6yrMyvVLtNmN7Z6srlTnK88=
=nbgf
-----END PGP SIGNATURE-----
Merge tag 'ti-k3-dt-for-v6.7-part2' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux into soc/dt
TI K3 device-tree updates for v6.7 - part 2
Second round of few DT updates for K3 platforms. These have been in
linux-next for a few days without issues. Most of the additions is for
newer AM62P SoC dtsi bringing support on par with rest of AM62x family.
New features:
AM62P SoCs:
Support for wide range of peripherals such as eMMC/SD,
CPSW Ethernet, OSPI, etc similar to AM62
J721s2/J784s4/AM69 SoCs:
Display support via DP and HDMI interfaces and associated SerDes support
AM654 EVM/IDK:
ICSSG/PRU based industrial Ethernet support
* tag 'ti-k3-dt-for-v6.7-part2' of https://git.kernel.org/pub/scm/linux/kernel/git/ti/linux:
arm64: dts: ti: k3-am654-idk: Add ICSSG Ethernet ports
arm64: dts: ti: k3-am654-icssg2: add ICSSG2 Ethernet support
arm64: dts: ti: k3-am65-main: Add ICSSG IEP nodes
arm64: dts: ti: k3-am62p5-sk: Updates for SK EVM
arm64: dts: ti: k3-am62p: Add nodes for more IPs
arm64: dts: ti: k3-am69-sk: Add DP and HDMI support
arm64: dts: ti: k3-j784s4-evm: Enable DisplayPort-0
arm64: dts: ti: k3-j784s4-main: Add DSS and DP-bridge node
arm64: dts: ti: k3-j784s4-main: Add WIZ and SERDES PHY nodes
arm64: dts: ti: k3-j784s4-main: Add system controller and SERDES lane mux
Link: https://lore.kernel.org/r/35a3c4c9-5c1b-4891-9ea2-e3f648a9afe0@ti.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
This reverts the following commits:
commit 53313ed25ba8 ("dt-bindings: marvell: Add Marvell MV88E6060 DSA schema")
commit 0f35369b4efe ("dt-bindings: marvell: Rewrite MV88E6xxx in schema")
commit 605a5f5d406d ("ARM64: dts: marvell: Fix some common switch mistakes")
commit bfedd8423643 ("ARM: dts: nxp: Fix some common switch mistakes")
commit 2b83557a588f ("ARM: dts: marvell: Fix some common switch mistakes")
commit ddae07ce9bb3 ("dt-bindings: net: mvusb: Fix up DSA example")
commit b5ef61718ad7 ("dt-bindings: net: dsa: Require ports or ethernet-ports")
As repoted by Vladimir, it breaks boot on the Turris MOX board.
Link: https://lore.kernel.org/all/20231025093632.fb2qdtunzaznd73z@skbuf/
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix some errors in the Marvell MV88E6xxx switch descriptions:
- The top node had no address size or cells.
- switch0@0 is not OK, should be ethernet-switch@0.
- ports should be ethernet-ports
- port@0 should be ethernet-port@0
- PHYs should be named ethernet-phy@
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
When trapping accesses from a NV guest that tries to access
SPSR_{irq,abt,und,fiq}, make sure we handle them as RAZ/WI,
as if AArch32 wasn't implemented.
This involves a bit of repainting to make the visibility
handler more generic.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231023095444.1587322-6-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
DBGVCR32_EL2, DACR32_EL2, IFSR32_EL2 and FPEXC32_EL2 are required to
UNDEF when AArch32 isn't implemented, which is definitely the case when
running NV.
Given that this is the only case where these registers can trap,
unconditionally inject an UNDEF exception.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Oliver Upton <oliver.upton@linux.dev>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Link: https://lore.kernel.org/r/20231023095444.1587322-5-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Implement a fine grained approach in the _EL2 sysreg range instead of
the current wide cast trap. This ensures that we don't mistakenly
inject the wrong exception into the guest.
[maz: commit message massaging, dropped secure and AArch32 registers
from the list]
Fixes: d0fc0a2519a6 ("KVM: arm64: nv: Add trap forwarding for HCR_EL2")
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Miguel Luis <miguel.luis@oracle.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231023095444.1587322-4-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Some _EL2 encodings are missing. Add them.
Signed-off-by: Miguel Luis <miguel.luis@oracle.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
[maz: dropped secure encodings]
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231023095444.1587322-3-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Some _EL12 encodings are missing. Add them.
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Miguel Luis <miguel.luis@oracle.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231023095444.1587322-2-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
KVM does not yet support userspace modifying PMCR_EL0.N (With
the previous patch, KVM ignores what is written by userspace).
Add support userspace limiting PMCR_EL0.N.
Disallow userspace to set PMCR_EL0.N to a value that is greater
than the host value as KVM doesn't support more event counters
than what the host HW implements. Also, make this register
immutable after the VM has started running. To maintain the
existing expectations, instead of returning an error, KVM
returns a success for these two cases.
Finally, ignore writes to read-only bits that are cleared on
vCPU reset, and RES{0,1} bits (including writable bits that
KVM doesn't support yet), as those bits shouldn't be modified
(at least with the current KVM).
Co-developed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Reiji Watanabe <reijiw@google.com>
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Link: https://lore.kernel.org/r/20231020214053.2144305-8-rananta@google.com
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
For unimplemented counters, the registers PM{C,I}NTEN{SET,CLR}
and PMOVS{SET,CLR} are expected to have the corresponding bits RAZ.
Hence to ensure correct KVM's PMU emulation, mask out the RES0 bits.
Defer this work to the point that userspace can no longer change the
number of advertised PMCs.
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231020214053.2144305-7-rananta@google.com
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
For unimplemented counters, the bits in PM{C,I}NTEN{SET,CLR} and
PMOVS{SET,CLR} registers are expected to RAZ. To honor this,
explicitly implement the {get,set}_user functions for these
registers to mask out unimplemented counters for userspace reads
and writes.
Co-developed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Link: https://lore.kernel.org/r/20231020214053.2144305-6-rananta@google.com
[Oliver: drop unnecessary locking]
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
The number of PMU event counters is indicated in PMCR_EL0.N.
For a vCPU with PMUv3 configured, the value is set to the same
value as the current PE on every vCPU reset. Unless the vCPU is
pinned to PEs that has the PMU associated to the guest from the
initial vCPU reset, the value might be different from the PMU's
PMCR_EL0.N on heterogeneous PMU systems.
Fix this by setting the vCPU's PMCR_EL0.N to the PMU's PMCR_EL0.N
value. Track the PMCR_EL0.N per guest, as only one PMU can be set
for the guest (PMCR_EL0.N must be the same for all vCPUs of the
guest), and it is convenient for updating the value.
To achieve this, the patch introduces a helper,
kvm_arm_pmu_get_max_counters(), that reads the maximum number of
counters from the arm_pmu associated to the VM. Make the function
global as upcoming patches will be interested to know the value
while setting the PMCR.N of the guest from userspace.
KVM does not yet support userspace modifying PMCR_EL0.N.
The following patch will add support for that.
Reviewed-by: Sebastian Ott <sebott@redhat.com>
Co-developed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Reiji Watanabe <reijiw@google.com>
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Link: https://lore.kernel.org/r/20231020214053.2144305-5-rananta@google.com
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Add a helper to read a vCPU's PMCR_EL0, and use it whenever KVM
reads a vCPU's PMCR_EL0.
Currently, the PMCR_EL0 value is tracked per vCPU. The following
patches will make (only) PMCR_EL0.N track per guest. Having the
new helper will be useful to combine the PMCR_EL0.N field
(tracked per guest) and the other fields (tracked per vCPU)
to provide the value of PMCR_EL0.
No functional change intended.
Reviewed-by: Sebastian Ott <sebott@redhat.com>
Signed-off-by: Reiji Watanabe <reijiw@google.com>
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231020214053.2144305-4-rananta@google.com
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Future changes to KVM's sysreg emulation will rely on having a valid PMU
instance to determine the number of implemented counters (PMCR_EL0.N).
This is earlier than when userspace is expected to modify the vPMU
device attributes, where the default is selected today.
Select the default PMU when handling KVM_ARM_VCPU_INIT such that it is
available in time for sysreg emulation.
Reviewed-by: Sebastian Ott <sebott@redhat.com>
Co-developed-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Signed-off-by: Reiji Watanabe <reijiw@google.com>
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Link: https://lore.kernel.org/r/20231020214053.2144305-3-rananta@google.com
[Oliver: rewrite changelog]
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Use more inclusive terms throughout the DSA subsystem by moving away
from "master" which is replaced by "conduit" and "slave" which is
replaced by "user". No functional changes.
Acked-by: Rob Herring <robh@kernel.org>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://lore.kernel.org/r/20231023181729.1191071-2-florian.fainelli@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Suzuki noticed that KVM's PMU emulation is oblivious to the NSU and NSK
event filter bits. On systems that have EL3 these bits modify the
filter behavior in non-secure EL0 and EL1, respectively. Even though the
kernel doesn't use these bits, it is entirely possible some other guest
OS does. Additionally, it would appear that these and the M bit are
required by the architecture if EL3 is implemented.
Allow the EL3 event filter bits to be set if EL3 is advertised in the
guest's ID register. Implement the behavior of NSU and NSK according to
the pseudocode, and entirely ignore the M bit for perf event creation.
Reported-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20231019185618.3442949-3-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
The NSH bit, which filters event counting at EL2, is required by the
architecture if an implementation has EL2. Even though KVM doesn't
support nested virt yet, it makes no effort to hide the existence of EL2
from the ID registers. Userspace can, however, change the value of PFR0
to hide EL2. Align KVM's sysreg emulation with the architecture and make
NSH RES0 if EL2 isn't advertised. Keep in mind the bit is ignored when
constructing the backing perf event.
While at it, build the event type mask using explicit field definitions
instead of relying on ARMV8_PMU_EVTYPE_MASK. KVM probably should've been
doing this in the first place, as it avoids changes to the
aforementioned mask affecting sysreg emulation.
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Link: https://lore.kernel.org/r/20231019185618.3442949-2-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Introduce new helper functions to set the guest's PMU
(kvm->arch.arm_pmu) either to a default probed instance or to a
caller requested one, and use it when the guest's PMU needs to
be set. These helpers will make it easier for the following
patches to modify the relevant code.
No functional change intended.
Reviewed-by: Sebastian Ott <sebott@redhat.com>
Signed-off-by: Reiji Watanabe <reijiw@google.com>
Signed-off-by: Raghavendra Rao Ananta <rananta@google.com>
Reviewed-by: Eric Auger <eric.auger@redhat.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231020214053.2144305-2-rananta@google.com
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
The counting of module PLTs has been broken when CONFIG_RANDOMIZE_BASE=n
since commit:
3e35d303ab7d22c4 ("arm64: module: rework module VA range selection")
Prior to that commit, when CONFIG_RANDOMIZE_BASE=n, the kernel image and
all modules were placed within a 128M region, and no PLTs were necessary
for B or BL. Hence count_plts() and partition_branch_plt_relas() skipped
handling B and BL when CONFIG_RANDOMIZE_BASE=n.
After that commit, modules can be placed anywhere within a 2G window
regardless of CONFIG_RANDOMIZE_BASE, and hence PLTs may be necessary for
B and BL even when CONFIG_RANDOMIZE_BASE=n. Unfortunately that commit
failed to update count_plts() and partition_branch_plt_relas()
accordingly.
Due to this, module_emit_plt_entry() may fail if an insufficient number
of PLT entries have been reserved, resulting in modules failing to load
with -ENOEXEC.
Fix this by counting PLTs regardless of CONFIG_RANDOMIZE_BASE in
count_plts() and partition_branch_plt_relas().
Fixes: 3e35d303ab7d ("arm64: module: rework module VA range selection")
Signed-off-by: Maria Yu <quic_aiquny@quicinc.com>
Cc: <stable@vger.kernel.org> # 6.5.x
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Fixes: 3e35d303ab7d ("arm64: module: rework module VA range selection")
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20231024010954.6768-1-quic_aiquny@quicinc.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
ACPI, irqchip and the architecture code all inspect the MADT
enabled bit for a GICC entry in the MADT.
The addition of an 'online capable' bit means all these sites need
updating.
Move the current checks behind a helper to make future updates easier.
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Signed-off-by: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
Acked-by: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
Link: https://lore.kernel.org/r/E1quv5D-00AeNJ-U8@rmk-PC.armlinux.org.uk
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
As all level 2 and level 3 caches are unified, add required
cache-unified property to fix warnings like:
uniphier-ld11-ref.dtb: l2-cache: 'cache-unified' is a required property
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/20231023021221.2884828-3-hayashi.kunihiko@socionext.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The DeviceTree Specification v0.3 specifies that the cache node
'compatible' and 'cache-level' properties are 'required'. Cf.
s3.8 Multi-level and Shared Cache Nodes
The 'cache-unified' property should be present if one of the
properties for unified cache is present ('cache-size', ...).
Update the Device Trees accordingly.
Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Reviewed-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/20221107155825.1644604-21-pierre.gondois@arm.com
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20231020195022.4183862-2-robh@kernel.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
We currently have a global VTCR_EL2 value for each guest, even
if the guest uses NV. This implies that the guest's own S2 must
fit in the host's. This is odd, for multiple reasons:
- the PARange values and the number of IPA bits don't necessarily
match: you can have 33 bits of IPA space, and yet you can only
describe 32 or 36 bits of PARange
- When userspace set the IPA space, it creates a contract with the
kernel saying "this is the IPA space I'm prepared to handle".
At no point does it constraint the guest's own IPA space as
long as the guest doesn't try to use a [I]PA outside of the
IPA space set by userspace
- We don't even try to hide the value of ID_AA64MMFR0_EL1.PARange.
And then there is the consequence of the above: if a guest tries
to create a S2 that has for input address something that is larger
than the IPA space defined by the host, we inject a fatal exception.
This is no good. For all intent and purposes, a guest should be
able to have the S2 it really wants, as long as the *output* address
of that S2 isn't outside of the IPA space.
For that, we need to have a per-s2_mmu VTCR_EL2 setting, which
allows us to represent the full PARange. Move the vctr field into
the s2_mmu structure, which has no impact whatsoever, except for NV.
Note that once we are able to override ID_AA64MMFR0_EL1.PARange
from userspace, we'll also be able to restrict the size of the
shadow S2 that NV uses.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231012205108.3937270-1-maz@kernel.org
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Now that we have the ability to display the list of cores
with a feature when its selectivly enabled, lets convert
DBM to use that as well.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Link: https://lore.kernel.org/r/20231017052322.1211099-3-jeremy.linton@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The AMU feature can be enabled on a subset of the cores in a system.
Because of that, it prints a message for each core as it is detected.
This becomes tedious when there are hundreds of cores. Instead, for
CPU features which can be enabled on a subset of the present cores,
lets wait until update_cpu_capabilities() and print the subset of cores
the feature was enabled on.
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com>
Tested-by: Ionela Voinescu <ionela.voinescu@arm.com>
Reviewed-by: Punit Agrawal <punit.agrawal@bytedance.com>
Tested-by: Punit Agrawal <punit.agrawal@bytedance.com>
Link: https://lore.kernel.org/r/20231017052322.1211099-2-jeremy.linton@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
RK3588 has three USB3 controllers. This adds the host-only controller,
which is using the naneng-combphy shared with PCIe and SATA.
The other two are dual-role and using a different PHY that is not yet
supported upstream.
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Link: https://lore.kernel.org/r/20231020150022.48725-4-sebastian.reichel@collabora.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To date the VHE code has aggressively reloaded the stage-2 MMU context
on every guest entry, despite the fact that this isn't necessary. This
was probably done for consistency with the nVHE code, which needs to
switch in/out the stage-2 MMU context as both the host and guest run at
EL1.
Hoist __load_stage2() into kvm_vcpu_load_vhe(), thus avoiding a reload
on every guest entry/exit. This is likely to be beneficial to systems
with one of the speculative AT errata, as there is now one fewer context
synchronization event on the guest entry path. Additionally, it is
possible that implementations have hitched correctness mitigations on
writes to VTTBR_EL2, which are now elided on guest re-entry.
Note that __tlb_switch_to_guest() is deliberately left untouched as it
can be called outside the context of a running vCPU.
Link: https://lore.kernel.org/r/20231018233212.2888027-6-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
The names for the helpers we expose to the 'generic' KVM code are a bit
imprecise; we switch the EL0 + EL1 sysreg context and setup trap
controls that do not need to change for every guest entry/exit. Rename +
shuffle things around a bit in preparation for loading the stage-2 MMU
context on vcpu_load().
Link: https://lore.kernel.org/r/20231018233212.2888027-5-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
Naturally, a change to the VMID for an MMU implies a new value for
VTTBR. Reload on VMID change in anticipation of loading stage-2 on
vcpu_load() instead of every guest entry.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231018233212.2888027-4-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
An MMU notifier could cause us to clobber the stage-2 context loaded on
a CPU when we switch to another VM's context to invalidate. This isn't
an issue right now as the stage-2 context gets reloaded on every guest
entry, but is disastrous when moving __load_stage2() into the
vcpu_load() path.
Restore the previous stage-2 context on the way out of a TLB
invalidation if we installed something else. Deliberately do this after
TGE=1 is synchronized to keep things safe in light of the speculative AT
errata.
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20231018233212.2888027-3-oliver.upton@linux.dev
Signed-off-by: Oliver Upton <oliver.upton@linux.dev>
The IDK application board has 4 Gigabit Ethernet ports.
This patch adds support for the 4 Gigabit Ethernet ports
which are provided by ICSSG0 and ICSSG1.
The IEP0 SYNC_OUT0 pins are used for PPS out on the IDK card.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Link: https://lore.kernel.org/r/20231020051937.3709871-4-danishanwar@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The ICSSG IP on AM65x SoCs have two Industrial Ethernet Peripherals (IEPs)
to manage/generate Industrial Ethernet functions such as time stamping.
Each IEP sub-module is sourced from an internal clock mux that can be
sourced from either of the IP instance's ICSSG_IEP_GCLK or ICSSG_ICLK.
Add the IEP nodes for all the ICSSG instances.
Signed-off-by: MD Danish Anwar <danishanwar@ti.com>
Link: https://lore.kernel.org/r/20231020051937.3709871-2-danishanwar@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
In the Linux kernel, a function whose name has two leading underscores
is conventionally called by the same-named function without leading
underscores -- not the other way around. __sha512_block_data_order()
got this backwards. Fix this, albeit without changing the name in the
perlasm since that is OpenSSL code. No change in behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In the Linux kernel, a function whose name has two leading underscores
is conventionally called by the same-named function without leading
underscores -- not the other way around. __sha256_block_data_order()
and __sha256_block_neon() got this backwards. Fix this, albeit without
changing the names in the perlasm since that is OpenSSL code. No change
in behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In the Linux kernel, a function whose name has two leading underscores
is conventionally called by the same-named function without leading
underscores -- not the other way around. __sha512_ce_transform() and
__sha512_block_data_order() got this backwards. Fix this, albeit
without changing "sha512_block_data_order" in the perlasm since that is
OpenSSL code. No change in behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In the Linux kernel, a function whose name has two leading underscores
is conventionally called by the same-named function without leading
underscores -- not the other way around. __sha2_ce_transform() and
__sha256_block_data_order() got this backwards. Fix this, albeit
without changing "sha256_block_data_order" in the perlasm since that is
OpenSSL code. No change in behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
In the Linux kernel, a function whose name has two leading underscores
is conventionally called by the same-named function without leading
underscores -- not the other way around. __sha1_ce_transform() got this
backwards. Fix this. No change in behavior.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Implement the ->digest method to improve performance on single-page
messages by reducing the number of indirect calls.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Implement a ->digest function for sha256-ce. This improves the
performance of crypto_shash_digest() with this algorithm by reducing the
number of indirect calls that are made. This only adds ~112 bytes of
code, mostly for the inlined init, as the finup function is tail-called.
For now, don't bother with this for sha224, since sha224 is rarely used.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Update the am62p5-sk board file to enable the new IPs introduced
in the SoC dtb.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20231019223055.1574125-6-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
The am62px shares many of the same IP as the existing am62x family
of SoCs, Introduce more nodes for hardware available on the am62p5.
Signed-off-by: Bryan Brattlof <bb@ti.com>
Link: https://lore.kernel.org/r/20231019223055.1574125-5-bb@ti.com
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
DRM_PANEL_ILITEK_ILI9882T is being split out from
DRM_PANEL_BOE_TV101WUM_NL6. Since the arm64 defconfig had the BOE
panel driver enabled, let's also enable the Ilitek driver.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20231013091844.804310-4-yangcong5@huaqin.corp-partner.google.com
