Features PIE and TCR2 introduce new registers, update the trap requirements
for these features.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230606145859.697944-19-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Copy the EL1 registers: TCR2_EL1, PIR_EL1, PIRE0_EL1, such that PIE
is also enabled for EL2.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230606145859.697944-18-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Now that the necessary changes have been made, set the Permission Indirection
registers and enable the Permission Indirection Extension.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230606145859.697944-17-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The encodings used in the permission indirection registers means that the
values that Linux puts in the PTEs do not need to be changed.
The E0 values are replicated in E1, with the execute permissions removed.
This is needed as the futex operations access user mappings with privileged
loads/stores.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230606145859.697944-16-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Disable trapping of TCR2_EL1 and PIRx_EL1 registers, so they can be
accessed from by EL1.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230606145859.697944-15-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Make these macros available to assembly code, so they can be re-used by the
PIE initialisation code.
This involves adding some extra macros, prepended with _ that are the raw
values not `pgprot` values.
A dummy value for PTE_MAYBE_NG is also provided, for use in assembly.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230606145859.697944-14-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
With PIE enabled, PROT_SECT_NORMAL would map onto PAGE_KERNEL_RO.
Add PTE_WRITE so that this maps onto PAGE_KERNEL, so that it is writable.
Without PIE, this should enable DBM for PROT_SECT_NORMAL. However PTE_RDONLY
is already cleared, so the DBM mechanism is not used, and it is always writable,
so this is functionally equivalent.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230606145859.697944-13-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
With PIE enabled, the swapper PTEs would have a Permission Indirection Index
(PIIndex) of 0. A PIIndex of 0 is not currently used by any other PTEs.
To avoid using index 0 specifically for the swapper PTEs, mark them as
PTE_UXN and PTE_WRITE, so that they map to a PAGE_KERNEL_EXEC equivalent.
This also adds PTE_WRITE to KPTI_NG_PTE_FLAGS, which was tested by booting
with kpti=on.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20230606145859.697944-12-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Now that KVM context switches the appropriate registers, expose ID_AA64MMFR3_EL1
to guests to allow them to use the new features.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Zenghui Yu <yuzenghui@huawei.com>
Cc: Will Deacon <will@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230606145859.697944-11-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Define the new system registers that PIE introduces and context switch them.
The PIE feature is still hidden from the ID register, and not exposed to a VM.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Zenghui Yu <yuzenghui@huawei.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230606145859.697944-10-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Define the new system register TCR2_EL1 and context switch it.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Oliver Upton <oliver.upton@linux.dev>
Cc: James Morse <james.morse@arm.com>
Cc: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: Zenghui Yu <yuzenghui@huawei.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20230606145859.697944-9-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This indicates if the system supports PIE. This is a CPUCAP_BOOT_CPU_FEATURE
as the boot CPU will enable PIE if it has it, so secondary CPUs must also
have this feature.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230606145859.697944-8-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
This capability indicates if the system supports the TCR2_ELx system register.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20230606145859.697944-7-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Update the HCRX_EL2 register with new bit definitions.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230606145859.697944-4-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Add definitions of TCR2_EL1, TCR2_EL12 and TCR_EL2 registers.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230606145859.697944-3-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Add the new ID register ID_AA64MMFR3, according to DDI0601 2023-03.
Signed-off-by: Joey Gouly <joey.gouly@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Brown <broonie@kernel.org>
Reviewed-by: Mark Brown <broonie@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20230606145859.697944-2-joey.gouly@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
The DSPI controller has configurable timing for
(a) tCSC: the interval between the assertion of the chip select and the
first clock edge
(b) tASC: the interval between the last clock edge and the deassertion
of the chip select
What is a bit surprising, but is documented in the figure "Example of
continuous transfer (CPHA=1, CONT=1)" in the datasheet, is that when the
chip select stays asserted between multiple TX FIFO writes, the tCSC and
tASC times still apply. With CONT=1, chip select remains asserted, but
SCK takes a break and goes to the idle state for tASC + tCSC ns.
In other words, the default values (of 0 and 0 ns) result in SCK
glitches where the SCK transition to the idle state, as well as the SCK
transition from the idle state, will have no delay in between, and it
may appear that a SCK cycle has simply gone missing. The resulting
timing violation might cause data corruption in many peripherals, as
their chip select is asserted.
The driver has device tree bindings for tCSC ("fsl,spi-cs-sck-delay")
and tASC ("fsl,spi-sck-cs-delay"), but these are only specified to apply
when the chip select toggles in the first place, and this timing
characteristic depends on each peripheral. Many peripherals do not have
explicit timing requirements, so many device trees do not have these
properties present at all.
Nonetheless, the lack of SCK glitches is a common sense requirement, and
since the SCK stays in the idle state during transfers for tCSC+tASC ns,
and that in itself should look like half a cycle, then let's ensure that
tCSC and tASC are at least a quarter of a SCK period, such that their
sum is at least half of one.
Fixes: 95bf15f386 ("spi: fsl-dspi: Add ~50ns delay between cs and sck")
Reported-by: Lisa Chen (陈敏捷) <minjie.chen@geekplus.com>
Debugged-by: Lisa Chen (陈敏捷) <minjie.chen@geekplus.com>
Tested-by: Lisa Chen (陈敏捷) <minjie.chen@geekplus.com>
Signed-off-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Link: https://lore.kernel.org/r/20230529223402.1199503-1-vladimir.oltean@nxp.com
Signed-off-by: Mark Brown <broonie@kernel.org>
In the commit 7bb6234095 ("ALSA: hda/realtek: fix speaker, mute/micmute
LEDs not work on a HP platform"), speakers and LEDs are fixed but only 2
CS35L41 amplifiers on SPI bus connected to Realtek codec are enabled. Need
the ALC245_FIXUP_CS35L41_SPI_4_HP_GPIO_LED to get all amplifiers working.
Signed-off-by: Chris Chiu <chris.chiu@canonical.com>
Fixes: 7bb6234095 ("ALSA: hda/realtek: fix speaker, mute/micmute LEDs not work on a HP platform")
Cc: <stable@vger.kernel.org>
Link: https://lore.kernel.org/r/20230606145747.135966-1-chris.chiu@canonical.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Merge series from Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>:
An unusually large set of patches to deal with new SoundWire-based
platforms.
The bulk of the patches addresses support for MTL using RT712, RT713,
MAX98363, CS42L42 jack codec and amplifiers. The sof_sdw machine
driver had to be updated to remove limitations on number of codecs per
links, dai types, dai naming, etc. We also moved parts of the Realtek
and Maxim support in common code to avoid duplication.
Community users also reported two Dell SKUs which were not supported
in the mainline due to hardware permutations.
Rework try_accept_one() to return accepted size instead of modifying
'start' inside the helper. It makes 'start' in-only argument and
streamlines code on the caller side.
Suggested-by: Borislav Petkov <bp@alien8.de>
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lore.kernel.org/r/20230606142637.5171-9-kirill.shutemov@linux.intel.com
1. Final cleanups and improvements as a result of dtbs_checks which rely
on previously merged driver changes thus affecting older or
out-of-tree kernels. The changes are necessary to achieve full
dtbs_check compliance, which justifies affecting out-of-tree users.
Changes affecting them are:
- Drop simple-bus compatible from FIMC: Exynos4 and S5PV210,
- Remove empty camera pinctrl configuration: Exynos4 and S5PV210,
- Re-order MFC clock names to match Exynos and bindings: S5PV210.
2. Except above few more non-intrusive cleanups for dtbs_check for
S5PV210. Fix also some typos.
3. Re-introduce Exynos4212 which was removed because of lack of upstream
users. Artur Weber adds now Samsung Galaxy Tab3 with Exynos4212.
-----BEGIN PGP SIGNATURE-----
iQJEBAABCgAuFiEE3dJiKD0RGyM7briowTdm5oaLg9cFAmR5rNgQHGtyemtAa2Vy
bmVsLm9yZwAKCRDBN2bmhouD131PD/9b9jaNO3NBJdHCg2e1XOG4Ca4EiZy7+c7g
JUqQcgdy478eXYSF2WM1qNLJjOIlnHgyWPChTHsNK8W0bD0wqR6JQReE5ZYj/hcA
5C1FrL5YMfA9ZHtyLBPl5NEilwtPYnNyJw7+LkPQdZIC8QQ4k4JaZzYtAgESAc3M
0uphSKcTIrT/hdbAA82hBFIGdSVu1GTiKfWAPRTKPyA3BGuYY8dLfMTIQ2czxVDZ
CbH1m2R/d6idppyDEkXmUNwOAOeiWpGbiJEcOEOwXq68hJUpkDjAJXs5QKlhb2Ue
TOR0DJp3ZorWt8WY50JXy/8Kzv3i/QgLugl7+3XMyNSvArxiFyEEDdZl9WXToJmV
hi5KrbWmMdKIuUGpFON5ZGzsTnDUYuvpILCWU7iyP59DA4pJMZW42JTskM1i2aDb
HPXQGCjQDJONuJq9MtB6QK+zCpHMO913hXIG7GsIiW73bimjER3y1rMW93PUL49x
08tNHWcyFN4ghwXcMBBbrf7yWfQ8SVhUSRnD1LGcJYj0gwaJgRPHyKDnApgxxIKB
35lVRH+84SYslLmkrZIJTN1lw2yqHF4+oxrnza0+ItdaJyZk8rmXaP34VKYjXZxs
y5SBjVZ8lrdCIB9kVhy2DtRj8vLO88uzUFRmAQF54TRL62jhC56T2gl7PJQtCfJz
OtyplsT7pQ==
=prN6
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmR/UdwACgkQYKtH/8kJ
UicS0xAAqi4ctbU0A4KNOUn2y/U1amFrEN9l7nfYjUCb1CH6Z1qAvRTyoOxO4xB/
dK82QdS7f2si4IWurVGeWfdruSqHWure1Py82iD2oIoRm0XIOkx/5EKSmPYrEXrJ
NbFl5lt5ox+nQLdD5mLAKsxswTP3bfor0ILYFYJj5zk5hEhdk72lGmXboO/0ulYn
sqE8JugXgxCehbA3xYbShghIdLrapaAnQDzawTeXKIH0IFdMfj31X7kQr6D6BO8S
EeJTvNwhaX5ZCTAgWmWX4O9fOoxj1FriRuic5WYI7skjwBwgsX2uFK/t5lV2pYn2
9gazldz0Bx5vu/DitsAmK1nyj9ma8996j5Vh5L4DLz4uo566RkNI3cEYHt388oyQ
d/zIloyu14HHr3YtRXieSakTf+FvHlMmHEvOMsAgqibsXFvHTJh5st6grIZHj3iO
zmBNsLW9tcvhLDe72QPcI4ZY/QWyeROuEH/d9OedD+whTpFA45kiG+qPZZYKKcl+
ZxOQC0kib7mW4KxvGLZoonzNC8vUMmiCbsPrkNBerTQdVHAvHt2GiO2aBvibNn/U
QismtyjiMKBLWb27MNngWURlWDv9kmu+p7gnF19sFUhTdJCXfeTiL9PI13tvRHF3
neG1BVchVXPUMUwymqW4RqZI01tp6H5OssGdp3kM6goXYcMlA7M=
=7GAg
-----END PGP SIGNATURE-----
Merge tag 'samsung-dt-6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux into soc/dt
Samsung DTS ARM changes for v6.5
1. Final cleanups and improvements as a result of dtbs_checks which rely
on previously merged driver changes thus affecting older or
out-of-tree kernels. The changes are necessary to achieve full
dtbs_check compliance, which justifies affecting out-of-tree users.
Changes affecting them are:
- Drop simple-bus compatible from FIMC: Exynos4 and S5PV210,
- Remove empty camera pinctrl configuration: Exynos4 and S5PV210,
- Re-order MFC clock names to match Exynos and bindings: S5PV210.
2. Except above few more non-intrusive cleanups for dtbs_check for
S5PV210. Fix also some typos.
3. Re-introduce Exynos4212 which was removed because of lack of upstream
users. Artur Weber adds now Samsung Galaxy Tab3 with Exynos4212.
* tag 'samsung-dt-6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
ARM: dts: s5pv210: Fix typo in comments, fix pinctrl header
ARM: dts: s3c64xx: Fix some typos in comments
ARM: dts: exynos: Fix some typos in comments
dt-bindings: arm: samsung: Add Samsung Galaxy Tab3 family boards
ARM: dts: exynos: Re-introduce Exynos4212 DTSI
ARM: dts: exynos: Move common Exynos4x12 definitions to exynos4x12.dtsi
ARM: dts: s5pv210: remove empty camera pinctrl configuration
ARM: dts: s5pv210: add dummy 5V regulator for backlight on SMDKv210
ARM: dts: s5pv210: re-order MFC clock names to match Exynos and bindings
ARM: dts: s5pv210: align USB node name with bindings
ARM: dts: s5pv210: align pin configuration nodes with bindings
ARM: dts: exynos: Remove empty camera pinctrl configuration in Odroid X/U3
ARM: dts: exynos: Remove empty camera pinctrl configuration in Universal C210
ARM: dts: exynos: Remove empty camera pinctrl configuration in Trats
ARM: dts: s5pv210: drop simple-bus from FIMC
ARM: dts: exynos: drop simple-bus from FIMC in Exynos4
Link: https://lore.kernel.org/r/20230602091501.15178-2-krzysztof.kozlowski@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
It contains:
- gpio-line-names addition for at91-tse850-3 board
- support for SMA connectors on lan966x-pcb8309 board
- use drive-open-drain as boolean property as this is how code handles
it
- generic names for clock controller devices
- use of the new clock controller bindings for at91sam9n12 slow clock
controller
- one blank line removal on sama5d2.dtsi
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQTsZ8eserC1pmhwqDmejrg/N2X7/QUCZHXRoQAKCRCejrg/N2X7
/aM4AQD9L1shYbMzPEhqj7UxQUXhGmZnoDzd5aP2OicgUS5JDwD/cg3CM29eq8Fj
wW21GjSM/evK3sDfdbDmvatIM41uhw0=
=zMgl
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmR/UX8ACgkQYKtH/8kJ
UieYbw//WnKz+UvPj8HC/HUz8MOKOHGfN4ZOyiV+Hg3Tt8L3AntU7tpPraGwpuy2
9h7rBBIPxk182VpkHIpcVCTH4xt8XQvcZKLaZoe57CaPl5VmpbFBavExtf1wzKbY
f62LaZce/rDI/yw9F6S0+WltzwRhLSMmX/eyGAlNgNfcezd+hFKvOY3/Jt5XsVgA
i53YTMGfryCWEaUW5F5qD5WOqz6d+LmxrKLbnPQpYjqPIaCF2K7GD+FspH0iVNpf
wpmYZK+ku0Q3OXpRL6j5FZhXG3q7haRRB86/fp31wU+IoMEx9Il9G6NHfbe7dc8Z
i1bHQOKUn4OPsftt5ld35v6MsJ1Kc4CWF8Rz7cOIIvDjDfsvlT91uiIMhg7cj+ql
eJvQUlKaj1P0cjv5KlXD2pIUDXlVHNK3YGcyzHf42+P9NSDaggFgvCywtO2Et744
46PHQ+IeuXFpbUuxFEPMn+cmzRZqodBDqSY1EWRwAIvC3nTAA14outEDclWh4rLj
3QZPIcv/r4TMIa+OSUL37eUUhcx8v5vo8qjfSBbGioDSi/XHnJA0Ef1z9cTs6/PQ
bDzwJuF9wAIyqegDkG6wrVbEV0DU6udcpDwibesAt/AnvUGXkX9Dj/K3JTWl7h1q
ImJPRX+YdZSw5zA0s9iFALjp8RxOqQzIKkptlCV3toa2dQ0RCGo=
=aFnJ
-----END PGP SIGNATURE-----
Merge tag 'at91-dt-6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into soc/dt
AT91 DT for 6.5
It contains:
- gpio-line-names addition for at91-tse850-3 board
- support for SMA connectors on lan966x-pcb8309 board
- use drive-open-drain as boolean property as this is how code handles
it
- generic names for clock controller devices
- use of the new clock controller bindings for at91sam9n12 slow clock
controller
- one blank line removal on sama5d2.dtsi
* tag 'at91-dt-6.5' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: dts: at91: sama5d2: remove extra line
ARM: dts: at91: Return to boolean properties
ARM: dts: lan966x: Add support for SMA connectors
ARM: dts: at91: use clock-controller name for sckc nodes
ARM: dts: at91: at91sam9n12: witch sckc to new clock bindings
ARM: dts: at91: use clock-controller name for PMC nodes
ARM: dts: at91: tse850: add properties for gpio-line-names
Link: https://lore.kernel.org/r/20230530105945.11638-1-claudiu.beznea@microchip.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Memory acceptance requires a hypercall and one or multiple module calls.
Make helpers for the calls available in boot stub. It has to accept
memory where kernel image and initrd are placed.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Link: https://lore.kernel.org/r/20230606142637.5171-8-kirill.shutemov@linux.intel.com
load_unaligned_zeropad() can lead to unwanted loads across page boundaries.
The unwanted loads are typically harmless. But, they might be made to
totally unrelated or even unmapped memory. load_unaligned_zeropad()
relies on exception fixup (#PF, #GP and now #VE) to recover from these
unwanted loads.
But, this approach does not work for unaccepted memory. For TDX, a load
from unaccepted memory will not lead to a recoverable exception within
the guest. The guest will exit to the VMM where the only recourse is to
terminate the guest.
There are two parts to fix this issue and comprehensively avoid access
to unaccepted memory. Together these ensure that an extra "guard" page
is accepted in addition to the memory that needs to be used.
1. Implicitly extend the range_contains_unaccepted_memory(start, end)
checks up to end+unit_size if 'end' is aligned on a unit_size
boundary.
2. Implicitly extend accept_memory(start, end) to end+unit_size if 'end'
is aligned on a unit_size boundary.
Side note: This leads to something strange. Pages which were accepted
at boot, marked by the firmware as accepted and will never
_need_ to be accepted might be on unaccepted_pages list
This is a cue to ensure that the next page is accepted
before 'page' can be used.
This is an actual, real-world problem which was discovered during TDX
testing.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20230606142637.5171-7-kirill.shutemov@linux.intel.com
efi_config_parse_tables() reserves memory that holds unaccepted memory
configuration table so it won't be reused by page allocator.
Core-mm requires few helpers to support unaccepted memory:
- accept_memory() checks the range of addresses against the bitmap and
accept memory if needed.
- range_contains_unaccepted_memory() checks if anything within the
range requires acceptance.
Architectural code has to provide efi_get_unaccepted_table() that
returns pointer to the unaccepted memory configuration table.
arch_accept_memory() handles arch-specific part of memory acceptance.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20230606142637.5171-6-kirill.shutemov@linux.intel.com
The firmware will pre-accept the memory used to run the stub. But, the
stub is responsible for accepting the memory into which it decompresses
the main kernel. Accept memory just before decompression starts.
The stub is also responsible for choosing a physical address in which to
place the decompressed kernel image. The KASLR mechanism will randomize
this physical address. Since the accepted memory region is relatively
small, KASLR would be quite ineffective if it only used the pre-accepted
area (EFI_CONVENTIONAL_MEMORY). Ensure that KASLR randomizes among the
entire physical address space by also including EFI_UNACCEPTED_MEMORY.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Liam Merwick <liam.merwick@oracle.com>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Link: https://lore.kernel.org/r/20230606142637.5171-5-kirill.shutemov@linux.intel.com
- Define the SRAM nodes that will be the preferred way to
specify SRAM segments to drivers going forward.
- Fix up the naming of the STMPE nodes as we are merging
proper YAML bindings which puts restrictions on those.
- Disable charging on the Ux500 HREF boards because these
do not have any real batteries connected.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmR0kGQACgkQQRCzN7AZ
XXPykBAAj9fc1CTWOdLik+8uZ0Al1U1cBL6VoK/nazIf7lla/nCmAJ5zTSC6lnAw
JtdUbyOJPTyKG5JqNvOTFngyNpChDVMQxDqgARxRcq4IRdNnE7YSsQKguUbC8rrv
Vl040G1dPF8HYxdNSjx5hGlgqLUQRVnhe1d8bRQvd68LCEoy7nqfr4aQ0TnW3ZEZ
IulMyA85PYmWlFgl6t5hKkCabf/tCK/mYuOM0dv0v7p1KMBLymtSp1C+89CPU/8F
xODSeRIOHlzYgCEQfx8I4S5TT37h4DAA0nvXMaKk22WzaTqmG0EzJAF22Zad+RzN
vKmYIJcELPV+ItCy9Vewrmwdf3y0mzIOzwTJeBxFc7O8PPyvs5VhOrBz1qjWWb4l
HwchVLQHEQcc3U64+hVEdyAGGNGBrLn/uk3WZu/CuAi2/Nm8C8du0SBDVIfVirYI
8ctjicsju4WUUXoAHvkCu9JCDiRCR7yUh6qoIdrZq+dDcSpPdSYsjY9o2ulJOQ1k
6rzRSNkKs6qSTGs+xKT5lg+hd7uXyKXUn/Cd+8OSPwkWO92VUrdvP8d0k+SxXlI4
vbNGRnsPzm6tRqWBEGK0fYdm8Q3SFOVnE1DpFBjxf0he3bRFNbCnpc8D5C1e6Kmw
857BSmqucGyZ9Ey+CLYChkcz+MIbXXEUbx7FgDgOBsl6u1nYax8=
=2rdu
-----END PGP SIGNATURE-----
gpgsig -----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEiK/NIGsWEZVxh/FrYKtH/8kJUicFAmR/Tc8ACgkQYKtH/8kJ
Uif/CA/+NhW9g/NiJXwZ2+THv+46A+Dhoe+1Yu/wrliN5Li2/awypAWsLBowjuzC
RRf1FzMhMwVNKZL5Sqy6kPUIceDBTlmarZsAc/j4qDql2XffPJBw8cggyNjgCoUO
ufaxgVrFMqQH+dWqjYw2ybOSu0AWmN0D8zRbUwhbdJ4u8QIz1gpgH+evATGdf1Xy
KT+1lLpol54gmC151u+JjqWPiRIgtrJ+8wlRDLTNPDeAeo1WCh+ePrX3XY5iP2+8
dZNigT4lTGF9ByfgrpG4psitN0RdlMoPFPYj/PNjamHZUKXX8gOrgD7RN4OXykhn
eHJqCqF25+vEuNdcHp9uKzG1KVCpGk8sWBeTNvEQSnP6fuoi2OLFIO1Jh9zkCHf4
T+UyRtzITjY38Gxk9tuFwz4sCeqbHbD+EIcnkc12nno0sZgXZYp1bFeZomvl+pTc
XseeM1cR1mbm7zKt7cdfKNtBUeKivwY/M4cRkWLK3ArKko6ffv6Sn8RkqSFPhQzr
VWjEDA6SP0KvBI+sYrXLFUgNMbkVEtcT7s5ZDuDrS7cuxHZQVczDLVanP9M1XbTU
pu3pgWLFbP/ieCb6RJpr083V61JEtT4V45BTDW382DtalUjh8dvPgTmkOJPdSo3g
/ahKav4lWiHGhadUgkw4hxmKLKBBHvIHtfgvDFOlb/5ixl1olZQ=
=QLb5
-----END PGP SIGNATURE-----
Merge tag 'ux500-dts-for-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik into soc/dt
These are some Ux500 DTS updates for the v6.5 kernel cycle:
- Define the SRAM nodes that will be the preferred way to
specify SRAM segments to drivers going forward.
- Fix up the naming of the STMPE nodes as we are merging
proper YAML bindings which puts restrictions on those.
- Disable charging on the Ux500 HREF boards because these
do not have any real batteries connected.
* tag 'ux500-dts-for-v6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik:
ARM: dts: ux500: Add eSRAM nodes
ARM: dts: ux500: Fix STMPE device nodes
ARM: dts: ux500: Disable charging on HREF boards
Link: https://lore.kernel.org/r/CACRpkdZ2YLzB-n+1M9u0UqVfct_LAR5cLvYyJhxHsXNR_TFzpQ@mail.gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Dan Carpenter found via Smatch static checker, that unsigned 'mtu_lo' is
never less than zero.
Variable mtu_lo should have been an 'int', because read_mtu_device_lo()
uses minus as error indications.
Fixes: b62eba5632 ("selftests/bpf: Tests using bpf_check_mtu BPF-helper")
Reported-by: Dan Carpenter <dan.carpenter@linaro.org>
Signed-off-by: Jesper Dangaard Brouer <brouer@redhat.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Simon Horman <simon.horman@corigine.com>
Link: https://lore.kernel.org/bpf/168605104733.3636467.17945947801753092590.stgit@firesoul
Arnd suggested that adding a maintainer handbook for the SoC "subsystem"
would be helpful in trying to bring on board maintainers for the various
new platforms cropping up in RISC-V land.
Add a document briefly describing the role of the SoC subsystem and some
basic advice for (new) platform maintainers.
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
When constructing the sim, gpio-sim constructs an array of named lines,
sized based on the largest offset of any named line, and then initializes
that array with the names of all lines, including unnamed hogs with higher
offsets. In doing so it writes NULLs beyond the extent of the array.
Add a check that only named lines are used to initialize the array.
Fixes: cb8c474e79 ("gpio: sim: new testing module")
Signed-off-by: Kent Gibson<warthog618@gmail.com>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The Intel Mount Evans SoC's Integrated Management Complex uses the SPI
controller for access to a NOR SPI FLASH. However, the SoC doesn't
provide a mechanism to override the native chip select signal.
This driver doesn't use DMA for memory operations when a chip select
override is not provided due to the native chip select timing behavior.
As a result no DMA configuration is done for the controller and this
configuration is not tested.
The controller also has an errata where a full TX FIFO can result in
data corruption. The suggested workaround is to never completely fill
the FIFO. The TX FIFO has a size of 32 so the fifo_len is set to 31.
Signed-off-by: Abe Kohandel <abe.kohandel@intel.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20230606145402.474866-2-abe.kohandel@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
UEFI Specification version 2.9 introduces the concept of memory
acceptance: Some Virtual Machine platforms, such as Intel TDX or AMD
SEV-SNP, requiring memory to be accepted before it can be used by the
guest. Accepting happens via a protocol specific for the Virtual
Machine platform.
Accepting memory is costly and it makes VMM allocate memory for the
accepted guest physical address range. It's better to postpone memory
acceptance until memory is needed. It lowers boot time and reduces
memory overhead.
The kernel needs to know what memory has been accepted. Firmware
communicates this information via memory map: a new memory type --
EFI_UNACCEPTED_MEMORY -- indicates such memory.
Range-based tracking works fine for firmware, but it gets bulky for
the kernel: e820 (or whatever the arch uses) has to be modified on every
page acceptance. It leads to table fragmentation and there's a limited
number of entries in the e820 table.
Another option is to mark such memory as usable in e820 and track if the
range has been accepted in a bitmap. One bit in the bitmap represents a
naturally aligned power-2-sized region of address space -- unit.
For x86, unit size is 2MiB: 4k of the bitmap is enough to track 64GiB or
physical address space.
In the worst-case scenario -- a huge hole in the middle of the
address space -- It needs 256MiB to handle 4PiB of the address
space.
Any unaccepted memory that is not aligned to unit_size gets accepted
upfront.
The bitmap is allocated and constructed in the EFI stub and passed down
to the kernel via EFI configuration table. allocate_e820() allocates the
bitmap if unaccepted memory is present, according to the size of
unaccepted region.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20230606142637.5171-4-kirill.shutemov@linux.intel.com
The kunit_abort() function has been renamed __kunit_abort(), update the
references to it in the documentation.
Suggested-by: Daniel Latypov <dlatypov@google.com>
Signed-off-by: David Gow <davidgow@google.com>
Reviewed-by: Daniel Latypov <dlatypov@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Currently allocate_e820() is only interested in the size of map and size
of memory descriptor to determine how many e820 entries the kernel
needs.
UEFI Specification version 2.9 introduces a new memory type --
unaccepted memory. To track unaccepted memory, the kernel needs to
allocate a bitmap. The size of the bitmap is dependent on the maximum
physical address present in the system. A full memory map is required to
find the maximum address.
Modify allocate_e820() to get a full memory map.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Tom Lendacky <thomas.lendacky@amd.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20230606142637.5171-3-kirill.shutemov@linux.intel.com
UEFI Specification version 2.9 introduces the concept of memory
acceptance. Some Virtual Machine platforms, such as Intel TDX or AMD
SEV-SNP, require memory to be accepted before it can be used by the
guest. Accepting happens via a protocol specific to the Virtual Machine
platform.
There are several ways the kernel can deal with unaccepted memory:
1. Accept all the memory during boot. It is easy to implement and it
doesn't have runtime cost once the system is booted. The downside is
very long boot time.
Accept can be parallelized to multiple CPUs to keep it manageable
(i.e. via DEFERRED_STRUCT_PAGE_INIT), but it tends to saturate
memory bandwidth and does not scale beyond the point.
2. Accept a block of memory on the first use. It requires more
infrastructure and changes in page allocator to make it work, but
it provides good boot time.
On-demand memory accept means latency spikes every time kernel steps
onto a new memory block. The spikes will go away once workload data
set size gets stabilized or all memory gets accepted.
3. Accept all memory in background. Introduce a thread (or multiple)
that gets memory accepted proactively. It will minimize time the
system experience latency spikes on memory allocation while keeping
low boot time.
This approach cannot function on its own. It is an extension of #2:
background memory acceptance requires functional scheduler, but the
page allocator may need to tap into unaccepted memory before that.
The downside of the approach is that these threads also steal CPU
cycles and memory bandwidth from the user's workload and may hurt
user experience.
Implement #1 and #2 for now. #2 is the default. Some workloads may want
to use #1 with accept_memory=eager in kernel command line. #3 can be
implemented later based on user's demands.
Support of unaccepted memory requires a few changes in core-mm code:
- memblock accepts memory on allocation. It serves early boot memory
allocations and doesn't limit them to pre-accepted pool of memory.
- page allocator accepts memory on the first allocation of the page.
When kernel runs out of accepted memory, it accepts memory until the
high watermark is reached. It helps to minimize fragmentation.
EFI code will provide two helpers if the platform supports unaccepted
memory:
- accept_memory() makes a range of physical addresses accepted.
- range_contains_unaccepted_memory() checks anything within the range
of physical addresses requires acceptance.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Acked-by: Mike Rapoport <rppt@linux.ibm.com> # memblock
Link: https://lore.kernel.org/r/20230606142637.5171-2-kirill.shutemov@linux.intel.com
Access to the files in /sys/firmware/efi/esrt has been restricted to
CAP_SYS_ADMIN since support for ESRT was added, but this seems overly
restrictive given that the files are read-only and just provide
information about UEFI firmware updates.
Remove the CAP_SYS_ADMIN restriction so that a non-root process can read
the files, provided a suitably-privileged process changes the file
ownership first. The files are still read-only and still owned by root
by default.
Signed-off-by: Nicholas Bishop <nicholasbishop@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Merge series from Andre Przywara <andre.przywara@arm.com>:
This patch series adds support for the X-Powers AXP15060 and AXP313a
PMIC, which are general purpose PMICs as seen on different boards with
different SOCs, mostly from Allwinner.
This is mostly a repost of the previous patches, combining both the
AXP313a and AXP15060 series, rebased on top of v6.4-rc3, and omitting
the patches that already got merged.
The first two patches are the successors of the AXP313a v10 post,
the third patch is based on Shengyu's AXP15060 v3 post.
There were no code changes, just some tiny context differences due to
the rebase, plus I added the newly gained tags.
As the DT bindings and the AXP15060 MFD part are already in the tree,
this is just completing support with the MFD part for the AXP313a, and
the regulator support for both PMICs.
This reverts commit b70813e4a8 ("wifi: iwlwifi: update response
for mcc_update command") since it causes a merge conflict, and it
seems easier to redo the patch later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This reverts commit 1bcbb1208e ("wifi: iwlwifi: mvm: FTM
initiator MLO support") as it causes a merge conflict, and
we can defer and re-do those changes later.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Convert x86/lib/msr.c comments to kernel-doc notation to
eliminate kernel-doc warnings:
msr.c:30: warning: This comment starts with '/**', but isn't \
a kernel-doc comment. Refer Documentation/doc-guide/kernel-doc.rst
...
Fixes: 22085a66c2 ("x86: Add another set of MSR accessor functions")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Link: https://lore.kernel.org/oe-kbuild-all/202304120048.v4uqUq9Q-lkp@intel.com/
A small collection of driver specific fixes, none of them particularly
remarkable or severe.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmR/LxwACgkQJNaLcl1U
h9DROwf+OL+WBoWbR6zVOG5xR6B70I03QNAewHOW+WWsyXAqw3im7T1H6H8rthOf
E6xKPNTMwfGceKkTVJvzZdajjEM3QYTdxAF8gNwffv2tTmXOxDmXDF8G510Up9Nh
h9CdqypfItEKRdVbN+qqX01XZpkqxWuHX1OeemR6u78gRSP4Tp5KCiQn6j/8GwRj
Zd7863hCj5uVuYQCu2bxrx1rFIgodCVeC333mnrDLvQMIRGgJeS7FGSdyrg+wLTQ
zEygY0mt5uezHt+8CyFbzHYCgmVNiM/iLBhNnkIvIzA4fhQoi4shm+S0BqGwB1VV
NgLghGlCbnGpyQpQQmEXsZZfOKvtvQ==
=pTb8
-----END PGP SIGNATURE-----
Merge tag 'spi-fix-v6.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi
Pull spi fixes from Mark Brown:
"A small collection of driver specific fixes, none of them particularly
remarkable or severe"
* tag 'spi-fix-v6.4-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi:
spi: qup: Request DMA before enabling clocks
spi: mt65xx: make sure operations completed before unloading
spi: lpspi: disable lpspi module irq in DMA mode
Running 'make dtbs_check' reports the following warning for the Jetson
Orin NX platform ...
arch/arm64/boot/dts/nvidia/tegra234-p3768-0000+p3767-0000.dtb:
usb@3550000: phy-names:1: 'usb3-0' was expected
Fix this by updating the phy-names:1 to be 'usb3-0' as expected.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Enable USB device support for the Jetson AGX Orin platform and update
the mode for the usb2-0 port to be on-the-go.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
