<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/mips/Makefile, branch v4.20</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>kbuild: replace cc-name test with CONFIG_CC_IS_CLANG</title>
<updated>2018-11-02T13:49:00+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2018-10-30T13:26:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=076f421da5d4594d0a3e60c032ccf02ba55e868a'/>
<id>076f421da5d4594d0a3e60c032ccf02ba55e868a</id>
<content type='text'>
Evaluating cc-name invokes the compiler every time even when you are
not compiling anything, like 'make help'. This is not efficient.

The compiler type has been already detected in the Kconfig stage.
Use CONFIG_CC_IS_CLANG, instead.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Acked-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt; (powerpc)
Acked-by: Paul Burton &lt;paul.burton@mips.com&gt; (MIPS)
Acked-by: Joel Stanley &lt;joel@jms.id.au&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Evaluating cc-name invokes the compiler every time even when you are
not compiling anything, like 'make help'. This is not efficient.

The compiler type has been already detected in the Kconfig stage.
Use CONFIG_CC_IS_CLANG, instead.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Acked-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt; (powerpc)
Acked-by: Paul Burton &lt;paul.burton@mips.com&gt; (MIPS)
Acked-by: Joel Stanley &lt;joel@jms.id.au&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge tag 'mips_4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux</title>
<updated>2018-10-26T21:43:48+00:00</updated>
<author>
<name>Linus Torvalds</name>
<email>torvalds@linux-foundation.org</email>
</author>
<published>2018-10-26T21:43:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=cc10ad25bbca3d2925adc32d51cb7a10b837d32c'/>
<id>cc10ad25bbca3d2925adc32d51cb7a10b837d32c</id>
<content type='text'>
Pull MIPS updates from Paul Burton:

 - kexec support for the generic MIPS platform when running on a CPU
   including the MIPS Coherence Manager &amp; related hardware.

 - Improvements to the definition of memory barriers used around MMIO
   accesses, and fixes in their use.

 - Switch to CONFIG_NO_BOOTMEM from Mike Rapoport, finally dropping
   reliance on the old bootmem code.

 - A number of fixes &amp; improvements for Loongson 3 systems.

 - DT &amp; config updates for the Microsemi Ocelot platform.

 - Workaround to enable USB power on the Netgear WNDR3400v3.

 - Various cleanups &amp; fixes.

* tag 'mips_4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: (51 commits)
  MIPS: Cleanup DSP ASE detection
  MIPS: dts: Change upper case to lower case
  MIPS: generic: Add Network, SPI and I2C to ocelot_defconfig
  MIPS: Loongson-3: Fix BRIDGE irq delivery problem
  MIPS: Loongson-3: Fix CPU UART irq delivery problem
  MIPS: Remove unused PREF, PREFE &amp; PREFX macros
  MIPS: lib: Use kernel_pref &amp; user_pref in memcpy()
  MIPS: Remove unused CAT macro
  MIPS: Add kernel_pref &amp; user_pref helpers
  MIPS: Remove unused TTABLE macro
  MIPS: Remove unused PIC macros
  MIPS: Remove unused MOVN &amp; MOVZ macros
  MIPS: Provide actually relaxed MMIO accessors
  MIPS: Enforce strong ordering for MMIO accessors
  MIPS: Correct `mmiowb' barrier for `wbflush' platforms
  MIPS: Define MMIO ordering barriers
  MIPS: mscc: add PCB120 to the ocelot fitImage
  MIPS: mscc: add DT for Ocelot PCB120
  MIPS: memset: Limit excessive `noreorder' assembly mode use
  MIPS: memset: Fix CPU_DADDI_WORKAROUNDS `small_fixup' regression
  ...
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Pull MIPS updates from Paul Burton:

 - kexec support for the generic MIPS platform when running on a CPU
   including the MIPS Coherence Manager &amp; related hardware.

 - Improvements to the definition of memory barriers used around MMIO
   accesses, and fixes in their use.

 - Switch to CONFIG_NO_BOOTMEM from Mike Rapoport, finally dropping
   reliance on the old bootmem code.

 - A number of fixes &amp; improvements for Loongson 3 systems.

 - DT &amp; config updates for the Microsemi Ocelot platform.

 - Workaround to enable USB power on the Netgear WNDR3400v3.

 - Various cleanups &amp; fixes.

