serial atag tag in devicetree ?

serial atag tag in devicetree ?

[Hans de Goede]

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.

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.

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 ?

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[U-Boot] serial atag tag in devicetree ?

[Hans de Goede]

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.

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.

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 ?

Regards,

Hans

Re: serial atag tag in devicetree ?

[Rob Herring]

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.

Rob

>
> Regards,
>
> Hans
> _______________________________________________
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] serial atag tag in devicetree ?

[Rob Herring]

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.

Rob

>
> Regards,
>
> Hans
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

Re: serial atag tag in devicetree ?

[Hans de Goede]

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

[U-Boot] serial atag tag in devicetree ?

[Hans de Goede]

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

Re: [U-Boot] serial atag tag in devicetree ?

[Rob Herring]

On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> Hi,
>
>
> On 22-03-15 22:01, Rob Herring wrote:
>>
>> On Sun, Mar 22, 2015 at 6:26 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>> 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.

Right.

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

Not that I'm aware of. It is something that predates our documentation
requirements. It could be in OpenFirmware specs. Documenting it in the
DT bindings does not hurt.

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

If there is sufficient reason to support this on old kernels you could.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[U-Boot] serial atag tag in devicetree ?

[Rob Herring]

On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> 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.

Right.

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

Not that I'm aware of. It is something that predates our documentation
requirements. It could be in OpenFirmware specs. Documenting it in the
DT bindings does not hurt.

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

If there is sufficient reason to support this on old kernels you could.

Rob

Re: [U-Boot] serial atag tag in devicetree ?

[Hans de Goede]

Hi,

On 24-03-15 00:12, Rob Herring wrote:
> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> Hi,
>>
>>
>> On 22-03-15 22:01, Rob Herring wrote:

<snip>

>>> 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.
>
> Right.
>
>> Is the use of the "serial-number" string property already documented
>> somewhere? If not I'll submit a kernel patch to document it.
>
> Not that I'm aware of. It is something that predates our documentation
> requirements. It could be in OpenFirmware specs. Documenting it in the
> DT bindings does not hurt.

Ok.

>> 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 ?
>
> If there is sufficient reason to support this on old kernels you could.

One problem with supporting this for older kernels is that if a non 0
serial gets shown in /proc/cpuinfo with older atag booted kernels, we
should really show the same number in /proc/cpuinfo which means adding
code to the kernel to get the devicetree "serial-number" string property
and somehow put that into the 64 bits which we have in /proc/cpuinfo,
but given that the "serial-number" string could be hex or decimal or
what ever and > 64 bits that will likely require a platform specific
solution. All doable, but the question then becomes is this worth the
effort ?

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[U-Boot] serial atag tag in devicetree ?

[Hans de Goede]

Hi,

On 24-03-15 00:12, Rob Herring wrote:
> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>>
>> On 22-03-15 22:01, Rob Herring wrote:

<snip>

>>> 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.
>
> Right.
>
>> Is the use of the "serial-number" string property already documented
>> somewhere? If not I'll submit a kernel patch to document it.
>
> Not that I'm aware of. It is something that predates our documentation
> requirements. It could be in OpenFirmware specs. Documenting it in the
> DT bindings does not hurt.

Ok.

>> 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 ?
>
> If there is sufficient reason to support this on old kernels you could.

One problem with supporting this for older kernels is that if a non 0
serial gets shown in /proc/cpuinfo with older atag booted kernels, we
should really show the same number in /proc/cpuinfo which means adding
code to the kernel to get the devicetree "serial-number" string property
and somehow put that into the 64 bits which we have in /proc/cpuinfo,
but given that the "serial-number" string could be hex or decimal or
what ever and > 64 bits that will likely require a platform specific
solution. All doable, but the question then becomes is this worth the
effort ?

Regards,

Hans

Re: serial atag tag in devicetree ?

[Paul Kocialkowski]

[-- Attachment #1.1: Type: text/plain, Size: 4134 bytes --]

Le mardi 24 mars 2015 à 09:01 +0100, Hans de Goede a écrit :
> Hi,
> 
> On 24-03-15 00:12, Rob Herring wrote:
> > On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> >> Hi,
> >>
> >>
> >> On 22-03-15 22:01, Rob Herring wrote:
> 
> <snip>
> 
> >>> 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.
> >
> > Right.
> >
> >> Is the use of the "serial-number" string property already documented
> >> somewhere? If not I'll submit a kernel patch to document it.
> >
> > Not that I'm aware of. It is something that predates our documentation
> > requirements. It could be in OpenFirmware specs. Documenting it in the
> > DT bindings does not hurt.
> 
> Ok.
> 
> >> 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 ?
> >
> > If there is sufficient reason to support this on old kernels you could.
> 
> One problem with supporting this for older kernels is that if a non 0
> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
> should really show the same number in /proc/cpuinfo which means adding
> code to the kernel to get the devicetree "serial-number" string property
> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
> but given that the "serial-number" string could be hex or decimal or
> what ever and > 64 bits that will likely require a platform specific
> solution. All doable, but the question then becomes is this worth the
> effort ?

After investigating a bit more, I found out that the USB serial number
is expected to be a string of 32 bytes, so a 128 bit numeric serial
doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
so there is no room left for the terminating null byte), hence it makes
sense to keep a 64 bit limitation for the serial number, if users are
going to rely on it as USB serial string. Moreover, it seems that
Android devices are mostly used 64 bit numbers for serial numbers/

I was initially going to suggest that we set it in stone that serial
must be 64 numeric bits (as it was in the ATAGs days) and that
bootloaders would pass it that way to the kernel through device tree
(with two 32 bits numeric integers), but Hans talked me out of it.
I just want to expose the situation (especially the USB and Android
thing) here to double-check that everyone still is convinced that a
string approach in device tree is best (which is fine with me).

This way, users that still want to use the serial passed through device
tree as a USB serial number will have to use a string of 32 bits,
including the null terminating byte (which is what I'll suggest for
sunxi by using only 64 bits for the serial number).

Also, I suggest that we show that serial-number string as-is in cpuinfo
as well and instead make a string out of the serial ATAG in the kernel
prior to showing it in cpuinfo (as opposed to translating the string
coming from device tree to a numeric value that cpuinfo will end up
showing as a string at the end of the day). Thus, the serial number
coming from device tree will still be shown in cpuinfo as well and no
ABI gets broken.

If you're all okay with this, I'll be sending patches to both U-Boot and
Linux to start documenting/implementing this.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 134 bytes --]

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] serial atag tag in devicetree ?

[Paul Kocialkowski]

Le mardi 24 mars 2015 ? 09:01 +0100, Hans de Goede a ?crit :
> Hi,
> 
> On 24-03-15 00:12, Rob Herring wrote:
> > On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> >> Hi,
> >>
> >>
> >> On 22-03-15 22:01, Rob Herring wrote:
> 
> <snip>
> 
> >>> 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.
> >
> > Right.
> >
> >> Is the use of the "serial-number" string property already documented
> >> somewhere? If not I'll submit a kernel patch to document it.
> >
> > Not that I'm aware of. It is something that predates our documentation
> > requirements. It could be in OpenFirmware specs. Documenting it in the
> > DT bindings does not hurt.
> 
> Ok.
> 
> >> 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 ?
> >
> > If there is sufficient reason to support this on old kernels you could.
> 
> One problem with supporting this for older kernels is that if a non 0
> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
> should really show the same number in /proc/cpuinfo which means adding
> code to the kernel to get the devicetree "serial-number" string property
> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
> but given that the "serial-number" string could be hex or decimal or
> what ever and > 64 bits that will likely require a platform specific
> solution. All doable, but the question then becomes is this worth the
> effort ?

After investigating a bit more, I found out that the USB serial number
is expected to be a string of 32 bytes, so a 128 bit numeric serial
doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
so there is no room left for the terminating null byte), hence it makes
sense to keep a 64 bit limitation for the serial number, if users are
going to rely on it as USB serial string. Moreover, it seems that
Android devices are mostly used 64 bit numbers for serial numbers/

I was initially going to suggest that we set it in stone that serial
must be 64 numeric bits (as it was in the ATAGs days) and that
bootloaders would pass it that way to the kernel through device tree
(with two 32 bits numeric integers), but Hans talked me out of it.
I just want to expose the situation (especially the USB and Android
thing) here to double-check that everyone still is convinced that a
string approach in device tree is best (which is fine with me).

This way, users that still want to use the serial passed through device
tree as a USB serial number will have to use a string of 32 bits,
including the null terminating byte (which is what I'll suggest for
sunxi by using only 64 bits for the serial number).

Also, I suggest that we show that serial-number string as-is in cpuinfo
as well and instead make a string out of the serial ATAG in the kernel
prior to showing it in cpuinfo (as opposed to translating the string
coming from device tree to a numeric value that cpuinfo will end up
showing as a string at the end of the day). Thus, the serial number
coming from device tree will still be shown in cpuinfo as well and no
ABI gets broken.

If you're all okay with this, I'll be sending patches to both U-Boot and
Linux to start documenting/implementing this.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150325/b39d97ad/attachment.sig>

Re: serial atag tag in devicetree ?

[Hans de Goede]

Hi,

