mbox series

[v2,0/9] x86: remove always-defined CONFIG_AS_* options

Message ID 20200324001358.4520-1-masahiroy@kernel.org (mailing list archive)
Headers show
Series x86: remove always-defined CONFIG_AS_* options | expand

Message

Masahiro Yamada March 24, 2020, 12:13 a.m. UTC
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 ?


Changes in v2:
  - New patch
  - Remove CFI_SIGNAL_FRAME entirely (per Nick)
  - add ifdef CONFIG_X86 to fix build errors on non-x86 arches

Masahiro Yamada (9):
  lib/raid6/test: fix build on distros whose /bin/sh is not bash
  x86: remove unneeded defined(__ASSEMBLY__) check from asm/dwarf2.h
  x86: remove always-defined CONFIG_AS_CFI
  x86: remove unneeded (CONFIG_AS_)CFI_SIGNAL_FRAME
  x86: remove always-defined CONFIG_AS_CFI_SECTIONS
  x86: remove always-defined CONFIG_AS_SSSE3
  x86: remove always-defined CONFIG_AS_AVX
  x86: add comments about the binutils version to support code in
    as-instr
  x86: replace arch macros from compiler with CONFIG_X86_{32,64}

 arch/x86/Makefile                             | 21 +++------
 arch/x86/crypto/Makefile                      | 32 +++++---------
 arch/x86/crypto/aesni-intel_avx-x86_64.S      |  3 --
 arch/x86/crypto/aesni-intel_glue.c            | 14 +-----
 arch/x86/crypto/blake2s-core.S                |  2 -
 arch/x86/crypto/poly1305-x86_64-cryptogams.pl |  8 ----
 arch/x86/crypto/poly1305_glue.c               |  6 +--
 arch/x86/crypto/sha1_ssse3_asm.S              |  4 --
 arch/x86/crypto/sha1_ssse3_glue.c             |  9 +---
 arch/x86/crypto/sha256-avx-asm.S              |  3 --
 arch/x86/crypto/sha256_ssse3_glue.c           |  8 +---
 arch/x86/crypto/sha512-avx-asm.S              |  2 -
 arch/x86/crypto/sha512_ssse3_glue.c           |  7 +--
 arch/x86/include/asm/dwarf2.h                 | 44 -------------------
 arch/x86/include/asm/xor_avx.h                |  9 ----
 kernel/signal.c                               |  2 +-
 lib/raid6/algos.c                             |  6 +--
 lib/raid6/recov_ssse3.c                       |  6 ---
 lib/raid6/test/Makefile                       |  8 ++--
 19 files changed, 33 insertions(+), 161 deletions(-)

Comments

Jason A. Donenfeld March 24, 2020, 12:29 a.m. UTC | #1
On Mon, Mar 23, 2020 at 6:15 PM Masahiro Yamada <masahiroy@kernel.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?

Jason
Masahiro Yamada March 24, 2020, 12:52 a.m. UTC | #2
On Tue, Mar 24, 2020 at 9:29 AM Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> On Mon, Mar 23, 2020 at 6:15 PM Masahiro Yamada <masahiroy@kernel.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
Jason A. Donenfeld March 24, 2020, 1:29 a.m. UTC | #3
On Mon, Mar 23, 2020 at 6:53 PM Masahiro Yamada <masahiroy@kernel.org> 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