* tag 'mips_4.20' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: (51 commits)
  MIPS: Cleanup DSP ASE detection
  MIPS: dts: Change upper case to lower case
  MIPS: generic: Add Network, SPI and I2C to ocelot_defconfig
  MIPS: Loongson-3: Fix BRIDGE irq delivery problem
  MIPS: Loongson-3: Fix CPU UART irq delivery problem
  MIPS: Remove unused PREF, PREFE &amp; PREFX macros
  MIPS: lib: Use kernel_pref &amp; user_pref in memcpy()
  MIPS: Remove unused CAT macro
  MIPS: Add kernel_pref &amp; user_pref helpers
  MIPS: Remove unused TTABLE macro
  MIPS: Remove unused PIC macros
  MIPS: Remove unused MOVN &amp; MOVZ macros
  MIPS: Provide actually relaxed MMIO accessors
  MIPS: Enforce strong ordering for MMIO accessors
  MIPS: Correct `mmiowb' barrier for `wbflush' platforms
  MIPS: Define MMIO ordering barriers
  MIPS: mscc: add PCB120 to the ocelot fitImage
  MIPS: mscc: add DT for Ocelot PCB120
  MIPS: memset: Limit excessive `noreorder' assembly mode use
  MIPS: memset: Fix CPU_DADDI_WORKAROUNDS `small_fixup' regression
  ...
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Cleanup DSP ASE detection</title>
<updated>2018-10-16T22:30:21+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2018-10-15T18:26:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=edbb4233e7efc37dbebb10f7774b38c64080dd66'/>
<id>edbb4233e7efc37dbebb10f7774b38c64080dd66</id>
<content type='text'>
Currently we hardcode a list of files for which we specify that the
toolchain has DSP ASE support when building for MIPSr2 only. This has a
number of problems:

  1) It doesn't actually ensure that the toolchain supports the DSP ASE
     at all.

  2) It's fragile if we try to use DSP ASE macros in other files.

  3) It makes no provision for MIPSr6 &amp; later systems which also support
     the DSP ASE &amp; end up using the .word directive implementation of
     the DSP macros.

Fix this by detecting assembler support for the DSP ASE globally, not
just for a small set of files, and not just for MIPSr2. This now exposes
use of toolchain DSP support to kernel builds targeting MIPSr1 and
older, so we add .set MIPS_ISA_LEVEL directives prior to all .set dsp
directives in order to prevent the assembler from complaining that the
DSP ASE is only supported with MIPSr2 &amp; higher.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/20901/
Cc: linux-mips@linux-mips.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently we hardcode a list of files for which we specify that the
toolchain has DSP ASE support when building for MIPSr2 only. This has a
number of problems:

  1) It doesn't actually ensure that the toolchain supports the DSP ASE
     at all.

  2) It's fragile if we try to use DSP ASE macros in other files.

  3) It makes no provision for MIPSr6 &amp; later systems which also support
     the DSP ASE &amp; end up using the .word directive implementation of
     the DSP macros.

Fix this by detecting assembler support for the DSP ASE globally, not
just for a small set of files, and not just for MIPSr2. This now exposes
use of toolchain DSP support to kernel builds targeting MIPSr1 and
older, so we add .set MIPS_ISA_LEVEL directives prior to all .set dsp
directives in order to prevent the assembler from complaining that the
DSP ASE is only supported with MIPSr2 &amp; higher.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/20901/
Cc: linux-mips@linux-mips.org
</pre>
</div>
</content>
</entry>
<entry>
<title>kbuild: consolidate Devicetree dtb build rules</title>
<updated>2018-10-02T14:23:21+00:00</updated>
<author>
<name>Rob Herring</name>
<email>robh@kernel.org</email>
</author>
<published>2018-01-10T21:19:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=37c8a5fafa3bb7dcdd51774be353be6cb2912b86'/>
<id>37c8a5fafa3bb7dcdd51774be353be6cb2912b86</id>
<content type='text'>
There is nothing arch specific about building dtb files other than their
location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
The dependencies and supported targets are all slightly different.
Also, a cross-compiler for each arch is needed, but really the host
compiler preprocessor is perfectly fine for building dtbs. Move the
build rules to a common location and remove the arch specific ones. This
is done in a single step to avoid warnings about overriding rules.

