diff options
author | Heiner Kallweit <[email protected]> | 2024-08-15 21:44:50 +0200 |
---|---|---|
committer | Wolfram Sang <[email protected]> | 2024-08-26 15:20:02 +0200 |
commit | 8d3cefaf659265aa82b0373a563fdb9d16a2b947 (patch) | |
tree | 57292875d7d6f94871452fd4883429dd4469b16b /tools/perf/util/trace-event-scripting.c | |
parent | 3d16973f771a957d0afd58551b43b861eacc3127 (diff) |
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/[email protected]/T/#m12706546e8e2414d8f1a0dc61c53393f731685cc
Fixes: caba40ec3531 ("eeprom: at24: Probe for DDR3 thermal sensor in the SPD case")
Cc: [email protected]
Tested-by: Krzysztof Piotr Oledzki <[email protected]>
Signed-off-by: Heiner Kallweit <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
Diffstat (limited to 'tools/perf/util/trace-event-scripting.c')
0 files changed, 0 insertions, 0 deletions