Re: [PATCH 1/2] i2c: acpi: skip generic I2C device when vendor-specific sibling exists

[Mika Westerberg <mika.westerberg@linux.intel.com>]

On Sat, Mar 14, 2026 at 01:31:55AM +0000, Edward Blair wrote:
> Some BIOS implementations (notably ASUS Z690/Z790/X670E motherboards)
> declare both a generic UCSI device (MSFT8000) and a vendor-specific
> device (e.g., ITE8853) as ACPI children of the same I2C controller,
> both referencing the same I2C slave address.
> 
> During ACPI I2C enumeration, whichever device is walked first claims
> the address, causing the second to fail with -EBUSY. When the generic
> MSFT8000 device registers first, the vendor-specific driver cannot
> bind, losing access to device-specific features like GPIO interrupt
> resources that are only declared on the vendor-specific ACPI device.
> 
> Fix this by checking, before registering a known generic I2C device,
> whether a sibling ACPI device exists at the same address on the same
> adapter. If so, skip the generic device to let the vendor-specific
> one register instead.
> 
> Signed-off-by: Edward Blair <edward.blair@gmail.com>
> ---
>  drivers/i2c/i2c-core-acpi.c | 88 +++++++++++++++++++++++++++++++++++++
>  1 file changed, 88 insertions(+)
> 
> diff --git a/drivers/i2c/i2c-core-acpi.c b/drivers/i2c/i2c-core-acpi.c
> index 2cbd31f77..87582eac7 100644
> --- a/drivers/i2c/i2c-core-acpi.c
> +++ b/drivers/i2c/i2c-core-acpi.c
> @@ -137,6 +137,17 @@ static const struct acpi_device_id i2c_acpi_ignored_device_ids[] = {
>  	{}
>  };
>  
> +/*
> + * Generic I2C device IDs that may be duplicated by vendor-specific devices.
> + * When a vendor-specific sibling exists at the same address, the generic
> + * device is skipped to avoid -EBUSY address conflicts.
> + */
> +static const struct acpi_device_id i2c_acpi_generic_device_ids[] = {
> +	/* Microsoft UCSI - often paired with vendor-specific UCSI device */
> +	{ "MSFT8000" },
> +	{}
> +};

Are they both "present"? I mean their _STA() returns 0xF for both?

We have a quirk table already in drivers/acpi/x86/utils.c that I think could
be used to mark the other one being not present.