public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Ben Nizette <bn@niasdigital.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	dsilvers@simtec.co.uk
Subject: Re: [PATCH v2] GPIO: Add gpio_lookup
Date: Tue, 13 Oct 2009 15:13:53 -0700	[thread overview]
Message-ID: <200910131513.53851.david-b@pacbell.net> (raw)
In-Reply-To: <1255422669.5347.281.camel@ben-desktop>

On Tuesday 13 October 2009, Ben Nizette wrote:
> If gpios are going to be named, and it seems they are,

I'm not so sure of that.  Keep in mind that "name" implies, to me,
focussing on name-centric operation, with lookup and browsing.
Neither of those mechanisms is fundamental to what GPIOs solve.

So far I've not seen any use case that can't be addressed within
the current framework, which keys only on numeric IDs.  If we *did*
see such cases appear in real-world scenarios, we could explore
what that means.


> 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 why would we need such lookups in the first place?

In-kernel, they are not needed, for either static or dynamic ID
assignment schemes.  Just register the numbers so they're available
as needed.

For userspace, I think gpio_export_link() is the best way to
go ... it scopes the names sanely, so there's no requirement
for driver-provided labels to be globally unique.

- Dave


  reply	other threads:[~2009-10-13 22:21 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
2009-10-13 22:13         ` David Brownell [this message]
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=200910131513.53851.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=akpm@linux-foundation.org \
    --cc=bn@niasdigital.com \
    --cc=corbet@lwn.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