Subject: Re: [PATCH 3/3] gpiolib: use chip->names for symlinks, always use
 gpioN for device names
From: Artem Bityutskiy <Artem.Bityutskiy@nokia.com>
Reply-To: Artem.Bityutskiy@nokia.com
To: Greg KH <gregkh@suse.de>
Cc: David Brownell <david-b@pacbell.net>,
       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, akpm@linux-foundation.org
In-Reply-To: <20091211043849.GA18007@suse.de>
References: <cover.1260364108.git.ext-jani.1.nikula@nokia.com>
	 <200912101939.30446.david-b@pacbell.net> <20091211034711.GA2773@suse.de>
	 <200912102013.59329.david-b@pacbell.net>  <20091211043849.GA18007@suse.de>
Content-Type: text/plain; charset="UTF-8"
Organization: Nokia
Date: Fri, 11 Dec 2009 07:36:11 +0200
Message-Id: <1260509771.12346.138.camel@localhost>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2644
Lines: 61

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.

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 :-)

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

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