On 25-03-15 23:35, Paul Kocialkowski wrote:
> Le mardi 24 mars 2015 à 09:01 +0100, Hans de Goede a écrit :
>> Hi,
>>
>> On 24-03-15 00:12, Rob Herring wrote:
>>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>>
>>>> On 22-03-15 22:01, Rob Herring wrote:
>>
>> <snip>
>>
>>>>> 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.
>>>
>>> Right.
>>>
>>>> Is the use of the "serial-number" string property already documented
>>>> somewhere? If not I'll submit a kernel patch to document it.
>>>
>>> Not that I'm aware of. It is something that predates our documentation
>>> requirements. It could be in OpenFirmware specs. Documenting it in the
>>> DT bindings does not hurt.
>>
>> Ok.
>>
>>>> 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 ?
>>>
>>> If there is sufficient reason to support this on old kernels you could.
>>
>> One problem with supporting this for older kernels is that if a non 0
>> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
>> should really show the same number in /proc/cpuinfo which means adding
>> code to the kernel to get the devicetree "serial-number" string property
>> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
>> but given that the "serial-number" string could be hex or decimal or
>> what ever and > 64 bits that will likely require a platform specific
>> solution. All doable, but the question then becomes is this worth the
>> effort ?
>
> After investigating a bit more, I found out that the USB serial number
> is expected to be a string of 32 bytes, so a 128 bit numeric serial
> doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
> so there is no room left for the terminating null byte), hence it makes
> sense to keep a 64 bit limitation for the serial number, if users are
> going to rely on it as USB serial string. Moreover, it seems that
> Android devices are mostly used 64 bit numbers for serial numbers/
>
> I was initially going to suggest that we set it in stone that serial
> must be 64 numeric bits (as it was in the ATAGs days) and that
> bootloaders would pass it that way to the kernel through device tree
> (with two 32 bits numeric integers), but Hans talked me out of it.
> I just want to expose the situation (especially the USB and Android
> thing) here to double-check that everyone still is convinced that a
> string approach in device tree is best (which is fine with me).

There are already existing users of the serial-number property in devicetree,
and these already use a free-format string, so AFAICT we have no choice
but to do the same as the existing users.

But Rob is the expert here, so lets see what Rob has to say.

> This way, users that still want to use the serial passed through device
> tree as a USB serial number will have to use a string of 32 bits,
> including the null terminating byte (which is what I'll suggest for
> sunxi by using only 64 bits for the serial number).
>
> Also, I suggest that we show that serial-number string as-is in cpuinfo
> as well

We cannot do that because we must guarantee that the serial shown
in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
else would break the kernel <-> userspace API and potentially break
userspace apps. So we must do the devicetree -> serialnumber low/high
-> /proc/cpinfo version to guarantee that this format does not change.

And as discussed before if you want a non 0 serial in cpuinfo then
the devicetree -> serialnumber low/high should be done in sunxi
specific kernel code, as on sunxi we will know that the string in
devicetree will be a hex value, but we've no such guarantee for
other platforms, so we cannot simply have a generic function to
populate erialnumber low/high from the devicetree serial-number
string.

 > and instead make a string out of the serial ATAG in the kernel
> prior to showing it in cpuinfo (as opposed to translating the string
> coming from device tree to a numeric value that cpuinfo will end up
> showing as a string at the end of the day). Thus, the serial number
> coming from device tree will still be shown in cpuinfo as well and no
> ABI gets broken.

You're forgetting the userspace <-> kernel ABI here, the serial line
in /proc/cpuinfo is not a free form string it is a 64 bit int shown
as 0 padded hex, and we cannot change that as changing that would be
an ABI break.

> If you're all okay with this, I'll be sending patches to both U-Boot and
> Linux to start documenting/implementing this.

Thanks for your work on this, lets first hash out to few remaining unclear
details and then I'm looking forward to your patch set for this.

Regards,

Hans
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] serial atag tag in devicetree ?

[Hans de Goede]

Hi,

On 25-03-15 23:35, Paul Kocialkowski wrote:
> Le mardi 24 mars 2015 ? 09:01 +0100, Hans de Goede a ?crit :
>> Hi,
>>
>> On 24-03-15 00:12, Rob Herring wrote:
>>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>> Hi,
>>>>
>>>>
>>>> On 22-03-15 22:01, Rob Herring wrote:
>>
>> <snip>
>>
>>>>> 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.
>>>
>>> Right.
>>>
>>>> Is the use of the "serial-number" string property already documented
>>>> somewhere? If not I'll submit a kernel patch to document it.
>>>
>>> Not that I'm aware of. It is something that predates our documentation
>>> requirements. It could be in OpenFirmware specs. Documenting it in the
>>> DT bindings does not hurt.
>>
>> Ok.
>>
>>>> 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 ?
>>>
>>> If there is sufficient reason to support this on old kernels you could.
>>
>> One problem with supporting this for older kernels is that if a non 0
>> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
>> should really show the same number in /proc/cpuinfo which means adding
>> code to the kernel to get the devicetree "serial-number" string property
>> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
>> but given that the "serial-number" string could be hex or decimal or
>> what ever and > 64 bits that will likely require a platform specific
>> solution. All doable, but the question then becomes is this worth the
>> effort ?
>
> After investigating a bit more, I found out that the USB serial number
> is expected to be a string of 32 bytes, so a 128 bit numeric serial
> doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
> so there is no room left for the terminating null byte), hence it makes
> sense to keep a 64 bit limitation for the serial number, if users are
> going to rely on it as USB serial string. Moreover, it seems that
> Android devices are mostly used 64 bit numbers for serial numbers/
>
> I was initially going to suggest that we set it in stone that serial
> must be 64 numeric bits (as it was in the ATAGs days) and that
> bootloaders would pass it that way to the kernel through device tree
> (with two 32 bits numeric integers), but Hans talked me out of it.
> I just want to expose the situation (especially the USB and Android
> thing) here to double-check that everyone still is convinced that a
> string approach in device tree is best (which is fine with me).

There are already existing users of the serial-number property in devicetree,
and these already use a free-format string, so AFAICT we have no choice
but to do the same as the existing users.

But Rob is the expert here, so lets see what Rob has to say.

> This way, users that still want to use the serial passed through device
> tree as a USB serial number will have to use a string of 32 bits,
> including the null terminating byte (which is what I'll suggest for
> sunxi by using only 64 bits for the serial number).
>
> Also, I suggest that we show that serial-number string as-is in cpuinfo
> as well

We cannot do that because we must guarantee that the serial shown
in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
else would break the kernel <-> userspace API and potentially break
userspace apps. So we must do the devicetree -> serialnumber low/high
-> /proc/cpinfo version to guarantee that this format does not change.

And as discussed before if you want a non 0 serial in cpuinfo then
the devicetree -> serialnumber low/high should be done in sunxi
specific kernel code, as on sunxi we will know that the string in
devicetree will be a hex value, but we've no such guarantee for
other platforms, so we cannot simply have a generic function to
populate erialnumber low/high from the devicetree serial-number
string.

 > and instead make a string out of the serial ATAG in the kernel
> prior to showing it in cpuinfo (as opposed to translating the string
> coming from device tree to a numeric value that cpuinfo will end up
> showing as a string at the end of the day). Thus, the serial number
> coming from device tree will still be shown in cpuinfo as well and no
> ABI gets broken.

You're forgetting the userspace <-> kernel ABI here, the serial line
in /proc/cpuinfo is not a free form string it is a 64 bit int shown
as 0 padded hex, and we cannot change that as changing that would be
an ABI break.

> If you're all okay with this, I'll be sending patches to both U-Boot and
> Linux to start documenting/implementing this.

Thanks for your work on this, lets first hash out to few remaining unclear
details and then I'm looking forward to your patch set for this.

Regards,

Hans

Re: serial atag tag in devicetree ?

[Paul Kocialkowski]

[-- Attachment #1.1: Type: text/plain, Size: 6543 bytes --]

Le jeudi 26 mars 2015 à 09:53 +0100, Hans de Goede a écrit :
> Hi,
> 
> On 25-03-15 23:35, Paul Kocialkowski wrote:
> > Le mardi 24 mars 2015 à 09:01 +0100, Hans de Goede a écrit :
> >> Hi,
> >>
> >> On 24-03-15 00:12, Rob Herring wrote:
> >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>> Hi,
> >>>>
> >>>>
> >>>> On 22-03-15 22:01, Rob Herring wrote:
> >>
> >> <snip>
> >>
> >>>>> 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.
> >>>
> >>> Right.
> >>>
> >>>> Is the use of the "serial-number" string property already documented
> >>>> somewhere? If not I'll submit a kernel patch to document it.
> >>>
> >>> Not that I'm aware of. It is something that predates our documentation
> >>> requirements. It could be in OpenFirmware specs. Documenting it in the
> >>> DT bindings does not hurt.
> >>
> >> Ok.
> >>
> >>>> 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 ?
> >>>
> >>> If there is sufficient reason to support this on old kernels you could.
> >>
> >> One problem with supporting this for older kernels is that if a non 0
> >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
> >> should really show the same number in /proc/cpuinfo which means adding
> >> code to the kernel to get the devicetree "serial-number" string property
> >> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
> >> but given that the "serial-number" string could be hex or decimal or
> >> what ever and > 64 bits that will likely require a platform specific
> >> solution. All doable, but the question then becomes is this worth the
> >> effort ?
> >
> > After investigating a bit more, I found out that the USB serial number
> > is expected to be a string of 32 bytes, so a 128 bit numeric serial
> > doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
> > so there is no room left for the terminating null byte), hence it makes
> > sense to keep a 64 bit limitation for the serial number, if users are
> > going to rely on it as USB serial string. Moreover, it seems that
> > Android devices are mostly used 64 bit numbers for serial numbers/
> >
> > I was initially going to suggest that we set it in stone that serial
> > must be 64 numeric bits (as it was in the ATAGs days) and that
> > bootloaders would pass it that way to the kernel through device tree
> > (with two 32 bits numeric integers), but Hans talked me out of it.
> > I just want to expose the situation (especially the USB and Android
> > thing) here to double-check that everyone still is convinced that a
> > string approach in device tree is best (which is fine with me).
> 
> There are already existing users of the serial-number property in devicetree,
> and these already use a free-format string, so AFAICT we have no choice
> but to do the same as the existing users.
> 
> But Rob is the expert here, so lets see what Rob has to say.
> 
> > This way, users that still want to use the serial passed through device
> > tree as a USB serial number will have to use a string of 32 bits,
> > including the null terminating byte (which is what I'll suggest for
> > sunxi by using only 64 bits for the serial number).
> >
> > Also, I suggest that we show that serial-number string as-is in cpuinfo
> > as well
> 
> We cannot do that because we must guarantee that the serial shown
> in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
> else would break the kernel <-> userspace API and potentially break
> userspace apps. So we must do the devicetree -> serialnumber low/high
> -> /proc/cpinfo version to guarantee that this format does not change.
> 
> And as discussed before if you want a non 0 serial in cpuinfo then
> the devicetree -> serialnumber low/high should be done in sunxi
> specific kernel code, as on sunxi we will know that the string in
> devicetree will be a hex value, but we've no such guarantee for
> other platforms, so we cannot simply have a generic function to
> populate erialnumber low/high from the devicetree serial-number
> string.
> 
>  > and instead make a string out of the serial ATAG in the kernel
> > prior to showing it in cpuinfo (as opposed to translating the string
> > coming from device tree to a numeric value that cpuinfo will end up
> > showing as a string at the end of the day). Thus, the serial number
> > coming from device tree will still be shown in cpuinfo as well and no
> > ABI gets broken.
> 
> You're forgetting the userspace <-> kernel ABI here, the serial line
> in /proc/cpuinfo is not a free form string it is a 64 bit int shown
> as 0 padded hex, and we cannot change that as changing that would be
> an ABI break.

