All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	U-Boot <u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org>,
	Ian Campbell <ijc-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org>,
	Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org>
Subject: Re: [U-Boot] serial atag tag in devicetree ?
Date: Tue, 24 Mar 2015 09:01:53 +0100	[thread overview]
Message-ID: <551119F1.2060002@redhat.com> (raw)
In-Reply-To: <CAL_JsqLev+DeWCzvhF7bwYk3URxpgaQDR+6OmwWHjJ2nx=HijQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

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

WARNING: multiple messages have this Message-ID (diff)
From: Hans de Goede <hdegoede@redhat.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] serial atag tag in devicetree ?
Date: Tue, 24 Mar 2015 09:01:53 +0100	[thread overview]
Message-ID: <551119F1.2060002@redhat.com> (raw)
In-Reply-To: <CAL_JsqLev+DeWCzvhF7bwYk3URxpgaQDR+6OmwWHjJ2nx=HijQ@mail.gmail.com>

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

  parent reply	other threads:[~2015-03-24  8:01 UTC|newest]

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

Reply instructions:

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

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

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

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

  git send-email \
    --in-reply-to=551119F1.2060002@redhat.com \
    --to=hdegoede-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=contact-W9ppeneeCTY@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=ijc-KcIKpvwj1kUDXYZnReoRVg@public.gmane.org \
    --cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=u-boot-0aAXYlwwYIKGBzrmiIFOJg@public.gmane.org \
    /path/to/YOUR_REPLY

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

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