From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932976AbaLDR5z (ORCPT ); Thu, 4 Dec 2014 12:57:55 -0500 Received: from mail-wg0-f42.google.com ([74.125.82.42]:59100 "EHLO mail-wg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932695AbaLDR5y (ORCPT ); Thu, 4 Dec 2014 12:57:54 -0500 From: Pali =?utf-8?q?Roh=C3=A1r?= To: Rob Herring Subject: Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible Date: Thu, 4 Dec 2014 18:57:48 +0100 User-Agent: KMail/1.13.7 (Linux/3.18.0-031800rc5-generic; KDE/4.14.1; x86_64; ; ) Cc: Russell King , Santosh Shilimkar , Will Deacon , Ivaylo Dimitrov , Sebastian Reichel , Pavel Machek , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" , Tony Lindgren References: <1403110464-29646-1-git-send-email-pali.rohar@gmail.com> <201412040148.31033@pali> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2098087.kgLVLCanfX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201412041857.49341@pali> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --nextPart2098087.kgLVLCanfX Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Thursday 04 December 2014 17:49:40 Rob Herring wrote: > On Wed, Dec 3, 2014 at 6:48 PM, Pali Roh=C3=A1r=20 wrote: > > On Thursday 04 December 2014 01:33:08 Rob Herring wrote: > >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh=C3=A1r > >=20 > > wrote: > >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote: > >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh=C3=A1r > >> >=20 > >> > wrote: > >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote: > >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh=C3=A1r > >> >> >=20 > >> >> > wrote: > >> >> >> > Machine name from board description is some generic > >> >> >> > name on DT kernel. DT provides machine name > >> >> >> > property which is specific for board, so use it > >> >> >> > instead generic one when possible. > >>=20 > >> [...] > >>=20 > >> >> > Basically in DT kernel is missing Hardware, Revision > >> >> > and probably also Serial key. (Now I used only qemu > >> >> > for testing which set serial key to 0). All these > >> >> > informations is used by userspace applications which > >> >> > determinate how to behave. > >> >>=20 > >> >> It is somewhat fragile to expect the name in the DT to > >> >> match the old name from the kernel. As your patch to > >> >> n900 dts shows, we'd probably have to update every dts > >> >> file to make them match. While I think we should work > >> >> to remove this string from the kernel, userspace > >> >> depending on the DT model string is a bad idea. For > >> >> example, if you had some platform with multiple OEMs > >> >> just rebranding the same base design, they may all want > >> >> to put their own model string into each product. The > >> >> true h/w id is the compatible string. > >> >>=20 > >> >> Serial number is easy. There is already a standard > >> >> although not widely used property for it with > >> >> "/serial-number". You just need to wire it up to > >> >> cpuinfo. > >> >=20 > >> > There is no "/serial-number" property in kernel: > >> >=20 > >> > $ ls -l -a /sys/bus/soc/devices/soc0/ > >> > drwxr-xr-x 3 0 0 0 Jan 1 00:00 > >> > . drwxr-xr-x 18 0 0 0 Jan 1 > >> > 00:00 .. -r--r--r-- 1 0 0 4096 Jan > >> > 1 00:00 family -r--r--r-- 1 0 0 =20 > >> > 4096 Jan 1 00:00 machine drwxr-xr-x 2 0 0 =20 > >> > 0 Jan 1 00:00 power -r--r--r-- 1 0 =20 > >> > 0 > >> > 4096 Jan 1 00:00 revision lrwxrwxrwx 1 0 0 > >> >=20 > >> > 0 Jan 1 00:00 subsystem -> ../../bus/soc > >> >=20 > >> > -r--r--r-- 1 0 0 4096 Jan 1 00:00 > >> > type -rw-r--r-- 1 0 0 4096 Jan 1 > >> > 00:00 uevent > >>=20 > >> Wrong place. If you put /serial-number in your DT, then it > >> will be in /proc/device-tree/serial-number. > >>=20 > >> If you want to wire that up to /proc/cpuinfo, I would be > >> fine with that. > >>=20 > >> Rob > >=20 > > I cannot hardcode it into DT, because it is set by > > bootloader. And bootloader tell it to kernel via ATAGs > > structure. Bootloader is closed and proprietary and cannot > > be replaced (there is no documentation for hw init). >=20 > Either the bootloader can put the serial number into the DTB > instead of ATAGs or the kernel decompressor can copy it from > ATAGs to DTB like is done already for other ATAGs. I presume > you cannot update the bootloader and will need the latter. >=20 > Rob Rob, thanks for info! Btw, theoretically I can update bootloader=20 if someone write it. So in practise I need to use second option. Can you tell me which CONFIG_ needs to be enabled for kernel=20 decompressor (so it copy some ATAGs) and where to start looking=20 at code (for adding new code for copying other ATAGs)? =2D-=20 Pali Roh=C3=A1r pali.rohar@gmail.com --nextPart2098087.kgLVLCanfX Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEABECAAYFAlSAoJ0ACgkQi/DJPQPkQ1JBSQCdH4pyA0y1nOFjy5Vi0OtMK7sy ngsAn3Bs0cskOQh73isqQ34tDT96+gOj =FbNr -----END PGP SIGNATURE----- --nextPart2098087.kgLVLCanfX-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: pali.rohar@gmail.com (Pali =?utf-8?q?Roh=C3=A1r?=) Date: Thu, 4 Dec 2014 18:57:48 +0100 Subject: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible In-Reply-To: References: <1403110464-29646-1-git-send-email-pali.rohar@gmail.com> <201412040148.31033@pali> Message-ID: <201412041857.49341@pali> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Thursday 04 December 2014 17:49:40 Rob Herring wrote: > On Wed, Dec 3, 2014 at 6:48 PM, Pali Roh?r wrote: > > On Thursday 04 December 2014 01:33:08 Rob Herring wrote: > >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r > > > > wrote: > >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote: > >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r > >> > > >> > wrote: > >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote: > >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r > >> >> > > >> >> > wrote: > >> >> >> > Machine name from board description is some generic > >> >> >> > name on DT kernel. DT provides machine name > >> >> >> > property which is specific for board, so use it > >> >> >> > instead generic one when possible. > >> > >> [...] > >> > >> >> > Basically in DT kernel is missing Hardware, Revision > >> >> > and probably also Serial key. (Now I used only qemu > >> >> > for testing which set serial key to 0). All these > >> >> > informations is used by userspace applications which > >> >> > determinate how to behave. > >> >> > >> >> It is somewhat fragile to expect the name in the DT to > >> >> match the old name from the kernel. As your patch to > >> >> n900 dts shows, we'd probably have to update every dts > >> >> file to make them match. While I think we should work > >> >> to remove this string from the kernel, userspace > >> >> depending on the DT model string is a bad idea. For > >> >> example, if you had some platform with multiple OEMs > >> >> just rebranding the same base design, they may all want > >> >> to put their own model string into each product. The > >> >> true h/w id is the compatible string. > >> >> > >> >> Serial number is easy. There is already a standard > >> >> although not widely used property for it with > >> >> "/serial-number". You just need to wire it up to > >> >> cpuinfo. > >> > > >> > There is no "/serial-number" property in kernel: > >> > > >> > $ ls -l -a /sys/bus/soc/devices/soc0/ > >> > drwxr-xr-x 3 0 0 0 Jan 1 00:00 > >> > . drwxr-xr-x 18 0 0 0 Jan 1 > >> > 00:00 .. -r--r--r-- 1 0 0 4096 Jan > >> > 1 00:00 family -r--r--r-- 1 0 0 > >> > 4096 Jan 1 00:00 machine drwxr-xr-x 2 0 0 > >> > 0 Jan 1 00:00 power -r--r--r-- 1 0 > >> > 0 > >> > 4096 Jan 1 00:00 revision lrwxrwxrwx 1 0 0 > >> > > >> > 0 Jan 1 00:00 subsystem -> ../../bus/soc > >> > > >> > -r--r--r-- 1 0 0 4096 Jan 1 00:00 > >> > type -rw-r--r-- 1 0 0 4096 Jan 1 > >> > 00:00 uevent > >> > >> Wrong place. If you put /serial-number in your DT, then it > >> will be in /proc/device-tree/serial-number. > >> > >> If you want to wire that up to /proc/cpuinfo, I would be > >> fine with that. > >> > >> Rob > > > > I cannot hardcode it into DT, because it is set by > > bootloader. And bootloader tell it to kernel via ATAGs > > structure. Bootloader is closed and proprietary and cannot > > be replaced (there is no documentation for hw init). > > Either the bootloader can put the serial number into the DTB > instead of ATAGs or the kernel decompressor can copy it from > ATAGs to DTB like is done already for other ATAGs. I presume > you cannot update the bootloader and will need the latter. > > Rob Rob, thanks for info! Btw, theoretically I can update bootloader if someone write it. So in practise I need to use second option. Can you tell me which CONFIG_ needs to be enabled for kernel decompressor (so it copy some ATAGs) and where to start looking at code (for adding new code for copying other ATAGs)? -- Pali Roh?r pali.rohar at gmail.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: