[PATCH 0/1] About MIPS/Loongson maintainance

[PATCH 0/1] About MIPS/Loongson maintainance

[Huacai Chen]

Hi, Linus, Stephen, Greg, Ralf and James,

We are kernel developers from Lemote Inc. and Loongson community. We
have already made some contributions in Linux kernel, but we hope we
can do more works.

Of course Loongson is a sub-arch in MIPS, but linux-mips community is
so inactive (Maybe maintainers are too busy?) that too many patches (
Not only for Loongson, but also for other sub-archs) were delayed for
a long time. So we are seeking a more efficient way to make Loongson
patches be merged in upstream.

Now we have a github organization for collaboration:
https://github.com/linux-loongson/linux-loongson.git

We don't want to replace linux-mips, we just want to find a way to co-
operate with linux-mips. So we will still use the maillist and patchwork
of linux-mips, but we hope we can send pull requests from our github to
linux-next and linux-mainline by ourselves (if there is no objections
to our patches from linux-mips community).

If we are doing something wrong, please let us know. Thanks very much!

--
2.7.0

[PATCH 1/1] MAINTAINERS: Add Loongson-2/Loongson-3 maintainers

[Huacai Chen]

Add Jiaxun Yang as the MIPS/Loongson-2 maintainer and add Huacai Chen
as the MIPS/Loongson-3 maintainer.

