linux-kernel - Re: [RFD] Sharing GPIOs for input (buttons) and output (LEDs)

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] [day] [month] [year] [list]

Message-ID: <CACRpkdZ=Xd3_T7paMif10P1zwOT5+p-qn_i1pYoUfvX1wi=EVQ@mail.gmail.com>
Date:	Tue, 22 Mar 2016 15:18:17 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Vaibhav Hiremath <vaibhav.hiremath@...aro.org>
Cc:	Geert Uytterhoeven <geert@...ux-m68k.org>,
	"linux-gpio@...r.kernel.org" <linux-gpio@...r.kernel.org>,
	"linux-leds@...r.kernel.org" <linux-leds@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	linux-renesas-soc@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFD] Sharing GPIOs for input (buttons) and output (LEDs)

On Tue, Mar 22, 2016 at 2:59 PM, Vaibhav Hiremath
<vaibhav.hiremath@...aro.org> wrote:
> On Thursday 17 March 2016 03:48 PM, Linus Walleij wrote:

> but recently I came across another usecase of shared gpio,
>
> Say, for example, we have multiple external I2C peripheral which share
> interrupt line over gpio (ofcourse irq line is muxed onto single gpio).
>
> Now in kernel I would have multiple instances of driver supporting each
> peripheral but gpio can not be shared for registering irq.
>
> Do you suggest MFD driver for such simple usecases ? Should gpiolib
> support SHARED gpios, and gpiolib can define all the policies over
> configuration

I don't see why you would want to use MFD at all.

Not shared GPIOs but shared interrupt lines.

If you're using device tree is is pretty straight forward:

- Make sure the GPIOlib and irqchip portions of the driver
  are totally orthogonal. (See Documentation/gpio/driver.txt
  section "GPIO drivers providing IRQs")

- Just use the irqchip side of the GPIO

- Make sure your consumers check if the IRQ is theirs
  and return IRQ_HANDLED vs NO_IRQ depending on
  whether it's theirs or not.

It is quite obvious from context that in this case all consumers
are using an open drain (if active low) scheme. However
since the GPIO is then used as input it has no effect, it is
more a question for the consumers to assure their IRQ
logic is not using push-pull but rather open drain or you will
get a disaster in the totempole...

> (input only, what about conflicts, bidirectional mode?)

We thought about this, see Documentation/gpio/driver.txt section
Locking IRQ usage".

When the line is locked for IRQ usage, it cannot be switched to
output.

Yours,
Linus Walleij