linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: ryan@bluewatersys.com (Ryan Mallon)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCHv2 1/2] Export SoC info through sysfs
Date: Fri, 08 Apr 2011 10:56:20 +1200	[thread overview]
Message-ID: <4D9E4114.3090102@bluewatersys.com> (raw)
In-Reply-To: <alpine.LFD.2.00.1104071840430.28032@xanadu.home>

On 04/08/2011 10:45 AM, Nicolas Pitre wrote:
> On Fri, 8 Apr 2011, Ryan Mallon wrote:
> 
>> On 04/08/2011 10:01 AM, Nicolas Pitre wrote:
>>> On Fri, 8 Apr 2011, Ryan Mallon wrote:
>>>
>>>> On 04/08/2011 09:29 AM, Arnd Bergmann wrote:
>>>>> I'll try to capture the opinions from the other people as well,
>>>>> hopefully this represents a consensus. Please correct me otherwise.
>>>>>
>>>>> I believe the uncontroversial parts are:
>>>>>
>>>>> * Make it not an entry but a device with certain properties.
>>>>> * Make the naming so that you can have more than one of them.
>>>>> * Put all devices on an SoC that uses this scheme underneath that
>>>>>   device by setting their parents to the SoC device.
>>>>>
>>>>> For the location of the device, I have not seen a clear consensus yet,
>>>>> but I'm fine with eihter of these:
>>>>>
>>>>> /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.
>>>>
>>>> Probably SoC number should match CPU number for SMP machines right?
>>>
>>> Not really.  SOC means System On Chip.  you usually have only one SOC on 
>>> a board, and within that SOC you may have one or more CPUs.  SMP 
>>> machines are still likely to have only one SOC.
>>
>> Ok. What is the situation where we have more than one SoC?
> 
> 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?

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)?

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan at bluewatersys.com         	PO Box 13 889, Christchurch 8013
http://www.bluewatersys.com	New Zealand
Phone: +64 3 3779127		Freecall: Australia 1800 148 751
Fax:   +64 3 3779135			  USA 1800 261 2934

  reply	other threads:[~2011-04-07 22:56 UTC|newest]

Thread overview: 33+ 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 ` [RFC PATCHv2 1/2] " Maxime Coquelin
2011-03-11 13:50   ` Eduardo Valentin
2011-03-11 15:40     ` Maxime Coquelin
2011-03-11 17:35       ` Eduardo Valentin
2011-03-11 14:32   ` Arnd Bergmann
2011-03-11 14:31     ` Eduardo Valentin
2011-03-11 15:40     ` Ben Dooks
2011-03-11 17:38       ` Eduardo Valentin
2011-03-11 15:52     ` Greg KH
2011-03-11 17:58       ` Eduardo Valentin
2011-03-11 19:33         ` Greg KH
2011-03-11 21:42           ` Arnd Bergmann
2011-03-11 22:03             ` Greg KH
2011-03-11 22:13               ` Arnd Bergmann
2011-04-07 16:24                 ` Lee Jones
2011-04-07 21:29                   ` Arnd Bergmann
2011-04-07 21:46                     ` Ryan Mallon
2011-04-07 22:01                       ` Nicolas Pitre
2011-04-07 22:07                         ` Ryan Mallon
2011-04-07 22:45                           ` Nicolas Pitre
2011-04-07 22:56                             ` Ryan Mallon [this message]
2011-04-07 23:19                               ` Arnd Bergmann
2011-04-07 23:29                                 ` Greg KH
2011-04-08  3:35                                   ` Arnd Bergmann
2011-04-08  7:41                                     ` Lee Jones
2011-04-08 15:02                                       ` Arnd Bergmann
2011-04-08 15:43                                         ` Lee Jones
2011-04-08 20:22                                           ` Arnd Bergmann
2011-03-11 12:35 ` [RFC PATCHv2 2/2] ux500: Export U8500 " Maxime Coquelin
2011-03-11 14:11   ` Jean-Christophe PLAGNIOL-VILLARD
2011-03-11 15:20     ` Linus Walleij
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=4D9E4114.3090102@bluewatersys.com \
    --to=ryan@bluewatersys.com \
    --cc=linux-arm-kernel@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).