From nobody Tue Apr 7 10:46:56 2026 Received: from mail-wr1-f53.google.com (mail-wr1-f53.google.com [209.85.221.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1230F1E1A3D for ; Sat, 14 Mar 2026 01:32:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.53 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773451935; cv=none; b=t6RKQnGUjc6PXSVA7QMZ+uDA56bHW66lGAlTquTt2xMzB2FfsyIlcEVgG4NSaZUYnlN+lM0opbON2wgXamjSgVDdB3M6Y18KCOVi9W/fsQmDL3rYKDgZ106FYpH0isav24vOcQEXlNS8lZXWtr3y3HJoftbQn6BJYzg5DIi3rg4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773451935; c=relaxed/simple; bh=mUxCPP/m7AMSSH1pxHzOmtIKNsUap3vsjNULA0fzP4Q=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=LQ8RzXM5yLLx4GziJGvruDq3ONzpHAqosj7HUiXPP3nVfjXGYQrdQZXF9l3V85+tB+Uo9LhjVZP9QPfh3w6n8SrIPKbsuVCCyX9fjjxwe/v2CeO4svwQ8w0NprVjAdGr8zvc1tbqxPno7UoSqDistLFjoovoG9RzzkOP/3jiRms= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Pf7Ujhb8; arc=none smtp.client-ip=209.85.221.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Pf7Ujhb8" Received: by mail-wr1-f53.google.com with SMTP id ffacd0b85a97d-439aeed8a5bso2884260f8f.3 for ; Fri, 13 Mar 2026 18:32:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1773451931; x=1774056731; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=iR0JNXye1PQ32tEpIdRTYUVyYik8LC1u1H+imbfX1oQ=; b=Pf7Ujhb8dtVkmMW1sYsmFyRiaTAg+CNq/Kje8X6lJgZTbaMtsSpsd/xOmfxnbOfpfd xRlwOCJDaZz+Btk8wQCnls32+3PTli+M2NwqaNOeeAnshzswbZFcablBSyQxjnUky86Q 9xPCWjQ8GPb080Ab2bucOWYip66HCaVd0LYfNiEuMxzwb7hNYI4yZdzgxVukpCDd0pYk 0wLajObpNsEup5MfL6bBHe2E+ch2DJkCph9hKhYheH1p2KONv2M1m2FgdBNPo/5oCSxk hRfExYrFYL1ymx/qmT/Eni/lKEuweArN1EPxIX7pb1+B87/09RD8F4M05Yp92UPlSjiW UJIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1773451931; x=1774056731; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=iR0JNXye1PQ32tEpIdRTYUVyYik8LC1u1H+imbfX1oQ=; b=j+LD4BIL1iXKYpPaLzFlOqimFcKaKuwGfkxx7VVm/fRLk7m9Gx8AZ3d95WcFeXdot5 qStYXMYMgFLR1rrSIa++d8JS4RJf/I1qo6zkldmXkFHjMBp44mPV9Wt0YCZXCC29ummJ ygZlyY1IDTWOGyrSVyeK9ZSjOfyuROZd5MsFvTGx8AxixkeVcdNoVVba+UzEVopHUSKV JqxgeaaQ/IfVxuaeF5Jylvj6aV5y8yH2M6XrkQ2fDwfpCEvP3Qru7YrWBDfkfNU8Xp06 xdmGKD/Afu3VkWkLhJTkUCiz5v3FBPfrmal7mBeIVqcaWAPIcHvbqKNyxB1EgW9NmC+3 dfJA== X-Forwarded-Encrypted: i=1; AJvYcCXsc1oga+sJkEZlp1H/T0/ua0S5KRHPQnNhQUkhuLtSTaVwa3znmhG/Or/HirRLLHjO0GHm4ZZIL42dt38=@vger.kernel.org X-Gm-Message-State: AOJu0YwDukOLmrq/MaZNJa+bpKi/qW4LIfn9YuSETghKbQNpTbI6kHEx 9c5tBqNi2Tyq0cwPT6g19TihyCWA0pyf+kk+RlYkGLg0mquDrQt44CUD X-Gm-Gg: ATEYQzy6ElZl5JblG2ImwRIAmlubN06DR1OO6at8bBZJr8iZznguwWziAP0B0SEwtC5 nPHJKNPmZCRc/bEKabhEw2mpuX5L/rXvDD/mIsaDM14gNvDsNeHxAEdnZWPFUkKMhXiTS4qD0dY K4Vyf/5HfBXZvPZtm2Tn09LxPv7OV7oLmdcP/+wHVYNtx7WlagAPDTWIC5jMbsQxwqkpW7n+LFS AMbEgNFjCtNXTuCGMXHW7IfyNfS1S3CzyYkZuk1yluzVsZazxQh7W14fZUJ8B44WBZ8MF5i/uaW hLyEbetiUjGcS+hhj+NMiZ1PtnRG94PN0QFbo2qAj+evX9gTJ9M2+6BonZeBBx/cvYJAohngbuW yH2P0FXQxTR3b6pyKrTrgO+QblwbD+cPQYUHYuAo12FNDTg84amxoqyL49OmUb6VqWPN4nWYrEm KKABmQ6j5y8EMYt2mjczhZlQVkF2NkrJQmySNqHVJyz6RZZYXfsQWNO7up9ZoGFChXxfsMZr24p pR31S8xPUNUeo6BKtA6DESqkuKaup6VgJzPraoTzoL3+ihSZN0Vad0ctE5F7TXT86IzPlDBpk4Z 7i1SBLPFDuU= X-Received: by 2002:a05:6000:2501:b0:439:ba4d:bf40 with SMTP id ffacd0b85a97d-43a04dc831fmr10711463f8f.43.1773451931220; Fri, 13 Mar 2026 18:32:11 -0700 (PDT) Received: from scambox.localdomain (5-198-68-184.static.kc.net.uk. [5.198.68.184]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-439fe22529csm21876575f8f.31.2026.03.13.18.32.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 13 Mar 2026 18:32:10 -0700 (PDT) From: Edward Blair To: linux-i2c@vger.kernel.org, linux-usb@vger.kernel.org Cc: heikki.krogerus@linux.intel.com, gregkh@linuxfoundation.org, wsa+renesas@sang-engineering.com, westeri@kernel.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, Edward Blair Subject: [PATCH 1/2] i2c: acpi: skip generic I2C device when vendor-specific sibling exists Date: Sat, 14 Mar 2026 01:31:55 +0000 Message-ID: <20260314013157.7181-2-edward.blair@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260314013157.7181-1-edward.blair@gmail.com> References: <20260314013157.7181-1-edward.blair@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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 --- 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_de= vice_ids[] =3D { {} }; =20 +/* + * Generic I2C device IDs that may be duplicated by vendor-specific device= s. + * 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[] =3D { + /* Microsoft UCSI - often paired with vendor-specific UCSI device */ + { "MSFT8000" }, + {} +}; + struct i2c_acpi_irq_context { int irq; bool wake_capable; @@ -274,6 +285,76 @@ static int i2c_acpi_get_info(struct acpi_device *adev, return 0; } =20 +struct i2c_acpi_sibling_check { + struct acpi_device *self; + struct i2c_adapter *adapter; + unsigned short addr; + bool found; +}; + +static int i2c_acpi_check_sibling_addr(struct acpi_device *adev, void *dat= a) +{ + struct i2c_acpi_sibling_check *check =3D data; + struct i2c_acpi_lookup lookup; + struct i2c_board_info info; + + if (adev =3D=3D check->self) + return 0; + + /* Only yield to vendor-specific devices, not other generic ones */ + if (!acpi_match_device_ids(adev, i2c_acpi_generic_device_ids)) + return 0; + + memset(&lookup, 0, sizeof(lookup)); + lookup.info =3D &info; + lookup.index =3D -1; + + if (i2c_acpi_do_lookup(adev, &lookup)) + return 0; + + if (!device_match_acpi_handle(&check->adapter->dev, + lookup.adapter_handle)) + return 0; + + if (info.addr =3D=3D check->addr) { + check->found =3D true; + return 1; + } + + return 0; +} + +/* + * Check whether this generic ACPI device has a vendor-specific sibling at= the + * same I2C address. Some BIOS implementations (e.g., ASUS Z690/Z790/X670E) + * declare both a generic UCSI device (MSFT8000) and a vendor-specific dev= ice + * (e.g., ITE8853) at the same address. Skip the generic one so the vendor + * driver can bind with proper interrupt and device-specific resources. + */ +static bool i2c_acpi_has_vendor_sibling(struct acpi_device *adev, + struct i2c_adapter *adapter, + struct i2c_board_info *info) +{ + struct acpi_device *parent; + struct i2c_acpi_sibling_check check; + + if (acpi_match_device_ids(adev, i2c_acpi_generic_device_ids)) + return false; + + parent =3D acpi_dev_parent(adev); + if (!parent) + return false; + + check.self =3D adev; + check.adapter =3D adapter; + check.addr =3D info->addr; + check.found =3D false; + + acpi_dev_for_each_child(parent, i2c_acpi_check_sibling_addr, &check); + + return check.found; +} + static void i2c_acpi_register_device(struct i2c_adapter *adapter, struct acpi_device *adev, struct i2c_board_info *info) @@ -302,6 +383,13 @@ static acpi_status i2c_acpi_add_device(acpi_handle han= dle, u32 level, if (!adev || i2c_acpi_get_info(adev, &info, adapter, NULL)) return AE_OK; =20 + if (i2c_acpi_has_vendor_sibling(adev, adapter, &info)) { + dev_info(&adapter->dev, + "skipping %s in favor of vendor-specific device at 0x%02x\n", + dev_name(&adev->dev), info.addr); + return AE_OK; + } + i2c_acpi_register_device(adapter, adev, &info); =20 return AE_OK; --=20 2.53.0