IMHO this really is all about interpretation. If you consider that the
serial is already a *string* and not a hex-representation of a number
(which it is when using ATAGs, but has no reason to be in general), then
my suggestion will introduce no ABI break.

Generally speaking, I found no documentation that indicates that the
serial has to be in that format. It just happens to be the case when
using ATAGs.

Also, I found an email from Rob suggesting he would be fine with wiring
the dts serial-number string to cpuinfo:
http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html

I think it's the most flexible solution and we can think of it as an
extension of the current scheme: the serial string will no longer be
limited to a hex representation of a number but can become any string.

Now I would appreciate it if Rob could weigh-in and state whether he
changed his mind on this or not.

> > If you're all okay with this, I'll be sending patches to both U-Boot and
> > Linux to start documenting/implementing this.
> 
> Thanks for your work on this, lets first hash out to few remaining unclear
> details and then I'm looking forward to your patch set for this.
> 
> Regards,
> 
> Hans


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 134 bytes --]

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] serial atag tag in devicetree ?

[Paul Kocialkowski]

Le jeudi 26 mars 2015 ? 09:53 +0100, Hans de Goede a ?crit :
> Hi,
> 
> On 25-03-15 23:35, Paul Kocialkowski wrote:
> > Le mardi 24 mars 2015 ? 09:01 +0100, Hans de Goede a ?crit :
> >> Hi,
> >>
> >> On 24-03-15 00:12, Rob Herring wrote:
> >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> >>>> Hi,
> >>>>
> >>>>
> >>>> On 22-03-15 22:01, Rob Herring wrote:
> >>
> >> <snip>
> >>
> >>>>> 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.
> >>>
> >>> Right.
> >>>
> >>>> Is the use of the "serial-number" string property already documented
> >>>> somewhere? If not I'll submit a kernel patch to document it.
> >>>
> >>> Not that I'm aware of. It is something that predates our documentation
> >>> requirements. It could be in OpenFirmware specs. Documenting it in the
> >>> DT bindings does not hurt.
> >>
> >> Ok.
> >>
> >>>> 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 ?
> >>>
> >>> If there is sufficient reason to support this on old kernels you could.
> >>
> >> One problem with supporting this for older kernels is that if a non 0
> >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
> >> should really show the same number in /proc/cpuinfo which means adding
> >> code to the kernel to get the devicetree "serial-number" string property
> >> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
> >> but given that the "serial-number" string could be hex or decimal or
> >> what ever and > 64 bits that will likely require a platform specific
> >> solution. All doable, but the question then becomes is this worth the
> >> effort ?
> >
> > After investigating a bit more, I found out that the USB serial number
> > is expected to be a string of 32 bytes, so a 128 bit numeric serial
> > doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
> > so there is no room left for the terminating null byte), hence it makes
> > sense to keep a 64 bit limitation for the serial number, if users are
> > going to rely on it as USB serial string. Moreover, it seems that
> > Android devices are mostly used 64 bit numbers for serial numbers/
> >
> > I was initially going to suggest that we set it in stone that serial
> > must be 64 numeric bits (as it was in the ATAGs days) and that
> > bootloaders would pass it that way to the kernel through device tree
> > (with two 32 bits numeric integers), but Hans talked me out of it.
> > I just want to expose the situation (especially the USB and Android
> > thing) here to double-check that everyone still is convinced that a
> > string approach in device tree is best (which is fine with me).
> 
> There are already existing users of the serial-number property in devicetree,
> and these already use a free-format string, so AFAICT we have no choice
> but to do the same as the existing users.
> 
> But Rob is the expert here, so lets see what Rob has to say.
> 
> > This way, users that still want to use the serial passed through device
> > tree as a USB serial number will have to use a string of 32 bits,
> > including the null terminating byte (which is what I'll suggest for
> > sunxi by using only 64 bits for the serial number).
> >
> > Also, I suggest that we show that serial-number string as-is in cpuinfo
> > as well
> 
> We cannot do that because we must guarantee that the serial shown
> in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
> else would break the kernel <-> userspace API and potentially break
> userspace apps. So we must do the devicetree -> serialnumber low/high
> -> /proc/cpinfo version to guarantee that this format does not change.
> 
> And as discussed before if you want a non 0 serial in cpuinfo then
> the devicetree -> serialnumber low/high should be done in sunxi
> specific kernel code, as on sunxi we will know that the string in
> devicetree will be a hex value, but we've no such guarantee for
> other platforms, so we cannot simply have a generic function to
> populate erialnumber low/high from the devicetree serial-number
> string.
> 
>  > and instead make a string out of the serial ATAG in the kernel
> > prior to showing it in cpuinfo (as opposed to translating the string
> > coming from device tree to a numeric value that cpuinfo will end up
> > showing as a string at the end of the day). Thus, the serial number
> > coming from device tree will still be shown in cpuinfo as well and no
> > ABI gets broken.
> 
> You're forgetting the userspace <-> kernel ABI here, the serial line
> in /proc/cpuinfo is not a free form string it is a 64 bit int shown
> as 0 padded hex, and we cannot change that as changing that would be
> an ABI break.

IMHO this really is all about interpretation. If you consider that the
serial is already a *string* and not a hex-representation of a number
(which it is when using ATAGs, but has no reason to be in general), then
my suggestion will introduce no ABI break.

Generally speaking, I found no documentation that indicates that the
serial has to be in that format. It just happens to be the case when
using ATAGs.

Also, I found an email from Rob suggesting he would be fine with wiring
the dts serial-number string to cpuinfo:
http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html

I think it's the most flexible solution and we can think of it as an
extension of the current scheme: the serial string will no longer be
limited to a hex representation of a number but can become any string.

Now I would appreciate it if Rob could weigh-in and state whether he
changed his mind on this or not.

> > If you're all okay with this, I'll be sending patches to both U-Boot and
> > Linux to start documenting/implementing this.
> 
> Thanks for your work on this, lets first hash out to few remaining unclear
> details and then I'm looking forward to your patch set for this.
> 
> Regards,
> 
> Hans

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150326/4ae898e8/attachment.sig>

Re: [U-Boot] serial atag tag in devicetree ?

[Paul Kocialkowski]

