58456 Commits

Author SHA1 Message Date
Adam Ford
6cb0ac0fb9 ARM: dts: ARM: dts: Configure interconnect target module for am3517sgx
Based on Tony Lindgren's work for omap34xx, this patch applies the same
functionality to the AM3517.

The following can be tested via sysfs with the following to ensure the SGX
module gets enabled and disabled properly:

0x00010201

Bus error

Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: moaz korena <moaz@korena.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Philipp Rossak <embed3d@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Adam Ford <aford173@gmail.com>
[tony@atomide.com: updated subject, dropped rstctrl info]
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:47:09 -07:00
Tony Lindgren
3b72fc895a ARM: dts: Configure interconnect target module for omap3 sgx
Looks like omap34xx OCP registers are not readable unlike on omap36xx.
We use SGX revision register instead of the OCP revision register for
34xx and do not configure any SYSCONFIG register unlike for 36xx.

I've tested that the interconnect target module enables and idles
just fine with PM runtime control via sys:

# echo on > $(find /sys -name control | grep \/5000); rwmem 0x5000fe10
# rwmem 0x50000014	# SGX revision register on 36xx
0x50000014 = 0x00010205
# echo auto > $(find /sys -name control | grep \/5000)
# rwmem 0x5000fe00
And when idled, it will produce "Bus error" as expected.

Cc: Adam Ford <aford173@gmail.com>
Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: moaz korena <moaz@korena.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Philipp Rossak <embed3d@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Adam Ford <aford173@gmail.com> #logicpd-torpedo-37xx-devkit
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:47:08 -07:00
Tony Lindgren
394534cb07 ARM: dts: Configure sgx for omap5
I've tested that the interconnect target module enables and idles
just fine when probed with ti-sysc with PM runtime control via sys:

# echo on > $(find /sys -name control | grep \/5600)
# rwmem 0x5600fe00	# OCP Revision
0x5600fe00 = 0x40000000
# echo auto > $(find /sys -name control | grep \/5600)
# rwmem 0x5600fe10
# rwmem 0x56000024

Cc: Adam Ford <aford173@gmail.com>
Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: moaz korena <moaz@korena.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Philipp Rossak <embed3d@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:47:08 -07:00
Tony Lindgren
1b95c5a48f ARM: OMAP2+: Drop legacy platform data for omap4 gpu
I've tested that the interconnect target module enables and idles
just fine when probed with ti-sysc with PM runtime control via sys:

# echo on > $(find /sys -name control | grep \/5601)
# rwmem 0x56000024
0x56000024 = 0x00010200		# SGX540 CORE_REVISION
# echo auto > $(find /sys -name control | grep \/5601)
# rwmem 0x56000024
And when idled, it will produce "Bus error" as expected.

Cc: Adam Ford <aford173@gmail.com>
Cc: Filip Matijević <filip.matijevic.pz@gmail.com>
Cc: "H. Nikolaus Schaller" <hns@goldelico.com>
Cc: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
Cc: moaz korena <moaz@korena.xyz>
Cc: Merlijn Wajer <merlijn@wizzup.org>
Cc: Paweł Chmiel <pawel.mikolaj.chmiel@gmail.com>
Cc: Philipp Rossak <embed3d@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:47:07 -07:00
Tony Lindgren
af055ade34 ARM: OMAP2+: Drop legacy platform data for omap4 d2d
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.

As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.

Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:41:17 -07:00
Tony Lindgren
d73d7667bb ARM: dts: Configure d2d dts data for omap4
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's configure the related dts data based on what we have
defined in the legacy platform data.

Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:41:16 -07:00
Tony Lindgren
84087b3d63 ARM: OMAP2+: Drop legacy watchdog platform data for omap4
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property.

As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.

Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:41:16 -07:00
Tony Lindgren
e47f534dae ARM: dts: Drop custom hwmod property for omap4 i2c
We can now probe devices with ti-sysc interconnect driver and dts
data. Let's drop the custom ti,hwmods dts property. We have already
dropped the platform data earlier and have been allocating it
dynamically.

Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:41:16 -07:00
Tony Lindgren
3f95f51b16 ARM: OMAP2+: Drop legacy platform data for cpsw on dra7
We can now probe cpsw with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property for am3 and am4.

