<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/arm, branch v3.8.7</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>ARM: EXYNOS: Fix crash on soft reset on EXYNOS5440</title>
<updated>2013-04-12T16:52:11+00:00</updated>
<author>
<name>Thomas Abraham</name>
<email>thomas.ab@samsung.com</email>
</author>
<published>2013-01-24T18:09:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3d574eb51f512fd6c7883f6b30677ea405851a5a'/>
<id>3d574eb51f512fd6c7883f6b30677ea405851a5a</id>
<content type='text'>
commit 60db7e5f9c9a25a7a9b01007e6e3f5a93bc16a3a upstream.

The soft-reset control register is located in the XMU controller space.
Map this controller space before writing to the soft-reset controller
register.

Signed-off-by: Thomas Abraham &lt;thomas.ab@samsung.com&gt;
Signed-off-by: Girish K S &lt;ks.giri@samsung.com&gt;
Signed-off-by: Kukjin &lt;kgene.kim@samsung.com&gt;
Signed-off-by: Jonghwan Choi &lt;jhbird.choi@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

The soft-reset control register is located in the XMU controller space.
Map this controller space before writing to the soft-reset controller
register.

Signed-off-by: Thomas Abraham &lt;thomas.ab@samsung.com&gt;
Signed-off-by: Girish K S &lt;ks.giri@samsung.com&gt;
Signed-off-by: Kukjin &lt;kgene.kim@samsung.com&gt;
Signed-off-by: Jonghwan Choi &lt;jhbird.choi@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: OMAP: clocks: Delay clk inits atleast until slab is initialized</title>
<updated>2013-04-05T16:26:15+00:00</updated>
<author>
<name>Rajendra Nayak</name>
<email>rnayak@ti.com</email>
</author>
<published>2013-03-21T11:04:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=db38da8af5b82709188a57de11c8a3f19804dae9'/>
<id>db38da8af5b82709188a57de11c8a3f19804dae9</id>
<content type='text'>
commit ff931c821bab6713a52b768b0cd7ee7e90713b36 upstream.

clk inits on OMAP happen quite early, even before slab is available.
The dependency comes from the fact that the timer init code starts to
use clocks and hwmod and we need clocks to be initialized by then.

There are various problems doing clk inits this early, one is,
not being able to do dynamic clk registrations and hence the
dependency on clk-private.h. The other is, inability to debug
early kernel crashes without enabling DEBUG_LL and earlyprintk.

Doing early clk init also exposed another instance of a kernel
panic due to a BUG() when CONFIG_DEBUG_SLAB is enabled.

