<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/arch/mips/kernel, branch v2.6.37</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>MIPS: MT: Fix typo in comment.</title>
<updated>2010-12-16T18:11:00+00:00</updated>
<author>
<name>Ralf Baechle</name>
<email>ralf@linux-mips.org</email>
</author>
<published>2010-12-01T17:33:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d002aaadf84c081623a0a8502c122d1492fbd47c'/>
<id>d002aaadf84c081623a0a8502c122d1492fbd47c</id>
<content type='text'>
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: FDT size is a be32</title>
<updated>2010-12-16T18:10:58+00:00</updated>
<author>
<name>Thomas Chou</name>
<email>thomas@wytron.com.tw</email>
</author>
<published>2010-11-24T07:35:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=e31fee7c3a197d88d1d0ced0e8600386da27fec4'/>
<id>e31fee7c3a197d88d1d0ced0e8600386da27fec4</id>
<content type='text'>
The totalsize field was be32. And the reserve bootmem would cause failure.

Signed-off-by: Thomas Chou &lt;thomas@wytron.com.tw&gt;
To: devicetree-discuss@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: grant.likely@secretlab.ca
Cc: David Daney &lt;ddaney@caviumnetworks.com&gt;
Cc: Dezhong Diao &lt;dediao@cisco.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/1838/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The totalsize field was be32. And the reserve bootmem would cause failure.

Signed-off-by: Thomas Chou &lt;thomas@wytron.com.tw&gt;
To: devicetree-discuss@lists.ozlabs.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: grant.likely@secretlab.ca
Cc: David Daney &lt;ddaney@caviumnetworks.com&gt;
Cc: Dezhong Diao &lt;dediao@cisco.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/1838/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Fix CP0 COUNTER clockevent race</title>
<updated>2010-12-16T18:10:58+00:00</updated>
<author>
<name>Kevin Cernekee</name>
<email>cernekee@gmail.com</email>
</author>
<published>2010-11-23T18:26:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=5878fc936aebf592cca418ca50773cd578f7daf4'/>
<id>5878fc936aebf592cca418ca50773cd578f7daf4</id>
<content type='text'>
Consider the following test case:

write_c0_compare(read_c0_count());

Even if the counter doesn't increment during execution, this might not
generate an interrupt until the counter wraps around.  The CPU may
perform the comparison each time CP0 COUNT increments, not when CP0
COMPARE is written.

If mips_next_event() is called with a very small delta, and CP0 COUNT
increments during the calculation of "cnt += delta", it is possible
that CP0 COMPARE will be written with the current value of CP0 COUNT.
If this is detected, the function should return -ETIME, to indicate
that the interrupt might not have actually gotten scheduled.

Signed-off-by: Kevin Cernekee &lt;cernekee@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/1836/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Consider the following test case:

write_c0_compare(read_c0_count());

Even if the counter doesn't increment during execution, this might not
generate an interrupt until the counter wraps around.  The CPU may
perform the comparison each time CP0 COUNT increments, not when CP0
COMPARE is written.

If mips_next_event() is called with a very small delta, and CP0 COUNT
increments during the calculation of "cnt += delta", it is possible
that CP0 COMPARE will be written with the current value of CP0 COUNT.
If this is detected, the function should return -ETIME, to indicate
that the interrupt might not have actually gotten scheduled.

Signed-off-by: Kevin Cernekee &lt;cernekee@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/1836/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Fix regression on BCM4710 processor detection</title>
<updated>2010-12-16T18:10:58+00:00</updated>
<author>
<name>Kevin Cernekee</name>
<email>cernekee@gmail.com</email>
</author>
<published>2010-11-23T18:26:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=190fca3e40a65303eac35ac4fbae4f1f1342431c'/>
<id>190fca3e40a65303eac35ac4fbae4f1f1342431c</id>
<content type='text'>
BCM4710 uses the BMIPS32 core (like BCM6345), not the MIPS 4Kc core as
was previously believed.

Signed-off-by: Kevin Cernekee &lt;cernekee@gmail.com&gt;
Tested-by: Alexandros C. Couloumbis &lt;alex@ozo.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/1837/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
BCM4710 uses the BMIPS32 core (like BCM6345), not the MIPS 4Kc core as
was previously believed.

Signed-off-by: Kevin Cernekee &lt;cernekee@gmail.com&gt;
Tested-by: Alexandros C. Couloumbis &lt;alex@ozo.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/1837/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Send proper signal and siginfo on FP emulator faults.</title>
<updated>2010-12-16T18:10:57+00:00</updated>
<author>
<name>David Daney</name>
<email>ddaney@caviumnetworks.com</email>
</author>
<published>2010-10-21T23:32:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=515b029d005b5694cf612a0a5ca6f861a7e45362'/>
<id>515b029d005b5694cf612a0a5ca6f861a7e45362</id>
<content type='text'>
We were unconditionally sending SIGBUS with an empty siginfo on FP
emulator faults.  This differs from what happens when real floating
point hardware would get a fault.

For most faults we need to send SIGSEGV with the faulting address
filled in in the struct siginfo.

Reported-by: Camm Maguire &lt;camm@maguirefamily.org&gt;
Signed-off-by: David Daney &lt;ddaney@caviumnetworks.com&gt;
To: linux-mips@linux-mips.org
Cc: Camm Maguire &lt;camm@maguirefamily.org&gt;
Patchwork: https://patchwork.linux-mips.org/patch/1727/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We were unconditionally sending SIGBUS with an empty siginfo on FP
emulator faults.  This differs from what happens when real floating
point hardware would get a fault.

For most faults we need to send SIGSEGV with the faulting address
filled in in the struct siginfo.

Reported-by: Camm Maguire &lt;camm@maguirefamily.org&gt;
Signed-off-by: David Daney &lt;ddaney@caviumnetworks.com&gt;
To: linux-mips@linux-mips.org
Cc: Camm Maguire &lt;camm@maguirefamily.org&gt;
Patchwork: https://patchwork.linux-mips.org/patch/1727/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: VPE loader: Check vmalloc return value in vpe_open</title>
<updated>2010-12-16T18:10:54+00:00</updated>
<author>
<name>Jesper Juhl</name>
<email>jj@chaosbits.net</email>
</author>
<published>2010-10-30T16:37:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=863abad4f644b6c12bc8176206b35fa7e7cfe1a9'/>
<id>863abad4f644b6c12bc8176206b35fa7e7cfe1a9</id>
<content type='text'>
The return value of the vmalloc() call in arch/mips/kernel/vpe.c::vpe_open()
is not checked, so we potentially store a null pointer in v-&gt;pbuffer.  Add
a check for a null return and then return -ENOMEM in that case.

[Ralf: The check added by Jesper's original patch is where it logically
should be.  Adding it eleminated the need for the checks in a few other
places, so I removed them.  There still is a zillion of other things that
need to be fixed in this file / API.]

Signed-off-by: Jesper Juhl &lt;jj@chaosbits.net&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/1747/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The return value of the vmalloc() call in arch/mips/kernel/vpe.c::vpe_open()
is not checked, so we potentially store a null pointer in v-&gt;pbuffer.  Add
a check for a null return and then return -ENOMEM in that case.

[Ralf: The check added by Jesper's original patch is where it logically
should be.  Adding it eleminated the need for the checks in a few other
places, so I removed them.  There still is a zillion of other things that
need to be fixed in this file / API.]

Signed-off-by: Jesper Juhl &lt;jj@chaosbits.net&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/1747/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: compat: Don't clobber personality bits in 32-bit sys_personality().</title>
<updated>2010-12-16T18:10:54+00:00</updated>
<author>
<name>David Daney</name>
<email>ddaney@caviumnetworks.com</email>
</author>
<published>2010-11-02T00:43:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=d62c9ced7ca783e64ff4d9d3d1340cfe2284d47b'/>
<id>d62c9ced7ca783e64ff4d9d3d1340cfe2284d47b</id>
<content type='text'>
If PER_LINUX32 has been set on a 32-bit kernel, only twiddle with the
low-order personality bits, let the upper bits pass through.

Signed-off-by: David Daney &lt;ddaney@caviumnetworks.com&gt;
To: linux-mips@linux-mips.org
Cc: Camm Maguire &lt;camm@maguirefamily.org&gt;
Patchwork: https://patchwork.linux-mips.org/patch/1751/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
If PER_LINUX32 has been set on a 32-bit kernel, only twiddle with the
low-order personality bits, let the upper bits pass through.

Signed-off-by: David Daney &lt;ddaney@caviumnetworks.com&gt;
To: linux-mips@linux-mips.org
Cc: Camm Maguire &lt;camm@maguirefamily.org&gt;
Patchwork: https://patchwork.linux-mips.org/patch/1751/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Don't stomp on caller's -&gt;regs[2] in copy_thread()</title>
<updated>2010-12-16T18:10:52+00:00</updated>
<author>
<name>Al Viro</name>
<email>viro@ZenIV.linux.org.uk</email>
</author>
<published>2010-11-04T11:13:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=a989ff898f9740651d00388c33bdf4f2a7914920'/>
<id>a989ff898f9740651d00388c33bdf4f2a7914920</id>
<content type='text'>
We never needed that (-&gt;regs[2] is overwritten on return from syscall paths
with return value of syscall, so storing it there early made no sense) and
with new restart logics since d27240bf7e61d2656de18e158ec910a902030847 it
has become really bad - we lose the original syscall number before the
place where we decide that we might need a syscall restart.

