<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/arch/arm/boot, branch v3.14.8</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>arm: dts: Fix missing device_type="memory" for ste-ccu8540</title>
<updated>2014-06-07T17:28:17+00:00</updated>
<author>
<name>Leif Lindholm</name>
<email>leif.lindholm@linaro.org</email>
</author>
<published>2014-04-17T17:41:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=542e7f333e12cb600e6a2a59356cae5ca8f0dea5'/>
<id>542e7f333e12cb600e6a2a59356cae5ca8f0dea5</id>
<content type='text'>
commit bfaed5abad998bfc88a66e6e71c7b08dcf82f04e upstream.

The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for
its memory node, relying on an old ppc quirk in order to discover its
memory. Fix the data so that all parsing code can handle it correctly.

Signed-off-by: Leif Lindholm &lt;leif.lindholm@linaro.org&gt;
Acked-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Acked-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Grant Likely &lt;grant.likely@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 bfaed5abad998bfc88a66e6e71c7b08dcf82f04e upstream.

The current .dts for ste-ccu8540 lacks a 'device_type = "memory"' for
its memory node, relying on an old ppc quirk in order to discover its
memory. Fix the data so that all parsing code can handle it correctly.

Signed-off-by: Leif Lindholm &lt;leif.lindholm@linaro.org&gt;
Acked-by: Lee Jones &lt;lee.jones@linaro.org&gt;
Acked-by: Linus Walleij &lt;linus.walleij@linaro.org&gt;
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: Mark Rutland &lt;mark.rutland@arm.com&gt;
Signed-off-by: Grant Likely &lt;grant.likely@linaro.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: mvebu: fix NOR bus-width in Armada XP OpenBlocks AX3 Device Tree</title>
<updated>2014-06-07T17:28:17+00:00</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2014-04-14T15:29:21+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c5a7378aa0114f09e3c7c89489b2a9aadfda1469'/>
<id>c5a7378aa0114f09e3c7c89489b2a9aadfda1469</id>
<content type='text'>
commit 6e20bae8a39c40d4e03698e4160bad2d2629062b upstream.

The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.

This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP OpenBlocks AX3 Device Tree: a 8 bits bus width was
declared, even though the hardware actually has a 16 bits bus width
connection with the NOR flash.

Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.

This bug was introduced in commit
a7d4f81821f7eec3175f8e23dd6949c71ab2da43 ('ARM: mvebu: Add support for
NOR flash device on Openblocks AX3 board') which was merged in v3.10.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Link: https://lkml.kernel.org/r/1397489361-5833-5-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: a7d4f81821f7 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board')
Acked-by: Ezequiel Garcia &lt;ezequiel.garcia@free-electrons.com&gt;
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&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 6e20bae8a39c40d4e03698e4160bad2d2629062b upstream.

The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.

This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP OpenBlocks AX3 Device Tree: a 8 bits bus width was
declared, even though the hardware actually has a 16 bits bus width
connection with the NOR flash.

Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.

