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: <5097F8CF.5090100@wwwdotorg.org>
Date:	Mon, 05 Nov 2012 10:35:11 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Alex Courbot <acourbot@...dia.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org
Subject: Re: How about a gpio_get(device *, char *) function?

On 11/04/2012 11:04 AM, Linus Walleij wrote:
> 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.

I don't really see why the return type of gpio_get() influences whether
it can be implemented or not.

If gpio_get() were implemented today, it could return an integer with
the same value as any other GPIO functions use already.

With board files, some "gpio map" table would simply contain the same
int GPIO ID value the table as is used anywhere else already. With DT,
the same xlate function would translate from DT GPIO-chip-relative
IDs/specifiers into the global number space in the same way that we do
today via other APIs.

If the GPIO subsystem were reworked as you propose, this API could be
reworked in exactly the same way, or if implemented after the rework, it
would return whatever handle type was in use at the time.
--
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/