linux-kernel - Re: [PATCH v2] GPIO: Add gpio

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, 12 Oct 2009 17:11:44 +1100
From:	Ben Nizette <bn@...sdigital.com>
To:	Jonathan Corbet <corbet@....net>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	David Brownell <dbrownell@...rs.sourceforge.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	dsilvers@...tec.co.uk
Subject: Re: [PATCH v2] GPIO: Add gpio_lookup

On Sat, 2009-10-10 at 13:53 -0600, Jonathan Corbet wrote:
> GPIO: add gpio_lookup()
> 
> GPIOs have names associated with them, but drivers cannot use those names
> and must thus rely on hardwired GPIO numbers.  That, in turn, makes dynamic
> assignment hard to use.  This patch adds a little function gpio_lookup()
> which returns the GPIO number associated with a name.
> 

OK for something supposedly basic, all this gpio stuff is getting messy.
The gpio framework was written to use gpio numbers as they were
recognised as being common to all possible implementations of the
framework.  Now gpiolib, one implementation (ok I think currently the
only implementation) of that framework, has the ability to have names
associated with the gpios it handles so userspace can get a better idea
of which gpio are which.  This is kind of OK (see below) because gpiolib
and gpio-sysfs are inextricably linked.  With the addition of this
patch, drivers are going to start not depending on the gpio framework
but on an implementation of that framework - gpiolib.  Or at least
require that all future implementations track this dual namespace.

I didn't notice Daniel's original patch fly by otherwise I would have
said something at the time, but storing the names at the chip level
seems an odd idea.  Given that at that stage they were only for sysfs
id, why not just give them as an argument to gpio_export()?

Back to this patch though, the gpio names have to come from the platform
code via some platform_data for the gpio chip [1], the driver then looks
up that pre-defined name to find the gpio number.  Why not just pass the
gpio number straight to the end device driver through platform_data and
bypass the middle-man?

At a higher level, there have been a number of pushes recently; for one
reason or another people really really seem to want the dual number/name
namespace inside the kernel.  With this patch we're at the stage where
this is true and gpiolib has functionality outside the gpio framework
concepts.  In order to keep drivers properly cross-platform we have some
options:  We can keep adding concepts and required functionality to the
gpio framework interface, recognise that some drivers won't be quite as
cross-platform as they could/should be or simply note that it's now been
2.5 years since the gpio framework and gpiolib were merged and it's
still the only implementation; maybe it's time to ditch the distinction
and simply make gpiolib /the/ way you wire up gpios.

David's call really, thoughts?

	--Ben.

[1] which is ugly for at least avr32, the only platform I know
intimately, but not my current point

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