<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/parisc, branch v3.10</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>parisc: Use unshadowed index register for flush instructions in flush_dcache_page_asm and flush_icache_page_asm</title>
<updated>2013-06-18T18:29:10+00:00</updated>
<author>
<name>John David Anglin</name>
<email>dave.anglin@bell.net</email>
</author>
<published>2013-06-02T16:21:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d65ea48dc61ffdf6cd7f25b4c319bbd68015e018'/>
<id>d65ea48dc61ffdf6cd7f25b4c319bbd68015e018</id>
<content type='text'>
The comment at the start of pacache.S states that the base and index
registers used for fdc,fic, and pdc instructions should not use shadowed
registers. Although this is probably unnecessary for tmpalias flushes,
there is also no reason not to comply.

Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The comment at the start of pacache.S states that the base and index
registers used for fdc,fic, and pdc instructions should not use shadowed
registers. Although this is probably unnecessary for tmpalias flushes,
there is also no reason not to comply.

Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: provide pci_mmap_page_range() for parisc</title>
<updated>2013-06-18T18:29:08+00:00</updated>
<author>
<name>Thomas Bogendoerfer</name>
<email>tsbogend@alpha.franken.de</email>
</author>
<published>2013-06-14T07:05:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=2cc7138f4347df939ce03f313e3d87794bab36f8'/>
<id>2cc7138f4347df939ce03f313e3d87794bab36f8</id>
<content type='text'>
pci_mmap_page_range() is needed for X11-server support on C8000 with ATI
FireGL card.

Signed-off-by Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
pci_mmap_page_range() is needed for X11-server support on C8000 with ATI
FireGL card.

Signed-off-by Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: fix serial ports on C8000 workstation</title>
<updated>2013-06-18T18:29:07+00:00</updated>
<author>
<name>Thomas Bogendoerfer</name>
<email>tsbogend@alpha.franken.de</email>
</author>
<published>2013-06-09T21:00:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9a66d1869d90f13fbaf83dcce5b1aeec86fbc699'/>
<id>9a66d1869d90f13fbaf83dcce5b1aeec86fbc699</id>
<content type='text'>
The C8000 workstation (64 bit kernel only) has a somewhat different
serial port configuration than other models.
Thomas Bogendoerfer sent a patch to fix this in September 2010, which
was now minimally modified by me.

Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The C8000 workstation (64 bit kernel only) has a somewhat different
serial port configuration than other models.
Thomas Bogendoerfer sent a patch to fix this in September 2010, which
was now minimally modified by me.

Signed-off-by: Thomas Bogendoerfer &lt;tsbogend@alpha.franken.de&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: fix kernel BUG at arch/parisc/include/asm/mmzone.h:50 (part 2)</title>
<updated>2013-06-18T18:20:21+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2013-06-05T20:50:01+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=91ea8207168793b365322be3c90a4ee9e8b03ed4'/>
<id>91ea8207168793b365322be3c90a4ee9e8b03ed4</id>
<content type='text'>
Make sure that we really return -1 (instead of 0x00ff) as node id for
page frame numbers which are not physically available.

This finally fixes the kernel panic when running
cat /proc/kpageflags /proc/kpagecount.

Theoretically this patch now limits the number of physical memory ranges
to 127 instead of 254, but currently we have MAX_PHYSMEM_RANGES
hardcoded to 8 which is sufficient for all existing parisc machines.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Make sure that we really return -1 (instead of 0x00ff) as node id for
page frame numbers which are not physically available.

This finally fixes the kernel panic when running
cat /proc/kpageflags /proc/kpagecount.

Theoretically this patch now limits the number of physical memory ranges
to 127 instead of 254, but currently we have MAX_PHYSMEM_RANGES
hardcoded to 8 which is sufficient for all existing parisc machines.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: kernel: using strlcpy() instead of strcpy()</title>
<updated>2013-06-01T12:29:01+00:00</updated>
<author>
<name>Chen Gang</name>
<email>gang.chen@asianux.com</email>
</author>
<published>2013-05-30T01:18:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ea99b1adf22abd62bdcf14b1c9a0a4d3664eefd8'/>
<id>ea99b1adf22abd62bdcf14b1c9a0a4d3664eefd8</id>
<content type='text'>
'boot_args' is an input args, and 'boot_command_line' has a fix length.
So use strlcpy() instead of strcpy() to avoid memory overflow.

Signed-off-by: Chen Gang &lt;gang.chen@asianux.com&gt;
Acked-by: Kyle McMartin &lt;kyle@mcmartin.ca&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
'boot_args' is an input args, and 'boot_command_line' has a fix length.
So use strlcpy() instead of strcpy() to avoid memory overflow.

Signed-off-by: Chen Gang &lt;gang.chen@asianux.com&gt;
Acked-by: Kyle McMartin &lt;kyle@mcmartin.ca&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: rename "CONFIG_PA7100" to "CONFIG_PA7000"</title>
<updated>2013-06-01T12:28:47+00:00</updated>
<author>
<name>Paul Bolle</name>
<email>pebolle@tiscali.nl</email>
</author>
<published>2013-05-29T09:56:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=766039022a480ede847659daaa78772bdcc598ae'/>
<id>766039022a480ede847659daaa78772bdcc598ae</id>
<content type='text'>
There's a Makefile line setting cflags for CONFIG_PA7100. But that
Kconfig macro doesn't exist. There is a Kconfig symbol PA7000, which
covers both PA7000 and PA7100 processors. So let's use the corresponding
Kconfig macro.

Signed-off-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
There's a Makefile line setting cflags for CONFIG_PA7100. But that
Kconfig macro doesn't exist. There is a Kconfig symbol PA7000, which
covers both PA7000 and PA7100 processors. So let's use the corresponding
Kconfig macro.

Signed-off-by: Paul Bolle &lt;pebolle@tiscali.nl&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: fix kernel BUG at arch/parisc/include/asm/mmzone.h:50</title>
<updated>2013-06-01T12:28:35+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2013-05-28T20:35:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=ae249b5fa27f9fba25aa59664d4338efc2dd2394'/>
<id>ae249b5fa27f9fba25aa59664d4338efc2dd2394</id>
<content type='text'>
With CONFIG_DISCONTIGMEM=y and multiple physical memory areas,
cat /proc/kpageflags triggers this kernel bug:

kernel BUG at arch/parisc/include/asm/mmzone.h:50!
CPU: 2 PID: 7848 Comm: cat Tainted: G      D W 3.10.0-rc3-64bit #44
 IAOQ[0]: kpageflags_read0x128/0x238
 IAOQ[1]: kpageflags_read0x12c/0x238
 RP(r2): proc_reg_read0xbc/0x130
Backtrace:
 [&lt;00000000402ca2d4&gt;] proc_reg_read0xbc/0x130
 [&lt;0000000040235bcc&gt;] vfs_read0xc4/0x1d0
 [&lt;0000000040235f0c&gt;] SyS_read0x94/0xf0
 [&lt;0000000040105fc0&gt;] syscall_exit0x0/0x14

kpageflags_read() walks through the whole memory, even if some memory
areas are physically not available. So, we should better not BUG on an
unavailable pfn in pfn_to_nid() but just return the expected value -1 or
0.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With CONFIG_DISCONTIGMEM=y and multiple physical memory areas,
cat /proc/kpageflags triggers this kernel bug:

kernel BUG at arch/parisc/include/asm/mmzone.h:50!
CPU: 2 PID: 7848 Comm: cat Tainted: G      D W 3.10.0-rc3-64bit #44
 IAOQ[0]: kpageflags_read0x128/0x238
 IAOQ[1]: kpageflags_read0x12c/0x238
 RP(r2): proc_reg_read0xbc/0x130
Backtrace:
 [&lt;00000000402ca2d4&gt;] proc_reg_read0xbc/0x130
 [&lt;0000000040235bcc&gt;] vfs_read0xc4/0x1d0
 [&lt;0000000040235f0c&gt;] SyS_read0x94/0xf0
 [&lt;0000000040105fc0&gt;] syscall_exit0x0/0x14

kpageflags_read() walks through the whole memory, even if some memory
areas are physically not available. So, we should better not BUG on an
unavailable pfn in pfn_to_nid() but just return the expected value -1 or
0.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: memory overflow, 'name' length is too short for using</title>
<updated>2013-06-01T12:27:56+00:00</updated>
<author>
<name>Chen Gang</name>
<email>gang.chen@asianux.com</email>
</author>
<published>2013-05-27T04:57:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=3f108de96ba449a8df3d7e3c053bf890fee2cb95'/>
<id>3f108de96ba449a8df3d7e3c053bf890fee2cb95</id>
<content type='text'>
'path.bc[i]' can be asigned by PCI_SLOT() which can '&gt; 10', so sizeof(6
* "%u:" + "%u" + '\0') may be 21.

Since 'name' length is 20, it may be memory overflow.

And 'path.bc[i]' is 'unsigned char' for printing, we can be sure the
max length of 'name' must be less than 28.

