From: Jarkko Nikula jarkko.nikula@linux.intel.com
[ Upstream commit d515503f3c8a8475b2f78782534aad09722904e1 ]
Add I3C controller PCI IDs on Intel Wildcat Lake-U.
Signed-off-by: Jarkko Nikula jarkko.nikula@linux.intel.com Reviewed-by: Frank Li Frank.Li@nxp.com Link: https://lore.kernel.org/r/20250808131732.1213227-1-jarkko.nikula@linux.intel... Signed-off-by: Alexandre Belloni alexandre.belloni@bootlin.com Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
YES
- What changed: Only two new PCI IDs were added to the Intel entry list in `drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c:126` to allow binding on Wildcat Lake-U: - `/* Wildcat Lake-U */` with `0x4d7c` and `0x4d6f` mapped to `intel_info` (`drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci- pci.c:127-129`). - No probe/remove logic or resource handling changed; the rest of the table remains for Panther Lake-H/P (`drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c:130-136`).
- Binding behavior: The new IDs use the same `driver_data` (`intel_info`) as existing Panther Lake entries, which runs the Intel- specific init reset sequence (`mipi_i3c_hci_pci_intel_init`) that ioremaps a small private window and toggles the reset bit (`drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c:28-50`). This is a contained and proven path already used for Panther Lake.
- Scope and risk: - No functional changes, no API/ABI changes, no control flow changes; strictly a device-ID enablement in a leaf driver. - Risk of regression is minimal because the driver will only bind on systems with those exact Intel vendor/device IDs. Systems without this hardware are unaffected. - Architectural impact is nil; this does not touch core I3C, PCI, or shared subsystems—only the HCI PCI glue driver’s ID table.
- User impact: Without these IDs, Wildcat Lake-U systems with MIPI I3C HCI on PCI will not have the I3C controller bound by this driver, reducing functionality. Adding the IDs enables existing code paths for a new platform, which is a classic stable backport case.
- Stable policy alignment: - This is not a new feature; it’s device-ID enablement for existing support. Such ID additions are routinely accepted into stable as low-risk hardware enablement. - No “Fixes”/“Cc: stable” tags, but stable trees regularly take ID- only patches when they unlock existing drivers for shipping hardware.
- Dependencies/constraints: - Backport only to stable branches that already contain `MIPI_I3C_HCI_PCI` and this PCI glue driver (initially added with Panther Lake support). For branches older than that introduction, this would imply pulling in the entire driver, which exceeds minimal-risk backporting. - In branches where `intel_info` and the Intel init/reset sequence are present and in use for Panther Lake, these IDs integrate cleanly.
Conclusion: The patch is a small, contained, low-risk device-ID addition enabling existing functionality on Wildcat Lake-U. It fits stable backport criteria and should be backported to applicable stable trees that already include the MIPI I3C HCI PCI driver.
drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c | 3 +++ 1 file changed, 3 insertions(+)
diff --git a/drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c b/drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c index c6c3a3ec11eae..08e6cbdf89cea 100644 --- a/drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c +++ b/drivers/i3c/master/mipi-i3c-hci/mipi-i3c-hci-pci.c @@ -124,6 +124,9 @@ static void mipi_i3c_hci_pci_remove(struct pci_dev *pci) }
static const struct pci_device_id mipi_i3c_hci_pci_devices[] = { + /* Wildcat Lake-U */ + { PCI_VDEVICE(INTEL, 0x4d7c), (kernel_ulong_t)&intel_info}, + { PCI_VDEVICE(INTEL, 0x4d6f), (kernel_ulong_t)&intel_info}, /* Panther Lake-H */ { PCI_VDEVICE(INTEL, 0xe37c), (kernel_ulong_t)&intel_info}, { PCI_VDEVICE(INTEL, 0xe36f), (kernel_ulong_t)&intel_info},