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
_______________________________________________
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
