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  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:	Thu, 17 Jul 2014 07:34:11 -0700
From:	Guenter Roeck <>
To:	Alexandre Courbot <>
CC:	"" <>,
	Linux Kernel Mailing List <>,
	Linus Walleij <>
Subject: Re: [PATCH] gpio: Add support for GPIOF_ACTIVE_LOW to gpio_request_one

On 07/17/2014 12:26 AM, Alexandre Courbot wrote:
> On Thu, Jul 17, 2014 at 3:37 PM, Guenter Roeck <> wrote:
>> On 07/16/2014 11:09 PM, Alexandre Courbot wrote:
>>> On Thu, Jul 17, 2014 at 8:11 AM, Guenter Roeck <> wrote:
>>>> The gpio include file and the gpio documentation declare and document
>>>> GPIOF_ACTIVE_LOW as one of the flags to be passed to gpio_request_one
>>>> and related functions. However, the flag is not evaluated or used.
>>>> Check the flag in gpio_request_one and set the gpio internal flag
>>>> FLAG_ACTIVE_LOW if it is set.
>>> What is the point since the integer GPIO API has no clue of the
>>> active-low status of a GPIO? It is only used by the gpiod and sysfs
>>> interfaces.
>> One can use gpio_request_one() to export a gpio pin to user space from
>> the kernel. That code path does use the flag, as you point out yourself
>> above.
> Ok, in that case I suppose it makes sense.
> Reviewed-by: Alexandre Courbot <>
>> One could also argue that the integer gpio API _should_ support this as
>> well,
>> but that is a different question.
> Probably not going to happen. The integer GPIO interface is deprecated
> and users who need new features should seriously consider switching to
> gpiod.

The new API is unfortunately not equivalent to the old one. For example,
if I understand correctly, gpiod_get is expected to be used instead of
gpio_request_one. That may work nicely in a world with full DT or ACPI
support, but doesn't work as well otherwise unless one drops the notion
of using platform specific drivers built as modules (gpiod_add_lookup_table
is not exported, and there is no remove function).

Specifically, I don't see an easy way to convert mdio-gpio to use the new
model, and that driver could really use support for an API which supports
active-low pins. And even if gpiod_add_lookup_table was supported,
converting a driver like this would be a major pain. Sure, it would be
all easy if there would be a gpiod equivalent to gpio_request_one and
gpio_request_array, but that is not the case. This makes converting
drivers from the old to the new model challenging enough that I suspect
that it won't really happen.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists