[PATCH 04/17] i3c: master: Match ACPI targets to the correct bus controller instance

[sashiko-bot at kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] ACPI-enumerated I2C targets lack multi-instance filtering, causing them to be incorrectly registered on every controller instance.
--

commit 54eadfeea381aab0d49e21f9beb9d6921078d83f
Author: Adrian Hunter <adrian.hunter at intel.com>

i3c: master: Match ACPI targets to the correct bus controller instance

This commit adds an instance number to the I3C master controller to match
ACPI targets to the correct multi-bus controller instance. It extracts the
instance number from the _ADR value to properly filter I3C child nodes and
allows secondary controller instances to successfully probe.

>     ACPI-enumerated I2C devices are unaffected. Their controller instance is
>     encoded in the Resource Source Index of the I2cSerialBusV2 descriptor
>     rather than in _ADR and will require separate handling.
> 
>     Fixes: b46a4b3c5d1e ("i3c: master: Support ACPI enumeration of child devices")
>     Signed-off-by: Adrian Hunter <adrian.hunter at intel.com>
> 
> diff --git a/drivers/i3c/master.c b/drivers/i3c/master.c
> index f9a6c8560fabf..215a22f2c7b61 100644
> --- a/drivers/i3c/master.c
> +++ b/drivers/i3c/master.c
[ ... ]
> @@ -3100,9 +3109,15 @@ static int i3c_master_add_acpi_dev(struct i3c_master_controller *master,
>  
>  	adr = acpi_device_adr(adev);
>  
> +	/* Match the multi-bus instance number */
> +	if (FIELD_GET(I3C_ACPI_ADR_INSTANCE, adr) != master->instance)
> +		return 0;
> +
>  	/* For I3C devices, _ADR will have the 48 bit PID of the device  */
> -	reg[1] = upper_32_bits(adr);
> -	reg[2] = lower_32_bits(adr);

[Severity: High]
This is a pre-existing issue, but is it accurate to say I2C devices are
unaffected in the commit message?

Looking at i3c_master_add_acpi_dev(), I2C devices return early before reaching
this new instance filtering:

	if (!acpi_has_method(adev->handle, "_ADR")) {
		ret = i3c_master_add_i2c_boardinfo(master, fwnode, reg);
		if (ret == -ENODEV)
			return 0;

		return ret;
	}

Because this patch enables secondary controller instances to successfully
probe by fixing the I3C _ADR check, won't these secondary instances now
register all I2C targets found in the shared ACPI parent node?

Could this cause phantom I2C devices to be registered on the wrong physical
bus controllers, leading the I2C subsystem to bind drivers to nonexistent
hardware?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260914113003.183150-1-adrian.hunter@intel.com?part=4