[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Paul Kocialkowski]

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
---
 Documentation/devicetree/booting-without-of.txt | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt
index 7768518..8b055897 100644
--- a/Documentation/devicetree/booting-without-of.txt
+++ b/Documentation/devicetree/booting-without-of.txt
@@ -828,6 +828,10 @@ address which can extend beyond that limit.
   name may clash with standard defined ones, you prefix them with your
   vendor name and a comma.
 
+  Additional properties for the root node:
+
+    - serial-number : a string representing the board's serial number
+
   b) The /cpus node
 
   This node is the parent of all individual CPU nodes. It doesn't
-- 
1.9.1

[PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo

[Paul Kocialkowski]

This grabs the serial number shown in cpuinfo from the serial-number devicetree
property in priority. When booting with ATAGs (and without device-tree), the
provided number is still shown instead.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
---
 arch/arm/include/asm/system_info.h |  1 +
 arch/arm/kernel/atags_parse.c      |  3 +++
 arch/arm/kernel/devtree.c          | 15 ++++++++++-----
 arch/arm/kernel/setup.c            | 11 +++++++++--
 4 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/arch/arm/include/asm/system_info.h b/arch/arm/include/asm/system_info.h
index 720ea03..3860cbd40 100644
--- a/arch/arm/include/asm/system_info.h
+++ b/arch/arm/include/asm/system_info.h
@@ -17,6 +17,7 @@
 
 /* information about the system we're running on */
 extern unsigned int system_rev;
+extern const char *system_serial;
 extern unsigned int system_serial_low;
 extern unsigned int system_serial_high;
 extern unsigned int mem_fclk_21285;
diff --git a/arch/arm/kernel/atags_parse.c b/arch/arm/kernel/atags_parse.c
index 68c6ae0..8384818 100644
--- a/arch/arm/kernel/atags_parse.c
+++ b/arch/arm/kernel/atags_parse.c
@@ -231,6 +231,9 @@ setup_machine_tags(phys_addr_t __atags_pointer, unsigned int machine_nr)
 		parse_tags(tags);
 	}
 
+	/* Serial number is stored in system_serial_low/high */
+	system_serial = NULL;
+
 	/* parse_early_param needs a boot_command_line */
 	strlcpy(boot_command_line, from, COMMAND_LINE_SIZE);
 
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 11c54de..a82a04d 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -26,6 +26,7 @@
 #include <asm/smp_plat.h>
 #include <asm/mach/arch.h>
 #include <asm/mach-types.h>
+#include <asm/system_info.h>
 
 
 #ifdef CONFIG_SMP
@@ -204,6 +205,9 @@ static const void * __init arch_get_next_mach(const char *const **match)
 const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 {
 	const struct machine_desc *mdesc, *mdesc_best = NULL;
+	const char *prop;
+	int size;
+	unsigned long dt_root;
 
 #ifdef CONFIG_ARCH_MULTIPLATFORM
 	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
@@ -215,17 +219,14 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
 		return NULL;
 
+	dt_root = of_get_flat_dt_root();
+
 	mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
 
 	if (!mdesc) {
-		const char *prop;
-		int size;
-		unsigned long dt_root;
-
 		early_print("\nError: unrecognized/unsupported "
 			    "device tree compatible list:\n[ ");
 
-		dt_root = of_get_flat_dt_root();
 		prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
 		while (size > 0) {
 			early_print("'%s' ", prop);
@@ -243,6 +244,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 
 	early_init_dt_scan_nodes();
 
+	/* Scan for serial number */
+	prop = of_get_flat_dt_prop(dt_root, "serial-number", &size);
+	system_serial = prop;
+
 	/* Change machine number to match the mdesc we're using */
 	__machine_arch_type = mdesc->nr;
 
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 1d60beb..69fa7ef 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -93,6 +93,9 @@ unsigned int __atags_pointer __initdata;
 unsigned int system_rev;
 EXPORT_SYMBOL(system_rev);
 
+const char *system_serial;
+EXPORT_SYMBOL(system_serial);
+
 unsigned int system_serial_low;
 EXPORT_SYMBOL(system_serial_low);
 
@@ -1091,8 +1094,12 @@ static int c_show(struct seq_file *m, void *v)
 
 	seq_printf(m, "Hardware\t: %s\n", machine_name);
 	seq_printf(m, "Revision\t: %04x\n", system_rev);
-	seq_printf(m, "Serial\t\t: %08x%08x\n",
-		   system_serial_high, system_serial_low);
+
+	if (system_serial)
+		seq_printf(m, "Serial\t\t: %s\n", system_serial);
+	else
+		seq_printf(m, "Serial\t\t: %08x%08x\n",
+			   system_serial_high, system_serial_low);
 
 	return 0;
 }
-- 
1.9.1

[PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo

[Russell King - ARM Linux]

On Sat, Mar 28, 2015 at 06:39:31PM +0100, Paul Kocialkowski wrote:
> This grabs the serial number shown in cpuinfo from the serial-number devicetree
> property in priority. When booting with ATAGs (and without device-tree), the
> provided number is still shown instead.
> 
> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> ---
>  arch/arm/include/asm/system_info.h |  1 +
>  arch/arm/kernel/atags_parse.c      |  3 +++
>  arch/arm/kernel/devtree.c          | 15 ++++++++++-----
>  arch/arm/kernel/setup.c            | 11 +++++++++--
>  4 files changed, 23 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/include/asm/system_info.h b/arch/arm/include/asm/system_info.h
> index 720ea03..3860cbd40 100644
> --- a/arch/arm/include/asm/system_info.h
> +++ b/arch/arm/include/asm/system_info.h
> @@ -17,6 +17,7 @@
>  
>  /* information about the system we're running on */
>  extern unsigned int system_rev;
> +extern const char *system_serial;
>  extern unsigned int system_serial_low;
>  extern unsigned int system_serial_high;
>  extern unsigned int mem_fclk_21285;
> diff --git a/arch/arm/kernel/atags_parse.c b/arch/arm/kernel/atags_parse.c
> index 68c6ae0..8384818 100644
> --- a/arch/arm/kernel/atags_parse.c
> +++ b/arch/arm/kernel/atags_parse.c
> @@ -231,6 +231,9 @@ setup_machine_tags(phys_addr_t __atags_pointer, unsigned int machine_nr)
>  		parse_tags(tags);
>  	}
>  
> +	/* Serial number is stored in system_serial_low/high */
> +	system_serial = NULL;
> +
>  	/* parse_early_param needs a boot_command_line */
>  	strlcpy(boot_command_line, from, COMMAND_LINE_SIZE);
>  
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 11c54de..a82a04d 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -26,6 +26,7 @@
>  #include <asm/smp_plat.h>
>  #include <asm/mach/arch.h>
>  #include <asm/mach-types.h>
> +#include <asm/system_info.h>
>  
>  
>  #ifdef CONFIG_SMP
> @@ -204,6 +205,9 @@ static const void * __init arch_get_next_mach(const char *const **match)
>  const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>  {
>  	const struct machine_desc *mdesc, *mdesc_best = NULL;
> +	const char *prop;
> +	int size;
> +	unsigned long dt_root;
>  
>  #ifdef CONFIG_ARCH_MULTIPLATFORM
>  	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> @@ -215,17 +219,14 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>  	if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
>  		return NULL;
>  
> +	dt_root = of_get_flat_dt_root();
> +
>  	mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
>  
>  	if (!mdesc) {
> -		const char *prop;
> -		int size;
> -		unsigned long dt_root;
> -
>  		early_print("\nError: unrecognized/unsupported "
>  			    "device tree compatible list:\n[ ");
>  
> -		dt_root = of_get_flat_dt_root();
>  		prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
>  		while (size > 0) {
>  			early_print("'%s' ", prop);
> @@ -243,6 +244,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>  
>  	early_init_dt_scan_nodes();
>  
> +	/* Scan for serial number */
> +	prop = of_get_flat_dt_prop(dt_root, "serial-number", &size);
> +	system_serial = prop;
> +
>  	/* Change machine number to match the mdesc we're using */
>  	__machine_arch_type = mdesc->nr;
>  
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 1d60beb..69fa7ef 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -93,6 +93,9 @@ unsigned int __atags_pointer __initdata;
>  unsigned int system_rev;
>  EXPORT_SYMBOL(system_rev);
>  
> +const char *system_serial;
> +EXPORT_SYMBOL(system_serial);
> +
>  unsigned int system_serial_low;
>  EXPORT_SYMBOL(system_serial_low);
>  
> @@ -1091,8 +1094,12 @@ static int c_show(struct seq_file *m, void *v)
>  
>  	seq_printf(m, "Hardware\t: %s\n", machine_name);
>  	seq_printf(m, "Revision\t: %04x\n", system_rev);
> -	seq_printf(m, "Serial\t\t: %08x%08x\n",
> -		   system_serial_high, system_serial_low);
> +
> +	if (system_serial)
> +		seq_printf(m, "Serial\t\t: %s\n", system_serial);
> +	else
> +		seq_printf(m, "Serial\t\t: %08x%08x\n",
> +			   system_serial_high, system_serial_low);

How about this becomes just:

	seq_printf(m, "Serial\t\t: %s\n", system_serial);

And we arrange for system_serial to always be initialised later on
during boot if it's not already set from the system_serial_high and
system_serial_low variables?  Eg, adding in init_machine_late():

	if (!system_serial)
		system_serial = kasprintf(GFP_KERNEL, "%08x%08x",
					  system_serial_high,
					  system_serial_low);

and is there a reason we can't look for the serial number in DT at
this point as well - is there a reason we might need the stringified
serial number early?

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo

[Paul Kocialkowski]

Hi Russell, thanks for the review!

Le jeudi 16 avril 2015 ? 10:46 +0100, Russell King - ARM Linux a ?crit :
> On Sat, Mar 28, 2015 at 06:39:31PM +0100, Paul Kocialkowski wrote:
> > This grabs the serial number shown in cpuinfo from the serial-number devicetree
> > property in priority. When booting with ATAGs (and without device-tree), the
> > provided number is still shown instead.
> > 
> > Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> > ---
> >  arch/arm/include/asm/system_info.h |  1 +
> >  arch/arm/kernel/atags_parse.c      |  3 +++
> >  arch/arm/kernel/devtree.c          | 15 ++++++++++-----
> >  arch/arm/kernel/setup.c            | 11 +++++++++--
> >  4 files changed, 23 insertions(+), 7 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/system_info.h b/arch/arm/include/asm/system_info.h
> > index 720ea03..3860cbd40 100644
> > --- a/arch/arm/include/asm/system_info.h
> > +++ b/arch/arm/include/asm/system_info.h
> > @@ -17,6 +17,7 @@
> >  
> >  /* information about the system we're running on */
> >  extern unsigned int system_rev;
> > +extern const char *system_serial;
> >  extern unsigned int system_serial_low;
> >  extern unsigned int system_serial_high;
> >  extern unsigned int mem_fclk_21285;
> > diff --git a/arch/arm/kernel/atags_parse.c b/arch/arm/kernel/atags_parse.c
> > index 68c6ae0..8384818 100644
> > --- a/arch/arm/kernel/atags_parse.c
> > +++ b/arch/arm/kernel/atags_parse.c
> > @@ -231,6 +231,9 @@ setup_machine_tags(phys_addr_t __atags_pointer, unsigned int machine_nr)
> >  		parse_tags(tags);
> >  	}
> >  
> > +	/* Serial number is stored in system_serial_low/high */
> > +	system_serial = NULL;
> > +
> >  	/* parse_early_param needs a boot_command_line */
> >  	strlcpy(boot_command_line, from, COMMAND_LINE_SIZE);
> >  
> > diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> > index 11c54de..a82a04d 100644
> > --- a/arch/arm/kernel/devtree.c
> > +++ b/arch/arm/kernel/devtree.c
> > @@ -26,6 +26,7 @@
> >  #include <asm/smp_plat.h>
> >  #include <asm/mach/arch.h>
> >  #include <asm/mach-types.h>
> > +#include <asm/system_info.h>
> >  
> >  
> >  #ifdef CONFIG_SMP
> > @@ -204,6 +205,9 @@ static const void * __init arch_get_next_mach(const char *const **match)
> >  const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
> >  {
> >  	const struct machine_desc *mdesc, *mdesc_best = NULL;
> > +	const char *prop;
> > +	int size;
> > +	unsigned long dt_root;
> >  
> >  #ifdef CONFIG_ARCH_MULTIPLATFORM
> >  	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> > @@ -215,17 +219,14 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
> >  	if (!dt_phys || !early_init_dt_verify(phys_to_virt(dt_phys)))
> >  		return NULL;
> >  
> > +	dt_root = of_get_flat_dt_root();
> > +
> >  	mdesc = of_flat_dt_match_machine(mdesc_best, arch_get_next_mach);
> >  
> >  	if (!mdesc) {
> > -		const char *prop;
> > -		int size;
> > -		unsigned long dt_root;
> > -
> >  		early_print("\nError: unrecognized/unsupported "
> >  			    "device tree compatible list:\n[ ");
> >  
> > -		dt_root = of_get_flat_dt_root();
> >  		prop = of_get_flat_dt_prop(dt_root, "compatible", &size);
> >  		while (size > 0) {
> >  			early_print("'%s' ", prop);
> > @@ -243,6 +244,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
> >  
> >  	early_init_dt_scan_nodes();
> >  
> > +	/* Scan for serial number */
> > +	prop = of_get_flat_dt_prop(dt_root, "serial-number", &size);
> > +	system_serial = prop;
> > +
> >  	/* Change machine number to match the mdesc we're using */
> >  	__machine_arch_type = mdesc->nr;
> >  
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 1d60beb..69fa7ef 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -93,6 +93,9 @@ unsigned int __atags_pointer __initdata;
> >  unsigned int system_rev;
> >  EXPORT_SYMBOL(system_rev);
> >  
> > +const char *system_serial;
> > +EXPORT_SYMBOL(system_serial);
> > +
> >  unsigned int system_serial_low;
> >  EXPORT_SYMBOL(system_serial_low);
> >  
> > @@ -1091,8 +1094,12 @@ static int c_show(struct seq_file *m, void *v)
> >  
> >  	seq_printf(m, "Hardware\t: %s\n", machine_name);
> >  	seq_printf(m, "Revision\t: %04x\n", system_rev);
> > -	seq_printf(m, "Serial\t\t: %08x%08x\n",
> > -		   system_serial_high, system_serial_low);
> > +
> > +	if (system_serial)
> > +		seq_printf(m, "Serial\t\t: %s\n", system_serial);
> > +	else
> > +		seq_printf(m, "Serial\t\t: %08x%08x\n",
> > +			   system_serial_high, system_serial_low);
> 
> How about this becomes just:
> 
> 	seq_printf(m, "Serial\t\t: %s\n", system_serial);

Okay, always printing the system_serial string in cpuinfo's c_show seems
cleaner and clearly states that the string way is preferred over the old
one, which becomes legacy.

> And we arrange for system_serial to always be initialised later on
> during boot if it's not already set from the system_serial_high and
> system_serial_low variables?  Eg, adding in init_machine_late():
> 
> 	if (!system_serial)
> 		system_serial = kasprintf(GFP_KERNEL, "%08x%08x",
> 					  system_serial_high,
> 					  system_serial_low);
> 
> and is there a reason we can't look for the serial number in DT at
> this point as well - is there a reason we might need the stringified
> serial number early?

Not that I know of -- I just thought it would be a good fit to fill-in
the string in setup_machine_fdt since ATAGs were being stored in
serial_low/high in setup_machine_tags (to preserve some kind of
"structure parallelism" in the way the serial number is obtained).

Now if the serial from ATAG is going to end up in the system_serial
string too, it doesn't make a lot of sense to keep the structure I
suggested, so I agree with your proposal.

We could simply check whether the serial-number property is there (when
DT is enabled at all) and fallback to using serial_low/high when it's
not the case (which would perhaps be 0), at a later point in
initialization. If you think init_machine_late is a good fit, then I'll
go for it.

-------------- 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.infradead.org/pipermail/linux-arm-kernel/attachments/20150416/5e725ceb/attachment.sig>

[PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo

[Russell King - ARM Linux]

On Thu, Apr 16, 2015 at 12:23:11PM +0200, Paul Kocialkowski wrote:
> We could simply check whether the serial-number property is there (when
> DT is enabled at all) and fallback to using serial_low/high when it's
> not the case (which would perhaps be 0), at a later point in
> initialization. If you think init_machine_late is a good fit, then I'll
> go for it.

I do.  The only user of the string right now is userspace.  We don't
expect the serial number to change over the lifetime of the kernel,
and we expect that it's initialised by the time userspace gets to run.

So, doing this at late_initcall() time seems completely sensible to me.

-- 
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Paul Kocialkowski]

Le samedi 28 mars 2015 ? 18:39 +0100, Paul Kocialkowski a ?crit :
> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

Since the merge windows on both U-Boot and Linux are now open, I'd like
to attract your attention on this again.

Any comments/remarks are welcome!

> ---
>  Documentation/devicetree/booting-without-of.txt | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt
> index 7768518..8b055897 100644
> --- a/Documentation/devicetree/booting-without-of.txt
> +++ b/Documentation/devicetree/booting-without-of.txt
> @@ -828,6 +828,10 @@ address which can extend beyond that limit.
>    name may clash with standard defined ones, you prefix them with your
>    vendor name and a comma.
>  
> +  Additional properties for the root node:
> +
> +    - serial-number : a string representing the board's serial number
> +
>    b) The /cpus node
>  
>    This node is the parent of all individual CPU nodes. It doesn't

-------------- 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.infradead.org/pipermail/linux-arm-kernel/attachments/20150414/031c416d/attachment.sig>

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Stefan Agner]

On 2015-03-28 18:39, Paul Kocialkowski wrote:
> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>

I think this is a worthwhile standardization.

Acked-by: Stefan Agner <stefan@agner.ch>


> ---
>  Documentation/devicetree/booting-without-of.txt | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/booting-without-of.txt
> b/Documentation/devicetree/booting-without-of.txt
> index 7768518..8b055897 100644
> --- a/Documentation/devicetree/booting-without-of.txt
> +++ b/Documentation/devicetree/booting-without-of.txt
> @@ -828,6 +828,10 @@ address which can extend beyond that limit.
>    name may clash with standard defined ones, you prefix them with your
>    vendor name and a comma.
>  
> +  Additional properties for the root node:
> +
> +    - serial-number : a string representing the board's serial number
> +
>    b) The /cpus node
>  
>    This node is the parent of all individual CPU nodes. It doesn't

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Paul Kocialkowski]

Le jeudi 16 avril 2015 ? 09:56 +0200, Stefan Agner a ?crit :
> On 2015-03-28 18:39, Paul Kocialkowski wrote:
> > Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> 
> I think this is a worthwhile standardization.
> 
> Acked-by: Stefan Agner <stefan@agner.ch>

Thanks! I should also add a commit message in v2 mentioning that this is
already used in open firmware and reported by lshw.

> > ---
> >  Documentation/devicetree/booting-without-of.txt | 4 ++++
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/booting-without-of.txt
> > b/Documentation/devicetree/booting-without-of.txt
> > index 7768518..8b055897 100644
> > --- a/Documentation/devicetree/booting-without-of.txt
> > +++ b/Documentation/devicetree/booting-without-of.txt
> > @@ -828,6 +828,10 @@ address which can extend beyond that limit.
> >    name may clash with standard defined ones, you prefix them with your
> >    vendor name and a comma.
> >  
> > +  Additional properties for the root node:
> > +
> > +    - serial-number : a string representing the board's serial number
> > +
> >    b) The /cpus node
> >  
> >    This node is the parent of all individual CPU nodes. It doesn't
> 

-------------- 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.infradead.org/pipermail/linux-arm-kernel/attachments/20150416/02095292/attachment.sig>

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Rob Herring]

On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> Le jeudi 16 avril 2015 ? 09:56 +0200, Stefan Agner a ?crit :
>> On 2015-03-28 18:39, Paul Kocialkowski wrote:
>> > Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>>
>> I think this is a worthwhile standardization.
>>
>> Acked-by: Stefan Agner <stefan@agner.ch>
>
> Thanks! I should also add a commit message in v2 mentioning that this is
> already used in open firmware and reported by lshw.

With that,

Acked-by: Rob Herring <robh@kernel.org>

>
>> > ---
>> >  Documentation/devicetree/booting-without-of.txt | 4 ++++
>> >  1 file changed, 4 insertions(+)
>> >
>> > diff --git a/Documentation/devicetree/booting-without-of.txt
>> > b/Documentation/devicetree/booting-without-of.txt
>> > index 7768518..8b055897 100644
>> > --- a/Documentation/devicetree/booting-without-of.txt
>> > +++ b/Documentation/devicetree/booting-without-of.txt
>> > @@ -828,6 +828,10 @@ address which can extend beyond that limit.
>> >    name may clash with standard defined ones, you prefix them with your
>> >    vendor name and a comma.
>> >
>> > +  Additional properties for the root node:
>> > +
>> > +    - serial-number : a string representing the board's serial number
>> > +
>> >    b) The /cpus node
>> >
>> >    This node is the parent of all individual CPU nodes. It doesn't
>>
>

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Kumar Gala]

> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2@gmail.com> wrote:
> 
> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
>> Le jeudi 16 avril 2015 ? 09:56 +0200, Stefan Agner a ?crit :
>>> On 2015-03-28 18:39, Paul Kocialkowski wrote:
>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>>> 
>>> I think this is a worthwhile standardization.
>>> 
>>> Acked-by: Stefan Agner <stefan@agner.ch>
>> 
>> Thanks! I should also add a commit message in v2 mentioning that this is
>> already used in open firmware and reported by lshw.
> 
> With that,
> 
> Acked-by: Rob Herring <robh@kernel.org>
> 
>> 
>>>> ---
>>>> Documentation/devicetree/booting-without-of.txt | 4 ++++
>>>> 1 file changed, 4 insertions(+)
>>>> 
>>>> diff --git a/Documentation/devicetree/booting-without-of.txt
>>>> b/Documentation/devicetree/booting-without-of.txt
>>>> index 7768518..8b055897 100644
>>>> --- a/Documentation/devicetree/booting-without-of.txt
>>>> +++ b/Documentation/devicetree/booting-without-of.txt
>>>> @@ -828,6 +828,10 @@ address which can extend beyond that limit.
>>>>   name may clash with standard defined ones, you prefix them with your
>>>>   vendor name and a comma.
>>>> 
>>>> +  Additional properties for the root node:
>>>> +
>>>> +    - serial-number : a string representing the board's serial number
>>>> +
>>>>   b) The /cpus node
>>>> 
>>>>   This node is the parent of all individual CPU nodes. It doesn't
>>> 
>> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

