<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/parisc, branch linux-5.19.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.19.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.19.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2022-10-24T07:56:45Z</updated>
<entry>
<title>parisc: Fix userspace graphics card breakage due to pgtable special bit</title>
<updated>2022-10-24T07:56:45Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-10-14T08:18:53Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=68a1aac5bdd5ba681d6406115ac0214d74bf498f'/>
<id>urn:sha1:68a1aac5bdd5ba681d6406115ac0214d74bf498f</id>
<content type='text'>
commit 70be49f2f6223ddd2fcddb0089a40864c37e1494 upstream.

Commit df24e1783e6e ("parisc: Add vDSO support") introduced the vDSO
support, for which a _PAGE_SPECIAL page table flag was needed.  Since we
wanted to keep every page table entry in 32-bits, this patch re-used the
existing - but yet unused - _PAGE_DMB flag (which triggers a hardware break
if a page is accessed) to store the special bit.

But when graphics card memory is mmapped into userspace, the kernel uses
vm_iomap_memory() which sets the the special flag. So, with the DMB bit
set, every access to the graphics memory now triggered a hardware
exception and segfaulted the userspace program.

Fix this breakage by dropping the DMB bit when writing the page
protection bits to the CPU TLB.

In addition this patch adds a small optimization: if huge pages aren't
configured (which is at least the case for 32-bit kernels), then the
special bit is stored in the hpage (HUGE PAGE) bit instead. That way we
can skip to reset the DMB bit.

Fixes: df24e1783e6e ("parisc: Add vDSO support")
Cc: &lt;stable@vger.kernel.org&gt; # 5.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: Allow CONFIG_64BIT with ARCH=parisc</title>
<updated>2022-09-23T12:14:05Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-09-13T06:51:10Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ac12a96d1d3535e94f6af0fd0f2d4f9d8be4c71d'/>
<id>urn:sha1:ac12a96d1d3535e94f6af0fd0f2d4f9d8be4c71d</id>
<content type='text'>
commit 805ce8614958c925877ba6b6dc26cdf9f8800474 upstream.

The previous patch triggered a build failure for the debian kernel,
which has CONFIG_64BIT enabled, uses the CROSS_COMPILER environment
variable and uses ARCH=parisc to configure the kernel for 64-bit
support.

This patch weakens the previous patch while keeping the recommended way
to configure the kernel with:
    ARCH=parisc     -&gt; build 32-bit kernel
    ARCH=parisc64   -&gt; build 64-bit kernel
while adding the possibility for debian to configure a 64-bit kernel
even if ARCH=parisc is set (PA8X00 CPU has to be selected and
CONFIG_64BIT needs to be enabled).

The downside of this patch is, that we now have a small window open
again where people may get it wrong: if they enable CONFIG_64BIT and try
to compile with a 32-bit compiler.

Fixes: 3dcfb729b5f4 ("parisc: Make CONFIG_64BIT available for ARCH=parisc64 only")
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 5.15+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: Add runtime check to prevent PA2.0 kernels on PA1.x machines</title>
<updated>2022-09-15T08:47:08Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-08-21T12:49:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=078dac729f733cbf55fd25bd0ac0ed70f299b2ab'/>
<id>urn:sha1:078dac729f733cbf55fd25bd0ac0ed70f299b2ab</id>
<content type='text'>
[ Upstream commit 591d2108f3abc4db9f9073cae37cf3591fd250d6 ]

If a 32-bit kernel was compiled for PA2.0 CPUs, it won't be able to run
on machines with PA1.x CPUs. Add a check and bail out early if a PA1.x
machine is detected.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>Revert "parisc: Show error if wrong 32/64-bit compiler is being used"</title>
<updated>2022-09-15T08:47:08Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-08-21T06:12:19Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=fe7f0ac20b86ffb74c12f0cabac085ae9609d153'/>
<id>urn:sha1:fe7f0ac20b86ffb74c12f0cabac085ae9609d153</id>
<content type='text'>
[ Upstream commit b4b18f47f4f9682fbf5827682645da7c8dde8f80 ]

This reverts commit b160628e9ebcdc85d0db9d7f423c26b3c7c179d0.

