* Re: [PATCH 1/2] dt-bindings: arm: fsl: Add SolidRun i.MX8DXL SoM and HummingBoard
From: Krzysztof Kozlowski @ 2026-04-09 8:48 UTC (permalink / raw)
To: Josua Mayer
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel
In-Reply-To: <20260408-imx8dxl-sr-som-v1-1-ce5a39acd713@solid-run.com>
On Wed, Apr 08, 2026 at 08:38:36PM +0200, Josua Mayer wrote:
> Add binding for the SolidRun i.MX8DXL based System on Module, and the
> reference HummingBoard Telematics.
>
> Signed-off-by: Josua Mayer <josua@solid-run.com>
> ---
> Documentation/devicetree/bindings/arm/fsl.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v5 2/2] dt-bindings: pinctrl: pinctrl-max77620: convert to DT schema
From: Linus Walleij @ 2026-04-09 8:47 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Liam Girdwood,
Mark Brown, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260406075114.25672-3-clamor95@gmail.com>
On Mon, Apr 6, 2026 at 9:51 AM Svyatoslav Ryhel <clamor95@gmail.com> wrote:
> Convert pinctrl-max77620 devicetree bindings for the MAX77620 PMIC from
> TXT to YAML format. This patch does not change any functionality; the
> bindings remain the same.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
Patch applied to the pinctrl tree for v7.1 in accordance with Rob's
instructions.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] dt-bindings: sram: Allow multiple-word prefixes to sram subnode
From: Krzysztof Kozlowski @ 2026-04-09 8:45 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-kernel, Luca Weiss, Konrad Dybcio
In-Reply-To: <20260408-topic-sram_dtbindings_misc-v1-1-00556167e136@oss.qualcomm.com>
On Wed, Apr 08, 2026 at 03:28:13PM +0200, Konrad Dybcio wrote:
> From: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Currently, foo-sram is allowed, but foo-bar-sram is not.
>
> Allow it so that more complex names aren't unnecessarily simplified.
>
> Signed-off-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/sram/sram.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
> index c451140962c8..b65c2ff846f1 100644
> --- a/Documentation/devicetree/bindings/sram/sram.yaml
> +++ b/Documentation/devicetree/bindings/sram/sram.yaml
> @@ -65,7 +65,7 @@ properties:
> type: boolean
>
> patternProperties:
> - "^([a-z0-9]*-)?sram(-section)?@[a-f0-9]+$":
> + "^([a-z0-9]*-|)+sram(-section)?@[a-f0-9]+$":
'|)' is an odd syntax, not really intuitive. Why this cannot be:
([a-z0-9]+-)*
?
(replacing also * -> + inside)
> type: object
> description:
> Each child of the sram node specifies a region of reserved memory.
>
> ---
> base-commit: f3e6330d7fe42b204af05a2dbc68b379e0ad179e
> change-id: 20260408-topic-sram_dtbindings_misc-5e8834f63d51
>
> Best regards,
> --
> Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
^ permalink raw reply
* Re: [PATCH 0/2] Utilize pinctrl-single for bcm7038-style chips
From: Linus Walleij @ 2026-04-09 8:44 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Tony Lindgren, Haojian Zhuang, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-1-florian.fainelli@broadcom.com>
On Wed, Apr 8, 2026 at 1:56 AM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
> This patch set allows Broadcom STB chips with the BCM7038-style
> pinmux/configuration blocks to use pinctrl-single. This does not
> preclude us from making use of a more sophisticated driver in the
> future, should we need to.
Patches applied for v7.1!
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: sdm845-lg: Enable qcom,snoc-host-cap-skip-quirk
From: David Heidelberg @ 2026-04-09 8:44 UTC (permalink / raw)
To: Paul Sajna, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jeff Johnson, Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming
In-Reply-To: <20260408-judyln-followup-v1-4-823467519b59@postmarketos.org>
On 09/04/2026 04:41, Paul Sajna wrote:
> The WCN3990 firmware for judyln does not respond to the request for
> host capabilities. Add the devicetree quirk to skip this request.
>
> Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
> ---
> arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
> index 86cf4eb44084..e0c3566761bf 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845-lg-common.dtsi
> @@ -694,5 +694,7 @@ &wifi {
> vdd-3.3-ch0-supply = <&vreg_l25a_3p3>;
> vdd-3.3-ch1-supply = <&vreg_l23a_3p3>;
>
> + qcom,snoc-host-cap-skip-quirk;
> +
> status = "okay";
> };
>
Reviewed-by: David Heidelberg <david@ixit.cz>
^ permalink raw reply
* Re: [PATCH 0/2] Utilize pinctrl-single for bcm7038-style chips
From: Linus Walleij @ 2026-04-09 8:43 UTC (permalink / raw)
To: Florian Fainelli
Cc: linux-kernel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Tony Lindgren, Haojian Zhuang, open list:PIN CONTROL SUBSYSTEM,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
moderated list:PIN CONTROLLER - SINGLE,
open list:PIN CONTROLLER - SINGLE
In-Reply-To: <20260407235611.550515-1-florian.fainelli@broadcom.com>
On Wed, Apr 8, 2026 at 1:56 AM Florian Fainelli
<florian.fainelli@broadcom.com> wrote:
> This patch set allows Broadcom STB chips with the BCM7038-style
> pinmux/configuration blocks to use pinctrl-single. This does not
> preclude us from making use of a more sophisticated driver in the
> future, should we need to.
OK that's one way to do it. I wonder if this approach also works for
BCMBCA given Haojian's comments on my previous patch attempts.
drivers/pinctrl/bcm/pinctrl-bcm4908.c would then be phased over
to pinctrl-single, or does the MSB/LSB register layout create a
problem? If we always write 0 into MSB I guess we could just add
some quirk...
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: qcom: sdm845-lg-{judyln, judyp}: Reference memory region in fb
From: David Heidelberg @ 2026-04-09 8:43 UTC (permalink / raw)
To: Paul Sajna, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jeff Johnson, Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming, Konrad Dybcio
In-Reply-To: <20260408-judyln-followup-v1-3-823467519b59@postmarketos.org>
On 09/04/2026 04:41, Paul Sajna wrote:
> To prevent duplicating the framebuffer address and size point out the
> existing framebuffer memory region instead of specifying the address
> manually.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
> ---
Reviewed-by: David Heidelberg <david@ixit.cz>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: arm: qcom,ids: add SOC IDs for IPQ9650 family
From: Krzysztof Kozlowski @ 2026-04-09 8:42 UTC (permalink / raw)
To: Kathiravan Thirumoorthy
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260408-ipq9650_soc_ids-v1-1-e76faac33f77@oss.qualcomm.com>
On Wed, Apr 08, 2026 at 03:28:34PM +0530, Kathiravan Thirumoorthy wrote:
> Add SoC IDs for Qualcomm's IPQ9650 family.
I don't see board compatibles being posted, so this could be the place
where you briefly describe the SoCs, including differences between them.
>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
> include/dt-bindings/arm/qcom,ids.h | 6 ++++++
> 1 file changed, 6 insertions(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: gpio: cavium,thunder-8890: Remove DT binding
From: Bartosz Golaszewski @ 2026-04-09 8:38 UTC (permalink / raw)
To: robh, Shi Hao
Cc: Bartosz Golaszewski, brgl, krzk+dt, conor+dt, rric, linux-gpio,
devicetree, linux-kernel
In-Reply-To: <20260408093313.17025-1-i.shihao.999@gmail.com>
On Wed, 08 Apr 2026 15:03:13 +0530, Shi Hao wrote:
> Remove the cavium,thunder-8890 GPIO binding as there are no active
> use cases. A previous attempt was made to convert the binding to DT
> schema, but since the binding is unused, remove it instead.
>
>
I tweaked the commit message as suggested by Krzysztof and queued this.
[1/1] dt-bindings: gpio: cavium,thunder-8890: Remove DT binding
https://git.kernel.org/brgl/c/5bcd451286176202f4ba84b89fd98c7ea74f33a2
Best regards,
--
Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
^ permalink raw reply
* [PATCH] arm64: dts: qcom: x1e80100-microsoft-romulus: enable OV02C10 webcam
From: Oliver White @ 2026-04-09 8:36 UTC (permalink / raw)
To: andersson, konradybcio, robh, krzk+dt, conor+dt
Cc: linux-arm-msm, devicetree, linux-kernel, Oliver White
Wire up the front-facing OV02C10 camera on Microsoft Romulus by enabling
CAMSS, CCI1 and CSIPHY4, adding the sensor node and its endpoint, and
describing the PM8010 regulator rails and pinctrl states required by the
camera module.
With these DT nodes in place the webcam can be probed and used through
the upstream OV02C10 driver.
Signed-off-by: Oliver White <oliverjwhite07@gmail.com>
---
.../dts/qcom/x1e80100-microsoft-romulus.dtsi | 127 ++++++++++++++++++
1 file changed, 127 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
index 14b5663a4d48..9e910813fa48 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100-microsoft-romulus.dtsi
@@ -857,6 +857,57 @@ vreg_l3j: ldo3 {
regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
};
};
+
+ regulators-8 {
+ compatible = "qcom,pm8010-rpmh-regulators";
+ qcom,pmic-id = "m";
+
+ vdd-l1-l2-supply = <&vreg_s5j>;
+ vdd-l3-l4-supply = <&vreg_s4c>;
+ vdd-l7-supply = <&vreg_bob1>;
+
+ vreg_l1m_1p2: ldo1 {
+ regulator-name = "vreg_l1m_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1260000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2m_1p2: ldo2 {
+ regulator-name = "vreg_l2m_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1260000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3m_1p8: ldo3 {
+ regulator-name = "vreg_l3m_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l4m_1p8: ldo4 {
+ regulator-name = "vreg_l4m_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5m_2p8: ldo5 {
+ regulator-name = "vreg_l5m_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3072000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l7m_2p8: ldo7 {
+ regulator-name = "vreg_l7m_2p8";
+ regulator-min-microvolt = <2800000>;
+ regulator-max-microvolt = <3072000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
};
&gpu {
@@ -867,6 +918,66 @@ &gpu_zap_shader {
firmware-name = "qcom/x1e80100/microsoft/qcdxkmsuc8380.mbn";
};
+&camss {
+ status = "okay";
+
+ ports {
+ /*
+ * port0 => csiphy0
+ * port1 => csiphy1
+ * port2 => csiphy2
+ * port3 => csiphy4
+ */
+ port@3 {
+ camss_csiphy4_inep0: endpoint@0 {
+ clock-lanes = <7>;
+ data-lanes = <0 1>;
+ remote-endpoint = <&ov02c10_ep>;
+ };
+ };
+ };
+};
+
+&cci1 {
+ status = "okay";
+};
+
+&cci1_i2c1 {
+ camera@36 {
+ compatible = "ovti,ov02c10";
+ reg = <0x36>;
+
+ reset-gpios = <&tlmm 237 GPIO_ACTIVE_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&cam_rgb_default>;
+
+ clocks = <&camcc CAM_CC_MCLK4_CLK>;
+ assigned-clocks = <&camcc CAM_CC_MCLK4_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ orientation = <0>; /* front facing */
+
+ avdd-supply = <&vreg_l5m_2p8>;
+ dvdd-supply = <&vreg_l1m_1p2>;
+ dovdd-supply = <&vreg_l3m_1p8>;
+
+ port {
+ ov02c10_ep: endpoint {
+ data-lanes = <1 2>;
+ link-frequencies = /bits/ 64 <400000000>;
+ remote-endpoint = <&camss_csiphy4_inep0>;
+ };
+ };
+ };
+};
+
+&csiphy4 {
+ vdda-0p8-supply = <&vreg_l2c>;
+ vdda-1p2-supply = <&vreg_l1c>;
+
+ status = "okay";
+};
+
&i2c0 {
clock-frequency = <100000>;
@@ -1441,6 +1552,22 @@ wcn_sw_en: wcn-sw-en-state {
bias-disable;
};
+ cam_rgb_default: cam-rgb-default-state {
+ mclk-pins {
+ pins = "gpio100";
+ function = "cam_aon";
+ drive-strength = <16>;
+ bias-disable;
+ };
+
+ reset-n-pins {
+ pins = "gpio237";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ };
+ };
+
cam_indicator_en: cam-indicator-en-state {
pins = "gpio225";
function = "gpio";
--
2.51.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: qcom: monaco: Add iface clock and power domain for ice sdhc
From: Kuldeep Singh @ 2026-04-09 8:31 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Kuldeep Singh
In-Reply-To: <20260409-ice_emmc_clock_addition-v2-0-90bbcc057361@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core'
clock the 'iface' clock should also be turned on by the driver. This can
only be done if power domain is enabled.
Specify both power domain and the iface clock.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 5fd289669353..8192d6b94305 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -4873,7 +4873,11 @@ sdhc_ice: crypto@87c8000 {
compatible = "qcom,qcs8300-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x0 0x087c8000 0x0 0x18000>;
- clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>,
+ <&gcc GCC_SDCC1_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&rpmhpd RPMHPD_CX>;
};
usb_1_hsphy: phy@8904000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 1/2] arm64: dts: qcom: kodiak: Add iface clock and power domain for ice sdhc
From: Kuldeep Singh @ 2026-04-09 8:31 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Kuldeep Singh
In-Reply-To: <20260409-ice_emmc_clock_addition-v2-0-90bbcc057361@oss.qualcomm.com>
Qualcomm in-line crypto engine (ICE) platform driver specifies and votes
for its own resources. Before accessing ICE hardware during probe, to
avoid potential unclocked register access issues (when clk_ignore_unused
is not passed on the kernel command line), in addition to the 'core'
clock the 'iface' clock should also be turned on by the driver. This can
only be done if power domain is enabled.
Specify both power domain and the iface clock.
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/kodiak.dtsi | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
index dda4697a61b7..a8260f695058 100644
--- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
+++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
@@ -1082,7 +1082,11 @@ sdhc_ice: crypto@7c8000 {
compatible = "qcom,sc7280-inline-crypto-engine",
"qcom,inline-crypto-engine";
reg = <0x0 0x007c8000 0x0 0x18000>;
- clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>;
+ clocks = <&gcc GCC_SDCC1_ICE_CORE_CLK>,
+ <&gcc GCC_SDCC1_AHB_CLK>;
+ clock-names = "core",
+ "iface";
+ power-domains = <&rpmhpd SC7280_CX>;
};
gpi_dma0: dma-controller@900000 {
--
2.34.1
^ permalink raw reply related
* [PATCH v2 0/2] Enable iface clock and power domain for kodiak and monaco ice sdhc
From: Kuldeep Singh @ 2026-04-09 8:31 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Kuldeep Singh
Previously, ice used to exists jointly with ufs/mmc driver and not a
standalone driver.
With recent efforts of making ice as separate module after decoupling
from ufs driver. Update sdhc ice kodiak/moanco DT nodes to adapt power
domain and iface clock to probe successfully.
The patchset is motivation to fix ice mmc where ice ufs is fixed with
below series.
https://lore.kernel.org/linux-arm-msm/20260323-qcom_ice_power_and_clk_vote-v4-0-e36044bbdfe9@oss.qualcomm.com/T/#m5da5dd7a18318583b23ffeb42fa07ef1438042d5
Testing:
* dtbs check
* Custom monaco/kodiak device with emmc storage.
This series depends on the following prerequisite patchsets:
[1] Add explicit clock vote and enable power-domain for QCOM-ICE
https://lore.kernel.org/linux-arm-msm/20260323-qcom_ice_power_and_clk_vote-v4-0-e36044bbdfe9@oss.qualcomm.com
[2] Enable Inline crypto engine for kodiak and monaco
https://lore.kernel.org/lkml/20260310113557.348502-1-neeraj.soni@oss.qualcomm.com/
Signed-off-by: Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
---
Changes in v2:
- Reorder clocks entries in different lines.
- Add power-domain as it's mandatory DT property as per new bindings.
- Drop reviewed-by tags as patchset has some extra changes.
- Link to v1: https://patch.msgid.link/20260406-ice_emmc_clock_addition-v1-0-e7b237bf7a69@oss.qualcomm.com
---
Kuldeep Singh (2):
arm64: dts: qcom: kodiak: Add iface clock and power domain for ice sdhc
arm64: dts: qcom: monaco: Add iface clock and power domain for ice sdhc
arch/arm64/boot/dts/qcom/kodiak.dtsi | 6 +++++-
arch/arm64/boot/dts/qcom/monaco.dtsi | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
---
base-commit: 816f193dd0d95246f208590924dd962b192def78
change-id: 20260406-ice_emmc_clock_addition-e19f36c1fca5
Best regards,
--
Kuldeep Singh <kuldeep.singh@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 5/9] dt-bindings: pinctrl: apple,pinctrl: Add t8122 compatible
From: Linus Walleij @ 2026-04-09 8:27 UTC (permalink / raw)
To: Janne Grunau
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Lorenzo Pieralisi,
Sven Peter, Neal Gompa, Wim Van Sebroeck, Guenter Roeck,
Mark Kettenis, Andi Shyti, Uwe Kleine-König,
Sasha Finkelstein, devicetree, linux-kernel, asahi,
linux-arm-kernel, linux-watchdog, linux-gpio, linux-i2c,
linux-pwm
In-Reply-To: <20260320-apple-m3-initial-devicetrees-v1-5-5842e1e393a8@jannau.net>
On Fri, Mar 20, 2026 at 1:23 PM Janne Grunau <j@jannau.net> wrote:
> The pin controller on the Apple silicon t8122 (M3) SoC is compatible
> with the existing driver. Add "apple,t8122-pinctrl" as SoC specific
> compatible under "apple,t8103-pinctrl" used by the driver.
>
> Signed-off-by: Janne Grunau <j@jannau.net>
This patch applied to the pinctrl tree for v7.1.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] dt-bindings: i2c: nxp,pca9564: convert to DT schema
From: Krzysztof Kozlowski @ 2026-04-09 8:26 UTC (permalink / raw)
To: Akhila YS
Cc: Andi Shyti, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Peter Rosin, linux-i2c, devicetree, linux-kernel
In-Reply-To: <20260408-i2c-nxp-v1-1-8276ccbd95fb@gmail.com>
On Wed, Apr 08, 2026 at 08:23:31AM +0000, Akhila YS wrote:
> Convert NXP PCA PCA9564/PCA9665 I2C controller to YAML format.
DT schema, not YAML format. Look at your subject.
...
> + reg:
> + maxItems: 1
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + interrupts:
> + maxItems: 1
> +
> + reset-gpios:
> + maxItems: 1
> +
> + clock-frequency:
> + default: 100000
> +
> +required:
> + - compatible
> + - reg
> +
> +additionalProperties: false
And if you tested any DTS with this, you would see this cannot work.
Look at other bindings - you miss ref to i2c-controller and
unevaluatedProps. But the problem is that you are doing something which
would never work, so I have doubts that you know what you are doing. One
thing is to make a mistake, other thing is to post something can never
work thus putting quite noticeable requirements on review.
Please first learn how DTS and DT bindings work, before you post new
patches.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6/6] arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
From: Luca Weiss @ 2026-04-09 8:26 UTC (permalink / raw)
To: Dmitry Baryshkov, Luca Weiss
Cc: Alex Elder, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Alexander Koskovich,
~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <ku4w5dbfk4ihxfslyf7lcxtxnbzabim5mmtm7xlhqbnmav36iv@zt3dky3vbfbo>
Hi Dmitry,
On Fri Apr 3, 2026 at 9:27 PM CEST, Dmitry Baryshkov wrote:
> On Fri, Apr 03, 2026 at 06:43:52PM +0200, Luca Weiss wrote:
>> Configure and enable the node for IPA which enables mobile data on this
>> device.
>>
>> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
>> ---
>> arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts | 9 +++++++++
>> 1 file changed, 9 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> index c1899db46e71..31c6d6627619 100644
>> --- a/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> +++ b/arch/arm64/boot/dts/qcom/milos-fairphone-fp6.dts
>> @@ -690,6 +690,15 @@ vreg_l7p: ldo7 {
>> /* AW86938FCR vibrator @ 0x5a */
>> };
>>
>> +&ipa {
>> + firmware-name = "qcom/milos/fairphone/fp6/ipa_fws.mbn";
>> + memory-region = <&ipa_fw_mem>;
>> +
>> + qcom,gsi-loader = "self";
>
> Are these two common to all Milos devices? Should they be a part of the
> milos.dtsi?
All qcom,gsi-loader properties are in device .dts (or device-common
.dtsi) files, never in SoC .dtsi files. Based on this, I guess it would
mostly differ based on the boot firmware used. If Linux is booted in
EL2, then probably it needs to be changed?
Regards
Luca
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: qcom: sdm845-lg: Enable qcom,snoc-host-cap-skip-quirk
From: Konrad Dybcio @ 2026-04-09 8:18 UTC (permalink / raw)
To: Paul Sajna, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jeff Johnson, Dmitry Baryshkov,
David Heidelberg
Cc: linux-arm-msm, devicetree, linux-kernel, phone-devel,
~postmarketos/upstreaming
In-Reply-To: <20260408-judyln-followup-v1-4-823467519b59@postmarketos.org>
On 4/9/26 4:41 AM, Paul Sajna wrote:
> The WCN3990 firmware for judyln does not respond to the request for
> host capabilities. Add the devicetree quirk to skip this request.
>
> Signed-off-by: Paul Sajna <sajattack@postmarketos.org>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Krzysztof Kozlowski @ 2026-04-09 8:17 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-2-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:16AM +0200, Gregor Herburger wrote:
> Raspberry Pis have OTP registers which can be accessed through the
> videocore firmware. Add a nvmem driver to support these OTP registers.
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> drivers/nvmem/Kconfig | 12 +++
> drivers/nvmem/Makefile | 1 +
> drivers/nvmem/raspberrypi-otp.c | 159 +++++++++++++++++++++++++++++
> include/soc/bcm2835/raspberrypi-firmware.h | 2 +
> 4 files changed, 174 insertions(+)
>
> diff --git a/drivers/nvmem/Kconfig b/drivers/nvmem/Kconfig
> index 74ddbd0f79b0..892d05fe67be 100644
> --- a/drivers/nvmem/Kconfig
> +++ b/drivers/nvmem/Kconfig
> @@ -483,4 +483,16 @@ config NVMEM_QORIQ_EFUSE
> This driver can also be built as a module. If so, the module
> will be called nvmem_qoriq_efuse.
>
> +config NVMEM_RASPBERRYPI_OTP
> + tristate "Raspberry Pi OTP support"
> + # Make sure not 'y' when RASPBERRYPI_FIRMWARE is 'm'. This can only
> + # happen when COMPILE_TEST=y, hence the added !RASPBERRYPI_FIRMWARE.
Drop comment and use standard rules for multiple modules.
https://lwn.net/Articles/944368/
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/2] arm64: dts: marvell: armada-37xx: USB3 PHY cleanup
From: Gregory CLEMENT @ 2026-04-09 8:15 UTC (permalink / raw)
To: Gabor Juhos, Andrew Lunn, Sebastian Hesselbarth, Robert Marko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Greg Kroah-Hartman, Stanley Chang
Cc: linux-arm-kernel, devicetree, linux-kernel, Gabor Juhos
In-Reply-To: <20260330-armada-37xx-usb3-phy-cleanup-v1-0-34d77f1a1784@gmail.com>
Gabor Juhos <j4g8y7@gmail.com> writes:
> There are two small patches in the series. The first helps to avoid
> triggering a bug in the USB core code, whereas the second one is a
> small cleanup to align PHY definitions of the USB3 node with other
> platforms.
>
> Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
> ---
> Gabor Juhos (2):
> arm64: dts: marvell: armada-37xx: use 'usb2-phy' in USB3 controller's phy-names
> arm64: dts: marvell: armada-37xx: swap PHYs' order in USB3 controller node
>
> arch/arm64/boot/dts/marvell/armada-3720-uDPU.dtsi | 2 +-
> arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 4 ++--
> 2 files changed, 3 insertions(+), 3 deletions(-)
Applied on mvebu/dt64
Thanks,
Gregory
> ---
> base-commit: 2ff6cc999a04bcb094b8cbba68a9251f03a5c876
> change-id: 20260330-armada-37xx-usb3-phy-cleanup-922a5472794a
>
> Best regards,
> --
> Gabor Juhos <j4g8y7@gmail.com>
>
--
Grégory CLEMENT, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 3/3] arm64: dts: broadcom: bcm2712: Add the otp nodes to firmware
From: Krzysztof Kozlowski @ 2026-04-09 8:15 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-3-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:17AM +0200, Gregor Herburger wrote:
> The Raspberry Pi 5 has two OTP registers (private and customer), add these
> to the devicetree.
So this sentence confirms my question on bindings - your device
raspberrypi,bcm2835-firmware has these, thus you do not need these child
nodes at all. Neither compatibles.
Drop entire DTS and binding patches.
See also writing-bindings and DTS101 why we do not allow this.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: nvmem: Add a binding for the RPi Firmware OTP register
From: Krzysztof Kozlowski @ 2026-04-09 8:13 UTC (permalink / raw)
To: Gregor Herburger
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Eric Anholt, Stefan Wahren, Srinivas Kandagatla, devicetree,
linux-rpi-kernel, linux-arm-kernel, linux-kernel
In-Reply-To: <20260408-rpi-otp-driver-v1-1-e02d1dbe6008@linutronix.de>
On Wed, Apr 08, 2026 at 10:00:15AM +0200, Gregor Herburger wrote:
> The firmware running on the Raspberry Pi VideoCore can be used to access
> OTP registers. There are two OTP regions (private and customer). Add a
> binding for these.
A nit, subject: drop second/last, redundant "a binding for the". The
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Signed-off-by: Gregor Herburger <gregor.herburger@linutronix.de>
> ---
> .../bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> index 983ea80eaec9..975c8927d75b 100644
> --- a/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> +++ b/Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.yaml
> @@ -137,6 +137,20 @@ required:
> - compatible
> - mboxes
>
> +patternProperties:
> + "^otp-(customer|private)$":
Not a pattern but just "otp".
> + type: object
> + additionalProperties: false
> +
> + properties:
> + compatible:
> + enum:
> + - raspberrypi,firmware-otp-customer
> + - raspberrypi,firmware-otp-private
I don't understand why having OTP regions is not deducible from
top-level compatible. I also do not get why do you need per OTP
compatible.
There are no resources here, so standard review would be "no" and you
need strong justification in terms of DT.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: iommu: arm-smmu-v3: Allow PMU child nodes
From: Krzysztof Kozlowski @ 2026-04-09 8:10 UTC (permalink / raw)
To: Peng Fan (OSS)
Cc: Will Deacon, Robin Murphy, Joerg Roedel, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Mark Rutland, linux-arm-kernel,
iommu, devicetree, linux-kernel, linux-perf-users, Peng Fan
In-Reply-To: <20260408-smmu-perf-v1-1-d75dac96e828@nxp.com>
On Wed, Apr 08, 2026 at 03:51:15PM +0800, Peng Fan (OSS) wrote:
> From: Peng Fan <peng.fan@nxp.com>
>
> The Arm SMMU v3 specification defines an optional PMCG (Performance
"optional" in a meaning some SMMUv3 implementations do not have it?
> Monitor Control Group) block. Per MMU-700 TRM, it has three 64KB pages,
> with TCU Performance Monitor Counter Group (PMCG) registers starting at
> offset 0x02000 in page 0. So PMCG could be described as a child node of the
> SMMU in Devicetree.
>
> Add a patternProperties entry to the arm,smmu-v3 binding to allow child
> nodes matching "pmu@<addr>" and reference the existing
> arm,smmu-v3-pmcg.yaml schema.
>
> Signed-off-by: Peng Fan <peng.fan@nxp.com>
> ---
> Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> index 82957334bea24402b583e47eb61b5724c91e4378..1d09c5476e5f1a7c3e5c935b677641ee6cc9897e 100644
> --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml
> @@ -50,6 +50,10 @@ properties:
> - cmdq-sync # CMD_SYNC complete
> - priq # PRI Queue not empty
>
> + '#address-cells': true
Instead enum [1, 2]
> + '#size-cells': true
Same here
> + ranges: true
I guess only one mapping is allowed so:
maxItems: 1
> +
> '#iommu-cells':
> const: 1
>
> @@ -83,6 +87,12 @@ properties:
> register access with page 0 offsets. Set for Cavium ThunderX2 silicon that
> doesn't support SMMU page1 register space.
>
> +patternProperties:
> + '^pmu@[0-9a-f]+$':
> + type: object
> + $ref: /schemas/perf/arm,smmu-v3-pmcg.yaml#
> + unevaluatedProperties: false
Please add another example with 4-space indentation.
> +
> allOf:
> - if:
> not:
>
> --
> 2.37.1
>
^ permalink raw reply
* Re: [PATCH v4 net-next 10/14] net: dsa: netc: introduce NXP NETC switch driver for i.MX94
From: Vladimir Oltean @ 2026-04-09 8:07 UTC (permalink / raw)
To: Wei Fang
Cc: Jakub Kicinski, Claudiu Manoil, Clark Wang, andrew+netdev@lunn.ch,
davem@davemloft.net, edumazet@google.com, pabeni@redhat.com,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
f.fainelli@gmail.com, Frank Li, chleroy@kernel.org,
horms@kernel.org, linux@armlinux.org.uk, andrew@lunn.ch,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
linux-arm-kernel@lists.infradead.org, imx@lists.linux.dev
In-Reply-To: <AM8PR04MB72840DBFC7F3FD578DFF6AF8885BA@AM8PR04MB7284.eurprd04.prod.outlook.com>
On Wed, Apr 08, 2026 at 11:59:24AM +0300, Wei Fang wrote:
> > > +static int netc_init_switch_id(struct netc_switch *priv)
> > > +{
> > > + struct netc_switch_regs *regs = &priv->regs;
> > > + struct dsa_switch *ds = priv->ds;
> > > +
> > > + /* The value of 0 is reserved for the VEPA switch and cannot
> > > + * be used.
> > > + */
> > > + if (ds->index > SWCR_SWID || !ds->index) {
> > > + dev_err(priv->dev, "Switch index %d out of range\n",
> > > + ds->index);
> > > + return -ERANGE;
> > > + }
> >
> > Does this check cause the probe to fail unconditionally for standard
> > single-switch topologies?
> >
> > The DSA core typically assigns ds->index = 0 by default for the first switch.
> > Because !ds->index evaluates to true for index 0, this setup function will
> > always fail unless the dsa,member property is explicitly overridden in the
> > device tree.
>
> As I mentioned in another mail, we added the 'dsa,member' property to the
> netc switch DT-binding doc, specifying that the 'member' (switch index) value
> cannot be 0. And 'dsa,member' is a required property for netc switch.
>
> >
> > Could the driver translate the hardware ID internally, for example by writing
> > ds->index + 1 to NETC_SWCR, rather than forcing this hardware-specific
> > restriction onto the software DSA index?
>
> The current approach is based on Vladimir's suggestion. I need to confirm with
> Vladimir which approach is better.
>
> Hi Vladimir,
>
> What are your thoughts on this suggestion? Is this approach better?
I maintain it is preferable/simpler the way you are doing it, with a 1:1 mapping.
The LLM's concern would be more valid if the switch were discrete and every
board DTS author would have to remember to place the dsa,member property.
But the switch OF node will live in an SoC dtsi.
Maybe you could put something along these lines in the commit message,
hopefully the LLM will pick it up and stop complaining.
^ permalink raw reply
* Re: [PATCH 2/3] nvmem: Add the Raspberry Pi OTP driver
From: Gregor Herburger @ 2026-04-09 8:05 UTC (permalink / raw)
To: Stefan Wahren
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Florian Fainelli,
Ray Jui, Scott Branden, Broadcom internal kernel review list,
Srinivas Kandagatla, devicetree, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
In-Reply-To: <90f54202-6eb6-4c44-b029-a4e0dafad861@gmx.net>
On Wed, Apr 08, 2026 at 10:03:47PM +0200, Stefan Wahren wrote:
> Am 08.04.26 um 21:47 schrieb Gregor Herburger:
> > Hi Stefan,
> >
> > thanks for the review.
> > > Is there any reason, why we cannot register this driver in
> > > rpi_firmware_probe() like hwmon and clk driver?
> > >
> > > I like to avoid the complete dt-binding from patch 1.
> > The private OTP registers are not available on all Raspberries. Afaik
> > only on 4 and 5. So I think these registers must be described through
> > the device tree. Therefore the bindings are needed.
> This binding doesn't represent some kind of hardware, it's just some
> firmware interface. A proper DT binding would describe the MMIO address
> range for OTP access.
I think it does represent real hardware. Although it is hidden through the
firmware. Not all hardware must be MMIO addresses.
The only driver that does not have a DT node is the hwmon driver. All
other drivers (clock, gpio, touchscreeen, reset, pwm) do have a DT
binding. Looking at the comment in rpi_register_clk_driver this
seems to be some legacy behaviour for older DTs for the clock driver.
> If you need some distinction between the Raspberry Pi generations there are
> firmware tags to do this.
So what is your suggestion? What tags do you mean?
I don't understand why you want to avoid the dt-binding. What is the
problem with dt-bindings?
What is the benefit of registering the driver in rpi_firmware_probe?
Imho describing this in the DT is the more natural way to do this. E.g.
if in the future there is a raspberry pi with a 64Byte otp it could easily
be supported by adding a devicetree property and add it to the driver.
Regards
Gregor
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: timestamp: Add Tegra264 support
From: Krzysztof Kozlowski @ 2026-04-09 8:05 UTC (permalink / raw)
To: Suneel Garapati
Cc: dipenp, jonathanh, thierry.reding, krzk+dt, conor+dt, amhetre,
sheetal, kkartik, robh, pshete, timestamp, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <20260408212413.217692-2-suneelg@nvidia.com>
On Wed, Apr 08, 2026 at 09:24:11PM +0000, Suneel Garapati wrote:
> Add timestamp provider support for the Tegra264 in devicetree
> bindings. Tegra264 has two generic timestamping engines (GTE)
> which are the always-on GTE (AON) and legacy interrupt
> controller (LIC) GTE.
> 'nvidia,slices' property is deprecated and hence not allowed for
> Tegra264.
>
> Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ 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