[-- Attachment #1: Type: text/plain, Size: 7084 bytes --]

Le jeudi 26 mars 2015 à 10:11 +0100, Paul Kocialkowski a écrit :
> Le jeudi 26 mars 2015 à 09:53 +0100, Hans de Goede a écrit :
> > Hi,
> > 
> > On 25-03-15 23:35, Paul Kocialkowski wrote:
> > > Le mardi 24 mars 2015 à 09:01 +0100, Hans de Goede a écrit :
> > >> Hi,
> > >>
> > >> On 24-03-15 00:12, Rob Herring wrote:
> > >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > >>>> Hi,
> > >>>>
> > >>>>
> > >>>> On 22-03-15 22:01, Rob Herring wrote:
> > >>
> > >> <snip>
> > >>
> > >>>>> 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.
> > >>>
> > >>> Right.
> > >>>
> > >>>> Is the use of the "serial-number" string property already documented
> > >>>> somewhere? If not I'll submit a kernel patch to document it.
> > >>>
> > >>> Not that I'm aware of. It is something that predates our documentation
> > >>> requirements. It could be in OpenFirmware specs. Documenting it in the
> > >>> DT bindings does not hurt.
> > >>
> > >> Ok.
> > >>
> > >>>> 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 ?
> > >>>
> > >>> If there is sufficient reason to support this on old kernels you could.
> > >>
> > >> One problem with supporting this for older kernels is that if a non 0
> > >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
> > >> should really show the same number in /proc/cpuinfo which means adding
> > >> code to the kernel to get the devicetree "serial-number" string property
> > >> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
> > >> but given that the "serial-number" string could be hex or decimal or
> > >> what ever and > 64 bits that will likely require a platform specific
> > >> solution. All doable, but the question then becomes is this worth the
> > >> effort ?
> > >
> > > After investigating a bit more, I found out that the USB serial number
> > > is expected to be a string of 32 bytes, so a 128 bit numeric serial
> > > doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
> > > so there is no room left for the terminating null byte), hence it makes
> > > sense to keep a 64 bit limitation for the serial number, if users are
> > > going to rely on it as USB serial string. Moreover, it seems that
> > > Android devices are mostly used 64 bit numbers for serial numbers/
> > >
> > > I was initially going to suggest that we set it in stone that serial
> > > must be 64 numeric bits (as it was in the ATAGs days) and that
> > > bootloaders would pass it that way to the kernel through device tree
> > > (with two 32 bits numeric integers), but Hans talked me out of it.
> > > I just want to expose the situation (especially the USB and Android
> > > thing) here to double-check that everyone still is convinced that a
> > > string approach in device tree is best (which is fine with me).
> > 
> > There are already existing users of the serial-number property in devicetree,
> > and these already use a free-format string, so AFAICT we have no choice
> > but to do the same as the existing users.
> > 
> > But Rob is the expert here, so lets see what Rob has to say.
> > 
> > > This way, users that still want to use the serial passed through device
> > > tree as a USB serial number will have to use a string of 32 bits,
> > > including the null terminating byte (which is what I'll suggest for
> > > sunxi by using only 64 bits for the serial number).
> > >
> > > Also, I suggest that we show that serial-number string as-is in cpuinfo
> > > as well
> > 
> > We cannot do that because we must guarantee that the serial shown
> > in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
> > else would break the kernel <-> userspace API and potentially break
> > userspace apps. So we must do the devicetree -> serialnumber low/high
> > -> /proc/cpinfo version to guarantee that this format does not change.
> > 
> > And as discussed before if you want a non 0 serial in cpuinfo then
> > the devicetree -> serialnumber low/high should be done in sunxi
> > specific kernel code, as on sunxi we will know that the string in
> > devicetree will be a hex value, but we've no such guarantee for
> > other platforms, so we cannot simply have a generic function to
> > populate erialnumber low/high from the devicetree serial-number
> > string.
> > 
> >  > and instead make a string out of the serial ATAG in the kernel
> > > prior to showing it in cpuinfo (as opposed to translating the string
> > > coming from device tree to a numeric value that cpuinfo will end up
> > > showing as a string at the end of the day). Thus, the serial number
> > > coming from device tree will still be shown in cpuinfo as well and no
> > > ABI gets broken.
> > 
> > You're forgetting the userspace <-> kernel ABI here, the serial line
> > in /proc/cpuinfo is not a free form string it is a 64 bit int shown
> > as 0 padded hex, and we cannot change that as changing that would be
> > an ABI break.
> 
> IMHO this really is all about interpretation. If you consider that the
> serial is already a *string* and not a hex-representation of a number
> (which it is when using ATAGs, but has no reason to be in general), then
> my suggestion will introduce no ABI break.
> 
> Generally speaking, I found no documentation that indicates that the
> serial has to be in that format. It just happens to be the case when
> using ATAGs.
> 
> Also, I found an email from Rob suggesting he would be fine with wiring
> the dts serial-number string to cpuinfo:
> http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html

Oh, and Russell King also seemed to agree back then:
http://lkml.iu.edu/hypermail/linux/kernel/1412.0/03318.html

Russell, Rob, what are your thoughts on this?

> I think it's the most flexible solution and we can think of it as an
> extension of the current scheme: the serial string will no longer be
> limited to a hex representation of a number but can become any string.
> 
> Now I would appreciate it if Rob could weigh-in and state whether he
> changed his mind on this or not.
> 
> > > If you're all okay with this, I'll be sending patches to both U-Boot and
> > > Linux to start documenting/implementing this.
> > 
> > Thanks for your work on this, lets first hash out to few remaining unclear
> > details and then I'm looking forward to your patch set for this.
> > 
> > Regards,
> > 
> > Hans
> 


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[U-Boot] serial atag tag in devicetree ?

[Paul Kocialkowski]

Le jeudi 26 mars 2015 ? 10:11 +0100, Paul Kocialkowski a ?crit :
> Le jeudi 26 mars 2015 ? 09:53 +0100, Hans de Goede a ?crit :
> > Hi,
> > 
> > On 25-03-15 23:35, Paul Kocialkowski wrote:
> > > Le mardi 24 mars 2015 ? 09:01 +0100, Hans de Goede a ?crit :
> > >> Hi,
> > >>
> > >> On 24-03-15 00:12, Rob Herring wrote:
> > >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> > >>>> Hi,
> > >>>>
> > >>>>
> > >>>> On 22-03-15 22:01, Rob Herring wrote:
> > >>
> > >> <snip>
> > >>
> > >>>>> 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.
> > >>>
> > >>> Right.
> > >>>
> > >>>> Is the use of the "serial-number" string property already documented
> > >>>> somewhere? If not I'll submit a kernel patch to document it.
> > >>>
> > >>> Not that I'm aware of. It is something that predates our documentation
> > >>> requirements. It could be in OpenFirmware specs. Documenting it in the
> > >>> DT bindings does not hurt.
> > >>
> > >> Ok.
> > >>
> > >>>> 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 ?
> > >>>
> > >>> If there is sufficient reason to support this on old kernels you could.
> > >>
> > >> One problem with supporting this for older kernels is that if a non 0
> > >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
> > >> should really show the same number in /proc/cpuinfo which means adding
> > >> code to the kernel to get the devicetree "serial-number" string property
> > >> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
> > >> but given that the "serial-number" string could be hex or decimal or
> > >> what ever and > 64 bits that will likely require a platform specific
> > >> solution. All doable, but the question then becomes is this worth the
> > >> effort ?
> > >
> > > After investigating a bit more, I found out that the USB serial number
> > > is expected to be a string of 32 bytes, so a 128 bit numeric serial
> > > doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
> > > so there is no room left for the terminating null byte), hence it makes
> > > sense to keep a 64 bit limitation for the serial number, if users are
> > > going to rely on it as USB serial string. Moreover, it seems that
> > > Android devices are mostly used 64 bit numbers for serial numbers/
> > >
> > > I was initially going to suggest that we set it in stone that serial
> > > must be 64 numeric bits (as it was in the ATAGs days) and that
> > > bootloaders would pass it that way to the kernel through device tree
> > > (with two 32 bits numeric integers), but Hans talked me out of it.
> > > I just want to expose the situation (especially the USB and Android
> > > thing) here to double-check that everyone still is convinced that a
> > > string approach in device tree is best (which is fine with me).
> > 
> > There are already existing users of the serial-number property in devicetree,
> > and these already use a free-format string, so AFAICT we have no choice
> > but to do the same as the existing users.
> > 
> > But Rob is the expert here, so lets see what Rob has to say.
> > 
> > > This way, users that still want to use the serial passed through device
> > > tree as a USB serial number will have to use a string of 32 bits,
> > > including the null terminating byte (which is what I'll suggest for
> > > sunxi by using only 64 bits for the serial number).
> > >
> > > Also, I suggest that we show that serial-number string as-is in cpuinfo
> > > as well
> > 
> > We cannot do that because we must guarantee that the serial shown
> > in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
> > else would break the kernel <-> userspace API and potentially break
> > userspace apps. So we must do the devicetree -> serialnumber low/high
> > -> /proc/cpinfo version to guarantee that this format does not change.
> > 
> > And as discussed before if you want a non 0 serial in cpuinfo then
> > the devicetree -> serialnumber low/high should be done in sunxi
> > specific kernel code, as on sunxi we will know that the string in
> > devicetree will be a hex value, but we've no such guarantee for
> > other platforms, so we cannot simply have a generic function to
> > populate erialnumber low/high from the devicetree serial-number
> > string.
> > 
> >  > and instead make a string out of the serial ATAG in the kernel
> > > prior to showing it in cpuinfo (as opposed to translating the string
> > > coming from device tree to a numeric value that cpuinfo will end up
> > > showing as a string at the end of the day). Thus, the serial number
> > > coming from device tree will still be shown in cpuinfo as well and no
> > > ABI gets broken.
> > 
> > You're forgetting the userspace <-> kernel ABI here, the serial line
> > in /proc/cpuinfo is not a free form string it is a 64 bit int shown
> > as 0 padded hex, and we cannot change that as changing that would be
> > an ABI break.
> 
> IMHO this really is all about interpretation. If you consider that the
> serial is already a *string* and not a hex-representation of a number
> (which it is when using ATAGs, but has no reason to be in general), then
> my suggestion will introduce no ABI break.
> 
> Generally speaking, I found no documentation that indicates that the
> serial has to be in that format. It just happens to be the case when
> using ATAGs.
> 
> Also, I found an email from Rob suggesting he would be fine with wiring
> the dts serial-number string to cpuinfo:
> http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html

Oh, and Russell King also seemed to agree back then:
http://lkml.iu.edu/hypermail/linux/kernel/1412.0/03318.html

Russell, Rob, what are your thoughts on this?

> I think it's the most flexible solution and we can think of it as an
> extension of the current scheme: the serial string will no longer be
> limited to a hex representation of a number but can become any string.
> 
> Now I would appreciate it if Rob could weigh-in and state whether he
> changed his mind on this or not.
> 
> > > If you're all okay with this, I'll be sending patches to both U-Boot and
> > > Linux to start documenting/implementing this.
> > 
> > Thanks for your work on this, lets first hash out to few remaining unclear
> > details and then I'm looking forward to your patch set for this.
> > 
> > Regards,
> > 
> > Hans
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150326/180d3d3b/attachment.sig>

