linux-stable.git/arch/arc, branch linux-4.5.y

ARC: Add missing io barriers to io{read,write}{16,32}be()

2016-05-11T09:21:36+00:00

commit e5bc0478ab6cf565619224536d75ecb2aedca43b upstream.

While reviewing a different change to asm-generic/io.h Arnd spotted that
ARC ioread32 and ioread32be both of which come from asm-generic versions
are not symmetrical in terms of calling the io barriers.

generic ioread32   -> ARC readl()                  [ has barriers]
generic ioread32be -> __be32_to_cpu(__raw_readl()) [ lacks barriers]

While generic ioread32be is being remediated to call readl(), that involves
a swab32(), causing double swaps on ioread32be() on Big Endian systems.

So provide our versions of big endian IO accessors to ensure io barrier
calls while also keeping them optimal

Suggested-by: Arnd Bergmann 
Acked-by: Arnd Bergmann 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: bitops: Remove non relevant comments

2016-04-12T14:33:38+00:00

commit 2a41b6dc28dc71c1a3f1622612a26edc58f7561e upstream.

commit 80f420842ff42 removed the ARC bitops microoptimization but failed
to prune the comments to same effect

Fixes: 80f420842ff42 ("ARC: Make ARC bitops "safer" (add anti-optimization)")
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: [BE] readl()/writel() to work in Big Endian CPU configuration

2016-04-12T14:33:37+00:00

commit f778cc65717687a3d3f26dd21bef62cd059f1b8b upstream.

read{l,w}() write{l,w}() primitives should use le{16,32}_to_cpu() and
cpu_to_le{16,32}() respectively to ensure device registers are read
correctly in Big Endian CPU configuration.

Per Arnd Bergmann
| Most drivers using readl() or readl_relaxed() expect those to perform byte
| swaps on big-endian architectures, as the registers tend to be fixed endian

This was needed for getting UART to work correctly on a Big Endian ARC.

The ARC accessors originally were fine, and the bug got introduced
inadventently by commit b8a033023994 ("ARCv2: barriers")

Fixes: b8a033023994 ("ARCv2: barriers")
Link: http://lkml.kernel.org/r/201603100845.30602.arnd@arndb.de
Cc: Alexey Brodkin 
Cc: Arnd Bergmann 
Signed-off-by: Lada Trimasova 
[vgupta: beefed up changelog, added Fixes/stable tags]
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

ARC: [plat-axs10x] add Ethernet PHY description in .dts

2016-04-12T14:33:37+00:00

commit 667a490bdb6e27db0887d2ca515b907d6aa87118 upstream.

Commit e34d65696d2e ("stmmac: create of compatible mdio bus for stmmac
driver") broke DW GMAC functionality on ARC AXS10x boards:

That's what happens on eth0 up:
  --------------------------->8------------------------
| libphy: PHY stmmac-0:ffffffff not found
| eth0: Could not attach to PHY
| stmmac_open: Cannot attach to PHY (error: -19)
  --------------------------->8------------------------

Simplest solution is to add PHY description in board's .dts.
And so we do here.

Signed-off-by: Alexey Brodkin 
Cc: Rob Herring 
Cc: Phil Reid 
Cc: David S. Miller 
Cc: linux-kernel@vger.kernel.org
Cc: netdev@vger.kernel.org
Reviewed-by: Sergei Shtylyov 
Signed-off-by: Vineet Gupta 
Signed-off-by: Greg Kroah-Hartman

arc: SMP: CONFIG_ARC_IPI_DBG cleanup

2016-02-24T08:45:39+00:00

Previous Commit ("ARC: SMP: No need for CONFIG_ARC_IPI_DBG") removed
the Kconfig option ARC_IPI_DBG.  Remove the last reference on this
option.

Signed-off-by: Valentin Rothberg 
Signed-off-by: Vineet Gupta

ARC: SMP: No need for CONFIG_ARC_IPI_DBG

2016-02-24T05:37:32+00:00

This was more relevant during SMP bringup.

The warning for bogus msg better be visible always.

Signed-off-by: Vineet Gupta

ARCv2: Elide sending new cross core intr if receiver didn't ack prev

2016-02-24T05:37:31+00:00

ARConnect/MCIP IPI sending has a retry-wait loop in case caller had
not seen a previous such interrupt. Turns out that it is not needed at
all. Linux cross core calling allows coalescing multiple IPIs to same
receiver - it is fine as long as there is one.

This logic is built into upper layer already, at a higher level of
abstraction. ipi_send_msg_one() sets the actual msg payload, but it only
calls MCIP IPI sending if msg holder was empty (using
atomic-set-new-and-get-old construct). Thus it is unlikely that the
retry-wait looping was ever getting exercised at all.

Cc: Chuck Jordan 
Cc: Peter Zijlstra 
Signed-off-by: Vineet Gupta

ARCv2: SMP: Push IPI_IRQ into IPI provider

2016-02-24T05:37:31+00:00

Signed-off-by: Vineet Gupta

ARC: [intc-compact] Remove IPI setup from ARCompact port

2016-02-24T05:37:31+00:00

There is no real ARC700 based SMP SoC so remove IPI definition.
EZChip's SMP ARC700 is going to use a different intc and IPI provider
anyways.

Signed-off-by: Vineet Gupta

ARCv2: SMP: Emulate IPI to self using software triggered interrupt

2016-02-24T05:37:28+00:00

ARConnect/MCIP Inter-Core-Interrupt module can't send interrupt to
local core. So use core intc capability to trigger software
interrupt to self, using an unsued IRQ #21.

This showed up as csd deadlock with LTP trace_sched on a dual core
system. This test acts as scheduler fuzzer, triggering all sorts of
schedulting activity. Trouble starts with IPI to self, which doesn't get
delivered (effectively lost due to H/w capability), but the msg intended
to be sent remain enqueued in per-cpu @ipi_data.

All subsequent IPIs to this core from other cores get elided due to the
IPI coalescing optimization in ipi_send_msg_one() where a pending msg
implies an IPI already sent and assumes other core is yet to ack it.
After the elided IPI, other core simply goes into csd_lock_wait()
but never comes out as this core never sees the interrupt.

Fixes STAR 9001008624

Cc: Peter Zijlstra 
Cc:         [4.2]
Signed-off-by: Vineet Gupta