From 1b133129ad6b28186214259af3bd5fc651a85509 Mon Sep 17 00:00:00 2001 From: E Shattow Date: Mon, 9 Dec 2024 20:19:56 -0800 Subject: [PATCH 01/35] riscv: dts: starfive: Fix a typo in StarFive JH7110 pin function definitions Fix a typo in StarFive JH7110 pin function definitions for GPOUT_SYS_SDIO1_DATA4 Fixes: e22f09e598d12 ("riscv: dts: starfive: Add StarFive JH7110 pin function definitions") Signed-off-by: E Shattow Acked-by: Hal Feng CC: stable@vger.kernel.org Signed-off-by: Conor Dooley --- arch/riscv/boot/dts/starfive/jh7110-pinfunc.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/riscv/boot/dts/starfive/jh7110-pinfunc.h b/arch/riscv/boot/dts/starfive/jh7110-pinfunc.h index 256de17f52611..ae49c908e7fb3 100644 --- a/arch/riscv/boot/dts/starfive/jh7110-pinfunc.h +++ b/arch/riscv/boot/dts/starfive/jh7110-pinfunc.h @@ -89,7 +89,7 @@ #define GPOUT_SYS_SDIO1_DATA1 59 #define GPOUT_SYS_SDIO1_DATA2 60 #define GPOUT_SYS_SDIO1_DATA3 61 -#define GPOUT_SYS_SDIO1_DATA4 63 +#define GPOUT_SYS_SDIO1_DATA4 62 #define GPOUT_SYS_SDIO1_DATA5 63 #define GPOUT_SYS_SDIO1_DATA6 64 #define GPOUT_SYS_SDIO1_DATA7 65 From 1ac98d6484c4a53e9b3ed1f59d03a2dd2d287b70 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Sat, 11 Jan 2025 18:23:26 +0100 Subject: [PATCH 02/35] soc: qcom: pmic_glink: Drop redundant pg assignment before taking lock Commit e9f826b0459f ("soc: qcom: pmic_glink: simplify locking with guard()") was on top of a fix [1] which was moving the 'pg = __pmic_glink' assignment into the critical section. Unfortunately the actual fix was not applied and instead rebased version of the next patch got in. The resulting code is in general correct, but now there is a duplicated assignment 'pg = __pmic_glink'. [1] https://lore.kernel.org/all/20240822164815.230167-1-krzysztof.kozlowski@linaro.org/ Fixes: e9f826b0459f ("soc: qcom: pmic_glink: simplify locking with guard()") Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250111172326.101779-1-krzysztof.kozlowski@linaro.org Signed-off-by: Bjorn Andersson --- drivers/soc/qcom/pmic_glink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/soc/qcom/pmic_glink.c b/drivers/soc/qcom/pmic_glink.c index 052c292eeda61..cde19cdfd3c7f 100644 --- a/drivers/soc/qcom/pmic_glink.c +++ b/drivers/soc/qcom/pmic_glink.c @@ -233,7 +233,7 @@ static void pmic_glink_pdr_callback(int state, char *svc_path, void *priv) static int pmic_glink_rpmsg_probe(struct rpmsg_device *rpdev) { - struct pmic_glink *pg = __pmic_glink; + struct pmic_glink *pg; guard(mutex)(&__pmic_glink_lock); pg = __pmic_glink; From 7f048b202333b967782a98aa21bb3354dc379bbf Mon Sep 17 00:00:00 2001 From: Dan Carpenter Date: Wed, 15 Jan 2025 09:52:53 +0300 Subject: [PATCH 03/35] firmware: qcom: scm: Fix error code in probe() Set the error code if devm_qcom_tzmem_pool_new() fails. Don't return success. Fixes: 1e76b546e6fc ("firmware: qcom: scm: Cleanup global '__scm' on probe failures") Signed-off-by: Dan Carpenter Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/a0845467-4f83-4070-ab1e-ff7e6764609f@stanley.mountain Signed-off-by: Bjorn Andersson --- drivers/firmware/qcom/qcom_scm.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c index f0569bb9411f7..fc4d67e4c4a67 100644 --- a/drivers/firmware/qcom/qcom_scm.c +++ b/drivers/firmware/qcom/qcom_scm.c @@ -2301,8 +2301,8 @@ static int qcom_scm_probe(struct platform_device *pdev) __scm->mempool = devm_qcom_tzmem_pool_new(__scm->dev, &pool_config); if (IS_ERR(__scm->mempool)) { - dev_err_probe(__scm->dev, PTR_ERR(__scm->mempool), - "Failed to create the SCM memory pool\n"); + ret = dev_err_probe(__scm->dev, PTR_ERR(__scm->mempool), + "Failed to create the SCM memory pool\n"); goto err; } From da8d493a80993972c427002684d0742560f3be4a Mon Sep 17 00:00:00 2001 From: Johan Hovold Date: Mon, 20 Jan 2025 16:10:00 +0100 Subject: [PATCH 04/35] firmware: qcom: uefisecapp: fix efivars registration race Since the conversion to using the TZ allocator, the efivars service is registered before the memory pool has been allocated, something which can lead to a NULL-pointer dereference in case of a racing EFI variable access. Make sure that all resources have been set up before registering the efivars. Fixes: 6612103ec35a ("firmware: qcom: qseecom: convert to using the TZ allocator") Cc: stable@vger.kernel.org # 6.11 Cc: Bartosz Golaszewski Signed-off-by: Johan Hovold Reviewed-by: Konrad Dybcio Reviewed-by: Maximilian Luz Reviewed-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20250120151000.13870-1-johan+linaro@kernel.org Signed-off-by: Bjorn Andersson --- .../firmware/qcom/qcom_qseecom_uefisecapp.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c b/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c index 447246bd04be3..98a463e9774bf 100644 --- a/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c +++ b/drivers/firmware/qcom/qcom_qseecom_uefisecapp.c @@ -814,15 +814,6 @@ static int qcom_uefisecapp_probe(struct auxiliary_device *aux_dev, qcuefi->client = container_of(aux_dev, struct qseecom_client, aux_dev); - auxiliary_set_drvdata(aux_dev, qcuefi); - status = qcuefi_set_reference(qcuefi); - if (status) - return status; - - status = efivars_register(&qcuefi->efivars, &qcom_efivar_ops); - if (status) - qcuefi_set_reference(NULL); - memset(&pool_config, 0, sizeof(pool_config)); pool_config.initial_size = SZ_4K; pool_config.policy = QCOM_TZMEM_POLICY_MULTIPLIER; @@ -833,6 +824,15 @@ static int qcom_uefisecapp_probe(struct auxiliary_device *aux_dev, if (IS_ERR(qcuefi->mempool)) return PTR_ERR(qcuefi->mempool); + auxiliary_set_drvdata(aux_dev, qcuefi); + status = qcuefi_set_reference(qcuefi); + if (status) + return status; + + status = efivars_register(&qcuefi->efivars, &qcom_efivar_ops); + if (status) + qcuefi_set_reference(NULL); + return status; } From 2eeb03ad9f42dfece63051be2400af487ddb96d2 Mon Sep 17 00:00:00 2001 From: Saranya R Date: Wed, 12 Feb 2025 22:07:20 +0530 Subject: [PATCH 05/35] soc: qcom: pdr: Fix the potential deadlock When some client process A call pdr_add_lookup() to add the look up for the service and does schedule locator work, later a process B got a new server packet indicating locator is up and call pdr_locator_new_server() which eventually sets pdr->locator_init_complete to true which process A sees and takes list lock and queries domain list but it will timeout due to deadlock as the response will queued to the same qmi->wq and it is ordered workqueue and process B is not able to complete new server request work due to deadlock on list lock. Fix it by removing the unnecessary list iteration as the list iteration is already being done inside locator work, so avoid it here and just call schedule_work() here. Process A Process B process_scheduled_works() pdr_add_lookup() qmi_data_ready_work() process_scheduled_works() pdr_locator_new_server() pdr->locator_init_complete=true; pdr_locator_work() mutex_lock(&pdr->list_lock); pdr_locate_service() mutex_lock(&pdr->list_lock); pdr_get_domain_list() pr_err("PDR: %s get domain list txn wait failed: %d\n", req->service_name, ret); Timeout error log due to deadlock: " PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110 " Thanks to Bjorn and Johan for letting me know that this commit also fixes an audio regression when using the in-kernel pd-mapper as that makes it easier to hit this race. [1] Link: https://lore.kernel.org/lkml/Zqet8iInnDhnxkT9@hovoldconsulting.com/ # [1] Fixes: fbe639b44a82 ("soc: qcom: Introduce Protection Domain Restart helpers") CC: stable@vger.kernel.org Reviewed-by: Bjorn Andersson Tested-by: Bjorn Andersson Tested-by: Johan Hovold Signed-off-by: Saranya R Co-developed-by: Mukesh Ojha Signed-off-by: Mukesh Ojha Link: https://lore.kernel.org/r/20250212163720.1577876-1-mukesh.ojha@oss.qualcomm.com Signed-off-by: Bjorn Andersson --- drivers/soc/qcom/pdr_interface.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/drivers/soc/qcom/pdr_interface.c b/drivers/soc/qcom/pdr_interface.c index 328b6153b2be6..71be378d2e43a 100644 --- a/drivers/soc/qcom/pdr_interface.c +++ b/drivers/soc/qcom/pdr_interface.c @@ -75,7 +75,6 @@ static int pdr_locator_new_server(struct qmi_handle *qmi, { struct pdr_handle *pdr = container_of(qmi, struct pdr_handle, locator_hdl); - struct pdr_service *pds; mutex_lock(&pdr->lock); /* Create a local client port for QMI communication */ @@ -87,12 +86,7 @@ static int pdr_locator_new_server(struct qmi_handle *qmi, mutex_unlock(&pdr->lock); /* Service pending lookup requests */ - mutex_lock(&pdr->list_lock); - list_for_each_entry(pds, &pdr->lookups, node) { - if (pds->need_locator_lookup) - schedule_work(&pdr->locator_work); - } - mutex_unlock(&pdr->list_lock); + schedule_work(&pdr->locator_work); return 0; } From fbf10b86f6057cf79300720da4ea4b77e6708b0d Mon Sep 17 00:00:00 2001 From: Joe Hattori Date: Tue, 24 Dec 2024 12:34:56 +0900 Subject: [PATCH 06/35] firmware: imx-scu: fix OF node leak in .probe() imx_scu_probe() calls of_parse_phandle_with_args(), but does not release the OF node reference obtained by it. Add a of_node_put() call after done with the node. Fixes: f25a066d1a07 ("firmware: imx-scu: Support one TX and one RX") Signed-off-by: Joe Hattori Signed-off-by: Shawn Guo --- drivers/firmware/imx/imx-scu.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/firmware/imx/imx-scu.c b/drivers/firmware/imx/imx-scu.c index 1dd4362ef9a3f..8c28e25ddc8a6 100644 --- a/drivers/firmware/imx/imx-scu.c +++ b/drivers/firmware/imx/imx-scu.c @@ -280,6 +280,7 @@ static int imx_scu_probe(struct platform_device *pdev) return ret; sc_ipc->fast_ipc = of_device_is_compatible(args.np, "fsl,imx8-mu-scu"); + of_node_put(args.np); num_channel = sc_ipc->fast_ipc ? 2 : SCU_MU_CHAN_NUM; for (i = 0; i < num_channel; i++) { From 38f59e0e8bd2b3e1319716e4aeaeb9a6223b006d Mon Sep 17 00:00:00 2001 From: Alexander Stein Date: Tue, 7 Jan 2025 16:03:09 +0100 Subject: [PATCH 07/35] arm64: dts: freescale: tqma8mpql: Fix vqmmc-supply eMMC is supplied by BUCK5 rail. Use the actual regulator instead of a virtual fixed regulator. Fixes: 418d1d840e421 ("arm64: dts: freescale: add initial device tree for TQMa8MPQL with i.MX8MP") Signed-off-by: Alexander Stein Signed-off-by: Shawn Guo --- .../boot/dts/freescale/imx8mp-tqma8mpql.dtsi | 16 ++++------------ 1 file changed, 4 insertions(+), 12 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql.dtsi index 336785a9fba89..3ddc5aaa7c5f0 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpql.dtsi @@ -1,7 +1,8 @@ // SPDX-License-Identifier: GPL-2.0-or-later OR MIT /* - * Copyright 2021-2022 TQ-Systems GmbH - * Author: Alexander Stein + * Copyright 2021-2025 TQ-Systems GmbH , + * D-82229 Seefeld, Germany. + * Author: Alexander Stein */ #include "imx8mp.dtsi" @@ -23,15 +24,6 @@ regulator-max-microvolt = <3300000>; regulator-always-on; }; - - /* e-MMC IO, needed for HS modes */ - reg_vcc1v8: regulator-vcc1v8 { - compatible = "regulator-fixed"; - regulator-name = "VCC1V8"; - regulator-min-microvolt = <1800000>; - regulator-max-microvolt = <1800000>; - regulator-always-on; - }; }; &A53_0 { @@ -197,7 +189,7 @@ no-sd; no-sdio; vmmc-supply = <®_vcc3v3>; - vqmmc-supply = <®_vcc1v8>; + vqmmc-supply = <&buck5_reg>; status = "okay"; }; From 83964a29379cb08929a39172780a4c2992bc7c93 Mon Sep 17 00:00:00 2001 From: Stefan Eichenberger Date: Fri, 10 Jan 2025 16:18:29 +0100 Subject: [PATCH 08/35] ARM: dts: imx6qdl-apalis: Fix poweroff on Apalis iMX6 The current solution for powering off the Apalis iMX6 is not functioning as intended. To resolve this, it is necessary to power off the vgen2_reg, which will also set the POWER_ENABLE_MOCI signal to a low state. This ensures the carrier board is properly informed to initiate its power-off sequence. The new solution uses the regulator-poweroff driver, which will power off the regulator during a system shutdown. Cc: Fixes: 4eb56e26f92e ("ARM: dts: imx6q-apalis: Command pmic to standby for poweroff") Signed-off-by: Stefan Eichenberger Signed-off-by: Shawn Guo --- arch/arm/boot/dts/nxp/imx/imx6qdl-apalis.dtsi | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/arch/arm/boot/dts/nxp/imx/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/nxp/imx/imx6qdl-apalis.dtsi index dffab5aa8b9ca..88be29166c1ae 100644 --- a/arch/arm/boot/dts/nxp/imx/imx6qdl-apalis.dtsi +++ b/arch/arm/boot/dts/nxp/imx/imx6qdl-apalis.dtsi @@ -108,6 +108,11 @@ }; }; + poweroff { + compatible = "regulator-poweroff"; + cpu-supply = <&vgen2_reg>; + }; + reg_module_3v3: regulator-module-3v3 { compatible = "regulator-fixed"; regulator-always-on; @@ -236,10 +241,6 @@ status = "disabled"; }; -&clks { - fsl,pmic-stby-poweroff; -}; - /* Apalis SPI1 */ &ecspi1 { cs-gpios = <&gpio5 25 GPIO_ACTIVE_LOW>; @@ -527,7 +528,6 @@ pmic: pmic@8 { compatible = "fsl,pfuze100"; - fsl,pmic-stby-poweroff; reg = <0x08>; regulators { From 304b0a60d38dc24bfbfc9adc7d254d1cf8f98317 Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Wed, 19 Feb 2025 10:33:02 +0100 Subject: [PATCH 09/35] arm64: dts: rockchip: remove supports-cqe from rk3588 jaguar The sdhci controller supports cqe it seems and necessary code also is in place - in theory. At this point Jaguar and Tiger are the only boards enabling cqe support on the rk3588 and we are seeing reliability issues under load. This can be caused by either a controller-, hw- or driver-issue and definitly needs more investigation to work properly it seems. So disable cqe support on Jaguar for now. Fixes: d1b8b36a2cc5 ("arm64: dts: rockchip: add Theobroma Jaguar SBC") Signed-off-by: Heiko Stuebner Reviewed-by: Quentin Schulz Link: https://lore.kernel.org/r/20250219093303.2320517-1-heiko@sntech.de Signed-off-by: Heiko Stuebner --- arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts b/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts index 90f823b2c2191..7f457ab78015a 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts +++ b/arch/arm64/boot/dts/rockchip/rk3588-jaguar.dts @@ -503,7 +503,6 @@ non-removable; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_cmd &emmc_clk &emmc_data_strobe>; - supports-cqe; vmmc-supply = <&vcc_3v3_s3>; vqmmc-supply = <&vcc_1v8_s3>; status = "okay"; From 3e0711f89e5e7b0c7b2ab4843dc92dcbbdbba777 Mon Sep 17 00:00:00 2001 From: Heiko Stuebner Date: Wed, 19 Feb 2025 10:33:03 +0100 Subject: [PATCH 10/35] arm64: dts: rockchip: remove supports-cqe from rk3588 tiger The sdhci controller supports cqe it seems and necessary code also is in place - in theory. At this point Jaguar and Tiger are the only boards enabling cqe support on the rk3588 and we are seeing reliability issues under load. This can be caused by either a controller-, hw- or driver-issue and definitly needs more investigation to work properly it seems. So disable cqe support on Tiger for now. Fixes: 6173ef24b35b ("arm64: dts: rockchip: add RK3588-Q7 (Tiger) SoM") Signed-off-by: Heiko Stuebner Reviewed-by: Quentin Schulz Link: https://lore.kernel.org/r/20250219093303.2320517-2-heiko@sntech.de Signed-off-by: Heiko Stuebner --- arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi index 81a6a05ce13b6..e8fa449517c27 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588-tiger.dtsi @@ -386,7 +386,6 @@ non-removable; pinctrl-names = "default"; pinctrl-0 = <&emmc_bus8 &emmc_cmd &emmc_clk &emmc_data_strobe>; - supports-cqe; vmmc-supply = <&vcc_3v3_s3>; vqmmc-supply = <&vcc_1v8_s3>; status = "okay"; From cf7139aac463880cbd5c5e999c118fbe91631411 Mon Sep 17 00:00:00 2001 From: Peng Fan Date: Fri, 14 Feb 2025 16:47:51 +0800 Subject: [PATCH 11/35] soc: imx8m: Unregister cpufreq and soc dev in cleanup path Unregister the cpufreq device and soc device when resource unwinding, otherwise there will be warning when do removing test: sysfs: cannot create duplicate filename '/devices/platform/imx-cpufreq-dt' CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.13.0-rc1-next-20241204 Hardware name: NXP i.MX8MPlus EVK board (DT) Fixes: 9cc832d37799 ("soc: imx8m: Probe the SoC driver as platform driver") Cc: Marco Felsch Signed-off-by: Peng Fan Reviewed-by: Marco Felsch Signed-off-by: Shawn Guo --- drivers/soc/imx/soc-imx8m.c | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/drivers/soc/imx/soc-imx8m.c b/drivers/soc/imx/soc-imx8m.c index 8ac7658e3d525..3ed8161d7d28b 100644 --- a/drivers/soc/imx/soc-imx8m.c +++ b/drivers/soc/imx/soc-imx8m.c @@ -192,9 +192,20 @@ static __maybe_unused const struct of_device_id imx8_soc_match[] = { devm_kasprintf((dev), GFP_KERNEL, "%d.%d", ((soc_rev) >> 4) & 0xf, (soc_rev) & 0xf) : \ "unknown" +static void imx8m_unregister_soc(void *data) +{ + soc_device_unregister(data); +} + +static void imx8m_unregister_cpufreq(void *data) +{ + platform_device_unregister(data); +} + static int imx8m_soc_probe(struct platform_device *pdev) { struct soc_device_attribute *soc_dev_attr; + struct platform_device *cpufreq_dev; const struct imx8_soc_data *data; struct device *dev = &pdev->dev; const struct of_device_id *id; @@ -239,11 +250,22 @@ static int imx8m_soc_probe(struct platform_device *pdev) if (IS_ERR(soc_dev)) return PTR_ERR(soc_dev); + ret = devm_add_action(dev, imx8m_unregister_soc, soc_dev); + if (ret) + return ret; + pr_info("SoC: %s revision %s\n", soc_dev_attr->soc_id, soc_dev_attr->revision); - if (IS_ENABLED(CONFIG_ARM_IMX_CPUFREQ_DT)) - platform_device_register_simple("imx-cpufreq-dt", -1, NULL, 0); + if (IS_ENABLED(CONFIG_ARM_IMX_CPUFREQ_DT)) { + cpufreq_dev = platform_device_register_simple("imx-cpufreq-dt", -1, NULL, 0); + if (IS_ERR(cpufreq_dev)) + return dev_err_probe(dev, PTR_ERR(cpufreq_dev), + "Failed to register imx-cpufreq-dev device\n"); + ret = devm_add_action(dev, imx8m_unregister_cpufreq, cpufreq_dev); + if (ret) + return ret; + } return 0; } From b0612fdba9afdce261bfb8684e0cece6f2e2b0bb Mon Sep 17 00:00:00 2001 From: Stefan Eichenberger Date: Mon, 17 Feb 2025 15:56:40 +0100 Subject: [PATCH 12/35] arm64: dts: freescale: imx8mp-verdin-dahlia: add Microphone Jack to sound card The simple-audio-card's microphone widget currently connects to the headphone jack. Routing the microphone input to the microphone jack allows for independent operation of the microphone and headphones. This resolves the following boot-time kernel log message, which indicated a conflict when the microphone and headphone functions were not separated: debugfs: File 'Headphone Jack' in directory 'dapm' already present! Fixes: 874958916844 ("arm64: dts: freescale: verdin-imx8mp: dahlia: add sound card") Signed-off-by: Stefan Eichenberger Reviewed-by: Francesco Dolcini Cc: Signed-off-by: Shawn Guo --- arch/arm64/boot/dts/freescale/imx8mp-verdin-dahlia.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mp-verdin-dahlia.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-verdin-dahlia.dtsi index da8902c5f7e5b..1493319aa748d 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-verdin-dahlia.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mp-verdin-dahlia.dtsi @@ -28,10 +28,10 @@ "Headphone Jack", "HPOUTR", "IN2L", "Line In Jack", "IN2R", "Line In Jack", - "Headphone Jack", "MICBIAS", - "IN1L", "Headphone Jack"; + "Microphone Jack", "MICBIAS", + "IN1L", "Microphone Jack"; simple-audio-card,widgets = - "Microphone", "Headphone Jack", + "Microphone", "Microphone Jack", "Headphone", "Headphone Jack", "Line", "Line In Jack"; From 2c1092823eb03f8508d6769e2f38eef7e1fe62a0 Mon Sep 17 00:00:00 2001 From: Stefan Eichenberger Date: Mon, 17 Feb 2025 15:56:41 +0100 Subject: [PATCH 13/35] arm64: dts: freescale: imx8mm-verdin-dahlia: add Microphone Jack to sound card The simple-audio-card's microphone widget currently connects to the headphone jack. Routing the microphone input to the microphone jack allows for independent operation of the microphone and headphones. This resolves the following boot-time kernel log message, which indicated a conflict when the microphone and headphone functions were not separated: debugfs: File 'Headphone Jack' in directory 'dapm' already present! Fixes: 6a57f224f734 ("arm64: dts: freescale: add initial support for verdin imx8m mini") Signed-off-by: Stefan Eichenberger Reviewed-by: Francesco Dolcini Cc: Signed-off-by: Shawn Guo --- arch/arm64/boot/dts/freescale/imx8mm-verdin-dahlia.dtsi | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/arm64/boot/dts/freescale/imx8mm-verdin-dahlia.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-verdin-dahlia.dtsi index ce20de2598054..3d0b149681310 100644 --- a/arch/arm64/boot/dts/freescale/imx8mm-verdin-dahlia.dtsi +++ b/arch/arm64/boot/dts/freescale/imx8mm-verdin-dahlia.dtsi @@ -16,10 +16,10 @@ "Headphone Jack", "HPOUTR", "IN2L", "Line In Jack", "IN2R", "Line In Jack", - "Headphone Jack", "MICBIAS", - "IN1L", "Headphone Jack"; + "Microphone Jack", "MICBIAS", + "IN1L", "Microphone Jack"; simple-audio-card,widgets = - "Microphone", "Headphone Jack", + "Microphone", "Microphone Jack", "Headphone", "Headphone Jack", "Line", "Line In Jack"; From f00db31d235946853fb430de8c6aa1295efc8353 Mon Sep 17 00:00:00 2001 From: Konrad Dybcio Date: Tue, 25 Feb 2025 14:44:40 +0100 Subject: [PATCH 14/35] Revert "arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu" There are reports that the pagetable walker cache coherency is not a given across the spectrum of SDM845/850 devices, leading to lock-ups and resets. It works fine on some devices (like the Dragonboard 845c, but not so much on the Lenovo Yoga C630). This unfortunately looks like a fluke in firmware development, where likely somewhere in the vast hypervisor stack, a change to accommodate for this was only introduced after the initial software release (which often serves as a baseline for products). Revert the change to avoid additional guesswork around crashes. This reverts commit 6b31a9744b8726c69bb0af290f8475a368a4b805. Reported-by: Dmitry Baryshkov Closes: https://lore.kernel.org/linux-arm-msm/20250215-yoga-dma-coherent-v1-1-2419ee184a81@linaro.org/ Fixes: 6b31a9744b87 ("arm64: dts: qcom: sdm845: Affirm IDR0.CCTW on apps_smmu") Signed-off-by: Konrad Dybcio Link: https://lore.kernel.org/r/20250225-topic-845_smmu_not_coherent-v1-1-98ca9d17471c@oss.qualcomm.com Signed-off-by: Bjorn Andersson --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi index e0ce804bb1a35..d0314cdf0b92f 100644 --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi @@ -5163,7 +5163,6 @@ , , ; - dma-coherent; }; anoc_1_tbu: tbu@150c5000 { From f44fa354a0715577ca32b085f6f60bcf32c748dd Mon Sep 17 00:00:00 2001 From: Stefan Wahren Date: Sat, 1 Feb 2025 12:27:29 +0100 Subject: [PATCH 15/35] ARM: dts: bcm2711: Fix xHCI power-domain During s2idle tests on the Raspberry CM4 the VPU firmware always crashes on xHCI power-domain resume: root@raspberrypi:/sys/power# echo freeze > state [ 70.724347] xhci_suspend finished [ 70.727730] xhci_plat_suspend finished [ 70.755624] bcm2835-power bcm2835-power: Power grafx off [ 70.761127] USB: Set power to 0 [ 74.653040] USB: Failed to set power to 1 (-110) This seems to be caused because of the mixed usage of raspberrypi-power and bcm2835-power at the same time. So avoid the usage of the VPU firmware power-domain driver, which prevents the VPU crash. Fixes: 522c35e08b53 ("ARM: dts: bcm2711: Add BCM2711 xHCI support") Link: https://github.com/raspberrypi/linux/issues/6537 Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/20250201112729.31509-1-wahrenst@gmx.net Signed-off-by: Florian Fainelli --- arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi | 5 ----- arch/arm/boot/dts/broadcom/bcm2711.dtsi | 1 + 2 files changed, 1 insertion(+), 5 deletions(-) diff --git a/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi b/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi index 6bf4241fe3b73..c78ed064d1667 100644 --- a/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi +++ b/arch/arm/boot/dts/broadcom/bcm2711-rpi.dtsi @@ -1,7 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 #include "bcm2835-rpi.dtsi" -#include #include / { @@ -101,7 +100,3 @@ &vchiq { interrupts = ; }; - -&xhci { - power-domains = <&power RPI_POWER_DOMAIN_USB>; -}; diff --git a/arch/arm/boot/dts/broadcom/bcm2711.dtsi b/arch/arm/boot/dts/broadcom/bcm2711.dtsi index e4e42af21ef3a..5eaec6c6a1df3 100644 --- a/arch/arm/boot/dts/broadcom/bcm2711.dtsi +++ b/arch/arm/boot/dts/broadcom/bcm2711.dtsi @@ -610,6 +610,7 @@ #address-cells = <1>; #size-cells = <0>; interrupts = ; + power-domains = <&pm BCM2835_POWER_DOMAIN_USB>; /* DWC2 and this IP block share the same USB PHY, * enabling both at the same time results in lockups. * So keep this node disabled and let the bootloader From 0de09025f161f67c07978c4742e221243d070d41 Mon Sep 17 00:00:00 2001 From: Phil Elwell Date: Sun, 23 Feb 2025 13:56:13 +0100 Subject: [PATCH 16/35] ARM: dts: bcm2711: PL011 UARTs are actually r1p5 The ARM PL011 UART instances in BCM2711 are r1p5 spec, which means they have 32-entry FIFOs. The correct periphid value for this is 0x00341011. Thanks to N Buchwitz for pointing this out. Signed-off-by: Phil Elwell Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/20250223125614.3592-2-wahrenst@gmx.net Fixes: 7dbe8c62ceeb ("ARM: dts: Add minimal Raspberry Pi 4 support") Signed-off-by: Florian Fainelli --- arch/arm/boot/dts/broadcom/bcm2711.dtsi | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/broadcom/bcm2711.dtsi b/arch/arm/boot/dts/broadcom/bcm2711.dtsi index 5eaec6c6a1df3..4fd0732a34d32 100644 --- a/arch/arm/boot/dts/broadcom/bcm2711.dtsi +++ b/arch/arm/boot/dts/broadcom/bcm2711.dtsi @@ -134,7 +134,7 @@ clocks = <&clocks BCM2835_CLOCK_UART>, <&clocks BCM2835_CLOCK_VPU>; clock-names = "uartclk", "apb_pclk"; - arm,primecell-periphid = <0x00241011>; + arm,primecell-periphid = <0x00341011>; status = "disabled"; }; @@ -145,7 +145,7 @@ clocks = <&clocks BCM2835_CLOCK_UART>, <&clocks BCM2835_CLOCK_VPU>; clock-names = "uartclk", "apb_pclk"; - arm,primecell-periphid = <0x00241011>; + arm,primecell-periphid = <0x00341011>; status = "disabled"; }; @@ -156,7 +156,7 @@ clocks = <&clocks BCM2835_CLOCK_UART>, <&clocks BCM2835_CLOCK_VPU>; clock-names = "uartclk", "apb_pclk"; - arm,primecell-periphid = <0x00241011>; + arm,primecell-periphid = <0x00341011>; status = "disabled"; }; @@ -167,7 +167,7 @@ clocks = <&clocks BCM2835_CLOCK_UART>, <&clocks BCM2835_CLOCK_VPU>; clock-names = "uartclk", "apb_pclk"; - arm,primecell-periphid = <0x00241011>; + arm,primecell-periphid = <0x00341011>; status = "disabled"; }; @@ -1178,6 +1178,7 @@ }; &uart0 { + arm,primecell-periphid = <0x00341011>; interrupts = ; }; From 768953614c1c13fdf771be5742f1be573eea8fa4 Mon Sep 17 00:00:00 2001 From: Phil Elwell Date: Sun, 23 Feb 2025 13:56:14 +0100 Subject: [PATCH 17/35] arm64: dts: bcm2712: PL011 UARTs are actually r1p5 The ARM PL011 UART instances in BCM2712 are r1p5 spec, which means they have 32-entry FIFOs. The correct periphid value for this is 0x00341011. Thanks to N Buchwitz for pointing this out. Signed-off-by: Phil Elwell Signed-off-by: Stefan Wahren Link: https://lore.kernel.org/r/20250223125614.3592-3-wahrenst@gmx.net Fixes: faa3381267d0 ("arm64: dts: broadcom: Add minimal support for Raspberry Pi 5") Signed-off-by: Florian Fainelli --- arch/arm64/boot/dts/broadcom/bcm2712.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/broadcom/bcm2712.dtsi b/arch/arm64/boot/dts/broadcom/bcm2712.dtsi index 689c82b7f596a..9e610a89a3378 100644 --- a/arch/arm64/boot/dts/broadcom/bcm2712.dtsi +++ b/arch/arm64/boot/dts/broadcom/bcm2712.dtsi @@ -227,7 +227,7 @@ interrupts = ; clocks = <&clk_uart>, <&clk_vpu>; clock-names = "uartclk", "apb_pclk"; - arm,primecell-periphid = <0x00241011>; + arm,primecell-periphid = <0x00341011>; status = "disabled"; }; From 38f4aa34a5f737ea8588dac320d884cc2e762c03 Mon Sep 17 00:00:00 2001 From: Justin Klaassen Date: Tue, 25 Feb 2025 17:03:58 +0000 Subject: [PATCH 18/35] arm64: dts: rockchip: fix u2phy1_host status for NanoPi R4S The u2phy1_host should always have the same status as usb_host1_ehci and usb_host1_ohci, otherwise the EHCI and OHCI drivers may be initialized for a disabled usb port. Per the NanoPi R4S schematic, the phy-supply for u2phy1_host is set to the vdd_5v regulator. Fixes: db792e9adbf8 ("rockchip: rk3399: Add support for FriendlyARM NanoPi R4S") Cc: stable@vger.kernel.org Signed-off-by: Justin Klaassen Reviewed-by: Dragan Simic Link: https://lore.kernel.org/r/20250225170420.3898-1-justin@tidylabs.net Signed-off-by: Heiko Stuebner --- arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi index b1c9bd0e63ef3..8d94d9f91a5c6 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-nanopi-r4s.dtsi @@ -115,7 +115,7 @@ }; &u2phy1_host { - status = "disabled"; + phy-supply = <&vdd_5v>; }; &uart0 { From 2db7d29c7b1629ced3cbab3de242511eb3c22066 Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Tue, 25 Feb 2025 12:53:29 +0100 Subject: [PATCH 19/35] arm64: dts: rockchip: fix pinmux of UART0 for PX30 Ringneck on Haikou MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit UART0 pinmux by default configures GPIO0_B5 in its UART RTS function for UART0. However, by default on Haikou, it is used as GPIO as UART RTS for UART5. Therefore, let's update UART0 pinmux to not configure the pin in that mode, a later commit will make UART5 request the GPIO pinmux. Fixes: c484cf93f61b ("arm64: dts: rockchip: add PX30-µQ7 (Ringneck) SoM with Haikou baseboard") Cc: stable@vger.kernel.org Signed-off-by: Quentin Schulz Link: https://lore.kernel.org/r/20250225-ringneck-dtbos-v3-1-853a9a6dd597@cherry.de Signed-off-by: Heiko Stuebner --- arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts index eb9470a00e549..6d45a19413ce6 100644 --- a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts +++ b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts @@ -222,6 +222,8 @@ }; &uart0 { + pinctrl-names = "default"; + pinctrl-0 = <&uart0_xfer>; status = "okay"; }; From 55de171bba1b8c0e3dd18b800955ac4b46a63d4b Mon Sep 17 00:00:00 2001 From: Quentin Schulz Date: Tue, 25 Feb 2025 12:53:30 +0100 Subject: [PATCH 20/35] arm64: dts: rockchip: fix pinmux of UART5 for PX30 Ringneck on Haikou UART5 uses GPIO0_B5 as UART RTS but muxed in its GPIO function, therefore UART5 must request this pin to be muxed in that function, so let's do that. Fixes: 5963d97aa780 ("arm64: dts: rockchip: add rs485 support on uart5 of px30-ringneck-haikou") Cc: stable@vger.kernel.org Signed-off-by: Quentin Schulz Link: https://lore.kernel.org/r/20250225-ringneck-dtbos-v3-2-853a9a6dd597@cherry.de Signed-off-by: Heiko Stuebner --- arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts index 6d45a19413ce6..1a59e8b1dc46e 100644 --- a/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts +++ b/arch/arm64/boot/dts/rockchip/px30-ringneck-haikou.dts @@ -194,6 +194,13 @@ <3 RK_PB3 RK_FUNC_GPIO &pcfg_pull_none>; }; }; + + uart { + uart5_rts_pin: uart5-rts-pin { + rockchip,pins = + <0 RK_PB5 RK_FUNC_GPIO &pcfg_pull_none>; + }; + }; }; &pwm0 { @@ -228,6 +235,9 @@ }; &uart5 { + /* Add pinmux for rts-gpios (uart5_rts_pin) */ + pinctrl-names = "default"; + pinctrl-0 = <&uart5_xfer &uart5_rts_pin>; rts-gpios = <&gpio0 RK_PB5 GPIO_ACTIVE_HIGH>; status = "okay"; }; From 43c854c65e47d2f3763345683b06257b4d12e4e3 Mon Sep 17 00:00:00 2001 From: Yao Zi Date: Fri, 28 Feb 2025 16:31:18 +0000 Subject: [PATCH 21/35] arm64: dts: rockchip: Remove undocumented sdmmc property from lubancat-1 Property "supports-sd" isn't documented anywhere and is unnecessary for mainline driver to function. It seems a property used by downstream kernel was brought into mainline. This should be reported by dtbs_check, but mmc-controller-common.yaml defaults additionalProperties to true thus allows it. Remove the property to clean the devicetree up and avoid possible confusion. Fixes: 8d94da58de53 ("arm64: dts: rockchip: Add EmbedFire LubanCat 1") Signed-off-by: Yao Zi Link: https://lore.kernel.org/r/20250228163117.47318-2-ziyao@disroot.org Signed-off-by: Heiko Stuebner --- arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts b/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts index 61dd71c259aac..ddf84c2a19cfa 100644 --- a/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts +++ b/arch/arm64/boot/dts/rockchip/rk3566-lubancat-1.dts @@ -512,7 +512,6 @@ &sdmmc0 { max-frequency = <150000000>; - supports-sd; bus-width = <4>; cap-mmc-highspeed; cap-sd-highspeed; From bd1c959f37f384b477f51572331b0dc828bd009a Mon Sep 17 00:00:00 2001 From: Dragan Simic Date: Sun, 2 Mar 2025 19:48:03 +0100 Subject: [PATCH 22/35] arm64: dts: rockchip: Add avdd HDMI supplies to RockPro64 board dtsi Add missing "avdd-0v9-supply" and "avdd-1v8-supply" properties to the "hdmi" node in the Pine64 RockPro64 board dtsi file. To achieve this, also add the associated "vcca_0v9" regulator that produces the 0.9 V supply, [1][2] which hasn't been defined previously in the board dtsi file. This also eliminates the following warnings from the kernel log: dwhdmi-rockchip ff940000.hdmi: supply avdd-0v9 not found, using dummy regulator dwhdmi-rockchip ff940000.hdmi: supply avdd-1v8 not found, using dummy regulator There are no functional changes to the way board works with these additions, because the "vcc1v8_dvp" and "vcca_0v9" regulators are always enabled, [1][2] but these additions improve the accuracy of hardware description. These changes apply to the both supported hardware revisions of the Pine64 RockPro64, i.e. to the production-run revisions 2.0 and 2.1. [1][2] [1] https://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf [2] https://files.pine64.org/doc/rockpro64/rockpro64_v20-SCH.pdf Fixes: e4f3fb490967 ("arm64: dts: rockchip: add initial dts support for Rockpro64") Cc: stable@vger.kernel.org Suggested-by: Diederik de Haas Signed-off-by: Dragan Simic Tested-by: Diederik de Haas Link: https://lore.kernel.org/r/df3d7e8fe74ed5e727e085b18c395260537bb5ac.1740941097.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner --- arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi index 69a9d61706495..47dc198706c85 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi @@ -227,6 +227,16 @@ vin-supply = <&vcc12v_dcin>; }; + vcca_0v9: regulator-vcca-0v9 { + compatible = "regulator-fixed"; + regulator-name = "vcca_0v9"; + regulator-always-on; + regulator-boot-on; + regulator-min-microvolt = <900000>; + regulator-max-microvolt = <900000>; + vin-supply = <&vcc3v3_sys>; + }; + vdd_log: regulator-vdd-log { compatible = "pwm-regulator"; pwms = <&pwm2 0 25000 1>; @@ -312,6 +322,8 @@ }; &hdmi { + avdd-0v9-supply = <&vcca_0v9>; + avdd-1v8-supply = <&vcc1v8_dvp>; ddc-i2c-bus = <&i2c3>; pinctrl-names = "default"; pinctrl-0 = <&hdmi_cec>; From ffcef3df680c437ca33ff434be18ec24d72907c2 Mon Sep 17 00:00:00 2001 From: Dragan Simic Date: Sun, 2 Mar 2025 19:48:04 +0100 Subject: [PATCH 23/35] arm64: dts: rockchip: Add missing PCIe supplies to RockPro64 board dtsi Add missing "vpcie0v9-supply" and "vpcie1v8-supply" properties to the "pcie0" node in the Pine64 RockPro64 board dtsi file. This eliminates the following warnings from the kernel log: rockchip-pcie f8000000.pcie: supply vpcie1v8 not found, using dummy regulator rockchip-pcie f8000000.pcie: supply vpcie0v9 not found, using dummy regulator These additions improve the accuracy of hardware description of the RockPro64 and, in theory, they should result in no functional changes to the way board works after the changes, because the "vcca_0v9" and "vcca_1v8" regulators are always enabled. [1][2] However, extended reliability testing, performed by Chris, [3] has proven that the age-old issues with some PCI Express cards, when used with a Pine64 RockPro64, are also resolved. Those issues were already mentioned in the commit 43853e843aa6 (arm64: dts: rockchip: Remove unsupported node from the Pinebook Pro dts, 2024-04-01), together with a brief description of the out-of-tree enumeration delay patch that reportedly resolves those issues. In a nutshell, booting a RockPro64 with some PCI Express cards attached to it caused a kernel oops. [4] Symptomatically enough, to the commit author's best knowledge, only the Pine64 RockPro64, out of all RK3399-based boards and devices supported upstream, has been reported to suffer from those PCI Express issues, and only the RockPro64 had some of the PCI Express supplies missing in its DT. Thus, perhaps some weird timing issues exist that caused the "vcca_1v8" always-on regulator, which is part of the RK808 PMIC, to actually not be enabled before the PCI Express is initialized and enumerated on the RockPro64, causing oopses with some PCIe cards, and the aforementioned enumeration delay patch [4] probably acted as just a workaround for the underlying timing issue. Admittedly, the Pine64 RockPro64 is a bit specific board by having a standard PCI Express slot, allowing use of various standard cards, but pretty much standard PCI Express cards have been attached to other RK3399 boards as well, and the commit author is unaware ot such issues reported for them. It's quite hard to be sure that the PCI Express issues are fully resolved by these additions to the DT, without some really extensive and time-consuming testing. However, these additions to the DT can result in good things and improvements anyway, making them perfectly safe from the standpoint of being unable to do any harm or cause some unforeseen regressions. These changes apply to the both supported hardware revisions of the Pine64 RockPro64, i.e. to the production-run revisions 2.0 and 2.1. [1][2] [1] https://files.pine64.org/doc/rockpro64/rockpro64_v21-SCH.pdf [2] https://files.pine64.org/doc/rockpro64/rockpro64_v20-SCH.pdf [3] https://z9.de/hedgedoc/s/nF4d5G7rg#reboot-tests-for-PCIe-improvements [4] https://lore.kernel.org/lkml/20230509153912.515218-1-vincenzopalazzodev@gmail.com/T/#u Fixes: bba821f5479e ("arm64: dts: rockchip: add PCIe nodes on rk3399-rockpro64") Cc: stable@vger.kernel.org Cc: Vincenzo Palazzo Cc: Peter Geis Cc: Bjorn Helgaas Reported-by: Diederik de Haas Tested-by: Chris Vogel Signed-off-by: Dragan Simic Tested-by: Diederik de Haas Link: https://lore.kernel.org/r/b39cfd7490d8194f053bf3971f13a43472d1769e.1740941097.git.dsimic@manjaro.org Signed-off-by: Heiko Stuebner --- arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi | 2 ++ 1 file changed, 2 insertions(+) diff --git a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi index 47dc198706c85..51c6aa26d8285 100644 --- a/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3399-rockpro64.dtsi @@ -673,6 +673,8 @@ num-lanes = <4>; pinctrl-names = "default"; pinctrl-0 = <&pcie_perst>; + vpcie0v9-supply = <&vcca_0v9>; + vpcie1v8-supply = <&vcca_1v8>; vpcie12v-supply = <&vcc12v_dcin>; vpcie3v3-supply = <&vcc3v3_pcie>; status = "okay"; From 98f3ab18a0a55aa1ff2cd6b74bd0c02c8f76f17e Mon Sep 17 00:00:00 2001 From: Arnd Bergmann Date: Wed, 5 Feb 2025 13:11:33 +0100 Subject: [PATCH 24/35] ARM: OMAP1: select CONFIG_GENERIC_IRQ_CHIP When GENERIC_IRQ_CHIP is disabled, OMAP1 kernels fail to link: arm-linux-gnueabi-ld: arch/arm/mach-omap1/irq.o: in function `omap1_init_irq': irq.c:(.init.text+0x1e8): undefined reference to `irq_alloc_generic_chip' arm-linux-gnueabi-ld: irq.c:(.init.text+0x228): undefined reference to `irq_setup_generic_chip' arm-linux-gnueabi-ld: irq.c:(.init.text+0x2a8): undefined reference to `irq_gc_set_wake' arm-linux-gnueabi-ld: irq.c:(.init.text+0x2b0): undefined reference to `irq_gc_mask_set_bit' arm-linux-gnueabi-ld: irq.c:(.init.text+0x2b4): undefined reference to `irq_gc_mask_clr_bit' This has apparently been the case for many years, but I never caught it in randconfig builds until now, as there are dozens of other drivers that also 'select GENERIC_IRQ_CHIP' and statistically there is almost always one of them enabled. Fixes: 55b447744389 ("ARM: OMAP1: Switch to use generic irqchip in preparation for sparse IRQ") Link: https://lore.kernel.org/r/20250205121151.289535-1-arnd@kernel.org Signed-off-by: Arnd Bergmann --- arch/arm/mach-omap1/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap1/Kconfig b/arch/arm/mach-omap1/Kconfig index a643b71e30a35..08ec6bd84ada5 100644 --- a/arch/arm/mach-omap1/Kconfig +++ b/arch/arm/mach-omap1/Kconfig @@ -8,6 +8,7 @@ menuconfig ARCH_OMAP1 select ARCH_OMAP select CLKSRC_MMIO select FORCE_PCI if PCCARD + select GENERIC_IRQ_CHIP select GPIOLIB help Support for older TI OMAP1 (omap7xx, omap15xx or omap16xx) From c24f272ae751a9f54f8816430e7f2d56031892cc Mon Sep 17 00:00:00 2001 From: Phil Elwell Date: Sat, 22 Feb 2025 10:41:13 +0100 Subject: [PATCH 25/35] ARM: dts: bcm2711: Don't mark timer regs unconfigured During upstream process of Raspberry Pi 4 back in 2019 the ARMv7 stubs didn't configured the ARM architectural timer. This firmware issue has been fixed in 2020, which gave users enough time to update their system. So drop this property to allow the use of the vDSO version of clock_gettime. Link: https://github.com/raspberrypi/tools/pull/113 Fixes: 7dbe8c62ceeb ("ARM: dts: Add minimal Raspberry Pi 4 support") Signed-off-by: Phil Elwell Signed-off-by: Stefan Wahren Reviewed-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20250222094113.48198-1-wahrenst@gmx.net Signed-off-by: Florian Fainelli --- arch/arm/boot/dts/broadcom/bcm2711.dtsi | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/boot/dts/broadcom/bcm2711.dtsi b/arch/arm/boot/dts/broadcom/bcm2711.dtsi index e4e42af21ef3a..7cf93fdc676cb 100644 --- a/arch/arm/boot/dts/broadcom/bcm2711.dtsi +++ b/arch/arm/boot/dts/broadcom/bcm2711.dtsi @@ -451,8 +451,6 @@ IRQ_TYPE_LEVEL_LOW)>, ; - /* This only applies to the ARMv7 stub */ - arm,cpu-registers-not-fw-configured; }; cpus: cpus { From 56e12d0c8d395b6e48f128858d4f725c1ded6c95 Mon Sep 17 00:00:00 2001 From: "Chester A. Unal" Date: Mon, 3 Mar 2025 13:06:50 +0000 Subject: [PATCH 26/35] ARM: dts: BCM5301X: Fix switch port labels of ASUS RT-AC5300 After using the device for a while, Tom reports that he initially described the switch port labels incorrectly. Correct them. Reported-by: Tom Brautaset Fixes: 961dedc6b4e4 ("ARM: dts: BCM5301X: Add DT for ASUS RT-AC5300") Signed-off-by: Chester A. Unal Link: https://lore.kernel.org/r/20250303-for-broadcom-fix-rt-ac5300-switch-ports-v1-1-e058856ef4d3@arinc9.com Signed-off-by: Florian Fainelli --- arch/arm/boot/dts/broadcom/bcm47094-asus-rt-ac5300.dts | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/broadcom/bcm47094-asus-rt-ac5300.dts b/arch/arm/boot/dts/broadcom/bcm47094-asus-rt-ac5300.dts index 6c666dc7ad23e..01ec8c03686a6 100644 --- a/arch/arm/boot/dts/broadcom/bcm47094-asus-rt-ac5300.dts +++ b/arch/arm/boot/dts/broadcom/bcm47094-asus-rt-ac5300.dts @@ -126,11 +126,11 @@ ports { port@0 { - label = "lan4"; + label = "wan"; }; port@1 { - label = "lan3"; + label = "lan1"; }; port@2 { @@ -138,11 +138,11 @@ }; port@3 { - label = "lan1"; + label = "lan3"; }; port@4 { - label = "wan"; + label = "lan4"; }; }; }; From 24d4c56dd68906bf55ff8fc2e2d36760f97dce5f Mon Sep 17 00:00:00 2001 From: "Chester A. Unal" Date: Tue, 4 Mar 2025 15:55:36 +0000 Subject: [PATCH 27/35] ARM: dts: BCM5301X: Fix switch port labels of ASUS RT-AC3200 After using the device for a while, Tom reports that he initially described the switch port labels incorrectly. Apparently, ASUS's own firmware also describes them incorrectly. Correct them to what is seen on the chassis. Reported-by: Tom Brautaset Fixes: b116239094d8 ("ARM: dts: BCM5301X: Add DT for ASUS RT-AC3200") Signed-off-by: Chester A. Unal Link: https://lore.kernel.org/r/20250304-for-broadcom-fix-rt-ac3200-switch-ports-v1-1-7e249a19a13e@arinc9.com Signed-off-by: Florian Fainelli --- arch/arm/boot/dts/broadcom/bcm4709-asus-rt-ac3200.dts | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/broadcom/bcm4709-asus-rt-ac3200.dts b/arch/arm/boot/dts/broadcom/bcm4709-asus-rt-ac3200.dts index 53cb0c58f6d05..3da2daee0c849 100644 --- a/arch/arm/boot/dts/broadcom/bcm4709-asus-rt-ac3200.dts +++ b/arch/arm/boot/dts/broadcom/bcm4709-asus-rt-ac3200.dts @@ -124,19 +124,19 @@ }; port@1 { - label = "lan1"; + label = "lan4"; }; port@2 { - label = "lan2"; + label = "lan3"; }; port@3 { - label = "lan3"; + label = "lan2"; }; port@4 { - label = "lan4"; + label = "lan1"; }; }; }; From b36402e4a0772d1b3da06a4f5fbd1cfe4d6f1cc0 Mon Sep 17 00:00:00 2001 From: Jianfeng Liu Date: Fri, 28 Feb 2025 22:33:08 +0800 Subject: [PATCH 28/35] arm64: dts: rockchip: slow down emmc freq for rock 5 itx The current max-frequency 200000000 of emmc is not stable. When doing heavy write there will be I/O Error. After setting max-frequency to 150000000 the emmc is stable under write. Also remove property mmc-hs200-1_8v because we are already running at HS400 mode. Tested with fio command: fio -filename=./test_randread -direct=1 -iodepth 1 -thread \ -rw=randwrite -ioengine=psync -bs=16k -size=1G -numjobs=10 \ -runtime=600 -group_reporting -name=mytest Signed-off-by: Jianfeng Liu Link: https://lore.kernel.org/r/20250228143341.70244-1-liujianfeng1994@gmail.com Signed-off-by: Heiko Stuebner --- arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts index 6d68f70284e45..2a0590209462e 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5-itx.dts @@ -690,10 +690,9 @@ &sdhci { bus-width = <8>; - max-frequency = <200000000>; + max-frequency = <150000000>; mmc-hs400-1_8v; mmc-hs400-enhanced-strobe; - mmc-hs200-1_8v; no-sdio; no-sd; non-removable; From 4fa911d2d4cf7e932461eab929c2799a434be2b0 Mon Sep 17 00:00:00 2001 From: Hector Martin Date: Wed, 6 Nov 2024 08:54:02 +0100 Subject: [PATCH 29/35] MAINTAINERS: Add apple-spi driver & binding files This Apple SPI controller is present on Apple ARM SoCs (t8103/t6000). Splitting this change from the binding/driver commits to avoid merge conflicts with other things touching this section, as usual. Signed-off-by: Hector Martin Signed-off-by: Janne Grunau Link: https://lore.kernel.org/r/20241106-asahi-spi-v5-3-e81a4f3a8e19@jannau.net Signed-off-by: Sven Peter --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 8e0736dc2ee0e..b124b897f6783 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2236,6 +2236,7 @@ F: Documentation/devicetree/bindings/pci/apple,pcie.yaml F: Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml F: Documentation/devicetree/bindings/power/apple* F: Documentation/devicetree/bindings/pwm/apple,s5l-fpwm.yaml +F: Documentation/devicetree/bindings/spi/apple,spi.yaml F: Documentation/devicetree/bindings/watchdog/apple,wdt.yaml F: arch/arm64/boot/dts/apple/ F: drivers/bluetooth/hci_bcm4377.c @@ -2253,6 +2254,7 @@ F: drivers/nvmem/apple-efuses.c F: drivers/pinctrl/pinctrl-apple-gpio.c F: drivers/pwm/pwm-apple.c F: drivers/soc/apple/* +F: drivers/spi/spi-apple.c F: drivers/watchdog/apple_wdt.c F: include/dt-bindings/interrupt-controller/apple-aic.h F: include/dt-bindings/pinctrl/apple.h From 3a0d2facfa645ce2fca794a1105d0634ab722008 Mon Sep 17 00:00:00 2001 From: Neal Gompa Date: Mon, 3 Mar 2025 10:40:10 -0500 Subject: [PATCH 30/35] MAINTAINERS: Add myself (Neal Gompa) as a reviewer for ARM Apple support As a member of the Asahi Linux project, I (Neal) have been involved in reviewing the patches downstream as part of enabling the Fedora Asahi Remix distribution for years and have recently been reviewing patches for upstream submission as well. This formalizes my role as a reviewer for ARM Apple system support patches. Signed-off-by: Neal Gompa Acked-by: Sven Peter Acked-by: Alyssa Rosenzweig Link: https://lore.kernel.org/r/20250303154012.1417088-1-neal@gompa.dev Signed-off-by: Sven Peter --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index b124b897f6783..226991726733a 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2212,6 +2212,7 @@ ARM/APPLE MACHINE SUPPORT M: Sven Peter M: Janne Grunau R: Alyssa Rosenzweig +R: Neal Gompa L: asahi@lists.linux.dev L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers) S: Maintained From 379c590113ce46f605439d4887996c60ab8820cc Mon Sep 17 00:00:00 2001 From: Geert Uytterhoeven Date: Mon, 10 Mar 2025 14:12:20 +0100 Subject: [PATCH 31/35] ARM: shmobile: smp: Enforce shmobile_smp_* alignment When the addresses of the shmobile_smp_mpidr, shmobile_smp_fn, and shmobile_smp_arg variables are not multiples of 4 bytes, secondary CPU bring-up fails: smp: Bringing up secondary CPUs ... CPU1: failed to come online CPU2: failed to come online CPU3: failed to come online smp: Brought up 1 node, 1 CPU Fix this by adding the missing alignment directive. Fixes: 4e960f52fce16a3b ("ARM: shmobile: Move shmobile_smp_{mpidr, fn, arg}[] from .text to .bss") Closes: https://lore.kernel.org/r/CAMuHMdU=QR-JLgEHKWpsr6SbaZRc-Hz9r91JfpP8c3n2G-OjqA@mail.gmail.com Signed-off-by: Geert Uytterhoeven Tested-by: Lad Prabhakar Link: https://lore.kernel.org/c499234d559a0d95ad9472883e46077311051cd8.1741612208.git.geert+renesas@glider.be Cc: stable@vger.kernel.org --- arch/arm/mach-shmobile/headsmp.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-shmobile/headsmp.S b/arch/arm/mach-shmobile/headsmp.S index a956b489b6ea1..2bc7e73a8582d 100644 --- a/arch/arm/mach-shmobile/headsmp.S +++ b/arch/arm/mach-shmobile/headsmp.S @@ -136,6 +136,7 @@ ENDPROC(shmobile_smp_sleep) .long shmobile_smp_arg - 1b .bss + .align 2 .globl shmobile_smp_mpidr shmobile_smp_mpidr: .space NR_CPUS * 4 From 0e2268f88bb27ef14ac3de1bc4df29ff12bb28cb Mon Sep 17 00:00:00 2001 From: Horatiu Vultur Date: Thu, 27 Feb 2025 11:55:02 +0100 Subject: [PATCH 32/35] reset: mchp: sparx5: Fix for lan966x With the blamed commit it seems that lan966x doesn't seem to boot anymore when the internal CPU is used. The reason seems to be the usage of the devm_of_iomap, if we replace this with devm_ioremap, this seems to fix the issue as we use the same region also for other devices. Fixes: 0426a920d6269c ("reset: mchp: sparx5: Map cpu-syscon locally in case of LAN966x") Reviewed-by: Herve Codina Tested-by: Herve Codina Signed-off-by: Horatiu Vultur Reviewed-by: Philipp Zabel Link: https://lore.kernel.org/r/20250227105502.25125-1-horatiu.vultur@microchip.com Signed-off-by: Philipp Zabel --- drivers/reset/reset-microchip-sparx5.c | 19 ++++++++++++++----- 1 file changed, 14 insertions(+), 5 deletions(-) diff --git a/drivers/reset/reset-microchip-sparx5.c b/drivers/reset/reset-microchip-sparx5.c index aa5464be7053b..6d3e75b33260e 100644 --- a/drivers/reset/reset-microchip-sparx5.c +++ b/drivers/reset/reset-microchip-sparx5.c @@ -8,6 +8,7 @@ */ #include #include +#include #include #include #include @@ -72,14 +73,22 @@ static struct regmap *mchp_lan966x_syscon_to_regmap(struct device *dev, struct device_node *syscon_np) { struct regmap_config regmap_config = mchp_lan966x_syscon_regmap_config; - resource_size_t size; + struct resource res; void __iomem *base; + int err; + + err = of_address_to_resource(syscon_np, 0, &res); + if (err) + return ERR_PTR(err); - base = devm_of_iomap(dev, syscon_np, 0, &size); - if (IS_ERR(base)) - return ERR_CAST(base); + /* It is not possible to use devm_of_iomap because this resource is + * shared with other drivers. + */ + base = devm_ioremap(dev, res.start, resource_size(&res)); + if (!base) + return ERR_PTR(-ENOMEM); - regmap_config.max_register = size - 4; + regmap_config.max_register = resource_size(&res) - 4; return devm_regmap_init_mmio(dev, base, ®map_config); } From edcccc6892f65eff5fd3027a13976131dc7fd733 Mon Sep 17 00:00:00 2001 From: Roger Quadros Date: Mon, 10 Mar 2025 15:15:14 +0100 Subject: [PATCH 33/35] memory: omap-gpmc: drop no compatible check We are no longer depending on legacy device trees so drop the no compatible check for NAND and OneNAND nodes. Suggested-by: Rob Herring (Arm) Signed-off-by: Roger Quadros Reviewed-by: Rob Herring (Arm) Link: https://lore.kernel.org/r/20250114-omap-gpmc-drop-no-compatible-check-v1-1-262c8d549732@kernel.org Signed-off-by: Krzysztof Kozlowski Signed-off-by: Arnd Bergmann --- drivers/memory/omap-gpmc.c | 20 -------------------- 1 file changed, 20 deletions(-) diff --git a/drivers/memory/omap-gpmc.c b/drivers/memory/omap-gpmc.c index e2a75a52563f5..53f1888cc84f6 100644 --- a/drivers/memory/omap-gpmc.c +++ b/drivers/memory/omap-gpmc.c @@ -2226,26 +2226,6 @@ static int gpmc_probe_generic_child(struct platform_device *pdev, goto err; } - if (of_node_name_eq(child, "nand")) { - /* Warn about older DT blobs with no compatible property */ - if (!of_property_read_bool(child, "compatible")) { - dev_warn(&pdev->dev, - "Incompatible NAND node: missing compatible"); - ret = -EINVAL; - goto err; - } - } - - if (of_node_name_eq(child, "onenand")) { - /* Warn about older DT blobs with no compatible property */ - if (!of_property_read_bool(child, "compatible")) { - dev_warn(&pdev->dev, - "Incompatible OneNAND node: missing compatible"); - ret = -EINVAL; - goto err; - } - } - if (of_match_node(omap_nand_ids, child)) { /* NAND specific setup */ val = 8; From 262666c04be6afa8f15b6c318596b54c37499cda Mon Sep 17 00:00:00 2001 From: Huisong Li Date: Fri, 14 Mar 2025 18:01:43 +0800 Subject: [PATCH 34/35] soc: hisilicon: kunpeng_hccs: Fix incorrect string assembly String assembly should use sysfs_emit_at() instead of sysfs_emit(). Fixes: 23fe8112a231 ("soc: hisilicon: kunpeng_hccs: Add used HCCS types sysfs") Reviewed-by: Jonathan Cameron Signed-off-by: Huisong Li Link: https://lore.kernel.org/r/20250314100143.3377268-1-lihuisong@huawei.com Signed-off-by: Arnd Bergmann --- drivers/soc/hisilicon/kunpeng_hccs.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/soc/hisilicon/kunpeng_hccs.c b/drivers/soc/hisilicon/kunpeng_hccs.c index 8aa8dec14911c..444a8f59b7da7 100644 --- a/drivers/soc/hisilicon/kunpeng_hccs.c +++ b/drivers/soc/hisilicon/kunpeng_hccs.c @@ -1539,8 +1539,8 @@ static ssize_t used_types_show(struct kobject *kobj, u16 i; for (i = 0; i < hdev->used_type_num - 1; i++) - len += sysfs_emit(&buf[len], "%s ", hdev->type_name_maps[i].name); - len += sysfs_emit(&buf[len], "%s\n", hdev->type_name_maps[i].name); + len += sysfs_emit_at(buf, len, "%s ", hdev->type_name_maps[i].name); + len += sysfs_emit_at(buf, len, "%s\n", hdev->type_name_maps[i].name); return len; } From 45d5fe1c53baaed1fb3043f45d1e15ebb4bbe86a Mon Sep 17 00:00:00 2001 From: David Lechner Date: Mon, 1 Apr 2024 10:09:46 -0500 Subject: [PATCH 35/35] ARM: davinci: da850: fix selecting ARCH_DAVINCI_DA8XX Chips in the DA850 family need to have ARCH_DAVINCI_DA8XX to be selected in order to enable some peripheral drivers. This was accidentally removed in a previous commit. Fixes: dec85a95167a ("ARM: davinci: clean up platform support") Signed-off-by: David Lechner Acked-by: Bartosz Golaszewski Signed-off-by: Arnd Bergmann --- arch/arm/mach-davinci/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-davinci/Kconfig b/arch/arm/mach-davinci/Kconfig index 2a8a9fe46586d..3fa15f3422409 100644 --- a/arch/arm/mach-davinci/Kconfig +++ b/arch/arm/mach-davinci/Kconfig @@ -27,6 +27,7 @@ config ARCH_DAVINCI_DA830 config ARCH_DAVINCI_DA850 bool "DA850/OMAP-L138/AM18x based system" + select ARCH_DAVINCI_DA8XX select DAVINCI_CP_INTC config ARCH_DAVINCI_DA8XX