<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/arm/kernel, branch linux-3.12.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ARM: 8643/3: arm/ptrace: Preserve previous registers for short regset write</title>
<updated>2017-02-16T10:44:42+00:00</updated>
<author>
<name>Dave Martin</name>
<email>Dave.Martin@arm.com</email>
</author>
<published>2017-01-18T16:11:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2975e82135231373542b07241794809500e2f711'/>
<id>2975e82135231373542b07241794809500e2f711</id>
<content type='text'>
commit 228dbbfb5d77f8e047b2a1d78da14b7158433027 upstream.

Ensure that if userspace supplies insufficient data to
PTRACE_SETREGSET to fill all the registers, the thread's old
registers are preserved.

Fixes: 5be6f62b0059 ("ARM: 6883/1: ptrace: Migrate to regsets framework")
Signed-off-by: Dave Martin &lt;Dave.Martin@arm.com&gt;
Acked-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&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 228dbbfb5d77f8e047b2a1d78da14b7158433027 upstream.

Ensure that if userspace supplies insufficient data to
PTRACE_SETREGSET to fill all the registers, the thread's old
registers are preserved.

Fixes: 5be6f62b0059 ("ARM: 6883/1: ptrace: Migrate to regsets framework")
Signed-off-by: Dave Martin &lt;Dave.Martin@arm.com&gt;
Acked-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8634/1: hw_breakpoint: blacklist Scorpion CPUs</title>
<updated>2017-01-27T10:15:54+00:00</updated>
<author>
<name>Mark Rutland</name>
<email>mark.rutland@arm.com</email>
</author>
<published>2017-01-06T12:12:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b9ac597cf8a001ac4c81f583404a0dc67eb272c7'/>
<id>b9ac597cf8a001ac4c81f583404a0dc67eb272c7</id>
<content type='text'>
commit ddc37832a1349f474c4532de381498020ed71d31 upstream.

On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an
undefined instruction trap within write_wb_reg. This is because Scorpion
CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if
the core is not powered down. When DBGPRSR.SPD is set, breakpoint and
watchpoint registers are treated as undefined.

It's possible to trigger similar crashes later on from userspace, by
requesting the kernel to install a breakpoint or watchpoint, as we can
go idle at any point between the reset of the debug registers and their
later use. This has always been the case.

Given that this has always been broken, no-one has complained until now,
and there is no clear workaround, disable hardware breakpoints and
watchpoints on Scorpion to avoid these issues.

Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Reported-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&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 ddc37832a1349f474c4532de381498020ed71d31 upstream.

On APQ8060, the kernel crashes in arch_hw_breakpoint_init, taking an
undefined instruction trap within write_wb_reg. This is because Scorpion
CPUs erroneously appear to set DBGPRSR.SPD when WFI is issued, even if
the core is not powered down. When DBGPRSR.SPD is set, breakpoint and
watchpoint registers are treated as undefined.

It's possible to trigger similar crashes later on from userspace, by
requesting the kernel to install a breakpoint or watchpoint, as we can
go idle at any point between the reset of the debug registers and their
later use. This has always been the case.

Given that this has always been broken, no-one has complained until now,
and there is no clear workaround, disable hardware breakpoints and
watchpoints on Scorpion to avoid these issues.

Signed-off-by: Mark Rutland &lt;mark.rutland@arm.com&gt;
Reported-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Reviewed-by: Stephen Boyd &lt;sboyd@codeaurora.org&gt;
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8616/1: dt: Respect property size when parsing CPUs</title>
<updated>2016-10-07T08:03:58+00:00</updated>
<author>
<name>Robin Murphy</name>
<email>robin.murphy@arm.com</email>
</author>
<published>2016-09-26T15:50:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b9e0d1cebcac8aeba3fb8608db6e9ee772ed32a6'/>
<id>b9e0d1cebcac8aeba3fb8608db6e9ee772ed32a6</id>
<content type='text'>
commit ba6dea4f7cedb4b1c17e36f4087675d817c2e24b upstream.

Whilst MPIDR values themselves are less than 32 bits, it is still
perfectly valid for a DT to have #address-cells &gt; 1 in the CPUs node,
resulting in the "reg" property having leading zero cell(s). In that
situation, the big-endian nature of the data conspires with the current
behaviour of only reading the first cell to cause the kernel to think
all CPUs have ID 0, and become resoundingly unhappy as a consequence.

Take the full property length into account when parsing CPUs so as to
be correct under any circumstances.

Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Signed-off-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&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 ba6dea4f7cedb4b1c17e36f4087675d817c2e24b upstream.

Whilst MPIDR values themselves are less than 32 bits, it is still
perfectly valid for a DT to have #address-cells &gt; 1 in the CPUs node,
resulting in the "reg" property having leading zero cell(s). In that
situation, the big-endian nature of the data conspires with the current
behaviour of only reading the first cell to cause the kernel to think
all CPUs have ID 0, and become resoundingly unhappy as a consequence.

Take the full property length into account when parsing CPUs so as to
be correct under any circumstances.

Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Signed-off-by: Robin Murphy &lt;robin.murphy@arm.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>arm: oabi compat: add missing access checks</title>
<updated>2016-08-19T07:51:05+00:00</updated>
<author>
<name>Dave Weinstein</name>
<email>olorin@google.com</email>
</author>
<published>2016-07-28T18:55:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3d207c4c414adc515aa666f2b010f6e85c5528a7'/>
<id>3d207c4c414adc515aa666f2b010f6e85c5528a7</id>
<content type='text'>
commit 7de249964f5578e67b99699c5f0b405738d820a2 upstream.

Add access checks to sys_oabi_epoll_wait() and sys_oabi_semtimedop().
This fixes CVE-2016-3857, a local privilege escalation under
CONFIG_OABI_COMPAT.

Reported-by: Chiachih Wu &lt;wuchiachih@gmail.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Dave Weinstein &lt;olorin@google.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.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 7de249964f5578e67b99699c5f0b405738d820a2 upstream.

Add access checks to sys_oabi_epoll_wait() and sys_oabi_semtimedop().
This fixes CVE-2016-3857, a local privilege escalation under
CONFIG_OABI_COMPAT.

Reported-by: Chiachih Wu &lt;wuchiachih@gmail.com&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Reviewed-by: Nicolas Pitre &lt;nico@linaro.org&gt;
Signed-off-by: Dave Weinstein &lt;olorin@google.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: fix PTRACE_SETVFPREGS on SMP systems</title>
<updated>2016-07-12T09:27:48+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@armlinux.org.uk</email>
</author>
<published>2016-05-30T22:14:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9b22674cfa8eba02150abe8e4633da313462a6f9'/>
<id>9b22674cfa8eba02150abe8e4633da313462a6f9</id>
<content type='text'>
commit e2dfb4b880146bfd4b6aa8e138c0205407cebbaf upstream.

PTRACE_SETVFPREGS fails to properly mark the VFP register set to be
reloaded, because it undoes one of the effects of vfp_flush_hwstate().

Specifically vfp_flush_hwstate() sets thread-&gt;vfpstate.hard.cpu to
an invalid CPU number, but vfp_set() overwrites this with the original
CPU number, thereby rendering the hardware state as apparently "valid",
even though the software state is more recent.

Fix this by reverting the previous change.

Fixes: 8130b9d7b9d8 ("ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers")
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Tested-by: Simon Marchi &lt;simon.marchi@ericsson.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&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 e2dfb4b880146bfd4b6aa8e138c0205407cebbaf upstream.

PTRACE_SETVFPREGS fails to properly mark the VFP register set to be
reloaded, because it undoes one of the effects of vfp_flush_hwstate().

Specifically vfp_flush_hwstate() sets thread-&gt;vfpstate.hard.cpu to
an invalid CPU number, but vfp_set() overwrites this with the original
CPU number, thereby rendering the hardware state as apparently "valid",
even though the software state is more recent.

Fix this by reverting the previous change.

Fixes: 8130b9d7b9d8 ("ARM: 7308/1: vfp: flush thread hwstate before copying ptrace registers")
Acked-by: Will Deacon &lt;will.deacon@arm.com&gt;
Tested-by: Simon Marchi &lt;simon.marchi@ericsson.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@armlinux.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8160/1: drop warning about return_address not using unwind tables</title>
<updated>2016-01-27T08:56:36+00:00</updated>
<author>
<name>Uwe Kleine-König</name>
<email>u.kleine-koenig@pengutronix.de</email>
</author>
<published>2014-09-24T07:51:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c49a18300ffce812f40ef269c76ddfbcbd01e5db'/>
<id>c49a18300ffce812f40ef269c76ddfbcbd01e5db</id>
<content type='text'>
commit e16343c47e4276f5ebc77ca16feb5e50ca1918f9 upstream.

