From: Timur Tabi ttabi@nvidia.com
[ Upstream commit 27738c3003bf3b124527c9ed75e1e0d0c013c101 ]
Always set the RMDevidCheckIgnore registry key for GSP-RM so that it will continue support newer variants of already supported GPUs.
GSP-RM maintains an internal list of PCI IDs of GPUs that it supports, and checks if the current GPU is on this list. While the actual GPU architecture (as specified in the BOOT_0/BOOT_42 registers) determines how to enable the GPU, the PCI ID is used for the product name, e.g. "NVIDIA GeForce RTX 5090".
Unfortunately, if there is no match, GSP-RM will refuse to initialize, even if the device is fully supported. Nouveau will get an error return code, but by then it's too late. This behavior may be corrected in a future version of GSP-RM, but that does not help Nouveau today.
Fortunately, GSP-RM supports an undocumented registry key that tells it to ignore the mismatch. In such cases, the product name returned will be a blank string, but otherwise GSP-RM will continue.
Unlike Nvidia's proprietary driver, Nouveau cannot update to newer firmware versions to keep up with every new hardware release. Instead, we can permanently set this registry key, and GSP-RM will continue to function the same with known hardware.
Signed-off-by: Timur Tabi ttabi@nvidia.com Link: https://lore.kernel.org/r/20250808191340.1701983-1-ttabi@nvidia.com Signed-off-by: Danilo Krummrich dakr@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
- What changed - Adds `"RMDevidCheckIgnore" = 1` to the always-applied GSP-RM registry entries array `r535_registry_entries` so the key is sent unconditionally to the GSP-RM firmware during bring-up: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c:586 - These entries are appended into the registry payload by the loop in `r535_gsp_rpc_set_registry()`: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c:639 - The registry is pushed early in device initialization from `r535_gsp_oneinit()`: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c:2185
- Why it matters - GSP-RM internally gates initialization on a PCI ID → product-name table, refusing to initialize if there’s no match, even when the GPU architecture is fully supported. This causes a hard failure on newly released PCI ID variants of already supported architectures. - The undocumented `RMDevidCheckIgnore` flag tells GSP-RM to ignore the PCI ID table mismatch: initialization proceeds, but the product name is blank. The driver does not rely on the RM-provided product string for functionality. - Nouveau cannot “chase” new PCI IDs via frequent firmware updates in stable kernels; always setting this flag ensures supported architectures remain usable as new board IDs are released.
- Scope and containment - The change is a single, small addition to a constant array of required registry entries; no logic changes, no interface changes, no data structure changes: drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c:586 - It only affects the r535 GSP-RM path, and only the firmware’s registry configuration step.
- Side effects and risk - For already-known PCI IDs, the flag is inert; there is no change in behavior. - For unknown PCI IDs of supported architectures, initialization proceeds (previously failed); the only visible difference is a blank product name reported by RM. A code search finds no driver dependence on the RM-provided product string in nouveau; device naming in DRM/userspace flows from PCI data instead. - If a truly unsupported architecture is encountered, architectural checks elsewhere (e.g., BOOT_0/BOOT_42-based flows) will still prevent successful bring-up; this flag does not bypass architectural enablement logic. - The module parameter `NVreg_RegistryDwords` still allows overrides; adding this fixed entry does not create compatibility issues (duplicate keys are benign on the RM side).
- Stable backport criteria - Fixes a real, user-visible failure (GPU initialization refusal on new PCI IDs of supported GPUs). - Minimal and low-risk change; no architectural rework; confined to nouveau’s GSP-RM r535 path. - No ABI changes; no new features; behavior matches the proprietary driver’s ability to keep working as IDs update, but implemented via a static registry setting since nouveau can’t update firmware frequently on stable trees. - Does not touch critical kernel subsystems beyond DRM/nouveau; is self-contained and compile-time safe.
Given the small, surgical change, the clear user impact (fixes hard initialization failures), and low regression risk, this is a strong candidate for stable backport.
drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c index 588cb4ab85cb4..32e6a065d6d7a 100644 --- a/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/gsp/rm/r535/gsp.c @@ -582,10 +582,13 @@ struct nv_gsp_registry_entries { * RMSecBusResetEnable - enables PCI secondary bus reset * RMForcePcieConfigSave - forces GSP-RM to preserve PCI configuration * registers on any PCI reset. + * RMDevidCheckIgnore - allows GSP-RM to boot even if the PCI dev ID + * is not found in the internal product name database. */ static const struct nv_gsp_registry_entries r535_registry_entries[] = { { "RMSecBusResetEnable", 1 }, { "RMForcePcieConfigSave", 1 }, + { "RMDevidCheckIgnore", 1 }, }; #define NV_GSP_REG_NUM_ENTRIES ARRAY_SIZE(r535_registry_entries)