ARM: Xilinx Zynq SoC patches for v5.4

- Add support for SMP in thumb mode
- Fix SMP trampoline code when FORTIFY_SOURCE is enabled

* tag 'zynq-soc-for-v5.4' of https://github.com/Xilinx/linux-xlnx:
  ARM: zynq: Use memcpy_toio instead of memcpy on smp bring-up
  ARM: zynq: Support smp in thumb mode

Link: https://lore.kernel.org/r/8e00ba70-9403-4bf7-2870-a94758e37346@monstr.euSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'omap-for-v5.4/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into arm/soc

SoC changes for omap variants for v5.4

The first change moves platform-specific asm-offsets.h to arch/arm/mach-omap2
to fix iessu with parallel build with CONFIG_IKHEADERS, and the second change
removes a useless kfree.

Note that the first change causes a trivial merge conflict with the iommu
changes for arch/arm/mach-omap2/Makefile.

* tag 'omap-for-v5.4/soc-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP2+: Delete an unnecessary kfree() call in omap_hsmmc_pdata_init()
  ARM: OMAP2+: move platform-specific asm-offset.h to arch/arm/mach-omap2

Link: https://lore.kernel.org/r/pull-1567016893-318461@atomide.comSigned-off-by: Arnd Bergmann <arnd@arndb.de>

AT91 SoC for 5.4

 - MAINTAINERS updates
 - a generated headers parallel build fix

* tag 'at91-5.4-soc' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
  mailmap: map old company name to new one @microchip.com
  MAINTAINERS: at91: remove the TC entry
  MAINTAINERS: at91: Collect all pinctrl/gpio drivers in same entry
  ARM: at91: move platform-specific asm-offset.h to arch/arm/mach-at91

Link: https://lore.kernel.org/r/20190825203222.GA22800@piout.netSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'imx-soc-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/soc

i.MX SoC changes for 5.4:
 - Drop AR8031 PHY TX delay adjusting from i.MX7D machine code, as
   it's superfluous due to the recent changes to Atheros AT803X driver.
 - Select TIMER_IMX_SYS_CTR for arm64 ARCH_MXC platform, since the
   system counter is needed as broadcast timer for cpuidle support.

* tag 'imx-soc-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
  ARM: imx: stop adjusting ar8031 phy tx delay
  arm64: Enable TIMER_IMX_SYS_CTR for ARCH_MXC platforms

Link: https://lore.kernel.org/r/20190825153237.28829-2-shawnguo@kernel.orgSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'aspeed-5.4-arch' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed into arm/soc

ASPEED architecture updates for 5.4

This adds support for the new ASPEED AST2600 BMC SoC.

* tag 'aspeed-5.4-arch' of git://git.kernel.org/pub/scm/linux/kernel/git/joel/aspeed:
  ARM: aspeed: Enable SMP boot
  ARM: aspeed: Add ASPEED AST2600 architecture
  ARM: aspeed: Select timer in each SoC
  dt-bindings: arm: cpus: Add ASPEED SMP

Link: https://lore.kernel.org/r/CACPK8Xc1aSp5fXL3cEzC9SJsCXG2JwsSPpQrW3a09dkvhCyHHA@mail.gmail.comSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'vexpress-update-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/soc

ARMv7 Vexpress update for v5.4

Single cleanup patch handling type checks using cppcheck tool
(bitwise shift by more than 31 on a 32 bit type)

* tag 'vexpress-update-5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
  ARM: vexpress: Cleanup cppcheck shifting warning

Link: https://lore.kernel.org/r/20190814172441.26143-1-sudeep.holla@arm.comSigned-off-by: Arnd Bergmann <arnd@arndb.de>

A null pointer would be passed to a call of the function "kfree" directly
after a call of the function "kzalloc" failed at one place.
Remove this superfluous function call.

This issue was detected by using the Coccinelle software.
Signed-off-by: Markus Elfring <elfring@users.sourceforge.net>
Signed-off-by: Tony Lindgren <tony@atomide.com>

<generated/ti-pm-asm-offsets.h> is only generated and included by
arch/arm/mach-omap2/, so it does not need to reside in the globally
visible include/generated/.

I renamed it to arch/arm/mach-omap2/pm-asm-offsets.h since the prefix
'ti-' is just redundant in mach-omap2/.

My main motivation of this change is to avoid the race condition for
the parallel build (-j) when CONFIG_IKHEADERS is enabled.

When it is enabled, all the headers under include/ are archived into
kernel/kheaders_data.tar.xz and exposed in the sysfs.

In the parallel build, we have no idea in which order files are built.

 - If ti-pm-asm-offsets.h is built before kheaders_data.tar.xz,
   the header will be included in the archive. Probably nobody will
   use it, but it is harmless except that it will increase the archive
   size needlessly.

 - If kheaders_data.tar.xz is built before ti-pm-asm-offsets.h,
   the header will not be included in the archive. However, in the next
   build, the archive will be re-generated to include the newly-found
   ti-pm-asm-offsets.h. This is not nice from the build system point
   of view.

 - If ti-pm-asm-offsets.h and kheaders_data.tar.xz are built at the
   same time, the corrupted header might be included in the archive,
   which does not look nice either.

This commit fixes the race.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Keerthy <j-keerthy@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

This brings the secondary CPU into Linux. It depends on the setup
performed by ASPEED's u-boot.
Signed-off-by: Joel Stanley <joel@jms.id.au>

The AST2600 is a Cortex A7 dual core CPU that uses the ARM GIC for
interrupts and ARM timer as a clocksource.
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>

In preparation for adding the ast2600 which does not use this timer.
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>

The AST2600 SoC contains two CPUs and requires the operating system to
bring the second one out of firmware.
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>

Recent changes to the Atheros at803x driver cause
the approach taken here to stop working because
commit 6d4cd041
("net: phy: at803x: disable delay only for RGMII mode")
and commit cd28d1d6
("net: phy: at803x: Disable phy delay for RGMII mode")
fix the AR8031 driver to configure the phy's (RX/TX)
delays as per the 'phy-mode' in the device tree.

In particular, the phy tx (and rx) delays are updated
again as per the 'phy-mode' *after* the code in here
runs.

Things worked before above commits, because the AR8031
comes out of reset with RX delay enabled, and the
at803x driver didn't touch the delay configuration at
all when "rgmii" mode was selected.

It appears the code in here tries to make device
trees work that incorrectly specify "rgmii", but
that can't work any more and it is imperative since
above commits to have the phy-mode configured
correctly in the device tree.

I suspect there are a few imx7d based boards using
the ar8031 phy and phy-mode = "rgmii", but given I
don't know which ones exactly, I am not in a
position to update the respective device trees.

Hence this patch is simply removing the superfluous
code from the imx7d initialisation. An alternative
could be to add a warning instead, but that would
penalize all boards that have been updated already.
Signed-off-by: André Draszik <git@andred.net>
CC: Russell King <linux@armlinux.org.uk>
CC: Shawn Guo <shawnguo@kernel.org>
CC: Sascha Hauer <s.hauer@pengutronix.de>
CC: Pengutronix Kernel Team <kernel@pengutronix.de>
CC: Fabio Estevam <festevam@gmail.com>
CC: NXP Linux Team <linux-imx@nxp.com>
CC: Kate Stewart <kstewart@linuxfoundation.org>
CC: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Leonard Crestez <leonard.crestez@nxp.com>
CC: linux-arm-kernel@lists.infradead.org
Signed-off-by: Shawn Guo <shawnguo@kernel.org>

Map my old email address @atmel.com to my new company name. It happened 3
years ago but I realized the existence of this file recently.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20190823083158.2649-3-nicolas.ferre@microchip.comSigned-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

"MICROCHIP TIMER COUNTER (TC) AND CLOCKSOURCE DRIVERS" is better
removed because one file entry is outdated and basically, the
maintainer's pool of Alexandre, Ludovic and myself is better suited.

drivers/misc/atmel_tclib.c file is going away in a patch to come and
drivers/clocksource/tcb_clksrc.c file is actually named timer-atmel-tcb.c.
This new name matches the AT91 entry regular expression.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20190823083158.2649-2-nicolas.ferre@microchip.comSigned-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

Andrei's address is not valid anymore, collect all pinctrl/gpio
entries in the common "PIN CONTROLLER - MICROCHIP AT91" one
and remove the PIOBU specific one.
Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Link: https://lore.kernel.org/r/20190823083158.2649-1-nicolas.ferre@microchip.comSigned-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

<generated/at91_pm_data-offsets.h> is only generated and included by
arch/arm/mach-at91/, so it does not need to reside in the globally
visible include/generated/.

I renamed it to arch/arm/mach-at91/pm_data-offsets.h since the prefix
'at91_' is just redundant in mach-at91/.

My main motivation of this change is to avoid the race condition for
the parallel build (-j) when CONFIG_IKHEADERS is enabled.

When it is enabled, all the headers under include/ are archived into
kernel/kheaders_data.tar.xz and exposed in the sysfs.

In the parallel build, we have no idea in which order files are built.

 - If at91_pm_data-offsets.h is built before kheaders_data.tar.xz,
   the header will be included in the archive. Probably nobody will
   use it, but it is harmless except that it will increase the archive
   size needlessly.

 - If kheaders_data.tar.xz is built before at91_pm_data-offsets.h,
   the header will not be included in the archive. However, in the next
   build, the archive will be re-generated to include the newly-found
   at91_pm_data-offsets.h. This is not nice from the build system point
   of view.

 - If at91_pm_data-offsets.h and kheaders_data.tar.xz are built at the
   same time, the corrupted header might be included in the archive,
   which does not look nice either.

This commit fixes the race.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Link: https://lore.kernel.org/r/20190823024346.591-1-yamada.masahiro@socionext.comSigned-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>

I revisited some older patches here, getting two of the remaining
ARM platforms to build with ARCH_MULTIPLATFORM like most others do.

In case of lpc32xx, I created a new set of patches, which seemed
easier than digging out what I did for an older release many
years ago.

* lpc32xx/multiplatform:
  ARM: lpc32xx: allow multiplatform build
  ARM: lpc32xx: clean up header files
  serial: lpc32xx: allow compile testing
  net: lpc-enet: allow compile testing
  net: lpc-enet: fix printk format strings
  net: lpc-enet: fix badzero.cocci warnings
  net: lpc-enet: move phy setup into platform code
  net: lpc-enet: factor out iram access
  gpio: lpc32xx: allow building on non-lpc32xx targets
  serial: lpc32xx_hs: allow compile-testing
  watchdog: pnx4008_wdt: allow compile-testing
  usb: udc: lpc32xx: allow compile-testing
  usb: ohci-nxp: enable compile-testing
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

All preparation work is done, so the platform can finally
be moved into ARCH_MULTIPLATFORM. This requires a small
change to the defconfig file to enable the platform.

Link: https://lore.kernel.org/r/20190809144043.476786-14-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

