About MIPS/Loongson maintainance
cover About MIPS/Loongson maintainance
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
Add Jiaxun Yang as the MIPS/Loongson-2 maintainer and add Huacai Chen as the MIPS/Loongson-3 maintainer.
--- MAINTAINERS | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)
MAINTAINERS +20 -0
@@ -9141,6 +9141,26 @@ F: arch/mips/include/asm/mach-loongson32/ F: drivers/*/*loongson1* F: drivers/*/*/*loongson1* +MIPS/LOONGSON2 ARCHITECTURE +M: Jiaxun Yang <[email protected]> +L: [email protected] +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 <[email protected]> +L: [email protected] +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 <[email protected]> L: [email protected]
Signature · 1 line
2.7.0
Re: [PATCH 1/1] MAINTAINERS: Add Loongson-2/Loongson-3 maintainers
Quoted 26 lines · 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 <[email protected]>Signed-off-by Jiaxun Yang <[email protected]>--- MAINTAINERS | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+)MAINTAINERS +9
-0@@ -9141,6 +9141,26 @@ F: arch/mips/include/asm/mach-loongson32/ F: drivers/*/*loongson1* F: drivers/*/*/*loongson1* +MIPS/LOONGSON2 ARCHITECTURE +M: Jiaxun Yang <[email protected]> +L: [email protected] +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*
MAINTAINERS F: arch/mips/include/asm/mach-loongson32/ · line 9162
Quoted 10 lines
MAINTAINERS +10
-0+ +MIPS/LOONGSON3 ARCHITECTURE +M: Huacai Chen <[email protected]> +L: [email protected] +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
Quoted 7 lines
MAINTAINERS +1
-0+ MIPS RINT INSTRUCTION EMULATION M: Aleksandar Markovic <[email protected]> L: [email protected]Signature · 1 line
2.7.0
Quoted 6 lines · 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.
Quoted 8 lines
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?
Quoted 5 lines
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
On 2017-12-07 07:57 +0100，Greg Kroah-Hartman wrote：
Quoted 19 lines · Huacai Chen
Quoted 18 lines
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.
Quoted 4 lines
Quoted 2 lines
Now we have a github organization for collaboration:
https://github.com/linux-loongson/linux-loongson.gitIck, 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.
Quoted 11 lines
Quoted 10 lines
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).
Quoted 7 lines
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.
Quoted 4 lines
thanks,
greg k-h
Jiaxun Yang
Quoted 24 lines · Greg Kroah-Hartman
Quoted 6 lines · 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.
Quoted 8 lines
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.gitIck, why not get a kernel.org account for your git tree?
Quoted 5 lines
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).
Quoted 5 lines
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
On 2017-12-07 Thu 11:05 +0000，James Hogan Wrote：
Quoted 43 lines · Greg Kroah-Hartman
Quoted 34 lines · Huacai Chen
Quoted 18 lines
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.Quoted 2 lines
Now we have a github organization for collaboration:
https://github.com/linux-loongson/linux-loongson.gitIck, why not get a kernel.org account for your git tree?
Quoted 9 lines
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).Quoted 7 lines
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?
Quoted 4 lines
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.
Quoted 5 lines
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.
Quoted 9 lines
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.
Quoted 14 lines
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
Signature · 1 line
Jiaxun Yang
Quoted 48 lines · Jiaxun Yang
On 2017-12-07 Thu 11:05 +0000，James Hogan Wrote：
Quoted 43 lines · Greg Kroah-Hartman
Quoted 34 lines · Huacai Chen
Quoted 18 lines
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.Quoted 2 lines
Now we have a github organization for collaboration:
https://github.com/linux-loongson/linux-loongson.gitIck, why not get a kernel.org account for your git tree?
Quoted 9 lines
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).Quoted 7 lines
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?Quoted 4 lines
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.
Quoted 5 lines
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/[email protected]
Cheers
James
Quoted 3 lines
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.
On 2017-12-07 Thu 14:18 +0000，James Hogan Wrote：
Quoted 67 lines · Jiaxun Yang
Quoted 58 lines
On 2017-12-07 Thu 11:05 +0000，James Hogan Wrote：
Quoted 51 lines
Quoted 41 lines · Greg Kroah-Hartman
Quoted 21 lines · 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.Quoted 2 lines
Now we have a github organization for collaboration:
https://github.com/linux-loongson/linux-loongson.gitIck, why not get a kernel.org account for your git tree?
Quoted 11 lines
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?
Quoted 7 lines
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?Quoted 5 lines
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.Quoted 7 lines
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.
Quoted 8 lines
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/[email protected]
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.
Quoted 7 lines
Cheers
JamesQuoted 4 lines
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.
Signature · 1 line
Jiaxun Yang
Quoted 3 lines · Jiaxun Yang
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?
Quoted 5 lines
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:
Quoted 14 lines
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.
Quoted 2 lines
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
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
Quoted 36 lines · James Hogan
Quoted 3 lines · Jiaxun Yang
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?
Quoted 5 lines
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:
Quoted 14 lines
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.Quoted 2 lines
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
On 2017-12-08 Fri 07:51 +0000，James Hogan Wrote：
Quoted 6 lines · Jiaxun Yang
Quoted 3 lines
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.
Quoted 7 lines
Quoted 7 lines
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.
Quoted 28 lines
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:
Quoted 18 lines
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.Quoted 3 lines
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
Signature · 1 line
Jiaxun Yang