[PATCH v2] ARM: remove name from machine_desc for DT platforms

Grant Likely grant.likely at secretlab.ca
Mon Nov 18 07:59:45 EST 2013


On Thu, 14 Nov 2013 17:17:55 -0600, Rob Herring <robherring2 at gmail.com> wrote:
> On 11/14/2013 11:16 AM, Grant Likely wrote:
> > On Thu, Nov 14, 2013 at 11:46 PM, Rob Herring <robherring2 at gmail.com> wrote:
> >> On 11/14/2013 07:33 AM, Grant Likely wrote:
> >>> On Thu, Nov 14, 2013 at 9:32 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> >>>> On Wednesday 13 November 2013, Rob Herring wrote:
> >>>>> I'm not inclined to expand cpuinfo and prior attempts to add more info
> >>>>> to cpuinfo like SoC name have failed. The differences between x86 and
> >>>>> arm cpuinfo already cause issues for arm. lscpu does not really work on arm.
> >>>>
> >>>> Well, they turned into drivers/base/soc.c, which adds the information in
> >>>> a structured way in sysfs, but is only used on a couple of platforms.
> >>>>
> >>>>> I'd actually prefer If you really want more system info, then go read
> >>>>> /proc/device-tree.
> >>>
> >>> I really don't mind pulling that information out of /proc/cpuinfo. My
> >>> point is merely that it is incredibly useful to be able to easily find
> >>> out exactly which machine_desc got chosen on any given platform. I
> >>> don't think I should have to grep the source tree to figure that out.
> >>>
> >>> The kernel log is useful, but it is also helpful to have it in a /proc
> >>> or /sysfs file for when the kernel log overflows. /proc/device-tree
> >>> doesn't give that information.
> >>
> >> Either we want to shrink/remove machine_desc or we don't. If we do, then
> >> the name has to go at some point. So what is the reason to remove it
> >> later rather than sooner? Later means we will have "Generic DT based
> >> system" in cpuinfo as platforms transition. Perhaps that is useful to
> >> know in the short term, but once all platforms print the same thing the
> >> information becomes useless. Then we either remove Hardware field from
> >> cpuinfo or change to use DT info. That's changing the string twice
> >> rather than once.
> >>
> >> We probably have at least a dozen machine_desc's we are close to being
> >> able to remove (sunxi, picoxcell, highbank, dove, rockchip, virt,
> >> several sh-mobile). There's also more that probably can be combined
> >> together which will change the string in /proc/cpuinfo.
> >>
> >> If this is a required feature then we should make machine_desc common
> >> (or at least part of it) with the other arches that have copied arm and
> >> then add it to arm64 as well. Then I could do further consolidation of
> >> the FDT machine matching code. Otherwise this is all just pointless
> >> architecture variation that really has nothing to do with the architecture.
> > 
> > I think you are missing my point. go ahead, take it out of
> > /proc/cpuinfo. That's not the issue.
> 
> I understand what you want. I just don't see a solution that satisfies
> you, Olof, and me. I don't see an easy way to add both strings in a way
> that is not an ABI, but yet is persistently available. I'm not sure I
> understand a scenario where you boot successfully enough to read
> /proc/cpuinfo, /sys or something, but cannot get the kernel log.

Okay, I'm being selfish. When the kernel output overflows the log buf
then I don't get the machine_desc structure. I won't make a big fuss
about this if it causes a lot of pain. As long as it shows up in the
boot log then I'm happy.

g.



More information about the linux-arm-kernel mailing list