[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK7LNATQG4ABWxkShbgTpW78M4FYY_9Fmg2GSxXDTE51yWF=MQ@mail.gmail.com>
Date: Tue, 24 Mar 2020 09:52:17 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: "Jason A. Donenfeld" <Jason@...c4.com>
Cc: X86 ML <x86@...nel.org>, Ingo Molnar <mingo@...nel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Borislav Petkov <bp@...en8.de>,
"H . Peter Anvin" <hpa@...or.com>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Herbert Xu <herbert@...dor.apana.org.au>,
Ingo Molnar <mingo@...hat.com>,
Jim Kukunas <james.t.kukunas@...ux.intel.com>,
NeilBrown <neilb@...e.de>,
Yuanhan Liu <yuanhan.liu@...ux.intel.com>,
clang-built-linux <clang-built-linux@...glegroups.com>
Subject: Re: [PATCH v2 0/9] x86: remove always-defined CONFIG_AS_* options
On Tue, Mar 24, 2020 at 9:29 AM Jason A. Donenfeld <Jason@...c4.com> wrote:
>
> On Mon, Mar 23, 2020 at 6:15 PM Masahiro Yamada <masahiroy@...nel.org> 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
Powered by blists - more mailing lists