This bug was introduced in commit
a7d4f81821f7eec3175f8e23dd6949c71ab2da43 ('ARM: mvebu: Add support for
NOR flash device on Openblocks AX3 board') which was merged in v3.10.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Link: https://lkml.kernel.org/r/1397489361-5833-5-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: a7d4f81821f7 ('ARM: mvebu: Add support for NOR flash device on Openblocks AX3 board')
Acked-by: Ezequiel Garcia &lt;ezequiel.garcia@free-electrons.com&gt;
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&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: mvebu: fix NOR bus-width in Armada XP DB Device Tree</title>
<updated>2014-06-07T17:28:17+00:00</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2014-04-14T15:29:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=dc68b6a6c724a43404ded6fb5227bca536c1209e'/>
<id>dc68b6a6c724a43404ded6fb5227bca536c1209e</id>
<content type='text'>
commit f3aec8f3f05025e7b450102dae0759375346706e upstream.

The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.

This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP DB Device Tree: a 8 bits bus width was declared, even
though the hardware actually has a 16 bits bus width connection with
the NOR flash.

Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.

This bug was introduced in commit
b484ff42df475c5087d614c4d477273e1906bcb9 ('ARM: mvebu: Add support for
NOR flash device on Armada XP-DB board') which was merged in v3.11.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Link: https://lkml.kernel.org/r/1397489361-5833-4-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: b484ff42df47 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board')
Acked-by: Ezequiel Garcia &lt;ezequiel.garcia@free-electrons.com&gt;
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&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 f3aec8f3f05025e7b450102dae0759375346706e upstream.

The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.

This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP DB Device Tree: a 8 bits bus width was declared, even
though the hardware actually has a 16 bits bus width connection with
the NOR flash.

Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.

This bug was introduced in commit
b484ff42df475c5087d614c4d477273e1906bcb9 ('ARM: mvebu: Add support for
NOR flash device on Armada XP-DB board') which was merged in v3.11.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Link: https://lkml.kernel.org/r/1397489361-5833-4-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: b484ff42df47 ('ARM: mvebu: Add support for NOR flash device on Armada XP-DB board')
Acked-by: Ezequiel Garcia &lt;ezequiel.garcia@free-electrons.com&gt;
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&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: mvebu: fix NOR bus-width in Armada XP GP Device Tree</title>
<updated>2014-06-07T17:28:17+00:00</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2014-04-14T15:29:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=f05b2f5730bdaa4f80864fb5a906e246b54a303d'/>
<id>f05b2f5730bdaa4f80864fb5a906e246b54a303d</id>
<content type='text'>
commit 1a88f809ccb5db1509a7514b187c00b3a995fc82 upstream.

The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.

This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP GP Device Tree: a 8 bits bus width was declared, even
though the hardware actually has a 16 bits bus width connection with
the NOR flash.

Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.

This bug was introduced in commit
da8d1b38356853c37116f9afa29f15648d7fb159 ('ARM: mvebu: Add support for
NOR flash device on Armada XP-GP board') which was merged in v3.10.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Link: https://lkml.kernel.org/r/1397489361-5833-3-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: da8d1b383568 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board')
Acked-by: Ezequiel Garcia &lt;ezequiel.garcia@free-electrons.com&gt;
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&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 1a88f809ccb5db1509a7514b187c00b3a995fc82 upstream.

The mvebu-devbus driver had a serious bug, which lead to a 8 bits bus
width declared in the Device Tree being considered as a 16 bits bus
width when configuring the hardware.

This bug in mvebu-devbus driver was compensated by a symetric mistake
in the Armada XP GP Device Tree: a 8 bits bus width was declared, even
though the hardware actually has a 16 bits bus width connection with
the NOR flash.

Now that we have fixed the mvebu-devbus driver to behave according to
its Device Tree binding, this commit fixes the problematic Device Tree
files as well.

This bug was introduced in commit
da8d1b38356853c37116f9afa29f15648d7fb159 ('ARM: mvebu: Add support for
NOR flash device on Armada XP-GP board') which was merged in v3.10.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Link: https://lkml.kernel.org/r/1397489361-5833-3-git-send-email-thomas.petazzoni@free-electrons.com
Fixes: da8d1b383568 ('ARM: mvebu: Add support for NOR flash device on Armada XP-GP board')
Acked-by: Ezequiel Garcia &lt;ezequiel.garcia@free-electrons.com&gt;
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&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: common: edma: Fix xbar mapping</title>
<updated>2014-06-07T17:28:17+00:00</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2014-04-13T18:44:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=0387a6a201d9a28032cd9882e440aaa9fed34aec'/>
<id>0387a6a201d9a28032cd9882e440aaa9fed34aec</id>
<content type='text'>
commit cf7eb979116c2568e8bc3b6a7269c7a359864ace upstream.

This is another great example of trainwreck engineering:

commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support)
added support for using EDMA on peripherals which have no direct EDMA
event mapping.

The code compiles and does not explode in your face, but that's it.

1) Reading an u16 array from an u32 device tree array simply does not
   work. Even if the function is named "edma_of_read_u32_to_s16_array".

   It merily calls of_property_read_u16_array. So the resulting 16bit
   array will have every other entry = 0.

2) The DT entry for the xbar registers related to xbar has length 0x10
   instead of the real length: 0xfd0 - 0xf90 = 0x40.

   Not a real problem as it does not cross a page boundary, but
   wrong nevertheless.

3) But none of this matters as the mapping never happens:

   After reading nonsense edma_of_read_u32_to_s16_array() invalidates
   the first array entry pair, so nobody can ever notice the
   braindamage by immediate explosion.

Seems the QA criteria for this code was solely not to explode when
someone adds edma-xbar-event-map entries to the DT. Goal achieved,
congratulations!

Not really helpful if someone wants to use edma on a device which
requires a xbar mapping.

Fix the issues by:

- annotating the device tree entry with "/bits/ 16" as documented in
  the of_property_read_u16_array kernel doc

- make the size of the xbar register mapping correct

- invalidating the end of the array and not the start

This convoluted mess wants to be completely rewritten as there is no
point to keep the xbar_chan array memory and the iomapping of the xbar
regs around forever. Marking the xbar mapped channels as used should
be done right there.

But that's a different issue and this patch is small enough to make it
work and allows a simple backport for stable.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&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 cf7eb979116c2568e8bc3b6a7269c7a359864ace upstream.

This is another great example of trainwreck engineering:

commit 2646a0e529 (ARM: edma: Add EDMA crossbar event mux support)
added support for using EDMA on peripherals which have no direct EDMA
event mapping.

The code compiles and does not explode in your face, but that's it.

1) Reading an u16 array from an u32 device tree array simply does not
   work. Even if the function is named "edma_of_read_u32_to_s16_array".

   It merily calls of_property_read_u16_array. So the resulting 16bit
   array will have every other entry = 0.

2) The DT entry for the xbar registers related to xbar has length 0x10
   instead of the real length: 0xfd0 - 0xf90 = 0x40.

   Not a real problem as it does not cross a page boundary, but
   wrong nevertheless.

3) But none of this matters as the mapping never happens:

   After reading nonsense edma_of_read_u32_to_s16_array() invalidates
   the first array entry pair, so nobody can ever notice the
   braindamage by immediate explosion.

Seems the QA criteria for this code was solely not to explode when
someone adds edma-xbar-event-map entries to the DT. Goal achieved,
congratulations!

Not really helpful if someone wants to use edma on a device which
requires a xbar mapping.

Fix the issues by:

- annotating the device tree entry with "/bits/ 16" as documented in
  the of_property_read_u16_array kernel doc

- make the size of the xbar register mapping correct

- invalidating the end of the array and not the start

This convoluted mess wants to be completely rewritten as there is no
point to keep the xbar_chan array memory and the iomapping of the xbar
regs around forever. Marking the xbar mapped channels as used should
be done right there.

But that's a different issue and this patch is small enough to make it
work and allows a simple backport for stable.

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&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: dts: i.MX53: Fix ipu register space size</title>
<updated>2014-06-07T17:28:17+00:00</updated>
<author>
<name>Sascha Hauer</name>
<email>s.hauer@pengutronix.de</email>
</author>
<published>2014-05-06T11:01:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=12800a2e16f3f4c2a28bb43feda1d56b566a1746'/>
<id>12800a2e16f3f4c2a28bb43feda1d56b566a1746</id>
<content type='text'>
commit 6d66da89bf4422c0a0693627fb3e25f74af50f92 upstream.

The IPU register space is 128MB, not 2GB.

Fixes: abed9a6bf2bb 'ARM i.MX53: Add IPU support'
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Acked-by: Shawn Guo &lt;shawn.guo@freescale.com&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.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 6d66da89bf4422c0a0693627fb3e25f74af50f92 upstream.

The IPU register space is 128MB, not 2GB.

Fixes: abed9a6bf2bb 'ARM i.MX53: Add IPU support'
Signed-off-by: Sascha Hauer &lt;s.hauer@pengutronix.de&gt;
Acked-by: Shawn Guo &lt;shawn.guo@freescale.com&gt;
Signed-off-by: Olof Johansson &lt;olof@lixom.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: dts: kirkwood: fix mislocated pcie-controller nodes</title>
<updated>2014-06-07T17:28:17+00:00</updated>
<author>
<name>Sebastian Hesselbarth</name>
<email>sebastian.hesselbarth@gmail.com</email>
</author>
<published>2014-04-30T12:56:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6f5d63343a96cfadaa16fd4bcc06c0c7b0b26c7f'/>
<id>6f5d63343a96cfadaa16fd4bcc06c0c7b0b26c7f</id>
<content type='text'>
commit 788296b2d19d16ec33aba0a5ad1544d50bb58601 upstream.

Commit 54397d85349f
 ("ARM: kirkwood: Relocate PCIe device tree nodes")

moved the pcie-controller nodes for the Kirkwood SoCs to the mbus
bus node. For some reason, two boards were not properly converted
and have their pci-controller nodes still in the ocp bus node.

As the corresponding SoC pcie-controller does not exist anymore,
it is likely that pcie is broken on those boards since above commit.
Fix it by moving the pcie related nodes to the correct location.

Signed-off-by: Sebastian Hesselbarth &lt;sebastian.hesselbarth@gmail.com&gt;
Fixes: 54397d85349f ("ARM: kirkwood: Relocate PCIe device tree nodes")
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lkml.kernel.org/r/1398862602-29595-2-git-send-email-sebastian.hesselbarth@gmail.com
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 788296b2d19d16ec33aba0a5ad1544d50bb58601 upstream.

Commit 54397d85349f
 ("ARM: kirkwood: Relocate PCIe device tree nodes")

moved the pcie-controller nodes for the Kirkwood SoCs to the mbus
bus node. For some reason, two boards were not properly converted
and have their pci-controller nodes still in the ocp bus node.

