[lkml]   [2019]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v6 10/15] gpio: devres: Add devm_gpiod_get_parent_array

Hi dee Ho peeps! (Linus & Lee + other interested),

On Mon, 2019-12-16 at 09:29 +0100, Linus Walleij wrote:
> On Wed, Dec 11, 2019 at 10:47 AM Matti Vaittinen
> <> wrote:
> > Bunch of MFD sub-devices which are instantiated by MFD do not have
> > own device-tree nodes but have (for example) the GPIO consumer
> > information in parent device's DT node. Add resource managed
> > devm_gpiod_get_array() for such devices so that they can get the
> > consumer information from parent DT while still binding the GPIO
> > reservation life-time to this sub-device life time.
> >
> > If devm_gpiod_get_array is used as such - then unloading and then
> > re-loading the child device fails as the GPIOs reserved during
> > first
> > load are not freed when driver for sub-device is unload (if parent
> > stays there).
> >
> > Signed-off-by: Matti Vaittinen <>
> > ---
> >
> > Changes since v5:
> > - renamed internal function (no __ - prefixes for Linus :] )
> Thanks, as there are things happening in the GPIO subsystem I
> have put this one patch on an immutable branch here:
> Please ask the maintainer (I guess Lee?) to pull this into wherever
> the rest of the patches should be merged if you want patches beyond
> this point to be applied for the next (v5.6) merge window, then this
> patch is not needed in the series.

I dropped the run-level support from regulator patch (for now at
least). This means that I no longer have GPIO consumers needing this
new API in the series. Which means two things:

1. There is no in-tree users of this new API as of now. This API has
valid use-case immediately when an MFD sub-device which has no own
(sub-device specific) compatible in DT wants to get the GPIO array and
use devm - but I am not sure if we have any in-tree. (I checked current
devm_gpiod_get_array() users and didn't see any MFD sub-devices which
would have errorneously used the parent device for management - but I
didn't check if there is any non-devm variant users that might benefit
from this API)

2. There is no dependency from this series to the new API.

So, there is two other options one can consider:
1. Drop this patch completely from the series and GPIO tree.
2. Apply it to GPIO tree only and drop it from this series (if this is
still seen useful).

 \ /
  Last update: 2019-12-16 10:00    [W:0.061 / U:3.148 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site