soc_id content according to specification

Stefan Agner stefan at agner.ch
Thu Mar 26 06:28:37 PDT 2015


Hi all,

While looking into current sysfs soc bus implementations (in preparation
for adding such an implementation for the Freescale Vybrid SoC), I
discovered different interpretations of the "soc_id" field between
SoC's.

The sysfs Documentation says
(Documentation/ABI/testing/sysfs-devices-soc):
<quote>
What:		/sys/devices/socX/soc_id
Date:		January 2012
contact:	Lee Jones <lee.jones at linaro.org>
Description:
		Read-only attribute supported by most SoCs. In the case of
		ST-Ericsson's chips this contains the SoC serial number.
</quote>

The name of the file "soc_id" is open for different interpretation: Is
the soc_id the identification of the SoC "type" or the identification of
the SoC "instance"? The description suggests that the second is the idea
behind soc_id (SoC serial number). IMHO, in that case, soc_uid would
have been more descriptive.

However, lets have a look at the implementations (the ones I caught at
first sight):

2012 Feb:
eda413c228e2 ("ARM: ux500: export System-on-Chip information ux500 via
sysfs")
=> 160-bit hexadecimal unique ID

2013 March:
d591fdf8e23e ("ARM: tegra: expose chip ID and revision")
=> 8-bit unsigned chip ID (e.g. 32 for Tegra 2, 48 Tegra 3...)

2013 Jul:
00f7dc636366 ("ARM: zynq: Add support for SOC_BUS")
=> 5-bit hexadecimal "device code id" (the register also says "PS Family
IDCODE")

2013 Aug:
a28875462bd4 ("ARM: imx6: report soc info via soc device")
=> string representing SoC type

2013 Nov:
b19e11fbb2d4 ("ARM: ep93xx: use soc bus")
=> 128-bit hexadecimal unique ID

2014 March:
56a705a48eae ("ARM: mvebu: Add a SOC bus device entry")
=> 16-bit hexadecimal PCI-E device ID?

2014 Aug:
e4e3a37d3316 ("ARM: clps711x: Add SOC BUS support")
=> 32-bit hexadecimal unique ID

So we have currently 7 implementations, of which 4 implement an ID per
SoC type and 3 an ID per SoC instance.

I think for the long run it would be nice if we can agree on what the
API exactly asks for and fix the wrong implementations accordingly. Any
thoughts on this? 

--
Stefan



More information about the linux-arm-kernel mailing list