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.
Arnd