All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: Rob Herring <robherring2@gmail.com>
Cc: devicetree <devicetree@vger.kernel.org>,
	Ian Campbell <ijc@hellion.org.uk>, U-Boot <u-boot@lists.denx.de>
Subject: Re: serial atag tag in devicetree ?
Date: Mon, 23 Mar 2015 12:30:57 +0100	[thread overview]
Message-ID: <550FF971.407@redhat.com> (raw)
In-Reply-To: <CAL_JsqK0VtDj_FmA8tQ5MRmGm-o2w7ia9U2_nD0aFDtTSfns2A@mail.gmail.com>

Hi,

On 22-03-15 22:01, Rob Herring wrote:
> On Sun, Mar 22, 2015 at 6:26 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi All,
>>
>> I'm sending this mail because Paul Kocialkowski (in the Cc)
>> has submitted a patch for upstream u-boot to set the serial
>> atag tag from u-boot for Allwinner SoCs, using the SoCs
>> SID, which is a 128 bit register containing a unique number
>> for each SoC.
>
> We shouldn't really be adding ATAGs to newer platforms...
>
>> In some cases a manufacturer may want to override this with
>> its own serial from say an eeprom, as such it is desirable
>> to communicate the serial from u-boot to the kernel rather
>> then reproducing the sid reading code in the kernel.
>>
>> For old atag using kernels there is an atag for this, and
>> the contents of this tag will show up in /proc/cpuinfo,
>> currently there is no equivalent for this in devicetree.
>>
>> I'm a bit reluctant to merge Paul's patch into u-boot
>> because of this as it will enable a feature on older
>> kernels while leaving the upstream kernel without it.
>>
>> So I was wondering how to deal with this in devicetree,
>> at least one board in u-boot already sets a devicetree
>> property for this:
>>
>> board/gateworks/gw_ventana/gw_ventana.c
>> 1202: *   serial# env var
>> 1207:   char *serial = getenv("serial#");
>> 1432:           setenv("serial#", str);
>> 1512:   fdt_setprop(blob, 0, "system-serial", getenv("serial#"),
>> 1513:               strlen(getenv("serial#")) + 1);
>>
>> Which sets a system-serial property in the root node,
>> so at the same level where we also have the model string
>> this seems to make sense to me.
>
> system-serial is new to me...
>
>> So do we want to add a devicetree binding for system
>> serials, and if we do should we make it a string like
>> above, or should we make it an 64 bit integer like the atag?
>>
>> If we make it a string we can store longer serials, but
>> how should we deal with those wrt /proc/cpuinfo? Only show
>> the first 64 bits ?
>
> There is already "serial-number" (a string) which exists for
> OpenFirmware. Also, "copyright" corresponds to vendor/manufacturer
> string. Both of these are supported by lshw already.

Ok, so if I understand you correctly then you're saying that we
should set a "serial-number" string property at the dt root level
and that this may contain pretty much anything, e.g. in the
sunxi case the full 128 bit SID in hex.

Is the use of the "serial-number" string property already documented
somewhere? If not I'll submit a kernel patch to document it.

And for older kernels we should not set any serial atag (u-boot
always sets it, so this leaves it at 0) and old kernel users are
out of luck wrt getting to the serial ?

Regards,

Hans

WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] serial atag tag in devicetree ?
Date: Mon, 23 Mar 2015 12:30:57 +0100	[thread overview]
Message-ID: <550FF971.407@redhat.com> (raw)
In-Reply-To: <CAL_JsqK0VtDj_FmA8tQ5MRmGm-o2w7ia9U2_nD0aFDtTSfns2A@mail.gmail.com>

Hi,

