linux-kernel - Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

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: <CAHp75Vd9qrp_gjMcZAHQrg8BsG5zQC6jZrkseo222=Xepce+ew@mail.gmail.com>
Date:   Tue, 16 Jan 2018 16:33:29 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Andy Shevchenko <andy.shevchenko@...il.com>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        linux-arm Mailing List <linux-arm-kernel@...ts.infradead.org>,
        Linus Walleij <linus.walleij@...aro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        nicolas.free@...rochip.com
Cc:     Ludovic Desroches <ludovic.desroches@...rochip.com>
Subject: Re: [RFC PATCH 1/2] pinctrl: add consumer variant for gpio request

On Tue, Jan 16, 2018 at 11:01 AM, Ludovic Desroches
<ludovic.desroches@...rochip.com> wrote:
> On Mon, Jan 15, 2018 at 10:19:39PM +0200, Andy Shevchenko wrote:
>> On Mon, Jan 15, 2018 at 6:22 PM, Ludovic Desroches
>> <ludovic.desroches@...rochip.com> wrote:
>>
>> Did I miss cover letter for this?
> It seems: https://lkml.org/lkml/2018/1/15/841

>> > Add a consumer variant to GPIO request relative functions. The goal
>> > is to fix the bad ownership, which is arbitrary set to
>> > "range->name:gpio", of a GPIO.
>>
>> Hmm... It's supposed to be name of the owner of the pin range (pin
>> control device name IIUC).

> Yes, the owner is the pinctrl device.

> There is an interesting thread here:
> https://www.spinics.net/lists/linux-gpio/msg16769.html

Okay, I have dove into all links provided. Below a set of my thoughts
with regard to topic.

> If things have changed and I missed it, please tell me. I have seen some
> improvements but it still don't fit my needs.

First of all, the main architectural issue with current pin control
design is so called "states". It's quite artificial entity which is
not represented by hardware per se.

Instead we better to provide an API to pin configuration and pin
muxing: I would like to switch to *this* pin function with *this* pin
configuration.

Second, the pin control and GPIOs are orthogonal as your hardware
confirms. The propagating pin configuration or muxing via GPIO API
looks to me a wrong direction.

To the point of the specific issue you are trying to solve.  I would
rather agree with Maxime:

"Something like "if the configuration is a gpio, and my pinctrl driver
is also a gpio controller, and that gpiod_request is being called on
that pin, hand over the reference"

Just in case of architectural review imagine a below case. We have two
UART devices which share same pins, and at the same time their pins
can be switched to GPIO function. So, use cases and questions:
- allow potential driver to switch between UARTs at run time
- allow UART driver to switch mode between no flow control (2 wire
mode) and HW flow (4 wire mode), though not specifically at run time
- allow GPIO function for some pins at run time to support OOB wake
up, for example, when UART is a console

More caveats:
- switching and reconfiguring pins at run time is a bad idea for the
start (only some exceptions can be applied, see above) because of
electrical properties of the devices and potential damage to the
hardware
- switching to GPIO is allowed at run time for the purpose of OOB wake source
- after switching to GPIO and freeing it the pin configuration (and
perhaps muxing) would return back to previous (before GPIO) settings
(this would be helpful to case described above: OOB wake up)

-- 
With Best Regards,
Andy Shevchenko