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 > <matti.vaittinen@xxxxxxxxxxxxxxxxx> 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 <matti.vaittinen@xxxxxxxxxxxxxxxxx> > > --- > > > > 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: > https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/log/?h=ib-devm-gpiod-get-parent-array > > 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). Br, Matti
