[26.04_linux-nvidia-bos] Backport Vera I3C v7 support

[nirmoy]

Backport the complete Vera I3C v7 series to the 26.04 BOS 7.0 kernel. The series adds the I3C core and DesignWare changes needed for Vera/Tegra410, ACPI matching for the controller, and SPD5118 hwmon support for DDR5 temperature monitoring.

This PR is only for 26.04_linux-nvidia-bos; Vera does not require a companion non-BOS kernel PR.

The backport contains:

• all 12 patches from the upstream Vera I3C v7 series
• the complete five-commit mainline ACPICA LVR prerequisite chain
• one downstream BOS annotations commit that explicitly pins the inherited arm64 I3C and SPD5118 module policies
• linux-next commit d2c743efd2d1ee64e94324664808f623dd865872, which fixes the I3C unregister descriptor lifetime
• two NVIDIA: VR: SAUCE SETAASA follow-up fixes for firmware modalias generation and early device-add error propagation
• linux-next commit 038cf48b3170af26a70bf2dee4f8c3ac910f5176, which fixes the empty-DAA UBSAN warning

Source series: https://lore.kernel.org/r/20260728065955.809445-1-akhilrajeev@nvidia.com

SETAASA follow-up series: https://lore.kernel.org/r/20260811103811.3380073-1-nirmoyd@nvidia.com

Backport adaptations for the Linux 7.0 BOS target are limited to:

• use i3c_master_reattach_i3c_dev() because this BOS branch predates the _locked rename
• resolve a context-only conflict in the ACPI child-enumeration patch because this branch predates surrounding I3C core changes; no code changes were made
• resolve a context-only conflict in the DesignWare clock-quirk patch because this branch predates the IBI data-capability detection block; no code changes were made

Validation:

• git diff --check passes against 26.04_linux-nvidia-bos
• targeted builds pass for the affected ACPI, I3C, DesignWare I3C, and SPD5118 objects
• the upstream unregister fix applies cleanly and its stable patch ID matches linux-next
• annotation parsing confirms the explicit arm64 pins match the inherited m policies for both BOS flavours; amd64 continues to inherit its policies from debian.master
• the earlier PR head completed Vera boot and focused I2C/I3C runtime validation with an I3C-capable SBIOS; final runtime validation of the review-updated head is pending

LP: https://bugs.launchpad.net/bugs/2139154

[github-actions]

PR Validation Report

Patchscan ✅ No Missing Fixes

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

PR Lint ❌ Errors found

Details

Checking 21 commits...

Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 01bde9aa65e4 │ i3c: dw: avoid shift-out-of-bounds when daa assigns no devices   │ match      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 2c4120f0d932 │ i3c: master: propagate setaasa early device-add failures         │ match      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 95ef2ec18787 │ i3c: master: emit firmware modalias for setaasa devices          │ noted      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 66f2b1563f22 │ i3c: master: fix info leak and uaf in device unregister path     │ match      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 6b28c857db50 │ [SAUCE] [config] pin i3c and spd5118 module policies for arm64   │ N/A        │ N/A     │ nirmoyd                   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 3e14f60bf7c8 │ hwmon: spd5118: add i3c support                                  │ match      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ c34f14139535 │ hwmon: spd5118: remove 16-bit addressing                         │ match      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 16f4b0de5638 │ i3c: dw-i3c-master: add acpi id for tegra410                     │ match      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 9aea7d014801 │ [SAUCE] i3c: dw-i3c-master: add acpi core clock frequency quirk  │ N/A        │ N/A     │ akhilraj, belloni, nirmoy │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 29e42d080ed3 │ i3c: dw-i3c-master: add setaasa as supported ccc                 │ match      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ c4caffbe69a4 │ i3c: master: match i3c device through dt and acpi                │ match      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b7bb5bd86057 │ i3c: master: add support for devices without pid                 │ match      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ b7697ab74c66 │ [SAUCE] i3c: master: add support for devices using setaasa       │ N/A        │ N/A     │ akhilraj, belloni, nirmoy │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 53ef02618450 │ [SAUCE] i3c: master: support acpi enumeration of child devices   │ N/A        │ N/A     │ akhilraj, belloni, nirmoy │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 6f89f1707afb │ 2543fbb21642 ACPICA: fix I2C LVR item count in the conversion ta │ match      │ match   │ preserved + nirmoyd added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 3bf2c0dc1f69 │ 53a3a7723c9e ACPICA: Mention the LVR bits                        │ match      │ match   │ preserved + nirmoyd added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ aca5628798d0 │ d364d76f3d0c ACPICA: Change LVR to 8 bit value                   │ match      │ match   │ preserved + nirmoyd added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 46d8c0c8fc07 │ 468adc6b1ff8 ACPICA: Fetch LVR I2C resource descriptor           │ match      │ match   │ preserved + nirmoyd added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 699c0854d5dc │ f0ee0b0927f7 ACPICA: Add LVR to acrestyp.h                       │ match      │ match   │ preserved + nirmoyd added │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 09a82f00cd79 │ i3c: master: use unified device property interface               │ match      │ found   │ ok, backporter: nirmoyd   │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ eaa22b7bfbe0 │ dt-bindings: i3c: add mipi-i3c-static-method to support setaasa  │ match      │ found   │ ok, backporter: nirmoyd   │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint results:
E: 9aea7d014801 ("i3c: dw-i3c-master: Add ACPI core clock frequency "): not SAUCE/UBUNTU/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)
E: b7697ab74c66 ("i3c: master: Add support for devices using SETAASA"): not SAUCE/UBUNTU/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)
E: 53ef02618450 ("i3c: master: Support ACPI enumeration of child dev"): not SAUCE/UBUNTU/Revert but has no upstream reference trailer (cherry picked from commit ... or backported from ...)

