linux-kernel - Re: [PATCH v5 2/4] gpiolib: Add ability to get GPIO 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]

Message-ID: <1299711236.6057.2125.camel@petert>
Date:	Wed, 09 Mar 2011 16:53:56 -0600
From:	Peter Tyser <ptyser@...-inc.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Grant Likely <grant.likely@...retlab.ca>,
	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 v5 2/4] gpiolib: Add ability to get GPIO direction

On Tue, 2011-03-08 at 12:13 +0000, Alan Cox wrote:
> > I don't object to a callback hook.  My objection is how it is bodged
> > on to work around limitations to the direction being cached in the
> > flags variable.  I want to see a solution that either depends entirely
> > on the callback, or completely fixes the problems with the cached
> > value by allowing the driver to update it.
> 
> Doing it all by callback might actually fix a lot of the problems because
> it can handle all kinds of 'unknowns'. If the callbacks for set/get
> optionally pass a char buffer as well even the /proc interface just comes
> out in the wash as the device can return a string to populate the status
> or to be parsed (obviously with most h/w using the default method which
> is in/out)

I like the callback-only implementation also.

> However who then does the enforcement of gpio_foo calls if the flag is
> not cached, does that end up in each driver or is there still a cache of
> some form ?

What enforcement are you referring to?  I was envisioning no cached
directions at the gpiolib level,  eg replace all the current references
that check desc->flag for direction with calls to chip->get_direction().
If a GPIO chip's hardware didn't support reading the direction of a pin
(eg the pcf857x chip), it would have to use its own caching to maintain
an accurate representation of its pins directions.  Is this concept in
line with what you were picturing?

Best,
Peter

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