* Re: [PATCH v9 02/12] reset: Add Realtek basic reset support
From: Philipp Zabel @ 2026-06-24 13:02 UTC (permalink / raw)
To: Yu-Chun Lin, mturquette, sboyd, robh, krzk+dt, conor+dt, cylee12,
afaerber, jyanchou, bmasney
Cc: devicetree, linux-clk, linux-kernel, linux-arm-kernel,
linux-realtek-soc, james.tai, cy.huang, stanley_chang
In-Reply-To: <20260624112940.3475605-3-eleanor.lin@realtek.com>
On Mi, 2026-06-24 at 19:29 +0800, Yu-Chun Lin wrote:
> From: Cheng-Yu Lee <cylee12@realtek.com>
>
> Define the reset operations backed by a regmap-based register interface
> and prepare the reset controller to be registered through the reset
> framework.
>
> Since the reset controllers on Realtek SoCs often share the same register
> space with the clock controllers, this common framework is designed to
> extract the regmap and device tree node from the parent device
> (e.g., an auxiliary device parent).
>
> Signed-off-by: Cheng-Yu Lee <cylee12@realtek.com>
> Co-developed-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> Signed-off-by: Yu-Chun Lin <eleanor.lin@realtek.com>
> ---
> Changes in v8:
> - Rename common.[ch] to reset-rtk-common.[ch].
> ---
> MAINTAINERS | 1 +
> drivers/reset/Kconfig | 1 +
> drivers/reset/Makefile | 1 +
> drivers/reset/realtek/Kconfig | 8 +++
> drivers/reset/realtek/Makefile | 2 +
> drivers/reset/realtek/reset-rtk-common.c | 90 ++++++++++++++++++++++++
> drivers/reset/realtek/reset-rtk-common.h | 29 ++++++++
> 7 files changed, 132 insertions(+)
> create mode 100644 drivers/reset/realtek/Kconfig
> create mode 100644 drivers/reset/realtek/Makefile
> create mode 100644 drivers/reset/realtek/reset-rtk-common.c
> create mode 100644 drivers/reset/realtek/reset-rtk-common.h
>
[...]
> diff --git a/drivers/reset/realtek/reset-rtk-common.c b/drivers/reset/realtek/reset-rtk-common.c
> new file mode 100644
> index 000000000000..75b27cb2a208
> --- /dev/null
> +++ b/drivers/reset/realtek/reset-rtk-common.c
> @@ -0,0 +1,90 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (C) 2019-2026 Realtek Semiconductor Corporation
> + */
> +
> +#include <linux/device.h>
> +#include <linux/export.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/regmap.h>
> +#include "reset-rtk-common.h"
> +
> +static inline struct rtk_reset_data *to_rtk_reset_controller(struct reset_controller_dev *r)
> +{
> + return container_of(r, struct rtk_reset_data, rcdev);
> +}
> +
> +static inline const struct rtk_reset_desc *rtk_reset_get_desc(struct rtk_reset_data *data,
> + unsigned long idx)
> +{
> + return &data->descs[idx];
> +}
> +
> +static int rtk_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> + const struct rtk_reset_desc *desc;
> + u32 mask, val;
> +
> + desc = rtk_reset_get_desc(data, idx);
> + mask = desc->write_en ? (0x3U << desc->bit) : BIT(desc->bit);
> + val = desc->write_en ? (0x2U << desc->bit) : 0;
> +
> + return regmap_update_bits(data->regmap, desc->ofs, mask, val);
> +}
> +
> +static int rtk_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> + const struct rtk_reset_desc *desc;
> + u32 mask, val;
> +
> + desc = rtk_reset_get_desc(data, idx);
> + mask = desc->write_en ? (0x3U << desc->bit) : BIT(desc->bit);
> + val = mask;
> +
> + return regmap_update_bits(data->regmap, desc->ofs, mask, val);
You can use regmap_set_bits() here.
> +}
> +
> +static int rtk_reset_status(struct reset_controller_dev *rcdev,
> + unsigned long idx)
> +{
> + struct rtk_reset_data *data = to_rtk_reset_controller(rcdev);
> + const struct rtk_reset_desc *desc;
> + u32 val;
unsigned int val;
> + int ret;
> +
> + desc = rtk_reset_get_desc(data, idx);
> + ret = regmap_read(data->regmap, desc->ofs, &val);
> + if (ret)
> + return ret;
> +
> + return !((val >> desc->bit) & 1);
> +}
> +
> +static const struct reset_control_ops rtk_reset_ops = {
> + .assert = rtk_reset_assert,
> + .deassert = rtk_reset_deassert,
> + .status = rtk_reset_status,
> +};
> +
> +/* The caller must initialize data->descs, data->rcdev.nr_resets and
> + * data->rcdev.owner before calling rtk_reset_controller_add().
> + */
> +int rtk_reset_controller_add(struct device *dev,
> + struct rtk_reset_data *data)
> +{
> + data->regmap = dev_get_platdata(dev);
> + data->rcdev.ops = &rtk_reset_ops;
> + data->rcdev.dev = dev;
> + data->rcdev.of_node = dev->parent->of_node;
This split rcdev initialization is more hassle than it is worth.
Please just export rtk_reset_ops and duplicate the
regmap/ops/dev/of_node assignment in the probe functions.
Alternatively, consolidate the probe function and export it from here.
regards
Philipp
^ permalink raw reply
* [PATCH v5 3/3] arm64: dts: qcom: Add Vicharak Axon Mini
From: Ajit Singh @ 2026-06-24 12:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio
Cc: Dmitry Baryshkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Ajit Singh
In-Reply-To: <20260624125443.18729-1-blfizzyy@gmail.com>
Add DTS for the Vicharak Axon Mini board based on the Qualcomm
QCS6490 SoC.
This adds debug UART, eMMC, UFS, SDIO WLAN, USB 2.0 host, PCIe
support along with regulators.
The UFS ICE block is kept disabled because enabling it currently causes
an SError during qcom_ice_create() on this board. UFS works without ICE.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Ajit Singh <blfizzyy@gmail.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../dts/qcom/qcs6490-vicharak-axon-mini.dts | 1014 +++++++++++++++++
2 files changed, 1015 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/qcs6490-vicharak-axon-mini.dts
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index f80b5d9cf1e8..d8d04dc88e08 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -146,6 +146,7 @@ qcs6490-rb3gen2-industrial-mezzanine-dtbs := qcs6490-rb3gen2.dtb qcs6490-rb3gen2
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-industrial-mezzanine.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2-vision-mezzanine.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs6490-thundercomm-rubikpi3.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs6490-vicharak-axon-mini.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcs6490-vicharak-axon-mini.dts b/arch/arm64/boot/dts/qcom/qcs6490-vicharak-axon-mini.dts
new file mode 100644
index 000000000000..4f2e0109f49b
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs6490-vicharak-axon-mini.dts
@@ -0,0 +1,1014 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2026 Vicharak Computers Pvt. Ltd.
+ */
+
+/dts-v1/;
+
+/* PM7250B is configured to use SID8/9 */
+#define PM7250B_SID 8
+#define PM7250B_SID1 9
+
+#include <dt-bindings/iio/qcom,spmi-adc7-pmk8350.h>
+#include <dt-bindings/iio/qcom,spmi-adc7-pm7325.h>
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/pinctrl/qcom,pmic-gpio.h>
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+
+#include "kodiak.dtsi"
+#include "pm7250b.dtsi"
+#include "pm7325.dtsi"
+#include "pm8350c.dtsi"
+#include "pmk8350.dtsi"
+
+/delete-node/ &adsp_mem;
+/delete-node/ &cdsp_mem;
+/delete-node/ &ipa_fw_mem;
+/delete-node/ &mpss_mem;
+/delete-node/ &remoteproc_mpss;
+/delete-node/ &remoteproc_wpss;
+/delete-node/ &rmtfs_mem;
+/delete-node/ &video_mem;
+/delete-node/ &wifi;
+/delete-node/ &wlan_ce_mem;
+/delete-node/ &wlan_fw_mem;
+/delete-node/ &wpss_mem;
+/delete-node/ &xbl_mem;
+
+/ {
+ model = "Vicharak Axon Mini";
+ compatible = "vicharak,axon-mini", "qcom,qcm6490";
+ chassis-type = "embedded";
+
+ aliases {
+ serial0 = &uart5;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ pinctrl-0 = <&user_leds>;
+ pinctrl-names = "default";
+
+ user-led {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_INDICATOR;
+ gpios = <&tlmm 19 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "default-on";
+ default-state = "on";
+ panic-indicator;
+ retain-state-suspended;
+ };
+
+ status-led {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_INDICATOR;
+ gpios = <&tlmm 55 GPIO_ACTIVE_HIGH>;
+ linux,default-trigger = "heartbeat";
+ default-state = "on";
+ retain-state-suspended;
+ };
+ };
+
+ reserved-memory {
+ xbl_mem: xbl@80700000 {
+ reg = <0x0 0x80700000 0x0 0x100000>;
+ no-map;
+ };
+
+ cdsp_secure_heap_mem: cdsp-secure-heap@81800000 {
+ reg = <0x0 0x81800000 0x0 0x1e00000>;
+ no-map;
+ };
+
+ camera_mem: camera@84300000 {
+ reg = <0x0 0x84300000 0x0 0x500000>;
+ no-map;
+ };
+
+ wpss_mem: wpss@84800000 {
+ reg = <0x0 0x84800000 0x0 0x1900000>;
+ no-map;
+ };
+
+ adsp_mem: adsp@86100000 {
+ reg = <0x0 0x86100000 0x0 0x2800000>;
+ no-map;
+ };
+
+ cdsp_mem: cdsp@88900000 {
+ reg = <0x0 0x88900000 0x0 0x1e00000>;
+ no-map;
+ };
+
+ video_mem: video@8a700000 {
+ reg = <0x0 0x8a700000 0x0 0x700000>;
+ no-map;
+ };
+
+ cvp_mem: cvp@8ae00000 {
+ reg = <0x0 0x8ae00000 0x0 0x500000>;
+ no-map;
+ };
+
+ ipa_fw_mem: ipa-fw@8b300000 {
+ reg = <0x0 0x8b300000 0x0 0x10000>;
+ no-map;
+ };
+
+ ipa_gsi_mem: ipa-gsi@8b310000 {
+ reg = <0x0 0x8b310000 0x0 0xa000>;
+ no-map;
+ };
+
+ gpu_microcode_mem: gpu-microcode@8b31a000 {
+ reg = <0x0 0x8b31a000 0x0 0x2000>;
+ no-map;
+ };
+
+ tz_stat_mem: tz-stat@c0000000 {
+ reg = <0x0 0xc0000000 0x0 0x100000>;
+ no-map;
+ };
+
+ tags_mem: tags@c0100000 {
+ reg = <0x0 0xc0100000 0x0 0x1200000>;
+ no-map;
+ };
+
+ qtee_mem: qtee@c1300000 {
+ reg = <0x0 0xc1300000 0x0 0x500000>;
+ no-map;
+ };
+
+ trusted_apps_mem: trusted-apps@c1800000 {
+ reg = <0x0 0xc1800000 0x0 0x1c00000>;
+ no-map;
+ };
+
+ debug_vm_mem: debug-vm@d0600000 {
+ reg = <0x0 0xd0600000 0x0 0x100000>;
+ no-map;
+ };
+ };
+
+ thermal-zones {
+ chg-skin-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pm7250b_adc_tm 0>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ conn-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pm7250b_adc_tm 1>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ quiet-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 1>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ sdm-skin-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 3>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+
+ xo-thermal {
+ polling-delay-passive = <0>;
+
+ thermal-sensors = <&pmk8350_adc_tm 0>;
+
+ trips {
+ active-config0 {
+ temperature = <125000>;
+ hysteresis = <1000>;
+ type = "passive";
+ };
+ };
+ };
+ };
+
+ vcc_5v0: regulator-vcc-5v-peri {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_5v0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+
+ vin-supply = <&vph_pwr>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vph_pwr: regulator-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vcc_5v0_usb2_0: regulator-vcc-5v0-usb2-0 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_5v0_usb2_0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+
+ vin-supply = <&vcc_5v0>;
+
+ gpio = <&tlmm 117 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&vcc5v0_usb2_0_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vcc_pcie1_3v3: regulator-vcc-pcie1-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_pcie1_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ vin-supply = <&vcc_5v0>;
+
+ gpio = <&tlmm 115 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&vcc_pcie1_3v3_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ vcc_pcie0_dsi_3v3: regulator-vcc-pcie0-dsi-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc_pcie0_dsi_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ vin-supply = <&vcc_5v0>;
+
+ gpio = <&tlmm 114 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&vcc_pcie0_dsi_3v3_en>;
+ pinctrl-names = "default";
+
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ wlan_pwrseq: wlan-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+
+ pinctrl-0 = <&wl_enable_h>;
+ pinctrl-names = "default";
+
+ reset-gpios = <&tlmm 84 GPIO_ACTIVE_LOW>;
+ post-power-on-delay-ms = <200>;
+ power-off-delay-us = <20000>;
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pm7325-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s3-supply = <&vph_pwr>;
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ vdd-s6-supply = <&vph_pwr>;
+ vdd-s7-supply = <&vph_pwr>;
+ vdd-s8-supply = <&vph_pwr>;
+ vdd-l1-l4-l12-l15-supply = <&vreg_s7b_0p972>;
+ vdd-l2-l7-supply = <&vreg_bob_3p296>;
+ vdd-l6-l9-l10-supply = <&vreg_s8b_1p272>;
+ vdd-l8-supply = <&vreg_s7b_0p972>;
+ vdd-l11-l17-l18-l19-supply = <&vreg_s1b_1p872>;
+ vdd-l13-supply = <&vreg_s7b_0p972>;
+ vdd-l14-l16-supply = <&vreg_s8b_1p272>;
+
+ vreg_s1b_1p872: smps1 {
+ regulator-name = "vreg_s1b_1p872";
+ regulator-min-microvolt = <1840000>;
+ regulator-max-microvolt = <2040000>;
+ };
+
+ vreg_s7b_0p972: smps7 {
+ regulator-name = "vreg_s7b_0p972";
+ regulator-min-microvolt = <535000>;
+ regulator-max-microvolt = <1120000>;
+ };
+
+ vreg_s8b_1p272: smps8 {
+ regulator-name = "vreg_s8b_1p272";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1500000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_RET>;
+ };
+
+ vreg_l1b_0p912: ldo1 {
+ regulator-name = "vreg_l1b_0p912";
+ regulator-min-microvolt = <825000>;
+ regulator-max-microvolt = <925000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2b_3p072: ldo2 {
+ regulator-name = "vreg_l2b_3p072";
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3b_0p504: ldo3 {
+ regulator-name = "vreg_l3b_0p504";
+ regulator-min-microvolt = <312000>;
+ regulator-max-microvolt = <650000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6b_1p2: ldo6 {
+ regulator-name = "vreg_l6b_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1260000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7b_2p96: ldo7 {
+ regulator-name = "vreg_l7b_2p96";
+ regulator-min-microvolt = <2960000>;
+ regulator-max-microvolt = <2960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8b_0p904: ldo8 {
+ regulator-name = "vreg_l8b_0p904";
+ regulator-min-microvolt = <870000>;
+ regulator-max-microvolt = <970000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9b_1p2: ldo9 {
+ regulator-name = "vreg_l9b_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11b_1p504: ldo11 {
+ regulator-name = "vreg_l11b_1p504";
+ regulator-min-microvolt = <1776000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12b_0p751: ldo12 {
+ regulator-name = "vreg_l12b_0p751";
+ regulator-min-microvolt = <751000>;
+ regulator-max-microvolt = <824000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l13b_0p53: ldo13 {
+ regulator-name = "vreg_l13b_0p53";
+ regulator-min-microvolt = <530000>;
+ regulator-max-microvolt = <824000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l14b_1p08: ldo14 {
+ regulator-name = "vreg_l14b_1p08";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1304000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l15b_0p765: ldo15 {
+ regulator-name = "vreg_l15b_0p765";
+ regulator-min-microvolt = <765000>;
+ regulator-max-microvolt = <1020000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l16b_1p1: ldo16 {
+ regulator-name = "vreg_l16b_1p1";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l17b_1p7: ldo17 {
+ regulator-name = "vreg_l17b_1p7";
+ regulator-min-microvolt = <1700000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l18b_1p8: ldo18 {
+ regulator-name = "vreg_l18b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l19b_1p8: ldo19 {
+ regulator-name = "vreg_l19b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pm8350c-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s3-supply = <&vph_pwr>;
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ vdd-s6-supply = <&vph_pwr>;
+ vdd-s7-supply = <&vph_pwr>;
+ vdd-s8-supply = <&vph_pwr>;
+ vdd-s9-supply = <&vph_pwr>;
+ vdd-s10-supply = <&vph_pwr>;
+ vdd-l1-l12-supply = <&vreg_s1b_1p872>;
+ vdd-l2-l8-supply = <&vreg_s1b_1p872>;
+ vdd-l3-l4-l5-l7-l13-supply = <&vreg_bob_3p296>;
+ vdd-l6-l9-l11-supply = <&vreg_bob_3p296>;
+ vdd-l10-supply = <&vreg_s7b_0p972>;
+ vdd-bob-supply = <&vph_pwr>;
+
+ vreg_s1c_2p19: smps1 {
+ regulator-name = "vreg_s1c_2p19";
+ regulator-min-microvolt = <2200000>;
+ regulator-max-microvolt = <2208000>;
+ };
+
+ vreg_s9c_1p084: smps9 {
+ regulator-name = "vreg_s9c_1p084";
+ regulator-min-microvolt = <1010000>;
+ regulator-max-microvolt = <1170000>;
+ };
+
+ vreg_l1c_1p8: ldo1 {
+ regulator-name = "vreg_l1c_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1980000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2c_1p62: ldo2 {
+ regulator-name = "vreg_l2c_1p62";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <1976000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3c_2p8: ldo3 {
+ regulator-name = "vreg_l3c_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3540000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4c_1p62: ldo4 {
+ regulator-name = "vreg_l4c_1p62";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5c_1p62: ldo5 {
+ regulator-name = "vreg_l5c_1p62";
+ regulator-min-microvolt = <1620000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l6c_2p96: ldo6 {
+ regulator-name = "vreg_l6c_2p96";
+ regulator-min-microvolt = <1650000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7c_3p0: ldo7 {
+ regulator-name = "vreg_l7c_3p0";
+ regulator-min-microvolt = <3000000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l8c_1p62: ldo8 {
+ regulator-name = "vreg_l8c_1p62";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l9c_2p96: ldo9 {
+ regulator-name = "vreg_l9c_2p96";
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l10c_0p88: ldo10 {
+ regulator-name = "vreg_l10c_0p88";
+ regulator-min-microvolt = <720000>;
+ regulator-max-microvolt = <1050000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l11c_2p8: ldo11 {
+ regulator-name = "vreg_l11c_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l12c_1p8: ldo12 {
+ regulator-name = "vreg_l12c_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+
+ /*
+ * VREG_L12C_1P8 supplies the Ampak WLAN/BT module
+ * VDDIO and the external 32.768 kHz oscillator.
+ */
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vreg_l13c_2p7: ldo13 {
+ regulator-name = "vreg_l13c_2p7";
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3544000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_bob_3p296: bob {
+ regulator-name = "vreg_bob_3p296";
+ regulator-min-microvolt = <3008000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+};
+
+&gcc {
+ protected-clocks = <GCC_CFG_NOC_LPASS_CLK>,
+ <GCC_MSS_CFG_AHB_CLK>,
+ <GCC_MSS_GPLL0_MAIN_DIV_CLK_SRC>,
+ <GCC_MSS_OFFLINE_AXI_CLK>,
+ <GCC_MSS_Q6SS_BOOT_CLK_SRC>,
+ <GCC_MSS_Q6_MEMNOC_AXI_CLK>,
+ <GCC_MSS_SNOC_AXI_CLK>,
+ <GCC_QSPI_CNOC_PERIPH_AHB_CLK>,
+ <GCC_QSPI_CORE_CLK>,
+ <GCC_QSPI_CORE_CLK_SRC>,
+ <GCC_SEC_CTRL_CLK_SRC>,
+ <GCC_WPSS_AHB_BDG_MST_CLK>,
+ <GCC_WPSS_AHB_CLK>,
+ <GCC_WPSS_RSCP_CLK>;
+};
+
+&gpi_dma0 {
+ status = "okay";
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/qcs6490/a660_zap.mbn";
+};
+
+&ice {
+ status = "disabled";
+};
+
+&pcie0 {
+ perst-gpios = <&tlmm 87 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 89 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&pcie0_clkreq_n>, <&pcie0_reset_n>, <&pcie0_wake_n>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie0_phy {
+ vdda-phy-supply = <&vreg_l10c_0p88>;
+ vdda-pll-supply = <&vreg_l6b_1p2>;
+
+ status = "okay";
+};
+
+&pcie1 {
+ perst-gpios = <&tlmm 2 GPIO_ACTIVE_LOW>;
+ wake-gpios = <&tlmm 3 GPIO_ACTIVE_HIGH>;
+
+ pinctrl-0 = <&pcie1_reset_n>, <&pcie1_wake_n>, <&pcie1_clkreq_n>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie1_phy {
+ vdda-phy-supply = <&vreg_l10c_0p88>;
+ vdda-pll-supply = <&vreg_l6b_1p2>;
+
+ status = "okay";
+};
+
+&pm7250b_adc {
+ channel@4d {
+ reg = <ADC5_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "charger_skin_therm";
+ };
+
+ channel@4f {
+ reg = <ADC5_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "conn_therm";
+ };
+};
+
+&pm7250b_adc_tm {
+ status = "okay";
+
+ charger-skin-therm@0 {
+ reg = <0>;
+ io-channels = <&pm7250b_adc ADC5_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ conn-therm@1 {
+ reg = <1>;
+ io-channels = <&pm7250b_adc ADC5_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+};
+
+&pm7325_temp_alarm {
+ io-channels = <&pmk8350_vadc PM7325_ADC7_DIE_TEMP>;
+ io-channel-names = "thermal";
+};
+
+&pmk8350_adc_tm {
+ status = "okay";
+
+ xo-therm@0 {
+ reg = <0>;
+ io-channels = <&pmk8350_vadc PMK8350_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ quiet-therm@1 {
+ reg = <1>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+
+ sdm-skin-therm@3 {
+ reg = <3>;
+ io-channels = <&pmk8350_vadc PM7325_ADC7_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time-us = <200>;
+ };
+};
+
+&pmk8350_rtc {
+ status = "okay";
+};
+
+&pmk8350_vadc {
+ status = "okay";
+
+ channel@3 {
+ reg = <PMK8350_ADC7_DIE_TEMP>;
+ qcom,pre-scaling = <1 1>;
+ label = "pmk8350_die_therm";
+ };
+
+ channel@44 {
+ reg = <PMK8350_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pmk8350_xo_therm";
+ };
+
+ channel@103 {
+ reg = <PM7325_ADC7_DIE_TEMP>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_die_therm";
+ };
+
+ channel@144 {
+ reg = <PM7325_ADC7_AMUX_THM1_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_quiet_therm";
+ };
+
+ channel@146 {
+ reg = <PM7325_ADC7_AMUX_THM3_100K_PU>;
+ qcom,ratiometric;
+ qcom,hw-settle-time = <200>;
+ qcom,pre-scaling = <1 1>;
+ label = "pm7325_sdm_skin_therm";
+ };
+};
+
+&pon_pwrkey {
+ status = "okay";
+};
+
+&pon_resin {
+ linux,code = <KEY_RESTART>;
+
+ status = "okay";
+};
+
+&qupv3_id_0 {
+ firmware-name = "qcom/qcs6490/qupv3fw.elf";
+
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ firmware-name = "qcom/qcs6490/qupv3fw.elf";
+
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/qcs6490/adsp.mbn";
+
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/qcs6490/cdsp.mbn";
+
+ status = "okay";
+};
+
+&sdhc_1 {
+ vqmmc-supply = <&vreg_l19b_1p8>;
+ vmmc-supply = <&vreg_bob_3p296>;
+
+ non-removable;
+ no-sd;
+ no-sdio;
+
+ status = "okay";
+};
+
+&sdhc_2 {
+ vqmmc-supply = <&vreg_l2c_1p62>;
+ vmmc-supply = <&vreg_l6c_2p96>;
+
+ mmc-pwrseq = <&wlan_pwrseq>;
+
+ bus-width = <4>;
+ non-removable;
+ no-sd;
+ no-mmc;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ max-frequency = <100000000>;
+
+ status = "okay";
+};
+
+&tlmm {
+ gpio-reserved-ranges = <48 4>; /* NFC */
+
+ pcie0_reset_n: pcie0-reset-n-state {
+ pins = "gpio87";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ pcie0_wake_n: pcie0-wake-n-state {
+ pins = "gpio89";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ pcie1_reset_n: pcie1-reset-n-state {
+ pins = "gpio2";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ pcie1_wake_n: pcie1-wake-n-state {
+ pins = "gpio3";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-pull-up;
+ };
+
+ user_leds: user-led-state {
+ pins = "gpio19", "gpio55";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ vcc5v0_usb2_0_en: vcc-5v0-usb2-0-en-state {
+ pins = "gpio117";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ vcc_pcie0_dsi_3v3_en: vcc-pcie0-dsi-3v3-en-state {
+ pins = "gpio114";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ vcc_pcie1_3v3_en: vcc-pcie1-3v3-en-state {
+ pins = "gpio115";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ wl_enable_h: wl-enable-h-state {
+ pins = "gpio84";
+ function = "gpio";
+ drive-strength = <8>;
+ bias-disable;
+ };
+};
+
+&uart5 {
+ status = "okay";
+};
+
+&ufs_mem_hc {
+ /delete-property/ qcom,ice;
+
+ reset-gpios = <&tlmm 175 GPIO_ACTIVE_LOW>;
+ vcc-supply = <&vreg_l7b_2p96>;
+ vcc-max-microamp = <800000>;
+ vccq-supply = <&vreg_l9b_1p2>;
+ vccq-max-microamp = <900000>;
+ vccq2-supply = <&vreg_l9b_1p2>;
+ vccq2-max-microamp = <900000>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l10c_0p88>;
+ vdda-pll-supply = <&vreg_l6b_1p2>;
+
+ status = "okay";
+};
+
+&usb_2 {
+ /* Routed to an onboard USB hub for two USB-A host ports. */
+ dr_mode = "host";
+
+ status = "okay";
+};
+
+&usb_2_hsphy {
+ vdda-pll-supply = <&vreg_l10c_0p88>;
+ vdda33-supply = <&vreg_l2b_3p072>;
+ vdda18-supply = <&vreg_l1c_1p8>;
+
+ status = "okay";
+};
+
+&venus {
+ status = "okay";
+};
+
+/* pinctrl */
+&pcie0_clkreq_n {
+ bias-pull-up;
+ drive-strength = <2>;
+};
+
+&pcie1_clkreq_n {
+ bias-pull-up;
+ drive-strength = <2>;
+};
+
+&sdc1_clk {
+ bias-disable;
+ drive-strength = <16>;
+};
+
+&sdc1_cmd {
+ bias-pull-up;
+ drive-strength = <10>;
+};
+
+&sdc1_data {
+ bias-pull-up;
+ drive-strength = <10>;
+};
+
+&sdc1_rclk {
+ bias-pull-down;
+};
+
+&sdc2_clk {
+ bias-disable;
+ drive-strength = <16>;
+};
+
+&sdc2_cmd {
+ bias-pull-up;
+ drive-strength = <10>;
+};
+
+&sdc2_data {
+ bias-pull-up;
+ drive-strength = <10>;
+};
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH v5 2/3] dt-bindings: arm: qcom: Add Vicharak Axon Mini
From: Ajit Singh @ 2026-06-24 12:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio
Cc: Dmitry Baryshkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Ajit Singh,
Krzysztof Kozlowski
In-Reply-To: <20260624125443.18729-1-blfizzyy@gmail.com>
The Vicharak Axon Mini is a single-board computer based on the
Qualcomm QCM6490 platform.
Add the top-level compatible string for this board.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Ajit Singh <blfizzyy@gmail.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index d48c625d3fc4..6924bfe7b949 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -361,6 +361,7 @@ properties:
- radxa,dragon-q6a
- shift,otter
- thundercomm,rubikpi3
+ - vicharak,axon-mini
- const: qcom,qcm6490
- description: Qualcomm Technologies, Inc. Distributed Unit 1000 platform
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH v5 1/3] dt-bindings: vendor-prefixes: Add prefix for Vicharak
From: Ajit Singh @ 2026-06-24 12:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio
Cc: Dmitry Baryshkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Ajit Singh,
Krzysztof Kozlowski
In-Reply-To: <20260624125443.18729-1-blfizzyy@gmail.com>
Vicharak develops computing platforms and manufactures single-board
computers, including FPGA-integrated SBCs. Add a vendor prefix for
them.
Link: https://vicharak.in/
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Ajit Singh <blfizzyy@gmail.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index ee7fd3cfe203..1948356337b9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -1767,6 +1767,8 @@ patternProperties:
description: VIA Technologies, Inc.
"^vialab,.*":
description: VIA Labs, Inc.
+ "^vicharak,.*":
+ description: Vicharak Computers Pvt. Ltd.
"^vicor,.*":
description: Vicor Corporation
"^videostrong,.*":
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* [PATCH v5 0/3] arm64: dts: qcom: Add Vicharak Axon Mini
From: Ajit Singh @ 2026-06-24 12:54 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio
Cc: Dmitry Baryshkov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, devicetree, linux-kernel, Ajit Singh
Add initial support for the Vicharak Axon Mini, a QCS6490-based
single-board computer.
This series adds the Vicharak vendor prefix, documents the board
compatible, and adds the initial board DTS.
Tested:
- debug UART
- eMMC
- UFS
- SDIO WLAN
- USB 2.0 host
- PCIe
---
v4: https://lore.kernel.org/all/20260607113658.25117-1-blfizzyy@gmail.com/
Changes in v5:
- Drop regulator-always-on/regulator-boot-on from vreg_l16b_1p1
and vreg_l17b_1p7.
- Remove the unused vcc_3v3_en pinctrl state.
- Pick up Dmitry's Reviewed-by tag.
Changes in v4:
- Move pinctrl-related changes under a /* pinctrl */ section.
- Explain why UFS ICE is kept disabled in commit msg.
- Add a comment describing the USB 2.0 host-only board routing.
Changes in v3:
- Dropped unused regulators.
- Pick up Acked-by tags for the binding patches.
Changes in v2:
- Drop unused Type-C VBUS regulator.
- Drop invalid camera thermal zone.
- Drop incorrect PM8350C thermal alarm override.
- Fix PCIe1 3.3 V regulator name.
- Drop redundant EUD disable override.
- Keep ICE disabled due to fatal SError during qcom_ice_create().
- Fix pinctrl property ordering.
- Sort top-level label references.
- Add blank lines before status properties.
Ajit Singh (3):
dt-bindings: vendor-prefixes: Add prefix for Vicharak
dt-bindings: arm: qcom: Add Vicharak Axon Mini
arm64: dts: qcom: Add Vicharak Axon Mini
.../devicetree/bindings/arm/qcom.yaml | 1 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
.../dts/qcom/qcs6490-vicharak-axon-mini.dts | 1014 +++++++++++++++++
4 files changed, 1018 insertions(+)
create mode 100644 arch/arm64/boot/dts/qcom/qcs6490-vicharak-axon-mini.dts
--
2.50.1 (Apple Git-155)
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: thermal: amlogic: Fix missing header in the example
From: Rob Herring @ 2026-06-24 12:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Guillaume La Roque, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Krzysztof Kozlowski, Conor Dooley, Ronald Claveau,
linux-pm, linux-amlogic, devicetree, linux-kernel
In-Reply-To: <20260622100231.438435-3-krzysztof.kozlowski@oss.qualcomm.com>
On Mon, Jun 22, 2026 at 12:02:32PM +0200, Krzysztof Kozlowski wrote:
> Usage of defines from headers requires including relevant header,
> otherwise dt_binding_check fails:
>
> Lexical error: Documentation/devicetree/bindings/thermal/amlogic,thermal.example.dts:59.27-34 Unexpected 'GIC_SPI'
> Lexical error: Documentation/devicetree/bindings/thermal/amlogic,thermal.example.dts:59.38-57 Unexpected 'IRQ_TYPE_LEVEL_HIGH'
> Lexical error: Documentation/devicetree/bindings/thermal/amlogic,thermal.example.dts:60.37-45 Unexpected 'CLKID_TS'
>
> Fixes: b1c8ccdbd4e9 ("dt-bindings: thermal: amlogic: Add support for T7")
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Fix for current RC - commit already pulled in merge window.
>
> This should be applied fast to fix current RC, thus maybe Rob?
Both applied.
Rob
^ permalink raw reply
* Re: [PATCH v3 1/7] dt-bindings: serial: 8250: aspeed: add compatible string for ast2600
From: Grégoire Layet @ 2026-06-24 12:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-realistic-spiked-parrot-db1d9c@quoll>
Hi Krzysztof,
> Do not attach (thread) your patchsets to some other threads (unrelated
> or older versions). This buries them deep in the mailbox and might
> interfere with applying entire sets. See also:
> https://elixir.bootlin.com/linux/v6.16-rc2/source/Documentation/process/submitting-patches.rst#L830
Oh okay sorry I missed this information. Thank's for letting me know !
> This should be oneOf (by convention and actually more accurate meaning).
Acknowledged
> More important, where is documenting of the actual compatible?
Yes, you are right, I missed it. Will be added in v4.
Best regards,
Grégoire
^ permalink raw reply
* Re: [PATCH v3 2/7] dt-bindings: serial: 8250: aspeed: add aspeed,vuart-over-pci bool prop
From: Grégoire Layet @ 2026-06-24 12:48 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: joel, andrew, lkundrak, devicetree, gregkh, jirislaby, robh,
krzk+dt, conor+dt, andrew, jacky_chou, yh_chung, ninad,
anirudhsriniv, linux-serial, linux-aspeed, linux-arm-kernel,
linux-kernel
In-Reply-To: <20260624-original-vigorous-mayfly-dfceac@quoll>
Hi Krzysztof,
> What does that mean? How UART can be accessible over PCI bus?
It's a Virtual UART. Internally, it's two FIFOs accessible via
8250-compatible register sets on both ends.
There is 4 Virtuals UARTs on the LPC bus of the AST2600 and 2 of them
are bridged over the PCI bus.
So, from the host, you can access the 8250 register set on the PCI bus.
> > + aspeed,vuart-over-pci:
> > + type: boolean
> > + default: false
>
> There is no such syntax. Please do not introduce own style. Instead,
> look at other files how this is done.
Ack. I will remove 'default: false' for the v4.
> > + description: |
>
> Do not need '|' unless you need to preserve formatting.
Acknowledged
Best regards,
Grégoire
^ permalink raw reply
* [PATCH v2] arm64: dts: qcom: glymur: Add label properties to CoreSight devices
From: Jie Gan @ 2026-06-24 12:38 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tingwei Zhang
Cc: linux-arm-msm, devicetree, linux-kernel, Jie Gan
Add label properties to TPDM and CTI nodes in the glymur device tree to
provide human-readable identifiers for each CoreSight device. These
labels allow userspace tools and the CoreSight framework to identify
devices by name rather than by base address.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v2:
- fix typo in commit message: "hamoa" -> "glymur"
- Link to v1: https://lore.kernel.org/r/20260624-add-label-node-for-glymur-v1-1-87576107b999@oss.qualcomm.com
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index 20b49af7298e..27cc30de940e 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -5770,6 +5770,7 @@ tpdm@1000f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_spdm";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -5834,6 +5835,7 @@ tpdm@1102c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_gcc";
qcom,dsb-msrs-num = <32>;
@@ -5852,6 +5854,7 @@ tpdm@11180000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
@@ -5871,6 +5874,7 @@ tpdm@11185000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_dpm_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -5890,6 +5894,7 @@ tpdm@11186000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_cdsp_dpm_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6010,6 +6015,7 @@ cti@11193000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_cdsp";
};
cti_wpss: cti@111ab000 {
@@ -6018,6 +6024,7 @@ cti_wpss: cti@111ab000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "cti_wpss";
};
tpdm@111d0000 {
@@ -6026,6 +6033,7 @@ tpdm@111d0000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qm";
qcom,dsb-msrs-num = <32>;
@@ -6201,6 +6209,7 @@ tpdm@11207000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_mm_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6219,6 +6228,7 @@ tpdm@1120b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_east_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6237,6 +6247,7 @@ tpdm@11213000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_west_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6255,6 +6266,7 @@ tpdm@11219000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_center_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6273,6 +6285,7 @@ tpdm@1121a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_ipcc";
qcom,cmb-msrs-num = <32>;
@@ -6291,6 +6304,7 @@ tpdm@1121b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_qrng";
qcom,cmb-msrs-num = <32>;
@@ -6309,6 +6323,7 @@ tpdm@1121c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pmu";
qcom,dsb-msrs-num = <32>;
@@ -6327,6 +6342,7 @@ tpdm@1121d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_cx";
qcom,cmb-msrs-num = <32>;
@@ -6345,6 +6361,7 @@ tpdm@1121e000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mxc";
qcom,cmb-msrs-num = <32>;
@@ -6363,6 +6380,7 @@ tpdm@1121f000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_rdpm_mxa";
qcom,cmb-msrs-num = <32>;
@@ -6381,6 +6399,7 @@ tpdm@11220000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_center_dsb_1";
qcom,dsb-msrs-num = <32>;
@@ -6399,6 +6418,7 @@ tpdm@11224000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_south2_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6417,6 +6437,7 @@ tpdm@11228000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_south_dsb";
qcom,dsb-msrs-num = <32>;
@@ -6435,6 +6456,7 @@ tpdm@11470000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_pcie_rscc";
qcom,cmb-element-bits = <32>;
qcom,cmb-msrs-num = <32>;
@@ -6478,6 +6500,7 @@ tpdm@11c03000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_4";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6656,6 +6679,7 @@ tpdm@11c09000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_0";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6675,6 +6699,7 @@ tpdm@11c0a000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_1";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6694,6 +6719,7 @@ tpdm@11c0b000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_2";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6713,6 +6739,7 @@ tpdm@11c0c000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao_prio_3";
qcom,cmb-element-bits = <64>;
qcom,cmb-msrs-num = <32>;
@@ -6732,6 +6759,7 @@ tpdm@11c0d000 {
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
+ label = "tpdm_swao";
qcom,dsb-element-bits = <32>;
qcom,dsb-msrs-num = <32>;
---
base-commit: 4e5dfb7c84012007c3c7061126491bbc92d71bf1
change-id: 20260624-add-label-node-for-glymur-1ba59f479870
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* Re: [PATCH v6 02/10] arm64: tegra: Remove fallback compatible for GPCDMA
From: Thierry Reding @ 2026-06-24 12:35 UTC (permalink / raw)
To: Rob Herring
Cc: Akhil R, Thierry Reding, Vinod Koul, Frank Li,
Krzysztof Kozlowski, Conor Dooley, Jonathan Hunter,
Laxman Dewangan, Philipp Zabel, dmaengine, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <ajuv2CVQ-b978cn6@orome>
[-- Attachment #1: Type: text/plain, Size: 967 bytes --]
On Wed, Jun 24, 2026 at 12:22:38PM +0200, Thierry Reding wrote:
> On Tue, Jun 23, 2026 at 09:02:39AM -0500, Rob Herring wrote:
> > On Tue, Mar 31, 2026 at 5:24 AM Akhil R <akhilrajeev@nvidia.com> wrote:
> > >
> > > Remove the fallback compatible string "nvidia,tegra186-gpcdma" for GPCDMA
> > > in Tegra264. Tegra186 compatible cannot work on Tegra264 because of the
> > > register offset changes and absence of the reset property.
> > >
> > > Fixes: 65ef237e4810 ("arm64: tegra: Add Tegra264 support")
> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> > > ---
> > > arch/arm64/boot/dts/nvidia/tegra264.dtsi | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Thierry, Are you going to apply this? The binding change has been
> > picked up and now there's a warning.
>
> Yes, I have this in my tree of fixes for 7.1 and plan to send it out
> towards the end of this week.
Sorry, fixes for 7.2-rc1, that is.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v7 3/4] PCI: tegra: Add Tegra264 support
From: Thierry Reding @ 2026-06-24 12:35 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Helgaas, Lorenzo Pieralisi, Krzysztof Wilczyński,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Thierry Reding,
Jonathan Hunter, Karthikeyan Mitran, Hou Zhiqiang,
Thomas Petazzoni, Pali Rohár, Michal Simek, Kevin Xie,
Aksh Garg, linux-pci, devicetree, linux-tegra, linux-kernel,
linux-arm-kernel, Thierry Reding, Manikanta Maddireddy
In-Reply-To: <slfaxyt6p5mwsqmxvmriy6npilpjhjxv5ruegj4hnivj6zufkl@o6adjy5jmzfy>
[-- Attachment #1: Type: text/plain, Size: 8181 bytes --]
On Thu, Jun 18, 2026 at 09:26:33AM +0200, Manivannan Sadhasivam wrote:
> On Wed, Jun 17, 2026 at 06:01:30PM +0200, Thierry Reding wrote:
[...]
> > +static int tegra264_pcie_parse_dt(struct tegra264_pcie *pcie)
> > +{
> > + struct device *dev = pcie->dev;
> > + int err;
> > +
> > + pcie->wake_gpio = devm_gpiod_get_optional(dev, "wake", GPIOD_IN);
> > + if (IS_ERR(pcie->wake_gpio))
> > + return PTR_ERR(pcie->wake_gpio);
> > +
> > + if (!pcie->wake_gpio)
> > + return 0;
> > +
> > + err = gpiod_to_irq(pcie->wake_gpio);
> > + if (err < 0)
> > + return dev_err_probe(dev, err, "failed to get wake IRQ\n");
> > +
> > + pcie->wake_irq = (unsigned int)err;
> > +
> > + err = devm_device_init_wakeup(dev);
> > + if (err < 0)
> > + return dev_err_probe(dev, err, "failed to initialize wakeup\n");
> > +
> > + err = devm_pm_set_wake_irq(dev, pcie->wake_irq);
> > + if (err < 0)
> > + return dev_err_probe(dev, err, "failed to set wakeup IRQ\n");
> > +
>
> I'd really like to get rid of custom WAKE# handling in the controller drivers.
> Krishna is trying to add generic WAKE# handling in the PCI core and I'd suggest
> you to take a look at the patches:
> https://lore.kernel.org/linux-pci/20260511-wakeirq_support-v10-2-c10af9c9eb8c@oss.qualcomm.com/
>
> But this also means that you need to use switch to Root Port binding to move the
> Root Port properties out of the controller node. This is something we are
> mandating for the new controllers. Not a big change though...
>
> Reference:
>
> Documentation/devicetree/bindings/pci/spacemit,k1-pcie-host.yaml#n80
Okay, let me look into it.
[...]
> > + err = devm_pm_runtime_set_active_enabled(dev);
>
> I belive this has to come after pm_runtime_get_sync() because at this point, the
> controller is not enabled.
Okay, I'll change that.
> > + if (err < 0) {
> > + dev_err_probe(dev, err, "failed to enable runtime PM\n");
> > + goto put_bpmp;
> > + }
> > +
> > + err = pm_runtime_get_sync(dev);
> > + if (err < 0) {
> > + dev_err_probe(dev, err, "failed to power on device\n");
> > + goto put_bpmp;
> > + }
> > +
> > + /* sanity check that programmed ranges match what's in DT */
> > + if (!tegra264_pcie_check_ranges(pdev)) {
> > + err = -EINVAL;
> > + goto put_pm;
> > + }
> > +
> > + pcie->cfg = pci_ecam_create(dev, res, bus->res, &pci_generic_ecam_ops);
> > + if (IS_ERR(pcie->cfg)) {
> > + err = dev_err_probe(dev, PTR_ERR(pcie->cfg),
> > + "failed to create ECAM\n");
> > + goto put_pm;
> > + }
> > +
> > + bridge->ops = (struct pci_ops *)&pci_generic_ecam_ops.pci_ops;
> > + bridge->sysdata = pcie->cfg;
> > + pcie->ecam = pcie->cfg->win;
> > +
> > + tegra264_pcie_init(pcie);
> > +
> > + if (!pcie->link_up)
> > + return 0;
>
> So not hotplug support? Also, you do not want the driver to error out? I'm
> wondering what's the use then?
Hotplug is supported via pciehp. We skip probing the host bridge if no
link was detected because there's simply nothing attached to the port,
otherwise the link would've come up.
pcie->link_up is slightly misleading because it actually means something
along the lines of "link could be up at some point", either during probe
or after some hotplug event later on. It is only ever false if there's
no link during probe and hotplug isn't supported at all.
> > +
> > + err = pci_host_probe(bridge);
> > + if (err < 0) {
> > + dev_err_probe(dev, err, "failed to register host\n");
> > + goto free_ecam;
> > + }
> > +
> > + return 0;
> > +
> > +free_ecam:
>
> Nit: Prefix 'err' for the labels.
I don't see any benefit of adding a prefix. Seems pretty redundant, but
I also don't feel too strongly about it, so I can add it.
> > + pci_ecam_free(pcie->cfg);
> > +put_pm:
> > + pm_runtime_put_sync(dev);
> > +put_bpmp:
> > + tegra_bpmp_put(pcie->bpmp);
> > +
> > + return err;
> > +}
> > +
> > +static void tegra264_pcie_remove(struct platform_device *pdev)
> > +{
> > + struct tegra264_pcie *pcie = platform_get_drvdata(pdev);
> > +
> > + /*
> > + * If we undo tegra264_pcie_init() then link goes down and need
> > + * controller reset to bring up the link again. Remove intention is
> > + * to clean up the root bridge and re-enumerate during bind.
>
> But the controller will be consuming power even if PCIe is not used. Do you
> really want that? Can't tegra264_pcie_init() handle the initialization? I'm
> wondering how tegra264_pcie_deinit() in tegra264_pcie_suspend() works then.
I had to clarify this with the PCI team and they indicated that
tegra264_pcie_deinit() is actually useless and maybe even harmful. The
reason is that there's a processor on these boards (BPMP) that takes
care of power sequencing and it will automatically take the PCI links
to L2 on suspend and assert PERST#.
Another reason why we don't want to reset the entire controller is that
it is already set up during early boot by UEFI and the kernel driver
does not redo the entire initialization.
So yes, I think a little bit of power consumption is the compromise that
we will have to live with. In the bigger picture it's probably not going
to be noticeable in most cases, and given that these are embedded
platforms we'll likely see fixed configurations most of the time and the
case where we remove the PCIe host controller will not be common.
> > + */
> > + pci_lock_rescan_remove();
> > + pci_stop_root_bus(pcie->bridge->bus);
> > + pci_remove_root_bus(pcie->bridge->bus);
> > + pci_unlock_rescan_remove();
> > +
> > + pm_runtime_put_sync(&pdev->dev);
> > + tegra_bpmp_put(pcie->bpmp);
> > + pci_ecam_free(pcie->cfg);
> > +}
> > +
> > +static int tegra264_pcie_suspend(struct device *dev)
> > +{
> > + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> > + int err;
> > +
> > + tegra264_pcie_deinit(pcie);
> > +
> > + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> > + err = enable_irq_wake(pcie->wake_irq);
> > + if (err < 0)
> > + dev_err(dev, "failed to enable wake IRQ: %pe\n",
> > + ERR_PTR(err));
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +static int tegra264_pcie_resume(struct device *dev)
> > +{
> > + struct tegra264_pcie *pcie = dev_get_drvdata(dev);
> > + int err;
> > +
> > + err = pinctrl_pm_select_default_state(dev);
> > + if (err < 0)
> > + dev_err(dev, "failed to configure sideband pins: %pe\n",
> > + ERR_PTR(err));
>
> Please remind me if you justified this manual pinctrl handling before.
This is just regular pinctrl PM boilerplate. There's plenty of other
drivers where we do this, too. We want this because some of the pins
get configured to non-default states on boot/resume, so doing this
here ensures they are muxed correctly.
> > +
> > + if (pcie->wake_gpio && device_may_wakeup(dev)) {
> > + err = disable_irq_wake(pcie->wake_irq);
> > + if (err < 0)
> > + dev_err(dev, "failed to disable wake IRQ: %pe\n",
> > + ERR_PTR(err));
> > + }
> > +
> > + if (pcie->link_up == false)
> > + return 0;
>
> How is this possible? If 'pcie->link_up' was 'false' during probe(), then it is
> going to stay until tegra264_pcie_init() is called below.
Yes, this keeps confusing me, too. The purpose of this is to skip
initialization if we've already determined during probe that there is
never going to be a link. link_up will be false if and only if there was
no link during probe and we don't expect there ever will be a link
because there is no hotplug support.
Maybe a different name for link_up could help here? maybe_link_up
perhaps? I don't know if that's any clearer, but I also couldn't come up
with a better name.
Or maybe we should split this into two booleans, since we're essentially
trying to use one boolean to track a tristate. What we want to know is
if a link is truly up and if the controller should be kept powered for
the case where hotplug is supported.
I suppose we could do:
bool link_up; /* track the link state */
bool supports_hotplug; /* track whether port is hotpluggable */
That would make the code a bit cleaner and easier to follow.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Daniele Briguglio @ 2026-06-24 12:20 UTC (permalink / raw)
To: Heiko Stuebner, Diederik de Haas, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <2008560.6tgchFWduM@diego>
Hi Heiko,
> Care to send a patch for that change? :-)
Will do. I was only waiting for your call on the approach before sending,
so I'll get it out shortly.
Best regards,
Daniele
^ permalink raw reply
* Re: [PATCH 5/7] soc: aspeed: Add eSPI flash channel support
From: Markus Elfring @ 2026-06-24 12:14 UTC (permalink / raw)
To: YH Chung, linux-aspeed, openbmc, linux-arm-kernel, devicetree,
Andrew Jeffery, Conor Dooley, Joel Stanley, Krzysztof Kozlowski,
Philipp Zabel, Rob Herring, Ryan Chen
Cc: LKML, Maciej Lawniczak
In-Reply-To: <20260313-upstream_espi-v1-5-9504428e1f43@aspeedtech.com>
…
> +++ b/drivers/soc/aspeed/espi/aspeed-espi.c
…
> +static void aspeed_espi_flash_rx_work(struct work_struct *work)
> +{
> + struct aspeed_espi_flash *flash = container_of(work, struct aspeed_espi_flash, rx_work);
> + struct aspeed_espi *espi = container_of(flash, struct aspeed_espi, flash);
> +
> + mutex_lock(&flash->tx_mtx);
> + aspeed_espi_flash_handle_lun(espi);
> + mutex_unlock(&flash->tx_mtx);
> +}
…
Under which circumstances would you become interested to apply a statement
like “guard(mutex)(&flash->tx_mtx);”?
https://elixir.bootlin.com/linux/v7.1.1/source/include/linux/mutex.h#L253
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v4 3/3] arm64: dts: qcom: Add Vicharak Axon Mini
From: Konrad Dybcio @ 2026-06-24 12:12 UTC (permalink / raw)
To: Ajit Singh
Cc: Bjorn Andersson, Bartosz Golaszewski, Dmitry Baryshkov,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-arm-msm,
devicetree, linux-kernel
In-Reply-To: <ajYcnHPZjkFwGjly@page.local>
On 6/20/26 6:57 AM, Ajit Singh wrote:
> On Fri, Jun 19, 2026 at 05:30:40PM +0530, Konrad Dybcio wrote:
>> On 6/18/26 8:29 AM, Ajit Singh wrote:
>>> On Tue, Jun 16, 2026 at 02:10:44PM +0530, Konrad Dybcio wrote:
>>>> On 6/12/26 6:16 AM, Ajit Singh wrote:
>>>>> On Wed, Jun 10, 2026 at 02:58:19PM +0530, Konrad Dybcio wrote:
>>>>>> On 6/7/26 1:36 PM, Ajit Singh wrote:
>>>>>>> Add DTS for the Vicharak Axon Mini board based on the Qualcomm
>>>>>>> QCS6490 SoC.
>>>>>>>
>>>>>>> This adds debug UART, eMMC, UFS, SDIO WLAN, USB 2.0 host, PCIe
>>>>>>> support along with regulators.
>>>>>>>
>>>>>>> The UFS ICE block is kept disabled because enabling it currently causes
>>>>>>> an SError during qcom_ice_create() on this board. UFS works without ICE.
>>>>>>>
>>>>>>> Signed-off-by: Ajit Singh <blfizzyy@gmail.com>
>>>>>>> ---
[...]
>>
>> most notably though, it seems that the brcmfmac driver doesn't even use
>> the regulator framework, probably because all of the SDIO WLANs that
>> Linux supports were wired in a more "embedded" way, where the V(Q)MMC
>> supplies were enough.. unless it's the case here too?
>
> It might not be possible to drop regulator-always-on for VREG_L12C here. The
> SDHC2 host already has its own vmmc/vqmmc rails:
>
> vqmmc-supply = <&vreg_l2c_1p62>;
> vmmc-supply = <&vreg_l6c_2p96>;
>
> VREG_L12C is a separate module-side VDDIO rail for the AP6272S WLAN/BT module.
> There is no separate GPIO-controlled enable for this rail;
>
> as you said, since brcmfmac does not appear to consume an extra VDDIO regulator
> from the SDIO child node, so unless there is a preferred way to model this
> module-side VDDIO rail, I think VREG_L12C still needs to stay always-on.
OK, let's get this merged then
Konrad
^ permalink raw reply
* Re: [PATCH v2 3/4] arm64: dts: qcom: Add HONOR MagicBook Art 14 device tree
From: Konrad Dybcio @ 2026-06-24 12:10 UTC (permalink / raw)
To: Konstantin Shabanov
Cc: andersson, robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260620173833.17728-1-mail@etehtsea.me>
On 6/20/26 7:38 PM, Konstantin Shabanov wrote:
> On Tue, 16 Jun 2026 14:37:13 +0200 Konrad Dybcio wrote:
>>> +/* MP0 goes to the USB-A port(USB3) and FPC */
>>
>> "MP0" refers to the first USB3+USB2 port on the multiport controller.
>> Is there a hub inbetween? Should we describe it? Do we know if VBUS on
>> the USB-A port is controllable?
>
> Unfortunately, I couldn't find any documentation for this laptop, and
> all I can tell is that the USB-A port seems to work and the FPC is
> recognized:
>
> Bus 005 Device 002: ID 10a5:9924 FPC FPC L:2407 FW:3334147
OK, if it works, it works
Konrad
^ permalink raw reply
* Re: [PATCH v3 3/4] arm64: dts: qcom: Add HONOR MagicBook Art 14 device tree
From: Konrad Dybcio @ 2026-06-24 12:10 UTC (permalink / raw)
To: Konstantin Shabanov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260620175210.19563-4-mail@etehtsea.me>
On 6/20/26 7:51 PM, Konstantin Shabanov wrote:
> Introduce support for the HONOR MagicBook Art 14 laptop.
> This version is based on the initial work by Kirill A. Korinsky [1]
> and Valentin Manea [2].
[...]
> +&iris {
> + firmware-name = "qcom/x1e80100/HONOR/MRO-XXX/qcvss8380.mbn";
Is that a model name, or a placeholder?
[...]
> +&tlmm {
> + gpio-reserved-ranges = <34 2>, /* Unused */
> + <44 4>; /* SPI (TPM) */
> +
> + hall_int_n_default: hall-int-n-state {
> + pins = "gpio92";
> + function = "gpio";
> + bias-disable;
> + };
nit: pins would be best sorted by their pin index
[...]
> + ts0_default: ts0-default-state {
> + int-n-pins {
> + pins = "gpio51";
> + function = "gpio";
> + bias-disable;
> + };
> +
> + reset-n-pins {
> + pins = "gpio48";
> + function = "gpio";
> + output-high;
not a nit: drop output-foo properties from TLMM pins, the
driver that consumes them should take care of setting their state
[...]
> +/* MP0 goes to the USB-A port(USB3) and FPC */
ultra nit: add a space before '(', please
Konrad
^ permalink raw reply
* Re: [PATCH v3 3/4] arm64: dts: qcom: Add HONOR MagicBook Art 14 device tree
From: Konrad Dybcio @ 2026-06-24 12:07 UTC (permalink / raw)
To: Konstantin Shabanov, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260620175210.19563-4-mail@etehtsea.me>
On 6/20/26 7:51 PM, Konstantin Shabanov wrote:
> Introduce support for the HONOR MagicBook Art 14 laptop.
> This version is based on the initial work by Kirill A. Korinsky [1]
> and Valentin Manea [2].
[...]
> +/* MP0 goes to the USB-A port(USB3) and FPC */
> +&usb_mp {
> + /* Limit to single port */
> + phys = <&usb_mp_hsphy0>, <&usb_mp_qmpphy0>;
> + phy-names = "usb2-0", "usb3-0";
> +
> + status = "okay";
> +};
It's fine to keep the other one enabled, if only to make sure that
it's powered off sanely
Konrad
^ permalink raw reply
* Re: [PATCH 5/7] soc: aspeed: Add eSPI flash channel support
From: Markus Elfring @ 2026-06-24 12:02 UTC (permalink / raw)
To: YH Chung, linux-aspeed, openbmc, linux-arm-kernel, devicetree,
Andrew Jeffery, Conor Dooley, Joel Stanley, Krzysztof Kozlowski,
Philipp Zabel, Rob Herring, Ryan Chen
Cc: LKML, Maciej Lawniczak
In-Reply-To: <20260313-upstream_espi-v1-5-9504428e1f43@aspeedtech.com>
…
> +++ b/drivers/soc/aspeed/espi/aspeed-espi-comm.h
> @@ -0,0 +1,62 @@
…
> +/*
> + * eSPI cycle type encoding
> + *
> + * Section 5.1 Cycle Types and Packet Format,
> + * Intel eSPI Interface Base Specification, Rev 1.0, Jan. 2016.
> + */
> +#define ESPI_FLASH_READ 0x00
> +#define ESPI_FLASH_WRITE 0x01
> +#define ESPI_FLASH_ERASE 0x02
…
How do you think about to use an enumeration for such data?
https://en.wikipedia.org/wiki/Enumerated_type#C_and_syntactically_similar_languages
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Konrad Dybcio @ 2026-06-24 12:00 UTC (permalink / raw)
To: Xin Xu, andersson, konradybcio; +Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <tencent_A65CB41DCB0CA96634CF8883E1CF89059706@qq.com>
On 6/22/26 8:46 PM, Xin Xu wrote:
> Add the pm8008 PMIC node on i2c15 with seven LDOs,
> using GPIO84 as interrupt and GPIO76 as reset.
>
> Signed-off-by: Xin Xu <xxsemail@qq.com>
> ---
[...]
> + pm8008_default: pm8008-default-state {
> + int-pins {
> + pins = "gpio84";
> + function = "gpio";
> + bias-disable;
> + drive-strength = <2>;
> + input-enable;
> + };
arch/arm64/boot/dts/qcom/sm8250-xiaomi-elish-boe.dtb: pinctrl@f100000 (qcom,sm8250-pinctrl): pm8008-default-state: 'oneOf' conditional failed, one must be fixed:
'function' is a required property
'pins' is a required property
Unevaluated properties are not allowed ('int-pins', 'reset-pins' were unexpected)
False schema does not allow True
from schema $id: http://devicetree.org/schemas/pinctrl/qcom,sm8250-pinctrl.yaml
Please drop input-enable, it's not a thing on TLMM pins
Konrad
^ permalink raw reply
* Re: [PATCH] arm64: dts: mediatek: mt8395-radxa-nio-12l: Enable I2C3 on 40-pin header
From: sashiko-bot @ 2026-06-24 11:58 UTC (permalink / raw)
To: Ricardo Pardini via B4 Relay; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260624-nio-12l-add-i2c-40-pin-v1-1-f6c11ed2184c@pardini.net>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Contradictory and invalid multiple drive strength properties (`drive-strength` and `drive-strength-microamp`) in the `i2c3_pins` pinctrl node.
--
commit cc885ce9bc43909e2fea294bb5532055037c4cf5
Author: Ricardo Pardini <ricardo@pardini.net>
arm64: dts: mediatek: mt8395-radxa-nio-12l: Enable I2C3 on 40-pin header
This commit enables I2C3 on the 40-pin header for the Radxa NIO 12L board.
It adds the corresponding pin configurations to allow users to connect
external I2C devices.
> diff --git a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
> index bf91305e8e4a5..03a2f2e746475 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
> +++ b/arch/arm64/boot/dts/mediatek/mt8395-radxa-nio-12l.dts
[ ... ]
> @@ -789,6 +797,16 @@ pins-bus {
> };
> };
>
> + i2c3_pins: i2c3-pins {
> + pins-bus {
> + pinmux = <PINMUX_GPIO14__FUNC_SDA3>,
> + <PINMUX_GPIO15__FUNC_SCL3>;
> + bias-pull-up = <1000>;
> + drive-strength = <6>;
> + drive-strength-microamp = <1000>;
[Severity: Medium]
Is it expected to specify both drive-strength and drive-strength-microamp
for the same pins here?
The generic pinconf parser will emit a boot error log when it encounters
multiple drive strength properties, as requesting both 6mA and 1mA drive
strengths is contradictory.
Both properties will then propagate to the Mediatek pinctrl driver, which
may program both the standard and advanced driving circuits simultaneously.
Could this leave the I2C3 pins in an undefined electrical state?
> + };
> + };
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-nio-12l-add-i2c-40-pin-v1-1-f6c11ed2184c@pardini.net?part=1
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDA 850
From: Konrad Dybcio @ 2026-06-24 11:58 UTC (permalink / raw)
To: Krzysztof Kozlowski, David Heidelberg, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <b3799f48-85bf-48d3-b2bd-daba59f6dd0b@kernel.org>
On 6/24/26 1:57 PM, Krzysztof Kozlowski wrote:
> On 24/06/2026 13:53, Konrad Dybcio wrote:
>> On 6/24/26 1:50 PM, Krzysztof Kozlowski wrote:
>>> On 24/06/2026 13:37, David Heidelberg wrote:
>>>> best I do is close-to-mainline tree,
>>>>
>>>> https://github.com/commaai/vamOS/tree/master/kernel/dts
>>>
>>>
>>> That's not upstream, so we do not need this patch upstream... Just keep
>>> it out of tree.
>>
>> As I mentioned, the proposed ID has upstream users e.g.
>> sdm850-lenovo-yoga-c630.dts
>
> There is no use of this in that DTS, so my comment is valid: please post
> it with users.
aaaah, I get it.. David, please add the socinfo entry
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: qcom: sm8250-xiaomi-elish: Add pm8008 PMIC
From: Konrad Dybcio @ 2026-06-24 11:57 UTC (permalink / raw)
To: Xin Xu, andersson, konradybcio; +Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <tencent_A65CB41DCB0CA96634CF8883E1CF89059706@qq.com>
On 6/22/26 8:46 PM, Xin Xu wrote:
> Add the pm8008 PMIC node on i2c15 with seven LDOs,
> using GPIO84 as interrupt and GPIO76 as reset.
>
> Signed-off-by: Xin Xu <xxsemail@qq.com>
> ---
[...]
> + pm8008_default: pm8008-default-state {
> + int-pins {
> + pins = "gpio84";
> + function = "gpio";
> + bias-disable;
> + drive-strength = <2>;
> + input-enable;
> + };
> +
> + reset-pins {
> + pins = "gpio76";
> + function = "gpio";
> + bias-pull-up;
> + drive-strength = <2>;
nit: bias properties after drive-strength (I now noticed that 8250 dtsi
has it ""wrong"", we'll mass-touch it up once we have a tool for that..
sorry for the trouble)
otherwise
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDA 850
From: Krzysztof Kozlowski @ 2026-06-24 11:57 UTC (permalink / raw)
To: Konrad Dybcio, David Heidelberg, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <12bc9f3d-bfea-4ff8-8eb6-d2203bb46b89@oss.qualcomm.com>
On 24/06/2026 13:53, Konrad Dybcio wrote:
> On 6/24/26 1:50 PM, Krzysztof Kozlowski wrote:
>> On 24/06/2026 13:37, David Heidelberg wrote:
>>> best I do is close-to-mainline tree,
>>>
>>> https://github.com/commaai/vamOS/tree/master/kernel/dts
>>
>>
>> That's not upstream, so we do not need this patch upstream... Just keep
>> it out of tree.
>
> As I mentioned, the proposed ID has upstream users e.g.
> sdm850-lenovo-yoga-c630.dts
There is no use of this in that DTS, so my comment is valid: please post
it with users.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sm8250-xiaomi-elish: add ov8856 front camera
From: Konrad Dybcio @ 2026-06-24 11:56 UTC (permalink / raw)
To: Xin Xu, andersson, konradybcio; +Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <tencent_A7DA95458754255A62A4C730EEE484AB2905@qq.com>
On 6/22/26 8:52 PM, Xin Xu wrote:
> Add the ov8856 front camera, connected on CCI1 to CSIPHY4 and
> powered by pm8008 LDOs and other supplies.
>
> Signed-off-by: Xin Xu <xxsemail@qq.com>
> ---
[...]
> &cdsp {
> firmware-name = "qcom/sm8250/xiaomi/elish/cdsp.mbn";
> status = "okay";
> @@ -877,6 +933,20 @@ bt_en_state: bt-default-state {
> bias-pull-up;
> };
>
> + camera_front_active: camera-front-active-state {
> + pins = "gpio109";
> + function = "gpio";
> + bias-disable;
> + drive-strength = <2>;
> + };
> +
> + mclk3_active: mclk3-active-state {
> + pins = "gpio97";
> + function = "cam_mclk";
> + bias-disable;
> + drive-strength = <4>;
> + };
nit: other nodes have drive-strength before bias-disable
Also let's move the mclk pin state definition to sm8250, it's not
specific to this board
Konrad
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: qcom,ids: Add SoC ID for Snapdragon SDA 850
From: Konrad Dybcio @ 2026-06-24 11:53 UTC (permalink / raw)
To: Krzysztof Kozlowski, David Heidelberg, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <80049d2e-ddc9-44e9-b231-876adcd79823@kernel.org>
On 6/24/26 1:50 PM, Krzysztof Kozlowski wrote:
> On 24/06/2026 13:37, David Heidelberg wrote:
>> best I do is close-to-mainline tree,
>>
>> https://github.com/commaai/vamOS/tree/master/kernel/dts
>
>
> That's not upstream, so we do not need this patch upstream... Just keep
> it out of tree.
As I mentioned, the proposed ID has upstream users e.g.
sdm850-lenovo-yoga-c630.dts
Konrad
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox