Skip to content

[26.04_linux-nvidia-bos] NVIDIA: SAUCE: usb: misc: add LSTP adapter support - #524

Draft
nirmoy wants to merge 479 commits into
NVIDIA:26.04_linux-nvidia-bosfrom
nirmoy:agent/lstp-driver-26.04-bos
Draft

[26.04_linux-nvidia-bos] NVIDIA: SAUCE: usb: misc: add LSTP adapter support#524
nirmoy wants to merge 479 commits into
NVIDIA:26.04_linux-nvidia-bosfrom
nirmoy:agent/lstp-driver-26.04-bos

Conversation

@nirmoy

@nirmoy nirmoy commented Aug 3, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Summary

  • import the LSTP USB multi-function driver from the LSTP GitLab source through main commit f662fa18e05d
  • adapt the out-of-tree source to the Linux 7.0 in-tree GPIO, I2C, allocation, and xarray APIs
  • sync the firmware-provided I2C retry policy and combined SMBus block-read fixes from the latest GitLab source
  • integrate lstp.ko under drivers/usb/misc/
  • enable CONFIG_USB_LSTP=m for amd64 and arm64 NVIDIA BOS flavours
  • enable automatic spidev creation for SPI channels without firmware-described children
  • keep separate IPMI POST-code routing disabled by default

Motivation

The temporary DKMS delivery works for image enablement, but carrying LSTP in NV-Kernels lets the normal kernel packaging and signing pipeline produce a module that supports Secure Boot.

Platform software requires the LSTP SPI channels to expose spidev children, so CONFIG_USB_LSTP_SPI_SPIDEV=y enables this behavior without a separate modprobe configuration file.

This is the 26.04_linux-nvidia-bos companion to standard-kernel PR #530.

BugLink: https://jirasw.nvidia.com/browse/DGX-17400

Source and scope

The driver is synchronized through LSTP GitLab main commit f662fa18e05d8c4b5a2b0bc83acc4e8687c9a9fb. The latest sync includes these kernel-source changes after the original c3e97053446a snapshot:

  • 4f28fdedaf85: use the firmware I2C configuration for bus retry policy
  • f662fa18e05d: fix combined userspace SMBus block reads

Out-of-tree packaging, CI, README, specification PDFs, and other repository-local files are not imported.

Device-tree schemas remain omitted because the released copies still need kernel-tree $id and maintainers normalization. They can follow with the upstream-oriented patch series; the schema-only update accompanying 4f28fdedaf85 is therefore not part of this PR.

The source exposes USB vendor ID 0x0955. The previously tested DKMS snapshot also exposed 0x0424; the LSTP owners should confirm whether that second alias is approved and required before this draft is marked ready.

Validation

  • rebased onto the current 26.04_linux-nvidia-bos tip
  • git diff --check: pass
  • latest I2C sync matches the two GitLab source deltas by normalized stable patch ID: 293704096353fd9a899984b967358332cf201272
  • scripts/checkpatch.pl --strict for the latest sync: 0 errors, 0 warnings, 0 checks
  • amd64 BOS config resolves CONFIG_USB_LSTP=m with the required USB, I2C, SPI, GPIO, LED, and TTY dependencies enabled
  • x86_64: all seven LSTP objects compile with W=1 against the PR's Linux 7.0 tree
  • arm64: LSTP compiled natively against 7.0.0-2015-nvidia-bos-64k
  • arm64 runtime: temporarily removed the DKMS shadow, confirmed modinfo -n lstp selected /lib/modules/7.0.0-2015-nvidia-bos-64k/kernel/drivers/usb/misc/lstp/lstp.ko, and ran modprobe lstp successfully
  • runtime evidence: lsmod showed lstp; dmesg recorded usbcore: registered new interface driver lstp; taint remained unchanged (12288 before and after)
  • config annotations resolve CONFIG_USB_LSTP=m and CONFIG_USB_LSTP_SPI_SPIDEV=y for amd64, arm64, and arm64-64k BOS flavours

The arm64 runtime test predates the two I2C-only sync commits. A refreshed kernel package build and I2C functional test remain required. The BOS configuration already has CONFIG_MODULE_SIG=y and CONFIG_MODULE_SIG_ALL=y; CI/package output will verify the production signature.

alucerop and others added 30 commits July 22, 2026 09:01
@alucerop @jacobmartin0
cxl: support Type2 when initializing cxl_dev_state
1617533 
BugLink: https://bugs.launchpad.net/bugs/2153819

In preparation for type2 drivers add function and macro for
differentiating CXL memory expanders (type 3) from CXL device
accelerators (type 2) helping drivers built from public headers
to embed struct cxl_dev_state inside a private struct.

Update type3 driver for using this same initialization.

Signed-off-by: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Gregory Price <gourry@gourry.net>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/20260306164741.3796372-2-alejandro.lucero-palau@amd.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
(cherry picked from commit 9a775c0)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@alucerop @jacobmartin0
cxl: export internal structs for external Type2 drivers
72fa359 
BugLink: https://bugs.launchpad.net/bugs/2153819

In preparation for type2 support, move structs and functions a type2
driver will need to access to into a new shared header file.

Differentiate between public and private data to be preserved by type2
drivers.

Signed-off-by: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Tested-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Gregory Price <gourry@gourry.net>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Link: https://patch.msgid.link/20260306164741.3796372-3-alejandro.lucero-palau@amd.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
(cherry picked from commit 0058698)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@alucerop @jacobmartin0
cxl: Move pci generic code from cxl_pci to core/cxl_pci
f285bd6 
BugLink: https://bugs.launchpad.net/bugs/2153819

Inside cxl/core/pci.c there are helpers for CXL PCIe initialization
meanwhile cxl/pci_drv.c implements the functionality for a Type3 device
initialization.

In preparation for type2 support, move helper functions from cxl/pci.c to
cxl/core/pci.c in order to be exported and used by type2 drivers.

[ dj: Clarified subject. ]

Signed-off-by: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Gregory Price <gourry@gourry.net>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Signed-off-by: Gregory Price <gourry@gourry.net>
Link: https://patch.msgid.link/20260306164741.3796372-4-alejandro.lucero-palau@amd.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
(cherry picked from commit 58f2893)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@gourry-hacks @jacobmartin0
cxl/pci: Remove redundant cxl_pci_find_port() call
07cb7e6 
BugLink: https://bugs.launchpad.net/bugs/2153819

Remove the redundant port lookup from cxl_rcrb_get_comp_regs() and use the
dport parameter directly. The caller has already validated the port is
non-NULL before invoking this function, and dport is given as a param.
This is simpler than getting dport in the callee and return the pointer
to the caller what would require more changes.

Signed-off-by: Gregory Price <gourry@gourry.net>
Reviewed-by: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Davidlohr Bueso <dave@stgolabs.net>
Link: https://patch.msgid.link/20260306164741.3796372-5-alejandro.lucero-palau@amd.com
Signed-off-by: Dave Jiang <dave.jiang@intel.com>
(cherry picked from commit d537d95)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@alucerop @jacobmartin0
NVIDIA: VR: SAUCE: sfc: add cxl support
056139d 
BugLink: https://bugs.launchpad.net/bugs/2153819

Add CXL initialization based on new CXL API for accel drivers and make
it dependent on kernel CXL configuration.

