Raspberry Pi mailbox drivers

[Eric Anholt]

This series can also be found at:

https://github.com/anholt/linux/tree/rpi-mailbox

The generic mailbox stuff was seen on the list last October:

http://marc.info/?l=linux-arm-kernel&m=141415695904815&w=2

which got review comments and then, as far as I can see, never got
resubmitted.  I think I've dealt with those comments except for the
following:

- Kconfig should say "Y or M" instead of "Y"

It looks like the majority behavior in Kconfig is to just say "Y"
generally, even for module things.

- Alphabetizing Makefile / Kconfig additions

In the time since the submission, everything else has been added in
submission order rather than alphabetizing, so I'm following that.

- Authorship (Lubomir or Craig) on the patch

Lubomir's patch (the one being reviewed) said it was squash of Craig's
onto previous work by Lubomir.  Craig's patch
(http://marc.info/?l=linux-arm-kernel&m=137907209606316&w=2) looked
like it was a replacement of a previous driver by Lubomir with a
rewrite onto the generic mailbox support.  Enough got rewritten in
Craig's rework that I could easily see his name going on the patch,
but I think it's a derivative of Lubomir's.  However, Lubomir did go
on to do some significant cleanup of Craig's work, as well.  I've left
Lubomir's name on the patch and made the MODULE_AUTHOR be him.  If
Craig is bothered by this, I'd be happy to try to work something out,
but this is one of those places where a certain style of development
is hard to fairly represent given the way we like history to happen in
the kernel tree.

My two driver bits haven't been seen on the list before.  I did read
some other drivers in the process of writing them (particularly the
downstream Raspberry Pi vcio.c and power.c).  I've tested the property
channel with some ad-hoc code to dump a few properties, and the
results look good.

I haven't added a MAINTAINERS entry for this series.  I'm personally
happy with the maintainers being the 2835 arch maintainers, but I'd
also be willing to add myself as a maintainer if that was desired.  I
should also be able to answer questions about the firmware behavior,
which would probably be useful to anyone trying to build more drivers
using this code.