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: <e209692a-18a3-4079-fda7-1cc7b6b74667@ti.com>
Date:   Wed, 6 Nov 2019 11:23:10 +0200
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     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>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "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 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.

- Péter

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki