* 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
* Re: [PATCH v2 1/2] dt-bindings: fpga: Technologic Systems TS-7300 FPGA Manager
From: Krzysztof Kozlowski @ 2026-04-09 8:03 UTC (permalink / raw)
To: Phil Pemberton
Cc: Moritz Fischer, Xu Yilun, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tom Rix, Florian Fainelli, linux-fpga, devicetree,
linux-kernel
In-Reply-To: <20260408165223.3051759-2-philpem@philpem.me.uk>
On Wed, Apr 08, 2026 at 05:52:22PM +0100, Phil Pemberton wrote:
> Add device tree binding documentation for the Altera Cyclone II FPGA
> found on Technologic Systems (now EmbeddedTS) TS-7300 boards, programmed
> via the memory-mapped interface in the CPLD.
Subject - I did not ask to drop "Add". The subject makes little sense now.
With subject fixed:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
<form letter>
This is an automated instruction, just in case, because many review
tags are being ignored. If you know the process, just skip it entirely
(please do not feel offended by me posting it here - no bad intentions
intended, no patronizing, I just want to avoid wasted efforts). If you
do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here ('b4 trailers -u ...').
However, there's no need to repost patches *only* to add the tags. The
upstream maintainer will do that for tags received on the version they
apply.
https://elixir.bootlin.com/linux/v6.15/source/Documentation/process/submitting-patches.rst#L591
</form letter>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2 0/2] Add device tree binding for ts73xx-fpga
From: Krzysztof Kozlowski @ 2026-04-09 8:01 UTC (permalink / raw)
To: Phil Pemberton
Cc: Moritz Fischer, Xu Yilun, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Tom Rix, Florian Fainelli, linux-fpga, devicetree,
linux-kernel
In-Reply-To: <20260408165223.3051759-1-philpem@philpem.me.uk>
On Wed, Apr 08, 2026 at 05:52:21PM +0100, Phil Pemberton wrote:
> The driver for the Technologic Systems (EmbeddedTS) TS-7300 board's
> onboard FPGA didn't have an OF match table. This prevented it from being
> instantiated from a device tree. This is undesirable given EP93xx is
> moving to device tree, and effectively prevents it from being used.
> This patch series adds the OF match table and a device tree binding.
>
> Changes since v1:
> - Use specific compatible "technologic,ts7300-fpga" instead of
> wildcard "technologic,ts73xx-fpga" (Krzysztof)
> - Fix subject line for dt-bindings patch (Krzysztof)
> - Simplify example in binding doc (Krzysztof)
Missing explanation of dropping tags.
<form letter>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here. However, there's no
need to repost patches *only* to add the tags. The upstream maintainer
will do that for tags received on the version they apply.
Please read:
https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state in the patch changelog
or cover letter why and what changed.
</form letter>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 0/6] IPA v5.2 support for Milos and Fairphone (Gen. 6)
From: patchwork-bot+netdevbpf @ 2026-04-09 8:00 UTC (permalink / raw)
To: Luca Weiss
Cc: elder, andrew+netdev, davem, edumazet, kuba, pabeni, robh,
krzk+dt, conor+dt, andersson, konradybcio, akoskovich,
~postmarketos/upstreaming, phone-devel, netdev, linux-kernel,
linux-arm-msm, devicetree
In-Reply-To: <20260403-milos-ipa-v1-0-01e9e4e03d3e@fairphone.com>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 03 Apr 2026 18:43:46 +0200 you wrote:
> First, two fixes that unbreak IPA v5.0+, which can be applied
> independently.
>
> Then add support for IPA v5.2 which can be found in the Milos SoC. And
> finally enable it on Fairphone (Gen. 6) so that mobile data (4G/5G/..)
> starts working.
>
> [...]
Here is the summary with links:
- [1/6] net: ipa: fix GENERIC_CMD register field masks for IPA v5.0+
https://git.kernel.org/netdev/net/c/9709b56d908a
- [2/6] net: ipa: fix event ring index not programmed for IPA v5.0+
https://git.kernel.org/netdev/net/c/56007972c0b1
- [3/6] dt-bindings: net: qcom,ipa: add Milos compatible
(no matching commit)
- [4/6] net: ipa: add IPA v5.2 configuration data
(no matching commit)
- [5/6] arm64: dts: qcom: milos: Add IPA node
(no matching commit)
- [6/6] arm64: dts: qcom: milos-fairphone-fp6: Enable IPA
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [5/6] arm64: dts: qcom: milos: Add IPA node
From: Krzysztof Kozlowski @ 2026-04-09 8:00 UTC (permalink / raw)
To: Paolo Abeni, luca.weiss
Cc: krzk+dt, akoskovich, konradybcio, linux-kernel, conor+dt,
devicetree, andersson, netdev, kuba, linux-arm-msm, andrew+netdev,
davem, robh, edumazet, ~postmarketos/upstreaming, phone-devel,
elder
In-Reply-To: <20260409075854.308955-1-pabeni@redhat.com>
On 09/04/2026 09:58, Paolo Abeni wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
...
>> +
>> + qcom,smem-states = <&smp2p_ipa_out 0>,
>> + <&smp2p_ipa_out 1>;
>> + qcom,smem-state-names = "ipa-clock-enabled-valid",
>> + "ipa-clock-enabled";
>> +
>> + sram = <&ipa_modem_tables>;
>> ^^^^^^^^^^^^^^^^^^
>
> Is the ipa_modem_tables label defined anywhere? The Device Tree Compiler
> will fail with "Reference to non-existent node or label
> 'ipa_modem_tables'" if this label doesn't exist.
Paul, please ignore all of such review from AI tools. It is completely
wrong and pointless.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [5/6] arm64: dts: qcom: milos: Add IPA node
From: Paolo Abeni @ 2026-04-09 7:58 UTC (permalink / raw)
To: luca.weiss
Cc: pabeni, krzk+dt, akoskovich, konradybcio, linux-kernel, conor+dt,
devicetree, andersson, netdev, kuba, linux-arm-msm, andrew+netdev,
davem, robh, edumazet, ~postmarketos/upstreaming, phone-devel,
elder
In-Reply-To: <20260403-milos-ipa-v1-5-01e9e4e03d3e@fairphone.com>
This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
---
arm64: dts: qcom: milos: Add IPA node
Add the description of the IPA block in the Milos SoC.
> diff --git a/arch/arm64/boot/dts/qcom/milos.dtsi b/arch/arm64/boot/dts/qcom/milos.dtsi
> index e1a51d43943f..a244e136a877 100644
> --- a/arch/arm64/boot/dts/qcom/milos.dtsi
> +++ b/arch/arm64/boot/dts/qcom/milos.dtsi
> @@ -1281,6 +1281,50 @@ adreno_smmu: iommu@3da0000 {
> dma-coherent;
> };
>
> + ipa: ipa@3f40000 {
> + compatible = "qcom,milos-ipa";
> +
> + reg = <0x0 0x03f40000 0x0 0x10000>,
> + <0x0 0x03f50000 0x0 0x5000>,
> + <0x0 0x03e04000 0x0 0xfc000>;
> + reg-names = "ipa-reg",
> + "ipa-shared",
> + "gsi";
> +
> + interrupts-extended = <&intc GIC_SPI 654 IRQ_TYPE_EDGE_RISING 0>,
> + <&intc GIC_SPI 432 IRQ_TYPE_LEVEL_HIGH 0>,
> + <&smp2p_ipa_in 0 IRQ_TYPE_EDGE_RISING>,
> + <&smp2p_ipa_in 1 IRQ_TYPE_EDGE_RISING>;
> + interrupt-names = "ipa",
> + "gsi",
> + "ipa-clock-query",
> + "ipa-setup-ready";
> +
> + clocks = <&rpmhcc RPMH_IPA_CLK>;
> + clock-names = "core";
> +
> + interconnects = <&aggre2_noc MASTER_IPA QCOM_ICC_TAG_ALWAYS
> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> + &cnoc_main SLAVE_IPA_CFG QCOM_ICC_TAG_ACTIVE_ONLY>;
> + interconnect-names = "memory",
> + "config";
> +
> + iommus = <&apps_smmu 0x4a0 0x0>,
> + <&apps_smmu 0x4a2 0x0>;
> +
> + qcom,qmp = <&aoss_qmp>;
> +
> + qcom,smem-states = <&smp2p_ipa_out 0>,
> + <&smp2p_ipa_out 1>;
> + qcom,smem-state-names = "ipa-clock-enabled-valid",
> + "ipa-clock-enabled";
> +
> + sram = <&ipa_modem_tables>;
> ^^^^^^^^^^^^^^^^^^
Is the ipa_modem_tables label defined anywhere? The Device Tree Compiler
will fail with "Reference to non-existent node or label
'ipa_modem_tables'" if this label doesn't exist.
The sram property is optional according to the qcom,ipa.yaml binding, and
other similar Qualcomm SoCs like SM8350, SM8550, and SM8650 don't include
this property in their IPA nodes. Should this line be removed, or does the
ipa_modem_tables node need to be added to the reserved-memory section?
> +
> + status = "disabled";
> + };
> +
[ ... ]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: pinctrl: qcom: Describe Hawi TLMM block
From: Krzysztof Kozlowski @ 2026-04-09 7:59 UTC (permalink / raw)
To: Mukesh Ojha
Cc: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260408-hawi-pinctrl-v2-1-fd7f681f5e05@oss.qualcomm.com>
On Wed, Apr 08, 2026 at 07:45:47PM +0530, Mukesh Ojha wrote:
> The Top Level Mode Multiplexer (TLMM) in the Qualcomm Hawi SoC
> provides GPIO and pinctrl functionality for UFS, SDC and 226
> GPIO pins.
>
> Add a DeviceTree binding to describe the TLMM block on Qualcomm's
> Hawi SoC.
>
> Signed-off-by: Mukesh Ojha <mukesh.ojha@oss.qualcomm.com>
> ---
> .../bindings/pinctrl/qcom,hawi-tlmm.yaml | 120 +++++++++++++++++++++
> 1 file changed, 120 insertions(+)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: i2c: cnxt,cx92755-i2c: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-04-09 7:52 UTC (permalink / raw)
To: Shi Hao
Cc: robh, krzk+dt, andi.shyti, conor+dt, linux-i2c, devicetree,
linux-kernel, daniel.baluta, simona.toaca, d-gole, m-chawdhry
In-Reply-To: <20260408083549.12815-1-i.shihao.999@gmail.com>
On Wed, Apr 08, 2026 at 02:05:49PM +0530, Shi Hao wrote:
> Convert the Conexant Digicolor I2C bindings to DT schema.
>
> Signed-off-by: Shi Hao <i.shihao.999@gmail.com>
> ---
>
<form letter>
This is a friendly reminder during the review process.
It looks like you received a tag and forgot to add it.
If you do not know the process, here is a short explanation:
Please add Acked-by/Reviewed-by/Tested-by tags when posting new
versions of patchset, under or above your Signed-off-by tag, unless
patch changed significantly (e.g. new properties added to the DT
bindings). Tag is "received", when provided in a message replied to you
on the mailing list. Tools like b4 can help here. However, there's no
need to repost patches *only* to add the tags. The upstream maintainer
will do that for tags received on the version they apply.
Please read:
https://elixir.bootlin.com/linux/v6.12-rc3/source/Documentation/process/submitting-patches.rst#L577
If a tag was not added on purpose, please state in the patch changelog
or cover letter why and what changed.
</form letter>
You missed Rob's tag.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite VAR-SOM-MX91
From: Stefano Radaelli @ 2026-04-09 7:48 UTC (permalink / raw)
To: Frank Li
Cc: linux-kernel, devicetree, imx, linux-arm-kernel, pierluigi.p,
Stefano Radaelli, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam, Shawn Guo,
Dario Binacchi, Markus Niebel, Maud Spierings, Alexander Stein,
Ernest Van Hoecke, Josua Mayer, Francesco Dolcini, Primoz Fiser
In-Reply-To: <adcdWdTcVR2T2F5c@lizhi-Precision-Tower-5810>
Hi Frank!
On Wed, Apr 08, 2026 at 11:30:33PM -0400, Frank Li wrote:
>
> what' difference with imx93-var-som ? Can you reuse it?
>
The imx91-var-som is conceptually similar to imx93-var-som, and I used
it as a reference while preparing this DTS.
However, it cannot be directly reused as there are several hardware
differences between the two platforms, including SoC integration and
peripheral configuration (e.g. pinctrl, and available IPs).
So a separate description is required for imx91.
Best regards,
Stefano
^ 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