[PATCH RFC 2/8] DRM: Armada: Add Armada DRM driver

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Mon, Jun 10, 2013 at 05:01:18PM -0400, Rob Clark wrote:
> I would like to get at least some of the driver upstream.  I'd hate
> for it to have to live completely out of tree.  I can think of a
> couple possibilities.
> 
> 1) the best would be, if there was some way for the drm driver to know
> the upper/lower bounds of the carveout, then it could bounds-check
> against this.  And then in worst case, userspace can just screw up
> other "graphics" buffers

The bounds check does what?  Check that the buffer object's physical
address is within another driver's range?  Fine, but all that it's
doing is preventing it being associated with a buffer object which can
_only_ be used for _read_ access by the LCD controller.  There is no
write access to the GEM objects by anything that this DRM driver talks
to.

So all it'll do is prevent you passing rogue addresses to the LCD
controller for scanout.

And how do we get that information into the driver from other random
drivers?  Hack in random inter-driver specific APIs to do it?  Come
up with yet another different way to try and identify whether a
particular resource is a block of reserved memory for this driver's
usage as a linear region or one of the others?  How.  Really, please
think about the problem.

The benefit vs the complexity involved really isn't worth it.