Add PHY2 register space to USB wrapper node. This is required
to deal with Errata i2409.
Signed-off-by: Roger Quadros <rogerq@kernel.org>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20240412-for-v6-9-am62-usb-errata-dt-v1-1-ef0d79920f75@kernel.org
Closes: https://lore.kernel.org/all/20240408095200.GA14655@francesco-nb/Signed-off-by: Nishanth Menon <nm@ti.com>

Add the required nodes to enable ICSSG SR1.0 based prueth networking.
Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Diogo Ivo <diogo.ivo@siemens.com>
Link: https://lore.kernel.org/r/20240409164314.157602-1-diogo.ivo@siemens.comSigned-off-by: Nishanth Menon <nm@ti.com>

The Audio Codec runs over the MCASP (Multichannel Audio Serial Port).

Add pinmux for the Audio Reference Clock and MCASP2.

Add DT nodes for Audio Codec, MCASP2, VCC 1v8 and VCC 3v3 regulators.

Additionally, create a sound node that connects our sound card and the
MCASP2.
Signed-off-by: Garrett Giordano <ggiordano@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240404184250.3772829-1-ggiordano@phytec.comSigned-off-by: Nishanth Menon <nm@ti.com>

The FSS bus contains several register ranges. Using an empty
ranges property works but causes a DT warning when we give
this node an address. Fix this by explicitly defining the
memory ranges in use.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326205920.40147-4-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

The FSS bus contains several register ranges. Using an empty
ranges property works but causes a DT warning when we give
this node an address. Fix this by explicitly defining the
memory ranges in use.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326205920.40147-3-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

The FSS bus contains several register ranges. Using an empty
ranges property works but causes a DT warning when we give
this node an address. Fix this by explicitly defining the
memory ranges in use.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326205920.40147-2-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

The FSS bus contains several register ranges. Using an empty
ranges property works but causes a DT warning when we give
this node an address. Fix this by explicitly defining the
memory ranges in use.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326205920.40147-1-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

These SerDes lane select muxes use bits from the same register as
the SerDes clock select mux. Make the lane select mux a child
of the SerDes control node.

This removes one more requirement on scm-conf being a syscon node
which will later be converted to fix a couple DTS check warnings.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326185627.29852-2-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

This matches the binding for this register region which fixes a couple
DTS check warnings.

While here trim the leading 0s from the "reg" definition.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326185627.29852-1-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

The J722S EVM has an on-board eMMC. Enable the SDHC interface for it.
There is no pinmuxing required because the interface has dedicated pins.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Link: https://lore.kernel.org/r/20240403102302.3934932-1-mwalle@kernel.orgSigned-off-by: Nishanth Menon <nm@ti.com>

Device tree best practice is to disable any external interface in the
dtsi and just enable them if needed in the device tree. Thus, disable
the ethernet switch and its ports by default and just enable the ones
used by the EVMs in their device trees.

There is no functional change.
Signed-off-by: Michael Walle <mwalle@kernel.org>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240403101545.3932437-1-mwalle@kernel.orgSigned-off-by: Nishanth Menon <nm@ti.com>

The phyBOARD-Electra has two TCAN1044VDD CAN transceivers which
support CAN FD at 8 Mbps.

Increase the maximum bitrate to 8 Mbps.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240402160825.1516036-3-nmorrisson@phytec.comSigned-off-by: Nishanth Menon <nm@ti.com>

The phyBOARD-Lyra has one TCAN1044VDD CAN transceiver which supports
CAN FD at 8 Mbps.

Increase the maximum bitrate to 8 Mbps.
Signed-off-by: Nathan Morrisson <nmorrisson@phytec.com>
Reviewed-by: Wadim Egorov <w.egorov@phytec.de>
Link: https://lore.kernel.org/r/20240402160825.1516036-2-nmorrisson@phytec.comSigned-off-by: Nishanth Menon <nm@ti.com>

Add a GPIO hog to release PCIe reset on the carrier board, this is
required to use M.2 or mPCIe cards.

Verdin AM62 does not have any PCIe interface, however the Verdin family
has PCIe and normally an M.2 or mPCIe slot is available in the carrier
board that can be used with cards that use only the USB interface toward
the host CPU, for example cellular network modem.
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20240327182801.5997-3-francesco@dolcini.itSigned-off-by: Nishanth Menon <nm@ti.com>

Generic GPIOs pinctrl nodes are not correct, gpio[1-4] are into the MCU
domain and should be into &mcu_gpio0, gpio[5-8] were missing and are added
in this commit.

Fixes: 7698622f ("arm64: dts: ti: Add verdin am62 mallow board")
Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20240327182801.5997-2-francesco@dolcini.itSigned-off-by: Nishanth Menon <nm@ti.com>

As described in the binding document for the "current-speed" property:

"This should only be present in case a driver has no chance to know the
baud rate of the slave device."

This is not the case for the UART used in K3 devices, the current
baud-rate can be calculated from the registers. Having this property
has the effect of actually skipping the baud-rate setup in some drivers
as it assumes it will already be set to this rate, which may not always
be the case.

It seems this property's purpose was mistaken as selecting the desired
baud-rate, which it does not. It would have been wrong to select that
here anyway as DT is not the place for configuration, especially when
there are already more standard ways to set serial baud-rates.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326185441.29656-6-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

As described in the binding document for the "current-speed" property:

"This should only be present in case a driver has no chance to know the
baud rate of the slave device."

This is not the case for the UART used in K3 devices, the current
baud-rate can be calculated from the registers. Having this property
has the effect of actually skipping the baud-rate setup in some drivers
as it assumes it will already be set to this rate, which may not always
be the case.

It seems this property's purpose was mistaken as selecting the desired
baud-rate, which it does not. It would have been wrong to select that
here anyway as DT is not the place for configuration, especially when
there are already more standard ways to set serial baud-rates.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326185441.29656-5-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

As described in the binding document for the "current-speed" property:

"This should only be present in case a driver has no chance to know the
baud rate of the slave device."

This is not the case for the UART used in K3 devices, the current
baud-rate can be calculated from the registers. Having this property
has the effect of actually skipping the baud-rate setup in some drivers
as it assumes it will already be set to this rate, which may not always
be the case.

It seems this property's purpose was mistaken as selecting the desired
baud-rate, which it does not. It would have been wrong to select that
here anyway as DT is not the place for configuration, especially when
there are already more standard ways to set serial baud-rates.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326185441.29656-4-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

As described in the binding document for the "current-speed" property:

"This should only be present in case a driver has no chance to know the
baud rate of the slave device."

This is not the case for the UART used in K3 devices, the current
baud-rate can be calculated from the registers. Having this property
has the effect of actually skipping the baud-rate setup in some drivers
as it assumes it will already be set to this rate, which may not always
be the case.

It seems this property's purpose was mistaken as selecting the desired
baud-rate, which it does not. It would have been wrong to select that
here anyway as DT is not the place for configuration, especially when
there are already more standard ways to set serial baud-rates.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326185441.29656-3-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

As described in the binding document for the "current-speed" property:

"This should only be present in case a driver has no chance to know the
baud rate of the slave device."

This is not the case for the UART used in K3 devices, the current
baud-rate can be calculated from the registers. Having this property
has the effect of actually skipping the baud-rate setup in some drivers
as it assumes it will already be set to this rate, which may not always
be the case.

It seems this property's purpose was mistaken as selecting the desired
baud-rate, which it does not. It would have been wrong to select that
here anyway as DT is not the place for configuration, especially when
there are already more standard ways to set serial baud-rates.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326185441.29656-2-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

As described in the binding document for the "current-speed" property:

"This should only be present in case a driver has no chance to know the
baud rate of the slave device."

This is not the case for the UART used in K3 devices, the current
baud-rate can be calculated from the registers. Having this property
has the effect of actually skipping the baud-rate setup in some drivers
as it assumes it will already be set to this rate, which may not always
be the case.

It seems this property's purpose was mistaken as selecting the desired
baud-rate, which it does not. It would have been wrong to select that
here anyway as DT is not the place for configuration, especially when
there are already more standard ways to set serial baud-rates.
Signed-off-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20240326185441.29656-1-afd@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

On am62-lp-sk the PMIC is not wired up to a power button. Remove this
property. This fixes issues observed when entering a very deep sleep
state that is not yet available upstream.

Fixes: e6a51ffa ("arm64: ti: dts: Add support for AM62x LP SK")
Signed-off-by: Markus Schneider-Pargmann <msp@baylibre.com>
Link: https://lore.kernel.org/r/20240325152029.2933445-1-msp@baylibre.comSigned-off-by: Nishanth Menon <nm@ti.com>

BeaglePlay SBC[1] has Texas Instrument's WL18xx WiFi chipset[2].

Currently, WLAN_EN is configured as regulator and regulator-always-on.
However, the timing and wlan_en sequencing is not correctly modelled.

This causes the sdio access to fail during runtime-pm power operations
saving or during system suspend/resume/hibernation/freeze operations.
This is because the WLAN_EN line is not deasserted to low '0' to power
down the WiFi. So during restore, the WiFi driver tries to load the FW
without following correct power sequence. WLAN_EN => '1'/assert (high)
to power-up the chipset.

Use mmc-pwrseq-simple to drive TI's WiFi (WL18xx) chipset enable
'WLAN_EN'. mmc-pwrseq-simple provides power sequence flexibility with
support for post power-on and power-off delays.

Typical log signature that indicates this bug is:
wl1271_sdio mmc2:0001:2: sdio write failed (-110)

Followed by possibly a kernel warning (depending on firmware present):
WARNING: CPU: 1 PID: 45 at drivers/net/wireless/ti/wlcore/sdio.c:123 wl12xx_sdio_raw_write+0xe4/0x168 [wlcore_sdio]

[1] https://www.beagleboard.org/boards/beagleplay
[2] https://www.ti.com/lit/ds/symlink/wl1807mod.pdf

Fixes: f5a731f0 ("arm64: dts: ti: Add k3-am625-beagleplay")
Suggested-by: Shengyu Qu <wiagn233@outlook.com>
Signed-off-by: Sukrut Bellary <sukrut.bellary@linux.com>
Tested-by: Robert Nelson <robertcnelson@gmail.com>
Link: https://lore.kernel.org/r/20240325143511.2144768-1-nm@ti.comSigned-off-by: Nishanth Menon <nm@ti.com>

