On Fri, Nov 6, 2020 at 4:16 PM Russell King - ARM Linux admin
<linux@xxxxxxxxxxxxxxx> wrote:
> On Fri, Nov 06, 2020 at 02:37:21PM +0100, Linus Walleij wrote:
> > Aha. So shall we submit this to Russell? I figure that his git will not
> > build *without* the changes from mmotm?
> >
> > That tree isn't using git either is it?
> >
> > Is this one of those cases where we should ask Stephen R
> > to carry this patch on top of -next until the merge window?
>
> Another solution would be to drop 9017/2 ("Enable KASan for ARM")
> until the following merge window, and queue up the non-conflicing
> ARM KASan fixes in my "misc" branch along with the rest of KASan,
> and the conflicting patches along with 9017/2 in the following
> merge window.
>
> That means delaying KASan enablement another three months or so,
> but should result in less headaches about how to avoid build
> breakage with different bits going through different trees.
>
> Comments?
I suppose I would survive deferring it. Or we could merge the
smaller enablement patch towards the end of the merge
window once the MM changes are in.
If it is just *one* patch in the MM tree I suppose we could also
just apply that one patch also to the ARM tree, and then this
fixup on top. It does look a bit convoluted in the git history with
two hashes and the same patch twice, but it's what I've done
at times when there was no other choice that doing that or
deferring development. It works as long as the patches are
textually identical: git will cope.
If there is a risk that the patch in MM changes this latter
approach is a no-go.
Yours,
Linus Walleij
