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: <92FFDB9F-37F1-4618-A53D-FEF4151A4953@niasdigital.com>
Date:	Mon, 18 Apr 2011 18:50:12 +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 18/04/2011, at 6:19 PM, Alan Cox wrote:

>> gpiolib handles input and output, high and low because that's all that could reasonably be expected to a) always work and b) be changed at run time in the driver.
> 
> Imagine if file systems only handled 8.3 filenames because that's all
> that could reasonably be expected to a) always work !

Fair call, but bringing this back to the particular case in hand what in that enum is worth 'hinting' in a might-have-an-effect manner rather than just letting the board take care of it?

Still my question stands, where is the driver ever better placed to make these calls than the board code?

> 
>> So in short - what's the use case?  Which driver requires this?
>> 
> 
> Also your comment re simply in or out on or off is incorrect. Pins may
> also be in use by firmware and the like and in a 'neither' state.
> Something certain gpio people seem to be in denial over.

Quite right, but should a pin ever be in a neither state and simultaneously controlled by a gpiolib driver?  If so, how should it behave and if not, is it anything that stricter enforcement of gpio_request() semantics can't get around?

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

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