Signed-off-by: Huacai Chen <chenhc@lemote.com>
Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
---
 MAINTAINERS | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index cdd6365..bf449da 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9141,6 +9141,26 @@ F:	arch/mips/include/asm/mach-loongson32/
 F:	drivers/*/*loongson1*
 F:	drivers/*/*/*loongson1*
 
+MIPS/LOONGSON2 ARCHITECTURE
+M:	Jiaxun Yang <jiaxun.yang@flygoat.com>
+L:	linux-mips@linux-mips.org
+S:	Maintained
+F:	arch/mips/loongson64/*{2e/2f}*
+F:	arch/mips/include/asm/mach-loongson64/
+F:	drivers/platform/mips/
+F:	drivers/*/*loongson2*
+F:	drivers/*/*/*loongson2*
+
+MIPS/LOONGSON3 ARCHITECTURE
+M:	Huacai Chen <chenhc@lemote.com>
+L:	linux-mips@linux-mips.org
+S:	Maintained
+F:	arch/mips/loongson64/
+F:	arch/mips/include/asm/mach-loongson64/
+F:	drivers/platform/mips/
+F:	drivers/*/*loongson3*
+F:	drivers/*/*/*loongson3*
+
 MIPS RINT INSTRUCTION EMULATION
 M:	Aleksandar Markovic <aleksandar.markovic@mips.com>
 L:	linux-mips@linux-mips.org
-- 
2.7.0

Re: [PATCH 0/1] About MIPS/Loongson maintainance

[Greg Kroah-Hartman]

On Thu, Dec 07, 2017 at 02:31:07PM +0800, Huacai Chen wrote:
> Hi, Linus, Stephen, Greg, Ralf and James,
> 
> We are kernel developers from Lemote Inc. and Loongson community. We
> have already made some contributions in Linux kernel, but we hope we
> can do more works.
> 
> Of course Loongson is a sub-arch in MIPS, but linux-mips community is
> so inactive (Maybe maintainers are too busy?) that too many patches (
> Not only for Loongson, but also for other sub-archs) were delayed for
> a long time. So we are seeking a more efficient way to make Loongson
> patches be merged in upstream.
> 
> Now we have a github organization for collaboration:
> https://github.com/linux-loongson/linux-loongson.git

Ick, why not get a kernel.org account for your git tree?

> We don't want to replace linux-mips, we just want to find a way to co-
> operate with linux-mips. So we will still use the maillist and patchwork
> of linux-mips, but we hope we can send pull requests from our github to
> linux-next and linux-mainline by ourselves (if there is no objections
> to our patches from linux-mips community).

What does the mips maintainers think about this?

Odds are a linux-next tree is fine, but they probably want to merge the
trees into their larger mips one for the pulls to Linus, much like the
arm-core tree works, right?

thanks,

greg k-h

Re: [PATCH 0/1] About MIPS/Loongson maintainance

[Jiaxun Yang]

[-- Attachment #1: Type: text/plain, Size: 1902 bytes --]

On 2017-12-07 07:57 +0100，Greg Kroah-Hartman wrote：
> On Thu, Dec 07, 2017 at 02:31:07PM +0800, Huacai Chen wrote:
> > Hi, Linus, Stephen, Greg, Ralf and James,
> > 
> > We are kernel developers from Lemote Inc. and Loongson community.
> > We
> > have already made some contributions in Linux kernel, but we hope
> > we
> > can do more works.
> > 
> > Of course Loongson is a sub-arch in MIPS, but linux-mips community
> > is
> > so inactive (Maybe maintainers are too busy?) that too many patches
> > (
> > Not only for Loongson, but also for other sub-archs) were delayed
> > for
> > a long time. So we are seeking a more efficient way to make
> > Loongson
> > patches be merged in upstream.
> > 
> > Now we have a github organization for collaboration:
> > https://github.com/linux-loongson/linux-loongson.git
> 
> Ick, why not get a kernel.org account for your git tree?

Of course we would like to get a kernel.org account. But in order to
get a kernel.org account, we must have enough kernel developer's PGP
sigs. In mainland China, it's hard to meet any of them. So wo choose
GitHub to host our git tree.
 
> 
> > We don't want to replace linux-mips, we just want to find a way to
> > co-
> > operate with linux-mips. So we will still use the maillist and
> > patchwork
> > of linux-mips, but we hope we can send pull requests from our
> > github to
> > linux-next and linux-mainline by ourselves (if there is no
> > objections
> > to our patches from linux-mips community).
> 
> What does the mips maintainers think about this?
> 
> Odds are a linux-next tree is fine, but they probably want to merge
> the
> trees into their larger mips one for the pulls to Linus, much like
> the
> arm-core tree works, right?
Yeah, thanks for your suggestion, we can do like this to reduce work
load of Linus.
> 
> thanks,
> 
> greg k-h

Jiaxun Yang

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/1] About MIPS/Loongson maintainance

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]

On Thu, Dec 07, 2017 at 07:57:59AM +0100, Greg Kroah-Hartman wrote:
> On Thu, Dec 07, 2017 at 02:31:07PM +0800, Huacai Chen wrote:
> > Hi, Linus, Stephen, Greg, Ralf and James,
> > 
> > We are kernel developers from Lemote Inc. and Loongson community. We
> > have already made some contributions in Linux kernel, but we hope we
> > can do more works.
> > 
> > Of course Loongson is a sub-arch in MIPS, but linux-mips community is
> > so inactive (Maybe maintainers are too busy?) that too many patches (
> > Not only for Loongson, but also for other sub-archs) were delayed for
> > a long time. So we are seeking a more efficient way to make Loongson
> > patches be merged in upstream.
> > 
> > Now we have a github organization for collaboration:
> > https://github.com/linux-loongson/linux-loongson.git
> 
> Ick, why not get a kernel.org account for your git tree?
> 
> > We don't want to replace linux-mips, we just want to find a way to co-
> > operate with linux-mips. So we will still use the maillist and patchwork
> > of linux-mips, but we hope we can send pull requests from our github to
> > linux-next and linux-mainline by ourselves (if there is no objections
> > to our patches from linux-mips community).
> 
> What does the mips maintainers think about this?
> 
> Odds are a linux-next tree is fine, but they probably want to merge the
> trees into their larger mips one for the pulls to Linus, much like the
> arm-core tree works, right?

I'm not officially a MIPS maintainer but I have donned the hat
unofficially a few times lately, so FWIW I think the Loongson stuff
should go through the MIPS tree, since it so often touches core
architecture code.

Clearly there have been some issues getting MIPS stuff applied recently,
but I think the right approach long-term is to try and improve things
there rather than bypass the MIPS tree altogether.

I believe assigning a co-maintainer would help spread Ralf's load, even
if that primarily means helping review patches (something we can all
help with tbh), and being able to ack patches which touch MIPS but need
to go through other subsystem trees (e.g. I know David Daney was waiting
on acks for the MIPS portions of the Octeon III ethernet driver series).

I'm willing to take on that role if Ralf is okay with it. I'm already
trying to keep track of fixes and spend more time reviewing patches on
the list, but the more who can help out the better.

The question of who applies patches can't be avoided though. It would
clearly suck to have all the review in the world but still end up with
the co-maintainer having to take the reigns at the last minute to get
those important fixes in, and then have no time to apply anything
substantial for the merge window.

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/1] About MIPS/Loongson maintainance

[Jiaxun Yang]

On 2017-12-07 Thu 11:05 +0000，James Hogan Wrote：
> On Thu, Dec 07, 2017 at 07:57:59AM +0100, Greg Kroah-Hartman wrote:
> > On Thu, Dec 07, 2017 at 02:31:07PM +0800, Huacai Chen wrote:
> > > Hi, Linus, Stephen, Greg, Ralf and James,
> > > 
> > > We are kernel developers from Lemote Inc. and Loongson community.
> > > We
> > > have already made some contributions in Linux kernel, but we hope
> > > we
> > > can do more works.
> > > 
> > > Of course Loongson is a sub-arch in MIPS, but linux-mips
> > > community is
> > > so inactive (Maybe maintainers are too busy?) that too many
> > > patches (
> > > Not only for Loongson, but also for other sub-archs) were delayed
> > > for
> > > a long time. So we are seeking a more efficient way to make
> > > Loongson
> > > patches be merged in upstream.
> > > 
> > > Now we have a github organization for collaboration:
> > > https://github.com/linux-loongson/linux-loongson.git
> > 
> > Ick, why not get a kernel.org account for your git tree?
> > 
> > > We don't want to replace linux-mips, we just want to find a way
> > > to co-
> > > operate with linux-mips. So we will still use the maillist and
> > > patchwork
> > > of linux-mips, but we hope we can send pull requests from our
> > > github to
> > > linux-next and linux-mainline by ourselves (if there is no
> > > objections
> > > to our patches from linux-mips community).
> > 
> > What does the mips maintainers think about this?
> > 
> > Odds are a linux-next tree is fine, but they probably want to merge
> > the
> > trees into their larger mips one for the pulls to Linus, much like
> > the
> > arm-core tree works, right?
> 
> I'm not officially a MIPS maintainer but I have donned the hat
> unofficially a few times lately, so FWIW I think the Loongson stuff
> should go through the MIPS tree, since it so often touches core
> architecture code.
Yes we are always touching architecture code. For that part, we'll
still submit our patches to linux-mips tree. But we're also maintaining
many platform code under /arch/mips/loongson64 and also platform
drivers such as hwmon, cpufreq and YeeLoong Laptop driver I'm trying to
submit recently. For that part, make a pull request might be more
efficient than apply patches to linux-mips for many times. Just as what
arm architecture did.

We would like to reduce Ralf's work load. Not bypassing him.

> Clearly there have been some issues getting MIPS stuff applied
> recently,
> but I think the right approach long-term is to try and improve things
> there rather than bypass the MIPS tree altogether.
> 
> I believe assigning a co-maintainer would help spread Ralf's load,
> even
> if that primarily means helping review patches (something we can all
> help with tbh), and being able to ack patches which touch MIPS but
> need
> to go through other subsystem trees (e.g. I know David Daney was
> waiting
> on acks for the MIPS portions of the Octeon III ethernet driver
> series).
I agree with that. Ralf really need help.
> I'm willing to take on that role if Ralf is okay with it. I'm already
> trying to keep track of fixes and spend more time reviewing patches
> on
> the list, but the more who can help out the better.
> 
> The question of who applies patches can't be avoided though. It would
> clearly suck to have all the review in the world but still end up
> with
> the co-maintainer having to take the reigns at the last minute to get
> those important fixes in, and then have no time to apply anything
> substantial for the merge window.
> 
> Cheers
> James
-- 
Jiaxun Yang

Re: [PATCH 0/1] About MIPS/Loongson maintainance

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 2852 bytes --]

On Thu, Dec 07, 2017 at 09:10:10PM +0800, Jiaxun Yang wrote:
> On 2017-12-07 Thu 11:05 +0000，James Hogan Wrote：
> > On Thu, Dec 07, 2017 at 07:57:59AM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Dec 07, 2017 at 02:31:07PM +0800, Huacai Chen wrote:
> > > > Hi, Linus, Stephen, Greg, Ralf and James,
> > > > 
> > > > We are kernel developers from Lemote Inc. and Loongson community.
> > > > We
> > > > have already made some contributions in Linux kernel, but we hope
> > > > we
> > > > can do more works.
> > > > 
> > > > Of course Loongson is a sub-arch in MIPS, but linux-mips
> > > > community is
> > > > so inactive (Maybe maintainers are too busy?) that too many
> > > > patches (
> > > > Not only for Loongson, but also for other sub-archs) were delayed
> > > > for
> > > > a long time. So we are seeking a more efficient way to make
> > > > Loongson
> > > > patches be merged in upstream.
> > > > 
> > > > Now we have a github organization for collaboration:
> > > > https://github.com/linux-loongson/linux-loongson.git
> > > 
> > > Ick, why not get a kernel.org account for your git tree?
> > > 
> > > > We don't want to replace linux-mips, we just want to find a way
> > > > to co-
> > > > operate with linux-mips. So we will still use the maillist and
> > > > patchwork
> > > > of linux-mips, but we hope we can send pull requests from our
> > > > github to
> > > > linux-next and linux-mainline by ourselves (if there is no
> > > > objections
> > > > to our patches from linux-mips community).
> > > 
> > > What does the mips maintainers think about this?
> > > 
> > > Odds are a linux-next tree is fine, but they probably want to merge
> > > the
> > > trees into their larger mips one for the pulls to Linus, much like
> > > the
> > > arm-core tree works, right?
> > 
> > I'm not officially a MIPS maintainer but I have donned the hat
> > unofficially a few times lately, so FWIW I think the Loongson stuff
> > should go through the MIPS tree, since it so often touches core
> > architecture code.
> Yes we are always touching architecture code. For that part, we'll
> still submit our patches to linux-mips tree. But we're also maintaining
> many platform code under /arch/mips/loongson64 and also platform
> drivers such as hwmon, cpufreq and YeeLoong Laptop driver I'm trying to
> submit recently.

The drivers at least can always go in via the relevant driver subsystem
anyway, though of course if they're tightly bound to arch headers that
could still be painful, as I found out here when trying to fix some
build errors there:
https://lkml.kernel.org/r/20171115211755.25102-1-james.hogan@mips.com

Cheers
James

> For that part, make a pull request might be more
> efficient than apply patches to linux-mips for many times. Just as what
> arm architecture did.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/1] About MIPS/Loongson maintainance

[Jiaxun Yang]

On 2017-12-07 Thu 14:18 +0000，James Hogan Wrote：
> On Thu, Dec 07, 2017 at 09:10:10PM +0800, Jiaxun Yang wrote:
> > On 2017-12-07 Thu 11:05 +0000，James Hogan Wrote：
> > > On Thu, Dec 07, 2017 at 07:57:59AM +0100, Greg Kroah-Hartman
> > > wrote:
> > > > On Thu, Dec 07, 2017 at 02:31:07PM +0800, Huacai Chen wrote:
> > > > > Hi, Linus, Stephen, Greg, Ralf and James,
> > > > > 
> > > > > We are kernel developers from Lemote Inc. and Loongson
> > > > > community.
> > > > > We
> > > > > have already made some contributions in Linux kernel, but we
> > > > > hope
> > > > > we
> > > > > can do more works.
> > > > > 
> > > > > Of course Loongson is a sub-arch in MIPS, but linux-mips
> > > > > community is
> > > > > so inactive (Maybe maintainers are too busy?) that too many
> > > > > patches (
> > > > > Not only for Loongson, but also for other sub-archs) were
> > > > > delayed
> > > > > for
> > > > > a long time. So we are seeking a more efficient way to make
> > > > > Loongson
> > > > > patches be merged in upstream.
> > > > > 
> > > > > Now we have a github organization for collaboration:
> > > > > https://github.com/linux-loongson/linux-loongson.git
> > > > 
> > > > Ick, why not get a kernel.org account for your git tree?
> > > > 
> > > > > We don't want to replace linux-mips, we just want to find a
> > > > > way
> > > > > to co-
> > > > > operate with linux-mips. So we will still use the maillist
> > > > > and
> > > > > patchwork
> > > > > of linux-mips, but we hope we can send pull requests from our
> > > > > github to
> > > > > linux-next and linux-mainline by ourselves (if there is no
> > > > > objections
> > > > > to our patches from linux-mips community).
> > > > 
> > > > What does the mips maintainers think about this?
> > > > 
> > > > Odds are a linux-next tree is fine, but they probably want to
> > > > merge
> > > > the
> > > > trees into their larger mips one for the pulls to Linus, much
> > > > like
> > > > the
> > > > arm-core tree works, right?
> > > 
> > > I'm not officially a MIPS maintainer but I have donned the hat
> > > unofficially a few times lately, so FWIW I think the Loongson
> > > stuff
> > > should go through the MIPS tree, since it so often touches core
> > > architecture code.
> > 
> > Yes we are always touching architecture code. For that part, we'll
> > still submit our patches to linux-mips tree. But we're also
> > maintaining
> > many platform code under /arch/mips/loongson64 and also platform
> > drivers such as hwmon, cpufreq and YeeLoong Laptop driver I'm
> > trying to
> > submit recently.
> 
> The drivers at least can always go in via the relevant driver
> subsystem
> anyway, though of course if they're tightly bound to arch headers
> that
> could still be painful, as I found out here when trying to fix some
> build errors there:
> https://lkml.kernel.org/r/20171115211755.25102-1-james.hogan@mips.com
> 
Yes I noticed that previous maintainer have made some problems. I'm
going to fix that later. Also we're going to separate code between
Loongson2 and Loongson3 since they are becoming more and more
identical. But It will cause a lot of changes under march of loongson64
 that currently maintaining by linux-mips community. Send plenty of
patches to mailing list would not be a wise way to do that. So we can
PR these changes to linux-next directly and PR to linux-mips before
merge window.
> Cheers
> James
> 
> > For that part, make a pull request might be more
> > efficient than apply patches to linux-mips for many times. Just as
> > what
> > arm architecture did.
-- 
Jiaxun Yang

Re: [PATCH 0/1] About MIPS/Loongson maintainance

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 1590 bytes --]

On Fri, Dec 08, 2017 at 12:01:46PM +0800, Jiaxun Yang wrote:
> Also we're going to separate code between
> Loongson2 and Loongson3 since they are becoming more and more
> identical.

Do you mean you want to combine them?

> But It will cause a lot of changes under march of loongson64
>  that currently maintaining by linux-mips community. Send plenty of
> patches to mailing list would not be a wise way to do that. So we can
> PR these changes to linux-next directly and PR to linux-mips before
> merge window.

For the avoidance of doubt, a pull request would not excempt you from
needing your patches properly reviewed on the mailing lists first.

And quoting Stephen's boilerplate response to linux-next additions:
> Thanks for adding your subsystem tree as a participant of linux-next.  As
> you may know, this is not a judgement of your code.  The purpose of
> linux-next is for integration testing and to lower the impact of
> conflicts between subsystems in the next merge window.
> 
> You will need to ensure that the patches/commits in your tree/series have
> been:
>      * submitted under GPL v2 (or later) and include the Contributor's
>         Signed-off-by,
>      * posted to the relevant mailing list,
>      * reviewed by you (or another maintainer of your subsystem tree),
>      * successfully unit tested, and
>      * destined for the current or next Linux merge window.
> 
> Basically, this should be just what you would send to Linus (or ask him
> to fetch).  It is allowed to be rebased if you deem it necessary.

Cheers
James

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [PATCH 0/1] About MIPS/Loongson maintainance

[Huacai Chen]

Hi, James,

Of course we don't want to send PR directly, if there is a better way.
So, I hope you can officially be a co-maintainer of linux-mips, and as
a result, our community will become more active. I think most of MIPS
developers have the same will as me.

Huacai

On Fri, Dec 8, 2017 at 3:51 PM, James Hogan <james.hogan@mips.com> wrote:
> On Fri, Dec 08, 2017 at 12:01:46PM +0800, Jiaxun Yang wrote:
>> Also we're going to separate code between
>> Loongson2 and Loongson3 since they are becoming more and more
>> identical.
>
> Do you mean you want to combine them?
>
>> But It will cause a lot of changes under march of loongson64
>>  that currently maintaining by linux-mips community. Send plenty of
>> patches to mailing list would not be a wise way to do that. So we can
>> PR these changes to linux-next directly and PR to linux-mips before
>> merge window.
>
> For the avoidance of doubt, a pull request would not excempt you from
> needing your patches properly reviewed on the mailing lists first.
>
> And quoting Stephen's boilerplate response to linux-next additions:
>> Thanks for adding your subsystem tree as a participant of linux-next.  As
>> you may know, this is not a judgement of your code.  The purpose of
>> linux-next is for integration testing and to lower the impact of
>> conflicts between subsystems in the next merge window.
>>
>> You will need to ensure that the patches/commits in your tree/series have
>> been:
>>      * submitted under GPL v2 (or later) and include the Contributor's
>>         Signed-off-by,
>>      * posted to the relevant mailing list,
>>      * reviewed by you (or another maintainer of your subsystem tree),
>>      * successfully unit tested, and
>>      * destined for the current or next Linux merge window.
>>
>> Basically, this should be just what you would send to Linus (or ask him
>> to fetch).  It is allowed to be rebased if you deem it necessary.
>
> Cheers
> James

Re: [PATCH 0/1] About MIPS/Loongson maintainance

[Jiaxun Yang]

On 2017-12-08 Fri 07:51 +0000，James Hogan Wrote：
> On Fri, Dec 08, 2017 at 12:01:46PM +0800, Jiaxun Yang wrote:
> > Also we're going to separate code between
> > Loongson2 and Loongson3 since they are becoming more and more
> > identical.
> 
> Do you mean you want to combine them?

Sorry, my fault. They're become more and more different and  I'm going
to separate loongson64 into loongson2 and loongson3.

> 
> > But It will cause a lot of changes under march of loongson64
> >  that currently maintaining by linux-mips community. Send plenty of
> > patches to mailing list would not be a wise way to do that. So we
> > can
> > PR these changes to linux-next directly and PR to linux-mips before
> > merge window.

So we can commit by ourselves after subsystem's review to reduce linux-
mips's workload. 
Since Huacai Chen said that we won't send PR, maybe it's unnecessary.
Thanks.

> For the avoidance of doubt, a pull request would not excempt you from
> needing your patches properly reviewed on the mailing lists first.
> 
> And quoting Stephen's boilerplate response to linux-next additions:
> > Thanks for adding your subsystem tree as a participant of linux-
> > next.  As
> > you may know, this is not a judgement of your code.  The purpose of
> > linux-next is for integration testing and to lower the impact of
> > conflicts between subsystems in the next merge window.
> > 
> > You will need to ensure that the patches/commits in your
> > tree/series have
> > been:
> >      * submitted under GPL v2 (or later) and include the
> > Contributor's
> >         Signed-off-by,
> >      * posted to the relevant mailing list,
> >      * reviewed by you (or another maintainer of your subsystem
> > tree),
> >      * successfully unit tested, and
> >      * destined for the current or next Linux merge window.
> > 
> > Basically, this should be just what you would send to Linus (or ask
> > him
> > to fetch).  It is allowed to be rebased if you deem it necessary.
> 
> Cheers
> James
-- 
Jiaxun Yang

Re: [PATCH 1/1] MAINTAINERS: Add Loongson-2/Loongson-3 maintainers

[James Hogan]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

On Thu, Dec 07, 2017 at 02:31:08PM +0800, Huacai Chen wrote:
> Add Jiaxun Yang as the MIPS/Loongson-2 maintainer and add Huacai Chen
> as the MIPS/Loongson-3 maintainer.
> 
> Signed-off-by: Huacai Chen <chenhc@lemote.com>
> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com>
> ---
>  MAINTAINERS | 20 ++++++++++++++++++++
>  1 file changed, 20 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index cdd6365..bf449da 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9141,6 +9141,26 @@ F:	arch/mips/include/asm/mach-loongson32/
>  F:	drivers/*/*loongson1*
>  F:	drivers/*/*/*loongson1*
>  
> +MIPS/LOONGSON2 ARCHITECTURE
> +M:	Jiaxun Yang <jiaxun.yang@flygoat.com>
> +L:	linux-mips@linux-mips.org
> +S:	Maintained
> +F:	arch/mips/loongson64/*{2e/2f}*
> +F:	arch/mips/include/asm/mach-loongson64/
> +F:	drivers/platform/mips/
> +F:	drivers/*/*loongson2*
> +F:	drivers/*/*/*loongson2*
> +
> +MIPS/LOONGSON3 ARCHITECTURE
> +M:	Huacai Chen <chenhc@lemote.com>
> +L:	linux-mips@linux-mips.org
> +S:	Maintained
> +F:	arch/mips/loongson64/
> +F:	arch/mips/include/asm/mach-loongson64/
> +F:	drivers/platform/mips/
> +F:	drivers/*/*loongson3*
> +F:	drivers/*/*/*loongson3*

Ralf applied this patch without the drivers/platform/mips/ changes,
adding that instead to the main MIPS entry. I have already cherry picked
both into my 4.16 branch.

Thanks
James

> +
>  MIPS RINT INSTRUCTION EMULATION
>  M:	Aleksandar Markovic <aleksandar.markovic@mips.com>
>  L:	linux-mips@linux-mips.org
> -- 
> 2.7.0
> 

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]