Re: microchip soc maintainance change proposal

[Alexandre Belloni <alexandre.belloni@bootlin.com>]

On 24/09/2024 16:05:45+0200, Nicolas Ferre wrote:
> On 24/09/2024 at 13:46, Conor Dooley wrote:
> > Hey folks,
> > 
> > I mentioned this to Arnd and Alexandre at LPC, and to Nicolas before
> > that, but I would like to propose some changes to how the Microchip soc
> > support is maintained - mostly affecting the riscv side of things that
> > I've been maintaining in my personal tree, alongside other platforms.
> > I'd like to propose moving those from my tree, into the at91 tree.
> 
> I don't know if the "at91" naming will remain a right designation of what
> we're doing in the future, but well, let's stick to it for now.
> Some find it a little too much tight to the old Atmel brand...
> 

We could take this opportunity to rename the tree microchip or mchp. 

> > While the dts bits for the arm and riscv platforms have no overlap
> > and nothing is particularly gained from me moving which tree
> > location they're in, I'm far more interested in disambiguating the tree
> > that soc and/or firmware bindings and drivers end up in.
> > 
> > I was going to add the bindings/soc/microchip directory to the
> > maintainers entry I have for drivers/soc/microchip, but while doing
> > that, I noticed that there have been recent patches for sam and sparx5
> 
> FYI: and we have the older drivers/soc/atmel directory (which is caught by
> "ARM/Microchip (AT91) SoC support" entry).
> 
> > bits that have added files to that bindings directory that went via at91
> > and I figure it's almost certain that there'll be drivers added before
> > too long. Having a single location, like we do at the moment for clocks,
> > would make the route upstream for things a bit clearer - and I figured
> > that while moving one thing, might as well move the firmware and dts
> > stuff too.
> > 
> > My assumption is that the riscv dts bits would retain their own branch,
> > and that I'd still send the PRs for them and for the firmware stuff given
> > that there's no !riscv soc content in that directory yet - and I don't
> > want to saddle Claudiu with more work for devices he probably doesn't
> > care about...
> > 
> > Seem reasonable?
> 
> That's fine with me Conor. It makes a lot of sense as we're working on more
> and more topics together.

Looks good to me.

-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com