Commit Graph

7389 Commits

Author SHA1 Message Date
Arnd Bergmann
610bf412e4 Freescale arm64 device tree fixups for 4.17:
- It reverts a couple of patches that "fix" DTC warnings on IFC memory
    controller in a wrong way.  We will start over agagin to address the
    DTC warnings later.
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJauf8KAAoJEFBXWFqHsHzO6fcIALbh/wNyaCDbKN7ra1CDh38B
 jzCIF8BzxCyhn+2j++8/UVUec9TVF+QYVy39rz0La3ikXCSECwyKwV7rGY5kRZSa
 //HhBiShB/u0Qik7leXflxLLZFz5XlUgZ3RG2Qx7nkZkSvsLX6k3c4HdPIKzoOe1
 oexR8bOLwshQjgDfNTZMr9KTI/V6ur0lRiolagB8zWjO8e448m8d7YkIeyYB6D7R
 PomjtDd3EoJ+fXAmVd1RtY1mhgzhoiS8hhIBFLLTE+Srwoxe+2DUfr5skxqNRAEs
 hbgBHHPyZoFt63gl87rohig6qPL26y9n63dE5N/o4iPn0YJDvMUmV9ZBybtoTY4=
 =pGg0
 -----END PGP SIGNATURE-----

Merge tag 'imx-dt64-4.17-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into next/dt

Pull "Freescale arm64 device tree fixups for 4.17" from Shawn Guo:
 - It reverts a couple of patches that "fix" DTC warnings on IFC memory
   controller in a wrong way.  We will start over agagin to address the
   DTC warnings later.

* tag 'imx-dt64-4.17-2' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
  Revert "dt-bindings: ifc: Fix the unit address format in the examples"
  Revert "arm64: dts: fsl: fix ifc simple-bus unit address format warnings"
2018-03-27 15:03:02 +02:00
Arnd Bergmann
38d03be7cb SoCFPGA DTS updates for v4.17
- Fix GIC PPI warning
 - Stratix10 platform updates
   - Disable over-current for Arria10 devkit
   - Enable watchdog timer
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJatRq4AAoJEBmUBAuBoyj0W4gP/03TAWE15A2ClnErWoy8Vr9C
 l0Ery0xv+U3KBpAgtqZobDDBC2YMe1kf4KR8XeoeU01lYvaiEZHNRenvVcMxpFKy
 cgTMGadiJRKHwx77Toa0GZeIGQuPcl5bwTvq91fEMMW9YTXl7Wn+IHdX5f+6Xupw
 mplRAvpcZC4fQylPtYnYpShA2lnZbcjzpt8FvtD4PTQEg5QMye6pf56zEp5MXM05
 SaLEjqOX0DtsXCfuGq4BmAsgo6IV1AzO9QE1T3AoCm0km7B4y9sd4lbpBKOfvO0t
 1b1dANhj9Evxw39er/4NYL+XDLjZEbEWHwjekmfiNx7Z+9Fj3QTbkaNnWi6EyPdX
 M8SlRZHOnpoWigPChS54no68vLbGNaI4mBdXcdogA32EkEeXJWwLOjqzoZ8dYdeq
 ubUWvTIpJzgJsYtBJOWVAloiMhtJF/nplVYdfElSz7wCYkJXmy239/ddM0FaLYcs
 diXgxQKSxQmKXXze/RQ0bT1agfisOQ0H09yja/XUKNeuWvoCyNasnMveQd4MPVjk
 sNMPsKSvnynGgFePhU8qt/MjREsZOQ8uBfWsbNYRLcNYNc2boBUAcW6gwIWWhtsw
 9QlXGbreHVOjXzbPTHoEAALuDPT5OxYGjigZAbAfqzrDqW1JuKX2S8ePv624pcte
 fSHRpAPrtqLEPR5ES/kD
 =PpB0
 -----END PGP SIGNATURE-----

Merge tag 'socfpga_dts_for_v4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux into next/dt

Pull "SoCFPGA DTS updates for v4.17" from Dinh Nguyen:

- Fix GIC PPI warning
- Stratix10 platform updates
  - Disable over-current for Arria10 devkit
  - Enable watchdog timer

* tag 'socfpga_dts_for_v4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux:
  arm: dts: socfpga: fix GIC PPI warning
  arm64: dts: stratix10: disable false USB overcurrent on devkit
  arm64: dts: stratix10: enable watchdog timer on the S10 devkit
2018-03-27 15:00:31 +02:00
Arnd Bergmann
190e3138f9 Allwinner H3/H5 changes for 4.17
Here is our usual bunch of changes to the common DTSI shared between arm
 and arm64, and their associated device trees.
 
 Even though the diffstat is quite big, it's been mostly just cleanups. The
 big feature is that the HDMI is now suported on H3 and H5 boards.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEE0VqZU19dR2zEVaqr0rTAlCFNr3QFAlqzy3UACgkQ0rTAlCFN
 r3RGXA/9GeVE6R7XQGJX5240cqfLg2HNDBMU5RmRege++kY8wzaoJvnyh2CbQXX5
 GJMOs3IEQuXfss7zX7uH9ZCm/b6ibves76gJE140+ZkX4N9DvZdJFaT0K83gYVAL
 6Zjt8fo7TAJXuF6SqLkTmG5W4Gs9vQ/n1ui8iM9zptphvm++W/knCht42wiZprHv
 +Z7HI5ITw/JGR2gGLD/MPkuCBy1VUmmg4LciVRTbrZ1aNNYirXosGep+TM91dwvh
 Dhg3K4fRass47woiyHk+CXhhqgM7xGrShKpX1DGzaQmzUhwQyUiFW0VLyPiWGuy+
 QrqCeA1X4XNwCH0v2JxxLQO3Wxu1hV9ZTYdruQM6vJ2QZSwURqr6KNzstAXc9H1b
 akcdbjGw25EJpP1s1rAqCJDdiFv1wo3q7nZELK3G6E89uurRn2bjbpIvFduL43Gs
 pYaZULcBvPRE7j4JZBrqdQg2EqAzGKLTkO574IiP97EQIUV9GfupHMJt8an38Jtg
 AWBYGGIa8UKRWRroAxJOTx7s4sVzNhxzWwNxUfzGd0PZ+/jtJZ8klbrZ62ZIKHgv
 yNYXXdQ56QC2JClB9fU+8Qe//ZCn94JyXXH7Ms4hf1cPaKQC6o1KOdVAHhiiwMwZ
 SW8ixLZ/1bgvyvHvv73MEkGOtinmLMqFATBzj4qd0oIfzH3oCU8=
 =hXvM
 -----END PGP SIGNATURE-----

Merge tag 'sunxi-h3-h5-for-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into next/dt

Pull "Allwinner H3/H5 changes for 4.17" from Maxime Ripard:

Here is our usual bunch of changes to the common DTSI shared between arm
and arm64, and their associated device trees.

Even though the diffstat is quite big, it's been mostly just cleanups. The
big feature is that the HDMI is now suported on H3 and H5 boards.

* tag 'sunxi-h3-h5-for-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
  arm64: allwinner: H5: Add Xunlong Orange Pi Zero Plus
  ARM: dts: sun8i-h3: Add Mali node
  ARM64: dts: sun50i: h5: Enable HDMI output on H5 boards
  ARM: dts: sun8i: h3: Enable HDMI output on H3 boards
  ARM: dts: sunxi: h3/h5: Add HDMI pipeline
  ARM: dts: sun8i: h2-plus: remove unnecessary mmc1_pins node
  ARM: dts: sunxi: h3-h5: rename mmc0_pins_a and mmc1_pins_a
  ARM: dts: sunxi: h3-h5: Move pinctrl of mmc1 from dts to dtsi
  ARM: dts: sunxi: h3-h5: Move pinctrl of mmc0 from dts to dtsi
  ARM: dts: sunxi: h3-h5: remove mmc0 card detection pin from pinctrl
  ARM: dts: sun8i: h2+: add support for Banana Pi M2 Zero board
  ARM: dts: sunxi: Switch MMC nodes away from cd-inverted property
  ARM: dts: nanopi-neo-air: Add WiFi / eMMC
2018-03-27 14:58:00 +02:00
Arnd Bergmann
cafc87023b Allwinner arm64 DT changes for 4.17
We've had for this release a pretty good progress on the arm64 front as
 well:
   - The A64 now has SPDIF support
   - The H6 is now supported (even though at an early stage)
   - The TERES-I laptop from Olimex has seen some early support as well
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEE0VqZU19dR2zEVaqr0rTAlCFNr3QFAlqzxaMACgkQ0rTAlCFN
 r3Tx9Q//f6XbZmxth22iPgQmmdt9BN6J4s4euL0NdfqUiJusw9sz00EmnEjplyHo
 erRnkYGmsx1/lyxgTRc+ueb6CoknusIQKaUz4IoQHuLc1Di4yB7HSkv32WKi6FPJ
 iL1eIbHHiDs1Z0dAKa8hhaA7iD/SimXGLzXySIGa2nVU7XS/e/5tk4pVul6/d4/S
 z1HkxRASidw91lRdx2t/mbs07uYC+TqPCCG+QN2m8mGenQo+6d6L7yl4rUpezXrM
 Z+mVHgB7Hi4921d7ydgEX4STtsKaERq4WjA/hCQgFYjzgbvkqVJ/zqZGAnoAlkc3
 gW/JgRXFn2eGxS/EkgGD+F8HR74aHtPkOG/LYcUOge7Oejbp/SVNPalD51/UodfR
 Q/dU7lDjCWBKvjCPLY/X+pBfLpkW079d7daa2523nHTYQWLPwJlufOBT2RNAf19b
 BCeh3gLEX48oCuGCTBMqJhnNbak6eDktsO14zj0gTxrX0kMsRw9PyvGyaStDL8YG
 y8T9kWCjXqXrP/aSzzAegyt0j+8/uPKUF6ZgudZUrdBJTn10dgskkBrAYTFGouAC
 Ga0oI5rr8r9zvUPoLgiT0pF4Zam3iXhhA+frEa48170mIOQfVQP1jENO2QsrPWpd
 kImVbI/Mn7G9xUKcy8STtP0DbnEOT0tXz20bx1kdlcsfGAhvhc4=
 =wSKq
 -----END PGP SIGNATURE-----

Merge tag 'sunxi-dt64-for-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into next/dt

Pull "Allwinner arm64 DT changes for 4.17" from Maxime Ripard:

We've had for this release a pretty good progress on the arm64 front as
well:
  - The A64 now has SPDIF support
  - The H6 is now supported (even though at an early stage)
  - The TERES-I laptop from Olimex has seen some early support as well

* tag 'sunxi-dt64-for-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/sunxi/linux:
  arm64: dts: allwinner: a64: Add support for TERES-I laptop
  arm64: dts: allwinner: a64: add simplefb for A64 SoC
  arm64: dts: allwinner: a64: Add watchdog
  arm64: dts: allwinner: a64: Add i2c0 pins
  arm64: allwinner: h6: add support for Pine H64 board
  arm64: allwinner: h6: add the basical Allwinner H6 DTSI file
  arm64: dts: sunxi: Switch MMC nodes away from cd-inverted property
  arm64: dts: allwinner: a64: Add DAI nodes
  arm64: dts: allwinner: a64: Add SPDIF to the Pine64
  arm64: dts: allwinner: a64: Add SPDIF to the A64
  arm64: dts: allwinner: a64: Add the SPDIF block and pin
2018-03-27 14:55:26 +02:00
Arnd Bergmann
2430bcda36 Qualcomm ARM64 Updates for v4.17
* Fix GIC_CPU_MASK_SIMPLE and SPI5 config on MSM8996
 * Add SDM845 and kryo385 documentation
 * Add MSM8916 cooling maps, cpu frequency scaling, APCS, and A53 PLL
 * Switch APCS to use mailbox on MSM8916
 * Add rmtfs-mem on MSM8996
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJasG5uAAoJEFKiBbHx2RXV+YoP/Rlvm9SJ5smJR16d5UzZxlb7
 /X8qySsltTYeHa5tx1G0Y29N3S8mFAbVDg2VP/vgvZNJUsRcdZOWpelga6/Njm+u
 +95g68pexVN9cEoBXMNAB/gmiXoSbk5k0rRQukkvdEJfX+v7SYMN3S8LOm6D6P1e
 gpa8yDDHTtRN8QhDIyWO1CSl2Sy7YOHis2loHJbTJFvqrTPtS5+iUVT1yldaQ5x9
 5VjQ/82DVUYgsh2W/qnqTT+yUJsQPRE1sF2bKHbrLAOoMlPgU0rBeQXEPwQAyYDx
 ugNYsU4knZ2L9S/B1hjtkPjBe1clX2OH/fHrddHLnrzZSrLdw493h+uI8LKaK5uz
 eVl+9Cjfkho+/rR+CQ+D5UhTrUnNRdJINh82hWp24pmLqwn1zgijFPtrsWaDOTWt
 bbqXuNCtRh85Jr6EPjPZlp03vN8YI5q3p2UW4PXuDrvLRyy9VAH188Ua+hWw2GZZ
 t7axYBGy63cjdkBSOSzAgRvaZ45B4KqClf/HHJk072dGi3dmSeEn3KkZd4agXjJf
 SyxmOUQ2WolUQKLAyrtso9a8Uje5WgODy3uMAHGjqYZcnScxtqv7f7TJgJBF2xOK
 +QSO+Jn+N94rc1vDfMk0s/NuE21SH9KoWBjZ8lDH4w934LKgKr9SydZcas59ylc8
 hgv4VIEptRCygKxIhTXs
 =2KM8
 -----END PGP SIGNATURE-----

Merge tag 'qcom-arm64-for-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/agross/linux into next/dt

Pull "Qualcomm ARM64 Updates for v4.17" from Andy Gross:

* Fix GIC_CPU_MASK_SIMPLE and SPI5 config on MSM8996
* Add SDM845 and kryo385 documentation
* Add MSM8916 cooling maps, cpu frequency scaling, APCS, and A53 PLL
* Switch APCS to use mailbox on MSM8916
* Add rmtfs-mem on MSM8996

* tag 'qcom-arm64-for-4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/agross/linux:
  arm64: dts: qcom: Fix SPI5 config on MSM8996
  dt-bindings: qcom: Add SDM845 bindings
  dt-bindings: arm: Document kryo385 cpu
  arm64: dts: msm8916: Add cpu cooling maps
  arm64: dts: msm8996: Add rmtfs sharedmem node
  arm64: dts: qcom: msm8916: Add CPU frequency scaling support
  arm64: dts: qcom: msm8916: Add clock properties to the APCS node
  arm64: dts: qcom: msm8916: Probe the APCS mailbox driver
  arm64: dts: qcom: msm8916: Add msm8916 A53 PLL DT node
  arm64: dts: msm8996: Fix wrong use of GIC_CPU_MASK_SIMPLE()
2018-03-27 14:30:49 +02:00
Viresh Kumar
b6f67b039c ARM64: dts: meson: Remove "cooling-{min|max}-level" for gpio-fan node
The "cooling-min-level" and "cooling-max-level" properties are not
parsed by any part of the kernel currently and the max cooling state of
gpio-fan cooling device is found by referring to the
"gpio-fan,speed-map" instead.

Remove the unused properties from the gpio-fan node.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-03-27 14:28:39 +02:00
Viresh Kumar
f65f2df29d ARM64: dts: meson: Remove "cooling-{min|max}-level" for CPU nodes
The "cooling-min-level" and "cooling-max-level" properties are not
parsed by any part of the kernel currently and the max cooling state of
a CPU cooling device is found by referring to the cpufreq table instead.

Remove the unused properties from the CPU nodes.

Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2018-03-27 14:25:40 +02:00
Arnd Bergmann
c073f31a96 Amlogic 64-bit DT updates for v4.17
- AXG: add/enable UART_A, I2C, RMII, system controller, HW RNG
 - accept MAC from u-boot environment
 - misc. fixes
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEEe4dGDhaSf6n1v/EMWTcYmtP7xmUFAlqwTz0ACgkQWTcYmtP7
 xmVt9Q/8CW7750OL2cQjPSCh9ZH3hQykjL2fbW+7Glljm98Oz3lDhFq88OWscSvD
 ciI5ysQxqJHLk65BSDflXdFG05m//rcPYfMbh5Qgvs9j5NFJs6FCYjwaLTDN8t9L
 uoRre6xYkaJO2CSPEWcVrKiEZM9gN6tnH9DR17jxf0ZUQc23atZYMDe5DfEXmEvn
 /D4bcuwVmkK0Md5MmWhNicvlYZsoPdDZXJ0B1luAsLTI38ynUTJYZjMtObVZRVrL
 ucYuhzZ6uxuDXDUXnbvOEW34/qyCVCXcoMYh+8G6SjKa95jXYnSG8iPckOe+dXW4
 Oq5w4WyVUrKSQ1dqNkekdIlvw+587+OivyJ/bkc1GHaUp870gGAs1LtLUX4frAa0
 tGWbJUzRHLLy2RTFl3ExSb17zYRXPQyjIUQE25IgQtNxbzjDoV3/gvx3+g4C/MLp
 hm3KB/mTkl8V0nKqFqsHGzF/BOxvJn2LNuxMiDn5WAOJ8f/Z9GvSo5jZbtXMyWFi
 w1FfhQoSOeqQpn5bBSkqHc8GyFEygUF9FYOrHtKVt/PMo++Slp3iMQTheFLE0euB
 CcIfNP49vgnYHPheVSVhqscZFofm8YMwZw0cgC32n9HlMgeagpj5BUP6/+cMv+in
 p2WyCkZtKLCkHtlQsoGWiZtkVhY/S6te9fomL+sRu9xxQ0iVdw8=
 =i0VK
 -----END PGP SIGNATURE-----

Merge tag 'amlogic-dt64' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic into next/dt

Pull "Amlogic 64-bit DT updates for v4.17" from Kevin Hilman:

- AXG: add/enable UART_A, I2C, RMII, system controller, HW RNG
- accept MAC from u-boot environment
- misc. fixes

* tag 'amlogic-dt64' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/khilman/linux-amlogic:
  ARM64: dts: meson-gx: make efuse read-only
  ARM64: dts: meson: bump mali450 clk to 744MHz
  meson-gx-socinfo: Add package id for S905H
  ARM64: dts: meson-gxbb-wetek: add a wetek specific dtsi to cleanup hub and play2
  ARM64: dts: meson: reduce odroid-c2 eMMC maximum rate
  ARM64: dts: amlogic: Convert to new-style SPDX license identifiers
  ARM64: dts: meson-axg: fix pwm_AO_cd compatible
  ARM64: dts: meson-axg: add sec_AO system controller
  ARM64: dts: meson: accept MAC addr from u-boot environment
  ARM64: dts: meson s905x: accept MAC addr from u-boot environment
  ARM64: dts: meson-axg: enable the UART_A controller
  ARM64: dts: meson-axg: complete the pinctrl info for UART_AO_A
  ARM64: dts: meson-axg: uart: Add the pinctrl info description
  ARM64: dts: meson-axg: uart: drop legacy compatible name from EE UART
  ARM64: dts: meson-axg: add RMII pins for ethernet controller
  ARM64: dts: meson-axg: enable I2C Master-1 for the audio speaker
  ARM64: dts: meson-axg: describe pin DT info for I2C controller
  ARM64: dts: meson-axg: add I2C DT info for Meson-AXG SoC
  ARM64: meson-axg: enable hardware rng
2018-03-27 14:21:05 +02:00
Arnd Bergmann
7c9e7cb344 mvebu dt64 for 4.17 (part 2)
- Add registers clock for all the peripheral nodes that had been yet
   converted for CP110 (Armada 7K/8K)
 
 - Document URL for schematic for the EspressoBin (Armada 3720)
 -----BEGIN PGP SIGNATURE-----
 
 iF0EABECAB0WIQQYqXDMF3cvSLY+g9cLBhiOFHI71QUCWq/qJAAKCRALBhiOFHI7
 1fG4AJ9sIUoukzIpcerurjS2ycxKHRRMzgCffTzrL1NpcFVahmKpWH0ZVQJTzgc=
 =DTZp
 -----END PGP SIGNATURE-----

Merge tag 'mvebu-dt64-4.17-2' of git://git.infradead.org/linux-mvebu into next/dt

Pull "mvebu dt64 for 4.17 (part 2)" from Gregory CLEMENT:

- Add registers clock for all the peripheral nodes that had been yet
  converted for CP110 (Armada 7K/8K)

- Document URL for schematic for the EspressoBin (Armada 3720)

* tag 'mvebu-dt64-4.17-2' of git://git.infradead.org/linux-mvebu:
  arm64: dts: armada-3720-espressobin: Document URL for schematic
  ARM64: dts: marvell: armada-cp110: Add registers clock for the PCIe nodes
  ARM64: dts: marvell: armada-cp110: Add registers clock for the NAND node
  ARM64: dts: marvell: armada-cp110: Add registers clock for the crypto node
  ARM64: dts: marvell: armada-cp110: Add registers clock for the trng node
  ARM64: dts: marvell: armada-cp110: Add registers clock for XOR engine nodes
  ARM64: dts: marvell: armada-cp110: Add registers clock for USB host nodes