Note that for child we do need the assignment to regs[2] - it won't go
through the normal return from syscall path.

[Ralf: Issue found and reported by Lluís; initial investigations by me;
bug finally found and patch by Al; testing by me and Lluís.]

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Tested-by: Lluís Batlle i Rossell &lt;viriketo@gmail.com&gt;
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We never needed that (-&gt;regs[2] is overwritten on return from syscall paths
with return value of syscall, so storing it there early made no sense) and
with new restart logics since d27240bf7e61d2656de18e158ec910a902030847 it
has become really bad - we lose the original syscall number before the
place where we decide that we might need a syscall restart.

Note that for child we do need the assignment to regs[2] - it won't go
through the normal return from syscall path.

[Ralf: Issue found and reported by Lluís; initial investigations by me;
bug finally found and patch by Al; testing by me and Lluís.]

Signed-off-by: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Tested-by: Lluís Batlle i Rossell &lt;viriketo@gmail.com&gt;
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Make TASK_SIZE reflect proper size for both 32 and 64 bit processes.</title>
<updated>2010-10-29T18:08:53+00:00</updated>
<author>
<name>David Daney</name>
<email>ddaney@caviumnetworks.com</email>
</author>
<published>2010-10-14T18:32:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=949e51bea342da838be5295628e4a7ada8bae833'/>
<id>949e51bea342da838be5295628e4a7ada8bae833</id>
<content type='text'>
The TASK_SIZE macro should reflect the size of a user process virtual
address space.  Previously for 64-bit kernels, this was not the case.
The immediate cause of pain was in
hugetlbfs/inode.c:hugetlb_get_unmapped_area() where 32-bit processes
trying to mmap a huge page would be served a page with an address
outside of the 32-bit address range.  But there are other uses of
TASK_SIZE in the kernel as well that would like an accurate value.

The new definition is nice because it now makes TASK_SIZE and
TASK_SIZE_OF() yield the same value for any given process.

For 32-bit kernels there should be no change, although I did factor
out some code in asm/processor.h that became identical for the 32-bit and
64-bit cases.

__UA_LIMIT is now set to ~((1 &lt;&lt; SEGBITS) - 1) for 64-bit kernels.
This should eliminate the possibility of getting a
AddressErrorException in the kernel for addresses that pass the
access_ok() test.

With the patch applied, I can still run o32, n32 and n64 processes,
and have an o32 shell fork/exec both n32 and n64 processes.

Signed-off-by: David Daney &lt;ddaney@caviumnetworks.com&gt;
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1701/
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The TASK_SIZE macro should reflect the size of a user process virtual
address space.  Previously for 64-bit kernels, this was not the case.
The immediate cause of pain was in
hugetlbfs/inode.c:hugetlb_get_unmapped_area() where 32-bit processes
trying to mmap a huge page would be served a page with an address
outside of the 32-bit address range.  But there are other uses of
TASK_SIZE in the kernel as well that would like an accurate value.

The new definition is nice because it now makes TASK_SIZE and
TASK_SIZE_OF() yield the same value for any given process.

For 32-bit kernels there should be no change, although I did factor
out some code in asm/processor.h that became identical for the 32-bit and
64-bit cases.

__UA_LIMIT is now set to ~((1 &lt;&lt; SEGBITS) - 1) for 64-bit kernels.
This should eliminate the possibility of getting a
AddressErrorException in the kernel for addresses that pass the
access_ok() test.

With the patch applied, I can still run o32, n32 and n64 processes,
and have an o32 shell fork/exec both n32 and n64 processes.

Signed-off-by: David Daney &lt;ddaney@caviumnetworks.com&gt;
To: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/1701/
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Allow UserLocal on MIPS_R1 processors</title>
<updated>2010-10-29T18:08:53+00:00</updated>
<author>
<name>Kevin Cernekee</name>
<email>cernekee@gmail.com</email>
</author>
<published>2010-10-16T21:22:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=18d693b3598fdebdd5c65a613221793456a7ce45'/>
<id>18d693b3598fdebdd5c65a613221793456a7ce45</id>
<content type='text'>
Some MIPS32R1 processors implement UserLocal (RDHWR $29) to accelerate
programs that make extensive use of thread-local storage.  Therefore,
setting up the HWRENA register should not depend on cpu_has_mips_r2.

Signed-off-by: Kevin Cernekee &lt;cernekee@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Some MIPS32R1 processors implement UserLocal (RDHWR $29) to accelerate
programs that make extensive use of thread-local storage.  Therefore,
setting up the HWRENA register should not depend on cpu_has_mips_r2.

Signed-off-by: Kevin Cernekee &lt;cernekee@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
</pre>
</div>
</content>
</entry>
</feed>
