lkml.org 
[lkml]   [2016]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH v2 0/4] gpio: fix an incorrect lockdep warning
    From
    Date
    On 2016-09-16 19:58, Wolfram Sang wrote:
    >
    >>> Looks good from my POV, but will wait for Peter to comment.
    >>>
    >>> If accepted, I'd think this should go via my I2C tree and I would like
    >>> to ask Linus to ack patch 4. D'accord, everyone?
    >>
    >> Since it is not clear if "Peter" is me or PeterZ (I suspect PeterZ...),
    >
    > Nope, I meant you :) I really value your input, it especially helps me
    > on topics like locking, nesting, muxing... etc. Much appreciated, thanks
    > a lot for doing that!
    >
    >> I'm just adding that it all looks fine by me as well, just to prevent
    >> this from being held up by a misunderstanding.
    >
    > OK. I read this as Acked-by.
    >
    >> It does unconditionally add a new function to i2c-core that is only
    >> ever used if lockdep is enabled, but it is tiny and I'm not bothered
    >> by that memory waste.
    >
    > Same here. And if it prevents us from false positive lockdep reports, I
    > am all for fixing it.

    Except it doesn't, when I think some more about it...

    If you have two gpio-expanders on the same depth but on different i2c
    branches you still end up with a splat if one is used to control a mux
    to reach the other.

    The only way to solve it for good, that I see, is to have every instance
    of the gpio-expander mutex in its own class. That might lead to many
    lockdep classes but then again, how many gpio expanders could there be
    in a system? A dozen or two seems extreme, so maybe that is the correct
    approach anyway?

    Cheers,
    Peter

    \
     
     \ /
      Last update: 2016-09-18 20:26    [W:3.853 / U:0.120 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site