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: <D3BCC8A3-7570-49F2-838C-A2B1899B0519@niasdigital.com>
Date:	Wed, 20 Apr 2011 10:09:10 +1000
From:	Ben Nizette <bn@...sdigital.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Linus Walleij <linus.walleij@...ricsson.com>,
	Grant Likely <grant.likely@...retlab.ca>,
	<linux-kernel@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>,
	Lee Jones <lee.jones@...aro.org>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [PATCH 1/2] gpio: add pin biasing and drive mode to gpiolib


On 19/04/2011, at 6:38 PM, Alan Cox wrote:

>>> It also doesn't solve the real problem which is that you've got to
>>> implement platform specific parallel gpio extensions all over the place
>>> when you really want it all using the same 'handle' and request logic.
>> 
>> Fair enough.  Forgive me if you've stated this in a previous conversation
>> then but what do you see as being the best way forward here?  Should
>> gpiolib enforce itself as the One True Allocator and require all firmware
>> drivers call back in to it to get access to the pins rather than gpiolib
>> calling back to the platform upon gpio_request()?
> 
> We need something to allocate gpios and manage them. gpiolib seems to be
> very good at this. We also need gpiolib to route other requests because
> gpiolib is the one thing which knows how to turn "gpio 43" a struct and
> function calls.
> 
>>> And for a lot of this stuff that the gpio layer really doesn't want
>>> internal knowledge of other chunks of the kernel have used models like
>>> 'get_property/set_property' (eg battery, video4linux etc) so that the mid
>>> layer can plumb in a conversation between the handle owner and the driver
>>> without getting involved in the conversation.
>> 
>> Yeah that sounds like a more reasonable way to expose this functionality if
>> the driver does indeed need it.
> 
> Leaving aside the current input/output and on/off bits I would go for
> being able to do
> 
> 	gpio_get_property(gpio, GPIO_BIAS, GPIO_BIAS_WHATEVER);
> 	gpio_set_property(gpio, GPIO_BIAS, GPIO_BIAS_WHATEVER_ELSE);

Yeah I'm all for that so long as the capability constants are defined by the gpio provider, eg <linux/gpio/mygpioexpander.h>.  There's no way gpiolib should be keeping a big ole list of every possible config option for every gpio provider.  Well, maybe gpiolib can know about the options (eg GPIO_BIAS) so long as it doesn't have to enumerate every possible value.

Thanks,
	--Ben.


> 
> and having gpiolib perform nothing more on these than
> 
> 	is the gpio allocated 
> 	does ->get_property() exist
> 		no -EOPNOTSUPP
> 		yes return ->get_proprty(gpio struct, op, val)
> 	
> For dynamically configurable features that avoids the 
> 
> 	gpio_request(35);
> 	magic_platform_hack(&foo[3], blah); /* foo3 will be gpio35 */
> 
> type stuff that becomes unmaintainable.
> 
> It would be entirely optional for a driver to support any of this stuff,
> but it would both allow drivers to do so and also mean that where there
> are multiple devices with a common feature *and* a driver wants to use it
> that it will be properly abstracted in the driver itself.
> 
> 
> Alan
> 
> 
> 
>> 
>> 	--Ben.
>> 
>>> 
>>> Alan
>>> --
>>> 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/
>> 
> 
> 
> -- 
> --
> 	"Alan, I'm getting a bit worried about you."
> 				-- Linus Torvalds
> --
> 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/