96Boards RB3 has a USB XHCI PCI Renesas host controller. This controller
requires firmware to be loaded on its ROM/RAM, so enable the module
CONFIG_USB_XHCI_PCI_RENESAS. This depends on CONFIG_USB_XHCI_PCI so
enable that as well.
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20210615081749.3210344-1-vkoul@kernel.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add support for SONY Xperia 1 and 5 smartphones, both based on the
Qualcomm SM8150 chipset. There also exist 5G-capable versions of these
devices, but they weren't sold much (if at all) outside Japan.
The devices are affected by a scary UFS behaviour where sending a certain UFS
command (which is worked around on downstream) renders the device unbootable,
by effectively erasing the bootloader. Therefore UFS AND UFSPHY are strictly
disabled for now.
Downstream workaround:
2e7a9ee1c9
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Tested-by: Marijn Suijten <marijn.suijten@somainline.org> (On Bahamut)
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210611203301.101067-2-konrad.dybcio@somainline.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Components that rely on proprietary (not to mention signed!) firmware should
not be enabled by default, as lack of the aforementioned firmware could cause
various issues, from random errors to straight-up failing to boot.
Not enabling modem back on the HDK, as it uses a sa8150.
Also fixed a sorting mistake in both boards' dt while at it.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210611203301.101067-1-konrad.dybcio@somainline.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Components that rely on proprietary (not to mention signed!) firmware should
not be enabled by default, as lack of the aforementioned firmware could cause
various issues, from random errors to straight-up failing to boot.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210612192358.62602-1-konrad.dybcio@somainline.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add the aforementioned properties in the SoC DTSI so that everybody doesn't
have to copy that into their device DTs, effectively reducing code
duplication.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210613114356.82358-1-konrad.dybcio@somainline.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
DPU/MDSS is borderline useless without MDP, so disabling
both of them makes little sense. With this change, enabling
mdss will be enough.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210613110635.46537-1-konrad.dybcio@somainline.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Up to here, the CPU boot mode can either be EL1 or EL2.
Correct the code comments a bit.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20210518101405.1048860-5-aisheng.dong@nxp.com
Signed-off-by: Will Deacon <will@kernel.org>
x5 is not used in the following map_memory. Instead,
__pa(__idmap_text_start) is stored in x3 which is used later.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/20210518101405.1048860-4-aisheng.dong@nxp.com
Signed-off-by: Will Deacon <will@kernel.org>
'count - 1' is confusing and not comply with the real code running.
'count' actually represents the extra entries required, no need minus 1.
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210518101405.1048860-3-aisheng.dong@nxp.com
Signed-off-by: Will Deacon <will@kernel.org>
When using CONFIG_ARM64_SW_TTBR0_PAN, a task's thread_info::ttbr0 must be
the TTBR0_EL1 value used to run userspace. With 52-bit PAs, the PA must be
packed into the TTBR using phys_to_ttbr(), but we forget to do this in some
of the SW PAN code. Thus, if the value is installed into TTBR0_EL1 (as may
happen in the uaccess routines), this could result in UNPREDICTABLE
behaviour.
Since hardware with 52-bit PA support almost certainly has HW PAN, which
will be used in preference, this shouldn't be a practical issue, but let's
fix this for consistency.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Fixes: 529c4b05a3 ("arm64: handle 52-bit addresses in TTBR")
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/1623749578-11231-1-git-send-email-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Contains changes to consolidate audio card names, adds audio support on
Jetson Xavier NX and enables SMMU on Tegra194.
-----BEGIN PGP SIGNATURE-----
iQJHBAABCAAxFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAmDDjl4THHRyZWRpbmdA
bnZpZGlhLmNvbQAKCRDdI6zXfz6zoYAqD/oCoIwSbN+JygsV1y7l1fJZrotmSISv
p9DhkLvTRHrEUFgp+I7/os2VDMDcF4UWwLcchBSpUZY7Nqi/Js091XR8m9XEniC5
XkgBI5v/ZvN6nXXU77WxbiLJ4EA98TpQj/CzjqNs9KGo7NZvZWNvSUECGkJ8qqdD
R1C+X9s+PMssPoz+GQRl9waNjk7uSFOb06w7l5wO+FqFbBVLl4ZG8rl8A38RUuYL
R/R8kQ/vNt55ujpz7FdUMkK35s3vb5Flf3agF5jKqUDqNVpM4diQgS9HRRSubYt1
EIIzPu9Il/IdhzM83x+o8JtiRqUPCGbg7Pms5piI36TRbFf7SLDkHMX+YNAXFRvC
DluT+7ThQ2ANMUXE9WhTJU/Fv7aEKqbXDSH9cJlU5ZzS3J8ZamKedTG6nLt9oE7B
Ebwgpmx6dctSjLJR/5hIgoanNthw2GmIa2/xrFH11if/W2XoTmvLZnWfqSjs/Ra7
YVv6V3nHhwcrh/FVNrTBjXisIAxo+9lLgzhe1jFiKCbrhlyOSAsKvARrOcdWEt5F
OVLjzr0co0NLqp2deXji9QpTxVKEhxWGU4tbZxbKe6A5vOEOvuYv6KJsXZOPD8Yv
AixIZPdvTqxX8hp9z0sohJiTqTf7CkFleAqQTSgmrMii04C5hLhPezGnK1KGBj3h
mD5QUXy7kfJCzg==
=A6hi
-----END PGP SIGNATURE-----
Merge tag 'tegra-for-5.14-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux into arm/dt
arm64: tegra: Device tree changes for v5.14-rc1
Contains changes to consolidate audio card names, adds audio support on
Jetson Xavier NX and enables SMMU on Tegra194.
* tag 'tegra-for-5.14-arm64-dt' of git://git.kernel.org/pub/scm/linux/kernel/git/tegra/linux:
arm64: tegra: Enable SMMU support on Tegra194
arm64: tegra: Hook up memory controller to SMMU on Tegra186
arm64: tegra: Use correct compatible string for Tegra186 SMMU
arm64: tegra: Audio graph sound card for Jetson Xavier NX
arm64: tegra: Consolidate audio card names
arm64: tegra: Add PMU node for Tegra194
Link: https://lore.kernel.org/r/20210611164437.3568059-6-thierry.reding@gmail.com
Signed-off-by: Olof Johansson <olof@lixom.net>
- Add DT support for Toshiba Visconti5 PWM driver
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEXmKe5SMhlzV7hM9DMiR/u0CtH6YFAmDH5nAACgkQMiR/u0Ct
H6bTIhAAh+7XXFrknfwxYANW0As/HfxxRRlHj04OUd6HsREHugj/X55n62F/eK0H
vVy78twgZ9ONhX64UXsFl3TyXsYtWZe0Nyb3QiSH2dp6X04RsdgcjVDluY8PepiR
aHOJgA5Udsr9Fj+6+HdmRMLf+BmmyfDbHGJW4p6dPIXrJBxI6yjCN9zrQybFMgG9
zPxYuKeDWDp5W2Hk/JZHxG2jI196Onq7DT7OookeWy0m77Kx35wxjgec/IannNZ1
WrVWtA7bu5pbMn0zO28EKMQ0BVA7ZvC5Ux77JEY2NCkL8HrAMoXU/RZ2V/1HenVS
loLgQcuvfzet4WuKHDM9+EUjZJ03gQM59+A+gTwR0OFzagNEvHwgshd9eB4citXH
qDhHhOtj8NmtuzulfrZvKNfdillnomECD96gr/3IrDbMYBEEkXsVQaq+EExyU4kg
v59RB2Y3pW3j1p3dKBTVwSyFdl8iuJK2gQ9a2qyUpTBywpHHk8ZlLLg35uk8vBVn
wiUnTR+v9QVVkBKrFPAMJhe3Utd+40l9eWqgp0kBLumHXP+/GIi2/IRkw3eyjaSx
zRD6cd1fAhls4kSGtaTvqOYIeiGfPoDvPxsTXNwNyy/93vuT6KIN9MRnii1v5yeD
gGFAEAxAtzUBzqCfAxM03bUgODAL2+XORLYYU8OVZA5k6GvhDKw=
=1GK5
-----END PGP SIGNATURE-----
Merge tag 'visconti-arm-dt-for-v5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/iwamatsu/linux-visconti into arm/dt
Visconti device tree updates for 5.14
- Add DT support for Toshiba Visconti5 PWM driver
* tag 'visconti-arm-dt-for-v5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/iwamatsu/linux-visconti:
arm64: dts: visconti: Add PWM support for TMPV7708 SoC
Link: https://lore.kernel.org/r/20210614234654.2u3xetnn5rwhymwz@toshiba.co.jp
Signed-off-by: Olof Johansson <olof@lixom.net>
MSM8916 gains new support for Huawei Ascend G7, with NFC, sensors and
touchscreen. The Samsung Galaxy A3/A5 gains battery support, touch keys,
NFC.
MSM8996 received more cleanup and refactoring, preparing for upcoming
new devices. Note worthy is the long pending enablement of CPUfreq.
SC7180 continues to stabilize, with a range of small fixes for various
bits and pieces, and new revisions for the CoachZ and pompom devices.
SC7280 continues to grow, with more clock controllers, thermal sensors,
thermal zones, CPUfreq and interconnect providers.
Xiaomi Poco F1 gaines audio support and the OnePlus 6/6T gaines IPA
support.
SM8350 gains some cleanups and the IPA device is enabled.
Initial support for the Microsoft Surface Duo, based on SM8150, is
added.
IPQ8074 gained support for the HK10 board.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmDH2OsbHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FDXkQAKsqE8ItJUGMoSjdmyFM
9qdaFPtrUI2kJdyq5HQ75duaSdIcVtiiDzl1w/oz8JQJg+1Wy0/x33Y8vPt4EIrs
9VQjeeXI4IyUMTnw/UEPZzmXebxYQBzryRQw0QQljptaFeIg9iVJXSUy+xqhHSdo
nWlT7XqWsDE/WA0JJhd1mPZeF1YQ7EbSJRAuME4lPDv8Toi158i2rFQLV/ebI306
U2KtN3C8N+XPsMwNZlGkPPIWXmcGlDgPHt3Wg7cTU8DUOP4c71pEuT2c8oC5o1Zu
XXd6Irp3MLlmLImLYZBLUYho1SCHknbya2pKGfBy39yiI0RqPFFIPVFjcpHMomDT
r1qsvbvtktK5TW7sYGR+Fcf66vQbvFVbydgR4IzvGth1DbajEkCGlPL7GwJURGN6
U5U6Fws6cF0wko81CMy09/9j9F/HmWsL0t1z3aL3gdo0DswsxUy5NsWcEEY9xG0t
A8IT7Qjd0t1OnVYp12oUKRKsvGtjL7O5iDBEV4QU4h2ckT0i12Wnxev1t6mw56V6
RWzKd0aki7NCFwQ3AWWNeFpC+hmVrKz3OtnSQbjS0R+DEg9ayO9T46UVLer1maoh
yXbaXyd5A1Vl3NQ4+1CARHgCWA9fmgJD13DDPF6zEVwPY8JS4ARSXVCLDXI7z4zC
5xyHsMOMWPhR8LHaAUxlGqyU
=Pj6c
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-for-5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/dt
Qualcomm ARM64 DT updates for v5.14
MSM8916 gains new support for Huawei Ascend G7, with NFC, sensors and
touchscreen. The Samsung Galaxy A3/A5 gains battery support, touch keys,
NFC.
MSM8996 received more cleanup and refactoring, preparing for upcoming
new devices. Note worthy is the long pending enablement of CPUfreq.
SC7180 continues to stabilize, with a range of small fixes for various
bits and pieces, and new revisions for the CoachZ and pompom devices.
SC7280 continues to grow, with more clock controllers, thermal sensors,
thermal zones, CPUfreq and interconnect providers.
Xiaomi Poco F1 gaines audio support and the OnePlus 6/6T gaines IPA
support.
SM8350 gains some cleanups and the IPA device is enabled.
Initial support for the Microsoft Surface Duo, based on SM8150, is
added.
IPQ8074 gained support for the HK10 board.
* tag 'qcom-arm64-for-5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux: (85 commits)
arm64: dts: qcom: sc7180: Add xo clock for eMMC and Sd card
arm64: dts: sc7280: Add interconnect provider DT nodes
arm64: dts: qcom: msm8916-huawei-g7: Add NFC
arm64: dts: qcom: msm8916-huawei-g7: Add display regulator
arm64: dts: qcom: msm8916-huawei-g7: Add sensors
arm64: dts: qcom: msm8916-huawei-g7: Add touchscreen
arm64: dts: qcom: msm8916: Add device tree for Huawei Ascend G7
arm64: dts: qcom: sc7180-trogdor: Update flash freq to match reality
arm64: dts: qcom: sc7180: Add wakeup delay for adau codec
arm64: dts: qcom: sdm845: Remove cros-pd-update on Cheza
arm64: dts: qcom: sc7180: Remove cros-pd-update on Trogdor
arm64: dts: qcom: sc7180: Disable PON on Trogdor
arm64: dts: qcom: sc7180: Modify SPI_CLK voltage level for trogdor
arm64: dts: qcom: add initial device-tree for Microsoft Surface Duo
arm64: dts: qcom: sdm845-mtp: enable IPA
arm64: dts: qcom: sc7180: SD-card GPIO pin set bias-pull up
arm64: dts: qcom: sc7180: Move sdc pinconf to board specific DT files
arm64: dts: qcom: msm8916-samsung-a2015: Add NFC
arm64: dts: qcom: msm8916-samsung-a2015: Add rt5033 battery
arm64: dts: qcom: msm8916-samsung-a5u: Add touch key regulator
...
Link: https://lore.kernel.org/r/20210614223712.393096-1-bjorn.andersson@linaro.org
Signed-off-by: Olof Johansson <olof@lixom.net>
This enables VADC, audio codecs and Venus (video decoder) found on
MSM8916 among others and the SM8350 interconnect provider driver.
-----BEGIN PGP SIGNATURE-----
iQJPBAABCAA5FiEEBd4DzF816k8JZtUlCx85Pw2ZrcUFAmDH0gsbHGJqb3JuLmFu
ZGVyc3NvbkBsaW5hcm8ub3JnAAoJEAsfOT8Nma3FgkEP/3jUJN4pp/hdWlF27z8p
FuSFxqjaLPVbKVoF47bIENsN71Jcs5ahyoxFFIxW5cH1BwGQ6T2cfvzW6Rj++rkY
Rr6xasJNTw0yu3gszaue2lFE+vLIbZaYVtqarPjIAow5Lsxcfm2UM5AoUt9etrK2
r+RQTxbsvv1AJ28eq+zEB/oyh1MC66ePQAoaii4qwTq0pj/vObzc3hSEJKDjzQ+O
Aw1uuXdH4AdSi0yi6mkxc62yphYldL6TqQHjnO26uvxhPitfy4Yp7ibPtvVsuId3
F9d5zr8SJsbOAyjx7Fty6OegVFq9apkyTxU5Vt1Kwx1slVVAwQscRRqlbuni/qyq
FoN86X8fkTRXS7ncgF99tjOEEqbbWIkcdUmMySRQqrHBR5RLkFszNvX7s4Hf4Drf
MSLH76ABEwMo/mwRsJ7vSQiubiYygBdN1BcQbwWhW8fA8GlvpV+bMuZW8XH78fO9
oLR33zvfUe64itf74yN7JqGGMSmnMho37XTnPtTbdjKfltLsGiMtEliv5m05Pwf/
Hihn0UL4NwMUB84LShu8Jbp1G0KaE0raiU07Swa7rMRE2G7HwHSYwrT/oPufwWaS
tnlkv4HY85i+L8QAGCbtkYu+6X/dXFrtfubfGR0GZXeQwHS5vPF90w+6eUptStpN
GBzyWdbWwvSbP5g+LIeJKkO2
=Uyjq
-----END PGP SIGNATURE-----
Merge tag 'qcom-arm64-defconfig-for-5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux into arm/defconfig
Qualcomm ARM64 defconfig udpates for v5.14
This enables VADC, audio codecs and Venus (video decoder) found on
MSM8916 among others and the SM8350 interconnect provider driver.
* tag 'qcom-arm64-defconfig-for-5.14' of https://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: defconfig: add drivers needed for DragonBoard410c
arm64: defconfig: qcom: enable interconnect for SM8350
Link: https://lore.kernel.org/r/20210614223704.393042-1-bjorn.andersson@linaro.org
Signed-off-by: Olof Johansson <olof@lixom.net>
- New board support: i.MX8MM Gateworks GW7901 board.
- Add SPBA bus description for i.MX8MN and i.MX8MM.
- A series of update on imx8mq-nitrogen board to add USB OTG/Host and
LT8912 MIPI-DSI to HDMI support.
- Correct enet clock description for i.MX8 Connection Subsystem.
- A couple of patches from Heiko Schocher to add FlexSPI device for
i.MX8MP SoC and enable SPI NOR Flash support on imx8mp-phycore-som.
- Remove the reference to audio IPG clock on i.MX8MP.
- Enable EQOS Ethernet and PMIC device support for imx8mp-evk.
- Disable USB over-current on imx8mm-evk and imx8mn-evk.
- Add dma-ranges description for i.MX8MM and i.MX8MN SoC.
- Add PCIe clock description for i.MX8MQ SoC.
- Enable PCIe support on freeway board.
- Enable OPTEE support on ls1028a-rdb board.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmDFvn4UHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM5v7Qf/QbcMDnuc3phG9SvVY2HYRhJwQqr+
Fj6bXtPZAtk6knPjdhuxhtbLqDbZoDaJGOYaZE2itJpSfMIRZHgk5gb+fz4caZvC
ZS4nefLmjAlyctlVaDpDwUGQVis+7BfwnsY7HVqbbqJDXjC0bNL0iQvcvIKjDDdg
aXirBcpZvRtdkXvXG2QdUZJmTjnLnDKe9oM6AP6Ernami5n3yX7VT9AyJfKQoEra
9A6Y+sGol65W8S2qVcpPxWfSSoiRHSKKuSlOHpeRaIALRCz0WgyIvvB1NsY1lTBt
VkhLq5ySI+AnHJwvBUn6R10cV8Lx4rUOi3Q4EtH/Sg7dtiK+UKKa2YmTxg==
=seFj
-----END PGP SIGNATURE-----
Merge tag 'imx-dt64-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/dt
i.MX arm64 device tree chagnes for 5.14:
- New board support: i.MX8MM Gateworks GW7901 board.
- Add SPBA bus description for i.MX8MN and i.MX8MM.
- A series of update on imx8mq-nitrogen board to add USB OTG/Host and
LT8912 MIPI-DSI to HDMI support.
- Correct enet clock description for i.MX8 Connection Subsystem.
- A couple of patches from Heiko Schocher to add FlexSPI device for
i.MX8MP SoC and enable SPI NOR Flash support on imx8mp-phycore-som.
- Remove the reference to audio IPG clock on i.MX8MP.
- Enable EQOS Ethernet and PMIC device support for imx8mp-evk.
- Disable USB over-current on imx8mm-evk and imx8mn-evk.
- Add dma-ranges description for i.MX8MM and i.MX8MN SoC.
- Add PCIe clock description for i.MX8MQ SoC.
- Enable PCIe support on freeway board.
- Enable OPTEE support on ls1028a-rdb board.
* tag 'imx-dt64-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux: (24 commits)
arm64: dts: imx8mn-evk: disable over current for usb
arm64: dts: imx8mm-evk: disable over current for usb1
arm64: dts: freescale: Separate each group of data in the property 'reg'
arm64: dts: imx8: conn: fix enet clock setting
arm64: dts: imx8mq: assign PCIe clocks
arm64: dts: imx8mn: specify dma-ranges
arm64: dts: imx8mm: specify dma-ranges
arm64: dts: fsl-ls1028a: Correct ECAM PCIE window ranges
arm64: dts: imx8mn-beacon-som: Assign PMIC clock
arm64: dts: ls208xa: remove bus-num from dspi node
arm64: dts: ls1012a: enable PCIe on freeway board
arm64: dts: imx8mp-evk: enable EQOS ethernet
arm64: dts: imx8mp: Remove the reference to audio ipg clock on imx8mp
arm64: dts: imx8mq-evk: add one regulator used to power up pcie phy
arm64: dts: imx8mm: Add spba1 and spba2 buses
arm64: dts: imx8mn: Add spba1 bus
arm64: dts: imx8mq-nitrogen: add lt8912 MIPI-DSI to HDMI
arm64: dts: imx8mq-nitrogen: add USB HOST support
arm64: dts: imx8mq-nitrogen: add USB OTG support
arm64: dts: imx8mp-phycore-som: enable spi nor
...
Link: https://lore.kernel.org/r/20210613082544.16067-5-shawnguo@kernel.org
Signed-off-by: Olof Johansson <olof@lixom.net>
Currently, the lower bits of fault address is cleared before it's
passed to handle_mm_fault(). It's unnecessary since generic code
does same thing since the commit 1a29d85eb0 ("mm: use vmf->address
instead of of vmf->virtual_address").
This passes the original fault address to handle_mm_fault() in case
the generic code needs to know the exact fault address.
Signed-off-by: Gavin Shan <gshan@redhat.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Anshuman Khandual <anshuman.khandual@arm.com>
Link: https://lore.kernel.org/r/20210614122701.100515-1-gshan@redhat.com
Signed-off-by: Will Deacon <will@kernel.org>
SECTION_[SHIFT|SIZE|MASK] are essentially PMD_[SHIFT|SIZE|MASK]. But these
create confusion being similar to generic sparsemem memory sections, which
are derived from SECTION_SIZE_BITS. Section references have always implied
PMD level block mapping. Instead just use all PMD level macros which would
make it explicit and also remove confusion with sparsmem memory sections.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
Reviewed-by: Gavin Shan <gshan@redhat.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/1623658706-7182-1-git-send-email-anshuman.khandual@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
If the kernel is not compiled with CONFIG_ARM64_PTR_AUTH_KERNEL=y,
then no PACI/AUTI instructions are expected while the kernel is running
so the kernel's key will not be used. Write of a system registers
is expensive therefore avoid if not required.
Signed-off-by: Daniel Kiss <daniel.kiss@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210613092632.93591-3-daniel.kiss@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
This patch add the ARM64_PTR_AUTH_KERNEL config and deals with the
build aspect of it.
Userspace support has no dependency on the toolchain therefore all
toolchain checks and build flags are controlled the new config
option.
The default config behavior will not be changed.
Signed-off-by: Daniel Kiss <daniel.kiss@arm.com>
Acked-by: Will Deacon <will@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210613092632.93591-2-daniel.kiss@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
The calculations for the DLL register values are based on the clock rate
of the reference clock. Provide the reference clock in the definition of
the two SDHCI controllers to not rely on the default values.
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Signed-off-by: Shaik Sajida Bhanu <sbhanu@codeaurora.org>
Link: https://lore.kernel.org/r/1623309107-27833-1-git-send-email-sbhanu@codeaurora.org
[bjorn: Rewrote commit message]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Currently the common definition of function_nocfi() is provided by
<linux/mm.h>, and architectures are expected to provide a definition in
<asm/memory.h>. Due to header dependencies, this can make it hard to use
function_nocfi() in low-level headers.
As function_nocfi() has no dependency on any mm code, nor on any memory
definitions, it doesn't need to live in <linux/mm.h> or <asm/memory.h>.
Generally, it would make more sense for it to live in
<linux/compiler.h>, where an architecture can override it in
<asm/compiler.h>.
Move the definitions accordingly.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Sami Tolvanen <samitolvanen@google.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210602153701.35957-1-mark.rutland@arm.com
8250_omap compatible UART IPs on all SoCs have registers aligned at 4
byte address boundary and constant byte addressability. Thus there is no
need for reg-io-width or reg-shift DT properties. These properties are
not used by 8250_omap driver nor documented as part of binding document.
Therefore drop them.
This is in preparation to move omap-serial.txt to YAML format.
Signed-off-by: Vignesh Raghavendra <vigneshr@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210607134558.23704-1-vigneshr@ti.com
ti,pindir-d0-out-d1-in property is expected to be of type boolean.
Therefore, fix the property accordingly.
Fixes: 4fb6c04683 ("arm64: dts: ti: k3-am642-evm: Add support for SPI EEPROM")
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210608051414.14873-3-a-govindraju@ti.com
The current device tree CPSW3g node adds non-zero "mac-address" property to
the ports, which prevents random MAC address assignment to network devices
if bootloader failed to update DT. This may cause more then one host to
have the same MAC in the network.
mac-address = [00 00 de ad be ef];
mac-address = [00 01 de ad be ef];
In addition, there is one MAC address available in eFuse registers which
can be used for default port 1.
Hence, fix ports MAC properties by:
- resetting "mac-address" property to 0
- adding ti,syscon-efuse = <&main_conf 0x200> to Port 1
Fixes: 3753b12877 ("arm64: dts: ti: k3-am64-main: Add CPSW DT node")
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210608184940.25934-1-grygorii.strashko@ti.com
Drop the hub_5v regulator which controls the HUB Reset line with GPIOH_4 which
is already controlled by a GPIO HOG.
Until we can properly describe how to control USB HUBs reset lines, keeping
the GPIO HOG is an acceptable solution we use on multiple boards.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210607065435.577334-8-narmstrong@baylibre.com
Add a node for the XT25F128B SPI-NOR flash to make it accessible
from Linux.
Signed-off-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210607065435.577334-7-narmstrong@baylibre.com
As described in the HC4 schematics, GPIOH_8 controls the USB 5V and 12V
regulators used to power the SATA drives.
And is set as Open Drain since this GPIO doesn't support Push-Pull.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210607065435.577334-6-narmstrong@baylibre.com
As described in the HC4 schematics, only the USB port B is used,
port A is left unconnected. Thus disable PHY0 and remove it from PHYs list.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210607065435.577334-5-narmstrong@baylibre.com
As described in the Odroid-C4 & Odroid-HC4 schematics, the 5V regulator is controlled
by GPIOH_8 and in Open Drain since this GPIO doesn't support Push-Pull.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210607065435.577334-4-narmstrong@baylibre.com
According to Odroid-C4 & HC4 Schematics, the TF_3V3N_1V8_EN can be in Hi-Z for 3v3,
and since it's the default GPIOAO_6 mode at reset, let switch this GPIO as Open-Source
to drive for 1, and input for 0.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210607065435.577334-3-narmstrong@baylibre.com
As described in the schematics of Odroid-C4 and Odroid-HC4, the TF_IO regulator
is enabled by the GPIOE_2 GPIO and gets it's supply from VCC_5V.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210607065435.577334-2-narmstrong@baylibre.com
All users of arm_pm_restart() have been converted to use the kernel
restart handler.
Acked-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Tested-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
There are 3 additional patches pending that handle the backward
compatiblity inside the PCI subsystem, but the address ranges
should be fixed anyway.
-----BEGIN PGP SIGNATURE-----
iQFEBAABCAAuFiEE7v+35S2Q1vLNA3Lx86Z5yZzRHYEFAmDD4CsQHGhlaWtvQHNu
dGVjaC5kZQAKCRDzpnnJnNEdgSjiB/4j2bmuvwwsB7ZRQjtjpmFNl+eGCeiXZTPL
ex8TEOMsG7ra+xMDF5ElbfLi8PnHu3VIZxCRLbU3r/15NRHY/Z34P59TDsW8WeQS
eVaSa87JlWxFL2JH/CSDGgPSY3jG33kk0cCf4a+FXFjMkaSNAUaXwpvCBio0MQG1
T5QnqEpV91Iej/BMXqyljst2LZNlYsN+vT4BGv4uaqUb6EPSOTSm1xJ60kbPPvE6
ylaqP/tUfL3u8hC1u0vrc2MWZh+Y/0EPyHvmLBEkTvOROTNOdNGiGvTfs5Gce2eu
Bzyzkn4Cp8d/UioGCpyKeXwcBYe47UlM1J28GTXUY3D+TKrjGhKy
=SSkm
-----END PGP SIGNATURE-----
Merge tag 'v5.13-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip into arm/fixes
Fix PCIe address ranges that are affected by recent PCI changes.
There are 3 additional patches pending that handle the backward
compatiblity inside the PCI subsystem, but the address ranges
should be fixed anyway.
* tag 'v5.13-rockchip-dtsfixes1' of git://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip:
arm64: dts: rockchip: Update RK3399 PCI host bridge window to 32-bit address memory
Link: https://lore.kernel.org/r/3405741.0S5aU1g85B@diego
Signed-off-by: Olof Johansson <olof@lixom.net>
mainly:
- I2S Support for the V3
- Audio Codec Support for the V3s
- DMA support for the V3s
- PWM support for the V3s
- Support for Bluetooth Audio on the pinephone
- Add A10-like timers to the A64 and R40
- New boards: Forlinx OKA40i-C, Forlinx OKA40i-C, NanoPi R1S H5
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCYMN5hwAKCRDj7w1vZxhR
xa2sAP0Y4UY9ncxWmuTUMgi4osqscowxGUsCHdfxP+Yk9/IJ8wEAqKA5tfior25d
guy+cgXft/CixRtgv6Go3W55tJpZ6wQ=
=A9Cb
-----END PGP SIGNATURE-----
Merge tag 'sunxi-dt-for-5.14-1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into arm/dt
Our usual bunch of patches to improve the Allwinner SoCs support,
mainly:
- I2S Support for the V3
- Audio Codec Support for the V3s
- DMA support for the V3s
- PWM support for the V3s
- Support for Bluetooth Audio on the pinephone
- Add A10-like timers to the A64 and R40
- New boards: Forlinx OKA40i-C, Forlinx OKA40i-C, NanoPi R1S H5
* tag 'sunxi-dt-for-5.14-1' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: (29 commits)
ARM: dts: sun8i: v3s: enable emac for zero Dock
arm64: dts: allwinner: pinephone: Set audio card name
ARM: dts: sun8i: r40: Add timer node
ARM: dts: sun8i: V3: add I2S interface to V3 dts
dt-bindings: sound: sun4i-i2s: add Allwinner V3 I2S compatible
ARM: dts: sun8i: V3: add codec analog frontend to V3 dts
ASoC: dt-bindings: sun8i-a23-codec-analog: add compatible for Allwinner V3
ARM: dts: sun8i: v3s: add analog codec and frontend to v3s dts
ARM: dts: sun8i: v3s: add DMA properties to peripherals supporting DMA
ARM: dts: sun8i: v3s: add DMA controller to v3s dts
ARM: dts: sun8i: v3s: add pwm controller to v3s dts
dt-bindings: pwm: allwinner: add v3s pwm compatible
arm64: dts: allwinner: h5: Add NanoPi R1S H5 support
dt-bindings: arm: Add NanoPi R1S H5
arm64: dts: allwinner: pinephone: Add support for Bluetooth audio
arm64: dts: allwinner: a64: Allow multiple DAI links
arm64: dts: allwinner: a64: Add pinmux nodes for AIF2/AIF3
arm64: dts: allwinner: a64: Allow using multiple codec DAIs
ARM: dts: sun8i-a33: Allow using multiple codec DAIs
ASoC: dt-bindings: sun8i-codec: Increase #sound-dai-cells
...
Link: https://lore.kernel.org/r/96cc77ec-139d-4685-8a66-a60964cf39fd.lettre@localhost
Signed-off-by: Olof Johansson <olof@lixom.net>
- Set MMC_MTK as built-in to be able to boot from MMC device.
-----BEGIN PGP SIGNATURE-----
iQJLBAABCAA1FiEEUdvKHhzqrUYPB/u8L21+TfbCqH4FAmDDNmUXHG1hdHRoaWFz
LmJnZ0BnbWFpbC5jb20ACgkQL21+TfbCqH6rehAAtAdaEHTBnYGhmRrgZZZigT5d
237SaFWne4bnePDd6hpoU44bpqxn7x8pVPXMLEZeeJwam4y5wfGs3lYeDZ8n/FG9
7g7oLKRjhsyI2skf5TJtk/lzsuRU1Ahr8pY4oypnd+irForwvxWD3mFTc7QjbGXJ
Z/05TNjBbHXUgtRPqKjs/WIjxKFIba1yWSGjRjD3xowl2zkhlyyfXyhWXl29kFE+
Ynd3VYVchfznqDV5yk/8+cjUFZjerxFIr9Ztz9fpAQDKJ6Ll9WZ8d18S/JtGc+bT
Vua0iLxnek0bgIfwxmmNlwP0j5Mz6Q5p2mYHWcrpUm3MEB8I77IUjg32WQL1WSey
U3de+GsDVtqGfCYDIM7FXYZfxabU4CyvzKhh2UnypdRiakH4kVfZszngPWDC1rK9
5Jqgu8mjFFtHINn25ud5ONFVBq2E58xJIKbxiopK6slc5jDYbZscYhzgnPrr9lfK
3AScENfxW3NBb96Ca2LV3tTTaWfXj6MOExFqxYj3J9fQOEsK9/DxJSH0ZrhgsV/j
l+hRQE3CzKA0Yw3m6GHlXjiUCdieIm2zMKK7G7YOVZDBWTk7o2y+fPoh8TEgtbue
jYSaY/MXRJ6GokQxEi1INBgCiiweKZ90XvdtQF6wleEFQ73mM56zpRlKgV+mKcrU
t3XTWoJys+MVIzo9zrs=
=MS0W
-----END PGP SIGNATURE-----
Merge tag 'v5.13-next-defconfig' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux into arm/defconfig
- Delete MTK_PMIC_WRAP added twice.
- Set MMC_MTK as built-in to be able to boot from MMC device.
* tag 'v5.13-next-defconfig' of https://git.kernel.org/pub/scm/linux/kernel/git/matthias.bgg/linux:
arm64: defconfig: Allow Mediatek boards to boot from the mmc
arm64: defconfig: Do not override the MTK_PMIC_WRAP symbol
Link: https://lore.kernel.org/r/ad6f7f4e-7e4d-08b9-8781-71bd78444929@gmail.com
Signed-off-by: Olof Johansson <olof@lixom.net>
- Enable support for the new RZ/G2L SoC variants in the arm64
defconfig.
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCYMMlhwAKCRCKwlD9ZEnx
cKvlAQDHZ4Us8NCpurU4LnFb01IjM5wnHhRZV67K1bS57ydX9AD/acKtF+lRgjz4
je+6YID3qhtsu0XXpRGA7GuiciTwdQw=
=ZT5k
-----END PGP SIGNATURE-----
Merge tag 'renesas-arm-defconfig-for-v5.14-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/defconfig
Renesas ARM defconfig updates for v5.14 (take two)
- Enable support for the new RZ/G2L SoC variants in the arm64
defconfig.
* tag 'renesas-arm-defconfig-for-v5.14-tag2' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
arm64: defconfig: Enable ARCH_R9A07G044
Link: https://lore.kernel.org/r/cover.1623403795.git.geert+renesas@glider.be
Signed-off-by: Olof Johansson <olof@lixom.net>
Just a single fix to use standard and generic nodes names for SCMI
power domain controller and clock controller devicetree nodes.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEunHlEgbzHrJD3ZPhAEG6vDF+4pgFAmDDE7YACgkQAEG6vDF+
4pg9mw/9EBMGCtYLRwJtc/0IvRrFEVmtqRcmwEKBrXagFnk62NmY5y5OemfToqse
T2UQdDfoj0Jr+1LVY5ScMAkugIbcadWVMQoLhTF82xTTTWsG5Q2rcRFb1gQeFSwG
gzes4PrQYkbPcdCphoAEr6veRhOJW5fwKU0txHs2grjILOKZczSfFcYdM2eki4Wf
84FwgitESBRpz4g3YKf0cKIeN+Q4kYJu3o40Z6V1fRPXuWycLW+0xSxG6u778Q7V
a2KK03dbNj1WYYGOhCS2lz3aN8vZXJPaTkUgnskam7hK9IlwwWy3CccK63QgfBmQ
OlKKA+3rVe8PUIHLCej3HT9PxY/3LCLG3NChqZ7vy5Btd6QJKaSI9Pc9sy2eUaPc
JNIblu+qu5bOO6/adsKBhX/dyiCqN8/KFDOLv9N+oBvJrRjGEWjd2nE44W2hhWEv
fdzrSgSkgvb5WGhDnCivS0ZkFim91D3Ayjq1FlkYRIXoo4h9LyO1ruDLK/pF9yOc
29X7gEryM8n9q9Kq7ypGF4sKd9JrBbk2XCFxp7rXq+uueSHUXqvtey06BnrvV7Tl
NTEon08E6Wo4KzUk6ZkunaufhAJx6cgMCn+dCCY+IrMWDitMn4I86h1uJDNnuWwS
1OrFZpXiq9jw5iBF158LcWzAwTIUxxFwNPaOJycbjgCGQiELw2Q=
=36FY
-----END PGP SIGNATURE-----
Merge tag 'juno-fix-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux into arm/dt
ARMv8 Juno fix for v5.14
Just a single fix to use standard and generic nodes names for SCMI
power domain controller and clock controller devicetree nodes.
* tag 'juno-fix-5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/sudeep.holla/linux:
arm64: dts: juno: Update SCPI nodes as per the YAML schema
Link: https://lore.kernel.org/r/20210611075805.2813712-1-sudeep.holla@arm.com
Signed-off-by: Olof Johansson <olof@lixom.net>
please pull the following:
- Zhen fixes the Broadcom stingray serial node unit names to fix a DT
binding warning
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmDCa9EACgkQh9CWnEQH
BwSGaRAAtLAJ1kD/AlcXGgnjW/l7PLYh6ni7oJbHwGtdisAABF8lYeYTG1d4AY8B
Dq9n3T1qi3+ZYEpiRx//43A3457ez089/l3Qn5Eu5NWAQ/Fp1BN0hw50/np3dIac
sxckbQGDamb0m+/nqR7v6pG58MTA+uf0PhW6zkRnhKdY4SujSVzcufwceNJNTA0d
3i5TlZaGRzgTCjmpASFQHRAgm/vc8fmYls8uSdyCyg1glkc/GyhdVwGpUl4jzw6f
wg8+0xpft41/gzTu7u/NXBk1TbAVJi2ez4LHaviSgHF47a/y6J/F1N7pzUSGlbFF
43ZVWXO5G3Wkl32lwiUEEWrA2EWu9rdlofv71RLWBI1s7B4bMGH5bcgw7OsyukV0
beQro/vPyF1R3wuEiAByQdFa3c104l3Jg1VOTBMKnoQuLE1Di9iSQfbIOnXlr4us
6WKPGmkgbtBLqkpSjs0rbGWk4w+sAmyIHGPx5bAGcb367yqmpNTNJDLlR93iozPU
q4zyb08aexxB7CNuSuxwtCb6t75UgmLBX0ow6D985wLlP3VQzm189IIdA8kvpf5l
NH39QdoFlzHv8ioqsPwhNselxJQUIM0brWm+vxXcTzTR1V8umtJI3ar09de3bLuH
/2KmgiSjDSodLSSuWDMXg6EQh4MftieRooF0uHJ8f7spvXrYkXI=
=6wtT
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-5.14/devicetree-arm64' of https://github.com/Broadcom/stblinux into arm/dt
This pull request contains Broadcom ARM64-based SoCs changes for 5.14,
please pull the following:
- Zhen fixes the Broadcom stingray serial node unit names to fix a DT
binding warning
* tag 'arm-soc/for-5.14/devicetree-arm64' of https://github.com/Broadcom/stblinux:
arm64: dts: broadcom: normalize the node name of the UART devices
Link: https://lore.kernel.org/r/20210610194836.309869-2-f.fainelli@gmail.com
Signed-off-by: Olof Johansson <olof@lixom.net>
for 5.14, please pull the following:
- Rafal updates the BCM5301x, HR2, BCM63xx, BCM5301x, NSP and Cygnus DTS
files to resolve a number of DT binding check warnings pertaining to
NAND, pinmux, clocks, SPI
- Stefan provides a fix for an increase in the DWC2 controller's RX FIFO
causing regressions on the Raspberry Pi 4B
- Mateusz adds a BCM2711 specific VEC compatible string to allow keying
off that variant properly
- Stefan adds support for the Raspberry Pi 400 by doing some DTS/DTSI
re-organization work and finally adding the DTS file proper
-----BEGIN PGP SIGNATURE-----
iQIyBAABCgAdFiEEm+Rq3+YGJdiR9yuFh9CWnEQHBwQFAmDCa4cACgkQh9CWnEQH
BwRszA/1Fed5AmheLNW0wEWfEvZ+uACS+jTINXV09rGuU1HZj0qeTv/bO1PJfl4m
tdSfUWdBTRa0IHeQ9o00GC2Rm/6UJoStAU2rOABw+sKJpH9y+El20xNBnqx5iXzO
GUlIGbm27S3XWZR5EF6f1ZCej4cJZbpv/Ms9sEHa3b1aT3fJfackiBEk3uyhYX8Q
fdxG9VNMyZIDOkocWQDeBCD82/IsizN3anFx88FP3vUtTYn/CldCc4H7JDmMzXid
o3uRTAYta/Ls4z3IsI5hSWZ5+Psv7rbO+Qa/crPZm0SKzPIxQ7drglRJkbMtRSJu
E27+9bzdLq4ruvUdJF/Wa1B2FKvk4kPtdMRwvStV7hoMrR9+DJ9S2trUUS4aehbx
/keSHahZSbwWuWtHlmkmsqjTSAxFHsFVfCE3tM9qUo8uWjtxYA+6JyWW4SRw9/nw
IOcRdxCeLYI29rWeACRjJ2XXXlwHLZWvZr1OrJVwJM2lMxKgLVqiQ38+O8uHDIEx
CVZE0IM5CqAy5nusOs4jibfBJrbnhhst77j3pDeqkjo/Nv2f2GcxEciw8D+uH+tU
4mj7sT4nQGSj3+lGtFml+s4MwBcbClcoep3VfIm+30JF41Xwa6Knv3+okJKM0DJK
VX/pCBkov6QuOwS2P3KIFxHGtamlzJnz4hu6zpOiuJVZoxqdGQ==
=ZmMv
-----END PGP SIGNATURE-----
Merge tag 'arm-soc/for-5.14/devicetree' of https://github.com/Broadcom/stblinux into arm/dt
This pull request contains Broadcom ARM-based SoCs Device Tree changes
for 5.14, please pull the following:
- Rafal updates the BCM5301x, HR2, BCM63xx, BCM5301x, NSP and Cygnus DTS
files to resolve a number of DT binding check warnings pertaining to
NAND, pinmux, clocks, SPI
- Stefan provides a fix for an increase in the DWC2 controller's RX FIFO
causing regressions on the Raspberry Pi 4B
- Mateusz adds a BCM2711 specific VEC compatible string to allow keying
off that variant properly
- Stefan adds support for the Raspberry Pi 400 by doing some DTS/DTSI
re-organization work and finally adding the DTS file proper
* tag 'arm-soc/for-5.14/devicetree' of https://github.com/Broadcom/stblinux:
arm64: dts: broadcom: Add reference to RPi 400
ARM: dts: Add Raspberry Pi 400 support
ARM: dts: bcm283x: Fix up GPIO LED node names
dt-bindings: arm: bcm2835: Add Raspberry Pi 400 to DT schema
ARM: dts: Move BCM2711 RPi specific into separate dtsi
ARM: dts: bcm283x: Fix up MMC node names
ARM: boot: dts: bcm2711: Add BCM2711 VEC compatible
Revert "ARM: dts: bcm283x: increase dwc2's RX FIFO size"
ARM: dts: BCM5301X: Fixup SPI binding
dt-bindings: clock: brcm, iproc-clocks: convert to the json-schema
ARM: dts: BCM5301X: Fix pinmux subnodes names
ARM: dts: Hurricane 2: Fix NAND nodes names
ARM: dts: BCM63xx: Fix NAND nodes names
ARM: NSP: dts: fix NAND nodes names
ARM: Cygnus: dts: fix NAND nodes names
ARM: brcmstb: dts: fix NAND nodes names
ARM: dts: BCM5301X: Fix NAND nodes names
Link: https://lore.kernel.org/r/20210610194836.309869-1-f.fainelli@gmail.com
Signed-off-by: Olof Johansson <olof@lixom.net>
- Refresh shmobile_defconfig for v5.13-rc1
- Enable R-Car USB2 clock selector support
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQQ9qaHoIs/1I4cXmEiKwlD9ZEnxcAUCYLChcAAKCRCKwlD9ZEnx
cH0xAQDKjUogB7W9c/K9I5+zNyqAtWvf3aqfrlBV0wnOvPk4jgD/Siph1MbVJacv
VQFV8LS4Ip7+RKJ1cPexHvVIW5DAxwg=
=+ks9
-----END PGP SIGNATURE-----
Merge tag 'renesas-arm-defconfig-for-v5.14-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel into arm/defconfig
Renesas ARM defconfig updates for v5.14
- Refresh shmobile_defconfig for v5.13-rc1
- Enable R-Car USB2 clock selector support
* tag 'renesas-arm-defconfig-for-v5.14-tag1' of git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-devel:
arm64: defconfig: Enable usb2_clksel for R-Car Gen3 and RZ/G2
ARM: shmobile: defconfig: Refresh for v5.13-rc1
Link: https://lore.kernel.org/r/cover.1622188834.git.geert+renesas@glider.be
Signed-off-by: Olof Johansson <olof@lixom.net>
imx8mn evk board usb port does not support over current detection,
so disable it.
Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
imx8mm evk board usb1 port does not support over current detection,
so disable it.
Signed-off-by: Li Jun <jun.li@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Do not write the 'reg' of multiple groups of data into a uint32 array,
use <> to separate them. Otherwise, the errors similar to the following
will be reported by reg.yaml.
arch/arm64/boot/dts/freescale/fsl-ls1012a-frdm.dt.yaml:
soc: pcie@3400000:reg:0: \
[0, 54525952, 0, 1048576, 64, 0, 0, 8192] is too long
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
enet_clk_ref actually is sourced from internal gpr clocks
which needs a default rate. Also update enet lpcg clock
output names to be more straightforward.
Cc: Abel Vesa <abel.vesa@nxp.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Dong Aisheng <aisheng.dong@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
This fixes multiple issues with the current non-existent PCIe clock setup:
The controller can run at up to 250MHz, so use a parent that provides this
clock.
The PHY needs an exact 100MHz reference clock to function if the PCIe
refclock is not fed in via the refclock pads. While this mode is not
supported (yet) in the driver it doesn't hurt to make sure we are
providing a clock with the right rate.
The AUX clock is specified to have a maximum clock rate of 10MHz. So
the current setup, which drives it straight from the 25MHz oscillator is
actually overclocking the AUX input.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
DMA addressing capabilities on i.MX8MN are limited by the interconnect,
same as on i.MX8MQ. Add dma-ranges to the the peripheral bus to let
the kernel know about this.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
DMA addressing capabilities on i.MX8MM are limited by the interconnect,
same as on i.MX8MQ. Add dma-ranges to the the peripheral bus to let
the kernel know about this.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Currently all PCIE windows point to bus address 0x0, which does not match
the values obtained from hardware during EA.
Replace those values with CPU addresses, since in reality we
have a 1:1 mapping between the two.
Signed-off-by: Kornel Duleba <mindal@semihalf.com>
Acked-by: Claudiu Manoil <claudiu.manoil@nxp.com>
Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The PMIC throws an errors because the clock isn't assigned to it.
Fix this by assigning the clocks info.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
On LS2088A-RDB board, if the spi-fsl-dspi driver is built as module
then its probe fails with the following warning:
[ 10.471363] couldn't get idr
[ 10.471381] WARNING: CPU: 4 PID: 488 at drivers/spi/spi.c:2689 spi_register_controller+0x73c/0x8d0
...
[ 10.471651] fsl-dspi 2100000.spi: Problem registering DSPI ctlr
[ 10.471708] fsl-dspi: probe of 2100000.spi failed with error -16
Reason for the failure is that bus-num property is set for dspi node.
However, bus-num property is not set for the qspi node. If probe for
spi-fsl-qspi happens first then id 0 is dynamically allocated to it.
Call to spi_register_controller() from spi-fsl-dspi driver then fails.
Since commit 29d2daf2c3 ("spi: spi-fsl-dspi: Make bus-num property
optional") bus-num property is optional. Remove bus-num property from
dspi node to fix the issue.
Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
ls1012a-freeway board contains a M.2 2230 slot. Update the status of
pcei1 node to okay so that the pcie controller can be probed.
Signed-off-by: Mian Yousaf Kaukab <ykaukab@suse.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
On i.MX8MP, there is no audio ipg clock, so remove the wrong reference
to this clock in dts file.
Signed-off-by: Jacky Bai <ping.bai@nxp.com>
Reviewed-by: Abel Vesa <abel.vesa@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Both 1.8v and 3.3v power supplies can be used by i.MX8MQ PCIe PHY.
In default, the PCIE_VPH voltage is suggested to be 1.8v refer to data
sheet. When PCIE_VPH is supplied by 3.3v in the HW schematic design,
the VREG_BYPASS bits of GPR registers should be cleared from default
value 1b'1 to 1b'0. Thus, the internal 3v3 to 1v8 translator would be
turned on.
Signed-off-by: Richard Zhu <hongxing.zhu@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The i.MX8MM reference manual shows there are two spba busses.
SPBA1 handles much of the serial interfaces, and SPBA2 covers much
of the audio.
Add both of them.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The i.MX8MN has an SPBA bus which covers much of the audio, but
there is a second SPBA bus which covers many of the serial interfaces
like SPI and UARTs currently missing from the device tree. The reference
manual calls the bus handling the audio peripherals SPBA2, and the bus
handling the serial peripherals is called SPBA1.
Rename the existing spba bus to spba2 and add spba1.
Signed-off-by: Adam Ford <aford173@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add support of the lt8912b in the DTB.
This adds the support of the DB_DSIHD daugther board from
Boundary Devices.
Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add the description for the USB host port.
This port is linked to a resettable USB HUB so handle
this reset signal with a GPIO hog.
Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
Add the description for the USB OTG port.
The OTG port uses a dedicated regulator for vbus.
Signed-off-by: Adrien Grassein <adrien.grassein@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
The PCIe host bridge on RK3399 advertises a single 64-bit memory
address range even though it lies entirely below 4GB.
Previously the OF PCI range parser treated 64-bit ranges more
leniently (i.e., as 32-bit), but since commit 9d57e61bf7 ("of/pci:
Add IORESOURCE_MEM_64 to resource flags for 64-bit memory addresses")
the code takes a stricter view and treats the ranges as advertised in
the device tree (i.e, as 64-bit).
The change in behaviour causes failure when allocating bus addresses
to devices connected behind a PCI-to-PCI bridge that require
non-prefetchable memory ranges. The allocation failure was observed
for certain Samsung NVMe drives connected to RockPro64 boards.
Update the host bridge window attributes to treat it as 32-bit address
memory. This fixes the allocation failure observed since commit
9d57e61bf7.
Reported-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/7a1e2ebc-f7d8-8431-d844-41a9c36a8911@arm.com
Suggested-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Punit Agrawal <punitagrawal@gmail.com>
Tested-by: Alexandru Elisei <alexandru.elisei@arm.com>
Link: https://lore.kernel.org/r/20210607112856.3499682-5-punitagrawal@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Host stage-2 optimisations from Quentin Perret
* kvm-arm64/mmu/reduce-vmemmap-overhead:
KVM: arm64: Use less bits for hyp_page refcount
KVM: arm64: Use less bits for hyp_page order
KVM: arm64: Remove hyp_pool pointer from struct hyp_page
KVM: arm64: Unify MMIO and mem host stage-2 pools
KVM: arm64: Remove list_head from hyp_page
KVM: arm64: Use refcount at hyp to check page availability
KVM: arm64: Move hyp_pool locking out of refcount helpers
Scheduling a 32-bit application on a 64-bit-only CPU is a bad idea.
Ensure that 32-bit applications always take the slow-path when returning
to userspace on a system with mismatched support at EL0, so that we can
avoid trying to run on a 64-bit-only CPU and force a SIGKILL instead.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210608180313.11502-5-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
If a vCPU is caught running 32-bit code on a system with mismatched
support at EL0, then we should kill it.
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210608180313.11502-4-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
When confronted with a mixture of CPUs, some of which support 32-bit
applications and others which don't, we quite sensibly treat the system
as 64-bit only for userspace and prevent execve() of 32-bit binaries.
Unfortunately, some crazy folks have decided to build systems like this
with the intention of running 32-bit applications, so relax our
sanitisation logic to continue to advertise 32-bit support to userspace
on these systems and track the real 32-bit capable cores in a cpumask
instead. For now, the default behaviour remains but will be tied to
a command-line option in a later patch.
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210608180313.11502-3-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
In preparation for late initialisation of the "sanitised" AArch32 register
state, move the AArch32 registers out of 'struct cpuinfo' and into their
own struct definition.
Acked-by: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210608180313.11502-2-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
The hyp_page refcount is currently encoded on 4 bytes even though we
never need to count that many objects in a page. Make it 2 bytes to save
some space in the vmemmap.
As overflows are more likely to happen as well, make sure to catch those
with a BUG in the increment function.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210608114518.748712-8-qperret@google.com
The hyp_page order is currently encoded on 4 bytes even though it is
guaranteed to be smaller than this. Make it 2 bytes to reduce the hyp
vmemmap overhead.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210608114518.748712-7-qperret@google.com
Each struct hyp_page currently contains a pointer to a hyp_pool struct
where the page should be freed if its refcount reaches 0. However, this
information can always be inferred from the context in the EL2 code, so
drop the pointer to save a few bytes in the vmemmap.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210608114518.748712-6-qperret@google.com
We currently maintain two separate memory pools for the host stage-2,
one for pages used in the page-table when mapping memory regions, and
the other to map MMIO regions. The former is large enough to map all of
memory with page granularity and the latter can cover an arbitrary
portion of IPA space, but allows to 'recycle' pages.
However, this split makes accounting difficult to manage as pages at
intermediate levels of the page-table may be used to map both memory and
MMIO regions. Simplify the scheme by merging both pools into one. This
means we can now hit the -ENOMEM case in the memory abort path, but
we're still guaranteed forward-progress in the worst case by unmapping
MMIO regions. On the plus side this also means we can usually map a lot
more MMIO space at once if memory ranges happen to be mapped with block
mappings.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210608114518.748712-5-qperret@google.com
The list_head member of struct hyp_page is only needed when the page is
attached to a free-list, which by definition implies the page is free.
As such, nothing prevents us from using the page itself to store the
list_head, hence reducing the size of the vmemmap.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210608114518.748712-4-qperret@google.com
The hyp buddy allocator currently checks the struct hyp_page list node
to see if a page is available for allocation or not when trying to
coalesce memory. Now that decrementing the refcount and attaching to
the buddy tree is done in the same critical section, we can rely on the
refcount of the buddy page to be in sync, which allows to replace the
list node check by a refcount check. This will ease removing the list
node from struct hyp_page later on.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210608114518.748712-3-qperret@google.com
The hyp_page refcount helpers currently rely on the hyp_pool lock for
serialization. However, this means the refcounts can't be changed from
the buddy allocator core as it already holds the lock, which means pages
have to go through odd transient states.
For example, when a page is freed, its refcount is set to 0, and the
lock is transiently released before the page can be attached to a free
list in the buddy tree. This is currently harmless as the allocator
checks the list node of each page to see if it is available for
allocation or not, but it means the page refcount can't be trusted to
represent the state of the page even if the pool lock is held.
In order to fix this, remove the pool locking from the refcount helpers,
and move all the logic to the buddy allocator. This will simplify the
removal of the list node from struct hyp_page in a later patch.
Signed-off-by: Quentin Perret <qperret@google.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210608114518.748712-2-qperret@google.com
Add the device tree node for the dual-SMMU found on Tegra194 and hook up
peripherals such as host1x, BPMP, HDA, SDMMC, EQOS and VIC.
Signed-off-by: Thierry Reding <treding@nvidia.com>
On Tegra186 and later, the memory controller needs to be programmed in
coordination with any of the ARM SMMU instances to configure the stream
ID used for each memory client.
To support this, add a phandle reference to the memory controller to the
SMMU device tree node.
Signed-off-by: Thierry Reding <treding@nvidia.com>
The SMMU found on Tegra186 requires interoperation with the memory
controller in order to program stream ID overrides. The generic ARM SMMU
500 compatible is therefore inaccurate. Replace it with a more correct,
SoC-specific compatible string.
Signed-off-by: Thierry Reding <treding@nvidia.com>
For histroical reasons, we define AARCH64_INSN_SIZE in
<asm/alternative-macros.h>, but it would make more sense to do so in
<asm/insn.h>. Let's move it into <asm/insn.h>, and add the necessary
include directives for this.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210609102301.17332-3-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Currently, <asm/insn.h> includes <asm/patching.h>. We intend that
<asm/insn.h> will be usable from userspace, so it doesn't make sense to
include headers for kernel-only features such as the patching routines,
and we'd intended to restrict <asm/insn.h> to instruction encoding
details.
Let's decouple the patching code from <asm/insn.h>, and explicitly
include <asm/patching.h> where it is needed. Since <asm/patching.h>
isn't included from assembly, we can drop the __ASSEMBLY__ guards.
At the same time, sort the kprobes includes so that it's easier to see
what is and isn't incldued.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210609102301.17332-2-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Use common macro PMU_EVENT_ATTR_ID to simplify ARMV8_EVENT_ATTR
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Will Deacon <will@kernel.org>
Signed-off-by: Qi Liu <liuqi115@huawei.com>
Link: https://lore.kernel.org/r/1623220863-58233-8-git-send-email-liuqi115@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
Add the DT nodes for the network-on-chip interconnect buses found
on sc7280-based platforms.
Signed-off-by: Odelu Kukatla <okukatla@codeaurora.org>
Link: https://lore.kernel.org/r/1619517059-12109-4-git-send-email-okukatla@codeaurora.org
[bjorn: Sorted nodes and dropped include]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The Huawei Ascend G7 supports NFC using the NXP PN547, which is
supported by the nxp-nci-i2c driver in mainline. It seems to detect
NFC tags using "nfctool" just fine, although it seems like there
are not really any useful applications making use of the Linux NFC
subsystem. :(
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210514104328.18756-5-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The display on the Huawei Ascend G7 is supplied by a TI TPS65132
regulator. The panel needs a driver in mainline first, but the
TPS65132 is already supported in mainline by the tps65132 driver.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210514104328.18756-4-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The Huawei Ascend G7 has a Synaptics "C199HW-006" touchscreen,
supplied by pm8916_l17 and pm8916_l16. Add it to the device tree
and reduce the maximum allowed voltage for pm8916_l16 to 1.8V since
we really should not use more for an I/O supply.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210514104328.18756-2-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The Huawei Ascend G7 is a smartphone from Huawei based on MSM8916.
It's fairly similar to the other MSM8916 devices, the only notable
exception are the "cd-gpios" for detecting if a SD card was inserted:
It looks like Huawei forgot to re-route this to gpio38, so the correct
GPIO seems to be gpio56 on this device.
Note: The original firmware from Huawei can only boot 32-bit kernels.
To boot arm64 kernels it is necessary to flash 64-bit TZ/HYP firmware
with EDL, e.g. taken from the DragonBoard 410c. This works because Huawei
forgot to set up (firmware) secure boot for some reason.
Also note that Huawei no longer provides bootloader unlock codes.
This can be bypassed by patching the bootloader from a custom HYP firmware,
making it think the bootloader is unlocked. I use a modified version of
qhypstub [1], that patches a single instruction in the Huawei bootloader.
The device tree contains initial support for the Huawei Ascend G7 with:
- UART (untested, probably available via some test points)
- eMMC/SD card
- Buttons
- Notification LED (combination of 3 GPIO LEDs)
- Vibrator
- WiFi/Bluetooth (WCNSS)
- USB
[1]: https://github.com/msm8916-mainline/qhypstub
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210514104328.18756-1-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
This spi flash part is actually being clocked at 37.5MHz, not 25MHz,
because of the way the clk driver is rounding up the rate that is
requested to the nearest supported frequency. Let's update the frequency
here, and remove the TODO because this is the fastest frequency we're
going to be able to use here.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210519054030.3217704-1-swboyd@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
This compatible string isn't present upstream. Let's drop the node as it
isn't used.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210601185959.3101132-2-swboyd@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
This compatible string isn't present upstream. Let's drop the node as it
isn't used.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210601185959.3101132-1-swboyd@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
We don't use the PON module on Trogdor devices. Instead the reboot
reason is sort of stored in the 'eventlog' and the bootloader figures
out if the boot is abnormal and records that there. Disable the PON node
and then drop the power key disabling because that's a child node that
will no longer be enabled if the PON node is disabled.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210601184417.3020834-1-swboyd@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
On coachz it could be observed that SPI_CLK voltage level was only
1.4V during active transfers because the drive strength was too
weak. The line hadn't finished slewing up by the time we started
driving it down again. Using a drive strength of 8 lets us achieve the
correct voltage level of 1.8V.
Though the worst problems were observed on coachz hardware, let's do
this across the board for trogdor devices. Scoping other boards shows
that this makes the clk line look nicer on them too and doesn't
introduce any problems.
Only the clk line is adjusted, not any data lines. Because SPI isn't a
DDR protocol we only sample the data lines on either rising or falling
edges, not both. That means the clk line needs to toggle twice as fast
as data lines so having the higher drive strength is more important
there.
Signed-off-by: Wenchao Han <hanwenchao@huaqin.corp-partner.google.com>
[dianders: Adjust author real name; adjust commit message]
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210510075253.1.Ib4c296d6ff9819f26bcaf91e8a08729cc203fed0@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add initial DTSI for RZ/G2{L,LC} SoC's.
File structure:
r9a07g044.dtsi => RZ/G2L family SoC common parts
r9a07g044l1.dtsi => RZ/G2L R9A07G044L1 SoC specific parts
r9a07g044l2.dtsi => RZ/G2L R9A07G044L2 SoC specific parts
Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Link: https://lore.kernel.org/r/20210609153230.6967-11-prabhakar.mahadev-lad.rj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Although the schematics of Pine A64-LTS and SoPine Baseboard shows both
the RX and TX internal delay are enabled, they're using the same broken
RTL8211E chip batch with Pine A64+, so they should use TXID instead, not
ID.
In addition, by checking the real components soldered on both a SoPine
Baseboard and a Pine A64-LTS, RX delay is not enabled (GR69 soldered and
GR70 NC) despite the schematics says it's enabled. It's a common
situation for Pine64 boards that the NC information on schematics is not
the same with the board.
So the RGMII delay mode should be TXID on these boards.
Fixes: c2b111e59a ("arm64: dts: allwinner: A64 Sopine: phy-mode rgmii-id")
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210609083843.463750-1-icenowy@aosc.io
Add a basic GPU node for mt8183, as well as OPP table.
Note that with the current panfrost driver, devfreq is not
actually functional, as the we do not have platform-specific
support for >1 supplies. Also, we are missing code to handle
frequency change, as the GPU frequency needs to be switched
away to a stable 26Mhz clock during the transition.
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Link: https://lore.kernel.org/r/20210521200038.v14.1.I9f45f5c1f975422d58b5904d11546349e9ccdc94@changeid
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add tboard thermal zones.
The tboard thermal sensors are a kind of NTC sensors which are located
on PCB board to correlate the temperature of the case (Tskin).
pull-up voltage: 1800 mv
pull-up resistor: 75K
Vsense = pull-up voltage * Rntc / ( pull-up resistor + Rntc )
AuxIn = Vsense * 4096 / 1500
Signed-off-by: Michael Kao <michael.kao@mediatek.com>
Signed-off-by: Ben Tseng <ben.tseng@mediatek.com>
Tested-by: Hsin-Yi Wang <hsinyi@chromium.org>
Link: https://lore.kernel.org/r/20210604093755.13288-1-ben.tseng@mediatek.com
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Add a 'cbas' device node for supporting tablet mode switch in
kukui devices.
Kukui platforms with detacheable base have an additional input
device under cros-ec, which reports SW_TABLET_MODE regarding
its base state (e.g. base flipped or detached).
Signed-off-by: Ikjoon Jang <ikjn@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210609032554.2443675-1-ikjn@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
This adds a reference to the dts of the Raspberry Pi 400,
so we don't need to maintain the content in arm64.
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Reviewed-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
Link: https://lore.kernel.org/r/1622981777-5023-8-git-send-email-stefan.wahren@i2se.com
Signed-off-by: Nicolas Saenz Julienne <nsaenz@kernel.org>
It would be helpful if mem_abort_decode() could decode the DFSC/IFSC, as
this can make it easier to identify common bugs (e.g. accesses which
trigger alignment faults) without having to manually decode the xFSC
value.
Decode the xFSC in mem_abort_decode().
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210608123742.11921-1-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
AM642-SK has no PCIe slot. Disable it here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603142251.14563-6-kishon@ti.com
AM642 EVM has a x4 lane PCIe connector. Enable PCIe in RC mode here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603142251.14563-4-kishon@ti.com
AM64 has one PCIe instance which can be configured in either
host mode (RC) or device mode (EP). Add PCIe DT node for host
mode and device mode here.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603142251.14563-3-kishon@ti.com
AM64 has one SERDES 10G instance. Add SERDES DT node for it.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603142251.14563-2-kishon@ti.com
Commit 66db854b1f ("arm64: dts: ti: k3-j721e-common-proc-board:
Configure the PCIe instances") and
commit 02c35dca2b ("arm64: dts: ti: k3-j721e: Enable Super-Speed
support for USB0") added PHY DT nodes with node name as "link"
However nodes with #phy-cells should be named 'phy' as discussed in [1].
Re-name subnodes of serdes in J721E to 'phy'.
[1] -> http://lore.kernel.org/r/20200909203631.GA3026331@bogus
Fixes: 66db854b1f ("arm64: dts: ti: k3-j721e-common-proc-board: Configure the PCIe instances")
Fixes: 02c35dca2b ("arm64: dts: ti: k3-j721e: Enable Super-Speed support for USB0")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603143427.28735-5-kishon@ti.com
Use external clock for all the SERDES used by PCIe controller. This will
make the same clock used by the local SERDES as well as the clock
provided to the PCIe connector.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603143427.28735-4-kishon@ti.com
Add #clock-cells property to serdes DT node since the serdes is also now
modeled as a clock provider and include the input clocks "pll0_refclk"
and "pll1_refclk" which are parents to the clocks modeled by serdes.
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603143427.28735-3-kishon@ti.com
Rename the external refclk inputs to the SERDES from
dummy_cmn_refclk/dummy_cmn_refclk1 to cmn_refclk/cmn_refclk1
respectively. Also move the external refclk DT nodes outside the
cbass_main DT node. Since in j721e common processor board, only the
cmn_refclk1 is connected to 100MHz clock, fix the clock frequency.
Fixes: afd094ebe6 ("arm64: dts: ti: k3-j721e-main: Add WIZ and SERDES PHY nodes")
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210603143427.28735-2-kishon@ti.com
SMCCC v1.2 requires that all SVE state be preserved over SMC calls which
introduces substantial overhead in the common case where there is no SVE
state in the registers. To avoid this SMCCC v1.3 introduces a flag which
allows the caller to say that there is no state that needs to be preserved
in the registers. Make use of this flag, setting it if the SMCCC version
indicates support for it and the TIF_ flags indicate that there is no live
SVE state in the registers, this avoids placing any constraints on when
SMCCC calls can be done or triggering extra saving and reloading of SVE
register state in the kernel.
This would be straightforward enough except for the rather entertaining
inline assembly we use to do SMCCC v1.1 calls to allow us to take advantage
of the limited number of registers it clobbers. Deal with this by having a
function which we call immediately before issuing the SMCCC call to make
our checks and set the flag. Using alternatives the overhead if SVE is
supported but not detected at runtime can be reduced to a single NOP.
Signed-off-by: Mark Brown <broonie@kernel.org>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210603184118.15090-1-broonie@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Enable support for audio-graph based sound card on Jetson Xavier NX.
Following I/O interfaces are enabled.
- I2S3 and I2S5
- DMIC1, DMIC2 and DMIC4
- DSPK1 and DSPK2
Signed-off-by: Sameer Pujar <spujar@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This enables the adreno-specific SMMU path that sets HUPCF so
(user-managed) page faults don't wedge the GPU.
Signed-off-by: Eric Anholt <eric@anholt.net>
Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210326231303.3071950-2-eric@anholt.net
Signed-off-by: Will Deacon <will@kernel.org>
The ICSSGs on K3 J721E SoCs contain an MDIO controller that can
be used to control external PHYs associated with the Industrial
Ethernet peripherals within each ICSSG instance. The MDIO module
used within the ICSSG is similar to the MDIO Controller used
in TI Davinci SoCs. A bus frequency of 1 MHz is chosen for the
MDIO operations.
The nodes are added and enabled in the common k3-j721e-main.dtsi
file by default, and disabled in the existing J721E board dts
file. These nodes need pinctrl lines, and so should be enabled
only on boards where they are actually wired and pinned out for
ICSSG Ethernet. Any new board dts file should disable these if
they are not sure.
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210601150032.11432-3-s-anna@ti.com
The ICSSGs on K3 AM65x SoCs contain an MDIO controller that can
be used to control external PHYs associated with the Industrial
Ethernet peripherals within each ICSSG instance. The MDIO module
used within the ICSSG is similar to the MDIO Controller used
in TI Davinci SoCs. A bus frequency of 1 MHz is chosen for the
MDIO operations.
The nodes are added and enabled in the common k3-am65-main.dtsi
file by default, and disabled in the existing AM65 board dts
files. These nodes need pinctrl lines, and so should be enabled
only on boards where they are actually wired and pinned out for
ICSSG Ethernet. Any new board dts file should disable these if
they are not sure.
Signed-off-by: Roger Quadros <rogerq@ti.com>
[s-anna@ti.com: move the disabled status to board dts files]
Signed-off-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210601150032.11432-2-s-anna@ti.com
UHS-I speed modes are supported in AM65 S.R. 2.0 SoC[1].
Add support by removing the no-1-8-v tag and including the voltage
regulator device tree nodes for power cycling.
However, the 4 bit interface of AM65 SR 1.0 cannot be supported at 3.3 V or
1.8 V because of erratas i2025 and i2026 [2]. As the SD card is the primary
boot mode for development usecases, continue to enable SD card and disable
UHS-I modes in it to minimize any ageing issues happening because of
erratas.
k3-am6528-iot2050-basic and k3-am6548-iot2050-advanced boards use S.R. 1.0
version of AM65 SoC. Therefore, add no-1-8-v in sdhci1 device tree node of
the common iot2050 device tree file.
[1] - https://www.ti.com/lit/ug/spruid7e/spruid7e.pdf, section 12.3.6.1.1
[2] - https://www.ti.com/lit/er/sprz452e/sprz452e.pdf
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Acked-by: Jan Kiszka <jan.kiszka@siemens.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210529033749.6250-1-a-govindraju@ti.com
The low-level idle code in arch_cpu_idle() and its callees runs at a
time where where portions of the kernel environment aren't available.
For example, RCU may not be watching, and lockdep state may be
out-of-sync with the hardware. Due to this, it is not sound to
instrument this code.
We generally avoid instrumentation by marking the entry functions as
`noinstr`, but currently this doesn't inhibit KCOV instrumentation.
Prevent this by factoring these functions into a new idle.c so that we
can disable KCOV for the entire compilation unit, as is done for the
core idle code in kernel/sched/idle.c.
We'd like to keep instrumentation of the rest of process.c, and for the
existing code in cpuidle.c, so a new compilation unit is preferable. The
arch_cpu_idle_dead() function in process.c is a cpu hotplug function
that is safe to instrument, so it is left as-is in process.c.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-21-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
The code in entry-common.c runs at exception entry and return
boundaries, where portions of the kernel environment aren't available.
For example, RCU may not be watching, and lockdep state may be
out-of-sync with the hardware. Due to this, it is not sound to
instrument this code.
We generally avoid instrumentation by marking the entry functions as
`noinstr`, but currently this doesn't inhibit KCOV instrumentation.
Prevent this by disabling KCOV for the entire compilation unit.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-20-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Now that we only call arm64_enter_nmi() and arm64_exit_nmi() from within
entry-common.c, let's make these static to ensure this remains the case.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-19-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
We'd like to keep all the entry sequencing in entry-common.c, as this
will allow us to ensure this is consistent, and free from any unsound
instrumentation.
Currently __sdei_handler() performs the NMI entry/exit sequences in
sdei.c. Let's split the low-level entry sequence from the event
handling, moving the former to entry-common.c and keeping the latter in
sdei.c. The event handling function is renamed to do_sdei_event(),
matching the do_${FOO}() pattern used for other exception handlers.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-18-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
We'd like to keep all the entry sequencing in entry-common.c, as this
will allow us to ensure this is consistent, and free from any unsound
instrumentation.
Currently handle_bad_stack() performs the NMI entry sequence in traps.c.
Let's split the low-level entry sequence from the reporting, moving the
former to entry-common.c and keeping the latter in traps.c. To make it
clear that reporting function never returns, it is renamed to
panic_bad_stack().
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-17-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
An unexpected synchronous exception from EL1h could happen at any time,
and for robustness we should treat this as an NMI, making minimal
assumptions about the context the exception was taken from.
Currently el1_inv() assumes we can use enter_from_kernel_mode(), and
also assumes that we should inherit the original DAIF value. Neither of
these are desireable when we take an unexpected exception. Further,
after el1_inv() calls __panic_unhandled(), the remainder of the function
is unreachable, and therefore superfluous.
Let's address this and simplify things by having el1h_64_sync_handler()
call __panic_unhandled() directly, without any of the redundant logic.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reported-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-16-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
We have 16 architectural exception vectors, and depending on kernel
configuration we handle 8 or 12 of these with C code, with the remaining
8 or 4 of these handled as special cases in the entry assembly.
It would be nicer if the entry assembly were uniform for all exceptions,
and we deferred any specific handling of the exceptions to C code. This
way the entry assembly can be more easily templated without ifdeffery or
special cases, and it's easier to modify the handling of these cases in
future (e.g. to dump additional registers other context).
This patch reworks the entry code so that we always have a C handler for
every architectural exception vector, with the entry assembly being
completely uniform. We now have to handle exceptions from EL1t and EL1h,
and also have to handle exceptions from AArch32 even when the kernel is
built without CONFIG_COMPAT. To make this clear and to simplify
templating, we rename the top-level exception handlers with a consistent
naming scheme:
asm: <el+sp>_<regsize>_<type>
c: <el+sp>_<regsize>_<type>_handler
.. where:
<el+sp> is `el1t`, `el1h`, or `el0t`
<regsize> is `64` or `32`
<type> is `sync`, `irq`, `fiq`, or `error`
... e.g.
asm: el1h_64_sync
c: el1h_64_sync_handler
... with lower-level handlers simply using "el1" and "compat" as today.
For unexpected exceptions, this information is passed to
__panic_unhandled(), so it can report the specific vector an unexpected
exception was taken from, e.g.
| Unhandled 64-bit el1t sync exception
For vectors we never expect to enter legitimately, the C code is
generated using a macro to avoid code duplication. The exceptions are
handled via __panic_unhandled(), replacing bad_mode() (which is
removed).
The `kernel_ventry` and `entry_handler` assembly macros are updated to
handle the new naming scheme. In theory it should be possible to
generate the entry functions at the same time as the vectors using a
single table, but this will require reworking the linker script to split
the two into separate sections, so for now we have separate tables.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-15-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Now that the majority of the exception triage logic has been converted
to C, the entry assembly functions all have a uniform structure.
Let's generate them all with an assembly macro to reduce the amount of
code and to ensure they all remain in sync if we make changes in future.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-14-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Our use of bad_mode() has a few rough edges:
* AArch64 doesn't use the term "mode", and refers to "Execution
states", "Exception levels", and "Selected stack pointer".
* We log the exception type (SYNC/IRQ/FIQ/SError), but not the actual
"mode" (though this can be decoded from the SPSR value).
* We use bad_mode() as a second-level handler for unexpected synchronous
exceptions, where the "mode" is legitimate, but the specific exception
is not.
* We dump the ESR value, but call this "code", and so it's not clear to
all readers that this is the ESR.
... and all of this can be somewhat opaque to those who aren't extremely
familiar with the code.
Let's make this a bit clearer by having bad_mode() log "Unhandled
${TYPE} exception" rather than "Bad mode in ${TYPE} handler", using
"ESR" rather than "code", and having the final panic() log "Unhandled
exception" rather than "Bad mode".
In future we'd like to log the specific architectural vector rather than
just the type of exception, so we also split the core of bad_mode() out
into a helper called __panic_unhandled(), which takes the vector as a
string argument.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-13-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
In subsequent patches we'll rework the way bad_mode() is called by
exception entry code. In preparation for this, let's move bad_mode()
itself into entry-common.c.
Let's also mark it as noinstr (e.g. to prevent it being kprobed), and
let's also make the `handler` array a local variable, as this is only
use by bad_mode(), and will be removed entirely in a subsequent patch.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-12-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Following the example of ret_to_user, let's consolidate all the EL1
return paths with a ret_to_kernel helper, rather than each entry point
having its own copy of the return code.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-11-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
In subsequent patches we'll rename the entry handlers based on their
original EL, register width, and exception class. To do so, we need to
make all 3 mandatory arguments to the `kernel_ventry` macro, and
distinguish EL1h from EL1t.
In preparation for this, let's make the current set of arguments
mandatory, and move the `regsize` column before the branch label suffix,
making the vectors easier to read column-wise.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-10-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
In entry.S we have two comments which distinguish EL0 and EL1 exception
handlers, but the code isn't actually laid out to match, and there are a
few other inconsistencies that would be good to clear up.
This patch organizes the entry handers consistently:
* The handlers are laid out in order of the vectors, to make them easier
to navigate.
* The inconsistently-applied alignment is removed
* The handlers are consistently marked with SYM_CODE_START_LOCAL()
rather than SYM_CODE_START_LOCAL_NOALIGN(), giving them the same
default alignment as other assembly code snippets.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-9-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
For various reasons we'd like to convert the bulk of arm64's exception
triage logic to C. As a step towards that, this patch converts the EL1
and EL0 IRQ+FIQ triage logic to C.
Separate C functions are added for the native and compat cases so that
in subsequent patches we can handle native/compat differences in C.
Since the triage functions can now call arm64_apply_bp_hardening()
directly, the do_el0_irq_bp_hardening() wrapper function is removed.
Since the user_exit_irqoff macro is now unused, it is removed. The
user_enter_irqoff macro is still used by the ret_to_user code, and
cannot be removed at this time.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-8-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
When handling IRQ/FIQ exceptions the entry assembly may transition from
a task's stack to a CPU's IRQ stack (and IRQ shadow call stack).
In subsequent patches we want to migrate the IRQ/FIQ triage logic to C,
and as we want to perform some actions on the task stack (e.g. EL1
preemption), we need to switch stacks within the C handler. So that we
can do so, this patch adds a helper to call a function on a CPU's IRQ
stack (and shadow stack as appropriate).
Subsequent patches will make use of the new helper function.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-7-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Currently portions of our preempt logic are written in C while other
parts are written in assembly. Let's clean this up a little bit by
moving the NMI preempt checks to C. For now, the preempt count (and
need_resched) checking is left in assembly, and will be converted
with the body of the IRQ handler in subsequent patches.
Other than the increased lockdep coverage there should be no functional
change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-6-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Subsequent patches will pull more of the IRQ entry handling into C. To
keep this in one place, let's move arm64_preempt_schedule_irq() into
entry-common.c along with the other entry management functions.
We no longer need to include <linux/lockdep.h> in process.c, so the
include directive is removed.
There should be no functional change as a result of this patch.
Reviewed-by Joey Gouly <joey.gouly@arm.com>
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-5-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
For various reasons we'd like to convert the bulk of arm64's exception
triage logic to C. As a step towards that, this patch converts the EL1
and EL0 SError triage logic to C.
Separate C functions are added for the native and compat cases so that
in subsequent patches we can handle native/compat differences in C.
There should be no functional change as a result of this patch.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-4-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
For non-fatal exceptions taken from EL0, we expect that at some point
during exception handling it is possible to return to a regular process
context with all exceptions unmasked (e.g. as we do in
do_notify_resume()), and we generally aim to unmask exceptions wherever
possible.
While handling SError and debug exceptions from EL0, we need to leave
some exceptions masked during handling. Handling SError requires us to
mask SError (which also requires masking IRQ+FIQ), and handing debug
exceptions requires us to mask debug (which also requires masking
SError+IRQ+FIQ).
Once do_serror() or do_debug_exception() has returned, we no longer need
to mask exceptions, and can unmask them all, which is what we did prior
to commit:
9034f62515 ("arm64: Do not enable IRQs for ct_user_exit")
... where we had to mask IRQs as for context_tracking_user_exit()
expected IRQs to be masked.
Since then, we realised that our context tracking wasn't entirely
correct, and reworked the entry code to fix this. As of commit:
23529049c6 ("arm64: entry: fix non-NMI user<->kernel transitions")
... we replaced the call to context_tracking_user_exit() with a call to
user_exit_irqoff() as part of enter_from_user_mode(), which occurs
earlier, before we run the body of the handler and unmask exceptions in
DAIF.
When we return to userspace, we go via ret_to_user(), which masks
exceptions in DAIF prior to calling user_enter_irqoff() as part of
exit_to_user_mode().
Thus, there's no longer a reason to leave IRQs or FIQs masked at the end
of the EL0 debug or error handlers, as neither the user exit context
tracking nor the user entry context tracking requires this. Let's bring
these into line with other EL0 exception handlers and ensure that IRQ
and FIQ are unmasked in DAIF at some point during the handler.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-3-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Upon taking an exception, the CPU sets all the DAIF bits. We never
clear any of these bits prior to calling bad_mode(), and bad_mode()
itself never clears any of these bits, so there's no need to call
local_daif_mask().
This patch removes the redundant call.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Marc Zyngier <maz@kernel.org>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Joey Gouly <joey.gouly@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210607094624.34689-2-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
"make dtbs_check":
arm64/boot/dts/renesas/r8a779a0-falcon.dt.yaml: interrupt-controller@f1000000: 'power-domains' does not match any of the regexes: '^(msi-controller|gic-its|interrupt-controller)@[0-9a-f]+$', '^gic-its@', '^interrupt-controller@[0-9a-f]+$', 'pinctrl-[0-9]+'
From schema: Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml
Remove the "power-domains" property, as the GIC on R-Car V3U is
always-on, and not part of a clock domain.
Fixes: 834c310f54 ("arm64: dts: renesas: Add Renesas R8A779A0 SoC support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/a9ae5cbc7c586bf2c6b18ddc665ad7051bd1d206.1622560236.git.geert+renesas@glider.be
A set of fixes that have been coming in over the last few weeks, the
usual mix of fixes:
- DT fixups for TI K3
- SATA drive detection fix for TI DRA7
- Power management fixes and a few build warning removals for OMAP
- OP-TEE fix to use standard API for UUID exporting
- DT fixes for a handful of i.MX boards
... plus a few other smaller items
-----BEGIN PGP SIGNATURE-----
iQJDBAABCgAtFiEElf+HevZ4QCAJmMQ+jBrnPN6EHHcFAmC9IRYPHG9sb2ZAbGl4
b20ubmV0AAoJEIwa5zzehBx3m/sQAI8JaXHnUBbXAAn0ugMLaTfXA1FKI+in+O43
xobyBwe6R4XNAr1GQvLYXF6vY3eaMHrcS/a1dU96uH7h3B8aq9ZR9DqrpJ5VNu37
q55t+brJkEI8+t5u08u6jrxfVARu4FbyZB4jIkbIwxnyEynx/8Bl7sLYImOhspkb
ipEkgPOSGcIDUcsI1eXIb6urQYkE0yssy20qNYFQ4neYS4Su4gy+LA2OTSqRHk/s
uQtfJZGN9LbxUFJ4mho349hebjM3rjXw2ox9Znk4bIhBbW38sppjstQ8lhi5YhbW
RlKDEIYcc/Fo/Hy1xoiAY2MZ7lMMUnXOEhMQmzQd1AZVNH0ysr8vuSEBy9mxF36r
Jx3eXWDZulDnhM/3eA8GJg3o5kcCZcymFHxo2X0bMeiMlXZ77QP8XV5Y5/C6LQf3
wJ4lncq0Q4wc9q7W2uGCq/JrMbJxOTjh6nbLlOIENHliRgwk48aoHY4RlOtKpws7
82S/vCAAj/08mpV2AzZtTtUxIrvgJcdKm9freXZOoUp53yvHbltLZXm2bBrfLdh1
qM0vT9+skUajxWXG0HpTNJSig3DeAMmfwC3As4kjibA8Jtr8y7249Z/xKPXJrZI+
5lvi4S2AT/QJbER0jUe6nIamS9RIFnDy0+J0BPvfJ6VpDMIM18rn6M4iev0am9v7
MDI6Mm2+
=TbGI
-----END PGP SIGNATURE-----
Merge tag 'arm-soc-fixes-v5.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull ARM SoC fixes from Olof Johansson:
"A set of fixes that have been coming in over the last few weeks, the
usual mix of fixes:
- DT fixups for TI K3
- SATA drive detection fix for TI DRA7
- Power management fixes and a few build warning removals for OMAP
- OP-TEE fix to use standard API for UUID exporting
- DT fixes for a handful of i.MX boards
And a few other smaller items"
* tag 'arm-soc-fixes-v5.13-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (29 commits)
arm64: meson: select COMMON_CLK
soc: amlogic: meson-clk-measure: remove redundant dev_err call in meson_msr_probe()
ARM: OMAP1: ams-delta: remove unused function ams_delta_camera_power
bus: ti-sysc: Fix flakey idling of uarts and stop using swsup_sidle_act
ARM: dts: imx: emcon-avari: Fix nxp,pca8574 #gpio-cells
ARM: dts: imx7d-pico: Fix the 'tuning-step' property
ARM: dts: imx7d-meerkat96: Fix the 'tuning-step' property
arm64: dts: freescale: sl28: var1: fix RGMII clock and voltage
arm64: dts: freescale: sl28: var4: fix RGMII clock and voltage
ARM: imx: pm-imx27: Include "common.h"
arm64: dts: zii-ultra: fix 12V_MAIN voltage
arm64: dts: zii-ultra: remove second GEN_3V3 regulator instance
arm64: dts: ls1028a: fix memory node
bus: ti-sysc: Fix am335x resume hang for usb otg module
ARM: OMAP2+: Fix build warning when mmc_omap is not built
ARM: OMAP1: isp1301-omap: Add missing gpiod_add_lookup_table function
ARM: OMAP1: Fix use of possibly uninitialized irq variable
optee: use export_uuid() to copy client UUID
arm64: dts: ti: k3*: Introduce reg definition for interrupt routers
arm64: dts: ti: k3-am65|j721e|am64: Map the dma / navigator subsystem via explicit ranges
...
MMIO block mapping support from Keqian Zhu, allowing larger
(and lazy) mappings for devices assigned to guests.
* kvm-arm64/mmu/MMIO-block-mapping:
KVM: arm64: Try stage2 block mapping for host device MMIO
KVM: arm64: Remove the creation time's mapping of MMIO regions
Microsoft Surface Duo is based on SM8150 chipset. This new Device Tree
is a copy of sm8150-mtp with a the addition of the volume up key and
relevant i2c nodes.
Signed-off-by: Felipe Balbi <felipe.balbi@microsoft.com>
Link: https://lore.kernel.org/r/20210603122923.1919624-1-balbi@kernel.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Some SC7180 based boards do not have external pull-up for cd-gpio.
Set this pin to internal pull-up for sleep config to avoid frequent
regulator toggle events.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Sujit Kautkar <sujitka@chromium.org>
Link: https://lore.kernel.org/r/20210602121313.v3.2.I52f30ddfe62041b7e6c3c362f0ad8f695ac28224@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The Samsung Galaxy A3/A5 both have a Samsung S3FWRN5 NFC chip that
works quite well with the s3fwrn5 driver in the Linux NFC subsystem.
The clock setup for the NFC chip is a bit special (although this
seems to be a common approach used for Qualcomm devices with NFC):
The NFC chip has an output GPIO that is asserted whenever the clock
is needed to function properly. On the A3/A5 this is wired up to
PM8916 GPIO2, which is then configured with a special function
(NFC_CLK_REQ or BB_CLK2_REQ).
Enabling the rpmcc RPM_SMD_BB_CLK2_PIN clock will then instruct
PM8916 to automatically enable the clock whenever the NFC chip
requests it. The advantage is that the clock is only enabled when
needed and we don't need to manage it ourselves from the NFC driver.
Note that for some reason Samsung decided to connect the I2C pins
to GPIOs where no hardware I2C bus is available, so we need to
fall back to software bit-banging with i2c-gpio.
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210604172742.10593-5-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The Samsung Galaxy A3/A5 use a Richtek RT5033 PMIC as battery
fuel gauge, charger, flash LED and for some regulators. For now,
only add the fuel gauge/battery device to the device tree,
so we can check the remaining battery percentage.
The other RT5033 drivers need some more work first before
they can be used properly.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210604172742.10593-4-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
On the Samsung Galaxy A5 the touch key is supplied by a single fixed
regulator (enabled via GPIO 97) that supplies both MCU and LED.
Add it to the device tree.
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210604172742.10593-3-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The touch key MCU and LED is supplied by two separate fixed regulators
that can be enabled through GPIO 86 and 60. Add them to the device tree.
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
[stephan: extend commit message]
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210604172742.10593-2-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The Samsung Galaxy A3/A5 both have two capacitive touch keys,
connected to an ABOV MCU. It implements the same interface as
implemented by the tm2-touchkey driver and works just fine with
the coreriver,tc360-touchkey compatible. It's probably actually some
Samsung-specific interface that they implement with different MCUs.
Note that for some reason Samsung decided to connect this to GPIOs
where no hardware I2C bus is available, so we need to fall back
to software bit-banging using i2c-gpio.
The vdd/vcc-supply is board-specific and will be added separately
for a3u/a5u.
Co-developed-by: Michael Srba <Michael.Srba@seznam.cz>
Signed-off-by: Michael Srba <Michael.Srba@seznam.cz>
Signed-off-by: Stephan Gerhold <stephan@gerhold.net>
Link: https://lore.kernel.org/r/20210604172742.10593-1-stephan@gerhold.net
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add a thermal zone for the pm6150 on-die temperature. The system should
try to shut down orderly when the temperature reaches the critical trip
point at 115°C, otherwise the PMIC will perform a HW power off at 145°C.
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20210603081215.v2.1.Id4510e9e4baaa3f6c9fdd5cdf4d8606e63c262e3@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
These minor fixes include:
* Fixups for device tree discovered during yaml conversion
* Fixups for missing dma-coherent property in j7200
* Removal of camera sensor node from am65 evm dts to overlay
as camera sensor boards are variable.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEE+KKGk1TrgjIXoxo03bWEnRc2JJ0FAmCjqiAACgkQ3bWEnRc2
JJ0BvQ//VZl9llR0VWY9mADZBxIZ4tKwEGK9tK1fvQx44oWfjy30YkoN5UNDVbOO
RsSNPOiaUZbGUBjmVXJlxsjgDgpFsA3jGYaNwOiPHsN6CcglNug8W2roytmPO7j2
+csfGvSXCgFZX/7fnaqyv5lTjZE2xoBH4btacSPkil34Na7sgZhEVJ1aZQ3gWYzl
occPgPPqR+8AK3mVVDk7C43eVGNUAs2VhxM7BoIUYNJrT2UZt4eWziFOBLq8ULSa
O3K6YqUNm59qSe5Y3Vy3oGItVtEHJi+6wsYLKOeYPL+DuomyO9GVNH5Qa9IiD/AU
E7zNaG3Chx1YygRNvaIZ5g/DD3iLVFxa5nOigdqu/VqzO80NJnw4OWt6/F8U1czX
TZscs1u1x9LmtWLhdfPBJ6O7qwuKKobVBPo+CqrviHbXebjJJdwRXbj8Bkf2IIKB
612V6kXwLJ4Q/2XWaDSZHoYw1GMjHE/qQg05o0GltkrHtes40LnAHNe1aB9yKCIJ
hMWK9Hp+asr5Jic7aJOXcFPWn6P10hp6jdEoV3Ihs5lygLdqHhrcQvjpT804z4Hz
4aWbHWTLODvLQwI9OBiiT3sr+H0s6HOoBQ6svzqoWsEBwRpukxtGCl+A19vj+hHg
far/47XRJBtDW+e8EV1pVhxQ7NqDjYjyBY4irgn2+FgH9WAPZJc=
=veTm
-----END PGP SIGNATURE-----
Merge tag 'ti-k3-dt-fixes-for-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux into arm/fixes
Devicetree fixes for TI K3 platforms for v5.13 merge window:
These minor fixes include:
* Fixups for device tree discovered during yaml conversion
* Fixups for missing dma-coherent property in j7200
* Removal of camera sensor node from am65 evm dts to overlay
as camera sensor boards are variable.
* tag 'ti-k3-dt-fixes-for-v5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/nmenon/linux:
arm64: dts: ti: k3*: Introduce reg definition for interrupt routers
arm64: dts: ti: k3-am65|j721e|am64: Map the dma / navigator subsystem via explicit ranges
arm64: dts: ti: k3-*: Rename the TI-SCI node
arm64: dts: ti: k3-am65-wakeup: Drop un-necessary properties from dmsc node
arm64: dts: ti: k3-am65-wakeup: Add debug region to TI-SCI node
arm64: dts: ti: k3-*: Rename the TI-SCI clocks node name
arm64: dts: ti: j7200-main: Mark Main NAVSS as dma-coherent
arm64: dts: ti: k3-am654-base-board: remove ov5640
Link: https://lore.kernel.org/r/20210518115634.467vgpbzplal5kou@obituary
Signed-off-by: Olof Johansson <olof@lixom.net>
- Fix missing-prototypes warning of 'imx27_pm_init' in i.MX27 platform
pm code.
- A couple of patches from Fabio Estevam to fix 'tuning-step' property
in imx7d-meerkat96 and imx7d-pico DT.
- Fix '#gpio-cells' of nxp,pca8574 device in imx6qdl-emcon-avari DT.
- A couple of patches from Lucas Stach to fix regulator and voltage for
imx8mq-zii-ultra board.
- Add missing regulators for imx6q-dhcom to avoid possible instability
issues.
- Fix memory-controller settings for fsl-ls1028a DT.
- Fix RGMII clock and voltage for a couple of fsl-ls1028a-kontron-sl28
boards.
- Fix RGMII connection to QCA8334 switch for imx6dl-yapp4 board.
-----BEGIN PGP SIGNATURE-----
iQFIBAABCgAyFiEEFmJXigPl4LoGSz08UFdYWoewfM4FAmCu8p4UHHNoYXduZ3Vv
QGtlcm5lbC5vcmcACgkQUFdYWoewfM7k+Qf9Ek/atJBjaaVzhbGFQ8HRnDOk4U5J
dR0GbXKSN1zXjDLSBOBRyNcVn2T6lp4LwwYoleC2qG6MNoe6+y7fk1oRdvjkGjRO
ZYfZT/JJl187IN6JsxR8VhRmmcI5/C3bihMbpKoLdHcPGbwC4relfSy99Io94Xfk
CVn3PTxBA4KfoDq/+EiA9HkQ/HwQh/y7KD5yVd6OtLkt9awT1hYW1ttVefp95nAK
5+zTm0Z14U8aGm+wo8jywvSyeXiuMeWDUrweo05XcaHWfcv3T0Wni7tgS2pluxqa
lCMsNQBsZDTk6fUWxqPjjAEl6ks8N1H9L7YIGpq1dOCSYFUqI3jCmkhrFQ==
=5vQk
-----END PGP SIGNATURE-----
Merge tag 'imx-fixes-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux into arm/fixes
i.MX fixes for 5.13:
- Fix missing-prototypes warning of 'imx27_pm_init' in i.MX27 platform
pm code.
- A couple of patches from Fabio Estevam to fix 'tuning-step' property
in imx7d-meerkat96 and imx7d-pico DT.
- Fix '#gpio-cells' of nxp,pca8574 device in imx6qdl-emcon-avari DT.
- A couple of patches from Lucas Stach to fix regulator and voltage for
imx8mq-zii-ultra board.
- Add missing regulators for imx6q-dhcom to avoid possible instability
issues.
- Fix memory-controller settings for fsl-ls1028a DT.
- Fix RGMII clock and voltage for a couple of fsl-ls1028a-kontron-sl28
boards.
- Fix RGMII connection to QCA8334 switch for imx6dl-yapp4 board.
* tag 'imx-fixes-5.13' of git://git.kernel.org/pub/scm/linux/kernel/git/shawnguo/linux:
ARM: dts: imx: emcon-avari: Fix nxp,pca8574 #gpio-cells
ARM: dts: imx7d-pico: Fix the 'tuning-step' property
ARM: dts: imx7d-meerkat96: Fix the 'tuning-step' property
arm64: dts: freescale: sl28: var1: fix RGMII clock and voltage
arm64: dts: freescale: sl28: var4: fix RGMII clock and voltage
ARM: imx: pm-imx27: Include "common.h"
arm64: dts: zii-ultra: fix 12V_MAIN voltage
arm64: dts: zii-ultra: remove second GEN_3V3 regulator instance
arm64: dts: ls1028a: fix memory node
ARM: dts: imx6q-dhcom: Add PU,VDD1P1,VDD2P5 regulators
ARM: dts: imx6dl-yapp4: Fix RGMII connection to QCA8334 switch
Link: https://lore.kernel.org/r/20210527011758.GD8194@dragon
Signed-off-by: Olof Johansson <olof@lixom.net>
Currently, on an anonymous page fault, the kernel allocates a zeroed
page and maps it in user space. If the mapping is tagged (PROT_MTE),
set_pte_at() additionally clears the tags. It is, however, more
efficient to clear the tags at the same time as zeroing the data on
allocation. To avoid clearing the tags on any page (which may not be
mapped as tagged), only do this if the vma flags contain VM_MTE. This
requires introducing a new GFP flag that is used to determine whether
to clear the tags.
The DC GZVA instruction with a 0 top byte (and 0 tag) requires
top-byte-ignore. Set the TCR_EL1.{TBI1,TBID1} bits irrespective of
whether KASAN_HW is enabled.
Signed-off-by: Peter Collingbourne <pcc@google.com>
Co-developed-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://linux-review.googlesource.com/id/Id46dc94e30fe11474f7e54f5d65e7658dbdddb26
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
Link: https://lore.kernel.org/r/20210602235230.3928842-4-pcc@google.com
Signed-off-by: Will Deacon <will@kernel.org>
In an upcoming change we would like to add a flag to
GFP_HIGHUSER_MOVABLE so that it would no longer be an OR
of GFP_HIGHUSER and __GFP_MOVABLE. This poses a problem for
alloc_zeroed_user_highpage_movable() which passes __GFP_MOVABLE
into an arch-specific __alloc_zeroed_user_highpage() hook which ORs
in GFP_HIGHUSER.
Since __alloc_zeroed_user_highpage() is only ever called from
alloc_zeroed_user_highpage_movable(), we can remove one level
of indirection here. Remove __alloc_zeroed_user_highpage(),
make alloc_zeroed_user_highpage_movable() the hook, and use
GFP_HIGHUSER_MOVABLE in the hook implementations so that they will
pick up the new flag that we are going to add.
Signed-off-by: Peter Collingbourne <pcc@google.com>
Link: https://linux-review.googlesource.com/id/Ic6361c657b2cdcd896adbe0cf7cb5a7fbb1ed7bf
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210602235230.3928842-2-pcc@google.com
Signed-off-by: Will Deacon <will@kernel.org>
We alread have is_el1_instruction_abort(), add is_el1_data_abort()
helper and use it.
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210603120239.169018-1-wangkefeng.wang@huawei.com
Signed-off-by: Will Deacon <will@kernel.org>
Kprobes has a counter 'nmissed', that is used to count the number of
times a probe handler was not called. This generally happens when we hit
a kprobe while handling another kprobe.
However, if one of the probe handlers causes a fault, we are currently
incrementing 'nmissed'. The comment in fault handler indicates that this
can be used to account faults taken by the probe handlers. But, this has
never been the intention as is evident from the comment above 'nmissed'
in 'struct kprobe':
/*count the number of times this probe was temporarily disarmed */
unsigned long nmissed;
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Link: https://lkml.kernel.org/r/20210601120150.672652-1-naveen.n.rao@linux.vnet.ibm.com
The Rockchip RK3308 features an integrated USB 2.0 phy, an USB OTG
controller and OHCI/EHCI interfaces.
This patch adds all of those to the RK3308 dtsi and thereby enables USB
support on the RK3308.
Signed-off-by: Tobias Schramm <t.schramm@manjaro.org>
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20210601164800.7670-6-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
The pattern: "^(|usb-|usb2-|usb3-|pci-|pcie-|sata-)phy(@[0-9a-f,]+)*$"
in phy-provider.yaml has required "#phy-cells" for phy nodes.
The "phy-cells" in rockchip-inno-usb2 nodes are located in subnodes.
Rename the nodename to pattern "usb2phy@[0-9a-f]+$" to prevent
notifications.
make ARCH=arm64 dtbs_check
DT_SCHEMA_FILES=~/.local/lib/python3.5/site-packages/dtschema/schemas/
phy/phy-provider.yaml
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Link: https://lore.kernel.org/r/20210601164800.7670-5-jbx6244@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Armv8.7 has introduced BUS_SLOTS and BUS_WIDTH in PMMIR_EL1 register,
add two entries in caps for bus_slots and bus_width under sysfs. It
will return the true slots and width if the information is available,
otherwise it will return 0.
Cc: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Shaokun Zhang <zhangshaokun@hisilicon.com>
Link: https://lore.kernel.org/r/1622704502-63951-1-git-send-email-zhangshaokun@hisilicon.com
Signed-off-by: Will Deacon <will@kernel.org>
Add the new rk817 codec driver to the Odroid Go Advance.
Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
Tested-by: Maciej Matuszczyk <maccraft123mc@gmail.com>
Link: https://lore.kernel.org/r/20210519203754.27184-5-macroalpha82@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
To make future archaeology easier, let's have the string routine comment
blocks encode the specific upstream commit ID they were imported from.
These are the same commit IDs as listed in the commits importing the
code, expanded to 16 characters. Note that the routines have different
commit IDs, each reprsenting the latest upstream commit which changed
the particular routine.
At the same time, let's consistently include 2021 in the copyright
dates.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: Will Deacon <will@kernel.org>
Link: https://lore.kernel.org/r/20210602151358.35571-1-mark.rutland@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Enable the Exynos UFS controller and PHY configs. They need to be
buildin to ensure UFS devices gets detected on exynos7 and its
variant boards.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
Link: https://lore.kernel.org/r/20210531170057.7730-1-alim.akhtar@samsung.com
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
We don't need to register smi_common as syscon. Also add required
property power-domains for this node.
Signed-off-by: Hsin-Yi Wang <hsinyi@chromium.org>
Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com>
Link: https://lore.kernel.org/r/20210601040014.2970805-1-hsinyi@chromium.org
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Back in 9730348075 ("arm64: Increase the max granular size"),
ARCH_DMA_MINALIGN was effectively increased to 128 bytes thanks to an
increase in L1_CACHE_BYTES due to an unsubstantiated performance claim
on the now obsolete ThunderX-1. Although this was reverted in
d93277b983, ARCH_DMA_MINALIGN was kept at 128 bytes by ebc7e21e0f
("arm64: Increase ARCH_DMA_MINALIGN to 128").
During discussion of the original patch, it was reported that the change
also prevented a warning during boot on (again, now obsolete) Qualcomm
server hardware where the cache writeback granule was larger than 64
bytes. The reason for this warning was because non-coherent DMA could
lead to data corruption due to unexpected writeback from the CPU where a
cacheline is shared with other allocations.
Since then, systems have appeared with larger cachelines still, and so
commit 8f5c9037a5 ("arm64/mm: Correct the cache line size warning with
non coherent device") reworked the warning so that it only appears on
systems where non-coherent DMA is actually required and taints the
kernel with TAINT_CPU_OUT_OF_SPEC. We are not aware of any systems, even
including the aforementioned obsolete machines, which have a CWG larger
than 64 bytes and require non-coherent DMA.
More recently, it has been reported that a ARCH_DMA_MINALIGN of 128
bytes wastes considerable memory (~6% immediately after boot on one
system).
Reduce ARCH_DMA_MINALIGN to 64 bytes and allow the warning/taint to
indicate if there are machines that unknowingly rely on this.
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Vincent Whitchurch <vincent.whitchurch@axis.com>
Link: https://lore.kernel.org/linux-arm-kernel/1442944788-17254-1-git-send-email-rric@kernel.org/
Link: https://lore.kernel.org/linux-arm-kernel/CAOZdJXUiRMAguDV+HEJqPg57MyBNqEcTyaH+ya=U93NHb-pdJA@mail.gmail.com/
Link: https://lore.kernel.org/linux-arm-kernel/20190614131141.4428-1-msys.mizuma@gmail.com/
Link: https://lore.kernel.org/r/20210517074332.28280-1-vincent.whitchurch@axis.com
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20210527124356.22367-1-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
The Normal-WT memory type is unused, so remove it and reclaim a MAIR.
Cc: Christoph Hellwig <hch@lst.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Link: https://lore.kernel.org/r/20210527110319.22157-4-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
The only user we have of Normal Write-Through memory is in the ACPI code
when mapping memory regions advertised as EFI_MEMORY_WT. Since most (all?)
CPUs treat write-through as non-cacheable under the hood, don't bother
with the extra memory type here and just treat EFI_MEMORY_WT the same way
as EFI_MEMORY_WC by mapping it to the Normal-NC memory type instead and
emitting a warning if we have failed to find an alternative EFI memory
type.
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Christoph Hellwig <hch@lst.de>
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Link: https://lore.kernel.org/r/20210527110319.22157-3-will@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Now that we're always using STTR variants rather than abstracting two
different addressing modes, the user_ldst macro here is frankly more
obfuscating than helpful. Rewrite __arch_clear_user() with regular
USER() annotations so that it's clearer what's going on, and take the
opportunity to minimise the branchiness in the most common paths, while
also allowing the exception fixup to return an accurate result.
Apparently some folks examine large reads from /dev/zero closely enough
to notice the loop being hot, so align it per the other critical loops
(presumably around a typical instruction fetch granularity).
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/1cbd78b12c076a8ad4656a345811cfb9425df0b3.1622128527.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Although we implement our own assembly version of memchr(), it turns
out to be barely any better than what GCC can generate for the generic
C version (and would go wrong if the size_t argument were ever large
enough to be interpreted as negative). Unfortunately we can't import the
tuned implementation from the Arm optimized-routines library, since that
has some Advanced SIMD parts which are not really viable for general
kernel library code. What we can do, however, is pep things up with some
relatively straightforward word-at-a-time logic for larger calls.
Adding some timing to optimized-routines' memchr() test for a simple
benchmark, overall this version comes in around half as fast as the SIMD
code, but still nearly 4x faster than our existing implementation.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/58471b42f9287e039dafa9e5e7035077152438fd.1622128527.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Import the latest implementation of memcpy(), based on the
upstream code of string/aarch64/memcpy.S at commit afd6244 from
https://github.com/ARM-software/optimized-routines, and subsuming
memmove() in the process.
Note that for simplicity Arm have chosen to contribute this code
to Linux under GPLv2 rather than the original MIT license.
Note also that the needs of the usercopy routines vs. regular memcpy()
have now diverged so far that we abandon the shared template idea
and the damage which that incurred to the tuning of LDP/STP loops.
We'll be back to tackle those routines separately in future.
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/3c953af43506581b2422f61952261e76949ba711.1622128527.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Import the latest version of the former Cortex Strings - now
Arm Optimized Routines - strncmp function based on the upstream
code of string/aarch64/strncmp.S at commit e823e3a from
https://github.com/ARM-software/optimized-routines
Note that for simplicity Arm have chosen to contribute this code
to Linux under GPLv2 rather than the original MIT license.
Signed-off-by: Sam Tebbs <sam.tebbs@arm.com>
[ rm: update attribution and commit message ]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/26110bee02ad360596c9a7536af7eaaf6890d0e8.1622128527.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Import an updated version of the former Cortex Strings - now Arm
Optimized Routines - strcmp function. The latest version introduces
Advanced SIMD usage which rules it out for our purposes, but we can
still pick an intermediate improvement from the previous version,
namely string/aarch64/strlen.S at commit 98e4d6a from
https://github.com/ARM-software/optimized-routines
Note that for simplicity Arm have chosen to contribute this code
to Linux under GPLv2 rather than the original MIT license.
Signed-off-by: Sam Tebbs <sam.tebbs@arm.com>
[ rm: update attribution and commit message ]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/32e3489398a24b23ae6e996935ac4818f8fd9dfd.1622128527.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Import the latest version of the former Cortex Strings - now
Arm Optimized Routines - strcmp function based on the upstream
code of string/aarch64/strcmp.S at commit afd6244 from
https://github.com/ARM-software/optimized-routines
Note that for simplicity Arm have chosen to contribute this code
to Linux under GPLv2 rather than the original MIT license.
Signed-off-by: Sam Tebbs <sam.tebbs@arm.com>
[ rm: update attribution and commit message ]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Link: https://lore.kernel.org/r/0fe90c90b96b569fbdfd46e47bd1298abb02079e.1622128527.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Import the latest version of the former Cortex Strings - now
Arm Optimized Routines - memcmp function based on the upstream
code of string/aarch64/memcmp.S at commit e823e3a from
https://github.com/ARM-software/optimized-routines
Note that for simplicity Arm have chosen to contribute this code
to Linux under GPLv2 rather than the original MIT license.
Signed-off-by: Sam Tebbs <sam.tebbs@arm.com>
[ rm: update attribution and commit message ]
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Link: https://lore.kernel.org/r/2889de2d41054f3f508fb3addad784a3606ef383.1622128527.git.robin.murphy@arm.com
Signed-off-by: Will Deacon <will@kernel.org>
Adds label for MI2S secondary block to allow follower projects to override
for the four speaker support which uses I2S SD1 line on gpio52 pin.
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Judy Hsiao <judyhsiao@chromium.org>
Link: https://lore.kernel.org/r/20210601022117.4071117-1-judyhsiao@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The reason for kprobe::fault_handler(), as given by their comment:
* We come here because instructions in the pre/post
* handler caused the page_fault, this could happen
* if handler tries to access user space by
* copy_from_user(), get_user() etc. Let the
* user-specified handler try to fix it first.
Is just plain bad. Those other handlers are ran from non-preemptible
context and had better use _nofault() functions. Also, there is no
upstream usage of this.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Acked-by: Masami Hiramatsu <mhiramat@kernel.org>
Link: https://lore.kernel.org/r/20210525073213.561116662@infradead.org
Use sysfs_emit instead of snprintf to avoid buf overrun,because in
sysfs_emit it strictly checks whether buf is null or buf whether
pagesize aligned, otherwise it returns an error.
Signed-off-by: Tian Tao <tiantao6@hisilicon.com>
Link: https://lore.kernel.org/r/1621497585-30887-1-git-send-email-tiantao6@hisilicon.com
Signed-off-by: Will Deacon <will@kernel.org>
The MMIO region of a device maybe huge (GB level), try to use
block mapping in stage2 to speedup both map and unmap.
Compared to normal memory mapping, we should consider two more
points when try block mapping for MMIO region:
1. For normal memory mapping, the PA(host physical address) and
HVA have same alignment within PUD_SIZE or PMD_SIZE when we use
the HVA to request hugepage, so we don't need to consider PA
alignment when verifing block mapping. But for device memory
mapping, the PA and HVA may have different alignment.
2. For normal memory mapping, we are sure hugepage size properly
fit into vma, so we don't check whether the mapping size exceeds
the boundary of vma. But for device memory mapping, we should pay
attention to this.
This adds get_vma_page_shift() to get page shift for both normal
memory and device MMIO region, and check these two points when
selecting block mapping size for MMIO region.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210507110322.23348-3-zhukeqian1@huawei.com
The MMIO regions may be unmapped for many reasons and can be remapped
by stage2 fault path. Map MMIO regions at creation time becomes a
minor optimization and makes these two mapping path hard to sync.
Remove the mapping code while keep the useful sanity check.
Signed-off-by: Keqian Zhu <zhukeqian1@huawei.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
Link: https://lore.kernel.org/r/20210507110322.23348-2-zhukeqian1@huawei.com
In order to deal with the lack of active state, we need to use
the mask/unmask primitives (after all, the active state is just an
additional mask on top of the normal one).
To avoid adding a bunch of ugly conditionals in the timer and vgic
code, let's use a timer-specific irqdomain to deal with the state
conversion. Yes, this is an unexpected use of irqdomains, but
there is no reason not to be just as creative as the designers
of the HW...
This involves overloading the vcpu_affinity, set_irqchip_state
and eoi callbacks so that the rest of the KVM code can continue
ignoring the oddities of the underlying platform.
Signed-off-by: Marc Zyngier <maz@kernel.org>
As we are about to add some more things to the timer IRQ
configuration, move this code out of the main timer init code
into its own set of functions.
No functional changes.
Signed-off-by: Marc Zyngier <maz@kernel.org>
In order to deal with these systems that do not offer HW-based
deactivation of interrupts, let implement a SW-based approach:
- When the irq is queued into a LR, treat it as a pure virtual
interrupt and set the EOI flag in the LR.
- When the interrupt state is read back from the LR, force a
deactivation when the state is invalid (neither active nor
pending)
Interrupts requiring such treatment get the VGIC_SW_RESAMPLE flag.
Signed-off-by: Marc Zyngier <maz@kernel.org>
We already have the option to attach a callback to an interrupt
to retrieve its pending state. As we are planning to expand this
facility, move this callback into its own data structure.
This will limit the size of individual interrupts as the ops
structures can be shared across multiple interrupts.
Signed-off-by: Marc Zyngier <maz@kernel.org>
The vGIC, as architected by ARM, allows a virtual interrupt to
trigger the deactivation of a physical interrupt. This allows
the following interrupt to be delivered without requiring an exit.
However, some implementations have choosen not to implement this,
meaning that we will need some unsavoury workarounds to deal with this.
On detecting such a case, taint the kernel and spit a nastygram.
We'll deal with this in later patches.
Signed-off-by: Marc Zyngier <maz@kernel.org>
As it turns out, not all the interrupt controllers are able to
expose a vGIC maintenance interrupt that can be independently
enabled/disabled.
And to be fair, it doesn't really matter as all we require is
for the interrupt to kick us out of guest mode out way or another.
To that effect, add gic_kvm_info.no_maint_irq_mask for an interrupt
controller to advertise the lack of masking.
Signed-off-by: Marc Zyngier <maz@kernel.org>
As we we now entertain the possibility of FIQ being used on the host,
treat the signalling of a FIQ while running a guest as an IRQ,
causing an exit instead of a HYP panic.
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
The vGIC advertising code is unsurprisingly very much tied to
the GIC implementations. However, we are about to extend the
support to lesser implementations.
Let's dissociate the vgic registration from the GIC code and
move it into KVM, where it makes a bit more sense. This also
allows us to mark the gic_kvm_info structures as __initdata.
Reviewed-by: Alexandru Elisei <alexandru.elisei@arm.com>
Signed-off-by: Marc Zyngier <maz@kernel.org>
The first UART controller in "Everything-Else" power domain, usually used
for Bluetooth HCI has 128bytes FIFO depth.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://lore.kernel.org/r/20210518075833.3736038-4-narmstrong@baylibre.com
The sc7280 IDP board is also called senor in the Chrome OS builds.
Add the "google,senor" compatible so coreboot/depthcharge knows what
device tree blob to pick
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Rajendra Nayak <rnayak@codeaurora.org>
Link: https://lore.kernel.org/r/1619674827-26650-2-git-send-email-rnayak@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Move rmtfs memory region so that it does not overlap with system
RAM (kernel data) when KAsan is enabled. This puts rmtfs right
after mba_mem which is not supposed to increase beyond 0x94600000
Reviewed-by: Sibi Sankar <sibis@codeaurora.org>
Signed-off-by: Sujit Kautkar <sujitka@chromium.org>
Link: https://lore.kernel.org/r/20210514113430.1.Ic2d032cd80424af229bb95e2c67dd4de1a70cb0c@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add support for the video, gpu, display, lpass clock controller
device nodes for SC7280 SoC.
Signed-off-by: Taniya Das <tdas@codeaurora.org>
Link: https://lore.kernel.org/r/1618020280-5470-3-git-send-email-tdas@codeaurora.org
[bjorn: Dropped includes, as they are not present in v5.13-rc1]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add ADC and thermal monitor configuration for skin temperature,
plus a thermal zone that monitors the skin temperature and uses
the big cores as cooling devices.
CoachZ rev1 is stuffed with an incompatible thermistor for the
skin temperature, disable the thermal zone for rev1 to avoid
the use of bogus temperature values.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20210414111007.v1.1.I1a438604a79025307f177347d45815987b105cb5@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
As per Dmitry Baryshkov [1]:
a) The 2nd "reg" should be 0x3c because "Offset 0x38 is
USB3_DP_COM_REVISION_ID3 (not used by the current driver though)."
b) The 3rd "reg" "is a serdes region and qmp_v3_dp_serdes_tbl contains
registers 0x148 and 0x154."
I think because the 3rd "reg" is a serdes region we should just use
the same size as the 1st "reg"?
[1] https://lore.kernel.org/r/ee5695bb-a603-0dd5-7a7f-695e919b1af1@linaro.org
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Cc: Stephen Boyd <swboyd@chromium.org>
Cc: Jeykumar Sankaran <jsanka@codeaurora.org>
Cc: Chandan Uddaraju <chandanu@codeaurora.org>
Cc: Vara Reddy <varar@codeaurora.org>
Cc: Tanmay Shah <tanmay@codeaurora.org>
Cc: Rob Clark <robdclark@chromium.org>
Fixes: 58fd7ae621 ("arm64: dts: qcom: sc7180: Update dts for DP phy inside QMP phy")
Reported-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210315103836.1.I9a97120319d43b42353aeac4d348624d60687df7@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Use sm8250 compatibles instead of sdm845 compatibles
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Signed-off-by: Jonathan Marek <jonathan@marek.ca>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Link: https://lore.kernel.org/r/20210329120051.3401567-5-dmitry.baryshkov@linaro.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
We should indicate that we're not using the HPD pin on this device, per
the binding document. Otherwise if code in the future wants to enable
HPD in the bridge when this property is absent we'll be enabling HPD
when it isn't supposed to be used. Presumably this board isn't using hpd
on the bridge.
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Steev Klimaszewski <steev@kali.org>
Fixes: 956e9c85f4 ("arm64: dts: qcom: c630: Define eDP bridge and panel")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210324231424.2890039-1-swboyd@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20210324204836.29668-8-Sergey.Semin@baikalelectronics.ru
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
We should indicate that we're not using the HPD pin on this device, per
the binding document. Otherwise if code in the future wants to enable
HPD in the bridge when this property is absent we'll be wasting power
powering hpd when we don't use it on trogdor boards. We didn't notice
this before because the kernel driver blindly disables hpd, but that
won't be true for much longer.
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Cc: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Cc: Douglas Anderson <dianders@chromium.org>
Fixes: 7ec3e67307 ("arm64: dts: qcom: sc7180-trogdor: add initial trogdor and lazor dt")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Link: https://lore.kernel.org/r/20210324025534.1837405-1-swboyd@chromium.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Reserve GPIO pins 85-88 as these aren't meant to be accessible from the
application CPUs (causes reboot). Yet another fix similar to
9134586715, 5f8d3ab136, which is needed to allow angler to boot after
3edfb7bd76 ("gpiolib: Show correct direction from the beginning").
Fixes: feeaf56ac7 ("arm64: dts: msm8994 SoC and Huawei Angler (Nexus 6P) support")
Signed-off-by: Petr Vorel <petr.vorel@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210415193913.1836153-1-petr.vorel@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Fix the compatible to make the driver probe and tell the
driver where to look for the "xo" clock to make sure everything
works.
Then we get a happy (eh, happier) 8996:
somainline-sdcard:/home/konrad# cat /sys/kernel/debug/clk/pwrcl_pll/clk_rate
1152000000
Don't backport without "arm64: dts: qcom: msm8996: Add CPU opps", as
the system fails to boot without consumers for these clocks.
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210527192958.775434-1-konrad.dybcio@somainline.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Add the operating points capabilities of the kryo CPUs, that can be
used for frequency scaling. There are two differents operating point
tables, one for the big cluster and one for the LITTLE cluster.
This frequency scaling support can then be used as a passive cooling
device (cpufreq cooling device).
Only add nominal fmax for now, since there is no dynamic control of
VDD APC (s11..) which is statically set at its nominal value.
Original patch link: https://patchwork.kernel.org/project/linux-arm-msm/patch/1595253740-29466-6-git-send-email-loic.poulain@linaro.org/
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
[konrad: drop the thermals part, rebase and remove spaces within <>]
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210527194455.782108-2-konrad.dybcio@somainline.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
CoachZ rev3 uses a 100k NTC thermistor for the charger temperatures,
instead of the 47k NTC that is stuffed in earlier revisions. Add .dts
files for rev3.
The 47k NTC currently isn't supported by the PM6150 ADC driver.
Disable the charger thermal zone for rev1 and rev2 to avoid the use
of bogus temperature values.
This also gets rid of the explicit DT files for rev2 and handles
rev2 in the rev1 .dts instead. There was some back and forth
downstream involving the 'dmic_clk_en' pin, after that was sorted
out the DT for rev1 and rev2 is the same.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210322094628.v4.3.I95b8a63103b77cab6a7cf9c150f0541db57fda98@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The only kernel visible change with respect to rev2 is that pompom
rev3 changed the charger thermistor from a 47k to a 100k NTC to use
a thermistor which is supported by the PM6150 ADC driver.
Disable the charger thermal zone for pompom rev1 and rev2 to avoid
the use of bogus temperature values from the unsupported thermistor.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210322094628.v4.2.I4138c3edee23d1efa637eef51e841d9d2e266659@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Commit f73558cc83d1 ("arm64: dts: qcom: sc7180: Disable charger
thermal zone for lazor") disables the charger thermal zone for
specific lazor revisions due to an unsupported thermistor type.
The initial idea was to disable the thermal zone for older
revisions and leave it enabled for newer ones that use a
supported thermistor. Finally the thermistor won't be changed
on newer revisions, hence the thermal zone should be disabled
for all lazor (and limozeen) revisions. Instead of disabling
it per revision do it once in the shared .dtsi for lazor.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Link: https://lore.kernel.org/r/20210322094628.v4.1.I6d587e7ae72a5a47253bb95dfdc3158f8cc8a157@changeid
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
We had introduced the QUP-CORE ICC path to put proxy votes from
QUP wrapper on behalf of earlycon, if other users of QUP-CORE turn
off this clock before the real console is probed, unclocked access
to HW was seen from earlycon.
With ICC sync state support proxy votes are no longer need as ICC
will ensure that the default bootloader votes are not removed until
all it's consumer are probed.
We can safely remove ICC path for QUP-CORE clock from QUP wrapper
device.
Signed-off-by: Roja Rani Yarubandi <rojay@codeaurora.org>
Signed-off-by: Akash Asthana <akashast@codeaurora.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Link: https://lore.kernel.org/r/20210324101836.25272-3-rojay@codeaurora.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Some node unit addresses were put wrongly in the dts, resulting in
below warning when run with W=1
arch/arm64/boot/dts/qcom/sm8350.dtsi:693.34-702.5: Warning (simple_bus_reg): /soc@0/thermal-sensor@c222000: simple-bus unit address format error, expected "c263000"
arch/arm64/boot/dts/qcom/sm8350.dtsi:704.34-713.5: Warning (simple_bus_reg): /soc@0/thermal-sensor@c223000: simple-bus unit address format error, expected "c265000"
arch/arm64/boot/dts/qcom/sm8350.dtsi:1180.32-1185.5: Warning (simple_bus_reg): /soc@0/interconnect@90e0000: simple-bus unit address format error, expected "90c0000"
Fix by correcting to the correct address as given in reg node
Reviewed-by: Robert Foss <robert.foss@linaro.org>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20210513060733.382420-1-vkoul@kernel.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
With this patch, DMA has a chance of probing and doing something
useful.
Reviewed-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Reviewed-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Felipe Balbi <felipe.balbi@microsoft.com>
Link: https://lore.kernel.org/r/20210417061951.2105530-3-balbi@kernel.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
The speedbin value blown in the efuse is used to determine is used to
determine the voltage and frequency value for different IPs, including
GPU, CPUs... So it's really not a gpu specific information.
This patch simply renames 'gpu_speed_bin' node to 'speedbin'.
Signed-off-by: Loic Poulain <loic.poulain@linaro.org>
Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org>
Link: https://lore.kernel.org/r/20210527194455.782108-1-konrad.dybcio@somainline.org
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
One of the QUSB USB PHY-s has been left enabled by
default, this is probably just a mistake as other
USB PHY-s are disabled by default.
It makes no sense to have it enabled by default as
not all board implement USB ports, so disable it.
Reviewed-by: Kathiravan T <kathirav@codeaurora.org>
Signed-off-by: Robert Marko <robimarko@gmail.com>
Link: https://lore.kernel.org/r/20210526150125.1816335-1-robimarko@gmail.com
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Correct the voltages in the "Power Optimized" (<= 1.5 GHz) Cortex-A57
operating point table entries for the R-Car M3-W and M3-W+ SoCs from
0.82V to 0.83V, as per the R-Car Gen3 EC Manual Errata for Revision
0.53.
Based on a patch for R-Car M3-W in the BSP by Takeshi Kihara
<takeshi.kihara.df@renesas.com>.
Fixes: da7e311334 ("arm64: dts: renesas: r8a7796: Add OPPs table for cpu devices")
Fixes: f51746ad7d ("arm64: dts: renesas: Add Renesas R8A77961 SoC support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/b9e9db907514790574429b83d070c823b36085ef.1619699909.git.geert+renesas@glider.be
Tag the highest "Power Optimized" (1.5 GHz) Cortex-A57 operating point
table entries for the RZ/G2M, R-Car M3-W and M3-W+ SoCs with the
"opp-suspend" property. This makes sure the system will enter suspend
in the same performance state as it will be resumed by the firmware
later, avoiding state inconsistencies after resume.
Based on a patch for R-Car M3-W in the BSP by Takeshi Kihara
<takeshi.kihara.df@renesas.com>.
Fixes: 800037e815 ("arm64: dts: renesas: r8a774a1: Add operating points")
Fixes: da7e311334 ("arm64: dts: renesas: r8a7796: Add OPPs table for cpu devices")
Fixes: f51746ad7d ("arm64: dts: renesas: Add Renesas R8A77961 SoC support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Link: https://lore.kernel.org/r/45a061c3b0463aac7d10664f47c4afdd999da50d.1619699721.git.geert+renesas@glider.be
This fix the recent removal of clock drivers selection.
While it is not necessary to select the clock drivers themselves, we need
to select a proper implementation of the clock API, which for the meson, is
CCF
Fixes: ba66a25536 ("arm64: meson: ship only the necessary clock controllers")
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Link: https://lore.kernel.org/r/20210429083823.59546-1-jbrunet@baylibre.com
* Another state update on exit to userspace fix
* Prevent the creation of mixed 32/64 VMs
* Fix regression with irqbypass not restarting the guest on failed connect
* Fix regression with debug register decoding resulting in overlapping access
* Commit exception state on exit to usrspace
* Fix the MMU notifier return values
* Add missing 'static' qualifiers in the new host stage-2 code
x86 fixes:
* fix guest missed wakeup with assigned devices
* fix WARN reported by syzkaller
* do not use BIT() in UAPI headers
* make the kvm_amd.avic parameter bool
PPC fixes:
* make halt polling heuristics consistent with other architectures
selftests:
* various fixes
* new performance selftest memslot_perf_test
* test UFFD minor faults in demand_paging_test
-----BEGIN PGP SIGNATURE-----
iQFIBAABCAAyFiEE8TM4V0tmI4mGbHaCv/vSX3jHroMFAmCyF0MUHHBib256aW5p
QHJlZGhhdC5jb20ACgkQv/vSX3jHroOHSgf/Q4Hm5e12Bj2xJy6A+iShnrbbT8PW
hcIIOA7zGWXfjVYcBV7anbj7CcpzfIz0otcRBABa5mkhj+fb3YmPEb0EzCPi4Hru
zxpcpB2w7W7WtUOIKe2EmaT+4Pk6/iLcfr8UMHMqx460akE9OmIg10QNWai3My/3
RIOeakSckBI9e/1TQZbxH66dsLwCT0lLco7i7AWHdFxkzUQyoA34HX5pczOCBsO5
3nXH+/txnRVhqlcyzWLVVGVzFqmpHtBqkIInDOXfUqIoxo/gOhOgF1QdMUEKomxn
5ZFXlL5IXNtr+7yiI67iHX7CWkGZE9oJ04TgPHn6LR6wRnVvc3JInzcB5Q==
=ollO
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm
Pull KVM fixes from Paolo Bonzini:
"ARM fixes:
- Another state update on exit to userspace fix
- Prevent the creation of mixed 32/64 VMs
- Fix regression with irqbypass not restarting the guest on failed
connect
- Fix regression with debug register decoding resulting in
overlapping access
- Commit exception state on exit to usrspace
- Fix the MMU notifier return values
- Add missing 'static' qualifiers in the new host stage-2 code
x86 fixes:
- fix guest missed wakeup with assigned devices
- fix WARN reported by syzkaller
- do not use BIT() in UAPI headers
- make the kvm_amd.avic parameter bool
PPC fixes:
- make halt polling heuristics consistent with other architectures
selftests:
- various fixes
- new performance selftest memslot_perf_test
- test UFFD minor faults in demand_paging_test"
* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm: (44 commits)
selftests: kvm: fix overlapping addresses in memslot_perf_test
KVM: X86: Kill off ctxt->ud
KVM: X86: Fix warning caused by stale emulation context
KVM: X86: Use kvm_get_linear_rip() in single-step and #DB/#BP interception
KVM: x86/mmu: Fix comment mentioning skip_4k
KVM: VMX: update vcpu posted-interrupt descriptor when assigning device
KVM: rename KVM_REQ_PENDING_TIMER to KVM_REQ_UNBLOCK
KVM: x86: add start_assignment hook to kvm_x86_ops
KVM: LAPIC: Narrow the timer latency between wait_lapic_expire and world switch
selftests: kvm: do only 1 memslot_perf_test run by default
KVM: X86: Use _BITUL() macro in UAPI headers
KVM: selftests: add shared hugetlbfs backing source type
KVM: selftests: allow using UFFD minor faults for demand paging
KVM: selftests: create alias mappings when using shared memory
KVM: selftests: add shmem backing source type
KVM: selftests: refactor vm_mem_backing_src_type flags
KVM: selftests: allow different backing source types
KVM: selftests: compute correct demand paging size
KVM: selftests: simplify setup_demand_paging error handling
KVM: selftests: Print a message if /dev/kvm is missing
...
The MCU RGMII MCU_RGMII1_TXC pin is defined as input by mistake, although
this does not make any difference functionality wise it's better to update
to avoid confusion.
Hence fix MCU RGMII MCU_RGMII1_TXC pin pinmux definitions to be an output
in K3 am654x/j721e/j7200 board files.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210526132041.6104-1-grygorii.strashko@ti.com
Enable work around feature built into the controller to address issue with
RX Sensitivity for USB2 PHY.
Fixes: 6197d7139d ("arm64: dts: ti: k3-j7200-main: Add USB controller")
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
Reviewed-by: Vignesh Raghavendra <vigneshr@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Link: https://lore.kernel.org/r/20210512153308.5840-1-a-govindraju@ti.com
The current scheme for audio card names is suboptimal because it causes
the automatically generated names (for ID and driver) to be truncated,
which in turn can cause conflicts.
Introduce a new scheme which reuses the board model for the names and
appends the "HDA" and "APE" suffixes for the HDA and APE, respectively.
As a side-effect these suffixes end up being used as the ID of the SoC
sound cards which makes it easy for users to select them when using the
ALSA command-line utilities, for example.
As a separate measure, the driver name for the cards is now set by the
corresponding audio driver (either tegra-hda or tegra-ape), making it a
more useful identifier than the currently normalized card name.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Populate the device-tree node for the PMU device on Tegra194. This also
fixes the following warning that is observed on booting Tegra194.
ERR KERN kvm: pmu event creation failed -2
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
