linux-kernel - Re: Strange location and name for platform devices when device-tree is used.

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]

Message-ID: <1383513150.4776.33.camel@pasglop>
Date:	Mon, 04 Nov 2013 08:12:30 +1100
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	NeilBrown <neilb@...e.de>, Grant Likely <grant.likely@...aro.org>,
	Rob Herring <rob.herring@...xeda.com>,
	devicetree@...r.kernel.org, lkml <linux-kernel@...r.kernel.org>
Subject: Re: Strange location and name for platform  devices when
 device-tree is used.

On Sat, 2013-11-02 at 13:40 -0700, Greg Kroah-Hartman wrote:
> On Sun, Nov 03, 2013 at 07:22:10AM +1100, Benjamin Herrenschmidt wrote:
> > On Sat, 2013-11-02 at 08:58 -0700, Greg Kroah-Hartman wrote:
> > > Just loop through all the platform devices before registering it to
> > > determine if you need to do this, the platform code can do this just
> > > fine.  If you try to register a duplicate name with the driver core,
> > > odds are it will complain loudly, so don't do that.
> > 
> > But that loop + registration is racy ... oh well, we might do something
> > better with Neil's idea of labels instead.
> 
> How is it racy?  Only one platform device should be allowed to be
> registered at a time, there is a per-bus lock that should be used to
> enforce this, right?

No, platform devices can be registered from different "sources" and
possibly from different threads. There's no fundamental reason why the
registration would have to be serialized accross all possible entities
capable of crating them (though it generally is at the moment).

There's no global mutex used by every piece of code in the kernel that
might create/register a platform device.

However, let's leave that aside for now and go back to the original
issue because that's probably worth discussing a bit more.

Normally, a device "name" in sysfs shouldn't be relevant to user space,
I think we agree. Devices get identified by function (class typically)
and additional functional attributes associated with them.

For platform devices, things get a bit more murky though, ie, let's say
we have a backlight device, that's good ... but nothing tells us what
specific display it controls (there could be more than one in a system).

The device-tree typically provide such cross linking, but sysfs doesn't.

My understanding, and Neil correct me if I'm wrong, is that it's become
a case where userspace has started relying on the "name" of the platform
device to identify it's specific function within a class. Is that
correct ? IE. Which screen this backlight is associated to isn't an
explicit information provided somewhere in sysfs but something intuited
by user space tools based on the platform device name.

Greg, I'm not saying that's a good thing btw :-) I'm just trying to get
a grasp of the exact scope of the problem.

Now, there's a way for userspace to sort that out using device-tree of
course, they can parse /proc/device-tree, find the linkage, and related
the device-tree nodes to the corresponding platform devices (are we
creating the devspec files btw ?)

But that only works for DT-created platform devices, not the hand-made
ones.

Another option would be for classes that are meaningless "seldomly" such
as a backlight control (ie, it's always attached to *something*, a
screen for example, etc...) to associate a separate name which isn't the
device name in sysfs but a "label" as Neil proposed. In this case we'd
need to add an attribute but I would object to this being specific to
pwm_bl, instead of should generally be an attribute of all backlight
devices.

This could then be class specific... but should it be ? it might
actually be a useful thing to generally be able to label devices,
especially in the embedded world.

But that's just one option ... the point remains, people seem to be
relying on platform device names in sysfs and yes, that's not right, but
we need to understand why they do it and what's the right way to do to
replace that practice. 

Cheers,
Ben.

--
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/