linux-kernel - Re: [RFC v2 0/2] gpio: Support for shared GPIO lines on boards

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]

Message-ID: <576d5e496a79c00857820289f8f772d3bb090e35.camel@pengutronix.de>
Date:   Wed, 06 Nov 2019 11:00:32 +0100
From:   Philipp Zabel <p.zabel@...gutronix.de>
To:     Peter Ujfalusi <peter.ujfalusi@...com>,
        Grygorii Strashko <grygorii.strashko@...com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Rob Herring <robh+dt@...nel.org>
Cc:     Mark Brown <broonie@...nel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Tero Kristo <t-kristo@...com>,
        Maxime Ripard <mripard@...nel.org>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>
Subject: Re: [RFC v2 0/2] gpio: Support for shared GPIO lines on boards

On Wed, 2019-11-06 at 11:23 +0200, Peter Ujfalusi wrote:
> 
> On 05/11/2019 20.07, Grygorii Strashko wrote:
> > > > (but hey - if this is boot only then gpio-hogs should work. Are they?)
> > > 
> > > That is another thing which almost works ;)
> > > w/o gpio binding deferred probing is not possible if the GPIO controller
> > > is probed later.
> > > In some cases it might be even impossible to make sure that the GPIO
> > > controller would probe first (GPIO extender on different i2c bus than
> > > the user(s) of the gpio line)
> > > In some cases moving around nodes in DT might artificially make things
> > > work, but then someone compiles the expander as module, or some 'small'
> > > change in kernel and the probe order on the bus changes.
> > > I don't think it is a valid thing to have commits on the DT files
> > > saying: move the expander front/after the hog affected user since since
> > > Monday the probe order has changed. Then move it back two weeks later ;)
> > > 
> > 
> > Ok. Above sounds like real problem. The implicit dependence is exist,
> > but can't
> > be resolved if any driver depends on gpio-hog of some gpio-controller.
> > Probe deferring of gpio-controller will not lead to probe differing of
> > dependent driver.
> > 
> > Question: will gpio-hog mechanism resolve your case if it works (and
> > probe differing issues)?
> 
> I see gpio-hog to fulfill different role, use cases. It is more like
> controlling muxes on boards to select between different exclusive
> features. Things like route the I2S lines to analog codec or HDMI, route
> RGB video to LCD panel or to HDMI, etc.
> 
> But, if it would work it could be used for components which can be
> enabled all the time. On the other hand, if a device has reset/enable
> line then the driver should have a way to control it.

I wonder if it would be useful to differentiate between required and
suggested state in the consumer facing GPIO API for nonexclusive GPIOs.

A driver that is ok with the enable line going into active state at any
time while the device is suspended could use

	gpiod_set_value(en_gpio, 1);

to resume, but

	gpiod_politely_suggest_value(en_gpio, 0);

or similar to suspend, and the core could allow other drivers to
override this state. Similarly to how the regulator framework allows
consumers to set a voltage range, and the core decides on the actual
voltage that fits the constraints.

regards
Philipp