<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/arch/mips/kernel, branch v3.12.29</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>MIPS: Remove BUG_ON(!is_fpu_owner()) in do_ade()</title>
<updated>2014-09-17T14:55:07+00:00</updated>
<author>
<name>Huacai Chen</name>
<email>chenhc@lemote.com</email>
</author>
<published>2014-07-16T01:19:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=6540a038754f78f73075f906ce42c04f84297e3e'/>
<id>6540a038754f78f73075f906ce42c04f84297e3e</id>
<content type='text'>
commit 2e5767a27337812f6850b3fa362419e2f085e5c3 upstream.

In do_ade(), is_fpu_owner() isn't preempt-safe. For example, when an
unaligned ldc1 is executed, do_cpu() is called and then FPU will be
enabled (and TIF_USEDFPU will be set for the current process). Then,
do_ade() is called because the access is unaligned.  If the current
process is preempted at this time, TIF_USEDFPU will be cleard.  So when
the process is scheduled again, BUG_ON(!is_fpu_owner()) is triggered.

This small program can trigger this BUG in a preemptible kernel:

int main (int argc, char *argv[])
{
        double u64[2];

        while (1) {
                asm volatile (
                        ".set push \n\t"
                        ".set noreorder \n\t"
                        "ldc1 $f3, 4(%0) \n\t"
                        ".set pop \n\t"
                        ::"r"(u64):
                );
        }

        return 0;
}

V2: Remove the BUG_ON() unconditionally due to Paul's suggestion.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Jie Chen &lt;chenj@lemote.com&gt;
Signed-off-by: Rui Wang &lt;wangr@lemote.com&gt;
Cc: John Crispin &lt;john@phrozen.org&gt;
Cc: Steven J. Hill &lt;Steven.Hill@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 2e5767a27337812f6850b3fa362419e2f085e5c3 upstream.

In do_ade(), is_fpu_owner() isn't preempt-safe. For example, when an
unaligned ldc1 is executed, do_cpu() is called and then FPU will be
enabled (and TIF_USEDFPU will be set for the current process). Then,
do_ade() is called because the access is unaligned.  If the current
process is preempted at this time, TIF_USEDFPU will be cleard.  So when
the process is scheduled again, BUG_ON(!is_fpu_owner()) is triggered.

This small program can trigger this BUG in a preemptible kernel:

int main (int argc, char *argv[])
{
        double u64[2];

        while (1) {
                asm volatile (
                        ".set push \n\t"
                        ".set noreorder \n\t"
                        "ldc1 $f3, 4(%0) \n\t"
                        ".set pop \n\t"
                        ::"r"(u64):
                );
        }

        return 0;
}

V2: Remove the BUG_ON() unconditionally due to Paul's suggestion.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Signed-off-by: Jie Chen &lt;chenj@lemote.com&gt;
Signed-off-by: Rui Wang &lt;wangr@lemote.com&gt;
Cc: John Crispin &lt;john@phrozen.org&gt;
Cc: Steven J. Hill &lt;Steven.Hill@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Prevent user from setting FCSR cause bits</title>
<updated>2014-09-17T14:55:06+00:00</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@imgtec.com</email>
</author>
<published>2014-07-22T13:21:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=44058412d0bd644f73b6a2e13d7a8be0f8a4b56d'/>
<id>44058412d0bd644f73b6a2e13d7a8be0f8a4b56d</id>
<content type='text'>
commit b1442d39fac2fcfbe6a4814979020e993ca59c9e upstream.

If one or more matching FCSR cause &amp; enable bits are set in saved thread
context then when that context is restored the kernel will take an FP
exception. This is of course undesirable and considered an oops, leading
to the kernel writing a backtrace to the console and potentially
rebooting depending upon the configuration. Thus the kernel avoids this
situation by clearing the cause bits of the FCSR register when handling
FP exceptions and after emulating FP instructions.

However the kernel does not prevent userland from setting arbitrary FCSR
cause &amp; enable bits via ptrace, using either the PTRACE_POKEUSR or
PTRACE_SETFPREGS requests. This means userland can trivially cause the
kernel to oops on any system with an FPU. Prevent this from happening
by clearing the cause bits when writing to the saved FCSR context via
ptrace.

This problem appears to exist at least back to the beginning of the git
era in the PTRACE_POKEUSR case.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7438/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit b1442d39fac2fcfbe6a4814979020e993ca59c9e upstream.

