linux-kernel - Re: [PATCH] gpio: Enable pcf857x GPIO expander for Device Tree

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]

Date:	Wed, 19 Jun 2013 21:38:39 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Archit Taneja <archit@...com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Linux-OMAP <linux-omap@...r.kernel.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	Grant Likely <grant.likely@...retlab.ca>
Subject: Re: [PATCH] gpio: Enable pcf857x GPIO expander for Device Tree

On Mon, Jun 17, 2013 at 1:46 PM, Archit Taneja <archit@...com> wrote:
> On Monday 17 June 2013 02:35 PM, Linus Walleij wrote:

>Just a query, there is an example in gpio.txt in the gpio
> bindings documentation which sets #gpio-cells as 1. Is this is a wrong
> example, or are 1 cell gpio controllers valid?

I don't think so. Try it and see if it works!

(If you want it, you may have to go in and fix drivers/gpio/gpiolib-of.c.)

> About this chip, a change in any of it's GPIOs configured as inputs will
> generate an interrupt, then it's up to the driver to figure out which GPIOs
> changed and handle their corresponding irqs. So shouldn't a device connected
> to the chip describe the gpio number within the pcf857x chip as it's first
> cell?

I guess so...

> I've made a hypothetical example of a pcf8575 chip, which has it's interrupt
> line connected to an omap gpio, and pcf8575's 7th gpio is connected to
> 'pcf_slave'. The pcf_slave's driver requests for an interrupt. Is this the
> correct way to describe this? :
>
> pcf: pcf8575@23 {
>         compatible = "ti,pcf8575";
>         reg = <0x23>;
>         gpio-controller;
>         #gpio-cells = <2>;
>         #interrupt-controller;
>         #interrupt-cells = <1>;
>         interrupt-parent = <&gpio2>;    /* an omap gpio bank */
>         interrupts = <2 8>;             /* gpio line 34, low triggered*/
> };
>
> pcf_slave: slave {
>         ...
>         ...
>         #interrupt-parent = <&pcf>;
>         interrupts = <7>;       /* connected to 7th IO pin of pcf857x*/
> };

There are two paths for dereferencing GPIOs and IRQs.

Simple approach:

give your slave a gpios = <...>;

and in the driver use gpio_to_irq() to dereference an IRQ number
from the GPIO number you get. The IRQdomain etc in the
GPIO driver will take care of the rest.

How to code up a driver so that it can use irqs directly from a GPIO
controller without referring to the GPIO line it is tied into is currently
quite unclear. Atleast to me. It's been discussed for the OMAP
case so search the archives...

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/