As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.

Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:41:15 -07:00
Tony Lindgren
7abe746191 ARM: OMAP2+: Drop legacy platform data for cpsw on am3 and am4
We can now probe cpsw with ti-sysc interconnect driver and dts
data. Let's drop the related platform data and custom ti,hwmods
dts property for am3 and am4.

As we're just dropping data, and the early platform data init
is based on the custom ti,hwmods property, we want to drop both
the platform data and ti,hwmods property in a single patch.

Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:41:15 -07:00
Tony Lindgren
1faa415c9c ARM: dts: Add fck for cpsw mdio for omap variants
In preparation for dropping legacy platform data and custom ti,hwmods
property, we need to make functional clock available for mdio for the
SoCs so the the mdio driver can find it.

The mdio hardware currently relies on a mdio_hwmod to manage the clock
for omap variants. This is wrong though as there are no separate
sysconfig registers for mdio. All the cpsw related components are just
children of the gmac module.

Note that since mdio is a child of cpsw, just doing pm_runtime_get()
in the mdio driver enables the clock. However, since mdio is also used
by davinci that does not implement runtime PM, let's just add the fck
for now.

Also note that am437x mdio already has a clock, let's update it to
not use the legacy clock naming to unify things further.

Cc: Grygorii Strashko <grygorii.strashko@ti.com>
Cc: Ivan Khoronzhuk <ivan.khoronzhuk@linaro.org>
Cc: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
2019-08-26 08:41:14 -07:00
Bartosz Golaszewski
9c65754cd3 ARM: davinci: da850-evm: switch to using a fixed regulator for lcdc
Now that the da8xx fbdev driver supports power control with an actual
regulator, switch to using a fixed power supply for da850-evm.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-08-26 17:53:57 +05:30
Bartosz Golaszewski
7b5ab64379 ARM: davinci: da850-evm: model the backlight GPIO as an actual device
Instead of enabling the panel backlight in a callback defined in board
file using deprecated legacy GPIO API calls, model the line as a GPIO
backlight device.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-08-26 17:53:56 +05:30
Christophe JAILLET
93eae12c9f ARM: davinci: dm646x: Fix a typo in the comment
The driver is dedicated to DM646x. So update the description in the top
most comment accordingly.

It must have been derived from dm644x.c, but looks DM646 speecific now.

Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-08-26 17:51:28 +05:30
Adam Ford
01cc0596ef ARM: dts: da850-evm: Use generic jedec, spi-nor for flash
Logic PD re-spun the L138 and AM1808 SOM's with larger flash.
The m25p80 driver has a generic 'jedec,spi-nor' compatible option
which is requests to use whenever possible since it will read the
JEDEC READ ID opcode.

Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-08-26 17:50:30 +05:30
Bartosz Golaszewski
d7d91d2647 ARM: davinci: dm646x: switch to using the clocksource driver
We now have a proper clocksource driver for davinci. Switch the dm646x
platform to using it.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-08-26 17:49:07 +05:30
Bartosz Golaszewski
135ce780b7 ARM: davinci: dm644x: switch to using the clocksource driver
We now have a proper clocksource driver for davinci. Switch the dm644x
platform to using it.

Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Reviewed-by: David Lechner <david@lechnology.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
2019-08-26 17:49:07 +05:30
Christoph Hellwig
b898e50f9f arm-nommu: remove the unused pgprot_dmacoherent define
Signed-off-by: Christoph Hellwig <hch@lst.de>
2019-08-26 09:13:18 +02:00
Joel Stanley
87dfe49691 ARM: aspeed: Enable SMP boot
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>
2019-08-25 23:26:52 +09:30
Joel Stanley
9afe2c0a37 ARM: aspeed: Add ASPEED AST2600 architecture
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>
2019-08-25 23:26:50 +09:30
Joel Stanley
e35d7db994 ARM: aspeed: Select timer in each SoC
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>
2019-08-25 23:26:48 +09:30
Joel Stanley
4cdabee7d6 ARM: configs: aspeed_g5: Enable AST2600
CONFIG_STRICT_KERNEL_RWX is enabled by default with ARMv7.

Turn on HIGHMEM as the EVB has 2GB of RAM, and not all is usable without
hihgmem.

The SoC contains Cortex A7 supporting VFP and has two CPUs.