If one or more matching FCSR cause &amp; enable bits are set in saved thread
context then when that context is restored the kernel will take an FP
exception. This is of course undesirable and considered an oops, leading
to the kernel writing a backtrace to the console and potentially
rebooting depending upon the configuration. Thus the kernel avoids this
situation by clearing the cause bits of the FCSR register when handling
FP exceptions and after emulating FP instructions.

However the kernel does not prevent userland from setting arbitrary FCSR
cause &amp; enable bits via ptrace, using either the PTRACE_POKEUSR or
PTRACE_SETFPREGS requests. This means userland can trivially cause the
kernel to oops on any system with an FPU. Prevent this from happening
by clearing the cause bits when writing to the saved FCSR context via
ptrace.

This problem appears to exist at least back to the beginning of the git
era in the PTRACE_POKEUSR case.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/7438/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: GIC: Prevent array overrun</title>
<updated>2014-09-17T14:55:06+00:00</updated>
<author>
<name>Jeffrey Deans</name>
<email>jeffrey.deans@imgtec.com</email>
</author>
<published>2014-07-17T08:20:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=41c6ebd1c89fd33d9d55fe5307626b35503d87db'/>
<id>41c6ebd1c89fd33d9d55fe5307626b35503d87db</id>
<content type='text'>
commit ffc8415afab20bd97754efae6aad1f67b531132b upstream.

A GIC interrupt which is declared as having a GIC_MAP_TO_NMI_MSK
mapping causes the cpu parameter to gic_setup_intr() to be increased
to 32, causing memory corruption when pcpu_masks[] is written to again
later in the function.

Signed-off-by: Jeffrey Deans &lt;jeffrey.deans@imgtec.com&gt;
Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7375/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ffc8415afab20bd97754efae6aad1f67b531132b upstream.

A GIC interrupt which is declared as having a GIC_MAP_TO_NMI_MSK
mapping causes the cpu parameter to gic_setup_intr() to be increased
to 32, causing memory corruption when pcpu_masks[] is written to again
later in the function.

Signed-off-by: Jeffrey Deans &lt;jeffrey.deans@imgtec.com&gt;
Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7375/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: MSC: Prevent out-of-bounds writes to MIPS SC ioremap'd region</title>
<updated>2014-07-17T11:43:16+00:00</updated>
<author>
<name>Markos Chandras</name>
<email>markos.chandras@imgtec.com</email>
</author>
<published>2014-06-23T08:48:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8acb1c84456884115a0e7a8d077a88d074d79d20'/>
<id>8acb1c84456884115a0e7a8d077a88d074d79d20</id>
<content type='text'>
commit ab6c15bc6620ebe220970cc040b29bcb2757f373 upstream.

Previously, the lower limit for the MIPS SC initialization loop was
set incorrectly allowing one extra loop leading to writes
beyond the MSC ioremap'd space. More precisely, the value of the 'imp'
in the last loop increased beyond the msc_irqmap_t boundaries and
as a result of which, the 'n' variable was loaded with an incorrect
value. This value was used later on to calculate the offset in the
MSC01_IC_SUP which led to random crashes like the following one:

CPU 0 Unable to handle kernel paging request at virtual address e75c0200,
epc == 8058dba4, ra == 8058db90
[...]
Call Trace:
[&lt;8058dba4&gt;] init_msc_irqs+0x104/0x154
[&lt;8058b5bc&gt;] arch_init_irq+0xd8/0x154
[&lt;805897b0&gt;] start_kernel+0x220/0x36c

Kernel panic - not syncing: Attempted to kill the idle task!

This patch fixes the problem

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7118/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit ab6c15bc6620ebe220970cc040b29bcb2757f373 upstream.

Previously, the lower limit for the MIPS SC initialization loop was
set incorrectly allowing one extra loop leading to writes
beyond the MSC ioremap'd space. More precisely, the value of the 'imp'
in the last loop increased beyond the msc_irqmap_t boundaries and
as a result of which, the 'n' variable was loaded with an incorrect
value. This value was used later on to calculate the offset in the
MSC01_IC_SUP which led to random crashes like the following one:

CPU 0 Unable to handle kernel paging request at virtual address e75c0200,
epc == 8058dba4, ra == 8058db90
[...]
Call Trace:
[&lt;8058dba4&gt;] init_msc_irqs+0x104/0x154
[&lt;8058b5bc&gt;] arch_init_irq+0xd8/0x154
[&lt;805897b0&gt;] start_kernel+0x220/0x36c

Kernel panic - not syncing: Attempted to kill the idle task!

