<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/parisc/Makefile, branch linux-4.19.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.19.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-4.19.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2021-12-08T07:50:14Z</updated>
<entry>
<title>parisc: Fix KBUILD_IMAGE for self-extracting kernel</title>
<updated>2021-12-08T07:50:14Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2021-11-26T21:35:45Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=dba156a3725c4e47c2b5f552a6db91d4de4b9a8c'/>
<id>urn:sha1:dba156a3725c4e47c2b5f552a6db91d4de4b9a8c</id>
<content type='text'>
commit 1d7c29b77725d05faff6754d2f5e7c147aedcf93 upstream.

Default KBUILD_IMAGE to $(boot)/bzImage if a self-extracting
(CONFIG_PARISC_SELF_EXTRACT=y) kernel is to be built.
This fixes the bindeb-pkg make target.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.14+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: Enable -ffunction-sections for modules on 32-bit kernel</title>
<updated>2018-12-13T08:16:18Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2018-11-29T16:05:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6c9ac388c6c86c32bc559c06a4ec52aa0f400374'/>
<id>urn:sha1:6c9ac388c6c86c32bc559c06a4ec52aa0f400374</id>
<content type='text'>
commit 1e8249b8a4e960018e4baca6b523b8a4500af600 upstream.

Frank Schreiner reported, that since kernel 4.18 he faces sysfs-warnings
when loading modules on a 32-bit kernel. Here is one such example:

 sysfs: cannot create duplicate filename '/module/nfs/sections/.text'
 CPU: 0 PID: 98 Comm: modprobe Not tainted 4.18.0-2-parisc #1 Debian 4.18.10-2
 Backtrace:
  [&lt;1017ce2c&gt;] show_stack+0x3c/0x50
  [&lt;107a7210&gt;] dump_stack+0x28/0x38
  [&lt;103f900c&gt;] sysfs_warn_dup+0x88/0xac
  [&lt;103f8b1c&gt;] sysfs_add_file_mode_ns+0x164/0x1d0
  [&lt;103f9e70&gt;] internal_create_group+0x11c/0x304
  [&lt;103fa0a0&gt;] sysfs_create_group+0x48/0x60
  [&lt;1022abe8&gt;] load_module.constprop.35+0x1f9c/0x23b8
  [&lt;1022b278&gt;] sys_finit_module+0xd0/0x11c
  [&lt;101831dc&gt;] syscall_exit+0x0/0x14

This warning gets triggered by the fact, that due to commit 24b6c22504a2
("parisc: Build kernel without -ffunction-sections") we now get multiple .text
sections in the kernel modules for which sysfs_create_group() can't create
multiple virtual files.

This patch works around the problem by re-enabling the -ffunction-sections
compiler option for modules, while keeping it disabled for the non-module
kernel code.

Reported-by: Frank Scheiner &lt;frank.scheiner@web.de&gt;
Fixes: 24b6c22504a2 ("parisc: Build kernel without -ffunction-sections")
Cc: &lt;stable@vger.kernel.org&gt; # v4.18+
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>parisc: Build kernel without -ffunction-sections</title>
<updated>2018-06-29T15:27:20Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2018-04-20T21:13:44Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=24b6c22504a27210a8377e54d24d425ae414f2c1'/>
<id>urn:sha1:24b6c22504a27210a8377e54d24d425ae414f2c1</id>
<content type='text'>
As suggested by Nick Piggin it seems we can drop the -ffunction-sections
compile flag, now that the kernel uses thin archives. Testing with 32-
and 64-bit kernel showed no difference in kernel size.

