Re: [PATCHv5 0/3] Introduce the /proc/socinfo and use it to exportOMAP data

[Saravana Kannan]

On 03/01/2011 05:13 PM, Andrei Warkentin wrote:
> On Mon, Feb 28, 2011 at 10:51 PM, Saravana Kannan
> <skannan@xxxxxxxxxxxxxx>  wrote:
> > On 02/28/2011 02:28 AM, Maxime Coquelin wrote:
> > > Hello Eduardo,
> > >
> > > On 02/16/2011 12:57 PM, Eduardo Valentin wrote:
> > > > > 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).
> >
> > I think the path /sys/devices/system/soc/ will work for the MSM too. I would
> > have ideally liked it to be /sys/devices/system/soc/msm,
> > /sys/devices/system/soc/omap, etc, but we can't get to pick names for
> > devices under a class. So, we can make do with /sys/devices/system/soc/.
> >
> > > 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).
> >
> > I like the idea of have a common file across all implementations that will
> > let user space identify what implementation is exporting the other files and
> > how to interpret them.
> >
> > I would like to propose an "arch" file to identify the arch the soc info
> > file are for. I'm guessing within an arch, the soc files would mostly be the
> > same? If there are other minor differences, we can let the arch specific
> > code deal with how the files are interpreted.
> >
> > Does "arch" work for everyone?
>
> Sorry to butt in, but what kind of info are you guys talking about?

Please do butt in :-), that's what a community discussion is for.

> Like SOC revision, serial numbers, etc...?

Like SOC type (to identify different chipsets), revision, etc.

> What would an "arch" file mean? The name of the soc platform?

The arch file would pretty much be the "xxxx" from arch/arm/mach-xxxx or 
similar paths. If that info is already available elsewhere, then that 
file is not needed. I proposed using the arch since that will remove the 
need to maintain some database of unique/reserved names/numbers for each 
implementation of socinfo (like the machinetypes list we have).

-Saravana

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/