linux-kernel - Re: How about a gpio_get(device *, char *) function?

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: <CACRpkdZc3cEGfSKW-b=G31yuw_E-GOXid3jkxZ0tuKYGYRE5Nw@mail.gmail.com>
Date:	Sun, 4 Nov 2012 19:04:33 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Alex Courbot <acourbot@...dia.com>,
	Grant Likely <grant.likely@...retlab.ca>
Cc:	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: How about a gpio_get(device *, char *) function?

On Wed, Oct 31, 2012 at 10:04 AM, Alex Courbot <acourbot@...dia.com> wrote:

> Would anyone be opposed to having a gpio_get() function that works similarly
> to e.g. regulator_get() and clk_get()?

I understand the concept and why you want to do this.

However I think the global GPIO numberspace defeats the
purpose.

gpio_get() should get an abstract handle just like clk_get() or
regulator_get(), not a fixed numeral.

That is the only way to really transit away from the global GPIO
numberspace.

The proper refactoring I can see is to introduce an orthogonal
mechanism that will return something like a struct gpio_handle *
when you call gpio_get(), and then use a new set of accessor
functions to manipulate the GPIO, like gpio_handle_set()/ etc
for all known GPIO operations.

So defined in a new #ifdef CONFIG_GPIO_HANDLES or so
in a new <linux/gpio-handles.h> header and like the other
subsystems handling abstract resources just passing an
opaque pointer cookie around.

Then when migrating a driver to use this mechanism, only
include <linux/gpio-handles.h> and make that one driver only
use the abstract interface and get rid of the global numberspace.

Then we can have drivers that under a transition period will
support both the global numberspace and this new
handle-based access pattern.

Then migrate all clients over to <linux/gpio-handle.h> and
finally kill off the old global numberspace and only use
handles with that driver.

So a much more thorough refactoring is needed, just doing
a simple int lookup returning global GPIO numbers will likely
only make the current mess worse.

This more ambitious refactoring path is going to be a large
endavour and will likely go through a lot of reviews and
debate, but something like this is badly needed for the
GPIO subsystem.

Maybe Grant will have different opinions though so this is
not the final word on this issue...

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/