diff options
author | Heiner Kallweit <hkallweit1@gmail.com> | 2024-08-15 22:44:50 +0300 |
---|---|---|
committer | Wolfram Sang <wsa+renesas@sang-engineering.com> | 2024-08-26 16:20:02 +0300 |
commit | 8d3cefaf659265aa82b0373a563fdb9d16a2b947 (patch) | |
tree | 57292875d7d6f94871452fd4883429dd4469b16b /rust/helpers/helpers.c | |
parent | 3d16973f771a957d0afd58551b43b861eacc3127 (diff) | |
download | linux-8d3cefaf659265aa82b0373a563fdb9d16a2b947.tar.xz |
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>
Diffstat (limited to 'rust/helpers/helpers.c')
0 files changed, 0 insertions, 0 deletions