From: NeilBrown <neilb-l3A5Bk7waGM@public.gmane.org>
To: Benjamin Herrenschmidt
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Cc: Greg Kroah-Hartman
<gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
lkml <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: Strange location and name for platform devices when device-tree is used.
Date: Sat, 2 Nov 2013 10:45:05 +1100 [thread overview]
Message-ID: <20131102104505.34105cbb@notabene.brown> (raw)
In-Reply-To: <1383347425.28909.63.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 3059 bytes --]
On Sat, 02 Nov 2013 10:10:25 +1100 Benjamin Herrenschmidt
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org> wrote:
> On Fri, 2013-11-01 at 13:47 -0700, Greg Kroah-Hartman wrote:
>
> > > > On my device I seem to have some platform devices registered through
> > > > device-tree, and some registered through platform_device_add (e.g.
> > > > 'alarmtimer'). Guaranteeing they remain disjoint sets if the kernel is
> > > > allowed to evolve independently of the devicetree might be tricky....
> > > > Maybe we need "/sys/devices/platform" and "/sys/devices/dt_platform" ??
> > >
> > > No, I think device-tree created platform devices should go
> > > to /sys/devices/platform like the "classic" ones.
> > >
> > > The problem is really how to deal with potential name duplication. We
> > > could try to register, if we get -EEXIST (assuming sysfs returns the
> > > right stuff), try again with ".1" etc...
> >
> > How can there be device name collisions? All platform devices _should_
> > be named uniquely, if not, you have bigger problems...
>
> The problem is how to create a unique name for a platform device created
> from a device-tree node.
>
> Device tree nodes aren't necessarily uniquely named. They are unique
> under a given parent but that hierarchy isn't preserved when creating
> corresponding platform devices (and it would be very tricky to do so).
>
> Currently, we simply append a number to the name when creating them,
> which is obtained from a global counter.
>
> Neil is unhappy about that because on his specific hardware, the device
> has a unique name and thus we introduce a naming difference between
> device-tree usage and old-style "hard coded" board file usage.
It occurs to me that a different approach could solve my problem.
My problem stems from the fact that the name of the device on the
platform-bus is used as the name of the device in the "backlight" class.
As Greg writes elsewhere, depending on names with /sys/devices is not
supported - we need to accept that bus-names might change.
However names in class devices tend to be a lot more stable.
Several devices allow these to be explicitly set.
leds have 'label'
regulators has "regulator-name"
gpio-keys has 'label'.
I could just teach pwm_bl to allow a 'label' property which would be used in
place of the platform-bus device name when creating the class/backlight
device.
The maxim "you cannot trust names to remain stable in /sys/devices" can
justify both the movement of platform devices into /sys/devices/platform, and
the use of "label" rather than the device-name for creating the class device.
Does that sound convincing?
Thanks,
NeilBrown
>
> It would be nice if we could do something that only appends the "global
> number" at the end of the name if the name isn't already unique. Thus my
> proposal of trying first with the base name, and trying again if that
> returns -EEXIST in some kind of loop.
>
> Do you have a better idea ?
>
> Cheers,
> Ben.
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
WARNING: multiple messages have this Message-ID (diff)
From: NeilBrown <neilb@suse.de>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Grant Likely <grant.likely@linaro.org>,
Rob Herring <rob.herring@calxeda.com>,
devicetree@vger.kernel.org, lkml <linux-kernel@vger.kernel.org>
Subject: Re: Strange location and name for platform devices when device-tree is used.
Date: Sat, 2 Nov 2013 10:45:05 +1100 [thread overview]
Message-ID: <20131102104505.34105cbb@notabene.brown> (raw)
In-Reply-To: <1383347425.28909.63.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 3029 bytes --]
On Sat, 02 Nov 2013 10:10:25 +1100 Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Fri, 2013-11-01 at 13:47 -0700, Greg Kroah-Hartman wrote:
>
> > > > On my device I seem to have some platform devices registered through
> > > > device-tree, and some registered through platform_device_add (e.g.
> > > > 'alarmtimer'). Guaranteeing they remain disjoint sets if the kernel is
> > > > allowed to evolve independently of the devicetree might be tricky....
> > > > Maybe we need "/sys/devices/platform" and "/sys/devices/dt_platform" ??
> > >
> > > No, I think device-tree created platform devices should go
> > > to /sys/devices/platform like the "classic" ones.
> > >
> > > The problem is really how to deal with potential name duplication. We
> > > could try to register, if we get -EEXIST (assuming sysfs returns the
> > > right stuff), try again with ".1" etc...
> >
> > How can there be device name collisions? All platform devices _should_
> > be named uniquely, if not, you have bigger problems...
>
> The problem is how to create a unique name for a platform device created
> from a device-tree node.
>
> Device tree nodes aren't necessarily uniquely named. They are unique
> under a given parent but that hierarchy isn't preserved when creating
> corresponding platform devices (and it would be very tricky to do so).
>
> Currently, we simply append a number to the name when creating them,
> which is obtained from a global counter.
>
> Neil is unhappy about that because on his specific hardware, the device
> has a unique name and thus we introduce a naming difference between
> device-tree usage and old-style "hard coded" board file usage.
It occurs to me that a different approach could solve my problem.
My problem stems from the fact that the name of the device on the
platform-bus is used as the name of the device in the "backlight" class.
As Greg writes elsewhere, depending on names with /sys/devices is not
supported - we need to accept that bus-names might change.
However names in class devices tend to be a lot more stable.
Several devices allow these to be explicitly set.
leds have 'label'
regulators has "regulator-name"
gpio-keys has 'label'.
I could just teach pwm_bl to allow a 'label' property which would be used in
place of the platform-bus device name when creating the class/backlight
device.
The maxim "you cannot trust names to remain stable in /sys/devices" can
justify both the movement of platform devices into /sys/devices/platform, and
the use of "label" rather than the device-name for creating the class device.
Does that sound convincing?
Thanks,
NeilBrown
>
> It would be nice if we could do something that only appends the "global
> number" at the end of the name if the name isn't already unique. Thus my
> proposal of trying first with the base name, and trying again if that
> returns -EEXIST in some kind of loop.
>
> Do you have a better idea ?
>
> Cheers,
> Ben.
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
next prev parent reply other threads:[~2013-11-01 23:45 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-01 3:59 Strange location and name for platform devices when device-tree is used NeilBrown
2013-11-01 3:59 ` NeilBrown
2013-11-01 4:22 ` Benjamin Herrenschmidt
2013-11-01 4:27 ` Benjamin Herrenschmidt
2013-11-01 5:03 ` NeilBrown
2013-11-01 5:08 ` Benjamin Herrenschmidt
2013-11-01 18:04 ` Grant Likely
2013-11-01 18:04 ` Grant Likely
2013-11-01 20:33 ` Benjamin Herrenschmidt
2013-11-15 7:37 ` Grant Likely
2013-11-15 7:37 ` Grant Likely
[not found] ` <20131101180459.81793C40A28-WNowdnHR2B42iJbIjFUEsiwD8/FfD2ys@public.gmane.org>
2013-11-01 20:48 ` Greg Kroah-Hartman
2013-11-01 20:48 ` Greg Kroah-Hartman
2013-11-01 20:47 ` Greg Kroah-Hartman
2013-11-01 20:47 ` Greg Kroah-Hartman
[not found] ` <20131101204749.GA19662-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2013-11-01 23:09 ` Benjamin Herrenschmidt
2013-11-01 23:09 ` Benjamin Herrenschmidt
2013-11-02 15:58 ` Greg Kroah-Hartman
2013-11-02 15:58 ` Greg Kroah-Hartman
[not found] ` <20131102155824.GG23938-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2013-11-02 20:22 ` Benjamin Herrenschmidt
2013-11-02 20:22 ` Benjamin Herrenschmidt
2013-11-02 20:40 ` Greg Kroah-Hartman
2013-11-02 20:40 ` Greg Kroah-Hartman
[not found] ` <20131102204021.GA13994-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2013-11-03 21:12 ` Benjamin Herrenschmidt
2013-11-03 21:12 ` Benjamin Herrenschmidt
2013-11-03 21:09 ` NeilBrown
2013-11-01 23:10 ` Benjamin Herrenschmidt
2013-11-01 23:10 ` Benjamin Herrenschmidt
2013-11-01 23:45 ` NeilBrown [this message]
2013-11-01 23:45 ` NeilBrown
[not found] ` <20131102104505.34105cbb-wvvUuzkyo1EYVZTmpyfIwg@public.gmane.org>
2013-11-04 8:56 ` Thierry Reding
2013-11-04 8:56 ` Thierry Reding
2013-11-15 7:44 ` Grant Likely
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131102104505.34105cbb@notabene.brown \
--to=neilb-l3a5bk7wagm@public.gmane.org \
--cc=benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.