On Sun, Oct 15, 2017 at 10:04:16AM +0200, Geert Uytterhoeven wrote:

On Sat, Oct 14, 2017 at 4:14 PM, Russell King - ARM Linux
[off-list ref] wrote:

quoted

Thanks, it would've been good to have known that ahead of time.

It's why the patch system has the KernelVersion: tag:

 6. Kernel version.
    On a separate line, add a tag "KernelVersion: " followed by the kernel
    version that the patch was generated against. This should be formatted
    as "KernelVersion: 2.6.0-rmk1"

This is because that information is relevant for knowing where it should
be applied, and to which branch.  Having it be something else means I
have to guess, and that can result in the patch being discarded in this
manner if I don't find where it's supposed to be applied.

That's why we have the standard Fixes tag, which was included
Fixes: 9520b1a1b5f7a348 ("ARM: head-common.S: speed up startup code")

Wrong.  You're confusing two different things.

The fixes tag identifies the commit to which the FIX applies.  That's
not what the kernelversion tag described above is for.  That's to
describe where the patch was GENERATED, so that it's easier to know
where it should be applied.

It's trivial for the repo maintainer to know which branch the fix to
apply to, given the Fixes tag.
It's non-trivial to know the branch for the patch submitter, who is
forced to use a non-standard patch submission system.

So what you're telling me is that you're unable to describe what commit
or the kernel version that the patch was GENERATED against.

I /really/ don't buy such an argument one bit.  If you don't have that
information, by definition you can't generate a git patch.

If it was trivial, then don't you think the patch would've been applied
without all this crap?  The proof is here in this thread, it's not as
trivial as you think it is.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up