* Re: [PATCH v8 0/2] Add Meta(Facebook) ventura2 BMC(AST2600)
From: Kyle Hsieh @ 2026-06-25 5:35 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: devicetree, linux-arm-kernel, linux-aspeed, linux-kernel,
Krzysztof Kozlowski
In-Reply-To: <20260615-ventura2_initial_dts-v8-0-c89f92c80447@gmail.com>
Hi Maintainers,
Just a gentle ping on this v8 series.
All review comments from the previous versions have been addressed.
Please let me know if there is anything else needed for this to be
applied.
Thanks,
Kyle
On Mon, Jun 15, 2026 at 10:44 AM Kyle Hsieh <kylehsieh1995@gmail.com> wrote:
>
> Summary:
> Add linux device tree entry related to Meta(Facebook) ventura2.
> specific devices connected to BMC(AST2600) SoC.
>
> Signed-off-by: Kyle Hsieh <kylehsieh1995@gmail.com>
> ---
> Changes in v8:
> - Addressed review comments from Andrew Lunn:
> * Added a detailed comment to the Marvell 88E6393X EEPROM node to clarify its hardware I2C multiplexer isolation and out-of-band firmware update mechanism, explaining why there is no concurrent access or multi-master scenario.
> - Link to v7: https://lore.kernel.org/r/20260611-ventura2_initial_dts-v7-0-a61d8902bc5f@gmail.com
>
> Changes in v7:
> - Updated the commit message to include a detailed description of the Ventura2 platform's purpose and its key hardware features.
> - Fix comments from Andrew Jeffery:
> * Ensured consistent blank lines to separate child nodes from parent properties and from each other throughout the DTS.
> * Sorted fan nodes in ascending order.
> * Replaced '//' comments with '/* */' block comments.
> - Fix feedback from Sashiko AI:
> * Added 'idle-state = <6>;' to the PCA9548 mux on i2c4.
> - Link to v6: https://lore.kernel.org/r/20260610-ventura2_initial_dts-v6-0-375d8e9d7ebf@gmail.com
>
> Changes in v6:
> - Addressed automated feedback from Sashiko bot:
> * Clarified comments that io_expander0 and io_expander8 physically share the same interrupt line (Wired-OR) by hardware design.
> * Removed leading zeros from unit addresses in DAC nodes (dac@c, dac@e, dac@f).
> * Removed unused properties from the adc@48 node.
> - Link to v5: https://lore.kernel.org/r/20260608-ventura2_initial_dts-v5-0-37ee5bcf58b6@gmail.com
>
> Changes in v5:
> - Addressed review comments:
> * Added comments explaining the necessity of 'legacy_' prefixes (hardware label collision), pre-allocated I2C aliases (future expansions), and the 'ledd1' naming convention (schematic alignment).
> * Removed the empty `&mdio0` node to comply with upstream networking subsystem guidelines.
> * Removed the redundant `&peci0` node.
> * Sorted `&kcs3` and `&lpc_ctrl` nodes in strict alphabetical order.
> - Hardware/DT alignment updates:
> * Removed unpopulated sensors (adi,adt7461, infineon,tda38640, ti,ina230, ti,ina238) to accurately reflect the current board population.
> * Added the secondary flash node (flash@1 labeled "e810") under the &spi2 bus.
> - Link to v4: https://lore.kernel.org/r/20260424-ventura2_initial_dts-v4-0-806b00ea4314@gmail.com
>
> Changes in v4:
> - Fixed capitalization: "ventura2" -> "Ventura2".
> - Reordered I2C child nodes in ascending order of unit addresses.
> - Enable PECI, LPC control, and KCS3 interfaces for host communication.
> - Configure MCTP controller on I2C4 and enable MCTP support for specific mux channels.
> - Add Infineon TDA38640 and TI INA230 power monitor nodes.
> - GPIO and Pinmux cleanup for PVT:
> - Aligned gpio-line-names as requested.
> - Remove unused or non-existent GPIO line names to align with Ventura2 PVT.
> - Update specific GPIO pins to empty strings where signals were removed or consolidated.
> - Adjust SGPIOM frequency to 200kHz and update signal line names.
> - Enable UART3 and add serial2 alias.
> - Link to v3: https://lore.kernel.org/r/20260113-ventura2_initial_dts-v3-0-2dbfda6a5b47@gmail.com
>
> Changes in v3:
> - Add annotation for marvel 88e6393x
> - Modify the gpio-line-name
> - Modify the node order alphabetically
> - Modify dt-bindings document for rmc instead of bmc
> - Move the gpio-line-names to original node
> - Link to v2: https://lore.kernel.org/r/20251224-ventura2_initial_dts-v2-0-f193ba5d4073@gmail.com
>
> Changes in v2:
> - Remove unused mdio
> - Link to v1: https://lore.kernel.org/r/20251222-ventura2_initial_dts-v1-0-1f06166c78a3@gmail.com
>
> ---
> Kyle Hsieh (2):
> dt-bindings: arm: aspeed: add Meta ventura2 board
> ARM: dts: aspeed: ventura2: Add Meta ventura2 BMC
>
> .../devicetree/bindings/arm/aspeed/aspeed.yaml | 1 +
> arch/arm/boot/dts/aspeed/Makefile | 1 +
> .../dts/aspeed/aspeed-bmc-facebook-ventura2.dts | 2903 ++++++++++++++++++++
> 3 files changed, 2905 insertions(+)
> ---
> base-commit: 9448598b22c50c8a5bb77a9103e2d49f134c9578
> change-id: 20251222-ventura2_initial_dts-909b3277d665
>
> Best regards,
> --
> Kyle Hsieh <kylehsieh1995@gmail.com>
>
^ permalink raw reply
* Re: [PATCH RFC v7 0/9] firmware: arm_scmi: vendors: Qualcomm Generic Vendor Extensions
From: Pragnesh Papaniya @ 2026-06-25 5:27 UTC (permalink / raw)
To: Sudeep Holla
Cc: Cristian Marussi, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sibi Sankar, MyungJoo Ham, Kyungmin Park, Chanwoo Choi,
Dmitry Osipenko, Thierry Reding, Jonathan Hunter, Bjorn Andersson,
Konrad Dybcio, Rajendra Nayak, Pankaj Patil, linux-arm-msm,
linux-kernel, arm-scmi, linux-arm-kernel, devicetree, linux-pm,
linux-tegra, Amir Vajid, Ramakrishna Gottimukkula
In-Reply-To: <20260623-busy-beautiful-trout-8cc2ea@sudeepholla>
On 23-Jun-26 2:17 PM, Sudeep Holla wrote:
> On Fri, Jun 19, 2026 at 06:01:23PM +0530, Pragnesh Papaniya wrote:
>>
>> On 16-Jun-26 1:57 PM, Sudeep Holla wrote:
>>
>>> Not sure if it was discussed in the previous versions or not, it would be
>>> good if you can capture why some of bus scaling doesn't work with the existing
>>> SCMI performance protocol and the monitors don't fit the MPAM mode.
>>>
>>> Please capture them in 1/9 as a motivation for this vendor protocol. It will
>>> then help to understand it better as I am still struggling to. Sorry for that.
>>
>> Thanks for the input!
>>
>> SCMI perf protocol exports perf domains to kernel where kernel can set
>> the frequency but here the scaling governor runs on the SCP while kernel
>> just observes frequency changes made by remote governor.
>
> OK if it is sort of read-only w.r.t kernel, why not perf domain notifications
> work to consume the change done by the SCMI platform.
>
> And why do you have set operations in the vendor protocol being proposed then.
> It all looks like something just cooked up to make things work. I need
> detailed reasoning as why the existing perf protocol can't work considering
> all the existing notifications in place.
Please do take another look at the documentation and driver changes to see
how it all comes together, since it's apparent that we use SET operation for
a ton of things. Taking another stab at explaining how the MEMLAT uses all
the ops exposed by the vendor protocol.
We use the SET operation to pass on various tuneables (IPM CEIL, stall floors,
write-back filter, freq-scale params, adaptive low/high freq, sample ms),
the core-freq -> mem-freq map, and min/max clamps) required to run the
MEMLAT algorithm on the SCP. You might ask why can't we have these values
stored somewhere on the SCP itself? We would like to but all of these are
tuneable values, that can change for various boards for the same SoC.
The START/STOP operations are meant to start/stop the algorithm, in this case
the bus scaling algorithm.
We use the GET operation to get the current frequency of memory that we
are trying to scale. It can be also used to read back all the parameters
that we are trying to set. Another thing to note is that exposing the current
frequency to the userspace was something that the community wanted.
With all of ^^ in mind, re-using the perf protocol becomes impossible.
https://lore.kernel.org/lkml/k4lpzxtrq3x6riyv6etxiobn7nbpczf2bp3m4oc752nhjknlit@uo53kbppzim7/
https://lore.kernel.org/lkml/20241115003809epcms1p518df149458f3023d33ec6d87a315e8f6@epcms1p5/
We'll add more call flow diagrams as part of the documentation for the next
re-spin to make reviews a bit more easier.
-Pragnesh
>
>> While MPAM is not enabled/supported on all hardware (Hamoa).
>
> Fair enough but I still don't fully understand to rule that out yet.
>
^ permalink raw reply
* Re: [PATCH v6 4/4] arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
From: sashiko-bot @ 2026-06-25 5:27 UTC (permalink / raw)
To: Alexander Stein; +Cc: imx, Frank.Li, conor+dt, devicetree, robh, wsa+renesas
In-Reply-To: <20260625051449.2560197-4-alexander.stein@ew.tq-group.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The device tree overlay adds a 'ports' node to '&panel_lvds0' without deleting the existing 'port' node, causing a structural conflict and leaving an orphaned, one-way OF graph endpoint.
--
commit 8dc3732086b5dde9e7781747b60e7109f1ba68e8
Author: Alexander Stein <alexander.stein@ew.tq-group.com>
arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
This adds an overlay for the supported LVDS display AUO G133HAN01.
Configure the video PLL frequency to exactly match typical pixel clock of
141.200 MHz.
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
> new file mode 100644
> index 0000000000000..2d2dfda944faa
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
[ ... ]
> +&panel_lvds0 {
> + compatible = "auo,g133han01";
> + status = "okay";
> +
> + ports {
> + #address-cells = <1>;
[Severity: Low]
Does this overlay need to delete the existing port node from the base tree
before defining the ports node?
Without an explicit /delete-node/ port; command, both the port and ports
nodes will coexist in the merged device tree, which violates the mutual
exclusion rule in panel-common-dual.yaml.
Additionally, since the overlay re-defines the panel_in_lvds0 label to point
to the new ports/port@0/endpoint, the old port/endpoint is not deleted. It
will retain its remote-endpoint = <&ldb_lvds_ch0> property, creating a
one-way link that triggers dtc warnings for graph connections not being
bidirectional.
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625051449.2560197-1-alexander.stein@ew.tq-group.com?part=4
^ permalink raw reply
* Re: [PATCH v6 3/4] arm64: dts: freescale: add LVDS overlays for TQMa8MPxS
From: sashiko-bot @ 2026-06-25 5:26 UTC (permalink / raw)
To: Alexander Stein; +Cc: devicetree, robh, wsa+renesas, imx, Frank.Li, conor+dt
In-Reply-To: <20260625051449.2560197-3-alexander.stein@ew.tq-group.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The standalone `.dtbo` files are not added to `dtb-$(CONFIG_ARCH_MXC)`, preventing them from being installed by `make dtbs_install`.
--
commit 11ad35117d23241efb0a2ebb767e914a535c2a98
Author: Paul Gerber <paul.gerber@tq-group.com>
arm64: dts: freescale: add LVDS overlays for TQMa8MPxS
This commit adds device tree overlays for the Tianma tm070jvhg33 display
supported by the TQMa8MPxS on both LVDS channels. The display timings and
pixel clock are explicitly specified to achieve the correct LDB clock
frequency.
> diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
> index 7a1d8586ce7c8..f0779a5d3b737 100644
> --- a/arch/arm64/boot/dts/freescale/Makefile
> +++ b/arch/arm64/boot/dts/freescale/Makefile
> @@ -379,6 +379,11 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtbo
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33.dtb
> dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33-imx219.dtb
>
> +imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtbo
> +imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtbo
> +dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtb
> +dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtb
[Severity: Medium]
Will this omit the standalone .dtbo files from being installed by
make dtbs_install?
The dtb-$(CONFIG_ARCH_MXC) target adds the statically merged composite .dtb
files, but it looks like the standalone .dtbo files are missing. Without
these, users wouldn't be able to apply the overlays dynamically via the
bootloader.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625051449.2560197-1-alexander.stein@ew.tq-group.com?part=3
^ permalink raw reply
* [PATCH v6 1/4] dt-bindings: arm: fsl: add TQMa8MPxS board
From: Alexander Stein @ 2026-06-25 5:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Paul Gerber, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc, Alexander Stein, Conor Dooley
From: Paul Gerber <paul.gerber@tq-group.com>
TQMa8MPxS is a SOM family using NXP i.MX8MP CPU family.
MB-SMARC-2 is an evaluation mainbord for this SOM
The SOM needs a mainboard, therefore we provide two compatibles here:
"tq,imx8mp-<SOM>" for the module and
"tq,imx8mp-<SOM>-<SBC>"
Signed-off-by: Paul Gerber <paul.gerber@tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
---
Changes in v6:
* None
Documentation/devicetree/bindings/arm/fsl.yaml | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 86876311ec59a..6237fb2ae50e6 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1310,6 +1310,18 @@ properties:
- const: tq,imx8mp-tqma8mpql # TQ-Systems GmbH i.MX8MP TQMa8MPQL SOM
- const: fsl,imx8mp
+ - description:
+ TQMa8MPxS is a series of SOM featuring NXP i.MX8MP system-on-chip
+ variants. It has the SMARC-2.0 form factor and is designed to be
+ placed on different carrier boards. All CPU variants use the same
+ device tree hence only one compatible is needed. MB-SMARC-2 is a
+ carrier reference design.
+ items:
+ - enum:
+ - tq,imx8mp-tqma8mpqs-mb-smarc-2 # TQ-Systems GmbH i.MX8MP TQMa8MPQS SOM on MB-SMARC-2
+ - const: tq,imx8mp-tqma8mpqs # TQ-Systems GmbH i.MX8MP TQMa8MPQS SOM
+ - const: fsl,imx8mp
+
- description: Variscite VAR-SOM-MX8M Plus based boards
items:
- const: variscite,var-som-mx8mp-symphony
--
2.54.0
^ permalink raw reply related
* [PATCH v6 2/4] arm64: dts: freescale: add initial device tree for TQMa8MPQS with i.MX8MP
From: Alexander Stein @ 2026-06-25 5:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Paul Gerber, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc, Alexander Stein
In-Reply-To: <20260625051449.2560197-1-alexander.stein@ew.tq-group.com>
From: Paul Gerber <paul.gerber@tq-group.com>
This adds support for TQMa8MPQS module on MB-SMARC-2 board.
Signed-off-by: Paul Gerber <paul.gerber@tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v6:
* Add interrupt to DSI-DP bridge
* Adjust AUDIO_PLL2 clock rate
The eMMC/SD card properties regarding higher speeds, as mentioned by
Sashiko bot, is not necessary for i.MX platforms as the capability bits
privde the correct information already.
The platform already runs at "mmc HS400 enhanced strobe" and
"sd uhs SDR104" (taken from /sys/kernel/debug/mmc*/ios)
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts | 380 ++++++
.../boot/dts/freescale/imx8mp-tqma8mpqs.dtsi | 1178 +++++++++++++++++
3 files changed, 1559 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 43e1dc51b11d7..acb73cde76f16 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -439,6 +439,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-skov-revc-jutouch-jt101tm023.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-toradex-smarc-dev.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mpxl.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2.dtb
imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10-dtbs += imx8mp-tx8p-ml81-moduline-display-106.dtb \
imx8mp-tx8p-ml81-moduline-display-106-av101hdt-a10.dtbo
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts
new file mode 100644
index 0000000000000..f01af630a7c4a
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2.dts
@@ -0,0 +1,380 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Paul Gerber
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include "imx8mp-tqma8mpqs.dtsi"
+
+/ {
+ model = "TQ-Systems i.MX8MPlus TQMa8MPxS on MB-SMARC-2";
+ compatible = "tq,imx8mp-tqma8mpqs-mb-smarc-2", "tq,imx8mp-tqma8mpqs", "fsl,imx8mp";
+ chassis-type = "embedded";
+
+ chosen {
+ stdout-path = &uart3;
+ };
+
+ aliases {
+ ethernet0 = &eqos;
+ ethernet1 = &fec;
+ mmc0 = &usdhc3;
+ mmc1 = &usdhc2;
+ rtc0 = &pcf85063;
+ rtc1 = &snvs_rtc;
+ spi0 = &flexspi;
+ spi1 = &ecspi1;
+ spi2 = &ecspi2;
+ spi3 = &ecspi3;
+ };
+
+ backlight_lvds0: backlight-lvds0 {
+ compatible = "pwm-backlight";
+ pwms = <&pwm3 0 100000 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = <&expander0 0 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_12v0>;
+ status = "disabled";
+ };
+
+ backlight_lvds1: backlight-lvds1 {
+ compatible = "pwm-backlight";
+ pwms = <&pwm2 0 100000 0>;
+ brightness-levels = <0 4 8 16 32 64 128 255>;
+ default-brightness-level = <7>;
+ enable-gpios = <&expander0 2 GPIO_ACTIVE_HIGH>;
+ power-supply = <®_12v0>;
+ status = "disabled";
+ };
+
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ label = "X6";
+ type = "a";
+
+ port {
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&hdmi_tx_out>;
+ };
+ };
+ };
+
+ panel_lvds0: panel-lvds0 {
+ /*
+ * Display is not fixed, so compatible has to be added from
+ * DT overlay
+ */
+ backlight = <&backlight_lvds0>;
+ power-supply = <®_lvds0>;
+ status = "disabled";
+
+ port {
+ panel_in_lvds0: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+ };
+
+ panel_lvds1: panel-lvds1 {
+ /*
+ * Display is not fixed, so compatible has to be added from
+ * DT overlay
+ */
+ backlight = <&backlight_lvds1>;
+ power-supply = <®_lvds1>;
+ status = "disabled";
+
+ port {
+ panel_in_lvds1: endpoint {
+ remote-endpoint = <&ldb_lvds_ch1>;
+ };
+ };
+ };
+
+ reg_1v8: regulator-1v8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1V8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ reg_3v3: regulator-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_12v0: regulator-12v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "12V0";
+ regulator-min-microvolt = <12000000>;
+ regulator-max-microvolt = <12000000>;
+ regulator-always-on;
+ };
+
+ reg_lvds0: regulator-lvds0 {
+ compatible = "regulator-fixed";
+ regulator-name = "LCD0_VDD_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&expander0 1 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reg_lvds1: regulator-lvds1 {
+ compatible = "regulator-fixed";
+ regulator-name = "LCD1_VDD_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&expander0 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ reserved-memory {
+ #address-cells = <2>;
+ #size-cells = <2>;
+ ranges;
+
+ /* global autoconfigured region for contiguous allocations */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ reusable;
+ size = <0 0x38000000>;
+ alloc-ranges = <0 0x40000000 0 0x78000000>;
+ linux,cma-default;
+ };
+ };
+
+ sound {
+ compatible = "fsl,imx-audio-tlv320aic32x4";
+ model = "tqm-tlv320aic32";
+ audio-asrc = <&easrc>;
+ audio-cpu = <&sai5>;
+ audio-codec = <&tlv320aic3x04>;
+ audio-routing =
+ "IN3_L", "Mic Jack",
+ "Mic Jack", "Mic Bias",
+ "IN1_L", "Line In Jack",
+ "IN1_R", "Line In Jack",
+ "Line Out Jack", "LOL",
+ "Line Out Jack", "LOR";
+ };
+
+ usb-connector {
+ compatible = "gpio-usb-b-connector", "usb-b-connector";
+ type = "micro";
+ label = "X4";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usbcon0>;
+ id-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+
+ port {
+ usb_dr_connector: endpoint {
+ remote-endpoint = <&usb3_dwc>;
+ };
+ };
+ };
+};
+
+&easrc {
+ status = "okay";
+};
+
+&ecspi1 {
+ status = "okay";
+};
+
+&eqos {
+ status = "okay";
+};
+
+ðphy0 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+ };
+};
+
+ðphy3 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+
+ led@2 {
+ reg = <2>;
+ color = <LED_COLOR_ID_AMBER>;
+ function = LED_FUNCTION_LAN;
+ function-enumerator = <0>;
+ default-state = "keep";
+ };
+ };
+};
+
+&fec {
+ status = "okay";
+};
+
+&flexcan1 {
+ xceiver-supply = <®_3v3>;
+ status = "okay";
+};
+
+&flexcan2 {
+ xceiver-supply = <®_3v3>;
+ status = "okay";
+};
+
+&hdmi_pvi {
+ status = "okay";
+};
+
+&hdmi_tx {
+ status = "okay";
+
+ ports {
+ port@1 {
+ hdmi_tx_out: endpoint {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+};
+
+&hdmi_tx_phy {
+ status = "okay";
+};
+
+&i2c1 {
+ tlv320aic3x04: audio-codec@18 {
+ compatible = "ti,tlv320aic32x4";
+ reg = <0x18>;
+ clock-names = "mclk";
+ clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI5_MCLK1>;
+ iov-supply = <®_1v8>;
+ ldoin-supply = <®_3v3>;
+ assigned-clocks = <&clk IMX8MP_CLK_SAI5>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12288000>;
+ };
+
+ eeprom2: eeprom@57 {
+ compatible = "atmel,24c32";
+ reg = <0x57>;
+ pagesize = <32>;
+ vcc-supply = <®_3v3>;
+ };
+};
+
+&ldb_lvds_ch0 {
+ remote-endpoint = <&panel_in_lvds0>;
+};
+
+&ldb_lvds_ch1 {
+ remote-endpoint = <&panel_in_lvds1>;
+};
+
+&lcdif1 {
+ status = "okay";
+};
+
+&lcdif3 {
+ status = "okay";
+};
+
+&pcie_phy {
+ fsl,clkreq-unsupported;
+ status = "okay";
+};
+
+&pcie {
+ status = "okay";
+};
+
+®_usdhc2_vmmc {
+ startup-delay-us = <100>;
+ off-on-delay-us = <200000>;
+ status = "okay";
+};
+
+®_usdhc2_vqmmc {
+ status = "okay";
+};
+
+&sai3 {
+ status = "okay";
+};
+
+&sai5 {
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "okay";
+};
+
+&uart1 {
+ status = "okay";
+};
+
+&uart2 {
+ status = "okay";
+};
+
+&uart4 {
+ status = "okay";
+};
+
+&usb3_0 {
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ status = "okay";
+
+ port {
+ usb3_dwc: endpoint {
+ remote-endpoint = <&usb_dr_connector>;
+ };
+ };
+};
+
+&usdhc2 {
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ wp-gpios = <&gpio2 20 GPIO_ACTIVE_HIGH>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ no-mmc;
+ no-sdio;
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
new file mode 100644
index 0000000000000..20d55eeead576
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs.dtsi
@@ -0,0 +1,1178 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/*
+ * Copyright 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Paul Gerber
+ */
+
+#include <dt-bindings/net/ti-dp83867.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>
+#include "imx8mp.dtsi"
+
+/ {
+ model = "TQ-Systems i.MX8MPlus TQMa8MPxS";
+ compatible = "tq,imx8mp-tqma8mpqs", "fsl,imx8mp";
+
+ clk_dp: clk-dp {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <26000000>;
+ };
+
+ clk_xtal25: clk-xtal25 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x0 0x40000000 0 0x80000000>;
+ };
+
+ reg_5v0: regulator-5v0 {
+ compatible = "regulator-fixed";
+ regulator-name = "VCC_5V0";
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ regulator-always-on;
+ };
+
+ reg_usdhc2_vmmc: regulator-usdhc2-vmmc {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>;
+ regulator-name = "SDIO_PWR_EN";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ status = "disabled";
+ };
+
+ reg_usdhc2_vqmmc: regulator-usdhc2-vqmmc {
+ compatible = "regulator-gpio";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_usdhc2_vqmmc>;
+ regulator-name = "V_SD";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ states = <1800000 0x1>,
+ <3300000 0x0>;
+ vin-supply = <&ldo5>;
+ status = "disabled";
+ };
+};
+
+&A53_0 {
+ cpu-supply = <&buck2>;
+};
+
+&audio_blk_ctrl {
+ assigned-clocks = <&clk IMX8MP_AUDIO_PLL1>,
+ <&clk IMX8MP_AUDIO_PLL2>;
+ assigned-clock-rates = <393216000>, <147333333>;
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>, <&gpio5 12 GPIO_ACTIVE_LOW>;
+};
+
+/* GBE0 */
+&eqos {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy0>;
+ snps,force_thresh_dma_mode;
+ snps,mtl-tx-config = <&mtl_tx_setup>;
+ snps,mtl-rx-config = <&mtl_rx_setup>;
+
+ mdio {
+ compatible = "snps,dwmac-mdio";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_eqos_phy>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ reset-gpios = <&expander0 6 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ enet-phy-lane-no-swap;
+ interrupt-parent = <&gpio2>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ ethphy3: ethernet-phy@3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec_phy>;
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <3>;
+ ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
+ ti,fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
+ ti,dp83867-rxctrl-strap-quirk;
+ ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
+ reset-gpios = <&expander0 7 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <500000>;
+ reset-deassert-us = <50000>;
+ enet-phy-lane-no-swap;
+ interrupt-parent = <&gpio2>;
+ interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
+ };
+ };
+
+ mtl_tx_setup: tx-queues-config {
+ snps,tx-queues-to-use = <5>;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ };
+
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x4>;
+ };
+
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x8>;
+ };
+
+ queue4 {
+ snps,dcb-algorithm;
+ snps,priority = <0xf0>;
+ };
+ };
+
+ mtl_rx_setup: rx-queues-config {
+ snps,rx-queues-to-use = <5>;
+ snps,rx-sched-sp;
+
+ queue0 {
+ snps,dcb-algorithm;
+ snps,priority = <0x1>;
+ snps,map-to-dma-channel = <0>;
+ };
+
+ queue1 {
+ snps,dcb-algorithm;
+ snps,priority = <0x2>;
+ snps,map-to-dma-channel = <1>;
+ };
+
+ queue2 {
+ snps,dcb-algorithm;
+ snps,priority = <0x4>;
+ snps,map-to-dma-channel = <2>;
+ };
+
+ queue3 {
+ snps,dcb-algorithm;
+ snps,priority = <0x8>;
+ snps,map-to-dma-channel = <3>;
+ };
+
+ queue4 {
+ snps,dcb-algorithm;
+ snps,priority = <0xf0>;
+ snps,map-to-dma-channel = <4>;
+ };
+ };
+};
+
+/* GBE1 */
+&fec {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_fec>;
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy3>;
+ fsl,magic-packet;
+};
+
+&flexcan1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan1>;
+};
+
+&flexcan2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexcan2>;
+};
+
+&flexspi {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_flexspi0>;
+ status = "okay";
+
+ flash0: flash@0 {
+ reg = <0>;
+ compatible = "jedec,spi-nor";
+ spi-max-frequency = <66666666>;
+ spi-tx-bus-width = <4>;
+ spi-rx-bus-width = <4>;
+ vcc-supply = <&buck5>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ };
+ };
+};
+
+&gpio1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio1>;
+
+ gpio-line-names = "SLEEP", "BATLOW#", "", "LID",
+ "", "GPIO10", "CHARGING#", "CHG_PRSNT#",
+ "PMIC_IRQ#", "ESPI_CS1_ALERT#", "USB1_OTG_ID", "USB2_OTG_ID",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+
+ pmic_irq_hog: pmic-irq-hog {
+ gpio-hog;
+ gpios = <8 0>;
+ input;
+ line-name = "PMIC_IRQ#";
+ };
+};
+
+&gpio2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hoggpio2>;
+
+ gpio-line-names = "", "", "", "",
+ "", "", "", "",
+ "", "", "PERST#", "PEWAKE#",
+ "SDIO_CD#", "", "", "",
+ "", "", "", "SDIO_PWR_EN",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+
+ enet0-int-hog {
+ gpio-hog;
+ gpios = <0 0>;
+ input;
+ line-name = "ENET0_INT#";
+ };
+
+ enet1-int-hog {
+ gpio-hog;
+ gpios = <1 0>;
+ input;
+ line-name = "ENET_INT#";
+ };
+
+ pewake-hog {
+ gpio-hog;
+ gpios = <11 0>;
+ input;
+ line-name = "PEWAKE#";
+ };
+};
+
+&gpio3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio3>;
+
+ gpio-line-names = "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "GPIO4",
+ "GPIO3", "", "", "",
+ "", "", "", "",
+ "TEMP_EVENT#", "", "", "";
+
+ temp-event-hog {
+ gpio-hog;
+ gpios = <28 0>;
+ input;
+ line-name = "TEMP_EVENT#";
+ };
+};
+
+&gpio4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio4>, <&pinctrl_sdp>, <&pinctrl_espi_rst>;
+
+ gpio-line-names = "RTC_INT#", "GPIO8", "", "",
+ "GPIO9", "ESPI_RST#", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "GBE0_SDP_DIR", "",
+ "GPIO7", "", "", "",
+ "", "GPIO0", "GPIO1", "",
+ "GPIO2", "GPIO6", "", "";
+
+ rtc-int-hog {
+ gpio-hog;
+ gpios = <0 0>;
+ input;
+ line-name = "RTC_INT#";
+ };
+
+ espi-reset-hog {
+ gpio-hog;
+ gpios = <5 0>;
+ output-high;
+ line-name = "ESPI_RST#";
+ };
+};
+
+&gpio5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio5>;
+
+ gpio-line-names = "", "", "", "",
+ "", "GPIO5", "", "",
+ "", "", "GPIO12", "GPIO11",
+ "", "GPIO13", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "",
+ "", "", "", "";
+
+ dp-hpd-int-hog {
+ gpio-hog;
+ gpios = <21 0>;
+ input;
+ line-name = "DP_HPD_INT";
+ };
+};
+
+&hdmi_tx {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hdmi>;
+};
+
+&i2c1 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c1>;
+ pinctrl-1 = <&pinctrl_i2c1_gpio>;
+ scl-gpios = <&gpio5 14 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 15 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ eeprom0: eeprom@50 {
+ compatible = "atmel,24c64";
+ reg = <0x50>;
+ pagesize = <32>;
+ read-only;
+ vcc-supply = <&buck5>;
+ };
+
+ pcf85063: rtc@51 {
+ compatible = "nxp,pcf85063a";
+ reg = <0x51>;
+ quartz-load-femtofarads = <7000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcf85063>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <0 IRQ_TYPE_EDGE_FALLING>;
+ };
+
+ eeprom1: eeprom@54 {
+ compatible = "atmel,24c64";
+ reg = <0x54>;
+ pagesize = <32>;
+ vcc-supply = <&buck5>;
+ };
+
+ /* protectable identification memory (part of M24C64-D @50) */
+ eeprom@58 {
+ compatible = "atmel,24c64d-wl";
+ reg = <0x58>;
+ size = <32>;
+ pagesize = <32>;
+ vcc-supply = <&buck5>;
+ };
+
+ /* protectable identification memory (part of M24C64-D @54) */
+ eeprom@5c {
+ compatible = "atmel,24c64d-wl";
+ reg = <0x5c>;
+ size = <32>;
+ pagesize = <32>;
+ vcc-supply = <&buck5>;
+ };
+
+ pcieclk: clock-generator@6a {
+ compatible = "renesas,9fgv0241";
+ reg = <0x6a>;
+ clocks = <&clk_xtal25>;
+ #clock-cells = <1>;
+ };
+
+ inertial-sensor@6b {
+ compatible = "st,ism330dhcx";
+ reg = <0x6b>;
+ vdd-supply = <&buck4>;
+ vddio-supply = <&buck4>;
+ };
+};
+
+&i2c2 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c2>;
+ pinctrl-1 = <&pinctrl_i2c2_gpio>;
+ scl-gpios = <&gpio5 16 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 17 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pmic: pmic@25 {
+ reg = <0x25>;
+ compatible = "nxp,pca9450c";
+
+ /* PMIC PCA9450 PMIC_nINT GPIO1_IO08 */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+
+ regulators {
+ /* V_0V85_SOC: 0.85 .. 0.95 */
+ buck1: BUCK1 {
+ regulator-name = "BUCK1";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <950000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <3125>;
+ };
+
+ /* VDD_ARM */
+ buck2: BUCK2 {
+ regulator-name = "BUCK2";
+ regulator-min-microvolt = <850000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-boot-on;
+ regulator-always-on;
+ nxp,dvs-run-voltage = <950000>;
+ nxp,dvs-standby-voltage = <850000>;
+ regulator-ramp-delay = <3125>;
+ };
+
+ /* VCC3V3 -> VMMC, ... must not be changed */
+ buck4: BUCK4 {
+ regulator-name = "BUCK4";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V8 -> VQMMC, SPI-NOR, ... must not be changed */
+ buck5: BUCK5 {
+ regulator-name = "BUCK5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V1 -> RAM, ... must not be changed */
+ buck6: BUCK6 {
+ regulator-name = "BUCK6";
+ regulator-min-microvolt = <1100000>;
+ regulator-max-microvolt = <1100000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V8_SNVS */
+ ldo1: LDO1 {
+ regulator-name = "LDO1";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* V_1V8_ANA */
+ ldo3: LDO3 {
+ regulator-name = "LDO3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ /* unused */
+ ldo4: LDO4 {
+ regulator-name = "LDO4";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ /* VCC SD IO - switched using SD2 VSELECT */
+ ldo5: LDO5 {
+ regulator-name = "LDO5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ };
+ };
+ };
+
+ tmp1075: temperature-sensor@4a {
+ compatible = "ti,tmp1075";
+ reg = <0x4a>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tmp1075>;
+ vs-supply = <&buck4>;
+ };
+
+ expander0: gpio@73 {
+ compatible = "nxp,pca9538";
+ reg = <0x73>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ vcc-supply = <&buck5>;
+ gpio-line-names = "LCD0_BKLT_EN", "LCD0_VDD_EN",
+ "LCD1_BKLT_EN", "LCD1_VDD_EN",
+ "DP_BRIDGE_EN", "HUB_RST#",
+ "ENET0_RESET#", "ENET1_RESET#";
+ };
+};
+
+&i2c3 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c3>;
+ pinctrl-1 = <&pinctrl_i2c3_gpio>;
+ scl-gpios = <&gpio5 18 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 19 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ dp_bridge: dp-bridge@f {
+ compatible = "toshiba,tc9595", "toshiba,tc358767";
+ reg = <0xf>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tc9595>;
+ clock-names = "ref";
+ clocks = <&clk_dp>;
+ reset-gpios = <&expander0 4 GPIO_ACTIVE_HIGH>;
+ toshiba,hpd-pin = <0>;
+ interrupts-extended = <&gpio5 21 IRQ_TYPE_LEVEL_HIGH>;
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ dsi_in: endpoint {
+ remote-endpoint = <&dsi_out>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ endpoint {
+ toshiba,pre-emphasis = /bits/ 8 <1 1>;
+ };
+ };
+ };
+ };
+};
+
+&i2c4 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ pinctrl-1 = <&pinctrl_i2c4_gpio>;
+ scl-gpios = <&gpio2 4 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 5 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+&i2c6 {
+ clock-frequency = <384000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c6>;
+ pinctrl-1 = <&pinctrl_i2c6_gpio>;
+ scl-gpios = <&gpio2 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio2 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+// Change parent clock of disp1 pixel clock to audio_pll2
+&media_blk_ctrl {
+ assigned-clocks = <&clk IMX8MP_CLK_MEDIA_AXI>,
+ <&clk IMX8MP_CLK_MEDIA_APB>,
+ <&clk IMX8MP_CLK_MEDIA_DISP1_PIX>,
+ <&clk IMX8MP_CLK_MEDIA_DISP2_PIX>,
+ <&clk IMX8MP_CLK_MEDIA_ISP>,
+ <&clk IMX8MP_VIDEO_PLL1>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_1000M>,
+ <&clk IMX8MP_SYS_PLL1_800M>,
+ <&clk IMX8MP_AUDIO_PLL2_OUT>,
+ <&clk IMX8MP_VIDEO_PLL1_OUT>,
+ <&clk IMX8MP_SYS_PLL2_500M>;
+};
+
+&mipi_dsi {
+ samsung,burst-clock-frequency = <1000000000>;
+ samsung,esc-clock-frequency = <10000000>;
+
+ ports {
+ port@1 {
+ reg = <1>;
+
+ dsi_out: endpoint {
+ remote-endpoint = <&dsi_in>;
+ data-lanes = <1 2 3 4>;
+ };
+ };
+ };
+};
+
+&pcie_phy {
+ fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+ clock-names = "ref";
+ clocks = <&pcieclk 0>;
+};
+
+&pcie {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pcie>;
+ clocks = <&clk IMX8MP_CLK_HSIO_ROOT>,
+ <&clk IMX8MP_CLK_HSIO_AXI>,
+ <&clk IMX8MP_CLK_PCIE_ROOT>;
+ clock-names = "pcie", "pcie_bus", "pcie_aux";
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>;
+ assigned-clocks = <&clk IMX8MP_CLK_PCIE_AUX>;
+ assigned-clock-rates = <10000000>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL2_50M>;
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm2>;
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm3>;
+};
+
+&sai3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai3>;
+ assigned-clocks = <&clk IMX8MP_CLK_SAI3>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12288000>;
+};
+
+&sai5 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai5>;
+ assigned-clocks = <&clk IMX8MP_CLK_SAI5>;
+ assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <12288000>;
+ fsl,sai-mclk-direction-output;
+};
+
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ assigned-clocks = <&clk IMX8MP_CLK_UART1>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+ uart-has-rtscts;
+};
+
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ assigned-clocks = <&clk IMX8MP_CLK_UART2>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+ uart-has-rtscts;
+};
+
+&uart3 {
+ /* console */
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ status = "okay";
+};
+
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>;
+ assigned-clocks = <&clk IMX8MP_CLK_UART4>;
+ assigned-clock-parents = <&clk IMX8MP_SYS_PLL1_80M>;
+};
+
+&usb3_phy0 {
+ vbus-supply = <®_5v0>;
+ status = "okay";
+};
+
+&usb3_phy1 {
+ vbus-supply = <®_5v0>;
+ status = "okay";
+};
+
+&usb3_0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb0>;
+ fsl,over-current-active-low;
+};
+
+&usb3_1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_usb1>;
+ fsl,over-current-active-low;
+ status = "okay";
+};
+
+&usb_dwc3_0 {
+ /* dual role is implemented, but not a full featured OTG */
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ dr_mode = "otg";
+ usb-role-switch;
+ role-switch-default-mode = "peripheral";
+ /* SMARC-2 USB0 interface only supports USB 2.0 signals */
+ maximum-speed = "high-speed";
+};
+
+&usb_dwc3_1 {
+ dr_mode = "host";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ hub_2_0: hub@1 {
+ compatible = "usb451,8142";
+ reg = <1>;
+ peer-hub = <&hub_3_0>;
+ reset-gpios = <&expander0 5 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_3v3>;
+ };
+
+ hub_3_0: hub@2 {
+ compatible = "usb451,8140";
+ reg = <2>;
+ peer-hub = <&hub_2_0>;
+ reset-gpios = <&expander0 5 GPIO_ACTIVE_LOW>;
+ vdd-supply = <®_3v3>;
+ };
+};
+
+&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>;
+ bus-width = <4>;
+ vqmmc-supply = <®_usdhc2_vqmmc>;
+ /* NOTE: CD / WP and VMMC support depends on mainboard */
+};
+
+&usdhc3 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc3>;
+ pinctrl-1 = <&pinctrl_usdhc3_100mhz>;
+ pinctrl-2 = <&pinctrl_usdhc3_200mhz>;
+ bus-width = <8>;
+ non-removable;
+ no-sdio;
+ no-sd;
+ vmmc-supply = <&buck4>;
+ vqmmc-supply = <&buck5>;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <MX8MP_IOMUXC_ECSPI1_MISO__ECSPI1_MISO 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI1_MOSI__ECSPI1_MOSI 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI1_SCLK__ECSPI1_SCLK 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI1_SS0__GPIO5_IO09 0x1c0>,
+ <MX8MP_IOMUXC_ECSPI2_MISO__GPIO5_IO12 0x1c0>;
+ };
+
+ pinctrl_eqos: eqosgrp {
+ fsl,pins = <MX8MP_IOMUXC_ENET_MDC__ENET_QOS_MDC 0x40000044>,
+ <MX8MP_IOMUXC_ENET_MDIO__ENET_QOS_MDIO 0x40000044>,
+ <MX8MP_IOMUXC_ENET_RD0__ENET_QOS_RGMII_RD0 0x90>,
+ <MX8MP_IOMUXC_ENET_RD1__ENET_QOS_RGMII_RD1 0x90>,
+ <MX8MP_IOMUXC_ENET_RD2__ENET_QOS_RGMII_RD2 0x90>,
+ <MX8MP_IOMUXC_ENET_RD3__ENET_QOS_RGMII_RD3 0x90>,
+ <MX8MP_IOMUXC_ENET_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x90>,
+ <MX8MP_IOMUXC_ENET_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x90>,
+ <MX8MP_IOMUXC_ENET_TD0__ENET_QOS_RGMII_TD0 0x12>,
+ <MX8MP_IOMUXC_ENET_TD1__ENET_QOS_RGMII_TD1 0x12>,
+ <MX8MP_IOMUXC_ENET_TD2__ENET_QOS_RGMII_TD2 0x12>,
+ <MX8MP_IOMUXC_ENET_TD3__ENET_QOS_RGMII_TD3 0x12>,
+ <MX8MP_IOMUXC_ENET_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x12>,
+ <MX8MP_IOMUXC_ENET_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x14>;
+ };
+
+ pinctrl_eqos_event: eqosevtgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI2_MCLK__ENET_QOS_1588_EVENT3_IN 0x100>,
+ <MX8MP_IOMUXC_SAI2_TXFS__ENET_QOS_1588_EVENT3_OUT 0x1c0>;
+ };
+
+ pinctrl_eqos_phy: eqosphygrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_CLK__GPIO2_IO00 0x1c0>;
+ };
+
+ pinctrl_espi_rst: espirstgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXD3__GPIO4_IO05 0x144>;
+ };
+
+ pinctrl_fec: fecgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXD4__ENET1_RGMII_RD0 0x90>,
+ <MX8MP_IOMUXC_SAI1_RXD5__ENET1_RGMII_RD1 0x90>,
+ <MX8MP_IOMUXC_SAI1_RXD6__ENET1_RGMII_RD2 0x90>,
+ <MX8MP_IOMUXC_SAI1_RXD7__ENET1_RGMII_RD3 0x90>,
+ <MX8MP_IOMUXC_SAI1_TXC__ENET1_RGMII_RXC 0x90>,
+ <MX8MP_IOMUXC_SAI1_TXFS__ENET1_RGMII_RX_CTL 0x90>,
+ <MX8MP_IOMUXC_SAI1_TXD0__ENET1_RGMII_TD0 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD1__ENET1_RGMII_TD1 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD2__ENET1_RGMII_TD2 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD3__ENET1_RGMII_TD3 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD4__ENET1_RGMII_TX_CTL 0x12>,
+ <MX8MP_IOMUXC_SAI1_TXD5__ENET1_RGMII_TXC 0x14>;
+ };
+
+ pinctrl_fec_event: fecevtgrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXD1__ENET1_1588_EVENT1_OUT 0x100>,
+ <MX8MP_IOMUXC_SAI1_RXD0__ENET1_1588_EVENT1_IN 0x1c0>;
+ };
+
+ pinctrl_fec_phy: fecphygrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_CMD__GPIO2_IO01 0x1c0>;
+ };
+
+ pinctrl_flexcan1: flexcan1grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI5_RXD1__CAN1_TX 0x150>,
+ <MX8MP_IOMUXC_SAI5_RXD2__CAN1_RX 0x150>;
+ };
+
+ pinctrl_flexcan2: flexcan2grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI5_RXD3__CAN2_TX 0x150>,
+ <MX8MP_IOMUXC_SAI5_MCLK__CAN2_RX 0x150>;
+ };
+
+ pinctrl_flexspi0: flexspi0grp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_ALE__FLEXSPI_A_SCLK 0x142>,
+ <MX8MP_IOMUXC_NAND_CE0_B__FLEXSPI_A_SS0_B 0x82>,
+ <MX8MP_IOMUXC_NAND_DQS__FLEXSPI_A_DQS 0x40000010>,
+ <MX8MP_IOMUXC_NAND_DATA00__FLEXSPI_A_DATA00 0x82>,
+ <MX8MP_IOMUXC_NAND_DATA01__FLEXSPI_A_DATA01 0x82>,
+ <MX8MP_IOMUXC_NAND_DATA02__FLEXSPI_A_DATA02 0x82>,
+ <MX8MP_IOMUXC_NAND_DATA03__FLEXSPI_A_DATA03 0x82>;
+ };
+
+ pinctrl_sdp: gbegrp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_TXD6__GPIO4_IO18 0x10>,
+ <MX8MP_IOMUXC_SAI1_TXD7__GPIO4_IO19 0x10>;
+ };
+
+ pinctrl_gpio1: gpio1grp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO00__GPIO1_IO00 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO01__GPIO1_IO01 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO03__GPIO1_IO03 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO05__GPIO1_IO05 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO06__GPIO1_IO06 0x10>,
+ <MX8MP_IOMUXC_GPIO1_IO07__GPIO1_IO07 0x80>,
+ <MX8MP_IOMUXC_GPIO1_IO09__GPIO1_IO09 0x80>;
+ };
+
+ pinctrl_gpio3: gpio3grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI5_RXFS__GPIO3_IO19 0x10>,
+ <MX8MP_IOMUXC_SAI5_RXC__GPIO3_IO20 0x10>;
+ };
+
+ pinctrl_gpio4: gpio4grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXC__GPIO4_IO01 0x10>,
+ <MX8MP_IOMUXC_SAI1_RXD2__GPIO4_IO04 0x10>,
+ <MX8MP_IOMUXC_SAI1_MCLK__GPIO4_IO20 0x10>,
+ <MX8MP_IOMUXC_SAI2_TXC__GPIO4_IO25 0x10>,
+ <MX8MP_IOMUXC_SAI2_TXD0__GPIO4_IO26 0x10>,
+ <MX8MP_IOMUXC_SAI3_RXFS__GPIO4_IO28 0x10>,
+ <MX8MP_IOMUXC_SAI3_RXC__GPIO4_IO29 0x10>;
+ };
+
+ pinctrl_gpio5: gpio5grp {
+ fsl,pins = <MX8MP_IOMUXC_SPDIF_EXT_CLK__GPIO5_IO05 0x10>,
+ <MX8MP_IOMUXC_ECSPI2_SCLK__GPIO5_IO10 0x10>,
+ <MX8MP_IOMUXC_ECSPI2_MOSI__GPIO5_IO11 0x10>,
+ <MX8MP_IOMUXC_ECSPI2_SS0__GPIO5_IO13 0x10>;
+ };
+
+ pinctrl_hdmi: hdmigrp {
+ fsl,pins = <MX8MP_IOMUXC_HDMI_DDC_SCL__HDMIMIX_HDMI_SCL 0x400001c2>,
+ <MX8MP_IOMUXC_HDMI_DDC_SDA__HDMIMIX_HDMI_SDA 0x400001c2>,
+ <MX8MP_IOMUXC_HDMI_HPD__HDMIMIX_HDMI_HPD 0x40000010>;
+ };
+
+ pinctrl_hoggpio2: hoggpio2grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_STROBE__GPIO2_IO11 0x140>;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C1_SCL__I2C1_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_I2C1_SDA__I2C1_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c1_gpio: i2c1-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C1_SCL__GPIO5_IO14 0x400001e2>,
+ <MX8MP_IOMUXC_I2C1_SDA__GPIO5_IO15 0x400001e2>;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C2_SCL__I2C2_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_I2C2_SDA__I2C2_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c2_gpio: i2c2-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C2_SCL__GPIO5_IO16 0x400001e2>,
+ <MX8MP_IOMUXC_I2C2_SDA__GPIO5_IO17 0x400001e2>;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C3_SCL__I2C3_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_I2C3_SDA__I2C3_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c3_gpio: i2c3-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C3_SCL__GPIO5_IO18 0x400001e2>,
+ <MX8MP_IOMUXC_I2C3_SDA__GPIO5_IO19 0x400001e2>;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA2__I2C4_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA3__I2C4_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c4_gpio: i2c4-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA2__GPIO2_IO04 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA3__GPIO2_IO05 0x400001e2>;
+ };
+
+ pinctrl_i2c6: i2c6grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA0__I2C6_SCL 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA1__I2C6_SDA 0x400001e2>;
+ };
+
+ pinctrl_i2c6_gpio: i2c6-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA0__GPIO2_IO02 0x400001e2>,
+ <MX8MP_IOMUXC_SD1_DATA1__GPIO2_IO03 0x400001e2>;
+ };
+
+ pinctrl_pcf85063: pcf85063grp {
+ fsl,pins = <MX8MP_IOMUXC_SAI1_RXFS__GPIO4_IO00 0x80>;
+ };
+
+ pinctrl_pcie: pciegrp {
+ fsl,pins = <MX8MP_IOMUXC_I2C4_SCL__PCIE_CLKREQ_B 0x60>,
+ <MX8MP_IOMUXC_SD1_RESET_B__GPIO2_IO10 0x94>;
+ };
+
+ pinctrl_pmic: pmicirqgrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO08__GPIO1_IO08 0x1c0>;
+ };
+
+ pinctrl_pwm2: pwm2grp {
+ fsl,pins = <MX8MP_IOMUXC_SPDIF_RX__PWM2_OUT 0x14>;
+ };
+
+ pinctrl_pwm3: pwm3grp {
+ fsl,pins = <MX8MP_IOMUXC_SPDIF_TX__PWM3_OUT 0x14>;
+ };
+
+ pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_RESET_B__GPIO2_IO19 0x10>;
+ };
+
+ pinctrl_reg_usdhc2_vqmmc: regusdhc2vqmmcgrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO04__GPIO1_IO04 0xc0>;
+ };
+
+ pinctrl_sai3: sai3grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI3_RXD__AUDIOMIX_SAI3_RX_DATA00 0x94
+ MX8MP_IOMUXC_SAI3_TXD__AUDIOMIX_SAI3_TX_DATA00 0x94
+ MX8MP_IOMUXC_SAI3_TXFS__AUDIOMIX_SAI3_TX_SYNC 0x94
+ MX8MP_IOMUXC_SAI3_TXC__AUDIOMIX_SAI3_TX_BCLK 0x94
+ >;
+ };
+
+ pinctrl_sai5: sai5grp {
+ fsl,pins = <
+ MX8MP_IOMUXC_SAI3_MCLK__AUDIOMIX_SAI5_MCLK 0x94
+ MX8MP_IOMUXC_SAI5_RXD0__AUDIOMIX_SAI5_RX_DATA00 0x94
+ MX8MP_IOMUXC_SAI2_RXD0__AUDIOMIX_SAI5_TX_DATA00 0x94
+ MX8MP_IOMUXC_SAI2_RXFS__AUDIOMIX_SAI5_TX_SYNC 0x94
+ MX8MP_IOMUXC_SAI2_RXC__AUDIOMIX_SAI5_TX_BCLK 0x94
+ >;
+ };
+
+ pinctrl_tc9595: tc9595grp {
+ fsl,pins = <MX8MP_IOMUXC_I2C4_SDA__GPIO5_IO21 0x10>;
+ };
+
+ pinctrl_tmp1075: tmp1075grp {
+ fsl,pins = <MX8MP_IOMUXC_HDMI_CEC__GPIO3_IO28 0x140>;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <MX8MP_IOMUXC_UART1_TXD__UART1_DCE_TX 0x140>,
+ <MX8MP_IOMUXC_UART1_RXD__UART1_DCE_RX 0x140>,
+ <MX8MP_IOMUXC_UART3_RXD__UART1_DCE_CTS 0x140>,
+ <MX8MP_IOMUXC_UART3_TXD__UART1_DCE_RTS 0x140>;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <MX8MP_IOMUXC_UART2_TXD__UART2_DCE_TX 0x140>,
+ <MX8MP_IOMUXC_UART2_RXD__UART2_DCE_RX 0x140>,
+ <MX8MP_IOMUXC_SD1_DATA4__UART2_DCE_RTS 0x140>,
+ <MX8MP_IOMUXC_SD1_DATA5__UART2_DCE_CTS 0x140>;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <MX8MP_IOMUXC_SD1_DATA6__UART3_DCE_TX 0x140>,
+ <MX8MP_IOMUXC_SD1_DATA7__UART3_DCE_RX 0x140>;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <MX8MP_IOMUXC_UART4_RXD__UART4_DCE_RX 0x140>,
+ <MX8MP_IOMUXC_UART4_TXD__UART4_DCE_TX 0x140>;
+ };
+
+ pinctrl_usb0: usb0grp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO13__USB1_OTG_OC 0x1c0>,
+ <MX8MP_IOMUXC_GPIO1_IO12__USB1_OTG_PWR 0x1c0>;
+ };
+
+ pinctrl_usb1: usb1grp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO15__USB2_OTG_OC 0x1c0>,
+ <MX8MP_IOMUXC_GPIO1_IO14__USB2_OTG_PWR 0x1c0>;
+ };
+
+ pinctrl_usbcon0: usb0congrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO10__GPIO1_IO10 0x1c0>;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x192>,
+ <MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d2>,
+ <MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d2>;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x194>,
+ <MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4>;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CLK__USDHC2_CLK 0x194>,
+ <MX8MP_IOMUXC_SD2_CMD__USDHC2_CMD 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA0__USDHC2_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA1__USDHC2_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA2__USDHC2_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_SD2_DATA3__USDHC2_DATA3 0x1d4>;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
+ fsl,pins = <MX8MP_IOMUXC_SD2_CD_B__GPIO2_IO12 0x1c0>,
+ <MX8MP_IOMUXC_SD2_WP__GPIO2_IO20 0x1c0>;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194>,
+ <MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4>,
+ <MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x84>,
+ <MX8MP_IOMUXC_NAND_READY_B__USDHC3_RESET_B 0x84>;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194>,
+ <MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4>,
+ <MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x84>,
+ <MX8MP_IOMUXC_NAND_READY_B__USDHC3_RESET_B 0x84>;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <MX8MP_IOMUXC_NAND_WE_B__USDHC3_CLK 0x194>,
+ <MX8MP_IOMUXC_NAND_WP_B__USDHC3_CMD 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA04__USDHC3_DATA0 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA05__USDHC3_DATA1 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA06__USDHC3_DATA2 0x1d4>,
+ <MX8MP_IOMUXC_NAND_DATA07__USDHC3_DATA3 0x1d4>,
+ <MX8MP_IOMUXC_NAND_RE_B__USDHC3_DATA4 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE2_B__USDHC3_DATA5 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE3_B__USDHC3_DATA6 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CLE__USDHC3_DATA7 0x1d4>,
+ <MX8MP_IOMUXC_NAND_CE1_B__USDHC3_STROBE 0x84>,
+ <MX8MP_IOMUXC_NAND_READY_B__USDHC3_RESET_B 0x84>;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <MX8MP_IOMUXC_GPIO1_IO02__WDOG1_WDOG_B 0x1c4>;
+ };
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v6 4/4] arm64: dts: freescale: Add dual-channel LVDS overlay for TQMa8MPxS
From: Alexander Stein @ 2026-06-25 5:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Alexander Stein, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc
In-Reply-To: <20260625051449.2560197-1-alexander.stein@ew.tq-group.com>
This adds an overlay for the supported LVDS display AUO G133HAN01.
Configure the video PLL frequency to exactly match typical pixel clock of
141.200 MHz.
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v6:
* None
arch/arm64/boot/dts/freescale/Makefile | 2 +
...p-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso | 81 +++++++++++++++++++
2 files changed, 83 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 2f4568e7105f4..0c390ef6f7571 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -498,8 +498,10 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33-imx219.dtb
+imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtbo
imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtbo
imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
new file mode 100644
index 0000000000000..2d2dfda944faa
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds-g133han01.dtso
@@ -0,0 +1,81 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Martin Schmiedel
+ */
+
+/dts-v1/;
+/plugin/;
+
+&backlight_lvds0 {
+ status = "okay";
+};
+
+&panel_lvds0 {
+ compatible = "auo,g133han01";
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ dual-lvds-odd-pixels;
+
+ panel_in_lvds0: endpoint {
+ remote-endpoint = <&ldb_lvds_ch0>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ dual-lvds-even-pixels;
+
+ panel_in_lvds1: endpoint {
+ remote-endpoint = <&ldb_lvds_ch1>;
+ };
+ };
+ };
+};
+
+&lcdif2 {
+ status = "okay";
+};
+
+&lvds_bridge {
+ status = "okay";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ ldb_lvds_ch0: endpoint {
+ remote-endpoint = <&panel_in_lvds0>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+
+ ldb_lvds_ch1: endpoint {
+ remote-endpoint = <&panel_in_lvds1>;
+ };
+ };
+ };
+};
+
+// Update VIDEO_PLL1 frequency
+&media_blk_ctrl {
+ assigned-clock-rates = <500000000>, <200000000>,
+ <0>, <0>, <500000000>,
+ <988400000>;
+};
+
+&pwm3 {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* [PATCH v6 3/4] arm64: dts: freescale: add LVDS overlays for TQMa8MPxS
From: Alexander Stein @ 2026-06-25 5:14 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Geert Uytterhoeven, Magnus Damm, Shawn Guo
Cc: Paul Gerber, devicetree, linux-kernel, imx, linux-arm-kernel,
linux, linux-renesas-soc, Alexander Stein
In-Reply-To: <20260625051449.2560197-1-alexander.stein@ew.tq-group.com>
From: Paul Gerber <paul.gerber@tq-group.com>
This adds overlays for the supported LVDS display tianma tm070jvhg33
for both LVDS channels.
The display timings have to be specified explicitly. Using the typical
pixel clock, the LDB clock can not be configured as the 7-fold of that.
By setting pixel clock to 74.25 MHz, LDB can be configured to exactly
519.75 MHz.
Signed-off-by: Paul Gerber <paul.gerber@tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
Changes in v6:
* None
arch/arm64/boot/dts/freescale/Makefile | 5 +++
...qma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtso | 43 +++++++++++++++++++
...qma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtso | 43 +++++++++++++++++++
3 files changed, 91 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtso
create mode 100644 arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtso
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index acb73cde76f16..2f4568e7105f4 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -498,6 +498,11 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-imx219.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpql-mba8mp-ras314-lvds-tm070jvhg33-imx219.dtb
+imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtbo
+imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33-dtbs += imx8mp-tqma8mpqs-mb-smarc-2.dtb imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtbo
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtb
+
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk.dtb
imx8mq-evk-pcie1-ep-dtbs += imx8mq-evk.dtb imx-pcie1-ep.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8mq-evk-pcie1-ep.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtso
new file mode 100644
index 0000000000000..2cf1de8c05b49
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds0-tm070jvhg33.dtso
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Paul Gerber
+ */
+
+/dts-v1/;
+/plugin/;
+
+&backlight_lvds0 {
+ status = "okay";
+};
+
+&panel_lvds0{
+ compatible = "tianma,tm070jvhg33";
+ status = "okay";
+
+ panel-timing {
+ clock-frequency = <74250000>;
+ hactive = <1280>;
+ vactive = <800>;
+ hfront-porch = <64>;
+ hback-porch = <5>;
+ hsync-len = <1>;
+ vfront-porch = <40>;
+ vback-porch = <2>;
+ vsync-len = <1>;
+ de-active = <1>;
+ };
+};
+
+&lcdif2 {
+ status = "okay";
+};
+
+&lvds_bridge {
+ status = "okay";
+};
+
+&pwm3 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtso b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtso
new file mode 100644
index 0000000000000..cbad0cfab2925
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mp-tqma8mpqs-mb-smarc-2-lvds1-tm070jvhg33.dtso
@@ -0,0 +1,43 @@
+// SPDX-License-Identifier: (GPL-2.0-or-later OR MIT)
+/*
+ * Copyright (c) 2025-2026 TQ-Systems GmbH <linux@ew.tq-group.com>,
+ * D-82229 Seefeld, Germany.
+ * Author: Paul Gerber
+ */
+
+/dts-v1/;
+/plugin/;
+
+&backlight_lvds1 {
+ status = "okay";
+};
+
+&panel_lvds1{
+ compatible = "tianma,tm070jvhg33";
+ status = "okay";
+
+ panel-timing {
+ clock-frequency = <74250000>;
+ hactive = <1280>;
+ vactive = <800>;
+ hfront-porch = <64>;
+ hback-porch = <5>;
+ hsync-len = <1>;
+ vfront-porch = <40>;
+ vback-porch = <2>;
+ vsync-len = <1>;
+ de-active = <1>;
+ };
+};
+
+&lcdif2 {
+ status = "okay";
+};
+
+&lvds_bridge {
+ status = "okay";
+};
+
+&pwm2 {
+ status = "okay";
+};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Dmitry Torokhov @ 2026-06-25 4:53 UTC (permalink / raw)
To: David Heidelberg
Cc: Krzysztof Kozlowski, Konrad Dybcio, Rob Herring, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio, linux-input, devicetree,
linux-kernel, linux-arm-msm, phone-devel, Krzysztof Kozlowski
In-Reply-To: <52b7dd3a-3f6f-474c-8386-4fc2776b185b@ixit.cz>
On Wed, Jun 24, 2026 at 04:37:25PM +0200, David Heidelberg wrote:
> On 24/06/2026 06:28, Dmitry Torokhov wrote:
> > Hi David,
> >
> > On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
> > > On 28/05/2026 00:13, David Heidelberg wrote:
> > > > On 27/05/2026 23:56, Dmitry Torokhov wrote:
> > > > > Hi David,
> > > > >
> > > > > On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
> > > > > > From: David Heidelberg <david@ixit.cz>
> > > > > >
> > > > > > We know the driver is reporting s3706b, introduce the compatible so we
> > > > > > can more easily introduce quirks for weird touchscreen replacements in
> > > > > > followup series.
> > > > > >
> > > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > > > > Signed-off-by: David Heidelberg <david@ixit.cz>
> > > > > > ---
> > > > > > arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > b/arch/ arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > index 6b7378cf4d493..148164d456a5a 100644
> > > > > > --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > @@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
> > > > > > };
> > > > > > };
> > > > > > &i2c12 {
> > > > > > status = "okay";
> > > > > > clock-frequency = <400000>;
> > > > > > synaptics-rmi4-i2c@20 {
> > > > > > - compatible = "syna,rmi4-i2c";
> > > > > > + compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
> > > > >
> > > > > So I believe we established that this device (s3706b) does not in fact
> > > > > implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
> > > > > fallback? Shouldn't it be just "syna,rmi4-s3706b"?
> > > >
> > > > The vendor supplies s3706b which does implement the RMI4 properly.
> > > >
> > > > The 3rd party replacement impersonating original parts may not implement
> > > > it properly, but I don't address this issue in this initial submission.
> > > >
> > > > With this compatible we know which original part is used by the vendor
> > > > and installed in the phones, so later we can deduct specific sequences
> > > > for the replacement aftermarket parts to keep phone touchscreen working
> > > > same as they do on Android without affecting other devices.
> > >
> > > Hello Dmitry.
> > >
> > > May I ask what is currently preventing this series from moving forward?
> > >
> > > The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
> > > and am now on the 9th iteration (this patchset). At this point, the series
> > > has been under discussion for well over a year, with relatively little
> > > feedback and increasingly long gaps between review rounds.
> > >
> > > The current approach is based on the guidance I have received so far,
> > > including suggestions from the device-tree maintainers. When concerns were
> > > raised, I tried to address them and rework the series accordingly.
> > >
> > > What I am struggling with is understanding what specific issue still needs
> > > to be resolved before these patches can be accepted. If there are remaining
> > > requirements, objections to the approach, or technical concerns that I have
> > > not addressed, I would appreciate having them stated explicitly so I can
> > > work on them.
> > >
> > > I also split out the straightforward, self-contained changes in the hope
> > > that at least those could progress independently while I continued working
> > > on any follow-up requirements. However, even those patches do not appear to
> > > be moving forward.
> > >
> > > Could you please clarify what outcome you would like to see from this
> > > series, and what concrete changes would be required to get it accepted?
> >
> > I am still confused about how you want to differentiate between the full
> > RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
> > mentioned, implements RMI4 protocol properly, so we do not need to
> > actually have it documented neither in binding nor in DTS.
>
> --- part 1 ---
>
> This series addresses identification within device-tree. It's normal
> recommended practice.
>
> If we know, the device ships specific, but **compliant** variant, we just
> put it as compatible = "more-specific", "less-specific"; in this case
> "syna,rmi4-s3706b", "syna,rmi4-i2c"
>
> This approach is used everywhere. This has nothing to do with after-market parts.
We do this in many cases, sometimes when a part has different timings or
maybe additional functionality compared to the base model.
How does this new compatible for controller that fully implements RMI4
protocol help here?
>
> --- part 2 (irrelevant for this series) ---
>
> >
> > The issue you have with after-market parts that are not compliant and we
> > need to figure out how to deal with them. Inside the driver I
>
> As was suggested by device-tree folks, this is the first step, there isn't
> better one available. If there is, please suggest one, and I'll apply it.
Was it clearly communicated to DT folks that the compatible you are
adding is fully compatible with the base "syna,rmi4-i2c" but other ones
will not be compatible?
>
> > essentially need a"incomplete protocol" flag that we can use to
> > implement additional checks or skip known to be not implemented
> > functions/queries. In DT we could introduce something like
> > "oneplus,rmi4-i2c" that is decidedly not compatible with "syna,rmi4-i2c"
> > and neither one should be a fallback for the other.
> >
> > This of course needs buy-in from DT maintainers.
>
> As you can see, this still holds Acked-by and Reviewed-by from the relevant
> people - Krzysztof and Konrad.
I see that but the commit does not explain how exactly you are planning
to deal with knockoffs.
>
> >
> > Does this make sense?
>
> For the scope we're discussing it doesn't seems so.
>
> This discussion should be associated with the last revision of the full
> series I sent 3 months ago. We're in very unflattering state, where:
>
> 2018 - these aftermarket touchscreen worked on Android well enough for
> people to have working touch (let's say with slightly worse experience then
> the original).
>
> 2026 in the mainline, we cannot even more forward and report to user-space
> there is aftermarket non-compliant piece of hardware installed.
>
> Actionable steps I suggest after this series lands:
>
> 1. don't do any changes, but since we know what 3rd party touchscreen do
> incorrectly deviating from the standard, REPORT it to the userspace, so USER
> know, their device (phone/tablet) doesn't have original part.
>
> 2. then figure out, IF we can reasonably well workaround it and HOW to do it
>
> These two steps present some progress which could be discussed and could
> lead us somewhere, what do you think?
So since we know that these devices can come with controllers that do
not implement RMI4 fully, can we:
1. Establish a new compatible that is separate from syna,rmi4-i2c? As I
mentioned, it could be oneplus,rmi4-i2c or event a concrete controller
vendor,id combo. The point that it should be completely separate from
the current compatible and not use the current compatible as a fallback.
2. Make modifications to RMI4 implementation to handle these controllers
in a reasonable manner, but not mess up the full RMI4 support
3. Update DTS for the affected headsets to switch them to this new
implementation.2. Make modifications to RMI4 implementation to handle
these controllers in a reasonable manner, but not mess up the full RMI4
support
3. Update DTS for the affected headsets to switch them to this new
implementation.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: mfd: qcom,spmi-pmic: Document haptics device
From: Rob Herring (Arm) @ 2026-06-25 3:32 UTC (permalink / raw)
To: Fenglin Wu
Cc: Subbaraman Narayanamurthy, Lee Jones, devicetree, kernel,
Dmitry Torokhov, Bjorn Andersson, linux-kernel, David Collins,
Kamal Wadhwa, Conor Dooley, Krzysztof Kozlowski, linux-input,
Stephen Boyd, Konrad Dybcio, linux-arm-msm
In-Reply-To: <20260624-qcom-spmi-haptics-v2-2-b9118e60f3e3@oss.qualcomm.com>
On Wed, 24 Jun 2026 19:00:37 -0700, Fenglin Wu wrote:
> Some of the Qualcomm SPMI PMIC has haptics device in it, add it in the
> device list.
>
> Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 ++++
> 1 file changed, 4 insertions(+)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/qcom,spmi-haptics.yaml: properties:qcom,vmax-microvolt: '$ref' should not be valid under {'const': '$ref'}
hint: Standard unit suffix properties don't need a type $ref
from schema $id: http://devicetree.org/meta-schemas/core.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/input/qcom,spmi-haptics.example.dtb: haptics@f000 (qcom,spmi-haptics): qcom,vmax-microvolt: 1300000 is not of type 'array'
from schema $id: http://devicetree.org/schemas/property-units.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260624-qcom-spmi-haptics-v2-2-b9118e60f3e3@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH v2 4/4] phy: nuvoton: phy-ma35d1-usb2: extend to dual-port with OTG support
From: sashiko-bot @ 2026-06-25 2:59 UTC (permalink / raw)
To: Joey Lu
Cc: neil.armstrong, robh, conor+dt, olteanv, devicetree, vkoul,
linux-phy
In-Reply-To: <20260625023958.569299-5-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] The custom `ma35_usb_phy_xlate` callback accesses `args->args[0]` without verifying `args->args_count`, leading to a potential read of uninitialized stack memory.
- [High] The driver breaks Device Tree backward compatibility by unconditionally relying on the parent's `of_node` for the syscon regmap, removing the legacy 'nuvoton,sys' phandle fallback.
- [High] The driver fails to explicitly clear the 'MISCFCR0_UHOVRCURH' bit if the 'nuvoton,oc-active-high' property is absent, leading to persistent incorrect hardware state across soft reboots.
- [High] The driver incorrectly skips PHY clock stabilization checks if the `SUSPEND` bit is already set, potentially leading to hardware hangs.
- [Medium] The variable 'val' in `ma35_role_sw_get` is used uninitialized if the `regmap_read` call fails.
--
commit ff3f6d83cfb95f48a64d4c533549a7465a41d150
Author: Joey Lu <a0987203069@gmail.com>
phy: nuvoton: phy-ma35d1-usb2: extend to dual-port with OTG support
This commit extends the driver to support both PHY ports and integrates OTG
role switching. It introduces a custom xlate function, unifies the init
callback, removes redundant clock management, and registers a USB role switch.
> --- a/drivers/phy/nuvoton/phy-ma35d1-usb2.c
> +++ b/drivers/phy/nuvoton/phy-ma35d1-usb2.c
[ ... ]
> +static int ma35_usb_phy_init(struct phy *phy)
> +{
> + struct ma35_phy_port *port = phy_get_drvdata(phy);
> + struct ma35_usb_phy *p = container_of(port - port->idx,
> + struct ma35_usb_phy, port[0]);
> + unsigned int n = port->idx;
> + unsigned int val;
> + int ret;
> +
> + regmap_read(p->sysreg, MA35_SYS_USBPMISCR, &val);
> +
> + if (val & USBPMISCR_PHY_SUSPEND(n))
> + return 0;
[Severity: High]
Does returning early here skip necessary PHY clock stabilization checks?
The previous implementation specifically polled the clock stable bit
even when the suspend bit was already set. By returning immediately,
the USB controller might start accessing the PHY before its newly ungated
clock has fully stabilized, potentially resulting in bus hangs.
[ ... ]
> +static enum usb_role ma35_role_sw_get(struct usb_role_switch *sw)
> +{
> + struct ma35_usb_phy *p = usb_role_switch_get_drvdata(sw);
> + u32 val;
> +
> + regmap_read(p->sysreg, MA35_SYS_PWRONOTP, &val);
> +
> + return (val & PWRONOTP_USBP0ID) ? USB_ROLE_HOST : USB_ROLE_DEVICE;
> +}
[Severity: Medium]
Is it possible for val to be evaluated uninitialized here?
If regmap_read() encounters an error, it returns a non-zero error code
and leaves val unmodified. This could cause the function to return an
incorrect USB role based on stack garbage.
[ ... ]
> +static struct phy *ma35_usb_phy_xlate(struct device *dev,
> + const struct of_phandle_args *args)
> +{
> + struct ma35_usb_phy *p = dev_get_drvdata(dev);
> +
> + if (args->args[0] >= MA35_PHY_NUM)
> + return ERR_PTR(-EINVAL);
[Severity: High]
Does this code safely handle device trees where the number of phy cells is zero?
If args_count is zero, args->args would be uninitialized stack memory,
which could result in returning an incorrect PHY port or out-of-bounds
access. Should there be a check for args->args_count >= 1?
[ ... ]
> +static int ma35_usb_phy_probe(struct platform_device *pdev)
> +{
[ ... ]
> + p->sysreg = syscon_node_to_regmap(pdev->dev.parent->of_node);
> + if (IS_ERR(p->sysreg))
> + return dev_err_probe(&pdev->dev, PTR_ERR(p->sysreg),
> + "failed to get parent SYS regmap\n");
[Severity: High]
Does this break Device Tree backward compatibility?
The old implementation relied on a "nuvoton,sys" phandle fallback which has
been removed here. Systems using older device tree binaries might fail to
probe the USB PHY on kernel upgrades if the node isn't a direct child of
the syscon.
[ ... ]
> + if (of_property_read_bool(pdev->dev.of_node, "nuvoton,oc-active-high"))
> + regmap_update_bits(p->sysreg, MA35_SYS_MISCFCR0,
> + MISCFCR0_UHOVRCURH, MISCFCR0_UHOVRCURH);
[Severity: High]
If the "nuvoton,oc-active-high" property is absent, should this code explicitly
clear the MISCFCR0_UHOVRCURH bit?
Without an else branch to clear the bit, a soft reboot could incorrectly
inherit an active-high state set by a bootloader or previous kernel.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625023958.569299-1-a0987203069@gmail.com?part=4
^ permalink raw reply
* Re: [PATCH v2 2/4] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
From: sashiko-bot @ 2026-06-25 2:58 UTC (permalink / raw)
To: Joey Lu
Cc: vkoul, devicetree, neil.armstrong, conor+dt, olteanv, linux-phy,
robh
In-Reply-To: <20260625023958.569299-3-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The commit message claims multiple driver behavioral changes that are missing from the patch, leaving the driver incompatible with the new binding.
--
commit f557b8622653f3df69b040020ac61c52fd0498d6
Author: Joey Lu <a0987203069@gmail.com>
dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
This commit updates the device tree binding for the MA35D1 USB2 PHY to support
dual-port OTG. It changes the PHY node to be a child of a syscon node, removes
the nuvoton,sys and clocks properties, and updates #phy-cells to 1.
> - The PHY node is now a child of the system-management syscon node
> with a reg property. The nuvoton,sys phandle and clocks properties
> are removed; the driver derives the regmap from its parent, and
> clock gating is owned by each individual USB controller.
>
> - #phy-cells changes from 0 to 1: the cell selects the PHY port.
> diff --git a/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
> index fff858c909a06..a20d03c80932b 100644
> --- a/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
> +++ b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
[ ... ]
> @@ -8,38 +8,72 @@ title: Nuvoton MA35D1 USB2 phy
[ ... ]
> "#phy-cells":
> - const: 0
> + const: 1
> + description:
> + The single cell selects the PHY port. 0 selects the OTG port (USB0,
> + shared with DWC2 gadget controller) and 1 selects the host-only port
> + (USB1).
>
> - clocks:
> - maxItems: 1
>
> - nuvoton,sys:
> - $ref: /schemas/types.yaml#/definitions/phandle
> + nuvoton,rcalcode:
[Severity: High]
Does this patch introduce a regression by updating the binding without the
corresponding driver updates?
The commit message indicates the driver derives the regmap from its parent and
handles the #phy-cells change, but this patch does not contain driver
modifications.
If a device tree is updated to comply with this new binding, will the existing
driver fail to probe? Looking at ma35_usb_phy_probe() in
drivers/phy/nuvoton/phy-ma35d1-usb2.c, it unconditionally requires the
nuvoton,sys property:
drivers/phy/nuvoton/phy-ma35d1-usb2.c:ma35_usb_phy_probe() {
...
p_phy->sysreg = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
"nuvoton,sys");
if (IS_ERR(p_phy->sysreg))
...
}
Additionally, the unmodified driver still uses of_phy_simple_xlate and
registers a single PHY, which is structurally incompatible with the binding
change to #phy-cells = <1>:
drivers/phy/nuvoton/phy-ma35d1-usb2.c:ma35_usb_phy_probe() {
...
provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
...
}
Should the driver changes be included in this patch or submitted together as
a series to avoid breaking USB initialization at boot time for compliant device
trees?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625023958.569299-1-a0987203069@gmail.com?part=2
^ permalink raw reply
* Re: [PATCH v2 3/4] arm64: dts: nuvoton: ma35d1: add USB controllers and dual-port PHY node
From: sashiko-bot @ 2026-06-25 2:56 UTC (permalink / raw)
To: Joey Lu
Cc: linux-phy, conor+dt, olteanv, robh, vkoul, devicetree,
neil.armstrong
In-Reply-To: <20260625023958.569299-4-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The PHY driver fails to probe unconditionally because the new device tree node lacks required properties.
- [High] The PHY driver does not support multi-PHY indexing, causing the second USB port to remain uninitialized.
- [Low] The `sys` node lacks a `ranges` property, breaking standard device tree address translation for its children.
--
commit 9dc588096b739f5b70f171c1eb14764b230dfb57
Author: Joey Lu <a0987203069@gmail.com>
arm64: dts: nuvoton: ma35d1: add USB controllers and dual-port PHY node
This commit adds device tree nodes for the MA35D1 USB subsystem, including
the simple-mfd sys node, the usb-phy child node, and the DWC2, EHCI0/1,
and OHCI0/1 controllers. It also enables them and sets up pinctrl in the
board files.
> diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
> index e51b98f5bdce4..a6a354f283117 100644
> --- a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
> +++ b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
> @@ -83,9 +83,18 @@ soc {
> ranges;
>
> sys: system-management@40460000 {
> - compatible = "nuvoton,ma35d1-reset", "syscon";
> + compatible = "nuvoton,ma35d1-reset", "syscon", "simple-mfd";
> reg = <0x0 0x40460000 0x0 0x200>;
> #reset-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <1>;
[Severity: Low]
Since this sys node is acting as a bus for usb_phy and now defines
#address-cells and #size-cells, does it also need a "ranges;" property?
Standard device tree specification requires a ranges property in the
parent to map the child's address space. Omitting it here breaks standard
device tree address translation and can trigger dtbs_check warnings.
> +
> + usb_phy: usb-phy@60 {
> + compatible = "nuvoton,ma35d1-usb2-phy";
> + reg = <0x60 0x14>;
> + #phy-cells = <1>;
> + status = "disabled";
> + };
[Severity: High]
Will this PHY node fail to probe since it lacks the "nuvoton,sys" and
"clocks" properties?
Looking at ma35_usb_phy_probe() in drivers/phy/nuvoton/phy-ma35d1-usb2.c,
it unconditionally requests both of these:
p_phy->sysreg = syscon_regmap_lookup_by_phandle(pdev->dev.of_node,
"nuvoton,sys");
if (IS_ERR(p_phy->sysreg))
return dev_err_probe(&pdev->dev, PTR_ERR(p_phy->sysreg),
"Failed to get SYS registers\n");
Because they are omitted from this node, won't the lookup return -ENODEV
and cause all dependent USB controllers (DWC2, EHCI0/1, OHCI0/1) to defer
indefinitely?
> };
>
> clk: clock-controller@40460200 {
[ ... ]
> + ehci1: usb@401c0000 {
> + compatible = "generic-ehci";
> + reg = <0x0 0x401c0000 0x0 0x1000>;
> + interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&clk HUSBH1_GATE>;
> + phys = <&usb_phy 1>;
[Severity: High]
Does the current driver actually support indexing the PHY like this?
The device tree maps controllers to <&usb_phy 0> and <&usb_phy 1>, but
looking at ma35_usb_phy_probe(), the driver registers with a simple xlate
that ignores the index:
provider = devm_of_phy_provider_register(&pdev->dev,
of_phy_simple_xlate);
Since of_phy_simple_xlate returns the first PHY object for all requests,
and the power routines like ma35_usb_phy_power_on() are hardcoded to only
manipulate PHY0 bits:
regmap_update_bits(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, 0x7,
(PHY0POR | PHY0SUSPEND));
Will the hardware for PHY1 (the dedicated host port) remain completely
unpowered and fail to initialize when ehci1 and ohci1 attempt to use it?
> + phy-names = "usb";
> + companion = <&ohci1>;
> + status = "disabled";
> + };
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625023958.569299-1-a0987203069@gmail.com?part=3
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: reset: nuvoton,ma35d1-reset: add simple-mfd and child node support
From: sashiko-bot @ 2026-06-25 2:55 UTC (permalink / raw)
To: Joey Lu
Cc: conor+dt, devicetree, linux-phy, vkoul, robh, neil.armstrong,
olteanv
In-Reply-To: <20260625023958.569299-2-a0987203069@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The child node pattern forces a unit address and `reg` property, but the intended child device's binding strictly prohibits `reg`, creating a validation Catch-22.
--
commit 64487b3a088a3cb8b25dc58df4266bfb284945b3
Author: Joey Lu <a0987203069@gmail.com>
dt-bindings: reset: nuvoton,ma35d1-reset: add simple-mfd and child node support
This commit updates the MA35D1 reset binding to allow simple-mfd and child
nodes. It adds #address-cells, #size-cells, and a pattern property to support
instantiating children like the USB PHY.
> diff --git a/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
> index 3ce7dcecd87ae..1fda7e8f4b5d1 100644
> --- a/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
> +++ b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
[ ... ]
> @@ -26,6 +28,16 @@ properties:
> '#reset-cells':
> const: 1
>
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 1
> +
> +patternProperties:
> + "^.*@[0-9a-f]+$":
> + type: object
[Severity: Medium]
This pattern property forces child nodes to have a unit address, which
inherently requires a reg property to avoid a dtc warning ("node has a unit
name, but no reg or ranges property").
However, looking at the child PHY binding
(Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml), it
strictly prohibits reg via additionalProperties: false.
If we provide the reg property required by the parent's unit address, it will
fail the PHY schema validation.
Additionally, the PHY driver doesn't seem to act as a true MFD child. Looking
at drivers/phy/nuvoton/phy-ma35d1-usb2.c:ma35_usb_phy_probe():
p_phy->sysreg = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "nuvoton,sys");
The driver hardcodes its offset and uses a phandle instead of expecting a reg
property.
Could this create a validation failure for the child PHY node, and are the
bindings and the driver structurally out of sync here?
> +
> required:
> - compatible
> - reg
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260625023958.569299-1-a0987203069@gmail.com?part=1
^ permalink raw reply
* [PATCH v2 4/4] phy: nuvoton: phy-ma35d1-usb2: extend to dual-port with OTG support
From: Joey Lu @ 2026-06-25 2:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Catalin Marinas, Jacky Huang, Shan-Chun Hung, Hui-Ping Chen,
Joey Lu, linux-phy, devicetree, linux-arm-kernel, linux-kernel,
Joey Lu
In-Reply-To: <20260625023958.569299-1-a0987203069@gmail.com>
The existing driver handled only PHY0 in device mode (DWC2 gadget).
Extend it to manage both PHY ports and integrate OTG support, per
reviewer suggestion to reuse the existing driver rather than add a
separate one.
The MA35D1 SoC has two USB PHY ports:
- PHY0 (USB0): OTG port shared between the DWC2 gadget controller
and EHCI0/OHCI0 host controllers. A hardware mux in the SoC
automatically routes the USB0 signals to the appropriate
controller based on the USB ID pin state.
- PHY1 (USB1): dedicated host-only port for EHCI1/OHCI1.
Key changes:
Dual-port support
A loop in probe() creates two struct phy objects, one per port,
each with its own phy_set_drvdata() context. A custom xlate
function selects the correct phy by the single #phy-cells argument.
Unified .init callback
A single ma35_usb_phy_init() handles both ports using parametric
register macros (USBPMISCR_PHY_*(n)). If the SUSPEND bit is
already set the init is skipped entirely, preventing the shared
PHY0 from being reset while a live link is active. On cold boot,
PHY0 polls for either host-mode clocks (HSTCKSTB + CK12MSTB) or
device-mode clock (DEVCKSTB) since the hardware selects the role
automatically; PHY1 polls for host-mode clocks only.
Clock management removed
.power_on/.power_off and all struct clk handling are removed.
Each USB controller (DWC2, EHCI, OHCI) already gates its own
clock directly through its DTS clocks binding. Having the PHY
driver redundantly enable the same gates added unnecessary
coupling without benefit.
OTG role switch for PHY0
A read-only USB role switch is registered, reporting the current
OTG role by reading the USB ID pin state from PWRONOTP[16].
.set returns -EOPNOTSUPP since the hardware mux is fully
automatic. allow_userspace_control is kept true to preserve the
sysfs attribute for observation; writes are rejected by .set.
syscon regmap via parent
The driver obtains the regmap by calling
syscon_node_to_regmap(pdev->dev.parent->of_node), removing the
need for the nuvoton,sys phandle.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
drivers/phy/nuvoton/phy-ma35d1-usb2.c | 267 ++++++++++++++++++--------
1 file changed, 192 insertions(+), 75 deletions(-)
diff --git a/drivers/phy/nuvoton/phy-ma35d1-usb2.c b/drivers/phy/nuvoton/phy-ma35d1-usb2.c
index 9a459b700ed4..19242b10cee3 100644
--- a/drivers/phy/nuvoton/phy-ma35d1-usb2.c
+++ b/drivers/phy/nuvoton/phy-ma35d1-usb2.c
@@ -1,11 +1,15 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Copyright (C) 2024 Nuvoton Technology Corp.
+ * Nuvoton MA35D1 USB 2.0 PHY driver
+ *
+ * Supports PHY0 (USB0 OTG port, shared between DWC2 gadget and EHCI0/OHCI0)
+ * and PHY1 (USB1 host-only port, used by EHCI1/OHCI1). The hardware mux on
+ * PHY0 switches automatically via the USB ID pin.
+ *
+ * Copyright (C) 2026 Nuvoton Technology Corp.
*/
#include <linux/bitfield.h>
-#include <linux/clk.h>
#include <linux/delay.h>
-#include <linux/io.h>
#include <linux/kernel.h>
#include <linux/mfd/syscon.h>
#include <linux/module.h>
@@ -13,131 +17,244 @@
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
#include <linux/regmap.h>
+#include <linux/usb/role.h>
-/* USB PHY Miscellaneous Control Register */
-#define MA35_SYS_REG_USBPMISCR 0x60
-#define PHY0POR BIT(0) /* PHY Power-On Reset Control Bit */
-#define PHY0SUSPEND BIT(1) /* PHY Suspend; 0: suspend, 1: operaion */
-#define PHY0COMN BIT(2) /* PHY Common Block Power-Down Control */
-#define PHY0DEVCKSTB BIT(10) /* PHY 60 MHz UTMI clock stable bit */
+#define MA35_SYS_PWRONOTP 0x04
+#define PWRONOTP_USBP0ID BIT(16) /* USB0 ID pin state */
+
+#define MA35_SYS_USBPMISCR 0x60
+#define USBPMISCR_PHY_POR(n) BIT(0 + (n) * 16)
+#define USBPMISCR_PHY_SUSPEND(n) BIT(1 + (n) * 16)
+#define USBPMISCR_PHY_COMN(n) BIT(2 + (n) * 16)
+#define USBPMISCR_PHY_HSTCKSTB(n) BIT(8 + (n) * 16)
+#define USBPMISCR_PHY_CK12MSTB(n) BIT(9 + (n) * 16)
+#define USBPMISCR_PHY_DEVCKSTB(n) BIT(10 + (n) * 16)
+/* Mask for control bits (POR, SUSPEND, COMN) of one PHY */
+#define USBPMISCR_PHY_CTL_MASK(n) (0x7u << ((n) * 16))
+/* Host-mode ready: SUSPEND set */
+#define USBPMISCR_PHY_HOST_READY(n) (USBPMISCR_PHY_SUSPEND(n) | \
+ USBPMISCR_PHY_HSTCKSTB(n) | \
+ USBPMISCR_PHY_CK12MSTB(n))
+/* Device-mode ready: SUSPEND set */
+#define USBPMISCR_PHY_DEV_READY(n) (USBPMISCR_PHY_SUSPEND(n) | \
+ USBPMISCR_PHY_DEVCKSTB(n))
+/* RCALCODE: 4-bit resistor trim at bits [15:12] (PHY0) or [31:28] (PHY1) */
+#define USBPMISCR_RCAL_SHIFT(n) (12 + (n) * 16)
+#define USBPMISCR_RCAL_MASK(n) GENMASK(USBPMISCR_RCAL_SHIFT(n) + 3, \
+ USBPMISCR_RCAL_SHIFT(n))
+
+#define MA35_SYS_MISCFCR0 0x70
+/* Bit 12: USB host over-current detect polarity (shared, both ports) */
+#define MISCFCR0_UHOVRCURH BIT(12)
+
+#define MA35_PHY_NUM 2
+
+struct ma35_phy_port {
+ struct phy *phy;
+ unsigned int idx;
+};
struct ma35_usb_phy {
- struct clk *clk;
struct device *dev;
struct regmap *sysreg;
+ struct ma35_phy_port port[MA35_PHY_NUM];
+ struct usb_role_switch *role_sw;
};
-static int ma35_usb_phy_power_on(struct phy *phy)
+static int ma35_usb_phy_init(struct phy *phy)
{
- struct ma35_usb_phy *p_phy = phy_get_drvdata(phy);
+ struct ma35_phy_port *port = phy_get_drvdata(phy);
+ struct ma35_usb_phy *p = container_of(port - port->idx,
+ struct ma35_usb_phy, port[0]);
+ unsigned int n = port->idx;
unsigned int val;
int ret;
- ret = clk_prepare_enable(p_phy->clk);
- if (ret < 0) {
- dev_err(p_phy->dev, "Failed to enable PHY clock: %d\n", ret);
- return ret;
- }
+ regmap_read(p->sysreg, MA35_SYS_USBPMISCR, &val);
- regmap_read(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, &val);
- if (val & PHY0SUSPEND) {
- /*
- * USB PHY0 is in operation mode already
- * make sure USB PHY 60 MHz UTMI Interface Clock ready
- */
- ret = regmap_read_poll_timeout(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, val,
- val & PHY0DEVCKSTB, 10, 1000);
- if (ret == 0)
- return 0;
- }
+ if (val & USBPMISCR_PHY_SUSPEND(n))
+ return 0;
- /*
- * reset USB PHY0.
- * wait until USB PHY0 60 MHz UTMI Interface Clock ready
- */
- regmap_update_bits(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, 0x7, (PHY0POR | PHY0SUSPEND));
+ regmap_update_bits(p->sysreg, MA35_SYS_USBPMISCR,
+ USBPMISCR_PHY_CTL_MASK(n),
+ USBPMISCR_PHY_POR(n) | USBPMISCR_PHY_SUSPEND(n));
udelay(20);
- /* make USB PHY0 enter operation mode */
- regmap_update_bits(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, 0x7, PHY0SUSPEND);
+ regmap_update_bits(p->sysreg, MA35_SYS_USBPMISCR,
+ USBPMISCR_PHY_CTL_MASK(n),
+ USBPMISCR_PHY_SUSPEND(n));
+
+ if (n == 0) {
+ ret = regmap_read_poll_timeout(p->sysreg, MA35_SYS_USBPMISCR,
+ val,
+ ((val & USBPMISCR_PHY_HOST_READY(0)) ==
+ USBPMISCR_PHY_HOST_READY(0)) ||
+ ((val & USBPMISCR_PHY_DEV_READY(0)) ==
+ USBPMISCR_PHY_DEV_READY(0)),
+ 10, 1000);
+ } else {
+ ret = regmap_read_poll_timeout(p->sysreg, MA35_SYS_USBPMISCR,
+ val,
+ (val & USBPMISCR_PHY_HOST_READY(n)) ==
+ USBPMISCR_PHY_HOST_READY(n),
+ 10, 1000);
+ }
- /* make sure USB PHY 60 MHz UTMI Interface Clock ready */
- ret = regmap_read_poll_timeout(p_phy->sysreg, MA35_SYS_REG_USBPMISCR, val,
- val & PHY0DEVCKSTB, 10, 1000);
- if (ret == -ETIMEDOUT) {
- dev_err(p_phy->dev, "Check PHY clock, Timeout: %d\n", ret);
- clk_disable_unprepare(p_phy->clk);
+ if (ret) {
+ dev_err(p->dev, "USB PHY%u clock not stable (USBPMISCR=0x%08x)\n",
+ n, val);
return ret;
}
return 0;
}
-static int ma35_usb_phy_power_off(struct phy *phy)
+static const struct phy_ops ma35_usb_phy_ops = {
+ .init = ma35_usb_phy_init,
+ .owner = THIS_MODULE,
+};
+
+static int ma35_role_sw_set(struct usb_role_switch *sw, enum usb_role role)
+{
+ return -EOPNOTSUPP;
+}
+
+static enum usb_role ma35_role_sw_get(struct usb_role_switch *sw)
+{
+ struct ma35_usb_phy *p = usb_role_switch_get_drvdata(sw);
+ u32 val;
+
+ regmap_read(p->sysreg, MA35_SYS_PWRONOTP, &val);
+
+ return (val & PWRONOTP_USBP0ID) ? USB_ROLE_HOST : USB_ROLE_DEVICE;
+}
+
+static int ma35_role_switch_init(struct platform_device *pdev,
+ struct ma35_usb_phy *p)
{
- struct ma35_usb_phy *p_phy = phy_get_drvdata(phy);
+ struct usb_role_switch_desc sw_desc = {0};
+
+ sw_desc.set = ma35_role_sw_set;
+ sw_desc.get = ma35_role_sw_get;
+ sw_desc.allow_userspace_control = true;
+ sw_desc.driver_data = p;
+ sw_desc.fwnode = dev_fwnode(&pdev->dev);
+
+ p->role_sw = usb_role_switch_register(&pdev->dev, &sw_desc);
+ if (IS_ERR(p->role_sw))
+ return dev_err_probe(&pdev->dev, PTR_ERR(p->role_sw),
+ "failed to register role switch\n");
- clk_disable_unprepare(p_phy->clk);
return 0;
}
-static const struct phy_ops ma35_usb_phy_ops = {
- .power_on = ma35_usb_phy_power_on,
- .power_off = ma35_usb_phy_power_off,
- .owner = THIS_MODULE,
-};
+static void ma35_role_switch_exit(struct ma35_usb_phy *p)
+{
+ if (p->role_sw) {
+ usb_role_switch_unregister(p->role_sw);
+ p->role_sw = NULL;
+ }
+}
+
+static struct phy *ma35_usb_phy_xlate(struct device *dev,
+ const struct of_phandle_args *args)
+{
+ struct ma35_usb_phy *p = dev_get_drvdata(dev);
+
+ if (args->args[0] >= MA35_PHY_NUM)
+ return ERR_PTR(-EINVAL);
+
+ return p->port[args->args[0]].phy;
+}
static int ma35_usb_phy_probe(struct platform_device *pdev)
{
struct phy_provider *provider;
- struct ma35_usb_phy *p_phy;
- struct phy *phy;
+ struct ma35_usb_phy *p;
+ int n, ret;
+ u32 code;
- p_phy = devm_kzalloc(&pdev->dev, sizeof(*p_phy), GFP_KERNEL);
- if (!p_phy)
+ p = devm_kzalloc(&pdev->dev, sizeof(*p), GFP_KERNEL);
+ if (!p)
return -ENOMEM;
- p_phy->dev = &pdev->dev;
- platform_set_drvdata(pdev, p_phy);
+ p->dev = &pdev->dev;
+ platform_set_drvdata(pdev, p);
+
+ p->sysreg = syscon_node_to_regmap(pdev->dev.parent->of_node);
+ if (IS_ERR(p->sysreg))
+ return dev_err_probe(&pdev->dev, PTR_ERR(p->sysreg),
+ "failed to get parent SYS regmap\n");
+
+ for (n = 0; n < MA35_PHY_NUM; n++) {
+ if (of_property_read_u32_index(pdev->dev.of_node,
+ "nuvoton,rcalcode", n, &code))
+ continue;
- p_phy->sysreg = syscon_regmap_lookup_by_phandle(pdev->dev.of_node, "nuvoton,sys");
- if (IS_ERR(p_phy->sysreg))
- return dev_err_probe(&pdev->dev, PTR_ERR(p_phy->sysreg),
- "Failed to get SYS registers\n");
+ if (code > 15)
+ return dev_err_probe(&pdev->dev, -EINVAL,
+ "rcalcode[%d] %u out of range (0-15)\n",
+ n, code);
- p_phy->clk = of_clk_get(pdev->dev.of_node, 0);
- if (IS_ERR(p_phy->clk))
- return dev_err_probe(&pdev->dev, PTR_ERR(p_phy->clk),
- "failed to find usb_phy clock\n");
+ regmap_update_bits(p->sysreg, MA35_SYS_USBPMISCR,
+ USBPMISCR_RCAL_MASK(n),
+ code << USBPMISCR_RCAL_SHIFT(n));
+ }
+
+ if (of_property_read_bool(pdev->dev.of_node, "nuvoton,oc-active-high"))
+ regmap_update_bits(p->sysreg, MA35_SYS_MISCFCR0,
+ MISCFCR0_UHOVRCURH, MISCFCR0_UHOVRCURH);
+
+ for (n = 0; n < MA35_PHY_NUM; n++) {
+ p->port[n].idx = n;
- phy = devm_phy_create(&pdev->dev, NULL, &ma35_usb_phy_ops);
- if (IS_ERR(phy))
- return dev_err_probe(&pdev->dev, PTR_ERR(phy), "Failed to create PHY\n");
+ p->port[n].phy = devm_phy_create(&pdev->dev, pdev->dev.of_node,
+ &ma35_usb_phy_ops);
+ if (IS_ERR(p->port[n].phy))
+ return dev_err_probe(&pdev->dev, PTR_ERR(p->port[n].phy),
+ "failed to create PHY%d\n", n);
- phy_set_drvdata(phy, p_phy);
+ phy_set_drvdata(p->port[n].phy, &p->port[n]);
+ }
+
+ ret = ma35_role_switch_init(pdev, p);
+ if (ret)
+ return ret;
- provider = devm_of_phy_provider_register(&pdev->dev, of_phy_simple_xlate);
- if (IS_ERR(provider))
+ provider = devm_of_phy_provider_register(&pdev->dev, ma35_usb_phy_xlate);
+ if (IS_ERR(provider)) {
+ ma35_role_switch_exit(p);
return dev_err_probe(&pdev->dev, PTR_ERR(provider),
- "Failed to register PHY provider\n");
+ "failed to register PHY provider\n");
+ }
+
return 0;
}
+static void ma35_usb_phy_remove(struct platform_device *pdev)
+{
+ struct ma35_usb_phy *p = platform_get_drvdata(pdev);
+
+ ma35_role_switch_exit(p);
+}
+
static const struct of_device_id ma35_usb_phy_of_match[] = {
- { .compatible = "nuvoton,ma35d1-usb2-phy", },
- { },
+ { .compatible = "nuvoton,ma35d1-usb2-phy" },
+ { /* sentinel */ }
};
MODULE_DEVICE_TABLE(of, ma35_usb_phy_of_match);
static struct platform_driver ma35_usb_phy_driver = {
.probe = ma35_usb_phy_probe,
- .driver = {
- .name = "ma35d1-usb2-phy",
- .of_match_table = ma35_usb_phy_of_match,
+ .remove = ma35_usb_phy_remove,
+ .driver = {
+ .name = "ma35d1-usb2-phy",
+ .of_match_table = ma35_usb_phy_of_match,
},
};
module_platform_driver(ma35_usb_phy_driver);
MODULE_DESCRIPTION("Nuvoton ma35d1 USB2.0 PHY driver");
MODULE_AUTHOR("Hui-Ping Chen <hpchen0nvt@gmail.com>");
+MODULE_AUTHOR("Joey Lu <a0987203069@gmail.com>");
MODULE_LICENSE("GPL");
--
2.43.0
^ permalink raw reply related
* [PATCH v2 3/4] arm64: dts: nuvoton: ma35d1: add USB controllers and dual-port PHY node
From: Joey Lu @ 2026-06-25 2:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Catalin Marinas, Jacky Huang, Shan-Chun Hung, Hui-Ping Chen,
Joey Lu, linux-phy, devicetree, linux-arm-kernel, linux-kernel,
Joey Lu
In-Reply-To: <20260625023958.569299-1-a0987203069@gmail.com>
Add device tree nodes for the MA35D1 USB subsystem:
- sys node gains simple-mfd + address/size-cells so it can contain
the usb-phy@60 child.
- usb-phy@60 is added as a child of sys, using the combined
nuvoton,ma35d1-usb2-phy driver with #phy-cells = <1>. No clock
properties: clock gating is handled by each controller node.
- DWC2 gadget (usb@40200000), EHCI0/1, and OHCI0/1 nodes are
added. Each controller names its clock gate directly and
references the PHY by index (0 for the OTG port, 1 for the
dedicated host port).
- Board files (ma35d1-som-256m.dts, ma35d1-iot-512m.dts) enable the
PHY, dwc2, ehci0/1, and ohci0/1 nodes and add pinctrl for the
HSUSB signals (VBUSVLD, PWREN, OVC).
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
.../boot/dts/nuvoton/ma35d1-iot-512m.dts | 36 ++++++++++
.../boot/dts/nuvoton/ma35d1-som-256m.dts | 36 ++++++++++
arch/arm64/boot/dts/nuvoton/ma35d1.dtsi | 68 ++++++++++++++++++-
3 files changed, 139 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts b/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts
index 9482bec1aa57..32fea36da7f4 100644
--- a/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts
+++ b/arch/arm64/boot/dts/nuvoton/ma35d1-iot-512m.dts
@@ -95,6 +95,16 @@ pinctrl_uart14: uart14-pins {
power-source = <1>;
};
};
+
+ hsusb {
+ pinctrl_hsusb: hsusb-pins {
+ nuvoton,pins = <5 15 1>, /* VBUSVLD */
+ <11 12 9>, /* PWREN */
+ <11 13 9>; /* OVC */
+ bias-disable;
+ power-source = <1>;
+ };
+ };
};
&uart0 {
@@ -126,3 +136,29 @@ &uart14 {
pinctrl-0 = <&pinctrl_uart14>;
status = "okay";
};
+
+&usb_phy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hsusb>;
+ status = "okay";
+};
+
+&usb {
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts b/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
index f6f20a17e501..85d1c5db8bd9 100644
--- a/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
+++ b/arch/arm64/boot/dts/nuvoton/ma35d1-som-256m.dts
@@ -98,6 +98,16 @@ pinctrl_uart16: uart16-pins {
power-source = <1>;
};
};
+
+ hsusb {
+ pinctrl_hsusb: hsusb-pins {
+ nuvoton,pins = <5 15 1>, /* VBUSVLD */
+ <11 12 9>, /* PWREN */
+ <11 13 9>; /* OVC */
+ bias-disable;
+ power-source = <1>;
+ };
+ };
};
&uart0 {
@@ -129,3 +139,29 @@ &uart16 {
pinctrl-0 = <&pinctrl_uart16>;
status = "okay";
};
+
+&usb_phy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_hsusb>;
+ status = "okay";
+};
+
+&usb {
+ status = "okay";
+};
+
+&ehci0 {
+ status = "okay";
+};
+
+&ehci1 {
+ status = "okay";
+};
+
+&ohci0 {
+ status = "okay";
+};
+
+&ohci1 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
index e51b98f5bdce..a6a354f28311 100644
--- a/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
+++ b/arch/arm64/boot/dts/nuvoton/ma35d1.dtsi
@@ -83,9 +83,18 @@ soc {
ranges;
sys: system-management@40460000 {
- compatible = "nuvoton,ma35d1-reset", "syscon";
+ compatible = "nuvoton,ma35d1-reset", "syscon", "simple-mfd";
reg = <0x0 0x40460000 0x0 0x200>;
#reset-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ usb_phy: usb-phy@60 {
+ compatible = "nuvoton,ma35d1-usb2-phy";
+ reg = <0x60 0x14>;
+ #phy-cells = <1>;
+ status = "disabled";
+ };
};
clk: clock-controller@40460200 {
@@ -379,5 +388,62 @@ uart16: serial@40880000 {
clocks = <&clk UART16_GATE>;
status = "disabled";
};
+
+ usb: usb@40200000 {
+ compatible = "snps,dwc2";
+ reg = <0x0 0x40200000 0x0 0x1000>;
+ interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk USBD_GATE>;
+ clock-names = "otg";
+ phys = <&usb_phy 0>;
+ phy-names = "usb2-phy";
+ dr_mode = "peripheral";
+ g-np-tx-fifo-size = <16>;
+ g-rx-fifo-size = <0x100>;
+ g-tx-fifo-size = <256 256 64 64 64 32 32 32>;
+ status = "disabled";
+ };
+
+ ehci0: usb@40140000 {
+ compatible = "generic-ehci";
+ reg = <0x0 0x40140000 0x0 0x1000>;
+ interrupts = <GIC_SPI 33 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk HUSBH0_GATE>;
+ phys = <&usb_phy 0>;
+ phy-names = "usb";
+ companion = <&ohci0>;
+ status = "disabled";
+ };
+
+ ehci1: usb@401c0000 {
+ compatible = "generic-ehci";
+ reg = <0x0 0x401c0000 0x0 0x1000>;
+ interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk HUSBH1_GATE>;
+ phys = <&usb_phy 1>;
+ phy-names = "usb";
+ companion = <&ohci1>;
+ status = "disabled";
+ };
+
+ ohci0: usb@40150000 {
+ compatible = "generic-ohci";
+ reg = <0x0 0x40150000 0x0 0x1000>;
+ interrupts = <GIC_SPI 35 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk HUSBH0_GATE>;
+ phys = <&usb_phy 0>;
+ phy-names = "usb";
+ status = "disabled";
+ };
+
+ ohci1: usb@401d0000 {
+ compatible = "generic-ohci";
+ reg = <0x0 0x401d0000 0x0 0x1000>;
+ interrupts = <GIC_SPI 36 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&clk HUSBH1_GATE>;
+ phys = <&usb_phy 1>;
+ phy-names = "usb";
+ status = "disabled";
+ };
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/4] dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG support
From: Joey Lu @ 2026-06-25 2:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Catalin Marinas, Jacky Huang, Shan-Chun Hung, Hui-Ping Chen,
Joey Lu, linux-phy, devicetree, linux-arm-kernel, linux-kernel,
Joey Lu
In-Reply-To: <20260625023958.569299-1-a0987203069@gmail.com>
The MA35D1 has two USB PHY ports managed by the same hardware block:
- PHY0 (index 0): OTG port shared between the DWC2 gadget controller
and EHCI0/OHCI0 host controllers. A hardware mux follows the USB
ID pin automatically.
- PHY1 (index 1): dedicated host-only port for EHCI1/OHCI1.
Extend the existing binding to cover both ports:
- The PHY node is now a child of the system-management syscon node
with a reg property. The nuvoton,sys phandle and clocks properties
are removed; the driver derives the regmap from its parent, and
clock gating is owned by each individual USB controller.
- #phy-cells changes from 0 to 1: the cell selects the PHY port.
- Two optional board-tuning properties are added: nuvoton,rcalcode
for per-port resistor trim and nuvoton,oc-active-high for
over-current polarity.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
.../bindings/phy/nuvoton,ma35d1-usb2-phy.yaml | 62 ++++++++++++++-----
1 file changed, 48 insertions(+), 14 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
index fff858c909a0..a20d03c80932 100644
--- a/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/nuvoton,ma35d1-usb2-phy.yaml
@@ -8,38 +8,72 @@ title: Nuvoton MA35D1 USB2 phy
maintainers:
- Hui-Ping Chen <hpchen0nvt@gmail.com>
+ - Joey Lu <yclu4@nuvoton.com>
+
+description:
+ USB 2.0 PHY for the Nuvoton MA35D1 SoC. The PHY node is a child of the
+ system-management syscon node and covers both PHY ports.
+
+ PHY0 (index 0) is the OTG port whose signals are routed to either the DWC2
+ gadget controller or the EHCI0/OHCI0 host controller by a hardware mux that
+ follows the USB ID pin automatically.
+
+ PHY1 (index 1) is a dedicated host-only port used by EHCI1/OHCI1.
properties:
compatible:
enum:
- nuvoton,ma35d1-usb2-phy
+ reg:
+ maxItems: 1
+
"#phy-cells":
- const: 0
+ const: 1
+ description:
+ The single cell selects the PHY port. 0 selects the OTG port (USB0,
+ shared with DWC2 gadget controller) and 1 selects the host-only port
+ (USB1).
- clocks:
- maxItems: 1
+ nuvoton,rcalcode:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
+ minItems: 1
+ maxItems: 2
+ items:
+ minimum: 0
+ maximum: 15
+ description:
+ Resistor calibration trim codes for PHY0 and PHY1 respectively.
+ Each 4-bit value is written to the RCALCODE field in USBPMISCR and
+ adjusts the PHY's internal termination resistance. Both entries are
+ optional; when absent the hardware reset default is used.
- nuvoton,sys:
- $ref: /schemas/types.yaml#/definitions/phandle
+ nuvoton,oc-active-high:
+ type: boolean
description:
- phandle to syscon for checking the PHY clock status.
+ When present, the over-current detect input from the VBUS power switch
+ is treated as active-high. The default (property absent) is active-low.
+ This setting is shared by both USB host ports.
required:
- compatible
+ - reg
- "#phy-cells"
- - clocks
- - nuvoton,sys
additionalProperties: false
examples:
- |
- #include <dt-bindings/clock/nuvoton,ma35d1-clk.h>
+ system-management@40460000 {
+ compatible = "nuvoton,ma35d1-reset", "syscon", "simple-mfd";
+ reg = <0x40460000 0x200>;
+ #reset-cells = <1>;
+ #address-cells = <1>;
+ #size-cells = <1>;
- usb_phy: usb-phy {
- compatible = "nuvoton,ma35d1-usb2-phy";
- clocks = <&clk USBD_GATE>;
- nuvoton,sys = <&sys>;
- #phy-cells = <0>;
+ usb-phy@60 {
+ compatible = "nuvoton,ma35d1-usb2-phy";
+ reg = <0x60 0x14>;
+ #phy-cells = <1>;
+ };
};
--
2.43.0
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: reset: nuvoton,ma35d1-reset: add simple-mfd and child node support
From: Joey Lu @ 2026-06-25 2:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Catalin Marinas, Jacky Huang, Shan-Chun Hung, Hui-Ping Chen,
Joey Lu, linux-phy, devicetree, linux-arm-kernel, linux-kernel,
Joey Lu
In-Reply-To: <20260625023958.569299-1-a0987203069@gmail.com>
The MA35D1 system-management syscon node hosts the USB PHY register
block at offset 0x60. To model usb-phy@60 as a DT child of the syscon
node the binding must allow:
- simple-mfd as an optional third compatible so the MFD core can
instantiate child platform devices.
- #address-cells and #size-cells (each const: 1) so child nodes can
carry a reg property.
- An open child-node pattern (patternProperties "^.*@[0-9a-f]+$")
to pass dt-schema validation.
Signed-off-by: Joey Lu <a0987203069@gmail.com>
---
.../bindings/reset/nuvoton,ma35d1-reset.yaml | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
index 3ce7dcecd87a..1fda7e8f4b5d 100644
--- a/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
+++ b/Documentation/devicetree/bindings/reset/nuvoton,ma35d1-reset.yaml
@@ -19,6 +19,8 @@ properties:
items:
- const: nuvoton,ma35d1-reset
- const: syscon
+ - const: simple-mfd
+ minItems: 2
reg:
maxItems: 1
@@ -26,6 +28,16 @@ properties:
'#reset-cells':
const: 1
+ '#address-cells':
+ const: 1
+
+ '#size-cells':
+ const: 1
+
+patternProperties:
+ "^.*@[0-9a-f]+$":
+ type: object
+
required:
- compatible
- reg
@@ -43,4 +55,3 @@ examples:
#reset-cells = <1>;
};
...
-
--
2.43.0
^ permalink raw reply related
* [PATCH v2 0/4] phy: nuvoton: extend MA35D1 USB2 PHY driver for dual-port OTG support
From: Joey Lu @ 2026-06-25 2:39 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Catalin Marinas, Jacky Huang, Shan-Chun Hung, Hui-Ping Chen,
Joey Lu, linux-phy, devicetree, linux-arm-kernel, linux-kernel,
Joey Lu
The MA35D1 SoC has two USB PHY ports managed by a shared hardware block:
- PHY0 (USB0): OTG port shared between the DWC2 gadget controller and
the EHCI0/OHCI0 host controllers. A hardware mux automatically routes
USB0 signals to the correct controller based on the USB ID pin.
- PHY1 (USB1): dedicated host-only port for EHCI1/OHCI1.
A previous series [1] added a separate phy-ma35d1-otg.c driver for this.
Following reviewer suggestion to reuse the existing phy-ma35d1-usb2.c
driver rather than introduce a new one, that series has been dropped and
this series instead extends the existing driver.
Changes in this series:
Patch 1 (new) adds simple-mfd support to the nuvoton,ma35d1-reset
syscon binding. The sys node needs to act as an MFD parent so that
usb-phy@60 can be its DT child. This patch is a prerequisite for
patch 2 and has no functional impact on existing users of the syscon.
Patch 2 updates the nuvoton,ma35d1-usb2-phy binding: the PHY node
becomes a child of the syscon node (reg = <0x60 0x14>), nuvoton,sys
phandle and clocks are removed, and #phy-cells changes from 0 to 1
for per-port selection. Optional nuvoton,rcalcode and
nuvoton,oc-active-high properties are added.
Patch 3 updates the MA35D1 DTS: sys gains simple-mfd, usb-phy@60 is
added as a syscon child, and DWC2/EHCI0/EHCI1/OHCI0/OHCI1 nodes are
added. Board files enable the nodes and add pinctrl for the HSUSB
signals (VBUSVLD, PWREN, OVC).
Patch 4 extends phy-ma35d1-usb2.c: a loop creates two struct phy
objects; a unified .init handles both ports with parametric register
macros; clock management is removed (each controller gates its own
clock); a read-only USB role switch is registered for PHY0 reporting
the USB ID pin via PWRONOTP[16].
Changes since v1:
- New patch 1: nuvoton,ma35d1-reset binding extended for simple-mfd
and child node support; required as a prerequisite for the PHY
binding which places usb-phy@60 as a syscon child.
- Patch 2 (was patch 1): nuvoton,rcalcode description updated to
clarify that both PHY entries are individually optional; example
reg corrected from 4-cell to 2-cell format.
- Patch 3 (was patch 2): ehci1 node address corrected to lowercase
(401c0000).
- Patch 4 (was patch 3): register definition section header comments
added; HOST_READY and DEV_READY macro comments made more
descriptive; ma35_role_switch_exit() added to the PHY provider
registration error path to prevent a role switch leak.
Link: [1] https://lore.kernel.org/linux-phy/20260604101220.1092822-1-a0987203069@gmail.com/T/#t
Joey Lu (4):
dt-bindings: reset: nuvoton,ma35d1-reset: add simple-mfd and child
node support
dt-bindings: phy: nuvoton,ma35d1-usb2-phy: extend for dual-port OTG
support
arm64: dts: nuvoton: ma35d1: add USB controllers and dual-port PHY
node
phy: nuvoton: phy-ma35d1-usb2: extend to dual-port with OTG support
.../bindings/phy/nuvoton,ma35d1-usb2-phy.yaml | 62 +++-
.../bindings/reset/nuvoton,ma35d1-reset.yaml | 13 +-
.../boot/dts/nuvoton/ma35d1-iot-512m.dts | 36 +++
.../boot/dts/nuvoton/ma35d1-som-256m.dts | 36 +++
arch/arm64/boot/dts/nuvoton/ma35d1.dtsi | 68 ++++-
drivers/phy/nuvoton/phy-ma35d1-usb2.c | 267 +++++++++++++-----
6 files changed, 391 insertions(+), 91 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH 1/2] regulator: dt-bindings: rtq2208: Label mtp-sel-high property as deprecated
From: sashiko-bot @ 2026-06-25 2:26 UTC (permalink / raw)
To: cy_huang; +Cc: conor+dt, devicetree, robh
In-Reply-To: <d111d67d40cc182a2ab8c6292e4ffff9c7dad9ba.1782353659.git.cy_huang@richtek.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The deprecated property `richtek,mtp-sel-high` remains in the YAML example block.
--
commit 34889eeeff15702a135fa4ac9e6b9f3ab88ee425
Author: ChiYuan Huang <cy_huang@richtek.com>
regulator: dt-bindings: rtq2208: Label mtp-sel-high property as deprecated
Since it can be identified by hardware register, label the unnecessary
property 'richtek,mtp-sel-high' as deprecated.
> diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> --- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> @@ -42,11 +42,14 @@ properties:
>
> richtek,mtp-sel-high:
> type: boolean
> + deprecated: true
> description:
> vout register selection based on this boolean value.
> false - Using DVS0 register setting to adjust vout
> true - Using DVS1 register setting to adjust vout
>
> + The property is now deprecated. Will be identified by RG HW register.
> +
> regulators:
[Severity: Low]
Since this property is now marked as deprecated, should it also be removed
from the example device tree in this binding?
Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml:examples:
...
pmic@10 {
compatible = "richtek,rtq2208";
reg = <0x10>;
interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>;
richtek,mtp-sel-high;
regulators {
...
Leaving the deprecated property in the example encourages its continued use
by developers who might copy and paste binding examples into their device
trees.
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782353659.git.cy_huang@richtek.com?part=1
^ permalink raw reply
* Re: [PATCH 1/8] clk: qcom: dispcc-sm8450: Fix mdss clocks
From: Esteban Urrutia @ 2026-06-25 2:22 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <65873506-1a9a-40ec-ac67-60f61a0b4b4c@oss.qualcomm.com>
On 6/23/26 11:50 AM, Konrad Dybcio wrote:
> This can also be fixed by migrating to use qcom_cc_driver_data,
> which takes a list of alpha PLLs to be configured, and thenthere's
> a switch-statement in clk-alpha-pll.c that always assigns the
> correct function
If this is done, should a patch that migrates to qcom_cc_driver_data and a
patch that fixes the issue be sent, or should only a single patch be sent?
Regards,
Esteban
^ permalink raw reply
* [PATCH 0/2] rtq2208: Remove the unnecessary MTP_SEL property
From: cy_huang @ 2026-06-25 2:18 UTC (permalink / raw)
To: Mark Brown, Krzysztof Kozlowski
Cc: Rob Herring, Conor Dooley, Liam Girdwood, ChiYuan Huang,
Yoon Dong Min, edward_kim, devicetree, linux-kernel
From: ChiYuan Huang <cy_huang@richtek.com>
This patch series remove the 'richtek,mtp-sel-high' property usage.
ChiYuan Huang (2):
regulator: dt-bindings: rtq2208: Label mtp-sel-high property as
deprecated
regualtor: rtq2208: Initiate the default MTP_SEL state by hardware
register
.../devicetree/bindings/regulator/richtek,rtq2208.yaml | 3 +++
drivers/regulator/rtq2208-regulator.c | 7 ++++++-
2 files changed, 9 insertions(+), 1 deletion(-)
--
2.43.0
^ permalink raw reply
* [PATCH 1/2] regulator: dt-bindings: rtq2208: Label mtp-sel-high property as deprecated
From: cy_huang @ 2026-06-25 2:18 UTC (permalink / raw)
To: Mark Brown, Krzysztof Kozlowski
Cc: Rob Herring, Conor Dooley, Liam Girdwood, ChiYuan Huang,
Yoon Dong Min, edward_kim, devicetree, linux-kernel
In-Reply-To: <cover.1782353659.git.cy_huang@richtek.com>
From: ChiYuan Huang <cy_huang@richtek.com>
Since it can be identified by hardware register, label the unnecessary
property 'richtek,mtp-sel-high' as deprecated.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
.../devicetree/bindings/regulator/richtek,rtq2208.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
index 022c1f197364..08648916e1fb 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
@@ -42,11 +42,14 @@ properties:
richtek,mtp-sel-high:
type: boolean
+ deprecated: true
description:
vout register selection based on this boolean value.
false - Using DVS0 register setting to adjust vout
true - Using DVS1 register setting to adjust vout
+ The property is now deprecated. Will be identified by RG HW register.
+
regulators:
type: object
additionalProperties: false
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] regualtor: rtq2208: Initiate the default MTP_SEL state by hardware register
From: cy_huang @ 2026-06-25 2:18 UTC (permalink / raw)
To: Mark Brown, Krzysztof Kozlowski
Cc: Rob Herring, Conor Dooley, Liam Girdwood, ChiYuan Huang,
Yoon Dong Min, edward_kim, devicetree, linux-kernel
In-Reply-To: <cover.1782353659.git.cy_huang@richtek.com>
From: ChiYuan Huang <cy_huang@richtek.com>
Read the initial MTP_SEL state by hardware register to prevent the wrong
specified property value from the conflict of hardware pin assignment.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
drivers/regulator/rtq2208-regulator.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/rtq2208-regulator.c b/drivers/regulator/rtq2208-regulator.c
index f669a562f036..7fe082def494 100644
--- a/drivers/regulator/rtq2208-regulator.c
+++ b/drivers/regulator/rtq2208-regulator.c
@@ -12,6 +12,7 @@
#include <linux/mod_devicetable.h>
/* Register */
+#define RTQ2208_REG_FSOUTB_CNTL 0x11
#define RTQ2208_REG_GLOBAL_INT1 0x12
#define RTQ2208_REG_FLT_RECORDBUCK_CB 0x18
#define RTQ2208_REG_GLOBAL_INT1_MASK 0x1D
@@ -34,6 +35,7 @@
#define RTQ2208_REG_HIDDEN1 0xFF
/* Mask */
+#define RTQ2208_MTP_SEL_RO_MASK BIT(7)
#define RTQ2208_BUCK_NR_MTP_SEL_MASK GENMASK(7, 0)
#define RTQ2208_BUCK_EN_NR_MTP_SEL0_MASK BIT(0)
#define RTQ2208_BUCK_EN_NR_MTP_SEL1_MASK BIT(1)
@@ -465,10 +467,13 @@ static int rtq2208_parse_regulator_dt_data(int n_regulator, const unsigned int *
struct rtq2208_regulator_desc *rdesc[RTQ2208_LDO_MAX], struct device *dev,
unsigned int ldo1_fixed, unsigned int ldo2_fixed)
{
+ struct regmap *regmap = dev_get_regmap(dev, NULL);
int mtp_sel, i, idx;
/* get mtp_sel0 or mtp_sel1 */
- mtp_sel = device_property_read_bool(dev, "richtek,mtp-sel-high");
+ mtp_sel = regmap_test_bits(regmap, RTQ2208_REG_FSOUTB_CNTL, RTQ2208_MTP_SEL_RO_MASK);
+ if (mtp_sel < 0)
+ return dev_err_probe(dev, mtp_sel, "Failed to init mtp_sel state\n");
for (i = 0; i < n_regulator; i++) {
idx = regulator_idx_table[i];
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 3/3] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: sashiko-bot @ 2026-06-25 2:13 UTC (permalink / raw)
To: Fenglin Wu; +Cc: linux-input, dmitry.torokhov, conor+dt, devicetree, robh
In-Reply-To: <20260624-qcom-spmi-haptics-v2-3-b9118e60f3e3@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 8 potential issue(s) to consider:
- [High] Concurrent effect uploads or erasures free `fifo_data` while it is actively used by the playback worker or IRQ handler, leading to a Use-After-Free.
- [High] System suspend races with the asynchronous playback worker, leaving the hardware active during sleep and leaking a PM runtime reference.
- [High] Incorrect teardown ordering allows userspace to trigger Use-After-Free of driver structures after removal.
- [High] The driver fails to terminate FIFO playback when finished, permanently leaking a PM runtime reference.
- [Medium] Unbounded user-controlled kmalloc size allows memory exhaustion.
- [Medium] Missing signedness check on the custom play rate allows negative values to bypass boundary checks.
- [Medium] Lockless, non-atomic accesses to `play_request` and `cur_effect_id` cause new play requests to be lost.
- [Medium] The runtime PM usage counter is leaked during device removal if playback is active.
--
commit 06679c85ddc3489b6ff4ed3aec7d938287e570cd
Author: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
input: misc: Add Qualcomm SPMI PMIC haptics driver
Add an initial driver for the Qualcomm PMIH0108 PMIC haptics module,
named as HAP530_HV. This module supports several play modes, including
DIRECT_PLAY, FIFO, PAT_MEM, and SWR, each with distinct data sourcing
and hardware data handling logic. Currently, the driver provides support
for two play modes using the input force-feedback framework: FF_CONSTANT
effect for DIRECT_PLAY mode and FF_PERIODIC effect with FF_CUSTOM
waveform for FIFO mode.
> diff --git a/drivers/input/misc/qcom-spmi-haptics.c b/drivers/input/misc/qcom-spmi-haptics.c
> new file mode 100644
> index 0000000000000..4b27638df9605
> --- /dev/null
> +++ b/drivers/input/misc/qcom-spmi-haptics.c
[ ... ]
> +static irqreturn_t haptics_fifo_empty_irq(int irq, void *dev_id)
> +{
> + struct qcom_haptics *h = dev_id;
> + u32 sts, to_write;
> + int ret;
> +
> + ret = regmap_read(h->regmap,
> + h->cfg_base + HAP_CFG_INT_RT_STS_REG, &sts);
> + if (ret || !(sts & FIFO_EMPTY_BIT))
> + return IRQ_HANDLED;
> +
> + mutex_lock(&h->fifo_lock);
> +
> + if (!h->fifo_data) {
> + mutex_unlock(&h->fifo_lock);
> + return IRQ_HANDLED;
> + }
> +
> + if (h->data_done) {
> + ptn_write(h, HAP_PTN_FIFO_EMPTY_CFG_REG, 0);
> + h->fifo_data = NULL;
> + h->play_request = false;
> + schedule_work(&h->play_work);
> + mutex_unlock(&h->fifo_lock);
> + return IRQ_HANDLED;
> + }
> +
> + /* Refill: write the next chunk, conservatively sized to the threshold */
> + to_write = min_t(u32, h->data_len - h->data_written,
> + h->fifo_len - FIFO_EMPTY_THRESH);
> + haptics_write_fifo_chunk(h, &h->fifo_data[h->data_written], to_write);
[Severity: High]
Does this code dereference a freed pointer?
A userspace process can start a FIFO effect, then concurrently call
EVIOCSFF (to re-upload) or EVIOCRMFF (to erase) the effect.
The input core calls haptics_erase() or haptics_upload_effect(), which
immediately execute kfree(priv->fifo_data).
Since the IRQ handler or worker continues to use h->fifo_data under
h->fifo_lock, it appears it will dereference the freed memory.
> + h->data_written += to_write;
> +
> + if (h->data_written >= h->data_len) {
> + /* Last chunk enqueued; disable threshold to stop further IRQs */
> + h->data_done = true;
> + ptn_write(h, HAP_PTN_FIFO_EMPTY_CFG_REG, 0);
[Severity: High]
Does this fail to terminate FIFO playback when finished?
When the final chunk is written, the code sets FIFO_EMPTY_CFG_REG to 0,
disabling the empty interrupt.
Because the interrupt is disabled, the handler will never fire again to
process the h->data_done block at the start of the function. This leaves
the hardware active indefinitely and leaks the PM runtime usage counter.
> + }
> +
> + mutex_unlock(&h->fifo_lock);
> + return IRQ_HANDLED;
> +}
[ ... ]
> +static int haptics_upload_effect(struct input_dev *dev,
> + struct ff_effect *effect,
> + struct ff_effect *old)
> +{
> + struct qcom_haptics *h = input_get_drvdata(dev);
> + struct qcom_haptics_effect *priv;
> + int id = effect->id;
> + u32 data_len;
> + s16 *buf;
> + s8 *fifo;
> +
> + if (id < 0 || id >= HAPTICS_MAX_EFFECTS)
> + return -EINVAL;
> +
> + priv = &h->effects[id];
> +
> + switch (effect->type) {
> + case FF_CONSTANT:
> + kfree(priv->fifo_data);
> + priv->fifo_data = NULL;
> + priv->data_len = 0;
> + priv->mode = HAPTICS_DIRECT_PLAY;
> + return 0;
> +
> + case FF_PERIODIC:
> + if (effect->u.periodic.waveform != FF_CUSTOM)
> + return -EINVAL;
> + /*
> + * Minimum 3 elements: play-rate code + vmax + at least one sample.
> + * No upper bound: the FIFO is refilled continuously from the IRQ
> + * handler, so any length of PCM data is supported.
> + */
> + if (effect->u.periodic.custom_len < 3)
> + return -EINVAL;
> +
> + buf = memdup_array_user(effect->u.periodic.custom_data,
> + effect->u.periodic.custom_len,
> + sizeof(s16));
[Severity: Medium]
Is there a missing upper bound check on custom_len?
A local user with write access to the input device can provide a very
large custom_len, and this directly allocates kernel memory without an
upper bound, which could lead to memory exhaustion.
> + if (IS_ERR(buf))
> + return PTR_ERR(buf);
> +
> + if (buf[CUSTOM_DATA_RATE_IDX] > PLAY_RATE_MAX) {
[Severity: Medium]
Can negative values bypass this boundary check?
buf is an array of signed 16-bit integers. A user passing a negative value
would bypass this check, get cast to u8 later, and be written to the
hardware registers as an out-of-bounds unsigned value.
> + kfree(buf);
> + return -EINVAL;
> + }
[ ... ]
> +static int haptics_playback(struct input_dev *dev, int effect_id, int val)
> +{
> + struct qcom_haptics *h = input_get_drvdata(dev);
> +
> + h->cur_effect_id = effect_id;
> + h->play_request = (val > 0);
[Severity: Medium]
Are play requests occasionally lost due to lockless accesses?
If the IRQ handler overwrites h->play_request to false immediately after a
new play event from userspace sets it to true here, the new request seems
to be lost. The worker will see play_request == false and stop the
hardware instead of starting the new effect.
> + schedule_work(&h->play_work);
> +
> + return 0;
> +}
[ ... ]
> +static void qcom_haptics_remove(struct platform_device *pdev)
> +{
> + struct qcom_haptics *h = platform_get_drvdata(pdev);
> + int i;
> +
> + pm_runtime_disable(&pdev->dev);
> + pm_runtime_set_suspended(&pdev->dev);
> +
> + mutex_lock(&h->play_lock);
> + haptics_stop_locked(h);
> + mutex_unlock(&h->play_lock);
[Severity: Medium]
Does this leak the runtime PM usage counter?
If remove is invoked while a haptics effect is actively playing,
h->pm_ref_held is true. This stops the hardware but does not call
pm_runtime_put_noidle(dev) to release the reference, leaving the PM
state unbalanced.
> +
> + haptics_enable_module(h, false);
> + cancel_work_sync(&h->play_work);
> + for (i = 0; i < HAPTICS_MAX_EFFECTS; i++) {
> + kfree(h->effects[i].fifo_data);
> + h->effects[i].fifo_data = NULL;
> + }
> +
> + input_unregister_device(h->input);
[Severity: High]
Is it safe to tear down resources before unregistering the input device?
Because the input device is still registered and active, an unprivileged
user can concurrently issue an ioctl (like EVIOCSFF or EVIOCRMFF) on the
open event node. This could access the freed effect structures or schedule
h->play_work after they have been destroyed.
> +}
[ ... ]
> +static int qcom_haptics_suspend(struct device *dev)
> +{
> + struct qcom_haptics *h = dev_get_drvdata(dev);
> +
> + mutex_lock(&h->play_lock);
> + haptics_stop_locked(h);
> + if (h->pm_ref_held) {
> + pm_runtime_put_noidle(dev);
> + h->pm_ref_held = false;
> + }
> + mutex_unlock(&h->play_lock);
[Severity: High]
Does this system suspend race with the asynchronous playback worker?
If userspace requests playback right before system suspend, h->play_request
is set to true and play_work is scheduled.
This suspend function stops the hardware but forgets to clear
h->play_request.
When this drops the lock, play_work can execute, see play_request is still
true, and re-enable the hardware just before the system suspends.
> +
> + cancel_work_sync(&h->play_work);
> + return pm_runtime_force_suspend(dev);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260624-qcom-spmi-haptics-v2-0-b9118e60f3e3@oss.qualcomm.com?part=3
^ 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