Re: [U-Boot] serial atag tag in devicetree ?

[Rob Herring]

On Thu, Mar 26, 2015 at 4:11 AM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> wrote:
> Le jeudi 26 mars 2015 à 09:53 +0100, Hans de Goede a écrit :
>> Hi,
>>
>> On 25-03-15 23:35, Paul Kocialkowski wrote:
>> > Le mardi 24 mars 2015 à 09:01 +0100, Hans de Goede a écrit :
>> >> Hi,
>> >>
>> >> On 24-03-15 00:12, Rob Herring wrote:
>> >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> >>>> Hi,
>> >>>>
>> >>>>
>> >>>> On 22-03-15 22:01, Rob Herring wrote:
>> >>
>> >> <snip>
>> >>
>> >>>>> 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.
>> >>>
>> >>> Right.
>> >>>
>> >>>> Is the use of the "serial-number" string property already documented
>> >>>> somewhere? If not I'll submit a kernel patch to document it.
>> >>>
>> >>> Not that I'm aware of. It is something that predates our documentation
>> >>> requirements. It could be in OpenFirmware specs. Documenting it in the
>> >>> DT bindings does not hurt.
>> >>
>> >> Ok.
>> >>
>> >>>> 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 ?
>> >>>
>> >>> If there is sufficient reason to support this on old kernels you could.
>> >>
>> >> One problem with supporting this for older kernels is that if a non 0
>> >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
>> >> should really show the same number in /proc/cpuinfo which means adding
>> >> code to the kernel to get the devicetree "serial-number" string property
>> >> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
>> >> but given that the "serial-number" string could be hex or decimal or
>> >> what ever and > 64 bits that will likely require a platform specific
>> >> solution. All doable, but the question then becomes is this worth the
>> >> effort ?
>> >
>> > After investigating a bit more, I found out that the USB serial number
>> > is expected to be a string of 32 bytes, so a 128 bit numeric serial
>> > doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
>> > so there is no room left for the terminating null byte), hence it makes
>> > sense to keep a 64 bit limitation for the serial number, if users are
>> > going to rely on it as USB serial string. Moreover, it seems that
>> > Android devices are mostly used 64 bit numbers for serial numbers/
>> >
>> > I was initially going to suggest that we set it in stone that serial
>> > must be 64 numeric bits (as it was in the ATAGs days) and that
>> > bootloaders would pass it that way to the kernel through device tree
>> > (with two 32 bits numeric integers), but Hans talked me out of it.
>> > I just want to expose the situation (especially the USB and Android
>> > thing) here to double-check that everyone still is convinced that a
>> > string approach in device tree is best (which is fine with me).
>>
>> There are already existing users of the serial-number property in devicetree,
>> and these already use a free-format string, so AFAICT we have no choice
>> but to do the same as the existing users.
>>
>> But Rob is the expert here, so lets see what Rob has to say.
>>
>> > This way, users that still want to use the serial passed through device
>> > tree as a USB serial number will have to use a string of 32 bits,
>> > including the null terminating byte (which is what I'll suggest for
>> > sunxi by using only 64 bits for the serial number).
>> >
>> > Also, I suggest that we show that serial-number string as-is in cpuinfo
>> > as well
>>
>> We cannot do that because we must guarantee that the serial shown
>> in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
>> else would break the kernel <-> userspace API and potentially break
>> userspace apps. So we must do the devicetree -> serialnumber low/high
>> -> /proc/cpinfo version to guarantee that this format does not change.
>>
>> And as discussed before if you want a non 0 serial in cpuinfo then
>> the devicetree -> serialnumber low/high should be done in sunxi
>> specific kernel code, as on sunxi we will know that the string in
>> devicetree will be a hex value, but we've no such guarantee for
>> other platforms, so we cannot simply have a generic function to
>> populate erialnumber low/high from the devicetree serial-number
>> string.
>>
>>  > and instead make a string out of the serial ATAG in the kernel
>> > prior to showing it in cpuinfo (as opposed to translating the string
>> > coming from device tree to a numeric value that cpuinfo will end up
>> > showing as a string at the end of the day). Thus, the serial number
>> > coming from device tree will still be shown in cpuinfo as well and no
>> > ABI gets broken.
>>
>> You're forgetting the userspace <-> kernel ABI here, the serial line
>> in /proc/cpuinfo is not a free form string it is a 64 bit int shown
>> as 0 padded hex, and we cannot change that as changing that would be
>> an ABI break.
>
> IMHO this really is all about interpretation. If you consider that the
> serial is already a *string* and not a hex-representation of a number
> (which it is when using ATAGs, but has no reason to be in general), then
> my suggestion will introduce no ABI break.
>
> Generally speaking, I found no documentation that indicates that the
> serial has to be in that format. It just happens to be the case when
> using ATAGs.
>
> Also, I found an email from Rob suggesting he would be fine with wiring
> the dts serial-number string to cpuinfo:
> http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html
>
> I think it's the most flexible solution and we can think of it as an
> extension of the current scheme: the serial string will no longer be
> limited to a hex representation of a number but can become any string.
>
> Now I would appreciate it if Rob could weigh-in and state whether he
> changed his mind on this or not.

The only ABI is on platforms that used ATAGS as any DT only platform
has so far had a serial# in cpuinfo of 16 0's. With a variable length
string we can still have a fixed 16 char hex serial number that is
compatible with ATAGS. I can't imagine that we have userspace that
cares about the length and yet doesn't care the value is always 0's
since converting to DT. As long as we keep 16 0's as the default I
don't see an issue with allowing other lengths.

It is only an ABI if someone notices and if we find an ABI issue later
we can always fix it.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[U-Boot] serial atag tag in devicetree ?

[Rob Herring]

On Thu, Mar 26, 2015 at 4:11 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> Le jeudi 26 mars 2015 ? 09:53 +0100, Hans de Goede a ?crit :
>> Hi,
>>
>> On 25-03-15 23:35, Paul Kocialkowski wrote:
>> > Le mardi 24 mars 2015 ? 09:01 +0100, Hans de Goede a ?crit :
>> >> Hi,
>> >>
>> >> On 24-03-15 00:12, Rob Herring wrote:
>> >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>> >>>> Hi,
>> >>>>
>> >>>>
>> >>>> On 22-03-15 22:01, Rob Herring wrote:
>> >>
>> >> <snip>
>> >>
>> >>>>> 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.
>> >>>
>> >>> Right.
>> >>>
>> >>>> Is the use of the "serial-number" string property already documented
>> >>>> somewhere? If not I'll submit a kernel patch to document it.
>> >>>
>> >>> Not that I'm aware of. It is something that predates our documentation
>> >>> requirements. It could be in OpenFirmware specs. Documenting it in the
>> >>> DT bindings does not hurt.
>> >>
>> >> Ok.
>> >>
>> >>>> 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 ?
>> >>>
>> >>> If there is sufficient reason to support this on old kernels you could.
>> >>
>> >> One problem with supporting this for older kernels is that if a non 0
>> >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
>> >> should really show the same number in /proc/cpuinfo which means adding
>> >> code to the kernel to get the devicetree "serial-number" string property
>> >> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
>> >> but given that the "serial-number" string could be hex or decimal or
>> >> what ever and > 64 bits that will likely require a platform specific
>> >> solution. All doable, but the question then becomes is this worth the
>> >> effort ?
>> >
>> > After investigating a bit more, I found out that the USB serial number
>> > is expected to be a string of 32 bytes, so a 128 bit numeric serial
>> > doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
>> > so there is no room left for the terminating null byte), hence it makes
>> > sense to keep a 64 bit limitation for the serial number, if users are
>> > going to rely on it as USB serial string. Moreover, it seems that
>> > Android devices are mostly used 64 bit numbers for serial numbers/
>> >
>> > I was initially going to suggest that we set it in stone that serial
>> > must be 64 numeric bits (as it was in the ATAGs days) and that
>> > bootloaders would pass it that way to the kernel through device tree
>> > (with two 32 bits numeric integers), but Hans talked me out of it.
>> > I just want to expose the situation (especially the USB and Android
>> > thing) here to double-check that everyone still is convinced that a
>> > string approach in device tree is best (which is fine with me).
>>
>> There are already existing users of the serial-number property in devicetree,
>> and these already use a free-format string, so AFAICT we have no choice
>> but to do the same as the existing users.
>>
>> But Rob is the expert here, so lets see what Rob has to say.
>>
>> > This way, users that still want to use the serial passed through device
>> > tree as a USB serial number will have to use a string of 32 bits,
>> > including the null terminating byte (which is what I'll suggest for
>> > sunxi by using only 64 bits for the serial number).
>> >
>> > Also, I suggest that we show that serial-number string as-is in cpuinfo
>> > as well
>>
>> We cannot do that because we must guarantee that the serial shown
>> in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
>> else would break the kernel <-> userspace API and potentially break
>> userspace apps. So we must do the devicetree -> serialnumber low/high
>> -> /proc/cpinfo version to guarantee that this format does not change.
>>
>> And as discussed before if you want a non 0 serial in cpuinfo then
>> the devicetree -> serialnumber low/high should be done in sunxi
>> specific kernel code, as on sunxi we will know that the string in
>> devicetree will be a hex value, but we've no such guarantee for
>> other platforms, so we cannot simply have a generic function to
>> populate erialnumber low/high from the devicetree serial-number
>> string.
>>
>>  > and instead make a string out of the serial ATAG in the kernel
>> > prior to showing it in cpuinfo (as opposed to translating the string
>> > coming from device tree to a numeric value that cpuinfo will end up
>> > showing as a string at the end of the day). Thus, the serial number
>> > coming from device tree will still be shown in cpuinfo as well and no
>> > ABI gets broken.
>>
>> You're forgetting the userspace <-> kernel ABI here, the serial line
>> in /proc/cpuinfo is not a free form string it is a 64 bit int shown
>> as 0 padded hex, and we cannot change that as changing that would be
>> an ABI break.
>
> IMHO this really is all about interpretation. If you consider that the
> serial is already a *string* and not a hex-representation of a number
> (which it is when using ATAGs, but has no reason to be in general), then
> my suggestion will introduce no ABI break.
>
> Generally speaking, I found no documentation that indicates that the
> serial has to be in that format. It just happens to be the case when
> using ATAGs.
>
> Also, I found an email from Rob suggesting he would be fine with wiring
> the dts serial-number string to cpuinfo:
> http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html
>
> I think it's the most flexible solution and we can think of it as an
> extension of the current scheme: the serial string will no longer be
> limited to a hex representation of a number but can become any string.
>
> Now I would appreciate it if Rob could weigh-in and state whether he
> changed his mind on this or not.

