aboutsummaryrefslogtreecommitdiff
path: root/tools/perf/util/trace-event-scripting.c
diff options
context:
space:
mode:
authorHeiner Kallweit <[email protected]>2024-08-15 21:44:50 +0200
committerWolfram Sang <[email protected]>2024-08-26 15:20:02 +0200
commit8d3cefaf659265aa82b0373a563fdb9d16a2b947 (patch)
tree57292875d7d6f94871452fd4883429dd4469b16b /tools/perf/util/trace-event-scripting.c
parent3d16973f771a957d0afd58551b43b861eacc3127 (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