All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Linus Walleij <linus.walleij@linaro.org>
Cc: ext Nishanth Menon <nm@ti.com>,
	ext Tony Lindgren <tony@atomide.com>,
	Peter De-Schrijver <Peter.De-Schrijver@nokia.com>,
	Ambresh <a0393775@ti.com>,
	Saravana Kannan <skannan@codeaurora.org>,
	Andrei Warkentin <andreiw@motorola.com>,
	Lee Jones <Lee.Jones@linaro.org>,
	Rabin VINCENT <rabin.vincent@stericsson.com>,
	Russell King <linux@arm.linux.org.uk>,
	Jonas ABERG <jonas.aberg@stericsson.com>,
	ext Kevin Hilman <khilman@deeprootsystems.com>,
	Greg KH <greg@kroah.com>, David Brown <davidb@codeaurora.org>,
	Maxime Coquelin <maxime.coquelin-nonst@stericsson.com>,
	"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
	Loic PALLARDY <loic.pallardy@stericsson.com>,
	"eduardo.valentin@nokia.com" <eduardo.valentin@nokia.com>,
	maxime_coquelin@yahoo.fr, Ryan Mallon <ryan@bluewatersys.com>,
	Linux-OMAP
	<linux-omap@vger.kernel.org>"linux-arm-kernel@lists.infradead.org"
	<linux-a>
Subject: Re: [RFC PATCHv1 1/2] Export SoC info through sysfs
Date: Fri, 11 Mar 2011 17:14:12 +0100	[thread overview]
Message-ID: <201103111714.12332.arnd@arndb.de> (raw)
In-Reply-To: <AANLkTin=Octa0BsxAh2QPsJXVCOKNrzELkcNJO88J+pN@mail.gmail.com>