All device drivers have stopped relying on mach/*.h headers,
so move the remaining headers into arch/arm/mach-lpc32xx/lpc32xx.h
to prepare for multiplatform builds.

The mach/entry-macro.S file has been unused for a long time now
and can simply get removed.

Link: https://lore.kernel.org/r/20190809144043.476786-13-arnd@arndb.deAcked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The lpc32xx_loopback_set() function in hte lpc32xx_hs driver is the
one thing that relies on platform header files. Move that into the
core platform code so we only need a variable declaration for it,
and enable COMPILE_TEST building.

Link: https://lore.kernel.org/r/20190809144043.476786-12-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The lpc-enet driver can now be built on all platforms, so
allow compile testing as well.

Add one missing header inclusion that is required in some
configurations.

Link: https://lore.kernel.org/r/20190809144043.476786-11-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

compile-testing this driver on other architectures showed
multiple warnings:

  drivers/net/ethernet/nxp/lpc_eth.c: In function 'lpc_eth_drv_probe':
  drivers/net/ethernet/nxp/lpc_eth.c:1337:19: warning: format '%d' expects argument of type 'int', but argument 4 has type 'resource_size_t {aka long long unsigned int}' [-Wformat=]

  drivers/net/ethernet/nxp/lpc_eth.c:1342:19: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]

Use format strings that work on all architectures.

Link: https://lore.kernel.org/r/20190809144043.476786-10-arnd@arndb.deReported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

drivers/net/ethernet/nxp/lpc_eth.c:1316:31-32: WARNING comparing pointer to 0

 Compare pointer-typed values to NULL rather than 0

Semantic patch information:
 This makes an effort to choose between !x and x == NULL.  !x is used
 if it has previously been used with the function used to initialize x.
 This relies on type information.  More type information can be obtained
 using the option -all_includes and the option -I to specify an
 include path.

Generated by: scripts/coccinelle/null/badzero.cocci

Link: https://lore.kernel.org/r/20190809144043.476786-9-arnd@arndb.de
Fixes: e42016eb3844 ("net: lpc-enet: allow compile testing")
Signed-off-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Setting the phy mode requires touching a platform specific
register, which prevents us from building the driver without
its header files.

Move it into a separate function in arch/arm/mach/lpc32xx
to hide the core registers from the network driver.

Link: https://lore.kernel.org/r/20190809144043.476786-8-arnd@arndb.deAcked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The lpc_eth driver uses a platform specific method to find
the internal sram. This prevents building it on other machines.

Rework to only use one function call and keep the other platform
internals where they belong. Ideally this would look up the
sram location from DT, but as this is a rarely used driver,
I want to keep the modifications to a minimum.

Link: https://lore.kernel.org/r/20190809144043.476786-7-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

The driver uses hardwire MMIO addresses instead of the data
that is passed in device tree. Change it over to only
hardcode the register offset values and allow compile-testing.

Link: https://lore.kernel.org/r/20190809144043.476786-6-arnd@arndb.deAcked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Tested-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The only thing that prevents building this driver on other
platforms is the mach/hardware.h include, which is not actually
used here at all, so remove the line and allow CONFIG_COMPILE_TEST.

Link: https://lore.kernel.org/r/20190809144043.476786-5-arnd@arndb.deAcked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The only thing that prevents building this driver on other
platforms is the mach/hardware.h include, which is not actually
used here at all, so remove the line and allow CONFIG_COMPILE_TEST.

Link: https://lore.kernel.org/r/20190809144043.476786-4-arnd@arndb.deAcked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The only thing that prevents building this driver on other
platforms is the mach/hardware.h include, which is not actually
used here at all, so remove the line and allow CONFIG_COMPILE_TEST.

Link: https://lore.kernel.org/r/20190809144043.476786-3-arnd@arndb.deAcked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Acked-by: Sylvain Lemieux <slemieux.tyco@gmail.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

The driver hardcodes a hardware I/O address the way one should
generally not do, and this prevents both compile-testing, and
moving the platform to CONFIG_ARCH_MULTIPLATFORM.

Change the code to be independent of the machine headers
to allow those two. Removing the hardcoded address would
be hard and is not necessary, so leave that in place for now.

Link: https://lore.kernel.org/r/20190809144043.476786-2-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

In a multiplatform configuration, enabling DEBUG_LL breaks booting
on all platforms with incompatible settings. In case of the Marvell
platforms of the Orion/MVEBU family, the physical addresses are
all the same, we just map them at different virtual addresses,
which makes it impossible to run a kernel with DEBUG_LL enabled on
a combination of the merged mvebu and the legacy boardfile based
platforms.

This is easily solved by using the same virtual address everywhere.
I picked the address that is already used by mach-mvebu for UART0:
0xfec12000. All these platforms have a 1MB region with their internal
registers, almost always at physical address 0xf1000000, so I'm
updating the iotable for that entry.

In case of mach-dove, this is slightly trickier, as the existing
mapping is 8MB and a second 8MB mapping is already at the 0xfec00000
address. I have verified from the datasheet that the last 7MB of the
physical mapping are "reserved" and nothing in Linux tries to use
it either. I'm putting this 1MB mapping at the same address as the
others, and the second 8MB register area immediately before that.

Link: https://lore.kernel.org/r/20190731195713.3150463-14-arnd@arndb.de
Link: https://lore.kernel.org/linux-arm-kernel/87si3eb1z8.fsf@free-electrons.com/Signed-off-by: Arnd Bergmann <arnd@arndb.de>

This is a simple move of all header files that are no longer
included by anything else from the include/mach directory
to the platform directory itself as preparation for
multiplatform support.

The mach/uncompress.h headers are left in place for now,
and are mildly modified to be independent of the other
headers. They will be removed entirely when ARCH_MULTIPLATFORM
gets enabled and they become obsolete.

Rather than updating the path names inside of the comments
of each header, I delete those comments to avoid having to
update them again, should they get moved or copied another
time.

Link: https://lore.kernel.org/r/20190731195713.3150463-13-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'ux500-v5.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson into arm/soc

This is a slew of Ux500 updates for the v5.4 kernel cycle:

- Stop populating the PRCMU devices from the core CPU
  file, it works just fine at device_initcall() level.

- Add a missing of_node_put() in the core file.

- Simplify the debug UART code.

- Add myself to MAINTAINERS

* tag 'ux500-v5.4-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson:
  MAINTAINERS: add soc/ux500
  ARM: ux500: simplify and move debug UART
  ARM: ux500: add missing of_node_put()
  ARM: ux500: Stop populating the PRCMU devices early

Link: https://lore.kernel.org/r/CACRpkdbH-h5fRwuidcpeOp8mtRoKUW65SAk8a4A==BCDzn3QMA@mail.gmail.comSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Various bits of iop32x are now in their traditional locations in plat-iop,
mach-iop/include/mach/ and in include/asm/mach/hardware. As nothing
outside of the iop32x mach code references these any more, this can all
be moved into one place now.

The only remaining things in the include/mach/ directory are now the
NR_IRQS definition, the entry-macros.S file and the the decompressor
uart access. After the irqchip code has been converted to SPARSE_IRQ
and GENERIC_IRQ_MULTI_HANDLER, it can be moved to ARCH_MULTIPLATFORM.

Link: https://lore.kernel.org/r/20190809163334.489360-7-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

All supported uarts use the same address: IQ80321_UART and IQ31244_UART
are both defined to the default value of 0xfe800000. By using that as
the address unconditionally, all dependencies on other machine headers
can be avoided.

Link: https://lore.kernel.org/r/20190809163334.489360-6-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Building a combined ARMv4+XScale kernel produces these
and other build failures:

/tmp/copypage-xscale-3aa821.s: Assembler messages:
/tmp/copypage-xscale-3aa821.s:167: Error: selected processor does not support `pld [r7,#0]' in ARM mode
/tmp/copypage-xscale-3aa821.s:168: Error: selected processor does not support `pld [r7,#32]' in ARM mode
/tmp/copypage-xscale-3aa821.s:169: Error: selected processor does not support `pld [r1,#0]' in ARM mode
/tmp/copypage-xscale-3aa821.s:170: Error: selected processor does not support `pld [r1,#32]' in ARM mode
/tmp/copypage-xscale-3aa821.s:171: Error: selected processor does not support `pld [r7,#64]' in ARM mode
/tmp/copypage-xscale-3aa821.s:176: Error: selected processor does not support `ldrd r4,r5,[r7],#8' in ARM mode
/tmp/copypage-xscale-3aa821.s:180: Error: selected processor does not support `strd r4,r5,[r1],#8' in ARM mode

Add an explict .arch armv5 in the inline assembly to allow the ARMv5
specific instructions regardless of the compiler -march= target.

Link: https://lore.kernel.org/r/20190809163334.489360-5-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

Now that iop3xx and iop13xx are gone, the iop-adma driver no
longer needs to deal with incompatible register layout defined
in machine specific header files.

Move the iop32x specific definitions into drivers/dma/iop-adma.h
and the platform_data into include/linux/platform_data/dma-iop32x.h,
and change the machine code to no longer reference those.

The DMA0_ID/DMA1_ID/AAU_ID macros are required as part of the
platform data interface and still need to be visible, so move
those from one header to the other.

Link: https://lore.kernel.org/r/20190809163334.489360-4-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>

When compile-testing on other architectures, we get lots of warnings
about incorrect format strings, like:

   drivers/dma/iop-adma.c: In function 'iop_adma_alloc_slots':
   drivers/dma/iop-adma.c:307:6: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'dma_addr_t {aka long long unsigned int}' [-Wformat=]

   drivers/dma/iop-adma.c: In function 'iop_adma_prep_dma_memcpy':
>> drivers/dma/iop-adma.c:518:40: warning: format '%u' expects argument of type 'unsigned int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=]

Use %zu for printing size_t as required, and cast the dma_addr_t
arguments to 'u64' for printing with %llx. Ideally this should use
the %pad format string, but that requires an lvalue argument that
doesn't work here.

Link: https://lore.kernel.org/r/20190809163334.489360-3-arnd@arndb.deSigned-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Compile-testing this driver fails on m68k without the
extra header inclusion.

Link: https://lore.kernel.org/r/20190809163334.489360-2-arnd@arndb.deReported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>