2018-03-27 14:19:44 +02:00
Arnd Bergmann
97be8ab23d - mt2712e add auxadc devcie
mt7622:
 - fix clock bindings description
 - add nodes for mmc, usb, SATA, PCI, ethernet, cpufreq, PMIC mt6380,
 pinctrl, scpsys and clock devices
 -----BEGIN PGP SIGNATURE-----
 
 iQJLBAABCAA1FiEEiUuSfQSYnG8EMsBltDliWyzx00MFAlqvjBMXHG1hdHRoaWFz
 LmJnZ0BnbWFpbC5jb20ACgkQtDliWyzx00Nwbg//UK5fODmeOoF/HAUp2tVhKo2J
 Jo1VXlnisHRENcfJDell+Naclo+yrKFQMF3GylTpiShdm7QymwLWKpFehg4uQbhn
 Q/ilDAcgCW2fJ2sylNbCs2/AKcnP/G8NWd8pNMdc6sF+Ult7nq1hYSMgY9B9Cu57
 IENaKScRcztDHDR2dPHUkNIFUyWS2m6n+FxdqhKWt7w5KJmcpUfoXATc26DWoeO9
 AZAx0JuhNMWhTlT+dDTucDDSfMFPfyiwdlPvlu6nEt1ILSes7Z758/adru2gYSmR
 A1q6QNSUavGK+3oRNM3b4aYVgbD8v+KjnoPZ5XRZvjwdGradIRu4d7aX3p7uCpvD
 mWRwQL8S9CByFGnWb62meQ7pMamfZJ6/r+v4B4rlTJuYwhM5FxeUOTVCEbTE1P3c
 jLQUx3i6j7xGznfnJAVuW0UEz2apx2aC/XFTUtZFsplDKMGSup6A0iCVBr/85cul
 7f49rbSrclvzr+JQ+NI9UDePWtFI4TSv1oauU7UoWZ+iIE8O706WraPowe7azBx0
 z031DHAykPwRKDXhHBRg5Z6xDshb8dL6EYXWzmHVxZmoMUukw/VsqR8ijzXiC8mA
 RaIYqPjOfZUbZpOxHTfmgZtDf7KLeln+8Tyf+cJkGTe19wg2ulNWo9j1u9ayojou
 iNY3i7NcvEHQMRxmVOM=
 =uaVH
 -----END PGP SIGNATURE-----

Merge tag 'v4.16-next-dts64' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into next/dt

Pull "ARM: mediatek: dts64 updates for v4.16-next" from Matthias Brugger:

- mt2712e add auxadc devcie

mt7622:
- fix clock bindings description
- add nodes for mmc, usb, SATA, PCI, ethernet, cpufreq, PMIC mt6380,
pinctrl, scpsys and clock devices

* tag 'v4.16-next-dts64' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux:
  arm64: dts: mt2712: Add auxadc device node.
  dt-bindings: clock: mediatek: add missing required #reset-cells
  arm64: dts: mt7622: add mmc related device nodes
  arm64: dts: mt7622: add usb device nodes
  arm64: dts: mt7622: add SATA device nodes
  arm64: dts: mt7622: add PCIe device nodes
  arm64: dts: mt7622: add ethernet device nodes
  arm64: dts: mt7622: add flash related device nodes
  arm64: dts: mt7622: add SoC and peripheral related device nodes
  arm64: dts: mt7622: turn uart0 clock to real ones
  arm64: dts: mt7622: add cpufreq related device nodes
  arm64: dts: mt7622: add PMIC MT6380 related nodes
  arm64: dts: mt7622: add pinctrl related device nodes
  arm64: dts: mt7622: add power domain controller device nodes
  arm64: dts: mt7622: add clock controller device nodes
2018-03-27 14:18:41 +02:00
Will Deacon
2a58fca9a7 arm64: cmpxchg: Include linux/compiler.h in asm/cmpxchg.h
We need linux/compiler.h for unreachable(), so #include it here.

Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-27 13:15:49 +01:00
Will Deacon
c9406e514b arm64: move percpu cmpxchg implementation from cmpxchg.h to percpu.h
We want to avoid pulling linux/preempt.h into cmpxchg.h, since that can
introduce a circular dependency on linux/bitops.h. linux/preempt.h is
only needed by the per-cpu cmpxchg implementation, which is better off
alongside the per-cpu xchg implementation in percpu.h, so move it there
and add the missing #include.

Reported-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-27 13:15:29 +01:00
Will Deacon
e8a2d040fe arm64: cmpxchg: Include build_bug.h instead of bug.h for BUILD_BUG
Having asm/cmpxchg.h pull in linux/bug.h is problematic because this
ends up pulling in the atomic bitops which themselves may be built on
top of atomic.h and cmpxchg.h.

