linux-kernel - 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>] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 26 Dec 2013 13:18:29 +0800
From:	曹荣荣 <caorr1980@...il.com>
To:	linux-kernel@...r.kernel.org
Subject: Confusion about Pinctrl and GPIO

Hi Linus and Stephen,

I'm learning the pinctrl subsystem codes these days, and have a
confusion about it, I'm very appreciated if you can help.

I noticed that Stephen<swarren@...dia.com> submitted a patch for pinctrl:
http://www.gossamer-threads.com/lists/linux/kernel/1500890?do=post_view_threaded

In this patch, Stephen said, "When an SoC muxes pins in a group, it's
quite possible for the group to contain e.g. 6 pins, but only 4 of
them actually be needed by the HW module that's mux'd to them. In this
case, the other 2 pins could be used as GPIOs. However, pinctrl marks
all the pins within the group as in-use by the selected mux function.
To allow the expected gpiolib interaction, separate the concepts of
pin ownership into two parts: One for the mux function and one for
GPIO usage. Finally, allow those two ownerships to exist in parallel.
"

I agree that gpiolib should be able to use the two idle pins as GPIO,
but after apply this patch, gpiolib can also request the 4 pins used
by HW module succesfully, and this will override the settings of the 4
pins for HW module.

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.

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. However, no drivers in drivers/pinctrl/ implements such
codes in pinmux_ops->gpio_request_enable().
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?

********************

Let me talk again 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.

Thank you very much in advance!
--
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/