<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/mips/Makefile, branch v4.19</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<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>
<entry>
<title>MIPS: generic: Add support for Microsemi Ocelot</title>
<updated>2018-03-21T23:33:10+00:00</updated>
<author>
<name>Alexandre Belloni</name>
<email>alexandre.belloni@bootlin.com</email>
</author>
<published>2018-03-20T13:08:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6bce3deae4d51326d0f07619ab6443ba771b3fb6'/>
<id>6bce3deae4d51326d0f07619ab6443ba771b3fb6</id>
<content type='text'>
Introduce support for the MIPS based Microsemi Ocelot SoCs.

Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Allan Nielsen &lt;Allan.Nielsen@microsemi.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/18858/
[jhogan@kernel.org: update ocelot_defconfig specification]
Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Introduce support for the MIPS based Microsemi Ocelot SoCs.

Signed-off-by: Alexandre Belloni &lt;alexandre.belloni@bootlin.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Allan Nielsen &lt;Allan.Nielsen@microsemi.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/18858/
[jhogan@kernel.org: update ocelot_defconfig specification]
Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Expand help text to list generic defconfigs</title>
<updated>2018-03-05T15:11:42+00:00</updated>
<author>
<name>James Hogan</name>
<email>jhogan@kernel.org</email>
</author>
<published>2018-02-09T16:11:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=cccd0b9a72d27f681c2e45da0c263a46e5c63926'/>
<id>cccd0b9a72d27f681c2e45da0c263a46e5c63926</id>
<content type='text'>
Expand the MIPS Makefile help text to list generic board names, generic
defconfigs, and legacy defconfigs which have been converted to generic
and are still usable.

Here's a snippet of the new "make ARCH=mips help" output:
  ...
  If you are targeting a system supported by generic kernels you may
  configure the kernel for a given architecture target like so:

  {micro32,32,64}{r1,r2,r6}{el,}_defconfig &lt;BOARDS="list of boards"&gt;

  Where BOARDS is some subset of the following:
    boston
    ni169445
    ranchu
    sead-3
    xilfpga

  Specifically the following generic default configurations are
  supported:

  32r1_defconfig           - Build generic kernel for MIPS32 r1
  32r1el_defconfig         - Build generic kernel for MIPS32 r1 little endian
  32r2_defconfig           - Build generic kernel for MIPS32 r2
  32r2el_defconfig         - Build generic kernel for MIPS32 r2 little endian
  32r6_defconfig           - Build generic kernel for MIPS32 r6
  32r6el_defconfig         - Build generic kernel for MIPS32 r6 little endian
  64r1_defconfig           - Build generic kernel for MIPS64 r1
  64r1el_defconfig         - Build generic kernel for MIPS64 r1 little endian
  64r2_defconfig           - Build generic kernel for MIPS64 r2
  64r2el_defconfig         - Build generic kernel for MIPS64 r2 little endian
  64r6_defconfig           - Build generic kernel for MIPS64 r6
  64r6el_defconfig         - Build generic kernel for MIPS64 r6 little endian
  micro32r2_defconfig      - Build generic kernel for microMIPS32 r2
  micro32r2el_defconfig    - Build generic kernel for microMIPS32 r2 little endian

  The following legacy default configurations have been converted to
  generic and can still be used:

  sead3_defconfig          - Build 32r2el_defconfig BOARDS=sead-3
  sead3micro_defconfig     - Build micro32r2el_defconfig BOARDS=sead-3
  xilfpga_defconfig        - Build 32r2el_defconfig BOARDS=xilfpga
  ...

Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Matt Redfearn &lt;matt.redfearn@mips.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kbuild@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/18598/
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Expand the MIPS Makefile help text to list generic board names, generic
defconfigs, and legacy defconfigs which have been converted to generic
and are still usable.

