| Message ID | 1403110464-29646-1-git-send-email-pali.rohar@gmail.com |
|---|---|
| State | New |
| Headers | show |
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."
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.
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.
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
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
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...
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.
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.
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)?
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.
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
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
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
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).
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.
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.
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.
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;
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(-)