linux-stable.git/arch/arc, branch v4.5.2

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

arc: get rid of DEVTMPFS dependency on INITRAMFS_SOURCE

2016-02-23T07:01:04+00:00

Even though DEVTMPFS is required when our pre-built initramfs
is used it is not the case in general. It is perfectly possible
to use initramfs with device nodes already populated or there
could be other usages, see discussion below for more detials:
http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/37819/focus=37821

This change removes mentioned dependency from arch/arc/Kconfig
updating instead those defconfigs that are usually used with this
kind of pre-build initramfs.

And while at it all touched defconfigs were regenerated via
savedefconfig and some options were removed:
 * USB is selected by other options implicitly
 * VGA_CONSOLE is disableb for ARC since
   031e29b5877f31676739dc2f847d04c2c0732034
 * EXT3_FS automatically selects EXT4_FS
 * MTDxxx and JFFS2_FS make no sense for AXS because
   AXS NAND controller is not upstreamed
 * NET_OSCI_LAN is not in upstream as well
 * ARCPGU_xxx options make no sense because ARC PGU is not yet
   in upstream and when it gets there all config options would
   be taken from devicetree

Signed-off-by: Alexey Brodkin 
Signed-off-by: Vineet Gupta