There is no need any longer to have this sanity check, because the
previous commit ("parisc: Make CONFIG_64BIT available for ARCH=parisc64
only") prevents that CONFIG_64BIT is set if ARCH==parisc.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>parisc: Fix exception handler for fldw and fstw instructions</title>
<updated>2022-08-31T15:17:59Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-08-20T15:59:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=760dc9f658d7fb133007eba63fa012618752fd48'/>
<id>urn:sha1:760dc9f658d7fb133007eba63fa012618752fd48</id>
<content type='text'>
commit 7ae1f5508d9a33fd58ed3059bd2d569961e3b8bd upstream.

The exception handler is broken for unaligned memory acceses with fldw
and fstw instructions, because it trashes or uses randomly some other
floating point register than the one specified in the instruction word
on loads and stores.

The instruction "fldw 0(addr),%fr22L" (and the other fldw/fstw
instructions) encode the target register (%fr22) in the rightmost 5 bits
of the instruction word. The 7th rightmost bit of the instruction word
defines if the left or right half of %fr22 should be used.

While processing unaligned address accesses, the FR3() define is used to
extract the offset into the local floating-point register set.  But the
calculation in FR3() was buggy, so that for example instead of %fr22,
register %fr12 [((22 * 2) &amp; 0x1f) = 12] was used.

This bug has been since forever in the parisc kernel and I wonder why it
wasn't detected earlier. Interestingly I noticed this bug just because
the libime debian package failed to build on *native* hardware, while it
successfully built in qemu.

This patch corrects the bitshift and masking calculation in FR3().

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: Make CONFIG_64BIT available for ARCH=parisc64 only</title>
<updated>2022-08-31T15:17:59Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-08-19T17:30:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=012dad4b908a1b7ee3b4c1a52f5deb12dc446c46'/>
<id>urn:sha1:012dad4b908a1b7ee3b4c1a52f5deb12dc446c46</id>
<content type='text'>
commit 3dcfb729b5f4a0c9b50742865cd5e6c4dbcc80dc upstream.

With this patch the ARCH= parameter decides if the
CONFIG_64BIT option will be set or not. This means, the
ARCH= parameter will give:

	ARCH=parisc	-&gt; 32-bit kernel
	ARCH=parisc64	-&gt; 64-bit kernel

This simplifies the usage of the other config options like
randconfig, allmodconfig and allyesconfig a lot and produces
the output which is expected for parisc64 (64-bit) vs. parisc (32-bit).

Suggested-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Tested-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Reviewed-by: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: &lt;stable@vger.kernel.org&gt; # 5.15+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: io_pgetevents_time64() needs compat syscall in 32-bit compat mode</title>
<updated>2022-08-17T13:13:48Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-08-01T15:36:15Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=844a857bbce3687af5fb1ba4c2e9243016766717'/>
<id>urn:sha1:844a857bbce3687af5fb1ba4c2e9243016766717</id>
<content type='text'>
commit 6431e92fc827bdd2d28f79150d90415ba9ce0d21 upstream.

For all syscalls in 32-bit compat mode on 64-bit kernels the upper
32-bits of the 64-bit registers are zeroed out, so a negative 32-bit
signed value will show up as positive 64-bit signed value.

This behaviour breaks the io_pgetevents_time64() syscall which expects
signed 64-bit values for the "min_nr" and "nr" parameters.
Fix this by switching to the compat_sys_io_pgetevents_time64() syscall,
which uses "compat_long_t" types for those parameters.

Cc: &lt;stable@vger.kernel.org&gt; # v5.1+
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: Drop pa_swapper_pg_lock spinlock</title>
<updated>2022-08-17T13:13:48Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-07-19T04:19:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=6f0c087a68e5ce6b1de8ba18ed59f14c606e74d5'/>
<id>urn:sha1:6f0c087a68e5ce6b1de8ba18ed59f14c606e74d5</id>
<content type='text'>
commit 3fbc9a7de0564c55d8a9584c9cd2c9dfe6bd6d43 upstream.

This spinlock was dropped with commit b7795074a046 ("parisc: Optimize
per-pagetable spinlocks") in kernel v5.12.

Remove it to silence a sparse warning.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v5.12+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: Fix device names in /proc/iomem</title>
<updated>2022-08-17T13:13:48Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-07-18T15:06:47Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5c9e6c5e86a09314fb52c01be03010715cbdc369'/>
<id>urn:sha1:5c9e6c5e86a09314fb52c01be03010715cbdc369</id>
<content type='text'>
commit cab56b51ec0e69128909cef4650e1907248d821b upstream.

Fix the output of /proc/iomem to show the real hardware device name
including the pa_pathname, e.g. "Merlin 160 Core Centronics [8:16:0]".
Up to now only the pa_pathname ("[8:16.0]") was shown.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.9+
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>parisc: Fix vDSO signal breakage on 32-bit kernel</title>
<updated>2022-07-02T16:36:58Z</updated>
<author>
<name>Helge Deller</name>
</author>
<published>2022-07-01T07:00:41Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=aa78fa905b4431c432071a878da99c2b37fc0e79'/>
<id>urn:sha1:aa78fa905b4431c432071a878da99c2b37fc0e79</id>
<content type='text'>
Addition of vDSO support for parisc in kernel v5.18 suddenly broke glibc
signal testcases on a 32-bit kernel.

The trampoline code (sigtramp.S) which is mapped into userspace includes
an offset to the context data on the stack, which is used by gdb and
glibc to get access to registers.

In a 32-bit kernel we used by mistake the offset into the compat context
(which is valid on a 64-bit kernel only) instead of the offset into the
"native" 32-bit context.

Reported-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Tested-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Fixes: 	df24e1783e6e ("parisc: Add vDSO support")
CC: stable@vger.kernel.org # 5.18
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
</entry>
</feed>
