[PATCH] ARM: mvebu: pass the coherency availability information at init time

On 11/06/15 13:45, Greg KH wrote:

On Thu, Jun 11, 2015 at 01:19:24PM +1000, gerg at uclinux.org wrote:

quoted

From: Greg Ungerer <redacted>

This patch is specifically meant to be applied to stable tree linux-3.10.y.

Why?  What's wrong with taking the exact specific upstream patches
instead?

The exact patch mentioned below ("5686a1e5aa4") will not apply.
Too much of the code around it has changed. This does the same
thing in the same away taking into account the changes around it.

Your descriptions here:

quoted

IO coherency should not be used on the Armada 370 SoC, due to all
the necessary pre-requisites for reliable operation not being met
(such as write allocate cache policy, shareable pages, SMP bit set).

Commit e55355453600a33bb5ca4f71f2d7214875f3b061 ("ARM: mvebu: disable
I/O coherency on non-SMP situations on Armada 370/375/38x/XP") was
intended to disable IO coherency for the Armada 370. However it only
disables the CPU side IO coherency. The mbus driver (drivers/bus/
mvebu-mbus.c) still passes the IO coherency attributes through the
dram chip selects and onto driver memory window attributes. It
does this based on looking directly into the device tree (looking
for "marvell,coherency-fabric").

To fix we pass the coherency availability information (whether enabled
or not) to the mbus driver at init time. This is done in the same way
that it was done for mainline kernels in commit
5686a1e5aa436c49187a60052d5885fb1f541ce6 ("bus: mvebu: pass the
coherency availability information at init time").

Having the IO coherency enabled on the Armada 370 SoC causes rare
unreliable system behavior. It is not easy to consistently reproduce
problems caused by this. Best method I have seen is heavy network
load resulting in kernel dumps due to corrupted memory.

I don't understand the issue here, I really don't want to not take
patches that are not in Linus's tree, sorry.

Sure.

Regards
Greg