[    0.000000] Kernel BUG at c01174f8 [verbose debug info unavailable]
[    0.000000] Internal error: Oops - BUG: 0 [#1] SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0    Not tainted  (3.9.0-rc1-12179-g72d48f9 #6)
[    0.000000] PC is at __kmalloc+0x1d4/0x248
[    0.000000] LR is at __clk_init+0x2e0/0x364
[    0.000000] pc : [&lt;c01174f8&gt;]    lr : [&lt;c0441f54&gt;]    psr: 600001d3
[    0.000000] sp : c076ff28  ip : c065cefc  fp : c0441f54
[    0.000000] r10: 0000001c  r9 : 000080d0  r8 : c076ffd4
[    0.000000] r7 : c074b578  r6 : c0794d88  r5 : 00000040  r4 : 00000000
[    0.000000] r3 : 00000000  r2 : c07cac70  r1 : 000080d0  r0 : 0000001c
[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
[    0.000000] Control: 10c53c7d  Table: 8000404a  DAC: 00000017
[    0.000000] Process swapper (pid: 0, stack limit = 0xc076e240)
[    0.000000] Stack: (0xc076ff28 to 0xc0770000)
[    0.000000] ff20:                   22222222 c0794ec8 c06546e8 00000000 00000040 c0794d88
[    0.000000] ff40: c074b578 c076ffd4 c07951c8 c076e000 00000000 c0441f54 c074b578 c076ffd4
[    0.000000] ff60: c0793828 00000040 c0794d88 c074b578 c076ffd4 c0776900 c076e000 c07272ac
[    0.000000] ff80: 2f800000 c074c968 c07f93d0 c0719780 c076ffa0 c076ff98 00000000 00000000
[    0.000000] ffa0: 00000000 00000000 00000000 00000001 c074cd6c c077b1ec 8000406a c0715724
[    0.000000] ffc0: 00000000 00000000 00000000 00000000 00000000 c074c968 10c53c7d c0776974
[    0.000000] ffe0: c074cd6c c077b1ec 8000406a 411fc092 00000000 80008074 00000000 00000000
[    0.000000] [&lt;c01174f8&gt;] (__kmalloc+0x1d4/0x248) from [&lt;c0441f54&gt;] (__clk_init+0x2e0/0x364)
[    0.000000] [&lt;c0441f54&gt;] (__clk_init+0x2e0/0x364) from [&lt;c07272ac&gt;] (omap4xxx_clk_init+0xbc/0x140)
[    0.000000] [&lt;c07272ac&gt;] (omap4xxx_clk_init+0xbc/0x140) from [&lt;c0719780&gt;] (setup_arch+0x15c/0x284)
[    0.000000] [&lt;c0719780&gt;] (setup_arch+0x15c/0x284) from [&lt;c0715724&gt;] (start_kernel+0x7c/0x334)
[    0.000000] [&lt;c0715724&gt;] (start_kernel+0x7c/0x334) from [&lt;80008074&gt;] (0x80008074)
[    0.000000] Code: e5883004 e1a00006 e28dd00c e8bd8ff0 (e7f001f2)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!

It was a know issue, that slab allocations would fail when common
clock core tries to cache parent pointers for mux clocks on OMAP,
and hence a patch 'clk: Allow late cache allocation for clk-&gt;parents,
commit 7975059d' was added to work this problem around.
A BUG() within kmalloc() with CONFIG_DEBUG_SLAB enabled was completely
overlooked causing this regression.

More details on the issue reported can be found here,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html

With all these issues around clk inits happening way too early, it
makes sense to at least move them to a point where dynamic memory
allocations are possible. So move them to a point just before the
timer code starts using clocks and hwmod.

This should at least pave way for clk inits on OMAP moving to dynamic
clock registrations instead of using the static macros defined in
clk-private.h.

The issue with kernel panic while CONFIG_DEBUG_SLAB is enabled
was reported by Piotr Haber and Tony Lindgren and this patch
fixes the reported issue as well.

Reported-by: Piotr Haber &lt;phaber@broadcom.com&gt;
Reported-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Rajendra Nayak &lt;rnayak@ti.com&gt;
Acked-by: Santosh Shilimkar &lt;santosh.shilimkar@ti.com&gt;
Reviewed-by: Mike Turquette &lt;mturquette@linaro.org&gt;
Acked-by: Paul Walmsley &lt;paul@pwsan.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

clk inits on OMAP happen quite early, even before slab is available.
The dependency comes from the fact that the timer init code starts to
use clocks and hwmod and we need clocks to be initialized by then.

There are various problems doing clk inits this early, one is,
not being able to do dynamic clk registrations and hence the
dependency on clk-private.h. The other is, inability to debug
early kernel crashes without enabling DEBUG_LL and earlyprintk.

Doing early clk init also exposed another instance of a kernel
panic due to a BUG() when CONFIG_DEBUG_SLAB is enabled.

[    0.000000] Kernel BUG at c01174f8 [verbose debug info unavailable]
[    0.000000] Internal error: Oops - BUG: 0 [#1] SMP ARM
[    0.000000] Modules linked in:
[    0.000000] CPU: 0    Not tainted  (3.9.0-rc1-12179-g72d48f9 #6)
[    0.000000] PC is at __kmalloc+0x1d4/0x248
[    0.000000] LR is at __clk_init+0x2e0/0x364
[    0.000000] pc : [&lt;c01174f8&gt;]    lr : [&lt;c0441f54&gt;]    psr: 600001d3
[    0.000000] sp : c076ff28  ip : c065cefc  fp : c0441f54
[    0.000000] r10: 0000001c  r9 : 000080d0  r8 : c076ffd4
[    0.000000] r7 : c074b578  r6 : c0794d88  r5 : 00000040  r4 : 00000000
[    0.000000] r3 : 00000000  r2 : c07cac70  r1 : 000080d0  r0 : 0000001c
[    0.000000] Flags: nZCv  IRQs off  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
[    0.000000] Control: 10c53c7d  Table: 8000404a  DAC: 00000017
[    0.000000] Process swapper (pid: 0, stack limit = 0xc076e240)
[    0.000000] Stack: (0xc076ff28 to 0xc0770000)
[    0.000000] ff20:                   22222222 c0794ec8 c06546e8 00000000 00000040 c0794d88
[    0.000000] ff40: c074b578 c076ffd4 c07951c8 c076e000 00000000 c0441f54 c074b578 c076ffd4
[    0.000000] ff60: c0793828 00000040 c0794d88 c074b578 c076ffd4 c0776900 c076e000 c07272ac
[    0.000000] ff80: 2f800000 c074c968 c07f93d0 c0719780 c076ffa0 c076ff98 00000000 00000000
[    0.000000] ffa0: 00000000 00000000 00000000 00000001 c074cd6c c077b1ec 8000406a c0715724
[    0.000000] ffc0: 00000000 00000000 00000000 00000000 00000000 c074c968 10c53c7d c0776974
[    0.000000] ffe0: c074cd6c c077b1ec 8000406a 411fc092 00000000 80008074 00000000 00000000
[    0.000000] [&lt;c01174f8&gt;] (__kmalloc+0x1d4/0x248) from [&lt;c0441f54&gt;] (__clk_init+0x2e0/0x364)
[    0.000000] [&lt;c0441f54&gt;] (__clk_init+0x2e0/0x364) from [&lt;c07272ac&gt;] (omap4xxx_clk_init+0xbc/0x140)
[    0.000000] [&lt;c07272ac&gt;] (omap4xxx_clk_init+0xbc/0x140) from [&lt;c0719780&gt;] (setup_arch+0x15c/0x284)
[    0.000000] [&lt;c0719780&gt;] (setup_arch+0x15c/0x284) from [&lt;c0715724&gt;] (start_kernel+0x7c/0x334)
[    0.000000] [&lt;c0715724&gt;] (start_kernel+0x7c/0x334) from [&lt;80008074&gt;] (0x80008074)
[    0.000000] Code: e5883004 e1a00006 e28dd00c e8bd8ff0 (e7f001f2)
[    0.000000] ---[ end trace 1b75b31a2719ed1c ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!

It was a know issue, that slab allocations would fail when common
clock core tries to cache parent pointers for mux clocks on OMAP,
and hence a patch 'clk: Allow late cache allocation for clk-&gt;parents,
commit 7975059d' was added to work this problem around.
A BUG() within kmalloc() with CONFIG_DEBUG_SLAB enabled was completely
overlooked causing this regression.

More details on the issue reported can be found here,
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg85932.html

With all these issues around clk inits happening way too early, it
makes sense to at least move them to a point where dynamic memory
allocations are possible. So move them to a point just before the
timer code starts using clocks and hwmod.

This should at least pave way for clk inits on OMAP moving to dynamic
clock registrations instead of using the static macros defined in
clk-private.h.

The issue with kernel panic while CONFIG_DEBUG_SLAB is enabled
was reported by Piotr Haber and Tony Lindgren and this patch
fixes the reported issue as well.

Reported-by: Piotr Haber &lt;phaber@broadcom.com&gt;
Reported-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Rajendra Nayak &lt;rnayak@ti.com&gt;
Acked-by: Santosh Shilimkar &lt;santosh.shilimkar@ti.com&gt;
Reviewed-by: Mike Turquette &lt;mturquette@linaro.org&gt;
Acked-by: Paul Walmsley &lt;paul@pwsan.com&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: kirkwood: Fix chip-delay for GoFlex Net</title>
<updated>2013-04-05T16:26:14+00:00</updated>
<author>
<name>Eric Hutter</name>
<email>hutter.eric@gmail.com</email>
</author>
<published>2013-03-18T18:48:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9daa43beb4e7a862d2e6aa8ecbe1056dee2e6aa2'/>
<id>9daa43beb4e7a862d2e6aa8ecbe1056dee2e6aa2</id>
<content type='text'>
commit 2992714d431976c4b154875bd18ba61bf4df3b93 upstream.

This fixes "Too few good blocks within range" issues on GoFlex Net by setting
chip-delay to 40.

The basic problem was discussed at http://forum.doozan.com/read.php?2,7451

Signed-off-by: Eric Hutter &lt;hutter.eric@gmail.com&gt;
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

This fixes "Too few good blocks within range" issues on GoFlex Net by setting
chip-delay to 40.

The basic problem was discussed at http://forum.doozan.com/read.php?2,7451

Signed-off-by: Eric Hutter &lt;hutter.eric@gmail.com&gt;
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Signed-off-by: Jason Cooper &lt;jason@lakedaemon.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: imx: fix sync issue between imx_cpu_die and imx_cpu_kill</title>
<updated>2013-04-05T16:26:14+00:00</updated>
<author>
<name>Shawn Guo</name>
<email>shawn.guo@linaro.org</email>
</author>
<published>2013-03-26T08:46:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=1df12d51667611bd288c0bc33cbe6aec60aaa011'/>
<id>1df12d51667611bd288c0bc33cbe6aec60aaa011</id>
<content type='text'>
commit 2f3edfd7e27ad4206acbc2ae99c9df5f46353024 upstream.

There is a sync issue with hotplug operation.  It's possible that when
imx_cpu_kill gets running on primary core, the imx_cpu_die execution
on the core which is to be killed hasn't been finished yet.  The problem
will very likely be hit when running suspend without no_console_suspend
setting on kernel cmdline.

It uses cpu jumping argument register to sync imx_cpu_die and
imx_cpu_kill.  The register will be set in imx_cpu_die and imx_cpu_kill
will wait for the register being cleared to actually kill the cpu.

Signed-off-by: Shawn Guo &lt;shawn.guo@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

There is a sync issue with hotplug operation.  It's possible that when
imx_cpu_kill gets running on primary core, the imx_cpu_die execution
on the core which is to be killed hasn't been finished yet.  The problem
will very likely be hit when running suspend without no_console_suspend
setting on kernel cmdline.

It uses cpu jumping argument register to sync imx_cpu_die and
imx_cpu_kill.  The register will be set in imx_cpu_die and imx_cpu_kill
will wait for the register being cleared to actually kill the cpu.

Signed-off-by: Shawn Guo &lt;shawn.guo@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: cns3xxx: fix mapping of private memory region</title>
<updated>2013-04-05T16:26:09+00:00</updated>
<author>
<name>Mac Lin</name>
<email>mkl0301@gmail.com</email>
</author>
<published>2013-03-25T09:23:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ece83fd9ecb8c15dff1e82c1571e0c9d76e4be77'/>
<id>ece83fd9ecb8c15dff1e82c1571e0c9d76e4be77</id>
<content type='text'>
commit a3d9052c6296ad3398d3ad649c3c682c3e7ecfa6 upstream.

Since commit 0536bdf33faf (ARM: move iotable mappings within the vmalloc
region), the Cavium CNS3xxx cannot boot anymore.

This is caused by the pre-defined iotable mappings is not in the vmalloc
region. This patch move the iotable mappings into the vmalloc region, and
merge the MPCore private memory region (containing the SCU, the GIC and
the TWD) as a single region.

Signed-off-by: Mac Lin &lt;mkl0301@gmail.com&gt;
Signed-off-by: Anton Vorontsov &lt;anton@enomsg.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

Since commit 0536bdf33faf (ARM: move iotable mappings within the vmalloc
region), the Cavium CNS3xxx cannot boot anymore.

This is caused by the pre-defined iotable mappings is not in the vmalloc
region. This patch move the iotable mappings into the vmalloc region, and
merge the MPCore private memory region (containing the SCU, the GIC and
the TWD) as a single region.

Signed-off-by: Mac Lin &lt;mkl0301@gmail.com&gt;
Signed-off-by: Anton Vorontsov &lt;anton@enomsg.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>signal: Define __ARCH_HAS_SA_RESTORER so we know whether to clear sa_restorer</title>
<updated>2013-04-05T16:26:05+00:00</updated>
<author>
<name>Ben Hutchings</name>
<email>ben@decadent.org.uk</email>
</author>
<published>2012-11-26T03:24:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9dccad6a1590cc1f8c37e066e64155439dfc70cf'/>
<id>9dccad6a1590cc1f8c37e066e64155439dfc70cf</id>
<content type='text'>
Vaguely based on upstream commit 574c4866e33d 'consolidate kernel-side
struct sigaction declarations'.

flush_signal_handlers() needs to know whether sigaction::sa_restorer
is defined, not whether SA_RESTORER is defined.  Define the
__ARCH_HAS_SA_RESTORER macro to indicate this.

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Vaguely based on upstream commit 574c4866e33d 'consolidate kernel-side
struct sigaction declarations'.

flush_signal_handlers() needs to know whether sigaction::sa_restorer
is defined, not whether SA_RESTORER is defined.  Define the
__ARCH_HAS_SA_RESTORER macro to indicate this.

Signed-off-by: Ben Hutchings &lt;ben@decadent.org.uk&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: DMA-mapping: add missing GFP_DMA flag for atomic buffer allocation</title>
<updated>2013-03-28T19:18:14+00:00</updated>
<author>
<name>Marek Szyprowski</name>
<email>m.szyprowski@samsung.com</email>
</author>
<published>2013-02-26T06:46:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=36bd37a9716002fc074b55638ff9583c03cea7ad'/>
<id>36bd37a9716002fc074b55638ff9583c03cea7ad</id>
<content type='text'>
commit 9d1400cf79afb49584b4873eb22cd5130cb341db upstream.

Atomic pool should always be allocated from DMA zone if such zone is
available in the system to avoid issues caused by limited dma mask of
any of the devices used for making an atomic allocation.

Reported-by: Krzysztof Halasa &lt;khc@pm.waw.pl&gt;
Signed-off-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

Atomic pool should always be allocated from DMA zone if such zone is
available in the system to avoid issues caused by limited dma mask of
any of the devices used for making an atomic allocation.

Reported-by: Krzysztof Halasa &lt;khc@pm.waw.pl&gt;
Signed-off-by: Marek Szyprowski &lt;m.szyprowski@samsung.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: tegra: fix register address of slink controller</title>
<updated>2013-03-28T19:17:48+00:00</updated>
<author>
<name>Laxman Dewangan</name>
<email>ldewangan@nvidia.com</email>
</author>
<published>2013-03-22T18:35:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=28608858a1511b64575860e4efc007ebb9340a64'/>
<id>28608858a1511b64575860e4efc007ebb9340a64</id>
<content type='text'>
commit 57471c8d3c22873f70813820e6b4d2d1fea9629d upstream.

Fix typo on register address of slink3 controller where register
address is wrongly set as 0x7000d480 but it is 0x7000d800.

Signed-off-by: Laxman Dewangan &lt;ldewangan@nvidia.com&gt;
Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

Fix typo on register address of slink3 controller where register
address is wrongly set as 0x7000d480 but it is 0x7000d800.

Signed-off-by: Laxman Dewangan &lt;ldewangan@nvidia.com&gt;
Signed-off-by: Stephen Warren &lt;swarren@nvidia.com&gt;
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: davinci: edma: fix dmaengine induced null pointer dereference on da830</title>
<updated>2013-03-20T20:10:55+00:00</updated>
<author>
<name>Matt Porter</name>
<email>mporter@ti.com</email>
</author>
<published>2013-03-05T15:58:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=2f9969215930e3273ed9dfc7db0ffbb5d495fbc0'/>
<id>2f9969215930e3273ed9dfc7db0ffbb5d495fbc0</id>
<content type='text'>
commit 069552777a121eb39da29de4bc0383483dbe1f7e upstream.

This adds additional error checking to the private edma api implementation
to catch the case where the edma_alloc_slot() has an invalid controller
parameter. The edma dmaengine wrapper driver relies on this condition
being handled in order to avoid setting up a second edma dmaengine
instance on DA830.

Verfied using a DA850 with the second EDMA controller platform instance
removed to simulate a DA830 which only has a single EDMA controller.

Reported-by: Tomas Novotny &lt;tomas@novotny.cz&gt;
Signed-off-by: Matt Porter &lt;mporter@ti.com&gt;
Tested-by: Tomas Novotny &lt;tomas@novotny.cz&gt;
Signed-off-by: Sekhar Nori &lt;nsekhar@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

This adds additional error checking to the private edma api implementation
to catch the case where the edma_alloc_slot() has an invalid controller
parameter. The edma dmaengine wrapper driver relies on this condition
being handled in order to avoid setting up a second edma dmaengine
instance on DA830.

Verfied using a DA850 with the second EDMA controller platform instance
removed to simulate a DA830 which only has a single EDMA controller.

Reported-by: Tomas Novotny &lt;tomas@novotny.cz&gt;
Signed-off-by: Matt Porter &lt;mporter@ti.com&gt;
Tested-by: Tomas Novotny &lt;tomas@novotny.cz&gt;
Signed-off-by: Sekhar Nori &lt;nsekhar@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: w1-gpio: fix erroneous gpio requests</title>
<updated>2013-03-20T20:10:54+00:00</updated>
<author>
<name>Johan Hovold</name>
<email>jhovold@gmail.com</email>
</author>
<published>2013-03-12T19:21:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=7be4a00d5c4aaef6e47e8e4032aaf015e76ae6a4'/>
<id>7be4a00d5c4aaef6e47e8e4032aaf015e76ae6a4</id>
<content type='text'>
commit 2d798a3f20ae992b0b69a2b68c04ada397c32ed4 upstream.

Fix regression introduced by commit d2323cf773 ("onewire: w1-gpio: add
ext_pullup_enable pin in platform data") which added a gpio entry to the
platform data, but did not add the required initialisers to the board
files using it. Consequently, the driver would request gpio 0 at probe,
which could break other uses of the corresponding pin.

On AT91 requesting gpio 0 changes the pin muxing for PIOA0, which, for
instance, breaks SPI0 on at91sam9g20.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Acked-by: Jean-Christophe PLAGNIOL-VILLARD &lt;plagnioj@jcrosoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

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

Fix regression introduced by commit d2323cf773 ("onewire: w1-gpio: add
ext_pullup_enable pin in platform data") which added a gpio entry to the
platform data, but did not add the required initialisers to the board
files using it. Consequently, the driver would request gpio 0 at probe,
which could break other uses of the corresponding pin.

On AT91 requesting gpio 0 changes the pin muxing for PIOA0, which, for
instance, breaks SPI0 on at91sam9g20.

Signed-off-by: Johan Hovold &lt;jhovold@gmail.com&gt;
Acked-by: Jean-Christophe PLAGNIOL-VILLARD &lt;plagnioj@jcrosoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
