[PATCH] ARM: /proc/atags: Export also for DT

[Russell King - ARM Linux]

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.