linux-kernel - Re: [PATCH V1 2/3] Documentation: gpio: Add details of open-drain configuration

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]

Date:	Tue, 14 Feb 2012 14:46:45 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Grant Likely <grant.likely@...retlab.ca>
CC:	"linus.walleij@...ricsson.com" <linus.walleij@...ricsson.com>,
	"dunlap@...otime.net" <dunlap@...otime.net>,
	"lrg@...com" <lrg@...com>,
	"broonie@...nsource.wolfsonmicro.com" 
	<broonie@...nsource.wolfsonmicro.com>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-tegra@...r.kernel.org" <linux-tegra@...r.kernel.org>
Subject: Re: [PATCH V1 2/3] Documentation: gpio: Add details of open-drain
 configuration

On Tuesday 14 February 2012 02:48 AM, Grant Likely wrote:
> On Mon, Feb 13, 2012 at 11:59:47AM +0530, Laxman Dewangan wrote:
>> Adding details of open drain configuration of the gpio so that
>> client can set the pin as open drain at the time of gpio request.
>>
>> Signed-off-by: Laxman Dewangan<ldewangan@...dia.com>
>
> Linus mentioned that this should be part of pinctrl instead of the gpio API,
> but I think there is an argument for making it part of the gpio API,
> particularly since open-drain is pretty much a universal concept that all
> gpio controllers can support (unlike driver strength) and as I said above, it
> is already implicitly supported by gpiolib.

I am not sure about other soc but taking Tegra as example, the gpio 
controller is almost same for same series of soc. It does not very much 
about different version of the socs. The pins, number of pins. pin 
controls, pin is OD or not etc vary from variant of socs and so it is 
much more depends on the particular soc rather than  the major family.
Bringing pincontrol information in gpio driver will make the gpio driver 
complex which need to take care of every variant of chips.

>    The difference with this
> method is it would allow drivers like the gpio-i2c.c driver to set the
> flag at gpio request time and then be able to always use gpio_set_value()
> regardless of the pin mode.
>
> However, I'm not thrilled about adding things to the already-horrible sysfs
> abi.  Please drop that hunk entirely or put it into a separate patch so it
> doesn't block the core functionality.
>

I will split the change in two parts one for core driver and other for 
the sysfs interface if all changes are fine here.

> Have you though about support for lines that are pulled low instead of
> high?  Those aren't as common, but it is conceivable that some
> hardware would need it.
I think open drain pin should not be pulled low otherwise it will not be 
possible to make the pin as HIGH with the assumption that the OD pin 
should never be driven to HIGH

But if it is there in any case then it should be handle differently at  
client level without letting the gpio driver that it is open-drain.

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