From: Frank Rowand <frowand.list-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Benjamin Herrenschmidt
<benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>
Subject: Re: [RFC] Add of_path property for all devices with a node
Date: Wed, 12 Nov 2014 20:28:52 -0800 [thread overview]
Message-ID: <54643384.5030309@gmail.com> (raw)
In-Reply-To: <1415342031.4925.27.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
On 11/6/2014 10:33 PM, Benjamin Herrenschmidt wrote:
> Hey folks ! This is not (yet) a formal patch submission but...
>
> So I've been annoyed lately with having a bunch of devices such as i2c
> eeproms (for use by VPDs, server world !) and other bits and pieces that
> I want to be able to identify from userspace, and possibly provide
> additional data about from FW.
>
> Basically, it boils down to correlating the sysfs device with the OF
> tree device node, so that user space can use device-tree info such as
> additional "location" or "label" (or whatever else we can come up with)
> propreties to identify a given device, or get some attributes of use
> about it, etc...
>
> Now, so far, we've done that in some subsystem in a fairly ad-hoc basis
> using "devspec" properties. For example, PCI creates them if it can
> correlate the probed device with a DT node. Some powerpc specific busses
> do that too.
>
> However, i2c doesn't and it would be nice to have something more generic
> since technically any device can have a corresponding device tree node.
>
> So I came up with this patch, it seems to work well for me. I'm adding
> an "of_path" attribute to not conflict with the existing "devspec" one
> just for the sake of this experiment (plus "devspec" sucks). Long run,
> we might want to use of_path and leave a "devspec" symlink to of_path on
> the few busses that currently have devspec (pci and some powerpc
> specific ones).
>
> Comments ?
>
> Cheers,
> Ben.
If I understand correctly, that information is already available in
the file uevent. For example, if I apply your patch, at least
for a simple path, I see the same path name in uevent as in of_path:
$ cd /sys/devices/soc/f9824900.sdhci
$ cat of_path
/soc/sdhci@f9824900
$ grep OF_FULLNAME uevent | cut -d"=" -f2
/soc/sdhci@f9824900
-Frank
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Frank Rowand <frowand.list@gmail.com>
To: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: devicetree@vger.kernel.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Rob Herring <robherring2@gmail.com>,
Arnd Bergmann <arnd@arndb.de>
Subject: Re: [RFC] Add of_path property for all devices with a node
Date: Wed, 12 Nov 2014 20:28:52 -0800 [thread overview]
Message-ID: <54643384.5030309@gmail.com> (raw)
In-Reply-To: <1415342031.4925.27.camel@kernel.crashing.org>
On 11/6/2014 10:33 PM, Benjamin Herrenschmidt wrote:
> Hey folks ! This is not (yet) a formal patch submission but...
>
> So I've been annoyed lately with having a bunch of devices such as i2c
> eeproms (for use by VPDs, server world !) and other bits and pieces that
> I want to be able to identify from userspace, and possibly provide
> additional data about from FW.
>
> Basically, it boils down to correlating the sysfs device with the OF
> tree device node, so that user space can use device-tree info such as
> additional "location" or "label" (or whatever else we can come up with)
> propreties to identify a given device, or get some attributes of use
> about it, etc...
>
> Now, so far, we've done that in some subsystem in a fairly ad-hoc basis
> using "devspec" properties. For example, PCI creates them if it can
> correlate the probed device with a DT node. Some powerpc specific busses
> do that too.
>
> However, i2c doesn't and it would be nice to have something more generic
> since technically any device can have a corresponding device tree node.
>
> So I came up with this patch, it seems to work well for me. I'm adding
> an "of_path" attribute to not conflict with the existing "devspec" one
> just for the sake of this experiment (plus "devspec" sucks). Long run,
> we might want to use of_path and leave a "devspec" symlink to of_path on
> the few busses that currently have devspec (pci and some powerpc
> specific ones).
>
> Comments ?
>
> Cheers,
> Ben.
If I understand correctly, that information is already available in
the file uevent. For example, if I apply your patch, at least
for a simple path, I see the same path name in uevent as in of_path:
$ cd /sys/devices/soc/f9824900.sdhci
$ cat of_path
/soc/sdhci@f9824900
$ grep OF_FULLNAME uevent | cut -d"=" -f2
/soc/sdhci@f9824900
-Frank
next prev parent reply other threads:[~2014-11-13 4:28 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-07 6:33 [RFC] Add of_path property for all devices with a node Benjamin Herrenschmidt
2014-11-07 6:33 ` Benjamin Herrenschmidt
[not found] ` <1415342031.4925.27.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2014-11-07 6:35 ` Benjamin Herrenschmidt
2014-11-07 6:35 ` Benjamin Herrenschmidt
[not found] ` <1415342117.4925.29.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2014-11-10 5:17 ` Benjamin Herrenschmidt
2014-11-10 5:17 ` Benjamin Herrenschmidt
2014-11-10 14:06 ` Rob Herring
2014-11-10 22:48 ` Benjamin Herrenschmidt
[not found] ` <CAL_JsqKG=vpeGKj3v-2VW9oGQsnmuYMHRfy6LuXDXE=ROjHT4w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-13 1:10 ` [PATCH] drivers/core/of: Add symlink to device-tree from devices with an OF node Benjamin Herrenschmidt
2014-11-13 1:10 ` Benjamin Herrenschmidt
2014-11-18 16:37 ` Rob Herring
2014-11-18 23:39 ` Jeremy Kerr
2014-11-18 23:53 ` Jeremy Kerr
[not found] ` <546BD8BD.2010605-8fk3Idey6ehBDgjK7y7TUQ@public.gmane.org>
2014-11-19 2:35 ` Benjamin Herrenschmidt
2014-11-19 2:35 ` Benjamin Herrenschmidt
[not found] ` <1416364544.5704.23.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2014-11-19 8:38 ` Arnd Bergmann
2014-11-19 8:38 ` Arnd Bergmann
2014-11-19 14:45 ` Rob Herring
2014-11-19 14:45 ` Rob Herring
[not found] ` <CAL_JsqKk5UdFEa02wA+3N5BCM7coWAK=4jAr96Pw5eFh2n0ioQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-19 14:49 ` Arnd Bergmann
2014-11-19 14:49 ` Arnd Bergmann
2014-11-19 15:39 ` Rob Herring
2014-11-19 15:39 ` Rob Herring
[not found] ` <CAL_JsqJm9c+GozQssLmjuSLzcsqDiMW8=1P_fM6-Zfdk=N6Lqg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-19 16:30 ` Grant Likely
2014-11-19 16:30 ` Grant Likely
[not found] ` <CAL_Jsq+YyfMWxiOFv4x3g5hZJH0XRqCKj2He1XO9eyXWjHTMrg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-19 2:30 ` Benjamin Herrenschmidt
2014-11-19 2:30 ` Benjamin Herrenschmidt
[not found] ` <1415841047.5124.62.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2014-11-27 3:39 ` Greg KH
2014-11-27 3:39 ` Greg KH
[not found] ` <20141127033923.GA28286-U8xfFu+wG4EAvxtiuMwx3w@public.gmane.org>
2014-11-27 6:24 ` Benjamin Herrenschmidt
2014-11-27 6:24 ` Benjamin Herrenschmidt
2015-02-18 0:25 ` [PATCH 2/2 v3] " Benjamin Herrenschmidt
2015-02-18 0:25 ` Benjamin Herrenschmidt
[not found] ` <1424219118.21410.111.camel-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org>
2015-02-18 1:07 ` Rob Herring
2015-02-18 1:07 ` Rob Herring
2015-02-18 4:57 ` Greg Kroah-Hartman
2015-02-18 9:50 ` Benjamin Herrenschmidt
2015-03-10 14:22 ` Rob Herring
2015-03-10 15:11 ` Greg Kroah-Hartman
2015-02-18 4:57 ` Greg Kroah-Hartman
2014-11-18 15:18 ` [RFC] Add of_path property for all devices with a node Grant Likely
[not found] ` <CACxGe6vg8SxwCHZ8HxzLzimQOAf8Q81wd5eO=x2LavD4dv81Rw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-11-19 2:25 ` Benjamin Herrenschmidt
2014-11-19 2:25 ` Benjamin Herrenschmidt
2014-11-13 4:28 ` Frank Rowand [this message]
2014-11-13 4:28 ` Frank Rowand
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=54643384.5030309@gmail.com \
--to=frowand.list-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=arnd-r2nGTMty4D4@public.gmane.org \
--cc=benh-XVmvHMARGAS8U2dJNN8I7kB+6BGkLq7r@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@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.