Introduce the /proc/socinfo and use it to export OMAP data
Get series with b4
b4 am [email protected]Versions newest first · linked by author and title
- v5 Latest posting 3/30 of 3 patches 0 repliesNew
- v5 posting 2/30 of 3 patches 0 repliesSuperseded
- v5 posting 1/30 of 3 patches 0 repliesSuperseded
Patches in v5 posting 3/3 No applies recorded yet
None of the 3 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v5 yet.
Cover letter [PATCHv5 0/3] Introduce the /proc/socinfo and use it to export OMAP data
Quoted 8 lines · Jamie Iles
Quoted 7 lines · Linus Walleij
Quoted 4 lines · Maxime Coquelin
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
Quoted 7 lines
Quoted 4 lines
Arbitrary number of bits? Some will have a 64-bit ID, some will have 32-bit etc.
Should we say it's a hex string of 64 bits?
Could we provide hooks for the platform that takes the buffer and length and let the platform do the
snprintf()? Our devices have a 128-bit serial number and I'm sure there must be others.
This is one possibility, another one is to let the platform specify how it exports this serial, as you proposed bellow.
Quoted 10 lines
Quoted 5 lines
Quoted 5 lines
/sys/devices/system/soc/mach//sys/devices/system/soc/mach/name<- Name of the mach/sys/devices/system/soc/mach/foo_id/sys/devices/system/soc/mach/bar_id<- Vendors may have several/different IDs to export (IDCODE for OMAP, Production ID...)Do we need a way to allow platforms to specify additional attributes to co into the socinfo? For our devices we can boot in different modes and how we boot determines how the firmware is upgraded. In the case above the platform could specify that it needs
foo_idandbar_idand the callbacks to fill them in.
Yes it was what I thought with the foo and bar IDs exports.
Maxime