Acked-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
2019-08-25 23:22:54 +09:30
Joel Stanley
e6fe57ebd5 ARM: configs: multi_v7: Add ASPEED G6
This adds the ASPEED AST2600 system and associated ASPEED devices so we
get build coverage.

The changes to the UART configuration to ensure the default console
(UART5) works.

Acked-by: Andrew Jeffery <andrew@aj.id.au>
Signed-off-by: Joel Stanley <joel@jms.id.au>
2019-08-25 23:22:52 +09:30
Andrey Smirnov
b04f537caa ARM: dts: vf610-zii-scu4-aib: Configure IRQ line for GPIO expander
Configure IRQ line for SX1503 GPIO expander. We already have
appropriate pinmux entry and all that is missing is "interrupt-parent"
and "interrupts" properties. Add them.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Cory Tusar <cory.tusar@zii.aero>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Tested-by: Chris Healy <cphealy@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-25 09:15:17 +02:00
Linus Torvalds
e67095fd2f dma-mapping fixes for 5.3-rc
Two fixes for regressions in this merge window:
 
  - select the Kconfig symbols for the noncoherent dma arch helpers
    on arm if swiotlb is selected, not just for LPAE to not break then
    Xen build, that uses swiotlb indirectly through swiotlb-xen
  - fix the page allocator fallback in dma_alloc_contiguous if the CMA
    allocation fails
 -----BEGIN PGP SIGNATURE-----
 
 iQI/BAABCgApFiEEgdbnc3r/njty3Iq9D55TZVIEUYMFAl1hvn4LHGhjaEBsc3Qu
 ZGUACgkQD55TZVIEUYON4w//Recfoy5T2Q4Gfjp1xVKGbr2sP7J93Vs7VCyQNZmX
 PrtzhmNKs4gxCEXVgHm+GVA+IJwQFqDtSFaPb8q3GQ+qM9NUDF4ScMFpfrLZsFr1
 dorm5kC1xcwrQtWjS1CQS/Gj0VBtWiMQOoUcAESMqgBIUo4ssj3Ny+vnh8hWgAOs
 oVDgOM4wt35bW0Pv/iY44uQzOq7xcYJUUYtPIiP9vMDrhPsxe6D1DgFQ4HZKJWix
 uS3BjZnsZDnLltXM/0CKdRV9wLF+jHYP/wJTztksRlr/A5V3FJ8lJIvgphxG1v3J
 tDfQs4BNuGWBjqdg+Qo6qOPEL9krvVYYVVql93DXwtPK/cJW1Z+0glgC2rbbHmIy
 ew35DFnYm9v0sFLZnbpuoHd6sQ9G59nTZstkqt/Z/hldBvKotwBpeuILAcMC9Nlw
 3iYW6Sz5L7cmkifC8OvopKKJWVoW5rVtMrVQw5niBiZVERtWbY825r/7ju2xYhZC
 iSAaUHT5wNtXsXQOTrFQ5LzTDBtgGyXRXgvNagEHhBf120jBQfOhvOCVT2HHOxdy
 5vx7xeeRS0M2HpxIsmd3XQjIUQEY9x1to4FKiYczGM1kcKeyWWBMFOXfLxe2Rmhg
 h14lbfsAxIEWdFkJAVFhjyjzC6IzxyVGtHCxw1iw0VgGzYATO/K6Oo8T2hG3HagR
 abQ=
 =DXk9
 -----END PGP SIGNATURE-----

Merge tag 'dma-mapping-5.3-5' of git://git.infradead.org/users/hch/dma-mapping

Pull dma-mapping fixes from Christoph Hellwig:
 "Two fixes for regressions in this merge window:

   - select the Kconfig symbols for the noncoherent dma arch helpers on
     arm if swiotlb is selected, not just for LPAE to not break then Xen
     build, that uses swiotlb indirectly through swiotlb-xen

   - fix the page allocator fallback in dma_alloc_contiguous if the CMA
     allocation fails"

* tag 'dma-mapping-5.3-5' of git://git.infradead.org/users/hch/dma-mapping:
  dma-direct: fix zone selection after an unaddressable CMA allocation
  arm: select the dma-noncoherent symbols for all swiotlb builds