As the corresponding SoC pcie-controller does not exist anymore,
it is likely that pcie is broken on those boards since above commit.
Fix it by moving the pcie related nodes to the correct location.

Signed-off-by: Sebastian Hesselbarth &lt;sebastian.hesselbarth@gmail.com&gt;
Fixes: 54397d85349f ("ARM: kirkwood: Relocate PCIe device tree nodes")
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://lkml.kernel.org/r/1398862602-29595-2-git-send-email-sebastian.hesselbarth@gmail.com
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: dts: am335x: update USB DT references</title>
<updated>2014-05-06T14:59:38+00:00</updated>
<author>
<name>Leigh Brown</name>
<email>leigh@solinno.co.uk</email>
</author>
<published>2014-04-16T11:26:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=cff520b03d074fc0a4a34de7a70a83af0e5e961e'/>
<id>cff520b03d074fc0a4a34de7a70a83af0e5e961e</id>
<content type='text'>
commit a2f8d6b303213a98436455aece7e14cdd1240629 upstream.

In "ARM: dts: am33xx: correcting dt node unit address for usb", the
usb_ctrl_mod and cppi41dma nodes were updated with the correct register
addresses.  However, the dts files that reference these nodes were not
updated, and those devices are no longer being enabled.

This patch corrects the references for the affected dts files.

Signed-off-by: Leigh Brown &lt;leigh@solinno.co.uk&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Cc: Johan Hovold &lt;jhovold@gmail.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 a2f8d6b303213a98436455aece7e14cdd1240629 upstream.

In "ARM: dts: am33xx: correcting dt node unit address for usb", the
usb_ctrl_mod and cppi41dma nodes were updated with the correct register
addresses.  However, the dts files that reference these nodes were not
updated, and those devices are no longer being enabled.

This patch corrects the references for the affected dts files.

Signed-off-by: Leigh Brown &lt;leigh@solinno.co.uk&gt;
Signed-off-by: Tony Lindgren &lt;tony@atomide.com&gt;
Cc: Johan Hovold &lt;jhovold@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ARM: tegra: remove UART5/UARTE from tegra124.dtsi</title>
<updated>2014-05-06T14:59:37+00:00</updated>
<author>
<name>Stephen Warren</name>
<email>swarren@nvidia.com</email>
</author>
<published>2014-04-01T20:13:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=185a3afb4e3dd9da07a2187bd2dfdecdf1d74cee'/>
<id>185a3afb4e3dd9da07a2187bd2dfdecdf1d74cee</id>
<content type='text'>
commit 862f0eea38409ff0d7f226c1245b787e3f0e2607 upstream.

Tegra124 only has 4 UARTs. Parts of the documentation hint at a fifth
UART, but this appears to be left-over from earlier SoC documentation.
Remove the non-existent DT node for UART5.

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 862f0eea38409ff0d7f226c1245b787e3f0e2607 upstream.

Tegra124 only has 4 UARTs. Parts of the documentation hint at a fifth
UART, but this appears to be left-over from earlier SoC documentation.
Remove the non-existent DT node for UART5.

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: mvebu: ensure the mdio node has a clock reference on Armada 370/XP</title>
<updated>2014-05-06T14:59:23+00:00</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2014-03-25T23:33:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=8d0e11e0fb8cb9c61e56194a00abbd7a63dddd26'/>
<id>8d0e11e0fb8cb9c61e56194a00abbd7a63dddd26</id>
<content type='text'>
commit a6e03dd451c724f785277d8ecca5d1a0b886d892 upstream.

The mvmdio driver accesses some register of the Ethernet unit. It
therefore takes a reference and enables a clock. However, on Armada
370/XP, no clock specification was given in the Device Tree, which
leads the mvmdio driver to fail when being used as a module and loaded
before the mvneta driver: it tries to access a register from a
hardware unit that isn't clocked.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Link: https://lkml.kernel.org/r/1395790439-21332-2-git-send-email-thomas.petazzoni@free-electrons.com
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&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 a6e03dd451c724f785277d8ecca5d1a0b886d892 upstream.

The mvmdio driver accesses some register of the Ethernet unit. It
therefore takes a reference and enables a clock. However, on Armada
370/XP, no clock specification was given in the Device Tree, which
leads the mvmdio driver to fail when being used as a module and loaded
before the mvneta driver: it tries to access a register from a
hardware unit that isn't clocked.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Link: https://lkml.kernel.org/r/1395790439-21332-2-git-send-email-thomas.petazzoni@free-electrons.com
Acked-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Acked-by: Gregory CLEMENT &lt;gregory.clement@free-electrons.com&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>
</feed>
