ARM: /proc/cpuinfo: Use DT machine name when possible
diff mbox

Message ID 1403110464-29646-1-git-send-email-pali.rohar@gmail.com
State New
Headers show

Commit Message

Pali Rohár June 18, 2014, 4:54 p.m. UTC
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(-)

Comments

Russell King - ARM Linux June 18, 2014, 7:01 p.m. UTC | #1
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."
Pali Rohár June 18, 2014, 7:09 p.m. UTC | #2
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.
Russell King - ARM Linux June 18, 2014, 7:59 p.m. UTC | #3
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.
Pavel Machek June 19, 2014, 8:21 a.m. UTC | #4
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
Pavel Machek July 11, 2014, 7:31 p.m. UTC | #5
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
Pali Rohár Sept. 5, 2014, 11:38 a.m. UTC | #6
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...
Russell King - ARM Linux Sept. 5, 2014, 12:13 p.m. UTC | #7
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.
Mark Rutland Sept. 5, 2014, 1:45 p.m. UTC | #8
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.
Pali Rohár Sept. 5, 2014, 1:52 p.m. UTC | #9
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)?
Mark Rutland Sept. 5, 2014, 1:58 p.m. UTC | #10
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.
Fabio Estevam Sept. 5, 2014, 1:58 p.m. UTC | #11
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
Andreas Färber Sept. 6, 2014, 3:34 p.m. UTC | #12
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
Pavel Machek Sept. 10, 2014, 12:46 p.m. UTC | #13
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
Pali Rohár Nov. 24, 2014, 10:23 p.m. UTC | #14
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 Nov. 24, 2014, 10:25 p.m. UTC | #15
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 Nov. 24, 2014, 10:27 p.m. UTC | #16
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 Nov. 24, 2014, 10:29 p.m. UTC | #17
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.

Patch
diff mbox

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;