This patch fixes the problem

Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Reviewed-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/7118/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Perf: Fix 74K cache map</title>
<updated>2013-10-29T20:18:23+00:00</updated>
<author>
<name>Deng-Cheng Zhu</name>
<email>dengcheng.zhu@imgtec.com</email>
</author>
<published>2013-10-08T15:17:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=7f081f175502373673c015a4d0fa1d5cc264758a'/>
<id>7f081f175502373673c015a4d0fa1d5cc264758a</id>
<content type='text'>
According to Software User's Manual, the event of last-level-cache
read/write misses is mapped to even counters. Odd counters of that
event number count miss cycles.

Signed-off-by: Deng-Cheng Zhu &lt;dengcheng.zhu@imgtec.com&gt;
Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6036/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
According to Software User's Manual, the event of last-level-cache
read/write misses is mapped to even counters. Odd counters of that
event number count miss cycles.

Signed-off-by: Deng-Cheng Zhu &lt;dengcheng.zhu@imgtec.com&gt;
Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6036/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: stack protector: Fix per-task canary switch</title>
<updated>2013-10-07T13:31:04+00:00</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2013-10-07T11:14:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8b3c569a3999a8fd5a819f892525ab5520777c92'/>
<id>8b3c569a3999a8fd5a819f892525ab5520777c92</id>
<content type='text'>
Commit 1400eb6 (MIPS: r4k,octeon,r2300: stack protector: change canary
per task) was merged in v3.11 and introduced assembly in the MIPS resume
functions to update the value of the current canary in
__stack_chk_guard. However it used PTR_L resulting in a load of the
canary value, instead of PTR_LA to construct its address. The value is
intended to be random but is then treated as an address in the
subsequent LONG_S (store).

This was observed to cause a fault and panic:

