Merge tag 'sunxi-fixes-for-4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes

Pull "Allwinner fixes for 4.15" from Chen-Yu Tsai:

First, one fix that adds proper regulator references for the EMAC
external PHYs on A64 boards. The EMAC bindings were developed for 4.13,
but reverted at the last minute. They were finalized and brought back
for 4.15. However in the time between, regulator support for the A64
boards was merged. When EMAC device tree changes were reintroduced,
this was not taken into account.

Second, a patch that adds OF based modalias uevent for RSB slave devices.
This has been missing since the introduction of RSB, and recently with
PMIC regulator support introduced for the A64, has been seen affecting
distributions, which have the all-important PMIC mfd drivers built as
modules, which then don't get loaded.

Other minor cleanups include final conversion of raw indices to CCU
binding macros for sun[4567]i HDMI, cleanup of dummy regulators on the
A64 SOPINE, a SD card detection polarity fix for the Orange Pi Zero
Plus2, and adding a missing compatible for the PMIC on the TBS A711
tablet.

* tag 'sunxi-fixes-for-4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
  ARM: dts: sun8i: a711: Reinstate the PMIC compatible
  arm64: dts: orange-pi-zero-plus2: fix sdcard detect
  arm64: allwinner: a64-sopine: Fix to use dcdc1 regulator instead of vcc3v3
  ARM: dts: sunxi: Convert to CCU index macros for HDMI controller
  sunxi-rsb: Include OF based modalias in device uevent
  arm64: allwinner: a64: add Ethernet PHY regulator for several boards

Merge tag 'renesas-fixes-for-v4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas into fixes

Pull "Renesas ARM Based SoC Fixes for v4.15" from Simon Horman:

Vladimir Zapolskiy says:

The present change is a bug fix for AVB link iteratively up/down.

Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
  without user interaction,
- this may heal after some seconds or even stay for minutes.

As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.

Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
  the RX & TX are enabled/disabled directly from adjust_link function
  without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
  HW interrogation. The HW check is made through the LMON pin in PSR
  register which specifies AVB_LINK signal value (0 - at low level;
  1 - at high level).

In conclusion, the change is also a safety improvement because it
removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.

Note that DTS files for V3M Starter Kit, Draak and Eagle boards
contain the same property, the files are untouched due to unavailable
schematics to verify if the fix applies to these boards as well.

* tag 'renesas-fixes-for-v4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
  arm64: dts: renesas: ulcb: Remove renesas, no-ether-link property
  arm64: dts: renesas: salvator-x: Remove renesas, no-ether-link property

The present change is a bug fix for AVB link iteratively up/down.

Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
  without user interaction,
- this may heal after some seconds or even stay for minutes.

As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.

Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
  the RX & TX are enabled/disabled directly from adjust_link function
  without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
  HW interrogation. The HW check is made through the LMON pin in PSR
  register which specifies AVB_LINK signal value (0 - at low level;
  1 - at high level).

In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.

Fixes: dc36965a ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
Fixes: 6fa501c5 ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

The present change is a bug fix for AVB link iteratively up/down.

Steps to reproduce:
- start AVB TX stream (Using aplay via MSE),
- disconnect+reconnect the eth cable,
- after a reconnection the eth connection goes iteratively up/down
  without user interaction,
- this may heal after some seconds or even stay for minutes.

As the documentation specifies, the "renesas,no-ether-link" option
should be used when a board does not provide a proper AVB_LINK signal.
There is no need for this option enabled on RCAR H3/M3 Salvator-X/XS
and ULCB starter kits since the AVB_LINK is correctly handled by HW.

Choosing to keep or remove the "renesas,no-ether-link" option will
have impact on the code flow in the following ways:
- keeping this option enabled may lead to unexpected behavior since
  the RX & TX are enabled/disabled directly from adjust_link function
  without any HW interrogation,
- removing this option, the RX & TX will only be enabled/disabled after
  HW interrogation. The HW check is made through the LMON pin in PSR
  register which specifies AVB_LINK signal value (0 - at low level;
  1 - at high level).

In conclusion, the present change is also a safety improvement because
it removes the "renesas,no-ether-link" option leading to a proper way
of detecting the link state based on HW interrogation and not on
software heuristic.

Fixes: dc36965a ("arm64: dts: r8a7796: salvator-x: Enable EthernetAVB")
Fixes: 6fa501c5 ("arm64: dts: r8a7795: enable EthernetAVB on Salvator-X")
Signed-off-by: Bogdan Mirea <Bogdan-Stefan_Mirea@mentor.com>
Signed-off-by: Vladimir Zapolskiy <vladimir_zapolskiy@mentor.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

dtc points out that the parent node of the interrupt controllers is not
actually an interrupt controller itself, and lacks an #interrupt-cells
property:

arch/arm/boot/dts/tango4-vantage-1172.dtb: Warning (interrupts_property): Missing #interrupt-cells in interrupt-parent /soc/interrupt-controller@6e000

This removes the annotation.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

dtc warns about two 'clocks' properties that have an extraneous '1'
at the end:

arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a
arch/arm/boot/dts/ls1021a-qds.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2180000/mux@77/i2c@4/sgtl5000@2a:clocks[1])
Property 'clocks', cell 1 is not a phandle reference in /soc/i2c@2190000/sgtl5000@a
arch/arm/boot/dts/ls1021a-twr.dtb: Warning (clocks_property): Missing property '#clock-cells' in node /soc/interrupt-controller@1400000 or bad phandle (referred from /soc/i2c@2190000/sgtl5000@a:clocks[1])

The clocks that get referenced here are fixed-rate, so they do not
take any argument, and dtc interprets the next cell as a phandle, which
is invalid.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Merge tag 'davinci-fixes-for-v4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci into fixes

Pull "TI DaVinci fixes for v4.15" from Sekhar Nori:

DaVinci fixes for v4.15 consiting of fixes to make EDMA and MMC/SD
work on DM365 and a fix for battery voltage monitoring on Lego EV3.

* tag 'davinci-fixes-for-v4.15' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/nsekhar/linux-davinci:
  ARM: davinci: fix mmc entries in dm365's dma_slave_map
  ARM: dts: da850-lego-ev3: Fix battery voltage gpio
  ARM: davinci: Add dma_mask to dm365's eDMA device
  ARM: davinci: Use platform_device_register_full() to create pdev for dm365's eDMA

Merge tag 'at91-ab-4.15-dt-fixes' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/abelloni/linux into fixes

Pull "Fixes for 4.15:" from Alexandre Belloni:

 - tse850-3: fix an i2c timeout issue

* tag 'at91-ab-4.15-dt-fixes' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/abelloni/linux:
  ARM: dts: at91: disable the nxp,se97b SMBUS timeout on the TSE-850

Merge tag 'v4.15-rockchip-dts64fixes-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into fixes

Pull "Rockchip dts64 fixes for 4.15" from Heiko Stübner:

Another trailing interrupt-cell 0 removed.

Removed as well got the vdd_log regulator from the rk3399-puma board.
While it is there, the absence of any user makes it prone to configuration
problems when the pwm-regulator takes over the boot-up default and wiggles
settings there. Case in question was the PCIe host not working anymore.
With vdd_log removed for the time being, PCIe on Puma works again.

And a second stopgap is limiting the speed of the gmac on the rk3328-rock64
to 100MBit. While the hardware can reach 1GBit, currently it is not stable.
Limiting it to 100MBit for the time being allows nfsroots to be used again
until the problem is identified.

* tag 'v4.15-rockchip-dts64fixes-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
  arm64: dts: rockchip: limit rk3328-rock64 gmac speed to 100MBit for now
  arm64: dts: rockchip: remove vdd_log from rk3399-puma
  arm64: dts: rockchip: fix trailing 0 in rk3328 tsadc interrupts

Merge tag 'v4.15-rockchip-dts32fixes-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into fixes

Pull "Rockchip dts32 fixes for 4.15" from Heiko Stübner:

Removed another trailing interrupt-cell 0 and added the cpu regulator
on the rk3066a-marsboard to make it not fail from cpufreq changes.

* tag 'v4.15-rockchip-dts32fixes-1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
  ARM: dts: rockchip: fix rk3288 iep-IOMMU interrupts property cells
  ARM: dts: rockchip: add cpu0-regulator on rk3066a-marsboard

This should have always been 8.

