From: arnd@arndb•de (Arnd Bergmann)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 1/5] Framework for exporting System-on-Chip information via sysfs
Date: Fri, 2 Sep 2011 19:22:04 +0200 [thread overview]
Message-ID: <201109021922.04449.arnd@arndb.de> (raw)
In-Reply-To: <20110902163136.GB5331@suse.de>
On Friday 02 September 2011, Greg KH wrote:
> no.
>
> How did you pass the attribute data into this core so that it knows how
> to get to it? You didn't, which is a mess.
>
> How about something like:
> struct soc_device *soc_device_create(struct device *parent, struct soc_device_attributes *attr);
>
> That would have the proper way to handle lifetime rules, userspace
> notificatation of userpace, placement in sysfs, and all the other good
> stuff.
I early on objected to the individual soc driver providing a set of
attributes, because we really want the attributes to follow a
common interface and I want to make it *hard* to add arbitrary
other attributes that are not documented.
> > >> +
> > >> + if (!soc_count) {
> > >> + /* Register top-level SoC device '/sys/devices/soc' */
> > >> + ret = device_register(&soc_grandparent);
> > >
> > > device_register can't be called with a spinlock. You must have gotten
> > > lucky in your testing, if you tested this.
> > >
> > > Anyway, this is not needed at all, please don't create "dummy" devices
> > > in the sysfs tree, properly hook up your new device to where it should
> > > be in the device tree.
> >
> > We need a /sys/devices/soc, how else can this be done?
>
> No you do not not, why would you think so?
Well, where is all comes from is the desire to have a way from user space
to find these devices, based on some path in the device tree. We had
discussed putting it into
/sys/class/soc
/sys/bus/soc
/sys/devices/platform/soc
/sys/devices/platform/soc%d
and a few others and eventually settled on /sys/devices/soc.
> > Would it make you happier if I called it a bus?
>
> Yes, see the other response about creating a bus for these, which would
> give you /sys/bus/soc/ where you can properly enumerate your devices,
> which is what I think you want to be able to do, right?
I think that would be a reasonable interface, but how does this work
when the device was created by of_platform_bus_probe? Should we
assume that any top-level device in the flattened device tree is
a soc? How about just adding a child device in each soc node that
is registered to the soc_bus_type?
That would end up looking like
/sys/devices/db8500
/soc0 # this is the soc device
/i2c-0 # and here are the other platform devices below db8500
/spi-0
/bus/soc/devices/soc0 -> ../../../devices/db8500/soc0
/bus/platform/devices/i2c-0 -> ../../../devices/db8500/i2c-0
Arnd
next prev parent reply other threads:[~2011-09-02 17:22 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-01 12:27 [PATCH 1/5] Framework for exporting System-on-Chip information via sysfs Lee Jones
2011-09-01 12:27 ` [PATCH 2/5] Add documentation for new sysfs devices/soc functionality Lee Jones
2011-09-01 12:27 ` [PATCH 3/5] mach-ux500: export System-on-Chip information ux500 via sysfs Lee Jones
2011-09-02 14:31 ` Arnd Bergmann
2011-09-01 12:27 ` [PATCH 4/5] mach-ux500: move top level platform devices in sysfs to /sys/devices/soc/X Lee Jones
2011-09-01 12:27 ` [PATCH 5/5] mach-ux500: add a SoC ID (serial) callback for the u8500 Lee Jones
2011-09-02 14:22 ` Arnd Bergmann
2011-09-02 15:16 ` Lee Jones
2011-09-02 15:56 ` Arnd Bergmann
2011-09-01 23:34 ` [PATCH 1/5] Framework for exporting System-on-Chip information via sysfs Greg KH
2011-09-02 8:44 ` Lee Jones
2011-09-02 9:29 ` Jamie Iles
2011-09-02 9:37 ` Lee Jones
2011-09-02 9:56 ` Jamie Iles
2011-09-02 16:31 ` Greg KH
2011-09-02 17:22 ` Arnd Bergmann [this message]
2011-09-02 18:14 ` Greg KH
2011-09-06 9:41 ` Lee Jones
2011-09-06 19:33 ` Arnd Bergmann
2011-09-06 19:45 ` Greg KH
2011-09-07 6:14 ` Lee Jones
2011-09-02 14:02 ` Arnd Bergmann
2011-09-02 16:24 ` Greg KH
2011-09-02 17:32 ` Arnd Bergmann
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=201109021922.04449.arnd@arndb.de \
--to=arnd@arndb$(echo .)de \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox