Message-ID: <20091211054614.GA23644@suse.de>
Date:	Thu, 10 Dec 2009 21:46:14 -0800
From:	Greg KH <gregkh@...e.de>
To:	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
Cc:	David Brownell <david-b@...bell.net>,
	Jani Nikula <ext-jani.1.nikula@...ia.com>,
	dbrownell@...rs.sourceforge.net, linux-kernel@...r.kernel.org,
	dsilvers@...tec.co.uk, ben@...tec.co.uk, akpm@...ux-foundation.org
Subject: Re: [PATCH 3/3] gpiolib: use chip->names for symlinks, always use
	gpioN for device names

On Fri, Dec 11, 2009 at 07:36:11AM +0200, Artem Bityutskiy wrote:
> On Thu, 2009-12-10 at 20:38 -0800, Greg KH wrote:
> > 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.
> 
> User-space does not know which GPIO number is what. E.g., is the
> "power_button" GPIO number 6 or 99? It just does not have this
> information.
> 
> Kernel knows this, either because it was compiled for a specific board
> revision, or it got this information from the bootloader.
> 
> And the whole idea is to make kernel export this name. Currently, the
> kernel exports only the numbers in sysfs, which is not enough.

Then export a file with the name somewhere as well.  Why not put that in
the directory you were going to point the symlink at?

> And because gpiolib is designed as it is designed, we found that having
> additional link in /sys/class/gpio is the nicest solution from gpiolib's
> POW. It just fits naturally to the existing design.
> 
> And no, we do not have per-gpio struct device, so we cannot add a new
> "name" attribute there. We need to either persuade you to accept our
> solution or make you take closer look at gpoiolib subsystem and suggest
> us the right way to go :-)

If you don't have a struct device, then what are you going to generate a
symlink to?

And sorry, I'm swamped with other work right now, I honestly have no
time to dig into the gpio subsystem.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists