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  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]
Date:	Tue, 22 Jul 2014 23:21:10 -0700
From:	Guenter Roeck <>
To:	Alexandre Courbot <>
CC:	Alexandre Courbot <>,
	Linus Walleij <>,
	"" <>,
	Linux Kernel Mailing List <>
Subject: Re: [PATCH 3/5] gpio: make gpiochip_get_desc() gpiolib-private

On 07/22/2014 10:39 PM, Alexandre Courbot wrote:
> On Wed, Jul 23, 2014 at 12:47 PM, Guenter Roeck <> wrote:
>> On 07/22/2014 08:10 PM, Alexandre Courbot wrote:
>>> On Wed, Jul 23, 2014 at 5:17 AM, Guenter Roeck <> wrote:
>>>> On Tue, Jul 22, 2014 at 04:17:41PM +0900, Alexandre Courbot wrote:
>>>>> As GPIO descriptors are not going to remain unique anymore, having this
>>>>> function public is not safe. Restrain its use to gpiolib since we have
>>>>> no user outside of it.
>>>> If I implement a gpio chip driver built as module, and I want to use
>>>> gpiochip_request_own_desc(), how am I supposed to get desc ?
>>>> I understand that there is still gpio_to_desc(), but I would have thought
>>>> that
>>>>           desc = gpiochip_get_desc(chip, pin);
>>>> would be better than
>>>>           desc = gpio_to_desc(chip->base + pin);
>>>> Not that it makes much of a difference for me, just asking.
>>> Actually I was thinking of changing the prototype of
>>> gpiochip_request_own_desc(), and your comment definitely strenghtens
>>> that idea. gpiochip functions should not work with descriptors,
>>> especially since we are going to switch to a multiple-consumer scheme
>>> where there won't be any canonical descriptor anymore. Thus, how about
>>> turning gpiochip_request_own_desc() into this:
>>> struct gpio_desc *
>>> gpiochip_request_own_desc(struct gpio_chip *chip, u16 hwnum, const char
>>> *label);
>>> which would basically do both the gpiochip_get_desc() and former
>>> gpiochip_request_own_desc() in one call. I think it should satisfy
>>> everybody and removes the need to have gpiochip_get_desc() (a not very
>>> useful function by itself) exposed out of gpiolib.
>>> I will send a patch taking care of this if you agree that makes sense.
>> I think you also plan to remove the capability to retrieve the chip
>> pointer, don't you ? If so, I won't be able to use the function from
>> the pca953x platform init function, since I won't be able to get the
>> pointer to the gpio chip. Even if you don't remove gpiod_to_chip(),
>> things would become a bit messy, since I would first have to convert
>> a pin to a desc and then to the chip pointer. Anyway, that change
>> would mean that exporting gpiochip_request_own_desc or its replacement
>> won't solve one of the problems addressed by my patch anymore, leaving
>> me more or less in the dark :-(.
> Here is why this change is taking place: right now you have a clear
> descriptor/pin mapping, i.e. there is only one descriptor per pin,
> anytime. For various reasons this is going to change soon, and
> descriptors will be allocated the provided to GPIO consumers as an
> abstraction of the pin. Meaning that you cannot really "get the
> descriptor for that pin" anymore. Since gpiochip_request_own_desc()'s
> purpose is precisely to request one descriptor for drivers to use, the
> new prototype makes much more sense IMHO.
> Another reason to have it work on a gpio_chip is that the gpio_chip
> pointer is a token to doing certain "priviledged" operations. Like
> obtaining an arbitrary descriptor. If consumers can get a pointer to
> the gpio_chip of a descriptor, this means they can basically do
> anything.
I understand, but my problem with pca953x platform initialization
is that the code to do that is outside the gpio directory in platform code.
Even though this is not consumer code, it still needs a means to perform
operations on a gpio pin, whatever those means are.

> Being in the board code, it seems to be that you are in a good
> position to obtain a pointer to the gpio_chip, and without knowing
> better I'd say that's what you should try to do. But maybe I would
> understand your problem better if you could post a small patch of what
> you want to achieve here.
Ok, but how do I get the pointer to the gpio chip from platform code
if gpiod_to_chip is gone ?

I attached the relevant parts of a platform file (scu.c), the one utilizing
pca953x initialization code to auto-export gpio pins. It currently uses
gpio_request_one(), which I am trying to replace. I can send you
the complete file if you like, but it is 1,600 bytes long so I figured
that would not help much.

I also attached a patch that tries to replace gpio_request_one with
gpiochip_request_own_desc in a gpio chip driver; maybe that gives
you an idea of that part of the problem.

>> I was thinking about implementing a separate platform driver which
>> would enable me to auto-export (or initialize, if needed) gpio pins
>> from arbitrary gpio drivers to user space. I could make this work
>> with both devicetree data and platform data. Sure, that driver
>> would not have a chance to get accepted upstream, since it would use
>> devicetree data to, in a sense, configure the system, but on the
>> upside it would be independent of gpio API changes, and it would
>> work for _all_ gpio chips, not just for the ones with gpio driver
>> support. Unfortunately this approach doesn't really work either,
>> since exported pin names need to be configured with the chip driver,
>> and can not be selected afterwards when a pin is actually exported.
>> On the other side, would you agree to adding something like
>> gpiod_export_name(), which would export a gpio pin with given name,
>> not using the default or chip->names ? That might help solving
>> at least some of my problems, and I would no longer depend on
>> gpiochip_request_own_desc or any of the related functions.
> Isn't that what gpiod_export_link() does?
This function assumes the existence of an exported pin,
and the resulting link is not in /sys/class/gpio but elsewhere.
That is not really the idea here; I did not want to create a second
export directory just for the sake of having well defined pin names
in some arbitrary place; the idea was to have those well defined
names in /sys/cass/gpio, and /sys/class/gpio is not available
as target for linking outside the gpio subsystem (if I remember
correctly because gpio_class is static and not exported).

>> For reference, I currently need the ability to auto-export
>> gpio pins to user space for pca953x, ich, and for various
>> to-be-published gpio drivers used by my employer.
> Under which criteria are the GPIOs auto-exported? Can't you have the
> board code simply request all the GPIOs as a regular consumer and
> export them to user-space?

That is what the above mentioned platform driver would do. On x86 it
would use platform data for the purpose of identifying to-be-exported
pins, on devicetree platforms it would use devicetree data.


View attachment "patch.sam" of type "text/plain" (3064 bytes)

View attachment "scu.c" of type "text/x-csrc" (7850 bytes)

Powered by blists - more mailing lists