From: Greg KH <gregkh@suse.de>
To: David Brownell <david-b@pacbell.net>
Cc: Jani Nikula <ext-jani.1.nikula@nokia.com>,
dbrownell@users.sourceforge.net, linux-kernel@vger.kernel.org,
dsilvers@simtec.co.uk, ben@simtec.co.uk,
Artem.Bityutskiy@nokia.com, akpm@linux-foundation.org
Subject: Re: [PATCH 3/3] gpiolib: use chip->names for symlinks, always use gpioN for device names
Date: Thu, 10 Dec 2009 20:38:49 -0800 [thread overview]
Message-ID: <20091211043849.GA18007@suse.de> (raw)
In-Reply-To: <200912102013.59329.david-b@pacbell.net>
On Thu, Dec 10, 2009 at 08:13:58PM -0800, David Brownell wrote:
> On Thursday 10 December 2009, Greg KH wrote:
> >
> > > IMO a "good" solution in this space needs to accept that
> > > those names are not going to be globally unique ... but
> > > that they'll be unique within some context, of necessity.
> > >
> > > If Greg doesn't want to see those names under classes,
> > > so be it ... but where should they then appear?
> >
> > 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?
>
> I want a concrete example. Those chip->names things don't
> seem helpful to me though...
>
> If for example I were building a JTAG adapter on Linux, it
> might consist of a spidev node (chardev) plus a handful of
> GPIOs. So "the device directory" would be the sysfs home
> of that spidev node (or some variant)? And inside that
> directory would be files named after various signals that
> are used as GPIOs ... maybe SRST, TRST, and DETECT to start
> with? Holding some cookie that gets mapped to those GPIO's
> sysfs entries?
Um, I really don't know, as I don't know the GPIO subsystem, nor why you
all have this problem in the first place :)
I also find it funny that you think changing the kernel is easier than
userspace, that's a strange situation.
Anyway, I assumed that you already have a struct device for the GPIO
devices, right? Put it in there was what I was thinking, but as I don't
understand your current layout, I really don't know.
> I confess I'd still think a symlink from that directory
> to the real GPIO would be easier to work with...
No, don't do that, no symlinks from a class please.
thanks,
greg k-h
next prev parent reply other threads:[~2009-12-11 4:38 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 [this message]
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=20091211043849.GA18007@suse.de \
--to=gregkh@suse.de \
--cc=Artem.Bityutskiy@nokia.com \
--cc=akpm@linux-foundation.org \
--cc=ben@simtec.co.uk \
--cc=david-b@pacbell.net \
--cc=dbrownell@users.sourceforge.net \
--cc=dsilvers@simtec.co.uk \
--cc=ext-jani.1.nikula@nokia.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.