On 15/04/2020 09:27, Wolfram Sang wrote: > > Status update on this series: > >> TODO: make sure there are no concurrency issues in patch 6 when handling >> the struct i2c_client. > > This turns out to be annoying. How to make sure that we don't modify the > i2c_client while the adapter it is sitting on just gets removed. AFAICS > we need a new locking scheme just for that and I am not convinced this > is the way forward. > > Also, there is still this small room for regressing when there are DTs > having multiple addresses specified in the DT and the drivers use > i2c_new_dummy_client on these addresses. I have verified that no in-tree > users of i2c_new_dummy (and friends) do work on extra addresses but > still I'd like to completely avoid this potential regression. > > One solution to both problems would be to unregister the reserved device > when its address is requested. I am working on this prototype currently. > However, I am not sure yet if one issue might make this approach messy: > re-registering the reserved device when the probe of the requested > address fails. If we 'unregister' the existing device, could we then register a new 'well named' device more appropriate to the driver, so it doesn't continue to show up as 'reserved' in the system, but rather a more appropriate name to the driver that registered it? > We will see... > Looking forward to it :-) -- Kieran