The only ABI is on platforms that used ATAGS as any DT only platform
has so far had a serial# in cpuinfo of 16 0's. With a variable length
string we can still have a fixed 16 char hex serial number that is
compatible with ATAGS. I can't imagine that we have userspace that
cares about the length and yet doesn't care the value is always 0's
since converting to DT. As long as we keep 16 0's as the default I
don't see an issue with allowing other lengths.

It is only an ABI if someone notices and if we find an ABI issue later
we can always fix it.

Rob

Re: serial atag tag in devicetree ?

[Hans de Goede]

Hi,

On 27-03-15 05:30, Rob Herring wrote:
> On Thu, Mar 26, 2015 at 4:11 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
>> Le jeudi 26 mars 2015 à 09:53 +0100, Hans de Goede a écrit :
>>> Hi,
>>>
>>> On 25-03-15 23:35, Paul Kocialkowski wrote:
>>>> Le mardi 24 mars 2015 à 09:01 +0100, Hans de Goede a écrit :
>>>>> Hi,
>>>>>
>>>>> On 24-03-15 00:12, Rob Herring wrote:
>>>>>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> On 22-03-15 22:01, Rob Herring wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>>>> 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.
>>>>>>
>>>>>> Right.
>>>>>>
>>>>>>> Is the use of the "serial-number" string property already documented
>>>>>>> somewhere? If not I'll submit a kernel patch to document it.
>>>>>>
>>>>>> Not that I'm aware of. It is something that predates our documentation
>>>>>> requirements. It could be in OpenFirmware specs. Documenting it in the
>>>>>> DT bindings does not hurt.
>>>>>
>>>>> Ok.
>>>>>
>>>>>>> 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 ?
>>>>>>
>>>>>> If there is sufficient reason to support this on old kernels you could.
>>>>>
>>>>> One problem with supporting this for older kernels is that if a non 0
>>>>> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
>>>>> should really show the same number in /proc/cpuinfo which means adding
>>>>> code to the kernel to get the devicetree "serial-number" string property
>>>>> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
>>>>> but given that the "serial-number" string could be hex or decimal or
>>>>> what ever and > 64 bits that will likely require a platform specific
>>>>> solution. All doable, but the question then becomes is this worth the
>>>>> effort ?
>>>>
>>>> After investigating a bit more, I found out that the USB serial number
>>>> is expected to be a string of 32 bytes, so a 128 bit numeric serial
>>>> doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
>>>> so there is no room left for the terminating null byte), hence it makes
>>>> sense to keep a 64 bit limitation for the serial number, if users are
>>>> going to rely on it as USB serial string. Moreover, it seems that
>>>> Android devices are mostly used 64 bit numbers for serial numbers/
>>>>
>>>> I was initially going to suggest that we set it in stone that serial
>>>> must be 64 numeric bits (as it was in the ATAGs days) and that
>>>> bootloaders would pass it that way to the kernel through device tree
>>>> (with two 32 bits numeric integers), but Hans talked me out of it.
>>>> I just want to expose the situation (especially the USB and Android
>>>> thing) here to double-check that everyone still is convinced that a
>>>> string approach in device tree is best (which is fine with me).
>>>
>>> There are already existing users of the serial-number property in devicetree,
>>> and these already use a free-format string, so AFAICT we have no choice
>>> but to do the same as the existing users.
>>>
>>> But Rob is the expert here, so lets see what Rob has to say.
>>>
>>>> This way, users that still want to use the serial passed through device
>>>> tree as a USB serial number will have to use a string of 32 bits,
>>>> including the null terminating byte (which is what I'll suggest for
>>>> sunxi by using only 64 bits for the serial number).
>>>>
>>>> Also, I suggest that we show that serial-number string as-is in cpuinfo
>>>> as well
>>>
>>> We cannot do that because we must guarantee that the serial shown
>>> in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
>>> else would break the kernel <-> userspace API and potentially break
>>> userspace apps. So we must do the devicetree -> serialnumber low/high
>>> -> /proc/cpinfo version to guarantee that this format does not change.
>>>
>>> And as discussed before if you want a non 0 serial in cpuinfo then
>>> the devicetree -> serialnumber low/high should be done in sunxi
>>> specific kernel code, as on sunxi we will know that the string in
>>> devicetree will be a hex value, but we've no such guarantee for
>>> other platforms, so we cannot simply have a generic function to
>>> populate erialnumber low/high from the devicetree serial-number
>>> string.
>>>
>>>   > and instead make a string out of the serial ATAG in the kernel
>>>> prior to showing it in cpuinfo (as opposed to translating the string
>>>> coming from device tree to a numeric value that cpuinfo will end up
>>>> showing as a string at the end of the day). Thus, the serial number
>>>> coming from device tree will still be shown in cpuinfo as well and no
>>>> ABI gets broken.
>>>
>>> You're forgetting the userspace <-> kernel ABI here, the serial line
>>> in /proc/cpuinfo is not a free form string it is a 64 bit int shown
>>> as 0 padded hex, and we cannot change that as changing that would be
>>> an ABI break.
>>
>> IMHO this really is all about interpretation. If you consider that the
>> serial is already a *string* and not a hex-representation of a number
>> (which it is when using ATAGs, but has no reason to be in general), then
>> my suggestion will introduce no ABI break.
>>
>> Generally speaking, I found no documentation that indicates that the
>> serial has to be in that format. It just happens to be the case when
>> using ATAGs.
>>
>> Also, I found an email from Rob suggesting he would be fine with wiring
>> the dts serial-number string to cpuinfo:
>> http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html
>>
>> I think it's the most flexible solution and we can think of it as an
>> extension of the current scheme: the serial string will no longer be
>> limited to a hex representation of a number but can become any string.
>>
>> Now I would appreciate it if Rob could weigh-in and state whether he
>> changed his mind on this or not.
>
> The only ABI is on platforms that used ATAGS as any DT only platform
> has so far had a serial# in cpuinfo of 16 0's. With a variable length
> string we can still have a fixed 16 char hex serial number that is
> compatible with ATAGS. I can't imagine that we have userspace that
> cares about the length and yet doesn't care the value is always 0's
> since converting to DT. As long as we keep 16 0's as the default I
> don't see an issue with allowing other lengths.

There are 2 problems with playing around with the serial line in
/proc/cpuinfo:

1) Length, currently it is always 16 chars, making it either shorter
or longer may break some userspace parsing code for it.

2) Contents, currently it is always in hex, so we cannot simply
copy a string from devicetree in there without verifying that that
string contains hex.

Now if we were to add code to:
1) Verify that the serial from devicetree is hex
2) Truncate it to 16 chars max

That would work, the easiest way to get there is to simply store
the serial from devicetree in the existing serial low and high
32 bit ints.

> It is only an ABI if someone notices and if we find an ABI issue later
> we can always fix it.

Erm, no it is an ABI once it has shipped, and we cannot always fix it later
because in the mean time other apps may have started depending on the new
ABI and then we've a big problem.

There are plenty of examples of "innocent" changes to files in /proc
breaking stuff, so we really really should be careful here.

Also I don't see why this is that important at all, we can limit
things to not break the ABI and apps who want the full serial in
the original string format can always get it from

/sys/firmware/devicetree/base/serial-number

Regards,

Hans



>
> Rob
>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] serial atag tag in devicetree ?

[Hans de Goede]

Hi,