CPU 0 Unable to handle kernel paging request at virtual address 139fea20, epc == 8000cc0c, ra == 8034f2a4
Oops[#1]:
...
$24   : 139fea20 1e1f7cb6
...
Call Trace:
[&lt;8000cc0c&gt;] resume+0xac/0x118
[&lt;8034f2a4&gt;] __schedule+0x5f8/0x78c
[&lt;8034f4e0&gt;] schedule_preempt_disabled+0x20/0x2c
[&lt;80348eec&gt;] rest_init+0x74/0x84
[&lt;804dc990&gt;] start_kernel+0x43c/0x454
Code: 3c18804b  8f184030  8cb901f8 &lt;af190000&gt; 00c0e021  8cb002f0 8cb102f4  8cb202f8  8cb302fc

This can also be forced by modifying
arch/mips/include/asm/stackprotector.h so that the default
__stack_chk_guard value is more likely to be a bad (or unaligned)
pointer.

Fix it to use PTR_LA instead, to load the address of the canary value,
which the LONG_S can then use to write into it.

Reported-by: bobjones (via #mipslinux on IRC)
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Gregory Fong &lt;gregory.0xf0@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/6026/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 1400eb6 (MIPS: r4k,octeon,r2300: stack protector: change canary
per task) was merged in v3.11 and introduced assembly in the MIPS resume
functions to update the value of the current canary in
__stack_chk_guard. However it used PTR_L resulting in a load of the
canary value, instead of PTR_LA to construct its address. The value is
intended to be random but is then treated as an address in the
subsequent LONG_S (store).

This was observed to cause a fault and panic:

CPU 0 Unable to handle kernel paging request at virtual address 139fea20, epc == 8000cc0c, ra == 8034f2a4
Oops[#1]:
...
$24   : 139fea20 1e1f7cb6
...
Call Trace:
[&lt;8000cc0c&gt;] resume+0xac/0x118
[&lt;8034f2a4&gt;] __schedule+0x5f8/0x78c
[&lt;8034f4e0&gt;] schedule_preempt_disabled+0x20/0x2c
[&lt;80348eec&gt;] rest_init+0x74/0x84
[&lt;804dc990&gt;] start_kernel+0x43c/0x454
Code: 3c18804b  8f184030  8cb901f8 &lt;af190000&gt; 00c0e021  8cb002f0 8cb102f4  8cb202f8  8cb302fc

This can also be forced by modifying
arch/mips/include/asm/stackprotector.h so that the default
__stack_chk_guard value is more likely to be a bad (or unaligned)
pointer.

Fix it to use PTR_LA instead, to load the address of the canary value,
which the LONG_S can then use to write into it.

Reported-by: bobjones (via #mipslinux on IRC)
Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Gregory Fong &lt;gregory.0xf0@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: stable@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/6026/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Disable usermode switching of the FR bit for MIPS R5 CPUs.</title>
<updated>2013-09-19T09:23:10+00:00</updated>
<author>
<name>Ralf Baechle</name>
<email>ralf@linux-mips.org</email>
</author>
<published>2013-09-19T09:15:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8b8a7634315be747959b0165e38138879f93cf6c'/>
<id>8b8a7634315be747959b0165e38138879f93cf6c</id>
<content type='text'>
Currently the kernel will always use the FR=0 register model for O32.  If
an O32 application did enable FR=1 mode, some data from another application
might be leaked in the extra registers becoming visible.

Iow, this patch is meant to make the kernel MIPS R5 tolerant but leaves
proper MIPS R5 support to a future patchset.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently the kernel will always use the FR=0 register model for O32.  If
an O32 application did enable FR=1 mode, some data from another application
might be leaked in the extra registers becoming visible.

Iow, this patch is meant to make the kernel MIPS R5 tolerant but leaves
proper MIPS R5 support to a future patchset.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Cleanup CP0 PRId and CP1 FPIR register access masks</title>
<updated>2013-09-18T18:25:19+00:00</updated>
<author>
<name>Maciej W. Rozycki</name>
<email>macro@linux-mips.org</email>
</author>
<published>2013-09-17T15:58:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8ff374b9c296b96484d5e63b45b22d0862ffee8f'/>
<id>8ff374b9c296b96484d5e63b45b22d0862ffee8f</id>
<content type='text'>
Replace hardcoded CP0 PRId and CP1 FPIR register access masks throughout.
The change does not touch places that use shifted or partial masks.

Signed-off-by: Maciej W. Rozycki &lt;macro@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5838/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Replace hardcoded CP0 PRId and CP1 FPIR register access masks throughout.
The change does not touch places that use shifted or partial masks.

Signed-off-by: Maciej W. Rozycki &lt;macro@linux-mips.org&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5838/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: Optimize current_cpu_type() for better code.</title>
<updated>2013-09-17T16:50:53+00:00</updated>
<author>
<name>Ralf Baechle</name>
<email>ralf@linux-mips.org</email>
</author>
<published>2013-09-17T08:25:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=69f24d1784b631b81a54eb57c49bf46536dd2382'/>
<id>69f24d1784b631b81a54eb57c49bf46536dd2382</id>
<content type='text'>
 o Move current_cpu_type() to a separate header file
 o #ifdefing on supported CPU types lets modern GCC know that certain
   code in callers may be discarded ideally turning current_cpu_type() into
   a function returning a constant.
 o Use current_cpu_type() rather than direct access to struct cpuinfo_mips.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Steven J. Hill &lt;Steven.Hill@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5833/
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
 o Move current_cpu_type() to a separate header file
 o #ifdefing on supported CPU types lets modern GCC know that certain
   code in callers may be discarded ideally turning current_cpu_type() into
   a function returning a constant.
 o Use current_cpu_type() rather than direct access to struct cpuinfo_mips.

Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Steven J. Hill &lt;Steven.Hill@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5833/
</pre>
</div>
</content>
</entry>
<entry>
<title>MIPS: kernel: vpe: Make vpe_attrs an array of pointers.</title>
<updated>2013-09-13T13:12:48+00:00</updated>
<author>
<name>Markos Chandras</name>
<email>markos.chandras@imgtec.com</email>
</author>
<published>2013-09-11T12:17:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=1b4676330aa6782bd73ec24cb4896467475f29f5'/>
<id>1b4676330aa6782bd73ec24cb4896467475f29f5</id>
<content type='text'>
Commit 567b21e973ccf5b0d13776e408d7c67099749eb8
"mips: convert vpe_class to use dev_groups"

broke the build on MIPS since vpe_attrs should be an array
of 'struct device_attribute' pointers.

Fixes the following build problem:
arch/mips/kernel/vpe.c:1372:2: error: missing braces around initializer
[-Werror=missing-braces]
arch/mips/kernel/vpe.c:1372:2: error: (near initialization for 'vpe_attrs[0]')
[-Werror=missing-braces]

Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: John Crispin &lt;blogic@openwrt.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5819/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Commit 567b21e973ccf5b0d13776e408d7c67099749eb8
"mips: convert vpe_class to use dev_groups"

broke the build on MIPS since vpe_attrs should be an array
of 'struct device_attribute' pointers.

Fixes the following build problem:
arch/mips/kernel/vpe.c:1372:2: error: missing braces around initializer
[-Werror=missing-braces]
arch/mips/kernel/vpe.c:1372:2: error: (near initialization for 'vpe_attrs[0]')
[-Werror=missing-braces]

Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: John Crispin &lt;blogic@openwrt.org&gt;
Cc: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/5819/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