[clsotog]

I have this comments from Codex:

• High: drivers/hwmon/spd5118.c:749, drivers/i3c/master.c:317, debian.nvidia-bos/config/annotations:273
  spd5118 is built as a module, but the new I3C driver only has an OF match table and no I3C modalias. The I3C device uevent still emits only MODALIAS=i3c:...; for PID-less SETAASA devices that becomes the all-zero I3C alias, so spd5118.ko will not autoload. It will bind if already loaded, but Tegra410 will likely miss the sensor by default. Add firmware modalias support to the I3C uevent path for these devices, or
  provide another working module alias/load mechanism.
• Medium: drivers/i3c/master.c:2253
  i3c_master_early_i3c_dev_add() now has a SETAASA path that must succeed for PID-less devices, but its return value is still ignored. For SETDASA this was recoverable after ENTDAA; for SETAASA/PID-less devices it is not. If attach/reattach fails, bus init continues, SETAASA is sent, and no device is registered. Propagate failures at least when static_addr_method & I3C_ADDR_METHOD_SETAASA.

[nvmochs]

@nirmoy

a05cce2 i3c: master: Add support for devices using SETAASA

Nit: Use backported from, no blank line between pick tag and context note

---

One additional Codex finding...

• - High: debian.nvidia-bos/config/annotations:192 sets CONFIG_I3C=n on amd64 but leaves inherited I3C-dependent policies enabled. After olddefconfig, annotation validation reports 12 mismatches, including REGMAP_I3C, multiple I3C controllers/clients, I3C_OR_I2C, and SENSORS_SPD5118_DETECT. This can break amd64 configuration validation/package builds. Either retain I3C=m on amd64 or override all affected dependent policies.

[jamieNguyenNVIDIA]

Reviewed all 17 commits at f3c0e1f14840. The backport itself is in very good
shape: 15 of the 16 cherry-picks are byte-identical to their cited upstream
commits, the one deviation is documented, and the affected objects build clean.
The points below are the delta on top of the annotations and Codex findings
already raised in this thread.

Backport fidelity

Comparing the added and removed lines of each pick against its cited upstream
commit, with context and hunk headers excluded, exactly one source line in the
whole series differs from upstream — the one a05cce2f8cec documents:

 commit 9, a05cce2f8cec
-               ret = i3c_master_reattach_i3c_dev_locked(i3cdev, 0);
+               ret = i3c_master_reattach_i3c_dev(i3cdev, 0);

09a82f00cd79, 46f5daecde96 and a6f892f3222e show differences only in
context lines and @@ header function names, from this tree lacking unrelated
upstream commits (no <linux/bitmap.h> in master.c; dw-i3c-master.c context
shows master->maxdevs = ret >> 16 where upstream shows
master->has_ibi_data = true). Payloads are identical, so no adaptation was
needed and none was made.

Tree attribution is correct throughout and the two trailer styles in this PR are
not inconsistent: the five ACPICA picks cite bare SHAs because those commits are
in mainline v7.2-rc1, while the i3c and hwmon picks carry linux-next because
they are in no release tag.

Built at the series tip for arm64 (defconfig plus CONFIG_ACPI=y,
CONFIG_I3C=m, CONFIG_DW_I3C_MASTER=m, CONFIG_SENSORS_SPD5118=m):

  CC [M]  drivers/hwmon/spd5118.o
  CC [M]  drivers/i3c/master.o
  CC [M]  drivers/i3c/master/dw-i3c-master.o
  CC      drivers/acpi/acpica/rsserial.o
  LD [M]  drivers/i3c/i3c.o

No warnings, and every identifier introduced by the backported code resolves in
this tree at the commit that uses it.