On 27-03-15 05:30, Rob Herring wrote:
> On Thu, Mar 26, 2015 at 4:11 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
>> Le jeudi 26 mars 2015 ? 09:53 +0100, Hans de Goede a ?crit :
>>> Hi,
>>>
>>> On 25-03-15 23:35, Paul Kocialkowski wrote:
>>>> Le mardi 24 mars 2015 ? 09:01 +0100, Hans de Goede a ?crit :
>>>>> Hi,
>>>>>
>>>>> On 24-03-15 00:12, Rob Herring wrote:
>>>>>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>> On 22-03-15 22:01, Rob Herring wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>>>> 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.
>>>>>>
>>>>>> Right.
>>>>>>
>>>>>>> Is the use of the "serial-number" string property already documented
>>>>>>> somewhere? If not I'll submit a kernel patch to document it.
>>>>>>
>>>>>> Not that I'm aware of. It is something that predates our documentation
>>>>>> requirements. It could be in OpenFirmware specs. Documenting it in the
>>>>>> DT bindings does not hurt.
>>>>>
>>>>> Ok.
>>>>>
>>>>>>> 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 ?
>>>>>>
>>>>>> If there is sufficient reason to support this on old kernels you could.
>>>>>
>>>>> One problem with supporting this for older kernels is that if a non 0
>>>>> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
>>>>> should really show the same number in /proc/cpuinfo which means adding
>>>>> code to the kernel to get the devicetree "serial-number" string property
>>>>> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
>>>>> but given that the "serial-number" string could be hex or decimal or
>>>>> what ever and > 64 bits that will likely require a platform specific
>>>>> solution. All doable, but the question then becomes is this worth the
>>>>> effort ?
>>>>
>>>> After investigating a bit more, I found out that the USB serial number
>>>> is expected to be a string of 32 bytes, so a 128 bit numeric serial
>>>> doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
>>>> so there is no room left for the terminating null byte), hence it makes
>>>> sense to keep a 64 bit limitation for the serial number, if users are
>>>> going to rely on it as USB serial string. Moreover, it seems that
>>>> Android devices are mostly used 64 bit numbers for serial numbers/
>>>>
>>>> I was initially going to suggest that we set it in stone that serial
>>>> must be 64 numeric bits (as it was in the ATAGs days) and that
>>>> bootloaders would pass it that way to the kernel through device tree
>>>> (with two 32 bits numeric integers), but Hans talked me out of it.
>>>> I just want to expose the situation (especially the USB and Android
>>>> thing) here to double-check that everyone still is convinced that a
>>>> string approach in device tree is best (which is fine with me).
>>>
>>> There are already existing users of the serial-number property in devicetree,
>>> and these already use a free-format string, so AFAICT we have no choice
>>> but to do the same as the existing users.
>>>
>>> But Rob is the expert here, so lets see what Rob has to say.
>>>
>>>> This way, users that still want to use the serial passed through device
>>>> tree as a USB serial number will have to use a string of 32 bits,
>>>> including the null terminating byte (which is what I'll suggest for
>>>> sunxi by using only 64 bits for the serial number).
>>>>
>>>> Also, I suggest that we show that serial-number string as-is in cpuinfo
>>>> as well
>>>
>>> We cannot do that because we must guarantee that the serial shown
>>> in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
>>> else would break the kernel <-> userspace API and potentially break
>>> userspace apps. So we must do the devicetree -> serialnumber low/high
>>> -> /proc/cpinfo version to guarantee that this format does not change.
>>>
>>> And as discussed before if you want a non 0 serial in cpuinfo then
>>> the devicetree -> serialnumber low/high should be done in sunxi
>>> specific kernel code, as on sunxi we will know that the string in
>>> devicetree will be a hex value, but we've no such guarantee for
>>> other platforms, so we cannot simply have a generic function to
>>> populate erialnumber low/high from the devicetree serial-number
>>> string.
>>>
>>>   > and instead make a string out of the serial ATAG in the kernel
>>>> prior to showing it in cpuinfo (as opposed to translating the string
>>>> coming from device tree to a numeric value that cpuinfo will end up
>>>> showing as a string at the end of the day). Thus, the serial number
>>>> coming from device tree will still be shown in cpuinfo as well and no
>>>> ABI gets broken.
>>>
>>> You're forgetting the userspace <-> kernel ABI here, the serial line
>>> in /proc/cpuinfo is not a free form string it is a 64 bit int shown
>>> as 0 padded hex, and we cannot change that as changing that would be
>>> an ABI break.
>>
>> IMHO this really is all about interpretation. If you consider that the
>> serial is already a *string* and not a hex-representation of a number
>> (which it is when using ATAGs, but has no reason to be in general), then
>> my suggestion will introduce no ABI break.
>>
>> Generally speaking, I found no documentation that indicates that the
>> serial has to be in that format. It just happens to be the case when
>> using ATAGs.
>>
>> Also, I found an email from Rob suggesting he would be fine with wiring
>> the dts serial-number string to cpuinfo:
>> http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html
>>
>> I think it's the most flexible solution and we can think of it as an
>> extension of the current scheme: the serial string will no longer be
>> limited to a hex representation of a number but can become any string.
>>
>> Now I would appreciate it if Rob could weigh-in and state whether he
>> changed his mind on this or not.
>
> The only ABI is on platforms that used ATAGS as any DT only platform
> has so far had a serial# in cpuinfo of 16 0's. With a variable length
> string we can still have a fixed 16 char hex serial number that is
> compatible with ATAGS. I can't imagine that we have userspace that
> cares about the length and yet doesn't care the value is always 0's
> since converting to DT. As long as we keep 16 0's as the default I
> don't see an issue with allowing other lengths.

There are 2 problems with playing around with the serial line in
/proc/cpuinfo:

1) Length, currently it is always 16 chars, making it either shorter
or longer may break some userspace parsing code for it.

2) Contents, currently it is always in hex, so we cannot simply
copy a string from devicetree in there without verifying that that
string contains hex.

Now if we were to add code to:
1) Verify that the serial from devicetree is hex
2) Truncate it to 16 chars max

That would work, the easiest way to get there is to simply store
the serial from devicetree in the existing serial low and high
32 bit ints.

> It is only an ABI if someone notices and if we find an ABI issue later
> we can always fix it.

Erm, no it is an ABI once it has shipped, and we cannot always fix it later
because in the mean time other apps may have started depending on the new
ABI and then we've a big problem.

There are plenty of examples of "innocent" changes to files in /proc
breaking stuff, so we really really should be careful here.

Also I don't see why this is that important at all, we can limit
things to not break the ABI and apps who want the full serial in
the original string format can always get it from

/sys/firmware/devicetree/base/serial-number

Regards,

Hans



>
> Rob
>

Re: serial atag tag in devicetree ?

[Paul Kocialkowski]

[-- Attachment #1.1: Type: text/plain, Size: 7901 bytes --]

Le jeudi 26 mars 2015 à 23:30 -0500, Rob Herring a écrit :
> On Thu, Mar 26, 2015 at 4:11 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> > Le jeudi 26 mars 2015 à 09:53 +0100, Hans de Goede a écrit :
> >> Hi,
> >>
> >> On 25-03-15 23:35, Paul Kocialkowski wrote:
> >> > Le mardi 24 mars 2015 à 09:01 +0100, Hans de Goede a écrit :
> >> >> Hi,
> >> >>
> >> >> On 24-03-15 00:12, Rob Herring wrote:
> >> >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> >> >>>> Hi,
> >> >>>>
> >> >>>>
> >> >>>> On 22-03-15 22:01, Rob Herring wrote:
> >> >>
> >> >> <snip>
> >> >>
> >> >>>>> 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.
> >> >>>
> >> >>> Right.
> >> >>>
> >> >>>> Is the use of the "serial-number" string property already documented
> >> >>>> somewhere? If not I'll submit a kernel patch to document it.
> >> >>>
> >> >>> Not that I'm aware of. It is something that predates our documentation
> >> >>> requirements. It could be in OpenFirmware specs. Documenting it in the
> >> >>> DT bindings does not hurt.
> >> >>
> >> >> Ok.
> >> >>
> >> >>>> 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 ?
> >> >>>
> >> >>> If there is sufficient reason to support this on old kernels you could.
> >> >>
> >> >> One problem with supporting this for older kernels is that if a non 0
> >> >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
> >> >> should really show the same number in /proc/cpuinfo which means adding
> >> >> code to the kernel to get the devicetree "serial-number" string property
> >> >> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
> >> >> but given that the "serial-number" string could be hex or decimal or
> >> >> what ever and > 64 bits that will likely require a platform specific
> >> >> solution. All doable, but the question then becomes is this worth the
> >> >> effort ?
> >> >
> >> > After investigating a bit more, I found out that the USB serial number
> >> > is expected to be a string of 32 bytes, so a 128 bit numeric serial
> >> > doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
> >> > so there is no room left for the terminating null byte), hence it makes
> >> > sense to keep a 64 bit limitation for the serial number, if users are
> >> > going to rely on it as USB serial string. Moreover, it seems that
> >> > Android devices are mostly used 64 bit numbers for serial numbers/
> >> >
> >> > I was initially going to suggest that we set it in stone that serial
> >> > must be 64 numeric bits (as it was in the ATAGs days) and that
> >> > bootloaders would pass it that way to the kernel through device tree
> >> > (with two 32 bits numeric integers), but Hans talked me out of it.
> >> > I just want to expose the situation (especially the USB and Android
> >> > thing) here to double-check that everyone still is convinced that a
> >> > string approach in device tree is best (which is fine with me).
> >>
> >> There are already existing users of the serial-number property in devicetree,
> >> and these already use a free-format string, so AFAICT we have no choice
> >> but to do the same as the existing users.
> >>
> >> But Rob is the expert here, so lets see what Rob has to say.
> >>
> >> > This way, users that still want to use the serial passed through device
> >> > tree as a USB serial number will have to use a string of 32 bits,
> >> > including the null terminating byte (which is what I'll suggest for
> >> > sunxi by using only 64 bits for the serial number).
> >> >
> >> > Also, I suggest that we show that serial-number string as-is in cpuinfo
> >> > as well
> >>
> >> We cannot do that because we must guarantee that the serial shown
> >> in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
> >> else would break the kernel <-> userspace API and potentially break
> >> userspace apps. So we must do the devicetree -> serialnumber low/high
> >> -> /proc/cpinfo version to guarantee that this format does not change.
> >>
> >> And as discussed before if you want a non 0 serial in cpuinfo then
> >> the devicetree -> serialnumber low/high should be done in sunxi
> >> specific kernel code, as on sunxi we will know that the string in
> >> devicetree will be a hex value, but we've no such guarantee for
> >> other platforms, so we cannot simply have a generic function to
> >> populate erialnumber low/high from the devicetree serial-number
> >> string.
> >>
> >>  > and instead make a string out of the serial ATAG in the kernel
> >> > prior to showing it in cpuinfo (as opposed to translating the string
> >> > coming from device tree to a numeric value that cpuinfo will end up
> >> > showing as a string at the end of the day). Thus, the serial number
> >> > coming from device tree will still be shown in cpuinfo as well and no
> >> > ABI gets broken.
> >>
> >> You're forgetting the userspace <-> kernel ABI here, the serial line
> >> in /proc/cpuinfo is not a free form string it is a 64 bit int shown
> >> as 0 padded hex, and we cannot change that as changing that would be
> >> an ABI break.
> >
> > IMHO this really is all about interpretation. If you consider that the
> > serial is already a *string* and not a hex-representation of a number
> > (which it is when using ATAGs, but has no reason to be in general), then
> > my suggestion will introduce no ABI break.
> >
> > Generally speaking, I found no documentation that indicates that the
> > serial has to be in that format. It just happens to be the case when
> > using ATAGs.
> >
> > Also, I found an email from Rob suggesting he would be fine with wiring
> > the dts serial-number string to cpuinfo:
> > http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html
> >
> > I think it's the most flexible solution and we can think of it as an
> > extension of the current scheme: the serial string will no longer be
> > limited to a hex representation of a number but can become any string.
> >
> > Now I would appreciate it if Rob could weigh-in and state whether he
> > changed his mind on this or not.
> 
> The only ABI is on platforms that used ATAGS as any DT only platform
> has so far had a serial# in cpuinfo of 16 0's. With a variable length
> string we can still have a fixed 16 char hex serial number that is
> compatible with ATAGS. I can't imagine that we have userspace that
> cares about the length and yet doesn't care the value is always 0's
> since converting to DT. As long as we keep 16 0's as the default I
> don't see an issue with allowing other lengths.
> 
> It is only an ABI if someone notices and if we find an ABI issue later
> we can always fix it.

