kernel/git/stable/linux.git/arch/arm64/boot, branch linux-5.7.y

arm64: dts: hisilicon: hikey: fixes to comply with adi, adv7533 DT binding

2020-08-19T06:23:36+00:00

[ Upstream commit bbe28fc3cbabbef781bcdf847615d52ce2e26e42 ] hi3660-hikey960.dts: Define a 'ports' node for 'adv7533: adv7533@39' and the 'adi,dsi-lanes' property to make it compliant with the adi,adv7533 DT binding. This fills the requirements to meet the binding requirements, remote endpoints are not defined. hi6220-hikey.dts: Change property name s/pd-gpio/pd-gpios, gpio properties should be plural. This is just a cosmetic change. Signed-off-by: Ricardo Cañuelo Acked-by: Laurent Pinchart Signed-off-by: Wei Xu Signed-off-by: Sasha Levin

arm64: dts: meson: fix mmc0 tuning error on Khadas VIM3

2020-08-19T06:23:31+00:00

[ Upstream commit f1bb924e8f5b50752a80fa5b48c43003680a7b64 ] Similar to other G12B devices using the W400 dtsi, I see reports of mmc0 tuning errors on VIM3 after a few hours uptime: [12483.917391] mmc0: tuning execution failed: -5 [30535.551221] mmc0: tuning execution failed: -5 [35359.953671] mmc0: tuning execution failed: -5 [35561.875332] mmc0: tuning execution failed: -5 [61733.348709] mmc0: tuning execution failed: -5 I do not see the same on VIM3L, so remove sd-uhs-sdr50 from the common dtsi to silence the error, then (re)add it to the VIM3L dts. Fixes: 4f26cc1c96c9 ("arm64: dts: khadas-vim3: move common nodes into meson-khadas-vim3.dtsi") Fixes: 700ab8d83927 ("arm64: dts: khadas-vim3: add support for the SM1 based VIM3L") Signed-off-by: Christian Hewitt Signed-off-by: Kevin Hilman Link: https://lore.kernel.org/r/20200721015950.11816-1-christianshewitt@gmail.com Signed-off-by: Sasha Levin

arm64: dts: renesas: Fix SD Card/eMMC interface device node names

2020-08-19T06:23:29+00:00

[ Upstream commit a6cb262af1e1adfa6287cb43f09021ee42beb21c ] Fix the device node names as "mmc@". Fixes: 663386c3e1aa ("arm64: dts: renesas: r8a774a1: Add SDHI nodes") Fixes: 9b33e3001b67 ("arm64: dts: renesas: Initial r8a774b1 SoC device tree") Fixes: 77223211f44d ("arm64: dts: renesas: r8a774c0: Add SDHI nodes") Fixes: d9d67010e0c6 ("arm64: dts: r8a7795: Add SDHI support to dtsi") Fixes: a513cf1e6457 ("arm64: dts: r8a7796: add SDHI nodes") Fixes: 111cc9ace2b5 ("arm64: dts: renesas: r8a77961: Add SDHI nodes") Fixes: f51746ad7d1f ("arm64: dts: renesas: Add Renesas R8A77961 SoC support") Fixes: df863d6f95f5 ("arm64: dts: renesas: initial R8A77965 SoC device tree") Fixes: 9aa3558a02f0 ("arm64: dts: renesas: ebisu: Add and enable SDHI device nodes") Fixes: 83f18749c2f6 ("arm64: dts: renesas: r8a77995: Add SDHI (MMC) support") Signed-off-by: Yoshihiro Shimoda Link: https://lore.kernel.org/r/1594382634-13714-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin

arm64: dts: exynos: Fix silent hang after boot on Espresso

2020-08-19T06:23:28+00:00

[ Upstream commit b072714bfc0e42c984b8fd6e069f3ca17de8137a ] Once regulators are disabled after kernel boot, on Espresso board silent hang observed because of LDO7 being disabled. LDO7 actually provide power to CPU cores and non-cpu blocks circuitries. Keep this regulator always-on to fix this hang. Fixes: 9589f7721e16 ("arm64: dts: Add S2MPS15 PMIC node on exynos7-espresso") Signed-off-by: Alim Akhtar Signed-off-by: Krzysztof Kozlowski Signed-off-by: Sasha Levin

arm64: dts: sun50i-pinephone: dldo4 must not be >= 1.8V

2020-08-19T06:23:28+00:00