Here's a snippet of the new "make ARCH=mips help" output:
  ...
  If you are targeting a system supported by generic kernels you may
  configure the kernel for a given architecture target like so:

  {micro32,32,64}{r1,r2,r6}{el,}_defconfig &lt;BOARDS="list of boards"&gt;

  Where BOARDS is some subset of the following:
    boston
    ni169445
    ranchu
    sead-3
    xilfpga

  Specifically the following generic default configurations are
  supported:

  32r1_defconfig           - Build generic kernel for MIPS32 r1
  32r1el_defconfig         - Build generic kernel for MIPS32 r1 little endian
  32r2_defconfig           - Build generic kernel for MIPS32 r2
  32r2el_defconfig         - Build generic kernel for MIPS32 r2 little endian
  32r6_defconfig           - Build generic kernel for MIPS32 r6
  32r6el_defconfig         - Build generic kernel for MIPS32 r6 little endian
  64r1_defconfig           - Build generic kernel for MIPS64 r1
  64r1el_defconfig         - Build generic kernel for MIPS64 r1 little endian
  64r2_defconfig           - Build generic kernel for MIPS64 r2
  64r2el_defconfig         - Build generic kernel for MIPS64 r2 little endian
  64r6_defconfig           - Build generic kernel for MIPS64 r6
  64r6el_defconfig         - Build generic kernel for MIPS64 r6 little endian
  micro32r2_defconfig      - Build generic kernel for microMIPS32 r2
  micro32r2el_defconfig    - Build generic kernel for microMIPS32 r2 little endian

  The following legacy default configurations have been converted to
  generic and can still be used:

  sead3_defconfig          - Build 32r2el_defconfig BOARDS=sead-3
  sead3micro_defconfig     - Build micro32r2el_defconfig BOARDS=sead-3
  xilfpga_defconfig        - Build 32r2el_defconfig BOARDS=xilfpga
  ...

Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Matt Redfearn &lt;matt.redfearn@mips.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kbuild@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/18598/
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Refactor legacy defconfigs</title>
<updated>2018-02-19T21:03:07+00:00</updated>
<author>
<name>James Hogan</name>
<email>jhogan@kernel.org</email>
</author>
<published>2018-02-09T16:11:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=318df8062852b6b7b6a9b2667289eca77fe42e3b'/>
<id>318df8062852b6b7b6a9b2667289eca77fe42e3b</id>
<content type='text'>
Define legacy defconfigs which have been converted to the generic
platform more programatically, so that they can be listed in the
Makefile help text and as a separate Makefile target without
duplication.

Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Matt Redfearn &lt;matt.redfearn@mips.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kbuild@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/18596/
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Define legacy defconfigs which have been converted to the generic
platform more programatically, so that they can be listed in the
Makefile help text and as a separate Makefile target without
duplication.

Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Paul Burton &lt;paul.burton@mips.com&gt;
Cc: Matt Redfearn &lt;matt.redfearn@mips.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kbuild@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/18596/
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: crypto: Add crc32 and crc32c hw accelerated module</title>
<updated>2018-02-19T20:50:36+00:00</updated>
<author>
<name>Marcin Nowakowski</name>
<email>marcin.nowakowski@mips.com</email>
</author>
<published>2018-02-09T22:11:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=4a5dc51e93e80463010ab4d8d00fc9cb6bc936fa'/>
<id>4a5dc51e93e80463010ab4d8d00fc9cb6bc936fa</id>
<content type='text'>
This module registers crc32 and crc32c algorithms that use the
optional CRC32[bhwd] and CRC32C[bhwd] instructions in MIPSr6 cores.

Signed-off-by: Marcin Nowakowski &lt;marcin.nowakowski@mips.com&gt;
Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-crypto@vger.kernel.org
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Patchwork: https://patchwork.linux-mips.org/patch/18601/
[jhogan@kernel.org: Add CRYPTO_ALG_OPTIONAL_KEY flag on Eric Biggers'
 suggestion, due to commit a208fa8f3303 ("crypto: hash - annotate
 algorithms taking optional key") in v4.16-rc1]
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This module registers crc32 and crc32c algorithms that use the
optional CRC32[bhwd] and CRC32C[bhwd] instructions in MIPSr6 cores.

Signed-off-by: Marcin Nowakowski &lt;marcin.nowakowski@mips.com&gt;
Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-crypto@vger.kernel.org
Acked-by: Herbert Xu &lt;herbert@gondor.apana.org.au&gt;
Patchwork: https://patchwork.linux-mips.org/patch/18601/
[jhogan@kernel.org: Add CRYPTO_ALG_OPTIONAL_KEY flag on Eric Biggers'
 suggestion, due to commit a208fa8f3303 ("crypto: hash - annotate
 algorithms taking optional key") in v4.16-rc1]
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: XPA: Use XPA instructions in assembly</title>
<updated>2018-01-22T20:51:55+00:00</updated>
<author>
<name>James Hogan</name>
<email>jhogan@kernel.org</email>
</author>
<published>2017-11-22T11:30:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=8e4789d288e0155db1929b5672252429e52b36a8'/>
<id>8e4789d288e0155db1929b5672252429e52b36a8</id>
<content type='text'>
Utilise XPA instructions MFHC0 &amp; MTHC0 in inline assembly instead of
directly encoding them with the _ASM_INSN* macros, and transparently
implement these instructions as assembler macros if the toolchain
doesn't support them natively, using the recently introduced assembler
macro helpers.

The old direct encodings were restricted to using the register $at, so
this allows the extra register moves to go away (saving a grand total of
24 bytes).

Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17775/
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Utilise XPA instructions MFHC0 &amp; MTHC0 in inline assembly instead of
directly encoding them with the _ASM_INSN* macros, and transparently
implement these instructions as assembler macros if the toolchain
doesn't support them natively, using the recently introduced assembler
macro helpers.

The old direct encodings were restricted to using the register $at, so
this allows the extra register moves to go away (saving a grand total of
24 bytes).

Signed-off-by: James Hogan &lt;jhogan@kernel.org&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/17775/
</pre>
</div>
</content>
</entry>
</feed>