Alright then, I think that all makes sense. I have a first proposal in
that direction ready then.

Russell, I'll just wait for your ack and start sending this to both the
U-Boot and ARM kernel lists.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/


[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[-- Attachment #2: Type: text/plain, Size: 134 bytes --]

_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] serial atag tag in devicetree ?

[Paul Kocialkowski]

Le jeudi 26 mars 2015 ? 23:30 -0500, Rob Herring a ?crit :
> On Thu, Mar 26, 2015 at 4:11 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> > Le jeudi 26 mars 2015 ? 09:53 +0100, Hans de Goede a ?crit :
> >> Hi,
> >>
> >> On 25-03-15 23:35, Paul Kocialkowski wrote:
> >> > Le mardi 24 mars 2015 ? 09:01 +0100, Hans de Goede a ?crit :
> >> >> Hi,
> >> >>
> >> >> On 24-03-15 00:12, Rob Herring wrote:
> >> >>> On Mon, Mar 23, 2015 at 6:30 AM, Hans de Goede <hdegoede@redhat.com> wrote:
> >> >>>> Hi,
> >> >>>>
> >> >>>>
> >> >>>> On 22-03-15 22:01, Rob Herring wrote:
> >> >>
> >> >> <snip>
> >> >>
> >> >>>>> 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.
> >> >>>
> >> >>> Right.
> >> >>>
> >> >>>> Is the use of the "serial-number" string property already documented
> >> >>>> somewhere? If not I'll submit a kernel patch to document it.
> >> >>>
> >> >>> Not that I'm aware of. It is something that predates our documentation
> >> >>> requirements. It could be in OpenFirmware specs. Documenting it in the
> >> >>> DT bindings does not hurt.
> >> >>
> >> >> Ok.
> >> >>
> >> >>>> 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 ?
> >> >>>
> >> >>> If there is sufficient reason to support this on old kernels you could.
> >> >>
> >> >> One problem with supporting this for older kernels is that if a non 0
> >> >> serial gets shown in /proc/cpuinfo with older atag booted kernels, we
> >> >> should really show the same number in /proc/cpuinfo which means adding
> >> >> code to the kernel to get the devicetree "serial-number" string property
> >> >> and somehow put that into the 64 bits which we have in /proc/cpuinfo,
> >> >> but given that the "serial-number" string could be hex or decimal or
> >> >> what ever and > 64 bits that will likely require a platform specific
> >> >> solution. All doable, but the question then becomes is this worth the
> >> >> effort ?
> >> >
> >> > After investigating a bit more, I found out that the USB serial number
> >> > is expected to be a string of 32 bytes, so a 128 bit numeric serial
> >> > doesn't fit (it takes 32 bytes for the hex representation of 128 bits,
> >> > so there is no room left for the terminating null byte), hence it makes
> >> > sense to keep a 64 bit limitation for the serial number, if users are
> >> > going to rely on it as USB serial string. Moreover, it seems that
> >> > Android devices are mostly used 64 bit numbers for serial numbers/
> >> >
> >> > I was initially going to suggest that we set it in stone that serial
> >> > must be 64 numeric bits (as it was in the ATAGs days) and that
> >> > bootloaders would pass it that way to the kernel through device tree
> >> > (with two 32 bits numeric integers), but Hans talked me out of it.
> >> > I just want to expose the situation (especially the USB and Android
> >> > thing) here to double-check that everyone still is convinced that a
> >> > string approach in device tree is best (which is fine with me).
> >>
> >> There are already existing users of the serial-number property in devicetree,
> >> and these already use a free-format string, so AFAICT we have no choice
> >> but to do the same as the existing users.
> >>
> >> But Rob is the expert here, so lets see what Rob has to say.
> >>
> >> > This way, users that still want to use the serial passed through device
> >> > tree as a USB serial number will have to use a string of 32 bits,
> >> > including the null terminating byte (which is what I'll suggest for
> >> > sunxi by using only 64 bits for the serial number).
> >> >
> >> > Also, I suggest that we show that serial-number string as-is in cpuinfo
> >> > as well
> >>
> >> We cannot do that because we must guarantee that the serial shown
> >> in cpu info is a 64 bits / 16 hex values (0 padded) number, anything
> >> else would break the kernel <-> userspace API and potentially break
> >> userspace apps. So we must do the devicetree -> serialnumber low/high
> >> -> /proc/cpinfo version to guarantee that this format does not change.
> >>
> >> And as discussed before if you want a non 0 serial in cpuinfo then
> >> the devicetree -> serialnumber low/high should be done in sunxi
> >> specific kernel code, as on sunxi we will know that the string in
> >> devicetree will be a hex value, but we've no such guarantee for
> >> other platforms, so we cannot simply have a generic function to
> >> populate erialnumber low/high from the devicetree serial-number
> >> string.
> >>
> >>  > and instead make a string out of the serial ATAG in the kernel
> >> > prior to showing it in cpuinfo (as opposed to translating the string
> >> > coming from device tree to a numeric value that cpuinfo will end up
> >> > showing as a string at the end of the day). Thus, the serial number
> >> > coming from device tree will still be shown in cpuinfo as well and no
> >> > ABI gets broken.
> >>
> >> You're forgetting the userspace <-> kernel ABI here, the serial line
> >> in /proc/cpuinfo is not a free form string it is a 64 bit int shown
> >> as 0 padded hex, and we cannot change that as changing that would be
> >> an ABI break.
> >
> > IMHO this really is all about interpretation. If you consider that the
> > serial is already a *string* and not a hex-representation of a number
> > (which it is when using ATAGs, but has no reason to be in general), then
> > my suggestion will introduce no ABI break.
> >
> > Generally speaking, I found no documentation that indicates that the
> > serial has to be in that format. It just happens to be the case when
> > using ATAGs.
> >
> > Also, I found an email from Rob suggesting he would be fine with wiring
> > the dts serial-number string to cpuinfo:
> > http://lkml.iu.edu/hypermail/linux/kernel/1412.0/02975.html
> >
> > I think it's the most flexible solution and we can think of it as an
> > extension of the current scheme: the serial string will no longer be
> > limited to a hex representation of a number but can become any string.
> >
> > Now I would appreciate it if Rob could weigh-in and state whether he
> > changed his mind on this or not.
> 
> The only ABI is on platforms that used ATAGS as any DT only platform
> has so far had a serial# in cpuinfo of 16 0's. With a variable length
> string we can still have a fixed 16 char hex serial number that is
> compatible with ATAGS. I can't imagine that we have userspace that
> cares about the length and yet doesn't care the value is always 0's
> since converting to DT. As long as we keep 16 0's as the default I
> don't see an issue with allowing other lengths.
> 
> It is only an ABI if someone notices and if we find an ABI issue later
> we can always fix it.

Alright then, I think that all makes sense. I have a first proposal in
that direction ready then.

Russell, I'll just wait for your ack and start sending this to both the
U-Boot and ARM kernel lists.

-- 
Paul Kocialkowski, Replicant developer

Replicant is a fully free Android distribution running on several
devices, a free software mobile operating system putting the emphasis on
freedom and privacy/security.

Website: http://www.replicant.us/
Blog: http://blog.replicant.us/
Wiki/tracker/forums: http://redmine.replicant.us/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150327/9dd67b13/attachment.sig>