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]

Message-ID: <df10bfc0-0ad5-36f5-ea68-9fee82cd2c5a@ti.com>
Date:   Tue, 19 Nov 2019 17:01:10 +0200
From:   Peter Ujfalusi <peter.ujfalusi@...com>
To:     Linus Walleij <linus.walleij@...aro.org>
CC:     Rajendra Nayak <rnayak@...eaurora.org>,
        Grant Likely <glikely@...retlab.ca>,
        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>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
        <devicetree@...r.kernel.org>, Rob Herring <robh+dt@...nel.org>
Subject: Re: [RFC 0/2] gpio: Support for shared GPIO lines on boards

Hi Linus,

On 19/11/2019 10.34, Peter Ujfalusi wrote:
>> So begin with creating a way to pull the shared handling of
>> regulators into gpiolib with these clearly cut semantics
>> delete the NONEXCLUSIVE thing and then when you are
>> done with that exploit the same
>> infrastructure for GPIO reset.
> 
> The logic is relatively simple, 229 lines in gpio-shared, but moving
> that into core will explode things a bit and going to add more
> complexity to all gpio lines.
> For one, we must maintain a list of clients requesting the line to be
> able to do proper refcounting and this needs to be done for all pins as
> we don't know beforehand that the given line is going to be shared.
> 
> Or add gpio-shared block similar to gpio-hog to prepare a given line for
> sharing? I think this might be a better thing to do and some of the code
> from gpio-shared.c can be reused.

I had some time today and now have a working support for shared GPIOs in
the gpio core.

Works fine with regulators and with my board which have two ocm3168a
codec with shared reset GPIO.

There are couple of things initially not going to work, like supporting
clients with different GPIO_ACTIVE_HIGH/LOW as we have only one
gpio_desc which got it's GPIO_ACTIVE_* form the gpio-shared child.

The means that all clients has to have the same GPIO_ACTIVE_* as how the
gpio-shared child is configured:

gpio1 {
	p00 {
		gpio-shared;
		/* raw level high is refcounted */
		gpios = <0 GPIO_ACTIVE_HIGH>;
		/* Initially set the gpio line to raw level high */
		output-high;
		line-name = "CODEC RESET";
	};
};

now clients can:
...
enable-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
...
enable-gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>;
...

I'm reusing some of the gpio-hog code for this from gpiolib-of.c

For supporting different GPIO_ACTIVE_* on the client side might be
tricky as we might need to create dummy gpio_desc for each client and
put them on a list for the shared gpio_desc.

In any case I try to clean up the patch and add some documentation and
send it for review as RFC in couple of days.



- Péter

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