linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* soc_id content according to specification
@ 2015-03-26 13:28 Stefan Agner
  2015-03-26 13:32 ` Andrew Lunn
  0 siblings, 1 reply; 2+ messages in thread
From: Stefan Agner @ 2015-03-26 13:28 UTC (permalink / raw)
  To: linux-arm-kernel

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@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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* soc_id content according to specification
  2015-03-26 13:28 soc_id content according to specification Stefan Agner
@ 2015-03-26 13:32 ` Andrew Lunn
  0 siblings, 0 replies; 2+ messages in thread
From: Andrew Lunn @ 2015-03-26 13:32 UTC (permalink / raw)
  To: linux-arm-kernel

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

Just for clarification here. The PCE-E ID is the same as the SoC
model. So for example, the Kirkwood MV88f6281 has a PCI product id of
6281. The Armada XP mv88f78230 has a PCI product id of 8230.

      Andrew

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2015-03-26 13:32 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-26 13:28 soc_id content according to specification Stefan Agner
2015-03-26 13:32 ` Andrew Lunn

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).