All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Ryan Mallon <ryan@bluewatersys.com>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>,
	ext Nishanth Menon <nm@ti.com>,
	ext Tony Lindgren <tony@atomide.com>, Greg KH <greg@kroah.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	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>,
	Peter De-Schrijver <Peter.De-Schrijver@nokia.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 <eduardo.valentin@nokia.com>,
	maxime_coquelin@yahoo.fr, Linux-OMAP <linux-omap@vger.kernel.org>,
	linux-arm-ke
Subject: Re: [RFC PATCHv2 1/2] Export SoC info through sysfs
Date: Fri, 8 Apr 2011 01:19:10 +0200	[thread overview]
Message-ID: <201104080119.11378.arnd@arndb.de> (raw)
In-Reply-To: <4D9E4114.3090102@bluewatersys.com>

On Friday 08 April 2011, Ryan Mallon wrote:
>>>>> /sys/devices/soc/${NAME}/
>>>>> /sys/devices/platform/soc${NUMBER}/
>>>>
>>>> I prefer the second format here since the path is always the same which
>>>> makes it easier to write parsing tools. The name should be an entry in
>>>> the directory rather than the name of the directory itself.

In the first case, we would ensure that every directory under /sys/devices/soc
is an SOC device, so you would not need to parse the name at all, which is
even simpler. I'm open to other arguments either way, but I think this
one is not particularly important.

> > That would mean two separate instances of Linux, just like two systems.  
> > SMP across multiple SOCs doesn't make much sense, and I don't think they 
> > are likely to be designed for that ability either.
> 
> So we probably don't need the ability to have multiple SoC directories
> under sysfs then?

There are systems that have multiple ones, they are just not as common.

> For the other part of the question, do you think it makes sense for the
> CPU's to be child devices of the SoC (and for the CPU devices to be
> potentially symlinked from the SoC directory)?

No, the CPUs are children of /sys/devices/system, and we should not change
that. Symlinks sound like a good idea though.

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCHv2 1/2] Export SoC info through sysfs
Date: Fri, 8 Apr 2011 01:19:10 +0200	[thread overview]
Message-ID: <201104080119.11378.arnd@arndb.de> (raw)
In-Reply-To: <4D9E4114.3090102@bluewatersys.com>

On Friday 08 April 2011, Ryan Mallon wrote:
>>>>> /sys/devices/soc/${NAME}/
>>>>> /sys/devices/platform/soc${NUMBER}/
>>>>
>>>> I prefer the second format here since the path is always the same which
>>>> makes it easier to write parsing tools. The name should be an entry in
>>>> the directory rather than the name of the directory itself.

In the first case, we would ensure that every directory under /sys/devices/soc
is an SOC device, so you would not need to parse the name at all, which is
even simpler. I'm open to other arguments either way, but I think this
one is not particularly important.

> > That would mean two separate instances of Linux, just like two systems.  
> > SMP across multiple SOCs doesn't make much sense, and I don't think they 
> > are likely to be designed for that ability either.
> 
> So we probably don't need the ability to have multiple SoC directories
> under sysfs then?

There are systems that have multiple ones, they are just not as common.

> For the other part of the question, do you think it makes sense for the
> CPU's to be child devices of the SoC (and for the CPU devices to be
> potentially symlinked from the SoC directory)?

No, the CPUs are children of /sys/devices/system, and we should not change
that. Symlinks sound like a good idea though.

	Arnd

  reply	other threads:[~2011-04-07 23:19 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-03-11 12:35 [RFC PATCHv2 0/2] Export SoC info through sysfs Maxime Coquelin
2011-03-11 12:35 ` Maxime Coquelin
2011-03-11 12:35 ` Maxime Coquelin
2011-03-11 12:35 ` [RFC PATCHv2 1/2] " Maxime Coquelin
2011-03-11 12:35   ` Maxime Coquelin
2011-03-11 12:35   ` Maxime Coquelin
2011-03-11 13:50   ` Eduardo Valentin
2011-03-11 13:50     ` Eduardo Valentin
2011-03-11 15:40     ` Maxime Coquelin
2011-03-11 15:40       ` Maxime Coquelin
2011-03-11 17:35       ` Eduardo Valentin
2011-03-11 17:35         ` Eduardo Valentin
2011-03-11 14:32   ` Arnd Bergmann
2011-03-11 14:32     ` Arnd Bergmann
2011-03-11 14:31     ` Eduardo Valentin
2011-03-11 14:31       ` Eduardo Valentin
2011-03-11 15:40     ` Ben Dooks
2011-03-11 15:40       ` Ben Dooks
2011-03-11 17:38       ` Eduardo Valentin
2011-03-11 17:38         ` Eduardo Valentin
2011-03-11 15:52     ` Greg KH
2011-03-11 15:52       ` Greg KH
2011-03-11 17:58       ` Eduardo Valentin
2011-03-11 17:58         ` Eduardo Valentin
2011-03-11 19:33         ` Greg KH
2011-03-11 19:33           ` Greg KH
2011-03-11 21:42           ` Arnd Bergmann
2011-03-11 21:42             ` Arnd Bergmann
2011-03-11 22:03             ` Greg KH
2011-03-11 22:03               ` Greg KH
2011-03-11 22:13               ` Arnd Bergmann
2011-03-11 22:13                 ` Arnd Bergmann
2011-04-07 16:24                 ` Lee Jones
2011-04-07 16:24                   ` Lee Jones
2011-04-07 21:29                   ` Arnd Bergmann
2011-04-07 21:29                     ` Arnd Bergmann
2011-04-07 21:46                     ` Ryan Mallon
2011-04-07 21:46                       ` Ryan Mallon
2011-04-07 22:01                       ` Nicolas Pitre
2011-04-07 22:01                         ` Nicolas Pitre
2011-04-07 22:07                         ` Ryan Mallon
2011-04-07 22:07                           ` Ryan Mallon
2011-04-07 22:45                           ` Nicolas Pitre
2011-04-07 22:45                             ` Nicolas Pitre
2011-04-07 22:56                             ` Ryan Mallon
2011-04-07 22:56                               ` Ryan Mallon
2011-04-07 23:19                               ` Arnd Bergmann [this message]
2011-04-07 23:19                                 ` Arnd Bergmann
2011-04-07 23:29                                 ` Greg KH
2011-04-07 23:29                                   ` Greg KH
2011-04-08  3:35                                   ` Arnd Bergmann
2011-04-08  3:35                                     ` Arnd Bergmann
2011-04-08  7:41                                     ` Lee Jones
2011-04-08  7:41                                       ` Lee Jones
2011-04-08 15:02                                       ` Arnd Bergmann
2011-04-08 15:02                                         ` Arnd Bergmann
2011-04-08 15:43                                         ` Lee Jones
2011-04-08 15:43                                           ` Lee Jones
2011-04-08 20:22                                           ` Arnd Bergmann
2011-04-08 20:22                                             ` Arnd Bergmann
2011-03-11 12:35 ` [RFC PATCHv2 2/2] ux500: Export U8500 " Maxime Coquelin
2011-03-11 12:35   ` Maxime Coquelin
2011-03-11 12:35   ` Maxime Coquelin
2011-03-11 14:11   ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-11 14:11     ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-11 15:20     ` Linus Walleij
2011-03-11 15:20       ` Linus Walleij
2011-03-11 17:24       ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-11 17:24         ` Jean-Christophe PLAGNIOL-VILLARD

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=201104080119.11378.arnd@arndb.de \
    --to=arnd@arndb.de \
    --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=lee.jones@linaro.org \
    --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=nicolas.pitre@linaro.org \
    --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.