On Thursday 10 March 2011, Linus Walleij wrote:
> What I'm trying to get at is that the user of this
> info isn't really interested in any device tree structure,
> it just becomes an obstacle s/he has to overcome
> to get this info out.
> 
> But there may be a compromise: if we create the
> socinfo in one place in the device tree (possibly the
> top node, or a dedicated device) then class it?
> 
> /sys/class/soc/soc0 -> ../../devices/platform/top-node
> 
> Then you find your entries easily by opening
> /sys/class/soc/soc0/* ?

That would be one way of finding all soc nodes, in
case we want to have multiple ones. Similarly,
it could be done based on

1. the name under /sys/devices/platform:

/sys/devices/platform/soc0
/sys/devices/platform/soc1
/sys/devices/platform/soc2

2. a new bus_type for soc devices, with bus_attributes:

/sys/bus/soc/devices/foo0 -> ../../../devices/platform/foo0
/sys/bus/soc/devices/bar0 -> ../../../devices/platform/bar0
/sys/bus/soc/devices/bar1 -> ../../../devices/platform/bar1

3. A new top-level device besides /sys/devices/platform (like PCI):

/sys/devices/soc0
/sys/devices/soc1
/sys/devices/soc2

> If the socinfo interface is singleton (and why should
> it not be) then:
> 
> /sys/class/soc -> ../devices/platfom/top-node
> 
> Or is this thing too trivial to have it's own class?

In case of a singleton, I'd just use a fixed device as
the parent:

/sys/devices/platform/soc/

or

/sys/devices/soc/

And pass that as the parent for all devices under it.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCHv1 1/2] Export SoC info through sysfs
Date: Fri, 11 Mar 2011 17:14:12 +0100	[thread overview]
Message-ID: <201103111714.12332.arnd@arndb.de> (raw)
In-Reply-To: <AANLkTin=Octa0BsxAh2QPsJXVCOKNrzELkcNJO88J+pN@mail.gmail.com>

On Thursday 10 March 2011, Linus Walleij wrote:
> What I'm trying to get at is that the user of this
> info isn't really interested in any device tree structure,
> it just becomes an obstacle s/he has to overcome
> to get this info out.
> 
> But there may be a compromise: if we create the
> socinfo in one place in the device tree (possibly the
> top node, or a dedicated device) then class it?
> 
> /sys/class/soc/soc0 -> ../../devices/platform/top-node
> 
> Then you find your entries easily by opening
> /sys/class/soc/soc0/* ?

That would be one way of finding all soc nodes, in
case we want to have multiple ones. Similarly,
it could be done based on

1. the name under /sys/devices/platform:

/sys/devices/platform/soc0
/sys/devices/platform/soc1
/sys/devices/platform/soc2

2. a new bus_type for soc devices, with bus_attributes:

/sys/bus/soc/devices/foo0 -> ../../../devices/platform/foo0
/sys/bus/soc/devices/bar0 -> ../../../devices/platform/bar0
/sys/bus/soc/devices/bar1 -> ../../../devices/platform/bar1

3. A new top-level device besides /sys/devices/platform (like PCI):

/sys/devices/soc0
/sys/devices/soc1
/sys/devices/soc2

> If the socinfo interface is singleton (and why should
> it not be) then:
> 
> /sys/class/soc -> ../devices/platfom/top-node
> 
> Or is this thing too trivial to have it's own class?

In case of a singleton, I'd just use a fixed device as
the parent:

/sys/devices/platform/soc/

or

/sys/devices/soc/

And pass that as the parent for all devices under it.

	Arnd

  reply	other threads:[~2011-03-11 16:14 UTC|newest]

Thread overview: 66+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-09 16:59 [RFC PATCHv1 0/2] Export SoC info through sysfs Maxime Coquelin
2011-03-09 16:59 ` Maxime Coquelin
2011-03-09 16:59 ` Maxime Coquelin
2011-03-09 16:59 ` [RFC PATCHv1 1/2] " Maxime Coquelin
2011-03-09 16:59   ` Maxime Coquelin
2011-03-09 16:59   ` Maxime Coquelin
2011-03-09 17:39   ` Jamie Iles
2011-03-09 17:39     ` Jamie Iles
2011-03-10  9:45     ` Maxime Coquelin
2011-03-10  9:45       ` Maxime Coquelin
2011-03-09 17:47   ` Mark Brown
2011-03-09 17:47     ` Mark Brown
2011-03-10  9:58     ` Maxime Coquelin
2011-03-10  9:58       ` Maxime Coquelin
2011-03-10 13:18       ` Mark Brown
2011-03-10 13:18         ` Mark Brown
2011-03-10 13:16         ` Maxime Coquelin
2011-03-10 13:16           ` Maxime Coquelin
2011-03-09 19:58   ` Arnd Bergmann
2011-03-09 19:58     ` Arnd Bergmann
2011-03-10 12:56     ` Maxime Coquelin
2011-03-10 12:56       ` Maxime Coquelin
2011-03-10 13:25     ` Linus Walleij
2011-03-10 13:25       ` Linus Walleij
2011-03-10 14:08       ` Mark Brown
2011-03-10 14:08         ` Mark Brown
2011-03-10 14:29         ` Arnd Bergmann
2011-03-10 14:29           ` Arnd Bergmann
2011-03-10 14:44           ` Mark Brown
2011-03-10 14:44             ` Mark Brown
2011-03-10 15:02             ` Arnd Bergmann
2011-03-10 15:02               ` Arnd Bergmann
2011-03-10 15:10               ` Russell King - ARM Linux
2011-03-10 15:10                 ` Russell King - ARM Linux
2011-03-10 15:17                 ` Linus Walleij
2011-03-10 15:17                   ` Linus Walleij
2011-03-10 15:21                 ` Helmut Raiger
2011-03-10 15:20               ` Mark Brown
2011-03-10 15:20                 ` Mark Brown
2011-03-10 16:11                 ` Arnd Bergmann
2011-03-10 16:11                   ` Arnd Bergmann
2011-03-10 16:19                   ` Mark Brown
2011-03-10 16:19                     ` Mark Brown
2011-03-10 16:54                     ` Arnd Bergmann
2011-03-10 16:54                       ` Arnd Bergmann
2011-03-10 14:23       ` Arnd Bergmann
2011-03-10 14:23         ` Arnd Bergmann
2011-03-10 16:05         ` Linus Walleij
2011-03-10 16:05           ` Linus Walleij
2011-03-10 16:32           ` Arnd Bergmann
2011-03-10 16:32             ` Arnd Bergmann
2011-03-10 17:08             ` Linus Walleij
2011-03-10 17:08               ` Linus Walleij
2011-03-11 16:14               ` Arnd Bergmann [this message]
2011-03-11 16:14                 ` Arnd Bergmann
2011-03-09 20:38   ` Ryan Mallon
2011-03-09 20:38     ` Ryan Mallon
2011-03-09 16:59 ` [RFC PATCHv1 2/2] ux500: Export U8500 " Maxime Coquelin
2011-03-09 16:59   ` Maxime Coquelin
2011-03-09 16:59   ` Maxime Coquelin
2011-03-09 20:02   ` Arnd Bergmann
2011-03-09 20:02     ` Arnd Bergmann
2011-03-10 13:05 ` [RFC PATCHv1 0/2] Export " Eduardo Valentin
2011-03-10 13:05   ` Eduardo Valentin
2011-03-10 13:36   ` Maxime Coquelin
2011-03-10 13:36     ` Maxime Coquelin

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=201103111714.12332.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=Lee.Jones@linaro.org \
    --cc=Peter.De-Schrijver@nokia.com \
    --cc=a0393775@ti.com \
    --cc=andreiw@motorola.com \
    --cc=davidb@codeaurora.org \
    --cc=eduardo.valentin@nokia.com \
    --cc=greg@kroah.com \
    --cc=jonas.aberg@stericsson.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=loic.pallardy@stericsson.com \
    --cc=maxime.coquelin-nonst@stericsson.com \
    --cc=maxime_coquelin@yahoo.fr \
    --cc=nm@ti.com \
    --cc=rabin.vincent@stericsson.com \
    --cc=ryan@bluewatersys.com \
    --cc=skannan@codeaurora.org \
    --cc=tony@atomide.com \
    /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.