Signed-off-by: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Edward Cree <ecree.xilinx@gmail.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
(cherry picked from https://lore.kernel.org/r/20260423180528.17166-2-alejandro.lucero-palau@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@alucerop @jacobmartin0
NVIDIA: VR: SAUCE: cxl/sfc: Map cxl regs
aed169a 
BugLink: https://bugs.launchpad.net/bugs/2153819

Export cxl core functions for a Type2 driver being able to discover and
map the device registers.

Use it in sfc driver cxl initialization.

Signed-off-by: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
(backported from https://lore.kernel.org/r/20260423180528.17166-3-alejandro.lucero-palau@amd.com)
[kobak: Kept cxl_pci_setup_regs() in the core/pci provider added by the full Type2 prerequisite series and dropped the duplicate provider hunk from drivers/cxl/pci.c.]
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@alucerop @jacobmartin0
NVIDIA: VR: SAUCE: cxl/sfc: Initialize dpa without a mailbox
26b00dd 
BugLink: https://bugs.launchpad.net/bugs/2153819

Type3 relies on mailbox CXL_MBOX_OP_IDENTIFY command for initializing
memdev state params which end up being used for DPA initialization.

Allow a Type2 driver to initialize DPA simply by giving the size of its
volatile hardware partition.

Move related functions to memdev.

Add sfc driver as the client.

Signed-off-by: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
(cherry picked from https://lore.kernel.org/r/20260423180528.17166-4-alejandro.lucero-palau@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@alucerop @jacobmartin0
NVIDIA: VR: SAUCE: cxl: Prepare memdev creation for type2
bd04414 
BugLink: https://bugs.launchpad.net/bugs/2153819

Current cxl core is relying on a CXL_DEVTYPE_CLASSMEM type device when
creating a memdev leading to problems when obtaining cxl_memdev_state
references from a CXL_DEVTYPE_DEVMEM type.

Modify check for obtaining cxl_memdev_state adding CXL_DEVTYPE_DEVMEM
support.

Make devm_cxl_add_memdev accessible from an accel driver.

Signed-off-by: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
(cherry picked from https://lore.kernel.org/r/20260423180528.17166-5-alejandro.lucero-palau@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@alucerop @jacobmartin0
NVIDIA: VR: SAUCE: sfc: create type2 cxl memdev
f9adf36 
BugLink: https://bugs.launchpad.net/bugs/2153819

Use cxl API for creating a cxl memory device using the type2
cxl_dev_state struct.

Signed-off-by: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Martin Habets <habetsm.xilinx@gmail.com>
Reviewed-by: Fan Ni <fan.ni@samsung.com>
Acked-by: Edward Cree <ecree.xilinx@gmail.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
(cherry picked from https://lore.kernel.org/r/20260423180528.17166-6-alejandro.lucero-palau@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@alucerop @jacobmartin0
NVIDIA: VR: SAUCE: cxl: attach region to an accelerator/type2 memdev
ef9e0f9 
BugLink: https://bugs.launchpad.net/bugs/2153819

Support an accelerator driver to safely work with an autodiscovered
region from a committed HDM decoder through:

        1) an accelerator driver cxl_attach_region struct with attach
           and detach callbacks.

        2) a specific function, cxl_memdev_attach_region() keeping the
           required locks for finding a region linked to the memdev
           endpoint, and

        3) invoking attach callback while keeping the locking allowing to
           work (ioremap and other internal stuff) with the related physical
           range by the accelerator driver, and

        4) linking a detach callback to the endpoint device removal where
           the accelerator driver can stop using the region range.

This covers the cases of a potential removal of cxl_acpi module or a
accelerator memdev unbinding from cxl_mem driver through sysfs.

Signed-off-by: Alejandro Lucero <alucerop@amd.com>
(backported from https://lore.kernel.org/r/20260423180528.17166-7-alejandro.lucero-palau@amd.com)
[kobak: Check cxl_memdev_attach_region() errors and propagate failure so SFC probe does not continue after CXL core tears down the attached region. Set probe_data->cxl before attaching so the attach callback can use it, guard attach attempts before a valid endpoint exists, explicitly unwind attach/autoremove side effects if devres action registration fails, preserve DEVMEM target type for autodiscovered regions, and route delete / construct-failure cleanup through endpoint-owned devres actions.]
[kobak: Keep no-detach DEVMEM unregister under the endpoint-device guard so attach cannot install endpoint devres actions for a region being freed.]
[kobak: Avoid devres-registration failure cleanup under cxl_rwsem.region read lock: keep endpoint->dev locked, drop the region/DPA read guards before unregister_region(), and use devm_remove_action() so failed detach-action registration does not run cxl_endpoint_region_autoremove() under the read lock.]
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@alucerop @jacobmartin0
NVIDIA: VR: SAUCE: cxl: Avoid dax creation for accelerators
654f365 
BugLink: https://bugs.launchpad.net/bugs/2153819

By definition a type2 cxl device will use the host managed memory for
specific functionality, therefore it should not be available to other
uses like DAX.

Signed-off-by: Alejandro Lucero <alucerop@amd.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Reviewed-by: Davidlohr Bueso <daves@stgolabs.net>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Ben Cheatham <benjamin.cheatham@amd.com>
(cherry picked from https://lore.kernel.org/r/20260423180528.17166-8-alejandro.lucero-palau@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@alucerop @jacobmartin0
NVIDIA: VR: SAUCE: sfc: support pio mapping based on cxl
9119243 
BugLink: https://bugs.launchpad.net/bugs/2153819

A PIO buffer is a region of device memory to which the driver can write a
packet for TX, with the device handling the transmit doorbell without
requiring a DMA for getting the packet data, which helps reducing latency
in certain exchanges. With CXL mem protocol this latency can be lowered
further.

With a device supporting CXL and successfully initialised, use the cxl
region to map the memory range and use this mapping for PIO buffers.

Add the disabling of those CXL-based PIO buffers if the callback for
potential cxl endpoint removal by the CXL core happens.

Signed-off-by: Alejandro Lucero <alucerop@amd.com>
(backported from https://lore.kernel.org/r/20260423180528.17166-9-alejandro.lucero-palau@amd.com)
[kobak: Added a !EFX_USE_PIO same-module stub for efx_ef10_disable_piobufs() so non-x86 builds that still enable CONFIG_SFC_CXL do not leave efx_cxl.o unresolved.]
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@djbw @jacobmartin0
NVIDIA: VR: SAUCE: dax/hmem: Request cxl_acpi and cxl_pci before walk…
7e38ecb 
…ing Soft Reserved ranges

BugLink: https://bugs.launchpad.net/bugs/2153819

Ensure cxl_acpi has published CXL Window resources before HMEM walks Soft
Reserved ranges.

Replace MODULE_SOFTDEP("pre: cxl_acpi") with an explicit, synchronous
request_module("cxl_acpi"). MODULE_SOFTDEP() only guarantees eventual
loading, it does not enforce that the dependency has finished init
before the current module runs. This can cause HMEM to start before
cxl_acpi has populated the resource tree, breaking detection of overlaps
between Soft Reserved and CXL Windows.

Also, request cxl_pci before HMEM walks Soft Reserved ranges. Unlike
cxl_acpi, cxl_pci attach is asynchronous and creates dependent devices
that trigger further module loads. Asynchronous probe flushing
(wait_for_device_probe()) is added later in the series in a deferred
context before HMEM makes ownership decisions for Soft Reserved ranges.

Add an additional explicit Kconfig ordering so that CXL_ACPI and CXL_PCI
must be initialized before DEV_DAX_HMEM. This prevents HMEM from consuming
Soft Reserved ranges before CXL drivers have had a chance to claim them.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Tested-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
Link: https://lore.kernel.org/r/20260210064501.157591-2-Smita.KoralahalliChannabasappa@amd.com
(cherry picked from https://lore.kernel.org/r/20260210064501.157591-2-Smita.KoralahalliChannabasappa@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@djbw @jacobmartin0
NVIDIA: VR: SAUCE: dax/hmem: Gate Soft Reserved deferral on DEV_DAX_CXL
a5ab482 
BugLink: https://bugs.launchpad.net/bugs/2153819

Replace IS_ENABLED(CONFIG_CXL_REGION) with IS_ENABLED(CONFIG_DEV_DAX_CXL)
so that HMEM only defers Soft Reserved ranges when CXL DAX support is
enabled. This makes the coordination between HMEM and the CXL stack more
precise and prevents deferral in unrelated CXL configurations.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Alison Schofield <alison.schofield@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Tested-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
Link: https://lore.kernel.org/r/20260210064501.157591-3-Smita.KoralahalliChannabasappa@amd.com
(cherry picked from https://lore.kernel.org/r/20260210064501.157591-3-Smita.KoralahalliChannabasappa@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@skoralah @jacobmartin0
NVIDIA: VR: SAUCE: cxl/region: Skip decoder reset on detach for autod…
4191216 
…iscovered regions

BugLink: https://bugs.launchpad.net/bugs/2153819

__cxl_decoder_detach() currently resets decoder programming whenever a
region is detached if cxl_config_state is beyond CXL_CONFIG_ACTIVE. For
autodiscovered regions, this can incorrectly tear down decoder state
that may be relied upon by other consumers or by subsequent ownership
decisions.

Skip cxl_region_decode_reset() during detach when CXL_REGION_F_AUTO is
set.

Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Alejandro Lucero <alucerop@amd.com>
Tested-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
Link: https://lore.kernel.org/r/20260210064501.157591-4-Smita.KoralahalliChannabasappa@amd.com
(cherry picked from https://lore.kernel.org/r/20260210064501.157591-4-Smita.KoralahalliChannabasappa@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@djbw @jacobmartin0
NVIDIA: VR: SAUCE: dax/cxl, hmem: Initialize hmem early and defer dax…
84804e3 
…_cxl binding

BugLink: https://bugs.launchpad.net/bugs/2153819

Move hmem/ earlier in the dax Makefile so that hmem_init() runs before
dax_cxl.

In addition, defer registration of the dax_cxl driver to a workqueue
instead of using module_cxl_driver(). This ensures that dax_hmem has
an opportunity to initialize and register its deferred callback and make
ownership decisions before dax_cxl begins probing and claiming Soft
Reserved ranges.

Mark the dax_cxl driver as PROBE_PREFER_ASYNCHRONOUS so its probe runs
out of line from other synchronous probing avoiding ordering
dependencies while coordinating ownership decisions with dax_hmem.

Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Tested-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
Link: https://lore.kernel.org/r/20260210064501.157591-5-Smita.KoralahalliChannabasappa@amd.com
(cherry picked from https://lore.kernel.org/r/20260210064501.157591-5-Smita.KoralahalliChannabasappa@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@skoralah @jacobmartin0
NVIDIA: VR: SAUCE: dax: Track all dax_region allocations under a glob…
99a11d0 
…al resource tree

BugLink: https://bugs.launchpad.net/bugs/2153819

Introduce a global "DAX Regions" resource root and register each
dax_region->res under it via request_resource(). Release the resource on
dax_region teardown.

By enforcing a single global namespace for dax_region allocations, this
ensures only one of dax_hmem or dax_cxl can successfully register a
dax_region for a given range.

Co-developed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Tested-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
Link: https://lore.kernel.org/r/20260210064501.157591-6-Smita.KoralahalliChannabasappa@amd.com
(cherry picked from https://lore.kernel.org/r/20260210064501.157591-6-Smita.KoralahalliChannabasappa@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@skoralah @jacobmartin0
NVIDIA: VR: SAUCE: cxl/region: Add helper to check Soft Reserved cont…
477935b 
…ainment by CXL regions

BugLink: https://bugs.launchpad.net/bugs/2153819

Add a helper to determine whether a given Soft Reserved memory range is
fully contained within the committed CXL region.

This helper provides a primitive for policy decisions in subsequent
patches such as co-ordination with dax_hmem to determine whether CXL has
fully claimed ownership of Soft Reserved memory ranges.

Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
Link: https://lore.kernel.org/r/20260210064501.157591-7-Smita.KoralahalliChannabasappa@amd.com
(backported from https://lore.kernel.org/r/20260210064501.157591-7-Smita.KoralahalliChannabasappa@amd.com)
[kobak: Added the Soft Reserved declaration to the existing Type2 include/cxl/cxl.h header instead of recreating that header.]
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@skoralah @jacobmartin0
NVIDIA: VR: SAUCE: dax: Add deferred-work helpers for dax_hmem and da…
d8af1a7 
…x_cxl coordination

BugLink: https://bugs.launchpad.net/bugs/2153819

Add helpers to register, queue and flush the deferred work.

These helpers allow dax_hmem to execute ownership resolution outside the
probe context before dax_cxl binds.

Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Tested-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
Link: https://lore.kernel.org/r/20260210064501.157591-8-Smita.KoralahalliChannabasappa@amd.com
(cherry picked from https://lore.kernel.org/r/20260210064501.157591-8-Smita.KoralahalliChannabasappa@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@skoralah @jacobmartin0
NVIDIA: VR: SAUCE: dax/hmem, cxl: Defer and resolve ownership of Soft…
44d9aee 
… Reserved memory ranges

BugLink: https://bugs.launchpad.net/bugs/2153819

The current probe time ownership check for Soft Reserved memory based
solely on CXL window intersection is insufficient. dax_hmem probing is not
always guaranteed to run after CXL enumeration and region assembly, which
can lead to incorrect ownership decisions before the CXL stack has
finished publishing windows and assembling committed regions.

Introduce deferred ownership handling for Soft Reserved ranges that
intersect CXL windows. When such a range is encountered during dax_hmem
probe, schedule deferred work and wait for the CXL stack to complete
enumeration and region assembly before deciding ownership.

Evaluate ownership of Soft Reserved ranges based on CXL region
containment.

   - If all Soft Reserved ranges are fully contained within committed CXL
     regions, DROP handling Soft Reserved ranges from dax_hmem and allow
     dax_cxl to bind.

   - If any Soft Reserved range is not fully claimed by committed CXL
     region, REGISTER the Soft Reserved ranges with dax_hmem.

Use dax_cxl_mode to coordinate ownership decisions for Soft Reserved
ranges. Once, ownership resolution is complete, flush the deferred work
from dax_cxl before allowing dax_cxl to bind.

This enforces a strict ownership. Either CXL fully claims the Soft
reserved ranges or it relinquishes it entirely.

Co-developed-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Tested-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
Link: https://lore.kernel.org/r/20260210064501.157591-9-Smita.KoralahalliChannabasappa@amd.com
(cherry picked from https://lore.kernel.org/r/20260210064501.157591-9-Smita.KoralahalliChannabasappa@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@skoralah @jacobmartin0
NVIDIA: VR: SAUCE: dax/hmem: Reintroduce Soft Reserved ranges back in…
380f826 
…to the iomem tree

BugLink: https://bugs.launchpad.net/bugs/2153819

Reworked from a patch by Alison Schofield <alison.schofield@intel.com>

Reintroduce Soft Reserved range into the iomem_resource tree for HMEM
to consume.

This restores visibility in /proc/iomem for ranges actively in use, while
avoiding the early-boot conflicts that occurred when Soft Reserved was
published into iomem before CXL window and region discovery.

Link: https://lore.kernel.org/linux-cxl/29312c0765224ae76862d59a17748c8188fb95f1.1692638817.git.alison.schofield@intel.com/
Co-developed-by: Alison Schofield <alison.schofield@intel.com>
Signed-off-by: Alison Schofield <alison.schofield@intel.com>
Co-developed-by: Zhijian Li <lizhijian@fujitsu.com>
Signed-off-by: Zhijian Li <lizhijian@fujitsu.com>
Signed-off-by: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
Tested-by: Tomasz Wolski <tomasz.wolski@fujitsu.com>
Link: https://lore.kernel.org/r/20260210064501.157591-10-Smita.KoralahalliChannabasappa@amd.com
(cherry picked from https://lore.kernel.org/r/20260210064501.157591-10-Smita.KoralahalliChannabasappa@amd.com)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
Robert Richter @jacobmartin0
NVIDIA: VR: SAUCE: cxl/region: Support multi-level interleaving with …
e774a2d 
…smaller granularities for lower levels

BugLink: https://bugs.launchpad.net/bugs/2153819

The CXL specification supports multi-level interleaving "as long as
all the levels use different, but consecutive, HPA bits to select the
target and no Interleave Set has more than 8 devices" (from 3.2).

Currently the kernel expects that a decoder's "interleave granularity
is a multiple of @parent_port granularity". That is, the granularity
of a lower level is bigger than those of the parent and uses the outer
HPA bits as selector. It works e.g. for the following 8-way config:

 * cross-link (cross-hostbridge config in CFMWS):
   * 4-way
   * 256 granularity
   * Selector: HPA[8:9]
 * sub-link (CXL Host bridge config of the HDM):
   * 2-way
   * 1024 granularity
   * Selector: HPA[10]

Now, if the outer HPA bits are used for the cross-hostbridge, an 8-way
config could look like this:

 * cross-link (cross-hostbridge config in CFMWS):
   * 4-way
   * 512 granularity
   * Selector: HPA[9:10]
 * sub-link (CXL Host bridge config of the HDM):
   * 2-way
   * 256 granularity
   * Selector: HPA[8]

The enumeration of decoders for this configuration fails then with
following error:

 cxl region0: pci0000:00:port1 cxl_port_setup_targets expected iw: 2 ig: 1024 [mem 0x10000000000-0x1ffffffffff flags 0x200]
 cxl region0: pci0000:00:port1 cxl_port_setup_targets got iw: 2 ig: 256 state: enabled 0x10000000000:0x1ffffffffff
 cxl_port endpoint12: failed to attach decoder12.0 to region0: -6

Note that this happens only if firmware is setting up the decoders
(CXL_REGION_F_AUTO). For userspace region assembly the granularities
are chosen to increase from root down to the lower levels. That is,
outer HPA bits are always used for lower interleaving levels.

Rework the implementation to also support multi-level interleaving
with smaller granularities for lower levels. Determine the interleave
set of autodetected decoders. Check that it is a subset of the root
interleave.

The HPA selector bits are extracted for all decoders of the set and
checked that there is no overlap and bits are consecutive. All
decoders can be programmed now to use any bit range within the
region's target selector.

Signed-off-by: Robert Richter <rrichter@amd.com>
(backported from https://lore.kernel.org/all/20251028094754.72816-1-rrichter@amd.com/)
[kobak: resolved conflicts with cxlr->cxlrd and spa_maps_hpa()]
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@JiandiAnNVIDIA @jacobmartin0
NVIDIA: VR: SAUCE: [Config] CXL config annotations for Type-2 device …
ecc92b7 
…and RAS support

BugLink: https://bugs.launchpad.net/bugs/2153819
BugLink: https://bugs.launchpad.net/bugs/2143032

Source: NVIDIA@f80636d

Add Ubuntu kernel config annotations for CXL-related configs introduced
or changed by the CXL Type-2, RAS, and autodiscovered-region support
backports.

CONFIG_CXL_BUS, CONFIG_CXL_PCI, CONFIG_CXL_MEM, and CONFIG_CXL_PORT are
built in for Type-2 device support. CONFIG_CXL_RAS and the EINJ symbols
cover CXL RAS/error-injection support. CONFIG_SFC_CXL remains disabled
for NVIDIA platforms.

Signed-off-by: Jiandi An <jan@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
(backported from commit f80636d nv-kernels/24.04_linux-nvidia-6.17-next)
[kobak: Backported annotation overrides from debian.nvidia-6.17 to debian.nvidia-bos; PCIEAER_CXL is overridden as removed instead of editing debian.master.]
Signed-off-by: Koba Ko <kobak@nvidia.com>
@JiandiAnNVIDIA @jacobmartin0
NVIDIA: VR: SAUCE: [Config] Enable CXL DAX and KMEM built-in for CXL …
9f76671 
…memory access

BugLink: https://bugs.launchpad.net/bugs/2153819
BugLink: https://bugs.launchpad.net/bugs/2143032

Source: NVIDIA@c5c11cf

Override debian.master policy for DEV_DAX, DEV_DAX_CXL, and
DEV_DAX_KMEM so CXL memory regions are available as raw DAX devices and
as hotplugged System-RAM without relying on module load ordering.

Signed-off-by: Jiandi An <jan@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
(backported from commit c5c11cf nv-kernels/24.04_linux-nvidia-6.17-next)
[kobak: Backported annotation overrides from debian.nvidia-6.17 to debian.nvidia-bos.]
Signed-off-by: Koba Ko <kobak@nvidia.com>
@JiandiAnNVIDIA @jacobmartin0
NVIDIA: VR: SAUCE: [Config] Add PCI_CXL annotation for CXL state save…
30e4f67 
…/restore

BugLink: https://bugs.launchpad.net/bugs/2153819
BugLink: https://bugs.launchpad.net/bugs/2143032

Source: NVIDIA@a5544cb

Add Ubuntu kernel config annotation for CONFIG_PCI_CXL introduced by
the CXL DVSEC and HDM state save/restore series.

CONFIG_PCI_CXL is a hidden bool auto-enabled when CXL_BUS=y. It gates
compilation of drivers/pci/cxl.o, which saves and restores CXL DVSEC
control/range registers and HDM decoder state across PCI resets and
link transitions.

Signed-off-by: Jiandi An <jan@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
(backported from commit a5544cb nv-kernels/24.04_linux-nvidia-6.17-next)
[kobak: Backported annotation override from debian.nvidia-6.17 to debian.nvidia-bos.]
Signed-off-by: Koba Ko <kobak@nvidia.com>
@kobak2026 @jacobmartin0
NVIDIA: SAUCE: Revert "NVIDIA: VR: SAUCE: cxl: add support for cxl re…
a491194 
…set"

BugLink: https://bugs.launchpad.net/bugs/2153819

This reverts commit 4f089d9.

Drop the older monolithic CXL reset method before applying the refreshed
save/restore and reset series.

Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@sriranganm @jacobmartin0
NVIDIA: VR: SAUCE: PCI: Add CXL DVSEC control, lock, and range regist…
48e0b8a 
…er definitions

BugLink: https://bugs.launchpad.net/bugs/2153819
BugLink: https://bugs.launchpad.net/bugs/2143032

PCI: Add CXL DVSEC control, lock, and range register definitions

Add register offset and field definitions for CXL DVSEC registers needed
by CXL state save/restore across resets:

  - CTRL2 (offset 0x10) and LOCK (offset 0x14) registers
  - CONFIG_LOCK bit in the LOCK register
  - RWL (read-write-when-locked) field masks for CTRL and range base
    registers.

Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
(cherry picked from https://lore.kernel.org/linux-cxl/20260306080026.116789-1-smadhavan@nvidia.com/)
Signed-off-by: Jiandi An <jan@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
(cherry picked from commit 07ad5f1 nv-kernels/24.04_linux-nvidia-6.17-next)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
@sriranganm @jacobmartin0
NVIDIA: VR: SAUCE: cxl: Move HDM decoder and register map definitions…
9a100ac 
… to include/cxl/cxl.h

BugLink: https://bugs.launchpad.net/bugs/2153819
BugLink: https://bugs.launchpad.net/bugs/2143032

Move CXL HDM decoder register defines, register map structs
(cxl_reg_map, cxl_component_reg_map, cxl_device_reg_map,
cxl_pmu_reg_map, cxl_register_map), cxl_hdm_decoder_count(),
enum cxl_regloc_type, and cxl_find_regblock()/cxl_setup_regs()
declarations from internal CXL headers to include/cxl/pci.h.

This makes them accessible to code outside the CXL subsystem, in
particular the PCI core CXL state save/restore support added in a
subsequent patch.

No functional change.

Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
(backported from https://lore.kernel.org/linux-cxl/20260306080026.116789-1-smadhavan@nvidia.com/)
Signed-off-by: Jiandi An <jan@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
(backported from commit b5e166c nv-kernels/24.04_linux-nvidia-6.17-next)
[koba: Also move CXL_CM_CAP_CAP_ID_RAS, CXL_CM_CAP_CAP_ID_HDM, and CXL_CM_CAP_CAP_HDM_VERSION into public include/cxl/cxl.h to keep the public CXL header layout consistent.]
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
@sriranganm @jacobmartin0
NVIDIA: VR: SAUCE: PCI: Add virtual extended cap save buffer for CXL …
f4352fb 
…state

BugLink: https://bugs.launchpad.net/bugs/2153819
BugLink: https://bugs.launchpad.net/bugs/2143032

Add pci_add_virtual_ext_cap_save_buffer() to allocate save buffers
using virtual cap IDs (above PCI_EXT_CAP_ID_MAX) that don't require
a real capability in config space.

The existing pci_add_ext_cap_save_buffer() cannot be used for
CXL DVSEC state because it calls pci_find_saved_ext_cap()
which searches for a matching capability in PCI config space.
The CXL state saved here is a synthetic snapshot (DVSEC+HDM)
and should not be tied to a real extended-cap instance. A
virtual extended-cap save buffer API (cap IDs above
PCI_EXT_CAP_ID_MAX) allows PCI to track this state without
a backing config space capability.

Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
(cherry picked from https://lore.kernel.org/linux-cxl/20260306080026.116789-1-smadhavan@nvidia.com/)
Signed-off-by: Jiandi An <jan@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
(cherry picked from commit b3a768f nv-kernels/24.04_linux-nvidia-6.17-next)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
@sriranganm @jacobmartin0
NVIDIA: VR: SAUCE: PCI: Add cxl DVSEC state save/restore across resets
608c2f9 
BugLink: https://bugs.launchpad.net/bugs/2153819
BugLink: https://bugs.launchpad.net/bugs/2143032

Save and restore CXL DVSEC control registers (CTRL, CTRL2), range
base registers, and lock state across PCI resets.

When the DVSEC CONFIG_LOCK bit is set, certain DVSEC fields
become read-only and hardware may have updated them. Blindly
restoring saved values would be silently ignored or conflict
with hardware state. Instead, a read-merge-write approach is
used: current hardware values are read for the RWL
(read-write-when-locked) fields and merged with saved state,
so only writable bits are restored while locked bits retain
their hardware values.

Hooked into pci_save_state()/pci_restore_state() so all PCI reset
paths automatically preserve CXL DVSEC configuration.

Signed-off-by: Srirangan Madhavan <smadhavan@nvidia.com>
(cherry picked from https://lore.kernel.org/linux-cxl/20260306080026.116789-1-smadhavan@nvidia.com/)
[jan: Resolve minor conflict in drivers/pci/Makefile due to code line shifts ]
Signed-off-by: Jiandi An <jan@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
(cherry picked from commit 0bb0dc0 nv-kernels/24.04_linux-nvidia-6.17-next)
Signed-off-by: Koba Ko <kobak@nvidia.com>
Acked-by: Matt Ochs <mochs@nvidia.com>
shankerd04 and others added 3 commits July 29, 2026 09:40
@shankerd04 @nvidia-bfigg
arm64: errata: work around NVIDIA Olympus device store/load ordering
7664e84 
BugLink: https://bugs.launchpad.net/bugs/2162028

On systems with NVIDIA Olympus cores, a Device-nGnR* load can be
observed by a peripheral before an older, non-overlapping Device-nGnR*
store to the same peripheral. This breaks the program-order guarantee
that software expects for Device-nGnR* accesses and can leave a
peripheral in an incorrect state.

The erratum can occur only when all of the following apply:

  - A PE executes a Device-nGnR* store followed by a younger
    Device-nGnR* load.
  - The store is not a store-release.
  - The accesses target the same peripheral and do not overlap in bytes.
  - There is at most one intervening Device-nGnR* store in program
    order, and there are no intervening Device-nGnR* loads.
  - There is no DSB or full DMB between the store and the load.
  - Specific microarchitectural and timing conditions occur.

Insert a DMB OSH immediately before each raw MMIO load on affected CPUs.
As a full barrier, DMB OSH orders the older Device store before the
younger Device load and prevents the erroneous observation.

Add the barrier directly to the __raw_read*() helpers, independently of
the existing device-load-acquire alternative. On affected CPUs this adds
one DMB OSH per raw MMIO load, including each load used by
memcpy_fromio(). On unaffected CPUs the alternative remains a NOP.

Co-developed-by: Vikram Sethi <vsethi@nvidia.com>
Signed-off-by: Vikram Sethi <vsethi@nvidia.com>
Signed-off-by: Shanker Donthineni <sdonthineni@nvidia.com>
Link: https://lore.kernel.org/all/akPQ8F3OgER621UP@willie-the-truck/
Reviewed-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Will Deacon <will@kernel.org>
(cherry picked from commit 12aab25 linux-next)
[csoto: fixup in cpucaps due to missing WORKAROUND_DISABLE_CNP
and carrying ARM64_WORKAROUND_NC_TO_NGNRE]
Signed-off-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@clsotog @nvidia-bfigg
NVIDIA: [Config] Enable ARM64_WORKAROUND_NVIDIA_OLYMPUS_1027
a383ef5 
BugLink: https://bugs.launchpad.net/bugs/2162028

Enable ARM64_WORKAROUND_NVIDIA_OLYMPUS_1027=y.

Signed-off-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@nirmoy @nvidia-bfigg
selftests: tls: size splice_short pipe by page size
55fde6a 
BugLink: https://bugs.launchpad.net/bugs/2161746

splice_short grows its pipe with (MAX_FRAGS + 1) * 0x1000 so it can
queue one short vmsplice() buffer for each fragment before draining the
pipe. That assumes 4K pipe buffers.

On 64K-page kernels the request is rounded to 262144 bytes, which
provides only four pipe buffers. The fifth one-byte vmsplice() blocks in
pipe_wait_writable and the test times out before it reaches the TLS path.

Request enough bytes for the same number of pipe buffers using the
runtime page size, and assert that the kernel granted at least that much.
If an unprivileged run cannot raise the pipe above the system
pipe-max-size limit, skip the test because it cannot exercise the
intended path.

Fixes: 3667e9b ("selftests: tls: add test for short splice due to full skmsg")
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Link: https://patch.msgid.link/20260624134416.3235403-1-nirmoyd@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
(cherry picked from commit 3e52f56)
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
Acked-by: Matthew R. Ochs <mochs@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@nirmoy
nirmoy force-pushed the agent/lstp-driver-26.04-bos branch 3 times, most recently from fdb866d to 266c382 Compare August 3, 2026 15:22
@github-actions

github-actions Bot commented Aug 3, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

PR Validation Report

Patchscan ✅ No Missing Fixes

All cherry-picked commits checked — no missing upstream fixes found.

PR Lint ❌ Errors found

Details 
Checking 9 commits...

Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 3c4975e4550f │ [SAUCE] usb: lstp: roll back failed spi startup                  │ N/A        │ N/A     │ nirmoyd                   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 935813563a09 │ [SAUCE] usb: lstp: skip zero-length mmio commands                │ N/A        │ N/A     │ nirmoyd                   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 3522af643d28 │ [SAUCE] usb: lstp: preserve unread ipmi requests                 │ N/A        │ N/A     │ nirmoyd                   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 65f9ea83cb08 │ [SAUCE] usb: lstp: recover chip select after errors              │ N/A        │ N/A     │ nirmoyd                   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ fd3afe6cd4be │ [SAUCE] usb: lstp: auto-bind empty spi firmware nodes            │ N/A        │ N/A     │ nirmoyd                   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 8ea1f1537bda │ [SAUCE] usb: lstp: advertise fixed spi settings                  │ N/A        │ N/A     │ nirmoyd                   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 72fb4bee457d │ [SAUCE] usb: lstp: bind auto-created spi devices                 │ N/A        │ N/A     │ nirmoyd                   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b9d70b230046 │ [SAUCE] [config] enable usb_lstp as a module                     │ N/A        │ N/A     │ nirmoyd                   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 44b2a45a733e │ [SAUCE] usb: misc: add lstp adapter support                      │ N/A        │ N/A     │ aambroze, nirmoyd         │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint: all checks passed.

PR metadata:
E: PR targets 26.04_linux-nvidia-bos but body has no https://bugs.launchpad.net/... link

@nirmoy
nirmoy force-pushed the agent/lstp-driver-26.04-bos branch 2 times, most recently from 01fb73b to 5d52b11 Compare August 3, 2026 15:40
@nirmoy nirmoy changed the title NVIDIA: SAUCE: Add LSTP USB driver [26.04_linux-nvidia-bos] NVIDIA: SAUCE: usb: misc: add LSTP adapter support Aug 3, 2026
@nirmoy
nirmoy force-pushed the agent/lstp-driver-26.04-bos branch 2 times, most recently from c8318a3 to c342480 Compare August 3, 2026 18:14
@nirmoy

nirmoy commented Aug 3, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

BaseOS Kernel Review

Summary

LSTP has false-success UART writes after repeated NACKs, a poll race that can hide pending IPMI requests, and incomplete SPI-child rollback that leaves unusable devices exposed.

Findings: Critical: 0, High: 0, Medium: 5, Low: 2

Latest watcher review: open review

Generated test plan: open test plan

Kernel deb build: successful (download debs, 4 files)

Head: 3c4975e4550f

This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review.

@nirmoy
nirmoy force-pushed the agent/lstp-driver-26.04-bos branch from c342480 to 5e908e6 Compare August 3, 2026 18:58
@kbutala-nv @nvidia-bfigg
ASoC: rt1320-sdw: Add settings to support more base clock frequency
1b8c581 
BugLink: https://bugs.launchpad.net/bugs/2162767

Add settings to support more base clock frequency on different platform.

Signed-off-by: Jack Yu <jack.yu@realtek.com>
Link: https://patch.msgid.link/20260716061536.1563252-1-jack.yu@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
(backported from commit ef9c8eb307046afa797befd84e6c741cd8954dfc sound.git)
Signed-off-by: Kaushal Rajeev Butala <kbutala@nvidia.com>
Acked-by: Carol L Soto <csoto@nvidia.com>
Acked-by: Jamie Nguyen <jamien@nvidia.com>
Acked-by: Nirmoy Das <nirmoyd@nvidia.com>
Signed-off-by: Brad Figg <bfigg@nvidia.com>
@nirmoy
nirmoy force-pushed the agent/lstp-driver-26.04-bos branch 2 times, most recently from 96b683a to f4cb906 Compare August 5, 2026 08:43
@nirmoy nirmoy mentioned this pull request Aug 5, 2026
Draft
@aambroze @nirmoy
NVIDIA: SAUCE: usb: misc: add LSTP adapter support
44b2a45 
The Low-Speed Transport Protocol (LSTP) adapter exposes
firmware-configured I2C, SPI, GPIO, UART, IPMI, and MMIO channels over a
single USB interface.

Add the driver as a downstream patch and integrate it with Kconfig,
Kbuild, and MAINTAINERS. Adapt the GPIO, I2C, memory-allocation, and
UART interfaces to the APIs available in this kernel.

Use the configured I2C retry count and avoid a spurious zero-length
write before a userspace SMBus block read.

(backported from
 https://gitlab-master.nvidia.com/spt-firmware-taskforce/lstp/lstp_module)

Signed-off-by: Adrian Ambrozewicz <aambrozewicz@nvidia.com>
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
@nirmoy
nirmoy force-pushed the agent/lstp-driver-26.04-bos branch from f4cb906 to 0d63a60 Compare August 5, 2026 11:27
@nirmoy
NVIDIA: SAUCE: [Config] Enable USB_LSTP as a module
b9d70b2 
Enable CONFIG_USB_LSTP=m for the amd64 and arm64 NVIDIA BOS flavours.
Building lstp.ko through the kernel packaging pipeline also allows the
module to be signed for Secure Boot.

Enable CONFIG_USB_LSTP_SPI_SPIDEV so auto_bind_spidev defaults to true
and LSTP SPI channels without firmware-described children create
spidev devices. Keep separate IPMI POST-code routing disabled.

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
@nirmoy
nirmoy force-pushed the agent/lstp-driver-26.04-bos branch from 0d63a60 to b9d70b2 Compare August 5, 2026 15:34
nirmoy added 7 commits August 5, 2026 11:08
@nirmoy
NVIDIA: SAUCE: usb: lstp: bind auto-created SPI devices
72fb4be 
The generic spidev modalias is not present in the spidev device ID table,
so dynamically created LSTP SPI devices remain unbound.

Load spidev before creating the devices and set its name as a driver
override before registration. Fail channel startup if a child cannot
be created or bound.

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
@nirmoy
NVIDIA: SAUCE: usb: lstp: advertise fixed SPI settings
8ea1f15 
LSTP firmware supplies one clock rate for each SPI channel and supports
only 8-bit words, but the controller currently accepts other settings
and silently ignores them during transfers.

Publish the firmware rate as both the minimum and maximum controller
speed and restrict the word-size mask to 8 bits so the SPI core rejects
unsupported requests.

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
@nirmoy
NVIDIA: SAUCE: usb: lstp: auto-bind empty SPI firmware nodes
fd3afe6 
A channel fwnode may be present without describing any available
SPI child devices. Treat that case like a missing fwnode so the
auto_bind_spidev option creates the fallback devices it promises.

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
@nirmoy
NVIDIA: SAUCE: usb: lstp: recover chip select after errors
65f9ea8 
A failed transfer can leave chip select asserted in the adapter. Send a
best-effort zero-length write with the deassert flag before completing
the failed message, while preserving the original transfer error.

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
@nirmoy
NVIDIA: SAUCE: usb: lstp: preserve unread IPMI requests
3522af6 
Removing a FIFO record before checking the userspace buffer loses the
request on a short read or copy fault. Serialize readers and retain
one dequeued record until copy_to_user() succeeds.

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
@nirmoy
NVIDIA: SAUCE: usb: lstp: skip zero-length MMIO commands
9358135 
Zero-length read and write calls must complete without issuing hardware
operations. Return immediately after validating the file offset instead
of sending empty LSTP commands.

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
@nirmoy
NVIDIA: SAUCE: usb: lstp: roll back failed SPI startup
3c4975e 
Channel startup failures do not abort USB probe. If fallback spidev
creation fails after controller registration, the controller and any
children created before the failure otherwise remain registered.

Group controller registration and child creation under devres so the
complete SPI channel is rolled back on an error.

Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
@nvidia-bfigg
nvidia-bfigg force-pushed the 26.04_linux-nvidia-bos branch from 9ef5052 to ab2723a Compare August 14, 2026 12:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.