]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
i2c: core: Lock address during client device instantiation
authorHeiner Kallweit <hkallweit1@gmail.com>
Thu, 15 Aug 2024 19:44:50 +0000 (21:44 +0200)
committerWolfram Sang <wsa+renesas@sang-engineering.com>
Mon, 26 Aug 2024 13:20:02 +0000 (15:20 +0200)
commit8d3cefaf659265aa82b0373a563fdb9d16a2b947
tree57292875d7d6f94871452fd4883429dd4469b16b
parent3d16973f771a957d0afd58551b43b861eacc3127
i2c: core: Lock address during client device instantiation

Krzysztof reported an issue [0] which is caused by parallel attempts to
instantiate the same I2C client device. This can happen if driver
supports auto-detection, but certain devices are also instantiated
explicitly.
The original change isn't actually wrong, it just revealed that I2C core
isn't prepared yet to handle this scenario.
Calls to i2c_new_client_device() can be nested, therefore we can't use a
simple mutex here. Parallel instantiation of devices at different addresses
is ok, so we just have to prevent parallel instantiation at the same address.
We can use a bitmap with one bit per 7-bit I2C client address, and atomic
bit operations to set/check/clear bits.
Now a parallel attempt to instantiate a device at the same address will
result in -EBUSY being returned, avoiding the "sysfs: cannot create duplicate
filename" splash.

Note: This patch version includes small cosmetic changes to the Tested-by
      version, only functional change is that address locking is supported
      for slave addresses too.

[0] https://lore.kernel.org/linux-i2c/9479fe4e-eb0c-407e-84c0-bd60c15baf74@ans.pl/T/#m12706546e8e2414d8f1a0dc61c53393f731685cc

Fixes: caba40ec3531 ("eeprom: at24: Probe for DDR3 thermal sensor in the SPD case")
Cc: stable@vger.kernel.org
Tested-by: Krzysztof Piotr Oledzki <ole@ans.pl>
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
Signed-off-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
drivers/i2c/i2c-core-base.c
include/linux/i2c.h