2019-08-24 20:00:11 -07:00
Krzysztof Kozlowski
1ea4b76cdf ARM: dts: imx6ul-kontron-n6310: Add Kontron i.MX6UL N6310 SoM and boards
Add support for i.MX6UL modules from Kontron Electronics GmbH (before
acquisition: Exceet Electronics) and evalkit boards based on it:

1. N6310 SOM: i.MX6 UL System-on-Module, a 25x25 mm solderable module
   (LGA pads and pin castellations) with 256 MB RAM, 1 MB NOR-Flash,
   256 MB NAND and other interfaces,
2. N6310 S: evalkit, w/wo eMMC, without display,
3. N6310 S 43: evalkit with 4.3" display,

The work is based on Exceet/Kontron source code (GPLv2) with numerous
changes:
1. Reorganize files,
2. Rename Exceet -> Kontron,
3. Rename models/compatibles to match newest Kontron product naming,
4. Fix coding style errors and adjust to device tree coding guidelines,
5. Fix DTC warnings,
6. Extend compatibles so eval boards inherit the SoM compatible,
7. Use defines instead of GPIO and interrupt flag values,
8. Use proper vendor compatible for Macronix SPI NOR,
9. Replace deprecated bindings with proper ones,
10. Sort nodes alphabetically,
11. Remove Admatec display nodes (not yet supported).

Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24 22:45:47 +02:00
Andrey Smirnov
801592402c ARM: dts: vf610-zii-cfu1: Slow I2C0 down to 100 kHz
Fiber-optic modules attached to the bus are only rated to work at
100 kHz, so decrease the bus frequency to accommodate that.

Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Cc: Shawn Guo <shawnguo@kernel.org>
Cc: Chris Healy <cphealy@gmail.com>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24 21:24:45 +02:00
André Draszik
acf993a0f2 ARM: imx: stop adjusting ar8031 phy tx delay
Recent changes to the Atheros at803x driver cause
the approach taken here to stop working because
commit 6d4cd041f0af
("net: phy: at803x: disable delay only for RGMII mode")
and commit cd28d1d6e52e
("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>
2019-08-24 20:30:22 +02:00
Alexandre Belloni
929c11a55b ARM: dts: pbab01: correct rtc vendor
The rtc8564 is made by Epson but is similar to the NXP pcf8563. Use the
correct vendor name.

Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2019-08-24 20:19:33 +02:00
Masahiro Yamada
9fac85a6db ARM: at91: move platform-specific asm-offset.h to arch/arm/mach-at91
<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.com
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
2019-08-23 21:50:10 +02:00
Will Deacon
834020366d ARM: 8898/1: mm: Don't treat faults reported from cache maintenance as writes
Translation faults arising from cache maintenance instructions are
rather unhelpfully reported with an FSR value where the WnR field is set
to 1, indicating that the faulting access was a write. Since cache
maintenance instructions on 32-bit ARM do not require any particular
permissions, this can cause our private 'cacheflush' system call to fail
spuriously if a translation fault is generated due to page aging when
targetting a read-only VMA.

In this situation, we will return -EFAULT to userspace, although this is
unfortunately suppressed by the popular '__builtin___clear_cache()'
intrinsic provided by GCC, which returns void.

Although it's tempting to write this off as a userspace issue, we can
actually do a little bit better on CPUs that support LPAE, even if the
short-descriptor format is in use. On these CPUs, cache maintenance
faults additionally set the CM field in the FSR, which we can use to
suppress the write permission checks in the page fault handler and
succeed in performing cache maintenance to read-only areas even in the
presence of a translation fault.

Reported-by: Orion Hodson <oth@google.com>
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:39:34 +01:00
Geert Uytterhoeven
3e07590e72 ARM: 8896/1: VDSO: Don't leak kernel addresses
Since commit ad67b74d2469d9b8 ("printk: hash addresses printed with
%p"), an obfuscated kernel pointer is printed at every boot if
debugging is enabled:

    vdso: 1 text pages at base (____ptrval____)

Remove the print completely, as it's useless without the address.

Based on commit 0f1bf7e39822476b ("arm64/vdso: don't leak kernel
addresses").

Fixes: ad67b74d2469d9b8 ("printk: hash addresses printed with %p")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:39:32 +01:00
Masahiro Yamada
2a58e142a6 ARM: 8895/1: visit mach-* and plat-* directories when cleaning
When you run "make clean" for arm, it never visits mach-* or plat-*
directories because machine-y and plat-y are just empty.

When cleaning, all machine, plat directories are accumulated to
machine-, plat-, respectively. So, let's pass them to core- to
clean up those directories.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:39:31 +01:00
Linus Walleij
6583d8298e ARM: 8894/1: boot: Replace open-coded nop with macro
This open-coded nop as mov r0, r0 is a development history
artifact.

First commit b11fe38883d1
("ARM: 6663/1: make Thumb2 kernel entry point more similar
to the ARM one") moved the code around so that the nops
would come before the conditional thumb instructions, as it
turned out that some boot loaders were patching the initial
nop instructions in the kernel. At this point it is clear
that all mov r0,r0 are open-coded nops.

Then commit 81a0bc39ea19 ("ARM: add UEFI stub support")
moved things around and defined __nop for EFI support and
missed this open-coded nop.

commit 06a4b6d009a1
("ARM: 8677/1: boot/compressed: fix decompressor header
layout for v7-M") makes all invocations of __nop be wide,
but that is fine, because this is what we want: the
mov r0,r0 is inside ifndef CONFIG_THUMB2_KERNEL.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Acked-by: Roy Franz <rfranz@marvell.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:39:30 +01:00
Linus Walleij
20699a42c0 ARM: 8893/1: boot: Explain the 8 nops
This was unclear to me until Russell explained the obvious
that 8 nops are added to offset an a.out image. Reading
git history reveals that thumb kernels first removed the
nops and then kept 7 of them (the last instruction being
a switch to thumb mode) as it turns out that some boot
loaders were using this as a "patch area". Also the magic
numbers after the initial nops and the jump of course
need to stay in the same offset for kernel file
detection.

Make the code easier to understand with a comment.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
Acked-by: Roy Franz <rfranz@marvell.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:39:29 +01:00
Masahiro Yamada
3c86889b05 ARM: 8876/1: fix O= building with CONFIG_FPE_FASTFPE
To use Fastfpe, a user is supposed to enable CONFIG_FPE_FASTFPE
and put downstream source files into arch/arm/fastfpe/.

It is not working for O= build because $(wildcard arch/arm/fastfpe)
checks if it exists in $(objtree), not in $(srctree).

Add the $(srctree)/ prefix to fix it.

While I was here, I slightly refactored the code.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:38:49 +01:00
Nick Desaulniers
a05b960845 ARM: 8875/1: Kconfig: default to AEABI w/ Clang
Clang produces references to __aeabi_uidivmod and __aeabi_idivmod for
arm-linux-gnueabi and arm-linux-gnueabihf targets incorrectly when AEABI
is not selected (such as when OABI_COMPAT is selected).

While this means that OABI userspaces wont be able to upgraded to
kernels built with Clang, it means that boards that don't enable AEABI
like s3c2410_defconfig will stop failing to link in KernelCI when built
with Clang.

Link: https://github.com/ClangBuiltLinux/linux/issues/482
Link: https://groups.google.com/forum/#!msg/clang-built-linux/yydsAAux5hk/GxjqJSW-AQAJ

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:38:48 +01:00
Phong Tran
6f8f3570f2 ARM: 8873/1: perf: cleanup cppcheck shifting warning
There is error from cppcheck tool.
"Shifting signed 32-bit value by 31 bits is undefined behaviour errors"

This error is false positive.
change to use BIT() macro for improvement.

Signed-off-by: Phong Tran <tranmanphong@gmail.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:38:46 +01:00
Paul E. McKenney
fb2eca315d ARM: 8872/1: Use common outgoing-CPU-notification code
This commit removes the open-coded CPU-offline notification with new
common code.  In particular, this change avoids calling scheduler code
using RCU from an offline CPU that RCU is ignoring.  This is a minimal
change.  A more intrusive change might invoke the cpu_check_up_prepare()
and cpu_set_state_online() functions at CPU-online time, which would
allow onlining throw an error if the CPU did not go offline properly.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: linux-arm-kernel@lists.infradead.org
Tested-by: Dietmar Eggemann <dietmar.eggemann@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:38:45 +01:00
Nathan Chancellor
4af0149842 ARM: 8871/1: iop13xx: Simplify iop13xx_atu{e,x}_pci_status checks
clang warns:

arch/arm/mach-iop13xx/pci.c:292:7: warning: logical not is only applied
to the left hand side of this comparison [-Wlogical-not-parentheses]
                if (!iop13xx_atux_pci_status(1) == 0)
                    ^                           ~~
arch/arm/mach-iop13xx/pci.c:439:7: warning: logical not is only applied
to the left hand side of this comparison [-Wlogical-not-parentheses]
                if (!iop13xx_atue_pci_status(1) == 0)
                    ^                           ~~

!func() == 0 is equivalent to func(), which clears up this warning and
makes the code more readable.

Link: https://github.com/ClangBuiltLinux/linux/issues/543

Reported-by: Nick Desaulniers <ndesaulniers@google.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:38:44 +01:00
Lvqiang Huang
6938983717 ARM: 8897/1: check stmfd instruction using right shift
In the commit ef41b5c92498 ("ARM: make kernel oops easier to read"),
-               .word   0xe92d0000 >> 10        @ stmfd sp!, {}
+               .word   0xe92d0000 >> 11        @ stmfd sp!, {}
then the shift need to change to 11.

Signed-off-by: Lvqiang Huang <Lvqiang.Huang@unisoc.com>
Signed-off-by: Chunyan Zhang <zhang.lyra@gmail.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:32:37 +01:00
Doug Berger
c51bc12d06 ARM: 8874/1: mm: only adjust sections of valid mm structures
A timing hazard exists when an early fork/exec thread begins
exiting and sets its mm pointer to NULL while a separate core
tries to update the section information.

This commit ensures that the mm pointer is not NULL before
setting its section parameters. The arguments provided by
commit 11ce4b33aedc ("ARM: 8672/1: mm: remove tasklist locking
from update_sections_early()") are equally valid for not
requiring grabbing the task_lock around this check.

Fixes: 08925c2f124f ("ARM: 8464/1: Update all mm structures with section adjustments")
Signed-off-by: Doug Berger <opendmb@gmail.com>
Acked-by: Laura Abbott <labbott@redhat.com>
Cc: Mike Rapoport <rppt@linux.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Cc: Peng Fan <peng.fan@nxp.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
2019-08-23 11:32:36 +01:00
Maxime Ripard
9e1975f0bc
ARM: dts: sunxi: Add missing watchdog clocks
The watchdog has a clock on all our SoCs, but it wasn't always listed.
Add it to the devicetree where it's missing.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-08-23 12:02:07 +02:00
Maxime Ripard
89d1e51462
ARM: dts: sunxi: Add missing watchdog interrupts
The watchdog has an interrupt on all our SoCs, but it wasn't always listed.
Add it to the devicetree where it's missing.

Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-08-23 12:02:05 +02:00
Maxime Ripard
d2b9c64443
ARM: dts: sun7i: Add CSI0 controller
The CSI controller embedded in the A20 can be supported by our new driver.
Let's add it to our DT.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-08-23 09:47:26 +02:00
Maxime Ripard
18742b249e
ARM: dts: v3s: Change the timers compatible
Unlike the A10 that has 6 timers available, the v3s has only three, with only
three interrupts. Let's change the compatible to reflect that, and add the
missing interrupts.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-08-23 09:14:50 +02:00
Maxime Ripard
19aeb5a80c
ARM: dts: h3: Change the timers compatible
Unlike the A10 that has 6 timers available, the H3 has only two, with only
two interrupts, just like the A23. Let's change the compatible to reflect
that.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-08-23 09:14:50 +02:00
Maxime Ripard
df75eaac49
ARM: dts: a83t: Change the timers compatible
Unlike the A10 that has 6 timers available, the A83t has only two, with
only two interrupts, just like the A23. Let's change the compatible to
reflect that.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-08-23 09:14:50 +02:00
Maxime Ripard
2b9df83fa6
ARM: dts: a23/a33: Change the timers compatible
Unlike the A10 that has 6 timers available, the A23 and A33 has only two,
with only two interrupts. Let's change the compatible to reflect that.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-08-23 09:14:50 +02:00
Maxime Ripard
628f020d13
ARM: dts: sun6i: Add missing timers interrupts
The timer unit in the A31 has 6 interrupts available. List all of them.

Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2019-08-23 09:14:49 +02:00