lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 16 Dec 2019 08:59:14 +0000
From:   "Vaittinen, Matti" <Matti.Vaittinen@...rohmeurope.com>
To:     "linus.walleij@...aro.org" <linus.walleij@...aro.org>
CC:     "corbet@....net" <corbet@....net>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "phil.edworthy@...esas.com" <phil.edworthy@...esas.com>,
        "dmurphy@...com" <dmurphy@...com>,
        "linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-rtc@...r.kernel.org" <linux-rtc@...r.kernel.org>,
        "linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
        "mchehab+samsung@...nel.org" <mchehab+samsung@...nel.org>,
        "alexandre.belloni@...tlin.com" <alexandre.belloni@...tlin.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "lgirdwood@...il.com" <lgirdwood@...il.com>,
        "jacek.anaszewski@...il.com" <jacek.anaszewski@...il.com>,
        "mazziesaccount@...il.com" <mazziesaccount@...il.com>,
        "a.zummo@...ertech.it" <a.zummo@...ertech.it>,
        "arnd@...db.de" <arnd@...db.de>,
        "wsa+renesas@...g-engineering.com" <wsa+renesas@...g-engineering.com>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "noralf@...nnes.org" <noralf@...nnes.org>,
        "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
        "bgolaszewski@...libre.com" <bgolaszewski@...libre.com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "lee.jones@...aro.org" <lee.jones@...aro.org>,
        "pavel@....cz" <pavel@....cz>,
        "broonie@...nel.org" <broonie@...nel.org>,
        "sboyd@...nel.org" <sboyd@...nel.org>
Subject: Re: [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
> <matti.vaittinen@...rohmeurope.com> 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@...rohmeurope.com>
> > ---
> > 
> > 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