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]

Date:   Wed, 30 Oct 2019 16:03:09 +0200
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     Philipp Zabel <p.zabel@...gutronix.de>,
        Rob Herring <robh+dt@...nel.org>
CC:     Linus Walleij <linus.walleij@...aro.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>,
        Mark Brown <broonie@...nel.org>, Tero Kristo <t-kristo@...com>,
        Maxime Ripard <mripard@...nel.org>,
        <devicetree@...r.kernel.org>
Subject: Re: [RFC v2 0/2] gpio: Support for shared GPIO lines on boards



On 30/10/2019 15.51, Philipp Zabel wrote:
> On Wed, 2019-10-30 at 15:32 +0200, Peter Ujfalusi wrote:
>>
>> On 30/10/2019 15.12, Rob Herring wrote:
>>> On Wed, Oct 30, 2019 at 7:03 AM Peter Ujfalusi <peter.ujfalusi@...com> wrote:
>>>> Hi,
>>>>
>>>> The shared GPIO line for external components tends to be a common issue and
>>>> there is no 'clean' way of handling it.
>>>>
>>>> I'm aware of the GPIOD_FLAGS_BIT_NONEXCLUSIVE flag, which must be provided when
>>>> a driver tries to request a GPIO which is already in use.
>>>> However the driver must know that the component is going to be used in such a
>>>> way, which can be said to any external components with GPIO line, so in theory
>>>> all drivers must set this flag when requesting the GPIO...
>>>>
>>>> But with the GPIOD_FLAGS_BIT_NONEXCLUSIVE all clients have full control of the
>>>> GPIO line. For example any device using the same GPIO as reset/enable line can
>>>> reset/enable other devices, which is not something the other device might like
>>>> or can handle.
>>>> For example a device needs to be configured after it is enabled, but some other
>>>> driver would reset it while handling the same GPIO -> the device is not
>>>> operational anymmore as it lost it's configuration.
>>>>
>>>> With the gpio-shared gpiochip we can overcome this by giving the gpio-shared
>>>> the role of making sure that the GPIO line only changes state when it will not
>>>> disturb any of the clients sharing the same GPIO line.
>>>
>>> Why can't we just add a shared flag like we have for interrupts?
>>> Effectively, we have that for resets too, it's just hardcoded in the
>>> the drivers.
>>
>> This would be kind of the same thing what the
>> GPIOD_FLAGS_BIT_NONEXCLUSIVE does, which was a quick workaround for
>> fixed-regulators afaik.
>>
>> But let's say that a board design will pick two components (C1 and C2)
>> and use the same GPIO line to enable them. We already have the drivers
>> for them and they are used in boards already.
>>
>> Both needs the GPIO line to be high for normal operation.
>> One or both of them needs register writes after they are enabled.
>>
>> During boot both requests the GPIO (OUTPUT_LOW) and sets it high, then
>> run the register setup.
>>
>> C1 request GPIO (LOW)
>> C1 gpio_set(1)
>> C1 register writes
>> C2 requests GPIO (LOW)
>>  C1 placed to reset and looses the configuration
>> C2 gpio_set(1)
>>  C1 also enabled
>> C2 register writes
>>
>> At this point C2 is operational, C1 is not.
>>
>> In shared GPIO case the GPIO should be handled like a regulator with a
>> twist that the 'sticky' state of the GPIO might be low or high depending
>> on the needs of the components it is connected to.
>>
>> The shared GPIO line is a board design quirk and basically any device
>> which have reset/enable GPIO must be able to work in a situation when
>> they are sharing that line with other components and the driver should
>> not know much about this small detail.
> 
> What about components that require a register write right after being
> enabled, for example to put the device into a low power state, to
> silence it on a bus, or to mask some initially enabled interrupts?

You are right, if a device needs driver to silence it when enabled (we
might not have the driver compiled) then this can be a problem.

But the same thing applies to components without enable/reset GPIO and
only needing power, no?

I would trust (I know...) on the board designers to not bundle
components of such kinds.

> 
> regards
> Philipp
> 

- Péter

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