<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/arch/mips, branch v3.14.4</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/arch/mips?h=v3.14.4</id>
<link rel='self' href='https://git.amat.us/linux/atom/arch/mips?h=v3.14.4'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2014-05-13T11:32:48Z</updated>
<entry>
<title>MIPS: Hibernate: Flush TLB entries in swsusp_arch_resume()</title>
<updated>2014-05-13T11:32:48Z</updated>
<author>
<name>Huacai Chen</name>
<email>chenhc@lemote.com</email>
</author>
<published>2014-03-22T09:21:44Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=771004298d9a73ff1bca0b4ff5168c74d3ff7af0'/>
<id>urn:sha1:771004298d9a73ff1bca0b4ff5168c74d3ff7af0</id>
<content type='text'>
commit c14af233fbe279d0e561ecf84f1208b1bae087ef upstream.

The original MIPS hibernate code flushes cache and TLB entries in
swsusp_arch_resume(). But they are removed in Commit 44eeab67416711
(MIPS: Hibernation: Remove SMP TLB and cacheflushing code.). A cross-
CPU flush is surely unnecessary because all but the local CPU have
already been disabled. But a local flush (at least the TLB flush) is
needed. When we do hibernation on Loongson-3 with an E1000E NIC, it is
very easy to produce a kernel panic (kernel page fault, or unaligned
access). The root cause is E1000E driver use vzalloc_node() to allocate
pages, the stale TLB entries of the booting kernel will be misused by
the resumed target kernel.

Signed-off-by: Huacai Chen &lt;chenhc@lemote.com&gt;
Cc: John Crispin &lt;john@phrozen.org&gt;
Cc: Steven J. Hill &lt;Steven.Hill@imgtec.com&gt;
Cc: Aurelien Jarno &lt;aurelien@aurel32.net&gt;
Cc: linux-mips@linux-mips.org
Cc: Fuxin Zhang &lt;zhangfx@lemote.com&gt;
Cc: Zhangjin Wu &lt;wuzhangjin@gmail.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/6643/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>MIPS: KVM: Pass reserved instruction exceptions to guest</title>
<updated>2014-05-13T11:32:48Z</updated>
<author>
<name>James Hogan</name>
<email>james.hogan@imgtec.com</email>
</author>
<published>2014-03-14T13:06:07Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2981534733f5deaa4ed86bc7f91f3bd18152abe0'/>
<id>urn:sha1:2981534733f5deaa4ed86bc7f91f3bd18152abe0</id>
<content type='text'>
commit 15505679362270d02c449626385cb74af8905514 upstream.

Previously a reserved instruction exception while in guest code would
cause a KVM internal error if kvm_mips_handle_ri() didn't recognise the
instruction (including a RDHWR from an unrecognised hardware register).

However the guest OS should really have the opportunity to catch the
exception so that it can take the appropriate actions such as sending a
SIGILL to the guest user process or emulating the instruction itself.

Therefore in these cases emulate a guest RI exception and only return
EMULATE_FAIL if that fails, being careful to revert the PC first in case
the exception occurred in a branch delay slot in which case the PC will
already point to the branch target.

Also turn the printk messages relating to these cases into kvm_debug
messages so that they aren't usually visible.

This allows crashme to run in the guest without killing the entire VM.

Signed-off-by: James Hogan &lt;james.hogan@imgtec.com&gt;
Cc: Ralf Baechle &lt;ralf@linux-mips.org&gt;
Cc: Gleb Natapov &lt;gleb@kernel.org&gt;
Cc: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Cc: Sanjay Lal &lt;sanjayl@kymasys.com&gt;
Cc: linux-mips@linux-mips.org
Cc: kvm@vger.kernel.org
Signed-off-by: Paolo Bonzini &lt;pbonzini@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>MIPS: Make local_irq_disable macro safe for non-Mipsr2</title>
<updated>2014-03-20T12:46:15Z</updated>
<author>
<name>Jim Quinlan</name>
<email>jim2101024@gmail.com</email>
</author>
<published>2013-11-27T20:34:50Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=71ca75888953166b72cf7a65b4c2b6a50fc0ce3b'/>
<id>urn:sha1:71ca75888953166b72cf7a65b4c2b6a50fc0ce3b</id>
<content type='text'>
For non-mipsr2 processors, the local_irq_disable contains an mfc0-mtc0
pair with instructions inbetween.  With preemption enabled, this sequence
may get preempted and effect a stale value of CP0_STATUS when executing
the mtc0 instruction.  This commit avoids this scenario by incrementing
the preempt count before the mfc0 and decrementing it after the mtc9.