[ Upstream commit 86be5c789690eb08656b08c072c50a7b02bf41f1 ] Some outputs from the RTL8723CS are connected to the PL port (BT_WAKE_AP), which runs at 1.8V. When BT_WAKE_AP is high, the PL pin this signal is connected to is overdriven, and the whole PL port's voltage rises somewhat. This results in changing voltage on the R_PWM pin (PL10), which is the cause for backlight flickering very noticeably when typing on a Bluetooth keyboard, because backlight intensity is highly sensitive to the voltage of the R_PWM pin. Limit the maximum WiFi/BT I/O voltage to 1.8V to avoid overdriving the PL port pins via BT and WiFi IO port signals. WiFi and BT functionality is unaffected by this change. This completely stops the backlight flicker when using bluetooth. Fixes: 91f480d40942 ("arm64: dts: allwinner: Add initial support for Pine64 PinePhone") Signed-off-by: Ondrej Jirman Link: https://lore.kernel.org/r/20200703194842.111845-4-megous@megous.com Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin

arm64: dts: qcom: msm8916: Replace invalid bias-pull-none property

2020-08-19T06:23:26+00:00

[ Upstream commit 1b6a1a162defe649c5599d661b58ac64bb6f31b6 ] msm8916-pins.dtsi specifies "bias-pull-none" for most of the audio pin configurations. This was likely copied from the qcom kernel fork where the same property was used for these audio pins. However, "bias-pull-none" actually does not exist at all - not in mainline and not in downstream. I can only guess that the original intention was to configure "no pull", i.e. bias-disable. Change it to that instead. Fixes: 143bb9ad85b7 ("arm64: dts: qcom: add audio pinctrls") Cc: Srinivas Kandagatla Signed-off-by: Stephan Gerhold Link: https://lore.kernel.org/r/20200605185916.318494-2-stephan@gerhold.net Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

arm64: dts: rockchip: fix rk3399-puma gmac reset gpio

2020-08-19T06:23:26+00:00

[ Upstream commit 8a445086f8af0b7b9bd8d1901d6f306bb154f70d ] The puma gmac node currently uses opposite active-values for the gmac phy reset pin. The gpio-declaration uses active-high while the separate snps,reset-active-low property marks the pin as active low. While on the kernel side this works ok, other DT users may get confused - as seen with uboot right now. So bring this in line and make both properties match, similar to the other Rockchip board. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20200603132836.362519-1-heiko@sntech.de Signed-off-by: Sasha Levin

arm64: dts: rockchip: fix rk3399-puma vcc5v0-host gpio

2020-08-19T06:23:26+00:00

[ Upstream commit 7a7184f6cfa9279f1a1c10a1845d247d7fad54ff ] The puma vcc5v0_host regulator node currently uses opposite active-values for the enable pin. The gpio-declaration uses active-high while the separate enable-active-low property marks the pin as active low. While on the kernel side this works ok, other DT users may get confused - as seen with uboot right now. So bring this in line and make both properties match, similar to the gmac fix. Fixes: 2c66fc34e945 ("arm64: dts: rockchip: add RK3399-Q7 (Puma) SoM") Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20200604091239.424318-1-heiko@sntech.de Signed-off-by: Sasha Levin

arm64: dts: rockchip: fix rk3368-lion gmac reset gpio

2020-08-19T06:23:26+00:00

[ Upstream commit 2300e6dab473e93181cf76e4fe6671aa3d24c57b ] The lion gmac node currently uses opposite active-values for the gmac phy reset pin. The gpio-declaration uses active-high while the separate snps,reset-active-low property marks the pin as active low. While on the kernel side this works ok, other DT users may get confused - as seen with uboot right now. So bring this in line and make both properties match, similar to the other Rockchip board. Fixes: d99a02bcfa81 ("arm64: dts: rockchip: add RK3368-uQ7 (Lion) SoM") Signed-off-by: Heiko Stuebner Link: https://lore.kernel.org/r/20200607212909.920575-1-heiko@sntech.de Signed-off-by: Sasha Levin

arm64: dts: clearfog-gt-8k: fix switch link configuration

2020-07-29T08:19:43+00:00

[ Upstream commit 7c6719a1aaca51ffd7cdf3905e70aa8313f6ef26 ] The commit below caused a regression for clearfog-gt-8k, where the link between the switch and the host does not come up. Investigation revealed two issues: - MV88E6xxx DSA no longer allows an in-band link to come up as the link is programmed to be forced down. Commit "net: dsa: mv88e6xxx: fix in-band AN link establishment" addresses this. - The dts configured dissimilar link modes at each end of the host to switch link; the host was configured using a fixed link (so has no in-band status) and the switch was configured to expect in-band status. With both issues fixed, the regression is resolved. Fixes: 34b5e6a33c1a ("net: dsa: mv88e6xxx: Configure MAC when using fixed link") Reported-by: Martin Rowe Signed-off-by: Russell King Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin