linux-kernel - Re: [RFC 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 14:03:12 +0200
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     <linus.walleij@...aro.org>, <bgolaszewski@...libre.com>
CC:     <linux-gpio@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <m.szyprowski@...sung.com>, <broonie@...nel.org>,
        <t-kristo@...com>, <mripard@...nel.org>, <p.zabel@...gutronix.de>
Subject: Re: [RFC 0/2] gpio: Support for shared GPIO lines on boards

Hi,

On 30/10/2019 13.45, Peter Ujfalusi 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 have missed Rob and the DT list from the recipients list, I'll send
the RFC v2 asap.

- Péter

> 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.
> 
> The 'sticky' state of the line depends on the board design, which can be
> communicated with the hold-active-state property:
> 
> GPIO_ACTIVE_HIGH: the line must be high as long as any of the clients want it to
> be high
> GPIO_ACTIVE_LOW: the line must be low as long as any of the clients want it to
> be low
> 
> In board DTS files it is just adding the node to descibe the shared GPIO line
> and point the users of this line to the shared-gpio node instead of the real
> GPIO.
> 
> Something like this:
> 
> codec_reset: gpio-shared0 {
> 	compatible = "gpio-shared";
> 	gpio-controller;
> 	#gpio-cells = <2>;
> 
> 	root-gpios = <&audio_exp 0 GPIO_ACTIVE_HIGH>;
> 
> 	branch-count = <2>;
> 	hold-active-state = <GPIO_ACTIVE_HIGH>;
> };
> 
> &main_i2c3 {
> 	audio_exp: gpio@21 {
> 		compatible = "ti,tca6416";
> 		reg = <0x21>;
> 		gpio-controller;
> 		#gpio-cells = <2>;
> 	};
> 
> 	pcm3168a_a: audio-codec@47 {
> 		compatible = "ti,pcm3168a";
> 		reg = <0x47>;
> 
> 		#sound-dai-cells = <1>;
> 
> 		rst-gpios = <&codec_reset 0 GPIO_ACTIVE_HIGH>;
> 		...
> 	};
> 
> 	pcm3168a_b: audio-codec@46 {
> 		compatible = "ti,pcm3168a";
> 		reg = <0x46>;
> 
> 		#sound-dai-cells = <1>;
> 
> 		rst-gpios = <&codec_reset 1 GPIO_ACTIVE_HIGH>;
> 		...
> 	};
> };
> 
> If any of the codec requests the GPIO to be high, the line will go up and will
> only going to be low when both of them set's their shared line to low.
> 
> Note: other option would be to have something similar to gpio-hog (gpio-shared)
> support in the core itself, but then all of the logic and state handling for the
> users of the shared line needs to be moved there.
> Simply counting the low and high requests would not work as the GPIO framework
> by design does not refcounts the state, iow gpio_set(0) three times and
> gpio_set(1) would set the line high.
> 
> I have also looked at the reset framework, but again it can not be applied in a
> generic way for GPIOs shared for other purposes and all existing drivers must
> be converted to use the reset framework (and adding a linux only warpper on top
> of reset GPIOs).
> 
> Regards,
> Peter
> ---
> Peter Ujfalusi (2):
>   dt-bindings: gpio: Add binding document for shared GPIO
>   gpio: Add new driver for handling 'shared' gpio lines on boards
> 
>  .../devicetree/bindings/gpio/gpio-shared.yaml | 100 ++++++++
>  drivers/gpio/Kconfig                          |   6 +
>  drivers/gpio/Makefile                         |   1 +
>  drivers/gpio/gpio-shared.c                    | 229 ++++++++++++++++++
>  4 files changed, 336 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-shared.yaml
>  create mode 100644 drivers/gpio/gpio-shared.c
> 

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