Messages in this thread | | | Subject | Re: [RFC PATCH v2 0/6] i2c: of: reserve unknown and ancillary addresses | From | Kieran Bingham <> | Date | Wed, 15 Apr 2020 09:35:08 +0100 |
| |
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
| |