Message-Id: <200910131506.05851.david-b@pacbell.net>
Date:	Tue, 13 Oct 2009 15:06:05 -0700
From:	David Brownell <david-b@...bell.net>
To:	Jonathan Corbet <corbet@....net>
Cc:	Ben Nizette <bn@...sdigital.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	dsilvers@...tec.co.uk
Subject: Re: [PATCH v2] GPIO: Add gpio_lookup

On Monday 12 October 2009, Jonathan Corbet wrote:
> On Mon, 12 Oct 2009 17:11:44 +1100
> Ben Nizette <bn@...sdigital.com> wrote:
> 
> > 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?
> 
> That's true in a situation where you've one One Platform to Bind Them
> All, yes.

What do you mean by "platform" though?  Clearly not what I mean!
You make it sound like an evil place, Barad-dûr hosting an assult
on the Forces Of Light!  :)

If you mean to imply that only statically assigned GPIO numbers
can work, I'll disagree.


> But if you have (say) GPIOs provided by a PCI-connected 
> peripheral which are needed in (say) a camera driver, there is no one
> platform which can manage all those GPIO numbers.

The basic trick is to have gpio chip drivers call back with enough
information to start hooking up the GPIO signals to consumers.  The
OS is only responsible for remembering things ... like how to connect
a phone number or IP address to the right destination.

See for example the pcf875x driver.  When it registers, it reports via
callback that the stage is setup() for performance.  Later it can report
that it's time to teardown() that part of the show.

Whatever sets up that PCI board has to know basically what's there, and
when it sets up the gpio chips it can provide the callbacks needed to
hook up e.g. "base + 19" as the "camera active" LED.  No lookup() needed.

Notice also how doing it that way provides clean ways to sequence the
startup and teardown of complex hardware stacks.  (Too many drivers tend
to ignore those issues, IMO, and for complex hardware modules that can
cause much trouble.)


> In particular, I've 
> done a driver for viafb-based GPIOs; these devices can show up in any
> of a number of x86-based systems.  I honestly don't know why it would
> make sense to try to hardware numbers to these GPIOs when using names
> and dynamic numbering is so much more flexible - and we are already
> tracking the names.

There are video drivers that solve this without needing name-to-ID
style lookups.  I recall discussing them well over a year ago... the
numbering is dynamic, yes.


> Perhaps it would make sense to implement a proper namespace layer for
> GPIOs

Today, that namespace is numeric.  And as far as I know, it's
sufficient ... although it's not intended for browsing, any more
than, say, phone numbers or IP address numbers.


> rather than continuing to grow something which evidently sneaked 
> in through the back door.  Until that's done, though, I think this
> patch is useful.  But it it's really unwanted I'll find some other way.

All *names* for GPIOs snuck through the back door ... except for
the labels in /sys/kernel/debug/gpio, which are diagnostic-only
and not unique.  And the gpio_export_link(), with sysfs names that
are unique within a clearly-defined driver context.

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