On Mon, Jun 01, 2020 at 06:56:46PM +0200, Thomas Bogendoerfer wrote:

On Mon, Jun 01, 2020 at 06:24:49PM +0300, Serge Semin wrote:

quoted

Hello Marc,

On Mon, Jun 01, 2020 at 01:31:27PM +0100, Marc Zyngier wrote:

quoted

On 2020-06-01 13:21, Serge Semin wrote:

[...]

quoted

Since Paul isn't looking after the MIPS arch code anymore, Ralf hasn't
been seen maintaining MIPS for a long time, Thomas is only responsible
for the next part of it:
	F:      Documentation/devicetree/bindings/mips/
	F:      Documentation/mips/
	F:      arch/mips/
	F:      drivers/platform/mips/
the MIPS-specific drivers like:
	F:	drivers/bus/mips_cdmm.c
	F:	drivers/irqchip/irq-mips-cpu.c
	F:	drivers/irqchip/irq-mips-gic.c
	F:	drivers/clocksource/mips-gic-timer.c
	F:	drivers/cpuidle/cpuidle-cps.c
seem to be left for the subsystems maintainers to support. So if you
don't
mind or unless there is a better alternative, I can help with looking
after them to ease the maintainers review burden and since I'll be
working
on our MIPS-based SoC drivers integrating into the mainline kernel repo
anyway. If you don't like this idea, please just decline the last
patch in the series.

quoted

Given how deeply integrated the MIPS GIC is in the architecture, I'd
really like Thomas to co-maintain it, or at the very least give his
blessing on you being the dedicated point of contact for MIPS GIC
stuff.

I don't mind either way. First option might be even better. Thomas,
what do you think?

sure, I'm happy to be your co-maintainer.

Great! As soon as we finish a discussion regarding the files-list ordering
raised around the last patch in the series, I'll resend the patchset with you
added to the list of the MIPS core drivers maintainers.

-Sergey

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.                                                [ RFC1925, 2.3 ]