Instead, just include build_bug.h for the definition of BUILD_BUG.

Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-27 13:14:54 +01:00
Will Deacon
8a624f145c arm64: lse: Include compiler_types.h and export.h for out-of-line LL/SC
When the LL/SC atomics are moved out-of-line, they are annotated as
notrace and exported to modules. Ensure we pull in the relevant include
files so that these macros are defined when we need them.

Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-27 13:14:49 +01:00
Will Deacon
b4f9b39074 arm64: fpsimd: include <linux/init.h> in fpsimd.h
fpsimd.h uses the __init annotation, so pull in linux/init.h

Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-27 13:14:43 +01:00
Arnd Bergmann
f02e0468c4 Renesas ARM64 Based SoC DT Updates for v4.17
* R-Car Gen3 boards and SoCs
   - Make phy-mode of EtherAVB a board-specific property.
 
     The SoC DTs file now uses "rgmii" and boards override this with
     "rgmii-txid" as appropriate. Previously "rgmii-txid" was used
     in SoC DTs but this did not describe that more sophiticated
     functionality is a board rather than SoC property.
 
 * Condor board with R-Car V3H (r8a77980) SoC
   - Initial upstream support
 
 * Condor board with R-Car V3H (r8a77980) SoC
   - Initial upstream support
 
 * R-Car D3 (r8a77995)
   - Add I2C nodes and then describing the PCA9654 I/O expander connected to
     the I2C0 bus.
 
 * Eagle board with R-Car V3M (r8a77970) SoC
   - Enable PFC support for configuring SCIF0 pins
     This uses PFC support added to the V3M DT
 
   - Describe EtherAVB PHY IRQ
     This uses support for GPIO added to the V3M DT
 
   - Enable I2C0 support
 
     Sergei Shtylyov says "The I2C0 bus is populated by ON Semiconductor
     PCA9653 I/O expander and Analog Devices ADV7511W HDMI transmitter (but
     we're only describing the former chip now)."
 
 * R-Car V3M (r8a77970) SoCs
   - Add PFC support
   - Describe GPIO devices
   - Describe I2C devices
   - Srt subnodes of root node alphabetically to eas future maintence overhead
 
 * Draak board with R-Car D3 (r8a77995) SoC
   - Enable SDHI2
 
     Wolfram Sang says "The single SDHI controller is connected to eMMC."
 
   - Enable DU
 
     Kieran Bingham says "Enable the DU, providing only the VGA output for
     now."
 
 * R-Car D3 (r8a77995) and V3M (r8a77970) SoCs
   - Move nodes which have no reg property out of bus
     By deffinition the bus only has hardware with an address on the bus
 
   - Remove non-existing STBE region from EtherAVB
     Stream Buffer for EtherAVB-IF (STBE) is not present on these SoCs
 
 * R-Car D3 (r8a77995) SoC
   - Add FCPV, VSP and DU support
 
     Kieran Bingham says "The r8a77995-d3 platform supports 3 VSP instances.
     One VSPBS can be used as a dual-input image blender, while two VSPD
     instances can be utilised as part of a display (DU) pipeline.
 
     Add support for these, along with their required FCPV nodes."
 
 * Salvator-X and Salvator-XS boards with R-Car Gen3 SoCs
   - Add GPIO extender
     This is a basis for follow-up work to configure the GPIOs of the extender
 
 * Salvator-X and Salvator-XS board with R-Car M3-N (r8a77965) SoC
   - Initial upstream support
 
 * R-Car H3 (r8a7795) and M3-W (r8a7796) SoCs
   - Add OPPs table for cpu devices
     This, along with recently upstreamed Z and Z2 clock support allows
     use of CPUFreq with both A57 and A53 CPUs.
 
   - Add thermal cooling management
     Allows the use of CPUFreq as a cooling device on A57 CPUs
 
   - Correct register size of thermal node
 
     Niklas Söderlund says "To be able to read fused calibration values from
     hardware the size of the register resource of TSC1 needs to be
     incremented to cover one more register which holds the information if
     the calibration values have been fused or not.
 
     Instead of increasing TSC1 size to the value from the datasheet update
     all TSC's size to the smallest granularity of the address decoder
     circuitry"
 
   - Fix register mappings on VSPs
 
     Kieran Bingham says "The VSPD includes a CLUT on RPF2. Ensure that the
     register space is mapped correctly to support this."
 
 * R-Car H3 (r8a7795) SoC
   - Move SCIF node into alphabetical order to ease future maintenance overhead
 
   - Add IPMMU-PV1 device node
 
     This resolves an oversight when IPMMU nodes were added to the H3 DT.
     All IPMMU devices should now be described in DT.
 
   - Add missing SYS-DMAC2 dmas
 
     Geert Uytterhoeven says "On R-Car H3, on-chip peripheral modules that
     can make use of DMA are wired to either SYS-DMAC0 only, or to both
     SYS-DMAC1 and SYS-DMAC2.
 
     Add the missing DMA properties pointing to SYS-DMAC2 for HSCIF[0-2],
     SCIF[0125], and I2C[0-2].  These were initially left out because early
     firmware versions prohibited using SYS-DMAC2.  This restriction has
     been lifted in IPL and Secure Monitor Rev1.0.6 (released on Feb 25,
     2016)."
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCAAdFiEE4nzZofWswv9L/nKF189kaWo3T74FAlqrw1cACgkQ189kaWo3
 T75rUw/+LR1H1BeU8TpNeSsq6rb2jD4lJhGfj8UQP5mo2ycRzYfMiZSJgNqsiAd+
 C1XgKsEPRCCXhEt52H2cKUocYfGbYrDiUXmy3lHEPHwYENj2+QSjObkZvcLtH3rX
 6H6quvBMRbKigBKM2A+6CEG1z/zcGCA25KbLvEqJylADKugldkXn/ao/1yoSmbnX
 bqWDZmJ2tPfqFrmp8EVKfW75INLkJUTgzMWAdmUmABdWkLXWEBaGfCIcabwPxeNJ
 RJ9jG9P4CVuVhqR85Pii9XbInhYbbVmqkQRwP5jspSULBIxc1LKFLWJeWNfYjE2R
 9FkW2EHEKzwK24bg+/rCtjFoM/Uk7E9OwS75IGqQ+QXVTzLmjQAI5vEifVZyaBzU
 ei9eh52Q53yG4GEuknEtZe5chVUdoKGxU2KP5D5/OzCcXjrSymHT5eK+t2Anr/vn
 ATon2o9RXw9hzy9AeglYl1wA07Vh+VaeEUYp2klYIjm6gSB8e333YghgrI2KdTK3
 pTAgwmjDZRZzq4/mC7nr6LI6i0RS9Drf7uzSpYKGSKwnuTAgH3IdkYhRzRA+aY1u
 cRXTfWfMJvaE15C7JfhqbduC3DGBVfl5E8kgbPJK8d29DA6m5tB4L5zZ2J2N7q8X
 J3jKJSZUYZqDyGzTCd2pJfDzofcsrRyWTvDv1YfobQzeibRJqG8=
 =wu1f
 -----END PGP SIGNATURE-----

Merge tag 'renesas-arm64-dt-for-v4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/dt

Pull "Renesas ARM64 Based SoC DT Updates for v4.17" from Simon Horman:

* R-Car Gen3 boards and SoCs
  - Make phy-mode of EtherAVB a board-specific property.

    The SoC DTs file now uses "rgmii" and boards override this with
    "rgmii-txid" as appropriate. Previously "rgmii-txid" was used
    in SoC DTs but this did not describe that more sophiticated
    functionality is a board rather than SoC property.

* Condor board with R-Car V3H (r8a77980) SoC
  - Initial upstream support

* Condor board with R-Car V3H (r8a77980) SoC
  - Initial upstream support

* R-Car D3 (r8a77995)
  - Add I2C nodes and then describing the PCA9654 I/O expander connected to
    the I2C0 bus.

* Eagle board with R-Car V3M (r8a77970) SoC
  - Enable PFC support for configuring SCIF0 pins
    This uses PFC support added to the V3M DT

  - Describe EtherAVB PHY IRQ
    This uses support for GPIO added to the V3M DT

  - Enable I2C0 support

    Sergei Shtylyov says "The I2C0 bus is populated by ON Semiconductor
    PCA9653 I/O expander and Analog Devices ADV7511W HDMI transmitter (but
    we're only describing the former chip now)."

* R-Car V3M (r8a77970) SoCs
  - Add PFC support
  - Describe GPIO devices
  - Describe I2C devices
  - Srt subnodes of root node alphabetically to eas future maintence overhead

* Draak board with R-Car D3 (r8a77995) SoC
  - Enable SDHI2

    Wolfram Sang says "The single SDHI controller is connected to eMMC."

  - Enable DU

    Kieran Bingham says "Enable the DU, providing only the VGA output for
    now."

* R-Car D3 (r8a77995) and V3M (r8a77970) SoCs
  - Move nodes which have no reg property out of bus
    By deffinition the bus only has hardware with an address on the bus

  - Remove non-existing STBE region from EtherAVB
    Stream Buffer for EtherAVB-IF (STBE) is not present on these SoCs

* R-Car D3 (r8a77995) SoC
  - Add FCPV, VSP and DU support

    Kieran Bingham says "The r8a77995-d3 platform supports 3 VSP instances.
    One VSPBS can be used as a dual-input image blender, while two VSPD
    instances can be utilised as part of a display (DU) pipeline.

    Add support for these, along with their required FCPV nodes."

* Salvator-X and Salvator-XS boards with R-Car Gen3 SoCs
  - Add GPIO extender
    This is a basis for follow-up work to configure the GPIOs of the extender

* Salvator-X and Salvator-XS board with R-Car M3-N (r8a77965) SoC
  - Initial upstream support

* R-Car H3 (r8a7795) and M3-W (r8a7796) SoCs
  - Add OPPs table for cpu devices
    This, along with recently upstreamed Z and Z2 clock support allows
    use of CPUFreq with both A57 and A53 CPUs.

  - Add thermal cooling management
    Allows the use of CPUFreq as a cooling device on A57 CPUs

  - Correct register size of thermal node

    Niklas Söderlund says "To be able to read fused calibration values from
    hardware the size of the register resource of TSC1 needs to be
    incremented to cover one more register which holds the information if
    the calibration values have been fused or not.

    Instead of increasing TSC1 size to the value from the datasheet update
    all TSC's size to the smallest granularity of the address decoder
    circuitry"

  - Fix register mappings on VSPs

    Kieran Bingham says "The VSPD includes a CLUT on RPF2. Ensure that the
    register space is mapped correctly to support this."

* R-Car H3 (r8a7795) SoC
  - Move SCIF node into alphabetical order to ease future maintenance overhead

  - Add IPMMU-PV1 device node

    This resolves an oversight when IPMMU nodes were added to the H3 DT.
    All IPMMU devices should now be described in DT.

  - Add missing SYS-DMAC2 dmas

    Geert Uytterhoeven says "On R-Car H3, on-chip peripheral modules that
    can make use of DMA are wired to either SYS-DMAC0 only, or to both
    SYS-DMAC1 and SYS-DMAC2.

    Add the missing DMA properties pointing to SYS-DMAC2 for HSCIF[0-2],
    SCIF[0125], and I2C[0-2].  These were initially left out because early
    firmware versions prohibited using SYS-DMAC2.  This restriction has
    been lifted in IPL and Secure Monitor Rev1.0.6 (released on Feb 25,
    2016)."

* tag 'renesas-arm64-dt-for-v4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas: (69 commits)
  arm64: dts: renesas: v3msk: add SCIF0 pins
  arm64: dts: renesas: r8a7795: Add missing SYS-DMAC2 dmas
  arm64: dts: renesas: r8a7795: Add IPMMU-PV1 device node
  arm64: dts: renesas: r8a77970: sort subnodes of root node alphabetically
  arm64: dts: renesas: eagle: add I2C0 support
  arm64: dts: renesas: r8a77970: add I2C support
  arm64: dts: renesas: r8a77965-salvator-xs: Add SoC name to file header
  arm64: dts: renesas: r8a77965: Add EtherAVB device node
  arm64: dts: renesas: r8a77970: Set EtherAVB phy mode to "rgmii"
  arm64: dts: renesas: r8a77995: Set EtherAVB phy mode to "rgmii"
  arm64: dts: renesas: r8a7795: Set EtherAVB phy mode to "rgmii"
  arm64: dts: renesas: r8a7796: Set EtherAVB phy mode to "rgmii"
  arm64: dts: renesas: v3msk: Override EtherAVB phy-mode
  arm64: dts: renesas: eagle: Override EtherAVB phy-mode
  arm64: dts: renesas: draak: Override EtherAVB phy-mode
  arm64: dts: renesas: ulcb: Override EtherAVB phy-mode
  arm64: dts: renesas: salvator-common: Override EtherAVB phy-mode
  arm64: dts: renesas: r8a77965: Add INTC-EX device node
  arm64: dts: renesas: r8a77965: Add IIC-DVFS device node
  arm64: dts: renesas: Add support for Salvator-XS with R-Car M3-N
  ...
2018-03-27 13:28:10 +02:00
Arnd Bergmann
d45357e40e arm64: tegra: Device tree changes for v4.17-rc1
Adds initial support for the P2972-0000 development board based on
 Tegra194 and enables the AHCI controller on Jetson TX1.
 -----BEGIN PGP SIGNATURE-----
 
 iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAlqr0SYTHHRyZWRpbmdA
 bnZpZGlhLmNvbQAKCRDdI6zXfz6zoUryD/0fakVwRpCnyRwlfe6hF2MJmpUPu8Ft
 K3VMcL+JW3fDpxS6NYfw7xaI0YiqXlmL/V/hDwmcI5LQVN/TmRxBg3811xxVYQy3
 d6nnDvZPru8wLMooereHZjSdY/1yRx/DjzS2RHd622ZwV7FR/7KzsBOEELooNlKG
 c6HK/evO8Wr1QC1nsQnrCOtQm6cuw5nVTOSxh3tzHjsx/YEqZrqalTjD0temyvA4
 vk/HrBwXQWS/3a7n6avCGxh3MW4K8zYgYw6E7w4GW3umeKu3kVht8LodqYl5B3Az
 8cXmd5cWDgyR8A5O0OOX/7EAUBg/D2RxbUUCwThgh/NCbrm+LCeE7xNM39eBuIJW
 GLwsdsAih3svPIMYDF7IgEMlJ1+X8IE+AtDmBLbta0fsNljAsK30v/96/+llL579
 S4sg3iphpe4Lzd7y0mLM8m5wRNCjaG/DbDYj+Xx0towtIm+UU6hf/G+MEUMTpC4W
 +ucGYzACguFOQNEPRvLptJxqqcEGz3Do3GaSpzdieWpibTm91Gfw/IfqdY8KYKy5
 DYKMCVo7iYSs0SbvRg7T0nMYF2OnIHDWVFYP26bK3OaQtWaU7mdaA99Q5V7GNQvH
 pklUJvjV5igWQ2J56QHD0C642C133kPvcKWu2638GeVtUsL/PF+HHhZaKhODODN7
 F/jibSvkt2wTxg==
 =u8uZ
 -----END PGP SIGNATURE-----

Merge tag 'tegra-for-4.17-arm64-dt' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tegra/linux into next/dt

Pull "arm64: tegra: Device tree changes for v4.17-rc1" from Thierry Reding:

Adds initial support for the P2972-0000 development board based on
Tegra194 and enables the AHCI controller on Jetson TX1.

* tag 'tegra-for-4.17-arm64-dt' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
  arm64: tegra: Enable AHCI on Jetson TX1
  arm64: tegra: Add SATA node for Tegra210
  arm64: tegra: Add device tree for the Tegra194 P2972-0000 board
  arm64: tegra: Add Tegra194 chip device tree
2018-03-27 13:27:04 +02:00
Will Deacon
3f251cf0ab Revert "arm64: Revert L1_CACHE_SHIFT back to 6 (64-byte cache line size)"
This reverts commit 1f85b42a69.

The internal dma-direct.h API has changed in -next, which collides with
us trying to use it to manage non-coherent DMA devices on systems with
unreasonably large cache writeback granules.

This isn't at all trivial to resolve, so revert our changes for now and
we can revisit this after the merge window. Effectively, this just
restores our behaviour back to that of 4.16.

Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-27 12:04:51 +01:00
Will Deacon
12eb369125 arm64: cpufeature: Avoid warnings due to unused symbols
An allnoconfig build complains about unused symbols due to functions
that are called via conditional cpufeature and cpu_errata table entries.

Annotate these as __maybe_unused if they are likely to be generic, or
predicate their compilation on the same option as the table entry if
they are specific to a given alternative.

Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-27 11:51:12 +01:00
Fabio Estevam
3ed9847800 Revert "arm64: dts: fsl: fix ifc simple-bus unit address format warnings"
This reverts commit f81d7af795.

As explained by Rob Herring:

"This "fix" is wrong. Memory controllers with chip selects should have
the chip select in the unit-address. The correct fix here is you should
drop "simple-bus"."

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
2018-03-27 16:00:01 +08:00
Suzuki K Poulose
ece1397cbc arm64: Add work around for Arm Cortex-A55 Erratum 1024718
Some variants of the Arm Cortex-55 cores (r0p0, r0p1, r1p0) suffer
from an erratum 1024718, which causes incorrect updates when DBM/AP
bits in a page table entry is modified without a break-before-make
sequence. The work around is to skip enabling the hardware DBM feature
on the affected cores. The hardware Access Flag management features
is not affected. There are some other cores suffering from this
errata, which could be added to the midr_list to trigger the work
around.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: ckadabi@codeaurora.org
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:44 +01:00
Suzuki K Poulose
05abb595bb arm64: Delay enabling hardware DBM feature
We enable hardware DBM bit in a capable CPU, very early in the
boot via __cpu_setup. This doesn't give us a flexibility of
optionally disable the feature, as the clearing the bit
is a bit costly as the TLB can cache the settings. Instead,
we delay enabling the feature until the CPU is brought up
into the kernel. We use the feature capability mechanism
to handle it.

The hardware DBM is a non-conflicting feature. i.e, the kernel
can safely run with a mix of CPUs with some using the feature
and the others don't. So, it is safe for a late CPU to have
this capability and enable it, even if the active CPUs don't.

To get this handled properly by the infrastructure, we
unconditionally set the capability and only enable it
on CPUs which really have the feature. Also, we print the
feature detection from the "matches" call back to make sure
we don't mislead the user when none of the CPUs could use the
feature.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:44 +01:00
Suzuki K Poulose
6e616864f2 arm64: Add MIDR encoding for Arm Cortex-A55 and Cortex-A35
Update the MIDR encodings for the Cortex-A55 and Cortex-A35

Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:43 +01:00
Suzuki K Poulose
ba7d9233c2 arm64: capabilities: Handle shared entries
Some capabilities have different criteria for detection and associated
actions based on the matching criteria, even though they all share the
same capability bit. So far we have used multiple entries with the same
capability bit to handle this. This is prone to errors, as the
cpu_enable is invoked for each entry, irrespective of whether the
detection rule applies to the CPU or not. And also this complicates
other helpers, e.g, __this_cpu_has_cap.

This patch adds a wrapper entry to cover all the possible variations
of a capability by maintaining list of matches + cpu_enable callbacks.
To avoid complicating the prototypes for the "matches()", we use
arm64_cpu_capabilities maintain the list and we ignore all the other
fields except the matches & cpu_enable.

This ensures :

 1) The capabilitiy is set when at least one of the entry detects
 2) Action is only taken for the entries that "matches".

