linux-kernel - Re: [PATCH 1/3] gpiolib: Add ability to get GPIO pin direction

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:	Mon, 14 Feb 2011 11:04:41 -0700
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Peter Tyser <ptyser@...-inc.com>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>, linux-kernel@...r.kernel.org,
	Alek Du <alek.du@...el.com>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Eric Miao <eric.y.miao@...il.com>,
	"Uwe Kleine-K?nig" <u.kleine-koenig@...gutronix.de>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>,
	Joe Perches <joe@...ches.com>
Subject: Re: [PATCH 1/3] gpiolib: Add ability to get GPIO pin direction

On Mon, Feb 14, 2011 at 10:45 AM, Peter Tyser <ptyser@...-inc.com> wrote:
>> > We need four states for a gpio pin direction though. A pin can be
>> >
>> > - input
>> > - output
>>
>> There are actually multiple output modes that a specific gpio
>> controller could implement, but the gpio api only has a boolean
>> understanding of output.  I don't know if it is really worthwhile to
>> try and encode all the possible configurations in this API.
>>
>> > - unknown (hardware lacks get functionality and it has not been set by
>> >  software yet)
>
> I'm not sure how we could handle unknown directions in a better way.  We
> really should know the direction by this point for most (all?) GPIO
> chips.  I'd think the proper fix would be to make sure we can detect a
> direction for all chips - either by reading hardware bits or by having
> the platform code let us know (eg pdata->n_latch in pcf857x.c).  If you
> have a suggestion about how unknown pins should be used, I can look into
> it and submit a follow up patch.

Does it really matter?  Sure it's *nice* to have the current status
information if the driver can easily get it, but it probably isn't
critical.  Any user of the pin should be putting the pin in the mode
it needs regardless of the initial state.

>
>> > - alt_func (pin is in use for some other purpose)
>>
>> What is the use-case for alt_func?  From the point of view of a GPIO
>> driver, I don't think it cares if the pin has been dedicated to
>> something else.  It can twiddle all it wants, but if the pin is routed
>> to something else then it won't have any external effects (pin mux is
>> often a separate logic block from the gpio controller).  Also with
>> GPIOs, the engineers fiddling with them *really* needs to know what
>> the gpios are routed to.  It is highly unlikely to have any kind of
>> automatic configuration of gpios; ie. if it isn't wired as a gpio,
>> then don't go twiddling it.
>
> Additionally, for this case I thought the low level GPIO driver should
> implement a request() function to prevent a non-GPIO pin from being used
> in the first place.  Eg like chip_gpio_request() in cs5535-gpio.c, or
> ichx_gpio_request() in patch 3 of this series.

Yes, *if* a driver has the knowledge that a pin is unusable, then it
should not allow the pin to be requested.

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