Re: [PATCH 3/3] gpiolib: use chip->names for symlinks, always usegpioN for device names

[Artem Bityutskiy]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/