This avoids explicit checks in the cpu_enable() take some action.
The only constraint here is that, all the entries should have the
same "type" (i.e, scope and conflict rules).

If a cpu_enable() method is associated with multiple matches for a
single capability, care should be taken that either the match criteria
are mutually exclusive, or that the method is robust against being
called multiple times.

This also reverts the changes introduced by commit 67948af41f
("arm64: capabilities: Handle duplicate entries for a capability").

Cc: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:43 +01:00
Suzuki K Poulose
be5b299830 arm64: capabilities: Add support for checks based on a list of MIDRs
Add helpers for detecting an errata on list of midr ranges
of affected CPUs, with the same work around.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:42 +01:00
Suzuki K Poulose
1df310505d arm64: Add helpers for checking CPU MIDR against a range
Add helpers for checking if the given CPU midr falls in a range
of variants/revisions for a given model.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:42 +01:00
Suzuki K Poulose
5e7951ce19 arm64: capabilities: Clean up midr range helpers
We are about to introduce generic MIDR range helpers. Clean
up the existing helpers in erratum handling, preparing them
to use generic version.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:42 +01:00
Suzuki K Poulose
830dcc9f9a arm64: capabilities: Change scope of VHE to Boot CPU feature
We expect all CPUs to be running at the same EL inside the kernel
with or without VHE enabled and we have strict checks to ensure
that any mismatch triggers a kernel panic. If VHE is enabled,
we use the feature based on the boot CPU and all other CPUs
should follow. This makes it a perfect candidate for a capability
based on the boot CPU,  which should be matched by all the CPUs
(both when is ON and OFF). This saves us some not-so-pretty
hooks and special code, just for verifying the conflict.

The patch also makes the VHE capability entry depend on
CONFIG_ARM64_VHE.

Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:41 +01:00
Suzuki K Poulose
fd9d63da17 arm64: capabilities: Add support for features enabled early
The kernel detects and uses some of the features based on the boot
CPU and expects that all the following CPUs conform to it. e.g,
with VHE and the boot CPU running at EL2, the kernel decides to
keep the kernel running at EL2. If another CPU is brought up without
this capability, we use custom hooks (via check_early_cpu_features())
to handle it. To handle such capabilities add support for detecting
and enabling capabilities based on the boot CPU.

A bit is added to indicate if the capability should be detected
early on the boot CPU. The infrastructure then ensures that such
capabilities are probed and "enabled" early on in the boot CPU
and, enabled on the subsequent CPUs.

Cc: Julien Thierry <julien.thierry@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:41 +01:00
Suzuki K Poulose
d3aec8a28b arm64: capabilities: Restrict KPTI detection to boot-time CPUs
KPTI is treated as a system wide feature and is only detected if all
the CPUs in the sysetm needs the defense, unless it is forced via kernel
command line. This leaves a system with a mix of CPUs with and without
the defense vulnerable. Also, if a late CPU needs KPTI but KPTI was not
activated at boot time, the CPU is currently allowed to boot, which is a
potential security vulnerability.
This patch ensures that the KPTI is turned on if at least one CPU detects
the capability (i.e, change scope to SCOPE_LOCAL_CPU). Also rejetcs a late
CPU, if it requires the defense, when the system hasn't enabled it,

Cc: Will Deacon <will.deacon@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:40 +01:00
Suzuki K Poulose
5c137714dd arm64: capabilities: Introduce weak features based on local CPU
Now that we have the flexibility of defining system features based
on individual CPUs, introduce CPU feature type that can be detected
on a local SCOPE and ignores the conflict on late CPUs. This is
applicable for ARM64_HAS_NO_HW_PREFETCH, where it is fine for
the system to have CPUs without hardware prefetch turning up
later. We only suffer a performance penalty, nothing fatal.

Cc: Will Deacon <will.deacon@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:40 +01:00
Suzuki K Poulose
ed478b3f9e arm64: capabilities: Group handling of features and errata workarounds
Now that the features and errata workarounds have the same
rules and flow, group the handling of the tables.

Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:40 +01:00
Suzuki K Poulose
fbd890b9b8 arm64: capabilities: Allow features based on local CPU scope
So far we have treated the feature capabilities as system wide
and this wouldn't help with features that could be detected locally
on one or more CPUs (e.g, KPTI, Software prefetch). This patch
splits the feature detection to two phases :

 1) Local CPU features are checked on all boot time active CPUs.
 2) System wide features are checked only once after all CPUs are
    active.

Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:39 +01:00
Suzuki K Poulose
d69fe9a7e7 arm64: capabilities: Split the processing of errata work arounds
Right now we run through the errata workarounds check on all boot
active CPUs, with SCOPE_ALL. This wouldn't help for detecting erratum
workarounds with a SYSTEM_SCOPE. There are none yet, but we plan to
introduce some: let us clean this up so that such workarounds can be
detected and enabled correctly.

So, we run the checks with SCOPE_LOCAL_CPU on all CPUs and SCOPE_SYSTEM
checks are run only once after all the boot time CPUs are active.

Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:39 +01:00
Suzuki K Poulose
600b9c919c arm64: capabilities: Prepare for grouping features and errata work arounds
We are about to group the handling of all capabilities (features
and errata workarounds). This patch open codes the wrapper routines
to make it easier to merge the handling.

Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:38 +01:00
Suzuki K Poulose
cce360b54c arm64: capabilities: Filter the entries based on a given mask
While processing the list of capabilities, it is useful to
filter out some of the entries based on the given mask for the
scope of the capabilities to allow better control. This can be
used later for handling LOCAL vs SYSTEM wide capabilities and more.
All capabilities should have their scope set to either LOCAL_CPU or
SYSTEM. No functional/flow change.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:38 +01:00
Suzuki K Poulose
eaac4d83da arm64: capabilities: Unify the verification
Now that each capability describes how to treat the conflicts
of CPU cap state vs System wide cap state, we can unify the
verification logic to a single place.

Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:38 +01:00
Suzuki K Poulose
5b4747c5dc arm64: capabilities: Add flags to handle the conflicts on late CPU
When a CPU is brought up, it is checked against the caps that are
known to be enabled on the system (via verify_local_cpu_capabilities()).
Based on the state of the capability on the CPU vs. that of System we
could have the following combinations of conflict.

	x-----------------------------x
	| Type  | System   | Late CPU |
	|-----------------------------|
	|  a    |   y      |    n     |
	|-----------------------------|
	|  b    |   n      |    y     |
	x-----------------------------x

Case (a) is not permitted for caps which are system features, which the
system expects all the CPUs to have (e.g VHE). While (a) is ignored for
all errata work arounds. However, there could be exceptions to the plain
filtering approach. e.g, KPTI is an optional feature for a late CPU as
long as the system already enables it.

Case (b) is not permitted for errata work arounds that cannot be activated
after the kernel has finished booting.And we ignore (b) for features. Here,
yet again, KPTI is an exception, where if a late CPU needs KPTI we are too
late to enable it (because we change the allocation of ASIDs etc).

Add two different flags to indicate how the conflict should be handled.

 ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU - CPUs may have the capability
 ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU - CPUs may not have the cappability.

Now that we have the flags to describe the behavior of the errata and
the features, as we treat them, define types for ERRATUM and FEATURE.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:37 +01:00
Suzuki K Poulose
143ba05d86 arm64: capabilities: Prepare for fine grained capabilities
We use arm64_cpu_capabilities to represent CPU ELF HWCAPs exposed
to the userspace and the CPU hwcaps used by the kernel, which
include cpu features and CPU errata work arounds. Capabilities
have some properties that decide how they should be treated :

 1) Detection, i.e scope : A cap could be "detected" either :
    - if it is present on at least one CPU (SCOPE_LOCAL_CPU)
	Or
    - if it is present on all the CPUs (SCOPE_SYSTEM)

 2) When is it enabled ? - A cap is treated as "enabled" when the
  system takes some action based on whether the capability is detected or
  not. e.g, setting some control register, patching the kernel code.
  Right now, we treat all caps are enabled at boot-time, after all
  the CPUs are brought up by the kernel. But there are certain caps,
  which are enabled early during the boot (e.g, VHE, GIC_CPUIF for NMI)
  and kernel starts using them, even before the secondary CPUs are brought
  up. We would need a way to describe this for each capability.

 3) Conflict on a late CPU - When a CPU is brought up, it is checked
  against the caps that are known to be enabled on the system (via
  verify_local_cpu_capabilities()). Based on the state of the capability
  on the CPU vs. that of System we could have the following combinations
  of conflict.

	x-----------------------------x
	| Type	| System   | Late CPU |
	------------------------------|
	|  a    |   y      |    n     |
	------------------------------|
	|  b    |   n      |    y     |
	x-----------------------------x

  Case (a) is not permitted for caps which are system features, which the
  system expects all the CPUs to have (e.g VHE). While (a) is ignored for
  all errata work arounds. However, there could be exceptions to the plain
  filtering approach. e.g, KPTI is an optional feature for a late CPU as
  long as the system already enables it.

  Case (b) is not permitted for errata work arounds which requires some
  work around, which cannot be delayed. And we ignore (b) for features.
  Here, yet again, KPTI is an exception, where if a late CPU needs KPTI we
  are too late to enable it (because we change the allocation of ASIDs
  etc).

So this calls for a lot more fine grained behavior for each capability.
And if we define all the attributes to control their behavior properly,
we may be able to use a single table for the CPU hwcaps (which cover
errata and features, not the ELF HWCAPs). This is a prepartory step
to get there. More bits would be added for the properties listed above.

We are going to use a bit-mask to encode all the properties of a
capabilities. This patch encodes the "SCOPE" of the capability.

