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:32:54 +0200 [thread overview]
Message-ID: <201109021932.54615.arnd@arndb.de> (raw)
In-Reply-To: <20110902162440.GA5331@suse.de>
On Friday 02 September 2011, Greg KH wrote:
> On Fri, Sep 02, 2011 at 04:02:14PM +0200, Arnd Bergmann wrote:
> > On Friday 02 September 2011, Greg KH wrote:
> > > > diff --git a/include/linux/sys_soc.h b/include/linux/sys_soc.h
> > > > new file mode 100644
> > > > index 0000000..811d7fe
> > > > --- /dev/null
> > > > +++ b/include/linux/sys_soc.h
> > > > @@ -0,0 +1,27 @@
> > > > +/*
> > > > + * Copyright (C) ST-Ericsson SA 2011
> > > > + * Author: Lee Jones <lee.jones@linaro•org> for ST-Ericsson.
> > > > + * License terms: GNU General Public License (GPL), version 2
> > > > + */
> > > > +#ifndef __SYS_SOC_H
> > > > +#define __SYS_SOC_H
> > > > +
> > > > +#include <linux/kobject.h>
> > > > +#include <linux/device.h>
> > > > +#include <linux/platform_device.h>
> > > > +
> > > > +struct soc_device {
> > > > + struct device dev;
> > > > + const char *machine;
> > > > + const char *family;
> > > > + const char *revision;
> > > > + const char *(*pfn_soc_id)(void);
> > > > +};
> > >
> > > Nice structure, but why do you export it, you aren't using it anywhere,
> > > nor should you be...
> >
> > This gets filled by the soc-specific code with information that is exported
> > through the common callbacks, so it needs to be visible to the platforms.
>
> But this api doesn't allow that to happen, so use it to create the data
> in the first place somehow, this is really confusing as-is.
Yes, that is true. I hadn't noticed the 'struct device' in the above
structure. What really needs to happen is the platform code to fill
out a structure with all the attribute data and to pass that into
the soc common code as constant data which then gets added to the
device data.
> > I think the ideal solution would be to make the soc layer a
> > class that can be set when initially adding the device (one way
> > or another) and that adds the standard attributes. Since you don't
> > really like classes any more, another option would be to just
> > have a function call that adds an attribute group to the soc node,
> > but then it's not easy to find which devices are actually soc
> > root nodes.
>
> Then make it a bus, like it should be, which would solve all of this,
> right?
I'm not sure if we're talking about the same thing. Do you mean
adding an artifical device (like a class_device) under the soc
device node and have that be of soc_bus type? Or do you mean
putting the entire soc with all its platform_device children
on the soc_bus?
In the former case, it's a somewhat ugly representation. It
would be really nice for the soc to be just one device, not
one device to hang all the children off and another one to
provide a user-space interface.
In the latter case, we would have to rewrite the way we probe
SoCs from the device tree so that the root node of the soc
becomes a soc_bus device instead of a platform_bus device.
> > > Oh wait, you forgot to have a function to remove anything created with
> > > the above call, that seems really broken and wrong.
> >
> > There is no way to remove a soc from the system, just like there
> > is no complementary function to pcibios_scan_root that removes
> > the PCI root bridge.
>
> And no one is ever going to remove the module that created the SOC
> device in the first place? It just really bothers me to see creation
> code but no removal code, as it feels wrong somehow :)
SoC code fundamentally cannot be a module, since the soc contains
all the basic stuff like irq controller, clocksource etc. If it didn't
have those, it would not be a system-on-a-chip but rather some random
multifunction device you hang off some bus.
Arnd
prev parent reply other threads:[~2011-09-02 17:32 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
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 [this message]
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=201109021932.54615.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