From: Maxime Coquelin <maxime.coquelin-nonst@stericsson.com>
To: Ryan Mallon <ryan@bluewatersys.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: Wed, 2 Mar 2011 09:50:39 +0100 [thread overview]
Message-ID: <4D6E04DF.3070905@stericsson.com> (raw)
In-Reply-To: <4D6DBF59.2050005@bluewatersys.com>
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?
Regards,
Maxime
WARNING: multiple messages have this Message-ID (diff)
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: Wed, 2 Mar 2011 09:50:39 +0100 [thread overview]
Message-ID: <4D6E04DF.3070905@stericsson.com> (raw)
In-Reply-To: <4D6DBF59.2050005@bluewatersys.com>
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?
Regards,
Maxime
next prev parent reply other threads:[~2011-03-02 8:50 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 [this message]
2011-03-02 8:50 ` Maxime Coquelin
2011-03-02 20:09 ` Ryan Mallon
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=4D6E04DF.3070905@stericsson.com \
--to=maxime.coquelin-nonst@stericsson.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=nm@ti.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.