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, 07 Mar 2011 18:28:53 -0600
From:	Peter Tyser <ptyser@...-inc.com>
To:	Grant Likely <grant.likely@...retlab.ca>
Cc:	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>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Alexander Stein <alexander.stein@...tec-electronic.com>,
	Ryan Mallon <ryan@...ewatersys.com>
Subject: Re: [PATCH v5 1/4] gpiolib: Add "unknown" direction support

On Sun, 2011-03-06 at 23:52 -0700, Grant Likely wrote:
> On Sun, Mar 06, 2011 at 08:43:05PM -0600, Peter Tyser wrote:
> > > The thing about gpios is that how they are used is entirely dependant
> > > on what they are wired up to.  There is no avoiding the fact that you
> > > *absolutely* must understand the usage model before even considering
> > > fiddling with a gpio (ignoring the "I wonder what this knob does"
> > > use-case such as when reverse engineer a board).  So, while it is nice
> > > to have an 'unknown' state for sysfs to report, it is certainly not
> > > required.  The model still remains that the pin direction must be set
> > > before (or at the same time as) reading/writing the pin.
> > 
> > As is, even if someone knows about the GPIO wiring on their board, they
> > have to know Linux has a "rule" that "before I can use a GPIO, I have to
> > explicitly set its direction, even if the current reported direction is
> > what I want".  A number of our customers have tried to use a GPIO which
> > states its an 'input' as an input after exporting it, which is
> > completely logical.  But it doesn't work, because its not really an
> > input...  Why not set the direction accurately as 'unknown' so users
> > intuitively know they have to set the direction before using it?  You
> > also mention that it would be a nice feature above, so why not include
> > it?
> 
> I don't like what it does to the implementation, and I'd rather make
> drivers provide accurate data at the outset.

Agreed that ideally drivers should provide accurate data at the outset.
The original patch attempted to move in that direction by making it
optional, and didn't touch the concept of "unknown" directions.  Alan
and others argued we should add support for the "unknown" direction,
which spawned this patch.

To be clear, are you saying you won't accept a patch adding an "unknown"
direction?  Or would you be OK with under circumstance X?  If so, what
is circumstance X?

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