lkml.org 
[lkml]   [2020]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFC PATCH v2 0/6] i2c: of: reserve unknown and ancillary addresses
    From
    Date
    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

    \
     
     \ /
      Last update: 2020-04-15 10:36    [W:4.222 / U:0.080 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site