1. a05cce2f8cec: the backport note names the wrong commit

The note reads:

[nirmoy: use the pre-8d8afa428318 static reattach helper name]

8d8afa428318 ("i3c: master: Expose the APIs to support I3C hub") did not rename
anything. It exported a helper that was already called *_locked:

-static int i3c_master_reattach_i3c_dev_locked(struct i3c_dev_desc *dev,
+/**
+ * i3c_master_reattach_i3c_dev_locked() - reattach an I3C device with a new address

The rename was 79c41666b397 ("i3c: master: rename i3c_master_reattach_i3c_dev()
to *_locked"), the immediately preceding patch in the same NXP series, and it is
a pure rename of one definition and two call sites:

-static int i3c_master_reattach_i3c_dev(struct i3c_dev_desc *dev,
+static int i3c_master_reattach_i3c_dev_locked(struct i3c_dev_desc *dev,

As written the note is also self-contradictory: pre-8d8afa428318 the helper
was already named *_locked, which is the opposite of what the backport uses.

The adaptation itself is correct — this tree has
static int i3c_master_reattach_i3c_dev(...) with a body byte-identical to
upstream's *_locked version, the rename is applied to all three sites, and
git grep i3c_master_reattach_i3c_dev_locked a05cce2f8cec returns nothing
tree-wide. Only the SHA in the note needs correcting to 79c41666b397.

2. f3c0e1f14840: the arm64 half of the commit is a no-op

The subject is "Enable I3C and SPD5118 for Tegra410", but
debian.nvidia-bos/config/annotations opens with

include "../../debian.master/config/annotations"

and debian.master already carries all three symbols at m for arm64:

CONFIG_I3C              policy<{'amd64': 'm', 'arm64': 'm', ..., 's390x': 'n'}>
CONFIG_DW_I3C_MASTER    policy<{'amd64': 'm', 'arm64': 'm', ...}>
CONFIG_SENSORS_SPD5118  policy<{'amd64': 'm', 'arm64': 'm', ...}>

Exporting the flavour fragments before and after this commit confirms nothing
changes on the target:

arm64-nvidia-bos:     IDENTICAL before/after
arm64-nvidia-bos-64k: IDENTICAL before/after

amd64-nvidia-bos:
-CONFIG_DW_I3C_MASTER=m        +# CONFIG_DW_I3C_MASTER is not set
-CONFIG_I3C=m                  +# CONFIG_I3C is not set
-CONFIG_SENSORS_SPD5118=m      +# CONFIG_SENSORS_SPD5118 is not set

So the commit's only net effect is to disable three symbols on amd64. The
commit message should say that, or the arm64 entries should be dropped as
redundant.

3. f3c0e1f14840: disabling SPD5118 on amd64 removes an existing feature

i2c_register_spd() in drivers/i2c/i2c-smbus.c instantiates the "spd5118"
device for SMBIOS memory types 0x22 and 0x23, which is the x86 DMI path named
in the SENSORS_SPD5118_DETECT help text. Setting CONFIG_SENSORS_SPD5118=n on
amd64 therefore removes DDR5 module temperature reporting from
amd64-nvidia-bos, which is a user-visible regression unrelated to Tegra410
enablement.

Since the arm64 side needs no change at all (point 2), leaving all three symbols
at their inherited m on both arches would satisfy the stated goal and avoid
both this and the annotations failure.

Notes on the annotations finding already raised

The CONFIG_I3C=n breakage reported above in this thread reproduces. Running the
real tool at both the commit and its parent isolates what this commit causes from
pre-existing environment noise:

parent (f3c0e1f14840^):  28 mismatches
tip    (f3c0e1f14840):   41 mismatches
                         -- 13 added, all I3C related

CONFIG_AD4062              changed from m to -
CONFIG_ADI_I3C_MASTER      changed from m to -
CONFIG_CDNS_I3C_MASTER     changed from m to -
CONFIG_DW_I3C_MASTER       changed from n to -
CONFIG_I3C_OR_I2C          changed from m to y
CONFIG_IIO_ST_LSM6DSX_I3C  changed from m to -
CONFIG_INV_ICM45600_I3C    changed from m to -
CONFIG_MCTP_TRANSPORT_I3C  changed from m to -
CONFIG_MIPI_I3C_HCI        changed from m to -
CONFIG_MIPI_I3C_HCI_PCI    changed from m to -
CONFIG_REGMAP_I3C          changed from m to -
CONFIG_SENSORS_SPD5118_DETECT changed from n to -
CONFIG_SVC_I3C_MASTER      changed from m to -

Twelve of these are inherited from debian.master. The thirteenth,
CONFIG_DW_I3C_MASTER, is annotated 'n' by this commit where the resolved
value is -; the in-file precedent for a symbol that stops being emitted is '-'
(see CONFIG_GENERIC_CPU_CACHE_MAINTENANCE).

CONFIG_I3C_OR_I2C flips rather than disappears because of its default:

config I3C_OR_I2C
	tristate
	default m if I3C=m
	default I2C

With I3C=n and CONFIG_I2C=y it resolves to y against an inherited 'm'.

The check is build-gating: debian/rules.d/2-binary-arch.mk runs it inside
stamp-prepare-%, skipped only when do_mainline_build sets do_skip_checks.

The Codex autoload finding also reproduces — spd5118.c declares
MODULE_DEVICE_TABLE for i2c and of but not i3c, and i3c_device_uevent()
emits only MODALIAS=i3c:dcr%02Xmanuf%04Xpart%04Xext%04X with no firmware
modalias fallback of the kind i2c_device_uevent() has. For a PID-less SETAASA
device pid is 0, and the SETAASA path in i3c_master_early_i3c_dev_add()
returns before i3c_master_retrieve_dev_info(), so dcr is 0 as well and the
alias is all zeros.

[nirmoy]

@clsotog @nvmochs @jamieNguyenNVIDIA Thanks for the detailed reviews. let me know how the curr version looks

[nvmochs]

@nirmoy Confirmed that the latest update addresses my prior findings.

bd24cdc77ffd i3c: dw-i3c-master: Add ACPI core clock frequency quirk

Was this a clean pick or did it require context fixup? (codex says replaying the branch produces a conflict for this patch)

---

For any new patches / fixes, please be sure to add them to the tracking SS (new rows under the existing i3c row).

[clsotog]

This is the P1 finding from my codex session:
NV-Kernels/drivers/i3c/master.c:2770: ACPI child devices are consumed by the I3C parent but never marked enumerated. i3c_master_add_acpi_dev() builds boardinfo from ACPI fwnodes, then the core registers I3C/I2C child devices, but there is no acpi_device_set_enumerated() / clear pairing like I2C and SPI use. That can let _ADR-only I3C children fall through to ACPI default
platform-device creation, and leaves serial-bus children looking unhandled to ACPI remove/reconfiguration paths.

[nirmoy]

BaseOS Kernel Review

Summary

Boro reported 8 findings.

Findings: Critical: 0, High: 0, Medium: 3, Low: 4, Info: 1

Latest watcher review: open review

Generated test plan: open test plan

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

Head: 01bde9aa65e4

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

[nirmoy]

@nirmoy Confirmed that the latest update addresses my prior findings.

bd24cdc77ffd i3c: dw-i3c-master: Add ACPI core clock frequency quirk

Was this a clean pick or did it require context fixup? (codex says replaying the branch produces a conflict for this patch)

It was not clean. context change needed, no code change ! Updated the patch to say backported from ...

For any new patches / fixes, please be sure to add them to the tracking SS (new rows under the existing i3c row).

Will add those

[nirmoy]

This is the P1 finding from my codex session: NV-Kernels/drivers/i3c/master.c:2770: ACPI child devices are consumed by the I3C parent but never marked enumerated. i3c_master_add_acpi_dev() builds boardinfo from ACPI fwnodes, then the core registers I3C/I2C child devices, but there is no acpi_device_set_enumerated() / clear pairing like I2C and SPI use. That can let _ADR-only I3C children fall through to ACPI default platform-device creation, and leaves serial-bus children looking unhandled to ACPI remove/reconfiguration paths.

Codex says:

The I2cSerialBus lifecycle concern is valid for dynamic ACPI reconfiguration, but I3C currently has no ACPI hotplug notifier.

So a upstream gap that is outscope for this PR.

[jamieNguyenNVIDIA]

Acked-by: Jamie Nguyen <jamien@nvidia.com>

[nvmochs]

@nirmoy Confirmed that the latest update addresses my prior findings.

bd24cdc77ffd i3c: dw-i3c-master: Add ACPI core clock frequency quirk

Was this a clean pick or did it require context fixup? (codex says replaying the branch produces a conflict for this patch)

It was not clean. context change needed, no code change ! Updated the patch to say backported from ...

For any new patches / fixes, please be sure to add them to the tracking SS (new rows under the existing i3c row).

Will add those

Thanks for addressing this, no further issues from me!

Acked-by: Matthew R. Ochs <mochs@nvidia.com>

[clsotog]

Acked-by: Carol L Soto <csoto@nvidia.com>

[jamieNguyenNVIDIA]

Applied: https://git.launchpad.net/~canonical-kernel/ubuntu/+source/linux-nvidia/+git/resolute/commit/?h=nvidia-bos-next&id=f8e341d3ffa90eabbcc15365adbeb4609ed846b1

Closing PR.