On Mon, Mar 23, 2020 at 6:15 PM Masahiro Yamada <[email protected]> wrote:
>
>
> arch/x86/Makefile tests instruction code by $(call as-instr, ...)
>
> Some of them are very old.
> For example, the check for CONFIG_AS_CFI dates back to 2006.
>
> We raise GCC versions from time to time, and we clean old code away.
> The same policy applied to binutils.
>
> The current minimal supported version of binutils is 2.21
>
> This is new enough to recognize the instruction in most of
> as-instr calls.
>
> If this series looks good, how to merge it?
> Via x86 tree or maybe crypto ?
This series looks fine, but why is it still incomplete? That is, it's
missing your drm commit plus the 4 I layered on top for moving to a
Kconfig-based approach and accounting for the bump to binutils 2.23.
Everything is now rebased here:
https://git.zx2c4.com/linux-dev/log/?h=jd/kconfig-assembler-support
Would you be up for resubmitting those all together so we can handle
this in one go?
Jason
On Tue, Mar 24, 2020 at 9:29 AM Jason A. Donenfeld <[email protected]> wrote:
>
> On Mon, Mar 23, 2020 at 6:15 PM Masahiro Yamada <[email protected]> wrote:
> >
> >
> > arch/x86/Makefile tests instruction code by $(call as-instr, ...)
> >
> > Some of them are very old.
> > For example, the check for CONFIG_AS_CFI dates back to 2006.
> >
> > We raise GCC versions from time to time, and we clean old code away.
> > The same policy applied to binutils.
> >
> > The current minimal supported version of binutils is 2.21
> >
> > This is new enough to recognize the instruction in most of
> > as-instr calls.
> >
> > If this series looks good, how to merge it?
> > Via x86 tree or maybe crypto ?
>
> This series looks fine, but why is it still incomplete? That is, it's
> missing your drm commit plus the 4 I layered on top for moving to a
> Kconfig-based approach and accounting for the bump to binutils 2.23.
> Everything is now rebased here:
> https://git.zx2c4.com/linux-dev/log/?h=jd/kconfig-assembler-support
>
> Would you be up for resubmitting those all together so we can handle
> this in one go?
The drm one was independent of the others,
so I just sent it to drm ML separately.
As for your 4, I just thought you would
send a fixed version.
But, folding everything in a series will clarify
the patch dependency.
OK, I will do it.
Who/which ML should I send it to?
--
Best Regards
Masahiro Yamada
On Mon, Mar 23, 2020 at 6:53 PM Masahiro Yamada <[email protected]> wrote:
> The drm one was independent of the others,
> so I just sent it to drm ML separately.
> As for your 4, I just thought you would
> send a fixed version.
> But, folding everything in a series will clarify
> the patch dependency.
> OK, I will do it.
Great, thanks. The ones in that branch now are ready to go, so grab
them out of there.
> Who/which ML should I send it to?
This seems to make sense, IMHO, for x86 or just as a pull to Linus
(i.e. the "kbuild mailing list", in which case, you'd send a pull from
your tree).
Jason