As such there is no change in how the capabilities are treated.

Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:37 +01:00
Suzuki K Poulose
1e89baed5d arm64: capabilities: Move errata processing code
We have errata work around processing code in cpu_errata.c,
which calls back into helpers defined in cpufeature.c. Now
that we are going to make the handling of capabilities
generic, by adding the information to each capability,
move the errata work around specific processing code.
No functional changes.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Marc Zyngier <marc.zyngier@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:36 +01:00
Suzuki K Poulose
5e91107b06 arm64: capabilities: Move errata work around check on boot CPU
We trigger CPU errata work around check on the boot CPU from
smp_prepare_boot_cpu() to make sure that we run the checks only
after the CPU feature infrastructure is initialised. While this
is correct, we can also do this from init_cpu_features() which
initilises the infrastructure, and is called only on the
Boot CPU. This helps to consolidate the CPU capability handling
to cpufeature.c. No functional changes.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:01:36 +01:00
Dave Martin
c0cda3b8ee arm64: capabilities: Update prototype for enable call back
We issue the enable() call back for all CPU hwcaps capabilities
available on the system, on all the CPUs. So far we have ignored
the argument passed to the call back, which had a prototype to
accept a "void *" for use with on_each_cpu() and later with
stop_machine(). However, with commit 0a0d111d40
("arm64: cpufeature: Pass capability structure to ->enable callback"),
there are some users of the argument who wants the matching capability
struct pointer where there are multiple matching criteria for a single
capability. Clean up the declaration of the call back to make it clear.

 1) Renamed to cpu_enable(), to imply taking necessary actions on the
    called CPU for the entry.
 2) Pass const pointer to the capability, to allow the call back to
    check the entry. (e.,g to check if any action is needed on the CPU)
 3) We don't care about the result of the call back, turning this to
    a void.

Cc: Will Deacon <will.deacon@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: James Morse <james.morse@arm.com>
Acked-by: Robin Murphy <robin.murphy@arm.com>
Reviewed-by: Julien Thierry <julien.thierry@arm.com>
Signed-off-by: Dave Martin <dave.martin@arm.com>
[suzuki: convert more users, rename call back and drop results]
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 18:00:37 +01:00
Dave Martin
5043694eb8 arm64/sve: Document firmware support requirements in Kconfig
Use of SVE by EL2 and below requires explicit support in the
firmware.  There is no means to hide the presence of SVE from EL2,
so a kernel configured with CONFIG_ARM64_SVE=y will typically not
work correctly on SVE capable hardware unless the firmware does
include the appropriate support.

This is not expected to pose a problem in the wild, since platform
integrators are responsible for ensuring that they ship up-to-date
firmware to support their hardware.  However, developers may hit
the issue when using mismatched compoments.

In order to draw attention to the issue and how to solve it, this
patch adds some Kconfig text giving a brief explanation and details
of compatible firmware versions.

Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-26 12:29:35 +01:00
Leonard Crestez
6aaf49b495 crypto: arm,arm64 - Fix random regeneration of S_shipped
The decision to rebuild .S_shipped is made based on the relative
timestamps of .S_shipped and .pl files but git makes this essentially
random. This means that the perl script might run anyway (usually at
most once per checkout), defeating the whole purpose of _shipped.

Fix by skipping the rule unless explicit make variables are provided:
REGENERATE_ARM_CRYPTO or REGENERATE_ARM64_CRYPTO.

This can produce nasty occasional build failures downstream, for example
for toolchains with broken perl. The solution is minimally intrusive to
make it easier to push into stable.

Another report on a similar issue here: https://lkml.org/lkml/2018/3/8/1379

Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Cc: <stable@vger.kernel.org>
Reviewed-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
2018-03-23 23:43:19 +08:00
Dinh Nguyen
83d6e27e68 arm64: defconfig: enable stmmac ethernet to defconfig
This patch enables the CONFIG_STMMAC_ETH to the default arm64 defconfig:

-CONFIG_STMMAC_ETH=m
+CONFIG_STMMAC_ETH=y
+CONFIG_DWMAC_IPQ806X=m
+CONFIG_DWMAC_MESON=m
+CONFIG_DWMAC_ROCKCHIP=m
+CONFIG_DWMAC_SUNXI=m
+CONFIG_DWMAC_SUN8I=m

The STMMAC ethernet controller is on the Stratix10 platform, and thus needs
driver to be in the kernel image for NFS to work.

Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2018-03-23 10:37:05 -05:00
Dinh Nguyen
956c8cd692 arm64: dts: stratix10: disable false USB overcurrent on devkit
Disable the USB overcurrent condition that is falsely detected on the
devkit.

Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2018-03-23 08:53:23 -05:00
Dinh Nguyen
3b0fb63f25 arm64: dts: stratix10: enable watchdog timer on the S10 devkit
Enables the watchdog0 timer on the Stratix10 devkit.

Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
2018-03-23 08:53:19 -05:00
Toshi Kani
b6bdb7517c mm/vmalloc: add interfaces to free unmapped page table
On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() may
create pud/pmd mappings.  A kernel panic was observed on arm64 systems
with Cortex-A75 in the following steps as described by Hanjun Guo.

 1. ioremap a 4K size, valid page table will build,
 2. iounmap it, pte0 will set to 0;
 3. ioremap the same address with 2M size, pgd/pmd is unchanged,
    then set the a new value for pmd;
 4. pte0 is leaked;
 5. CPU may meet exception because the old pmd is still in TLB,
    which will lead to kernel panic.

This panic is not reproducible on x86.  INVLPG, called from iounmap,
purges all levels of entries associated with purged address on x86.  x86
still has memory leak.

The patch changes the ioremap path to free unmapped page table(s) since
doing so in the unmap path has the following issues:

 - The iounmap() path is shared with vunmap(). Since vmap() only
   supports pte mappings, making vunmap() to free a pte page is an
   overhead for regular vmap users as they do not need a pte page freed
   up.

 - Checking if all entries in a pte page are cleared in the unmap path
   is racy, and serializing this check is expensive.

 - The unmap path calls free_vmap_area_noflush() to do lazy TLB purges.
   Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB
   purge.

Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), which
clear a given pud/pmd entry and free up a page for the lower level
entries.

This patch implements their stub functions on x86 and arm64, which work
as workaround.

[akpm@linux-foundation.org: fix typo in pmd_free_pte_page() stub]
Link: http://lkml.kernel.org/r/20180314180155.19492-2-toshi.kani@hpe.com
Fixes: e61ce6ade4 ("mm: change ioremap to set up huge I/O mappings")
Reported-by: Lei Li <lious.lilei@hisilicon.com>
Signed-off-by: Toshi Kani <toshi.kani@hpe.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Wang Xuefeng <wxf.wang@hisilicon.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Hanjun Guo <guohanjun@huawei.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Chintan Pandya <cpandya@codeaurora.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-03-22 17:07:01 -07:00
Marc Zyngier
33625282ad irqchip/gic-v3: Probe for SCR_EL3 being clear before resetting AP0Rn
We would like to reset the Group-0 Active Priority Registers
at boot time if they are available to us. They would be available
if SCR_EL3.FIQ was not set, but we cannot directly probe this bit,
and short of checking, we may end-up trapping to EL3, and the
firmware may not be please to get such an exception. Yes, this
is dumb.

Instead, let's use PMR to find out if its value gets affected by
SCR_EL3.FIQ being set. We use the fact that when SCR_EL3.FIQ is
set, the LSB of the priority is lost due to the shifting back and
forth of the actual priority. If we read back a 0, we know that
Group0 is unavailable. In case we read a non-zero value, we can
safely reset the AP0Rn register.

Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-22 13:46:18 +00:00
Katsuhiro Suzuki
6c35921dd3 arm64: dts: uniphier: add syscon property for UniPhier sound system
This patch adds syscon property for specifying soc-glue core into
device-tree of LD11/LD20 SoC.

Currently, soc-glue core is used for changing the state of S/PDIF
signal output pin to signal output state or Hi-Z state.

Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-21 00:12:16 +09:00
Hauke Mehrtens
a7affb13b2
arm64: allwinner: H5: Add Xunlong Orange Pi Zero Plus
The Xunlong Orange Pi Zero Plus is single board computer.
- H5 Quad-core 64-bit Cortex-A53
- 512MB DDR3
- microSD slot
- Debug TTL UART
- 1000M/100M/10M Ethernet RJ45
- Realtek RTL8189FTV
- Spi flash (2MB)
- One USB 2.0 HOST, One USB 2.0 OTG

This is based on a patch from armbian:
https://github.com/armbian/build/blob/master/patch/kernel/sunxi-next/sunxi-add-orangepi-zero-plus.patch

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-03-20 11:43:41 +01:00
Dave Martin
af4a81b9cd arm64: fpsimd: Fix bad si_code for undiagnosed SIGFPE
Currently a SIGFPE delivered in response to a floating-point
exception trap may have si_code set to 0 on arm64.  As reported by
Eric, this is a bad idea since this is the value of SI_USER -- yet
this signal is definitely not the result of kill(2), tgkill(2) etc.
and si_uid and si_pid make limited sense whereas we do want to
yield a value for si_addr (which doesn't exist for SI_USER).

It's not entirely clear whether the architecure permits a
"spurious" fp exception trap where none of the exception flag bits
in ESR_ELx is set.  (IMHO the architectural intent is to forbid
this.)  However, it does permit those bits to contain garbage if
the TFV bit in ESR_ELx is 0.  That case isn't currently handled at
all and may result in si_code == 0 or si_code containing a FPE_FLT*
constant corresponding to an exception that did not in fact happen.

There is nothing sensible we can return for si_code in such cases,
but SI_USER is certainly not appropriate and will lead to violation
of legitimate userspace assumptions.

This patch allocates a new si_code value FPE_UNKNOWN that at least
does not conflict with any existing SI_* or FPE_* code, and yields
this in si_code for undiagnosable cases.  This is probably the best
simplicity/incorrectness tradeoff achieveable without relying on
implementation-dependent features or adding a lot of code.  In any
case, there appears to be no perfect solution possible that would
justify a lot of effort here.

Yielding FPE_UNKNOWN when some well-defined fp exception caused the
trap is a violation of POSIX, but this is forced by the
architecture.  We have no realistic prospect of yielding the
correct code in such cases.  At present I am not aware of any ARMv8
implementation that supports trapped floating-point exceptions in
any case.

The new code may be applicable to other architectures for similar
reasons.

No attempt is made to provide ESR_ELx to userspace in the signal
frame, since architectural limitations mean that it is unlikely to
provide much diagnostic value, doesn't benefit existing software
and would create ABI with no proven purpose.  The existing
mechanism for passing it also has problems of its own which may
result in the wrong value being passed to userspace due to
interaction with mm faults.  The implied rework does not appear
justified.

Acked-by: "Eric W. Biederman" <ebiederm@xmission.com>
Reported-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Dave Martin <Dave.Martin@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-20 10:03:11 +00:00
Jerome Brunet
c339f0e29c ARM64: dts: meson-gx: make efuse read-only
efuse is one time programmable, so it is safer to deny write request
to this memory, unless the user is savvy enough to remove the read-only
flag from DTB

Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2018-03-19 16:44:39 -07:00
Neil Armstrong
97ac009309 ARM64: dts: meson: bump mali450 clk to 744MHz
The Mali-450 IP can run up to 744MHz, bump the frequency using
the GP0 PLL clock.

Cc: Michal Lazo <michal.lazo@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
2018-03-19 16:39:26 -07:00
Harald Geyer
c916eb95bc
arm64: dts: allwinner: a64: Add support for TERES-I laptop
The TERES-I is an open hardware laptop built by Olimex using the
Allwinner A64 SoC.

Add the board specific .dts file, which includes the A64 .dtsi and
enables the peripherals that we support so far.

Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-03-19 22:12:31 +01:00
Harald Geyer
c1cff65f9b
arm64: dts: allwinner: a64: add simplefb for A64 SoC
The A64 SoC features two display pipelines, one has a LCD output, the
other has a HDMI output.

Add support for simplefb for the LCD output. Tested on Teres I.

This patch was inspired by work of Icenowy Zheng.

Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-03-19 22:12:28 +01:00
Harald Geyer
d41850437c
arm64: dts: allwinner: a64: Add watchdog
Add a watchdog node for the A64, automatically enabled on all boards.
Since the device is compatible with an existing driver, we only reserve
a new compatible string to be used together with the fall back.
Tested on Olimex Teres-I.

Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-03-19 22:12:26 +01:00
Harald Geyer
11239fe6a0
arm64: dts: allwinner: a64: Add i2c0 pins
Add the proper pin group node to reference in board files.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-03-19 22:12:25 +01:00
Icenowy Zheng
494d836762
arm64: allwinner: h6: add support for Pine H64 board
Pine H64 is an Allwinner H6-based SBC from Pine64, with the following
features:

- 1GiB/2GiB/4GiB LPDDR3 DRAM (in 4GiB situation only 3GiB is
accessible)
- AXP805 PMIC
- Raspberry-Pi-compatible GPIO header, "Euler" GPIO header (not
compatible with the "Euler" on Pine A64) and "Expansion" pin header
- 2 USB 2.0 ports and 1 USB 3.0 ports
- Audio jack
- MicroSD slot and eMMC module slot
- on-board SPI NOR flash
- 1Gbps Ethernet port (via RTL8211E PHY)
- HDMI port

Adds initial support for it, including the UART on the Expansion pin
header.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-03-19 22:12:23 +01:00
Icenowy Zheng
e54be32d02
arm64: allwinner: h6: add the basical Allwinner H6 DTSI file
Allwinner H6 is a new SoC with Cortex-A53 cores from Allwinner, with its
memory map fully reworked and some high-speed peripherals (PCIe, USB
3.0) introduced.

This commit adds the basical DTSI file of it, including the clock
support and UART support.

Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
2018-03-19 22:12:21 +01:00
Shanker Donthineni
f9f5dc1950 arm64: KVM: Use SMCCC_ARCH_WORKAROUND_1 for Falkor BP hardening
The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
V1.1 Calling Convention to mitigate CVE-2017-5715. This patch uses
the standard call SMCCC_ARCH_WORKAROUND_1 for Falkor chips instead
of Silicon provider service ID 0xC2001700.

Cc: <stable@vger.kernel.org> # 4.14+
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 18:35:38 +00:00
Suzuki K Poulose
7206dc93a5 arm64: Expose Arm v8.4 features
Expose the new features introduced by Arm v8.4 extensions to
Arm v8-A profile.

These include :

 1) Data indpendent timing of instructions. (DIT, exposed as HWCAP_DIT)
 2) Unaligned atomic instructions and Single-copy atomicity of loads
    and stores. (AT, expose as HWCAP_USCAT)
 3) LDAPR and STLR instructions with immediate offsets (extension to
    LRCPC, exposed as HWCAP_ILRCPC)
 4) Flag manipulation instructions (TS, exposed as HWCAP_FLAGM).

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-19 18:14:27 +00:00
Ard Biesheuvel
350e1dad0d arm64: asm: drop special versions of adr_l/ldr_l/str_l for modules
Now that we started keeping modules within 4 GB of the core kernel
in all cases, we no longer need to special case the adr_l/ldr_l/str_l
macros for modules to deal with them being loaded farther away.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-19 18:14:26 +00:00
Arnd Bergmann
bd99f9a159 arm64: fix undefined reference to 'printk'
The printk symbol was intended as a generic address that is always
exported, however that turned out to be false with CONFIG_PRINTK=n:

ERROR: "printk" [arch/arm64/kernel/arm64-reloc-test.ko] undefined!

This changes the references to memstart_addr, which should be there
regardless of configuration.

Fixes: a257e02579 ("arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum #843419")
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2018-03-19 18:14:25 +00:00
Uwe Kleine-König
003456f564 arm64: dts: armada-3720-espressobin: Document URL for schematic
The schematic of the espressobin is publicly available, add a comment
where to find it.

Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2018-03-19 17:19:24 +01:00
Gregory CLEMENT
b15c9d3550 ARM64: dts: marvell: armada-cp110: Add registers clock for the PCIe nodes
This extra clock is needed to access the registers of the PCIe host
controller used on CP110 component of the Armada 7K/8K SoCs.

This follow the changes already made in the binding documentation (as
well as in the driver): "PCI: armada8k: Fix clock resource by adding
a register clock"

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2018-03-19 17:13:53 +01:00
Gregory CLEMENT
ef04faf106 ARM64: dts: marvell: armada-cp110: Add registers clock for the NAND node
This extra clock is needed to access the registers of the NAND controller
used on CP110 component of the Armada 7K/8K SoCs.

This follow the changes already made in the binding documentation (as
well as in the driver): "mtd: nand: marvell: Fix clock resource by adding
a register clock"

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2018-03-19 17:13:50 +01:00
Gregory CLEMENT
3c7f7f1503 ARM64: dts: marvell: armada-cp110: Add registers clock for the crypto node
This extra clock is needed to access the registers of the safexcel EIP97
used on CP110 component of the Armada 7K/8K SoCs.

This follow the changes already made in the binding documentation (as
well as in the driver): "crypto: inside-secure - fix clock resource by
adding a register clock"

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2018-03-19 17:13:47 +01:00
Gregory CLEMENT
cc4d5aed82 ARM64: dts: marvell: armada-cp110: Add registers clock for the trng node
This extra clock is needed to access the registers of the harware RNG
used on CP110 component of the Armada 7K/8K SoCs.

This follow the changes already made in the binding documentation (as
well as in the driver): "hwrng: omap - Fix clock resource by adding a
register clock"

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2018-03-19 17:13:44 +01:00
Gregory CLEMENT
f1ebfab99d ARM64: dts: marvell: armada-cp110: Add registers clock for XOR engine nodes
This extra clock is needed to access the registers of the XOR engine
controller used on CP110 component of the Armada 7K/8K SoCs.

This follow the changes already made in the binding documentation (as
well as in the driver): "dmaengine: mv_xor_v2: Fix clock resource by
adding a register clock"

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2018-03-19 17:13:41 +01:00
Gregory CLEMENT
f03ad7f6c5 ARM64: dts: marvell: armada-cp110: Add registers clock for USB host nodes
This extra clock is needed to access the registers of the USB host
controller used on Armada 7K/8K SoCs.

This follow the changes already made in the binding documentation (as
well as in the driver): "usb: host: xhci-plat: Fix clock resource by
adding a register clock"

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
2018-03-19 17:13:38 +01:00
Marc Zyngier
4b472ffd15 arm64: Enable ARM64_HARDEN_EL2_VECTORS on Cortex-A57 and A72
Cortex-A57 and A72 are vulnerable to the so-called "variant 3a" of
Meltdown, where an attacker can speculatively obtain the value
of a privileged system register.

By enabling ARM64_HARDEN_EL2_VECTORS on these CPUs, obtaining
VBAR_EL2 is not disclosing the hypervisor mappings anymore.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:06:55 +00:00
Marc Zyngier
dee39247dc arm64: KVM: Allow mapping of vectors outside of the RAM region
We're now ready to map our vectors in weird and wonderful locations.
On enabling ARM64_HARDEN_EL2_VECTORS, a vector slot gets allocated
if this hasn't been already done via ARM64_HARDEN_BRANCH_PREDICTOR
and gets mapped outside of the normal RAM region, next to the
idmap.

That way, being able to obtain VBAR_EL2 doesn't reveal the mapping
of the rest of the hypervisor code.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:06:46 +00:00
Marc Zyngier
4205a89b80 arm64: Make BP hardening slot counter available
We're about to need to allocate hardening slots from other parts
of the kernel (in order to support ARM64_HARDEN_EL2_VECTORS).

Turn the counter into an atomic_t and make it available to the
rest of the kernel. Also add BP_HARDEN_EL2_SLOTS as the number of
slots instead of the hardcoded 4...

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:06:39 +00:00
Marc Zyngier
dc2e4633ff arm/arm64: KVM: Introduce EL2-specific executable mappings
Until now, all EL2 executable mappings were derived from their
EL1 VA. Since we want to decouple the vectors mapping from
the rest of the hypervisor, we need to be able to map some
text somewhere else.

The "idmap" region (for lack of a better name) is ideally suited
for this, as we have a huge range that hardly has anything in it.

Let's extend the IO allocator to also deal with executable mappings,
thus providing the required feature.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:06:05 +00:00
Marc Zyngier
71dcb8be6d arm64: KVM: Allow far branches from vector slots to the main vectors
So far, the branch from the vector slots to the main vectors can at
most be 4GB from the main vectors (the reach of ADRP), and this
distance is known at compile time. If we were to remap the slots
to an unrelated VA, things would break badly.

A way to achieve VA independence would be to load the absolute
address of the vectors (__kvm_hyp_vector), either using a constant
pool or a series of movs, followed by an indirect branch.

This patches implements the latter solution, using another instance
of a patching callback. Note that since we have to save a register
pair on the stack, we branch to the *second* instruction in the
vectors in order to compensate for it. This also results in having
to adjust this balance in the invalid vector entry point.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:06:01 +00:00
Marc Zyngier
f0445dfadb arm64: KVM: Reserve 4 additional instructions in the BPI template
So far, we only reserve a single instruction in the BPI template in
order to branch to the vectors. As we're going to stuff a few more
instructions there, let's reserve a total of 5 instructions, which
we're going to patch later on as required.

We also introduce a small refactor of the vectors themselves, so that
we stop carrying the target branch around.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:05:56 +00:00
Marc Zyngier
4340ba80bd arm64: KVM: Move BP hardening vectors into .hyp.text section
There is no reason why the BP hardening vectors shouldn't be part
of the HYP text at compile time, rather than being mapped at runtime.

Also introduce a new config symbol that controls the compilation
of bpi.S.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:05:49 +00:00
Marc Zyngier
7e80f637fd arm64: KVM: Move stashing of x0/x1 into the vector code itself
All our useful entry points into the hypervisor are starting by
saving x0 and x1 on the stack. Let's move those into the vectors
by introducing macros that annotate whether a vector is valid or
not, thus indicating whether we want to stash registers or not.