On 22-03-15 22:01, Rob Herring wrote:
> On Sun, Mar 22, 2015 at 6:26 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi All,
>>
>> I'm sending this mail because Paul Kocialkowski (in the Cc)
>> has submitted a patch for upstream u-boot to set the serial
>> atag tag from u-boot for Allwinner SoCs, using the SoCs
>> SID, which is a 128 bit register containing a unique number
>> for each SoC.
>
> We shouldn't really be adding ATAGs to newer platforms...
>
>> In some cases a manufacturer may want to override this with
>> its own serial from say an eeprom, as such it is desirable
>> to communicate the serial from u-boot to the kernel rather
>> then reproducing the sid reading code in the kernel.
>>
>> For old atag using kernels there is an atag for this, and
>> the contents of this tag will show up in /proc/cpuinfo,
>> currently there is no equivalent for this in devicetree.
>>
>> I'm a bit reluctant to merge Paul's patch into u-boot
>> because of this as it will enable a feature on older
>> kernels while leaving the upstream kernel without it.
>>
>> So I was wondering how to deal with this in devicetree,
>> at least one board in u-boot already sets a devicetree
>> property for this:
>>
>> board/gateworks/gw_ventana/gw_ventana.c
>> 1202: *   serial# env var
>> 1207:   char *serial = getenv("serial#");
>> 1432:           setenv("serial#", str);
>> 1512:   fdt_setprop(blob, 0, "system-serial", getenv("serial#"),
>> 1513:               strlen(getenv("serial#")) + 1);
>>
>> Which sets a system-serial property in the root node,
>> so at the same level where we also have the model string
>> this seems to make sense to me.
>
> system-serial is new to me...
>
>> So do we want to add a devicetree binding for system
>> serials, and if we do should we make it a string like
>> above, or should we make it an 64 bit integer like the atag?
>>
>> If we make it a string we can store longer serials, but
>> how should we deal with those wrt /proc/cpuinfo? Only show
>> the first 64 bits ?
>
> There is already "serial-number" (a string) which exists for
> OpenFirmware. Also, "copyright" corresponds to vendor/manufacturer
> string. Both of these are supported by lshw already.

Ok, so if I understand you correctly then you're saying that we
should set a "serial-number" string property at the dt root level
and that this may contain pretty much anything, e.g. in the
sunxi case the full 128 bit SID in hex.

Is the use of the "serial-number" string property already documented
somewhere? If not I'll submit a kernel patch to document it.

And for older kernels we should not set any serial atag (u-boot
always sets it, so this leaves it at 0) and old kernel users are
out of luck wrt getting to the serial ?

Regards,

Hans

  reply	other threads:[~2015-03-23 11:30 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-22 11:26 serial atag tag in devicetree ? Hans de Goede
2015-03-22 11:26 ` [U-Boot] " Hans de Goede
2015-03-22 21:01 ` Rob Herring
2015-03-22 21:01   ` [U-Boot] " Rob Herring
2015-03-23 11:30   ` Hans de Goede [this message]
2015-03-23 11:30     ` Hans de Goede
     [not found]     ` <550FF971.407-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-03-23 23:12       ` Rob Herring
2015-03-23 23:12         ` Rob Herring
     [not found]         ` <CAL_JsqLev+DeWCzvhF7bwYk3URxpgaQDR+6OmwWHjJ2nx=HijQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-03-24  8:01           ` Hans de Goede
2015-03-24  8:01             ` Hans de Goede
2015-03-25 22:35             ` Paul Kocialkowski
2015-03-25 22:35               ` [U-Boot] " Paul Kocialkowski
2015-03-26  8:53               ` Hans de Goede
2015-03-26  8:53                 ` [U-Boot] " Hans de Goede
2015-03-26  9:11                 ` Paul Kocialkowski
2015-03-26  9:11                   ` [U-Boot] " Paul Kocialkowski
2015-03-26  9:16                   ` Paul Kocialkowski
2015-03-26  9:16                     ` Paul Kocialkowski
2015-03-27  4:30                   ` Rob Herring
2015-03-27  4:30                     ` Rob Herring
2015-03-27  8:36                     ` Hans de Goede
2015-03-27  8:36                       ` [U-Boot] " Hans de Goede
2015-03-27 10:23                     ` Paul Kocialkowski
2015-03-27 10:23                       ` [U-Boot] " Paul Kocialkowski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550FF971.407@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=devicetree@vger.kernel.org \
    --cc=ijc@hellion.org.uk \
    --cc=robherring2@gmail.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.