The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Jani Nikula <ext-jani.1.nikula@nokia.com>
To: ext Ben Nizette <bn@niasdigital.com>,
	David Brownell <david-b@pacbell.net>
Cc: Greg KH <gregkh@suse.de>,
	"dbrownell@users.sourceforge.net"
	<dbrownell@users.sourceforge.net>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dsilvers@simtec.co.uk" <dsilvers@simtec.co.uk>,
	"ben@simtec.co.uk" <ben@simtec.co.uk>,
	"Bityutskiy Artem (Nokia-D/Helsinki)"
	<Artem.Bityutskiy@nokia.com>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH 3/3] gpiolib: use chip->names for symlinks, always use gpioN for device names
Date: Mon, 14 Dec 2009 13:16:03 +0200	[thread overview]
Message-ID: <1260789363.25352.7358.camel@jani-desktop> (raw)
In-Reply-To: <1260508357.12048.217.camel@ben-desktop>

Hi David and Ben -

On Fri, 2009-12-11 at 06:12 +0100, ext Ben Nizette wrote:
> On Thu, 2009-12-10 at 19:47 -0800, Greg KH wrote:
> > As a sysfs file within the device directory called 'name'?  Then just
> > grep through the tree to find the right device, that also handles
> > duplicates just fine, right?
> 
> Well it bunts the handling of duplicates to who ever is grepping but
> yea, sounds good.  The user script can sanity-check it's results against
> the controlling gpio-chip if need be.  In fact, maybe symlink from
> gpioN/chip back to gpio-chipY could be useful?  A bit redundant though,
> as you can check using the number ranges..
> 
> In fact I thought I had a patch to create /sys/class/gpio/gpioN/name at
> some stage..  Can't find it though, oh well.

Ben, could you please look harder? ;)

If we were to add /sys/class/gpio/gpioN/name attribute, what would be
the optimal source for the names?

I'd prefer a scheme where a) the name could be set in both board files
and drivers, the latter overriding the former as necessary, and b) the
name could be set without actually requesting the gpio, so you could set
all known names in board files without interfering with the drivers.

AFAICS this would pretty much lead to adding a pair of new functions
gpio_set_name() and gpio_get_name(), which would work also for gpios
that haven't been requested. (IDR lookup Ben mentioned in another mail
sounds good, though there's the problem you can't specify the id - this
is why gpio_setup_irq() uses the flags for storing the id.)

Here are some other alternatives I could think of, but none of them
sound good to me:

1) Add new function gpio_export_name() to export with a certain name
attribute. Leads to two ways of exporting.

2) Add 'name' parameter to gpio_export() to export with a certain name
attribute. Changes an existing interface.

3) Use 'label' in gpio_request() for name attribute. Stores names also
for gpios that are never exported, wastes a pointer per gpio in
gpio_desc.

4) Use chip->names. Wastes a pointer per gpio even if one name is used,
almost the same as adding char *name to struct gpio_desc. Not convenient
to use, at least in OMAP.

Opinions?


BR,
Jani.



  reply	other threads:[~2009-12-14 11:17 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-09 13:49 [PATCH 0/3] gpiolib: gpio naming in sysfs Jani Nikula
2009-12-09 13:49 ` [PATCH 1/3] device class: add symlink creation helpers Jani Nikula
2009-12-10  2:49   ` Greg KH
2009-12-09 13:49 ` [PATCH 2/3] gpiolib: add support for having symlinks under gpio class directory Jani Nikula
2009-12-10  2:48   ` Greg KH
2009-12-10 14:32     ` Jani Nikula
2009-12-10 14:49       ` Greg KH
2009-12-10 15:17         ` Kay Sievers
2009-12-10 15:24           ` Greg KH
2009-12-11  8:41         ` Jani Nikula
2009-12-11 15:38           ` Greg KH
2009-12-11  3:35       ` David Brownell
2009-12-09 13:49 ` [PATCH 3/3] gpiolib: use chip->names for symlinks, always use gpioN for device names Jani Nikula
2009-12-11  3:39   ` David Brownell
2009-12-11  3:47     ` Greg KH
2009-12-11  4:13       ` David Brownell
2009-12-11  4:38         ` Greg KH
2009-12-11  5:13           ` David Brownell
2009-12-11  5:18             ` Greg KH
2009-12-11  5:36           ` Artem Bityutskiy
2009-12-11  5:46             ` Greg KH
2009-12-11  7:51               ` Artem Bityutskiy
2009-12-11 15:36                 ` Greg KH
2009-12-11 13:23             ` [PATCH]crypto: Fix complain about lack test for internal used algorithm Youquan,Song
2009-12-11  6:04               ` Herbert Xu
2009-12-19  9:40                 ` Youquan,Song
2009-12-19  2:29                   ` Herbert Xu
2009-12-19 15:07                     ` Youquan,Song
2009-12-19  9:42                       ` Herbert Xu
2009-12-21 10:38                         ` [Resend PATCH]crypto: " Youquan,Song
2009-12-23 11:59                           ` Herbert Xu
2009-12-11  5:22         ` [PATCH 3/3] gpiolib: use chip->names for symlinks, always use gpioN for device names Ben Nizette
2009-12-11  5:12       ` Ben Nizette
2009-12-14 11:16         ` Jani Nikula [this message]
2009-12-14 22:27           ` Ben Nizette
2009-12-10  0:02 ` [PATCH 0/3] gpiolib: gpio naming in sysfs Andrew Morton

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=1260789363.25352.7358.camel@jani-desktop \
    --to=ext-jani.1.nikula@nokia.com \
    --cc=Artem.Bityutskiy@nokia.com \
    --cc=akpm@linux-foundation.org \
    --cc=ben@simtec.co.uk \
    --cc=bn@niasdigital.com \
    --cc=david-b@pacbell.net \
    --cc=dbrownell@users.sourceforge.net \
    --cc=dsilvers@simtec.co.uk \
    --cc=gregkh@suse.de \
    --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