The only drawback is that we now also stash registers for el2_error,
but this should never happen, and we pop them back right at the
start of the handling sequence.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:05:44 +00:00
Marc Zyngier
3c5e81232e arm64: KVM: Move vector offsetting from hyp-init.S to kvm_get_hyp_vector
We currently provide the hyp-init code with a kernel VA, and expect
it to turn it into a HYP va by itself. As we're about to provide
the hypervisor with mappings that are not necessarily in the memory
range, let's move the kern_hyp_va macro to kvm_get_hyp_vector.

No functionnal change.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:05:37 +00:00
Marc Zyngier
ed57cac83e arm64: KVM: Introduce EL2 VA randomisation
The main idea behind randomising the EL2 VA is that we usually have
a few spare bits between the most significant bit of the VA mask
and the most significant bit of the linear mapping.

Those bits could be a bunch of zeroes, and could be useful
to move things around a bit. Of course, the more memory you have,
the less randomisation you get...

Alternatively, these bits could be the result of KASLR, in which
case they are already random. But it would be nice to have a
*different* randomization, just to make the job of a potential
attacker a bit more difficult.

Inserting these random bits is a bit involved. We don't have a spare
register (short of rewriting all the kern_hyp_va call sites), and
the immediate we want to insert is too random to be used with the
ORR instruction. The best option I could come up with is the following
sequence:

	and x0, x0, #va_mask
	ror x0, x0, #first_random_bit
	add x0, x0, #(random & 0xfff)
	add x0, x0, #(random >> 12), lsl #12
	ror x0, x0, #(63 - first_random_bit)

making it a fairly long sequence, but one that a decent CPU should
be able to execute without breaking a sweat. It is of course NOPed
out on VHE. The last 4 instructions can also be turned into NOPs
if it appears that there is no free bits to use.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:05:22 +00:00
Marc Zyngier
005e975a3b arm64: KVM: Dynamically compute the HYP VA mask
As we're moving towards a much more dynamic way to compute our
HYP VA, let's express the mask in a slightly different way.

Instead of comparing the idmap position to the "low" VA mask,
we directly compute the mask by taking into account the idmap's
(VA_BIT-1) bit.

No functionnal change.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:05:15 +00:00
Marc Zyngier
11d764079c arm64: insn: Allow ADD/SUB (immediate) with LSL #12
The encoder for ADD/SUB (immediate) can only cope with 12bit
immediates, while there is an encoding for a 12bit immediate shifted
by 12 bits to the left.

Let's fix this small oversight by allowing the LSL_12 bit to be set.

Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:05:13 +00:00
Marc Zyngier
9f2efa320d arm64; insn: Add encoder for the EXTR instruction
Add an encoder for the EXTR instruction, which also implements the ROR
variant (where Rn == Rm).

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:05:10 +00:00
Marc Zyngier
1bb32a44ae KVM: arm/arm64: Keep GICv2 HYP VAs in kvm_vgic_global_state
As we're about to change the way we map devices at HYP, we need
to move away from kern_hyp_va on an IO address.

One way of achieving this is to store the VAs in kvm_vgic_global_state,
and use that directly from the HYP code. This requires a small change
to create_hyp_io_mappings so that it can also return a HYP VA.

We take this opportunity to nuke the vctrl_base field in the emulated
distributor, as it is not used anymore.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:04:06 +00:00
Marc Zyngier
807a378425 KVM: arm/arm64: Move ioremap calls to create_hyp_io_mappings
Both HYP io mappings call ioremap, followed by create_hyp_io_mappings.
Let's move the ioremap call into create_hyp_io_mappings itself, which
simplifies the code a bit and allows for further refactoring.

Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:03:47 +00:00
Marc Zyngier
44a497abd6 KVM: arm/arm64: Do not use kern_hyp_va() with kvm_vgic_global_state
kvm_vgic_global_state is part of the read-only section, and is
usually accessed using a PC-relative address generation (adrp + add).

It is thus useless to use kern_hyp_va() on it, and actively problematic
if kern_hyp_va() becomes non-idempotent. On the other hand, there is
no way that the compiler is going to guarantee that such access is
always PC relative.

So let's bite the bullet and provide our own accessor.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:03:33 +00:00
Marc Zyngier
a1efdff442 arm64: cpufeatures: Drop the ARM64_HYP_OFFSET_LOW feature flag
Now that we can dynamically compute the kernek/hyp VA mask, there
is no need for a feature flag to trigger the alternative patching.
Let's drop the flag and everything that depends on it.

Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:03:31 +00:00
Marc Zyngier
2b4d1606aa arm64: KVM: Dynamically patch the kernel/hyp VA mask
So far, we're using a complicated sequence of alternatives to
patch the kernel/hyp VA mask on non-VHE, and NOP out the
masking altogether when on VHE.

The newly introduced dynamic patching gives us the opportunity
to simplify that code by patching a single instruction with
the correct mask (instead of the mind bending cumulative masking
we have at the moment) or even a single NOP on VHE. This also
adds some initial code that will allow the patching callback
to switch to a more complex patching.

Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:03:29 +00:00
Marc Zyngier
ef3935eeeb arm64: insn: Add encoder for bitwise operations using literals
We lack a way to encode operations such as AND, ORR, EOR that take
an immediate value. Doing so is quite involved, and is all about
reverse engineering the decoding algorithm described in the
pseudocode function DecodeBitMasks().

This has been tested by feeding it all the possible literal values
and comparing the output with that of GAS.

Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:03:27 +00:00
Marc Zyngier
a264bf3442 arm64: insn: Add N immediate encoding
We're missing the a way to generate the encoding of the N immediate,
which is only a single bit used in a number of instruction that take
an immediate.

Acked-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:03:25 +00:00
Marc Zyngier
dea5e2a4c5 arm64: alternatives: Add dynamic patching feature
We've so far relied on a patching infrastructure that only gave us
a single alternative, without any way to provide a range of potential
replacement instructions. For a single feature, this is an all or
nothing thing.

It would be interesting to have a more flexible grained way of patching
the kernel though, where we could dynamically tune the code that gets
injected.

In order to achive this, let's introduce a new form of dynamic patching,
assiciating a callback to a patching site. This callback gets source and
target locations of the patching request, as well as the number of
instructions to be patched.

Dynamic patching is declared with the new ALTERNATIVE_CB and alternative_cb
directives:

	asm volatile(ALTERNATIVE_CB("mov %0, #0\n", callback)
		     : "r" (v));
or
	alternative_cb callback
		mov	x0, #0
	alternative_cb_end

where callback is the C function computing the alternative.

Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 13:03:17 +00:00
Christoffer Dall
2d0e63e030 KVM: arm/arm64: Avoid VGICv3 save/restore on VHE with no IRQs
We can finally get completely rid of any calls to the VGICv3
save/restore functions when the AP lists are empty on VHE systems.  This
requires carefully factoring out trap configuration from saving and
restoring state, and carefully choosing what to do on the VHE and
non-VHE path.

One of the challenges is that we cannot save/restore the VMCR lazily
because we can only write the VMCR when ICC_SRE_EL1.SRE is cleared when
emulating a GICv2-on-GICv3, since otherwise all Group-0 interrupts end
up being delivered as FIQ.

To solve this problem, and still provide fast performance in the fast
path of exiting a VM when no interrupts are pending (which also
optimized the latency for actually delivering virtual interrupts coming
from physical interrupts), we orchestrate a dance of only doing the
activate/deactivate traps in vgic load/put for VHE systems (which can
have ICC_SRE_EL1.SRE cleared when running in the host), and doing the
configuration on every round-trip on non-VHE systems.

Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 10:53:21 +00:00
Christoffer Dall
923a2e30e5 KVM: arm/arm64: Move VGIC APR save/restore to vgic put/load
The APRs can only have bits set when the guest acknowledges an interrupt
in the LR and can only have a bit cleared when the guest EOIs an
interrupt in the LR.  Therefore, if we have no LRs with any
pending/active interrupts, the APR cannot change value and there is no
need to clear it on every exit from the VM (hint: it will have already
been cleared when we exited the guest the last time with the LRs all
EOIed).

The only case we need to take care of is when we migrate the VCPU away
from a CPU or migrate a new VCPU onto a CPU, or when we return to
userspace to capture the state of the VCPU for migration.  To make sure
this works, factor out the APR save/restore functionality into separate
functions called from the VCPU (and by extension VGIC) put/load hooks.

Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 10:53:21 +00:00
Christoffer Dall
771621b0e2 KVM: arm/arm64: Handle VGICv3 save/restore from the main VGIC code on VHE
Just like we can program the GICv2 hypervisor control interface directly
from the core vgic code, we can do the same for the GICv3 hypervisor
control interface on VHE systems.

We do this by simply calling the save/restore functions when we have VHE
and we can then get rid of the save/restore function calls from the VHE
world switch function.

One caveat is that we now write GICv3 system register state before the
potential early exit path in the run loop, and because we sync back
state in the early exit path, we have to ensure that we read a
consistent GIC state from the sync path, even though we have never
actually run the guest with the newly written GIC state.  We solve this
by inserting an ISB in the early exit path.

Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 10:53:21 +00:00
Christoffer Dall
8a43a2b34b KVM: arm/arm64: Move arm64-only vgic-v2-sr.c file to arm64
The vgic-v2-sr.c file now only contains the logic to replay unaligned
accesses to the virtual CPU interface on 16K and 64K page systems, which
is only relevant on 64-bit platforms.  Therefore move this file to the
arm64 KVM tree, remove the compile directive from the 32-bit side
makefile, and remove the ifdef in the C file.

Since this file also no longer saves/restores anything, rename the file
to vgic-v2-cpuif-proxy.c to more accurately describe the logic in this
file.

Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 10:53:20 +00:00
Christoffer Dall
75174ba6ca KVM: arm/arm64: Handle VGICv2 save/restore from the main VGIC code
We can program the GICv2 hypervisor control interface logic directly
from the core vgic code and can instead do the save/restore directly
from the flush/sync functions, which can lead to a number of future
optimizations.

Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 10:53:20 +00:00
Christoffer Dall
b7787e6666 KVM: arm64: Cleanup __activate_traps and __deactive_traps for VHE and non-VHE
To make the code more readable and to avoid the overhead of a function
call, let's get rid of a pair of the alternative function selectors and
explicitly call the VHE and non-VHE functions using the has_vhe() static
key based selector instead, telling the compiler to try to inline the
static function if it can.

Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 10:53:19 +00:00
Christoffer Dall
a2465629b6 KVM: arm64: Configure c15, PMU, and debug register traps on cpu load/put for VHE
We do not have to change the c15 trap setting on each switch to/from the
guest on VHE systems, because this setting only affects guest EL1/EL0
(and therefore not the VHE host).

The PMU and debug trap configuration can also be done on vcpu load/put
instead, because they don't affect how the VHE host kernel can access the
debug registers while executing KVM kernel code.

Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 10:53:19 +00:00
Christoffer Dall
c16c1131fb KVM: arm64: Directly call VHE and non-VHE FPSIMD enabled functions
There is no longer a need for an alternative to choose the right
function to tell us whether or not FPSIMD was enabled for the VM,
because we can simply can the appropriate functions directly from within
the _vhe and _nvhe run functions.

Reviewed-by: Marc Zyngier <marc.zyngier@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2018-03-19 10:53:19 +00:00