All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 16:54 ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-06-18 16:54 UTC (permalink / raw)
  To: Russell King, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek
  Cc: linux-arm-kernel, linux-kernel, Pali Rohár

Machine name from board description is some generic name on DT kernel.
DT provides machine name property which is specific for board, so use
it instead generic one when possible.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 arch/arm/kernel/setup.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 8a16ee5..fbc7b4f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p)
 
 	setup_processor();
 	mdesc = setup_machine_fdt(__atags_pointer);
-	if (!mdesc)
+	if (mdesc)
+		machine_name = of_flat_dt_get_machine_name();
+	else
 		mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
 	machine_desc = mdesc;
-	machine_name = mdesc->name;
+	if (!machine_name)
+		machine_name = mdesc->name;
 
 	if (mdesc->reboot_mode != REBOOT_HARD)
 		reboot_mode = mdesc->reboot_mode;
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 16:54 ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-06-18 16:54 UTC (permalink / raw)
  To: linux-arm-kernel

Machine name from board description is some generic name on DT kernel.
DT provides machine name property which is specific for board, so use
it instead generic one when possible.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
 arch/arm/kernel/setup.c |    7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 8a16ee5..fbc7b4f 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p)
 
 	setup_processor();
 	mdesc = setup_machine_fdt(__atags_pointer);
-	if (!mdesc)
+	if (mdesc)
+		machine_name = of_flat_dt_get_machine_name();
+	else
 		mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
 	machine_desc = mdesc;
-	machine_name = mdesc->name;
+	if (!machine_name)
+		machine_name = mdesc->name;
 
 	if (mdesc->reboot_mode != REBOOT_HARD)
 		reboot_mode = mdesc->reboot_mode;
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 16:54 ` Pali Rohár
@ 2014-06-18 19:01   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-06-18 19:01 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-arm-kernel, linux-kernel

On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Rohár wrote:
> Machine name from board description is some generic name on DT kernel.
> DT provides machine name property which is specific for board, so use
> it instead generic one when possible.

http://archive.arm.linux.org.uk/lurker/message/20130726.132850.53d47576.en.html

"If userspace wants to get at the DT information about a platform, we already
have ways that can happen already - we export the DT stuff so that kexec's
tools can get at it."

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 19:01   ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-06-18 19:01 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r wrote:
> Machine name from board description is some generic name on DT kernel.
> DT provides machine name property which is specific for board, so use
> it instead generic one when possible.

http://archive.arm.linux.org.uk/lurker/message/20130726.132850.53d47576.en.html

"If userspace wants to get at the DT information about a platform, we already
have ways that can happen already - we export the DT stuff so that kexec's
tools can get at it."

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 16:54 ` Pali Rohár
@ 2014-06-18 19:07   ` Rob Herring
  -1 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-06-18 19:07 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel

On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> Machine name from board description is some generic name on DT kernel.
> DT provides machine name property which is specific for board, so use
> it instead generic one when possible.
>
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  arch/arm/kernel/setup.c |    7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 8a16ee5..fbc7b4f 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p)
>
>         setup_processor();
>         mdesc = setup_machine_fdt(__atags_pointer);
> -       if (!mdesc)
> +       if (mdesc)
> +               machine_name = of_flat_dt_get_machine_name();
> +       else
>                 mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
>         machine_desc = mdesc;
> -       machine_name = mdesc->name;
> +       if (!machine_name)
> +               machine_name = mdesc->name;
>
>         if (mdesc->reboot_mode != REBOOT_HARD)
>                 reboot_mode = mdesc->reboot_mode;

I did a similar patch previously[1]. Like my original patch, your
patch unconditionally changes the name which could be considered part
of the userspace ABI. It's arguably not good practice for userspace to
depend on the name, but there are likely cases that do. So I think
this needs to be optional and only use the DT name if the machine desc
name is NULL.

So something like the below and then change the machine descriptors
you care about. The default generic DT machine desc should definitely
be changed.

I had a follow-up discussion with Grant about his concerns in the
thread about knowing which machine desc used to boot. He said he was
okay if just the machine desc address is printed out.


diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 50e198c..1479250 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -887,7 +887,7 @@ void __init setup_arch(char **cmdline_p)
        if (!mdesc)
                mdesc = setup_machine_tags(__atags_pointer,
__machine_arch_type);
        machine_desc = mdesc;
-       machine_name = mdesc->name;
+       machine_name = mdesc->name ? mdesc->name :
of_flat_dt_get_machine_name();

        if (mdesc->reboot_mode != REBOOT_HARD)
                reboot_mode = mdesc->reboot_mode;


[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/208878.html

^ permalink raw reply related	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 19:07   ` Rob Herring
  0 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-06-18 19:07 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> Machine name from board description is some generic name on DT kernel.
> DT provides machine name property which is specific for board, so use
> it instead generic one when possible.
>
> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> ---
>  arch/arm/kernel/setup.c |    7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 8a16ee5..fbc7b4f 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p)
>
>         setup_processor();
>         mdesc = setup_machine_fdt(__atags_pointer);
> -       if (!mdesc)
> +       if (mdesc)
> +               machine_name = of_flat_dt_get_machine_name();
> +       else
>                 mdesc = setup_machine_tags(__atags_pointer, __machine_arch_type);
>         machine_desc = mdesc;
> -       machine_name = mdesc->name;
> +       if (!machine_name)
> +               machine_name = mdesc->name;
>
>         if (mdesc->reboot_mode != REBOOT_HARD)
>                 reboot_mode = mdesc->reboot_mode;

I did a similar patch previously[1]. Like my original patch, your
patch unconditionally changes the name which could be considered part
of the userspace ABI. It's arguably not good practice for userspace to
depend on the name, but there are likely cases that do. So I think
this needs to be optional and only use the DT name if the machine desc
name is NULL.

So something like the below and then change the machine descriptors
you care about. The default generic DT machine desc should definitely
be changed.

I had a follow-up discussion with Grant about his concerns in the
thread about knowing which machine desc used to boot. He said he was
okay if just the machine desc address is printed out.


diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 50e198c..1479250 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -887,7 +887,7 @@ void __init setup_arch(char **cmdline_p)
        if (!mdesc)
                mdesc = setup_machine_tags(__atags_pointer,
__machine_arch_type);
        machine_desc = mdesc;
-       machine_name = mdesc->name;
+       machine_name = mdesc->name ? mdesc->name :
of_flat_dt_get_machine_name();

        if (mdesc->reboot_mode != REBOOT_HARD)
                reboot_mode = mdesc->reboot_mode;


[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2013-November/208878.html

^ permalink raw reply related	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 19:01   ` Russell King - ARM Linux
@ 2014-06-18 19:09     ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-06-18 19:09 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-arm-kernel, linux-kernel

[-- Attachment #1: Type: Text/Plain, Size: 1112 bytes --]

On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux 
wrote:
> On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Rohár wrote:
> > Machine name from board description is some generic name on
> > DT kernel. DT provides machine name property which is
> > specific for board, so use it instead generic one when
> > possible.
> 
> http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> .53d47576.en.html
> 
> "If userspace wants to get at the DT information about a
> platform, we already have ways that can happen already - we
> export the DT stuff so that kexec's tools can get at it."

Userspace application does not know that kernel using DT. And 
also it does not want to get DT information. Only board/machine 
name. So existing applications stop working after migration to 
DT. And because legacy board boot code (without DT) is going to 
be removed for ARM in near future this will permanently break 
existing applications.

And sometimes it is even not possible to fix userspace 
application if is closed source - binary only.

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 19:09     ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-06-18 19:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux 
wrote:
> On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r wrote:
> > Machine name from board description is some generic name on
> > DT kernel. DT provides machine name property which is
> > specific for board, so use it instead generic one when
> > possible.
> 
> http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> .53d47576.en.html
> 
> "If userspace wants to get at the DT information about a
> platform, we already have ways that can happen already - we
> export the DT stuff so that kexec's tools can get at it."

Userspace application does not know that kernel using DT. And 
also it does not want to get DT information. Only board/machine 
name. So existing applications stop working after migration to 
DT. And because legacy board boot code (without DT) is going to 
be removed for ARM in near future this will permanently break 
existing applications.

And sometimes it is even not possible to fix userspace 
application if is closed source - binary only.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140618/5d34ccda/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 19:07   ` Rob Herring
@ 2014-06-18 19:22     ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-06-18 19:22 UTC (permalink / raw)
  To: Rob Herring
  Cc: Russell King, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 4458 bytes --]

On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > Machine name from board description is some generic name on
> > DT kernel. DT provides machine name property which is
> > specific for board, so use it instead generic one when
> > possible.
> > 
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> > 
> >  arch/arm/kernel/setup.c |    7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/setup.c
> > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -875,10 +875,13 @@ void __init setup_arch(char
> > **cmdline_p)
> > 
> >         setup_processor();
> >         mdesc = setup_machine_fdt(__atags_pointer);
> > 
> > -       if (!mdesc)
> > +       if (mdesc)
> > +               machine_name =
> > of_flat_dt_get_machine_name(); +       else
> > 
> >                 mdesc = setup_machine_tags(__atags_pointer,
> >                 __machine_arch_type);
> >         
> >         machine_desc = mdesc;
> > 
> > -       machine_name = mdesc->name;
> > +       if (!machine_name)
> > +               machine_name = mdesc->name;
> > 
> >         if (mdesc->reboot_mode != REBOOT_HARD)
> >         
> >                 reboot_mode = mdesc->reboot_mode;
> 
> I did a similar patch previously[1]. Like my original patch,
> your patch unconditionally changes the name which could be
> considered part of the userspace ABI. It's arguably not good
> practice for userspace to depend on the name, but there are
> likely cases that do. So I think this needs to be optional
> and only use the DT name if the machine desc name is NULL.
> 
> So something like the below and then change the machine
> descriptors you care about. The default generic DT machine
> desc should definitely be changed.
> 
> I had a follow-up discussion with Grant about his concerns in
> the thread about knowing which machine desc used to boot. He
> said he was okay if just the machine desc address is printed
> out.
> 
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 50e198c..1479250 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -887,7 +887,7 @@ void __init setup_arch(char **cmdline_p)
>         if (!mdesc)
>                 mdesc = setup_machine_tags(__atags_pointer,
> __machine_arch_type);
>         machine_desc = mdesc;
> -       machine_name = mdesc->name;
> +       machine_name = mdesc->name ? mdesc->name :
> of_flat_dt_get_machine_name();
> 
>         if (mdesc->reboot_mode != REBOOT_HARD)
>                 reboot_mode = mdesc->reboot_mode;
> 
> 
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-No
> vember/208878.html

Hi,

now legacy board code for Nokia N900 (RX-51) is migrating to DT  
kernel and there is problem with info which /proc/cpuinfo reports

New DT kernel (3.16-rc1) reports:

# busybox cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
Features        : swp half thumb fastmult vfp edsp thumbee neon 
vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc08
CPU revision    : 3

Hardware        : Generic OMAP3 (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

But legacy board code kernel reports:

# busybox cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
Features        : swp half thumb fastmult vfp edsp thumbee neon 
vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc08
CPU revision    : 3

Hardware        : Nokia RX-51 board
Revision        : 0012
Serial          : 0000000000000000

Basically in DT kernel is missing Hardware, Revision and probably 
also Serial key. (Now I used only qemu for testing which set 
serial key to 0). All these informations is used by userspace 
applications which determinate how to behave.

So without this patch DT migration for Nokia N900 cannot be done 
without breaking userspace - which is not acceptable...

Also I still did not know why DT kernel does not report Revision 
number which is passed by bootloader via atags. Any idea?

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 19:22     ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-06-18 19:22 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r 
<pali.rohar@gmail.com> wrote:
> > Machine name from board description is some generic name on
> > DT kernel. DT provides machine name property which is
> > specific for board, so use it instead generic one when
> > possible.
> > 
> > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > ---
> > 
> >  arch/arm/kernel/setup.c |    7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/setup.c
> > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -875,10 +875,13 @@ void __init setup_arch(char
> > **cmdline_p)
> > 
> >         setup_processor();
> >         mdesc = setup_machine_fdt(__atags_pointer);
> > 
> > -       if (!mdesc)
> > +       if (mdesc)
> > +               machine_name =
> > of_flat_dt_get_machine_name(); +       else
> > 
> >                 mdesc = setup_machine_tags(__atags_pointer,
> >                 __machine_arch_type);
> >         
> >         machine_desc = mdesc;
> > 
> > -       machine_name = mdesc->name;
> > +       if (!machine_name)
> > +               machine_name = mdesc->name;
> > 
> >         if (mdesc->reboot_mode != REBOOT_HARD)
> >         
> >                 reboot_mode = mdesc->reboot_mode;
> 
> I did a similar patch previously[1]. Like my original patch,
> your patch unconditionally changes the name which could be
> considered part of the userspace ABI. It's arguably not good
> practice for userspace to depend on the name, but there are
> likely cases that do. So I think this needs to be optional
> and only use the DT name if the machine desc name is NULL.
> 
> So something like the below and then change the machine
> descriptors you care about. The default generic DT machine
> desc should definitely be changed.
> 
> I had a follow-up discussion with Grant about his concerns in
> the thread about knowing which machine desc used to boot. He
> said he was okay if just the machine desc address is printed
> out.
> 
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 50e198c..1479250 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -887,7 +887,7 @@ void __init setup_arch(char **cmdline_p)
>         if (!mdesc)
>                 mdesc = setup_machine_tags(__atags_pointer,
> __machine_arch_type);
>         machine_desc = mdesc;
> -       machine_name = mdesc->name;
> +       machine_name = mdesc->name ? mdesc->name :
> of_flat_dt_get_machine_name();
> 
>         if (mdesc->reboot_mode != REBOOT_HARD)
>                 reboot_mode = mdesc->reboot_mode;
> 
> 
> [1]
> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-No
> vember/208878.html

Hi,

now legacy board code for Nokia N900 (RX-51) is migrating to DT  
kernel and there is problem with info which /proc/cpuinfo reports

New DT kernel (3.16-rc1) reports:

# busybox cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
Features        : swp half thumb fastmult vfp edsp thumbee neon 
vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc08
CPU revision    : 3

Hardware        : Generic OMAP3 (Flattened Device Tree)
Revision        : 0000
Serial          : 0000000000000000

But legacy board code kernel reports:

# busybox cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
Features        : swp half thumb fastmult vfp edsp thumbee neon 
vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc08
CPU revision    : 3

Hardware        : Nokia RX-51 board
Revision        : 0012
Serial          : 0000000000000000

Basically in DT kernel is missing Hardware, Revision and probably 
also Serial key. (Now I used only qemu for testing which set 
serial key to 0). All these informations is used by userspace 
applications which determinate how to behave.

So without this patch DT migration for Nokia N900 cannot be done 
without breaking userspace - which is not acceptable...

Also I still did not know why DT kernel does not report Revision 
number which is passed by bootloader via atags. Any idea?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140618/5a518bfe/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 19:09     ` Pali Rohár
@ 2014-06-18 19:59       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-06-18 19:59 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-arm-kernel, linux-kernel

On Wed, Jun 18, 2014 at 09:09:58PM +0200, Pali Rohár wrote:
> On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux 
> wrote:
> > On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Rohár wrote:
> > > Machine name from board description is some generic name on
> > > DT kernel. DT provides machine name property which is
> > > specific for board, so use it instead generic one when
> > > possible.
> > 
> > http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> > .53d47576.en.html
> > 
> > "If userspace wants to get at the DT information about a
> > platform, we already have ways that can happen already - we
> > export the DT stuff so that kexec's tools can get at it."
> 
> Userspace application does not know that kernel using DT. And 
> also it does not want to get DT information. Only board/machine 
> name. So existing applications stop working after migration to 
> DT. And because legacy board boot code (without DT) is going to 
> be removed for ARM in near future this will permanently break 
> existing applications.

We're already breaking the userspace API through moving to DT, because
all the device names in /sys/devices are changing.  Userspace is going
to have to cope with change as we move towards DT.  This is just
another aspect of moving towards DT, and one which userspace is going
to have to deal with.

> And sometimes it is even not possible to fix userspace 
> application if is closed source - binary only.

And why do we care about closed source?

If we listened to this argument, then we wouldn't ever be able to
change anything in procfs or sysfs.

Change is inevitable.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 19:59       ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-06-18 19:59 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 18, 2014 at 09:09:58PM +0200, Pali Roh?r wrote:
> On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux 
> wrote:
> > On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r wrote:
> > > Machine name from board description is some generic name on
> > > DT kernel. DT provides machine name property which is
> > > specific for board, so use it instead generic one when
> > > possible.
> > 
> > http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> > .53d47576.en.html
> > 
> > "If userspace wants to get at the DT information about a
> > platform, we already have ways that can happen already - we
> > export the DT stuff so that kexec's tools can get at it."
> 
> Userspace application does not know that kernel using DT. And 
> also it does not want to get DT information. Only board/machine 
> name. So existing applications stop working after migration to 
> DT. And because legacy board boot code (without DT) is going to 
> be removed for ARM in near future this will permanently break 
> existing applications.

We're already breaking the userspace API through moving to DT, because
all the device names in /sys/devices are changing.  Userspace is going
to have to cope with change as we move towards DT.  This is just
another aspect of moving towards DT, and one which userspace is going
to have to deal with.

> And sometimes it is even not possible to fix userspace 
> application if is closed source - binary only.

And why do we care about closed source?

If we listened to this argument, then we wouldn't ever be able to
change anything in procfs or sysfs.

Change is inevitable.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 19:22     ` Pali Rohár
@ 2014-06-18 20:00       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-06-18 20:00 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Rob Herring, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel

On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote:
> So without this patch DT migration for Nokia N900 cannot be done 
> without breaking userspace - which is not acceptable...
> 
> Also I still did not know why DT kernel does not report Revision 
> number which is passed by bootloader via atags. Any idea?

It was a concious decision by the DT people to exclude most of the ATAGs
which provide that information.  Only memory information and command line
ATAGs are merged into DT.  Every other tag is ignored (as there's no
place for it in DT.)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 20:00       ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-06-18 20:00 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Roh?r wrote:
> So without this patch DT migration for Nokia N900 cannot be done 
> without breaking userspace - which is not acceptable...
> 
> Also I still did not know why DT kernel does not report Revision 
> number which is passed by bootloader via atags. Any idea?

It was a concious decision by the DT people to exclude most of the ATAGs
which provide that information.  Only memory information and command line
ATAGs are merged into DT.  Every other tag is ignored (as there's no
place for it in DT.)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 20:00       ` Russell King - ARM Linux
@ 2014-06-18 20:20         ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-06-18 20:20 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Rob Herring, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 775 bytes --]

On Wednesday 18 June 2014 22:00:54 Russell King - ARM Linux 
wrote:
> On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote:
> > So without this patch DT migration for Nokia N900 cannot be
> > done without breaking userspace - which is not
> > acceptable...
> > 
> > Also I still did not know why DT kernel does not report
> > Revision number which is passed by bootloader via atags.
> > Any idea?
> 
> It was a concious decision by the DT people to exclude most of
> the ATAGs which provide that information.  Only memory
> information and command line ATAGs are merged into DT.  Every
> other tag is ignored (as there's no place for it in DT.)

So how to read Revision and Serial number in DT based kernel? 

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 20:20         ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-06-18 20:20 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 18 June 2014 22:00:54 Russell King - ARM Linux 
wrote:
> On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Roh?r wrote:
> > So without this patch DT migration for Nokia N900 cannot be
> > done without breaking userspace - which is not
> > acceptable...
> > 
> > Also I still did not know why DT kernel does not report
> > Revision number which is passed by bootloader via atags.
> > Any idea?
> 
> It was a concious decision by the DT people to exclude most of
> the ATAGs which provide that information.  Only memory
> information and command line ATAGs are merged into DT.  Every
> other tag is ignored (as there's no place for it in DT.)

So how to read Revision and Serial number in DT based kernel? 

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140618/b648a269/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 19:22     ` Pali Rohár
@ 2014-06-18 20:46       ` Rob Herring
  -1 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-06-18 20:46 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel

On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > Machine name from board description is some generic name on
>> > DT kernel. DT provides machine name property which is
>> > specific for board, so use it instead generic one when
>> > possible.
>> >
>> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>> > ---
>> >
>> >  arch/arm/kernel/setup.c |    7 +++++--
>> >  1 file changed, 5 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm/kernel/setup.c
>> > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
>> > --- a/arch/arm/kernel/setup.c
>> > +++ b/arch/arm/kernel/setup.c
>> > @@ -875,10 +875,13 @@ void __init setup_arch(char
>> > **cmdline_p)
>> >
>> >         setup_processor();
>> >         mdesc = setup_machine_fdt(__atags_pointer);
>> >
>> > -       if (!mdesc)
>> > +       if (mdesc)
>> > +               machine_name =
>> > of_flat_dt_get_machine_name(); +       else
>> >
>> >                 mdesc = setup_machine_tags(__atags_pointer,
>> >                 __machine_arch_type);
>> >
>> >         machine_desc = mdesc;
>> >
>> > -       machine_name = mdesc->name;
>> > +       if (!machine_name)
>> > +               machine_name = mdesc->name;
>> >
>> >         if (mdesc->reboot_mode != REBOOT_HARD)
>> >
>> >                 reboot_mode = mdesc->reboot_mode;
>>
>> I did a similar patch previously[1]. Like my original patch,
>> your patch unconditionally changes the name which could be
>> considered part of the userspace ABI. It's arguably not good
>> practice for userspace to depend on the name, but there are
>> likely cases that do. So I think this needs to be optional
>> and only use the DT name if the machine desc name is NULL.
>>
>> So something like the below and then change the machine
>> descriptors you care about. The default generic DT machine
>> desc should definitely be changed.
>>
>> I had a follow-up discussion with Grant about his concerns in
>> the thread about knowing which machine desc used to boot. He
>> said he was okay if just the machine desc address is printed
>> out.
>>
>>
>> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> index 50e198c..1479250 100644
>> --- a/arch/arm/kernel/setup.c
>> +++ b/arch/arm/kernel/setup.c
>> @@ -887,7 +887,7 @@ void __init setup_arch(char **cmdline_p)
>>         if (!mdesc)
>>                 mdesc = setup_machine_tags(__atags_pointer,
>> __machine_arch_type);
>>         machine_desc = mdesc;
>> -       machine_name = mdesc->name;
>> +       machine_name = mdesc->name ? mdesc->name :
>> of_flat_dt_get_machine_name();
>>
>>         if (mdesc->reboot_mode != REBOOT_HARD)
>>                 reboot_mode = mdesc->reboot_mode;
>>
>>
>> [1]
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-No
>> vember/208878.html
>
> Hi,
>
> now legacy board code for Nokia N900 (RX-51) is migrating to DT
> kernel and there is problem with info which /proc/cpuinfo reports

Thanks for providing your motivation which was missing from the commit message.

>
> New DT kernel (3.16-rc1) reports:
>
> # busybox cat /proc/cpuinfo
> processor       : 0
> model name      : ARMv7 Processor rev 3 (v7l)
> Features        : swp half thumb fastmult vfp edsp thumbee neon
> vfpv3 tls vfpd32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x2
> CPU part        : 0xc08
> CPU revision    : 3
>
> Hardware        : Generic OMAP3 (Flattened Device Tree)
> Revision        : 0000
> Serial          : 0000000000000000
>
> But legacy board code kernel reports:
>
> # busybox cat /proc/cpuinfo
> processor       : 0
> model name      : ARMv7 Processor rev 3 (v7l)
> Features        : swp half thumb fastmult vfp edsp thumbee neon
> vfpv3 tls vfpd32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x2
> CPU part        : 0xc08
> CPU revision    : 3
>
> Hardware        : Nokia RX-51 board
> Revision        : 0012
> Serial          : 0000000000000000
>
> Basically in DT kernel is missing Hardware, Revision and probably
> also Serial key. (Now I used only qemu for testing which set
> serial key to 0). All these informations is used by userspace
> applications which determinate how to behave.

It is somewhat fragile to expect the name in the DT to match the old
name from the kernel. As your patch to n900 dts shows, we'd probably
have to update every dts file to make them match. While I think we
should work to remove this string from the kernel, userspace depending
on the DT model string is a bad idea. For example, if you had some
platform with multiple OEMs just rebranding the same base design, they
may all want to put their own model string into each product. The true
h/w id is the compatible string.

Serial number is easy. There is already a standard although not widely
used property for it with "/serial-number". You just need to wire it
up to cpuinfo.

> So without this patch DT migration for Nokia N900 cannot be done
> without breaking userspace - which is not acceptable...

I agree, but I would like to come up with something that prevents
future dependence on this string.

> Also I still did not know why DT kernel does not report Revision
> number which is passed by bootloader via atags. Any idea?

Probably because no one cared until now and revision info for every
SOC is different. I would like to see revision info set in the DT in a
standard way and remove the various SOC specific kernel
implementations.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 20:46       ` Rob Herring
  0 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-06-18 20:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
> <pali.rohar@gmail.com> wrote:
>> > Machine name from board description is some generic name on
>> > DT kernel. DT provides machine name property which is
>> > specific for board, so use it instead generic one when
>> > possible.
>> >
>> > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
>> > ---
>> >
>> >  arch/arm/kernel/setup.c |    7 +++++--
>> >  1 file changed, 5 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/arch/arm/kernel/setup.c
>> > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
>> > --- a/arch/arm/kernel/setup.c
>> > +++ b/arch/arm/kernel/setup.c
>> > @@ -875,10 +875,13 @@ void __init setup_arch(char
>> > **cmdline_p)
>> >
>> >         setup_processor();
>> >         mdesc = setup_machine_fdt(__atags_pointer);
>> >
>> > -       if (!mdesc)
>> > +       if (mdesc)
>> > +               machine_name =
>> > of_flat_dt_get_machine_name(); +       else
>> >
>> >                 mdesc = setup_machine_tags(__atags_pointer,
>> >                 __machine_arch_type);
>> >
>> >         machine_desc = mdesc;
>> >
>> > -       machine_name = mdesc->name;
>> > +       if (!machine_name)
>> > +               machine_name = mdesc->name;
>> >
>> >         if (mdesc->reboot_mode != REBOOT_HARD)
>> >
>> >                 reboot_mode = mdesc->reboot_mode;
>>
>> I did a similar patch previously[1]. Like my original patch,
>> your patch unconditionally changes the name which could be
>> considered part of the userspace ABI. It's arguably not good
>> practice for userspace to depend on the name, but there are
>> likely cases that do. So I think this needs to be optional
>> and only use the DT name if the machine desc name is NULL.
>>
>> So something like the below and then change the machine
>> descriptors you care about. The default generic DT machine
>> desc should definitely be changed.
>>
>> I had a follow-up discussion with Grant about his concerns in
>> the thread about knowing which machine desc used to boot. He
>> said he was okay if just the machine desc address is printed
>> out.
>>
>>
>> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> index 50e198c..1479250 100644
>> --- a/arch/arm/kernel/setup.c
>> +++ b/arch/arm/kernel/setup.c
>> @@ -887,7 +887,7 @@ void __init setup_arch(char **cmdline_p)
>>         if (!mdesc)
>>                 mdesc = setup_machine_tags(__atags_pointer,
>> __machine_arch_type);
>>         machine_desc = mdesc;
>> -       machine_name = mdesc->name;
>> +       machine_name = mdesc->name ? mdesc->name :
>> of_flat_dt_get_machine_name();
>>
>>         if (mdesc->reboot_mode != REBOOT_HARD)
>>                 reboot_mode = mdesc->reboot_mode;
>>
>>
>> [1]
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-No
>> vember/208878.html
>
> Hi,
>
> now legacy board code for Nokia N900 (RX-51) is migrating to DT
> kernel and there is problem with info which /proc/cpuinfo reports

Thanks for providing your motivation which was missing from the commit message.

>
> New DT kernel (3.16-rc1) reports:
>
> # busybox cat /proc/cpuinfo
> processor       : 0
> model name      : ARMv7 Processor rev 3 (v7l)
> Features        : swp half thumb fastmult vfp edsp thumbee neon
> vfpv3 tls vfpd32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x2
> CPU part        : 0xc08
> CPU revision    : 3
>
> Hardware        : Generic OMAP3 (Flattened Device Tree)
> Revision        : 0000
> Serial          : 0000000000000000
>
> But legacy board code kernel reports:
>
> # busybox cat /proc/cpuinfo
> processor       : 0
> model name      : ARMv7 Processor rev 3 (v7l)
> Features        : swp half thumb fastmult vfp edsp thumbee neon
> vfpv3 tls vfpd32
> CPU implementer : 0x41
> CPU architecture: 7
> CPU variant     : 0x2
> CPU part        : 0xc08
> CPU revision    : 3
>
> Hardware        : Nokia RX-51 board
> Revision        : 0012
> Serial          : 0000000000000000
>
> Basically in DT kernel is missing Hardware, Revision and probably
> also Serial key. (Now I used only qemu for testing which set
> serial key to 0). All these informations is used by userspace
> applications which determinate how to behave.

It is somewhat fragile to expect the name in the DT to match the old
name from the kernel. As your patch to n900 dts shows, we'd probably
have to update every dts file to make them match. While I think we
should work to remove this string from the kernel, userspace depending
on the DT model string is a bad idea. For example, if you had some
platform with multiple OEMs just rebranding the same base design, they
may all want to put their own model string into each product. The true
h/w id is the compatible string.

Serial number is easy. There is already a standard although not widely
used property for it with "/serial-number". You just need to wire it
up to cpuinfo.

> So without this patch DT migration for Nokia N900 cannot be done
> without breaking userspace - which is not acceptable...

I agree, but I would like to come up with something that prevents
future dependence on this string.

> Also I still did not know why DT kernel does not report Revision
> number which is passed by bootloader via atags. Any idea?

Probably because no one cared until now and revision info for every
SOC is different. I would like to see revision info set in the DT in a
standard way and remove the various SOC specific kernel
implementations.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 19:22     ` Pali Rohár
@ 2014-06-18 21:10       ` Aaro Koskinen
  -1 siblings, 0 replies; 197+ messages in thread
From: Aaro Koskinen @ 2014-06-18 21:10 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Rob Herring, Ivaylo Dimitrov, Russell King, Sebastian Reichel,
	Will Deacon, linux-kernel, Santosh Shilimkar, Pavel Machek,
	linux-arm-kernel

Hi,

On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote:
> So without this patch DT migration for Nokia N900 cannot be done 
> without breaking userspace - which is not acceptable...

I guess the fact is that the Nokia N900 proprietary userspace has
never worked properly with the mainline kernel without severe patching,
so you cannot really talk about any regression. If you cannot fix
those programs, you could still probably emulate the old Nokia kernel's
/proc/cpuinfo by providing some text file and bind mounting it, no?

A.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 21:10       ` Aaro Koskinen
  0 siblings, 0 replies; 197+ messages in thread
From: Aaro Koskinen @ 2014-06-18 21:10 UTC (permalink / raw)
  To: linux-arm-kernel

Hi,

On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Roh?r wrote:
> So without this patch DT migration for Nokia N900 cannot be done 
> without breaking userspace - which is not acceptable...

I guess the fact is that the Nokia N900 proprietary userspace has
never worked properly with the mainline kernel without severe patching,
so you cannot really talk about any regression. If you cannot fix
those programs, you could still probably emulate the old Nokia kernel's
/proc/cpuinfo by providing some text file and bind mounting it, no?

A.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 20:46       ` Rob Herring
@ 2014-06-18 21:47         ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-06-18 21:47 UTC (permalink / raw)
  To: Rob Herring
  Cc: Pali Rohár, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel

On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > Also I still did not know why DT kernel does not report Revision
> > number which is passed by bootloader via atags. Any idea?
> 
> Probably because no one cared until now and revision info for every
> SOC is different. I would like to see revision info set in the DT in a
> standard way and remove the various SOC specific kernel
> implementations.

Except... that's not what it is.  What that revision field was originally
invented for was the Netwinder to indicate the _platform_ revision.

>From what I've seen, almost everyone else sets this to zero in their
boot loaders - it is /very/ rarely used.  However, I think OMAP (ab)uses
it by putting the SoC revision into it at kernel boot time.  That's
not what it is supposed to be used for.

Others have already solved the problem of exporting SoC specific
information, such as SoC name, SoC revision, etc, if only people would
use it - drivers/base/soc.c.  This gives machine, family, soc_id and
SoC revision information in a standard place - it /might/ have been
a good idea if the creation of that also contained documentation for
what was expected in each of the fields, rather than leaving it
open...

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 21:47         ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-06-18 21:47 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> > Also I still did not know why DT kernel does not report Revision
> > number which is passed by bootloader via atags. Any idea?
> 
> Probably because no one cared until now and revision info for every
> SOC is different. I would like to see revision info set in the DT in a
> standard way and remove the various SOC specific kernel
> implementations.

Except... that's not what it is.  What that revision field was originally
invented for was the Netwinder to indicate the _platform_ revision.

>From what I've seen, almost everyone else sets this to zero in their
boot loaders - it is /very/ rarely used.  However, I think OMAP (ab)uses
it by putting the SoC revision into it at kernel boot time.  That's
not what it is supposed to be used for.

Others have already solved the problem of exporting SoC specific
information, such as SoC name, SoC revision, etc, if only people would
use it - drivers/base/soc.c.  This gives machine, family, soc_id and
SoC revision information in a standard place - it /might/ have been
a good idea if the creation of that also contained documentation for
what was expected in each of the fields, rather than leaving it
open...

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 20:20         ` Pali Rohár
@ 2014-06-18 21:53           ` Fabio Estevam
  -1 siblings, 0 replies; 197+ messages in thread
From: Fabio Estevam @ 2014-06-18 21:53 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King - ARM Linux, Ivaylo Dimitrov, Sebastian Reichel,
	Will Deacon, linux-kernel, Santosh Shilimkar, Pavel Machek,
	linux-arm-kernel

On Wed, Jun 18, 2014 at 5:20 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>
> So how to read Revision and Serial number in DT based kernel?

$ cat /sys/bus/soc/devices/soc0/soc_id
i.MX6SX

$ cat /sys/bus/soc/devices/soc0/revision
1.0

$ cat /sys/bus/soc/devices/soc0/machine
Freescale i.MX6 SoloX SDB Board

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 21:53           ` Fabio Estevam
  0 siblings, 0 replies; 197+ messages in thread
From: Fabio Estevam @ 2014-06-18 21:53 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 18, 2014 at 5:20 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
>
> So how to read Revision and Serial number in DT based kernel?

$ cat /sys/bus/soc/devices/soc0/soc_id
i.MX6SX

$ cat /sys/bus/soc/devices/soc0/revision
1.0

$ cat /sys/bus/soc/devices/soc0/machine
Freescale i.MX6 SoloX SDB Board

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 21:47         ` Russell King - ARM Linux
@ 2014-06-18 22:27           ` Rob Herring
  -1 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-06-18 22:27 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Pali Rohár, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel

On Wed, Jun 18, 2014 at 4:47 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>> > Also I still did not know why DT kernel does not report Revision
>> > number which is passed by bootloader via atags. Any idea?
>>
>> Probably because no one cared until now and revision info for every
>> SOC is different. I would like to see revision info set in the DT in a
>> standard way and remove the various SOC specific kernel
>> implementations.
>
> Except... that's not what it is.  What that revision field was originally
> invented for was the Netwinder to indicate the _platform_ revision.

Okay. DT describes the platform, so having a top-level revision in the
DT could be similar, but...

>
> From what I've seen, almost everyone else sets this to zero in their
> boot loaders - it is /very/ rarely used.  However, I think OMAP (ab)uses
> it by putting the SoC revision into it at kernel boot time.  That's
> not what it is supposed to be used for.

it could suffer the same abuse as the ATAG.

Perhaps if Revision in cpuinfo is never going to be set for DT based
platforms, then we should remove it from cpuinfo in that case.

> Others have already solved the problem of exporting SoC specific
> information, such as SoC name, SoC revision, etc, if only people would
> use it - drivers/base/soc.c.  This gives machine, family, soc_id and
> SoC revision information in a standard place - it /might/ have been
> a good idea if the creation of that also contained documentation for
> what was expected in each of the fields, rather than leaving it
> open...

The problem with soc-device is it is optional and at the whim of the
platform to add. Adding it also causes the the platform devices to
change paths because people make the soc device the bus parent. Sysfs
paths to devices are not considered part of the ABI, but still this is
a silly reason to change the path. If we want soc-device to be used,
then it should always exist and have a default version.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 22:27           ` Rob Herring
  0 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-06-18 22:27 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 18, 2014 at 4:47 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
>> > Also I still did not know why DT kernel does not report Revision
>> > number which is passed by bootloader via atags. Any idea?
>>
>> Probably because no one cared until now and revision info for every
>> SOC is different. I would like to see revision info set in the DT in a
>> standard way and remove the various SOC specific kernel
>> implementations.
>
> Except... that's not what it is.  What that revision field was originally
> invented for was the Netwinder to indicate the _platform_ revision.

Okay. DT describes the platform, so having a top-level revision in the
DT could be similar, but...

>
> From what I've seen, almost everyone else sets this to zero in their
> boot loaders - it is /very/ rarely used.  However, I think OMAP (ab)uses
> it by putting the SoC revision into it at kernel boot time.  That's
> not what it is supposed to be used for.

it could suffer the same abuse as the ATAG.

Perhaps if Revision in cpuinfo is never going to be set for DT based
platforms, then we should remove it from cpuinfo in that case.

> Others have already solved the problem of exporting SoC specific
> information, such as SoC name, SoC revision, etc, if only people would
> use it - drivers/base/soc.c.  This gives machine, family, soc_id and
> SoC revision information in a standard place - it /might/ have been
> a good idea if the creation of that also contained documentation for
> what was expected in each of the fields, rather than leaving it
> open...

The problem with soc-device is it is optional and at the whim of the
platform to add. Adding it also causes the the platform devices to
change paths because people make the soc device the bus parent. Sysfs
paths to devices are not considered part of the ABI, but still this is
a silly reason to change the path. If we want soc-device to be used,
then it should always exist and have a default version.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 22:27           ` Rob Herring
@ 2014-06-18 23:07             ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-06-18 23:07 UTC (permalink / raw)
  To: Rob Herring
  Cc: Pali Rohár, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel

On Wed, Jun 18, 2014 at 05:27:16PM -0500, Rob Herring wrote:
> On Wed, Jun 18, 2014 at 4:47 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> >> > Also I still did not know why DT kernel does not report Revision
> >> > number which is passed by bootloader via atags. Any idea?
> >>
> >> Probably because no one cared until now and revision info for every
> >> SOC is different. I would like to see revision info set in the DT in a
> >> standard way and remove the various SOC specific kernel
> >> implementations.
> >
> > Except... that's not what it is.  What that revision field was originally
> > invented for was the Netwinder to indicate the _platform_ revision.
> 
> Okay. DT describes the platform, so having a top-level revision in the
> DT could be similar, but...
> 
> >
> > From what I've seen, almost everyone else sets this to zero in their
> > boot loaders - it is /very/ rarely used.  However, I think OMAP (ab)uses
> > it by putting the SoC revision into it at kernel boot time.  That's
> > not what it is supposed to be used for.
> 
> it could suffer the same abuse as the ATAG.

I think the (ab)use I mentioned above has been eliminated (it was
being used for the SoC revision).  It's worth grepping for system_rev
to find where it's used now, and it's looks like it's all platform
level.

> The problem with soc-device is it is optional and at the whim of the
> platform to add. Adding it also causes the the platform devices to
> change paths because people make the soc device the bus parent.

It's got to be optional, but anyone with a SoC should be strongly
encouraged to use it, especially when converting to DT - again, this
is probably one of those numerous "missed opportunities" since the
DT conversion fundamentally changes the names of all platform
devices in that heirarchy.

I'm tempted to say that we went through that device name change,
and as far as I saw, there was not one complaint about those devices
changing names.  So, I suspect it isn't that big a deal to encourage
SoCs to make use of this.

> Sysfs
> paths to devices are not considered part of the ABI, but still this is
> a silly reason to change the path. If we want soc-device to be used,
> then it should always exist and have a default version.

So what do we do on systems which aren't a SoC?  Make up some random
information for the SoC stuff?  That's just wrong.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-18 23:07             ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-06-18 23:07 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jun 18, 2014 at 05:27:16PM -0500, Rob Herring wrote:
> On Wed, Jun 18, 2014 at 4:47 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Wed, Jun 18, 2014 at 03:46:19PM -0500, Rob Herring wrote:
> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> >> > Also I still did not know why DT kernel does not report Revision
> >> > number which is passed by bootloader via atags. Any idea?
> >>
> >> Probably because no one cared until now and revision info for every
> >> SOC is different. I would like to see revision info set in the DT in a
> >> standard way and remove the various SOC specific kernel
> >> implementations.
> >
> > Except... that's not what it is.  What that revision field was originally
> > invented for was the Netwinder to indicate the _platform_ revision.
> 
> Okay. DT describes the platform, so having a top-level revision in the
> DT could be similar, but...
> 
> >
> > From what I've seen, almost everyone else sets this to zero in their
> > boot loaders - it is /very/ rarely used.  However, I think OMAP (ab)uses
> > it by putting the SoC revision into it at kernel boot time.  That's
> > not what it is supposed to be used for.
> 
> it could suffer the same abuse as the ATAG.

I think the (ab)use I mentioned above has been eliminated (it was
being used for the SoC revision).  It's worth grepping for system_rev
to find where it's used now, and it's looks like it's all platform
level.

> The problem with soc-device is it is optional and at the whim of the
> platform to add. Adding it also causes the the platform devices to
> change paths because people make the soc device the bus parent.

It's got to be optional, but anyone with a SoC should be strongly
encouraged to use it, especially when converting to DT - again, this
is probably one of those numerous "missed opportunities" since the
DT conversion fundamentally changes the names of all platform
devices in that heirarchy.

I'm tempted to say that we went through that device name change,
and as far as I saw, there was not one complaint about those devices
changing names.  So, I suspect it isn't that big a deal to encourage
SoCs to make use of this.

> Sysfs
> paths to devices are not considered part of the ABI, but still this is
> a silly reason to change the path. If we want soc-device to be used,
> then it should always exist and have a default version.

So what do we do on systems which aren't a SoC?  Make up some random
information for the SoC stuff?  That's just wrong.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 19:59       ` Russell King - ARM Linux
@ 2014-06-19  8:21         ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2014-06-19  8:21 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Pali Roh?r, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, linux-arm-kernel, linux-kernel

On Wed 2014-06-18 20:59:08, Russell King - ARM Linux wrote:
> On Wed, Jun 18, 2014 at 09:09:58PM +0200, Pali Rohár wrote:
> > On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux 
> > wrote:
> > > On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Rohár wrote:
> > > > Machine name from board description is some generic name on
> > > > DT kernel. DT provides machine name property which is
> > > > specific for board, so use it instead generic one when
> > > > possible.
> > > 
> > > http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> > > .53d47576.en.html
> > > 
> > > "If userspace wants to get at the DT information about a
> > > platform, we already have ways that can happen already - we
> > > export the DT stuff so that kexec's tools can get at it."
> > 
> > Userspace application does not know that kernel using DT. And 
> > also it does not want to get DT information. Only board/machine 
> > name. So existing applications stop working after migration to 
> > DT. And because legacy board boot code (without DT) is going to 
> > be removed for ARM in near future this will permanently break 
> > existing applications.
> 
> We're already breaking the userspace API through moving to DT, because
> all the device names in /sys/devices are changing.  Userspace is going
> to have to cope with change as we move towards DT.  This is just
> another aspect of moving towards DT, and one which userspace is going
> to have to deal with.
> 
> > And sometimes it is even not possible to fix userspace 
> > application if is closed source - binary only.
> 
> And why do we care about closed source?

"No regressions". Recent DT changes broke userspace we care about. Now you can either
revert DT changes, or fix the code to be compatible-enough. Second option is better, I guess.

> If we listened to this argument, then we wouldn't ever be able to
> change anything in procfs or sysfs.

If we find procfs/sysfs changes that break userspace, we revert them. Its 
that simple.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-06-19  8:21         ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2014-06-19  8:21 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed 2014-06-18 20:59:08, Russell King - ARM Linux wrote:
> On Wed, Jun 18, 2014 at 09:09:58PM +0200, Pali Roh?r wrote:
> > On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux 
> > wrote:
> > > On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r wrote:
> > > > Machine name from board description is some generic name on
> > > > DT kernel. DT provides machine name property which is
> > > > specific for board, so use it instead generic one when
> > > > possible.
> > > 
> > > http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> > > .53d47576.en.html
> > > 
> > > "If userspace wants to get at the DT information about a
> > > platform, we already have ways that can happen already - we
> > > export the DT stuff so that kexec's tools can get at it."
> > 
> > Userspace application does not know that kernel using DT. And 
> > also it does not want to get DT information. Only board/machine 
> > name. So existing applications stop working after migration to 
> > DT. And because legacy board boot code (without DT) is going to 
> > be removed for ARM in near future this will permanently break 
> > existing applications.
> 
> We're already breaking the userspace API through moving to DT, because
> all the device names in /sys/devices are changing.  Userspace is going
> to have to cope with change as we move towards DT.  This is just
> another aspect of moving towards DT, and one which userspace is going
> to have to deal with.
> 
> > And sometimes it is even not possible to fix userspace 
> > application if is closed source - binary only.
> 
> And why do we care about closed source?

"No regressions". Recent DT changes broke userspace we care about. Now you can either
revert DT changes, or fix the code to be compatible-enough. Second option is better, I guess.

> If we listened to this argument, then we wouldn't ever be able to
> change anything in procfs or sysfs.

If we find procfs/sysfs changes that break userspace, we revert them. Its 
that simple.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 21:10       ` Aaro Koskinen
@ 2014-07-11 19:28         ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2014-07-11 19:28 UTC (permalink / raw)
  To: Aaro Koskinen
  Cc: Pali Rohár, Rob Herring, Ivaylo Dimitrov, Russell King,
	Sebastian Reichel, Will Deacon, linux-kernel, Santosh Shilimkar,
	linux-arm-kernel

On Thu 2014-06-19 00:10:39, Aaro Koskinen wrote:
> Hi,
> 
> On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote:
> > So without this patch DT migration for Nokia N900 cannot be done 
> > without breaking userspace - which is not acceptable...
> 
> I guess the fact is that the Nokia N900 proprietary userspace has
> never worked properly with the mainline kernel without severe patching,
> so you cannot really talk about any regression. If you cannot fix
> those programs, you could still probably emulate the old Nokia kernel's
> /proc/cpuinfo by providing some text file and bind mounting it, no?

Actually, yes, it worked pretty well with some close-to-mainline
kernels.

And bind-mount on /proc/cpuinfo is beyond ugly, don't you think?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-07-11 19:28         ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2014-07-11 19:28 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu 2014-06-19 00:10:39, Aaro Koskinen wrote:
> Hi,
> 
> On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Roh?r wrote:
> > So without this patch DT migration for Nokia N900 cannot be done 
> > without breaking userspace - which is not acceptable...
> 
> I guess the fact is that the Nokia N900 proprietary userspace has
> never worked properly with the mainline kernel without severe patching,
> so you cannot really talk about any regression. If you cannot fix
> those programs, you could still probably emulate the old Nokia kernel's
> /proc/cpuinfo by providing some text file and bind mounting it, no?

Actually, yes, it worked pretty well with some close-to-mainline
kernels.

And bind-mount on /proc/cpuinfo is beyond ugly, don't you think?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 19:59       ` Russell King - ARM Linux
@ 2014-07-11 19:31         ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2014-07-11 19:31 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Pali Rohár, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, linux-arm-kernel, linux-kernel

On Wed 2014-06-18 20:59:08, Russell King - ARM Linux wrote:
> On Wed, Jun 18, 2014 at 09:09:58PM +0200, Pali Rohár wrote:
> > On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux 
> > wrote:
> > > On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Rohár wrote:
> > > > Machine name from board description is some generic name on
> > > > DT kernel. DT provides machine name property which is
> > > > specific for board, so use it instead generic one when
> > > > possible.
> > > 
> > > http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> > > .53d47576.en.html
> > > 
> > > "If userspace wants to get at the DT information about a
> > > platform, we already have ways that can happen already - we
> > > export the DT stuff so that kexec's tools can get at it."
> > 
> > Userspace application does not know that kernel using DT. And 
> > also it does not want to get DT information. Only board/machine 
> > name. So existing applications stop working after migration to 
> > DT. And because legacy board boot code (without DT) is going to 
> > be removed for ARM in near future this will permanently break 
> > existing applications.
> 
> We're already breaking the userspace API through moving to DT, because
> all the device names in /sys/devices are changing.  Userspace is going
> to have to cope with change as we move towards DT.  This is just
> another aspect of moving towards DT, and one which userspace is going
> to have to deal with.

You don't _have_ to break /proc/cpuinfo.  No, "DT breaks stuff" should
not be reason to "break more stuff".  (Actually, I'm not aware of
anything DT would have to break.)

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-07-11 19:31         ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2014-07-11 19:31 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed 2014-06-18 20:59:08, Russell King - ARM Linux wrote:
> On Wed, Jun 18, 2014 at 09:09:58PM +0200, Pali Roh?r wrote:
> > On Wednesday 18 June 2014 21:01:09 Russell King - ARM Linux 
> > wrote:
> > > On Wed, Jun 18, 2014 at 06:54:24PM +0200, Pali Roh?r wrote:
> > > > Machine name from board description is some generic name on
> > > > DT kernel. DT provides machine name property which is
> > > > specific for board, so use it instead generic one when
> > > > possible.
> > > 
> > > http://archive.arm.linux.org.uk/lurker/message/20130726.132850
> > > .53d47576.en.html
> > > 
> > > "If userspace wants to get at the DT information about a
> > > platform, we already have ways that can happen already - we
> > > export the DT stuff so that kexec's tools can get at it."
> > 
> > Userspace application does not know that kernel using DT. And 
> > also it does not want to get DT information. Only board/machine 
> > name. So existing applications stop working after migration to 
> > DT. And because legacy board boot code (without DT) is going to 
> > be removed for ARM in near future this will permanently break 
> > existing applications.
> 
> We're already breaking the userspace API through moving to DT, because
> all the device names in /sys/devices are changing.  Userspace is going
> to have to cope with change as we move towards DT.  This is just
> another aspect of moving towards DT, and one which userspace is going
> to have to deal with.

You don't _have_ to break /proc/cpuinfo.  No, "DT breaks stuff" should
not be reason to "break more stuff".  (Actually, I'm not aware of
anything DT would have to break.)

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 16:54 ` Pali Rohár
@ 2014-09-05 11:38   ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-09-05 11:38 UTC (permalink / raw)
  To: Russell King
  Cc: Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-arm-kernel, linux-kernel,
	Rob Herring, Fabio Estevam, Aaro Koskinen

[-- Attachment #1: Type: Text/Plain, Size: 1330 bytes --]

On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote:
> Machine name from board description is some generic name on DT
> kernel. DT provides machine name property which is specific
> for board, so use it instead generic one when possible.
> 
> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> ---
>  arch/arm/kernel/setup.c |    7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 8a16ee5..fbc7b4f 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p)
> 
>  	setup_processor();
>  	mdesc = setup_machine_fdt(__atags_pointer);
> -	if (!mdesc)
> +	if (mdesc)
> +		machine_name = of_flat_dt_get_machine_name();
> +	else
>  		mdesc = setup_machine_tags(__atags_pointer,
> __machine_arch_type); machine_desc = mdesc;
> -	machine_name = mdesc->name;
> +	if (!machine_name)
> +		machine_name = mdesc->name;
> 
>  	if (mdesc->reboot_mode != REBOOT_HARD)
>  		reboot_mode = mdesc->reboot_mode;

So, do you really want to break userspace which reading file 
/proc/cpuinfo (after migration from boardcode --> DT)?

I still do not see reason for that. And only this one file is 
problematic...

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-09-05 11:38   ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-09-05 11:38 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
> Machine name from board description is some generic name on DT
> kernel. DT provides machine name property which is specific
> for board, so use it instead generic one when possible.
> 
> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> ---
>  arch/arm/kernel/setup.c |    7 +++++--
>  1 file changed, 5 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 8a16ee5..fbc7b4f 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p)
> 
>  	setup_processor();
>  	mdesc = setup_machine_fdt(__atags_pointer);
> -	if (!mdesc)
> +	if (mdesc)
> +		machine_name = of_flat_dt_get_machine_name();
> +	else
>  		mdesc = setup_machine_tags(__atags_pointer,
> __machine_arch_type); machine_desc = mdesc;
> -	machine_name = mdesc->name;
> +	if (!machine_name)
> +		machine_name = mdesc->name;
> 
>  	if (mdesc->reboot_mode != REBOOT_HARD)
>  		reboot_mode = mdesc->reboot_mode;

So, do you really want to break userspace which reading file 
/proc/cpuinfo (after migration from boardcode --> DT)?

I still do not see reason for that. And only this one file is 
problematic...

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140905/db8b702e/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-09-05 11:38   ` Pali Rohár
@ 2014-09-05 12:13     ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-09-05 12:13 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-arm-kernel, linux-kernel,
	Rob Herring, Fabio Estevam, Aaro Koskinen

On Fri, Sep 05, 2014 at 01:38:40PM +0200, Pali Rohár wrote:
> On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote:
> > Machine name from board description is some generic name on DT
> > kernel. DT provides machine name property which is specific
> > for board, so use it instead generic one when possible.
> > 
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> >  arch/arm/kernel/setup.c |    7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 8a16ee5..fbc7b4f 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p)
> > 
> >  	setup_processor();
> >  	mdesc = setup_machine_fdt(__atags_pointer);
> > -	if (!mdesc)
> > +	if (mdesc)
> > +		machine_name = of_flat_dt_get_machine_name();
> > +	else
> >  		mdesc = setup_machine_tags(__atags_pointer,
> > __machine_arch_type); machine_desc = mdesc;
> > -	machine_name = mdesc->name;
> > +	if (!machine_name)
> > +		machine_name = mdesc->name;
> > 
> >  	if (mdesc->reboot_mode != REBOOT_HARD)
> >  		reboot_mode = mdesc->reboot_mode;
> 
> So, do you really want to break userspace which reading file 
> /proc/cpuinfo (after migration from boardcode --> DT)?
> 
> I still do not see reason for that. And only this one file is 
> problematic...

Sorry, I just don't give a damn about your whinging about this.  I've
made the situation perfectly clear.  Your patch will not be accepted.

Thanks.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-09-05 12:13     ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-09-05 12:13 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Sep 05, 2014 at 01:38:40PM +0200, Pali Roh?r wrote:
> On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
> > Machine name from board description is some generic name on DT
> > kernel. DT provides machine name property which is specific
> > for board, so use it instead generic one when possible.
> > 
> > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > ---
> >  arch/arm/kernel/setup.c |    7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 8a16ee5..fbc7b4f 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p)
> > 
> >  	setup_processor();
> >  	mdesc = setup_machine_fdt(__atags_pointer);
> > -	if (!mdesc)
> > +	if (mdesc)
> > +		machine_name = of_flat_dt_get_machine_name();
> > +	else
> >  		mdesc = setup_machine_tags(__atags_pointer,
> > __machine_arch_type); machine_desc = mdesc;
> > -	machine_name = mdesc->name;
> > +	if (!machine_name)
> > +		machine_name = mdesc->name;
> > 
> >  	if (mdesc->reboot_mode != REBOOT_HARD)
> >  		reboot_mode = mdesc->reboot_mode;
> 
> So, do you really want to break userspace which reading file 
> /proc/cpuinfo (after migration from boardcode --> DT)?
> 
> I still do not see reason for that. And only this one file is 
> problematic...

Sorry, I just don't give a damn about your whinging about this.  I've
made the situation perfectly clear.  Your patch will not be accepted.

Thanks.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-09-05 11:38   ` Pali Rohár
@ 2014-09-05 13:45     ` Mark Rutland
  -1 siblings, 0 replies; 197+ messages in thread
From: Mark Rutland @ 2014-09-05 13:45 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King, Ivaylo Dimitrov, Aaro Koskinen, Sebastian Reichel,
	Will Deacon, linux-kernel, Santosh Shilimkar, Pavel Machek,
	Fabio Estevam, linux-arm-kernel

On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Rohár wrote:
> On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote:
> > Machine name from board description is some generic name on DT
> > kernel. DT provides machine name property which is specific
> > for board, so use it instead generic one when possible.
> > 
> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > ---
> >  arch/arm/kernel/setup.c |    7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 8a16ee5..fbc7b4f 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p)
> > 
> >  	setup_processor();
> >  	mdesc = setup_machine_fdt(__atags_pointer);
> > -	if (!mdesc)
> > +	if (mdesc)
> > +		machine_name = of_flat_dt_get_machine_name();
> > +	else
> >  		mdesc = setup_machine_tags(__atags_pointer,
> > __machine_arch_type); machine_desc = mdesc;
> > -	machine_name = mdesc->name;
> > +	if (!machine_name)
> > +		machine_name = mdesc->name;
> > 
> >  	if (mdesc->reboot_mode != REBOOT_HARD)
> >  		reboot_mode = mdesc->reboot_mode;
> 
> So, do you really want to break userspace which reading file 
> /proc/cpuinfo (after migration from boardcode --> DT)?

You have no guarantee model name in the DT == the name in a board file
anyhow, and trying to force that is wrong. So further to Russell's
reply, I must NAK this from a DT perspective.

Realistically your userspace is already broken if relying on such
things. You built something that only ever worked for a particular
arbitrary string. So it was already broken for every other board, and
there was never any guarantee that new boards where your userspace could
have worked would share the same name.

You're trying to fix the wrong side of the equation.

Mark.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-09-05 13:45     ` Mark Rutland
  0 siblings, 0 replies; 197+ messages in thread
From: Mark Rutland @ 2014-09-05 13:45 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Roh?r wrote:
> On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
> > Machine name from board description is some generic name on DT
> > kernel. DT provides machine name property which is specific
> > for board, so use it instead generic one when possible.
> > 
> > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > ---
> >  arch/arm/kernel/setup.c |    7 +++++--
> >  1 file changed, 5 insertions(+), 2 deletions(-)
> > 
> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> > index 8a16ee5..fbc7b4f 100644
> > --- a/arch/arm/kernel/setup.c
> > +++ b/arch/arm/kernel/setup.c
> > @@ -875,10 +875,13 @@ void __init setup_arch(char **cmdline_p)
> > 
> >  	setup_processor();
> >  	mdesc = setup_machine_fdt(__atags_pointer);
> > -	if (!mdesc)
> > +	if (mdesc)
> > +		machine_name = of_flat_dt_get_machine_name();
> > +	else
> >  		mdesc = setup_machine_tags(__atags_pointer,
> > __machine_arch_type); machine_desc = mdesc;
> > -	machine_name = mdesc->name;
> > +	if (!machine_name)
> > +		machine_name = mdesc->name;
> > 
> >  	if (mdesc->reboot_mode != REBOOT_HARD)
> >  		reboot_mode = mdesc->reboot_mode;
> 
> So, do you really want to break userspace which reading file 
> /proc/cpuinfo (after migration from boardcode --> DT)?

You have no guarantee model name in the DT == the name in a board file
anyhow, and trying to force that is wrong. So further to Russell's
reply, I must NAK this from a DT perspective.

Realistically your userspace is already broken if relying on such
things. You built something that only ever worked for a particular
arbitrary string. So it was already broken for every other board, and
there was never any guarantee that new boards where your userspace could
have worked would share the same name.

You're trying to fix the wrong side of the equation.

Mark.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-09-05 13:45     ` Mark Rutland
@ 2014-09-05 13:52       ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-09-05 13:52 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Russell King, Ivaylo Dimitrov, Aaro Koskinen, Sebastian Reichel,
	Will Deacon, linux-kernel, Santosh Shilimkar, Pavel Machek,
	Fabio Estevam, linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 2314 bytes --]

On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
> On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Rohár wrote:
> > On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote:
> > > Machine name from board description is some generic name
> > > on DT kernel. DT provides machine name property which is
> > > specific for board, so use it instead generic one when
> > > possible.
> > > 
> > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > ---
> > > 
> > >  arch/arm/kernel/setup.c |    7 +++++--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm/kernel/setup.c
> > > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> > > --- a/arch/arm/kernel/setup.c
> > > +++ b/arch/arm/kernel/setup.c
> > > @@ -875,10 +875,13 @@ void __init setup_arch(char
> > > **cmdline_p)
> > > 
> > >  	setup_processor();
> > >  	mdesc = setup_machine_fdt(__atags_pointer);
> > > 
> > > -	if (!mdesc)
> > > +	if (mdesc)
> > > +		machine_name = of_flat_dt_get_machine_name();
> > > +	else
> > > 
> > >  		mdesc = setup_machine_tags(__atags_pointer,
> > > 
> > > __machine_arch_type); machine_desc = mdesc;
> > > -	machine_name = mdesc->name;
> > > +	if (!machine_name)
> > > +		machine_name = mdesc->name;
> > > 
> > >  	if (mdesc->reboot_mode != REBOOT_HARD)
> > >  	
> > >  		reboot_mode = mdesc->reboot_mode;
> > 
> > So, do you really want to break userspace which reading file
> > /proc/cpuinfo (after migration from boardcode --> DT)?
> 
> You have no guarantee model name in the DT == the name in a
> board file anyhow, and trying to force that is wrong. So
> further to Russell's reply, I must NAK this from a DT
> perspective.
> 
> Realistically your userspace is already broken if relying on
> such things. You built something that only ever worked for a
> particular arbitrary string. So it was already broken for
> every other board, and there was never any guarantee that new
> boards where your userspace could have worked would share the
> same name.
> 
> You're trying to fix the wrong side of the equation.
> 
> Mark.

So what is your suggestion for identifing board (name/type) which 
will work with any kernel (and will not be broken again by kernel 
later)?

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-09-05 13:52       ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-09-05 13:52 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
> On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Roh?r wrote:
> > On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
> > > Machine name from board description is some generic name
> > > on DT kernel. DT provides machine name property which is
> > > specific for board, so use it instead generic one when
> > > possible.
> > > 
> > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > ---
> > > 
> > >  arch/arm/kernel/setup.c |    7 +++++--
> > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/arch/arm/kernel/setup.c
> > > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> > > --- a/arch/arm/kernel/setup.c
> > > +++ b/arch/arm/kernel/setup.c
> > > @@ -875,10 +875,13 @@ void __init setup_arch(char
> > > **cmdline_p)
> > > 
> > >  	setup_processor();
> > >  	mdesc = setup_machine_fdt(__atags_pointer);
> > > 
> > > -	if (!mdesc)
> > > +	if (mdesc)
> > > +		machine_name = of_flat_dt_get_machine_name();
> > > +	else
> > > 
> > >  		mdesc = setup_machine_tags(__atags_pointer,
> > > 
> > > __machine_arch_type); machine_desc = mdesc;
> > > -	machine_name = mdesc->name;
> > > +	if (!machine_name)
> > > +		machine_name = mdesc->name;
> > > 
> > >  	if (mdesc->reboot_mode != REBOOT_HARD)
> > >  	
> > >  		reboot_mode = mdesc->reboot_mode;
> > 
> > So, do you really want to break userspace which reading file
> > /proc/cpuinfo (after migration from boardcode --> DT)?
> 
> You have no guarantee model name in the DT == the name in a
> board file anyhow, and trying to force that is wrong. So
> further to Russell's reply, I must NAK this from a DT
> perspective.
> 
> Realistically your userspace is already broken if relying on
> such things. You built something that only ever worked for a
> particular arbitrary string. So it was already broken for
> every other board, and there was never any guarantee that new
> boards where your userspace could have worked would share the
> same name.
> 
> You're trying to fix the wrong side of the equation.
> 
> Mark.

So what is your suggestion for identifing board (name/type) which 
will work with any kernel (and will not be broken again by kernel 
later)?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140905/6e3c7aea/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-09-05 13:52       ` Pali Rohár
@ 2014-09-05 13:58         ` Mark Rutland
  -1 siblings, 0 replies; 197+ messages in thread
From: Mark Rutland @ 2014-09-05 13:58 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King, Ivaylo Dimitrov, Aaro Koskinen, Sebastian Reichel,
	Will Deacon, linux-kernel, Santosh Shilimkar, Pavel Machek,
	Fabio Estevam, linux-arm-kernel

On Fri, Sep 05, 2014 at 02:52:05PM +0100, Pali Rohár wrote:
> On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
> > On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Rohár wrote:
> > > On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote:
> > > > Machine name from board description is some generic name
> > > > on DT kernel. DT provides machine name property which is
> > > > specific for board, so use it instead generic one when
> > > > possible.
> > > > 
> > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > ---
> > > > 
> > > >  arch/arm/kernel/setup.c |    7 +++++--
> > > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/kernel/setup.c
> > > > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> > > > --- a/arch/arm/kernel/setup.c
> > > > +++ b/arch/arm/kernel/setup.c
> > > > @@ -875,10 +875,13 @@ void __init setup_arch(char
> > > > **cmdline_p)
> > > > 
> > > >  	setup_processor();
> > > >  	mdesc = setup_machine_fdt(__atags_pointer);
> > > > 
> > > > -	if (!mdesc)
> > > > +	if (mdesc)
> > > > +		machine_name = of_flat_dt_get_machine_name();
> > > > +	else
> > > > 
> > > >  		mdesc = setup_machine_tags(__atags_pointer,
> > > > 
> > > > __machine_arch_type); machine_desc = mdesc;
> > > > -	machine_name = mdesc->name;
> > > > +	if (!machine_name)
> > > > +		machine_name = mdesc->name;
> > > > 
> > > >  	if (mdesc->reboot_mode != REBOOT_HARD)
> > > >  	
> > > >  		reboot_mode = mdesc->reboot_mode;
> > > 
> > > So, do you really want to break userspace which reading file
> > > /proc/cpuinfo (after migration from boardcode --> DT)?
> > 
> > You have no guarantee model name in the DT == the name in a
> > board file anyhow, and trying to force that is wrong. So
> > further to Russell's reply, I must NAK this from a DT
> > perspective.
> > 
> > Realistically your userspace is already broken if relying on
> > such things. You built something that only ever worked for a
> > particular arbitrary string. So it was already broken for
> > every other board, and there was never any guarantee that new
> > boards where your userspace could have worked would share the
> > same name.
> > 
> > You're trying to fix the wrong side of the equation.
> > 
> > Mark.
> 
> So what is your suggestion for identifing board (name/type) which 
> will work with any kernel (and will not be broken again by kernel 
> later)?

Without knowing your use case I have no idea if that's even a sane thing
to do.

Mark.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-09-05 13:58         ` Mark Rutland
  0 siblings, 0 replies; 197+ messages in thread
From: Mark Rutland @ 2014-09-05 13:58 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Sep 05, 2014 at 02:52:05PM +0100, Pali Roh?r wrote:
> On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
> > On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Roh?r wrote:
> > > On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
> > > > Machine name from board description is some generic name
> > > > on DT kernel. DT provides machine name property which is
> > > > specific for board, so use it instead generic one when
> > > > possible.
> > > > 
> > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > > ---
> > > > 
> > > >  arch/arm/kernel/setup.c |    7 +++++--
> > > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/arch/arm/kernel/setup.c
> > > > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> > > > --- a/arch/arm/kernel/setup.c
> > > > +++ b/arch/arm/kernel/setup.c
> > > > @@ -875,10 +875,13 @@ void __init setup_arch(char
> > > > **cmdline_p)
> > > > 
> > > >  	setup_processor();
> > > >  	mdesc = setup_machine_fdt(__atags_pointer);
> > > > 
> > > > -	if (!mdesc)
> > > > +	if (mdesc)
> > > > +		machine_name = of_flat_dt_get_machine_name();
> > > > +	else
> > > > 
> > > >  		mdesc = setup_machine_tags(__atags_pointer,
> > > > 
> > > > __machine_arch_type); machine_desc = mdesc;
> > > > -	machine_name = mdesc->name;
> > > > +	if (!machine_name)
> > > > +		machine_name = mdesc->name;
> > > > 
> > > >  	if (mdesc->reboot_mode != REBOOT_HARD)
> > > >  	
> > > >  		reboot_mode = mdesc->reboot_mode;
> > > 
> > > So, do you really want to break userspace which reading file
> > > /proc/cpuinfo (after migration from boardcode --> DT)?
> > 
> > You have no guarantee model name in the DT == the name in a
> > board file anyhow, and trying to force that is wrong. So
> > further to Russell's reply, I must NAK this from a DT
> > perspective.
> > 
> > Realistically your userspace is already broken if relying on
> > such things. You built something that only ever worked for a
> > particular arbitrary string. So it was already broken for
> > every other board, and there was never any guarantee that new
> > boards where your userspace could have worked would share the
> > same name.
> > 
> > You're trying to fix the wrong side of the equation.
> > 
> > Mark.
> 
> So what is your suggestion for identifing board (name/type) which 
> will work with any kernel (and will not be broken again by kernel 
> later)?

Without knowing your use case I have no idea if that's even a sane thing
to do.

Mark.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-09-05 13:52       ` Pali Rohár
@ 2014-09-05 13:58         ` Fabio Estevam
  -1 siblings, 0 replies; 197+ messages in thread
From: Fabio Estevam @ 2014-09-05 13:58 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Mark Rutland, Russell King, Ivaylo Dimitrov, Aaro Koskinen,
	Sebastian Reichel, Will Deacon, linux-kernel, Santosh Shilimkar,
	Pavel Machek, linux-arm-kernel

On Fri, Sep 5, 2014 at 10:52 AM, Pali Rohár <pali.rohar@gmail.com> wrote:

> So what is your suggestion for identifing board (name/type) which
> will work with any kernel (and will not be broken again by kernel
> later)?

$ cat /sys/bus/soc/devices/soc0/machine
Freescale i.MX6 Quad SABRE Smart Device Board

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-09-05 13:58         ` Fabio Estevam
  0 siblings, 0 replies; 197+ messages in thread
From: Fabio Estevam @ 2014-09-05 13:58 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri, Sep 5, 2014 at 10:52 AM, Pali Roh?r <pali.rohar@gmail.com> wrote:

> So what is your suggestion for identifing board (name/type) which
> will work with any kernel (and will not be broken again by kernel
> later)?

$ cat /sys/bus/soc/devices/soc0/machine
Freescale i.MX6 Quad SABRE Smart Device Board

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-09-05 13:52       ` Pali Rohár
@ 2014-09-06 15:34         ` Andreas Färber
  -1 siblings, 0 replies; 197+ messages in thread
From: Andreas Färber @ 2014-09-06 15:34 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Mark Rutland, Ivaylo Dimitrov, Russell King, Aaro Koskinen,
	Sebastian Reichel, Will Deacon, linux-kernel, Santosh Shilimkar,
	Pavel Machek, Fabio Estevam, linux-arm-kernel

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

Am 05.09.2014 15:52, schrieb Pali Rohár:
> On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
>> On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Rohár wrote:
>>> On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote:
>>>> Machine name from board description is some generic name
>>>> on DT kernel. DT provides machine name property which is
>>>> specific for board, so use it instead generic one when
>>>> possible.
>>>>
>>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
>>>> ---
>>>>
>>>>  arch/arm/kernel/setup.c |    7 +++++--
>>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm/kernel/setup.c
>>>> b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
>>>> --- a/arch/arm/kernel/setup.c
>>>> +++ b/arch/arm/kernel/setup.c
>>>> @@ -875,10 +875,13 @@ void __init setup_arch(char
>>>> **cmdline_p)
>>>>
>>>>  	setup_processor();
>>>>  	mdesc = setup_machine_fdt(__atags_pointer);
>>>>
>>>> -	if (!mdesc)
>>>> +	if (mdesc)
>>>> +		machine_name = of_flat_dt_get_machine_name();
>>>> +	else
>>>>
>>>>  		mdesc = setup_machine_tags(__atags_pointer,
>>>>
>>>> __machine_arch_type); machine_desc = mdesc;
>>>> -	machine_name = mdesc->name;
>>>> +	if (!machine_name)
>>>> +		machine_name = mdesc->name;
>>>>
>>>>  	if (mdesc->reboot_mode != REBOOT_HARD)
>>>>  	
>>>>  		reboot_mode = mdesc->reboot_mode;
>>>
>>> So, do you really want to break userspace which reading file
>>> /proc/cpuinfo (after migration from boardcode --> DT)?
>>
>> You have no guarantee model name in the DT == the name in a
>> board file anyhow, and trying to force that is wrong. So
>> further to Russell's reply, I must NAK this from a DT
>> perspective.
>>
>> Realistically your userspace is already broken if relying on
>> such things. You built something that only ever worked for a
>> particular arbitrary string. So it was already broken for
>> every other board, and there was never any guarantee that new
>> boards where your userspace could have worked would share the
>> same name.
>>
>> You're trying to fix the wrong side of the equation.
> 
> So what is your suggestion for identifing board (name/type) which 
> will work with any kernel (and will not be broken again by kernel 
> later)?

/proc/device-tree/compatible should give you a nul-separated list of
compatible strings for the machine. Ideally they're even documented
under Documentation/devicetree/bindings/arm/.

But as Mark said, depending on what you are actually trying to
distinguish in userspace, there may be better ways.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer; HRB 16746 AG Nürnberg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-09-06 15:34         ` Andreas Färber
  0 siblings, 0 replies; 197+ messages in thread
From: Andreas Färber @ 2014-09-06 15:34 UTC (permalink / raw)
  To: linux-arm-kernel

Am 05.09.2014 15:52, schrieb Pali Roh?r:
> On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
>> On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Roh?r wrote:
>>> On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
>>>> Machine name from board description is some generic name
>>>> on DT kernel. DT provides machine name property which is
>>>> specific for board, so use it instead generic one when
>>>> possible.
>>>>
>>>> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
>>>> ---
>>>>
>>>>  arch/arm/kernel/setup.c |    7 +++++--
>>>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/arch/arm/kernel/setup.c
>>>> b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
>>>> --- a/arch/arm/kernel/setup.c
>>>> +++ b/arch/arm/kernel/setup.c
>>>> @@ -875,10 +875,13 @@ void __init setup_arch(char
>>>> **cmdline_p)
>>>>
>>>>  	setup_processor();
>>>>  	mdesc = setup_machine_fdt(__atags_pointer);
>>>>
>>>> -	if (!mdesc)
>>>> +	if (mdesc)
>>>> +		machine_name = of_flat_dt_get_machine_name();
>>>> +	else
>>>>
>>>>  		mdesc = setup_machine_tags(__atags_pointer,
>>>>
>>>> __machine_arch_type); machine_desc = mdesc;
>>>> -	machine_name = mdesc->name;
>>>> +	if (!machine_name)
>>>> +		machine_name = mdesc->name;
>>>>
>>>>  	if (mdesc->reboot_mode != REBOOT_HARD)
>>>>  	
>>>>  		reboot_mode = mdesc->reboot_mode;
>>>
>>> So, do you really want to break userspace which reading file
>>> /proc/cpuinfo (after migration from boardcode --> DT)?
>>
>> You have no guarantee model name in the DT == the name in a
>> board file anyhow, and trying to force that is wrong. So
>> further to Russell's reply, I must NAK this from a DT
>> perspective.
>>
>> Realistically your userspace is already broken if relying on
>> such things. You built something that only ever worked for a
>> particular arbitrary string. So it was already broken for
>> every other board, and there was never any guarantee that new
>> boards where your userspace could have worked would share the
>> same name.
>>
>> You're trying to fix the wrong side of the equation.
> 
> So what is your suggestion for identifing board (name/type) which 
> will work with any kernel (and will not be broken again by kernel 
> later)?

/proc/device-tree/compatible should give you a nul-separated list of
compatible strings for the machine. Ideally they're even documented
under Documentation/devicetree/bindings/arm/.

But as Mark said, depending on what you are actually trying to
distinguish in userspace, there may be better ways.

Regards,
Andreas

-- 
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140906/61e3eb45/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-09-05 12:13     ` Russell King - ARM Linux
@ 2014-09-10 12:46       ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2014-09-10 12:46 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Pali Roh?r, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, linux-arm-kernel, linux-kernel, Rob Herring,
	Fabio Estevam, Aaro Koskinen

On Fri 2014-09-05 13:13:16, Russell King - ARM Linux wrote:
> On Fri, Sep 05, 2014 at 01:38:40PM +0200, Pali Rohár wrote:
> > On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote:
> > > -	if (!mdesc)
> > > +	if (mdesc)
> > > +		machine_name = of_flat_dt_get_machine_name();
> > > +	else
> > >  		mdesc = setup_machine_tags(__atags_pointer,
> > > __machine_arch_type); machine_desc = mdesc;
> > > -	machine_name = mdesc->name;
> > > +	if (!machine_name)
> > > +		machine_name = mdesc->name;
> > > 
> > >  	if (mdesc->reboot_mode != REBOOT_HARD)
> > >  		reboot_mode = mdesc->reboot_mode;
> > 
> > So, do you really want to break userspace which reading file 
> > /proc/cpuinfo (after migration from boardcode --> DT)?
> > 
> > I still do not see reason for that. And only this one file is 
> > problematic...
> 
> Sorry, I just don't give a damn about your whinging about this.  I've
> made the situation perfectly clear.  Your patch will not be accepted.

Linus made it pretty clear that regressions are not accepted. 

You are an arm maintainer and there is regression in n900 that broke userspace.

How do you solve it?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-09-10 12:46       ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2014-09-10 12:46 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri 2014-09-05 13:13:16, Russell King - ARM Linux wrote:
> On Fri, Sep 05, 2014 at 01:38:40PM +0200, Pali Roh?r wrote:
> > On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
> > > -	if (!mdesc)
> > > +	if (mdesc)
> > > +		machine_name = of_flat_dt_get_machine_name();
> > > +	else
> > >  		mdesc = setup_machine_tags(__atags_pointer,
> > > __machine_arch_type); machine_desc = mdesc;
> > > -	machine_name = mdesc->name;
> > > +	if (!machine_name)
> > > +		machine_name = mdesc->name;
> > > 
> > >  	if (mdesc->reboot_mode != REBOOT_HARD)
> > >  		reboot_mode = mdesc->reboot_mode;
> > 
> > So, do you really want to break userspace which reading file 
> > /proc/cpuinfo (after migration from boardcode --> DT)?
> > 
> > I still do not see reason for that. And only this one file is 
> > problematic...
> 
> Sorry, I just don't give a damn about your whinging about this.  I've
> made the situation perfectly clear.  Your patch will not be accepted.

Linus made it pretty clear that regressions are not accepted. 

You are an arm maintainer and there is regression in n900 that broke userspace.

How do you solve it?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 21:53           ` Fabio Estevam
@ 2014-11-24 22:16             ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:16 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Russell King - ARM Linux, Ivaylo Dimitrov, Sebastian Reichel,
	Will Deacon, linux-kernel, Santosh Shilimkar, Pavel Machek,
	linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 1229 bytes --]

On Wednesday 18 June 2014 23:53:00 Fabio Estevam wrote:
> On Wed, Jun 18, 2014 at 5:20 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > So how to read Revision and Serial number in DT based
> > kernel?
> 
> $ cat /sys/bus/soc/devices/soc0/soc_id
> i.MX6SX
> 
> $ cat /sys/bus/soc/devices/soc0/revision
> 1.0
> 
> $ cat /sys/bus/soc/devices/soc0/machine
> Freescale i.MX6 SoloX SDB Board

This does *not* working with DT based boot!

$ cat /sys/bus/soc/devices/soc0/soc_id
cat: can't open '/sys/bus/soc/devices/soc0/soc_id': No such file or directory
$ cat /sys/bus/soc/devices/soc0/revision 
ES3.1
$ cat /sys/bus/soc/devices/soc0/machine 
OMAP3430/3530


Here is output from *non* DT based boot:

# busybox cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
Features        : swp half thumb fastmult vfp edsp thumbee neon 
vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc08
CPU revision    : 3

Hardware        : Nokia RX-51 board
Revision        : 0012
Serial          : 0000000000000000


As you can see in those files are totally *different* values.

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-11-24 22:16             ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:16 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 18 June 2014 23:53:00 Fabio Estevam wrote:
> On Wed, Jun 18, 2014 at 5:20 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> > So how to read Revision and Serial number in DT based
> > kernel?
> 
> $ cat /sys/bus/soc/devices/soc0/soc_id
> i.MX6SX
> 
> $ cat /sys/bus/soc/devices/soc0/revision
> 1.0
> 
> $ cat /sys/bus/soc/devices/soc0/machine
> Freescale i.MX6 SoloX SDB Board

This does *not* working with DT based boot!

$ cat /sys/bus/soc/devices/soc0/soc_id
cat: can't open '/sys/bus/soc/devices/soc0/soc_id': No such file or directory
$ cat /sys/bus/soc/devices/soc0/revision 
ES3.1
$ cat /sys/bus/soc/devices/soc0/machine 
OMAP3430/3530


Here is output from *non* DT based boot:

# busybox cat /proc/cpuinfo 
processor       : 0
model name      : ARMv7 Processor rev 3 (v7l)
Features        : swp half thumb fastmult vfp edsp thumbee neon 
vfpv3 tls vfpd32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x2
CPU part        : 0xc08
CPU revision    : 3

Hardware        : Nokia RX-51 board
Revision        : 0012
Serial          : 0000000000000000


As you can see in those files are totally *different* values.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/835bc0cb/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 20:46       ` Rob Herring
@ 2014-11-24 22:19         ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:19 UTC (permalink / raw)
  To: Rob Herring
  Cc: Russell King, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 6968 bytes --]

On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > Machine name from board description is some generic name
> >> > on DT kernel. DT provides machine name property which is
> >> > specific for board, so use it instead generic one when
> >> > possible.
> >> > 
> >> > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> >> > ---
> >> > 
> >> >  arch/arm/kernel/setup.c |    7 +++++--
> >> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >> > 
> >> > diff --git a/arch/arm/kernel/setup.c
> >> > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> >> > --- a/arch/arm/kernel/setup.c
> >> > +++ b/arch/arm/kernel/setup.c
> >> > @@ -875,10 +875,13 @@ void __init setup_arch(char
> >> > **cmdline_p)
> >> > 
> >> >         setup_processor();
> >> >         mdesc = setup_machine_fdt(__atags_pointer);
> >> > 
> >> > -       if (!mdesc)
> >> > +       if (mdesc)
> >> > +               machine_name =
> >> > of_flat_dt_get_machine_name(); +       else
> >> > 
> >> >                 mdesc =
> >> >                 setup_machine_tags(__atags_pointer,
> >> >                 __machine_arch_type);
> >> >         
> >> >         machine_desc = mdesc;
> >> > 
> >> > -       machine_name = mdesc->name;
> >> > +       if (!machine_name)
> >> > +               machine_name = mdesc->name;
> >> > 
> >> >         if (mdesc->reboot_mode != REBOOT_HARD)
> >> >         
> >> >                 reboot_mode = mdesc->reboot_mode;
> >> 
> >> I did a similar patch previously[1]. Like my original
> >> patch, your patch unconditionally changes the name which
> >> could be considered part of the userspace ABI. It's
> >> arguably not good practice for userspace to depend on the
> >> name, but there are likely cases that do. So I think this
> >> needs to be optional and only use the DT name if the
> >> machine desc name is NULL.
> >> 
> >> So something like the below and then change the machine
> >> descriptors you care about. The default generic DT machine
> >> desc should definitely be changed.
> >> 
> >> I had a follow-up discussion with Grant about his concerns
> >> in the thread about knowing which machine desc used to
> >> boot. He said he was okay if just the machine desc address
> >> is printed out.
> >> 
> >> 
> >> diff --git a/arch/arm/kernel/setup.c
> >> b/arch/arm/kernel/setup.c index 50e198c..1479250 100644
> >> --- a/arch/arm/kernel/setup.c
> >> +++ b/arch/arm/kernel/setup.c
> >> @@ -887,7 +887,7 @@ void __init setup_arch(char
> >> **cmdline_p)
> >> 
> >>         if (!mdesc)
> >>         
> >>                 mdesc = setup_machine_tags(__atags_pointer,
> >> 
> >> __machine_arch_type);
> >> 
> >>         machine_desc = mdesc;
> >> 
> >> -       machine_name = mdesc->name;
> >> +       machine_name = mdesc->name ? mdesc->name :
> >> of_flat_dt_get_machine_name();
> >> 
> >>         if (mdesc->reboot_mode != REBOOT_HARD)
> >>         
> >>                 reboot_mode = mdesc->reboot_mode;
> >> 
> >> [1]
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-> >> No vember/208878.html
> > 
> > Hi,
> > 
> > now legacy board code for Nokia N900 (RX-51) is migrating to
> > DT kernel and there is problem with info which
> > /proc/cpuinfo reports
> 
> Thanks for providing your motivation which was missing from
> the commit message.
> 
> > New DT kernel (3.16-rc1) reports:
> > 
> > # busybox cat /proc/cpuinfo
> > processor       : 0
> > model name      : ARMv7 Processor rev 3 (v7l)
> > Features        : swp half thumb fastmult vfp edsp thumbee
> > neon vfpv3 tls vfpd32
> > CPU implementer : 0x41
> > CPU architecture: 7
> > CPU variant     : 0x2
> > CPU part        : 0xc08
> > CPU revision    : 3
> > 
> > Hardware        : Generic OMAP3 (Flattened Device Tree)
> > Revision        : 0000
> > Serial          : 0000000000000000
> > 
> > But legacy board code kernel reports:
> > 
> > # busybox cat /proc/cpuinfo
> > processor       : 0
> > model name      : ARMv7 Processor rev 3 (v7l)
> > Features        : swp half thumb fastmult vfp edsp thumbee
> > neon vfpv3 tls vfpd32
> > CPU implementer : 0x41
> > CPU architecture: 7
> > CPU variant     : 0x2
> > CPU part        : 0xc08
> > CPU revision    : 3
> > 
> > Hardware        : Nokia RX-51 board
> > Revision        : 0012
> > Serial          : 0000000000000000
> > 
> > Basically in DT kernel is missing Hardware, Revision and
> > probably also Serial key. (Now I used only qemu for testing
> > which set serial key to 0). All these informations is used
> > by userspace applications which determinate how to behave.
> 
> It is somewhat fragile to expect the name in the DT to match
> the old name from the kernel. As your patch to n900 dts
> shows, we'd probably have to update every dts file to make
> them match. While I think we should work to remove this
> string from the kernel, userspace depending on the DT model
> string is a bad idea. For example, if you had some platform
> with multiple OEMs just rebranding the same base design, they
> may all want to put their own model string into each product.
> The true h/w id is the compatible string.
> 
> Serial number is easy. There is already a standard although
> not widely used property for it with "/serial-number". You
> just need to wire it up to cpuinfo.
> 

There is no "/serial-number" property in kernel:

$ ls -l -a /sys/bus/soc/devices/soc0/
drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
-r--r--r--    1 0        0             4096 Jan  1 00:00 family
-r--r--r--    1 0        0             4096 Jan  1 00:00 machine
drwxr-xr-x    2 0        0                0 Jan  1 00:00 power
-r--r--r--    1 0        0             4096 Jan  1 00:00 revision
lrwxrwxrwx    1 0        0                0 Jan  1 00:00 
subsystem -> ../../bus/soc
-r--r--r--    1 0        0             4096 Jan  1 00:00 type
-rw-r--r--    1 0        0             4096 Jan  1 00:00 uevent

> > So without this patch DT migration for Nokia N900 cannot be
> > done without breaking userspace - which is not
> > acceptable...
> 
> I agree, but I would like to come up with something that
> prevents future dependence on this string.
> 
> > Also I still did not know why DT kernel does not report
> > Revision number which is passed by bootloader via atags.
> > Any idea?
> 
> Probably because no one cared until now and revision info for
> every SOC is different. I would like to see revision info set
> in the DT in a standard way and remove the various SOC
> specific kernel implementations.
> 
> Rob

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-11-24 22:19         ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:19 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r 
<pali.rohar@gmail.com> wrote:
> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > Machine name from board description is some generic name
> >> > on DT kernel. DT provides machine name property which is
> >> > specific for board, so use it instead generic one when
> >> > possible.
> >> > 
> >> > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> >> > ---
> >> > 
> >> >  arch/arm/kernel/setup.c |    7 +++++--
> >> >  1 file changed, 5 insertions(+), 2 deletions(-)
> >> > 
> >> > diff --git a/arch/arm/kernel/setup.c
> >> > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> >> > --- a/arch/arm/kernel/setup.c
> >> > +++ b/arch/arm/kernel/setup.c
> >> > @@ -875,10 +875,13 @@ void __init setup_arch(char
> >> > **cmdline_p)
> >> > 
> >> >         setup_processor();
> >> >         mdesc = setup_machine_fdt(__atags_pointer);
> >> > 
> >> > -       if (!mdesc)
> >> > +       if (mdesc)
> >> > +               machine_name =
> >> > of_flat_dt_get_machine_name(); +       else
> >> > 
> >> >                 mdesc =
> >> >                 setup_machine_tags(__atags_pointer,
> >> >                 __machine_arch_type);
> >> >         
> >> >         machine_desc = mdesc;
> >> > 
> >> > -       machine_name = mdesc->name;
> >> > +       if (!machine_name)
> >> > +               machine_name = mdesc->name;
> >> > 
> >> >         if (mdesc->reboot_mode != REBOOT_HARD)
> >> >         
> >> >                 reboot_mode = mdesc->reboot_mode;
> >> 
> >> I did a similar patch previously[1]. Like my original
> >> patch, your patch unconditionally changes the name which
> >> could be considered part of the userspace ABI. It's
> >> arguably not good practice for userspace to depend on the
> >> name, but there are likely cases that do. So I think this
> >> needs to be optional and only use the DT name if the
> >> machine desc name is NULL.
> >> 
> >> So something like the below and then change the machine
> >> descriptors you care about. The default generic DT machine
> >> desc should definitely be changed.
> >> 
> >> I had a follow-up discussion with Grant about his concerns
> >> in the thread about knowing which machine desc used to
> >> boot. He said he was okay if just the machine desc address
> >> is printed out.
> >> 
> >> 
> >> diff --git a/arch/arm/kernel/setup.c
> >> b/arch/arm/kernel/setup.c index 50e198c..1479250 100644
> >> --- a/arch/arm/kernel/setup.c
> >> +++ b/arch/arm/kernel/setup.c
> >> @@ -887,7 +887,7 @@ void __init setup_arch(char
> >> **cmdline_p)
> >> 
> >>         if (!mdesc)
> >>         
> >>                 mdesc = setup_machine_tags(__atags_pointer,
> >> 
> >> __machine_arch_type);
> >> 
> >>         machine_desc = mdesc;
> >> 
> >> -       machine_name = mdesc->name;
> >> +       machine_name = mdesc->name ? mdesc->name :
> >> of_flat_dt_get_machine_name();
> >> 
> >>         if (mdesc->reboot_mode != REBOOT_HARD)
> >>         
> >>                 reboot_mode = mdesc->reboot_mode;
> >> 
> >> [1]
> >> http://lists.infradead.org/pipermail/linux-arm-kernel/2013-> >> No vember/208878.html
> > 
> > Hi,
> > 
> > now legacy board code for Nokia N900 (RX-51) is migrating to
> > DT kernel and there is problem with info which
> > /proc/cpuinfo reports
> 
> Thanks for providing your motivation which was missing from
> the commit message.
> 
> > New DT kernel (3.16-rc1) reports:
> > 
> > # busybox cat /proc/cpuinfo
> > processor       : 0
> > model name      : ARMv7 Processor rev 3 (v7l)
> > Features        : swp half thumb fastmult vfp edsp thumbee
> > neon vfpv3 tls vfpd32
> > CPU implementer : 0x41
> > CPU architecture: 7
> > CPU variant     : 0x2
> > CPU part        : 0xc08
> > CPU revision    : 3
> > 
> > Hardware        : Generic OMAP3 (Flattened Device Tree)
> > Revision        : 0000
> > Serial          : 0000000000000000
> > 
> > But legacy board code kernel reports:
> > 
> > # busybox cat /proc/cpuinfo
> > processor       : 0
> > model name      : ARMv7 Processor rev 3 (v7l)
> > Features        : swp half thumb fastmult vfp edsp thumbee
> > neon vfpv3 tls vfpd32
> > CPU implementer : 0x41
> > CPU architecture: 7
> > CPU variant     : 0x2
> > CPU part        : 0xc08
> > CPU revision    : 3
> > 
> > Hardware        : Nokia RX-51 board
> > Revision        : 0012
> > Serial          : 0000000000000000
> > 
> > Basically in DT kernel is missing Hardware, Revision and
> > probably also Serial key. (Now I used only qemu for testing
> > which set serial key to 0). All these informations is used
> > by userspace applications which determinate how to behave.
> 
> It is somewhat fragile to expect the name in the DT to match
> the old name from the kernel. As your patch to n900 dts
> shows, we'd probably have to update every dts file to make
> them match. While I think we should work to remove this
> string from the kernel, userspace depending on the DT model
> string is a bad idea. For example, if you had some platform
> with multiple OEMs just rebranding the same base design, they
> may all want to put their own model string into each product.
> The true h/w id is the compatible string.
> 
> Serial number is easy. There is already a standard although
> not widely used property for it with "/serial-number". You
> just need to wire it up to cpuinfo.
> 

There is no "/serial-number" property in kernel:

$ ls -l -a /sys/bus/soc/devices/soc0/
drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
-r--r--r--    1 0        0             4096 Jan  1 00:00 family
-r--r--r--    1 0        0             4096 Jan  1 00:00 machine
drwxr-xr-x    2 0        0                0 Jan  1 00:00 power
-r--r--r--    1 0        0             4096 Jan  1 00:00 revision
lrwxrwxrwx    1 0        0                0 Jan  1 00:00 
subsystem -> ../../bus/soc
-r--r--r--    1 0        0             4096 Jan  1 00:00 type
-rw-r--r--    1 0        0             4096 Jan  1 00:00 uevent

> > So without this patch DT migration for Nokia N900 cannot be
> > done without breaking userspace - which is not
> > acceptable...
> 
> I agree, but I would like to come up with something that
> prevents future dependence on this string.
> 
> > Also I still did not know why DT kernel does not report
> > Revision number which is passed by bootloader via atags.
> > Any idea?
> 
> Probably because no one cared until now and revision info for
> every SOC is different. I would like to see revision info set
> in the DT in a standard way and remove the various SOC
> specific kernel implementations.
> 
> Rob

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/ab5e61a4/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-06-18 21:10       ` Aaro Koskinen
@ 2014-11-24 22:21         ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:21 UTC (permalink / raw)
  To: Aaro Koskinen
  Cc: Rob Herring, Ivaylo Dimitrov, Russell King, Sebastian Reichel,
	Will Deacon, linux-kernel, Santosh Shilimkar, Pavel Machek,
	linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 973 bytes --]

On Wednesday 18 June 2014 23:10:39 Aaro Koskinen wrote:
> Hi,
> 
> On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Rohár wrote:
> > So without this patch DT migration for Nokia N900 cannot be
> > done without breaking userspace - which is not
> > acceptable...
> 
> I guess the fact is that the Nokia N900 proprietary userspace
> has never worked properly with the mainline kernel without
> severe patching, so you cannot really talk about any
> regression. If you cannot fix those programs, you could still
> probably emulate the old Nokia kernel's /proc/cpuinfo by
> providing some text file and bind mounting it, no?
> 
> A.

Mainline kernel (with patches for missing driver) working with 
Maemo CSSU-Devel userspace. So there are regressions.

Emulation of /proc/cpuinfo is possible if somebody provides 
needed info. But I still do not know from *where* to read 
machine, serial number and hw revision.

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-11-24 22:21         ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:21 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 18 June 2014 23:10:39 Aaro Koskinen wrote:
> Hi,
> 
> On Wed, Jun 18, 2014 at 09:22:29PM +0200, Pali Roh?r wrote:
> > So without this patch DT migration for Nokia N900 cannot be
> > done without breaking userspace - which is not
> > acceptable...
> 
> I guess the fact is that the Nokia N900 proprietary userspace
> has never worked properly with the mainline kernel without
> severe patching, so you cannot really talk about any
> regression. If you cannot fix those programs, you could still
> probably emulate the old Nokia kernel's /proc/cpuinfo by
> providing some text file and bind mounting it, no?
> 
> A.

Mainline kernel (with patches for missing driver) working with 
Maemo CSSU-Devel userspace. So there are regressions.

Emulation of /proc/cpuinfo is possible if somebody provides 
needed info. But I still do not know from *where* to read 
machine, serial number and hw revision.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/aa667d0d/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-09-10 12:46       ` Pavel Machek
@ 2014-11-24 22:23         ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:23 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Russell King - ARM Linux, Santosh Shilimkar, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, linux-arm-kernel,
	linux-kernel, Rob Herring, Fabio Estevam, Aaro Koskinen

[-- Attachment #1: Type: Text/Plain, Size: 1579 bytes --]

On Wednesday 10 September 2014 14:46:15 Pavel Machek wrote:
> On Fri 2014-09-05 13:13:16, Russell King - ARM Linux wrote:
> > On Fri, Sep 05, 2014 at 01:38:40PM +0200, Pali Rohár wrote:
> > > On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote:
> > > > -	if (!mdesc)
> > > > +	if (mdesc)
> > > > +		machine_name = of_flat_dt_get_machine_name();
> > > > +	else
> > > > 
> > > >  		mdesc = setup_machine_tags(__atags_pointer,
> > > > 
> > > > __machine_arch_type); machine_desc = mdesc;
> > > > -	machine_name = mdesc->name;
> > > > +	if (!machine_name)
> > > > +		machine_name = mdesc->name;
> > > > 
> > > >  	if (mdesc->reboot_mode != REBOOT_HARD)
> > > >  	
> > > >  		reboot_mode = mdesc->reboot_mode;
> > > 
> > > So, do you really want to break userspace which reading
> > > file /proc/cpuinfo (after migration from boardcode -->
> > > DT)?
> > > 
> > > I still do not see reason for that. And only this one file
> > > is problematic...
> > 
> > Sorry, I just don't give a damn about your whinging about
> > this.  I've made the situation perfectly clear.  Your patch
> > will not be accepted.
> 
> Linus made it pretty clear that regressions are not accepted.
> 
> You are an arm maintainer and there is regression in n900 that
> broke userspace.
> 
> How do you solve it?
> 									Pavel

I must agree, it is breaking userspace. Even worse DT booting 
does not provide those old information about board which 
bootloader set in ATAG info (and which is needed for some 
applications).

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-11-24 22:23         ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:23 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 10 September 2014 14:46:15 Pavel Machek wrote:
> On Fri 2014-09-05 13:13:16, Russell King - ARM Linux wrote:
> > On Fri, Sep 05, 2014 at 01:38:40PM +0200, Pali Roh?r wrote:
> > > On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
> > > > -	if (!mdesc)
> > > > +	if (mdesc)
> > > > +		machine_name = of_flat_dt_get_machine_name();
> > > > +	else
> > > > 
> > > >  		mdesc = setup_machine_tags(__atags_pointer,
> > > > 
> > > > __machine_arch_type); machine_desc = mdesc;
> > > > -	machine_name = mdesc->name;
> > > > +	if (!machine_name)
> > > > +		machine_name = mdesc->name;
> > > > 
> > > >  	if (mdesc->reboot_mode != REBOOT_HARD)
> > > >  	
> > > >  		reboot_mode = mdesc->reboot_mode;
> > > 
> > > So, do you really want to break userspace which reading
> > > file /proc/cpuinfo (after migration from boardcode -->
> > > DT)?
> > > 
> > > I still do not see reason for that. And only this one file
> > > is problematic...
> > 
> > Sorry, I just don't give a damn about your whinging about
> > this.  I've made the situation perfectly clear.  Your patch
> > will not be accepted.
> 
> Linus made it pretty clear that regressions are not accepted.
> 
> You are an arm maintainer and there is regression in n900 that
> broke userspace.
> 
> How do you solve it?
> 									Pavel

I must agree, it is breaking userspace. Even worse DT booting 
does not provide those old information about board which 
bootloader set in ATAG info (and which is needed for some 
applications).

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/32a8d5c9/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-09-05 13:58         ` Mark Rutland
@ 2014-11-24 22:25           ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:25 UTC (permalink / raw)
  To: Mark Rutland
  Cc: Russell King, Ivaylo Dimitrov, Aaro Koskinen, Sebastian Reichel,
	Will Deacon, linux-kernel, Santosh Shilimkar, Pavel Machek,
	Fabio Estevam, linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 3074 bytes --]

On Friday 05 September 2014 15:58:16 Mark Rutland wrote:
> On Fri, Sep 05, 2014 at 02:52:05PM +0100, Pali Rohár wrote:
> > On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
> > > On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Rohár wrote:
> > > > On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote:
> > > > > Machine name from board description is some generic
> > > > > name on DT kernel. DT provides machine name property
> > > > > which is specific for board, so use it instead
> > > > > generic one when possible.
> > > > > 
> > > > > Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> > > > > ---
> > > > > 
> > > > >  arch/arm/kernel/setup.c |    7 +++++--
> > > > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/arch/arm/kernel/setup.c
> > > > > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f
> > > > > 100644 --- a/arch/arm/kernel/setup.c
> > > > > +++ b/arch/arm/kernel/setup.c
> > > > > @@ -875,10 +875,13 @@ void __init setup_arch(char
> > > > > **cmdline_p)
> > > > > 
> > > > >  	setup_processor();
> > > > >  	mdesc = setup_machine_fdt(__atags_pointer);
> > > > > 
> > > > > -	if (!mdesc)
> > > > > +	if (mdesc)
> > > > > +		machine_name = of_flat_dt_get_machine_name();
> > > > > +	else
> > > > > 
> > > > >  		mdesc = setup_machine_tags(__atags_pointer,
> > > > > 
> > > > > __machine_arch_type); machine_desc = mdesc;
> > > > > -	machine_name = mdesc->name;
> > > > > +	if (!machine_name)
> > > > > +		machine_name = mdesc->name;
> > > > > 
> > > > >  	if (mdesc->reboot_mode != REBOOT_HARD)
> > > > >  	
> > > > >  		reboot_mode = mdesc->reboot_mode;
> > > > 
> > > > So, do you really want to break userspace which reading
> > > > file /proc/cpuinfo (after migration from boardcode -->
> > > > DT)?
> > > 
> > > You have no guarantee model name in the DT == the name in
> > > a board file anyhow, and trying to force that is wrong.
> > > So further to Russell's reply, I must NAK this from a DT
> > > perspective.
> > > 
> > > Realistically your userspace is already broken if relying
> > > on such things. You built something that only ever worked
> > > for a particular arbitrary string. So it was already
> > > broken for every other board, and there was never any
> > > guarantee that new boards where your userspace could have
> > > worked would share the same name.
> > > 
> > > You're trying to fix the wrong side of the equation.
> > > 
> > > Mark.
> > 
> > So what is your suggestion for identifing board (name/type)
> > which will work with any kernel (and will not be broken
> > again by kernel later)?
> 
> Without knowing your use case I have no idea if that's even a
> sane thing to do.
> 
> Mark.

Read information which was previously (non DT boot) in file: 
/proc/cpuinfo

Hardware        : Nokia RX-51 board
Revision        : 0012
Serial          : 0000000000000000

Userspace applications using them for identifying on which device 
and hw revisions are running.

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-11-24 22:25           ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday 05 September 2014 15:58:16 Mark Rutland wrote:
> On Fri, Sep 05, 2014 at 02:52:05PM +0100, Pali Roh?r wrote:
> > On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
> > > On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Roh?r wrote:
> > > > On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
> > > > > Machine name from board description is some generic
> > > > > name on DT kernel. DT provides machine name property
> > > > > which is specific for board, so use it instead
> > > > > generic one when possible.
> > > > > 
> > > > > Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> > > > > ---
> > > > > 
> > > > >  arch/arm/kernel/setup.c |    7 +++++--
> > > > >  1 file changed, 5 insertions(+), 2 deletions(-)
> > > > > 
> > > > > diff --git a/arch/arm/kernel/setup.c
> > > > > b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f
> > > > > 100644 --- a/arch/arm/kernel/setup.c
> > > > > +++ b/arch/arm/kernel/setup.c
> > > > > @@ -875,10 +875,13 @@ void __init setup_arch(char
> > > > > **cmdline_p)
> > > > > 
> > > > >  	setup_processor();
> > > > >  	mdesc = setup_machine_fdt(__atags_pointer);
> > > > > 
> > > > > -	if (!mdesc)
> > > > > +	if (mdesc)
> > > > > +		machine_name = of_flat_dt_get_machine_name();
> > > > > +	else
> > > > > 
> > > > >  		mdesc = setup_machine_tags(__atags_pointer,
> > > > > 
> > > > > __machine_arch_type); machine_desc = mdesc;
> > > > > -	machine_name = mdesc->name;
> > > > > +	if (!machine_name)
> > > > > +		machine_name = mdesc->name;
> > > > > 
> > > > >  	if (mdesc->reboot_mode != REBOOT_HARD)
> > > > >  	
> > > > >  		reboot_mode = mdesc->reboot_mode;
> > > > 
> > > > So, do you really want to break userspace which reading
> > > > file /proc/cpuinfo (after migration from boardcode -->
> > > > DT)?
> > > 
> > > You have no guarantee model name in the DT == the name in
> > > a board file anyhow, and trying to force that is wrong.
> > > So further to Russell's reply, I must NAK this from a DT
> > > perspective.
> > > 
> > > Realistically your userspace is already broken if relying
> > > on such things. You built something that only ever worked
> > > for a particular arbitrary string. So it was already
> > > broken for every other board, and there was never any
> > > guarantee that new boards where your userspace could have
> > > worked would share the same name.
> > > 
> > > You're trying to fix the wrong side of the equation.
> > > 
> > > Mark.
> > 
> > So what is your suggestion for identifing board (name/type)
> > which will work with any kernel (and will not be broken
> > again by kernel later)?
> 
> Without knowing your use case I have no idea if that's even a
> sane thing to do.
> 
> Mark.

Read information which was previously (non DT boot) in file: 
/proc/cpuinfo

Hardware        : Nokia RX-51 board
Revision        : 0012
Serial          : 0000000000000000

Userspace applications using them for identifying on which device 
and hw revisions are running.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/cf51288a/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-09-05 13:58         ` Fabio Estevam
@ 2014-11-24 22:27           ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:27 UTC (permalink / raw)
  To: Fabio Estevam
  Cc: Mark Rutland, Russell King, Ivaylo Dimitrov, Aaro Koskinen,
	Sebastian Reichel, Will Deacon, linux-kernel, Santosh Shilimkar,
	Pavel Machek, linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 629 bytes --]

On Friday 05 September 2014 15:58:34 Fabio Estevam wrote:
> On Fri, Sep 5, 2014 at 10:52 AM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > So what is your suggestion for identifing board (name/type)
> > which will work with any kernel (and will not be broken
> > again by kernel later)?
> 
> $ cat /sys/bus/soc/devices/soc0/machine
> Freescale i.MX6 Quad SABRE Smart Device Board

This output is on Nokia N900 useless:

$ cat /sys/bus/soc/devices/soc0/machine
OMAP3430/3530

It does not specify that this is Nokia N900 (RX-51) device but 
only some generic omap board.

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-11-24 22:27           ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:27 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday 05 September 2014 15:58:34 Fabio Estevam wrote:
> On Fri, Sep 5, 2014 at 10:52 AM, Pali Roh?r 
<pali.rohar@gmail.com> wrote:
> > So what is your suggestion for identifing board (name/type)
> > which will work with any kernel (and will not be broken
> > again by kernel later)?
> 
> $ cat /sys/bus/soc/devices/soc0/machine
> Freescale i.MX6 Quad SABRE Smart Device Board

This output is on Nokia N900 useless:

$ cat /sys/bus/soc/devices/soc0/machine
OMAP3430/3530

It does not specify that this is Nokia N900 (RX-51) device but 
only some generic omap board.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/823526be/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-09-06 15:34         ` Andreas Färber
@ 2014-11-24 22:29           ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:29 UTC (permalink / raw)
  To: Andreas Färber
  Cc: Mark Rutland, Ivaylo Dimitrov, Russell King, Aaro Koskinen,
	Sebastian Reichel, Will Deacon, linux-kernel, Santosh Shilimkar,
	Pavel Machek, Fabio Estevam, linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 3147 bytes --]

On Saturday 06 September 2014 17:34:47 Andreas Färber wrote:
> Am 05.09.2014 15:52, schrieb Pali Rohár:
> > On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
> >> On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Rohár wrote:
> >>> On Wednesday 18 June 2014 18:54:24 Pali Rohár wrote:
> >>>> Machine name from board description is some generic name
> >>>> on DT kernel. DT provides machine name property which is
> >>>> specific for board, so use it instead generic one when
> >>>> possible.
> >>>> 
> >>>> Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
> >>>> ---
> >>>> 
> >>>>  arch/arm/kernel/setup.c |    7 +++++--
> >>>>  1 file changed, 5 insertions(+), 2 deletions(-)
> >>>> 
> >>>> diff --git a/arch/arm/kernel/setup.c
> >>>> b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> >>>> --- a/arch/arm/kernel/setup.c
> >>>> +++ b/arch/arm/kernel/setup.c
> >>>> @@ -875,10 +875,13 @@ void __init setup_arch(char
> >>>> **cmdline_p)
> >>>> 
> >>>>  	setup_processor();
> >>>>  	mdesc = setup_machine_fdt(__atags_pointer);
> >>>> 
> >>>> -	if (!mdesc)
> >>>> +	if (mdesc)
> >>>> +		machine_name = of_flat_dt_get_machine_name();
> >>>> +	else
> >>>> 
> >>>>  		mdesc = setup_machine_tags(__atags_pointer,
> >>>> 
> >>>> __machine_arch_type); machine_desc = mdesc;
> >>>> -	machine_name = mdesc->name;
> >>>> +	if (!machine_name)
> >>>> +		machine_name = mdesc->name;
> >>>> 
> >>>>  	if (mdesc->reboot_mode != REBOOT_HARD)
> >>>>  	
> >>>>  		reboot_mode = mdesc->reboot_mode;
> >>> 
> >>> So, do you really want to break userspace which reading
> >>> file /proc/cpuinfo (after migration from boardcode -->
> >>> DT)?
> >> 
> >> You have no guarantee model name in the DT == the name in a
> >> board file anyhow, and trying to force that is wrong. So
> >> further to Russell's reply, I must NAK this from a DT
> >> perspective.
> >> 
> >> Realistically your userspace is already broken if relying
> >> on such things. You built something that only ever worked
> >> for a particular arbitrary string. So it was already
> >> broken for every other board, and there was never any
> >> guarantee that new boards where your userspace could have
> >> worked would share the same name.
> >> 
> >> You're trying to fix the wrong side of the equation.
> > 
> > So what is your suggestion for identifing board (name/type)
> > which will work with any kernel (and will not be broken
> > again by kernel later)?
> 
> /proc/device-tree/compatible should give you a nul-separated
> list of compatible strings for the machine. Ideally they're
> even documented under Documentation/devicetree/bindings/arm/.
> 
> But as Mark said, depending on what you are actually trying to
> distinguish in userspace, there may be better ways.
> 
> Regards,
> Andreas

Ok, this is better. It at least output that device is Nokia N900 
and not some generic omap device...

$ cat /proc/device-tree/compatible
nokia,omap3-n900ti,omap3430ti,omap3

But I need also serial number and hw revisions which are reported 
by bootloader in ATAGs.

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-11-24 22:29           ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-11-24 22:29 UTC (permalink / raw)
  To: linux-arm-kernel

On Saturday 06 September 2014 17:34:47 Andreas F?rber wrote:
> Am 05.09.2014 15:52, schrieb Pali Roh?r:
> > On Friday 05 September 2014 15:45:42 Mark Rutland wrote:
> >> On Fri, Sep 05, 2014 at 12:38:40PM +0100, Pali Roh?r wrote:
> >>> On Wednesday 18 June 2014 18:54:24 Pali Roh?r wrote:
> >>>> Machine name from board description is some generic name
> >>>> on DT kernel. DT provides machine name property which is
> >>>> specific for board, so use it instead generic one when
> >>>> possible.
> >>>> 
> >>>> Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
> >>>> ---
> >>>> 
> >>>>  arch/arm/kernel/setup.c |    7 +++++--
> >>>>  1 file changed, 5 insertions(+), 2 deletions(-)
> >>>> 
> >>>> diff --git a/arch/arm/kernel/setup.c
> >>>> b/arch/arm/kernel/setup.c index 8a16ee5..fbc7b4f 100644
> >>>> --- a/arch/arm/kernel/setup.c
> >>>> +++ b/arch/arm/kernel/setup.c
> >>>> @@ -875,10 +875,13 @@ void __init setup_arch(char
> >>>> **cmdline_p)
> >>>> 
> >>>>  	setup_processor();
> >>>>  	mdesc = setup_machine_fdt(__atags_pointer);
> >>>> 
> >>>> -	if (!mdesc)
> >>>> +	if (mdesc)
> >>>> +		machine_name = of_flat_dt_get_machine_name();
> >>>> +	else
> >>>> 
> >>>>  		mdesc = setup_machine_tags(__atags_pointer,
> >>>> 
> >>>> __machine_arch_type); machine_desc = mdesc;
> >>>> -	machine_name = mdesc->name;
> >>>> +	if (!machine_name)
> >>>> +		machine_name = mdesc->name;
> >>>> 
> >>>>  	if (mdesc->reboot_mode != REBOOT_HARD)
> >>>>  	
> >>>>  		reboot_mode = mdesc->reboot_mode;
> >>> 
> >>> So, do you really want to break userspace which reading
> >>> file /proc/cpuinfo (after migration from boardcode -->
> >>> DT)?
> >> 
> >> You have no guarantee model name in the DT == the name in a
> >> board file anyhow, and trying to force that is wrong. So
> >> further to Russell's reply, I must NAK this from a DT
> >> perspective.
> >> 
> >> Realistically your userspace is already broken if relying
> >> on such things. You built something that only ever worked
> >> for a particular arbitrary string. So it was already
> >> broken for every other board, and there was never any
> >> guarantee that new boards where your userspace could have
> >> worked would share the same name.
> >> 
> >> You're trying to fix the wrong side of the equation.
> > 
> > So what is your suggestion for identifing board (name/type)
> > which will work with any kernel (and will not be broken
> > again by kernel later)?
> 
> /proc/device-tree/compatible should give you a nul-separated
> list of compatible strings for the machine. Ideally they're
> even documented under Documentation/devicetree/bindings/arm/.
> 
> But as Mark said, depending on what you are actually trying to
> distinguish in userspace, there may be better ways.
> 
> Regards,
> Andreas

Ok, this is better. It at least output that device is Nokia N900 
and not some generic omap device...

$ cat /proc/device-tree/compatible
nokia,omap3-n900ti,omap3430ti,omap3

But I need also serial number and hw revisions which are reported 
by bootloader in ATAGs.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141124/a2955bc8/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-11-24 22:19         ` Pali Rohár
@ 2014-12-04  0:33           ` Rob Herring
  -1 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-12-04  0:33 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel

On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
>> >
>> > <pali.rohar@gmail.com> wrote:
>> >> > Machine name from board description is some generic name
>> >> > on DT kernel. DT provides machine name property which is
>> >> > specific for board, so use it instead generic one when
>> >> > possible.
>> >> >

[...]

>> > Basically in DT kernel is missing Hardware, Revision and
>> > probably also Serial key. (Now I used only qemu for testing
>> > which set serial key to 0). All these informations is used
>> > by userspace applications which determinate how to behave.
>>
>> It is somewhat fragile to expect the name in the DT to match
>> the old name from the kernel. As your patch to n900 dts
>> shows, we'd probably have to update every dts file to make
>> them match. While I think we should work to remove this
>> string from the kernel, userspace depending on the DT model
>> string is a bad idea. For example, if you had some platform
>> with multiple OEMs just rebranding the same base design, they
>> may all want to put their own model string into each product.
>> The true h/w id is the compatible string.
>>
>> Serial number is easy. There is already a standard although
>> not widely used property for it with "/serial-number". You
>> just need to wire it up to cpuinfo.
>>
>
> There is no "/serial-number" property in kernel:
>
> $ ls -l -a /sys/bus/soc/devices/soc0/
> drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
> drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
> -r--r--r--    1 0        0             4096 Jan  1 00:00 family
> -r--r--r--    1 0        0             4096 Jan  1 00:00 machine
> drwxr-xr-x    2 0        0                0 Jan  1 00:00 power
> -r--r--r--    1 0        0             4096 Jan  1 00:00 revision
> lrwxrwxrwx    1 0        0                0 Jan  1 00:00
> subsystem -> ../../bus/soc
> -r--r--r--    1 0        0             4096 Jan  1 00:00 type
> -rw-r--r--    1 0        0             4096 Jan  1 00:00 uevent

Wrong place. If you put /serial-number in your DT, then it will be in
/proc/device-tree/serial-number.

If you want to wire that up to /proc/cpuinfo, I would be fine with that.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-12-04  0:33           ` Rob Herring
  0 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-12-04  0:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
> <pali.rohar@gmail.com> wrote:
>> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
>> >
>> > <pali.rohar@gmail.com> wrote:
>> >> > Machine name from board description is some generic name
>> >> > on DT kernel. DT provides machine name property which is
>> >> > specific for board, so use it instead generic one when
>> >> > possible.
>> >> >

[...]

>> > Basically in DT kernel is missing Hardware, Revision and
>> > probably also Serial key. (Now I used only qemu for testing
>> > which set serial key to 0). All these informations is used
>> > by userspace applications which determinate how to behave.
>>
>> It is somewhat fragile to expect the name in the DT to match
>> the old name from the kernel. As your patch to n900 dts
>> shows, we'd probably have to update every dts file to make
>> them match. While I think we should work to remove this
>> string from the kernel, userspace depending on the DT model
>> string is a bad idea. For example, if you had some platform
>> with multiple OEMs just rebranding the same base design, they
>> may all want to put their own model string into each product.
>> The true h/w id is the compatible string.
>>
>> Serial number is easy. There is already a standard although
>> not widely used property for it with "/serial-number". You
>> just need to wire it up to cpuinfo.
>>
>
> There is no "/serial-number" property in kernel:
>
> $ ls -l -a /sys/bus/soc/devices/soc0/
> drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
> drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
> -r--r--r--    1 0        0             4096 Jan  1 00:00 family
> -r--r--r--    1 0        0             4096 Jan  1 00:00 machine
> drwxr-xr-x    2 0        0                0 Jan  1 00:00 power
> -r--r--r--    1 0        0             4096 Jan  1 00:00 revision
> lrwxrwxrwx    1 0        0                0 Jan  1 00:00
> subsystem -> ../../bus/soc
> -r--r--r--    1 0        0             4096 Jan  1 00:00 type
> -rw-r--r--    1 0        0             4096 Jan  1 00:00 uevent

Wrong place. If you put /serial-number in your DT, then it will be in
/proc/device-tree/serial-number.

If you want to wire that up to /proc/cpuinfo, I would be fine with that.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-12-04  0:33           ` Rob Herring
@ 2014-12-04  0:48             ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-12-04  0:48 UTC (permalink / raw)
  To: Rob Herring
  Cc: Russell King, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel,
	Tony Lindgren

[-- Attachment #1: Type: Text/Plain, Size: 2960 bytes --]

On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> >> > 
> >> > <pali.rohar@gmail.com> wrote:
> >> >> > Machine name from board description is some generic
> >> >> > name on DT kernel. DT provides machine name property
> >> >> > which is specific for board, so use it instead
> >> >> > generic one when possible.
> 
> [...]
> 
> >> > Basically in DT kernel is missing Hardware, Revision and
> >> > probably also Serial key. (Now I used only qemu for
> >> > testing which set serial key to 0). All these
> >> > informations is used by userspace applications which
> >> > determinate how to behave.
> >> 
> >> It is somewhat fragile to expect the name in the DT to
> >> match the old name from the kernel. As your patch to n900
> >> dts shows, we'd probably have to update every dts file to
> >> make them match. While I think we should work to remove
> >> this string from the kernel, userspace depending on the DT
> >> model string is a bad idea. For example, if you had some
> >> platform with multiple OEMs just rebranding the same base
> >> design, they may all want to put their own model string
> >> into each product. The true h/w id is the compatible
> >> string.
> >> 
> >> Serial number is easy. There is already a standard although
> >> not widely used property for it with "/serial-number". You
> >> just need to wire it up to cpuinfo.
> > 
> > There is no "/serial-number" property in kernel:
> > 
> > $ ls -l -a /sys/bus/soc/devices/soc0/
> > drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
> > drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> > family -r--r--r--    1 0        0             4096 Jan  1
> > 00:00 machine drwxr-xr-x    2 0        0                0
> > Jan  1 00:00 power -r--r--r--    1 0        0            
> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0      
> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> > type -rw-r--r--    1 0        0             4096 Jan  1
> > 00:00 uevent
> 
> Wrong place. If you put /serial-number in your DT, then it
> will be in /proc/device-tree/serial-number.
> 
> If you want to wire that up to /proc/cpuinfo, I would be fine
> with that.
> 
> Rob

I cannot hardcode it into DT, because it is set by bootloader. 
And bootloader tell it to kernel via ATAGs structure. Bootloader 
is closed and proprietary and cannot be replaced (there is no 
documentation for hw init).

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-12-04  0:48             ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-12-04  0:48 UTC (permalink / raw)
  To: linux-arm-kernel

On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
> On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r 
<pali.rohar@gmail.com> wrote:
> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
> >> > 
> >> > <pali.rohar@gmail.com> wrote:
> >> >> > Machine name from board description is some generic
> >> >> > name on DT kernel. DT provides machine name property
> >> >> > which is specific for board, so use it instead
> >> >> > generic one when possible.
> 
> [...]
> 
> >> > Basically in DT kernel is missing Hardware, Revision and
> >> > probably also Serial key. (Now I used only qemu for
> >> > testing which set serial key to 0). All these
> >> > informations is used by userspace applications which
> >> > determinate how to behave.
> >> 
> >> It is somewhat fragile to expect the name in the DT to
> >> match the old name from the kernel. As your patch to n900
> >> dts shows, we'd probably have to update every dts file to
> >> make them match. While I think we should work to remove
> >> this string from the kernel, userspace depending on the DT
> >> model string is a bad idea. For example, if you had some
> >> platform with multiple OEMs just rebranding the same base
> >> design, they may all want to put their own model string
> >> into each product. The true h/w id is the compatible
> >> string.
> >> 
> >> Serial number is easy. There is already a standard although
> >> not widely used property for it with "/serial-number". You
> >> just need to wire it up to cpuinfo.
> > 
> > There is no "/serial-number" property in kernel:
> > 
> > $ ls -l -a /sys/bus/soc/devices/soc0/
> > drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
> > drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> > family -r--r--r--    1 0        0             4096 Jan  1
> > 00:00 machine drwxr-xr-x    2 0        0                0
> > Jan  1 00:00 power -r--r--r--    1 0        0            
> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0      
> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> > type -rw-r--r--    1 0        0             4096 Jan  1
> > 00:00 uevent
> 
> Wrong place. If you put /serial-number in your DT, then it
> will be in /proc/device-tree/serial-number.
> 
> If you want to wire that up to /proc/cpuinfo, I would be fine
> with that.
> 
> Rob

I cannot hardcode it into DT, because it is set by bootloader. 
And bootloader tell it to kernel via ATAGs structure. Bootloader 
is closed and proprietary and cannot be replaced (there is no 
documentation for hw init).

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141204/c9644671/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-12-04  0:33           ` Rob Herring
@ 2014-12-04 10:59             ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-12-04 10:59 UTC (permalink / raw)
  To: Rob Herring
  Cc: Pali Rohár, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel

On Wed, Dec 03, 2014 at 06:33:08PM -0600, Rob Herring wrote:
> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > There is no "/serial-number" property in kernel:
> >
> > $ ls -l -a /sys/bus/soc/devices/soc0/
> > drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
> > drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 family
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 machine
> > drwxr-xr-x    2 0        0                0 Jan  1 00:00 power
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 revision
> > lrwxrwxrwx    1 0        0                0 Jan  1 00:00
> > subsystem -> ../../bus/soc
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 type
> > -rw-r--r--    1 0        0             4096 Jan  1 00:00 uevent
> 
> Wrong place. If you put /serial-number in your DT, then it will be in
> /proc/device-tree/serial-number.
> 
> If you want to wire that up to /proc/cpuinfo, I would be fine with that.

That would be fine for me too.  Then it's just a matter of how to copy
the contents of the ATAG into the DT (I assume it's possible in a
similar way to the memory and command line information.)  That's
something I know nothing about though.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-12-04 10:59             ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2014-12-04 10:59 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Dec 03, 2014 at 06:33:08PM -0600, Rob Herring wrote:
> On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> > There is no "/serial-number" property in kernel:
> >
> > $ ls -l -a /sys/bus/soc/devices/soc0/
> > drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
> > drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 family
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 machine
> > drwxr-xr-x    2 0        0                0 Jan  1 00:00 power
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 revision
> > lrwxrwxrwx    1 0        0                0 Jan  1 00:00
> > subsystem -> ../../bus/soc
> > -r--r--r--    1 0        0             4096 Jan  1 00:00 type
> > -rw-r--r--    1 0        0             4096 Jan  1 00:00 uevent
> 
> Wrong place. If you put /serial-number in your DT, then it will be in
> /proc/device-tree/serial-number.
> 
> If you want to wire that up to /proc/cpuinfo, I would be fine with that.

That would be fine for me too.  Then it's just a matter of how to copy
the contents of the ATAG into the DT (I assume it's possible in a
similar way to the memory and command line information.)  That's
something I know nothing about though.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-12-04  0:48             ` Pali Rohár
@ 2014-12-04 16:49               ` Rob Herring
  -1 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-12-04 16:49 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel,
	Tony Lindgren

On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
>> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
>> >
>> > <pali.rohar@gmail.com> wrote:
>> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
>> >> >
>> >> > <pali.rohar@gmail.com> wrote:
>> >> >> > Machine name from board description is some generic
>> >> >> > name on DT kernel. DT provides machine name property
>> >> >> > which is specific for board, so use it instead
>> >> >> > generic one when possible.
>>
>> [...]
>>
>> >> > Basically in DT kernel is missing Hardware, Revision and
>> >> > probably also Serial key. (Now I used only qemu for
>> >> > testing which set serial key to 0). All these
>> >> > informations is used by userspace applications which
>> >> > determinate how to behave.
>> >>
>> >> It is somewhat fragile to expect the name in the DT to
>> >> match the old name from the kernel. As your patch to n900
>> >> dts shows, we'd probably have to update every dts file to
>> >> make them match. While I think we should work to remove
>> >> this string from the kernel, userspace depending on the DT
>> >> model string is a bad idea. For example, if you had some
>> >> platform with multiple OEMs just rebranding the same base
>> >> design, they may all want to put their own model string
>> >> into each product. The true h/w id is the compatible
>> >> string.
>> >>
>> >> Serial number is easy. There is already a standard although
>> >> not widely used property for it with "/serial-number". You
>> >> just need to wire it up to cpuinfo.
>> >
>> > There is no "/serial-number" property in kernel:
>> >
>> > $ ls -l -a /sys/bus/soc/devices/soc0/
>> > drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
>> > drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
>> > -r--r--r--    1 0        0             4096 Jan  1 00:00
>> > family -r--r--r--    1 0        0             4096 Jan  1
>> > 00:00 machine drwxr-xr-x    2 0        0                0
>> > Jan  1 00:00 power -r--r--r--    1 0        0
>> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
>> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
>> > -r--r--r--    1 0        0             4096 Jan  1 00:00
>> > type -rw-r--r--    1 0        0             4096 Jan  1
>> > 00:00 uevent
>>
>> Wrong place. If you put /serial-number in your DT, then it
>> will be in /proc/device-tree/serial-number.
>>
>> If you want to wire that up to /proc/cpuinfo, I would be fine
>> with that.
>>
>> Rob
>
> I cannot hardcode it into DT, because it is set by bootloader.
> And bootloader tell it to kernel via ATAGs structure. Bootloader
> is closed and proprietary and cannot be replaced (there is no
> documentation for hw init).

Either the bootloader can put the serial number into the DTB instead
of ATAGs or the kernel decompressor can copy it from ATAGs to DTB like
is done already for other ATAGs. I presume you cannot update the
bootloader and will need the latter.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-12-04 16:49               ` Rob Herring
  0 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-12-04 16:49 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Dec 3, 2014 at 6:48 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
>> On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r
> <pali.rohar@gmail.com> wrote:
>> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
>> >
>> > <pali.rohar@gmail.com> wrote:
>> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
>> >> >
>> >> > <pali.rohar@gmail.com> wrote:
>> >> >> > Machine name from board description is some generic
>> >> >> > name on DT kernel. DT provides machine name property
>> >> >> > which is specific for board, so use it instead
>> >> >> > generic one when possible.
>>
>> [...]
>>
>> >> > Basically in DT kernel is missing Hardware, Revision and
>> >> > probably also Serial key. (Now I used only qemu for
>> >> > testing which set serial key to 0). All these
>> >> > informations is used by userspace applications which
>> >> > determinate how to behave.
>> >>
>> >> It is somewhat fragile to expect the name in the DT to
>> >> match the old name from the kernel. As your patch to n900
>> >> dts shows, we'd probably have to update every dts file to
>> >> make them match. While I think we should work to remove
>> >> this string from the kernel, userspace depending on the DT
>> >> model string is a bad idea. For example, if you had some
>> >> platform with multiple OEMs just rebranding the same base
>> >> design, they may all want to put their own model string
>> >> into each product. The true h/w id is the compatible
>> >> string.
>> >>
>> >> Serial number is easy. There is already a standard although
>> >> not widely used property for it with "/serial-number". You
>> >> just need to wire it up to cpuinfo.
>> >
>> > There is no "/serial-number" property in kernel:
>> >
>> > $ ls -l -a /sys/bus/soc/devices/soc0/
>> > drwxr-xr-x    3 0        0                0 Jan  1 00:00 .
>> > drwxr-xr-x   18 0        0                0 Jan  1 00:00 ..
>> > -r--r--r--    1 0        0             4096 Jan  1 00:00
>> > family -r--r--r--    1 0        0             4096 Jan  1
>> > 00:00 machine drwxr-xr-x    2 0        0                0
>> > Jan  1 00:00 power -r--r--r--    1 0        0
>> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
>> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
>> > -r--r--r--    1 0        0             4096 Jan  1 00:00
>> > type -rw-r--r--    1 0        0             4096 Jan  1
>> > 00:00 uevent
>>
>> Wrong place. If you put /serial-number in your DT, then it
>> will be in /proc/device-tree/serial-number.
>>
>> If you want to wire that up to /proc/cpuinfo, I would be fine
>> with that.
>>
>> Rob
>
> I cannot hardcode it into DT, because it is set by bootloader.
> And bootloader tell it to kernel via ATAGs structure. Bootloader
> is closed and proprietary and cannot be replaced (there is no
> documentation for hw init).

Either the bootloader can put the serial number into the DTB instead
of ATAGs or the kernel decompressor can copy it from ATAGs to DTB like
is done already for other ATAGs. I presume you cannot update the
bootloader and will need the latter.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-12-04 16:49               ` Rob Herring
@ 2014-12-04 17:57                 ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-12-04 17:57 UTC (permalink / raw)
  To: Rob Herring
  Cc: Russell King, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel,
	Tony Lindgren

[-- Attachment #1: Type: Text/Plain, Size: 3912 bytes --]

On Thursday 04 December 2014 17:49:40 Rob Herring wrote:
> On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> >> > 
> >> > <pali.rohar@gmail.com> wrote:
> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> >> >> > 
> >> >> > <pali.rohar@gmail.com> wrote:
> >> >> >> > Machine name from board description is some generic
> >> >> >> > name on DT kernel. DT provides machine name
> >> >> >> > property which is specific for board, so use it
> >> >> >> > instead generic one when possible.
> >> 
> >> [...]
> >> 
> >> >> > Basically in DT kernel is missing Hardware, Revision
> >> >> > and probably also Serial key. (Now I used only qemu
> >> >> > for testing which set serial key to 0). All these
> >> >> > informations is used by userspace applications which
> >> >> > determinate how to behave.
> >> >> 
> >> >> It is somewhat fragile to expect the name in the DT to
> >> >> match the old name from the kernel. As your patch to
> >> >> n900 dts shows, we'd probably have to update every dts
> >> >> file to make them match. While I think we should work
> >> >> to remove this string from the kernel, userspace
> >> >> depending on the DT model string is a bad idea. For
> >> >> example, if you had some platform with multiple OEMs
> >> >> just rebranding the same base design, they may all want
> >> >> to put their own model string into each product. The
> >> >> true h/w id is the compatible string.
> >> >> 
> >> >> Serial number is easy. There is already a standard
> >> >> although not widely used property for it with
> >> >> "/serial-number". You just need to wire it up to
> >> >> cpuinfo.
> >> > 
> >> > There is no "/serial-number" property in kernel:
> >> > 
> >> > $ ls -l -a /sys/bus/soc/devices/soc0/
> >> > drwxr-xr-x    3 0        0                0 Jan  1 00:00
> >> > . drwxr-xr-x   18 0        0                0 Jan  1
> >> > 00:00 .. -r--r--r--    1 0        0             4096 Jan
> >> >  1 00:00 family -r--r--r--    1 0        0            
> >> > 4096 Jan  1 00:00 machine drwxr-xr-x    2 0        0    
> >> >            0 Jan  1 00:00 power -r--r--r--    1 0       
> >> > 0
> >> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
> >> > 
> >> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
> >> > 
> >> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> >> > type -rw-r--r--    1 0        0             4096 Jan  1
> >> > 00:00 uevent
> >> 
> >> Wrong place. If you put /serial-number in your DT, then it
> >> will be in /proc/device-tree/serial-number.
> >> 
> >> If you want to wire that up to /proc/cpuinfo, I would be
> >> fine with that.
> >> 
> >> Rob
> > 
> > I cannot hardcode it into DT, because it is set by
> > bootloader. And bootloader tell it to kernel via ATAGs
> > structure. Bootloader is closed and proprietary and cannot
> > be replaced (there is no documentation for hw init).
> 
> Either the bootloader can put the serial number into the DTB
> instead of ATAGs or the kernel decompressor can copy it from
> ATAGs to DTB like is done already for other ATAGs. I presume
> you cannot update the bootloader and will need the latter.
> 
> Rob

Rob, thanks for info! Btw, theoretically I can update bootloader 
if someone write it. So in practise I need to use second option.

Can you tell me which CONFIG_ needs to be enabled for kernel 
decompressor (so it copy some ATAGs) and where to start looking 
at code (for adding new code for copying other ATAGs)?

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-12-04 17:57                 ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-12-04 17:57 UTC (permalink / raw)
  To: linux-arm-kernel

On Thursday 04 December 2014 17:49:40 Rob Herring wrote:
> On Wed, Dec 3, 2014 at 6:48 PM, Pali Roh?r 
<pali.rohar@gmail.com> wrote:
> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
> >> > 
> >> > <pali.rohar@gmail.com> wrote:
> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
> >> >> > 
> >> >> > <pali.rohar@gmail.com> wrote:
> >> >> >> > Machine name from board description is some generic
> >> >> >> > name on DT kernel. DT provides machine name
> >> >> >> > property which is specific for board, so use it
> >> >> >> > instead generic one when possible.
> >> 
> >> [...]
> >> 
> >> >> > Basically in DT kernel is missing Hardware, Revision
> >> >> > and probably also Serial key. (Now I used only qemu
> >> >> > for testing which set serial key to 0). All these
> >> >> > informations is used by userspace applications which
> >> >> > determinate how to behave.
> >> >> 
> >> >> It is somewhat fragile to expect the name in the DT to
> >> >> match the old name from the kernel. As your patch to
> >> >> n900 dts shows, we'd probably have to update every dts
> >> >> file to make them match. While I think we should work
> >> >> to remove this string from the kernel, userspace
> >> >> depending on the DT model string is a bad idea. For
> >> >> example, if you had some platform with multiple OEMs
> >> >> just rebranding the same base design, they may all want
> >> >> to put their own model string into each product. The
> >> >> true h/w id is the compatible string.
> >> >> 
> >> >> Serial number is easy. There is already a standard
> >> >> although not widely used property for it with
> >> >> "/serial-number". You just need to wire it up to
> >> >> cpuinfo.
> >> > 
> >> > There is no "/serial-number" property in kernel:
> >> > 
> >> > $ ls -l -a /sys/bus/soc/devices/soc0/
> >> > drwxr-xr-x    3 0        0                0 Jan  1 00:00
> >> > . drwxr-xr-x   18 0        0                0 Jan  1
> >> > 00:00 .. -r--r--r--    1 0        0             4096 Jan
> >> >  1 00:00 family -r--r--r--    1 0        0            
> >> > 4096 Jan  1 00:00 machine drwxr-xr-x    2 0        0    
> >> >            0 Jan  1 00:00 power -r--r--r--    1 0       
> >> > 0
> >> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
> >> > 
> >> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
> >> > 
> >> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> >> > type -rw-r--r--    1 0        0             4096 Jan  1
> >> > 00:00 uevent
> >> 
> >> Wrong place. If you put /serial-number in your DT, then it
> >> will be in /proc/device-tree/serial-number.
> >> 
> >> If you want to wire that up to /proc/cpuinfo, I would be
> >> fine with that.
> >> 
> >> Rob
> > 
> > I cannot hardcode it into DT, because it is set by
> > bootloader. And bootloader tell it to kernel via ATAGs
> > structure. Bootloader is closed and proprietary and cannot
> > be replaced (there is no documentation for hw init).
> 
> Either the bootloader can put the serial number into the DTB
> instead of ATAGs or the kernel decompressor can copy it from
> ATAGs to DTB like is done already for other ATAGs. I presume
> you cannot update the bootloader and will need the latter.
> 
> Rob

Rob, thanks for info! Btw, theoretically I can update bootloader 
if someone write it. So in practise I need to use second option.

Can you tell me which CONFIG_ needs to be enabled for kernel 
decompressor (so it copy some ATAGs) and where to start looking 
at code (for adding new code for copying other ATAGs)?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141204/fa7d9132/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-12-04 17:57                 ` Pali Rohár
@ 2014-12-04 18:10                   ` Rob Herring
  -1 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-12-04 18:10 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King, Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Pavel Machek, linux-kernel, linux-arm-kernel, Tony Lindgren

On Thu, Dec 4, 2014 at 11:57 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Thursday 04 December 2014 17:49:40 Rob Herring wrote:
>> On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
>> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
>> >
>> > <pali.rohar@gmail.com> wrote:
>> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
>> >> >
>> >> > <pali.rohar@gmail.com> wrote:
>> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
>> >> >> >
>> >> >> > <pali.rohar@gmail.com> wrote:
>> >> >> >> > Machine name from board description is some generic
>> >> >> >> > name on DT kernel. DT provides machine name
>> >> >> >> > property which is specific for board, so use it
>> >> >> >> > instead generic one when possible.
>> >>
>> >> [...]
>> >>
>> >> >> > Basically in DT kernel is missing Hardware, Revision
>> >> >> > and probably also Serial key. (Now I used only qemu
>> >> >> > for testing which set serial key to 0). All these
>> >> >> > informations is used by userspace applications which
>> >> >> > determinate how to behave.
>> >> >>
>> >> >> It is somewhat fragile to expect the name in the DT to
>> >> >> match the old name from the kernel. As your patch to
>> >> >> n900 dts shows, we'd probably have to update every dts
>> >> >> file to make them match. While I think we should work
>> >> >> to remove this string from the kernel, userspace
>> >> >> depending on the DT model string is a bad idea. For
>> >> >> example, if you had some platform with multiple OEMs
>> >> >> just rebranding the same base design, they may all want
>> >> >> to put their own model string into each product. The
>> >> >> true h/w id is the compatible string.
>> >> >>
>> >> >> Serial number is easy. There is already a standard
>> >> >> although not widely used property for it with
>> >> >> "/serial-number". You just need to wire it up to
>> >> >> cpuinfo.
>> >> >
>> >> > There is no "/serial-number" property in kernel:
>> >> >
>> >> > $ ls -l -a /sys/bus/soc/devices/soc0/
>> >> > drwxr-xr-x    3 0        0                0 Jan  1 00:00
>> >> > . drwxr-xr-x   18 0        0                0 Jan  1
>> >> > 00:00 .. -r--r--r--    1 0        0             4096 Jan
>> >> >  1 00:00 family -r--r--r--    1 0        0
>> >> > 4096 Jan  1 00:00 machine drwxr-xr-x    2 0        0
>> >> >            0 Jan  1 00:00 power -r--r--r--    1 0
>> >> > 0
>> >> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
>> >> >
>> >> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
>> >> >
>> >> > -r--r--r--    1 0        0             4096 Jan  1 00:00
>> >> > type -rw-r--r--    1 0        0             4096 Jan  1
>> >> > 00:00 uevent
>> >>
>> >> Wrong place. If you put /serial-number in your DT, then it
>> >> will be in /proc/device-tree/serial-number.
>> >>
>> >> If you want to wire that up to /proc/cpuinfo, I would be
>> >> fine with that.
>> >>
>> >> Rob
>> >
>> > I cannot hardcode it into DT, because it is set by
>> > bootloader. And bootloader tell it to kernel via ATAGs
>> > structure. Bootloader is closed and proprietary and cannot
>> > be replaced (there is no documentation for hw init).
>>
>> Either the bootloader can put the serial number into the DTB
>> instead of ATAGs or the kernel decompressor can copy it from
>> ATAGs to DTB like is done already for other ATAGs. I presume
>> you cannot update the bootloader and will need the latter.
>>
>> Rob
>
> Rob, thanks for info! Btw, theoretically I can update bootloader
> if someone write it. So in practise I need to use second option.
>
> Can you tell me which CONFIG_ needs to be enabled for kernel
> decompressor (so it copy some ATAGs) and where to start looking
> at code (for adding new code for copying other ATAGs)?

See CONFIG_ARM_ATAG_DTB_COMPAT and arch/arm/boot/compressed/atags_to_fdt.c.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-12-04 18:10                   ` Rob Herring
  0 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2014-12-04 18:10 UTC (permalink / raw)
  To: linux-arm-kernel

On Thu, Dec 4, 2014 at 11:57 AM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> On Thursday 04 December 2014 17:49:40 Rob Herring wrote:
>> On Wed, Dec 3, 2014 at 6:48 PM, Pali Roh?r
> <pali.rohar@gmail.com> wrote:
>> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
>> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r
>> >
>> > <pali.rohar@gmail.com> wrote:
>> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
>> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
>> >> >
>> >> > <pali.rohar@gmail.com> wrote:
>> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
>> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
>> >> >> >
>> >> >> > <pali.rohar@gmail.com> wrote:
>> >> >> >> > Machine name from board description is some generic
>> >> >> >> > name on DT kernel. DT provides machine name
>> >> >> >> > property which is specific for board, so use it
>> >> >> >> > instead generic one when possible.
>> >>
>> >> [...]
>> >>
>> >> >> > Basically in DT kernel is missing Hardware, Revision
>> >> >> > and probably also Serial key. (Now I used only qemu
>> >> >> > for testing which set serial key to 0). All these
>> >> >> > informations is used by userspace applications which
>> >> >> > determinate how to behave.
>> >> >>
>> >> >> It is somewhat fragile to expect the name in the DT to
>> >> >> match the old name from the kernel. As your patch to
>> >> >> n900 dts shows, we'd probably have to update every dts
>> >> >> file to make them match. While I think we should work
>> >> >> to remove this string from the kernel, userspace
>> >> >> depending on the DT model string is a bad idea. For
>> >> >> example, if you had some platform with multiple OEMs
>> >> >> just rebranding the same base design, they may all want
>> >> >> to put their own model string into each product. The
>> >> >> true h/w id is the compatible string.
>> >> >>
>> >> >> Serial number is easy. There is already a standard
>> >> >> although not widely used property for it with
>> >> >> "/serial-number". You just need to wire it up to
>> >> >> cpuinfo.
>> >> >
>> >> > There is no "/serial-number" property in kernel:
>> >> >
>> >> > $ ls -l -a /sys/bus/soc/devices/soc0/
>> >> > drwxr-xr-x    3 0        0                0 Jan  1 00:00
>> >> > . drwxr-xr-x   18 0        0                0 Jan  1
>> >> > 00:00 .. -r--r--r--    1 0        0             4096 Jan
>> >> >  1 00:00 family -r--r--r--    1 0        0
>> >> > 4096 Jan  1 00:00 machine drwxr-xr-x    2 0        0
>> >> >            0 Jan  1 00:00 power -r--r--r--    1 0
>> >> > 0
>> >> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
>> >> >
>> >> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
>> >> >
>> >> > -r--r--r--    1 0        0             4096 Jan  1 00:00
>> >> > type -rw-r--r--    1 0        0             4096 Jan  1
>> >> > 00:00 uevent
>> >>
>> >> Wrong place. If you put /serial-number in your DT, then it
>> >> will be in /proc/device-tree/serial-number.
>> >>
>> >> If you want to wire that up to /proc/cpuinfo, I would be
>> >> fine with that.
>> >>
>> >> Rob
>> >
>> > I cannot hardcode it into DT, because it is set by
>> > bootloader. And bootloader tell it to kernel via ATAGs
>> > structure. Bootloader is closed and proprietary and cannot
>> > be replaced (there is no documentation for hw init).
>>
>> Either the bootloader can put the serial number into the DTB
>> instead of ATAGs or the kernel decompressor can copy it from
>> ATAGs to DTB like is done already for other ATAGs. I presume
>> you cannot update the bootloader and will need the latter.
>>
>> Rob
>
> Rob, thanks for info! Btw, theoretically I can update bootloader
> if someone write it. So in practise I need to use second option.
>
> Can you tell me which CONFIG_ needs to be enabled for kernel
> decompressor (so it copy some ATAGs) and where to start looking
> at code (for adding new code for copying other ATAGs)?

See CONFIG_ARM_ATAG_DTB_COMPAT and arch/arm/boot/compressed/atags_to_fdt.c.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
  2014-12-04 16:49               ` Rob Herring
@ 2014-12-04 19:00                 ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-12-04 19:00 UTC (permalink / raw)
  To: Rob Herring
  Cc: Russell King, Santosh Shilimkar, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, linux-kernel, linux-arm-kernel,
	Tony Lindgren

[-- Attachment #1: Type: Text/Plain, Size: 4003 bytes --]

On Thursday 04 December 2014 17:49:40 Rob Herring wrote:
> On Wed, Dec 3, 2014 at 6:48 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Rohár
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Rohár
> >> > 
> >> > <pali.rohar@gmail.com> wrote:
> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Rohár
> >> >> > 
> >> >> > <pali.rohar@gmail.com> wrote:
> >> >> >> > Machine name from board description is some generic
> >> >> >> > name on DT kernel. DT provides machine name
> >> >> >> > property which is specific for board, so use it
> >> >> >> > instead generic one when possible.
> >> 
> >> [...]
> >> 
> >> >> > Basically in DT kernel is missing Hardware, Revision
> >> >> > and probably also Serial key. (Now I used only qemu
> >> >> > for testing which set serial key to 0). All these
> >> >> > informations is used by userspace applications which
> >> >> > determinate how to behave.
> >> >> 
> >> >> It is somewhat fragile to expect the name in the DT to
> >> >> match the old name from the kernel. As your patch to
> >> >> n900 dts shows, we'd probably have to update every dts
> >> >> file to make them match. While I think we should work
> >> >> to remove this string from the kernel, userspace
> >> >> depending on the DT model string is a bad idea. For
> >> >> example, if you had some platform with multiple OEMs
> >> >> just rebranding the same base design, they may all want
> >> >> to put their own model string into each product. The
> >> >> true h/w id is the compatible string.
> >> >> 
> >> >> Serial number is easy. There is already a standard
> >> >> although not widely used property for it with
> >> >> "/serial-number". You just need to wire it up to
> >> >> cpuinfo.
> >> > 
> >> > There is no "/serial-number" property in kernel:
> >> > 
> >> > $ ls -l -a /sys/bus/soc/devices/soc0/
> >> > drwxr-xr-x    3 0        0                0 Jan  1 00:00
> >> > . drwxr-xr-x   18 0        0                0 Jan  1
> >> > 00:00 .. -r--r--r--    1 0        0             4096 Jan
> >> >  1 00:00 family -r--r--r--    1 0        0            
> >> > 4096 Jan  1 00:00 machine drwxr-xr-x    2 0        0    
> >> >            0 Jan  1 00:00 power -r--r--r--    1 0       
> >> > 0
> >> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
> >> > 
> >> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
> >> > 
> >> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> >> > type -rw-r--r--    1 0        0             4096 Jan  1
> >> > 00:00 uevent
> >> 
> >> Wrong place. If you put /serial-number in your DT, then it
> >> will be in /proc/device-tree/serial-number.
> >> 
> >> If you want to wire that up to /proc/cpuinfo, I would be
> >> fine with that.
> >> 
> >> Rob
> > 
> > I cannot hardcode it into DT, because it is set by
> > bootloader. And bootloader tell it to kernel via ATAGs
> > structure. Bootloader is closed and proprietary and cannot
> > be replaced (there is no documentation for hw init).
> 
> Either the bootloader can put the serial number into the DTB
> instead of ATAGs or the kernel decompressor can copy it from
> ATAGs to DTB like is done already for other ATAGs. I presume
> you cannot update the bootloader and will need the latter.
> 
> Rob

And what about copying also Revision ATAG (passed by bootloader) 
to DTB (in compressed code) and then show DTB revision in 
/proc/cpuinfo file?

Would be something like this for Revision acceptable for 
upstream?

Rob, and what about exporting /proc/atags file (to userspace) 
also in DT boot if bootloader provides ATAG structure? It is 
possible? Would be something like that accepted to upstream?

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible
@ 2014-12-04 19:00                 ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2014-12-04 19:00 UTC (permalink / raw)
  To: linux-arm-kernel

On Thursday 04 December 2014 17:49:40 Rob Herring wrote:
> On Wed, Dec 3, 2014 at 6:48 PM, Pali Roh?r 
<pali.rohar@gmail.com> wrote:
> > On Thursday 04 December 2014 01:33:08 Rob Herring wrote:
> >> On Mon, Nov 24, 2014 at 4:19 PM, Pali Roh?r
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > On Wednesday 18 June 2014 22:46:19 Rob Herring wrote:
> >> >> On Wed, Jun 18, 2014 at 2:22 PM, Pali Roh?r
> >> > 
> >> > <pali.rohar@gmail.com> wrote:
> >> >> > On Wednesday 18 June 2014 21:07:35 Rob Herring wrote:
> >> >> >> On Wed, Jun 18, 2014 at 11:54 AM, Pali Roh?r
> >> >> > 
> >> >> > <pali.rohar@gmail.com> wrote:
> >> >> >> > Machine name from board description is some generic
> >> >> >> > name on DT kernel. DT provides machine name
> >> >> >> > property which is specific for board, so use it
> >> >> >> > instead generic one when possible.
> >> 
> >> [...]
> >> 
> >> >> > Basically in DT kernel is missing Hardware, Revision
> >> >> > and probably also Serial key. (Now I used only qemu
> >> >> > for testing which set serial key to 0). All these
> >> >> > informations is used by userspace applications which
> >> >> > determinate how to behave.
> >> >> 
> >> >> It is somewhat fragile to expect the name in the DT to
> >> >> match the old name from the kernel. As your patch to
> >> >> n900 dts shows, we'd probably have to update every dts
> >> >> file to make them match. While I think we should work
> >> >> to remove this string from the kernel, userspace
> >> >> depending on the DT model string is a bad idea. For
> >> >> example, if you had some platform with multiple OEMs
> >> >> just rebranding the same base design, they may all want
> >> >> to put their own model string into each product. The
> >> >> true h/w id is the compatible string.
> >> >> 
> >> >> Serial number is easy. There is already a standard
> >> >> although not widely used property for it with
> >> >> "/serial-number". You just need to wire it up to
> >> >> cpuinfo.
> >> > 
> >> > There is no "/serial-number" property in kernel:
> >> > 
> >> > $ ls -l -a /sys/bus/soc/devices/soc0/
> >> > drwxr-xr-x    3 0        0                0 Jan  1 00:00
> >> > . drwxr-xr-x   18 0        0                0 Jan  1
> >> > 00:00 .. -r--r--r--    1 0        0             4096 Jan
> >> >  1 00:00 family -r--r--r--    1 0        0            
> >> > 4096 Jan  1 00:00 machine drwxr-xr-x    2 0        0    
> >> >            0 Jan  1 00:00 power -r--r--r--    1 0       
> >> > 0
> >> > 4096 Jan  1 00:00 revision lrwxrwxrwx    1 0        0
> >> > 
> >> >          0 Jan  1 00:00 subsystem -> ../../bus/soc
> >> > 
> >> > -r--r--r--    1 0        0             4096 Jan  1 00:00
> >> > type -rw-r--r--    1 0        0             4096 Jan  1
> >> > 00:00 uevent
> >> 
> >> Wrong place. If you put /serial-number in your DT, then it
> >> will be in /proc/device-tree/serial-number.
> >> 
> >> If you want to wire that up to /proc/cpuinfo, I would be
> >> fine with that.
> >> 
> >> Rob
> > 
> > I cannot hardcode it into DT, because it is set by
> > bootloader. And bootloader tell it to kernel via ATAGs
> > structure. Bootloader is closed and proprietary and cannot
> > be replaced (there is no documentation for hw init).
> 
> Either the bootloader can put the serial number into the DTB
> instead of ATAGs or the kernel decompressor can copy it from
> ATAGs to DTB like is done already for other ATAGs. I presume
> you cannot update the bootloader and will need the latter.
> 
> Rob

And what about copying also Revision ATAG (passed by bootloader) 
to DTB (in compressed code) and then show DTB revision in 
/proc/cpuinfo file?

Would be something like this for Revision acceptable for 
upstream?

Rob, and what about exporting /proc/atags file (to userspace) 
also in DT boot if bootloader provides ATAG structure? It is 
possible? Would be something like that accepted to upstream?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20141204/93a4559f/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
  2014-12-04 18:10                   ` Rob Herring
@ 2015-01-26 19:09                     ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-26 19:09 UTC (permalink / raw)
  To: Rob Herring
  Cc: Russell King, Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Pavel Machek, linux-kernel, linux-arm-kernel, Tony Lindgren

[-- Attachment #1: Type: Text/Plain, Size: 3068 bytes --]

Ok, here is patch which set Revision field (global variable system_rev) in /proc/cpuinfo from DT 
revision property:

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 11c54de..9946c1b 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -19,6 +19,7 @@
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/smp.h>
+#include <linux/libfdt_env.h>
 
 #include <asm/cputype.h>
 #include <asm/setup.h>
@@ -26,6 +27,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 +206,8 @@ 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;
+	unsigned long dt_root;
+	const u32 *prop;
 
 #ifdef CONFIG_ARCH_MULTIPLATFORM
 	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
@@ -215,17 +219,16 @@ 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);
@@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	/* Change machine number to match the mdesc we're using */
 	__machine_arch_type = mdesc->nr;
 
+	/* Set system revision from DT */
+	prop = of_get_flat_dt_prop(dt_root, "revision", NULL);
+	if (prop)
+		system_rev = fdt32_to_cpu(*prop);
+
 	return mdesc;
 }


And here is patch which convert ATAG revision into DT revision property and append it into DT in 
decompress code:

diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
index 9448aa0..e7e1cc9 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
 					cpu_to_fdt32(atag->u.mem.size);
 			}
 
+		} else if (atag->hdr.tag == ATAG_REVISION) {
+			setprop_cell(fdt, "/", "revision", atag->u.revision.rev);
 		} else if (atag->hdr.tag == ATAG_INITRD2) {
 			uint32_t initrd_start, initrd_size;
 			initrd_start = atag->u.initrd.start;


I tested it on DT booted Nokia N900 and it is working, in /proc/cpuinfo is revision from ATAG.

I do not know which DT property to use for storing HW Revision, so if "/revision" is not correct one, 
let me know what to use instead. Also you can add my Signed-off-by for both patches.

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply related	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-01-26 19:09                     ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-26 19:09 UTC (permalink / raw)
  To: linux-arm-kernel

Ok, here is patch which set Revision field (global variable system_rev) in /proc/cpuinfo from DT 
revision property:

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 11c54de..9946c1b 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -19,6 +19,7 @@
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/smp.h>
+#include <linux/libfdt_env.h>
 
 #include <asm/cputype.h>
 #include <asm/setup.h>
@@ -26,6 +27,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 +206,8 @@ 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;
+	unsigned long dt_root;
+	const u32 *prop;
 
 #ifdef CONFIG_ARCH_MULTIPLATFORM
 	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
@@ -215,17 +219,16 @@ 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);
@@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	/* Change machine number to match the mdesc we're using */
 	__machine_arch_type = mdesc->nr;
 
+	/* Set system revision from DT */
+	prop = of_get_flat_dt_prop(dt_root, "revision", NULL);
+	if (prop)
+		system_rev = fdt32_to_cpu(*prop);
+
 	return mdesc;
 }


And here is patch which convert ATAG revision into DT revision property and append it into DT in 
decompress code:

diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
index 9448aa0..e7e1cc9 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
 					cpu_to_fdt32(atag->u.mem.size);
 			}
 
+		} else if (atag->hdr.tag == ATAG_REVISION) {
+			setprop_cell(fdt, "/", "revision", atag->u.revision.rev);
 		} else if (atag->hdr.tag == ATAG_INITRD2) {
 			uint32_t initrd_start, initrd_size;
 			initrd_start = atag->u.initrd.start;


I tested it on DT booted Nokia N900 and it is working, in /proc/cpuinfo is revision from ATAG.

I do not know which DT property to use for storing HW Revision, so if "/revision" is not correct one, 
let me know what to use instead. Also you can add my Signed-off-by for both patches.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/e883d073/attachment.sig>

^ permalink raw reply related	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
  2014-12-04 18:10                   ` Rob Herring
@ 2015-01-26 19:16                     ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-26 19:16 UTC (permalink / raw)
  To: Rob Herring
  Cc: Russell King, Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Pavel Machek, linux-kernel, linux-arm-kernel, Tony Lindgren

[-- Attachment #1: Type: Text/Plain, Size: 2145 bytes --]

This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):

diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
index e7e1cc9..1975d7c 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -112,7 +112,7 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
 	 * address and size for each bank */
 	uint32_t mem_reg_property[2 * 2 * NR_BANKS];
 	int memcount = 0;
-	int ret, memsize;
+	int ret, memsize, atag_size;
 
 	/* make sure we've got an aligned pointer */
 	if ((u32)atag_list & 0x3)
@@ -184,6 +184,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
 		}
 	}
 
+	/* include the terminating ATAG_NONE */
+	atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
+	setprop(fdt, "/", "atags", atag_list, atag_size);
+
 	if (memcount) {
 		setprop(fdt, "/memory", "reg", mem_reg_property,
 			4 * memcount * memsize);



And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 9946c1b..0f249a3 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -29,6 +29,7 @@
 #include <asm/mach-types.h>
 #include <asm/system_info.h>
 
+#include "atags.h"
 
 #ifdef CONFIG_SMP
 extern struct of_cpu_method __cpu_method_of_table[];
@@ -254,5 +255,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	if (prop)
 		system_rev = fdt32_to_cpu(*prop);
 
+	/* Save atags */
+	prop = of_get_flat_dt_prop(dt_root, "atags", NULL);
+	if (prop)
+		save_atags((void *)prop);
+
 	return mdesc;
 }


Some userspace applications needs access to ATAG structure where can be stored some information passed 
from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information 
about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal 
mode or device update mode).

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply related	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-26 19:16                     ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-26 19:16 UTC (permalink / raw)
  To: linux-arm-kernel

This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):

diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
index e7e1cc9..1975d7c 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -112,7 +112,7 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
 	 * address and size for each bank */
 	uint32_t mem_reg_property[2 * 2 * NR_BANKS];
 	int memcount = 0;
-	int ret, memsize;
+	int ret, memsize, atag_size;
 
 	/* make sure we've got an aligned pointer */
 	if ((u32)atag_list & 0x3)
@@ -184,6 +184,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
 		}
 	}
 
+	/* include the terminating ATAG_NONE */
+	atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
+	setprop(fdt, "/", "atags", atag_list, atag_size);
+
 	if (memcount) {
 		setprop(fdt, "/memory", "reg", mem_reg_property,
 			4 * memcount * memsize);



And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 9946c1b..0f249a3 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -29,6 +29,7 @@
 #include <asm/mach-types.h>
 #include <asm/system_info.h>
 
+#include "atags.h"
 
 #ifdef CONFIG_SMP
 extern struct of_cpu_method __cpu_method_of_table[];
@@ -254,5 +255,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	if (prop)
 		system_rev = fdt32_to_cpu(*prop);
 
+	/* Save atags */
+	prop = of_get_flat_dt_prop(dt_root, "atags", NULL);
+	if (prop)
+		save_atags((void *)prop);
+
 	return mdesc;
 }


Some userspace applications needs access to ATAG structure where can be stored some information passed 
from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information 
about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal 
mode or device update mode).

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/f941725a/attachment.sig>

^ permalink raw reply related	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-01-26 19:09                     ` Pali Rohár
@ 2015-01-26 20:22                       ` Rob Herring
  -1 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2015-01-26 20:22 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King, Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Pavel Machek, linux-kernel, linux-arm-kernel, Tony Lindgren

On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> Ok, here is patch which set Revision field (global variable system_rev) in /proc/cpuinfo from DT
> revision property:
>
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 11c54de..9946c1b 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -19,6 +19,7 @@
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>  #include <linux/smp.h>
> +#include <linux/libfdt_env.h>
>
>  #include <asm/cputype.h>
>  #include <asm/setup.h>
> @@ -26,6 +27,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 +206,8 @@ 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;
> +       unsigned long dt_root;
> +       const u32 *prop;
>
>  #ifdef CONFIG_ARCH_MULTIPLATFORM
>         DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> @@ -215,17 +219,16 @@ 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);
> @@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>         /* Change machine number to match the mdesc we're using */
>         __machine_arch_type = mdesc->nr;
>
> +       /* Set system revision from DT */
> +       prop = of_get_flat_dt_prop(dt_root, "revision", NULL);
> +       if (prop)
> +               system_rev = fdt32_to_cpu(*prop);
> +
>         return mdesc;
>  }
>
>
> And here is patch which convert ATAG revision into DT revision property and append it into DT in
> decompress code:
>
> diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
> index 9448aa0..e7e1cc9 100644
> --- a/arch/arm/boot/compressed/atags_to_fdt.c
> +++ b/arch/arm/boot/compressed/atags_to_fdt.c
> @@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
>                                         cpu_to_fdt32(atag->u.mem.size);
>                         }
>
> +               } else if (atag->hdr.tag == ATAG_REVISION) {
> +                       setprop_cell(fdt, "/", "revision", atag->u.revision.rev);
>                 } else if (atag->hdr.tag == ATAG_INITRD2) {
>                         uint32_t initrd_start, initrd_size;
>                         initrd_start = atag->u.initrd.start;
>
>
> I tested it on DT booted Nokia N900 and it is working, in /proc/cpuinfo is revision from ATAG.
>
> I do not know which DT property to use for storing HW Revision, so if "/revision" is not correct one,
> let me know what to use instead. Also you can add my Signed-off-by for both patches.

It is the correct property, but /revision in DT is a string.

You need to add your own sign-off.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-01-26 20:22                       ` Rob Herring
  0 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2015-01-26 20:22 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 26, 2015 at 1:09 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> Ok, here is patch which set Revision field (global variable system_rev) in /proc/cpuinfo from DT
> revision property:
>
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 11c54de..9946c1b 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -19,6 +19,7 @@
>  #include <linux/of_irq.h>
>  #include <linux/of_platform.h>
>  #include <linux/smp.h>
> +#include <linux/libfdt_env.h>
>
>  #include <asm/cputype.h>
>  #include <asm/setup.h>
> @@ -26,6 +27,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 +206,8 @@ 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;
> +       unsigned long dt_root;
> +       const u32 *prop;
>
>  #ifdef CONFIG_ARCH_MULTIPLATFORM
>         DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> @@ -215,17 +219,16 @@ 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);
> @@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>         /* Change machine number to match the mdesc we're using */
>         __machine_arch_type = mdesc->nr;
>
> +       /* Set system revision from DT */
> +       prop = of_get_flat_dt_prop(dt_root, "revision", NULL);
> +       if (prop)
> +               system_rev = fdt32_to_cpu(*prop);
> +
>         return mdesc;
>  }
>
>
> And here is patch which convert ATAG revision into DT revision property and append it into DT in
> decompress code:
>
> diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
> index 9448aa0..e7e1cc9 100644
> --- a/arch/arm/boot/compressed/atags_to_fdt.c
> +++ b/arch/arm/boot/compressed/atags_to_fdt.c
> @@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
>                                         cpu_to_fdt32(atag->u.mem.size);
>                         }
>
> +               } else if (atag->hdr.tag == ATAG_REVISION) {
> +                       setprop_cell(fdt, "/", "revision", atag->u.revision.rev);
>                 } else if (atag->hdr.tag == ATAG_INITRD2) {
>                         uint32_t initrd_start, initrd_size;
>                         initrd_start = atag->u.initrd.start;
>
>
> I tested it on DT booted Nokia N900 and it is working, in /proc/cpuinfo is revision from ATAG.
>
> I do not know which DT property to use for storing HW Revision, so if "/revision" is not correct one,
> let me know what to use instead. Also you can add my Signed-off-by for both patches.

It is the correct property, but /revision in DT is a string.

You need to add your own sign-off.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-26 19:16                     ` Pali Rohár
@ 2015-01-26 20:33                       ` Rob Herring
  -1 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2015-01-26 20:33 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King, Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Pavel Machek, linux-kernel, linux-arm-kernel, Tony Lindgren

On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):
>
> diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
> index e7e1cc9..1975d7c 100644
> --- a/arch/arm/boot/compressed/atags_to_fdt.c
> +++ b/arch/arm/boot/compressed/atags_to_fdt.c
> @@ -112,7 +112,7 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
>          * address and size for each bank */
>         uint32_t mem_reg_property[2 * 2 * NR_BANKS];
>         int memcount = 0;
> -       int ret, memsize;
> +       int ret, memsize, atag_size;
>
>         /* make sure we've got an aligned pointer */
>         if ((u32)atag_list & 0x3)
> @@ -184,6 +184,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
>                 }
>         }
>
> +       /* include the terminating ATAG_NONE */
> +       atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
> +       setprop(fdt, "/", "atags", atag_list, atag_size);
> +
>         if (memcount) {
>                 setprop(fdt, "/memory", "reg", mem_reg_property,
>                         4 * memcount * memsize);
>
>
>
> And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:

Please properly send your patches.

> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 9946c1b..0f249a3 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -29,6 +29,7 @@
>  #include <asm/mach-types.h>
>  #include <asm/system_info.h>
>
> +#include "atags.h"
>
>  #ifdef CONFIG_SMP
>  extern struct of_cpu_method __cpu_method_of_table[];
> @@ -254,5 +255,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>         if (prop)
>                 system_rev = fdt32_to_cpu(*prop);
>
> +       /* Save atags */
> +       prop = of_get_flat_dt_prop(dt_root, "atags", NULL);
> +       if (prop)
> +               save_atags((void *)prop);
> +
>         return mdesc;
>  }
>
>
> Some userspace applications needs access to ATAG structure where can be stored some information passed
> from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
> about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
> mode or device update mode).

This goes in the commit message.

These would be non-standard fields which are not upstream. I don't
know that we care in that case...

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-26 20:33                       ` Rob Herring
  0 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2015-01-26 20:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 26, 2015 at 1:16 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):
>
> diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
> index e7e1cc9..1975d7c 100644
> --- a/arch/arm/boot/compressed/atags_to_fdt.c
> +++ b/arch/arm/boot/compressed/atags_to_fdt.c
> @@ -112,7 +112,7 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
>          * address and size for each bank */
>         uint32_t mem_reg_property[2 * 2 * NR_BANKS];
>         int memcount = 0;
> -       int ret, memsize;
> +       int ret, memsize, atag_size;
>
>         /* make sure we've got an aligned pointer */
>         if ((u32)atag_list & 0x3)
> @@ -184,6 +184,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
>                 }
>         }
>
> +       /* include the terminating ATAG_NONE */
> +       atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
> +       setprop(fdt, "/", "atags", atag_list, atag_size);
> +
>         if (memcount) {
>                 setprop(fdt, "/memory", "reg", mem_reg_property,
>                         4 * memcount * memsize);
>
>
>
> And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:

Please properly send your patches.

> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 9946c1b..0f249a3 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
> @@ -29,6 +29,7 @@
>  #include <asm/mach-types.h>
>  #include <asm/system_info.h>
>
> +#include "atags.h"
>
>  #ifdef CONFIG_SMP
>  extern struct of_cpu_method __cpu_method_of_table[];
> @@ -254,5 +255,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>         if (prop)
>                 system_rev = fdt32_to_cpu(*prop);
>
> +       /* Save atags */
> +       prop = of_get_flat_dt_prop(dt_root, "atags", NULL);
> +       if (prop)
> +               save_atags((void *)prop);
> +
>         return mdesc;
>  }
>
>
> Some userspace applications needs access to ATAG structure where can be stored some information passed
> from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
> about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
> mode or device update mode).

This goes in the commit message.

These would be non-standard fields which are not upstream. I don't
know that we care in that case...

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-26 19:16                     ` Pali Rohár
@ 2015-01-26 20:37                       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-26 20:37 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Rob Herring, Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Pavel Machek, linux-kernel, linux-arm-kernel, Tony Lindgren

On Mon, Jan 26, 2015 at 08:16:52PM +0100, Pali Rohár wrote:
> This patch will cause that decompressor store full ATAG structure into
> DT tree ("/atags"):

How about something a little more radical.

Rather than trying to squeeze various ATAGs into DT, why don't we add a
standard ATAG to contain the DT and pass that through into the kernel.
This is IMHO how we _should_ have done the ATAG compatibility from the
start.

That means we could get rid of most of the libfdt in the decompressor,
and instead resolve the differences in the kernel.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-26 20:37                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-26 20:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Jan 26, 2015 at 08:16:52PM +0100, Pali Roh?r wrote:
> This patch will cause that decompressor store full ATAG structure into
> DT tree ("/atags"):

How about something a little more radical.

Rather than trying to squeeze various ATAGs into DT, why don't we add a
standard ATAG to contain the DT and pass that through into the kernel.
This is IMHO how we _should_ have done the ATAG compatibility from the
start.

That means we could get rid of most of the libfdt in the decompressor,
and instead resolve the differences in the kernel.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-26 20:37                       ` Russell King - ARM Linux
@ 2015-01-26 20:44                         ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-26 20:44 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Rob Herring, Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Pavel Machek, linux-kernel, linux-arm-kernel, Tony Lindgren

[-- Attachment #1: Type: Text/Plain, Size: 920 bytes --]

On Monday 26 January 2015 21:37:51 Russell King - ARM Linux 
wrote:
> On Mon, Jan 26, 2015 at 08:16:52PM +0100, Pali Rohár wrote:
> > This patch will cause that decompressor store full ATAG
> > structure into
> 
> > DT tree ("/atags"):
> How about something a little more radical.
> 
> Rather than trying to squeeze various ATAGs into DT, why don't
> we add a standard ATAG to contain the DT and pass that
> through into the kernel. This is IMHO how we _should_ have
> done the ATAG compatibility from the start.
> 
> That means we could get rid of most of the libfdt in the
> decompressor, and instead resolve the differences in the
> kernel.

This sounds good. Now when I patched decompressor myself with 
Revision property support, I wanted to ask same question: Why to 
convert some part from ATAGs to DT instead to pass both ATAGs and 
DT to kernel?

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-26 20:44                         ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-26 20:44 UTC (permalink / raw)
  To: linux-arm-kernel

On Monday 26 January 2015 21:37:51 Russell King - ARM Linux 
wrote:
> On Mon, Jan 26, 2015 at 08:16:52PM +0100, Pali Roh?r wrote:
> > This patch will cause that decompressor store full ATAG
> > structure into
> 
> > DT tree ("/atags"):
> How about something a little more radical.
> 
> Rather than trying to squeeze various ATAGs into DT, why don't
> we add a standard ATAG to contain the DT and pass that
> through into the kernel. This is IMHO how we _should_ have
> done the ATAG compatibility from the start.
> 
> That means we could get rid of most of the libfdt in the
> decompressor, and instead resolve the differences in the
> kernel.

This sounds good. Now when I patched decompressor myself with 
Revision property support, I wanted to ask same question: Why to 
convert some part from ATAGs to DT instead to pass both ATAGs and 
DT to kernel?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/76bf758b/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-01-26 19:09                     ` Pali Rohár
@ 2015-01-26 22:34                       ` Andreas Färber
  -1 siblings, 0 replies; 197+ messages in thread
From: Andreas Färber @ 2015-01-26 22:34 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Rob Herring, Ivaylo Dimitrov, Russell King, Tony Lindgren,
	Sebastian Reichel, Will Deacon, linux-kernel, Pavel Machek,
	linux-arm-kernel

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

Am 26.01.2015 um 20:09 schrieb Pali Rohár:
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 11c54de..9946c1b 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
[...]
> @@ -204,6 +206,8 @@ 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;
> +	unsigned long dt_root;
> +	const u32 *prop;
>  
>  #ifdef CONFIG_ARCH_MULTIPLATFORM
>  	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> @@ -215,17 +219,16 @@ 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;

Probably the use of two differently typed variables of name "prop" in
this function is not intentional?

Regards,
Andreas

>  		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);
> @@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>  	/* Change machine number to match the mdesc we're using */
>  	__machine_arch_type = mdesc->nr;
>  
> +	/* Set system revision from DT */
> +	prop = of_get_flat_dt_prop(dt_root, "revision", NULL);
> +	if (prop)
> +		system_rev = fdt32_to_cpu(*prop);
> +
>  	return mdesc;
>  }
[snip]

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG Nürnberg)


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-01-26 22:34                       ` Andreas Färber
  0 siblings, 0 replies; 197+ messages in thread
From: Andreas Färber @ 2015-01-26 22:34 UTC (permalink / raw)
  To: linux-arm-kernel

Am 26.01.2015 um 20:09 schrieb Pali Roh?r:
> diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
> index 11c54de..9946c1b 100644
> --- a/arch/arm/kernel/devtree.c
> +++ b/arch/arm/kernel/devtree.c
[...]
> @@ -204,6 +206,8 @@ 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;
> +	unsigned long dt_root;
> +	const u32 *prop;
>  
>  #ifdef CONFIG_ARCH_MULTIPLATFORM
>  	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> @@ -215,17 +219,16 @@ 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;

Probably the use of two differently typed variables of name "prop" in
this function is not intentional?

Regards,
Andreas

>  		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);
> @@ -246,5 +249,10 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
>  	/* Change machine number to match the mdesc we're using */
>  	__machine_arch_type = mdesc->nr;
>  
> +	/* Set system revision from DT */
> +	prop = of_get_flat_dt_prop(dt_root, "revision", NULL);
> +	if (prop)
> +		system_rev = fdt32_to_cpu(*prop);
> +
>  	return mdesc;
>  }
[snip]

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Felix Imend?rffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu,
Graham Norton; HRB 21284 (AG N?rnberg)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150126/a6b5053f/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-26 20:33                       ` Rob Herring
@ 2015-01-27 13:21                         ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-27 13:21 UTC (permalink / raw)
  To: Rob Herring
  Cc: Pali Rohár, Russell King, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, linux-kernel, linux-arm-kernel, Tony Lindgren

On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> > This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):
> >

> > +       /* include the terminating ATAG_NONE */
> > +       atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
> > +       setprop(fdt, "/", "atags", atag_list, atag_size);
> > +
> >         if (memcount) {
> >                 setprop(fdt, "/memory", "reg", mem_reg_property,
> >                         4 * memcount * memsize);
> >
> >
> >
> > And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:
> 
> Please properly send your patches.

Actually, when sending patches for discussion, this is format easier
to read.

> > Some userspace applications needs access to ATAG structure where can be stored some information passed
> > from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
> > about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
> > mode or device update mode).
> 
> This goes in the commit message.
> 
> These would be non-standard fields which are not upstream. I don't
> know that we care in that case...

Other devices are going to care about boot reason, too, and we might
as well be compatible...
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 13:21                         ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-27 13:21 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> On Mon, Jan 26, 2015 at 1:16 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> > This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):
> >

> > +       /* include the terminating ATAG_NONE */
> > +       atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
> > +       setprop(fdt, "/", "atags", atag_list, atag_size);
> > +
> >         if (memcount) {
> >                 setprop(fdt, "/memory", "reg", mem_reg_property,
> >                         4 * memcount * memsize);
> >
> >
> >
> > And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:
> 
> Please properly send your patches.

Actually, when sending patches for discussion, this is format easier
to read.

> > Some userspace applications needs access to ATAG structure where can be stored some information passed
> > from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
> > about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
> > mode or device update mode).
> 
> This goes in the commit message.
> 
> These would be non-standard fields which are not upstream. I don't
> know that we care in that case...

Other devices are going to care about boot reason, too, and we might
as well be compatible...
									Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 13:21                         ` Pavel Machek
@ 2015-01-27 14:16                           ` Rob Herring
  -1 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2015-01-27 14:16 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Pali Rohár, Russell King, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, linux-kernel, linux-arm-kernel, Tony Lindgren

On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2015-01-26 14:33:21, Rob Herring wrote:
>> On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
>> > This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):
>> >
>
>> > +       /* include the terminating ATAG_NONE */
>> > +       atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
>> > +       setprop(fdt, "/", "atags", atag_list, atag_size);
>> > +
>> >         if (memcount) {
>> >                 setprop(fdt, "/memory", "reg", mem_reg_property,
>> >                         4 * memcount * memsize);
>> >
>> >
>> >
>> > And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:
>>
>> Please properly send your patches.
>
> Actually, when sending patches for discussion, this is format easier
> to read.

Some people might prefer them as attachments too...

>> > Some userspace applications needs access to ATAG structure where can be stored some information passed
>> > from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
>> > about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
>> > mode or device update mode).
>>
>> This goes in the commit message.
>>
>> These would be non-standard fields which are not upstream. I don't
>> know that we care in that case...
>
> Other devices are going to care about boot reason, too, and we might
> as well be compatible...

What other devices? Where is bootreason in the list of ATAGS:

#define ATAG_MEM        0x54410002
#define ATAG_VIDEOTEXT  0x54410003
#define ATAG_RAMDISK    0x54410004
#define ATAG_INITRD     0x54410005
#define ATAG_INITRD2    0x54420005
#define ATAG_SERIAL     0x54410006
#define ATAG_REVISION   0x54410007
#define ATAG_VIDEOLFB   0x54410008
#define ATAG_CMDLINE    0x54410009
#define ATAG_ACORN      0x41000101
#define ATAG_MEMCLK     0x41000402

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 14:16                           ` Rob Herring
  0 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2015-01-27 14:16 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> wrote:
> On Mon 2015-01-26 14:33:21, Rob Herring wrote:
>> On Mon, Jan 26, 2015 at 1:16 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
>> > This patch will cause that decompressor store full ATAG structure into DT tree ("/atags"):
>> >
>
>> > +       /* include the terminating ATAG_NONE */
>> > +       atag_size = (char *)atag - (char *)atag_list + sizeof(struct tag_header);
>> > +       setprop(fdt, "/", "atags", atag_list, atag_size);
>> > +
>> >         if (memcount) {
>> >                 setprop(fdt, "/memory", "reg", mem_reg_property,
>> >                         4 * memcount * memsize);
>> >
>> >
>> >
>> > And this patch will export ATAG structure from DT tree ("/atags") into /proc/atags file:
>>
>> Please properly send your patches.
>
> Actually, when sending patches for discussion, this is format easier
> to read.

Some people might prefer them as attachments too...

>> > Some userspace applications needs access to ATAG structure where can be stored some information passed
>> > from bootloader to kernel. Example is Nokia N900 device and NOLO bootloader which provides information
>> > about bootreason (device was started by power button or by alarm or restarted...) and bootmode (normal
>> > mode or device update mode).
>>
>> This goes in the commit message.
>>
>> These would be non-standard fields which are not upstream. I don't
>> know that we care in that case...
>
> Other devices are going to care about boot reason, too, and we might
> as well be compatible...

What other devices? Where is bootreason in the list of ATAGS:

#define ATAG_MEM        0x54410002
#define ATAG_VIDEOTEXT  0x54410003
#define ATAG_RAMDISK    0x54410004
#define ATAG_INITRD     0x54410005
#define ATAG_INITRD2    0x54420005
#define ATAG_SERIAL     0x54410006
#define ATAG_REVISION   0x54410007
#define ATAG_VIDEOLFB   0x54410008
#define ATAG_CMDLINE    0x54410009
#define ATAG_ACORN      0x41000101
#define ATAG_MEMCLK     0x41000402

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 14:16                           ` Rob Herring
@ 2015-01-27 14:24                             ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-27 14:24 UTC (permalink / raw)
  To: Rob Herring
  Cc: Pali Rohár, Russell King, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, linux-kernel, linux-arm-kernel, Tony Lindgren

On Tue 2015-01-27 08:16:45, Rob Herring wrote:
> On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> >> On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár <pali.rohar@gmail.com> wrote:

> >> This goes in the commit message.
> >>
> >> These would be non-standard fields which are not upstream. I don't
> >> know that we care in that case...
> >
> > Other devices are going to care about boot reason, too, and we might
> > as well be compatible...
> 
> What other devices? Where is bootreason in the list of ATAGS:
> 
> #define ATAG_MEM        0x54410002
> #define ATAG_VIDEOTEXT  0x54410003
> #define ATAG_RAMDISK    0x54410004
> #define ATAG_INITRD     0x54410005
> #define ATAG_INITRD2    0x54420005
> #define ATAG_SERIAL     0x54410006
> #define ATAG_REVISION   0x54410007
> #define ATAG_VIDEOLFB   0x54410008
> #define ATAG_CMDLINE    0x54410009
> #define ATAG_ACORN      0x41000101
> #define ATAG_MEMCLK     0x41000402

Anyone, whose charging involves userspace.

But the fact that it is needed on n900 should be enough.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 14:24                             ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-27 14:24 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue 2015-01-27 08:16:45, Rob Herring wrote:
> On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> wrote:
> > On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> >> On Mon, Jan 26, 2015 at 1:16 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:

> >> This goes in the commit message.
> >>
> >> These would be non-standard fields which are not upstream. I don't
> >> know that we care in that case...
> >
> > Other devices are going to care about boot reason, too, and we might
> > as well be compatible...
> 
> What other devices? Where is bootreason in the list of ATAGS:
> 
> #define ATAG_MEM        0x54410002
> #define ATAG_VIDEOTEXT  0x54410003
> #define ATAG_RAMDISK    0x54410004
> #define ATAG_INITRD     0x54410005
> #define ATAG_INITRD2    0x54420005
> #define ATAG_SERIAL     0x54410006
> #define ATAG_REVISION   0x54410007
> #define ATAG_VIDEOLFB   0x54410008
> #define ATAG_CMDLINE    0x54410009
> #define ATAG_ACORN      0x41000101
> #define ATAG_MEMCLK     0x41000402

Anyone, whose charging involves userspace.

But the fact that it is needed on n900 should be enough.
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 14:16                           ` Rob Herring
@ 2015-01-27 14:32                             ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-27 14:32 UTC (permalink / raw)
  To: Rob Herring
  Cc: Pavel Machek, Russell King, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, linux-kernel, linux-arm-kernel, Tony Lindgren

[-- Attachment #1: Type: Text/Plain, Size: 3471 bytes --]

On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> 
wrote:
> > On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> >> On Mon, Jan 26, 2015 at 1:16 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> >> > This patch will cause that decompressor store full ATAG
> >> > structure into DT tree ("/atags"):
> >> > 
> >> > 
> >> > +       /* include the terminating ATAG_NONE */
> >> > +       atag_size = (char *)atag - (char *)atag_list +
> >> > sizeof(struct tag_header); +       setprop(fdt, "/",
> >> > "atags", atag_list, atag_size); +
> >> > 
> >> >         if (memcount) {
> >> >         
> >> >                 setprop(fdt, "/memory", "reg",
> >> >                 mem_reg_property,
> >> >                 
> >> >                         4 * memcount * memsize);
> >> > 
> >> > And this patch will export ATAG structure from DT tree 
("/atags") into /proc/atags file:
> >> Please properly send your patches.
> > 
> > Actually, when sending patches for discussion, this is
> > format easier to read.
> 
> Some people might prefer them as attachments too...
> 
> >> > Some userspace applications needs access to ATAG
> >> > structure where can be stored some information passed
> >> > from bootloader to kernel. Example is Nokia N900 device
> >> > and NOLO bootloader which provides information about
> >> > bootreason (device was started by power button or by
> >> > alarm or restarted...) and bootmode (normal mode or
> >> > device update mode).
> >> 
> >> This goes in the commit message.
> >> 
> >> These would be non-standard fields which are not upstream.
> >> I don't know that we care in that case...
> > 
> > Other devices are going to care about boot reason, too, and
> > we might as well be compatible...
> 
> What other devices? Where is bootreason in the list of ATAGS:
> 
> #define ATAG_MEM        0x54410002
> #define ATAG_VIDEOTEXT  0x54410003
> #define ATAG_RAMDISK    0x54410004
> #define ATAG_INITRD     0x54410005
> #define ATAG_INITRD2    0x54420005
> #define ATAG_SERIAL     0x54410006
> #define ATAG_REVISION   0x54410007
> #define ATAG_VIDEOLFB   0x54410008
> #define ATAG_CMDLINE    0x54410009
> #define ATAG_ACORN      0x41000101
> #define ATAG_MEMCLK     0x41000402
> 
> Rob

Each device is using own proprietary atag (or other information) 
to pass bootreason from bootloader to kernel. No standard way :-(

I think Pavel mean to introduce some standard way how *new* 
version of bootloaders can pass boot reason to kernel and how 
kernel tell it to userspace...

E.g. NOLO -- bootloader for Nokia N900 -- pass this information 
in ATAG_OMAP (0x414f4d50) and Nokia kernel exports it via procfs 
file /proc/bootreason.

Also NOLO pass some other information via ATAGs, but those are 
static and now part of n900 DT file. But bootreason is not static 
information so cannot be hardcoded into static DT file which is 
part of kernel.

I think this kind of information (how was board/computer started) 
can be useful also for other architectures. E.g. on laptop you 
would like to know if if was started by RTC, power button, 
WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
And scripts can act depending on this event (when by RTC, you 
need to run some planned job, when by watchdog reset you should 
check what caused that reason...).

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 14:32                             ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-27 14:32 UTC (permalink / raw)
  To: linux-arm-kernel

On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> On Tue, Jan 27, 2015 at 7:21 AM, Pavel Machek <pavel@ucw.cz> 
wrote:
> > On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> >> On Mon, Jan 26, 2015 at 1:16 PM, Pali Roh?r 
<pali.rohar@gmail.com> wrote:
> >> > This patch will cause that decompressor store full ATAG
> >> > structure into DT tree ("/atags"):
> >> > 
> >> > 
> >> > +       /* include the terminating ATAG_NONE */
> >> > +       atag_size = (char *)atag - (char *)atag_list +
> >> > sizeof(struct tag_header); +       setprop(fdt, "/",
> >> > "atags", atag_list, atag_size); +
> >> > 
> >> >         if (memcount) {
> >> >         
> >> >                 setprop(fdt, "/memory", "reg",
> >> >                 mem_reg_property,
> >> >                 
> >> >                         4 * memcount * memsize);
> >> > 
> >> > And this patch will export ATAG structure from DT tree 
("/atags") into /proc/atags file:
> >> Please properly send your patches.
> > 
> > Actually, when sending patches for discussion, this is
> > format easier to read.
> 
> Some people might prefer them as attachments too...
> 
> >> > Some userspace applications needs access to ATAG
> >> > structure where can be stored some information passed
> >> > from bootloader to kernel. Example is Nokia N900 device
> >> > and NOLO bootloader which provides information about
> >> > bootreason (device was started by power button or by
> >> > alarm or restarted...) and bootmode (normal mode or
> >> > device update mode).
> >> 
> >> This goes in the commit message.
> >> 
> >> These would be non-standard fields which are not upstream.
> >> I don't know that we care in that case...
> > 
> > Other devices are going to care about boot reason, too, and
> > we might as well be compatible...
> 
> What other devices? Where is bootreason in the list of ATAGS:
> 
> #define ATAG_MEM        0x54410002
> #define ATAG_VIDEOTEXT  0x54410003
> #define ATAG_RAMDISK    0x54410004
> #define ATAG_INITRD     0x54410005
> #define ATAG_INITRD2    0x54420005
> #define ATAG_SERIAL     0x54410006
> #define ATAG_REVISION   0x54410007
> #define ATAG_VIDEOLFB   0x54410008
> #define ATAG_CMDLINE    0x54410009
> #define ATAG_ACORN      0x41000101
> #define ATAG_MEMCLK     0x41000402
> 
> Rob

Each device is using own proprietary atag (or other information) 
to pass bootreason from bootloader to kernel. No standard way :-(

I think Pavel mean to introduce some standard way how *new* 
version of bootloaders can pass boot reason to kernel and how 
kernel tell it to userspace...

E.g. NOLO -- bootloader for Nokia N900 -- pass this information 
in ATAG_OMAP (0x414f4d50) and Nokia kernel exports it via procfs 
file /proc/bootreason.

Also NOLO pass some other information via ATAGs, but those are 
static and now part of n900 DT file. But bootreason is not static 
information so cannot be hardcoded into static DT file which is 
part of kernel.

I think this kind of information (how was board/computer started) 
can be useful also for other architectures. E.g. on laptop you 
would like to know if if was started by RTC, power button, 
WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
And scripts can act depending on this event (when by RTC, you 
need to run some planned job, when by watchdog reset you should 
check what caused that reason...).

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150127/f0b0c2da/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 14:32                             ` Pali Rohár
@ 2015-01-27 17:48                               ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-27 17:48 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Rob Herring, Pavel Machek, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, linux-kernel, linux-arm-kernel, Tony Lindgren

On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote:
> On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > What other devices? Where is bootreason in the list of ATAGS:
> > 
> > #define ATAG_MEM        0x54410002
> > #define ATAG_VIDEOTEXT  0x54410003
> > #define ATAG_RAMDISK    0x54410004
> > #define ATAG_INITRD     0x54410005
> > #define ATAG_INITRD2    0x54420005
> > #define ATAG_SERIAL     0x54410006
> > #define ATAG_REVISION   0x54410007
> > #define ATAG_VIDEOLFB   0x54410008
> > #define ATAG_CMDLINE    0x54410009
> > #define ATAG_ACORN      0x41000101
> > #define ATAG_MEMCLK     0x41000402
> > 
> > Rob
> 
> Each device is using own proprietary atag (or other information) 
> to pass bootreason from bootloader to kernel. No standard way :-(

The reason that happens is because people refuse to discuss their
requirements here - just like people refuse to report userspace API
regressions to kernel people.  This rather pisses me off, because
it creates all sorts of horrid per-platform yuck.

We _could_ (and have in the past) turned round and refused to support
these kinds of hacks - which IMHO is quite a reasonable stance to
take: the message we should be sending is "if you wish to design
new methods without discussing it with us, we reserve the right not
to support them in mainline kernels; please discuss with us your
requirements."

Each time that we accept one of these hacks, we're sending a message
that says "it's okay to work in this crappy way".

Yes, I realise that the N900 has little in the way of support, and we
can't exert that kind of back pressure (since there's no one to direct
that onto to effect any change) so I guess we just have to live with it.

> I think this kind of information (how was board/computer started) 
> can be useful also for other architectures. E.g. on laptop you 
> would like to know if if was started by RTC, power button, 
> WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> And scripts can act depending on this event (when by RTC, you 
> need to run some planned job, when by watchdog reset you should 
> check what caused that reason...).

There is a standard way to get the boot information already: look at
the watchdog API:

#define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2, int)

which uses the WDIOF_* flags to indicate the last boot reason.  It
probably isn't as flexible as some may desire, but it should provide
at least the "watchdog rebooted us" vs "over temperature" vs some
other boot reason.

The other thing to consider is whether we have a way to know what
the boot reason was, and what we should do if we do not have a way
of supporting some of the boot reasons.  For example, if we have
support for RTC alarm based booting, but no way to actually tell
if the boot was caused by the RTC alarm triggering.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 17:48                               ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-27 17:48 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Roh?r wrote:
> On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > What other devices? Where is bootreason in the list of ATAGS:
> > 
> > #define ATAG_MEM        0x54410002
> > #define ATAG_VIDEOTEXT  0x54410003
> > #define ATAG_RAMDISK    0x54410004
> > #define ATAG_INITRD     0x54410005
> > #define ATAG_INITRD2    0x54420005
> > #define ATAG_SERIAL     0x54410006
> > #define ATAG_REVISION   0x54410007
> > #define ATAG_VIDEOLFB   0x54410008
> > #define ATAG_CMDLINE    0x54410009
> > #define ATAG_ACORN      0x41000101
> > #define ATAG_MEMCLK     0x41000402
> > 
> > Rob
> 
> Each device is using own proprietary atag (or other information) 
> to pass bootreason from bootloader to kernel. No standard way :-(

The reason that happens is because people refuse to discuss their
requirements here - just like people refuse to report userspace API
regressions to kernel people.  This rather pisses me off, because
it creates all sorts of horrid per-platform yuck.

We _could_ (and have in the past) turned round and refused to support
these kinds of hacks - which IMHO is quite a reasonable stance to
take: the message we should be sending is "if you wish to design
new methods without discussing it with us, we reserve the right not
to support them in mainline kernels; please discuss with us your
requirements."

Each time that we accept one of these hacks, we're sending a message
that says "it's okay to work in this crappy way".

Yes, I realise that the N900 has little in the way of support, and we
can't exert that kind of back pressure (since there's no one to direct
that onto to effect any change) so I guess we just have to live with it.

> I think this kind of information (how was board/computer started) 
> can be useful also for other architectures. E.g. on laptop you 
> would like to know if if was started by RTC, power button, 
> WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> And scripts can act depending on this event (when by RTC, you 
> need to run some planned job, when by watchdog reset you should 
> check what caused that reason...).

There is a standard way to get the boot information already: look at
the watchdog API:

#define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2, int)

which uses the WDIOF_* flags to indicate the last boot reason.  It
probably isn't as flexible as some may desire, but it should provide
at least the "watchdog rebooted us" vs "over temperature" vs some
other boot reason.

The other thing to consider is whether we have a way to know what
the boot reason was, and what we should do if we do not have a way
of supporting some of the boot reasons.  For example, if we have
support for RTC alarm based booting, but no way to actually tell
if the boot was caused by the RTC alarm triggering.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 13:21                         ` Pavel Machek
@ 2015-01-27 19:40                           ` Nicolas Pitre
  -1 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-01-27 19:40 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Rob Herring, Pali Rohár, Russell King, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel, Tony Lindgren

On Tue, 27 Jan 2015, Pavel Machek wrote:

> On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> > These would be non-standard fields which are not upstream. I don't
> > know that we care in that case...
> 
> Other devices are going to care about boot reason, too, and we might
> as well be compatible...

Care to elaborate on that statement please?  What does this have to do 
with ATAGs?


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 19:40                           ` Nicolas Pitre
  0 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-01-27 19:40 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 27 Jan 2015, Pavel Machek wrote:

> On Mon 2015-01-26 14:33:21, Rob Herring wrote:
> > These would be non-standard fields which are not upstream. I don't
> > know that we care in that case...
> 
> Other devices are going to care about boot reason, too, and we might
> as well be compatible...

Care to elaborate on that statement please?  What does this have to do 
with ATAGs?


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 17:48                               ` Russell King - ARM Linux
@ 2015-01-27 20:03                                 ` Nicolas Pitre
  -1 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-01-27 20:03 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Pali Rohár, Rob Herring, Pavel Machek, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel, Tony Lindgren

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2699 bytes --]

On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:

> On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote:
> > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > > What other devices? Where is bootreason in the list of ATAGS:
> > > 
> > > #define ATAG_MEM        0x54410002
> > > #define ATAG_VIDEOTEXT  0x54410003
> > > #define ATAG_RAMDISK    0x54410004
> > > #define ATAG_INITRD     0x54410005
> > > #define ATAG_INITRD2    0x54420005
> > > #define ATAG_SERIAL     0x54410006
> > > #define ATAG_REVISION   0x54410007
> > > #define ATAG_VIDEOLFB   0x54410008
> > > #define ATAG_CMDLINE    0x54410009
> > > #define ATAG_ACORN      0x41000101
> > > #define ATAG_MEMCLK     0x41000402
> > > 
> > > Rob
> > 
> > Each device is using own proprietary atag (or other information) 
> > to pass bootreason from bootloader to kernel. No standard way :-(

So that's what Pavel was alluding to.

> The reason that happens is because people refuse to discuss their
> requirements here - just like people refuse to report userspace API
> regressions to kernel people.  This rather pisses me off, because
> it creates all sorts of horrid per-platform yuck.
> 
> We _could_ (and have in the past) turned round and refused to support
> these kinds of hacks - which IMHO is quite a reasonable stance to
> take: the message we should be sending is "if you wish to design
> new methods without discussing it with us, we reserve the right not
> to support them in mainline kernels; please discuss with us your
> requirements."
> 
> Each time that we accept one of these hacks, we're sending a message
> that says "it's okay to work in this crappy way".
> 
> Yes, I realise that the N900 has little in the way of support, and we
> can't exert that kind of back pressure (since there's no one to direct
> that onto to effect any change) so I guess we just have to live with it.

If the method is: "let's pass non-standard ATAGs around and have ad-hoc 
user space code interpret it in some arbitrary way" then it's a complete 
abomination.

> > I think this kind of information (how was board/computer started) 
> > can be useful also for other architectures. E.g. on laptop you 
> > would like to know if if was started by RTC, power button, 
> > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > And scripts can act depending on this event (when by RTC, you 
> > need to run some planned job, when by watchdog reset you should 
> > check what caused that reason...).

Useful when properly designed and generic enough to be shared.

I'd suggest a DT property be proposed for that purpose if it doesn't 
already exist.  That at least has a chance to be generically useful.


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 20:03                                 ` Nicolas Pitre
  0 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-01-27 20:03 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:

> On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Roh?r wrote:
> > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > > What other devices? Where is bootreason in the list of ATAGS:
> > > 
> > > #define ATAG_MEM        0x54410002
> > > #define ATAG_VIDEOTEXT  0x54410003
> > > #define ATAG_RAMDISK    0x54410004
> > > #define ATAG_INITRD     0x54410005
> > > #define ATAG_INITRD2    0x54420005
> > > #define ATAG_SERIAL     0x54410006
> > > #define ATAG_REVISION   0x54410007
> > > #define ATAG_VIDEOLFB   0x54410008
> > > #define ATAG_CMDLINE    0x54410009
> > > #define ATAG_ACORN      0x41000101
> > > #define ATAG_MEMCLK     0x41000402
> > > 
> > > Rob
> > 
> > Each device is using own proprietary atag (or other information) 
> > to pass bootreason from bootloader to kernel. No standard way :-(

So that's what Pavel was alluding to.

> The reason that happens is because people refuse to discuss their
> requirements here - just like people refuse to report userspace API
> regressions to kernel people.  This rather pisses me off, because
> it creates all sorts of horrid per-platform yuck.
> 
> We _could_ (and have in the past) turned round and refused to support
> these kinds of hacks - which IMHO is quite a reasonable stance to
> take: the message we should be sending is "if you wish to design
> new methods without discussing it with us, we reserve the right not
> to support them in mainline kernels; please discuss with us your
> requirements."
> 
> Each time that we accept one of these hacks, we're sending a message
> that says "it's okay to work in this crappy way".
> 
> Yes, I realise that the N900 has little in the way of support, and we
> can't exert that kind of back pressure (since there's no one to direct
> that onto to effect any change) so I guess we just have to live with it.

If the method is: "let's pass non-standard ATAGs around and have ad-hoc 
user space code interpret it in some arbitrary way" then it's a complete 
abomination.

> > I think this kind of information (how was board/computer started) 
> > can be useful also for other architectures. E.g. on laptop you 
> > would like to know if if was started by RTC, power button, 
> > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > And scripts can act depending on this event (when by RTC, you 
> > need to run some planned job, when by watchdog reset you should 
> > check what caused that reason...).

Useful when properly designed and generic enough to be shared.

I'd suggest a DT property be proposed for that purpose if it doesn't 
already exist.  That at least has a chance to be generically useful.


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 20:03                                 ` Nicolas Pitre
@ 2015-01-27 21:09                                   ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-27 21:09 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Pali Rohár, Rob Herring, Pavel Machek, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel, Tony Lindgren

On Tue, Jan 27, 2015 at 03:03:23PM -0500, Nicolas Pitre wrote:
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> 
> > On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote:
> > > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > > > What other devices? Where is bootreason in the list of ATAGS:
> > > > 
> > > > #define ATAG_MEM        0x54410002
> > > > #define ATAG_VIDEOTEXT  0x54410003
> > > > #define ATAG_RAMDISK    0x54410004
> > > > #define ATAG_INITRD     0x54410005
> > > > #define ATAG_INITRD2    0x54420005
> > > > #define ATAG_SERIAL     0x54410006
> > > > #define ATAG_REVISION   0x54410007
> > > > #define ATAG_VIDEOLFB   0x54410008
> > > > #define ATAG_CMDLINE    0x54410009
> > > > #define ATAG_ACORN      0x41000101
> > > > #define ATAG_MEMCLK     0x41000402
> > > > 
> > > > Rob
> > > 
> > > Each device is using own proprietary atag (or other information) 
> > > to pass bootreason from bootloader to kernel. No standard way :-(
> 
> So that's what Pavel was alluding to.
> 
> > The reason that happens is because people refuse to discuss their
> > requirements here - just like people refuse to report userspace API
> > regressions to kernel people.  This rather pisses me off, because
> > it creates all sorts of horrid per-platform yuck.
> > 
> > We _could_ (and have in the past) turned round and refused to support
> > these kinds of hacks - which IMHO is quite a reasonable stance to
> > take: the message we should be sending is "if you wish to design
> > new methods without discussing it with us, we reserve the right not
> > to support them in mainline kernels; please discuss with us your
> > requirements."
> > 
> > Each time that we accept one of these hacks, we're sending a message
> > that says "it's okay to work in this crappy way".
> > 
> > Yes, I realise that the N900 has little in the way of support, and we
> > can't exert that kind of back pressure (since there's no one to direct
> > that onto to effect any change) so I guess we just have to live with it.
> 
> If the method is: "let's pass non-standard ATAGs around and have ad-hoc 
> user space code interpret it in some arbitrary way" then it's a complete 
> abomination.
> 
> > > I think this kind of information (how was board/computer started) 
> > > can be useful also for other architectures. E.g. on laptop you 
> > > would like to know if if was started by RTC, power button, 
> > > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > > And scripts can act depending on this event (when by RTC, you 
> > > need to run some planned job, when by watchdog reset you should 
> > > check what caused that reason...).
> 
> Useful when properly designed and generic enough to be shared.
> 
> I'd suggest a DT property be proposed for that purpose if it doesn't 
> already exist.  That at least has a chance to be generically useful.

What this means is that we have to further augment the atags-to-dt code
in the decompressor with the platform specific ATAGs to parse this
information and merge it into the appended DT before passing the
resulting DT blob to the kernel.

Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
and let the kernel deal with it in a much saner environment than the
restricted decompressor environment.

Or we /could/ say that mainline never supported it, and we aren't going
to add support for "new" tags to the mainline kernel.  It wouldn't be
a regression, because mainline hasn't ever supported them (that's been
said before about such things on other platforms.)

However, there's another consideration to be had here before we can say
that: how many people out there want to run a mainline (or even an
updated kernel derived from mainline) on this device?  If there's a
sizable following for the device wanting updated support, then it's
something we really need to consider supporting inspite of our
disappointment with Nokia inventing these "proprietary" tags.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 21:09                                   ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-27 21:09 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 27, 2015 at 03:03:23PM -0500, Nicolas Pitre wrote:
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> 
> > On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Roh?r wrote:
> > > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > > > What other devices? Where is bootreason in the list of ATAGS:
> > > > 
> > > > #define ATAG_MEM        0x54410002
> > > > #define ATAG_VIDEOTEXT  0x54410003
> > > > #define ATAG_RAMDISK    0x54410004
> > > > #define ATAG_INITRD     0x54410005
> > > > #define ATAG_INITRD2    0x54420005
> > > > #define ATAG_SERIAL     0x54410006
> > > > #define ATAG_REVISION   0x54410007
> > > > #define ATAG_VIDEOLFB   0x54410008
> > > > #define ATAG_CMDLINE    0x54410009
> > > > #define ATAG_ACORN      0x41000101
> > > > #define ATAG_MEMCLK     0x41000402
> > > > 
> > > > Rob
> > > 
> > > Each device is using own proprietary atag (or other information) 
> > > to pass bootreason from bootloader to kernel. No standard way :-(
> 
> So that's what Pavel was alluding to.
> 
> > The reason that happens is because people refuse to discuss their
> > requirements here - just like people refuse to report userspace API
> > regressions to kernel people.  This rather pisses me off, because
> > it creates all sorts of horrid per-platform yuck.
> > 
> > We _could_ (and have in the past) turned round and refused to support
> > these kinds of hacks - which IMHO is quite a reasonable stance to
> > take: the message we should be sending is "if you wish to design
> > new methods without discussing it with us, we reserve the right not
> > to support them in mainline kernels; please discuss with us your
> > requirements."
> > 
> > Each time that we accept one of these hacks, we're sending a message
> > that says "it's okay to work in this crappy way".
> > 
> > Yes, I realise that the N900 has little in the way of support, and we
> > can't exert that kind of back pressure (since there's no one to direct
> > that onto to effect any change) so I guess we just have to live with it.
> 
> If the method is: "let's pass non-standard ATAGs around and have ad-hoc 
> user space code interpret it in some arbitrary way" then it's a complete 
> abomination.
> 
> > > I think this kind of information (how was board/computer started) 
> > > can be useful also for other architectures. E.g. on laptop you 
> > > would like to know if if was started by RTC, power button, 
> > > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > > And scripts can act depending on this event (when by RTC, you 
> > > need to run some planned job, when by watchdog reset you should 
> > > check what caused that reason...).
> 
> Useful when properly designed and generic enough to be shared.
> 
> I'd suggest a DT property be proposed for that purpose if it doesn't 
> already exist.  That at least has a chance to be generically useful.

What this means is that we have to further augment the atags-to-dt code
in the decompressor with the platform specific ATAGs to parse this
information and merge it into the appended DT before passing the
resulting DT blob to the kernel.

Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
and let the kernel deal with it in a much saner environment than the
restricted decompressor environment.

Or we /could/ say that mainline never supported it, and we aren't going
to add support for "new" tags to the mainline kernel.  It wouldn't be
a regression, because mainline hasn't ever supported them (that's been
said before about such things on other platforms.)

However, there's another consideration to be had here before we can say
that: how many people out there want to run a mainline (or even an
updated kernel derived from mainline) on this device?  If there's a
sizable following for the device wanting updated support, then it's
something we really need to consider supporting inspite of our
disappointment with Nokia inventing these "proprietary" tags.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 21:09                                   ` Russell King - ARM Linux
@ 2015-01-27 21:34                                     ` Nicolas Pitre
  -1 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-01-27 21:34 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Pali Rohár, Rob Herring, Pavel Machek, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel, Tony Lindgren

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5021 bytes --]

On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:

> On Tue, Jan 27, 2015 at 03:03:23PM -0500, Nicolas Pitre wrote:
> > On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> > 
> > > On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Rohár wrote:
> > > > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > > > > What other devices? Where is bootreason in the list of ATAGS:
> > > > > 
> > > > > #define ATAG_MEM        0x54410002
> > > > > #define ATAG_VIDEOTEXT  0x54410003
> > > > > #define ATAG_RAMDISK    0x54410004
> > > > > #define ATAG_INITRD     0x54410005
> > > > > #define ATAG_INITRD2    0x54420005
> > > > > #define ATAG_SERIAL     0x54410006
> > > > > #define ATAG_REVISION   0x54410007
> > > > > #define ATAG_VIDEOLFB   0x54410008
> > > > > #define ATAG_CMDLINE    0x54410009
> > > > > #define ATAG_ACORN      0x41000101
> > > > > #define ATAG_MEMCLK     0x41000402
> > > > > 
> > > > > Rob
> > > > 
> > > > Each device is using own proprietary atag (or other information) 
> > > > to pass bootreason from bootloader to kernel. No standard way :-(
> > 
> > So that's what Pavel was alluding to.
> > 
> > > The reason that happens is because people refuse to discuss their
> > > requirements here - just like people refuse to report userspace API
> > > regressions to kernel people.  This rather pisses me off, because
> > > it creates all sorts of horrid per-platform yuck.
> > > 
> > > We _could_ (and have in the past) turned round and refused to support
> > > these kinds of hacks - which IMHO is quite a reasonable stance to
> > > take: the message we should be sending is "if you wish to design
> > > new methods without discussing it with us, we reserve the right not
> > > to support them in mainline kernels; please discuss with us your
> > > requirements."
> > > 
> > > Each time that we accept one of these hacks, we're sending a message
> > > that says "it's okay to work in this crappy way".
> > > 
> > > Yes, I realise that the N900 has little in the way of support, and we
> > > can't exert that kind of back pressure (since there's no one to direct
> > > that onto to effect any change) so I guess we just have to live with it.
> > 
> > If the method is: "let's pass non-standard ATAGs around and have ad-hoc 
> > user space code interpret it in some arbitrary way" then it's a complete 
> > abomination.
> > 
> > > > I think this kind of information (how was board/computer started) 
> > > > can be useful also for other architectures. E.g. on laptop you 
> > > > would like to know if if was started by RTC, power button, 
> > > > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > > > And scripts can act depending on this event (when by RTC, you 
> > > > need to run some planned job, when by watchdog reset you should 
> > > > check what caused that reason...).
> > 
> > Useful when properly designed and generic enough to be shared.
> > 
> > I'd suggest a DT property be proposed for that purpose if it doesn't 
> > already exist.  That at least has a chance to be generically useful.
> 
> What this means is that we have to further augment the atags-to-dt code
> in the decompressor with the platform specific ATAGs to parse this
> information and merge it into the appended DT before passing the
> resulting DT blob to the kernel.

That would be only 2 new lines of code in the best case.

Still, I opposed such platform specific hacks in the past, suggesting 
that a separate shim be used instead, which was done successfully.

> Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
> and let the kernel deal with it in a much saner environment than the
> restricted decompressor environment.

... which would be a step backward in the context of the transition to 
DT we accepted.  People will have even less of an incentive to fix their 
stuff.

> Or we /could/ say that mainline never supported it, and we aren't going
> to add support for "new" tags to the mainline kernel.  It wouldn't be
> a regression, because mainline hasn't ever supported them (that's been
> said before about such things on other platforms.)

That would be my stance.

> However, there's another consideration to be had here before we can say
> that: how many people out there want to run a mainline (or even an
> updated kernel derived from mainline) on this device?  If there's a
> sizable following for the device wanting updated support, then it's
> something we really need to consider supporting inspite of our
> disappointment with Nokia inventing these "proprietary" tags.

If there is indeed a sizable following for the device then someone 
should figure out how to cope with upstream kernels, either through the 
installation of some intermediate bootloader that can talk FDT directly, 
or via a shim layer.  None of that has to be performed by nor linked 
with the kernel binary, nor maintained in the kernel tree. And it's not 
even that hard to do: we have precedents on other platforms with crappy 
bootloaders where this just works.


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 21:34                                     ` Nicolas Pitre
  0 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-01-27 21:34 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:

> On Tue, Jan 27, 2015 at 03:03:23PM -0500, Nicolas Pitre wrote:
> > On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> > 
> > > On Tue, Jan 27, 2015 at 03:32:25PM +0100, Pali Roh?r wrote:
> > > > On Tuesday 27 January 2015 15:16:45 Rob Herring wrote:
> > > > > What other devices? Where is bootreason in the list of ATAGS:
> > > > > 
> > > > > #define ATAG_MEM        0x54410002
> > > > > #define ATAG_VIDEOTEXT  0x54410003
> > > > > #define ATAG_RAMDISK    0x54410004
> > > > > #define ATAG_INITRD     0x54410005
> > > > > #define ATAG_INITRD2    0x54420005
> > > > > #define ATAG_SERIAL     0x54410006
> > > > > #define ATAG_REVISION   0x54410007
> > > > > #define ATAG_VIDEOLFB   0x54410008
> > > > > #define ATAG_CMDLINE    0x54410009
> > > > > #define ATAG_ACORN      0x41000101
> > > > > #define ATAG_MEMCLK     0x41000402
> > > > > 
> > > > > Rob
> > > > 
> > > > Each device is using own proprietary atag (or other information) 
> > > > to pass bootreason from bootloader to kernel. No standard way :-(
> > 
> > So that's what Pavel was alluding to.
> > 
> > > The reason that happens is because people refuse to discuss their
> > > requirements here - just like people refuse to report userspace API
> > > regressions to kernel people.  This rather pisses me off, because
> > > it creates all sorts of horrid per-platform yuck.
> > > 
> > > We _could_ (and have in the past) turned round and refused to support
> > > these kinds of hacks - which IMHO is quite a reasonable stance to
> > > take: the message we should be sending is "if you wish to design
> > > new methods without discussing it with us, we reserve the right not
> > > to support them in mainline kernels; please discuss with us your
> > > requirements."
> > > 
> > > Each time that we accept one of these hacks, we're sending a message
> > > that says "it's okay to work in this crappy way".
> > > 
> > > Yes, I realise that the N900 has little in the way of support, and we
> > > can't exert that kind of back pressure (since there's no one to direct
> > > that onto to effect any change) so I guess we just have to live with it.
> > 
> > If the method is: "let's pass non-standard ATAGs around and have ad-hoc 
> > user space code interpret it in some arbitrary way" then it's a complete 
> > abomination.
> > 
> > > > I think this kind of information (how was board/computer started) 
> > > > can be useful also for other architectures. E.g. on laptop you 
> > > > would like to know if if was started by RTC, power button, 
> > > > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > > > And scripts can act depending on this event (when by RTC, you 
> > > > need to run some planned job, when by watchdog reset you should 
> > > > check what caused that reason...).
> > 
> > Useful when properly designed and generic enough to be shared.
> > 
> > I'd suggest a DT property be proposed for that purpose if it doesn't 
> > already exist.  That at least has a chance to be generically useful.
> 
> What this means is that we have to further augment the atags-to-dt code
> in the decompressor with the platform specific ATAGs to parse this
> information and merge it into the appended DT before passing the
> resulting DT blob to the kernel.

That would be only 2 new lines of code in the best case.

Still, I opposed such platform specific hacks in the past, suggesting 
that a separate shim be used instead, which was done successfully.

> Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
> and let the kernel deal with it in a much saner environment than the
> restricted decompressor environment.

... which would be a step backward in the context of the transition to 
DT we accepted.  People will have even less of an incentive to fix their 
stuff.

> Or we /could/ say that mainline never supported it, and we aren't going
> to add support for "new" tags to the mainline kernel.  It wouldn't be
> a regression, because mainline hasn't ever supported them (that's been
> said before about such things on other platforms.)

That would be my stance.

> However, there's another consideration to be had here before we can say
> that: how many people out there want to run a mainline (or even an
> updated kernel derived from mainline) on this device?  If there's a
> sizable following for the device wanting updated support, then it's
> something we really need to consider supporting inspite of our
> disappointment with Nokia inventing these "proprietary" tags.

If there is indeed a sizable following for the device then someone 
should figure out how to cope with upstream kernels, either through the 
installation of some intermediate bootloader that can talk FDT directly, 
or via a shim layer.  None of that has to be performed by nor linked 
with the kernel binary, nor maintained in the kernel tree. And it's not 
even that hard to do: we have precedents on other platforms with crappy 
bootloaders where this just works.


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 21:34                                     ` Nicolas Pitre
@ 2015-01-27 21:58                                       ` Nicolas Pitre
  -1 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-01-27 21:58 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Pali Rohár, Rob Herring, Pavel Machek, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel, Tony Lindgren

On Tue, 27 Jan 2015, Nicolas Pitre wrote:

> If there is indeed a sizable following for the device then someone 
> should figure out how to cope with upstream kernels, either through the 
> installation of some intermediate bootloader that can talk FDT directly, 
> or via a shim layer.  None of that has to be performed by nor linked 
> with the kernel binary, nor maintained in the kernel tree. And it's not 
> even that hard to do: we have precedents on other platforms with crappy 
> bootloaders where this just works.

For reference I recommend the following threads:

http://comments.gmane.org/gmane.linux.kbuild.devel/10722

http://www.spinics.net/lists/arm-kernel/msg249719.html


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 21:58                                       ` Nicolas Pitre
  0 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-01-27 21:58 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 27 Jan 2015, Nicolas Pitre wrote:

> If there is indeed a sizable following for the device then someone 
> should figure out how to cope with upstream kernels, either through the 
> installation of some intermediate bootloader that can talk FDT directly, 
> or via a shim layer.  None of that has to be performed by nor linked 
> with the kernel binary, nor maintained in the kernel tree. And it's not 
> even that hard to do: we have precedents on other platforms with crappy 
> bootloaders where this just works.

For reference I recommend the following threads:

http://comments.gmane.org/gmane.linux.kbuild.devel/10722

http://www.spinics.net/lists/arm-kernel/msg249719.html


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 21:34                                     ` Nicolas Pitre
@ 2015-01-27 22:33                                       ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-27 22:33 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Pali Rohár, Rob Herring, Pavel Machek, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel, Tony Lindgren

On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> > Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
> > and let the kernel deal with it in a much saner environment than the
> > restricted decompressor environment.
> 
> ... which would be a step backward in the context of the transition to 
> DT we accepted.  People will have even less of an incentive to fix their 
> stuff.

Where's the people fixing their stuff today?  I think your position is
something of an idealist rather than a realist - the reality is that
five years down the line of DT, the platforms which have not converted
are now *never* going to convert, irrespective of how much "incentive"
we may think we should apply to the situation.

So, at some point we have to start thinking as a realist rather than
an idealist, and realise that there are platforms out there which are
/never/ going to convert.

Most of my platforms here are /never/ going to convert to DT-only
booting quite simply because they don't have anyone working on that
stuff, and no one is willing to put the effort in.

The only platforms which I have which have converted are:
- OMAP SDP4430
- Versatile Express
- SolidRun Hummingboard & Cubox-i

Quite literally everything else is *never* going to support native DT
booting - and I'd go as far as to say that if I ever wanted to put the
effort in, I probably couldn't, because the boot loader sources aren't
available anymore.  (eg, the LDP3430 situation is such a mess that even
if the boot loader source is still available, identifying the correct
board version is near on impossible given the multitude of different
variants of the same product.)

The older Versatile and Integrator platforms, for example, are going
to be booting with the appended DTB for as long as they're around.
Most likely all the PXA platforms too, and, the IOP32x based N2100
boxes (which already need their kernels wrapped because the provided
boot loader has had environment saving disabled.)

As much as you may not like it, ATAGs are here to stay now, at least
on the older platforms, and no amount of "incentives" will change that.

> > However, there's another consideration to be had here before we can say
> > that: how many people out there want to run a mainline (or even an
> > updated kernel derived from mainline) on this device?  If there's a
> > sizable following for the device wanting updated support, then it's
> > something we really need to consider supporting inspite of our
> > disappointment with Nokia inventing these "proprietary" tags.
> 
> If there is indeed a sizable following for the device then someone 
> should figure out how to cope with upstream kernels, either through the 
> installation of some intermediate bootloader that can talk FDT directly, 
> or via a shim layer.  None of that has to be performed by nor linked 
> with the kernel binary, nor maintained in the kernel tree. And it's not 
> even that hard to do: we have precedents on other platforms with crappy 
> bootloaders where this just works.

That's a rediculous position if you want something which "just works"
on as much hardware as possible, which is, after all, what the single
zImage project is all about.

To be pro single-zImage, and anti popular hardware is quite contradictory.

You only have to look at x86 for this: just because ACPI came along does
not mean that the Linux kernel started demanding that ACPI is the only
way to describe the world.  Linux continues to directly support all the
old boot protocols that it did since the days of i386, such as the e820
memory interface and doesn't convert these to an ACPI table just because
it can.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 22:33                                       ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-27 22:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> > Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
> > and let the kernel deal with it in a much saner environment than the
> > restricted decompressor environment.
> 
> ... which would be a step backward in the context of the transition to 
> DT we accepted.  People will have even less of an incentive to fix their 
> stuff.

Where's the people fixing their stuff today?  I think your position is
something of an idealist rather than a realist - the reality is that
five years down the line of DT, the platforms which have not converted
are now *never* going to convert, irrespective of how much "incentive"
we may think we should apply to the situation.

So, at some point we have to start thinking as a realist rather than
an idealist, and realise that there are platforms out there which are
/never/ going to convert.

Most of my platforms here are /never/ going to convert to DT-only
booting quite simply because they don't have anyone working on that
stuff, and no one is willing to put the effort in.

The only platforms which I have which have converted are:
- OMAP SDP4430
- Versatile Express
- SolidRun Hummingboard & Cubox-i

Quite literally everything else is *never* going to support native DT
booting - and I'd go as far as to say that if I ever wanted to put the
effort in, I probably couldn't, because the boot loader sources aren't
available anymore.  (eg, the LDP3430 situation is such a mess that even
if the boot loader source is still available, identifying the correct
board version is near on impossible given the multitude of different
variants of the same product.)

The older Versatile and Integrator platforms, for example, are going
to be booting with the appended DTB for as long as they're around.
Most likely all the PXA platforms too, and, the IOP32x based N2100
boxes (which already need their kernels wrapped because the provided
boot loader has had environment saving disabled.)

As much as you may not like it, ATAGs are here to stay now, at least
on the older platforms, and no amount of "incentives" will change that.

> > However, there's another consideration to be had here before we can say
> > that: how many people out there want to run a mainline (or even an
> > updated kernel derived from mainline) on this device?  If there's a
> > sizable following for the device wanting updated support, then it's
> > something we really need to consider supporting inspite of our
> > disappointment with Nokia inventing these "proprietary" tags.
> 
> If there is indeed a sizable following for the device then someone 
> should figure out how to cope with upstream kernels, either through the 
> installation of some intermediate bootloader that can talk FDT directly, 
> or via a shim layer.  None of that has to be performed by nor linked 
> with the kernel binary, nor maintained in the kernel tree. And it's not 
> even that hard to do: we have precedents on other platforms with crappy 
> bootloaders where this just works.

That's a rediculous position if you want something which "just works"
on as much hardware as possible, which is, after all, what the single
zImage project is all about.

To be pro single-zImage, and anti popular hardware is quite contradictory.

You only have to look at x86 for this: just because ACPI came along does
not mean that the Linux kernel started demanding that ACPI is the only
way to describe the world.  Linux continues to directly support all the
old boot protocols that it did since the days of i386, such as the e820
memory interface and doesn't convert these to an ACPI table just because
it can.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 21:34                                     ` Nicolas Pitre
@ 2015-01-27 23:10                                       ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-27 23:10 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Russell King - ARM Linux, Pali Rohár, Rob Herring,
	Will Deacon, Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel, Tony Lindgren

Hi!

> > > Useful when properly designed and generic enough to be shared.
> > > 
> > > I'd suggest a DT property be proposed for that purpose if it doesn't 
> > > already exist.  That at least has a chance to be generically useful.
> > 
> > What this means is that we have to further augment the atags-to-dt code
> > in the decompressor with the platform specific ATAGs to parse this
> > information and merge it into the appended DT before passing the
> > resulting DT blob to the kernel.
> 
> That would be only 2 new lines of code in the best case.

Yes, instead of 2 new lines of code, let people write, debug, and
flash 1000 lines shim. Completely makes sense.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-27 23:10                                       ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-27 23:10 UTC (permalink / raw)
  To: linux-arm-kernel

Hi!

> > > Useful when properly designed and generic enough to be shared.
> > > 
> > > I'd suggest a DT property be proposed for that purpose if it doesn't 
> > > already exist.  That at least has a chance to be generically useful.
> > 
> > What this means is that we have to further augment the atags-to-dt code
> > in the decompressor with the platform specific ATAGs to parse this
> > information and merge it into the appended DT before passing the
> > resulting DT blob to the kernel.
> 
> That would be only 2 new lines of code in the best case.

Yes, instead of 2 new lines of code, let people write, debug, and
flash 1000 lines shim. Completely makes sense.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 17:48                               ` Russell King - ARM Linux
@ 2015-01-28  0:50                                 ` Tony Lindgren
  -1 siblings, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-01-28  0:50 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Pali Rohár, Rob Herring, Pavel Machek, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [150127 09:51]:
> 
> We _could_ (and have in the past) turned round and refused to support
> these kinds of hacks - which IMHO is quite a reasonable stance to
> take: the message we should be sending is "if you wish to design
> new methods without discussing it with us, we reserve the right not
> to support them in mainline kernels; please discuss with us your
> requirements."
> 
> Each time that we accept one of these hacks, we're sending a message
> that says "it's okay to work in this crappy way".
> 
> Yes, I realise that the N900 has little in the way of support, and we
> can't exert that kind of back pressure (since there's no one to direct
> that onto to effect any change) so I guess we just have to live with it.

I believe after N900 Nokia dropped the custom ATAGs and used the
kernel cmdline instead. And most of the n900 custom ATAGs are not
even needed any longer.

The ATAG_REVISION is a standard feature that we should support
naturally. I don't think we should add any custom ATAGs, except
maybe for the bootreason.
 
> > I think this kind of information (how was board/computer started) 
> > can be useful also for other architectures. E.g. on laptop you 
> > would like to know if if was started by RTC, power button, 
> > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > And scripts can act depending on this event (when by RTC, you 
> > need to run some planned job, when by watchdog reset you should 
> > check what caused that reason...).
> 
> There is a standard way to get the boot information already: look at
> the watchdog API:
> 
> #define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2, int)
> 
> which uses the WDIOF_* flags to indicate the last boot reason.  It
> probably isn't as flexible as some may desire, but it should provide
> at least the "watchdog rebooted us" vs "over temperature" vs some
> other boot reason.
> 
> The other thing to consider is whether we have a way to know what
> the boot reason was, and what we should do if we do not have a way
> of supporting some of the boot reasons.  For example, if we have
> support for RTC alarm based booting, but no way to actually tell
> if the boot was caused by the RTC alarm triggering.

On omaps, the bootrom passes the bootreason in r1 to the bootloader
that can do whatever it wants with it. We could maybe pass it
in the kernel cmdline to the watchdog driver for user space?

Of course the problem is that the signed bootloader on n900 cannot
be modified so the pass through u-boot would have to translate
the custom ATAG for bootreason into a kernel cmdline..

But it may actually make sense to add the bootreason ATAGs, it
seems quite generic to me.

AFAIK, the other n900 ATAGs can be just ignored.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28  0:50                                 ` Tony Lindgren
  0 siblings, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-01-28  0:50 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [150127 09:51]:
> 
> We _could_ (and have in the past) turned round and refused to support
> these kinds of hacks - which IMHO is quite a reasonable stance to
> take: the message we should be sending is "if you wish to design
> new methods without discussing it with us, we reserve the right not
> to support them in mainline kernels; please discuss with us your
> requirements."
> 
> Each time that we accept one of these hacks, we're sending a message
> that says "it's okay to work in this crappy way".
> 
> Yes, I realise that the N900 has little in the way of support, and we
> can't exert that kind of back pressure (since there's no one to direct
> that onto to effect any change) so I guess we just have to live with it.

I believe after N900 Nokia dropped the custom ATAGs and used the
kernel cmdline instead. And most of the n900 custom ATAGs are not
even needed any longer.

The ATAG_REVISION is a standard feature that we should support
naturally. I don't think we should add any custom ATAGs, except
maybe for the bootreason.
 
> > I think this kind of information (how was board/computer started) 
> > can be useful also for other architectures. E.g. on laptop you 
> > would like to know if if was started by RTC, power button, 
> > WakeOnLan, another ACPI event, rebooted machine, watchdog, etc... 
> > And scripts can act depending on this event (when by RTC, you 
> > need to run some planned job, when by watchdog reset you should 
> > check what caused that reason...).
> 
> There is a standard way to get the boot information already: look at
> the watchdog API:
> 
> #define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2, int)
> 
> which uses the WDIOF_* flags to indicate the last boot reason.  It
> probably isn't as flexible as some may desire, but it should provide
> at least the "watchdog rebooted us" vs "over temperature" vs some
> other boot reason.
> 
> The other thing to consider is whether we have a way to know what
> the boot reason was, and what we should do if we do not have a way
> of supporting some of the boot reasons.  For example, if we have
> support for RTC alarm based booting, but no way to actually tell
> if the boot was caused by the RTC alarm triggering.

On omaps, the bootrom passes the bootreason in r1 to the bootloader
that can do whatever it wants with it. We could maybe pass it
in the kernel cmdline to the watchdog driver for user space?

Of course the problem is that the signed bootloader on n900 cannot
be modified so the pass through u-boot would have to translate
the custom ATAG for bootreason into a kernel cmdline..

But it may actually make sense to add the bootreason ATAGs, it
seems quite generic to me.

AFAIK, the other n900 ATAGs can be just ignored.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-27 22:33                                       ` Russell King - ARM Linux
@ 2015-01-28  2:07                                         ` Nicolas Pitre
  -1 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-01-28  2:07 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Pali Rohár, Rob Herring, Pavel Machek, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel, Tony Lindgren

On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:

> On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
> > On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> > > Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
> > > and let the kernel deal with it in a much saner environment than the
> > > restricted decompressor environment.
> > 
> > ... which would be a step backward in the context of the transition to 
> > DT we accepted.  People will have even less of an incentive to fix their 
> > stuff.
> 
> Where's the people fixing their stuff today?

At least some people in this thread are, otherwise they'd still be away 
hacking on their own.

> I think your position is something of an idealist rather than a 
> realist - the reality is that five years down the line of DT, the 
> platforms which have not converted are now *never* going to convert, 
> irrespective of how much "incentive" we may think we should apply to 
> the situation.

Don't get me wrong.  I'm not expecting those platforms to do native DT 
booting ever.  However "faking" DT booting with already proven solutions 
that don't bastardize the kernel further should be encouraged.

> > If there is indeed a sizable following for the device then someone 
> > should figure out how to cope with upstream kernels, either through the 
> > installation of some intermediate bootloader that can talk FDT directly, 
> > or via a shim layer.  None of that has to be performed by nor linked 
> > with the kernel binary, nor maintained in the kernel tree. And it's not 
> > even that hard to do: we have precedents on other platforms with crappy 
> > bootloaders where this just works.
> 
> That's a rediculous position if you want something which "just works"
> on as much hardware as possible, which is, after all, what the single
> zImage project is all about.

Agreed.

> To be pro single-zImage, and anti popular hardware is quite contradictory.

Indeed.  I'm not against popular hardware.

> You only have to look at x86 for this: just because ACPI came along does
> not mean that the Linux kernel started demanding that ACPI is the only
> way to describe the world.  Linux continues to directly support all the
> old boot protocols that it did since the days of i386, such as the e820
> memory interface and doesn't convert these to an ACPI table just because
> it can.

Booting from a floppy boot sector is no longer supported though.

But that's besides the point.  If someone needs a 5-line addition to 
atags_to_fdt.c in order to boot some old stuff then let's just do it and 
move on. I'll happily ACK the patch. The code is there and it is not 
going away soon.

However, if something more involved is needed, is platform specific and 
is likely to require about as many lines in the kernel than it would 
need in some externat shim then the shim solution should be encouraged 
instead.  After all that's why LILO, Syslinux and Grub were created on 
X86: to Supplement the crappy PC BIOS boot interface.  And if the 
hardware is popular, then finding a motivated hacker to do it shouldn't 
be too hard, right?

In other words, what prevents someone from creating, say, a custom 
minimal Barebox version that sits on top of the existing N900 
bootloader?  Wouldn't that provide a much better user experience?


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28  2:07                                         ` Nicolas Pitre
  0 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-01-28  2:07 UTC (permalink / raw)
  To: linux-arm-kernel

On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:

> On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
> > On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> > > Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
> > > and let the kernel deal with it in a much saner environment than the
> > > restricted decompressor environment.
> > 
> > ... which would be a step backward in the context of the transition to 
> > DT we accepted.  People will have even less of an incentive to fix their 
> > stuff.
> 
> Where's the people fixing their stuff today?

At least some people in this thread are, otherwise they'd still be away 
hacking on their own.

> I think your position is something of an idealist rather than a 
> realist - the reality is that five years down the line of DT, the 
> platforms which have not converted are now *never* going to convert, 
> irrespective of how much "incentive" we may think we should apply to 
> the situation.

Don't get me wrong.  I'm not expecting those platforms to do native DT 
booting ever.  However "faking" DT booting with already proven solutions 
that don't bastardize the kernel further should be encouraged.

> > If there is indeed a sizable following for the device then someone 
> > should figure out how to cope with upstream kernels, either through the 
> > installation of some intermediate bootloader that can talk FDT directly, 
> > or via a shim layer.  None of that has to be performed by nor linked 
> > with the kernel binary, nor maintained in the kernel tree. And it's not 
> > even that hard to do: we have precedents on other platforms with crappy 
> > bootloaders where this just works.
> 
> That's a rediculous position if you want something which "just works"
> on as much hardware as possible, which is, after all, what the single
> zImage project is all about.

Agreed.

> To be pro single-zImage, and anti popular hardware is quite contradictory.

Indeed.  I'm not against popular hardware.

> You only have to look at x86 for this: just because ACPI came along does
> not mean that the Linux kernel started demanding that ACPI is the only
> way to describe the world.  Linux continues to directly support all the
> old boot protocols that it did since the days of i386, such as the e820
> memory interface and doesn't convert these to an ACPI table just because
> it can.

Booting from a floppy boot sector is no longer supported though.

But that's besides the point.  If someone needs a 5-line addition to 
atags_to_fdt.c in order to boot some old stuff then let's just do it and 
move on. I'll happily ACK the patch. The code is there and it is not 
going away soon.

However, if something more involved is needed, is platform specific and 
is likely to require about as many lines in the kernel than it would 
need in some externat shim then the shim solution should be encouraged 
instead.  After all that's why LILO, Syslinux and Grub were created on 
X86: to Supplement the crappy PC BIOS boot interface.  And if the 
hardware is popular, then finding a motivated hacker to do it shouldn't 
be too hard, right?

In other words, what prevents someone from creating, say, a custom 
minimal Barebox version that sits on top of the existing N900 
bootloader?  Wouldn't that provide a much better user experience?


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28  2:07                                         ` Nicolas Pitre
@ 2015-01-28  6:21                                           ` Jean-Christophe PLAGNIOL-VILLARD
  -1 siblings, 0 replies; 197+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-01-28  6:21 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Jean-Christophe PLAGNIOL-VILLARD, Russell King - ARM Linux,
	Ivaylo Dimitrov, Tony Lindgren, Sebastian Reichel, Will Deacon,
	linux-kernel, Pavel Machek, Pali Rohár, linux-arm-kernel


> On Jan 28, 2015, at 10:07 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> 
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> 
>> On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
>>> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
>>>> Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
>>>> and let the kernel deal with it in a much saner environment than the
>>>> restricted decompressor environment.
>>> 
>>> ... which would be a step backward in the context of the transition to 
>>> DT we accepted.  People will have even less of an incentive to fix their 
>>> stuff.
>> 
>> Where's the people fixing their stuff today?
> 
> At least some people in this thread are, otherwise they'd still be away 
> hacking on their own.
> 
>> I think your position is something of an idealist rather than a 
>> realist - the reality is that five years down the line of DT, the 
>> platforms which have not converted are now *never* going to convert, 
>> irrespective of how much "incentive" we may think we should apply to 
>> the situation.
> 
> Don't get me wrong.  I'm not expecting those platforms to do native DT 
> booting ever.  However "faking" DT booting with already proven solutions 
> that don't bastardize the kernel further should be encouraged.
> 
>>> If there is indeed a sizable following for the device then someone 
>>> should figure out how to cope with upstream kernels, either through the 
>>> installation of some intermediate bootloader that can talk FDT directly, 
>>> or via a shim layer.  None of that has to be performed by nor linked 
>>> with the kernel binary, nor maintained in the kernel tree. And it's not 
>>> even that hard to do: we have precedents on other platforms with crappy 
>>> bootloaders where this just works.
>> 
>> That's a rediculous position if you want something which "just works"
>> on as much hardware as possible, which is, after all, what the single
>> zImage project is all about.
> 
> Agreed.
> 
>> To be pro single-zImage, and anti popular hardware is quite contradictory.
> 
> Indeed.  I'm not against popular hardware.
> 
>> You only have to look at x86 for this: just because ACPI came along does
>> not mean that the Linux kernel started demanding that ACPI is the only
>> way to describe the world.  Linux continues to directly support all the
>> old boot protocols that it did since the days of i386, such as the e820
>> memory interface and doesn't convert these to an ACPI table just because
>> it can.
> 
> Booting from a floppy boot sector is no longer supported though.
> 
> But that's besides the point.  If someone needs a 5-line addition to 
> atags_to_fdt.c in order to boot some old stuff then let's just do it and 
> move on. I'll happily ACK the patch. The code is there and it is not 
> going away soon.
> 
> However, if something more involved is needed, is platform specific and 
> is likely to require about as many lines in the kernel than it would 
> need in some externat shim then the shim solution should be encouraged 
> instead.  After all that's why LILO, Syslinux and Grub were created on 
> X86: to Supplement the crappy PC BIOS boot interface.  And if the 
> hardware is popular, then finding a motivated hacker to do it shouldn't 
> be too hard, right?
> 
> In other words, what prevents someone from creating, say, a custom 
> minimal Barebox version that sits on top of the existing N900 
> bootloader?  Wouldn't that provide a much better user experience?

I do agree with Nicolas

If I can get my hand on a phone I’ll put barebox on it

Best Regards,
J.
> 
> 
> Nicolas
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28  6:21                                           ` Jean-Christophe PLAGNIOL-VILLARD
  0 siblings, 0 replies; 197+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-01-28  6:21 UTC (permalink / raw)
  To: linux-arm-kernel


> On Jan 28, 2015, at 10:07 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> 
> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
> 
>> On Tue, Jan 27, 2015 at 04:34:47PM -0500, Nicolas Pitre wrote:
>>> On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
>>>> Or we pass both the ATAGs and wrapped DT to the kernel when both exist,
>>>> and let the kernel deal with it in a much saner environment than the
>>>> restricted decompressor environment.
>>> 
>>> ... which would be a step backward in the context of the transition to 
>>> DT we accepted.  People will have even less of an incentive to fix their 
>>> stuff.
>> 
>> Where's the people fixing their stuff today?
> 
> At least some people in this thread are, otherwise they'd still be away 
> hacking on their own.
> 
>> I think your position is something of an idealist rather than a 
>> realist - the reality is that five years down the line of DT, the 
>> platforms which have not converted are now *never* going to convert, 
>> irrespective of how much "incentive" we may think we should apply to 
>> the situation.
> 
> Don't get me wrong.  I'm not expecting those platforms to do native DT 
> booting ever.  However "faking" DT booting with already proven solutions 
> that don't bastardize the kernel further should be encouraged.
> 
>>> If there is indeed a sizable following for the device then someone 
>>> should figure out how to cope with upstream kernels, either through the 
>>> installation of some intermediate bootloader that can talk FDT directly, 
>>> or via a shim layer.  None of that has to be performed by nor linked 
>>> with the kernel binary, nor maintained in the kernel tree. And it's not 
>>> even that hard to do: we have precedents on other platforms with crappy 
>>> bootloaders where this just works.
>> 
>> That's a rediculous position if you want something which "just works"
>> on as much hardware as possible, which is, after all, what the single
>> zImage project is all about.
> 
> Agreed.
> 
>> To be pro single-zImage, and anti popular hardware is quite contradictory.
> 
> Indeed.  I'm not against popular hardware.
> 
>> You only have to look at x86 for this: just because ACPI came along does
>> not mean that the Linux kernel started demanding that ACPI is the only
>> way to describe the world.  Linux continues to directly support all the
>> old boot protocols that it did since the days of i386, such as the e820
>> memory interface and doesn't convert these to an ACPI table just because
>> it can.
> 
> Booting from a floppy boot sector is no longer supported though.
> 
> But that's besides the point.  If someone needs a 5-line addition to 
> atags_to_fdt.c in order to boot some old stuff then let's just do it and 
> move on. I'll happily ACK the patch. The code is there and it is not 
> going away soon.
> 
> However, if something more involved is needed, is platform specific and 
> is likely to require about as many lines in the kernel than it would 
> need in some externat shim then the shim solution should be encouraged 
> instead.  After all that's why LILO, Syslinux and Grub were created on 
> X86: to Supplement the crappy PC BIOS boot interface.  And if the 
> hardware is popular, then finding a motivated hacker to do it shouldn't 
> be too hard, right?
> 
> In other words, what prevents someone from creating, say, a custom 
> minimal Barebox version that sits on top of the existing N900 
> bootloader?  Wouldn't that provide a much better user experience?

I do agree with Nicolas

If I can get my hand on a phone I?ll put barebox on it

Best Regards,
J.
> 
> 
> Nicolas
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28  2:07                                         ` Nicolas Pitre
@ 2015-01-28  7:18                                           ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-28  7:18 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Russell King - ARM Linux, Pali Rohár, Rob Herring,
	Will Deacon, Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel, Tony Lindgren

Hi!

> In other words, what prevents someone from creating, say, a custom 
> minimal Barebox version that sits on top of the existing N900 
> bootloader?  Wouldn't that provide a much better user experience?

Lot of useless work, that would make user experience worse?

We have mostly working u-boot on N900. Its there, useful for boot
menus, but makes debugging tricky, so we want to keep working with
internal bootloader, too. And I have already explained this to you
before.

Now, would you stop assigning work to other people?

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28  7:18                                           ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-28  7:18 UTC (permalink / raw)
  To: linux-arm-kernel

Hi!

> In other words, what prevents someone from creating, say, a custom 
> minimal Barebox version that sits on top of the existing N900 
> bootloader?  Wouldn't that provide a much better user experience?

Lot of useless work, that would make user experience worse?

We have mostly working u-boot on N900. Its there, useful for boot
menus, but makes debugging tricky, so we want to keep working with
internal bootloader, too. And I have already explained this to you
before.

Now, would you stop assigning work to other people?

Thanks,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28  6:21                                           ` Jean-Christophe PLAGNIOL-VILLARD
@ 2015-01-28  7:19                                             ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-28  7:19 UTC (permalink / raw)
  To: Jean-Christophe PLAGNIOL-VILLARD
  Cc: Nicolas Pitre, Russell King - ARM Linux, Ivaylo Dimitrov,
	Tony Lindgren, Sebastian Reichel, Will Deacon, linux-kernel,
	Pali Rohár, linux-arm-kernel

Hi!

> > In other words, what prevents someone from creating, say, a custom 
> > minimal Barebox version that sits on top of the existing N900 
> > bootloader?  Wouldn't that provide a much better user experience?
> 
> I do agree with Nicolas
> 
> If I can get my hand on a phone I’ll put barebox on it

Grab it in the nearest "second hand cellphones" shop, and have fun! It
should be less than $70.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28  7:19                                             ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-28  7:19 UTC (permalink / raw)
  To: linux-arm-kernel

Hi!

> > In other words, what prevents someone from creating, say, a custom 
> > minimal Barebox version that sits on top of the existing N900 
> > bootloader?  Wouldn't that provide a much better user experience?
> 
> I do agree with Nicolas
> 
> If I can get my hand on a phone I?ll put barebox on it

Grab it in the nearest "second hand cellphones" shop, and have fun! It
should be less than $70.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28  7:19                                             ` Pavel Machek
@ 2015-01-28  8:06                                               ` Jean-Christophe PLAGNIOL-VILLARD
  -1 siblings, 0 replies; 197+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-01-28  8:06 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Jean-Christophe PLAGNIOL-VILLARD, Nicolas Pitre,
	Russell King - ARM Linux, Ivaylo Dimitrov, Tony Lindgren,
	Sebastian Reichel, Will Deacon, linux-kernel, Pali Rohár,
	linux-arm-kernel


> On Jan 28, 2015, at 3:19 PM, Pavel Machek <pavel@ucw.cz> wrote:
> 
> Hi!
> 
>>> In other words, what prevents someone from creating, say, a custom 
>>> minimal Barebox version that sits on top of the existing N900 
>>> bootloader?  Wouldn't that provide a much better user experience?
>> 
>> I do agree with Nicolas
>> 
>> If I can get my hand on a phone I’ll put barebox on it
> 
> Grab it in the nearest "second hand cellphones" shop, and have fun! It
> should be less than $70.

will see if I can found one in Shanghai at the second hand market

Does it exist a qemu emulation?

Best Regards,
J.
> 									Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28  8:06                                               ` Jean-Christophe PLAGNIOL-VILLARD
  0 siblings, 0 replies; 197+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-01-28  8:06 UTC (permalink / raw)
  To: linux-arm-kernel


> On Jan 28, 2015, at 3:19 PM, Pavel Machek <pavel@ucw.cz> wrote:
> 
> Hi!
> 
>>> In other words, what prevents someone from creating, say, a custom 
>>> minimal Barebox version that sits on top of the existing N900 
>>> bootloader?  Wouldn't that provide a much better user experience?
>> 
>> I do agree with Nicolas
>> 
>> If I can get my hand on a phone I?ll put barebox on it
> 
> Grab it in the nearest "second hand cellphones" shop, and have fun! It
> should be less than $70.

will see if I can found one in Shanghai at the second hand market

Does it exist a qemu emulation?

Best Regards,
J.
> 									Pavel
> -- 
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28  8:06                                               ` Jean-Christophe PLAGNIOL-VILLARD
@ 2015-01-28  8:25                                                 ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-28  8:25 UTC (permalink / raw)
  To: Jean-Christophe PLAGNIOL-VILLARD
  Cc: Nicolas Pitre, Russell King - ARM Linux, Ivaylo Dimitrov,
	Tony Lindgren, Sebastian Reichel, Will Deacon, linux-kernel,
	Pali Rohár, linux-arm-kernel

On Wed 2015-01-28 16:06:17, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > On Jan 28, 2015, at 3:19 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > 
> > Hi!
> > 
> >>> In other words, what prevents someone from creating, say, a custom 
> >>> minimal Barebox version that sits on top of the existing N900 
> >>> bootloader?  Wouldn't that provide a much better user experience?
> >> 
> >> I do agree with Nicolas
> >> 
> >> If I can get my hand on a phone I’ll put barebox on it
> > 
> > Grab it in the nearest "second hand cellphones" shop, and have fun! It
> > should be less than $70.
> 
> will see if I can found one in Shanghai at the second hand market
> 
> Does it exist a qemu emulation?

Yes, linaro-qemu supports it. (But people are trying to break it
"because it is not real hardware so it can be fixed").

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28  8:25                                                 ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-28  8:25 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed 2015-01-28 16:06:17, Jean-Christophe PLAGNIOL-VILLARD wrote:
> 
> > On Jan 28, 2015, at 3:19 PM, Pavel Machek <pavel@ucw.cz> wrote:
> > 
> > Hi!
> > 
> >>> In other words, what prevents someone from creating, say, a custom 
> >>> minimal Barebox version that sits on top of the existing N900 
> >>> bootloader?  Wouldn't that provide a much better user experience?
> >> 
> >> I do agree with Nicolas
> >> 
> >> If I can get my hand on a phone I?ll put barebox on it
> > 
> > Grab it in the nearest "second hand cellphones" shop, and have fun! It
> > should be less than $70.
> 
> will see if I can found one in Shanghai at the second hand market
> 
> Does it exist a qemu emulation?

Yes, linaro-qemu supports it. (But people are trying to break it
"because it is not real hardware so it can be fixed").

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28  2:07                                         ` Nicolas Pitre
@ 2015-01-28 13:38                                           ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-28 13:38 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Russell King - ARM Linux, Rob Herring, Pavel Machek, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel, Tony Lindgren

[-- Attachment #1: Type: Text/Plain, Size: 779 bytes --]

On Wednesday 28 January 2015 03:07:43 Nicolas Pitre wrote:
> In other words, what prevents someone from creating, say, a
> custom minimal Barebox version that sits on top of the
> existing N900 bootloader?  Wouldn't that provide a much
> better user experience?
> 

Strong cryptography used for signing first stage bootloader, 
undocumented interface and other stuff which initialize HW and 
small memory (about 100kB) for second stage non-signed 
bootloader. Next kernel image is limited to size 2MB. And 
currently uboot can be compiled to act as "kernel" image, so 
second stage bootloader can boot it.

I spend some time to replace second (non signed) bootloader with 
something other, but really it is not possible.

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 13:38                                           ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-28 13:38 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 28 January 2015 03:07:43 Nicolas Pitre wrote:
> In other words, what prevents someone from creating, say, a
> custom minimal Barebox version that sits on top of the
> existing N900 bootloader?  Wouldn't that provide a much
> better user experience?
> 

Strong cryptography used for signing first stage bootloader, 
undocumented interface and other stuff which initialize HW and 
small memory (about 100kB) for second stage non-signed 
bootloader. Next kernel image is limited to size 2MB. And 
currently uboot can be compiled to act as "kernel" image, so 
second stage bootloader can boot it.

I spend some time to replace second (non signed) bootloader with 
something other, but really it is not possible.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150128/3a1db462/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28  0:50                                 ` Tony Lindgren
@ 2015-01-28 13:58                                   ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-28 13:58 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Russell King - ARM Linux, Rob Herring, Pavel Machek, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, linux-kernel,
	linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 4977 bytes --]

On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [150127 
09:51]:
> > We _could_ (and have in the past) turned round and refused
> > to support these kinds of hacks - which IMHO is quite a
> > reasonable stance to take: the message we should be sending
> > is "if you wish to design new methods without discussing it
> > with us, we reserve the right not to support them in
> > mainline kernels; please discuss with us your
> > requirements."
> > 
> > Each time that we accept one of these hacks, we're sending a
> > message that says "it's okay to work in this crappy way".
> > 
> > Yes, I realise that the N900 has little in the way of
> > support, and we can't exert that kind of back pressure
> > (since there's no one to direct that onto to effect any
> > change) so I guess we just have to live with it.
> 
> I believe after N900 Nokia dropped the custom ATAGs and used
> the kernel cmdline instead. And most of the n900 custom ATAGs
> are not even needed any longer.
> 

Yes, almost all N900 ATAGs are static and are already hardcoded 
into kernel or DT file.

Basically there are 4 non static values which are used:

1. ATAG_REVISION

2. ATAG_OMAP
2.1 OMAP_TAG_BOOT_REASON --> boot reason
2.2 OMAP_TAG_VERSION ("nolo") --> for bootloader version
2.3 OMAP_TAG_VERSION ("boot-mode") --> "normal" or "update"

ATAG_OMAP is non standard and contains sub-atags.

bootloader version is static now (as Nokia does not develop it 
anymore), but boot reason and boot mode are set by bootloader and 
are needed for userspace. boot mode tells init system/userspace 
if to start normal OS or only small subset for flashing.

> The ATAG_REVISION is a standard feature that we should support
> naturally. I don't think we should add any custom ATAGs,
> except maybe for the bootreason.
> 
> > > I think this kind of information (how was board/computer
> > > started) can be useful also for other architectures. E.g.
> > > on laptop you would like to know if if was started by
> > > RTC, power button, WakeOnLan, another ACPI event,
> > > rebooted machine, watchdog, etc... And scripts can act
> > > depending on this event (when by RTC, you need to run
> > > some planned job, when by watchdog reset you should check
> > > what caused that reason...).
> > 
> > There is a standard way to get the boot information already:
> > look at the watchdog API:
> > 
> > #define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2,
> > int)
> > 
> > which uses the WDIOF_* flags to indicate the last boot
> > reason.  It probably isn't as flexible as some may desire,
> > but it should provide at least the "watchdog rebooted us"
> > vs "over temperature" vs some other boot reason.
> > 
> > The other thing to consider is whether we have a way to know
> > what the boot reason was, and what we should do if we do
> > not have a way of supporting some of the boot reasons.  For
> > example, if we have support for RTC alarm based booting,
> > but no way to actually tell if the boot was caused by the
> > RTC alarm triggering.
> 
> On omaps, the bootrom passes the bootreason in r1 to the
> bootloader that can do whatever it wants with it. We could
> maybe pass it in the kernel cmdline to the watchdog driver
> for user space?
> 

Not truth for N900. Bootreason depends on PRM_RSTST omap 
register, state of vbat charger pins, time how long was power key 
pressed, R&D data stored in CAL partition and other undocumented 
registers for omap HS devices. I already tried to implement at 
least some subset of it in userspace (or kernel), but it is 
impossible because NOLO bootloader clear status of PRM_RSTST 
register.

There is also copy of PRM_RSTST register stored at address 
0x4020FFB8 (tracing data) but that address is rewritten (probably 
by kernel), so we really cannot implement reading bootreason in 
kernel.

But in early stage in uboot it is possible to read 0x4020FFB8 
address and get some part of bootreason. But still PRM_RSTST is 
not enough!

I would be happy if DT kernel can export /proc/atags file with 
ATAGs passed by bootloader. It would be enough for me. In 
userspace I can parse content and do what is needed.

In non DT kernel file /proc/atags is always exported.

> Of course the problem is that the signed bootloader on n900
> cannot be modified so the pass through u-boot would have to
> translate the custom ATAG for bootreason into a kernel
> cmdline..
> 
> But it may actually make sense to add the bootreason ATAGs, it
> seems quite generic to me.
> 

Which bootreason atag? Invent new? Or use above big ATAG_OMAP 
structure? Inventing new does not solve anything because all 
developers does not boot kernel for debugging from uboot -- but 
directly.

> AFAIK, the other n900 ATAGs can be just ignored.
> 
> Regards,
> 
> Tony

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 13:58                                   ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-28 13:58 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [150127 
09:51]:
> > We _could_ (and have in the past) turned round and refused
> > to support these kinds of hacks - which IMHO is quite a
> > reasonable stance to take: the message we should be sending
> > is "if you wish to design new methods without discussing it
> > with us, we reserve the right not to support them in
> > mainline kernels; please discuss with us your
> > requirements."
> > 
> > Each time that we accept one of these hacks, we're sending a
> > message that says "it's okay to work in this crappy way".
> > 
> > Yes, I realise that the N900 has little in the way of
> > support, and we can't exert that kind of back pressure
> > (since there's no one to direct that onto to effect any
> > change) so I guess we just have to live with it.
> 
> I believe after N900 Nokia dropped the custom ATAGs and used
> the kernel cmdline instead. And most of the n900 custom ATAGs
> are not even needed any longer.
> 

Yes, almost all N900 ATAGs are static and are already hardcoded 
into kernel or DT file.

Basically there are 4 non static values which are used:

1. ATAG_REVISION

2. ATAG_OMAP
2.1 OMAP_TAG_BOOT_REASON --> boot reason
2.2 OMAP_TAG_VERSION ("nolo") --> for bootloader version
2.3 OMAP_TAG_VERSION ("boot-mode") --> "normal" or "update"

ATAG_OMAP is non standard and contains sub-atags.

bootloader version is static now (as Nokia does not develop it 
anymore), but boot reason and boot mode are set by bootloader and 
are needed for userspace. boot mode tells init system/userspace 
if to start normal OS or only small subset for flashing.

> The ATAG_REVISION is a standard feature that we should support
> naturally. I don't think we should add any custom ATAGs,
> except maybe for the bootreason.
> 
> > > I think this kind of information (how was board/computer
> > > started) can be useful also for other architectures. E.g.
> > > on laptop you would like to know if if was started by
> > > RTC, power button, WakeOnLan, another ACPI event,
> > > rebooted machine, watchdog, etc... And scripts can act
> > > depending on this event (when by RTC, you need to run
> > > some planned job, when by watchdog reset you should check
> > > what caused that reason...).
> > 
> > There is a standard way to get the boot information already:
> > look at the watchdog API:
> > 
> > #define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2,
> > int)
> > 
> > which uses the WDIOF_* flags to indicate the last boot
> > reason.  It probably isn't as flexible as some may desire,
> > but it should provide at least the "watchdog rebooted us"
> > vs "over temperature" vs some other boot reason.
> > 
> > The other thing to consider is whether we have a way to know
> > what the boot reason was, and what we should do if we do
> > not have a way of supporting some of the boot reasons.  For
> > example, if we have support for RTC alarm based booting,
> > but no way to actually tell if the boot was caused by the
> > RTC alarm triggering.
> 
> On omaps, the bootrom passes the bootreason in r1 to the
> bootloader that can do whatever it wants with it. We could
> maybe pass it in the kernel cmdline to the watchdog driver
> for user space?
> 

Not truth for N900. Bootreason depends on PRM_RSTST omap 
register, state of vbat charger pins, time how long was power key 
pressed, R&D data stored in CAL partition and other undocumented 
registers for omap HS devices. I already tried to implement at 
least some subset of it in userspace (or kernel), but it is 
impossible because NOLO bootloader clear status of PRM_RSTST 
register.

There is also copy of PRM_RSTST register stored at address 
0x4020FFB8 (tracing data) but that address is rewritten (probably 
by kernel), so we really cannot implement reading bootreason in 
kernel.

But in early stage in uboot it is possible to read 0x4020FFB8 
address and get some part of bootreason. But still PRM_RSTST is 
not enough!

I would be happy if DT kernel can export /proc/atags file with 
ATAGs passed by bootloader. It would be enough for me. In 
userspace I can parse content and do what is needed.

In non DT kernel file /proc/atags is always exported.

> Of course the problem is that the signed bootloader on n900
> cannot be modified so the pass through u-boot would have to
> translate the custom ATAG for bootreason into a kernel
> cmdline..
> 
> But it may actually make sense to add the bootreason ATAGs, it
> seems quite generic to me.
> 

Which bootreason atag? Invent new? Or use above big ATAG_OMAP 
structure? Inventing new does not solve anything because all 
developers does not boot kernel for debugging from uboot -- but 
directly.

> AFAIK, the other n900 ATAGs can be just ignored.
> 
> Regards,
> 
> Tony

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150128/0c252bff/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 13:58                                   ` Pali Rohár
  (?)
@ 2015-01-28 14:33                                   ` Nicolas Pitre
  2015-01-28 15:39                                       ` Tony Lindgren
  2015-01-28 15:57                                       ` Rob Herring
  -1 siblings, 2 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-01-28 14:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, 28 Jan 2015, Pali Roh?r wrote:

> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> > On omaps, the bootrom passes the bootreason in r1 to the
> > bootloader that can do whatever it wants with it. We could
> > maybe pass it in the kernel cmdline to the watchdog driver
> > for user space?
> > 
> 
> Not truth for N900. Bootreason depends on PRM_RSTST omap 
> register, state of vbat charger pins, time how long was power key 
> pressed, R&D data stored in CAL partition and other undocumented 
> registers for omap HS devices. I already tried to implement at 
> least some subset of it in userspace (or kernel), but it is 
> impossible because NOLO bootloader clear status of PRM_RSTST 
> register.
> 
> There is also copy of PRM_RSTST register stored at address 
> 0x4020FFB8 (tracing data) but that address is rewritten (probably 
> by kernel), so we really cannot implement reading bootreason in 
> kernel.
> 
> But in early stage in uboot it is possible to read 0x4020FFB8 
> address and get some part of bootreason. But still PRM_RSTST is 
> not enough!
> 
> I would be happy if DT kernel can export /proc/atags file with 
> ATAGs passed by bootloader. It would be enough for me. In 
> userspace I can parse content and do what is needed.

What about defining a DT boot reason property instead?
Maybe it already exists?  If not, it's something that could certainly be 
generically used on other platforms too.

Converting the special ATAG into its standard DT equivalent would then 
be trivial and much cleaner overall.


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 13:58                                   ` Pali Rohár
@ 2015-01-28 14:46                                     ` Jean-Christophe PLAGNIOL-VILLARD
  -1 siblings, 0 replies; 197+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-01-28 14:46 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Jean-Christophe PLAGNIOL-VILLARD, Tony Lindgren, Ivaylo Dimitrov,
	Russell King - ARM Linux, Sebastian Reichel, Will Deacon,
	linux-kernel, Pavel Machek, linux-arm-kernel


> On Jan 28, 2015, at 9:58 PM, Pali Rohár <pali.rohar@gmail.com> wrote:
> 
> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [150127 
> 09:51]:
>>> We _could_ (and have in the past) turned round and refused
>>> to support these kinds of hacks - which IMHO is quite a
>>> reasonable stance to take: the message we should be sending
>>> is "if you wish to design new methods without discussing it
>>> with us, we reserve the right not to support them in
>>> mainline kernels; please discuss with us your
>>> requirements."
>>> 
>>> Each time that we accept one of these hacks, we're sending a
>>> message that says "it's okay to work in this crappy way".
>>> 
>>> Yes, I realise that the N900 has little in the way of
>>> support, and we can't exert that kind of back pressure
>>> (since there's no one to direct that onto to effect any
>>> change) so I guess we just have to live with it.
>> 
>> I believe after N900 Nokia dropped the custom ATAGs and used
>> the kernel cmdline instead. And most of the n900 custom ATAGs
>> are not even needed any longer.
>> 
> 
> Yes, almost all N900 ATAGs are static and are already hardcoded 
> into kernel or DT file.
> 
> Basically there are 4 non static values which are used:
> 
> 1. ATAG_REVISION
> 
> 2. ATAG_OMAP
> 2.1 OMAP_TAG_BOOT_REASON --> boot reason

you can pass it via DT I already do it on other platform such as amineoIP
which is full DT with barebox as bootloader

> 2.2 OMAP_TAG_VERSION ("nolo") --> for bootloader version

do you really need such information in the kernel as we have a standard boot API?

> 2.3 OMAP_TAG_VERSION ("boot-mode") --> "normal" or “update"

this is application specific not related to the kernel just pass it via cmdline

Best Regards,
J.
> 
> ATAG_OMAP is non standard and contains sub-atags.
> 
> bootloader version is static now (as Nokia does not develop it 
> anymore), but boot reason and boot mode are set by bootloader and 
> are needed for userspace. boot mode tells init system/userspace 
> if to start normal OS or only small subset for flashing.
> 
>> The ATAG_REVISION is a standard feature that we should support
>> naturally. I don't think we should add any custom ATAGs,
>> except maybe for the bootreason.
>> 
>>>> I think this kind of information (how was board/computer
>>>> started) can be useful also for other architectures. E.g.
>>>> on laptop you would like to know if if was started by
>>>> RTC, power button, WakeOnLan, another ACPI event,
>>>> rebooted machine, watchdog, etc... And scripts can act
>>>> depending on this event (when by RTC, you need to run
>>>> some planned job, when by watchdog reset you should check
>>>> what caused that reason...).
>>> 
>>> There is a standard way to get the boot information already:
>>> look at the watchdog API:
>>> 
>>> #define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2,
>>> int)
>>> 
>>> which uses the WDIOF_* flags to indicate the last boot
>>> reason.  It probably isn't as flexible as some may desire,
>>> but it should provide at least the "watchdog rebooted us"
>>> vs "over temperature" vs some other boot reason.
>>> 
>>> The other thing to consider is whether we have a way to know
>>> what the boot reason was, and what we should do if we do
>>> not have a way of supporting some of the boot reasons.  For
>>> example, if we have support for RTC alarm based booting,
>>> but no way to actually tell if the boot was caused by the
>>> RTC alarm triggering.
>> 
>> On omaps, the bootrom passes the bootreason in r1 to the
>> bootloader that can do whatever it wants with it. We could
>> maybe pass it in the kernel cmdline to the watchdog driver
>> for user space?
>> 
> 
> Not truth for N900. Bootreason depends on PRM_RSTST omap 
> register, state of vbat charger pins, time how long was power key 
> pressed, R&D data stored in CAL partition and other undocumented 
> registers for omap HS devices. I already tried to implement at 
> least some subset of it in userspace (or kernel), but it is 
> impossible because NOLO bootloader clear status of PRM_RSTST 
> register.
> 
> There is also copy of PRM_RSTST register stored at address 
> 0x4020FFB8 (tracing data) but that address is rewritten (probably 
> by kernel), so we really cannot implement reading bootreason in 
> kernel.
> 
> But in early stage in uboot it is possible to read 0x4020FFB8 
> address and get some part of bootreason. But still PRM_RSTST is 
> not enough!
> 
> I would be happy if DT kernel can export /proc/atags file with 
> ATAGs passed by bootloader. It would be enough for me. In 
> userspace I can parse content and do what is needed.
> 
> In non DT kernel file /proc/atags is always exported.
> 
>> Of course the problem is that the signed bootloader on n900
>> cannot be modified so the pass through u-boot would have to
>> translate the custom ATAG for bootreason into a kernel
>> cmdline..
>> 
>> But it may actually make sense to add the bootreason ATAGs, it
>> seems quite generic to me.
>> 
> 
> Which bootreason atag? Invent new? Or use above big ATAG_OMAP 
> structure? Inventing new does not solve anything because all 
> developers does not boot kernel for debugging from uboot -- but 
> directly.
> 
>> AFAIK, the other n900 ATAGs can be just ignored.
>> 
>> Regards,
>> 
>> Tony
> 
> -- 
> Pali Rohár
> pali.rohar@gmail.com
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 14:46                                     ` Jean-Christophe PLAGNIOL-VILLARD
  0 siblings, 0 replies; 197+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-01-28 14:46 UTC (permalink / raw)
  To: linux-arm-kernel


> On Jan 28, 2015, at 9:58 PM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> 
> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>> * Russell King - ARM Linux <linux@arm.linux.org.uk> [150127 
> 09:51]:
>>> We _could_ (and have in the past) turned round and refused
>>> to support these kinds of hacks - which IMHO is quite a
>>> reasonable stance to take: the message we should be sending
>>> is "if you wish to design new methods without discussing it
>>> with us, we reserve the right not to support them in
>>> mainline kernels; please discuss with us your
>>> requirements."
>>> 
>>> Each time that we accept one of these hacks, we're sending a
>>> message that says "it's okay to work in this crappy way".
>>> 
>>> Yes, I realise that the N900 has little in the way of
>>> support, and we can't exert that kind of back pressure
>>> (since there's no one to direct that onto to effect any
>>> change) so I guess we just have to live with it.
>> 
>> I believe after N900 Nokia dropped the custom ATAGs and used
>> the kernel cmdline instead. And most of the n900 custom ATAGs
>> are not even needed any longer.
>> 
> 
> Yes, almost all N900 ATAGs are static and are already hardcoded 
> into kernel or DT file.
> 
> Basically there are 4 non static values which are used:
> 
> 1. ATAG_REVISION
> 
> 2. ATAG_OMAP
> 2.1 OMAP_TAG_BOOT_REASON --> boot reason

you can pass it via DT I already do it on other platform such as amineoIP
which is full DT with barebox as bootloader

> 2.2 OMAP_TAG_VERSION ("nolo") --> for bootloader version

do you really need such information in the kernel as we have a standard boot API?

> 2.3 OMAP_TAG_VERSION ("boot-mode") --> "normal" or ?update"

this is application specific not related to the kernel just pass it via cmdline

Best Regards,
J.
> 
> ATAG_OMAP is non standard and contains sub-atags.
> 
> bootloader version is static now (as Nokia does not develop it 
> anymore), but boot reason and boot mode are set by bootloader and 
> are needed for userspace. boot mode tells init system/userspace 
> if to start normal OS or only small subset for flashing.
> 
>> The ATAG_REVISION is a standard feature that we should support
>> naturally. I don't think we should add any custom ATAGs,
>> except maybe for the bootreason.
>> 
>>>> I think this kind of information (how was board/computer
>>>> started) can be useful also for other architectures. E.g.
>>>> on laptop you would like to know if if was started by
>>>> RTC, power button, WakeOnLan, another ACPI event,
>>>> rebooted machine, watchdog, etc... And scripts can act
>>>> depending on this event (when by RTC, you need to run
>>>> some planned job, when by watchdog reset you should check
>>>> what caused that reason...).
>>> 
>>> There is a standard way to get the boot information already:
>>> look at the watchdog API:
>>> 
>>> #define WDIOC_GETBOOTSTATUS     _IOR(WATCHDOG_IOCTL_BASE, 2,
>>> int)
>>> 
>>> which uses the WDIOF_* flags to indicate the last boot
>>> reason.  It probably isn't as flexible as some may desire,
>>> but it should provide at least the "watchdog rebooted us"
>>> vs "over temperature" vs some other boot reason.
>>> 
>>> The other thing to consider is whether we have a way to know
>>> what the boot reason was, and what we should do if we do
>>> not have a way of supporting some of the boot reasons.  For
>>> example, if we have support for RTC alarm based booting,
>>> but no way to actually tell if the boot was caused by the
>>> RTC alarm triggering.
>> 
>> On omaps, the bootrom passes the bootreason in r1 to the
>> bootloader that can do whatever it wants with it. We could
>> maybe pass it in the kernel cmdline to the watchdog driver
>> for user space?
>> 
> 
> Not truth for N900. Bootreason depends on PRM_RSTST omap 
> register, state of vbat charger pins, time how long was power key 
> pressed, R&D data stored in CAL partition and other undocumented 
> registers for omap HS devices. I already tried to implement at 
> least some subset of it in userspace (or kernel), but it is 
> impossible because NOLO bootloader clear status of PRM_RSTST 
> register.
> 
> There is also copy of PRM_RSTST register stored at address 
> 0x4020FFB8 (tracing data) but that address is rewritten (probably 
> by kernel), so we really cannot implement reading bootreason in 
> kernel.
> 
> But in early stage in uboot it is possible to read 0x4020FFB8 
> address and get some part of bootreason. But still PRM_RSTST is 
> not enough!
> 
> I would be happy if DT kernel can export /proc/atags file with 
> ATAGs passed by bootloader. It would be enough for me. In 
> userspace I can parse content and do what is needed.
> 
> In non DT kernel file /proc/atags is always exported.
> 
>> Of course the problem is that the signed bootloader on n900
>> cannot be modified so the pass through u-boot would have to
>> translate the custom ATAG for bootreason into a kernel
>> cmdline..
>> 
>> But it may actually make sense to add the bootreason ATAGs, it
>> seems quite generic to me.
>> 
> 
> Which bootreason atag? Invent new? Or use above big ATAG_OMAP 
> structure? Inventing new does not solve anything because all 
> developers does not boot kernel for debugging from uboot -- but 
> directly.
> 
>> AFAIK, the other n900 ATAGs can be just ignored.
>> 
>> Regards,
>> 
>> Tony
> 
> -- 
> Pali Roh?r
> pali.rohar at gmail.com
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 14:33                                   ` Nicolas Pitre
@ 2015-01-28 15:39                                       ` Tony Lindgren
  2015-01-28 15:57                                       ` Rob Herring
  1 sibling, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-01-28 15:39 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Pali Rohár, Ivaylo Dimitrov, Russell King - ARM Linux,
	Sebastian Reichel, Will Deacon, linux-kernel, Pavel Machek,
	linux-arm-kernel

* Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
> On Wed, 28 Jan 2015, Pali Rohár wrote:
> 
> > On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> > > On omaps, the bootrom passes the bootreason in r1 to the
> > > bootloader that can do whatever it wants with it. We could
> > > maybe pass it in the kernel cmdline to the watchdog driver
> > > for user space?
> > > 
> > 
> > Not truth for N900. Bootreason depends on PRM_RSTST omap 
> > register, state of vbat charger pins, time how long was power key 
> > pressed, R&D data stored in CAL partition and other undocumented 
> > registers for omap HS devices. I already tried to implement at 
> > least some subset of it in userspace (or kernel), but it is 
> > impossible because NOLO bootloader clear status of PRM_RSTST 
> > register.
> > 
> > There is also copy of PRM_RSTST register stored at address 
> > 0x4020FFB8 (tracing data) but that address is rewritten (probably 
> > by kernel), so we really cannot implement reading bootreason in 
> > kernel.
> > 
> > But in early stage in uboot it is possible to read 0x4020FFB8 
> > address and get some part of bootreason. But still PRM_RSTST is 
> > not enough!
> > 
> > I would be happy if DT kernel can export /proc/atags file with 
> > ATAGs passed by bootloader. It would be enough for me. In 
> > userspace I can parse content and do what is needed.
> 
> What about defining a DT boot reason property instead?
> Maybe it already exists?  If not, it's something that could certainly be 
> generically used on other platforms too.
> 
> Converting the special ATAG into its standard DT equivalent would then 
> be trivial and much cleaner overall.

Sounds good to me as then we don't have to add any legacy custom
Nokia specific atag. And it won't prevent us from adding a generic
ATAG_BOOTREASON if really needed.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 15:39                                       ` Tony Lindgren
  0 siblings, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-01-28 15:39 UTC (permalink / raw)
  To: linux-arm-kernel

* Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
> On Wed, 28 Jan 2015, Pali Roh?r wrote:
> 
> > On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> > > On omaps, the bootrom passes the bootreason in r1 to the
> > > bootloader that can do whatever it wants with it. We could
> > > maybe pass it in the kernel cmdline to the watchdog driver
> > > for user space?
> > > 
> > 
> > Not truth for N900. Bootreason depends on PRM_RSTST omap 
> > register, state of vbat charger pins, time how long was power key 
> > pressed, R&D data stored in CAL partition and other undocumented 
> > registers for omap HS devices. I already tried to implement at 
> > least some subset of it in userspace (or kernel), but it is 
> > impossible because NOLO bootloader clear status of PRM_RSTST 
> > register.
> > 
> > There is also copy of PRM_RSTST register stored at address 
> > 0x4020FFB8 (tracing data) but that address is rewritten (probably 
> > by kernel), so we really cannot implement reading bootreason in 
> > kernel.
> > 
> > But in early stage in uboot it is possible to read 0x4020FFB8 
> > address and get some part of bootreason. But still PRM_RSTST is 
> > not enough!
> > 
> > I would be happy if DT kernel can export /proc/atags file with 
> > ATAGs passed by bootloader. It would be enough for me. In 
> > userspace I can parse content and do what is needed.
> 
> What about defining a DT boot reason property instead?
> Maybe it already exists?  If not, it's something that could certainly be 
> generically used on other platforms too.
> 
> Converting the special ATAG into its standard DT equivalent would then 
> be trivial and much cleaner overall.

Sounds good to me as then we don't have to add any legacy custom
Nokia specific atag. And it won't prevent us from adding a generic
ATAG_BOOTREASON if really needed.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 15:39                                       ` Tony Lindgren
@ 2015-01-28 15:47                                         ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-28 15:47 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Nicolas Pitre, Ivaylo Dimitrov, Russell King - ARM Linux,
	Sebastian Reichel, Will Deacon, linux-kernel, Pavel Machek,
	linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 2140 bytes --]

On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote:
> * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
> > On Wed, 28 Jan 2015, Pali Rohár wrote:
> > > On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> > > > On omaps, the bootrom passes the bootreason in r1 to the
> > > > bootloader that can do whatever it wants with it. We
> > > > could maybe pass it in the kernel cmdline to the
> > > > watchdog driver for user space?
> > > 
> > > Not truth for N900. Bootreason depends on PRM_RSTST omap
> > > register, state of vbat charger pins, time how long was
> > > power key pressed, R&D data stored in CAL partition and
> > > other undocumented registers for omap HS devices. I
> > > already tried to implement at least some subset of it in
> > > userspace (or kernel), but it is impossible because NOLO
> > > bootloader clear status of PRM_RSTST register.
> > > 
> > > There is also copy of PRM_RSTST register stored at address
> > > 0x4020FFB8 (tracing data) but that address is rewritten
> > > (probably by kernel), so we really cannot implement
> > > reading bootreason in kernel.
> > > 
> > > But in early stage in uboot it is possible to read
> > > 0x4020FFB8 address and get some part of bootreason. But
> > > still PRM_RSTST is not enough!
> > > 
> > > I would be happy if DT kernel can export /proc/atags file
> > > with ATAGs passed by bootloader. It would be enough for
> > > me. In userspace I can parse content and do what is
> > > needed.
> > 
> > What about defining a DT boot reason property instead?
> > Maybe it already exists?  If not, it's something that could
> > certainly be generically used on other platforms too.
> > 
> > Converting the special ATAG into its standard DT equivalent
> > would then be trivial and much cleaner overall.
> 
> Sounds good to me as then we don't have to add any legacy
> custom Nokia specific atag. And it won't prevent us from
> adding a generic ATAG_BOOTREASON if really needed.
> 
> Regards,
> 
> Tony

And what would new atag ATAG_BOOTREASON solve for Nokia N900? 
Nothing.

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 15:47                                         ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-28 15:47 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote:
> * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
> > On Wed, 28 Jan 2015, Pali Roh?r wrote:
> > > On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> > > > On omaps, the bootrom passes the bootreason in r1 to the
> > > > bootloader that can do whatever it wants with it. We
> > > > could maybe pass it in the kernel cmdline to the
> > > > watchdog driver for user space?
> > > 
> > > Not truth for N900. Bootreason depends on PRM_RSTST omap
> > > register, state of vbat charger pins, time how long was
> > > power key pressed, R&D data stored in CAL partition and
> > > other undocumented registers for omap HS devices. I
> > > already tried to implement at least some subset of it in
> > > userspace (or kernel), but it is impossible because NOLO
> > > bootloader clear status of PRM_RSTST register.
> > > 
> > > There is also copy of PRM_RSTST register stored at address
> > > 0x4020FFB8 (tracing data) but that address is rewritten
> > > (probably by kernel), so we really cannot implement
> > > reading bootreason in kernel.
> > > 
> > > But in early stage in uboot it is possible to read
> > > 0x4020FFB8 address and get some part of bootreason. But
> > > still PRM_RSTST is not enough!
> > > 
> > > I would be happy if DT kernel can export /proc/atags file
> > > with ATAGs passed by bootloader. It would be enough for
> > > me. In userspace I can parse content and do what is
> > > needed.
> > 
> > What about defining a DT boot reason property instead?
> > Maybe it already exists?  If not, it's something that could
> > certainly be generically used on other platforms too.
> > 
> > Converting the special ATAG into its standard DT equivalent
> > would then be trivial and much cleaner overall.
> 
> Sounds good to me as then we don't have to add any legacy
> custom Nokia specific atag. And it won't prevent us from
> adding a generic ATAG_BOOTREASON if really needed.
> 
> Regards,
> 
> Tony

And what would new atag ATAG_BOOTREASON solve for Nokia N900? 
Nothing.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150128/a090cf43/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 15:47                                         ` Pali Rohár
@ 2015-01-28 15:48                                           ` Tony Lindgren
  -1 siblings, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-01-28 15:48 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Nicolas Pitre, Ivaylo Dimitrov, Russell King - ARM Linux,
	Sebastian Reichel, Will Deacon, linux-kernel, Pavel Machek,
	linux-arm-kernel

* Pali Rohár <pali.rohar@gmail.com> [150128 07:50]:
> On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote:
> > * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
> > > On Wed, 28 Jan 2015, Pali Rohár wrote:
> > > > On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> > > > > On omaps, the bootrom passes the bootreason in r1 to the
> > > > > bootloader that can do whatever it wants with it. We
> > > > > could maybe pass it in the kernel cmdline to the
> > > > > watchdog driver for user space?
> > > > 
> > > > Not truth for N900. Bootreason depends on PRM_RSTST omap
> > > > register, state of vbat charger pins, time how long was
> > > > power key pressed, R&D data stored in CAL partition and
> > > > other undocumented registers for omap HS devices. I
> > > > already tried to implement at least some subset of it in
> > > > userspace (or kernel), but it is impossible because NOLO
> > > > bootloader clear status of PRM_RSTST register.
> > > > 
> > > > There is also copy of PRM_RSTST register stored at address
> > > > 0x4020FFB8 (tracing data) but that address is rewritten
> > > > (probably by kernel), so we really cannot implement
> > > > reading bootreason in kernel.
> > > > 
> > > > But in early stage in uboot it is possible to read
> > > > 0x4020FFB8 address and get some part of bootreason. But
> > > > still PRM_RSTST is not enough!
> > > > 
> > > > I would be happy if DT kernel can export /proc/atags file
> > > > with ATAGs passed by bootloader. It would be enough for
> > > > me. In userspace I can parse content and do what is
> > > > needed.
> > > 
> > > What about defining a DT boot reason property instead?
> > > Maybe it already exists?  If not, it's something that could
> > > certainly be generically used on other platforms too.
> > > 
> > > Converting the special ATAG into its standard DT equivalent
> > > would then be trivial and much cleaner overall.
> > 
> > Sounds good to me as then we don't have to add any legacy
> > custom Nokia specific atag. And it won't prevent us from
> > adding a generic ATAG_BOOTREASON if really needed.
> 
> And what would new atag ATAG_BOOTREASON solve for Nokia N900? 
> Nothing.

Right, so probably no need to add it then :) But what Nico is
saying we can translate the Nokia custom bootreason to a
standard DT property if I'm reading right.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 15:48                                           ` Tony Lindgren
  0 siblings, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-01-28 15:48 UTC (permalink / raw)
  To: linux-arm-kernel

* Pali Roh?r <pali.rohar@gmail.com> [150128 07:50]:
> On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote:
> > * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
> > > On Wed, 28 Jan 2015, Pali Roh?r wrote:
> > > > On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> > > > > On omaps, the bootrom passes the bootreason in r1 to the
> > > > > bootloader that can do whatever it wants with it. We
> > > > > could maybe pass it in the kernel cmdline to the
> > > > > watchdog driver for user space?
> > > > 
> > > > Not truth for N900. Bootreason depends on PRM_RSTST omap
> > > > register, state of vbat charger pins, time how long was
> > > > power key pressed, R&D data stored in CAL partition and
> > > > other undocumented registers for omap HS devices. I
> > > > already tried to implement at least some subset of it in
> > > > userspace (or kernel), but it is impossible because NOLO
> > > > bootloader clear status of PRM_RSTST register.
> > > > 
> > > > There is also copy of PRM_RSTST register stored at address
> > > > 0x4020FFB8 (tracing data) but that address is rewritten
> > > > (probably by kernel), so we really cannot implement
> > > > reading bootreason in kernel.
> > > > 
> > > > But in early stage in uboot it is possible to read
> > > > 0x4020FFB8 address and get some part of bootreason. But
> > > > still PRM_RSTST is not enough!
> > > > 
> > > > I would be happy if DT kernel can export /proc/atags file
> > > > with ATAGs passed by bootloader. It would be enough for
> > > > me. In userspace I can parse content and do what is
> > > > needed.
> > > 
> > > What about defining a DT boot reason property instead?
> > > Maybe it already exists?  If not, it's something that could
> > > certainly be generically used on other platforms too.
> > > 
> > > Converting the special ATAG into its standard DT equivalent
> > > would then be trivial and much cleaner overall.
> > 
> > Sounds good to me as then we don't have to add any legacy
> > custom Nokia specific atag. And it won't prevent us from
> > adding a generic ATAG_BOOTREASON if really needed.
> 
> And what would new atag ATAG_BOOTREASON solve for Nokia N900? 
> Nothing.

Right, so probably no need to add it then :) But what Nico is
saying we can translate the Nokia custom bootreason to a
standard DT property if I'm reading right.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 14:33                                   ` Nicolas Pitre
@ 2015-01-28 15:57                                       ` Rob Herring
  2015-01-28 15:57                                       ` Rob Herring
  1 sibling, 0 replies; 197+ messages in thread
From: Rob Herring @ 2015-01-28 15:57 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Pali Rohár, Ivaylo Dimitrov, Russell King - ARM Linux,
	Tony Lindgren, Sebastian Reichel, Will Deacon, linux-kernel,
	Pavel Machek, linux-arm-kernel

On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Wed, 28 Jan 2015, Pali Rohár wrote:
>
>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>> > On omaps, the bootrom passes the bootreason in r1 to the
>> > bootloader that can do whatever it wants with it. We could
>> > maybe pass it in the kernel cmdline to the watchdog driver
>> > for user space?
>> >
>>
>> Not truth for N900. Bootreason depends on PRM_RSTST omap
>> register, state of vbat charger pins, time how long was power key
>> pressed, R&D data stored in CAL partition and other undocumented
>> registers for omap HS devices. I already tried to implement at
>> least some subset of it in userspace (or kernel), but it is
>> impossible because NOLO bootloader clear status of PRM_RSTST
>> register.
>>
>> There is also copy of PRM_RSTST register stored at address
>> 0x4020FFB8 (tracing data) but that address is rewritten (probably
>> by kernel), so we really cannot implement reading bootreason in
>> kernel.
>>
>> But in early stage in uboot it is possible to read 0x4020FFB8
>> address and get some part of bootreason. But still PRM_RSTST is
>> not enough!
>>
>> I would be happy if DT kernel can export /proc/atags file with
>> ATAGs passed by bootloader. It would be enough for me. In
>> userspace I can parse content and do what is needed.
>
> What about defining a DT boot reason property instead?
> Maybe it already exists?  If not, it's something that could certainly be
> generically used on other platforms too.

I'm fine with that, but we just need to have a standard kernel
userspace interface in addition to something like
/proc/device-tree/bootreason. Perhaps this can be the default
implementation for the watchdog dev. Someday when we decide DT is crap
and have a new boot interface, we'll have people relying on
/proc/device-tree. I hope to be retired when that happens...

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 15:57                                       ` Rob Herring
  0 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2015-01-28 15:57 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Wed, 28 Jan 2015, Pali Roh?r wrote:
>
>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>> > On omaps, the bootrom passes the bootreason in r1 to the
>> > bootloader that can do whatever it wants with it. We could
>> > maybe pass it in the kernel cmdline to the watchdog driver
>> > for user space?
>> >
>>
>> Not truth for N900. Bootreason depends on PRM_RSTST omap
>> register, state of vbat charger pins, time how long was power key
>> pressed, R&D data stored in CAL partition and other undocumented
>> registers for omap HS devices. I already tried to implement at
>> least some subset of it in userspace (or kernel), but it is
>> impossible because NOLO bootloader clear status of PRM_RSTST
>> register.
>>
>> There is also copy of PRM_RSTST register stored at address
>> 0x4020FFB8 (tracing data) but that address is rewritten (probably
>> by kernel), so we really cannot implement reading bootreason in
>> kernel.
>>
>> But in early stage in uboot it is possible to read 0x4020FFB8
>> address and get some part of bootreason. But still PRM_RSTST is
>> not enough!
>>
>> I would be happy if DT kernel can export /proc/atags file with
>> ATAGs passed by bootloader. It would be enough for me. In
>> userspace I can parse content and do what is needed.
>
> What about defining a DT boot reason property instead?
> Maybe it already exists?  If not, it's something that could certainly be
> generically used on other platforms too.

I'm fine with that, but we just need to have a standard kernel
userspace interface in addition to something like
/proc/device-tree/bootreason. Perhaps this can be the default
implementation for the watchdog dev. Someday when we decide DT is crap
and have a new boot interface, we'll have people relying on
/proc/device-tree. I hope to be retired when that happens...

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 15:57                                       ` Rob Herring
@ 2015-01-28 16:13                                         ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-28 16:13 UTC (permalink / raw)
  To: Rob Herring
  Cc: Nicolas Pitre, Pali Rohár, Ivaylo Dimitrov, Tony Lindgren,
	Sebastian Reichel, Will Deacon, linux-kernel, Pavel Machek,
	linux-arm-kernel

On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT is crap
> and have a new boot interface, we'll have people relying on
> /proc/device-tree. I hope to be retired when that happens...

Anyone who thinks that DT can be replaced in the same way that we made
the mistake with ATAGs would really need their head examined.

As you point out, removing DT removes the /proc/device-tree/ sub-tree.
Whether we like it or not, that is a userspace API, one which we have
users of already.  That pretty much means that we can't remove DT for
existing platforms or any platform we have now converted to DT.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 16:13                                         ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-28 16:13 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT is crap
> and have a new boot interface, we'll have people relying on
> /proc/device-tree. I hope to be retired when that happens...

Anyone who thinks that DT can be replaced in the same way that we made
the mistake with ATAGs would really need their head examined.

As you point out, removing DT removes the /proc/device-tree/ sub-tree.
Whether we like it or not, that is a userspace API, one which we have
users of already.  That pretty much means that we can't remove DT for
existing platforms or any platform we have now converted to DT.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 16:13                                         ` Russell King - ARM Linux
@ 2015-01-28 16:19                                           ` Will Deacon
  -1 siblings, 0 replies; 197+ messages in thread
From: Will Deacon @ 2015-01-28 16:19 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Rob Herring, Nicolas Pitre, Pali Rohár, Ivaylo Dimitrov,
	Tony Lindgren, Sebastian Reichel, linux-kernel, Pavel Machek,
	linux-arm-kernel

On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> > I'm fine with that, but we just need to have a standard kernel
> > userspace interface in addition to something like
> > /proc/device-tree/bootreason. Perhaps this can be the default
> > implementation for the watchdog dev. Someday when we decide DT is crap
> > and have a new boot interface, we'll have people relying on
> > /proc/device-tree. I hope to be retired when that happens...
> 
> Anyone who thinks that DT can be replaced in the same way that we made
> the mistake with ATAGs would really need their head examined.
> 
> As you point out, removing DT removes the /proc/device-tree/ sub-tree.
> Whether we like it or not, that is a userspace API, one which we have
> users of already.  That pretty much means that we can't remove DT for
> existing platforms or any platform we have now converted to DT.

<ok, I'll go there!>

... and for platforms that can also be booted via ACPI? If we have to
convert the ACPI tables into a device-tree purely for /proc/device-tree,
then we may as well boot with the thing too :)

Seriously though, I don't see how we can maintain this directory for
ACPI, regardless of whether or not it's ABI.

Will

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 16:19                                           ` Will Deacon
  0 siblings, 0 replies; 197+ messages in thread
From: Will Deacon @ 2015-01-28 16:19 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
> On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> > I'm fine with that, but we just need to have a standard kernel
> > userspace interface in addition to something like
> > /proc/device-tree/bootreason. Perhaps this can be the default
> > implementation for the watchdog dev. Someday when we decide DT is crap
> > and have a new boot interface, we'll have people relying on
> > /proc/device-tree. I hope to be retired when that happens...
> 
> Anyone who thinks that DT can be replaced in the same way that we made
> the mistake with ATAGs would really need their head examined.
> 
> As you point out, removing DT removes the /proc/device-tree/ sub-tree.
> Whether we like it or not, that is a userspace API, one which we have
> users of already.  That pretty much means that we can't remove DT for
> existing platforms or any platform we have now converted to DT.

<ok, I'll go there!>

... and for platforms that can also be booted via ACPI? If we have to
convert the ACPI tables into a device-tree purely for /proc/device-tree,
then we may as well boot with the thing too :)

Seriously though, I don't see how we can maintain this directory for
ACPI, regardless of whether or not it's ABI.

Will

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 15:48                                           ` Tony Lindgren
@ 2015-01-28 16:31                                             ` Jason Cooper
  -1 siblings, 0 replies; 197+ messages in thread
From: Jason Cooper @ 2015-01-28 16:31 UTC (permalink / raw)
  To: Tony Lindgren, Pali Rohár, Daniel Mack
  Cc: Ivaylo Dimitrov, Russell King - ARM Linux, Nicolas Pitre,
	Sebastian Reichel, Will Deacon, linux-kernel, Pavel Machek,
	linux-arm-kernel

On 1/28/15 10:48 AM, Tony Lindgren wrote:
> * Pali Rohár <pali.rohar@gmail.com> [150128 07:50]:
>> On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote:
>>> * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
>>>> On Wed, 28 Jan 2015, Pali Rohár wrote:
>>>>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>>>>>> On omaps, the bootrom passes the bootreason in r1 to the
>>>>>> bootloader that can do whatever it wants with it. We
>>>>>> could maybe pass it in the kernel cmdline to the
>>>>>> watchdog driver for user space?
>>>>>
>>>>> Not truth for N900. Bootreason depends on PRM_RSTST omap
>>>>> register, state of vbat charger pins, time how long was
>>>>> power key pressed, R&D data stored in CAL partition and
>>>>> other undocumented registers for omap HS devices. I
>>>>> already tried to implement at least some subset of it in
>>>>> userspace (or kernel), but it is impossible because NOLO
>>>>> bootloader clear status of PRM_RSTST register.
>>>>>
>>>>> There is also copy of PRM_RSTST register stored at address
>>>>> 0x4020FFB8 (tracing data) but that address is rewritten
>>>>> (probably by kernel), so we really cannot implement
>>>>> reading bootreason in kernel.
>>>>>
>>>>> But in early stage in uboot it is possible to read
>>>>> 0x4020FFB8 address and get some part of bootreason. But
>>>>> still PRM_RSTST is not enough!
>>>>>
>>>>> I would be happy if DT kernel can export /proc/atags file
>>>>> with ATAGs passed by bootloader. It would be enough for
>>>>> me. In userspace I can parse content and do what is
>>>>> needed.
>>>>
>>>> What about defining a DT boot reason property instead?
>>>> Maybe it already exists?  If not, it's something that could
>>>> certainly be generically used on other platforms too.
>>>>
>>>> Converting the special ATAG into its standard DT equivalent
>>>> would then be trivial and much cleaner overall.
>>>
>>> Sounds good to me as then we don't have to add any legacy
>>> custom Nokia specific atag. And it won't prevent us from
>>> adding a generic ATAG_BOOTREASON if really needed.
>>
>> And what would new atag ATAG_BOOTREASON solve for Nokia N900?
>> Nothing.
>
> Right, so probably no need to add it then :) But what Nico is
> saying we can translate the Nokia custom bootreason to a
> standard DT property if I'm reading right.

Well, it's mostly been forgotten now, but the pxa-impedance-matcher 
could do the proprietary ATAGS -> standard DT conversion before booting 
the kernel.

   https://github.com/zonque/pxa-impedance-matcher.git

Don't let the 'pxa' fool you, it's grown (slightly) beyond it's original 
purpose.

We augmented it to facilitate booting DT kernels from legacy bootloaders 
to prevent polluting the kernel with random vendor ATAG crap.

Ping me or Daniel Mack if you have any questions.

hth,

Jason.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 16:31                                             ` Jason Cooper
  0 siblings, 0 replies; 197+ messages in thread
From: Jason Cooper @ 2015-01-28 16:31 UTC (permalink / raw)
  To: linux-arm-kernel

On 1/28/15 10:48 AM, Tony Lindgren wrote:
> * Pali Roh?r <pali.rohar@gmail.com> [150128 07:50]:
>> On Wednesday 28 January 2015 16:39:13 Tony Lindgren wrote:
>>> * Nicolas Pitre <nico@fluxnic.net> [150128 06:37]:
>>>> On Wed, 28 Jan 2015, Pali Roh?r wrote:
>>>>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>>>>>> On omaps, the bootrom passes the bootreason in r1 to the
>>>>>> bootloader that can do whatever it wants with it. We
>>>>>> could maybe pass it in the kernel cmdline to the
>>>>>> watchdog driver for user space?
>>>>>
>>>>> Not truth for N900. Bootreason depends on PRM_RSTST omap
>>>>> register, state of vbat charger pins, time how long was
>>>>> power key pressed, R&D data stored in CAL partition and
>>>>> other undocumented registers for omap HS devices. I
>>>>> already tried to implement at least some subset of it in
>>>>> userspace (or kernel), but it is impossible because NOLO
>>>>> bootloader clear status of PRM_RSTST register.
>>>>>
>>>>> There is also copy of PRM_RSTST register stored at address
>>>>> 0x4020FFB8 (tracing data) but that address is rewritten
>>>>> (probably by kernel), so we really cannot implement
>>>>> reading bootreason in kernel.
>>>>>
>>>>> But in early stage in uboot it is possible to read
>>>>> 0x4020FFB8 address and get some part of bootreason. But
>>>>> still PRM_RSTST is not enough!
>>>>>
>>>>> I would be happy if DT kernel can export /proc/atags file
>>>>> with ATAGs passed by bootloader. It would be enough for
>>>>> me. In userspace I can parse content and do what is
>>>>> needed.
>>>>
>>>> What about defining a DT boot reason property instead?
>>>> Maybe it already exists?  If not, it's something that could
>>>> certainly be generically used on other platforms too.
>>>>
>>>> Converting the special ATAG into its standard DT equivalent
>>>> would then be trivial and much cleaner overall.
>>>
>>> Sounds good to me as then we don't have to add any legacy
>>> custom Nokia specific atag. And it won't prevent us from
>>> adding a generic ATAG_BOOTREASON if really needed.
>>
>> And what would new atag ATAG_BOOTREASON solve for Nokia N900?
>> Nothing.
>
> Right, so probably no need to add it then :) But what Nico is
> saying we can translate the Nokia custom bootreason to a
> standard DT property if I'm reading right.

Well, it's mostly been forgotten now, but the pxa-impedance-matcher 
could do the proprietary ATAGS -> standard DT conversion before booting 
the kernel.

   https://github.com/zonque/pxa-impedance-matcher.git

Don't let the 'pxa' fool you, it's grown (slightly) beyond it's original 
purpose.

We augmented it to facilitate booting DT kernels from legacy bootloaders 
to prevent polluting the kernel with random vendor ATAG crap.

Ping me or Daniel Mack if you have any questions.

hth,

Jason.

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 16:19                                           ` Will Deacon
@ 2015-01-28 17:01                                             ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-28 17:01 UTC (permalink / raw)
  To: Will Deacon
  Cc: Rob Herring, Nicolas Pitre, Pali Rohár, Ivaylo Dimitrov,
	Tony Lindgren, Sebastian Reichel, linux-kernel, Pavel Machek,
	linux-arm-kernel

On Wed, Jan 28, 2015 at 04:19:13PM +0000, Will Deacon wrote:
> On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> > > I'm fine with that, but we just need to have a standard kernel
> > > userspace interface in addition to something like
> > > /proc/device-tree/bootreason. Perhaps this can be the default
> > > implementation for the watchdog dev. Someday when we decide DT is crap
> > > and have a new boot interface, we'll have people relying on
> > > /proc/device-tree. I hope to be retired when that happens...
> > 
> > Anyone who thinks that DT can be replaced in the same way that we made
> > the mistake with ATAGs would really need their head examined.
> > 
> > As you point out, removing DT removes the /proc/device-tree/ sub-tree.
> > Whether we like it or not, that is a userspace API, one which we have
> > users of already.  That pretty much means that we can't remove DT for
> > existing platforms or any platform we have now converted to DT.
> 
> <ok, I'll go there!>
> 
> ... and for platforms that can also be booted via ACPI? If we have to
> convert the ACPI tables into a device-tree purely for /proc/device-tree,
> then we may as well boot with the thing too :)
> 
> Seriously though, I don't see how we can maintain this directory for
> ACPI, regardless of whether or not it's ABI.

Welcome to the problem that exporting information to userspace creates.
The same problem is also true where ACPI is exported to userspace too.
As soon as ACPI is exported to userspace, it also becomes part of the
userspace API that the kernel provides - even if it is merely passing
through the data that it received from the firmware.

(I'm not saying that the kernel is ultimately responsible for the
contents of the blob.)

If we took the idea that the kernel receives a blob from the firmware,
and it parses it to discover whatever it needs using the appropriate
parser for that blob, and then passes the blob to userspace, then it's
pretty clear that where a platform switches between providing DT or
ACPI tables is neither here nor there, and can't cause a kernel
regression.  The specification for such an API is that the kernel
provides userspace with whatever data the firmware provided it.

If we take the idea that the kernel receives a blob from the firmware,
decodes it, and then provides the decoded form to userspace, then we're
vulnerable to changes in firmware providers causing regressions for us
because they've changed the way that that information is provided to us.

That's the difference, and this is why I feel that a lack of thought has
been put into stuff like the /sys/firmware/device-tree and similar which
provides the decoded forms of the "blob".  It's far too easy to export
a string or number to userspace, which then becomes part of the user API,
and which can then later become quite a headache later.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 17:01                                             ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-28 17:01 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jan 28, 2015 at 04:19:13PM +0000, Will Deacon wrote:
> On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> > > I'm fine with that, but we just need to have a standard kernel
> > > userspace interface in addition to something like
> > > /proc/device-tree/bootreason. Perhaps this can be the default
> > > implementation for the watchdog dev. Someday when we decide DT is crap
> > > and have a new boot interface, we'll have people relying on
> > > /proc/device-tree. I hope to be retired when that happens...
> > 
> > Anyone who thinks that DT can be replaced in the same way that we made
> > the mistake with ATAGs would really need their head examined.
> > 
> > As you point out, removing DT removes the /proc/device-tree/ sub-tree.
> > Whether we like it or not, that is a userspace API, one which we have
> > users of already.  That pretty much means that we can't remove DT for
> > existing platforms or any platform we have now converted to DT.
> 
> <ok, I'll go there!>
> 
> ... and for platforms that can also be booted via ACPI? If we have to
> convert the ACPI tables into a device-tree purely for /proc/device-tree,
> then we may as well boot with the thing too :)
> 
> Seriously though, I don't see how we can maintain this directory for
> ACPI, regardless of whether or not it's ABI.

Welcome to the problem that exporting information to userspace creates.
The same problem is also true where ACPI is exported to userspace too.
As soon as ACPI is exported to userspace, it also becomes part of the
userspace API that the kernel provides - even if it is merely passing
through the data that it received from the firmware.

(I'm not saying that the kernel is ultimately responsible for the
contents of the blob.)

If we took the idea that the kernel receives a blob from the firmware,
and it parses it to discover whatever it needs using the appropriate
parser for that blob, and then passes the blob to userspace, then it's
pretty clear that where a platform switches between providing DT or
ACPI tables is neither here nor there, and can't cause a kernel
regression.  The specification for such an API is that the kernel
provides userspace with whatever data the firmware provided it.

If we take the idea that the kernel receives a blob from the firmware,
decodes it, and then provides the decoded form to userspace, then we're
vulnerable to changes in firmware providers causing regressions for us
because they've changed the way that that information is provided to us.

That's the difference, and this is why I feel that a lack of thought has
been put into stuff like the /sys/firmware/device-tree and similar which
provides the decoded forms of the "blob".  It's far too easy to export
a string or number to userspace, which then becomes part of the user API,
and which can then later become quite a headache later.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 15:57                                       ` Rob Herring
@ 2015-01-28 17:18                                         ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-28 17:18 UTC (permalink / raw)
  To: Rob Herring
  Cc: Nicolas Pitre, Ivaylo Dimitrov, Russell King - ARM Linux,
	Tony Lindgren, Sebastian Reichel, Will Deacon, linux-kernel,
	Pavel Machek, linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 2192 bytes --]

On Wednesday 28 January 2015 16:57:18 Rob Herring wrote:
> On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre 
<nico@fluxnic.net> wrote:
> > On Wed, 28 Jan 2015, Pali Rohár wrote:
> >> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> >> > On omaps, the bootrom passes the bootreason in r1 to the
> >> > bootloader that can do whatever it wants with it. We
> >> > could maybe pass it in the kernel cmdline to the
> >> > watchdog driver for user space?
> >> 
> >> Not truth for N900. Bootreason depends on PRM_RSTST omap
> >> register, state of vbat charger pins, time how long was
> >> power key pressed, R&D data stored in CAL partition and
> >> other undocumented registers for omap HS devices. I
> >> already tried to implement at least some subset of it in
> >> userspace (or kernel), but it is impossible because NOLO
> >> bootloader clear status of PRM_RSTST register.
> >> 
> >> There is also copy of PRM_RSTST register stored at address
> >> 0x4020FFB8 (tracing data) but that address is rewritten
> >> (probably by kernel), so we really cannot implement
> >> reading bootreason in kernel.
> >> 
> >> But in early stage in uboot it is possible to read
> >> 0x4020FFB8 address and get some part of bootreason. But
> >> still PRM_RSTST is not enough!
> >> 
> >> I would be happy if DT kernel can export /proc/atags file
> >> with ATAGs passed by bootloader. It would be enough for
> >> me. In userspace I can parse content and do what is
> >> needed.
> > 
> > What about defining a DT boot reason property instead?
> > Maybe it already exists?  If not, it's something that could
> > certainly be generically used on other platforms too.
> 
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT
> is crap and have a new boot interface, we'll have people
> relying on /proc/device-tree. I hope to be retired when that
> happens...
> 
> Rob

Then what about exporting bootreason as /proc/bootreason?

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 17:18                                         ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-28 17:18 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 28 January 2015 16:57:18 Rob Herring wrote:
> On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre 
<nico@fluxnic.net> wrote:
> > On Wed, 28 Jan 2015, Pali Roh?r wrote:
> >> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> >> > On omaps, the bootrom passes the bootreason in r1 to the
> >> > bootloader that can do whatever it wants with it. We
> >> > could maybe pass it in the kernel cmdline to the
> >> > watchdog driver for user space?
> >> 
> >> Not truth for N900. Bootreason depends on PRM_RSTST omap
> >> register, state of vbat charger pins, time how long was
> >> power key pressed, R&D data stored in CAL partition and
> >> other undocumented registers for omap HS devices. I
> >> already tried to implement at least some subset of it in
> >> userspace (or kernel), but it is impossible because NOLO
> >> bootloader clear status of PRM_RSTST register.
> >> 
> >> There is also copy of PRM_RSTST register stored at address
> >> 0x4020FFB8 (tracing data) but that address is rewritten
> >> (probably by kernel), so we really cannot implement
> >> reading bootreason in kernel.
> >> 
> >> But in early stage in uboot it is possible to read
> >> 0x4020FFB8 address and get some part of bootreason. But
> >> still PRM_RSTST is not enough!
> >> 
> >> I would be happy if DT kernel can export /proc/atags file
> >> with ATAGs passed by bootloader. It would be enough for
> >> me. In userspace I can parse content and do what is
> >> needed.
> > 
> > What about defining a DT boot reason property instead?
> > Maybe it already exists?  If not, it's something that could
> > certainly be generically used on other platforms too.
> 
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT
> is crap and have a new boot interface, we'll have people
> relying on /proc/device-tree. I hope to be retired when that
> happens...
> 
> Rob

Then what about exporting bootreason as /proc/bootreason?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150128/410e6031/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 16:19                                           ` Will Deacon
@ 2015-01-28 17:29                                             ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-28 17:29 UTC (permalink / raw)
  To: Will Deacon
  Cc: Rob Herring, Nicolas Pitre, Pali Rohár, Ivaylo Dimitrov,
	Tony Lindgren, Sebastian Reichel, linux-kernel, Pavel Machek,
	linux-arm-kernel

On Wed, Jan 28, 2015 at 04:19:13PM +0000, Will Deacon wrote:
> On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> > > I'm fine with that, but we just need to have a standard kernel
> > > userspace interface in addition to something like
> > > /proc/device-tree/bootreason. Perhaps this can be the default
> > > implementation for the watchdog dev. Someday when we decide DT is crap
> > > and have a new boot interface, we'll have people relying on
> > > /proc/device-tree. I hope to be retired when that happens...
> > 
> > Anyone who thinks that DT can be replaced in the same way that we made
> > the mistake with ATAGs would really need their head examined.
> > 
> > As you point out, removing DT removes the /proc/device-tree/ sub-tree.
> > Whether we like it or not, that is a userspace API, one which we have
> > users of already.  That pretty much means that we can't remove DT for
> > existing platforms or any platform we have now converted to DT.
> 
> <ok, I'll go there!>
> 
> ... and for platforms that can also be booted via ACPI? If we have to
> convert the ACPI tables into a device-tree purely for /proc/device-tree,
> then we may as well boot with the thing too :)
> 
> Seriously though, I don't see how we can maintain this directory for
> ACPI, regardless of whether or not it's ABI.

And if it needs stating more clearly, you have just shown why adding
a boot reason to devicetree is the wrong thing to do.

Let's say that we do decide to convert the boot reason atag to a device
tree property.  As soon as we do that, it appears in the /proc/device-tree
sub-tree, whether we like it or not, because that sub-tree exports
*everything* mentioned in the DT blob.

So, as soon as we put anything into the DT blob, it immediately becomes
part of the kernel's userspace API, whether we like it or not.  That
means it becomes available for userspace to start (ab)using - again,
whether or not we provide a saner firmware independent interface.

The more we mess around converting crap from one firmware interface to
another, the more problems we're creating for ourselves.  We really
need to re-think our approach to this, and stop this religous "DT is
everything, we must convert everything to DT."

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 17:29                                             ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-01-28 17:29 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed, Jan 28, 2015 at 04:19:13PM +0000, Will Deacon wrote:
> On Wed, Jan 28, 2015 at 04:13:17PM +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 28, 2015 at 09:57:18AM -0600, Rob Herring wrote:
> > > I'm fine with that, but we just need to have a standard kernel
> > > userspace interface in addition to something like
> > > /proc/device-tree/bootreason. Perhaps this can be the default
> > > implementation for the watchdog dev. Someday when we decide DT is crap
> > > and have a new boot interface, we'll have people relying on
> > > /proc/device-tree. I hope to be retired when that happens...
> > 
> > Anyone who thinks that DT can be replaced in the same way that we made
> > the mistake with ATAGs would really need their head examined.
> > 
> > As you point out, removing DT removes the /proc/device-tree/ sub-tree.
> > Whether we like it or not, that is a userspace API, one which we have
> > users of already.  That pretty much means that we can't remove DT for
> > existing platforms or any platform we have now converted to DT.
> 
> <ok, I'll go there!>
> 
> ... and for platforms that can also be booted via ACPI? If we have to
> convert the ACPI tables into a device-tree purely for /proc/device-tree,
> then we may as well boot with the thing too :)
> 
> Seriously though, I don't see how we can maintain this directory for
> ACPI, regardless of whether or not it's ABI.

And if it needs stating more clearly, you have just shown why adding
a boot reason to devicetree is the wrong thing to do.

Let's say that we do decide to convert the boot reason atag to a device
tree property.  As soon as we do that, it appears in the /proc/device-tree
sub-tree, whether we like it or not, because that sub-tree exports
*everything* mentioned in the DT blob.

So, as soon as we put anything into the DT blob, it immediately becomes
part of the kernel's userspace API, whether we like it or not.  That
means it becomes available for userspace to start (ab)using - again,
whether or not we provide a saner firmware independent interface.

The more we mess around converting crap from one firmware interface to
another, the more problems we're creating for ourselves.  We really
need to re-think our approach to this, and stop this religous "DT is
everything, we must convert everything to DT."

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 15:57                                       ` Rob Herring
@ 2015-01-28 18:00                                         ` Jean-Christophe PLAGNIOL-VILLARD
  -1 siblings, 0 replies; 197+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-01-28 18:00 UTC (permalink / raw)
  To: Rob Herring
  Cc: Jean-Christophe PLAGNIOL-VILLARD, Nicolas Pitre, Ivaylo Dimitrov,
	Russell King - ARM Linux, Tony Lindgren, Sebastian Reichel,
	Will Deacon, linux-kernel, Pavel Machek, Pali Rohár,
	linux-arm-kernel


> On Jan 28, 2015, at 11:57 PM, Rob Herring <robherring2@gmail.com> wrote:
> 
> On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> On Wed, 28 Jan 2015, Pali Rohár wrote:
>> 
>>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>>>> On omaps, the bootrom passes the bootreason in r1 to the
>>>> bootloader that can do whatever it wants with it. We could
>>>> maybe pass it in the kernel cmdline to the watchdog driver
>>>> for user space?
>>>> 
>>> 
>>> Not truth for N900. Bootreason depends on PRM_RSTST omap
>>> register, state of vbat charger pins, time how long was power key
>>> pressed, R&D data stored in CAL partition and other undocumented
>>> registers for omap HS devices. I already tried to implement at
>>> least some subset of it in userspace (or kernel), but it is
>>> impossible because NOLO bootloader clear status of PRM_RSTST
>>> register.
>>> 
>>> There is also copy of PRM_RSTST register stored at address
>>> 0x4020FFB8 (tracing data) but that address is rewritten (probably
>>> by kernel), so we really cannot implement reading bootreason in
>>> kernel.
>>> 
>>> But in early stage in uboot it is possible to read 0x4020FFB8
>>> address and get some part of bootreason. But still PRM_RSTST is
>>> not enough!
>>> 
>>> I would be happy if DT kernel can export /proc/atags file with
>>> ATAGs passed by bootloader. It would be enough for me. In
>>> userspace I can parse content and do what is needed.
>> 
>> What about defining a DT boot reason property instead?
>> Maybe it already exists?  If not, it's something that could certainly be
>> generically used on other platforms too.
> 
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT is crap
> and have a new boot interface, we'll have people relying on
> /proc/device-tree. I hope to be retired when that happens…

but if we try to do this generic, where will you store the boot mode

I mean where the SoC boot from

useful to for the Userspace to known where is the bootloader in case of multi boot mode

Best Regards,
J.
> 
> Rob
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 18:00                                         ` Jean-Christophe PLAGNIOL-VILLARD
  0 siblings, 0 replies; 197+ messages in thread
From: Jean-Christophe PLAGNIOL-VILLARD @ 2015-01-28 18:00 UTC (permalink / raw)
  To: linux-arm-kernel


> On Jan 28, 2015, at 11:57 PM, Rob Herring <robherring2@gmail.com> wrote:
> 
> On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> On Wed, 28 Jan 2015, Pali Roh?r wrote:
>> 
>>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
>>>> On omaps, the bootrom passes the bootreason in r1 to the
>>>> bootloader that can do whatever it wants with it. We could
>>>> maybe pass it in the kernel cmdline to the watchdog driver
>>>> for user space?
>>>> 
>>> 
>>> Not truth for N900. Bootreason depends on PRM_RSTST omap
>>> register, state of vbat charger pins, time how long was power key
>>> pressed, R&D data stored in CAL partition and other undocumented
>>> registers for omap HS devices. I already tried to implement at
>>> least some subset of it in userspace (or kernel), but it is
>>> impossible because NOLO bootloader clear status of PRM_RSTST
>>> register.
>>> 
>>> There is also copy of PRM_RSTST register stored at address
>>> 0x4020FFB8 (tracing data) but that address is rewritten (probably
>>> by kernel), so we really cannot implement reading bootreason in
>>> kernel.
>>> 
>>> But in early stage in uboot it is possible to read 0x4020FFB8
>>> address and get some part of bootreason. But still PRM_RSTST is
>>> not enough!
>>> 
>>> I would be happy if DT kernel can export /proc/atags file with
>>> ATAGs passed by bootloader. It would be enough for me. In
>>> userspace I can parse content and do what is needed.
>> 
>> What about defining a DT boot reason property instead?
>> Maybe it already exists?  If not, it's something that could certainly be
>> generically used on other platforms too.
> 
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT is crap
> and have a new boot interface, we'll have people relying on
> /proc/device-tree. I hope to be retired when that happens?

but if we try to do this generic, where will you store the boot mode

I mean where the SoC boot from

useful to for the Userspace to known where is the bootloader in case of multi boot mode

Best Regards,
J.
> 
> Rob
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 15:57                                       ` Rob Herring
@ 2015-01-28 18:03                                         ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-28 18:03 UTC (permalink / raw)
  To: Rob Herring
  Cc: Nicolas Pitre, Pali Rohár, Ivaylo Dimitrov,
	Russell King - ARM Linux, Tony Lindgren, Sebastian Reichel,
	Will Deacon, linux-kernel, linux-arm-kernel

On Wed 2015-01-28 09:57:18, Rob Herring wrote:
> On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Wed, 28 Jan 2015, Pali Rohár wrote:
> >
> >> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> >> > On omaps, the bootrom passes the bootreason in r1 to the
> >> > bootloader that can do whatever it wants with it. We could
> >> > maybe pass it in the kernel cmdline to the watchdog driver
> >> > for user space?
> >> >
> >>
> >> Not truth for N900. Bootreason depends on PRM_RSTST omap
> >> register, state of vbat charger pins, time how long was power key
> >> pressed, R&D data stored in CAL partition and other undocumented
> >> registers for omap HS devices. I already tried to implement at
> >> least some subset of it in userspace (or kernel), but it is
> >> impossible because NOLO bootloader clear status of PRM_RSTST
> >> register.
> >>
> >> There is also copy of PRM_RSTST register stored at address
> >> 0x4020FFB8 (tracing data) but that address is rewritten (probably
> >> by kernel), so we really cannot implement reading bootreason in
> >> kernel.
> >>
> >> But in early stage in uboot it is possible to read 0x4020FFB8
> >> address and get some part of bootreason. But still PRM_RSTST is
> >> not enough!
> >>
> >> I would be happy if DT kernel can export /proc/atags file with
> >> ATAGs passed by bootloader. It would be enough for me. In
> >> userspace I can parse content and do what is needed.
> >
> > What about defining a DT boot reason property instead?
> > Maybe it already exists?  If not, it's something that could certainly be
> > generically used on other platforms too.
> 
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT is crap
> and have a new boot interface, we'll have people relying on
> /proc/device-tree. I hope to be retired when that happens...

Huh. Who thought putting device-tree into /proc was good idea? That
should have gone to /sys, as it is not process related...

Anyway, bootreason does not depend on device-tree, so it should not be
in device-tree specific subdirectory.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 18:03                                         ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-01-28 18:03 UTC (permalink / raw)
  To: linux-arm-kernel

On Wed 2015-01-28 09:57:18, Rob Herring wrote:
> On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre <nico@fluxnic.net> wrote:
> > On Wed, 28 Jan 2015, Pali Roh?r wrote:
> >
> >> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> >> > On omaps, the bootrom passes the bootreason in r1 to the
> >> > bootloader that can do whatever it wants with it. We could
> >> > maybe pass it in the kernel cmdline to the watchdog driver
> >> > for user space?
> >> >
> >>
> >> Not truth for N900. Bootreason depends on PRM_RSTST omap
> >> register, state of vbat charger pins, time how long was power key
> >> pressed, R&D data stored in CAL partition and other undocumented
> >> registers for omap HS devices. I already tried to implement at
> >> least some subset of it in userspace (or kernel), but it is
> >> impossible because NOLO bootloader clear status of PRM_RSTST
> >> register.
> >>
> >> There is also copy of PRM_RSTST register stored at address
> >> 0x4020FFB8 (tracing data) but that address is rewritten (probably
> >> by kernel), so we really cannot implement reading bootreason in
> >> kernel.
> >>
> >> But in early stage in uboot it is possible to read 0x4020FFB8
> >> address and get some part of bootreason. But still PRM_RSTST is
> >> not enough!
> >>
> >> I would be happy if DT kernel can export /proc/atags file with
> >> ATAGs passed by bootloader. It would be enough for me. In
> >> userspace I can parse content and do what is needed.
> >
> > What about defining a DT boot reason property instead?
> > Maybe it already exists?  If not, it's something that could certainly be
> > generically used on other platforms too.
> 
> I'm fine with that, but we just need to have a standard kernel
> userspace interface in addition to something like
> /proc/device-tree/bootreason. Perhaps this can be the default
> implementation for the watchdog dev. Someday when we decide DT is crap
> and have a new boot interface, we'll have people relying on
> /proc/device-tree. I hope to be retired when that happens...

Huh. Who thought putting device-tree into /proc was good idea? That
should have gone to /sys, as it is not process related...

Anyway, bootreason does not depend on device-tree, so it should not be
in device-tree specific subdirectory.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 18:03                                         ` Pavel Machek
@ 2015-01-28 19:27                                           ` Arnd Bergmann
  -1 siblings, 0 replies; 197+ messages in thread
From: Arnd Bergmann @ 2015-01-28 19:27 UTC (permalink / raw)
  To: linux-arm-kernel
  Cc: Pavel Machek, Rob Herring, Ivaylo Dimitrov,
	Russell King - ARM Linux, Nicolas Pitre, Tony Lindgren,
	Sebastian Reichel, Will Deacon, linux-kernel, Pali Rohár

On Wednesday 28 January 2015 19:03:22 Pavel Machek wrote:
> > /proc/device-tree. I hope to be retired when that happens...
> 
> Huh. Who thought putting device-tree into /proc was good idea? That
> should have gone to /sys, as it is not process related...
> 

I think /proc/device-tree predates sysfs by about six years. These
days, it is a symlink to /sys/firmware/devicetree/base.

	Arnd

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 19:27                                           ` Arnd Bergmann
  0 siblings, 0 replies; 197+ messages in thread
From: Arnd Bergmann @ 2015-01-28 19:27 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 28 January 2015 19:03:22 Pavel Machek wrote:
> > /proc/device-tree. I hope to be retired when that happens...
> 
> Huh. Who thought putting device-tree into /proc was good idea? That
> should have gone to /sys, as it is not process related...
> 

I think /proc/device-tree predates sysfs by about six years. These
days, it is a symlink to /sys/firmware/devicetree/base.

	Arnd

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/atags: Export also for DT
  2015-01-28 18:00                                         ` Jean-Christophe PLAGNIOL-VILLARD
@ 2015-01-28 19:33                                           ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-28 19:33 UTC (permalink / raw)
  To: Jean-Christophe PLAGNIOL-VILLARD
  Cc: Rob Herring, Nicolas Pitre, Ivaylo Dimitrov,
	Russell King - ARM Linux, Tony Lindgren, Sebastian Reichel,
	Will Deacon, linux-kernel, Pavel Machek, linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 3109 bytes --]

On Wednesday 28 January 2015 19:00:25 Jean-Christophe PLAGNIOL-
VILLARD wrote:
> > On Jan 28, 2015, at 11:57 PM, Rob Herring
> > <robherring2@gmail.com> wrote:
> > 
> > On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre 
<nico@fluxnic.net> wrote:
> >> On Wed, 28 Jan 2015, Pali Rohár wrote:
> >>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> >>>> On omaps, the bootrom passes the bootreason in r1 to the
> >>>> bootloader that can do whatever it wants with it. We
> >>>> could maybe pass it in the kernel cmdline to the
> >>>> watchdog driver for user space?
> >>> 
> >>> Not truth for N900. Bootreason depends on PRM_RSTST omap
> >>> register, state of vbat charger pins, time how long was
> >>> power key pressed, R&D data stored in CAL partition and
> >>> other undocumented registers for omap HS devices. I
> >>> already tried to implement at least some subset of it in
> >>> userspace (or kernel), but it is impossible because NOLO
> >>> bootloader clear status of PRM_RSTST register.
> >>> 
> >>> There is also copy of PRM_RSTST register stored at address
> >>> 0x4020FFB8 (tracing data) but that address is rewritten
> >>> (probably by kernel), so we really cannot implement
> >>> reading bootreason in kernel.
> >>> 
> >>> But in early stage in uboot it is possible to read
> >>> 0x4020FFB8 address and get some part of bootreason. But
> >>> still PRM_RSTST is not enough!
> >>> 
> >>> I would be happy if DT kernel can export /proc/atags file
> >>> with ATAGs passed by bootloader. It would be enough for
> >>> me. In userspace I can parse content and do what is
> >>> needed.
> >> 
> >> What about defining a DT boot reason property instead?
> >> Maybe it already exists?  If not, it's something that could
> >> certainly be generically used on other platforms too.
> > 
> > I'm fine with that, but we just need to have a standard
> > kernel userspace interface in addition to something like
> > /proc/device-tree/bootreason. Perhaps this can be the
> > default implementation for the watchdog dev. Someday when
> > we decide DT is crap and have a new boot interface, we'll
> > have people relying on /proc/device-tree. I hope to be
> > retired when that happens…
> 
> but if we try to do this generic, where will you store the
> boot mode
> 
> I mean where the SoC boot from
> 
> useful to for the Userspace to known where is the bootloader
> in case of multi boot mode
> 
> Best Regards,
> J.
> 
> > Rob
> > 

I think in this discussion we are mixing two parts which should 
be designed & solved separately.

1) How should bootloader tell to kernel what is bootreason

2) How should kernel export bootreason to userspace

In modern x86 laptop world bootreason can be requested from 
BIOS/WMI/firmware by special proprietary vendor specific command.

So we should not lock bootreason to DT or ATAG only. Or only 
bootloader --> kernel transition. For other platforms, board or 
even architectures (x86) there can runtime way (for kernel) how 
to read bootreason...

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/atags: Export also for DT
@ 2015-01-28 19:33                                           ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-28 19:33 UTC (permalink / raw)
  To: linux-arm-kernel

On Wednesday 28 January 2015 19:00:25 Jean-Christophe PLAGNIOL-
VILLARD wrote:
> > On Jan 28, 2015, at 11:57 PM, Rob Herring
> > <robherring2@gmail.com> wrote:
> > 
> > On Wed, Jan 28, 2015 at 8:33 AM, Nicolas Pitre 
<nico@fluxnic.net> wrote:
> >> On Wed, 28 Jan 2015, Pali Roh?r wrote:
> >>> On Wednesday 28 January 2015 01:50:33 Tony Lindgren wrote:
> >>>> On omaps, the bootrom passes the bootreason in r1 to the
> >>>> bootloader that can do whatever it wants with it. We
> >>>> could maybe pass it in the kernel cmdline to the
> >>>> watchdog driver for user space?
> >>> 
> >>> Not truth for N900. Bootreason depends on PRM_RSTST omap
> >>> register, state of vbat charger pins, time how long was
> >>> power key pressed, R&D data stored in CAL partition and
> >>> other undocumented registers for omap HS devices. I
> >>> already tried to implement at least some subset of it in
> >>> userspace (or kernel), but it is impossible because NOLO
> >>> bootloader clear status of PRM_RSTST register.
> >>> 
> >>> There is also copy of PRM_RSTST register stored at address
> >>> 0x4020FFB8 (tracing data) but that address is rewritten
> >>> (probably by kernel), so we really cannot implement
> >>> reading bootreason in kernel.
> >>> 
> >>> But in early stage in uboot it is possible to read
> >>> 0x4020FFB8 address and get some part of bootreason. But
> >>> still PRM_RSTST is not enough!
> >>> 
> >>> I would be happy if DT kernel can export /proc/atags file
> >>> with ATAGs passed by bootloader. It would be enough for
> >>> me. In userspace I can parse content and do what is
> >>> needed.
> >> 
> >> What about defining a DT boot reason property instead?
> >> Maybe it already exists?  If not, it's something that could
> >> certainly be generically used on other platforms too.
> > 
> > I'm fine with that, but we just need to have a standard
> > kernel userspace interface in addition to something like
> > /proc/device-tree/bootreason. Perhaps this can be the
> > default implementation for the watchdog dev. Someday when
> > we decide DT is crap and have a new boot interface, we'll
> > have people relying on /proc/device-tree. I hope to be
> > retired when that happens?
> 
> but if we try to do this generic, where will you store the
> boot mode
> 
> I mean where the SoC boot from
> 
> useful to for the Userspace to known where is the bootloader
> in case of multi boot mode
> 
> Best Regards,
> J.
> 
> > Rob
> > 

I think in this discussion we are mixing two parts which should 
be designed & solved separately.

1) How should bootloader tell to kernel what is bootreason

2) How should kernel export bootreason to userspace

In modern x86 laptop world bootreason can be requested from 
BIOS/WMI/firmware by special proprietary vendor specific command.

So we should not lock bootreason to DT or ATAG only. Or only 
bootloader --> kernel transition. For other platforms, board or 
even architectures (x86) there can runtime way (for kernel) how 
to read bootreason...

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150128/cc59673e/attachment-0001.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-01-26 20:22                       ` Rob Herring
@ 2015-01-30 14:14                         ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-30 14:14 UTC (permalink / raw)
  To: Rob Herring
  Cc: Russell King, Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Pavel Machek, linux-kernel, linux-arm-kernel, Tony Lindgren

[-- Attachment #1: Type: Text/Plain, Size: 4621 bytes --]

On Monday 26 January 2015 21:22:27 Rob Herring wrote:
> On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > Ok, here is patch which set Revision field (global variable
> > system_rev) in /proc/cpuinfo from DT revision property:
> > 
> > diff --git a/arch/arm/kernel/devtree.c
> > b/arch/arm/kernel/devtree.c index 11c54de..9946c1b 100644
> > --- a/arch/arm/kernel/devtree.c
> > +++ b/arch/arm/kernel/devtree.c
> > @@ -19,6 +19,7 @@
> > 
> >  #include <linux/of_irq.h>
> >  #include <linux/of_platform.h>
> >  #include <linux/smp.h>
> > 
> > +#include <linux/libfdt_env.h>
> > 
> >  #include <asm/cputype.h>
> >  #include <asm/setup.h>
> > 
> > @@ -26,6 +27,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 +206,8 @@ 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;
> > 
> > +       unsigned long dt_root;
> > +       const u32 *prop;
> > 
> >  #ifdef CONFIG_ARCH_MULTIPLATFORM
> >  
> >         DT_MACHINE_START(GENERIC_DT, "Generic DT based
> >         system")
> > 
> > @@ -215,17 +219,16 @@ 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);
> > 
> > @@ -246,5 +249,10 @@ const struct machine_desc * __init
> > setup_machine_fdt(unsigned int dt_phys)
> > 
> >         /* Change machine number to match the mdesc we're
> >         using */ __machine_arch_type = mdesc->nr;
> > 
> > +       /* Set system revision from DT */
> > +       prop = of_get_flat_dt_prop(dt_root, "revision",
> > NULL); +       if (prop)
> > +               system_rev = fdt32_to_cpu(*prop);
> > +
> > 
> >         return mdesc;
> >  
> >  }
> > 
> > And here is patch which convert ATAG revision into DT
> > revision property and append it into DT in decompress code:
> > 
> > diff --git a/arch/arm/boot/compressed/atags_to_fdt.c
> > b/arch/arm/boot/compressed/atags_to_fdt.c index
> > 9448aa0..e7e1cc9 100644
> > --- a/arch/arm/boot/compressed/atags_to_fdt.c
> > +++ b/arch/arm/boot/compressed/atags_to_fdt.c
> > @@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void
> > *fdt, int total_space)
> > 
> >                                         cpu_to_fdt32(atag->u
> >                                         .mem.size);
> >                         
> >                         }
> > 
> > +               } else if (atag->hdr.tag == ATAG_REVISION) {
> > +                       setprop_cell(fdt, "/", "revision",
> > atag->u.revision.rev);
> > 
> >                 } else if (atag->hdr.tag == ATAG_INITRD2) {
> >                 
> >                         uint32_t initrd_start, initrd_size;
> >                         initrd_start = atag->u.initrd.start;
> > 
> > I tested it on DT booted Nokia N900 and it is working, in
> > /proc/cpuinfo is revision from ATAG.
> > 
> > I do not know which DT property to use for storing HW
> > Revision, so if "/revision" is not correct one, let me know
> > what to use instead. Also you can add my Signed-off-by for
> > both patches.
> 
> It is the correct property, but /revision in DT is a string.
> 
> You need to add your own sign-off.
> 
> Rob

Any documentation which says that /revision is string?

If it is really string, how to store ATAG_REVISON (number) to 
string? dec or hex?

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-01-30 14:14                         ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-01-30 14:14 UTC (permalink / raw)
  To: linux-arm-kernel

On Monday 26 January 2015 21:22:27 Rob Herring wrote:
> On Mon, Jan 26, 2015 at 1:09 PM, Pali Roh?r 
<pali.rohar@gmail.com> wrote:
> > Ok, here is patch which set Revision field (global variable
> > system_rev) in /proc/cpuinfo from DT revision property:
> > 
> > diff --git a/arch/arm/kernel/devtree.c
> > b/arch/arm/kernel/devtree.c index 11c54de..9946c1b 100644
> > --- a/arch/arm/kernel/devtree.c
> > +++ b/arch/arm/kernel/devtree.c
> > @@ -19,6 +19,7 @@
> > 
> >  #include <linux/of_irq.h>
> >  #include <linux/of_platform.h>
> >  #include <linux/smp.h>
> > 
> > +#include <linux/libfdt_env.h>
> > 
> >  #include <asm/cputype.h>
> >  #include <asm/setup.h>
> > 
> > @@ -26,6 +27,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 +206,8 @@ 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;
> > 
> > +       unsigned long dt_root;
> > +       const u32 *prop;
> > 
> >  #ifdef CONFIG_ARCH_MULTIPLATFORM
> >  
> >         DT_MACHINE_START(GENERIC_DT, "Generic DT based
> >         system")
> > 
> > @@ -215,17 +219,16 @@ 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);
> > 
> > @@ -246,5 +249,10 @@ const struct machine_desc * __init
> > setup_machine_fdt(unsigned int dt_phys)
> > 
> >         /* Change machine number to match the mdesc we're
> >         using */ __machine_arch_type = mdesc->nr;
> > 
> > +       /* Set system revision from DT */
> > +       prop = of_get_flat_dt_prop(dt_root, "revision",
> > NULL); +       if (prop)
> > +               system_rev = fdt32_to_cpu(*prop);
> > +
> > 
> >         return mdesc;
> >  
> >  }
> > 
> > And here is patch which convert ATAG revision into DT
> > revision property and append it into DT in decompress code:
> > 
> > diff --git a/arch/arm/boot/compressed/atags_to_fdt.c
> > b/arch/arm/boot/compressed/atags_to_fdt.c index
> > 9448aa0..e7e1cc9 100644
> > --- a/arch/arm/boot/compressed/atags_to_fdt.c
> > +++ b/arch/arm/boot/compressed/atags_to_fdt.c
> > @@ -171,6 +171,8 @@ int atags_to_fdt(void *atag_list, void
> > *fdt, int total_space)
> > 
> >                                         cpu_to_fdt32(atag->u
> >                                         .mem.size);
> >                         
> >                         }
> > 
> > +               } else if (atag->hdr.tag == ATAG_REVISION) {
> > +                       setprop_cell(fdt, "/", "revision",
> > atag->u.revision.rev);
> > 
> >                 } else if (atag->hdr.tag == ATAG_INITRD2) {
> >                 
> >                         uint32_t initrd_start, initrd_size;
> >                         initrd_start = atag->u.initrd.start;
> > 
> > I tested it on DT booted Nokia N900 and it is working, in
> > /proc/cpuinfo is revision from ATAG.
> > 
> > I do not know which DT property to use for storing HW
> > Revision, so if "/revision" is not correct one, let me know
> > what to use instead. Also you can add my Signed-off-by for
> > both patches.
> 
> It is the correct property, but /revision in DT is a string.
> 
> You need to add your own sign-off.
> 
> Rob

Any documentation which says that /revision is string?

If it is really string, how to store ATAG_REVISON (number) to 
string? dec or hex?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150130/d560d228/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-01-30 14:14                         ` Pali Rohár
@ 2015-01-30 21:03                           ` Rob Herring
  -1 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2015-01-30 21:03 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King, Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Pavel Machek, linux-kernel, linux-arm-kernel, Tony Lindgren

lOn Fri, Jan 30, 2015 at 8:14 AM, Pali Rohár <pali.rohar@gmail.com> wrote:
> On Monday 26 January 2015 21:22:27 Rob Herring wrote:
>> On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár
> <pali.rohar@gmail.com> wrote:
>> > Ok, here is patch which set Revision field (global variable
>> > system_rev) in /proc/cpuinfo from DT revision property:

[...]

>> > I do not know which DT property to use for storing HW
>> > Revision, so if "/revision" is not correct one, let me know
>> > what to use instead. Also you can add my Signed-off-by for
>> > both patches.
>>
>> It is the correct property, but /revision in DT is a string.
>>
>> You need to add your own sign-off.
>>
>> Rob
>
> Any documentation which says that /revision is string?

Sorry, I was confusing this with serial-number, so I guess a number is
fine here.

> If it is really string, how to store ATAG_REVISON (number) to
> string? dec or hex?

However /proc/cpuinfo displays it would be fine if you stay with a string.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-01-30 21:03                           ` Rob Herring
  0 siblings, 0 replies; 197+ messages in thread
From: Rob Herring @ 2015-01-30 21:03 UTC (permalink / raw)
  To: linux-arm-kernel

lOn Fri, Jan 30, 2015 at 8:14 AM, Pali Roh?r <pali.rohar@gmail.com> wrote:
> On Monday 26 January 2015 21:22:27 Rob Herring wrote:
>> On Mon, Jan 26, 2015 at 1:09 PM, Pali Roh?r
> <pali.rohar@gmail.com> wrote:
>> > Ok, here is patch which set Revision field (global variable
>> > system_rev) in /proc/cpuinfo from DT revision property:

[...]

>> > I do not know which DT property to use for storing HW
>> > Revision, so if "/revision" is not correct one, let me know
>> > what to use instead. Also you can add my Signed-off-by for
>> > both patches.
>>
>> It is the correct property, but /revision in DT is a string.
>>
>> You need to add your own sign-off.
>>
>> Rob
>
> Any documentation which says that /revision is string?

Sorry, I was confusing this with serial-number, so I guess a number is
fine here.

> If it is really string, how to store ATAG_REVISON (number) to
> string? dec or hex?

However /proc/cpuinfo displays it would be fine if you stay with a string.

Rob

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-01-30 21:03                           ` Rob Herring
@ 2015-02-27 15:45                             ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-02-27 15:45 UTC (permalink / raw)
  To: Rob Herring
  Cc: Russell King, Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Pavel Machek, linux-kernel, linux-arm-kernel, Tony Lindgren

[-- Attachment #1: Type: Text/Plain, Size: 1329 bytes --]

On Friday 30 January 2015 22:03:36 Rob Herring wrote:
> lOn Fri, Jan 30, 2015 at 8:14 AM, Pali Rohár 
<pali.rohar@gmail.com> wrote:
> > On Monday 26 January 2015 21:22:27 Rob Herring wrote:
> >> On Mon, Jan 26, 2015 at 1:09 PM, Pali Rohár
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > Ok, here is patch which set Revision field (global
> >> > variable
> 
> >> > system_rev) in /proc/cpuinfo from DT revision property:
> [...]
> 
> >> > I do not know which DT property to use for storing HW
> >> > Revision, so if "/revision" is not correct one, let me
> >> > know what to use instead. Also you can add my
> >> > Signed-off-by for both patches.
> >> 
> >> It is the correct property, but /revision in DT is a
> >> string.
> >> 
> >> You need to add your own sign-off.
> >> 
> >> Rob
> > 
> > Any documentation which says that /revision is string?
> 
> Sorry, I was confusing this with serial-number, so I guess a
> number is fine here.
> 
> > If it is really string, how to store ATAG_REVISON (number)
> > to string? dec or hex?
> 
> However /proc/cpuinfo displays it would be fine if you stay
> with a string.
> 
> Rob

I will send new patch which will store number value as string. So 
same output will be in /proc/cpuinfo and in DT /revision.

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-02-27 15:45                             ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-02-27 15:45 UTC (permalink / raw)
  To: linux-arm-kernel

On Friday 30 January 2015 22:03:36 Rob Herring wrote:
> lOn Fri, Jan 30, 2015 at 8:14 AM, Pali Roh?r 
<pali.rohar@gmail.com> wrote:
> > On Monday 26 January 2015 21:22:27 Rob Herring wrote:
> >> On Mon, Jan 26, 2015 at 1:09 PM, Pali Roh?r
> > 
> > <pali.rohar@gmail.com> wrote:
> >> > Ok, here is patch which set Revision field (global
> >> > variable
> 
> >> > system_rev) in /proc/cpuinfo from DT revision property:
> [...]
> 
> >> > I do not know which DT property to use for storing HW
> >> > Revision, so if "/revision" is not correct one, let me
> >> > know what to use instead. Also you can add my
> >> > Signed-off-by for both patches.
> >> 
> >> It is the correct property, but /revision in DT is a
> >> string.
> >> 
> >> You need to add your own sign-off.
> >> 
> >> Rob
> > 
> > Any documentation which says that /revision is string?
> 
> Sorry, I was confusing this with serial-number, so I guess a
> number is fine here.
> 
> > If it is really string, how to store ATAG_REVISON (number)
> > to string? dec or hex?
> 
> However /proc/cpuinfo displays it would be fine if you stay
> with a string.
> 
> Rob

I will send new patch which will store number value as string. So 
same output will be in /proc/cpuinfo and in DT /revision.

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150227/f30eeba9/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-02-27 15:45                             ` Pali Rohár
@ 2015-02-27 15:55                               ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-02-27 15:55 UTC (permalink / raw)
  To: Rob Herring, Russell King, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, Tony Lindgren,
	Andreas Färber
  Cc: linux-kernel, linux-arm-kernel, Pali Rohár

This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.

Pali Rohár (2):
  arm: devtree: Set system_rev from DT revision
  arm: boot: convert ATAG_REVISION to DT revision field

 arch/arm/boot/compressed/atags_to_fdt.c |   37 +++++++++++++++++++++++++++++++
 arch/arm/kernel/devtree.c               |   20 ++++++++++++-----
 2 files changed, 52 insertions(+), 5 deletions(-)

-- 
1.7.9.5


^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-02-27 15:55                               ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-02-27 15:55 UTC (permalink / raw)
  To: linux-arm-kernel

This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.

Pali Roh?r (2):
  arm: devtree: Set system_rev from DT revision
  arm: boot: convert ATAG_REVISION to DT revision field

 arch/arm/boot/compressed/atags_to_fdt.c |   37 +++++++++++++++++++++++++++++++
 arch/arm/kernel/devtree.c               |   20 ++++++++++++-----
 2 files changed, 52 insertions(+), 5 deletions(-)

-- 
1.7.9.5

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
  2015-02-27 15:55                               ` Pali Rohár
@ 2015-02-27 15:55                                 ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-02-27 15:55 UTC (permalink / raw)
  To: Rob Herring, Russell King, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, Tony Lindgren,
	Andreas Färber
  Cc: linux-kernel, linux-arm-kernel, Pali Rohár

With this patch "revision" DT string entry is used to set global system_rev
variable. DT "revision" is expected to be string with one hexadecimal number.
So "Revision" line in /proc/cpuinfo will be same as "revision" DT value.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 arch/arm/kernel/devtree.c |   20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 11c54de..7e13e27 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -19,6 +19,7 @@
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/smp.h>
+#include <linux/libfdt_env.h>
 
 #include <asm/cputype.h>
 #include <asm/setup.h>
@@ -26,6 +27,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 +206,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;
+	unsigned long dt_root;
+	const char *prop;
+	int size;
 
 #ifdef CONFIG_ARCH_MULTIPLATFORM
 	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
@@ -215,17 +220,13 @@ 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);
@@ -246,5 +247,14 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	/* Change machine number to match the mdesc we're using */
 	__machine_arch_type = mdesc->nr;
 
+	/* Set system revision from DT */
+	prop = of_get_flat_dt_prop(dt_root, "revision", &size);
+	if (prop && size > 0) {
+		char revision[11];
+		strlcpy(revision, prop, min(size, (int)sizeof(revision)));
+		if (kstrtouint(revision, 16, &system_rev) != 0)
+			system_rev = 0;
+	}
+
 	return mdesc;
 }
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 197+ messages in thread

* [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision
@ 2015-02-27 15:55                                 ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-02-27 15:55 UTC (permalink / raw)
  To: linux-arm-kernel

With this patch "revision" DT string entry is used to set global system_rev
variable. DT "revision" is expected to be string with one hexadecimal number.
So "Revision" line in /proc/cpuinfo will be same as "revision" DT value.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
 arch/arm/kernel/devtree.c |   20 +++++++++++++++-----
 1 file changed, 15 insertions(+), 5 deletions(-)

diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index 11c54de..7e13e27 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -19,6 +19,7 @@
 #include <linux/of_irq.h>
 #include <linux/of_platform.h>
 #include <linux/smp.h>
+#include <linux/libfdt_env.h>
 
 #include <asm/cputype.h>
 #include <asm/setup.h>
@@ -26,6 +27,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 +206,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;
+	unsigned long dt_root;
+	const char *prop;
+	int size;
 
 #ifdef CONFIG_ARCH_MULTIPLATFORM
 	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
@@ -215,17 +220,13 @@ 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);
@@ -246,5 +247,14 @@ const struct machine_desc * __init setup_machine_fdt(unsigned int dt_phys)
 	/* Change machine number to match the mdesc we're using */
 	__machine_arch_type = mdesc->nr;
 
+	/* Set system revision from DT */
+	prop = of_get_flat_dt_prop(dt_root, "revision", &size);
+	if (prop && size > 0) {
+		char revision[11];
+		strlcpy(revision, prop, min(size, (int)sizeof(revision)));
+		if (kstrtouint(revision, 16, &system_rev) != 0)
+			system_rev = 0;
+	}
+
 	return mdesc;
 }
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 197+ messages in thread

* [PATCH v2 2/2] arm: boot: convert ATAG_REVISION to DT revision field
  2015-02-27 15:55                               ` Pali Rohár
@ 2015-02-27 15:55                                 ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-02-27 15:55 UTC (permalink / raw)
  To: Rob Herring, Russell King, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Pavel Machek, Tony Lindgren,
	Andreas Färber
  Cc: linux-kernel, linux-arm-kernel, Pali Rohár

ATAG_REVISION is unsigned number and revision in DT is stored as hexadecimal
string value. It means that it will be correctly parsed by kernel.

Signed-off-by: Pali Rohár <pali.rohar@gmail.com>
---
 arch/arm/boot/compressed/atags_to_fdt.c |   37 +++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
index 9448aa0..b23748e 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -97,6 +97,39 @@ static void merge_fdt_bootargs(void *fdt, const char *fdt_cmdline)
 	setprop_string(fdt, "/chosen", "bootargs", cmdline);
 }
 
+static void tohexstr(char * str, int size, unsigned int num)
+{
+	int len = 0;
+	int i, tmp;
+
+	if (size < 4) {
+		if (size > 0)
+			str[0] = 0;
+		return;
+	}
+
+	str[len++] = '0';
+	str[len++] = 'x';
+
+	while (len-1 < size && num) {
+		tmp = num % 16;
+		if (tmp >= 10)
+			tmp += 'A';
+		else
+			tmp += '0';
+		str[len++] = tmp;
+		num /= 16;
+	}
+
+	str[len] = 0;
+
+	for (i = 2; i < 2+(len-2)/2; ++i) {
+		tmp = str[i];
+		str[i] = str[len-i+1];
+		str[len-i+1] = tmp;
+	}
+}
+
 /*
  * Convert and fold provided ATAGs into the provided FDT.
  *
@@ -171,6 +204,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
 					cpu_to_fdt32(atag->u.mem.size);
 			}
 
+		} else if (atag->hdr.tag == ATAG_REVISION) {
+			char revision[11];
+			tohexstr(revision, sizeof(revision), atag->u.revision.rev);
+			setprop_string(fdt, "/", "revision", revision);
 		} else if (atag->hdr.tag == ATAG_INITRD2) {
 			uint32_t initrd_start, initrd_size;
 			initrd_start = atag->u.initrd.start;
-- 
1.7.9.5


^ permalink raw reply related	[flat|nested] 197+ messages in thread

* [PATCH v2 2/2] arm: boot: convert ATAG_REVISION to DT revision field
@ 2015-02-27 15:55                                 ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-02-27 15:55 UTC (permalink / raw)
  To: linux-arm-kernel

ATAG_REVISION is unsigned number and revision in DT is stored as hexadecimal
string value. It means that it will be correctly parsed by kernel.

Signed-off-by: Pali Roh?r <pali.rohar@gmail.com>
---
 arch/arm/boot/compressed/atags_to_fdt.c |   37 +++++++++++++++++++++++++++++++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/compressed/atags_to_fdt.c b/arch/arm/boot/compressed/atags_to_fdt.c
index 9448aa0..b23748e 100644
--- a/arch/arm/boot/compressed/atags_to_fdt.c
+++ b/arch/arm/boot/compressed/atags_to_fdt.c
@@ -97,6 +97,39 @@ static void merge_fdt_bootargs(void *fdt, const char *fdt_cmdline)
 	setprop_string(fdt, "/chosen", "bootargs", cmdline);
 }
 
+static void tohexstr(char * str, int size, unsigned int num)
+{
+	int len = 0;
+	int i, tmp;
+
+	if (size < 4) {
+		if (size > 0)
+			str[0] = 0;
+		return;
+	}
+
+	str[len++] = '0';
+	str[len++] = 'x';
+
+	while (len-1 < size && num) {
+		tmp = num % 16;
+		if (tmp >= 10)
+			tmp += 'A';
+		else
+			tmp += '0';
+		str[len++] = tmp;
+		num /= 16;
+	}
+
+	str[len] = 0;
+
+	for (i = 2; i < 2+(len-2)/2; ++i) {
+		tmp = str[i];
+		str[i] = str[len-i+1];
+		str[len-i+1] = tmp;
+	}
+}
+
 /*
  * Convert and fold provided ATAGs into the provided FDT.
  *
@@ -171,6 +204,10 @@ int atags_to_fdt(void *atag_list, void *fdt, int total_space)
 					cpu_to_fdt32(atag->u.mem.size);
 			}
 
+		} else if (atag->hdr.tag == ATAG_REVISION) {
+			char revision[11];
+			tohexstr(revision, sizeof(revision), atag->u.revision.rev);
+			setprop_string(fdt, "/", "revision", revision);
 		} else if (atag->hdr.tag == ATAG_INITRD2) {
 			uint32_t initrd_start, initrd_size;
 			initrd_start = atag->u.initrd.start;
-- 
1.7.9.5

^ permalink raw reply related	[flat|nested] 197+ messages in thread

* Re: [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-01-26 22:34                       ` Andreas Färber
@ 2015-02-27 15:56                         ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-02-27 15:56 UTC (permalink / raw)
  To: Andreas Färber
  Cc: Rob Herring, Ivaylo Dimitrov, Russell King, Tony Lindgren,
	Sebastian Reichel, Will Deacon, linux-kernel, Pavel Machek,
	linux-arm-kernel

[-- Attachment #1: Type: Text/Plain, Size: 2201 bytes --]

On Monday 26 January 2015 23:34:34 Andreas Färber wrote:
> Am 26.01.2015 um 20:09 schrieb Pali Rohár:
> > diff --git a/arch/arm/kernel/devtree.c
> > b/arch/arm/kernel/devtree.c index 11c54de..9946c1b 100644
> > --- a/arch/arm/kernel/devtree.c
> > +++ b/arch/arm/kernel/devtree.c
> 
> [...]
> 
> > @@ -204,6 +206,8 @@ 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;
> > 
> > +	unsigned long dt_root;
> > +	const u32 *prop;
> > 
> >  #ifdef CONFIG_ARCH_MULTIPLATFORM
> >  
> >  	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> > 
> > @@ -215,17 +219,16 @@ 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;
> 
> Probably the use of two differently typed variables of name
> "prop" in this function is not intentional?
> 

Fixed in PATCH v2.

> Regards,
> Andreas
> 
> >  		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);
> > 
> > @@ -246,5 +249,10 @@ const struct machine_desc * __init
> > setup_machine_fdt(unsigned int dt_phys)
> > 
> >  	/* Change machine number to match the mdesc we're using */
> >  	__machine_arch_type = mdesc->nr;
> > 
> > +	/* Set system revision from DT */
> > +	prop = of_get_flat_dt_prop(dt_root, "revision", NULL);
> > +	if (prop)
> > +		system_rev = fdt32_to_cpu(*prop);
> > +
> > 
> >  	return mdesc;
> >  
> >  }
> 
> [snip]

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-02-27 15:56                         ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-02-27 15:56 UTC (permalink / raw)
  To: linux-arm-kernel

On Monday 26 January 2015 23:34:34 Andreas F?rber wrote:
> Am 26.01.2015 um 20:09 schrieb Pali Roh?r:
> > diff --git a/arch/arm/kernel/devtree.c
> > b/arch/arm/kernel/devtree.c index 11c54de..9946c1b 100644
> > --- a/arch/arm/kernel/devtree.c
> > +++ b/arch/arm/kernel/devtree.c
> 
> [...]
> 
> > @@ -204,6 +206,8 @@ 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;
> > 
> > +	unsigned long dt_root;
> > +	const u32 *prop;
> > 
> >  #ifdef CONFIG_ARCH_MULTIPLATFORM
> >  
> >  	DT_MACHINE_START(GENERIC_DT, "Generic DT based system")
> > 
> > @@ -215,17 +219,16 @@ 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;
> 
> Probably the use of two differently typed variables of name
> "prop" in this function is not intentional?
> 

Fixed in PATCH v2.

> Regards,
> Andreas
> 
> >  		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);
> > 
> > @@ -246,5 +249,10 @@ const struct machine_desc * __init
> > setup_machine_fdt(unsigned int dt_phys)
> > 
> >  	/* Change machine number to match the mdesc we're using */
> >  	__machine_arch_type = mdesc->nr;
> > 
> > +	/* Set system revision from DT */
> > +	prop = of_get_flat_dt_prop(dt_root, "revision", NULL);
> > +	if (prop)
> > +		system_rev = fdt32_to_cpu(*prop);
> > +
> > 
> >  	return mdesc;
> >  
> >  }
> 
> [snip]

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150227/f46f060f/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-02-27 15:55                               ` Pali Rohár
@ 2015-03-02 11:28                                 ` Pavel Machek
  -1 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-03-02 11:28 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Rob Herring, Russell King, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Tony Lindgren, Andreas Färber,
	linux-kernel, linux-arm-kernel

On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> 
> Pali Rohár (2):
>   arm: devtree: Set system_rev from DT revision
>   arm: boot: convert ATAG_REVISION to DT revision field

Acked-by: Pavel Machek <pavel@ucw.cz>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-03-02 11:28                                 ` Pavel Machek
  0 siblings, 0 replies; 197+ messages in thread
From: Pavel Machek @ 2015-03-02 11:28 UTC (permalink / raw)
  To: linux-arm-kernel

On Fri 2015-02-27 16:55:26, Pali Roh?r wrote:
> This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> 
> Pali Roh?r (2):
>   arm: devtree: Set system_rev from DT revision
>   arm: boot: convert ATAG_REVISION to DT revision field

Acked-by: Pavel Machek <pavel@ucw.cz>

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-03-02 11:28                                 ` Pavel Machek
@ 2015-03-16 15:44                                   ` Tony Lindgren
  -1 siblings, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-03-16 15:44 UTC (permalink / raw)
  To: Pavel Machek
  Cc: Pali Rohár, Rob Herring, Russell King, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, Andreas Färber,
	linux-kernel, linux-arm-kernel, Nicolas Pitre, Arnd Bergmann

* Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > 
> > Pali Rohár (2):
> >   arm: devtree: Set system_rev from DT revision
> >   arm: boot: convert ATAG_REVISION to DT revision field
> 
> Acked-by: Pavel Machek <pavel@ucw.cz>

Are these queued somewhere now? Sounds like this is the last pending
issue for n900 to use legacy user space with current mainline kernels,
so I'd like to get these in so we can get closer to making omap3 boot
in device tree only mode.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-03-16 15:44                                   ` Tony Lindgren
  0 siblings, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-03-16 15:44 UTC (permalink / raw)
  To: linux-arm-kernel

* Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> On Fri 2015-02-27 16:55:26, Pali Roh?r wrote:
> > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > 
> > Pali Roh?r (2):
> >   arm: devtree: Set system_rev from DT revision
> >   arm: boot: convert ATAG_REVISION to DT revision field
> 
> Acked-by: Pavel Machek <pavel@ucw.cz>

Are these queued somewhere now? Sounds like this is the last pending
issue for n900 to use legacy user space with current mainline kernels,
so I'd like to get these in so we can get closer to making omap3 boot
in device tree only mode.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-03-16 15:44                                   ` Tony Lindgren
@ 2015-03-16 16:14                                     ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-03-16 16:14 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Pavel Machek, Pali Rohár, Rob Herring, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, Andreas Färber,
	linux-kernel, linux-arm-kernel, Nicolas Pitre, Arnd Bergmann

On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > > 
> > > Pali Rohár (2):
> > >   arm: devtree: Set system_rev from DT revision
> > >   arm: boot: convert ATAG_REVISION to DT revision field
> > 
> > Acked-by: Pavel Machek <pavel@ucw.cz>
> 
> Are these queued somewhere now? Sounds like this is the last pending
> issue for n900 to use legacy user space with current mainline kernels,
> so I'd like to get these in so we can get closer to making omap3 boot
> in device tree only mode.

Not that I know of.  As everyone is aware, patches need to be in my
patch system if they want me to apply them - which would've been
especially important as I was away from kernel stuff for a week at
the start of March (for medical reasons) and I can't be expected to
track the status of stuff which is buried behind 1000+ extra mails.

In any case, I'm currently not accepting /any/ patches into my tree at
present; I'm chasing a horrid instability on one of my test platforms
which is making it impossible to tell whether any particular change or
changes in my tree is responsible or not for it.  It doesn't seem to be
a hardware failure (if it was, I'd simply take the board out of the
nightly test system.)

It's quite literally taking hours to figure out what's going on - I've
been on this for about 12 hours now and still not much closer to knowing
what's causing it (other than I know that -rc1 plus my queue seems to be
fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine.  So
something I'm already carrying seems to be responsible, but each time I
identify a particular patch and drop _just_ that change, I find that the
problem is back when I try my queue minus the bad changes.  With a test
cycle time of 20+ minutes (due to the number of boots required to make
certain of a dependable result), this is /really/ slow progress.

Right now, I can't be positively sure that /anything/ I have already
merged isn't a factor in causing this problem, so I don't want to
augment my tree with any additional patches which would upset my
ability to move about in the tree, and get reproducable results from
repeated testing.  To merge something else will probably mean I'll
have to start again from the beginning and the last 12 hours spent
testing will have been wasted.

Sorry.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-03-16 16:14                                     ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-03-16 16:14 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote:
> * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > On Fri 2015-02-27 16:55:26, Pali Roh?r wrote:
> > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > > 
> > > Pali Roh?r (2):
> > >   arm: devtree: Set system_rev from DT revision
> > >   arm: boot: convert ATAG_REVISION to DT revision field
> > 
> > Acked-by: Pavel Machek <pavel@ucw.cz>
> 
> Are these queued somewhere now? Sounds like this is the last pending
> issue for n900 to use legacy user space with current mainline kernels,
> so I'd like to get these in so we can get closer to making omap3 boot
> in device tree only mode.

Not that I know of.  As everyone is aware, patches need to be in my
patch system if they want me to apply them - which would've been
especially important as I was away from kernel stuff for a week at
the start of March (for medical reasons) and I can't be expected to
track the status of stuff which is buried behind 1000+ extra mails.

In any case, I'm currently not accepting /any/ patches into my tree at
present; I'm chasing a horrid instability on one of my test platforms
which is making it impossible to tell whether any particular change or
changes in my tree is responsible or not for it.  It doesn't seem to be
a hardware failure (if it was, I'd simply take the board out of the
nightly test system.)

It's quite literally taking hours to figure out what's going on - I've
been on this for about 12 hours now and still not much closer to knowing
what's causing it (other than I know that -rc1 plus my queue seems to be
fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine.  So
something I'm already carrying seems to be responsible, but each time I
identify a particular patch and drop _just_ that change, I find that the
problem is back when I try my queue minus the bad changes.  With a test
cycle time of 20+ minutes (due to the number of boots required to make
certain of a dependable result), this is /really/ slow progress.

Right now, I can't be positively sure that /anything/ I have already
merged isn't a factor in causing this problem, so I don't want to
augment my tree with any additional patches which would upset my
ability to move about in the tree, and get reproducable results from
repeated testing.  To merge something else will probably mean I'll
have to start again from the beginning and the last 12 hours spent
testing will have been wasted.

Sorry.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-03-16 16:14                                     ` Russell King - ARM Linux
@ 2015-03-16 16:43                                       ` Nicolas Pitre
  -1 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-03-16 16:43 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Tony Lindgren, Pavel Machek, Pali Rohár, Rob Herring,
	Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Andreas Färber, linux-kernel, linux-arm-kernel,
	Arnd Bergmann

On Mon, 16 Mar 2015, Russell King - ARM Linux wrote:

> In any case, I'm currently not accepting /any/ patches into my tree at
> present; I'm chasing a horrid instability on one of my test platforms
> which is making it impossible to tell whether any particular change or
> changes in my tree is responsible or not for it.  It doesn't seem to be
> a hardware failure (if it was, I'd simply take the board out of the
> nightly test system.)
> 
> It's quite literally taking hours to figure out what's going on - I've
> been on this for about 12 hours now and still not much closer to knowing
> what's causing it (other than I know that -rc1 plus my queue seems to be
> fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine.  So
> something I'm already carrying seems to be responsible, but each time I
> identify a particular patch and drop _just_ that change, I find that the
> problem is back when I try my queue minus the bad changes.  With a test
> cycle time of 20+ minutes (due to the number of boots required to make
> certain of a dependable result), this is /really/ slow progress.
> 
> Right now, I can't be positively sure that /anything/ I have already
> merged isn't a factor in causing this problem, so I don't want to
> augment my tree with any additional patches which would upset my
> ability to move about in the tree, and get reproducable results from
> repeated testing.  To merge something else will probably mean I'll
> have to start again from the beginning and the last 12 hours spent
> testing will have been wasted.

Your publicly visible tree contains only a few mundane patches.
Is that the tree you're testing with?  If no then could you publish it 
for others to have a look and test?


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-03-16 16:43                                       ` Nicolas Pitre
  0 siblings, 0 replies; 197+ messages in thread
From: Nicolas Pitre @ 2015-03-16 16:43 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, 16 Mar 2015, Russell King - ARM Linux wrote:

> In any case, I'm currently not accepting /any/ patches into my tree at
> present; I'm chasing a horrid instability on one of my test platforms
> which is making it impossible to tell whether any particular change or
> changes in my tree is responsible or not for it.  It doesn't seem to be
> a hardware failure (if it was, I'd simply take the board out of the
> nightly test system.)
> 
> It's quite literally taking hours to figure out what's going on - I've
> been on this for about 12 hours now and still not much closer to knowing
> what's causing it (other than I know that -rc1 plus my queue seems to be
> fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine.  So
> something I'm already carrying seems to be responsible, but each time I
> identify a particular patch and drop _just_ that change, I find that the
> problem is back when I try my queue minus the bad changes.  With a test
> cycle time of 20+ minutes (due to the number of boots required to make
> certain of a dependable result), this is /really/ slow progress.
> 
> Right now, I can't be positively sure that /anything/ I have already
> merged isn't a factor in causing this problem, so I don't want to
> augment my tree with any additional patches which would upset my
> ability to move about in the tree, and get reproducable results from
> repeated testing.  To merge something else will probably mean I'll
> have to start again from the beginning and the last 12 hours spent
> testing will have been wasted.

Your publicly visible tree contains only a few mundane patches.
Is that the tree you're testing with?  If no then could you publish it 
for others to have a look and test?


Nicolas

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-03-16 16:14                                     ` Russell King - ARM Linux
@ 2015-03-16 18:10                                       ` Tony Lindgren
  -1 siblings, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-03-16 18:10 UTC (permalink / raw)
  To: Russell King - ARM Linux
  Cc: Pavel Machek, Pali Rohár, Rob Herring, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, Andreas Färber,
	linux-kernel, linux-arm-kernel, Nicolas Pitre, Arnd Bergmann

* Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 09:15]:
> On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote:
> > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > > > 
> > > > Pali Rohár (2):
> > > >   arm: devtree: Set system_rev from DT revision
> > > >   arm: boot: convert ATAG_REVISION to DT revision field
> > > 
> > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > 
> > Are these queued somewhere now? Sounds like this is the last pending
> > issue for n900 to use legacy user space with current mainline kernels,
> > so I'd like to get these in so we can get closer to making omap3 boot
> > in device tree only mode.
> 
> Not that I know of.  As everyone is aware, patches need to be in my
> patch system if they want me to apply them - which would've been
> especially important as I was away from kernel stuff for a week at
> the start of March (for medical reasons) and I can't be expected to
> track the status of stuff which is buried behind 1000+ extra mails.

Pali, care to upload these two patches to Russell's patch tracking
system if no other comments?
 
> In any case, I'm currently not accepting /any/ patches into my tree at
> present; I'm chasing a horrid instability on one of my test platforms
> which is making it impossible to tell whether any particular change or
> changes in my tree is responsible or not for it.  It doesn't seem to be
> a hardware failure (if it was, I'd simply take the board out of the
> nightly test system.)
> 
> It's quite literally taking hours to figure out what's going on - I've
> been on this for about 12 hours now and still not much closer to knowing
> what's causing it (other than I know that -rc1 plus my queue seems to be
> fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine.  So
> something I'm already carrying seems to be responsible, but each time I
> identify a particular patch and drop _just_ that change, I find that the
> problem is back when I try my queue minus the bad changes.  With a test
> cycle time of 20+ minutes (due to the number of boots required to make
> certain of a dependable result), this is /really/ slow progress.
> 
> Right now, I can't be positively sure that /anything/ I have already
> merged isn't a factor in causing this problem, so I don't want to
> augment my tree with any additional patches which would upset my
> ability to move about in the tree, and get reproducable results from
> repeated testing.  To merge something else will probably mean I'll
> have to start again from the beginning and the last 12 hours spent
> testing will have been wasted.

Oh debugging those things sucks. Maybe try with CONFIG_DEBUG_SLAB to
see if you trigger any poison.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-03-16 18:10                                       ` Tony Lindgren
  0 siblings, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-03-16 18:10 UTC (permalink / raw)
  To: linux-arm-kernel

* Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 09:15]:
> On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote:
> > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > On Fri 2015-02-27 16:55:26, Pali Roh?r wrote:
> > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > > > 
> > > > Pali Roh?r (2):
> > > >   arm: devtree: Set system_rev from DT revision
> > > >   arm: boot: convert ATAG_REVISION to DT revision field
> > > 
> > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > 
> > Are these queued somewhere now? Sounds like this is the last pending
> > issue for n900 to use legacy user space with current mainline kernels,
> > so I'd like to get these in so we can get closer to making omap3 boot
> > in device tree only mode.
> 
> Not that I know of.  As everyone is aware, patches need to be in my
> patch system if they want me to apply them - which would've been
> especially important as I was away from kernel stuff for a week at
> the start of March (for medical reasons) and I can't be expected to
> track the status of stuff which is buried behind 1000+ extra mails.

Pali, care to upload these two patches to Russell's patch tracking
system if no other comments?
 
> In any case, I'm currently not accepting /any/ patches into my tree at
> present; I'm chasing a horrid instability on one of my test platforms
> which is making it impossible to tell whether any particular change or
> changes in my tree is responsible or not for it.  It doesn't seem to be
> a hardware failure (if it was, I'd simply take the board out of the
> nightly test system.)
> 
> It's quite literally taking hours to figure out what's going on - I've
> been on this for about 12 hours now and still not much closer to knowing
> what's causing it (other than I know that -rc1 plus my queue seems to be
> fine, -rc3 plus my queue is definitely broken, -rc3 alone is fine.  So
> something I'm already carrying seems to be responsible, but each time I
> identify a particular patch and drop _just_ that change, I find that the
> problem is back when I try my queue minus the bad changes.  With a test
> cycle time of 20+ minutes (due to the number of boots required to make
> certain of a dependable result), this is /really/ slow progress.
> 
> Right now, I can't be positively sure that /anything/ I have already
> merged isn't a factor in causing this problem, so I don't want to
> augment my tree with any additional patches which would upset my
> ability to move about in the tree, and get reproducable results from
> repeated testing.  To merge something else will probably mean I'll
> have to start again from the beginning and the last 12 hours spent
> testing will have been wasted.

Oh debugging those things sucks. Maybe try with CONFIG_DEBUG_SLAB to
see if you trigger any poison.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-03-16 16:43                                       ` Nicolas Pitre
@ 2015-03-16 19:21                                         ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-03-16 19:21 UTC (permalink / raw)
  To: Nicolas Pitre
  Cc: Tony Lindgren, Pavel Machek, Pali Rohár, Rob Herring,
	Will Deacon, Ivaylo Dimitrov, Sebastian Reichel,
	Andreas Färber, linux-kernel, linux-arm-kernel,
	Arnd Bergmann

On Mon, Mar 16, 2015 at 12:43:47PM -0400, Nicolas Pitre wrote:
> Your publicly visible tree contains only a few mundane patches.
> Is that the tree you're testing with?  If no then could you publish it 
> for others to have a look and test?

Okay, having investigated three cases of this, ended up mostly at
dead-ends, and having talked to Will, I think the conclusion is that
no one really understands what's going on here. :p

A number of people (including people within ARM) have seen the problem
that I've seen with a variety of kernel versions, including versions
which I haven't seen a problem with.

My own investigations turn up patches which don't have that much to do
with the SMP booting itself: yes, one was a L2C patch, but I've had
that for a very long time.  The FIQ changes for the GIC which shouldn't
have affected it.  Olof's MMC patches to support resets and regulators
which we don't even get to, so couldn't affect it /code-wise/.

What all these have in common is an influence on the layout of the
kernel image.  Exactly what that is, I don't know yet - I've not had
the time to be able to investigate that deeply as I've been trying to
characterise the failure and track it down to an easy "this works,
this doesn't" test case.  I now have that with a kernel without MMC
changes vs a kernel with MMC changes - where I know that the actual
changes have nothing to do with the problem itself.

There's only one person (not me) who has been able to get a reasonable
amount of debug so far - Sudeep (@arm) has found that both CPU0 and CPU1
are stuck in the radix code, but merely using the debugger "frees" them
from there.

Now that I'm aware that _others_ are or have seen the same issue I am,
I can worry slightly less about the issue... and what it confirms to
me is that it's less about what the kernel code is, more about the
placement of kernel code.

The unfortunate side effect is that it cuts down on the amount of useful
testing I can do prior to sending stuff to Linus... but C'est la vie.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-03-16 19:21                                         ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-03-16 19:21 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Mar 16, 2015 at 12:43:47PM -0400, Nicolas Pitre wrote:
> Your publicly visible tree contains only a few mundane patches.
> Is that the tree you're testing with?  If no then could you publish it 
> for others to have a look and test?

Okay, having investigated three cases of this, ended up mostly at
dead-ends, and having talked to Will, I think the conclusion is that
no one really understands what's going on here. :p

A number of people (including people within ARM) have seen the problem
that I've seen with a variety of kernel versions, including versions
which I haven't seen a problem with.

My own investigations turn up patches which don't have that much to do
with the SMP booting itself: yes, one was a L2C patch, but I've had
that for a very long time.  The FIQ changes for the GIC which shouldn't
have affected it.  Olof's MMC patches to support resets and regulators
which we don't even get to, so couldn't affect it /code-wise/.

What all these have in common is an influence on the layout of the
kernel image.  Exactly what that is, I don't know yet - I've not had
the time to be able to investigate that deeply as I've been trying to
characterise the failure and track it down to an easy "this works,
this doesn't" test case.  I now have that with a kernel without MMC
changes vs a kernel with MMC changes - where I know that the actual
changes have nothing to do with the problem itself.

There's only one person (not me) who has been able to get a reasonable
amount of debug so far - Sudeep (@arm) has found that both CPU0 and CPU1
are stuck in the radix code, but merely using the debugger "frees" them
from there.

Now that I'm aware that _others_ are or have seen the same issue I am,
I can worry slightly less about the issue... and what it confirms to
me is that it's less about what the kernel code is, more about the
placement of kernel code.

The unfortunate side effect is that it cuts down on the amount of useful
testing I can do prior to sending stuff to Linus... but C'est la vie.

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-03-16 18:10                                       ` Tony Lindgren
@ 2015-03-16 19:59                                         ` Russell King - ARM Linux
  -1 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-03-16 19:59 UTC (permalink / raw)
  To: Tony Lindgren
  Cc: Pavel Machek, Pali Rohár, Rob Herring, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, Andreas Färber,
	linux-kernel, linux-arm-kernel, Nicolas Pitre, Arnd Bergmann

On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 09:15]:
> > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote:
> > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > > > > 
> > > > > Pali Rohár (2):
> > > > >   arm: devtree: Set system_rev from DT revision
> > > > >   arm: boot: convert ATAG_REVISION to DT revision field
> > > > 
> > > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > 
> > > Are these queued somewhere now? Sounds like this is the last pending
> > > issue for n900 to use legacy user space with current mainline kernels,
> > > so I'd like to get these in so we can get closer to making omap3 boot
> > > in device tree only mode.
> > 
> > Not that I know of.  As everyone is aware, patches need to be in my
> > patch system if they want me to apply them - which would've been
> > especially important as I was away from kernel stuff for a week at
> > the start of March (for medical reasons) and I can't be expected to
> > track the status of stuff which is buried behind 1000+ extra mails.
> 
> Pali, care to upload these two patches to Russell's patch tracking
> system if no other comments?

If it's done soon, I should be able to send them to Linus fairly quickly,
since this problem I'm grappling with is being seen by others who have
better tools to be able to investigate the problem (and hence they're in
a better position to investigate what's going on.)

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-03-16 19:59                                         ` Russell King - ARM Linux
  0 siblings, 0 replies; 197+ messages in thread
From: Russell King - ARM Linux @ 2015-03-16 19:59 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316 09:15]:
> > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren wrote:
> > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > > On Fri 2015-02-27 16:55:26, Pali Roh?r wrote:
> > > > > This patch adds support for DT "/revision" and convert ATAG_REVISION to DT.
> > > > > 
> > > > > Pali Roh?r (2):
> > > > >   arm: devtree: Set system_rev from DT revision
> > > > >   arm: boot: convert ATAG_REVISION to DT revision field
> > > > 
> > > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > 
> > > Are these queued somewhere now? Sounds like this is the last pending
> > > issue for n900 to use legacy user space with current mainline kernels,
> > > so I'd like to get these in so we can get closer to making omap3 boot
> > > in device tree only mode.
> > 
> > Not that I know of.  As everyone is aware, patches need to be in my
> > patch system if they want me to apply them - which would've been
> > especially important as I was away from kernel stuff for a week at
> > the start of March (for medical reasons) and I can't be expected to
> > track the status of stuff which is buried behind 1000+ extra mails.
> 
> Pali, care to upload these two patches to Russell's patch tracking
> system if no other comments?

If it's done soon, I should be able to send them to Linus fairly quickly,
since this problem I'm grappling with is being seen by others who have
better tools to be able to investigate the problem (and hence they're in
a better position to investigate what's going on.)

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-03-16 19:59                                         ` Russell King - ARM Linux
@ 2015-03-16 20:54                                           ` Pali Rohár
  -1 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-03-16 20:54 UTC (permalink / raw)
  To: Russell King - ARM Linux, Tony Lindgren
  Cc: Pavel Machek, Rob Herring, Will Deacon, Ivaylo Dimitrov,
	Sebastian Reichel, Andreas Färber, linux-kernel,
	linux-arm-kernel, Nicolas Pitre, Arnd Bergmann

[-- Attachment #1: Type: Text/Plain, Size: 2116 bytes --]

On Monday 16 March 2015 20:59:04 Russell King - ARM Linux wrote:
> On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316
> > 09:15]:
> > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren
> > > wrote:
> > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > > > > > This patch adds support for DT "/revision" and
> > > > > > convert ATAG_REVISION to DT.
> > > > > > 
> > > > > > Pali Rohár (2):
> > > > > >   arm: devtree: Set system_rev from DT revision
> > > > > >   arm: boot: convert ATAG_REVISION to DT revision
> > > > > >   field
> > > > > 
> > > > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > > 
> > > > Are these queued somewhere now? Sounds like this is the
> > > > last pending issue for n900 to use legacy user space
> > > > with current mainline kernels, so I'd like to get these
> > > > in so we can get closer to making omap3 boot in device
> > > > tree only mode.
> > > 
> > > Not that I know of.  As everyone is aware, patches need to
> > > be in my patch system if they want me to apply them -
> > > which would've been especially important as I was away
> > > from kernel stuff for a week at the start of March (for
> > > medical reasons) and I can't be expected to track the
> > > status of stuff which is buried behind 1000+ extra mails.
> > 
> > Pali, care to upload these two patches to Russell's patch
> > tracking system if no other comments?
> 
> If it's done soon, I should be able to send them to Linus
> fairly quickly, since this problem I'm grappling with is
> being seen by others who have better tools to be able to
> investigate the problem (and hence they're in a better
> position to investigate what's going on.)

I have no idea how to upload those patches into tracking system. 
Right now I do not have enough time for testing any patches...

Tony, or somebody else, if you have free time, can you upload 
(my) patches to that needed tracking system?

-- 
Pali Rohár
pali.rohar@gmail.com

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

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-03-16 20:54                                           ` Pali Rohár
  0 siblings, 0 replies; 197+ messages in thread
From: Pali Rohár @ 2015-03-16 20:54 UTC (permalink / raw)
  To: linux-arm-kernel

On Monday 16 March 2015 20:59:04 Russell King - ARM Linux wrote:
> On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316
> > 09:15]:
> > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren
> > > wrote:
> > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > > > On Fri 2015-02-27 16:55:26, Pali Roh?r wrote:
> > > > > > This patch adds support for DT "/revision" and
> > > > > > convert ATAG_REVISION to DT.
> > > > > > 
> > > > > > Pali Roh?r (2):
> > > > > >   arm: devtree: Set system_rev from DT revision
> > > > > >   arm: boot: convert ATAG_REVISION to DT revision
> > > > > >   field
> > > > > 
> > > > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > > 
> > > > Are these queued somewhere now? Sounds like this is the
> > > > last pending issue for n900 to use legacy user space
> > > > with current mainline kernels, so I'd like to get these
> > > > in so we can get closer to making omap3 boot in device
> > > > tree only mode.
> > > 
> > > Not that I know of.  As everyone is aware, patches need to
> > > be in my patch system if they want me to apply them -
> > > which would've been especially important as I was away
> > > from kernel stuff for a week at the start of March (for
> > > medical reasons) and I can't be expected to track the
> > > status of stuff which is buried behind 1000+ extra mails.
> > 
> > Pali, care to upload these two patches to Russell's patch
> > tracking system if no other comments?
> 
> If it's done soon, I should be able to send them to Linus
> fairly quickly, since this problem I'm grappling with is
> being seen by others who have better tools to be able to
> investigate the problem (and hence they're in a better
> position to investigate what's going on.)

I have no idea how to upload those patches into tracking system. 
Right now I do not have enough time for testing any patches...

Tony, or somebody else, if you have free time, can you upload 
(my) patches to that needed tracking system?

-- 
Pali Roh?r
pali.rohar at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150316/a2326a34/attachment.sig>

^ permalink raw reply	[flat|nested] 197+ messages in thread

* Re: [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
  2015-03-16 20:54                                           ` Pali Rohár
@ 2015-03-16 20:59                                             ` Tony Lindgren
  -1 siblings, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-03-16 20:59 UTC (permalink / raw)
  To: Pali Rohár
  Cc: Russell King - ARM Linux, Pavel Machek, Rob Herring, Will Deacon,
	Ivaylo Dimitrov, Sebastian Reichel, Andreas Färber,
	linux-kernel, linux-arm-kernel, Nicolas Pitre, Arnd Bergmann

* Pali Rohár <pali.rohar@gmail.com> [150316 13:54]:
> On Monday 16 March 2015 20:59:04 Russell King - ARM Linux wrote:
> > On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316
> > > 09:15]:
> > > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren
> > > > wrote:
> > > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > > > > On Fri 2015-02-27 16:55:26, Pali Rohár wrote:
> > > > > > > This patch adds support for DT "/revision" and
> > > > > > > convert ATAG_REVISION to DT.
> > > > > > > 
> > > > > > > Pali Rohár (2):
> > > > > > >   arm: devtree: Set system_rev from DT revision
> > > > > > >   arm: boot: convert ATAG_REVISION to DT revision
> > > > > > >   field
> > > > > > 
> > > > > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > > > 
> > > > > Are these queued somewhere now? Sounds like this is the
> > > > > last pending issue for n900 to use legacy user space
> > > > > with current mainline kernels, so I'd like to get these
> > > > > in so we can get closer to making omap3 boot in device
> > > > > tree only mode.
> > > > 
> > > > Not that I know of.  As everyone is aware, patches need to
> > > > be in my patch system if they want me to apply them -
> > > > which would've been especially important as I was away
> > > > from kernel stuff for a week at the start of March (for
> > > > medical reasons) and I can't be expected to track the
> > > > status of stuff which is buried behind 1000+ extra mails.
> > > 
> > > Pali, care to upload these two patches to Russell's patch
> > > tracking system if no other comments?
> > 
> > If it's done soon, I should be able to send them to Linus
> > fairly quickly, since this problem I'm grappling with is
> > being seen by others who have better tools to be able to
> > investigate the problem (and hence they're in a better
> > position to investigate what's going on.)
> 
> I have no idea how to upload those patches into tracking system. 
> Right now I do not have enough time for testing any patches...

Well it's pretty easy, all you have to do is upload them to:

http://www.arm.linux.org.uk/developer/patches/

There's an email interface it too.
 
> Tony, or somebody else, if you have free time, can you upload 
> (my) patches to that needed tracking system?

Eeek, I'm swamped too, probably best that you do it yourself
since they're your patches.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

* [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision
@ 2015-03-16 20:59                                             ` Tony Lindgren
  0 siblings, 0 replies; 197+ messages in thread
From: Tony Lindgren @ 2015-03-16 20:59 UTC (permalink / raw)
  To: linux-arm-kernel

* Pali Roh?r <pali.rohar@gmail.com> [150316 13:54]:
> On Monday 16 March 2015 20:59:04 Russell King - ARM Linux wrote:
> > On Mon, Mar 16, 2015 at 11:10:26AM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux <linux@arm.linux.org.uk> [150316
> > > 09:15]:
> > > > On Mon, Mar 16, 2015 at 08:44:10AM -0700, Tony Lindgren
> > > > wrote:
> > > > > * Pavel Machek <pavel@ucw.cz> [150302 03:32]:
> > > > > > On Fri 2015-02-27 16:55:26, Pali Roh?r wrote:
> > > > > > > This patch adds support for DT "/revision" and
> > > > > > > convert ATAG_REVISION to DT.
> > > > > > > 
> > > > > > > Pali Roh?r (2):
> > > > > > >   arm: devtree: Set system_rev from DT revision
> > > > > > >   arm: boot: convert ATAG_REVISION to DT revision
> > > > > > >   field
> > > > > > 
> > > > > > Acked-by: Pavel Machek <pavel@ucw.cz>
> > > > > 
> > > > > Are these queued somewhere now? Sounds like this is the
> > > > > last pending issue for n900 to use legacy user space
> > > > > with current mainline kernels, so I'd like to get these
> > > > > in so we can get closer to making omap3 boot in device
> > > > > tree only mode.
> > > > 
> > > > Not that I know of.  As everyone is aware, patches need to
> > > > be in my patch system if they want me to apply them -
> > > > which would've been especially important as I was away
> > > > from kernel stuff for a week at the start of March (for
> > > > medical reasons) and I can't be expected to track the
> > > > status of stuff which is buried behind 1000+ extra mails.
> > > 
> > > Pali, care to upload these two patches to Russell's patch
> > > tracking system if no other comments?
> > 
> > If it's done soon, I should be able to send them to Linus
> > fairly quickly, since this problem I'm grappling with is
> > being seen by others who have better tools to be able to
> > investigate the problem (and hence they're in a better
> > position to investigate what's going on.)
> 
> I have no idea how to upload those patches into tracking system. 
> Right now I do not have enough time for testing any patches...

Well it's pretty easy, all you have to do is upload them to:

http://www.arm.linux.org.uk/developer/patches/

There's an email interface it too.
 
> Tony, or somebody else, if you have free time, can you upload 
> (my) patches to that needed tracking system?

Eeek, I'm swamped too, probably best that you do it yourself
since they're your patches.

Regards,

Tony

^ permalink raw reply	[flat|nested] 197+ messages in thread

end of thread, other threads:[~2015-03-16 21:04 UTC | newest]

Thread overview: 197+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-18 16:54 [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible Pali Rohár
2014-06-18 16:54 ` Pali Rohár
2014-06-18 19:01 ` Russell King - ARM Linux
2014-06-18 19:01   ` Russell King - ARM Linux
2014-06-18 19:09   ` Pali Rohár
2014-06-18 19:09     ` Pali Rohár
2014-06-18 19:59     ` Russell King - ARM Linux
2014-06-18 19:59       ` Russell King - ARM Linux
2014-06-19  8:21       ` Pavel Machek
2014-06-19  8:21         ` Pavel Machek
2014-07-11 19:31       ` Pavel Machek
2014-07-11 19:31         ` Pavel Machek
2014-06-18 19:07 ` Rob Herring
2014-06-18 19:07   ` Rob Herring
2014-06-18 19:22   ` Pali Rohár
2014-06-18 19:22     ` Pali Rohár
2014-06-18 20:00     ` Russell King - ARM Linux
2014-06-18 20:00       ` Russell King - ARM Linux
2014-06-18 20:20       ` Pali Rohár
2014-06-18 20:20         ` Pali Rohár
2014-06-18 21:53         ` Fabio Estevam
2014-06-18 21:53           ` Fabio Estevam
2014-11-24 22:16           ` Pali Rohár
2014-11-24 22:16             ` Pali Rohár
2014-06-18 20:46     ` Rob Herring
2014-06-18 20:46       ` Rob Herring
2014-06-18 21:47       ` Russell King - ARM Linux
2014-06-18 21:47         ` Russell King - ARM Linux
2014-06-18 22:27         ` Rob Herring
2014-06-18 22:27           ` Rob Herring
2014-06-18 23:07           ` Russell King - ARM Linux
2014-06-18 23:07             ` Russell King - ARM Linux
2014-11-24 22:19       ` Pali Rohár
2014-11-24 22:19         ` Pali Rohár
2014-12-04  0:33         ` Rob Herring
2014-12-04  0:33           ` Rob Herring
2014-12-04  0:48           ` Pali Rohár
2014-12-04  0:48             ` Pali Rohár
2014-12-04 16:49             ` Rob Herring
2014-12-04 16:49               ` Rob Herring
2014-12-04 17:57               ` Pali Rohár
2014-12-04 17:57                 ` Pali Rohár
2014-12-04 18:10                 ` Rob Herring
2014-12-04 18:10                   ` Rob Herring
2015-01-26 19:09                   ` [PATCH] ARM: /proc/cpuinfo: DT: Add support for Revision Pali Rohár
2015-01-26 19:09                     ` Pali Rohár
2015-01-26 20:22                     ` Rob Herring
2015-01-26 20:22                       ` Rob Herring
2015-01-30 14:14                       ` Pali Rohár
2015-01-30 14:14                         ` Pali Rohár
2015-01-30 21:03                         ` Rob Herring
2015-01-30 21:03                           ` Rob Herring
2015-02-27 15:45                           ` Pali Rohár
2015-02-27 15:45                             ` Pali Rohár
2015-02-27 15:55                             ` [PATCH v2 0/2] " Pali Rohár
2015-02-27 15:55                               ` Pali Rohár
2015-02-27 15:55                               ` [PATCH v2 1/2] arm: devtree: Set system_rev from DT revision Pali Rohár
2015-02-27 15:55                                 ` Pali Rohár
2015-02-27 15:55                               ` [PATCH v2 2/2] arm: boot: convert ATAG_REVISION to DT revision field Pali Rohár
2015-02-27 15:55                                 ` Pali Rohár
2015-03-02 11:28                               ` [PATCH v2 0/2] ARM: /proc/cpuinfo: DT: Add support for Revision Pavel Machek
2015-03-02 11:28                                 ` Pavel Machek
2015-03-16 15:44                                 ` Tony Lindgren
2015-03-16 15:44                                   ` Tony Lindgren
2015-03-16 16:14                                   ` Russell King - ARM Linux
2015-03-16 16:14                                     ` Russell King - ARM Linux
2015-03-16 16:43                                     ` Nicolas Pitre
2015-03-16 16:43                                       ` Nicolas Pitre
2015-03-16 19:21                                       ` Russell King - ARM Linux
2015-03-16 19:21                                         ` Russell King - ARM Linux
2015-03-16 18:10                                     ` Tony Lindgren
2015-03-16 18:10                                       ` Tony Lindgren
2015-03-16 19:59                                       ` Russell King - ARM Linux
2015-03-16 19:59                                         ` Russell King - ARM Linux
2015-03-16 20:54                                         ` Pali Rohár
2015-03-16 20:54                                           ` Pali Rohár
2015-03-16 20:59                                           ` Tony Lindgren
2015-03-16 20:59                                             ` Tony Lindgren
2015-01-26 22:34                     ` [PATCH] " Andreas Färber
2015-01-26 22:34                       ` Andreas Färber
2015-02-27 15:56                       ` Pali Rohár
2015-02-27 15:56                         ` Pali Rohár
2015-01-26 19:16                   ` [PATCH] ARM: /proc/atags: Export also for DT Pali Rohár
2015-01-26 19:16                     ` Pali Rohár
2015-01-26 20:33                     ` Rob Herring
2015-01-26 20:33                       ` Rob Herring
2015-01-27 13:21                       ` Pavel Machek
2015-01-27 13:21                         ` Pavel Machek
2015-01-27 14:16                         ` Rob Herring
2015-01-27 14:16                           ` Rob Herring
2015-01-27 14:24                           ` Pavel Machek
2015-01-27 14:24                             ` Pavel Machek
2015-01-27 14:32                           ` Pali Rohár
2015-01-27 14:32                             ` Pali Rohár
2015-01-27 17:48                             ` Russell King - ARM Linux
2015-01-27 17:48                               ` Russell King - ARM Linux
2015-01-27 20:03                               ` Nicolas Pitre
2015-01-27 20:03                                 ` Nicolas Pitre
2015-01-27 21:09                                 ` Russell King - ARM Linux
2015-01-27 21:09                                   ` Russell King - ARM Linux
2015-01-27 21:34                                   ` Nicolas Pitre
2015-01-27 21:34                                     ` Nicolas Pitre
2015-01-27 21:58                                     ` Nicolas Pitre
2015-01-27 21:58                                       ` Nicolas Pitre
2015-01-27 22:33                                     ` Russell King - ARM Linux
2015-01-27 22:33                                       ` Russell King - ARM Linux
2015-01-28  2:07                                       ` Nicolas Pitre
2015-01-28  2:07                                         ` Nicolas Pitre
2015-01-28  6:21                                         ` Jean-Christophe PLAGNIOL-VILLARD
2015-01-28  6:21                                           ` Jean-Christophe PLAGNIOL-VILLARD
2015-01-28  7:19                                           ` Pavel Machek
2015-01-28  7:19                                             ` Pavel Machek
2015-01-28  8:06                                             ` Jean-Christophe PLAGNIOL-VILLARD
2015-01-28  8:06                                               ` Jean-Christophe PLAGNIOL-VILLARD
2015-01-28  8:25                                               ` Pavel Machek
2015-01-28  8:25                                                 ` Pavel Machek
2015-01-28  7:18                                         ` Pavel Machek
2015-01-28  7:18                                           ` Pavel Machek
2015-01-28 13:38                                         ` Pali Rohár
2015-01-28 13:38                                           ` Pali Rohár
2015-01-27 23:10                                     ` Pavel Machek
2015-01-27 23:10                                       ` Pavel Machek
2015-01-28  0:50                               ` Tony Lindgren
2015-01-28  0:50                                 ` Tony Lindgren
2015-01-28 13:58                                 ` Pali Rohár
2015-01-28 13:58                                   ` Pali Rohár
2015-01-28 14:33                                   ` Nicolas Pitre
2015-01-28 15:39                                     ` Tony Lindgren
2015-01-28 15:39                                       ` Tony Lindgren
2015-01-28 15:47                                       ` Pali Rohár
2015-01-28 15:47                                         ` Pali Rohár
2015-01-28 15:48                                         ` Tony Lindgren
2015-01-28 15:48                                           ` Tony Lindgren
2015-01-28 16:31                                           ` Jason Cooper
2015-01-28 16:31                                             ` Jason Cooper
2015-01-28 15:57                                     ` Rob Herring
2015-01-28 15:57                                       ` Rob Herring
2015-01-28 16:13                                       ` Russell King - ARM Linux
2015-01-28 16:13                                         ` Russell King - ARM Linux
2015-01-28 16:19                                         ` Will Deacon
2015-01-28 16:19                                           ` Will Deacon
2015-01-28 17:01                                           ` Russell King - ARM Linux
2015-01-28 17:01                                             ` Russell King - ARM Linux
2015-01-28 17:29                                           ` Russell King - ARM Linux
2015-01-28 17:29                                             ` Russell King - ARM Linux
2015-01-28 17:18                                       ` Pali Rohár
2015-01-28 17:18                                         ` Pali Rohár
2015-01-28 18:00                                       ` Jean-Christophe PLAGNIOL-VILLARD
2015-01-28 18:00                                         ` Jean-Christophe PLAGNIOL-VILLARD
2015-01-28 19:33                                         ` Pali Rohár
2015-01-28 19:33                                           ` Pali Rohár
2015-01-28 18:03                                       ` Pavel Machek
2015-01-28 18:03                                         ` Pavel Machek
2015-01-28 19:27                                         ` Arnd Bergmann
2015-01-28 19:27                                           ` Arnd Bergmann
2015-01-28 14:46                                   ` Jean-Christophe PLAGNIOL-VILLARD
2015-01-28 14:46                                     ` Jean-Christophe PLAGNIOL-VILLARD
2015-01-27 19:40                         ` Nicolas Pitre
2015-01-27 19:40                           ` Nicolas Pitre
2015-01-26 20:37                     ` Russell King - ARM Linux
2015-01-26 20:37                       ` Russell King - ARM Linux
2015-01-26 20:44                       ` Pali Rohár
2015-01-26 20:44                         ` Pali Rohár
2014-12-04 19:00               ` [PATCH] ARM: /proc/cpuinfo: Use DT machine name when possible Pali Rohár
2014-12-04 19:00                 ` Pali Rohár
2014-12-04 10:59           ` Russell King - ARM Linux
2014-12-04 10:59             ` Russell King - ARM Linux
2014-06-18 21:10     ` Aaro Koskinen
2014-06-18 21:10       ` Aaro Koskinen
2014-07-11 19:28       ` Pavel Machek
2014-07-11 19:28         ` Pavel Machek
2014-11-24 22:21       ` Pali Rohár
2014-11-24 22:21         ` Pali Rohár
2014-09-05 11:38 ` Pali Rohár
2014-09-05 11:38   ` Pali Rohár
2014-09-05 12:13   ` Russell King - ARM Linux
2014-09-05 12:13     ` Russell King - ARM Linux
2014-09-10 12:46     ` Pavel Machek
2014-09-10 12:46       ` Pavel Machek
2014-11-24 22:23       ` Pali Rohár
2014-11-24 22:23         ` Pali Rohár
2014-09-05 13:45   ` Mark Rutland
2014-09-05 13:45     ` Mark Rutland
2014-09-05 13:52     ` Pali Rohár
2014-09-05 13:52       ` Pali Rohár
2014-09-05 13:58       ` Mark Rutland
2014-09-05 13:58         ` Mark Rutland
2014-11-24 22:25         ` Pali Rohár
2014-11-24 22:25           ` Pali Rohár
2014-09-05 13:58       ` Fabio Estevam
2014-09-05 13:58         ` Fabio Estevam
2014-11-24 22:27         ` Pali Rohár
2014-11-24 22:27           ` Pali Rohár
2014-09-06 15:34       ` Andreas Färber
2014-09-06 15:34         ` Andreas Färber
2014-11-24 22:29         ` Pali Rohár
2014-11-24 22:29           ` Pali Rohár

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.