The warning was introduced in 2009 (commit 4bf1fa5a34aa ([ARM] 5613/1:
implement CALLER_ADDRESSx)). The only "problem" here is that
CALLER_ADDRESSx for x &gt; 1 returns NULL which doesn't do much harm.

The drawback of implementing a fix (i.e. use unwind tables to implement CALLER_ADDRESSx) is that much of the unwinder code would need to be marked as not
traceable.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&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 e16343c47e4276f5ebc77ca16feb5e50ca1918f9 upstream.

The warning was introduced in 2009 (commit 4bf1fa5a34aa ([ARM] 5613/1:
implement CALLER_ADDRESSx)). The only "problem" here is that
CALLER_ADDRESSx for x &gt; 1 returns NULL which doesn't do much harm.

The drawback of implementing a fix (i.e. use unwind tables to implement CALLER_ADDRESSx) is that much of the unwinder code would need to be marked as not
traceable.

Signed-off-by: Uwe Kleine-König &lt;u.kleine-koenig@pengutronix.de&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 8158/1: LLVMLinux: use static inline in ARM ftrace.h</title>
<updated>2016-01-27T08:56:35+00:00</updated>
<author>
<name>Behan Webster</name>
<email>behanw@converseincode.com</email>
</author>
<published>2014-09-24T00:06:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=94738c4f7c1cfefee481a3d3e5c8f78de2c9fd41'/>
<id>94738c4f7c1cfefee481a3d3e5c8f78de2c9fd41</id>
<content type='text'>
commit aeea3592a13bf12861943e44fc48f1f270941f8d upstream.

With compilers which follow the C99 standard (like modern versions of gcc and
clang), "extern inline" does the wrong thing (emits code for an externally
linkable version of the inline function). In this case using static inline
and removing the NULL version of return_address in return_address.c does
the right thing.

Signed-off-by: Behan Webster &lt;behanw@converseincode.com&gt;
Reviewed-by: Mark Charlebois &lt;charlebm@gmail.com&gt;
Acked-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&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 aeea3592a13bf12861943e44fc48f1f270941f8d upstream.

With compilers which follow the C99 standard (like modern versions of gcc and
clang), "extern inline" does the wrong thing (emits code for an externally
linkable version of the inline function). In this case using static inline
and removing the NULL version of return_address in return_address.c does
the right thing.

Signed-off-by: Behan Webster &lt;behanw@converseincode.com&gt;
Reviewed-by: Mark Charlebois &lt;charlebm@gmail.com&gt;
Acked-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: fix Thumb2 signal handling when ARMv6 is enabled</title>
<updated>2015-10-27T09:18:22+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2015-09-11T15:44:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=a2f70b57b05c9a8cd6a68e05372682f951d058f0'/>
<id>a2f70b57b05c9a8cd6a68e05372682f951d058f0</id>
<content type='text'>
commit 9b55613f42e8d40d5c9ccb8970bde6af4764b2ab upstream.

When a kernel is built covering ARMv6 to ARMv7, we omit to clear the
IT state when entering a signal handler.  This can cause the first
few instructions to be conditionally executed depending on the parent
context.

In any case, the original test for &gt;= ARMv7 is broken - ARMv6 can have
Thumb-2 support as well, and an ARMv6T2 specific build would omit this
code too.

Relax the test back to ARMv6 or greater.  This results in us always
clearing the IT state bits in the PSR, even on CPUs where these bits
are reserved.  However, they're reserved for the IT state, so this
should cause no harm.

Fixes: d71e1352e240 ("Clear the IT state when invoking a Thumb-2 signal handler")
Acked-by: Tony Lindgren &lt;tony@atomide.com&gt;
Tested-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Tested-by: Grazvydas Ignotas &lt;notasas@gmail.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&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 9b55613f42e8d40d5c9ccb8970bde6af4764b2ab upstream.