The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
These pull in several dependencies some of which need a target compiler
(specifically devicetable-offsets.h) and aren't needed to build dtbs.
All that is really needed is dtc, so adjust the dependencies to only be
dtc.

This change enables support 'dtbs_install' on some arches which were
missing the target.

Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Acked-by: Paul Burton &lt;paul.burton@mips.com&gt;
Acked-by: Ley Foon Tan &lt;ley.foon.tan@intel.com&gt;
Acked-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Cc: Michal Marek &lt;michal.lkml@markovi.net&gt;
Cc: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Cc: Michal Simek &lt;monstr@monstr.eu&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Chris Zankel &lt;chris@zankel.net&gt;
Cc: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Cc: linux-kbuild@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: uclinux-h8-devel@lists.sourceforge.jp
Cc: linux-mips@linux-mips.org
Cc: nios2-dev@lists.rocketboards.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-xtensa@linux-xtensa.org
Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There is nothing arch specific about building dtb files other than their
location under /arch/*/boot/dts/. Keeping each arch aligned is a pain.
The dependencies and supported targets are all slightly different.
Also, a cross-compiler for each arch is needed, but really the host
compiler preprocessor is perfectly fine for building dtbs. Move the
build rules to a common location and remove the arch specific ones. This
is done in a single step to avoid warnings about overriding rules.

The build dependencies had been a mixture of 'scripts' and/or 'prepare'.
These pull in several dependencies some of which need a target compiler
(specifically devicetable-offsets.h) and aren't needed to build dtbs.
All that is really needed is dtc, so adjust the dependencies to only be
dtc.

This change enables support 'dtbs_install' on some arches which were
missing the target.

Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Acked-by: Paul Burton &lt;paul.burton@mips.com&gt;
Acked-by: Ley Foon Tan &lt;ley.foon.tan@intel.com&gt;
Acked-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Cc: Michal Marek &lt;michal.lkml@markovi.net&gt;
Cc: Vineet Gupta &lt;vgupta@synopsys.com&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Cc: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Cc: Yoshinori Sato &lt;ysato@users.sourceforge.jp&gt;
Cc: Michal Simek &lt;monstr@monstr.eu&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Benjamin Herrenschmidt &lt;benh@kernel.crashing.org&gt;
Cc: Paul Mackerras &lt;paulus@samba.org&gt;
Cc: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Cc: Chris Zankel &lt;chris@zankel.net&gt;
Cc: Max Filippov &lt;jcmvbkbc@gmail.com&gt;
Cc: linux-kbuild@vger.kernel.org
Cc: linux-snps-arc@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: uclinux-h8-devel@lists.sourceforge.jp
Cc: linux-mips@linux-mips.org
Cc: nios2-dev@lists.rocketboards.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: linux-xtensa@linux-xtensa.org
Signed-off-by: Rob Herring &lt;robh@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Use a custom elf-entry program to find kernel entry point</title>
<updated>2018-08-30T16:39:22+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2018-08-29T18:01:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e245767abf2797f1581f94e48db7f6184e14ebed'/>
<id>e245767abf2797f1581f94e48db7f6184e14ebed</id>
<content type='text'>
For a long time arch/mips/Makefile used nm to discover the kernel entry
point by looking for the address of the kernel_entry symbol. This
doesn't work for systems which make use of bit 0 of the PC to reflect
the ISA mode - ie. microMIPS (and MIPS16, but we don't support building
kernels that target MIPS16 anyway).

So for a while with commit 5fc9484f5e41 ("MIPS: Set ISA bit in entry-y
for microMIPS kernels") we manually modified the last nibble of the
output from nm, which worked but wasn't particularly pretty.

Commit 27c524d17430 ("MIPS: Use the entry point from the ELF file
header") then cleaned this up by using objdump to print the ELF entry
point which includes the ISA bit, rather than using nm to print the
address of the kernel_entry symbol which doesn't. That removed the ugly
replacement of the last nibble, but added its own ugliness by needing to
manually sign extend in the 32 bit case.

Unfortunately it has been pointed out that objdump's output is
localised, and therefore grepping for its "start address" output doesn't
work when the user's language settings are such that objdump doesn't
print in English.

We could simply revert commit 27c524d17430 ("MIPS: Use the entry point
from the ELF file header") and return to the manual replacement of the
last nibble of entry-y, but it seems that was found sufficiently
unpalatable to avoid. We could attempt to force the language used by
objdump by setting an environment variable such as LC_ALL, but that
seems fragile. Instead we add a small tool named elf-entry which simply
prints out the entry point of the kernel in the format we require.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Reported-by: Philippe Reynes &lt;philippe.reynes@softathome.com&gt;
Tested-by: Philippe Reynes &lt;philippe.reynes@softathome.com&gt;
Fixes: 27c524d17430 ("MIPS: Use the entry point from the ELF file header")
Patchwork: https://patchwork.linux-mips.org/patch/20322/
Cc: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
For a long time arch/mips/Makefile used nm to discover the kernel entry
point by looking for the address of the kernel_entry symbol. This
doesn't work for systems which make use of bit 0 of the PC to reflect
the ISA mode - ie. microMIPS (and MIPS16, but we don't support building
kernels that target MIPS16 anyway).

So for a while with commit 5fc9484f5e41 ("MIPS: Set ISA bit in entry-y
for microMIPS kernels") we manually modified the last nibble of the
output from nm, which worked but wasn't particularly pretty.

Commit 27c524d17430 ("MIPS: Use the entry point from the ELF file
header") then cleaned this up by using objdump to print the ELF entry
point which includes the ISA bit, rather than using nm to print the
address of the kernel_entry symbol which doesn't. That removed the ugly
replacement of the last nibble, but added its own ugliness by needing to
manually sign extend in the 32 bit case.

Unfortunately it has been pointed out that objdump's output is
localised, and therefore grepping for its "start address" output doesn't
work when the user's language settings are such that objdump doesn't
print in English.

We could simply revert commit 27c524d17430 ("MIPS: Use the entry point
from the ELF file header") and return to the manual replacement of the
last nibble of entry-y, but it seems that was found sufficiently
unpalatable to avoid. We could attempt to force the language used by
objdump by setting an environment variable such as LC_ALL, but that
seems fragile. Instead we add a small tool named elf-entry which simply
prints out the entry point of the kernel in the format we require.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Reported-by: Philippe Reynes &lt;philippe.reynes@softathome.com&gt;
Tested-by: Philippe Reynes &lt;philippe.reynes@softathome.com&gt;
Fixes: 27c524d17430 ("MIPS: Use the entry point from the ELF file header")
Patchwork: https://patchwork.linux-mips.org/patch/20322/
Cc: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
</pre>
</div>
</content>
</entry>
<entry>
<title>kbuild: rename LDFLAGS to KBUILD_LDFLAGS</title>
<updated>2018-08-23T23:22:08+00:00</updated>
<author>
<name>Masahiro Yamada</name>
<email>yamada.masahiro@socionext.com</email>
</author>
<published>2018-08-23T23:20:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d503ac531a5246e4d910f971b213807fea925956'/>
<id>d503ac531a5246e4d910f971b213807fea925956</id>
<content type='text'>
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add
additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.

Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add
additional options to AS") renamed AFLAGS to KBUILD_AFLAGS.

Commit 06c5040cdb13 ("kbuild: enable 'make CPPFLAGS=...' to add
additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS.

For some reason, LDFLAGS was not renamed.

Using a well-known variable like LDFLAGS may result in accidental
override of the variable.

Kbuild generally uses KBUILD_ prefixed variables for the internally
appended options, so here is one more conversion to sanitize the
naming convention.

I did not touch Makefiles under tools/ since the tools build system
is a different world.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Acked-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Reviewed-by: Palmer Dabbelt &lt;palmer@sifive.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add
additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.

Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add
additional options to AS") renamed AFLAGS to KBUILD_AFLAGS.

Commit 06c5040cdb13 ("kbuild: enable 'make CPPFLAGS=...' to add
additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS.

For some reason, LDFLAGS was not renamed.

Using a well-known variable like LDFLAGS may result in accidental
override of the variable.

Kbuild generally uses KBUILD_ prefixed variables for the internally
appended options, so here is one more conversion to sanitize the
naming convention.

I did not touch Makefiles under tools/ since the tools build system
is a different world.

Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
Acked-by: Kirill A. Shutemov &lt;kirill.shutemov@linux.intel.com&gt;
Reviewed-by: Palmer Dabbelt &lt;palmer@sifive.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Always specify -EB or -EL when using clang</title>
<updated>2018-08-07T23:16:08+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2018-08-07T23:06:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=c6d6f4c55f5cda5a7fa5a08eede0eb289937c328'/>
<id>c6d6f4c55f5cda5a7fa5a08eede0eb289937c328</id>
<content type='text'>
When building using clang, always specify -EB or -EL in order to ensure
we target the desired endianness.

Since clang cross compiles using a single compiler build with multiple
targets, our -dumpmachine tests which don't specify clang's --target
argument check output based upon the build machine rather than the
machine our build will target. This means our detection of whether to
specify -EB fails miserably &amp; we never do. Providing the endianness flag
unconditionally for clang resolves this issue &amp; simplifies the clang
path somewhat.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When building using clang, always specify -EB or -EL in order to ensure
we target the desired endianness.

Since clang cross compiles using a single compiler build with multiple
targets, our -dumpmachine tests which don't specify clang's --target
argument check output based upon the build machine rather than the
machine our build will target. This means our detection of whether to
specify -EB fails miserably &amp; we never do. Providing the endianness flag
unconditionally for clang resolves this issue &amp; simplifies the clang
path somewhat.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Always use -march=&lt;arch&gt;, not -&lt;arch&gt; shortcuts</title>
<updated>2018-06-28T21:24:30+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@mips.com</email>
</author>
<published>2018-06-19T00:37:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=344ebf09949c31bcb8818d8458b65add29f1d67b'/>
<id>344ebf09949c31bcb8818d8458b65add29f1d67b</id>
<content type='text'>
The VDSO Makefile filters CFLAGS to select a subset which it uses whilst
building the VDSO ELF. One of the flags it allows through is the -march=
flag that selects the architecture/ISA to target.

Unfortunately in cases where CONFIG_CPU_MIPS32_R{1,2}=y and the
toolchain defaults to building for MIPS64, the main MIPS Makefile ends
up using the short-form -&lt;arch&gt; flags in cflags-y. This is because the
calls to cc-option always fail to use the long-form -march=&lt;arch&gt; flag
due to the lack of an -mabi=&lt;abi&gt; flag in KBUILD_CFLAGS at the point
where the cc-option function is executed. The resulting GCC invocation
is something like:

  $ mips64-linux-gcc -Werror -march=mips32r2 -c -x c /dev/null -o tmp
  cc1: error: '-march=mips32r2' is not compatible with the selected ABI

These short-form -&lt;arch&gt; flags are dropped by the VDSO Makefile's
filtering, and so we attempt to build the VDSO without specifying any
architecture. This results in an attempt to build the VDSO using
whatever the compiler's default architecture is, regardless of whether
that is suitable for the kernel configuration.

One encountered build failure resulting from this mismatch is a
rejection of the sync instruction if the kernel is configured for a
MIPS32 or MIPS64 r1 or r2 target but the toolchain defaults to an older
architecture revision such as MIPS1 which did not include the sync
instruction:

    CC      arch/mips/vdso/gettimeofday.o
  /tmp/ccGQKoOj.s: Assembler messages:
  /tmp/ccGQKoOj.s:273: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:329: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:520: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:714: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1009: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1066: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1114: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1279: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1334: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1374: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1459: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1514: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1814: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:2002: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:2066: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  make[2]: *** [scripts/Makefile.build:318: arch/mips/vdso/gettimeofday.o] Error 1
  make[1]: *** [scripts/Makefile.build:558: arch/mips/vdso] Error 2
  make[1]: *** Waiting for unfinished jobs....

This can be reproduced for example by attempting to build
pistachio_defconfig using Arnd's GCC 8.1.0 mips64 toolchain from
kernel.org:

  https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-mips64-linux.tar.xz

Resolve this problem by using the long-form -march=&lt;arch&gt; in all cases,
which makes it through the arch/mips/vdso/Makefile's filtering &amp; is thus
consistently used to build both the kernel proper &amp; the VDSO.

The use of cc-option to prefer the long-form &amp; fall back to the
short-form flags makes no sense since the short-form is just an
abbreviation for the also-supported long-form in all GCC versions that
we support building with. This means there is no case in which we have
to use the short-form -&lt;arch&gt; flags, so we can simply remove them.

The manual redefinition of _MIPS_ISA is removed naturally along with the
use of the short-form flags that it accompanied, and whilst here we
remove the separate assembler ISA selection. I suspect that both of
these were only required due to the mips32 vs mips2 mismatch that was
introduced by commit 59b3e8e9aac6 ("[MIPS] Makefile crapectomy.") and
fixed but not cleaned up by commit 9200c0b2a07c ("[MIPS] Fix Makefile
bugs for MIPS32/MIPS64 R1 and R2.").

I've marked this for backport as far as v4.4 where the MIPS VDSO was
introduced. In earlier kernels there should be no ill effect to using
the short-form flags.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.4+
Reviewed-by: James Hogan &lt;jhogan@kernel.org&gt;
Patchwork: https://patchwork.linux-mips.org/patch/19579/
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The VDSO Makefile filters CFLAGS to select a subset which it uses whilst
building the VDSO ELF. One of the flags it allows through is the -march=
flag that selects the architecture/ISA to target.

Unfortunately in cases where CONFIG_CPU_MIPS32_R{1,2}=y and the
toolchain defaults to building for MIPS64, the main MIPS Makefile ends
up using the short-form -&lt;arch&gt; flags in cflags-y. This is because the
calls to cc-option always fail to use the long-form -march=&lt;arch&gt; flag
due to the lack of an -mabi=&lt;abi&gt; flag in KBUILD_CFLAGS at the point
where the cc-option function is executed. The resulting GCC invocation
is something like:

  $ mips64-linux-gcc -Werror -march=mips32r2 -c -x c /dev/null -o tmp
  cc1: error: '-march=mips32r2' is not compatible with the selected ABI

These short-form -&lt;arch&gt; flags are dropped by the VDSO Makefile's
filtering, and so we attempt to build the VDSO without specifying any
architecture. This results in an attempt to build the VDSO using
whatever the compiler's default architecture is, regardless of whether
that is suitable for the kernel configuration.

One encountered build failure resulting from this mismatch is a
rejection of the sync instruction if the kernel is configured for a
MIPS32 or MIPS64 r1 or r2 target but the toolchain defaults to an older
architecture revision such as MIPS1 which did not include the sync
instruction:

    CC      arch/mips/vdso/gettimeofday.o
  /tmp/ccGQKoOj.s: Assembler messages:
  /tmp/ccGQKoOj.s:273: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:329: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:520: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:714: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1009: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1066: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1114: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1279: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1334: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1374: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1459: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1514: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:1814: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:2002: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  /tmp/ccGQKoOj.s:2066: Error: opcode not supported on this processor: mips1 (mips1) `sync'
  make[2]: *** [scripts/Makefile.build:318: arch/mips/vdso/gettimeofday.o] Error 1
  make[1]: *** [scripts/Makefile.build:558: arch/mips/vdso] Error 2
  make[1]: *** Waiting for unfinished jobs....

This can be reproduced for example by attempting to build
pistachio_defconfig using Arnd's GCC 8.1.0 mips64 toolchain from
kernel.org:

  https://mirrors.edge.kernel.org/pub/tools/crosstool/files/bin/x86_64/8.1.0/x86_64-gcc-8.1.0-nolibc-mips64-linux.tar.xz

Resolve this problem by using the long-form -march=&lt;arch&gt; in all cases,
which makes it through the arch/mips/vdso/Makefile's filtering &amp; is thus
consistently used to build both the kernel proper &amp; the VDSO.

The use of cc-option to prefer the long-form &amp; fall back to the
short-form flags makes no sense since the short-form is just an
abbreviation for the also-supported long-form in all GCC versions that
we support building with. This means there is no case in which we have
to use the short-form -&lt;arch&gt; flags, so we can simply remove them.

The manual redefinition of _MIPS_ISA is removed naturally along with the
use of the short-form flags that it accompanied, and whilst here we
remove the separate assembler ISA selection. I suspect that both of
these were only required due to the mips32 vs mips2 mismatch that was
introduced by commit 59b3e8e9aac6 ("[MIPS] Makefile crapectomy.") and
fixed but not cleaned up by commit 9200c0b2a07c ("[MIPS] Fix Makefile
bugs for MIPS32/MIPS64 R1 and R2.").

I've marked this for backport as far as v4.4 where the MIPS VDSO was
introduced. In earlier kernels there should be no ill effect to using
the short-form flags.

Signed-off-by: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org # v4.4+
Reviewed-by: James Hogan &lt;jhogan@kernel.org&gt;
Patchwork: https://patchwork.linux-mips.org/patch/19579/
</pre>
</div>
</content>
</entry>
<entry>
<title>kbuild: add machine size to CHECKFLAGS</title>
<updated>2018-06-01T02:36:58+00:00</updated>
<author>
<name>Luc Van Oostenryck</name>
<email>luc.vanoostenryck@gmail.com</email>
</author>
<published>2018-05-30T20:48:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1f2f01b122d7c78a9e842a126ef168afb279552b'/>
<id>1f2f01b122d7c78a9e842a126ef168afb279552b</id>
<content type='text'>
By default, sparse assumes a 64bit machine when compiled on x86-64
and 32bit when compiled on anything else.

This can of course create all sort of problems for the other archs, like
issuing false warnings ('shift too big (32) for type unsigned long'), or
worse, failing to emit legitimate warnings.

Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT,
to CHECKFLAGS in the main Makefile (and so for all archs).
Also, remove the now unneeded -m32/-m64 in arch specific Makefiles.

Signed-off-by: Luc Van Oostenryck &lt;luc.vanoostenryck@gmail.com&gt;
Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
By default, sparse assumes a 64bit machine when compiled on x86-64
and 32bit when compiled on anything else.

This can of course create all sort of problems for the other archs, like
issuing false warnings ('shift too big (32) for type unsigned long'), or
worse, failing to emit legitimate warnings.

Fix this by adding the -m32/-m64 flag, depending on CONFIG_64BIT,
to CHECKFLAGS in the main Makefile (and so for all archs).
Also, remove the now unneeded -m32/-m64 in arch specific Makefiles.

Signed-off-by: Luc Van Oostenryck &lt;luc.vanoostenryck@gmail.com&gt;
Signed-off-by: Masahiro Yamada &lt;yamada.masahiro@socionext.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Use the entry point from the ELF file header</title>
<updated>2018-03-22T22:30:58+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@mips.com</email>
</author>
<published>2018-03-22T16:30:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=27c524d1743047258f9a6a2ad813f54d35c1f8e8'/>
<id>27c524d1743047258f9a6a2ad813f54d35c1f8e8</id>
<content type='text'>
In order to fetch the correct entry point with the ISA bit included, for
use by non-ELF boot loaders, parse the output of `objdump -f' for the
start address recorded in the kernel executable itself, rather than
using `nm' to get the value of the `kernel_entry' symbol.

Sign-extend the address retrieved if 32-bit, so that execution is
correctly started on 64-bit processors as well.  The tool always prints
the entry point using either 8 or 16 hexadecimal digits, matching the
address width (aka class) of the ELF file, even in the presence of
leading zeros.

Signed-off-by: Maciej W. Rozycki &lt;macro@mips.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/18912/
Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In order to fetch the correct entry point with the ISA bit included, for
use by non-ELF boot loaders, parse the output of `objdump -f' for the
start address recorded in the kernel executable itself, rather than
using `nm' to get the value of the `kernel_entry' symbol.

Sign-extend the address retrieved if 32-bit, so that execution is
correctly started on 64-bit processors as well.  The tool always prints
the entry point using either 8 or 16 hexadecimal digits, matching the
address width (aka class) of the ELF file, even in the presence of
leading zeros.

Signed-off-by: Maciej W. Rozycki &lt;macro@mips.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/18912/
Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