[ralf@linux-mips.org: This patch is sorting out the part that were missed
by e97c5b6098 [MIPS: Make irqflags.h functions preempt-safe for non-mipsr2
cpus.]  I also re-enabled the inclusion of &lt;asm/asm-offsets.h&gt; at the top
of &lt;asm/asmmacro.h&gt;].

Signed-off-by: Jim Quinlan &lt;jim2101024@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: cernekee@gmail.com
Patchwork: https://patchwork.linux-mips.org/patch/6164/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Octeon: Fix warning in of_device_alloc on cn3xxx</title>
<updated>2014-03-19T22:50:30Z</updated>
<author>
<name>Andreas Herrmann</name>
<email>andreas.herrmann@caviumnetworks.com</email>
</author>
<published>2014-03-19T22:03:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2eddb708d83ead02b5d41c65bfb26bab5afc8210'/>
<id>urn:sha1:2eddb708d83ead02b5d41c65bfb26bab5afc8210</id>
<content type='text'>
Starting with commit 3da5278727a895d49a601f67fd49dffa0b80f9a5 (of/irq:
Rework of_irq_count()) the following warning is triggered on octeon
cn3xxx:

[    0.887281] WARNING: CPU: 0 PID: 1 at drivers/of/platform.c:171 of_device_alloc+0x228/0x230()
[    0.895642] Modules linked in:
[    0.898689] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-rc7-00012-g9ae51f2-dirty #41
[    0.906860] Stack : c8b439581166d96e ffffffff816b0000 0000000040808000 ffffffff81185ddc
[    0.906860] 	  0000000000000000 0000000000000000 0000000000000000 000000000000000b
[    0.906860] 	  000000000000000a 000000000000000a 0000000000000000 0000000000000000
[    0.906860] 	  ffffffff81740000 ffffffff81720000 ffffffff81615900 ffffffff816b0177
[    0.906860] 	  ffffffff81727d10 800000041f868fb0 0000000000000001 0000000000000000
[    0.906860] 	  0000000000000000 0000000000000038 0000000000000001 ffffffff81568484
[    0.906860] 	  800000041f86faa8 ffffffff81145ddc 0000000000000000 ffffffff811873f4
[    0.906860] 	  800000041f868b88 800000041f86f9c0 0000000000000000 ffffffff81569c9c
[    0.906860] 	  0000000000000000 0000000000000000 0000000000000000 0000000000000000
[    0.906860] 	  0000000000000000 ffffffff811205e0 0000000000000000 0000000000000000
[    0.906860] 	  ...
[    0.971695] Call Trace:
[    0.974139] [&lt;ffffffff811205e0&gt;] show_stack+0x68/0x80
[    0.979183] [&lt;ffffffff81569c9c&gt;] dump_stack+0x8c/0xe0
[    0.984196] [&lt;ffffffff81145efc&gt;] warn_slowpath_common+0x84/0xb8
[    0.990110] [&lt;ffffffff81436888&gt;] of_device_alloc+0x228/0x230
[    0.995726] [&lt;ffffffff814368d8&gt;] of_platform_device_create_pdata+0x48/0xd0
[    1.002593] [&lt;ffffffff81436a94&gt;] of_platform_bus_create+0x134/0x1e8
[    1.008837] [&lt;ffffffff81436af8&gt;] of_platform_bus_create+0x198/0x1e8
[    1.015064] [&lt;ffffffff81436cc4&gt;] of_platform_bus_probe+0xa4/0x100
[    1.021149] [&lt;ffffffff81100570&gt;] do_one_initcall+0xd8/0x128
[    1.026701] [&lt;ffffffff816e2a10&gt;] kernel_init_freeable+0x144/0x210
[    1.032753] [&lt;ffffffff81564bc4&gt;] kernel_init+0x14/0x110
[    1.037973] [&lt;ffffffff8111bb44&gt;] ret_from_kernel_thread+0x14/0x1c

With this commit the kernel starts mapping the interrupts listed for
gpio-controller node. irq_domain_ops for CIU (octeon_irq_ciu_map and
octeon_irq_ciu_xlat) refuse to handle the GPIO lines (returning -EINVAL)
and this is causing above warning in of_device_alloc().

Modify irq_domain_ops for CIU and CIU2 to "gracefully handle" GPIO
lines (neither return error code nor call octeon_irq_set_ciu_mapping
for it). This should avoid the warning.

(As before the real setup for GPIO lines will happen using
irq_domain_ops of gpio-controller.)

This patch is based on Wei's patch v2 (see
http://marc.info/?l=linux-mips&amp;m=139511814813247).

Signed-off-by: Andreas Herrmann &lt;andreas.herrmann@caviumnetworks.com&gt;
Reported-by: Yang Wei &lt;wei.yang@windriver.com&gt;
Acked-by: David Daney &lt;david.daney@cavium.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6624/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>MIPS: ftrace: Tweak safe_load()/safe_store() macros</title>
<updated>2014-03-19T22:18:40Z</updated>
<author>
<name>Viller Hsiao</name>
<email>villerhsiao@gmail.com</email>
</author>
<published>2014-03-18T07:39:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b08ac66b4026f0151d712903695bf266042fbe2c'/>
<id>urn:sha1:b08ac66b4026f0151d712903695bf266042fbe2c</id>
<content type='text'>
Due to name collision in ftrace safe_load and safe_store macros,
these macros cannot take expressions as operands.

For example, compiler will complain for a macro call like the following:
  safe_store_code(new_code2, ip + 4, faulted);

  arch/mips/include/asm/ftrace.h:61:6: note: in definition of macro 'safe_store'
     : [dst] "r" (dst), [src] "r" (src)\
        ^
  arch/mips/kernel/ftrace.c:118:2: note: in expansion of macro 'safe_store_code'
    safe_store_code(new_code2, ip + 4, faulted);
    ^
  arch/mips/kernel/ftrace.c:118:32: error: undefined named operand 'ip + 4'
    safe_store_code(new_code2, ip + 4, faulted);
                                  ^
  arch/mips/include/asm/ftrace.h:61:6: note: in definition of macro 'safe_store'
     : [dst] "r" (dst), [src] "r" (src)\
        ^
  arch/mips/kernel/ftrace.c:118:2: note: in expansion of macro 'safe_store_code'
    safe_store_code(new_code2, ip + 4, faulted);
    ^

This build error is triggered by a4671094 [MIPS: ftrace: Fix icache flush
range error].  Tweak variable naming in those macros to allow flexible
operands.

Signed-off-by: Viller Hsiao &lt;villerhsiao@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: rostedt@goodmis.org
Cc: fweisbec@gmail.com
Cc: mingo@redhat.com
Cc: Qais.Yousef@imgtec.com
Patchwork: https://patchwork.linux-mips.org/patch/6622/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>MIPS: BCM47XX: Check all (32) GPIOs when looking for a pin</title>
<updated>2014-03-19T08:28:10Z</updated>
<author>
<name>Rafał Miłecki</name>
<email>zajec5@gmail.com</email>
</author>
<published>2014-02-13T16:48:12Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4fe2169acecb6e62821dfe14bc5c5852870b516f'/>
<id>urn:sha1:4fe2169acecb6e62821dfe14bc5c5852870b516f</id>
<content type='text'>
Broadcom boards support 32 GPIOs and NVRAM may have entires for higher
ones too. Example:
gpio23=wombo_reset

Signed-off-by: Rafa? Mi?ecki &lt;zajec5@gmail.com&gt;
Acked-by: Hauke Mehrtens &lt;hauke@hauke-m.de&gt;
Cc: linux-mips@linux-mips.org
Cc: Rafał Miłecki &lt;zajec5@gmail.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/6547/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Fix possible build error with transparent hugepages enabled</title>
<updated>2014-03-18T07:18:11Z</updated>
<author>
<name>Alex Smith</name>
<email>alex.smith@imgtec.com</email>
</author>
<published>2014-01-21T11:22:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=e4362d1e64ff6da64118dcf74ff450cd0a029deb'/>
<id>urn:sha1:e4362d1e64ff6da64118dcf74ff450cd0a029deb</id>
<content type='text'>
If CONFIG_TRANSPARENT_HUGEPAGE is enabled, but CONFIG_HUGETLB_PAGE is not,
it is possible to end up with a configuration that fails to build with the
following error:

include/linux/huge_mm.h:125:2: error: #error "hugepages can't be allocated by the buddy allocator"

This is due to CONFIG_FORCE_MAX_ZONEORDER defaulting to 11. It already has
ranges that change the valid values when HUGETLB_PAGE is enabled, but this
is not done for TRANSPARENT_HUGEPAGE. Fix by changing the HUGETLB_PAGE
dependencies to MIPS_HUGE_TLB_SUPPORT, which includes both
TRANSPARENT_HUGEPAGE and HUGETLB_PAGE.

Signed-off-by: Alex Smith &lt;alex.smith@imgtec.com&gt;
Reviewed-by: Markos Chandras &lt;markos.chandras@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6391/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>MIPS: mark O32+FP64 experimental for now</title>
<updated>2014-03-17T15:06:12Z</updated>
<author>
<name>Paul Burton</name>
<email>paul.burton@imgtec.com</email>
</author>
<published>2014-02-14T17:55:18Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=06e2e88292e9ea6f5a23ead2e9c5ccf8bbd99e93'/>
<id>urn:sha1:06e2e88292e9ea6f5a23ead2e9c5ccf8bbd99e93</id>
<content type='text'>
Commit 597ce1723e0f "MIPS: Support for 64-bit FP with O32 binaries"
introduced support for setting Status.FR=1 for O32 binaries with the
EF_MIPS_FP64 ELF header flag set. Whilst this flag is currently
supported by binutils it does introduce an ABI break within userland.
Objects built with EF_MIPS_FP64 cannot be safely linked with those built
without it since code in either object may assume behaviour specific to
a value of FR.

More recently there has been discussion around avoiding further
fragmentation of the O32 ABI whilst still allowing the use of FR=1 and
features such as MSA which depend upon it. Details of the plan to allow
this are still being worked on, and whilst the kernel will need the
ability to handle FR=1 with O32 tasks it is unclear what else it may
need to provide to a userland which seeks to avoid another ABI break. In
order to prevent the proliferation of userland which may rely upon the
current EF_MIPS_FP64 behaviour this patch marks the kernel support for
it experimental &amp; disables it by default. Under current proposals it is
likely that this support can simply be enabled again later, but possibly
after the introduction of further interfaces with userland and support
for the MIPS R5 UFR feature.

Signed-off-by: Paul Burton &lt;paul.burton@imgtec.com&gt;
Cc: Matthew Fortune &lt;matthew.fortune@imgtec.com&gt;
Cc: linux-mips@linux-mips.org
Cc: Paul Burton &lt;paul.burton@imgtec.com&gt;
Patchwork: https://patchwork.linux-mips.org/patch/6549/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>MIPS: ftrace: Fix icache flush range error</title>
<updated>2014-03-17T14:42:07Z</updated>
<author>
<name>Viller Hsiao</name>
<email>villerhsiao@gmail.com</email>
</author>
<published>2014-02-22T07:46:49Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a4671094227d11985c06ee1178d7205c5fd39f8a'/>
<id>urn:sha1:a4671094227d11985c06ee1178d7205c5fd39f8a</id>
<content type='text'>
In 32-bit mode, the start address passed to flush_icache_range is
shifted by 4 bytes before the second safe_store_code() call.

This causes system crash from time to time because the first 4 bytes
might not be flushed properly. This bug exists since linux-3.8.

Also remove obsoleted comment while at it.

Signed-off-by: Viller Hsiao &lt;villerhsiao@gmail.com&gt;
Cc: linux-mips@linux-mips.org
Cc: rostedt@goodmis.org
Cc: fweisbec@gmail.com
Cc: mingo@redhat.com
Cc: Qais.Yousef@imgtec.com
Patchwork: https://patchwork.linux-mips.org/patch/6586/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
<entry>
<title>MIPS: Fix syscall tracing interface</title>
<updated>2014-03-17T14:38:38Z</updated>
<author>
<name>Lars Persson</name>
<email>lars.persson@axis.com</email>
</author>
<published>2014-03-17T11:14:13Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=86ca57b5a5525dbf89fc2a3285781fae807276b0'/>
<id>urn:sha1:86ca57b5a5525dbf89fc2a3285781fae807276b0</id>
<content type='text'>
Fix pointer computation for stack-based arguments.

Signed-off-by: Lars Persson &lt;larper@axis.com&gt;
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/6620/
Signed-off-by: Ralf Baechle &lt;ralf@linux-mips.org&gt;
</content>
</entry>
</feed>
