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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 Dec 2009 07:36:11 +0200
From:	Artem Bityutskiy <Artem.Bityutskiy@...ia.com>
To:	Greg KH <gregkh@...e.de>
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 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/