public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: Jani Nikula <ext-jani.1.nikula@nokia.com>
Cc: ext 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 2/3] gpiolib: add support for having symlinks under gpio class directory
Date: Thu, 10 Dec 2009 19:35:01 -0800	[thread overview]
Message-ID: <200912101935.01974.david-b@pacbell.net> (raw)
In-Reply-To: <1260455537.25352.1762.camel@jani-desktop>

On Thursday 10 December 2009, Jani Nikula wrote:
> GPIOs can be exported to gpiolib sysfs at /sys/class/gpio/ like this:
> 
> # ls -l /sys/class/gpio/
> --w-------    1 root     0            4096 Jan  1 00:00 export
> lrwxrwxrwx    1 root     0               0 Jan  1 00:00 gpio25 -> ../../devices/virtual/gpio/gpio25
> lrwxrwxrwx    1 root     0               0 Jan  1 00:00 gpio38 -> ../../devices/virtual/gpio/gpio38
> ...

Hmm, ISTR they don't always appear as "virtual" ... though that's
pretty much irrelevant to the larger point you're making.  Even
when there are real device nodes for the gpio chips parenting any
given GPIOs, they end up in fairly un-useful parts of the device
tree (in terms of being related to something more significant than
the random wires that were handy to the hardware designer).


> The GPIO lines may and do change from board revision to another. For
> example a power button's GPIO number might be 25 in board rev 1.0 but 66
> in board rev 1.1.
> 
> We want to assign symbolic names to GPIO lines and hide the numbering
> changes from userspace, because it is very painful to amend userspace
> for every board revision.

Related:  these are part of what one might call "composite devices",
which are crafted using a component from this subsystem, one from that,
a few from over there, and so on.  They don't properly belong in any
single location in the device tree.  Some level of symlinking seems
inevitable.

And no, a full fledged chardev node is inappropriate so I don't
see udev as able to help out.


  parent reply	other threads:[~2009-12-11  3:34 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 [this message]
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
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=200912101935.01974.david-b@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=Artem.Bityutskiy@nokia.com \
    --cc=akpm@linux-foundation.org \
    --cc=ben@simtec.co.uk \
    --cc=dbrownell@users.sourceforge.net \
    --cc=dsilvers@simtec.co.uk \
    --cc=ext-jani.1.nikula@nokia.com \
    --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