Suggested-by: Nicholas Piggin &lt;npiggin@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>kbuild: add machine size to CHECKFLAGS</title>
<updated>2018-06-01T02:36:58Z</updated>
<author>
<name>Luc Van Oostenryck</name>
</author>
<published>2018-05-30T20:48:38Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1f2f01b122d7c78a9e842a126ef168afb279552b'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>kbuild: add endianness flag to CHEKCFLAGS</title>
<updated>2018-05-29T13:05:08Z</updated>
<author>
<name>Luc Van Oostenryck</name>
</author>
<published>2018-05-28T18:27:35Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=145167650b96967d6b726efef978c74831e6b2bd'/>
<id>urn:sha1:145167650b96967d6b726efef978c74831e6b2bd</id>
<content type='text'>
The kernel depends on macros like __BYTE_ORDER__,
__BIG_ENDIAN__ or __LITTLE_ENDIAN__.

OTOH, sparse doesn't know about the endianness of the kernel and
by default uses the same as the machine on which sparse was built.

Ensure that sparse can predefine the macros corresponding to
how the kernel was configured by adding -m{big,little}-endian
to CHECKFLAGS in the main Makefile (and so for all archs).
Also, remove the equivalent done 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>
</entry>
<entry>
<title>parisc: Make bzImage default build target</title>
<updated>2018-04-18T13:44:06Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2018-04-18T05:49:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=89e050c87dab3e933dcb90677947752d19aeafa4'/>
<id>urn:sha1:89e050c87dab3e933dcb90677947752d19aeafa4</id>
<content type='text'>
Debian uses "make all" to build the Linux kernel, thus to be able to use
the self-decompressing kernel as default debian kernel we need to make
bzImage the default build target.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>parisc: Pass endianness info to sparse</title>
<updated>2017-11-17T14:27:33Z</updated>
<author>
<name>Luc Van Oostenryck</name>
</author>
<published>2017-10-31T17:21:59Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3744d988c05a27f40408003352841aefadba1324'/>
<id>urn:sha1:3744d988c05a27f40408003352841aefadba1324</id>
<content type='text'>
parisc is big-endian only but sparse assumes the same endianness as the
building machine.
This is problematic for code which expect __BYTE_ORDER__ being correctly
predefined by the compiler which sparse can then pre-process differently
from what gcc would.

Fix this by letting sparse know about the architecture endianness.

To: James Bottomley &lt;jejb@parisc-linux.org&gt;
To: Helge Deller &lt;deller@gmx.de&gt;
CC: linux-parisc@vger.kernel.org
Signed-off-by: Luc Van Oostenryck &lt;luc.vanoostenryck@gmail.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>parisc: Reintroduce option to gzip-compress the kernel</title>
<updated>2017-09-22T20:26:41Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2017-09-22T20:24:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=af21b01d1166248f282fc02d0f459c94de06615e'/>
<id>urn:sha1:af21b01d1166248f282fc02d0f459c94de06615e</id>
<content type='text'>
By adding the feature to build the kernel as self-extracting
executeable, the possibility to simply compress the kernel with gzip was
lost.

This patch now reintroduces this possibilty again and leaves it up to
the user to decide how the kernel should be built.

The palo bootloader is able to natively load both formats.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>parisc: Wire up support for self-extracting kernel</title>
<updated>2017-08-22T14:34:35Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2017-08-20T08:52:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b6adc16e08e0ee8bbc9cccf7af3882b6e1cb30c2'/>
<id>urn:sha1:b6adc16e08e0ee8bbc9cccf7af3882b6e1cb30c2</id>
<content type='text'>
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
<entry>
<title>parisc: Fix ftrace function tracer</title>
<updated>2016-04-14T15:47:19Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2016-04-13T20:27:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=366dd4ea9d5f0eb78fdf4982d76506f99480ec0a'/>
<id>urn:sha1:366dd4ea9d5f0eb78fdf4982d76506f99480ec0a</id>
<content type='text'>
Fix the FTRACE function tracer for 32- and 64-bit kernel.
The former code was horribly broken.

Reimplement most coding in assembly and utilize optimizations, e.g. put
mcount() and ftrace_stub() into one L1 cacheline.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
</feed>
