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(-)
--
Krzysztof Halasa
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: [email protected]' 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 <[email protected]> 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: [email protected]' 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.
--
Krzysztof Halasa
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 <[email protected]> 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.