[ Upstream commit 4e486cba285ff06a1f28f0fc2991dde1482d1dcf ]

The "Miscellaneous Node" fell through cracks of node initialisation,
as its ID is shared with HN-I.

This patch treats MN as a special case (which it is), adding separate
validation check for it and pre-defining the node ID in relevant events
descriptions. That way one can simply run:

	# perf stat -a -e ccn/mn_ecbarrier/ <workload>

Additionally, direction in the MN pseudo-events XP watchpoint
definitions is corrected to be "TX" (1) as they are defined from the
crosspoint point of view (thus barriers are transmitted from XP to MN).

Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

[ Upstream commit 8f06c51fac1ca4104b8b64872f310e28186aea42 ]

Since 688d4dfcdd624192cbf03c08402e444d1d11f294 "perf tools: Support
parsing parameterized events" the perf userspace tools understands
"argument=?" syntax in the events file, making sure that required
arguments are provided by the user and not defaulting to 0, causing
confusion.

This patch adds the required arguments lists for CCN events.

Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

[ Upstream commit b928466b2169e061822daad48ecf55b005445547 ]

The code setting XP watchpoint comparator and mask registers should, in
order to be fully compliant with specification, zero one or more most
significant bits of each field. In both L cases it means zeroing bit 63.
The bitmask doing this was wrong, though, zeroing bit 60 instead.
Fortunately, due to a lucky coincidence, this turned out to be fairly
innocent with the existing hardware.

Fixed now.

Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

[ Upstream commit b7c1beb278e8e3dc664ed3df3fc786db126120a9 ]

Fuzzing the CCN perf driver revealed a small but definitely dangerous
mistake in the event setup code. When a cycle counter is requested, the
driver should not reconfigure the events bus at all, otherwise it will
corrupt (in most but the simplest cases) its configuration and may end
up accessing XP array out of its bounds and corrupting control
registers.

Reported-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Tested-by: Mark Rutland <mark.rutland@arm.com>
Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Sasha Levin <alexander.levin@verizon.com>

[ Upstream commit 33b96d2c9579213cf3f36d7b29841b1e464750c4 ]

Currently we have an incorrect behaviour when multiple devices
are present under the weim node. For example:

&weim {
	...
	status = "okay";

	sram@0,0 {
		...
        	status = "okay";
	};

	mram@0,0 {
		...
        	status = "disabled";
    	};
};

In this case only the 'sram' device should be probed and not 'mram'.

However what happens currently is that the status variable is ignored,
causing the 'sram' device to be disabled and 'mram' to be enabled.

Change the weim_parse_dt() function to use
for_each_available_child_of_node()so that the devices marked with
'status = disabled' are not probed.

Cc: <stable@vger.kernel.org>
Suggested-by: Wolfgang Netbal <wolfgang.netbal@sigmatek.at>
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Sasha Levin <sasha.levin@oracle.com>

commit a18f8e97fe69195823d7fb5c68a8d6565f39db4b upstream.

Events defined as watchpoints on nodes must have their config values
converted so that they apply to the respective node's XP. The
function setting new values was using wrong mask for the "port" field,
resulting in corrupted value. Fixed now.

Signed-off-by: Pawel Moll <pawel.moll@arm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge "mvebu fixes for 4.1 (part 3)" from Gregory CLEMENT:

Disable unused internal RTC for Mamba from linksys (Armada XP)
And 2 commits fixing regressions on mvebu-mbus:
- the first one for Kirkwood or Orion SoC
- the second one for DMA when the platform have more than 4GB (only
  possible on Armada XP as far as I know)

* tag 'mvebu-fixes-4.1-3' of git://git.infradead.org/linux-mvebu:
  Revert "bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window"
  bus: mvebu-mbus: do not set WIN_CTRL_SYNCBARRIER on non io-coherent platforms.
  ARM: mvebu: armada-xp-linksys-mamba: Disable internal RTC

This reverts commit 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS
for DMA don't overlap the MBus bridge window"), because it breaks DMA
on platforms having more than 2 GB of RAM.

This commit changed the information reported to DMA masters device
drivers through the mv_mbus_dram_info() function so that the returned
DRAM ranges do not overlap with I/O windows.

This was necessary as a preparation to support the new CESA Crypto
Engine driver, which will use DMA for cryptographic operations. But
since it does DMA with the SRAM which is mapped as an I/O window,
having DRAM ranges overlapping with I/O windows was problematic.

To solve this, the above mentioned commit changed the mvebu-mbus to
adjust the DRAM ranges so that they don't overlap with the I/O
windows. However, by doing this, we re-adjust the DRAM ranges in a way
that makes them have a size that is no longer a power of two. While
this is perfectly fine for the Crypto Engine, which supports DRAM
ranges with a granularity of 64 KB, it breaks basically all other DMA
masters, which expect power of two sizes for the DRAM ranges.

Due to this, if the installed system memory is 4 GB, in two
chip-selects of 2 GB, the second DRAM range will be reduced from 2 GB
to a little bit less than 2 GB to not overlap with the I/O windows, in
a way that results in a DRAM range that doesn't have a power of two
size. This means that whenever you do a DMA transfer with an address
located in the [ 2 GB ; 4 GB ] area, it will freeze the system. Any
serious DMA activity like simply running:

  for i in $(seq 1 64) ; do dd if=/dev/urandom of=file$i bs=1M count=16 ; done

in an ext3 partition mounted over a SATA drive will freeze the system.

Since the new CESA crypto driver that uses DMA has not been merged
yet, the easiest fix is to simply revert this commit. A follow-up
commit will introduce a different solution for the CESA crypto driver.

Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fixes: 1737cac69369 ("bus: mvebu-mbus: make sure SDRAM CS for DMA don't overlap the MBus bridge window")
Cc: <stable@vger.kernel.org> # v4.0+
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

Commit a0b5cd4ac2d6 ("bus: mvebu-mbus: use automatic I/O
synchronization barriers") enabled the usage of automatic I/O
synchronization barriers by enabling bit WIN_CTRL_SYNCBARRIER in the
control registers of MBus windows, but on non io-coherent platforms
(orion5x, kirkwood and dove) the WIN_CTRL_SYNCBARRIER bit in
the window control register is either reserved (all windows except 6
and 7) or enables read-only protection (windows 6 and 7).

Signed-off-by: Nicolas Schichan <nschichan@freebox.fr>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: <stable@vger.kernel.org> # v4.0+
Fixes: a0b5cd4ac2d6 ("bus: mvebu-mbus: use automatic I/O synchronization barriers")
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

The MIPS Common Device Memory Map (CDMM) is internal to the core and has
native endianness. There is therefore no need to byte swap the accesses
on big endian targets, so convert the CDMM bus driver to use
__raw_readl() rather than readl().

Fixes: 8286ae03308c ("MIPS: Add CDMM bus support")
Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/9904/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>