linux-kernel - Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib

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: <528C1A42-AFCB-4EE1-A881-3D6BD4C1F539@niasdigital.com>
Date:	Tue, 19 Apr 2011 14:50:52 +1000
From:	Ben Nizette <bn@...sdigital.com>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Linus Walleij <linus.walleij@...ricsson.com>,
	Linus Walleij <linus.walleij@...aro.org>,
	linux-kernel@...r.kernel.org,
	Grant Likely <grant.likely@...retlab.ca>,
	linux-arm-kernel@...ts.infradead.org,
	Lee Jones <lee.jones@...aro.org>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib

On 19/04/2011, at 8:31 AM, Mark Brown wrote:

> On Tue, Apr 19, 2011 at 08:16:12AM +1000, Ben Nizette wrote:
>> On 18/04/2011, at 9:59 PM, Mark Brown wrote:
> 
>>> Even if it ends up being the board code using these APIs it seems
>>> sensible to have a standard API that GPIO drivers can use to expose the
>>> functionality.  This will help with getting control into code Linux owns
>>> (since people don't have to implement custom APIs) and will mean we can
>>> do things like add control of this for device tree based boards.
> 
>> Oh I'm all for platform-specific libraries abstracting this away from the
>> board code if that helps, that's certainly the way that, eg, AVR32 does it.
>> It just doesn't make sense to me to bounce from the board code in to
>> 'generic' gpio code then back to platform-specific implementations when
>> you could cut out the middle man.
> 
> We have cross platform abstractions for lots of things - device tree,
> which I mentioned, is the obvious example - and many of the GPIO
> controllers are themselves cross platform as they're for off-SoC chips.

OK let's take a step back here:  My qualms simply expressed are that the
board code knows how the pin needs to be set up and the gpio provider knows
how the pin can be set up; I don't like the idea of trying to teach gpiolib
and any driver that uses it about those parameters.  I don't see it as necessary
or, for that matter, a war we can without exploding enums.

How about we provide a conduit in gpiolib through which the board code can
express its wishes directly to the gpio provider without trying to interpret
it first?  The gpio provider can supply the mode enumerations in a header
file (much like they do already with, eg, platform data structures), the
board support writer can make a judgement about which settings are required
and gpiolib just worries about passing essentially an opaque cookie of setup
data through as soon as the latter side is ready to accept it?

Or does the gpio-consuming driver genuinely need to know about these concepts?

	--Ben.

> --
> 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/

--
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/