linux-kernel - Re: Confusion about Pinctrl and GPIO

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

Message-ID: <CACRpkdYK+ceGO2rayHW27h4KAcdk_Je7EimTZ5ZiO6NmPpzaWA@mail.gmail.com>
Date:	Tue, 7 Jan 2014 20:02:03 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	曹荣荣 <caorr1980@...il.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Stephen Warren <swarren@...dia.com>
Subject: Re: Confusion about Pinctrl and GPIO

On Thu, Dec 26, 2013 at 5:56 AM, 曹荣荣 <caorr1980@...il.com> wrote:

> I have read the latest Documentation/pinctrl.txt, and there is two examples
> about muxing logic in "GPIO mode pitfalls" section, let me take example A
> for instance:
>
>                        pin config
>                        logic regs
>                        |               +- SPI
>      Physical pins --- pad --- pinmux -+- I2C
>                                |       +- mmc
>                                |       +- GPIO
>                                pin
>                                multiplex
>                                logic regs
>
> Assuming that the pin has been configured as SPI mode, undoubtedly we can't
> use it as GPIO any longer. However, if we call gpio_request() (gpiolib API)
> to requet this pin for GPIO purpose, gpio_request() still can return
> successfully. I think this is unreasonable, gpio_request() should return an
> "error code" if the pin is in-use by PINMUX.

Yes but there is also example (B) where it is perfectly possible
to use the same pin as GPIO and for a device at the same time.
So that case needs to be supported as well.

> I read the codes of pin_request() in pinmux.c, and guess
> pinmux_ops->gpio_request_enable() may be responsible to handle this use
> case, that is, to return an "error code" if the pin has been owned by
> pinmux.

Yes this is one way to fix this: let the driver impose such
restrictions.

> However, no drivers in drivers/pinctrl/ implements such codes in
> pinmux_ops->gpio_request_enable().

OK so what about you fix it for a driver you have a problem
with? :-)

> Or, pinctrl subsystem is just resposible to set the pin in GPIO mode, and
> gpio subsystem (gpiolib) is responsible for other things like set direction,
> get value if input, or set high/low if output. Is my understanding right?

The pinctrl subsystem is responsible for all muxing, and the GPIO
subsystem drives and reads GPIO lines yes.

> Let me talk about the example described by Stephen. If actually only 4 pins
> of the group which contains 6 pins are needed by HW module, then why does
> the group be defined to contain 6 pins? I think the group should be defined
> only containing 4 pins rather than 6 pins, then the other 2 idle pins can be
> used for any other purpose.

Group definition should be done at the granularity needed to work
with the system mux configuration. Nominally the group definition
should reflect the electrical use case(s) indicated in the documentation
of the pin controller. Some choose to create one group per pin when
all pins can be muxed around individually.

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/