Fixes: db4d6d9d ("ARM: dts: aspeed: Correctly order UART nodes")
Cc: stable@vger.kernel.org
Signed-off-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Commit 1cb686c0 ("ARM: dts: exynos: Add status property to Exynos 542x
Mixer nodes") disabled the Mixer node by default in the DTSI and enabled
for each Exynos 542x DTS. But unfortunately it missed to enable it for the
Exynos5800 Peach Pi machine, since the 5800 is also an 542x SoC variant.

Fixes: 1cb686c0 ("ARM: dts: exynos: Add status property to Exynos 542x Mixer nodes")
Signed-off-by: Javier Martinez Canillas <javierm@redhat.com>
Acked-by: Marek Szyprowski <m.szyprowski@samsung.com>
Tested-by: Guillaume Tucker <guillaume.tucker@collabora.com>
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

When we added the regulator support in commit 90c5d7cd ("ARM: dts:
sun8i: a711: Add regulator support"), we also dropped the PMIC's
compatible. Since it's not in the PMIC DTSI, unlike most other PMIC
DTSI, it obviously wasn't probing anymore.

Re-add it so that everything works again.

Fixes: 90c5d7cd ("ARM: dts: sun8i: a711: Add regulator support")
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Merge tag 'amlogic-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into fixes

Amlogic fixes for v4.15-rc
- GPIO interrupt fixes
- socinfo fix for GX series
- fix typo

* tag 'amlogic-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic:
  ARM64: dts: meson-gx: fix UART pclk clock name
  meson-gx-socinfo: Fix package id parsing
  ARM: meson: fix spelling mistake: "Couln't" -> "Couldn't"
  ARM: dts: meson: fix the memory region of the GPIO interrupt controller
  ARM: dts: meson: correct the sort order for the the gpio_intc node
Signed-off-by: Olof Johansson <olof@lixom.net>

bus: ARM CCN and CCI PMU driver fixes

This is a bunch of fixes CCN and (guest starring this time) CCI drivers.

* Check for potential of failed allocation for the driver name string
* Manage CPU ID properly at allocation (both CCN and CCI)
* Fix module unload warnings related to objects release order
* Small improvements like using allocating printfs and proper
  attributes constification

The one fixing potential issues have been cc-ed to stable.

* tag 'ccn/fixes-for-4.15' of git://git.linaro.org/people/pawel.moll/linux:
  bus: arm-ccn: fix module unloading Error: Removing state 147 which has instances left.
  bus: arm-cci: Fix use of smp_processor_id() in preemptible context
  bus: arm-ccn: Fix use of smp_processor_id() in preemptible context
  bus: arm-ccn: Simplify code
  bus: arm-ccn: Check memory allocation failure
  bus: arm-ccn: constify attribute_group structures.
Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'omap-for-v4.15/fixes-dt-warnings' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes

Two fixes for dts compiler warnings

These recently started showing up with better dtc checks being
introduced.

* tag 'omap-for-v4.15/fixes-dt-warnings' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: dts: Fix dm814x missing phy-cells property
  ARM: dts: Fix elm interrupt compiler warning
Signed-off-by: Olof Johansson <olof@lixom.net>

The clock-names for pclk was wrongly set to "core", but the bindings
specifies "pclk".
This was not cathed until the legacy non-documented bindings were removed.
Reported-by: Andreas Färber <afaerber@suse.de>
Fixes: f72d6f60 ("ARM64: dts: meson-gx: use stable UART bindings with correct gate clock")
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>

fix mmc entries in dm365's dma_slave_map to match the actual device names

Fixes: 0c750e1f ("ARM: davinci: dm365: Add dma_slave_map to edma")
Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

In configurations without CONFIG_OMAP3 but with secure RAM support,
we now run into a link failure:

arch/arm/mach-omap2/omap-secure.o: In function `omap3_save_secure_ram':
omap-secure.c:(.text+0x130): undefined reference to `save_secure_ram_context'

The omap3_save_secure_ram() function is only called from the OMAP34xx
power management code, so we can simply hide that function in the
appropriate #ifdef.

Fixes: d09220a8 ("ARM: OMAP2+: Fix SRAM virt to phys translation for save_secure_ram_context")
Acked-by: Tony Lindgren <tony@atomide.com>
Tested-by: Dan Murphy <dmurphy@ti.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

"usb-nop-xceiv" is using the phy binding, but is missing #phy-cells
property. This is probably because the binding was the precursor to the phy
binding.

Fixes the following warning in nspire dts files:

Warning (phys_property): Missing property '#phy-cells' in node ...
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

This fixes the battery voltage monitoring gpio-hog settings.

When the gpio is low, it turns off the battery voltage to the ADC chip.
However, this needs to be on all of the time so that we can monitor
battery voltage.

Also, there was a typo that prevented pinmuxing from working correctly.
Signed-off-by: David Lechner <david@lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

Add dma_mask to dm365's EDMA device.

Without a valid dma_mask, EDMA on DM365 refuses to
probe.

Fixes: cef5b0da ("ARM: davinci: Add dma_mask to eDMA devices")
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

Convert the DM365 EDMA platform device creation to use
struct platform_device_info XXXXXX __initconst and
platform_device_register_full()

This will allow us to specify the dma_mask for the device
in an upcoming patch. Without this, EDMA on DM365 refuses
to probe.

Fixes: 7ab388e8 ("ARM: davinci: Use platform_device_register_full() to create pdev for eDMA")
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>

It looks like either the current kernel or the hardware has reliability
issues when the gmac is actually running at 1GBit. In my test-case
it is not able to boot on a nfsroot at this speed, as the system
will always lose the connection to the nfs-server during boot, before
reaching any login prompt and not recover from this.

So until this is solved, limit the speed to 100MBit as with this the
nfsroot survives stress tests like an apt-get upgrade without problems.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

vdd_log has no consumer and therefore will not be set to a specific
voltage. Still the PWM output pin gets configured and thence the vdd_log
output voltage will changed from it's default. Depending on the idle
state of the PWM this will slightly over or undervoltage the logic supply
of the RK3399 and cause instability with GbE (undervoltage) and PCIe
(overvoltage). Since the default value set by a voltage divider is the
correct supply voltage and we don't need to change it during runtime we
remove the rail from the devicetree completely so the PWM pin will not
be configured.
Signed-off-by: Klaus Goger <klaus.goger@theobroma-systems.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

We have phy-cells for usb_phy0, but it's missing for usb_phy1 and we get:

Warning (phys_property): Missing property '#phy-cells' in node
/ocp/l4ls@48000000/control@140000/usb-phy@1b00 or bad phandle
(referred from /ocp/usb@47400000/usb@47401800:phys[0])
Signed-off-by: Tony Lindgren <tony@atomide.com>

Looks like the interrupt property is missing the controller and level
information causing:

Warning (interrupts_property): interrupts size is (4), expected multiple
of 12 in /ocp/elm@48078000
Signed-off-by: Tony Lindgren <tony@atomide.com>

The sdcard detect pin on orange-pi-zero-plus2 is pulled up.
Fix cd-gpio description to enable sdcard detect.
Signed-off-by: Sergey Matyukevich <geomatsi@gmail.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Since current tree support AXP803 regulators,
replace fixed regulator vcc3v3 with AXP803 dcdc1 regulator where ever
it need to replace.

Tested mmc0 on sopine baseboard.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

When the HDMI controller device node was added, the needed PLL clock
macros were not exported. A separate patch addresses that, but it is
merged through a different tree.

Now that both patches are in mainline proper, we can convert the raw
numbers to proper macros.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

Include the OF-based modalias in the uevent sent when registering devices
on the sunxi RSB bus, so that user space has a chance to autoload the
kernel module for the device.

Fixes a regression caused by commit 3f241bfa ("arm64: allwinner: a64:
pine64: Use dcdc1 regulator for mmc0"). When the axp20x-rsb module for
the AXP803 PMIC is built as a module, it is not loaded and the system
ends up with an disfunctional MMC controller.

Fixes: d787dcdb ("bus: sunxi-rsb: Add driver for Allwinner Reduced Serial Bus")
Cc: stable <stable@vger.kernel.org> # 4.4.x 7a3b7cd3 of: device: Export of_device_{get_modalias, uvent_modalias} to modules
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Stefan Brüns <stefan.bruens@rwth-aachen.de>
Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>

The I2C adapter driver is sometimes slow, causing the SCL line to
be stuck low for more than the stipulated SMBUS timeout of 25-35 ms.
This causes the client device to give up which in turn causes silent
corruption of data. So, disable the SMBUS timeout in the client device.
Signed-off-by: Peter Rosin <peda@axentia.se>
Acked-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

Probably due to some copy-paste mistake, the tsadc of rk3328 ended up
with a 0 as 4th element that shouldn't be there, as interrupts on the
rk3328 only have multiples of 3, making dtc complain. So remove it.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

Unregistering the driver before calling cpuhp_remove_multi_state() removes
any remaining hotplug cpu instances so __cpuhp_remove_state_cpuslocked()
doesn't emit this warning:

[  268.748362] Error: Removing state 147 which has instances left.
[  268.748373] ------------[ cut here ]------------
[  268.748386] WARNING: CPU: 2 PID: 5476 at kernel/cpu.c:1734 __cpuhp_remove_state_cpuslocked+0x454/0x4f0
[  268.748389] Modules linked in: arm_ccn(-) [last unloaded: arm_ccn]
[  268.748403] CPU: 2 PID: 5476 Comm: rmmod Tainted: G        W       4.14.0-rc4+ #3
[  268.748406] Hardware name: AMD Seattle/Seattle, BIOS 10:18:39 Dec  8 2016
[  268.748410] task: ffff8001a18ca000 task.stack: ffff80019c120000
[  268.748416] PC is at __cpuhp_remove_state_cpuslocked+0x454/0x4f0
[  268.748421] LR is at __cpuhp_remove_state_cpuslocked+0x448/0x4f0
[  268.748425] pc : [<ffff2000081729ec>] lr : [<ffff2000081729e0>] pstate: 60000145
[  268.748427] sp : ffff80019c127d30
[  268.748430] x29: ffff80019c127d30 x28: ffff8001a18ca000
[  268.748437] x27: ffff20000c2cb000 x26: 1fffe4000042d490
[  268.748443] x25: ffff20000216a480 x24: 0000000000000000
[  268.748449] x23: ffff20000b08e000 x22: 0000000000000001
[  268.748455] x21: 0000000000000093 x20: 00000000000016f8
[  268.748460] x19: ffff20000c2cbb80 x18: 0000ffffb5fe7c58
[  268.748466] x17: 00000000004402d0 x16: 1fffe40001864f01
[  268.748472] x15: ffff20000c4bf8b0 x14: 0000000000000000
[  268.748477] x13: 0000000000007032 x12: ffff20000829ae48
[  268.748483] x11: ffff20000c4bf000 x10: 0000000000000004
[  268.748488] x9 : 0000000000006fbc x8 : ffff20000c318a40
[  268.748494] x7 : 0000000000000000 x6 : ffff040001864f02
[  268.748500] x5 : 0000000000000000 x4 : 0000000000000000
[  268.748505] x3 : 0000000000000007 x2 : dfff200000000000
[  268.748510] x1 : 000000000000ad3d x0 : 00000000000001f0
[  268.748516] Call trace:
[  268.748521] Exception stack(0xffff80019c127bf0 to 0xffff80019c127d30)
[  268.748526] 7be0:                                   00000000000001f0 000000000000ad3d
[  268.748531] 7c00: dfff200000000000 0000000000000007 0000000000000000 0000000000000000
[  268.748535] 7c20: ffff040001864f02 0000000000000000 ffff20000c318a40 0000000000006fbc
[  268.748539] 7c40: 0000000000000004 ffff20000c4bf000 ffff20000829ae48 0000000000007032
[  268.748544] 7c60: 0000000000000000 ffff20000c4bf8b0 1fffe40001864f01 00000000004402d0
[  268.748548] 7c80: 0000ffffb5fe7c58 ffff20000c2cbb80 00000000000016f8 0000000000000093
[  268.748553] 7ca0: 0000000000000001 ffff20000b08e000 0000000000000000 ffff20000216a480
[  268.748557] 7cc0: 1fffe4000042d490 ffff20000c2cb000 ffff8001a18ca000 ffff80019c127d30
[  268.748562] 7ce0: ffff2000081729e0 ffff80019c127d30 ffff2000081729ec 0000000060000145
[  268.748566] 7d00: 00000000000001f0 0000000000000000 0001000000000000 0000000000000000
[  268.748569] 7d20: ffff80019c127d30 ffff2000081729ec
[  268.748575] [<ffff2000081729ec>] __cpuhp_remove_state_cpuslocked+0x454/0x4f0
[  268.748580] [<ffff200008172adc>] __cpuhp_remove_state+0x54/0x80
[  268.748597] [<ffff20000215dd84>] arm_ccn_exit+0x2c/0x70 [arm_ccn]
[  268.748604] [<ffff20000834cfbc>] SyS_delete_module+0x5a4/0x708
[  268.748607] Exception stack(0xffff80019c127ec0 to 0xffff80019c128000)
[  268.748612] 7ec0: 0000000019bb7258 0000000000000800 ba64d0fb3d26a800 00000000000000da
[  268.748616] 7ee0: 0000ffffb6144e28 0000ffffcd95b409 fefefefefefefeff 7f7f7f7f7f7f7f7f
[  268.748621] 7f00: 000000000000006a 1999999999999999 0000ffffb6179000 0000000000bbcc6d
[  268.748625] 7f20: 0000ffffb6176b98 0000ffffcd95c2d0 0000ffffb5fe7b58 0000ffffb6163000
[  268.748630] 7f40: 0000ffffb60ad3e0 00000000004402d0 0000ffffb5fe7c58 0000000019bb71f0
[  268.748634] 7f60: 0000ffffcd95c740 0000000000000000 0000000019bb71f0 0000000000416700
[  268.748639] 7f80: 0000000000000000 00000000004402e8 0000000019bb6010 0000ffffcd95c748
[  268.748643] 7fa0: 0000000000000000 0000ffffcd95c460 00000000004113a8 0000ffffcd95c460
[  268.748648] 7fc0: 0000ffffb60ad3e8 0000000080000000 0000000019bb7258 000000000000006a
[  268.748652] 7fe0: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
[  268.748657] [<ffff200008084f9c>] __sys_trace_return+0x0/0x4
[  268.748661] ---[ end trace a996d358dcaa7f9c ]---

Fixes: 8df03872 ("bus/arm-ccn: Use cpu-hp's multi instance support instead custom list")
Signed-off-by: Kim Phillips <kim.phillips@arm.com>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: stable@vger.kernel.org # 4.8+
Signed-off-by: Pawel Moll <pawel.moll@arm.com>

The ARM CCI driver seem to be using smp_processor_id() in a
preemptible context, which is likely to make a DEBUG_PREMPT
kernel scream at boot time.

Turn this into a get_cpu()/put_cpu() that extends over the CPU
hotplug registration, making sure that we don't race against
a CPU down operation.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: stable@vger.kernel.org # 4.2+
Signed-off-by: Pawel Moll <pawel.moll@arm.com>

Booting a DEBUG_PREEMPT enabled kernel on a CCN-based system
results in the following splat:

[...]
arm-ccn e8000000.ccn: No access to interrupts, using timer.
BUG: using smp_processor_id() in preemptible [00000000] code: swapper/0/1
caller is debug_smp_processor_id+0x1c/0x28
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 4.13.0 #6111
Hardware name: AMD Seattle/Seattle, BIOS 17:08:23 Jun 26 2017
Call trace:
[<ffff000008089e78>] dump_backtrace+0x0/0x278
[<ffff00000808a22c>] show_stack+0x24/0x30
[<ffff000008bc3bc4>] dump_stack+0x8c/0xb0
[<ffff00000852b534>] check_preemption_disabled+0xfc/0x100
[<ffff00000852b554>] debug_smp_processor_id+0x1c/0x28
[<ffff000008551bd8>] arm_ccn_probe+0x358/0x4f0
[...]

as we use smp_processor_id() in the wrong context.

Turn this into a get_cpu()/put_cpu() that extends over the CPU hotplug
registration, making sure that we don't race against a CPU down operation.
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Cc: stable@vger.kernel.org # 4.2+
Signed-off-by: Pawel Moll <pawel.moll@arm.com>

Use 'devm_kasprintf()' to simplify the code.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>

Check memory allocation failures and return -ENOMEM in such cases

This avoids a potential NULL pointer dereference.
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Acked-by: Scott Branden <scott.branden@broadcom.com>
Cc: stable@vger.kernel.org # 3.17+
Signed-off-by: Pawel Moll <pawel.moll@arm.com>

attribute_groups are not supposed to change at runtime. All functions
working with attribute_groups provided by <linux/sysfs.h> work with const
attribute_group. So mark the non-const structs as const.

File size before:
   text	   data	    bss	    dec	    hex	filename
   9074	   5592	    416	  15082	   3aea	drivers/bus/arm-ccn.o

File size After adding 'const':
   text	   data	    bss	    dec	    hex	filename
   9327	   5336	    416	  15079	   3ae7	drivers/bus/arm-ccn.o
Signed-off-by: Arvind Yadav <arvind.yadav.cs@gmail.com>
Signed-off-by: Pawel Moll <pawel.moll@arm.com>

The interrupts property in the iep-IOMMU node for the rk3288 dts file has a
spurious extra cell causing a dtc warning:

Warning (interrupts_property): interrupts size is (16), expected multiple of 12 in /iommu@ff900800

Remove the extra cell.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>