| Message ID | m3bog6m5iz.fsf@intrepid.localdomain |
|---|---|
| State | New |
| Headers | show |
On Saturday 13 October 2012, Krzysztof Halasa wrote: > Linus, > > please pull my ARM IXP4xx changes for 3.7: > > The following changes since commit 4d7127dace8cf4b05eb7c8c8531fc204fbb195f4: > > "Merge branch 'for-linus' of git://git.kernel.org/.../jmorris/linux-security" > (2012-10-13 11:29:00 +0900) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux.git next > > for you to fetch changes up to b94740b3b38fd8e37fcd3bb06a18ec2796061c7d: > IXP4xx: use __iomem for MMIO (2012-10-13 20:37:30 +0200) > > Build-tested for now. This is based on your current tree tip because it > depends on commits following 3.6 release. Hi Krzysztof, as mentioned before, all arch/arm/mach-* patches should go through the arm-soc tree or get an Ack from the arm-soc maintainers. The same thing is true for the char-misc and the crypto trees. Also, never rebase your tree immediately before sending a pull request. The preferred way is to have everything based on the -rc release that is the latest one at the time when you do your testing. If you rebase later, you essentially have to test everything again. Finally when sending bug fixes, please annotate any patches with 'Cc: stable@vger.kernel.org' if they address bugs that are already present in older kernels, so that the stable and longterm maintainers can easily backport the fixes. Almost all of the platform patches in your tree seem to be bug fixes, so they are still good for inclusion in v3.7 if you submit them to arm-soc soon, but please make sure you separate bug fixes from other changes so we can group them appropriately when forwarding them to Linus. Thanks, Arnd
Hi, Arnd Bergmann <arnd@arndb.de> writes: > as mentioned before, all arch/arm/mach-* patches should go through the > arm-soc tree or get an Ack from the arm-soc maintainers. The same thing > is true for the char-misc and the crypto trees. You've seen the changes. They were trivial fixes, touched only IXP4xx-related areas, there was nothing related to char or crypto subsystems there, except file location (well, IXP4xx drivers have to be located somewhere). The patches have been posted to linux-arm-kernel and you knew about them. That they were obviously correct and clean is probably not that important. Nobody bothered to comment the patches. > Also, never rebase your tree immediately before sending a pull > request. I did not, of course. My mail stated: "Build-tested for now. This is based on your current tree tip because it depends on commits following 3.6 release." Normally I wouldn't rebase, but had to (as you well knew) - because you commited a conflicting patch to this very IXP4xx arch. Using your logic, you were supposed to get an Ack from me (or from Imre) for this patch. Actually it wasn't a problem for me, I simply had to rebase. > Finally when sending bug fixes, please annotate any patches with > 'Cc: stable@vger.kernel.org' if they address bugs that are already > present in older kernels, so that the stable and longterm maintainers > can easily backport the fixes. I do that when I think it makes sense. In this case (two patches for Goramo MultiLink platform) practically all such devices use kernels prepared by me, and I think Greg (and others) have more efficient ways to spend their time than handling almost unused patches. Also, I have much more efficient ways to spend time. Anyway, if I can't have my patches upstream, why should they end up in stable? > Almost all of the platform patches in your tree seem to be bug fixes, > so they are still good for inclusion in v3.7 if you submit them to > arm-soc soon, but please make sure you separate bug fixes from other > changes so we can group them appropriately when forwarding them to > Linus. Unfortunately, as I already explained to you in https://lkml.org/lkml/2012/9/29/37, my resources for IXP4xx are very limited (and this isn't a paid job) and I'm in no way able to do what you require. This, coupled with my inability to make the patches end up upstream any other way, will make me post relevant MAINTAINERS changes shortly. Don't get me wrong. If I had time for this it could be different. Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at this point. Given the raised barriers to participate, probably aimed at paid maintainers, I have to quit doing this. BTW since Imre has probably even much less time, it would be a good time to find someone to maintain IXP4xx code. I will be publishing (from time to time) my tree (I'm using the hw myself), so even simple cherry-picking would probably make some sense.
On Thu, Oct 18, 2012 at 12:01:17AM +0200, Krzysztof Halasa wrote: ... > Unfortunately, as I already explained to you in > https://lkml.org/lkml/2012/9/29/37, my resources for IXP4xx are very > limited (and this isn't a paid job) and I'm in no way able to do what > you require. This, coupled with my inability to make the patches end > up upstream any other way, will make me post relevant MAINTAINERS > changes shortly. > > Don't get me wrong. If I had time for this it could be different. > Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby > at this point. Given the raised barriers to participate, probably > aimed at paid maintainers, I have to quit doing this. Krzysztof, please reconsider. I'm also a hobbyist maintainer (kirkwood,orion5x,mv78xx0,dove,mvebu). I'd hate to see the community lose a valuable maintainer because arch/arm/ has grown so much. If you would like, I could pull your patches through my tree and send them on to arm-soc. I'm already familiar with arm-soc process, and I'll admit I have a soft spot for mach-ixp4xx. It was my first experience with embedded Linux (nslu2, gateworks boards). This way, you could see the process first hand without having to do the labor. We could do this for a few release cycles so you can see how it goes. After that, we can reassess things. If you still don't wish to lend your experience, so be it. But I hope we can change your mind. thx, Jason.
On Thu, Oct 18, 2012 at 12:01:17AM +0200, Krzysztof Halasa wrote: > > Don't get me wrong. If I had time for this it could be different. > Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at > this point. Given the raised barriers to participate, probably aimed at > paid maintainers, I have to quit doing this. > > BTW since Imre has probably even much less time, it would be a good time > to find someone to maintain IXP4xx code. I will be publishing (from time > to time) my tree (I'm using the hw myself), so even simple > cherry-picking would probably make some sense. So if no one else wants to do this, then I am willing to look after the IXP code. I think that I do have the time for it. Thanks, Richard
On Thu, Oct 18, 2012 at 12:01:17AM +0200, Krzysztof Halasa wrote: > Hi, > > Arnd Bergmann <arnd@arndb.de> writes: > > Also, never rebase your tree immediately before sending a pull > > request. > > I did not, of course. My mail stated: > "Build-tested for now. This is based on your current tree tip because it > depends on commits following 3.6 release." You're lucky that you didn't get flamed by Linus himself for that, as others _have_ been in the past. > Normally I wouldn't rebase, but had to (as you well knew) - because you > commited a conflicting patch to this very IXP4xx arch. Using your logic, > you were supposed to get an Ack from me (or from Imre) for this patch. If you had *bothered* asking the arm-soc people to pull your tree _instead_ of Linus, then that problem becomes the arm-soc's problem, not yours. That means _you_ end up with _less_ work to do. Yet, instead of seeing that benefit, whenever you've been asked to send your tree via arm-soc, you throw your toys out of your pram and basically refuse. So, you're making *more* work for yourself by not participating in arm-soc (as I've explained to you before.) The _ONLY_ thing you have to do is send your pull request to the arm-soc people instead of Linus before the merge window opens. You don't need to rebase your stuff on a different tree, you can still use Linus' tree as a basis. You have offered no technical reason why you can't participate in arm-soc which has stood up to screutiny. The only reasons you've offered seem to be: 1. it'll be more work (untrue) 2. you look after platforms which aren't in mainline and you're not submitting to mainline. Both of these a total nonsense arguments when it comes to the _route_ that your patches make their way into mainline. They have absolutely no bearing on the path your changes take AT ALL. > Don't get me wrong. If I had time for this it could be different. > Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at > this point. Given the raised barriers to participate, probably aimed at > paid maintainers, I have to quit doing this. As you're being difficult and not willing to co-operate, and for whatever reason building this issue into a mountain, this unfortunately sounds to me like a good thing. Hopefully, a more co-operative maintainer will step up in your place who can see the benefits.
On 18/10/12 09:01, Krzysztof Halasa wrote: > Hi, > <snip> > > Unfortunately, as I already explained to you in > https://lkml.org/lkml/2012/9/29/37, my resources for IXP4xx are very > limited (and this isn't a paid job) and I'm in no way able to do what > you require. This, coupled with my inability to make the patches end up > upstream any other way, will make me post relevant MAINTAINERS changes > shortly. > > Don't get me wrong. If I had time for this it could be different. > Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at > this point. Given the raised barriers to participate, probably aimed at > paid maintainers, I have to quit doing this. > > BTW since Imre has probably even much less time, it would be a good time > to find someone to maintain IXP4xx code. I will be publishing (from time > to time) my tree (I'm using the hw myself), so even simple > cherry-picking would probably make some sense. I maintain a tree for the ep93xx, which is another legacy arm soc. I also do this as a hobbyist, not as a paid position. Pushing patches to mainline via arm-soc has been very easy. Basically I branch from Linus's tree (typically 3.x-rc1), apply patches to one of a bunch of branches (-devel, -fixes, etc) and then send pull requests to the arm-soc maintainers prior to the merge window. I also have a aggregate branch which is tested in next. It takes very little of my time to maintain this tree. I cannot see how it could be any harder than sending to Linus directly. Also, the arm-soc maintainers, Arnd and Olof, have been very helpful in getting me started with my maintainer tree, and in learning the development flow. I would also rather get flamed by the arm-soc guys than Linus when I make a mistake :-). ~Ryan
On Monday 29 October 2012, Richard Cochran wrote: > On Thu, Oct 18, 2012 at 12:01:17AM +0200, Krzysztof Halasa wrote: > > > > Don't get me wrong. If I had time for this it could be different. > > Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at > > this point. Given the raised barriers to participate, probably aimed at > > paid maintainers, I have to quit doing this. > > > > BTW since Imre has probably even much less time, it would be a good time > > to find someone to maintain IXP4xx code. I will be publishing (from time > > to time) my tree (I'm using the hw myself), so even simple > > cherry-picking would probably make some sense. > > So if no one else wants to do this, then I am willing to look after > the IXP code. I think that I do have the time for it. Thanks for the offer! Jason Cooper was also volunteering to help out with this, and even we can't convince Krzysztof to continue doing it, there is also Imre who is officially listed as maintainer for IXP4xx and who has not commented on this. As Krzysztof mentions, he probably doesn't have much time for it, but I'd like to give him the chance to comment as well. I'm sure we can find some solution between the four of you. Right now, I think we should focus on getting the bug fixes from Krzysztof's tree into mainline and the stable kernels where applicable, and then establish a better working mode for the future kernels. Arnd
On Tue, Oct 30, 2012 at 10:27:55PM +0000, Arnd Bergmann wrote: > On Monday 29 October 2012, Richard Cochran wrote: > > On Thu, Oct 18, 2012 at 12:01:17AM +0200, Krzysztof Halasa wrote: > > > > > > Don't get me wrong. If I had time for this it could be different. > > > Unfortunately IXP4xx is a legacy arch, and for me it's simply a hobby at > > > this point. Given the raised barriers to participate, probably aimed at > > > paid maintainers, I have to quit doing this. > > > > > > BTW since Imre has probably even much less time, it would be a good time > > > to find someone to maintain IXP4xx code. I will be publishing (from time > > > to time) my tree (I'm using the hw myself), so even simple > > > cherry-picking would probably make some sense. > > > > So if no one else wants to do this, then I am willing to look after > > the IXP code. I think that I do have the time for it. > > Thanks for the offer! Yes, thank you! > Jason Cooper was also volunteering to help out with this, and even we can't > convince Krzysztof to continue doing it, there is also Imre who is officially > listed as maintainer for IXP4xx and who has not commented on this. As Krzysztof > mentions, he probably doesn't have much time for it, but I'd like to give > him the chance to comment as well. Agreed. > I'm sure we can find some solution between the four of you. Right now, I think > we should focus on getting the bug fixes from Krzysztof's tree into mainline > and the stable kernels where applicable, and then establish a better working > mode for the future kernels. We also need to keep an eye on the big picture. If we are going to keep/maintain ixp4xx in the kernel, there are some things which need to be done. The drivers need moved to drivers/, platform headers need moved to platform_data/, and we may as well add devicetree bindings while we're moving things around. Making ixp4xx compatible with multiplatform zImage would probably help out the embedded distros as well. thx, Jason.
Linus, please pull my ARM IXP4xx changes for 3.7: The following changes since commit 4d7127dace8cf4b05eb7c8c8531fc204fbb195f4: "Merge branch 'for-linus' of git://git.kernel.org/.../jmorris/linux-security" (2012-10-13 11:29:00 +0900) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/chris/linux.git next for you to fetch changes up to b94740b3b38fd8e37fcd3bb06a18ec2796061c7d: IXP4xx: use __iomem for MMIO (2012-10-13 20:37:30 +0200) Build-tested for now. This is based on your current tree tip because it depends on commits following 3.6 release. Thanks. ---------------------------------------------------------------- Arnd Bergmann (1): IXP4xx: use __iomem for MMIO Krzysztof Hałasa (9): IXP4xx: Fix Goramo MultiLink platform compilation. IXP4xx: Fix off-by-one bug in Goramo MultiLink platform. IXP4xx: HW pseudo-random generator is available on IXP45x/46x only. IXP4xx: ixp4xx_crypto driver requires Queue Manager and NPE drivers. IXP4xx: Remove time limit for PCI TRDY to enable use of slow devices. WAN: Remove redundant HDLC info printed by IXP4xx HSS driver. IXP4xx crypto: MOD_AES{128,192,256} already include key size. IXP4xx: Always ioremap() Queue Manager MMIO region at boot. IXP4xx: map CPU config registers within VMALLOC region. Tim Gardner (1): ixp4xx: Declare MODULE_FIRMWARE usage arch/arm/mach-ixp4xx/common-pci.c | 1 + arch/arm/mach-ixp4xx/common.c | 13 +++++-------- arch/arm/mach-ixp4xx/goramo_mlr.c | 3 ++- arch/arm/mach-ixp4xx/include/mach/debug-macro.S | 4 ++-- arch/arm/mach-ixp4xx/include/mach/ixp4xx-regs.h | 46 +++++++++++++++++++-------------------------- arch/arm/mach-ixp4xx/include/mach/qmgr.h | 12 ++++++------ arch/arm/mach-ixp4xx/ixp4xx_npe.c | 9 ++++++++- arch/arm/mach-ixp4xx/ixp4xx_qmgr.c | 12 +----------- drivers/char/hw_random/Kconfig | 6 +++--- drivers/char/hw_random/ixp4xx-rng.c | 5 ++++- drivers/crypto/Kconfig | 2 +- drivers/crypto/ixp4xx_crypto.c | 12 ++++++------ drivers/net/wan/ixp4xx_hss.c | 2 +- 13 files changed, 59 insertions(+), 68 deletions(-)