public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ben Nizette <bn@niasdigital.com>
To: Jonathan Corbet <corbet@lwn.net>
Cc: LKML <linux-kernel@vger.kernel.org>,
	David Brownell <dbrownell@users.sourceforge.net>,
	Andrew Morton <akpm@linux-foundation.org>,
	dsilvers@simtec.co.uk
Subject: Re: [PATCH v2] GPIO: Add gpio_lookup
Date: Tue, 13 Oct 2009 19:31:09 +1100	[thread overview]
Message-ID: <1255422669.5347.281.camel@ben-desktop> (raw)
In-Reply-To: <20091012092331.45d7e71b@bike.lwn.net>

On Mon, 2009-10-12 at 09:23 -0600, Jonathan Corbet wrote:
> On Mon, 12 Oct 2009 17:11:44 +1100
> Ben Nizette <bn@niasdigital.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.  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.  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.
> 
> Perhaps it would make sense to implement a proper namespace layer for
> GPIOs 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.
> 

Fair enough; I hadn't seen gpio controllers on such buses before but
that makes sense.  If the naming information isn't coming from platform
code but from some driver itself this seems fairly sane.

If gpios are going to be named, and it seems they are, then personally
I'd like to see the names field of struct gpio_chip go and a proper
namespace layer inserted.  Something which allows gpio_name() and
gpio_lookup() and decentralises that responsibility would be nice (the
chip could call gpio_name itself if it has reason).  That code could be
common to all gpio framework implementations.

But a) I don't have the hours to do this myself and b) it's really
David's call, I'm just an interested bystander :-)

	--Ben




  reply	other threads:[~2009-10-13  8:31 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-10 19:48 [PATCH] GPIO: Add gpio_lookup Jonathan Corbet
2009-10-10 19:53 ` [PATCH v2] " Jonathan Corbet
2009-10-12  6:11   ` Ben Nizette
2009-10-12 15:23     ` Jonathan Corbet
2009-10-13  8:31       ` Ben Nizette [this message]
2009-10-13 22:13         ` David Brownell
2009-10-13 22:06       ` David Brownell
2009-10-13 22:05     ` David Brownell
2009-10-13 21:10   ` David Brownell
2009-10-13 22:28     ` Jonathan Corbet
2009-10-13 22:53       ` David Brownell
2009-10-14 12:53         ` Mark Brown
2009-10-13 18:05 ` [PATCH] " Andrew Morton
2009-10-13 18:19   ` Jonathan Corbet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1255422669.5347.281.camel@ben-desktop \
    --to=bn@niasdigital.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=dbrownell@users.sourceforge.net \
    --cc=dsilvers@simtec.co.uk \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox