* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-03-28 17:39 ` Paul Kocialkowski 0 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-03-28 17:39 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Rob Herring, Russell King, Hans De Goede, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, Paul Kocialkowski Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.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 -- 1.9.1 -- 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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-03-28 17:39 ` Paul Kocialkowski 0 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-03-28 17:39 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
[parent not found: <1427564371-26039-1-git-send-email-contact-W9ppeneeCTY@public.gmane.org>]
* [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo 2015-03-28 17:39 ` Paul Kocialkowski @ 2015-03-28 17:39 ` Paul Kocialkowski -1 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-03-28 17:39 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r Cc: Rob Herring, Russell King, Hans De Goede, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala, 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-W9ppeneeCTY@public.gmane.org> --- 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 -- 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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
* [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo @ 2015-03-28 17:39 ` Paul Kocialkowski 0 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-03-28 17:39 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply related [flat|nested] 37+ messages in thread
[parent not found: <1427564371-26039-2-git-send-email-contact-W9ppeneeCTY@public.gmane.org>]
* Re: [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo 2015-03-28 17:39 ` Paul Kocialkowski @ 2015-04-16 9:46 ` Russell King - ARM Linux -1 siblings, 0 replies; 37+ messages in thread From: Russell King - ARM Linux @ 2015-04-16 9:46 UTC (permalink / raw) To: Paul Kocialkowski Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring, Hans De Goede, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala 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-W9ppeneeCTY@public.gmane.org> > --- > 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. -- 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo @ 2015-04-16 9:46 ` Russell King - ARM Linux 0 siblings, 0 replies; 37+ messages in thread From: Russell King - ARM Linux @ 2015-04-16 9:46 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <20150416094623.GX12732-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org>]
* Re: [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo 2015-04-16 9:46 ` Russell King - ARM Linux @ 2015-04-16 10:23 ` Paul Kocialkowski -1 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 10:23 UTC (permalink / raw) To: Russell King - ARM Linux Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring, Hans De Goede, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala [-- Attachment #1: Type: text/plain, Size: 6278 bytes --] 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-W9ppeneeCTY@public.gmane.org> > > --- > > 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. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo @ 2015-04-16 10:23 ` Paul Kocialkowski 0 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 10:23 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo 2015-04-16 10:23 ` Paul Kocialkowski (?) @ 2015-04-16 14:37 ` Rob Herring -1 siblings, 0 replies; 37+ messages in thread From: Rob Herring @ 2015-04-16 14:37 UTC (permalink / raw) To: Paul Kocialkowski Cc: Russell King - ARM Linux, devicetree, linux-arm-kernel, Rob Herring, Hans De Goede, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala On Thu, Apr 16, 2015 at 5:23 AM, Paul Kocialkowski <contact@paulk.fr> wrote: > 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. I agree. There's no reason to do this early on a flattened ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo 2015-04-16 10:23 ` Paul Kocialkowski @ 2015-04-16 16:05 ` Russell King - ARM Linux -1 siblings, 0 replies; 37+ messages in thread From: Russell King - ARM Linux @ 2015-04-16 16:05 UTC (permalink / raw) To: Paul Kocialkowski Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Rob Herring, Hans De Goede, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala 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. -- 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo @ 2015-04-16 16:05 ` Russell King - ARM Linux 0 siblings, 0 replies; 37+ messages in thread From: Russell King - ARM Linux @ 2015-04-16 16:05 UTC (permalink / raw) To: linux-arm-kernel 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. ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-03-28 17:39 ` Paul Kocialkowski @ 2015-04-14 14:31 ` Paul Kocialkowski -1 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-14 14:31 UTC (permalink / raw) To: devicetree-u79uwXL29TY76Z2rM5mHXA Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland, Russell King, Pawel Moll, Ian Campbell, Hans De Goede, Rob Herring, Kumar Gala [-- Attachment #1: Type: text/plain, Size: 1081 bytes --] Le samedi 28 mars 2015 à 18:39 +0100, Paul Kocialkowski a écrit : > Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-14 14:31 ` Paul Kocialkowski 0 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-14 14:31 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-03-28 17:39 ` Paul Kocialkowski @ 2015-04-16 7:56 ` Stefan Agner -1 siblings, 0 replies; 37+ messages in thread From: Stefan Agner @ 2015-04-16 7:56 UTC (permalink / raw) To: Paul Kocialkowski Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland, Russell King, Pawel Moll, Ian Campbell, Hans De Goede, Rob Herring, Kumar Gala On 2015-03-28 18:39, Paul Kocialkowski wrote: > Signed-off-by: Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> I think this is a worthwhile standardization. Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.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 -- 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 7:56 ` Stefan Agner 0 siblings, 0 replies; 37+ messages in thread From: Stefan Agner @ 2015-04-16 7:56 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <f6f4f862c78fa626e7f94bde51eec5b1-XLVq0VzYD2Y@public.gmane.org>]
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-04-16 7:56 ` Stefan Agner @ 2015-04-16 9:10 ` Paul Kocialkowski -1 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 9:10 UTC (permalink / raw) To: Stefan Agner Cc: devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland, Russell King, Pawel Moll, Ian Campbell, Hans De Goede, Rob Herring, Kumar Gala [-- Attachment #1: Type: text/plain, Size: 1270 bytes --] 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-W9ppeneeCTY@public.gmane.org> > > I think this is a worthwhile standardization. > > Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> 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 > [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 9:10 ` Paul Kocialkowski 0 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 9:10 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-04-16 9:10 ` Paul Kocialkowski @ 2015-04-16 14:36 ` Rob Herring -1 siblings, 0 replies; 37+ messages in thread From: Rob Herring @ 2015-04-16 14:36 UTC (permalink / raw) To: Paul Kocialkowski Cc: Stefan Agner, devicetree-u79uwXL29TY76Z2rM5mHXA, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland, Russell King, Pawel Moll, Ian Campbell, Hans De Goede, Rob Herring, Kumar Gala On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> 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-W9ppeneeCTY@public.gmane.org> >> >> I think this is a worthwhile standardization. >> >> Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> > > 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 >> > -- 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 14:36 ` Rob Herring 0 siblings, 0 replies; 37+ messages in thread From: Rob Herring @ 2015-04-16 14:36 UTC (permalink / raw) To: linux-arm-kernel 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 >> > ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <CAL_JsqKdHQZL5Z6hKgquKihFykX0ZiCDQfeHOfOZWOh2NMg4Rw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-04-16 14:36 ` Rob Herring @ 2015-04-16 15:23 ` Kumar Gala -1 siblings, 0 replies; 37+ messages in thread From: Kumar Gala @ 2015-04-16 15:23 UTC (permalink / raw) To: Rob Herring Cc: Paul Kocialkowski, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Pawel Moll, Ian Campbell, Stefan Agner, Hans De Goede, Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r > On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> 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-W9ppeneeCTY@public.gmane.org> >>> >>> I think this is a worthwhile standardization. >>> >>> Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> >> >> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.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 -- 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 15:23 ` Kumar Gala 0 siblings, 0 replies; 37+ messages in thread From: Kumar Gala @ 2015-04-16 15:23 UTC (permalink / raw) To: linux-arm-kernel > 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <CFEF8F54-7A3E-482C-B295-6A6BC5D837C8-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-04-16 15:23 ` Kumar Gala @ 2015-04-16 15:45 ` Paul Kocialkowski -1 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 15:45 UTC (permalink / raw) To: Kumar Gala Cc: Rob Herring, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Pawel Moll, Ian Campbell, Stefan Agner, Hans De Goede, Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r [-- Attachment #1: Type: text/plain, Size: 2392 bytes --] Le jeudi 16 avril 2015 à 10:23 -0500, Kumar Gala a écrit : > > On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > > > > On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> 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-W9ppeneeCTY@public.gmane.org> > >>> > >>> I think this is a worthwhile standardization. > >>> > >>> Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> > >> > >> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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/ [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 15:45 ` Paul Kocialkowski 0 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 15:45 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-04-16 15:45 ` Paul Kocialkowski @ 2015-04-16 15:53 ` Kumar Gala -1 siblings, 0 replies; 37+ messages in thread From: Kumar Gala @ 2015-04-16 15:53 UTC (permalink / raw) To: Paul Kocialkowski Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Pawel Moll, Ian Campbell, Stefan Agner, Hans De Goede, Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r > On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> wrote: > > Le jeudi 16 avril 2015 à 10:23 -0500, Kumar Gala a écrit : >>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-W9ppeneeCTY@public.gmane.org> >>>>> >>>>> I think this is a worthwhile standardization. >>>>> >>>>> Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> >>>> >>>> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 -- 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 15:53 ` Kumar Gala 0 siblings, 0 replies; 37+ messages in thread From: Kumar Gala @ 2015-04-16 15:53 UTC (permalink / raw) To: linux-arm-kernel > 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <F4D05489-ACF0-44BB-AEC7-7E8FB83FAE4C-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-04-16 15:53 ` Kumar Gala @ 2015-04-16 18:14 ` Paul Kocialkowski -1 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 18:14 UTC (permalink / raw) To: Kumar Gala Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Pawel Moll, Ian Campbell, Stefan Agner, Hans De Goede, Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r [-- Attachment #1: Type: text/plain, Size: 3442 bytes --] Le jeudi 16 avril 2015 à 10:53 -0500, Kumar Gala a écrit : > > On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> wrote: > > > > Le jeudi 16 avril 2015 à 10:23 -0500, Kumar Gala a écrit : > >>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote: > >>> > >>> On Thu, Apr 16, 2015 at 4:10 AM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> 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-W9ppeneeCTY@public.gmane.org> > >>>>> > >>>>> I think this is a worthwhile standardization. > >>>>> > >>>>> Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> > >>>> > >>>> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 18:14 ` Paul Kocialkowski 0 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 18:14 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-04-16 18:14 ` Paul Kocialkowski @ 2015-04-16 18:54 ` Kumar Gala -1 siblings, 0 replies; 37+ messages in thread From: Kumar Gala @ 2015-04-16 18:54 UTC (permalink / raw) To: Paul Kocialkowski Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Pawel Moll, Ian Campbell, Stefan Agner, Hans De Goede, Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r > On Apr 16, 2015, at 1:14 PM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> wrote: > > Le jeudi 16 avril 2015 à 10:53 -0500, Kumar Gala a écrit : >>> On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> wrote: >>> >>> Le jeudi 16 avril 2015 à 10:23 -0500, Kumar Gala a écrit : >>>>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-W9ppeneeCTY@public.gmane.org> >>>>>>> >>>>>>> I think this is a worthwhile standardization. >>>>>>> >>>>>>> Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> >>>>>> >>>>>> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 -- 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 18:54 ` Kumar Gala 0 siblings, 0 replies; 37+ messages in thread From: Kumar Gala @ 2015-04-16 18:54 UTC (permalink / raw) To: linux-arm-kernel > 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <B1128C28-AC17-47F6-A64A-FD3197112751-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>]
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-04-16 18:54 ` Kumar Gala @ 2015-04-16 19:15 ` Paul Kocialkowski -1 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 19:15 UTC (permalink / raw) To: Kumar Gala Cc: Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Pawel Moll, Ian Campbell, Stefan Agner, Hans De Goede, Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r [-- Attachment #1: Type: text/plain, Size: 4147 bytes --] Le jeudi 16 avril 2015 à 13:54 -0500, Kumar Gala a écrit : > > On Apr 16, 2015, at 1:14 PM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> wrote: > > > > Le jeudi 16 avril 2015 à 10:53 -0500, Kumar Gala a écrit : > >>> On Apr 16, 2015, at 10:45 AM, Paul Kocialkowski <contact-W9ppeneeCTY@public.gmane.org> wrote: > >>> > >>> Le jeudi 16 avril 2015 à 10:23 -0500, Kumar Gala a écrit : > >>>>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-W9ppeneeCTY@public.gmane.org> > >>>>>>> > >>>>>>> I think this is a worthwhile standardization. > >>>>>>> > >>>>>>> Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> > >>>>>> > >>>>>> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 19:15 ` Paul Kocialkowski 0 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 19:15 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-04-16 18:14 ` Paul Kocialkowski @ 2015-04-16 19:40 ` Stefan Agner -1 siblings, 0 replies; 37+ messages in thread From: Stefan Agner @ 2015-04-16 19:40 UTC (permalink / raw) To: Paul Kocialkowski Cc: Kumar Gala, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Pawel Moll, Ian Campbell, Hans De Goede, Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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-W9ppeneeCTY@public.gmane.org> wrote: >> > >> > Le jeudi 16 avril 2015 à 10:23 -0500, Kumar Gala a écrit : >> >>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-W9ppeneeCTY@public.gmane.org> >> >>>>> >> >>>>> I think this is a worthwhile standardization. >> >>>>> >> >>>>> Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> >> >>>> >> >>>> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 -- 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 19:40 ` Stefan Agner 0 siblings, 0 replies; 37+ messages in thread From: Stefan Agner @ 2015-04-16 19:40 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
[parent not found: <97473e9075df185ab3024db70c471f53-XLVq0VzYD2Y@public.gmane.org>]
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-04-16 19:40 ` Stefan Agner @ 2015-04-16 20:06 ` Paul Kocialkowski -1 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 20:06 UTC (permalink / raw) To: Stefan Agner Cc: Kumar Gala, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Pawel Moll, Ian Campbell, Hans De Goede, Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r [-- Attachment #1: Type: text/plain, Size: 4030 bytes --] 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-W9ppeneeCTY@public.gmane.org> wrote: > >> > > >> > Le jeudi 16 avril 2015 à 10:23 -0500, Kumar Gala a écrit : > >> >>> On Apr 16, 2015, at 9:36 AM, Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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-W9ppeneeCTY@public.gmane.org> > >> >>>>> > >> >>>>> I think this is a worthwhile standardization. > >> >>>>> > >> >>>>> Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> > >> >>>> > >> >>>> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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. [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 20:06 ` Paul Kocialkowski 0 siblings, 0 replies; 37+ messages in thread From: Paul Kocialkowski @ 2015-04-16 20:06 UTC (permalink / raw) To: linux-arm-kernel 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> ^ permalink raw reply [flat|nested] 37+ messages in thread
* Re: [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation 2015-04-16 20:06 ` Paul Kocialkowski @ 2015-04-16 22:05 ` Stefan Agner -1 siblings, 0 replies; 37+ messages in thread From: Stefan Agner @ 2015-04-16 22:05 UTC (permalink / raw) To: Paul Kocialkowski Cc: Kumar Gala, Mark Rutland, devicetree-u79uwXL29TY76Z2rM5mHXA, Russell King, Pawel Moll, Ian Campbell, Hans De Goede, Rob Herring, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r 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-W9ppeneeCTY@public.gmane.org> >> >> >>>>> >> >> >>>>> I think this is a worthwhile standardization. >> >> >>>>> >> >> >>>>> Acked-by: Stefan Agner <stefan-XLVq0VzYD2Y@public.gmane.org> >> >> >>>> >> >> >>>> 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-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.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 -- 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
* [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation @ 2015-04-16 22:05 ` Stefan Agner 0 siblings, 0 replies; 37+ messages in thread From: Stefan Agner @ 2015-04-16 22:05 UTC (permalink / raw) To: linux-arm-kernel 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 ^ permalink raw reply [flat|nested] 37+ messages in thread
end of thread, other threads:[~2015-04-16 22:05 UTC | newest] Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-28 17:39 [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation Paul Kocialkowski 2015-03-28 17:39 ` Paul Kocialkowski [not found] ` <1427564371-26039-1-git-send-email-contact-W9ppeneeCTY@public.gmane.org> 2015-03-28 17:39 ` [PATCH 2/2] arch: arm: Show the serial number from devicetree in cpuinfo Paul Kocialkowski 2015-03-28 17:39 ` Paul Kocialkowski [not found] ` <1427564371-26039-2-git-send-email-contact-W9ppeneeCTY@public.gmane.org> 2015-04-16 9:46 ` Russell King - ARM Linux 2015-04-16 9:46 ` Russell King - ARM Linux [not found] ` <20150416094623.GX12732-l+eeeJia6m9vn6HldHNs0ANdhmdF6hFW@public.gmane.org> 2015-04-16 10:23 ` Paul Kocialkowski 2015-04-16 10:23 ` Paul Kocialkowski 2015-04-16 14:37 ` Rob Herring 2015-04-16 16:05 ` Russell King - ARM Linux 2015-04-16 16:05 ` Russell King - ARM Linux 2015-04-14 14:31 ` [PATCH 1/2] Documentation: devicetree: root node serial-number property documentation Paul Kocialkowski 2015-04-14 14:31 ` Paul Kocialkowski 2015-04-16 7:56 ` Stefan Agner 2015-04-16 7:56 ` Stefan Agner [not found] ` <f6f4f862c78fa626e7f94bde51eec5b1-XLVq0VzYD2Y@public.gmane.org> 2015-04-16 9:10 ` Paul Kocialkowski 2015-04-16 9:10 ` Paul Kocialkowski 2015-04-16 14:36 ` Rob Herring 2015-04-16 14:36 ` Rob Herring [not found] ` <CAL_JsqKdHQZL5Z6hKgquKihFykX0ZiCDQfeHOfOZWOh2NMg4Rw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2015-04-16 15:23 ` Kumar Gala 2015-04-16 15:23 ` Kumar Gala [not found] ` <CFEF8F54-7A3E-482C-B295-6A6BC5D837C8-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2015-04-16 15:45 ` Paul Kocialkowski 2015-04-16 15:45 ` Paul Kocialkowski 2015-04-16 15:53 ` Kumar Gala 2015-04-16 15:53 ` Kumar Gala [not found] ` <F4D05489-ACF0-44BB-AEC7-7E8FB83FAE4C-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2015-04-16 18:14 ` Paul Kocialkowski 2015-04-16 18:14 ` Paul Kocialkowski 2015-04-16 18:54 ` Kumar Gala 2015-04-16 18:54 ` Kumar Gala [not found] ` <B1128C28-AC17-47F6-A64A-FD3197112751-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org> 2015-04-16 19:15 ` Paul Kocialkowski 2015-04-16 19:15 ` Paul Kocialkowski 2015-04-16 19:40 ` Stefan Agner 2015-04-16 19:40 ` Stefan Agner [not found] ` <97473e9075df185ab3024db70c471f53-XLVq0VzYD2Y@public.gmane.org> 2015-04-16 20:06 ` Paul Kocialkowski 2015-04-16 20:06 ` Paul Kocialkowski 2015-04-16 22:05 ` Stefan Agner 2015-04-16 22:05 ` Stefan Agner
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.