I feel like this is a little lite either in the doc or commit message.  Is the string completely arbitrary?  Is it meant to match labeling on a board or case?  Is this meant to be used by the kernel at all?

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Paul Kocialkowski]

Le jeudi 16 avril 2015 ? 10:23 -0500, Kumar Gala a ?crit :
> > On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2@gmail.com> wrote:
> > 
> > On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> >> Le jeudi 16 avril 2015 ? 09:56 +0200, Stefan Agner a ?crit :
> >>> On 2015-03-28 18:39, Paul Kocialkowski wrote:
> >>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> >>> 
> >>> I think this is a worthwhile standardization.
> >>> 
> >>> Acked-by: Stefan Agner <stefan@agner.ch>
> >> 
> >> Thanks! I should also add a commit message in v2 mentioning that this is
> >> already used in open firmware and reported by lshw.
> > 
> > With that,
> > 
> > Acked-by: Rob Herring <robh@kernel.org>

[snip]

> I feel like this is a little lite either in the doc or commit message.
> Is the string completely arbitrary?  Is it meant to match labeling on
> a board or case?  Is this meant to be used by the kernel at all?

I guess it doesn't really matter what it is, as long as it's a string.
The kernel does not suggest any use for it either, it's just made
available to userspace through cpuinfo.

Now if there is a particular use for this in user-space, it would have
to match some standards. For instance, it Android, ro.serialno is
usually a 16-bytes (plus one null byte) representation of a 64 bit
number. For USB, I recall it is usually a 32 bytes string (including the
null byte), but may be extended to more.

What the string actually represents depends and some SOCs have serial
number bytes (I know that omap and sunxi have some for instance, that
are usually used) while other devices may take it from somewhere else.
In any case, it doesn't really matter and is not up to the kernel anyway
since it is just passed through from the bootloader.

Thus, I don't think it's very relevant to mention it in either the
documentation or the commit message.

-- 
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.infradead.org/pipermail/linux-arm-kernel/attachments/20150416/4fa14dc4/attachment.sig>

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Kumar Gala]

> On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> 
> Le jeudi 16 avril 2015 ? 10:23 -0500, Kumar Gala a ?crit :
>>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2@gmail.com> wrote:
>>> 
>>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
>>>> Le jeudi 16 avril 2015 ? 09:56 +0200, Stefan Agner a ?crit :
>>>>> On 2015-03-28 18:39, Paul Kocialkowski wrote:
>>>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>>>>> 
>>>>> I think this is a worthwhile standardization.
>>>>> 
>>>>> Acked-by: Stefan Agner <stefan@agner.ch>
>>>> 
>>>> Thanks! I should also add a commit message in v2 mentioning that this is
>>>> already used in open firmware and reported by lshw.
>>> 
>>> With that,
>>> 
>>> Acked-by: Rob Herring <robh@kernel.org>
> 
> [snip]
> 
>> I feel like this is a little lite either in the doc or commit message.
>> Is the string completely arbitrary?  Is it meant to match labeling on
>> a board or case?  Is this meant to be used by the kernel at all?
> 
> I guess it doesn't really matter what it is, as long as it's a string.
> The kernel does not suggest any use for it either, it's just made
> available to userspace through cpuinfo.
> 
> Now if there is a particular use for this in user-space, it would have
> to match some standards. For instance, it Android, ro.serialno is
> usually a 16-bytes (plus one null byte) representation of a 64 bit
> number. For USB, I recall it is usually a 32 bytes string (including the
> null byte), but may be extended to more.
> 
> What the string actually represents depends and some SOCs have serial
> number bytes (I know that omap and sunxi have some for instance, that
> are usually used) while other devices may take it from somewhere else.
> In any case, it doesn't really matter and is not up to the kernel anyway
> since it is just passed through from the bootloader.
> 
> Thus, I don't think it's very relevant to mention it in either the
> documentation or the commit message.

So you say ?board? in the patch, since it could be SoC specific, we should probably clean up the wording a bit.  I?m just saying when someone reads this 6 months or a year later and tries to figure out what the purpose of the property is they don?t really have enough info.  Putting some examples in the commit message of what possibly usages is I think a reasonable thing.

- k
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Paul Kocialkowski]

Le jeudi 16 avril 2015 ? 10:53 -0500, Kumar Gala a ?crit :
> > On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> > 
> > Le jeudi 16 avril 2015 ? 10:23 -0500, Kumar Gala a ?crit :
> >>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2@gmail.com> wrote:
> >>> 
> >>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> >>>> Le jeudi 16 avril 2015 ? 09:56 +0200, Stefan Agner a ?crit :
> >>>>> On 2015-03-28 18:39, Paul Kocialkowski wrote:
> >>>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> >>>>> 
> >>>>> I think this is a worthwhile standardization.
> >>>>> 
> >>>>> Acked-by: Stefan Agner <stefan@agner.ch>
> >>>> 
> >>>> Thanks! I should also add a commit message in v2 mentioning that this is
> >>>> already used in open firmware and reported by lshw.
> >>> 
> >>> With that,
> >>> 
> >>> Acked-by: Rob Herring <robh@kernel.org>
> > 
> > [snip]
> > 
> >> I feel like this is a little lite either in the doc or commit message.
> >> Is the string completely arbitrary?  Is it meant to match labeling on
> >> a board or case?  Is this meant to be used by the kernel at all?
> > 
> > I guess it doesn't really matter what it is, as long as it's a string.
> > The kernel does not suggest any use for it either, it's just made
> > available to userspace through cpuinfo.
> > 
> > Now if there is a particular use for this in user-space, it would have
> > to match some standards. For instance, it Android, ro.serialno is
> > usually a 16-bytes (plus one null byte) representation of a 64 bit
> > number. For USB, I recall it is usually a 32 bytes string (including the
> > null byte), but may be extended to more.
> > 
> > What the string actually represents depends and some SOCs have serial
> > number bytes (I know that omap and sunxi have some for instance, that
> > are usually used) while other devices may take it from somewhere else.
> > In any case, it doesn't really matter and is not up to the kernel anyway
> > since it is just passed through from the bootloader.
> > 
> > Thus, I don't think it's very relevant to mention it in either the
> > documentation or the commit message.
> 
> So you say ?board? in the patch, since it could be SoC specific, we
> should probably clean up the wording a bit.

It really doesn't matter where the string comes from, what it contains
or whether some SoCs have provisions to generate one.
I think board is one the most common words that we can use to describe
devices. "devices" is also fine, I could go with it if you prefer, but I
don't really see what it changes.

> I?m just saying when someone reads this 6 months or a year later and
> tries to figure out what the purpose of the property is they don?t
> really have enough info.  Putting some examples in the commit message
> of what possibly usages is I think a reasonable thing.

Okay, that would make sense. Still, the purpose of this is to pass the
serial number string from the bootloader to userspace. All of the
discussion about where to grab the serial from and what it should look
like is not relevant to the kernel. Instead, it's up to the bootloader
that is in charge of generating the serial string, so the discussion
should happen there.
-------------- 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.infradead.org/pipermail/linux-arm-kernel/attachments/20150416/30e5c303/attachment.sig>

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Kumar Gala]

> On Apr 16, 2015, at 1:14 PM, Paul Kocialkowski <contact@paulk.fr> wrote:
> 
> Le jeudi 16 avril 2015 ? 10:53 -0500, Kumar Gala a ?crit :
>>> On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
>>> 
>>> Le jeudi 16 avril 2015 ? 10:23 -0500, Kumar Gala a ?crit :
>>>>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2@gmail.com> wrote:
>>>>> 
>>>>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
>>>>>> Le jeudi 16 avril 2015 ? 09:56 +0200, Stefan Agner a ?crit :
>>>>>>> On 2015-03-28 18:39, Paul Kocialkowski wrote:
>>>>>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>>>>>>> 
>>>>>>> I think this is a worthwhile standardization.
>>>>>>> 
>>>>>>> Acked-by: Stefan Agner <stefan@agner.ch>
>>>>>> 
>>>>>> Thanks! I should also add a commit message in v2 mentioning that this is
>>>>>> already used in open firmware and reported by lshw.
>>>>> 
>>>>> With that,
>>>>> 
>>>>> Acked-by: Rob Herring <robh@kernel.org>
>>> 
>>> [snip]
>>> 
>>>> I feel like this is a little lite either in the doc or commit message.
>>>> Is the string completely arbitrary?  Is it meant to match labeling on
>>>> a board or case?  Is this meant to be used by the kernel at all?
>>> 
>>> I guess it doesn't really matter what it is, as long as it's a string.
>>> The kernel does not suggest any use for it either, it's just made
>>> available to userspace through cpuinfo.
>>> 
>>> Now if there is a particular use for this in user-space, it would have
>>> to match some standards. For instance, it Android, ro.serialno is
>>> usually a 16-bytes (plus one null byte) representation of a 64 bit
>>> number. For USB, I recall it is usually a 32 bytes string (including the
>>> null byte), but may be extended to more.
>>> 
>>> What the string actually represents depends and some SOCs have serial
>>> number bytes (I know that omap and sunxi have some for instance, that
>>> are usually used) while other devices may take it from somewhere else.
>>> In any case, it doesn't really matter and is not up to the kernel anyway
>>> since it is just passed through from the bootloader.
>>> 
>>> Thus, I don't think it's very relevant to mention it in either the
>>> documentation or the commit message.
>> 
>> So you say ?board? in the patch, since it could be SoC specific, we
>> should probably clean up the wording a bit.
> 
> It really doesn't matter where the string comes from, what it contains
> or whether some SoCs have provisions to generate one.
> I think board is one the most common words that we can use to describe
> devices. "devices" is also fine, I could go with it if you prefer, but I
> don't really see what it changes.

Lets go with device instead of board.

> 
>> I?m just saying when someone reads this 6 months or a year later and
>> tries to figure out what the purpose of the property is they don?t
>> really have enough info.  Putting some examples in the commit message
>> of what possibly usages is I think a reasonable thing.
> 
> Okay, that would make sense. Still, the purpose of this is to pass the
> serial number string from the bootloader to userspace. All of the
> discussion about where to grab the serial from and what it should look
> like is not relevant to the kernel. Instead, it's up to the bootloader
> that is in charge of generating the serial string, so the discussion
> should happen there.

Again, I?ve got no issues with the property and its purpose to be used by user space, just saying we need to convey more of the intent via commit message or updating the doc.

- k
-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Paul Kocialkowski]

Le jeudi 16 avril 2015 ? 13:54 -0500, Kumar Gala a ?crit :
> > On Apr 16, 2015, at 1:14 PM, Paul Kocialkowski <contact@paulk.fr> wrote:
> > 
> > Le jeudi 16 avril 2015 ? 10:53 -0500, Kumar Gala a ?crit :
> >>> On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> >>> 
> >>> Le jeudi 16 avril 2015 ? 10:23 -0500, Kumar Gala a ?crit :
> >>>>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2@gmail.com> wrote:
> >>>>> 
> >>>>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> >>>>>> Le jeudi 16 avril 2015 ? 09:56 +0200, Stefan Agner a ?crit :
> >>>>>>> On 2015-03-28 18:39, Paul Kocialkowski wrote:
> >>>>>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> >>>>>>> 
> >>>>>>> I think this is a worthwhile standardization.
> >>>>>>> 
> >>>>>>> Acked-by: Stefan Agner <stefan@agner.ch>
> >>>>>> 
> >>>>>> Thanks! I should also add a commit message in v2 mentioning that this is
> >>>>>> already used in open firmware and reported by lshw.
> >>>>> 
> >>>>> With that,
> >>>>> 
> >>>>> Acked-by: Rob Herring <robh@kernel.org>
> >>> 
> >>> [snip]
> >>> 
> >>>> I feel like this is a little lite either in the doc or commit message.
> >>>> Is the string completely arbitrary?  Is it meant to match labeling on
> >>>> a board or case?  Is this meant to be used by the kernel at all?
> >>> 
> >>> I guess it doesn't really matter what it is, as long as it's a string.
> >>> The kernel does not suggest any use for it either, it's just made
> >>> available to userspace through cpuinfo.
> >>> 
> >>> Now if there is a particular use for this in user-space, it would have
> >>> to match some standards. For instance, it Android, ro.serialno is
> >>> usually a 16-bytes (plus one null byte) representation of a 64 bit
> >>> number. For USB, I recall it is usually a 32 bytes string (including the
> >>> null byte), but may be extended to more.
> >>> 
> >>> What the string actually represents depends and some SOCs have serial
> >>> number bytes (I know that omap and sunxi have some for instance, that
> >>> are usually used) while other devices may take it from somewhere else.
> >>> In any case, it doesn't really matter and is not up to the kernel anyway
> >>> since it is just passed through from the bootloader.
> >>> 
> >>> Thus, I don't think it's very relevant to mention it in either the
> >>> documentation or the commit message.
> >> 
> >> So you say ?board? in the patch, since it could be SoC specific, we
> >> should probably clean up the wording a bit.
> > 
> > It really doesn't matter where the string comes from, what it contains
> > or whether some SoCs have provisions to generate one.
> > I think board is one the most common words that we can use to describe
> > devices. "devices" is also fine, I could go with it if you prefer, but I
> > don't really see what it changes.
> 
> Lets go with device instead of board.
> 
> > 
> >> I?m just saying when someone reads this 6 months or a year later and
> >> tries to figure out what the purpose of the property is they don?t
> >> really have enough info.  Putting some examples in the commit message
> >> of what possibly usages is I think a reasonable thing.
> > 
> > Okay, that would make sense. Still, the purpose of this is to pass the
> > serial number string from the bootloader to userspace. All of the
> > discussion about where to grab the serial from and what it should look
> > like is not relevant to the kernel. Instead, it's up to the bootloader
> > that is in charge of generating the serial string, so the discussion
> > should happen there.
> 
> Again, I?ve got no issues with the property and its purpose to be used
> by user space, just saying we need to convey more of the intent via
> commit message or updating the doc.

