On Thu, Jul 28, 2011 at 09:42:15PM +0200, Arnd Bergmann wrote:
On Thursday 28 July 2011 14:44:17 Nicolas Pitre wrote:
We could even embed the printch() function body into the DT if we wanted to make the kernel's job even simpler. Realistic implementations of this function are tiny, so this shouldn't be too cumbersome. That really seems an abuse of the DT though, since this goes beyond just describing the hardware.
Well... I'm not entirely against the idea. This could be seen as the most efficient way to describe how to output a character over some serial device for the given hardware. The danger is that some vendors might be tempted to abuse that idea by stuffing BIOS-like services in there that the kernel would have to cope with.
I thought about this before, but then remembered the horrors of RTAS on powerpc and quickly discarded the idea. There are so many ways in which this can backfire:
- People putting entire closed source device drivers into the firmware
and letting the kernel call that
- changing linkage convention in the kernel in a way that doesn't
work with the code: thumb2, big-endian, oabi, ...
- sharing (part of) a device tree on SoC platforms that have
multiple CPU architectures: TI C6x, qualcomm hexagon, freescale ppc, xilinx microblaze, openrisc
- subtle resource conflicts between the embedded code and other
device drivers, e.g. using the same IRQ, registers or pins.
Doing it just for printch sounds harmless at first, but I think we should say no to this solution whenever it comes up, so it doesn't have the chance to grow into something evil.
That sounds sensible to me; I was just throwing ideas about, really. The embedded code idea would work for this, but doesn't feel like the correct solution -- as you say, it invites future breakages and abuses, as well as going against the basic design principles of devicetree.
I guess the flipside is that it would be good to have a way to extract specific bits of information from the device tree really early during boot. We don't need this yet, but it could be worth exploring it next week.
Cheers ---Dave