[PATCH] MAINTAINERS: extend Raspberry Pi entry

[mzoran@crowfest.net (Michael Zoran)]

On Mon, 2017-01-30 at 09:51 +0100, Uwe Kleine-K?nig wrote:
> On Mon, Jan 30, 2017 at 12:09:32AM -0800, Michael Zoran wrote:
> > On Mon, 2017-01-30 at 08:56 +0100, Uwe Kleine-K?nig wrote:
> > > On Sun, Jan 29, 2017 at 02:24:08PM -0800, Michael Zoran wrote:
> > > I don't agree. To be able to review a driver to a Broadcom
> > > specific
> > > spi
> > > driver, you need to know more about spi than about Broadcom.
> > > 
> > 
> > I would say that's 50/50.??Some of these drivers like I2C or SPI
> > are?not really that complex.??The complexity happens when people
> > begin
> > to try to connect the various drivers in arbitrary ways at which
> > point
> > things begin to break.
> > 
> > SOCs are designed with cost in mind, so allowing arbitrary
> > configurations are not aways possible because of attempts to limits
> > the
> > amount of hardware resources required and the complexity. And I
> > don't
> > think this is specific to Broadcom or anybody. It's just the way
> > SOCs
> > work.
> > 
> > This is all vary different from PCs where you expect people to buy
> > random parts and start connecting them together.??For the reasons I
> > have given, SOCs arn't quite as flexible.
> 
> I fail to follow here. Can you please show an example where you see a
> benefit from having the drivers grouped by SoC instead of bus type?
> 

Two that instantly come to mind are GPIO function assignment and clock
management.   Most SOCs and I'm not just talking about the RPI can't
handle arbitrary configuration of GPIO function mapping.  They also
tend to generate one clock off the other for different peripherals. 
Change the clock of one peripheral or the CPU, and other peripheral
breaks.