Okay so I'll go with "device" and mention a few use cases and what the
serial numbers look like for those. Is that satisfying to you?

> - k

-------------- 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.infradead.org/pipermail/linux-arm-kernel/attachments/20150416/840d6ef4/attachment.sig>

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Stefan Agner]

On 2015-04-16 20:14, Paul Kocialkowski wrote:
> Le jeudi 16 avril 2015 ? 10:53 -0500, Kumar Gala a ?crit :
>> > On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
>> >
>> > Le jeudi 16 avril 2015 ? 10:23 -0500, Kumar Gala a ?crit :
>> >>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2@gmail.com> wrote:
>> >>>
>> >>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
>> >>>> Le jeudi 16 avril 2015 ? 09:56 +0200, Stefan Agner a ?crit :
>> >>>>> On 2015-03-28 18:39, Paul Kocialkowski wrote:
>> >>>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>> >>>>>
>> >>>>> I think this is a worthwhile standardization.
>> >>>>>
>> >>>>> Acked-by: Stefan Agner <stefan@agner.ch>
>> >>>>
>> >>>> Thanks! I should also add a commit message in v2 mentioning that this is
>> >>>> already used in open firmware and reported by lshw.
>> >>>
>> >>> With that,
>> >>>
>> >>> Acked-by: Rob Herring <robh@kernel.org>
>> >
>> > [snip]
>> >
>> >> I feel like this is a little lite either in the doc or commit message.
>> >> Is the string completely arbitrary?  Is it meant to match labeling on
>> >> a board or case?  Is this meant to be used by the kernel at all?
>> >
>> > I guess it doesn't really matter what it is, as long as it's a string.
>> > The kernel does not suggest any use for it either, it's just made
>> > available to userspace through cpuinfo.
>> >
>> > Now if there is a particular use for this in user-space, it would have
>> > to match some standards. For instance, it Android, ro.serialno is
>> > usually a 16-bytes (plus one null byte) representation of a 64 bit
>> > number. For USB, I recall it is usually a 32 bytes string (including the
>> > null byte), but may be extended to more.
>> >
>> > What the string actually represents depends and some SOCs have serial
>> > number bytes (I know that omap and sunxi have some for instance, that
>> > are usually used) while other devices may take it from somewhere else.
>> > In any case, it doesn't really matter and is not up to the kernel anyway
>> > since it is just passed through from the bootloader.
>> >
>> > Thus, I don't think it's very relevant to mention it in either the
>> > documentation or the commit message.
>>
>> So you say ?board? in the patch, since it could be SoC specific, we
>> should probably clean up the wording a bit.
> 
> It really doesn't matter where the string comes from, what it contains
> or whether some SoCs have provisions to generate one.
> I think board is one the most common words that we can use to describe
> devices. "devices" is also fine, I could go with it if you prefer, but I
> don't really see what it changes.

There is already something related for SoC's in SoC bus called soc_id,
see
Documentation/ABI/testing/sysfs-devices-soc

So I would rather prefer that this is more reserved for device/board
serial number...

--
Stefan

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Paul Kocialkowski]

Le jeudi 16 avril 2015 ? 21:40 +0200, Stefan Agner a ?crit :
> On 2015-04-16 20:14, Paul Kocialkowski wrote:
> > Le jeudi 16 avril 2015 ? 10:53 -0500, Kumar Gala a ?crit :
> >> > On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> >> >
> >> > Le jeudi 16 avril 2015 ? 10:23 -0500, Kumar Gala a ?crit :
> >> >>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2@gmail.com> wrote:
> >> >>>
> >> >>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
> >> >>>> Le jeudi 16 avril 2015 ? 09:56 +0200, Stefan Agner a ?crit :
> >> >>>>> On 2015-03-28 18:39, Paul Kocialkowski wrote:
> >> >>>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
> >> >>>>>
> >> >>>>> I think this is a worthwhile standardization.
> >> >>>>>
> >> >>>>> Acked-by: Stefan Agner <stefan@agner.ch>
> >> >>>>
> >> >>>> Thanks! I should also add a commit message in v2 mentioning that this is
> >> >>>> already used in open firmware and reported by lshw.
> >> >>>
> >> >>> With that,
> >> >>>
> >> >>> Acked-by: Rob Herring <robh@kernel.org>
> >> >
> >> > [snip]
> >> >
> >> >> I feel like this is a little lite either in the doc or commit message.
> >> >> Is the string completely arbitrary?  Is it meant to match labeling on
> >> >> a board or case?  Is this meant to be used by the kernel at all?
> >> >
> >> > I guess it doesn't really matter what it is, as long as it's a string.
> >> > The kernel does not suggest any use for it either, it's just made
> >> > available to userspace through cpuinfo.
> >> >
> >> > Now if there is a particular use for this in user-space, it would have
> >> > to match some standards. For instance, it Android, ro.serialno is
> >> > usually a 16-bytes (plus one null byte) representation of a 64 bit
> >> > number. For USB, I recall it is usually a 32 bytes string (including the
> >> > null byte), but may be extended to more.
> >> >
> >> > What the string actually represents depends and some SOCs have serial
> >> > number bytes (I know that omap and sunxi have some for instance, that
> >> > are usually used) while other devices may take it from somewhere else.
> >> > In any case, it doesn't really matter and is not up to the kernel anyway
> >> > since it is just passed through from the bootloader.
> >> >
> >> > Thus, I don't think it's very relevant to mention it in either the
> >> > documentation or the commit message.
> >>
> >> So you say ?board? in the patch, since it could be SoC specific, we
> >> should probably clean up the wording a bit.
> > 
> > It really doesn't matter where the string comes from, what it contains
> > or whether some SoCs have provisions to generate one.
> > I think board is one the most common words that we can use to describe
> > devices. "devices" is also fine, I could go with it if you prefer, but I
> > don't really see what it changes.
> 
> There is already something related for SoC's in SoC bus called soc_id,
> see
> Documentation/ABI/testing/sysfs-devices-soc
> 
> So I would rather prefer that this is more reserved for device/board
> serial number...

Again, I don't wish to define what the number represents in the kernel.

It's whatever string the bootloader sends. I know that e.g. on an omap3
device, I'll be using this with the ID bits provided by the SoC (maybe
only part of them, there are 128 bits available and I like to have 64
bit serial numbers). But if you want your device to use something else
(e.g. some serial number stored in an external eeprom), it's up to you
to decide and in any case, that will be decided at bootloader stage.

Perhaps it would make sense to provide consistency for this among a
particular family of devices (say, devices from the same manufacture or
devices using the same SoC). We have already set up such a standard for
Allwinner (sunxi) devices, in U-Boot.

-------------- 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.infradead.org/pipermail/linux-arm-kernel/attachments/20150416/a51d6615/attachment.sig>

[PATCH 1/2] Documentation: devicetree: root node serial-number property documentation

[Stefan Agner]

On 2015-04-16 22:06, Paul Kocialkowski wrote:
> Le jeudi 16 avril 2015 ? 21:40 +0200, Stefan Agner a ?crit :
>> On 2015-04-16 20:14, Paul Kocialkowski wrote:
>> > Le jeudi 16 avril 2015 ? 10:53 -0500, Kumar Gala a ?crit :
>> >> > On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
>> >> >
>> >> > Le jeudi 16 avril 2015 ? 10:23 -0500, Kumar Gala a ?crit :
>> >> >>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2@gmail.com> wrote:
>> >> >>>
>> >> >>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact@paulk.fr> wrote:
>> >> >>>> Le jeudi 16 avril 2015 ? 09:56 +0200, Stefan Agner a ?crit :
>> >> >>>>> On 2015-03-28 18:39, Paul Kocialkowski wrote:
>> >> >>>>>> Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
>> >> >>>>>
>> >> >>>>> I think this is a worthwhile standardization.
>> >> >>>>>
>> >> >>>>> Acked-by: Stefan Agner <stefan@agner.ch>
>> >> >>>>
>> >> >>>> Thanks! I should also add a commit message in v2 mentioning that this is
>> >> >>>> already used in open firmware and reported by lshw.
>> >> >>>
>> >> >>> With that,
>> >> >>>
>> >> >>> Acked-by: Rob Herring <robh@kernel.org>
>> >> >
>> >> > [snip]
>> >> >
>> >> >> I feel like this is a little lite either in the doc or commit message.
>> >> >> Is the string completely arbitrary?  Is it meant to match labeling on
>> >> >> a board or case?  Is this meant to be used by the kernel at all?
>> >> >
>> >> > I guess it doesn't really matter what it is, as long as it's a string.
>> >> > The kernel does not suggest any use for it either, it's just made
>> >> > available to userspace through cpuinfo.
>> >> >
>> >> > Now if there is a particular use for this in user-space, it would have
>> >> > to match some standards. For instance, it Android, ro.serialno is
>> >> > usually a 16-bytes (plus one null byte) representation of a 64 bit
>> >> > number. For USB, I recall it is usually a 32 bytes string (including the
>> >> > null byte), but may be extended to more.
>> >> >
>> >> > What the string actually represents depends and some SOCs have serial
>> >> > number bytes (I know that omap and sunxi have some for instance, that
>> >> > are usually used) while other devices may take it from somewhere else.
>> >> > In any case, it doesn't really matter and is not up to the kernel anyway
>> >> > since it is just passed through from the bootloader.
>> >> >
>> >> > Thus, I don't think it's very relevant to mention it in either the
>> >> > documentation or the commit message.
>> >>
>> >> So you say ?board? in the patch, since it could be SoC specific, we
>> >> should probably clean up the wording a bit.
>> >
>> > It really doesn't matter where the string comes from, what it contains
>> > or whether some SoCs have provisions to generate one.
>> > I think board is one the most common words that we can use to describe
>> > devices. "devices" is also fine, I could go with it if you prefer, but I
>> > don't really see what it changes.
>>
>> There is already something related for SoC's in SoC bus called soc_id,
>> see
>> Documentation/ABI/testing/sysfs-devices-soc
>>
>> So I would rather prefer that this is more reserved for device/board
>> serial number...
> 
> Again, I don't wish to define what the number represents in the kernel.
> 
> It's whatever string the bootloader sends. I know that e.g. on an omap3
> device, I'll be using this with the ID bits provided by the SoC (maybe
> only part of them, there are 128 bits available and I like to have 64
> bit serial numbers). But if you want your device to use something else
> (e.g. some serial number stored in an external eeprom), it's up to you
> to decide and in any case, that will be decided at bootloader stage.

For that ID the soc_id attribute is actually much more appropriate. 

But if anybody wants to use that as serial-number, fine. I'm not saying
we should prohibit that.


> Perhaps it would make sense to provide consistency for this among a
> particular family of devices (say, devices from the same manufacture or
> devices using the same SoC). We have already set up such a standard for
> Allwinner (sunxi) devices, in U-Boot.

That is actually exactly my concern. We (Toradex) are a ARM module
provider which populate SoC's of different vendors. However, we would
like to keep consistency across modules. If a SoC vendor mandates to use
the field for the SoC serial number, we end up with different serial
numbers in that field.

IMHO, the top level serial-number should be used for the board/device.

But if you don't like to define that, it is ok for me. But maybe we
could just mention soc_id as a possible alternative for SoC serial
numbers in the documentation?

--
Stefan