public inbox for linux-arm-kernel@lists.infradead.org 
 help / color / mirror / Atom feed
From: maxime.coquelin-nonst@stericsson•com (Maxime Coquelin)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
Date: Mon, 28 Feb 2011 11:28:15 +0100	[thread overview]
Message-ID: <4D6B78BF.1020102@stericsson.com> (raw)
In-Reply-To: <20110216115729.GA29817@besouro.research.nokia.com>

Hello Eduardo,

On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
> Hello Linus,
>
> On Tue, Feb 15, 2011 at 01:58:00PM +0100, ext Linus Walleij wrote:
>> 2010/5/11 Eduardo Valentin<eduardo.valentin@nokia•com>:
>>
>>> Here is the version 5 of the change to export OMAP data to userspace
>>> (name, revision, id code, production id and die id).
>>>
>>> Basically, this version is still attempting to create a new file under /proc.
>>> It is the /proc/socinfo, which should be used to export bits which are SoC specific
>>> (not CPU related, nor machine related).
>>>
>>> So, differences between previous version are:
>>> - merged patch 02/04 with 03/04 to avoid compilation breakages.
>>> - simplified the seq_file usage by using the single_open and single_release functions
>>> - exported a function to register a seq_operation .show callback
>>> - adapted the changes accordingly
>>>
>>> As usual, comments are welcome.
>> Eduardo, what has happened to this patchset?
> Got forgotten :-(. Unfortunately I didn't pushed it hard enough.
  I propose to refactor your patchset, moving from procfs to sysfs.
>> Do you want help in picking it up and try to polish it up?
> Yeah, but it would need a refactoring. IIRC, result of last discussion was that
> we should not mess with /proc. So, maybe moving back to something under sysfs.
> Perhaps /sys/devices/soc or so?
About the location of this new sysfs entry, where do you think it should be?
I propose to create a new directory named "soc" in /sys/devices/system/.

As platform vendors have several/different kind of IDs to export to 
sysfs, I propose each vendor to create file entries related to their IDs 
(eg. /sys/devices/system/soc/idcode for OMAP platforms).

However, I think we should have a common file entry to export the unique 
ID of the platforms. Indeed, user-space applications should have a 
unified way to get this kind of ID, regardless of the platform (eg. 
/sys/devices/system/soc/unique_id).

Do you agree with my proposal?

Thanks for your comments.

Regards,

Maxime Coquelin

  reply	other threads:[~2011-02-28 10:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-11 14:15 [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data Eduardo Valentin
2010-05-11 14:15 ` [PATCHv5 1/3] procfs: Introduce socinfo under /proc Eduardo Valentin
2010-05-11 14:15 ` [PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo Eduardo Valentin
2010-05-11 14:28   ` Nishanth Menon
2010-05-11 16:58     ` Eduardo Valentin
2010-05-12 12:34       ` Eduardo Valentin
2010-05-12 12:36         ` Nishanth Menon
2010-05-11 14:15 ` [PATCHv5 3/3] OMAP3: export chip IDCODE, Production ID and Die ID Eduardo Valentin
2010-05-12 22:24 ` [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data Andrew Morton
2010-05-14  8:24   ` Eduardo Valentin
2010-05-14 16:27   ` Tony Lindgren
2011-02-15 12:58 ` Linus Walleij
2011-02-16 11:57   ` Eduardo Valentin
2011-02-28 10:28     ` Maxime Coquelin [this message]
2011-03-01  4:51       ` Saravana Kannan
2011-03-02  1:13         ` Andrei Warkentin
2011-03-02  1:19           ` Saravana Kannan
2011-03-02  1:27             ` Ryan Mallon
2011-03-02  1:39               ` Saravana Kannan
2011-03-02  1:51                 ` Ryan Mallon
2011-03-02  2:23                   ` Saravana Kannan
2011-03-02  2:41                     ` Ryan Mallon
2011-03-02  2:55                       ` Saravana Kannan
2011-03-02  3:11                         ` Ryan Mallon
2011-03-02  3:21                           ` Saravana Kannan
2011-03-02  3:35                             ` Ryan Mallon
2011-03-02  3:46                               ` Saravana Kannan
2011-03-02  3:54                                 ` Ryan Mallon
2011-03-02  8:50                                   ` Maxime Coquelin
2011-03-02 20:09                                     ` Ryan Mallon
2011-03-02  8:23                         ` Maxime Coquelin
2011-03-02 10:36                           ` Linus Walleij
2011-03-02 10:53                             ` Maxime Coquelin
2011-03-03  5:55                               ` Saravana Kannan
2011-03-02 11:38                             ` Jamie Iles
2011-03-02 12:17                               ` Maxime Coquelin
2011-03-02 14:42                               ` Linus Walleij
2011-03-02 15:18                                 ` Jamie Iles

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=4D6B78BF.1020102@stericsson.com \
    --to=maxime.coquelin-nonst@stericsson$(echo .)com \
    --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