lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Wed, 18 Jun 2014 17:27:16 -0500
From:	Rob Herring <>
To:	Russell King - ARM Linux <>
Cc:	Pali Rohár <>,
	Santosh Shilimkar <>,
	Will Deacon <>,
	Ivaylo Dimitrov <>,
	Sebastian Reichel <>,
	Pavel Machek <>,
	"" <>,
Subject: Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible

On Wed, Jun 18, 2014 at 4:47 PM, Russell King - ARM Linux
<> wrote:
> On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <> wrote:
>> > Also I still did not know why DT kernel does not report Revision
>> > number which is passed by bootloader via atags. Any idea?
>> Probably because no one cared until now and revision info for every
>> SOC is different. I would like to see revision info set in the DT in a
>> standard way and remove the various SOC specific kernel
>> implementations.
> Except... that's not what it is.  What that revision field was originally
> invented for was the Netwinder to indicate the _platform_ revision.

Okay. DT describes the platform, so having a top-level revision in the
DT could be similar, but...

> From what I've seen, almost everyone else sets this to zero in their
> boot loaders - it is /very/ rarely used.  However, I think OMAP (ab)uses
> it by putting the SoC revision into it at kernel boot time.  That's
> not what it is supposed to be used for.

it could suffer the same abuse as the ATAG.

Perhaps if Revision in cpuinfo is never going to be set for DT based
platforms, then we should remove it from cpuinfo in that case.

> Others have already solved the problem of exporting SoC specific
> information, such as SoC name, SoC revision, etc, if only people would
> use it - drivers/base/soc.c.  This gives machine, family, soc_id and
> SoC revision information in a standard place - it /might/ have been
> a good idea if the creation of that also contained documentation for
> what was expected in each of the fields, rather than leaving it
> open...

The problem with soc-device is it is optional and at the whim of the
platform to add. Adding it also causes the the platform devices to
change paths because people make the soc device the bus parent. Sysfs
paths to devices are not considered part of the ABI, but still this is
a silly reason to change the path. If we want soc-device to be used,
then it should always exist and have a default version.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists