All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ryan Mallon <ryan@bluewatersys.com>
To: Maxime Coquelin <maxime.coquelin-nonst@stericsson.com>
Cc: ext Nishanth Menon <nm@ti.com>,
	ext Tony Lindgren <tony@atomide.com>,
	Peter De-Schrijver <Peter.De-Schrijver@nokia.com>,
	ext Linus Walleij <linus.walleij@linaro.org>,
	Ambresh <a0393775@ti.com>,
	Saravana Kannan <skannan@codeaurora.org>,
	Jouni Hogander <jouni.hogander@nokia.com>,
	Lee Jones <Lee.Jones@linaro.org>,
	Russell King <linux@arm.linux.org.uk>,
	Jonas ABERG <jonas.aberg@stericsson.com>,
	ext Kevin Hilman <khilman@deeprootsystems.com>,
	David Brown <davidb@codeaurora.org>,
	"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>,
	Linux-OMAP <linux-omap@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Daniel Walker <dwalker@codeaurora.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Andrei Warkentin <andreiw@motorol>
Subject: Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
Date: Thu, 03 Mar 2011 09:09:39 +1300	[thread overview]
Message-ID: <4D6EA403.2060407@bluewatersys.com> (raw)
In-Reply-To: <4D6E04DF.3070905@stericsson.com>

On 03/02/2011 09:50 PM, Maxime Coquelin wrote:
> On 03/02/2011 04:54 AM, Ryan Mallon wrote:
>> On 03/02/2011 04:46 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>>>> The only real objection I have to adding the SoC family information is
>>>> basically to discourage it being abused by userspace. I can see it
>>>> being
>>>> useful in debug situations, but I can also see stupid userspace
>>>> applications explicitly testing for some particular SoC, rather than
>>>> more correctly (IMHO) checking for presence of certain drivers etc.
>>> True, but so many other things could be misused by stupid userspace
>>> programs. When there are legitimate usecases, I think we shouldn't
>>> prevent them just because we think a stupid userspace program could
>>> misuse it.
>>>
>>> Again, although you might not be gung-ho about this, I think I have at
>>> least made you indifferent/mildly supportive to adding socinfo. If you
>>> don't mind, I would like to wait for others to chime in before
>>> continuing this discussion.
>> Agreed.
>>
>> In general I am in support of having the SoC information exposed
>> somewhere. I think we just want to be careful that it doesn't become a
>> dumping ground for anything and everything SoC related whether the
>> information is useful or not. I think each piece of exposed information
>> should have a genuine use case, not just "because we can".
> I definitely agree we should not export every SoC-related information
> just because we can do it.
> The first goal of this interface was to export some SoCs IDs, as we need
> this kind of information for some user-space tools.
> Does someone need to export other information than the mach name and
> some IDs?
> 
> As proposed in my previous mail, do you agree to have a unified file for
> all vendors, which exports the unique silicon ID of the chip?

As mentioned earlier, on ep93xx we would like to export the Maverick
Crunch ID, which is a unique identifier for the chip.

I think the ABI should specify a minimum set of values which are
guaranteed to be provided on all SoCs, but allow individual SoCs to
provide additional information as necessary.

~Ryan

-- 
Bluewater Systems Ltd - ARM Technology Solution Centre

Ryan Mallon         		5 Amuri Park, 404 Barbadoes St
ryan@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

WARNING: multiple messages have this Message-ID (diff)
From: ryan@bluewatersys.com (Ryan Mallon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
Date: Thu, 03 Mar 2011 09:09:39 +1300	[thread overview]
Message-ID: <4D6EA403.2060407@bluewatersys.com> (raw)
In-Reply-To: <4D6E04DF.3070905@stericsson.com>

On 03/02/2011 09:50 PM, Maxime Coquelin wrote:
> On 03/02/2011 04:54 AM, Ryan Mallon wrote:
>> On 03/02/2011 04:46 PM, Saravana Kannan wrote:
>>> On 03/01/2011 07:35 PM, Ryan Mallon wrote:
>>>> The only real objection I have to adding the SoC family information is
>>>> basically to discourage it being abused by userspace. I can see it
>>>> being
>>>> useful in debug situations, but I can also see stupid userspace
>>>> applications explicitly testing for some particular SoC, rather than
>>>> more correctly (IMHO) checking for presence of certain drivers etc.
>>> True, but so many other things could be misused by stupid userspace
>>> programs. When there are legitimate usecases, I think we shouldn't
>>> prevent them just because we think a stupid userspace program could
>>> misuse it.
>>>
>>> Again, although you might not be gung-ho about this, I think I have at
>>> least made you indifferent/mildly supportive to adding socinfo. If you
>>> don't mind, I would like to wait for others to chime in before
>>> continuing this discussion.
>> Agreed.
>>
>> In general I am in support of having the SoC information exposed
>> somewhere. I think we just want to be careful that it doesn't become a
>> dumping ground for anything and everything SoC related whether the
>> information is useful or not. I think each piece of exposed information
>> should have a genuine use case, not just "because we can".
> I definitely agree we should not export every SoC-related information
> just because we can do it.
> The first goal of this interface was to export some SoCs IDs, as we need
> this kind of information for some user-space tools.
> Does someone need to export other information than the mach name and
> some IDs?
> 
> As proposed in my previous mail, do you agree to have a unified file for
> all vendors, which exports the unique silicon ID of the chip?

As mentioned earlier, on ep93xx we would like to export the Maverick
Crunch ID, which is a unique identifier for the chip.

I think the ABI should specify a minimum set of values which are
guaranteed to be provided on all SoCs, but allow individual SoCs to
provide additional information as necessary.

~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-03-02 20:09 UTC|newest]

Thread overview: 89+ 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 ` Eduardo Valentin
2010-05-11 14:15 ` Eduardo Valentin
2010-05-11 14:15 ` [PATCHv5 1/3] procfs: Introduce socinfo under /proc Eduardo Valentin
2010-05-11 14:15   ` Eduardo Valentin
2010-05-11 14:15 ` [PATCHv5 2/3] OMAP: export OMAP info under /proc/socinfo Eduardo Valentin
2010-05-11 14:15   ` Eduardo Valentin
2010-05-11 14:28   ` Nishanth Menon
2010-05-11 14:28     ` Nishanth Menon
2010-05-11 16:58     ` Eduardo Valentin
2010-05-11 16:58       ` Eduardo Valentin
2010-05-12 12:34       ` Eduardo Valentin
2010-05-12 12:34         ` Eduardo Valentin
2010-05-12 12:36         ` Nishanth Menon
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-11 14:15   ` Eduardo Valentin
2010-05-11 14:15   ` 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-12 22:24   ` Andrew Morton
2010-05-14  8:24   ` Eduardo Valentin
2010-05-14  8:24     ` Eduardo Valentin
2010-05-14  8:24     ` Eduardo Valentin
2010-05-14 16:27   ` Tony Lindgren
2010-05-14 16:27     ` Tony Lindgren
2011-02-15 12:58 ` Linus Walleij
2011-02-15 12:58   ` Linus Walleij
2011-02-16 11:57   ` Eduardo Valentin
2011-02-16 11:57     ` Eduardo Valentin
2011-02-28 10:28     ` Maxime Coquelin
2011-02-28 10:28       ` Maxime Coquelin
2011-02-28 10:28       ` Maxime Coquelin
2011-03-01  4:51       ` Saravana Kannan
2011-03-01  4:51         ` Saravana Kannan
2011-03-01  4:51         ` Saravana Kannan
2011-03-02  1:13         ` Andrei Warkentin
2011-03-02  1:13           ` Andrei Warkentin
2011-03-02  1:13           ` Andrei Warkentin
2011-03-02  1:19           ` Saravana Kannan
2011-03-02  1:19             ` Saravana Kannan
2011-03-02  1:19             ` Saravana Kannan
2011-03-02  1:27             ` Ryan Mallon
2011-03-02  1:27               ` Ryan Mallon
2011-03-02  1:39               ` Saravana Kannan
2011-03-02  1:39                 ` Saravana Kannan
2011-03-02  1:51                 ` Ryan Mallon
2011-03-02  1:51                   ` Ryan Mallon
2011-03-02  2:23                   ` Saravana Kannan
2011-03-02  2:23                     ` Saravana Kannan
2011-03-02  2:41                     ` Ryan Mallon
2011-03-02  2:41                       ` Ryan Mallon
2011-03-02  2:55                       ` Saravana Kannan
2011-03-02  2:55                         ` Saravana Kannan
2011-03-02  2:55                         ` Saravana Kannan
2011-03-02  3:11                         ` Ryan Mallon
2011-03-02  3:11                           ` Ryan Mallon
2011-03-02  3:11                           ` Ryan Mallon
2011-03-02  3:21                           ` Saravana Kannan
2011-03-02  3:21                             ` Saravana Kannan
2011-03-02  3:21                             ` Saravana Kannan
2011-03-02  3:35                             ` Ryan Mallon
2011-03-02  3:35                               ` Ryan Mallon
2011-03-02  3:35                               ` Ryan Mallon
2011-03-02  3:46                               ` Saravana Kannan
2011-03-02  3:46                                 ` Saravana Kannan
2011-03-02  3:46                                 ` Saravana Kannan
2011-03-02  3:54                                 ` Ryan Mallon
2011-03-02  3:54                                   ` Ryan Mallon
2011-03-02  3:54                                   ` Ryan Mallon
2011-03-02  8:50                                   ` Maxime Coquelin
2011-03-02  8:50                                     ` Maxime Coquelin
2011-03-02 20:09                                     ` Ryan Mallon [this message]
2011-03-02 20:09                                       ` Ryan Mallon
2011-03-02  8:23                         ` Maxime Coquelin
2011-03-02  8:23                           ` Maxime Coquelin
2011-03-02 10:36                           ` Linus Walleij
2011-03-02 10:36                             ` Linus Walleij
2011-03-02 10:53                             ` Maxime Coquelin
2011-03-02 10:53                               ` Maxime Coquelin
2011-03-03  5:55                               ` Saravana Kannan
2011-03-03  5:55                                 ` Saravana Kannan
2011-03-02 11:38                             ` Jamie Iles
2011-03-02 11:38                               ` Jamie Iles
2011-03-02 12:17                               ` Maxime Coquelin
2011-03-02 12:17                                 ` Maxime Coquelin
2011-03-02 14:42                               ` Linus Walleij
2011-03-02 14:42                                 ` Linus Walleij
2011-03-02 15:18                                 ` Jamie Iles
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=4D6EA403.2060407@bluewatersys.com \
    --to=ryan@bluewatersys.com \
    --cc=Lee.Jones@linaro.org \
    --cc=Peter.De-Schrijver@nokia.com \
    --cc=a0393775@ti.com \
    --cc=andreiw@motorol \
    --cc=davidb@codeaurora.org \
    --cc=dwalker@codeaurora.org \
    --cc=eduardo.valentin@nokia.com \
    --cc=jonas.aberg@stericsson.com \
    --cc=jouni.hogander@nokia.com \
    --cc=khilman@deeprootsystems.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@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=nm@ti.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.