[PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data

[skannan@codeaurora.org (Saravana Kannan)]

On 03/02/2011 02:53 AM, Maxime Coquelin wrote:
> On 03/02/2011 11:36 AM, Linus Walleij wrote:
>> On Wed, Mar 2, 2011 at 9:23 AM, Maxime Coquelin
>> <maxime.coquelin-nonst@stericsson.com> wrote:
>>
>>> I think we should have a tree like this :
>>>
>>> /sys/devices/system/soc/
>>> /sys/devices/system/soc/unique_id<- Unified way to export an ID for
>>> all machs
>> Arbitrary number of bits? Some will have a 64-bit ID, some will have
>> 32-bit
>> etc.
>
> Yes, here is the difficulty. For example, in our case, the SoC unique ID
> is 160 bits long.
> Maybe it would be a better solution to get rid of this unified file, and
> keep only mach specific entries? I mean :
>
> /sys/devices/system/soc/
> /sys/devices/system/soc/mach_name
> /sys/devices/system/soc/foo_id
> /sys/devices/system/soc/bar_id

Sorry for the late reply guys. Got wrapped up is some other stuff.

I'm with Maxime on getting rid of the unique id file. It's not as if 
it's unique across all machs and archs. Any user space caring to look at 
the id will anyway have to check the mach/family first. So, there is no 
point in having this unique id file. It just adds more weirdness and 
complexity to deal with the different formats or ways each family wants 
to export the id. Actually, in the case of MSM, we don't have any need 
to export unique id. We just want to export what type of soc it is 
within the MSM family.

As for the path, it's not clear we have settled on the final path. I see 
us ping-pong between /sys/devices/system/soc/ and 
/sys/devices/system/soc/mach/. Can we drop the "mach" subdir? Seems 
pointless.

The mandatory file, I would like to call it "family", since "mach" is 
too specific (omap3 and omap4 is my usual example -- they can have one 
implementation of socinfo and report the family as "omap"). We don't 
want people to misunderstand "mach" to be an accurate representation of 
the xxxx in mach-xxxx.

The patch that adds this should probably allow each socinfo 
implementation to specify the family name and an array of attributes 
(struct attribute *) that can be used to expose whatever else they want 
to export.

Thanks,
Saravana
-- 
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.