When a kernel is built covering ARMv6 to ARMv7, we omit to clear the
IT state when entering a signal handler.  This can cause the first
few instructions to be conditionally executed depending on the parent
context.

In any case, the original test for &gt;= ARMv7 is broken - ARMv6 can have
Thumb-2 support as well, and an ARMv6T2 specific build would omit this
code too.

Relax the test back to ARMv6 or greater.  This results in us always
clearing the IT state bits in the PSR, even on CPUs where these bits
are reserved.  However, they're reserved for the IT state, so this
should cause no harm.

Fixes: d71e1352e240 ("Clear the IT state when invoking a Thumb-2 signal handler")
Acked-by: Tony Lindgren &lt;tony@atomide.com&gt;
Tested-by: H. Nikolaus Schaller &lt;hns@goldelico.com&gt;
Tested-by: Grazvydas Ignotas &lt;notasas@gmail.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: 7880/1: Clear the IT state independent of the Thumb-2 mode</title>
<updated>2015-10-22T08:07:04+00:00</updated>
<author>
<name>T.J. Purtell</name>
<email>tj@mobisocial.us</email>
</author>
<published>2013-11-06T17:38:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0072abfc723f192261b5817f1f058bfc46796d19'/>
<id>0072abfc723f192261b5817f1f058bfc46796d19</id>
<content type='text'>
commit 6ecf830e5029598732e04067e325d946097519cb upstream.

The ARM architecture reference specifies that the IT state bits in the
PSR must be all zeros in ARM mode or behavior is unspecified.  On the
Qualcomm Snapdragon S4/Krait architecture CPUs the processor continues
to consider the IT state bits while in ARM mode.  This makes it so
that some instructions are skipped by the CPU.

Signed-off-by: T.J. Purtell &lt;tj@mobisocial.us&gt;
[rmk+kernel@arm.linux.org.uk: fixed whitespace formatting in patch]
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&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 6ecf830e5029598732e04067e325d946097519cb upstream.

The ARM architecture reference specifies that the IT state bits in the
PSR must be all zeros in ARM mode or behavior is unspecified.  On the
Qualcomm Snapdragon S4/Krait architecture CPUs the processor continues
to consider the IT state bits while in ARM mode.  This makes it so
that some instructions are skipped by the CPU.

Signed-off-by: T.J. Purtell &lt;tj@mobisocial.us&gt;
[rmk+kernel@arm.linux.org.uk: fixed whitespace formatting in patch]
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;

Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: fix missing syscall trace exit</title>
<updated>2015-06-02T15:01:14+00:00</updated>
<author>
<name>Russell King</name>
<email>rmk+kernel@arm.linux.org.uk</email>
</author>
<published>2015-05-15T10:02:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=bd7044dfd8a3bcfd386d2cd7f0c01ba884a2cc88'/>
<id>bd7044dfd8a3bcfd386d2cd7f0c01ba884a2cc88</id>
<content type='text'>
commit 1b97937246d8b97c0760d16d8992c7937bdf5e6a upstream.

Josh Stone reports:

  I've discovered a case where both arm and arm64 will miss a ptrace
  syscall-exit that they should report.  If the syscall is entered
  without TIF_SYSCALL_TRACE set, then it goes on the fast path.  It's
  then possible to have TIF_SYSCALL_TRACE added in the middle of the
  syscall, but ret_fast_syscall doesn't check this flag again.

Fix this by always checking for a syscall trace in the fast exit path.

Reported-by: Josh Stone &lt;jistone@redhat.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&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 1b97937246d8b97c0760d16d8992c7937bdf5e6a upstream.

Josh Stone reports:

  I've discovered a case where both arm and arm64 will miss a ptrace
  syscall-exit that they should report.  If the syscall is entered
  without TIF_SYSCALL_TRACE set, then it goes on the fast path.  It's
  then possible to have TIF_SYSCALL_TRACE added in the middle of the
  syscall, but ret_fast_syscall doesn't check this flag again.

Fix this by always checking for a syscall trace in the fast exit path.

Reported-by: Josh Stone &lt;jistone@redhat.com&gt;
Signed-off-by: Russell King &lt;rmk+kernel@arm.linux.org.uk&gt;
Signed-off-by: Jiri Slaby &lt;jslaby@suse.cz&gt;
</pre>
</div>
</content>
</entry>
</feed>