So simplify thinking, we can use 28 instead of 20 directly, and do not
think of whether 'patchc.bc[i]' can '&gt; 100'.

Signed-off-by: Chen Gang &lt;gang.chen@asianux.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
'path.bc[i]' can be asigned by PCI_SLOT() which can '&gt; 10', so sizeof(6
* "%u:" + "%u" + '\0') may be 21.

Since 'name' length is 20, it may be memory overflow.

And 'path.bc[i]' is 'unsigned char' for printing, we can be sure the
max length of 'name' must be less than 28.

So simplify thinking, we can use 28 instead of 20 directly, and do not
think of whether 'patchc.bc[i]' can '&gt; 100'.

Signed-off-by: Chen Gang &lt;gang.chen@asianux.com&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: fix irq stack on UP and SMP</title>
<updated>2013-05-24T21:29:01+00:00</updated>
<author>
<name>Helge Deller</name>
<email>deller@gmx.de</email>
</author>
<published>2013-05-24T21:27:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d96b51ec14650b490ab98e738bcc02309396e5bc'/>
<id>d96b51ec14650b490ab98e738bcc02309396e5bc</id>
<content type='text'>
The logic to detect if the irq stack was already in use with
raw_spin_trylock() is wrong, because it will generate a "trylock failure
on UP" error message with CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y.

arch_spin_trylock() can't be used either since in the CONFIG_SMP=n case
no atomic protection is given and we are reentrant here. A mutex didn't
worked either and brings more overhead by turning off interrupts.

So, let's use the fastest path for parisc which is the ldcw instruction.

Counting how often the irq stack was used is pretty useless, so just
drop this piece of code.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The logic to detect if the irq stack was already in use with
raw_spin_trylock() is wrong, because it will generate a "trylock failure
on UP" error message with CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y.

arch_spin_trylock() can't be used either since in the CONFIG_SMP=n case
no atomic protection is given and we are reentrant here. A mutex didn't
worked either and brings more overhead by turning off interrupts.

So, let's use the fastest path for parisc which is the ldcw instruction.

Counting how often the irq stack was used is pretty useless, so just
drop this piece of code.

Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>parisc: make interrupt and interruption stack allocation reentrant</title>
<updated>2013-05-24T20:35:36+00:00</updated>
<author>
<name>John David Anglin</name>
<email>dave.anglin@bell.net</email>
</author>
<published>2013-05-20T16:42:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=b63a2bbc0b9b106a93e11952ab057e2408f2eb02'/>
<id>b63a2bbc0b9b106a93e11952ab057e2408f2eb02</id>
<content type='text'>
The get_stack_use_cr30 and get_stack_use_r30 macros allocate a stack
frame for external interrupts and interruptions requiring a stack frame.
They are currently not reentrant in that they save register context
before the stack is set or adjusted.

I have observed a number of system crashes where there was clear
evidence of stack corruption during interrupt processing, and as a
result register corruption. Some interruptions can still occur during
interruption processing, however external interrupts are disabled and
data TLB misses don't occur for absolute accesses. So, it's not entirely
clear what triggers this issue. Also, if an interruption occurs when
Q=0, it is generally not possible to recover as the shadowed registers
are not copied.

The attached patch reworks the get_stack_use_cr30 and get_stack_use_r30
macros to allocate stack before doing register saves. The new code is a
couple of instructions shorter than the old implementation. Thus, it's
an improvement even if it doesn't fully resolve the stack corruption
issue. Based on limited testing, it improves SMP system stability.

Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The get_stack_use_cr30 and get_stack_use_r30 macros allocate a stack
frame for external interrupts and interruptions requiring a stack frame.
They are currently not reentrant in that they save register context
before the stack is set or adjusted.

I have observed a number of system crashes where there was clear
evidence of stack corruption during interrupt processing, and as a
result register corruption. Some interruptions can still occur during
interruption processing, however external interrupts are disabled and
data TLB misses don't occur for absolute accesses. So, it's not entirely
clear what triggers this issue. Also, if an interruption occurs when
Q=0, it is generally not possible to recover as the shadowed registers
are not copied.

The attached patch reworks the get_stack_use_cr30 and get_stack_use_r30
macros to allocate stack before doing register saves. The new code is a
couple of instructions shorter than the old implementation. Thus, it's
an improvement even if it doesn't fully resolve the stack corruption
issue. Based on limited testing, it improves SMP system stability.

Signed-off-by: John David Anglin &lt;dave.anglin@bell.net&gt;
Signed-off-by: Helge Deller &lt;deller@gmx.de&gt;
</pre>
</div>
</content>
</entry>
</feed>