TI SDHCI instance has a hardware debounce timer of 1 second as described
in commit 7ca0f166 ("mmc: sdhci_am654: Add workaround for card detect
debounce timer"), because of this the boot time increases of up to 1
second.

Workaround the issue the same way that is done on
arch/arm64/boot/dts/ti/k3-am625-beagleplay.dts, using the SD1 CD as
GPIO.
Suggested-by: Nishanth Menon <nm@ti.com>
Reported-by: João Paulo Silva Gonçalves <joao.goncalves@toradex.com>
Closes: https://lore.kernel.org/all/0e81af80de3d55e72f79af83fa5db87f5c9938f8.camel@toradex.com/Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20240325083340.89568-1-francesco@dolcini.itSigned-off-by: Nishanth Menon <nm@ti.com>

The maximum DDR RAM size stuffed on the Verdin AM62 is 2GB,
correct the memory node accordingly.

Fixes: 316b8024 ("arm64: dts: ti: add verdin am62")
Cc: <stable@vger.kernel.org>
Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20240320142937.2028707-1-max.oss.09@gmail.comSigned-off-by: Nishanth Menon <nm@ti.com>

In current configuration, wm8904 codec on Dahlia carrier board provides
distorted audio output. This happens due to reference clock is fixed to
25MHz and no FLL is enabled. During playback following parameters are set:

44100Hz:

[  310.276924] wm8904 1-001a: Target BCLK is 1411200Hz
[  310.276990] wm8904 1-001a: Using 25000000Hz MCLK
[  310.277001] wm8904 1-001a: CLK_SYS is 12500000Hz
[  310.277018] wm8904 1-001a: Selected CLK_SYS_RATIO of 256
[  310.277026] wm8904 1-001a: Selected SAMPLE_RATE of 44100Hz
[  310.277034] wm8904 1-001a: Selected BCLK_DIV of 80 for 1562500Hz BCLK
[  310.277044] wm8904 1-001a: LRCLK_RATE is 35

Deviation = 1411200 vs 1562500 = 10.721%
Also, LRCLK_RATE is 35, should be 32.

48000Hz:

[  302.449970] wm8904 1-001a: Target BCLK is 1536000Hz
[  302.450037] wm8904 1-001a: Using 25000000Hz MCLK
[  302.450049] wm8904 1-001a: CLK_SYS is 12500000Hz
[  302.450065] wm8904 1-001a: Selected CLK_SYS_RATIO of 256
[  302.450074] wm8904 1-001a: Selected SAMPLE_RATE of 48000Hz
[  302.450083] wm8904 1-001a: Selected BCLK_DIV of 80 for 1562500Hz BCLK
[  302.450092] wm8904 1-001a: LRCLK_RATE is 32

Deviation = 1536000 vs 1562500 = 1.725%

Enabling wm8904 FLL via providing mclk-fs property to simple-audio-card
configures clocks properly, but also adjusts audio reference clock
(mclk), which in case of TI AM62 should be avoided, as it only
supports 25MHz output [1][2].

This change enables FLL on wm8904 by providing mclk-fs, and drops
audio reference clock out of DAI configuration, which prevents
simple-audio-card to adjust it before every playback [3].

41000Hz:

[  111.820533] wm8904 1-001a: FLL configured for 25000000Hz->11289600Hz
[  111.820597] wm8904 1-001a: Clock source is 0 at 11289600Hz
[  111.820651] wm8904 1-001a: Using 11289600Hz FLL clock
[  111.820703] wm8904 1-001a: CLK_SYS is 11289600Hz
[  111.820798] wm8904 1-001a: Target BCLK is 1411200Hz
[  111.820847] wm8904 1-001a: Using 11289600Hz FLL clock
[  111.820894] wm8904 1-001a: CLK_SYS is 11289600Hz
[  111.820933] wm8904 1-001a: Selected CLK_SYS_RATIO of 256
[  111.820971] wm8904 1-001a: Selected SAMPLE_RATE of 44100Hz
[  111.821009] wm8904 1-001a: Selected BCLK_DIV of 80 for 1411200Hz BCLK
[  111.821051] wm8904 1-001a: LRCLK_RATE is 32

48000Hz:

[  144.119254] wm8904 1-001a: FLL configured for 25000000Hz->12288000Hz
[  144.119309] wm8904 1-001a: Clock source is 0 at 12288000Hz
[  144.119364] wm8904 1-001a: Using 12288000Hz FLL clock
[  144.119413] wm8904 1-001a: CLK_SYS is 12288000Hz
[  144.119512] wm8904 1-001a: Target BCLK is 1536000Hz
[  144.119561] wm8904 1-001a: Using 12288000Hz FLL clock
[  144.119608] wm8904 1-001a: CLK_SYS is 12288000Hz
[  144.119646] wm8904 1-001a: Selected CLK_SYS_RATIO of 256
[  144.119685] wm8904 1-001a: Selected SAMPLE_RATE of 48000Hz
[  144.119723] wm8904 1-001a: Selected BCLK_DIV of 80 for 1536000Hz BCLK
[  144.119764] wm8904 1-001a: LRCLK_RATE is 32

[1]: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1175479/processor-sdk-am62x-output-audio_ext_refclk0-as-mclk-for-codec-and-mcbsp/4444986#4444986
[2]: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1188051/am625-audio_ext_refclk1-clock-output---dts-support/4476322#4476322
[3]: sound/soc/generic/simple-card-utils.c#L441

Fixes: f5bf894c ("arm64: dts: ti: verdin-am62: dahlia: add sound card")
Suggested-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Signed-off-by: Andrejs Cainikovs <andrejs.cainikovs@toradex.com>
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Reviewed-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Link: https://lore.kernel.org/r/20240315102500.18492-1-andrejs.cainikovs@gmail.comSigned-off-by: Nishanth Menon <nm@ti.com>

The DTS code coding style expects exactly one space before '{'
character.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240208105146.128645-1-krzysztof.kozlowski@linaro.orgSigned-off-by: Nishanth Menon <nm@ti.com>

Pull EFI fixes from Ard Biesheuvel:

 - Fix logic that is supposed to prevent placement of the kernel image
   below LOAD_PHYSICAL_ADDR

 - Use the firmware stack in the EFI stub when running in mixed mode

 - Clear BSS only once when using mixed mode

 - Check efi.get_variable() function pointer for NULL before trying to
   call it

* tag 'efi-fixes-for-v6.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
  efi: fix panic in kdump kernel
  x86/efistub: Don't clear BSS twice in mixed mode
  x86/efistub: Call mixed mode boot services on the firmware's stack
  efi/libstub: fix efi_random_alloc() to allocate memory at alloc_min or higher address

Pull x86 fixes from Thomas Gleixner:

 - Ensure that the encryption mask at boot is properly propagated on
   5-level page tables, otherwise the PGD entry is incorrectly set to
   non-encrypted, which causes system crashes during boot.

 - Undo the deferred 5-level page table setup as it cannot work with
   memory encryption enabled.

 - Prevent inconsistent XFD state on CPU hotplug, where the MSR is reset
   to the default value but the cached variable is not, so subsequent
   comparisons might yield the wrong result and as a consequence the
   result prevents updating the MSR.

 - Register the local APIC address only once in the MPPARSE enumeration
   to prevent triggering the related WARN_ONs() in the APIC and topology
   code.

 - Handle the case where no APIC is found gracefully by registering a
   fake APIC in the topology code. That makes all related topology
   functions work correctly and does not affect the actual APIC driver
   code at all.

 - Don't evaluate logical IDs during early boot as the local APIC IDs
   are not yet enumerated and the invoked function returns an error
   code. Nothing requires the logical IDs before the final CPUID
   enumeration takes place, which happens after the enumeration.

 - Cure the fallout of the per CPU rework on UP which misplaced the
   copying of boot_cpu_data to per CPU data so that the final update to
   boot_cpu_data got lost which caused inconsistent state and boot
   crashes.

 - Use copy_from_kernel_nofault() in the kprobes setup as there is no
   guarantee that the address can be safely accessed.

 - Reorder struct members in struct saved_context to work around another
   kmemleak false positive

 - Remove the buggy code which tries to update the E820 kexec table for
   setup_data as that is never passed to the kexec kernel.

 - Update the resource control documentation to use the proper units.

 - Fix a Kconfig warning observed with tinyconfig

* tag 'x86-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/boot/64: Move 5-level paging global variable assignments back
  x86/boot/64: Apply encryption mask to 5-level pagetable update
  x86/cpu: Add model number for another Intel Arrow Lake mobile processor
  x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD
  Documentation/x86: Document that resctrl bandwidth control units are MiB
  x86/mpparse: Register APIC address only once
  x86/topology: Handle the !APIC case gracefully
  x86/topology: Don't evaluate logical IDs during early boot
  x86/cpu: Ensure that CPU info updates are propagated on UP
  kprobes/x86: Use copy_from_kernel_nofault() to read from unsafe address
  x86/pm: Work around false positive kmemleak report in msr_build_context()
  x86/kexec: Do not update E820 kexec table for setup_data
  x86/config: Fix warning for 'make ARCH=x86_64 tinyconfig'

Pull scheduler doc clarification from Thomas Gleixner:
 "A single update for the documentation of the base_slice_ns tunable to
  clarify that any value which is less than the tick slice has no effect
  because the scheduler tick is not guaranteed to happen within the set
  time slice"

* tag 'sched-urgent-2024-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched/doc: Update documentation for base_slice_ns and CONFIG_HZ relation

Pull dma-mapping fixes from Christoph Hellwig:
 "This has a set of swiotlb alignment fixes for sometimes very long
  standing bugs from Will. We've been discussion them for a while and
  they should be solid now"

* tag 'dma-mapping-6.9-2024-03-24' of git://git.infradead.org/users/hch/dma-mapping:
  swiotlb: Reinstate page-alignment for mappings >= PAGE_SIZE
  iommu/dma: Force swiotlb_max_mapping_size on an untrusted device
  swiotlb: Fix alignment checks when both allocation and DMA masks are present
  swiotlb: Honour dma_alloc_coherent() alignment in swiotlb_alloc()
  swiotlb: Enforce page alignment in swiotlb_alloc()
  swiotlb: Fix double-allocation of slots due to broken alignment handling

Check if get_next_variable() is actually valid pointer before
calling it. In kdump kernel this method is set to NULL that causes
panic during the kexec-ed kernel boot.

Tested with QEMU and OVMF firmware.

Fixes: bad267f9 ("efi: verify that variable services are supported")
Signed-off-by: Oleksandr Tymoshenko <ovt@google.com>
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

Clearing BSS should only be done once, at the very beginning.
efi_pe_entry() is the entrypoint from the firmware, which may not clear
BSS and so it is done explicitly. However, efi_pe_entry() is also used
as an entrypoint by the mixed mode startup code, in which case BSS will
already have been cleared, and doing it again at this point will corrupt
global variables holding the firmware's GDT/IDT and segment selectors.

So make the memset() conditional on whether the EFI stub is running in
native mode.

Fixes: b3810c5a ("x86/efistub: Clear decompressor BSS in native EFI entrypoint")
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

Normally, the EFI stub calls into the EFI boot services using the stack
that was live when the stub was entered. According to the UEFI spec,
this stack needs to be at least 128k in size - this might seem large but
all asynchronous processing and event handling in EFI runs from the same
stack and so quite a lot of space may be used in practice.

In mixed mode, the situation is a bit different: the bootloader calls
the 32-bit EFI stub entry point, which calls the decompressor's 32-bit
entry point, where the boot stack is set up, using a fixed allocation
of 16k. This stack is still in use when the EFI stub is started in
64-bit mode, and so all calls back into the EFI firmware will be using
the decompressor's limited boot stack.

Due to the placement of the boot stack right after the boot heap, any
stack overruns have gone unnoticed. However, commit

  5c4feadb0011983b ("x86/decompressor: Move global symbol references to C code")

moved the definition of the boot heap into C code, and now the boot
stack is placed right at the base of BSS, where any overruns will
corrupt the end of the .data section.

While it would be possible to work around this by increasing the size of
the boot stack, doing so would affect all x86 systems, and mixed mode
systems are a tiny (and shrinking) fraction of the x86 installed base.

So instead, record the firmware stack pointer value when entering from
the 32-bit firmware, and switch to this stack every time a EFI boot
service call is made.

Cc: <stable@kernel.org> # v6.1+
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>

Commit 63bed966 ("x86/startup_64: Defer assignment of 5-level paging
global variables") moved assignment of 5-level global variables to later
in the boot in order to avoid having to use RIP relative addressing in
order to set them. However, when running with 5-level paging and SME
active (mem_encrypt=on), the variables are needed as part of the page
table setup needed to encrypt the kernel (using pgd_none(), p4d_offset(),
etc.). Since the variables haven't been set, the page table manipulation
is done as if 4-level paging is active, causing the system to crash on
boot.

While only a subset of the assignments that were moved need to be set
early, move all of the assignments back into check_la57_support() so that
these assignments aren't spread between two locations. Instead of just
reverting the fix, this uses the new RIP_REL_REF() macro when assigning
the variables.

Fixes: 63bed966 ("x86/startup_64: Defer assignment of 5-level paging global variables")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/2ca419f4d0de719926fd82353f6751f717590a86.1711122067.git.thomas.lendacky@amd.com

When running with 5-level page tables, the kernel mapping PGD entry is
updated to point to the P4D table. The assignment uses _PAGE_TABLE_NOENC,
which, when SME is active (mem_encrypt=on), results in a page table
entry without the encryption mask set, causing the system to crash on
boot.

Change the assignment to use _PAGE_TABLE instead of _PAGE_TABLE_NOENC so
that the encryption mask is set for the PGD entry.

Fixes: 533568e0 ("x86/boot/64: Use RIP_REL_REF() to access early_top_pgt[]")
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/8f20345cda7dbba2cf748b286e1bc00816fe649a.1711122067.git.thomas.lendacky@amd.com

This one is the regular laptop CPU.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20240322161725.195614-1-tony.luck@intel.com

Commit 67236547 ("x86/fpu: Update XFD state where required") and
commit 8bf26758 ("x86/fpu: Add XFD state to fpstate") introduced a
per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in
order to avoid unnecessary writes to the MSR.

On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which
wipes out any stale state. But the per CPU cached xfd value is not
reset, which brings them out of sync.

As a consequence a subsequent xfd_update_state() might fail to update
the MSR which in turn can result in XRSTOR raising a #NM in kernel
space, which crashes the kernel.

To fix this, introduce xfd_set_state() to write xfd_state together
with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.

Fixes: 67236547 ("x86/fpu: Update XFD state where required")
Signed-off-by: Adamos Ttofari <attofari@amazon.de>
Signed-off-by: Chang S. Bae <chang.seok.bae@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20240322230439.456571-1-chang.seok.bae@intel.com

Closes: https://lore.kernel.org/lkml/20230511152818.13839-1-attofari@amazon.de

The memory bandwidth software controller uses 2^20 units rather than
10^6. See mbm_bw_count() which computes bandwidth using the "SZ_1M"
Linux define for 0x00100000.

Update the documentation to use MiB when describing this feature.
It's too late to fix the mount option "mba_MBps" as that is now an
established user interface.
Signed-off-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20240322182016.196544-1-tony.luck@intel.com