* Re: [PATCH v9 2/9] lib: vsprintf: export simple_strntoull() in a safe prototype
From: Andy Shevchenko @ 2026-03-27 9:17 UTC (permalink / raw)
To: Petr Mladek
Cc: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc,
Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Steven Rostedt, Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <acZDneLrIPOmU5ci@pathway.suse.cz>
On Fri, Mar 27, 2026 at 09:45:17AM +0100, Petr Mladek wrote:
> On Fri 2026-03-20 16:27:27, Rodrigo Alencar via B4 Relay wrote:
...
> > +extern ssize_t __must_check simple_strntoull(const char *startp, const char **endp,
> > + unsigned int base, size_t max_chars,
> > + unsigned long long *res);
>
> Sigh, naming is hard. I personally find it a bit confusing that the
> name is too similar to the unsafe API.
>
> IMHO, the semantic of the new API is closer to kstrtoull().
> It just limits the size, so I would call it kstrntoull().
It's not. kstrto*() quite strict about the input, this one is actually relaxed
variant, so I wouldn't mix these two groups.
> Also I would use int as the return parameter, see below.
...
TBH, I am skeptical about this approach. My main objection is max_chars
parameter. If we want to limit the input strictly to the given number of
characters, we have to copy the string and then just use kstrto*() in a normal
way. The whole idea of that parameter is to be able to parse the fractional
part of the float number as 'iiiii.fffff', where 'i' is for integer part, and
'f' for the fractional. Since we have *endp, we may simply check that.
In case if we want to parse only, say, 6 digits and input is longer there are
a few options (in my personal preferences, the first is the better):
- consider the input invalid
- parse it as is up to the maximum and then do ceil() or floor() on top of that
- copy only necessary amount of the (sub)string and parse that.
The problem with precision is that we need to also consider floor() or ceil()
and I don't think this should be burden of the library as it's individual
preference of each of the callers (users). At least for the starter, we will
see if it's only one approach is used, we may incorporate it into the library
code.
The easiest way out is to just consider the input invalid if it overflows the
given type (s32 or s64).
But we need to have an agreement what will be the representation of the
fixed-width float numbers in the kernel? Currently IIO uses
struct float // name is crafted for simplicity
{
int integer;
int fraction;
}
This parser wants AFAIU to have at the end of the day something like
struct float
{
s64 integer;
s64 fraction;
}
but also wants to have the fraction part be limited in some cases to s32
or so:
struct float
{
s64 integer;
s32 fraction; // precision may be lost if input is longer
}
Maybe we want to have kstrtof32() and kstrtof64() for these two cases?
With that we will always consider the fraction part as 32- or 64-bit,
imply floor() on the fraction for the sake of simplicity and require
it to be NUL-terminated with possible trailing '\n'.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH v6] arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
From: MidG971 @ 2026-03-27 9:11 UTC (permalink / raw)
To: heiko
Cc: linux-rockchip, linux-arm-kernel, devicetree, shawn.lin, jonas,
Midgy BALON
From: Midgy BALON <midgy971@gmail.com>
The Radxa ROCK 3B uses a PI6C20100 PCIe reference clock buffer to
provide a 100MHz reference clock to the PCIe 3.0 PHY and controllers.
This chip is currently modeled only as a fixed regulator
(vcc3v3_pi6c_03), with no clock output representation.
The PI6C20100 is a clock generator, not a power supply. Model it
properly as a gated-fixed-clock, following the pattern established
for the Rock 5 ITX and other boards with similar PCIe clock buffer
chips.
The gated-fixed-clock node references the regulator as its vdd-supply,
allowing the regulator to be enabled on demand. Remove the
regulator-always-on and regulator-boot-on properties from vcc3v3_pi6c_03
since the clock framework will manage the regulator lifecycle via
vdd-supply. The pcie3x2 node is updated to include the pipe and
reference clocks, matching the approach used in rk3588-rock-5-itx.dts.
Assisted-by: Claude:claude-3-opus
Signed-off-by: Midgy BALON <midgy971@gmail.com>
---
Changes since v5:
- Drop "(100MHz)" from clock node comment, already in clock-frequency (Jonas)
- Drop redundant comment before vcc3v3_pi6c_03 (Jonas)
- Remove regulator-always-on and regulator-boot-on from vcc3v3_pi6c_03 (Jonas)
- Drop Reviewed-by (patch has functional changes since v3 review)
Changes since v4:
- Fix From: line to match Signed-off-by (Heiko)
Changes since v3 [1]:
- Add Reviewed-by from Shawn Lin
Changes since v2 [2]:
- Fix AI attribution: use Assisted-by tag instead of Signed-off-by (Shawn)
- Add missing pipe clock (CLK_PCIE30X2_PIPE_DFT) to pcie3x2 clocks
override (Shawn, referencing David's patch [3])
Changes since v1 [4]:
- Drop phy-supply approach entirely (Jonas, Shawn)
- Model PI6C20100 as gated-fixed-clock instead
- Wire reference clock to pcie3x2 controller
- Follow pattern from rk3588-rock-5-itx.dts
[1] https://lore.kernel.org/linux-rockchip/20260304132957.684616-1-midgy971@gmail.com/
[2] https://lore.kernel.org/linux-rockchip/20260304132957.684616-1-midgy971@gmail.com/
[3] https://lore.kernel.org/linux-rockchip/d981fa84-bd05-ac9d-98ca-89ee47177829@rock-chips.com/T/#m6a8289609e6a60691d3c06358b6322c7aa5e43d1
[4] https://lore.kernel.org/linux-rockchip/20260213151452.535527-1-midgy971@gmail.com/
.../boot/dts/rockchip/rk3568-rock-3b.dts | 20 ++++++++++++++++---
1 file changed, 17 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
index 3d0c1ccfa..d7d85b090 100644
--- a/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts
@@ -56,7 +56,15 @@ led-0 {
};
};
- /* pi6c pcie clock generator */
+ /* PI6C20100 PCIe reference clock buffer */
+ pcie30_refclk: pcie-clock-generator {
+ compatible = "gated-fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ clock-output-names = "pcie30_refclk";
+ vdd-supply = <&vcc3v3_pi6c_03>;
+ };
+
vcc3v3_pi6c_03: regulator-3v3-vcc-pi6c-03 {
compatible = "regulator-fixed";
enable-active-high;
@@ -64,8 +72,6 @@ vcc3v3_pi6c_03: regulator-3v3-vcc-pi6c-03 {
pinctrl-names = "default";
pinctrl-0 = <&pcie_pwren_h>;
regulator-name = "vcc3v3_pi6c_03";
- regulator-always-on;
- regulator-boot-on;
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
startup-delay-us = <10000>;
@@ -545,6 +551,14 @@ &pcie30phy {
};
&pcie3x2 {
+ clocks = <&cru ACLK_PCIE30X2_MST>, <&cru ACLK_PCIE30X2_SLV>,
+ <&cru ACLK_PCIE30X2_DBI>, <&cru PCLK_PCIE30X2>,
+ <&cru CLK_PCIE30X2_AUX_NDFT>,
+ <&cru CLK_PCIE30X2_PIPE_DFT>,
+ <&pcie30_refclk>;
+ clock-names = "aclk_mst", "aclk_slv",
+ "aclk_dbi", "pclk", "aux",
+ "pipe", "ref";
pinctrl-names = "default";
pinctrl-0 = <&pcie30x2m1_pins>;
reset-gpios = <&gpio2 RK_PD6 GPIO_ACTIVE_HIGH>;
--
2.30.2
^ permalink raw reply related
* Re: [PATCH 0/7] Add vibrator, IR transmitter and USB-C handling in xiaomi-ginkgo
From: Konrad Dybcio @ 2026-03-27 9:11 UTC (permalink / raw)
To: barnabas.czeman
Cc: Biswapriyo Nath, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Pavel Machek,
Sean Young, Michael Turquette, Stephen Boyd, Martin Botka,
linux-arm-msm, devicetree, linux-kernel, linux-leds, linux-clk,
~postmarketos/upstreaming, phone-devel, kernel test robot
In-Reply-To: <cc0d9e1d8f85bf2b67df35b8d9c2110c@mainlining.org>
On 3/26/26 6:48 PM, barnabas.czeman@mainlining.org wrote:
> On 2026-03-26 10:39, Konrad Dybcio wrote:
>> On 3/25/26 7:07 PM, Biswapriyo Nath wrote:
>>> This patch series add support for various components in Xiaomi Redmi
>>> Note 8.
>>>
>>> Most notably:
>>> - IR transmitter
>>> - USB-C OTG
>>> - Vibrator
>>>
>>> Also, fix some bindings warning as reported due to previous commits.
>>> These are tested with linux-next tag next-20260320.
>>>
>>> Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
>>> ---
>>> Biswapriyo Nath (7):
>>> arm64: dts: qcom: sm6125-xiaomi-ginkgo: Enable vibrator
>>> arm64: dts: qcom: sm6125: Enable USB-C port handling
>>> arm64: dts: qcom: sm6125-xiaomi-ginkgo: Add PMI632 Type-C property
>>> dt-bindings: leds: irled: ir-spi-led: Add new duty-cycle value
>>> arm64: dts: qcom: sm6125-xiaomi-ginkgo: Add IR transmitter
>>> arm64: dts: qcom: sm6125: Use 64 bit addressing
>>> dt-bindings: clock: qcom, dispcc-sm6125: Add #reset-cells property
>>>
>>> .../bindings/clock/qcom,dispcc-sm6125.yaml | 3 +
>>> .../devicetree/bindings/leds/irled/ir-spi-led.yaml | 2 +-
>>> .../boot/dts/qcom/sm6125-xiaomi-ginkgo-common.dtsi | 56 +++++++
>>
>> I'm assuming all of these changes apply to both ginkgo and willow,
>> which both include ginkgo-common?
> All these change should work on both, willow is a ginkgo with NFC.
Thanks for confirming!
Konrad
^ permalink raw reply
* Re: [PATCH 4/4] arm64: dts: renesas: rzg2l-smarc: Fix missing cells and reg into DU subnode
From: Laurent Pinchart @ 2026-03-27 9:10 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-5-marek.vasut+renesas@mailbox.org>
On Thu, Mar 26, 2026 at 05:24:01AM +0100, Marek Vasut wrote:
> Add missing cells and reg DT property into DU subnode to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi:29.10-33.5: Warning (unit_address_vs_reg): /fragment@1/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi b/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
> index 36707576030d4..f5412578ee65f 100644
> --- a/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rz-smarc-du-adv7513.dtsi
> @@ -26,7 +26,12 @@ &du {
> status = "okay";
>
> ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> port@0 {
> + reg = <0>;
> +
> du_out_rgb: endpoint {
> remote-endpoint = <&adv7513_in>;
> };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 3/4] arm64: dts: renesas: rzg2l-smarc: Fix missing cells and reg into CSI2 subnode
From: Laurent Pinchart @ 2026-03-27 9:09 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-4-marek.vasut+renesas@mailbox.org>
On Thu, Mar 26, 2026 at 05:24:00AM +0100, Marek Vasut wrote:
> Add missing cells and reg DT property into CSI2 subnode to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi:49.10-55.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@0: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi b/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
> index 4d2b0655859ab..3feffa4f16a9a 100644
> --- a/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
> +++ b/arch/arm64/boot/dts/renesas/rz-smarc-cru-csi-ov5645.dtsi
> @@ -46,7 +46,12 @@ &csi2 {
> status = "okay";
>
> ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> port@0 {
> + reg = <0>;
> +
> csi2_in: endpoint {
> clock-lanes = <0>;
> data-lanes = <1 2>;
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 3/3] arm64: dts: imx93-var-dart: Add support for Variscite Sonata board
From: Stefano Radaelli @ 2026-03-27 9:08 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Primoz Fiser,
Francesco Dolcini
In-Reply-To: <cover.1774601806.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite Sonata carrier board with the
DART-MX93 system on module.
The Sonata board includes
- uSD Card support
- USB ports and OTG
- Additional Gigabit Ethernet interface
- Uart, SPI and I2C interfaces
- GPIO Expanders
- RTC module
- TPM module
- CAN peripherals
Link: https://variscite.com/carrier-boards/sonata-board/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
-
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx93-var-dart-sonata.dts | 654 ++++++++++++++++++
2 files changed, 655 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2da6dc4f8a14..266eddd745c9 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -487,6 +487,7 @@ imx93-tqma9352-mba91xxca-rgb-cdtech-dc44-dtbs := imx93-tqma9352-mba91xxca.dtb im
dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba91xxca-lvds-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-tqma9352-mba91xxca-rgb-cdtech-dc44.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx93-var-dart-sonata.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93-var-som-symphony.dtb
dtb-$(CONFIG_ARCH_MXC) += imx93w-evk.dtb
dtb-$(CONFIG_ARCH_MXC) += imx943-evk.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
new file mode 100644
index 000000000000..5513d3b148a2
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
@@ -0,0 +1,654 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Variscite Sonata carrier board for DART-MX93
+ *
+ * Link: https://variscite.com/carrier-boards/sonata-board/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include "imx93-var-dart.dtsi"
+
+/ {
+ model = "Variscite DART-MX93 on Sonata-Board";
+ compatible = "variscite,var-dart-mx93-sonata",
+ "variscite,var-dart-mx93",
+ "fsl,imx93";
+
+ aliases {
+ ethernet0 = &eqos;
+ ethernet1 = &fec;
+ gpio0 = &gpio1;
+ gpio1 = &gpio2;
+ gpio2 = &gpio3;
+ i2c0 = &lpi2c1;
+ i2c1 = &lpi2c2;
+ i2c2 = &lpi2c3;
+ i2c3 = &lpi2c4;
+ i2c4 = &lpi2c5;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ serial0 = &lpuart1;
+ serial1 = &lpuart2;
+ serial2 = &lpuart3;
+ serial3 = &lpuart4;
+ serial4 = &lpuart5;
+ serial5 = &lpuart6;
+ serial6 = &lpuart7;
+ };
+
+ chosen {
+ stdout-path = &lpuart1;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-home {
+ label = "Home";
+ linux,code = <KEY_HOME>;
+ gpios = <&pca6408_1 4 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-up {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ gpios = <&pca6408_1 5 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-down {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ gpios = <&pca6408_1 6 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-back {
+ label = "Back";
+ linux,code = <KEY_BACK>;
+ gpios = <&pca6408_1 7 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_leds_gpio>;
+
+ led-emmc {
+ gpios = <&gpio2 11 GPIO_ACTIVE_HIGH>;
+ label = "eMMC";
+ linux,default-trigger = "mmc0";
+ };
+ };
+
+ clk40m: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <40000000>;
+ clock-output-names = "can_osc";
+ };
+
+ reg_vref_1v8: regulator-adc-vref {
+ compatible = "regulator-fixed";
+ regulator-name = "vref_1v8";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
+ compatible = "regulator-fixed";
+ regulator-name = "VDD_SD2_3V3";
+ off-on-delay-us = <20000>;
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&gpio2 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ ethosu_mem: ethosu-region@88000000 {
+ compatible = "shared-dma-pool";
+ reusable;
+ reg = <0x0 0x88000000 0x0 0x8000000>;
+ };
+
+ vdev0vring0: vdev0vring0@87ee0000 {
+ reg = <0 0x87ee0000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: vdev0vring1@87ee8000 {
+ reg = <0 0x87ee8000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring0: vdev1vring0@87ef0000 {
+ reg = <0 0x87ef0000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring1: vdev1vring1@87ef8000 {
+ reg = <0 0x87ef8000 0 0x8000>;
+ no-map;
+ };
+
+ rsc_table: rsc-table@2021e000 {
+ reg = <0 0x2021e000 0 0x1000>;
+ no-map;
+ };
+
+ vdevbuffer: vdevbuffer@87f00000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x87f00000 0 0x100000>;
+ no-map;
+ };
+
+ ele_reserved: ele-reserved@87de0000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x87de0000 0 0x100000>;
+ no-map;
+ };
+ };
+};
+
+&adc1 {
+ vref-supply = <®_vref_1v8>;
+ status = "okay";
+};
+
+/* Use external instead of internal RTC */
+&bbnsm_rtc {
+ status = "disabled";
+};
+
+&eqos {
+ mdio {
+ ethphy1: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <1>;
+ reset-assert-us = <15000>;
+ reset-deassert-us = <100000>;
+ reset-gpios = <&pca6408_2 0 GPIO_ACTIVE_LOW>;
+
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+ };
+ };
+};
+
+ðphy0 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+};
+
+&fec {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_fec>;
+ pinctrl-1 = <&pinctrl_fec_sleep>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy1>;
+ status = "okay";
+};
+
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+ status = "okay";
+};
+
+&lpi2c1 {
+ clock-frequency = <400000>;
+ pinctrl-0 = <&pinctrl_lpi2c1>;
+ pinctrl-1 = <&pinctrl_lpi2c1_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c1_gpio>;
+ pinctrl-names = "default", "sleep", "gpio";
+ scl-gpios = <&gpio1 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio1 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca9534: gpio@22 {
+ compatible = "nxp,pca9534";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ /* Capacitive touch controller */
+ ft5x06_ts: touchscreen@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <27 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-0 = <&pinctrl_captouch>;
+ pinctrl-names = "default";
+ reset-gpios = <&pca6408_2 4 GPIO_ACTIVE_LOW>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ wakeup-source;
+ };
+
+ /* USB Type-C Controller */
+ typec@3d {
+ compatible = "nxp,ptn5150";
+ reg = <0x3d>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <29 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-0 = <&pinctrl_extcon>;
+ pinctrl-names = "default";
+
+ port {
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+
+ rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <2 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rtc>;
+ wakeup-source;
+ };
+};
+
+&lpi2c5 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c5>;
+ pinctrl-1 = <&pinctrl_lpi2c5_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c5_gpio>;
+ scl-gpios = <&gpio2 23 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 22 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+&lpi2c7 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c7>;
+ pinctrl-1 = <&pinctrl_lpi2c7_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c7_gpio>;
+ scl-gpios = <&gpio2 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca6408_1: gpio@20 {
+ compatible = "nxp,pcal6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ pca6408_2: gpio@21 {
+ compatible = "nxp,pcal6408";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ st33ktpm2xi2c: tpm@2e {
+ compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
+ reg = <0x2e>;
+ };
+};
+
+&lpspi8 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_lpspi8>;
+ cs-gpios = <&gpio2 1 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ /* CAN controller */
+ can0: can@0 {
+ compatible = "microchip,mcp251xfd";
+ reg = <0>;
+ clocks = <&clk40m>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can>;
+ spi-max-frequency = <1000000>;
+ };
+};
+
+/* Console (J10) */
+&lpuart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ status = "okay";
+};
+
+/* Header (J12.4, J12.6) */
+&lpuart6 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart6>;
+ status = "okay";
+};
+
+/* Header (J12.11, J12.13) */
+&lpuart7 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart7>;
+ status = "okay";
+};
+
+&tpm3 {
+ pinctrl-0 = <&pinctrl_tpm3>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usbotg1 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ disable-over-current;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ status = "okay";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usbotg2 {
+ disable-over-current;
+ dr_mode = "host";
+ status = "okay";
+};
+
+/* SD */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ bus-width = <4>;
+ no-sdio;
+ no-mmc;
+ status = "okay";
+};
+
+&wdog3 {
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hog>;
+
+ pinctrl_can: cangrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO03__GPIO2_IO03 0x31e
+ >;
+ };
+
+ pinctrl_captouch: captouchgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO2__GPIO3_IO27 0x31e
+ >;
+ };
+
+ pinctrl_extcon: extcongrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO4__GPIO4_IO29 0x31e
+ >;
+ };
+
+ pinctrl_fec: fecgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_RD0__ENET1_RGMII_RD0 0x57e
+ MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1 0x57e
+ MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2 0x57e
+ MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3 0x37e
+ MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC 0x58e
+ MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL 0x57e
+ MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0 0x57e
+ MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1 0x57e
+ MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2 0x57e
+ MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3 0x57e
+ MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC 0x58e
+ MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e
+ >;
+ };
+
+ pinctrl_fec_sleep: fecsleepgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_RD0__GPIO4_IO24 0x51e
+ MX93_PAD_ENET2_RD1__GPIO4_IO25 0x51e
+ MX93_PAD_ENET2_RD2__GPIO4_IO26 0x51e
+ MX93_PAD_ENET2_RD3__GPIO4_IO27 0x51e
+ MX93_PAD_ENET2_RXC__GPIO4_IO23 0x51e
+ MX93_PAD_ENET2_RX_CTL__GPIO4_IO22 0x51e
+ MX93_PAD_ENET2_TD0__GPIO4_IO19 0x51e
+ MX93_PAD_ENET2_TD1__GPIO4_IO18 0x51e
+ MX93_PAD_ENET2_TD2__GPIO4_IO17 0x51e
+ MX93_PAD_ENET2_TD3__GPIO4_IO16 0x51e
+ MX93_PAD_ENET2_TXC__GPIO4_IO21 0x51e
+ MX93_PAD_ENET2_TX_CTL__GPIO4_IO20 0x51e
+ >;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <
+ MX93_PAD_PDM_CLK__CAN1_TX 0x139e
+ MX93_PAD_PDM_BIT_STREAM0__CAN1_RX 0x139e
+ >;
+ };
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ /* GPIO Expanders shared IRQ */
+ MX93_PAD_PDM_BIT_STREAM1__GPIO1_IO10 0x31e
+ >;
+ };
+
+ pinctrl_leds_gpio: ledgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO11__GPIO2_IO11 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c1: lpi2c1grp {
+ fsl,pins = <
+ MX93_PAD_I2C1_SCL__LPI2C1_SCL 0x40000b9e
+ MX93_PAD_I2C1_SDA__LPI2C1_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c1_gpio: lpi2c1-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_I2C1_SCL__GPIO1_IO00 0x31e
+ MX93_PAD_I2C1_SDA__GPIO1_IO01 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c5: lpi2c5grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO22__LPI2C5_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO23__LPI2C5_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c5_gpio: lpi2c5-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO22__GPIO2_IO22 0x31e
+ MX93_PAD_GPIO_IO23__GPIO2_IO23 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c7: lpi2c7grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO07__LPI2C7_SCL 0x40000b9e
+ MX93_PAD_GPIO_IO06__LPI2C7_SDA 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c7_gpio: lpi2c7-gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO07__GPIO2_IO07 0x31e
+ MX93_PAD_GPIO_IO06__GPIO2_IO06 0x31e
+ >;
+ };
+
+ pinctrl_lpspi8: lpspi8grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO00__GPIO2_IO00 0x31e
+ MX93_PAD_GPIO_IO01__GPIO2_IO01 0x31e
+ MX93_PAD_GPIO_IO12__GPIO2_IO12 0x31e
+ MX93_PAD_GPIO_IO13__LPSPI8_SIN 0x31e
+ MX93_PAD_GPIO_IO14__LPSPI8_SOUT 0x31e
+ MX93_PAD_GPIO_IO15__LPSPI8_SCK 0x31e
+ >;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <
+ MX93_PAD_CCM_CLKO3__GPIO4_IO28 0x31e
+ >;
+ };
+
+ pinctrl_rtc: rtcgrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO02__GPIO2_IO02 0x31e
+ >;
+ };
+
+ pinctrl_tpm3: tpm3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO24__TPM3_CH3 0x51e
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX93_PAD_UART1_RXD__LPUART1_RX 0x31e
+ MX93_PAD_UART1_TXD__LPUART1_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart6: uart6grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO05__LPUART6_RX 0x31e
+ MX93_PAD_GPIO_IO04__LPUART6_TX 0x31e
+ >;
+ };
+
+ pinctrl_uart7: uart7grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO09__LPUART7_RX 0x31e
+ MX93_PAD_GPIO_IO08__LPUART7_TX 0x31e
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe
+ MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe
+ MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe
+ MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe
+ MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe
+ MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe
+ MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2gpiogrp {
+ fsl,pins = <
+ MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 2/3] arm64: dts: freescale: Add support for Variscite DART-MX93
From: Stefano Radaelli @ 2026-03-27 9:08 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Primoz Fiser,
Francesco Dolcini
In-Reply-To: <cover.1774601806.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite DART-MX93 system on module.
This SOM is designed to be used with various carrier boards.
The module includes:
- NXP i.MX93 MPU processor
- Up to 2GB of LPDDR4 memory
- Up to 128GB of eMMC storage memory
- Integrated 10/100/1000 Mbps Ethernet Transceiver
- Codec audio WM8904
- WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth
Only SOM-specific peripherals are enabled by default. Carrier board
specific interfaces are left disabled to be enabled in the respective
carrier board device trees.
Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-93/dart-mx93/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
- Remove clock-frequency property from eqos node
.../boot/dts/freescale/imx93-var-dart.dtsi | 461 ++++++++++++++++++
1 file changed, 461 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
diff --git a/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi b/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
new file mode 100644
index 000000000000..69495bb7fc9f
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
@@ -0,0 +1,461 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Common dtsi for Variscite DART-MX93
+ *
+ * Link: https://variscite.com/system-on-module-som/i-mx-9/i-mx-93/dart-mx93/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/usb/pd.h>
+#include "imx93.dtsi"
+
+/ {
+ model = "Variscite DART-MX93 Module";
+ compatible = "variscite,var-dart-mx93", "fsl,imx93";
+
+ sound-wm8904 {
+ compatible = "simple-audio-card";
+ simple-audio-card,bitclock-master = <&codec_dai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&codec_dai>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "wm8904-audio";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "IN1L", "Microphone Jack",
+ "IN1R", "Microphone Jack";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Line", "Line In Jack";
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&wm8904>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai1>;
+ };
+ };
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <10000>;
+ reset-gpios = <&gpio4 14 GPIO_ACTIVE_LOW>, /* WIFI_RESET */
+ <&gpio3 7 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */
+ };
+};
+
+&cm33 {
+ mbox-names = "tx", "rx", "rxdb";
+ mboxes = <&mu1 0 1>,
+ <&mu1 1 1>,
+ <&mu1 3 1>;
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
+ status = "okay";
+};
+
+&eqos {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_eqos>;
+ pinctrl-1 = <&pinctrl_eqos_sleep>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy0>;
+ snps,clk-csr = <5>;
+ status = "okay";
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <100000>;
+ };
+ };
+};
+
+&lpi2c3 {
+ clock-frequency = <400000>;
+ pinctrl-names = "default", "sleep", "gpio";
+ pinctrl-0 = <&pinctrl_lpi2c3>;
+ pinctrl-1 = <&pinctrl_lpi2c3_gpio>;
+ pinctrl-2 = <&pinctrl_lpi2c3_gpio>;
+ scl-gpios = <&gpio2 29 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 28 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ wm8904: audio-codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ #sound-dai-cells = <0>;
+ clocks = <&clk IMX93_CLK_SAI1_GATE>;
+ clock-names = "mclk";
+ AVDD-supply = <&buck5>;
+ CPVDD-supply = <&buck5>;
+ DBVDD-supply = <&buck4>;
+ DCVDD-supply = <&buck5>;
+ MICVDD-supply = <&buck5>;
+ wlf,drc-cfg-names = "default", "peaklimiter", "tradition",
+ "soft", "music";
+ /*
+ * Config registers per name, respectively:
+ * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1
+ * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1
+ * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1
+ * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1
+ * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>,
+ /bits/ 16 <0x04af 0x324b 0x0028 0x0704>,
+ /bits/ 16 <0x04af 0x324b 0x0018 0x078c>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x050e>;
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+ /* DMIC is connected to IN1L */
+ wlf,in1l-as-dmicdat1;
+ };
+
+ pmic@25 {
+ compatible = "nxp,pca9451a";
+ reg = <0x25>;
+
+ regulators {
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <650000>;
+ regulator-max-microvolt = <2237500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <2187500>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ buck4: BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5: BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <600000>;
+ regulator-max-microvolt = <3400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo5: LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+/* BT module */
+&lpuart5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart5>, <&pinctrl_bt>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
+&mu1 {
+ status = "okay";
+};
+
+&mu2 {
+ status = "okay";
+};
+
+&sai1 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_sai1>;
+ pinctrl-1 = <&pinctrl_sai1_sleep>;
+ assigned-clocks = <&clk IMX93_CLK_SAI1>;
+ assigned-clock-parents = <&clk IMX93_CLK_AUDIO_PLL>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ status = "okay";
+};
+
+/* WiFi */
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep";
+ pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>, <&pinctrl_usdhc3_wlan>;
+ pinctrl-3 = <&pinctrl_usdhc3_sleep>, <&pinctrl_usdhc3_wlan>;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ keep-power-in-suspend;
+ bus-width = <4>;
+ non-removable;
+ wakeup-source;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_bt: btgrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_MDIO__GPIO4_IO15 0x51e
+ >;
+ };
+
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDC__ENET_QOS_MDC 0x57e
+ MX93_PAD_ENET1_MDIO__ENET_QOS_MDIO 0x57e
+ MX93_PAD_ENET1_RD0__ENET_QOS_RGMII_RD0 0x57e
+ MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e
+ MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e
+ MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e
+ MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x58e
+ MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e
+ MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e
+ MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1 0x57e
+ MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e
+ MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e
+ MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x58e
+ MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e
+ MX93_PAD_UART2_TXD__GPIO1_IO07 0x51e
+ >;
+ };
+
+ pinctrl_eqos_sleep: eqos-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_ENET1_MDC__GPIO4_IO00 0x31e
+ MX93_PAD_ENET1_MDIO__GPIO4_IO01 0x31e
+ MX93_PAD_ENET1_RD0__GPIO4_IO10 0x31e
+ MX93_PAD_ENET1_RD1__GPIO4_IO11 0x31e
+ MX93_PAD_ENET1_RD2__GPIO4_IO12 0x31e
+ MX93_PAD_ENET1_RD3__GPIO4_IO13 0x31e
+ MX93_PAD_ENET1_RXC__GPIO4_IO09 0x31e
+ MX93_PAD_ENET1_RX_CTL__GPIO4_IO08 0x31e
+ MX93_PAD_ENET1_TD0__GPIO4_IO05 0x31e
+ MX93_PAD_ENET1_TD1__GPIO4_IO04 0x31e
+ MX93_PAD_ENET1_TD2__GPIO4_IO03 0x31e
+ MX93_PAD_ENET1_TD3__GPIO4_IO02 0x31e
+ MX93_PAD_ENET1_TXC__GPIO4_IO07 0x31e
+ MX93_PAD_ENET1_TX_CTL__GPIO4_IO06 0x31e
+ >;
+ };
+
+ pinctrl_lpi2c3: lpi2c3grp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__LPI2C3_SDA 0x40000b9e
+ MX93_PAD_GPIO_IO29__LPI2C3_SCL 0x40000b9e
+ >;
+ };
+
+ pinctrl_lpi2c3_gpio: lpi2c3gpiogrp {
+ fsl,pins = <
+ MX93_PAD_GPIO_IO28__GPIO2_IO28 0x40000b9e
+ MX93_PAD_GPIO_IO29__GPIO2_IO29 0x40000b9e
+ >;
+ };
+
+ pinctrl_sai1: sai1grp {
+ fsl,pins = <
+ MX93_PAD_SAI1_TXC__SAI1_TX_BCLK 0x31e
+ MX93_PAD_SAI1_TXFS__SAI1_TX_SYNC 0x31e
+ MX93_PAD_SAI1_TXD0__SAI1_TX_DATA00 0x31e
+ MX93_PAD_SAI1_RXD0__SAI1_RX_DATA00 0x31e
+ MX93_PAD_I2C2_SDA__SAI1_RX_BCLK 0x31e
+ MX93_PAD_I2C2_SCL__SAI1_RX_SYNC 0x31e
+ MX93_PAD_UART2_RXD__SAI1_MCLK 0x31e
+ >;
+ };
+
+ pinctrl_sai1_sleep: sai1-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_SAI1_TXC__GPIO1_IO12 0x31e
+ MX93_PAD_SAI1_TXFS__GPIO1_IO11 0x31e
+ MX93_PAD_SAI1_TXD0__GPIO1_IO13 0x31e
+ MX93_PAD_SAI1_RXD0__GPIO1_IO14 0x31e
+ MX93_PAD_UART2_RXD__GPIO1_IO06 0x31e
+ MX93_PAD_I2C2_SDA__GPIO1_IO03 0x31e
+ MX93_PAD_I2C2_SCL__GPIO1_IO02 0x31e
+ >;
+ };
+
+ pinctrl_uart5: uart5grp {
+ fsl,pins = <
+ MX93_PAD_DAP_TDO_TRACESWO__LPUART5_TX 0x31e
+ MX93_PAD_DAP_TDI__LPUART5_RX 0x31e
+ MX93_PAD_DAP_TMS_SWDIO__LPUART5_RTS_B 0x31e
+ MX93_PAD_DAP_TCLK_SWCLK__LPUART5_CTS_B 0x31e
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x1582
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x40001382
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x40001382
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x40001382
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x40001382
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x40001382
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x40001382
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x40001382
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x40001382
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x40001382
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x1582
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x158e
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x4000138e
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x4000138e
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x4000138e
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x4000138e
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x4000138e
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x4000138e
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x4000138e
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x4000138e
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x4000138e
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x158e
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD1_CLK__USDHC1_CLK 0x15fe
+ MX93_PAD_SD1_CMD__USDHC1_CMD 0x400013fe
+ MX93_PAD_SD1_DATA0__USDHC1_DATA0 0x400013fe
+ MX93_PAD_SD1_DATA1__USDHC1_DATA1 0x400013fe
+ MX93_PAD_SD1_DATA2__USDHC1_DATA2 0x400013fe
+ MX93_PAD_SD1_DATA3__USDHC1_DATA3 0x400013fe
+ MX93_PAD_SD1_DATA4__USDHC1_DATA4 0x400013fe
+ MX93_PAD_SD1_DATA5__USDHC1_DATA5 0x400013fe
+ MX93_PAD_SD1_DATA6__USDHC1_DATA6 0x400013fe
+ MX93_PAD_SD1_DATA7__USDHC1_DATA7 0x400013fe
+ MX93_PAD_SD1_STROBE__USDHC1_STROBE 0x15fe
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x1582
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x40001382
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x40001382
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x40001382
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x40001382
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x40001382
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x158e
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x4000138e
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x4000138e
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x4000138e
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x4000138e
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x4000138e
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__USDHC3_CLK 0x15fe
+ MX93_PAD_SD3_CMD__USDHC3_CMD 0x400013fe
+ MX93_PAD_SD3_DATA0__USDHC3_DATA0 0x400013fe
+ MX93_PAD_SD3_DATA1__USDHC3_DATA1 0x400013fe
+ MX93_PAD_SD3_DATA2__USDHC3_DATA2 0x400013fe
+ MX93_PAD_SD3_DATA3__USDHC3_DATA3 0x400013fe
+ >;
+ };
+
+ pinctrl_usdhc3_sleep: usdhc3-sleepgrp {
+ fsl,pins = <
+ MX93_PAD_SD3_CLK__GPIO3_IO20 0x400
+ MX93_PAD_SD3_CMD__GPIO3_IO21 0x400
+ MX93_PAD_SD3_DATA0__GPIO3_IO22 0x400
+ MX93_PAD_SD3_DATA1__GPIO3_IO23 0x400
+ MX93_PAD_SD3_DATA2__GPIO3_IO24 0x400
+ MX93_PAD_SD3_DATA3__GPIO3_IO25 0x400
+ >;
+ };
+
+ pinctrl_usdhc3_wlan: usdhc3wlangrp {
+ fsl,pins = <
+ MX93_PAD_ENET2_MDC__GPIO4_IO14 0x51e
+ MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x51e
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: arm: fsl: add Variscite DART-MX93 Boards
From: Stefano Radaelli @ 2026-03-27 9:08 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Primoz Fiser,
Francesco Dolcini, Conor Dooley
In-Reply-To: <cover.1774601806.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add DT compatible strings for Variscite DART-MX93 SoM and Variscite
development carrier Board.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
v1->v2:
-
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index da2be7114f64..77497a261fd5 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1587,6 +1587,12 @@ properties:
- const: variscite,var-dart-mx91 # Variscite DART-MX91 SOM
- const: fsl,imx91
+ - description: Variscite DART-MX93 based boards
+ items:
+ - const: variscite,var-dart-mx93-sonata # Variscite DART-MX93 on Sonata Development Board
+ - const: variscite,var-dart-mx93 # Variscite DART-MX93 SOM
+ - const: fsl,imx93
+
- description: Variscite VAR-SOM-MX93 based boards
items:
- const: variscite,var-som-mx93-symphony
--
2.47.3
^ permalink raw reply related
* [PATCH v2 0/3] Add support for Variscite DART-MX93 and Sonata board
From: Stefano Radaelli @ 2026-03-27 9:08 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Dario Binacchi, Alexander Stein,
Maud Spierings, Josua Mayer, Markus Niebel, Primoz Fiser,
Francesco Dolcini
This patch series adds support for the Variscite DART-MX93 system on
module and the Sonata carrier board.
The series includes:
- SOM device tree with on-module peripherals
- Sonata carrier board device tree with board-specific features
The implementation follows the standard SOM + carrier board pattern
where the SOM dtsi contains only peripherals mounted on the module,
while carrier-specific interfaces are enabled in the board dts.
v1->v2:
- Remove clock-frequency property from eqos node
Stefano Radaelli (3):
dt-bindings: arm: fsl: add Variscite DART-MX93 Boards
arm64: dts: freescale: Add support for Variscite DART-MX93
arm64: dts: imx93-var-dart: Add support for Variscite Sonata board
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx93-var-dart-sonata.dts | 654 ++++++++++++++++++
.../boot/dts/freescale/imx93-var-dart.dtsi | 461 ++++++++++++
4 files changed, 1122 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart-sonata.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx93-var-dart.dtsi
base-commit: 6c4b48012d57f205c94f25da0c68a4027ea6daf6
--
2.47.3
^ permalink raw reply
* Re: [PATCH 2/4] arm64: dts: renesas: Fix missing cells and reg in Salvator-X panel DTO
From: Laurent Pinchart @ 2026-03-27 9:07 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-3-marek.vasut+renesas@mailbox.org>
Hi Marek,
Thank you for the patch.
On Thu, Mar 26, 2026 at 05:23:59AM +0100, Marek Vasut wrote:
> Add missing cells and reg DT property into Salvator-X panel DTO to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso:30.10-34.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@1: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso b/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso
> index c83a30adc6adf..7807c3f80409a 100644
> --- a/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso
> +++ b/arch/arm64/boot/dts/renesas/salvator-panel-aa104xd12.dtso
> @@ -27,7 +27,12 @@ &lvds0 {
> status = "okay";
>
> ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> port@1 {
> + reg = <1>;
> +
> lvds0_out: endpoint {
> remote-endpoint = <&panel_in>;
> };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH 1/4] arm64: dts: renesas: Fix missing cells and reg in Draak/Ebisu panel DTO
From: Laurent Pinchart @ 2026-03-27 9:07 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-arm-kernel, Conor Dooley, Geert Uytterhoeven,
Krzysztof Kozlowski, Magnus Damm, Rob Herring, devicetree,
linux-kernel, linux-renesas-soc
In-Reply-To: <20260326042411.215241-2-marek.vasut+renesas@mailbox.org>
On Thu, Mar 26, 2026 at 05:23:58AM +0100, Marek Vasut wrote:
> Add missing cells and reg DT property into Draak/Ebisu panel DTO to fix
> the following warning:
>
> "
> arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso:30.10-34.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@1: node has a unit name, but no reg or ranges property
> "
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
It's slightly annoying to have to specify those properties in overlays.
It would be nice to improve the tooling, but a warning-free build is
probably a more important target for now.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Magnus Damm <magnus.damm@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-renesas-soc@vger.kernel.org
> ---
> arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso b/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso
> index 258f8668ca361..90767d74e21b2 100644
> --- a/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso
> +++ b/arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso
> @@ -27,7 +27,12 @@ &lvds1 {
> status = "okay";
>
> ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> port@1 {
> + reg = <1>;
> +
> lvds1_out: endpoint {
> remote-endpoint = <&panel_in>;
> };
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v5] arm64: dts: rockchip: rock-3b: Model PI6C20100 as gated-fixed-clock
From: Midgy Balon @ 2026-03-27 9:07 UTC (permalink / raw)
To: Heiko Stuebner
Cc: Jonas Karlman, linux-rockchip, shawn.lin, jonas, linux-arm-kernel,
devicetree
In-Reply-To: <10821700.nUPlyArG6x@phil>
Hello Heiko,
I apologize for missing Jonas' comments. It will be done for the next
version as requested.
Indeed Claude works "well" :D . I'll be more careful next time.
Thanks,
Midgy
Le mar. 24 mars 2026 à 23:27, Heiko Stuebner <heiko@sntech.de> a écrit :
>
> Hi Jonas,
>
> Am Dienstag, 24. März 2026, 18:15:38 Mitteleuropäische Normalzeit schrieb Jonas Karlman:
> > Hi Heiko,
> >
> > On 3/24/2026 6:04 PM, Heiko Stuebner wrote:
> > >
> > > On Fri, 20 Mar 2026 10:44:41 +0100, MidG971 wrote:
> > >> The Radxa ROCK 3B uses a PI6C20100 PCIe reference clock buffer to
> > >> provide a 100MHz reference clock to the PCIe 3.0 PHY and controllers.
> > >> This chip is currently modeled only as a fixed regulator
> > >> (vcc3v3_pi6c_03), with no clock output representation.
> > >>
> > >> The PI6C20100 is a clock generator, not a power supply. Model it
> > >> properly as a gated-fixed-clock, following the pattern established
> > >> for the Rock 5 ITX and other boards with similar PCIe clock buffer
> > >> chips.
> > >>
> > >> [...]
> > >
> > > Applied, thanks!
> >
> > My comments from v3 [1] was not addressed in v4 och v5. E.g.
> > regulator-always-on/boot-on not being removed and redundant comments.
> >
> > [1] https://lore.kernel.org/all/fec0f25d-733a-4b6c-aef1-2ac51bd15798@kwiboo.se/
>
> thank you so much for noticing. Looks like that AI thing is
> working "well" ;-) .
>
> I've droped the patch and recreated the for-next branch now.
>
> @Midgy, please honor feedback in future revisions.
>
> Thanks
> Heiko
>
>
^ permalink raw reply
* RE: [PATCH v3 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Torreno, Alexis Czezar @ 2026-03-27 9:01 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Lars-Peter Clausen, Hennerich, Michael, Jonathan Cameron,
David Lechner, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-iio@vger.kernel.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <acPRSzrHUtSEx-J3@ashevche-desk.local>
> >
> > To neatly summarize, my needs are: (in future patches) 1. SPI
> > read/write can have different frequencies and runtime changeable
>
> How does it related to regmap? Is it dependent on the register?
>
> > 2. SPI data bits needs to be exactly 8bits or 16bits depending on
> > register width
>
> This is solved very easily with regmap, no problem at all (two regmaps with
> configuration for 8-bit and 16-bit registers), I believe we have even driver in
> kernel that does exactly this.
>
> > 3. DAC Device reads SPI command bits [14:12] for communication, not
> > just chip select
>
> Okay, but I'm not sure how this is a limitation...
>
> > For regmap to be used
> > 1. regmap_config would need new read_speed and write_speed entries.
> > 2. val_bits must now be changeable depending on the need.
> > 3. I think the read/write_flag_mask can do this.
> >
> > 1) is relatively easy I think, but am not sure with 2) as it might
> > break other regmap core code that already assumes it to be fixed.
> > Feels like a lot of work for a niche amount of devices, I may still
> > lean on the opinion of keeping regmap as is.
>
> Okay, I leave it to others, for the simplicity we can leave driver as is, but make
> sure you put the summary of this into the cover letter, so we will be crystal
> clear why regmap hasn't been chosen.
>
With some discussion with Nuno, I get now that I could still use regmap but employ
a custom regmap_bus for my use case. Will do this on v4, I think I can still
satisfy my future requirements with it. Thanks!
Regards,
Alexis
^ permalink raw reply
* Re: [PATCH 0/4] arm64: dts: renesas: Fix missing cells and reg
From: Geert Uytterhoeven @ 2026-03-27 8:58 UTC (permalink / raw)
To: Marek Vasut
Cc: Marek Vasut, linux-arm-kernel, Conor Dooley, Krzysztof Kozlowski,
Magnus Damm, Rob Herring, devicetree, linux-kernel,
linux-renesas-soc, Laurent Pinchart, Niklas Söderlund
In-Reply-To: <2ad69ee6-9170-46dc-a963-71f327192bad@mailbox.org>
On Thu, 26 Mar 2026 at 21:40, Marek Vasut <marek.vasut@mailbox.org> wrote:
> On 3/26/26 11:07 AM, Geert Uytterhoeven wrote:
> > On Thu, 26 Mar 2026 at 05:24, Marek Vasut
> > <marek.vasut+renesas@mailbox.org> wrote:
> >> Add missing cells and reg DT property into DTOs to fix warnings like this:
> >>
> >> "
> >> arch/arm64/boot/dts/renesas/draak-ebisu-panel-aa104xd12.dtso:30.10-34.5: Warning (unit_address_vs_reg): /fragment@2/__overlay__/ports/port@1: node has a unit name, but no reg or ranges property
> >> "
> >
> > All of these are dtc W=1 warnings, right?
>
> Yes, I slowly started linting and validating the various DTs we have to
> remove leftover warnings.
As this is about display and camera, I am pulling in some multimedia guys.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v1] arm64: dts: qcom: hamoa-iot-som: Add firmware-name to QUPv3 nodes
From: Xueyao An @ 2026-03-27 8:53 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
Traditionally, firmware loading for Serial Engines (SE) in the QUP hardware
of Qualcomm SoCs has been managed by TrustZone (TZ). While this approach
ensures secure SE assignment and access control, it limits flexibility for
developers who need to enable various protocols on different SEs.
Add the firmware-name property to QUPv3 nodes in the device tree to enable
firmware loading from the Linux environment. Handle SE assignments and
access control permissions directly within Linux, removing the dependency
on TrustZone.
Signed-off-by: Xueyao An <xueyao.an@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
index 1a9e930c0496..c26eaf187b17 100644
--- a/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa-iot-som.dtsi
@@ -458,14 +458,20 @@ &pcie6a_phy {
};
&qupv3_0 {
+ firmware-name = "qcom/x1e80100/qupv3fw.elf";
+
status = "okay";
};
&qupv3_1 {
+ firmware-name = "qcom/x1e80100/qupv3fw.elf";
+
status = "okay";
};
&qupv3_2 {
+ firmware-name = "qcom/x1e80100/qupv3fw.elf";
+
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v9 2/9] lib: vsprintf: export simple_strntoull() in a safe prototype
From: Petr Mladek @ 2026-03-27 8:45 UTC (permalink / raw)
To: rodrigo.alencar
Cc: linux-kernel, linux-iio, devicetree, linux-doc, Jonathan Cameron,
David Lechner, Andy Shevchenko, Lars-Peter Clausen,
Michael Hennerich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jonathan Corbet, Andrew Morton, Steven Rostedt, Andy Shevchenko,
Rasmus Villemoes, Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260320-adf41513-iio-driver-v9-2-132f0d076374@analog.com>
On Fri 2026-03-20 16:27:27, Rodrigo Alencar via B4 Relay wrote:
> From: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> Expose simple_strntoull(), by addressing its FIXME, i.e. its prototype is
> slightly changed so that -ERANGE or -EINVAL can be evaluated by the user.
> Flow of the function is not changed and error value is returned in the
> end. Unsafe internal wrapper is created to reduce amount of changes.
>
> --- a/include/linux/kstrtox.h
> +++ b/include/linux/kstrtox.h
> @@ -148,4 +148,8 @@ extern long simple_strtol(const char *,char **,unsigned int);
> extern unsigned long long simple_strtoull(const char *,char **,unsigned int);
> extern long long simple_strtoll(const char *,char **,unsigned int);
>
> +extern ssize_t __must_check simple_strntoull(const char *startp, const char **endp,
> + unsigned int base, size_t max_chars,
> + unsigned long long *res);
Sigh, naming is hard. I personally find it a bit confusing that the
name is too similar to the unsafe API.
IMHO, the semantic of the new API is closer to kstrtoull().
It just limits the size, so I would call it kstrntoull().
Also I would use int as the return parameter, see below.
> #endif /* _LINUX_KSTRTOX_H */
> diff --git a/lib/vsprintf.c b/lib/vsprintf.c
> index 800b8ac49f53..6fb880f4013b 100644
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -75,25 +75,66 @@ enum hash_pointers_policy {
> };
> static enum hash_pointers_policy hash_pointers_mode __initdata;
>
> +/**
> + * simple_strntoull - convert a string to an unsigned long long with a character limit
> + *
> + * @startp: The start of the string
> + * @endp: A pointer to the end of the parsed string will be placed here
I would write:
* @endp: A pointer to the end of the parsed string (output)
> + * @base: The number base to use
> + * @max_chars: The maximum number of characters to parse
> + * @res: Where to write the result of the conversion on success
Nit: I would omit "on success" *res value is set to 0 on failure.
Instead, I would write:
* @res: Result of the conversion (output)
> + *
> + * Returns amount of processed characters on success, -ERANGE on overflow and
> + * -EINVAL on parsing error.
> + */
> noinline
> -static unsigned long long simple_strntoull(const char *startp, char **endp, unsigned int base, size_t max_chars)
> +ssize_t simple_strntoull(const char *startp, const char **endp,
> + unsigned int base, size_t max_chars,
> + unsigned long long *res)
It might be enoungh to use "int" for the return value. The number
of proceed characters is pretty limited by definition. And it
would be similar to vsnprintf(), kstrtoull(), ...
I guess that you wanted to match the "size_t max_chars" parameter.
It makes some sense as well.
Please, use "int" especially if we agreed to call the new API
kstrntoull().
> {
> const char *cp;
> - unsigned long long result = 0ULL;
> size_t prefix_chars;
> unsigned int rv;
> + ssize_t ret;
>
> cp = _parse_integer_fixup_radix(startp, &base);
> prefix_chars = cp - startp;
> if (prefix_chars < max_chars) {
> - rv = _parse_integer_limit(cp, base, &result, max_chars - prefix_chars);
> - /* FIXME */
> + rv = _parse_integer_limit(cp, base, res, max_chars - prefix_chars);
> + if (rv & KSTRTOX_OVERFLOW)
> + ret = -ERANGE;
> + else if (rv == 0)
> + ret = -EINVAL;
> + else
> + ret = rv + prefix_chars;
> cp += (rv & ~KSTRTOX_OVERFLOW);
> } else {
> /* Field too short for prefix + digit, skip over without converting */
> cp = startp + max_chars;
> + ret = -EINVAL;
> + *res = 0ULL;
> }
>
> + if (endp)
> + *endp = cp;
> +
> + return ret;
> +}
> +EXPORT_SYMBOL(simple_strntoull);
> +
> +/* unsafe_strntoull ignores simple_strntoull() return value and endp const qualifier */
> +inline
> +static unsigned long long unsafe_strntoull(const char *startp, char **endp,
> + unsigned int base, size_t max_chars)
> +{
> + unsigned long long result;
> + const char *cp;
> +
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wunused-result"
> + simple_strntoull(startp, &cp, base, max_chars, &result);
> +#pragma GCC diagnostic pop
> +
> if (endp)
> *endp = (char *)cp;
IMHO, we do not need local "cp". We could simply pass the endp
to the new simple_strntoull. Or do I miss anything?
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 4/7] dt-bindings: leds: irled: ir-spi-led: Add new duty-cycle value
From: Sean Young @ 2026-03-27 8:41 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Biswapriyo Nath, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Lee Jones, Pavel Machek,
Michael Turquette, Stephen Boyd, Martin Botka, linux-arm-msm,
devicetree, linux-kernel, linux-leds, linux-clk,
~postmarketos/upstreaming, phone-devel
In-Reply-To: <20260327-natural-wild-mongrel-5bcc43@quoll>
On Fri, Mar 27, 2026 at 08:51:18AM +0100, Krzysztof Kozlowski wrote:
> On Wed, Mar 25, 2026 at 06:07:27PM +0000, Biswapriyo Nath wrote:
> > 30 duty cycle for IR transmitter is used in Xiaomi Redmi Note 8 (ginkgo).
> >
> > Signed-off-by: Biswapriyo Nath <nathbappai@gmail.com>
> > ---
> > Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml b/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml
> > index 72cadebf6e3..0297bfbb275 100644
> > --- a/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml
> > +++ b/Documentation/devicetree/bindings/leds/irled/ir-spi-led.yaml
> > @@ -25,7 +25,7 @@ properties:
> >
> > duty-cycle:
> > $ref: /schemas/types.yaml#/definitions/uint8
> > - enum: [50, 60, 70, 75, 80, 90]
> > + enum: [30, 50, 60, 70, 75, 80, 90]
>
> Hm, why is this enum, instead of 1-99, in the first place?
Well in reality only a few different duty cycles are used by IR protocols.
30% is quite common so that should part of the list.
Having said that a range of 1-99 would be nicer. Do we set this like so:
- minimum: 1
- maximum: 99
?
Thanks,
Sean
^ permalink raw reply
* Re: (subset) [PATCH v3 0/4] iio: adc: meson-saradc: add support for Meson S4
From: Neil Armstrong @ 2026-03-27 8:31 UTC (permalink / raw)
To: khilman, martin.blumenstingl, jbrunet, jic23, dlechner, andy,
Nick Xie
Cc: krzk+dt, robh, conor+dt, linux-iio, linux-amlogic,
linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20260325070618.81955-1-nick@khadas.com>
Hi,
On Wed, 25 Mar 2026 15:06:14 +0800, Nick Xie wrote:
> This series adds support for the SARADC IP block found in the Amlogic
> Meson S4 (S905Y4) SoC and enables it for the Khadas VIM1S board to
> support the onboard ADC 'Function' key.
>
> There are no known hardware differences between the SARADC on the S4
> and the previous G12A generation. The S4 bindings utilize a fallback
> to G12A, but a dedicated driver match entry is included to ensure the
> correct part name is exposed to the userspace ABI.
>
> [...]
Thanks, Applied to https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git (v7.1/arm64-dt)
[3/4] arm64: dts: amlogic: meson-s4: add internal SARADC controller
https://git.kernel.org/amlogic/c/3b095e9b3674da0666aea3021167ca44097ed7fa
[4/4] arm64: dts: amlogic: meson-s4-s905y4-khadas-vim1s: add Function key support
https://git.kernel.org/amlogic/c/97c4d4b7de6ef264fbd45300a168c2a0874d6c75
These changes has been applied on the intermediate git tree [1].
The v7.1/arm64-dt branch will then be sent via a formal Pull Request to the Linux SoC maintainers
for inclusion in their intermediate git branches in order to be sent to Linus during
the next merge window, or sooner if it's a set of fixes.
In the cases of fixes, those will be merged in the current release candidate
kernel and as soon they appear on the Linux master branch they will be
backported to the previous Stable and Long-Stable kernels [2].
The intermediate git branches are merged daily in the linux-next tree [3],
people are encouraged testing these pre-release kernels and report issues on the
relevant mailing-lists.
If problems are discovered on those changes, please submit a signed-off-by revert
patch followed by a corrective changeset.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/amlogic/linux.git
[2] https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
[3] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
--
Neil
^ permalink raw reply
* [PATCH 2/2] arm64: dts: qcom: monaco-evk: enable UART6 for robot expansion board
From: Canfeng Zhuang @ 2026-03-27 8:31 UTC (permalink / raw)
To: konradybcio, andersson
Cc: robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-arm-kernel
In-Reply-To: <20260327083101.1343613-1-canfeng.zhuang@oss.qualcomm.com>
The monaco-evk mezzanine connector supports a robot expansion board that
requires UART6, which is currently disabled. This prevents the expansion
board from exchanging data and control commands.
Enable UART6 and assign the serial2 alias to provide stable device
enumeration for the expansion board.
Signed-off-by: Canfeng Zhuang <canfeng.zhuang@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/monaco-evk.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco-evk.dts b/arch/arm64/boot/dts/qcom/monaco-evk.dts
index 565418b86b2a..0b26861eac02 100644
--- a/arch/arm64/boot/dts/qcom/monaco-evk.dts
+++ b/arch/arm64/boot/dts/qcom/monaco-evk.dts
@@ -21,6 +21,7 @@ aliases {
ethernet0 = ðernet0;
i2c1 = &i2c1;
serial0 = &uart7;
+ serial2 = &uart6;
};
chosen {
@@ -572,6 +573,10 @@ qup_i2c15_default: qup-i2c15-state {
};
};
+&uart6 {
+ status = "okay";
+};
+
&uart7 {
status = "okay";
};
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] arm64: dts: qcom: lemans-evk: enable UART0 for robot expansion board
From: Canfeng Zhuang @ 2026-03-27 8:31 UTC (permalink / raw)
To: konradybcio, andersson
Cc: robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-arm-kernel
In-Reply-To: <20260327083101.1343613-1-canfeng.zhuang@oss.qualcomm.com>
The lemans-evk mezzanine connector supports a robot expansion board that
requires UART0, which is currently disabled. This prevents the expansion
board from exchanging data and control commands.
Enable UART0 and assign the serial2 alias to provide stable device
enumeration for the expansion board.
Signed-off-by: Canfeng Zhuang <canfeng.zhuang@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans-evk.dts | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
index 90fce947ca7e..1e9386677bf5 100644
--- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
+++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
@@ -21,6 +21,7 @@ aliases {
ethernet0 = ðernet0;
mmc1 = &sdhc;
serial0 = &uart10;
+ serial2 = &uart0;
};
dmic: audio-codec-0 {
@@ -870,6 +871,10 @@ usb_id: usb-id-state {
};
};
+&uart0 {
+ status = "okay";
+};
+
&uart10 {
compatible = "qcom,geni-debug-uart";
pinctrl-0 = <&qup_uart10_default>;
--
2.34.1
^ permalink raw reply related
* [PATCH 0/2] arm64: dts: qcom: enable UARTs for robot expansion board
From: Canfeng Zhuang @ 2026-03-27 8:30 UTC (permalink / raw)
To: konradybcio, andersson
Cc: robh, krzk+dt, conor+dt, linux-arm-msm, devicetree,
linux-arm-kernel
The Qualcomm Lemans EVK and Monaco EVK boards expose a mezzanine
connector used by a motor control expansion board.
This expansion board hosts an MCU running NuttX and communicates with
Linux over UART, with all protocol handling done in userspace.
This series enables the required UARTs and assigns stable serial aliases
to ensure consistent device enumeration across platforms.
Canfeng Zhuang (2):
arm64: dts: qcom: lemans-evk: enable UART0 for robot expansion board
arm64: dts: qcom: monaco-evk: enable UART6 for robot expansion board
arch/arm64/boot/dts/qcom/lemans-evk.dts | 5 +++++
arch/arm64/boot/dts/qcom/monaco-evk.dts | 5 +++++
2 files changed, 10 insertions(+)
base-commit: 46b513250491a7bfc97d98791dbe6a10bcc8129d
prerequisite-patch-id: a877aad0127409ffea7c0a7411968d336497b035
--
2.34.1
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: phy: realtek,usb2phy.yaml: extend for resets and RTL9607C support
From: Krzysztof Kozlowski @ 2026-03-27 8:28 UTC (permalink / raw)
To: Rustam Adilov
Cc: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Stanley Chang, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260326193419.48419-4-adilov@disroot.org>
On Fri, Mar 27, 2026 at 12:34:16AM +0500, Rustam Adilov wrote:
> description: |
> - Realtek USB 2.0 PHY support the digital home center (DHC) RTD series SoCs.
> + Realtek USB 2.0 PHY support the digital home center (DHC) RTD and
> + RTL9607C series SoCs.
> The USB 2.0 PHY driver is designed to support the XHCI controller. The SoCs
> support multiple XHCI controllers. One PHY device node maps to one XHCI
> controller.
> + This driver also supports the OCHI and EHCI controllers.
Hardware is fixed, does not change. Don't reference your driver changes
here.
>
> RTD1295/RTD1619 SoCs USB
> The USB architecture includes three XHCI controllers.
> @@ -57,6 +59,12 @@ description: |
> XHCI controller#1 -- usb2phy -- phy#0
> XHCI controller#2 -- usb2phy -- phy#0
>
> + RTL9607C SoCs USB
> + The USB architecture includes OHCI and EHCI controllers.
> + Both of them map to one USB2.0 PHY.
> + OHCI controller#0 -- usb2phy -- phy#0
> + EHCI controller#0 -- usb2phy -- phy#0
> +
> properties:
> compatible:
> enum:
> @@ -69,6 +77,7 @@ properties:
> - realtek,rtd1395-usb2phy-2port
> - realtek,rtd1619-usb2phy
> - realtek,rtd1619b-usb2phy
> + - realtek,rtl9607-usb2phy
>
> reg:
> items:
> @@ -130,6 +139,9 @@ properties:
> minimum: -8
> maximum: 8
>
> + resets:
> + maxItems: 1
> +
> required:
> - compatible
> - reg
> @@ -157,6 +169,15 @@ allOf:
> then:
> properties:
> realtek,driving-level-compensate: false
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - realtek,rtl9607-usb2phy
> + then:
> + required:
> + - resets
If it is unclear, they might not have it so,
else: ... :false
see example-schema.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 01/12] dt-bindings: i3c: Add mipi-i3c-static-method to support SETAASA
From: Alexandre Belloni @ 2026-03-27 8:27 UTC (permalink / raw)
To: Akhil R
Cc: Frank.Li, acpica-devel, conor+dt, conor, devicetree, ebiggers,
fredrik.markstrom, jonathanh, krzk+dt, lenb, linux-acpi,
linux-hwmon, linux-i3c, linux-kernel, linux-tegra, linux,
miquel.raynal, p.zabel, rafael, robert.moore, robh, smangipudi,
thierry.reding
In-Reply-To: <20260327081858.32354-1-akhilrajeev@nvidia.com>
On 27/03/2026 13:48:58+0530, Akhil R wrote:
> On Thu, 26 Mar 2026 16:44:31 +0100, Alexandre Belloni wrote:
> > On 26/03/2026 10:05:03-0500, Rob Herring wrote:
> >> On Wed, Mar 18, 2026 at 05:31:50PM +0000, Conor Dooley wrote:
> >> > On Wed, Mar 18, 2026 at 10:57:14PM +0530, Akhil R wrote:
> >> > > Add the 'mipi-i3c-static-method' property mentioned in the MIPI I3C
> >> > > Discovery and Configuration Specification [1] to specify which discovery
> >> > > method an I3C device supports during bus initialization. The property is
> >> > > a bitmap, where a bit value of 1 indicates support for that method, and 0
> >> > > indicates lack of support.
> >> > > Bit 0: SETDASA CCC (Direct)
> >> > > Bit 1: SETAASA CCC (Broadcast)
> >> > > Bit 2: Other CCC (vendor / standards extension)
> >> > > All other bits are reserved.
> >> > >
> >> > > It is specifically needed when an I3C device requires SETAASA for the
> >> > > address assignment. SETDASA will be supported by default if this property
> >> > > is absent - which means for now the property just serves as a flag to
> >> > > enable SETAASA, but keep the property as a bitmap to align with the
> >> > > specifications.
> >> > >
> >> > > [1] https://www.mipi.org/specifications/disco
> >> > >
> >> > > Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
> >> > > ---
> >> > > .../devicetree/bindings/i3c/i3c.yaml | 30 ++++++++++++++++---
> >> > > 1 file changed, 26 insertions(+), 4 deletions(-)
> >> > >
> >> > > diff --git a/Documentation/devicetree/bindings/i3c/i3c.yaml b/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> > > index e25fa72fd785..1705d90d4d79 100644
> >> > > --- a/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> > > +++ b/Documentation/devicetree/bindings/i3c/i3c.yaml
> >> > > @@ -31,10 +31,12 @@ properties:
> >> > > described in the device tree, which in turn means we have to describe
> >> > > I3C devices.
> >> > >
> >> > > - Another use case for describing an I3C device in the device tree is when
> >> > > - this I3C device has a static I2C address and we want to assign it a
> >> > > - specific I3C dynamic address before the DAA takes place (so that other
> >> > > - devices on the bus can't take this dynamic address).
> >> > > + Other use-cases for describing an I3C device in the device tree are:
> >> > > + - When the I3C device has a static I2C address and we want to assign
> >> > > + it a specific I3C dynamic address before the DAA takes place (so
> >> > > + that other devices on the bus can't take this dynamic address).
> >> > > + - When the I3C device requires SETAASA for its discovery and uses a
> >> > > + pre-defined static address.
> >> > >
> >> > > "#size-cells":
> >> > > const: 0
> >> > > @@ -147,6 +149,26 @@ patternProperties:
> >> > > through SETDASA. If static address is not present, this address is assigned
> >> > > through SETNEWDA after assigning a temporary address via ENTDAA.
> >> > >
> >> > > + mipi-i3c-static-method:
> >> > > + $ref: /schemas/types.yaml#/definitions/uint32
> >> > > + minimum: 0x1
> >> > > + maximum: 0xff
> >> > > + default: 1
> >> > > + description: |
> >> > > + Bitmap describing which methods of Dynamic Address Assignment from a
> >> > > + static address are supported by this I3C Target. A bit value of 1
> >> > > + indicates support for that method, and 0 indicates lack of support.
> >> >
> >> > I really am not keen on properties that are bitmaps, why can't we just
> >> > use the strings "setdasa", "setaasa" etc?
> >>
> >> If this comes from a specification, then I'd tend to just copy it rather
> >> than invent our own thing. Obviously if is something structured
> >> fundamentally different from how DT is designed, then we wouldn't. But
> >> this is just a simple property.
> >>
> >
> > The issue being that the specification is not public so it is difficult
> > to take any decision.
>
> There is a public version available in the same link, but you would still
> have to provide them a name and an email ID. The document will be sent to
> the mail ID.
>
The public version only contains one property:
mipi-disco-interface-revision
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: pwm: amlogic: Add new bindings for S6 S7 S7D
From: Krzysztof Kozlowski @ 2026-03-27 8:25 UTC (permalink / raw)
To: Xianwei Zhao
Cc: Uwe Kleine-König, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiner Kallweit, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl, linux-pwm, devicetree,
linux-kernel, linux-arm-kernel, linux-amlogic, Junyi Zhao
In-Reply-To: <20260326-s6-s7-pwm-v1-1-67e2f72b98bc@amlogic.com>
On Thu, Mar 26, 2026 at 06:35:38AM +0000, Xianwei Zhao wrote:
> + - items:
> + - enum:
> + - amlogic,s6-pwm
> + - amlogic,s7d-pwm
> + - const: amlogic,s7-pwm
> - items:
> - enum:
> - amlogic,meson8b-pwm-v2
> @@ -146,6 +152,20 @@ allOf:
> clock-names: false
> required:
> - clocks
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - amlogic,s7-pwm
> + then:
> + properties:
> + clocks:
> + items:
> + - description: input clock of PWM
so simpler: "maxItems: 1"
> + clock-names: false
> + required:
> + - clocks
>
> - if:
> properties:
> @@ -182,3 +202,10 @@ examples:
> clocks = <&pwm_src_a>, <&pwm_src_b>;
> #pwm-cells = <3>;
> };
> + - |
> + pwm@1000 {
> + compatible = "amlogic,s7-pwm";
You already have three examples, don't add more.
With these changes:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v2] dt-bindings: mfd: twl: Reference converted schemas for subnodes
From: Jihed Chaibi @ 2026-03-27 8:23 UTC (permalink / raw)
To: andreas
Cc: lee, robh, krzk+dt, conor+dt, devicetree, linux-kernel,
jihed.chaibi.dev
Now that all TWL subnode bindings (audio, keypad, twl4030-usb, gpio,
usb-comparator) have been converted and merged into mainline, update the
parent ti,twl.yaml to properly reference them via $ref.
Replace the inline compatible definitions with $ref to the appropriate
schemas and unevaluatedProperties: false, matching the pattern already
used by the madc, gpadc, and charger subnodes.
Signed-off-by: Jihed Chaibi <jihed.chaibi.dev@gmail.com>
---
Changes in v2:
- Drop "YAML" from subject and commit message
- Remove incorrect claim that subnode properties were not being validated
.../devicetree/bindings/mfd/ti,twl.yaml | 50 ++++---------------
1 file changed, 10 insertions(+), 40 deletions(-)
diff --git a/Documentation/devicetree/bindings/mfd/ti,twl.yaml b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
index 9cc3e4721612..a3af8e717ec7 100644
--- a/Documentation/devicetree/bindings/mfd/ti,twl.yaml
+++ b/Documentation/devicetree/bindings/mfd/ti,twl.yaml
@@ -265,47 +265,23 @@ properties:
audio:
type: object
- additionalProperties: true
-
- properties:
- compatible:
- const: ti,twl4030-audio
-
- required:
- - compatible
+ $ref: /schemas/sound/ti,twl4030-audio.yaml
+ unevaluatedProperties: false
keypad:
type: object
- additionalProperties: true
-
- properties:
- compatible:
- const: ti,twl4030-keypad
-
- required:
- - compatible
+ $ref: /schemas/input/ti,twl4030-keypad.yaml
+ unevaluatedProperties: false
twl4030-usb:
type: object
- additionalProperties: true
-
- properties:
- compatible:
- const: ti,twl4030-usb
-
- required:
- - compatible
+ $ref: /schemas/usb/ti,twl4030-usb.yaml
+ unevaluatedProperties: false
gpio:
type: object
- additionalProperties: true
-
- properties:
- compatible:
- const: ti,twl4030-gpio
-
- required:
- - compatible
+ $ref: /schemas/gpio/ti,twl4030-gpio.yaml
+ unevaluatedProperties: false
power:
type: object
@@ -371,14 +347,8 @@ properties:
usb-comparator:
type: object
- additionalProperties: true
-
- properties:
- compatible:
- const: ti,twl6030-usb
-
- required:
- - compatible
+ $ref: /schemas/usb/ti,twl6030-usb.yaml
+ unevaluatedProperties: false
pwm:
type: object
--
2.47.3
^ permalink raw reply related
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