* Re: [PATCH RFC v7 2/9] dt-bindings: firmware: arm,scmi: Add Qualcomm Generic Extension Protocol
From: sashiko-bot @ 2026-06-10 9:01 UTC (permalink / raw)
To: Pragnesh Papaniya; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260610-rfc_v7_scmi_memlat-v7-2-f3f68c608f25@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Adding `qcom,generic-scmi.yaml` to the unconditional `anyOf` block silently bypasses strict schema validation for all other vendor schemas (e.g., `nxp,imx95-scmi.yaml`).
--
commit 4cdbbb0bcf03bec0f34cb611707f09de406a9cfa
Author: Pragnesh Papaniya <pragnesh.papaniya@oss.qualcomm.com>
dt-bindings: firmware: arm,scmi: Add Qualcomm Generic Extension Protocol
This commit adds the binding schema for the Qualcomm SCMI Generic Extension
Protocol to support Bus DVFS on several SoCs.
> diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> index d06cca9273c48..aedc57dd3b389 100644
> --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml
> @@ -24,6 +24,7 @@ description: |
>
> anyOf:
> - $ref: /schemas/firmware/nxp,imx95-scmi.yaml
> + - $ref: /schemas/firmware/qcom,generic-scmi.yaml
[Severity: Medium]
Does adding qcom,generic-scmi.yaml to the unconditional anyOf block silently
bypass strict schema validation for all other vendor schemas?
Due to JSON Schema evaluation rules, an additionalProperties: true keyword in
the newly added QCOM schema evaluates to boolean true and annotates all
properties it matches as evaluated.
If an NXP device tree has an invalid property (for example, wrong types inside
protocol@81 or protocol@84), it correctly fails the nxp,imx95-scmi.yaml
schema. However, because it is evaluated against the unconditional anyOf block
here, it then falls back to qcom,generic-scmi.yaml.
Since the QCOM schema does not define NXP's specific properties, it accepts
them via its additionalProperties: true directive and annotates them as
evaluated. The anyOf condition is thus satisfied, and the top-level
unevaluatedProperties: false check in arm,scmi.yaml passes, silently
suppressing the NXP schema validation failure.
Should vendor schemas be conditionally applied based on compatible strings
(for example, using if: properties: compatible: contains: ...) instead of
being placed into an unconditional anyOf list?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610-rfc_v7_scmi_memlat-v7-0-f3f68c608f25@oss.qualcomm.com?part=2
^ permalink raw reply
* Re: [net-next 1/3] dt-bindings: ptp: renesas,rcar-gen4-gptp: Add binding for R-Car Gen4
From: Krzysztof Kozlowski @ 2026-06-10 9:01 UTC (permalink / raw)
To: Niklas Söderlund
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Richard Cochran, Andrew Lunn,
DavidS. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-renesas-soc, devicetree, linux-kernel, netdev
In-Reply-To: <20260610085354.GC2465390@ragnatech.se>
On 10/06/2026 10:53, Niklas Söderlund wrote:
> Hi Krzysztof,
>
> Thanks for your comments.
>
> On 2026-06-10 08:54:06 +0200, Krzysztof Kozlowski wrote:
>> On 09/06/2026 23:57, Niklas Söderlund wrote:
>>> Add bindings for the R-Car Gen4 gPTP timer. The timer enables accurate
>>> synchronization of the clock in the control system. The timer is
>>> system-wide and used by different Ethernet devices on each Gen4 platform.
>>
>> A nit, subject: drop second/last, redundant "binding for". The
>> "dt-bindings" prefix is already stating that these are bindings.
>
> Thanks, will fix.
>
>> See also:
>> https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L18
>
> Not sure I follow this one, L18 reads,
>
> "Few subsystems, like ASoC, media, regulators and SPI, expect reverse
> order of the prefixes::"
>
> But 'git log Documentation/devicetree/bindings/ptp/' shows all commits
> in that directory use the 'dt-bindings: ptp:' prefix.
5 lines below.
https://elixir.bootlin.com/linux/v6.17-rc3/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: hwmon: ina2xx: add ina232 compatible
From: Loic Poulain @ 2026-06-10 9:01 UTC (permalink / raw)
To: sashiko-reviews; +Cc: robh, conor+dt, linux-hwmon, devicetree
In-Reply-To: <20260610084110.95B9A1F00893@smtp.kernel.org>
On Wed, Jun 10, 2026 at 10:41 AM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] The `ti,ina232` compatible string was added to the top-level enum but omitted from the existing `if-then` conditional blocks that restrict unsupported properties.
> --
>
> commit 3cd10611f4c71e7280e19fcd316cd7a918042ee6
> Author: Martino Facchin <m.facchin@arduino.cc>
>
> dt-bindings: hwmon: ina2xx: add ina232 compatible
>
> The INA232 is a current/power monitor from Texas Instruments sharing
> the same register map as the other INA2xx.
>
> > diff --git a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
> > index 009d78b308596..a30888c9156b9 100644
> > --- a/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
> > +++ b/Documentation/devicetree/bindings/hwmon/ti,ina2xx.yaml
> > @@ -28,6 +28,7 @@ properties:
> > - ti,ina228
> > - ti,ina230
> > - ti,ina231
> > + - ti,ina232
>
> [Severity: Low]
> Does this new compatible string need to be added to the allOf conditional
> blocks further down in the schema file?
>
> By omitting ti,ina232 from the exclusion list for
> ti,maximum-expected-current-microamp, the schema might incorrectly allow
> this property for ti,ina232 nodes:
>
> allOf:
> - if:
> properties:
> compatible:
> contains:
> enum:
> - silergy,sq52206
> ...
> - ti,ina231
> - ti,ina234
> - ti,ina237
> then:
> properties:
> ti,maximum-expected-current-microamp: false
>
> Should ti,ina232 be added alongside ti,ina231 here?
>
> Similarly, ti,ina232 appears to be omitted from the conditional block
> restricting ti,shunt-gain:
>
> - if:
> properties:
> compatible:
> contains:
> enum:
> - silergy,sy24655
> ...
> - ti,ina231
> - ti,ina234
> - ti,ina260
> then:
> properties:
> ti,shunt-gain: false
>
> Could this weaken schema validation when checking device tree nodes for
> this specific hardware variant?
That's a valid point, will be addressed in v2.
^ permalink raw reply
* Re: [PATCH v2 03/16] power: sequencing: Change CONFIG_POWER_SEQUENCING to bool
From: Chen-Yu Tsai @ 2026-06-10 9:00 UTC (permalink / raw)
To: Bartosz Golaszewski, Greg Kroah-Hartman, Andy Shevchenko,
Daniel Scally, Heikki Krogerus, Sakari Ailus, Rafael J. Wysocki,
Danilo Krummrich, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Matthias Brugger, AngeloGioacchino Del Regno
Cc: Alan Stern, linux-acpi, driver-core, linux-pm, linux-usb,
devicetree, linux-mediatek, linux-arm-kernel, linux-kernel,
Manivannan Sadhasivam
In-Reply-To: <20260610084053.2059858-4-wenst@chromium.org>
On Wed, Jun 10, 2026 at 5:41 PM Chen-Yu Tsai <wenst@chromium.org> wrote:
>
> USB support, including the core and hub driver, is bool, no modules. To
> be able to use the power sequencing API in the USB core, the former must
> also be bool to avoid the latter being built as a module.
>
> Change CONFIG_POWER_SEQUENCING to bool.
As Sashiko pointed out, CONFIG_USB is tristate. I was looking at the
wrong symbol. Please ignore this patch.
ChenYu
^ permalink raw reply
* RE: [PATCH 1/2] dt-bindings: connector: pcie-m2-e: Add 3.3Vaux supply support
From: Sherry Sun @ 2026-06-10 9:00 UTC (permalink / raw)
To: Krzysztof Kozlowski, sashiko-reviews@lists.linux.dev,
manivannan.sadhasivam@oss.qualcomm.com
Cc: linux-pci@vger.kernel.org, robh@kernel.org, Frank.Li@kernel.org,
conor+dt@kernel.org, devicetree@vger.kernel.org,
imx@lists.linux.dev
In-Reply-To: <10f5d51a-2e0e-477f-8431-9a305d57118c@kernel.org>
> On 10/06/2026 10:40, Sherry Sun wrote:
> >> On Tue, Jun 09, 2026 at 03:44:08AM +0000, sashiko-bot@kernel.org wrote:
> >>> Thank you for your contribution! Sashiko AI review found 1 potential
> >> issue(s) to consider:
> >>> - [Medium] The `vpcie3v3aux-supply` property describes a
> >>> non-existent
> >> hardware feature on the M.2 Key E connector to work around a software
> >> policy.
> >>
> >> Feels valid. Describe which pin on M2 connector are you representing.
> >>
> >
> > Refer to PCI Express M.2 Specification r5.1 sec3.1.1 Power Sources and
> > Grounds.
> >
> > PCI Express M.2 Socket 1 utilizes a 3.3 V power source. The voltage
> > source, 3.3 V, is expected to be available during the system’s
> > stand-by/suspend state to support wake event processing on the
> > communications card.
>
> Again:
> Describe which pin on M2 connector are you representing.
Same pin with the vpcie3v3-supply property in current dt-binding.
So from Device tree bindings perspective, vpcie3v3aux looks not that
reasonable. I am wondering if there are better solutions to support this.
Best Regards
Sherry
^ permalink raw reply
* [net-next v1 3/6] net: stmmac: Add register NCSI device support
From: Minda Chen @ 2026-06-10 7:24 UTC (permalink / raw)
To: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Jose Abreu, Maxime Coquelin, Russell King,
Giuseppe Cavallaro, Alexandre Torgue, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260610072420.64699-1-minda.chen@starfivetech.com>
Add stmmac register support. The register NCSI code is
almost from faraday ftgmac100.c
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 +
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 44 +++++++++++++++++--
.../ethernet/stmicro/stmmac/stmmac_platform.c | 10 ++++-
include/linux/stmmac.h | 1 +
4 files changed, 51 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac.h b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
index 8ba8f03e1ce0..1df0689e22a5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac.h
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac.h
@@ -383,6 +383,7 @@ struct stmmac_priv {
struct bpf_prog *xdp_prog;
struct devlink *devlink;
+ struct ncsi_dev *nsdev;
};
enum stmmac_state {
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index 010802389772..b6af53783883 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -41,6 +41,7 @@
#include <linux/udp.h>
#include <linux/bpf_trace.h>
#include <net/devlink.h>
+#include <net/ncsi.h>
#include <net/page_pool/helpers.h>
#include <net/pkt_cls.h>
#include <net/xdp_sock_drv.h>
@@ -4167,6 +4168,16 @@ static int __stmmac_open(struct net_device *dev,
if (ret)
goto irq_error;
+ if (priv->plat->use_ncsi) {
+ /* If using NC-SI, set our carrier on and start the stack */
+ netif_carrier_on(priv->dev);
+
+ /* Start the NCSI device */
+ ret = ncsi_start_dev(priv->nsdev);
+ if (ret)
+ goto irq_error;
+ }
+
stmmac_enable_all_queues(priv);
netif_tx_start_all_queues(priv->dev);
stmmac_enable_all_dma_irq(priv);
@@ -4250,6 +4261,9 @@ static void __stmmac_release(struct net_device *dev)
netif_tx_disable(dev);
+ if (priv->plat->use_ncsi)
+ ncsi_stop_dev(priv->nsdev);
+
/* Free the IRQ lines */
stmmac_free_irq(dev, REQ_IRQ_ERR_ALL, 0);
@@ -7795,6 +7809,15 @@ struct plat_stmmacenet_data *stmmac_plat_dat_alloc(struct device *dev)
}
EXPORT_SYMBOL_GPL(stmmac_plat_dat_alloc);
+static void stmmac_ncsi_handler(struct ncsi_dev *nd)
+{
+ if (unlikely(nd->state != ncsi_dev_state_functional))
+ return;
+
+ netdev_info(nd->dev, "NCSI interface %s\n",
+ nd->link_up ? "up" : "down");
+}
+
static int __stmmac_dvr_probe(struct device *device,
struct plat_stmmacenet_data *plat_dat,
struct stmmac_resources *res)
@@ -8048,10 +8071,19 @@ static int __stmmac_dvr_probe(struct device *device,
if (ret)
goto error_pcs_setup;
- ret = stmmac_phylink_setup(priv);
- if (ret) {
- netdev_err(ndev, "failed to setup phy (%d)\n", ret);
- goto error_phy_setup;
+ if (priv->plat->use_ncsi) {
+ dev_info(priv->device, "Using NCSI interface\n");
+ priv->nsdev = ncsi_register_dev(ndev, stmmac_ncsi_handler);
+ if (!priv->nsdev) {
+ ret = -ENODEV;
+ goto error_phy_setup;
+ }
+ } else {
+ ret = stmmac_phylink_setup(priv);
+ if (ret) {
+ netdev_err(ndev, "failed to setup phy (%d)\n", ret);
+ goto error_phy_setup;
+ }
}
ret = stmmac_register_devlink(priv);
@@ -8082,6 +8114,8 @@ static int __stmmac_dvr_probe(struct device *device,
error_netdev_register:
stmmac_unregister_devlink(priv);
error_devlink_setup:
+ if (priv->nsdev)
+ ncsi_unregister_dev(priv->nsdev);
stmmac_phylink_destroy(priv->phylink);
error_phy_setup:
stmmac_pcs_clean(ndev);
@@ -8141,6 +8175,8 @@ void stmmac_dvr_remove(struct device *dev)
pm_runtime_get_sync(dev);
+ if (priv->nsdev)
+ ncsi_unregister_dev(priv->nsdev);
unregister_netdev(ndev);
#ifdef CONFIG_DEBUG_FS
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
index 5cae2aa72906..483ecf06fc13 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c
@@ -348,7 +348,7 @@ static int stmmac_mdio_setup(struct plat_stmmacenet_data *plat,
* described assume this is the case since there must be something
* connected to the MAC.
*/
- legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node;
+ legacy_mdio = !of_phy_is_fixed_link(np) && !plat->phy_node && !plat->use_ncsi;
if (legacy_mdio)
dev_info(dev, "Deprecated MDIO bus assumption used\n");
@@ -451,6 +451,14 @@ stmmac_probe_config_dt(struct platform_device *pdev, u8 *mac)
* they are not converted to phylink. */
plat->phy_node = of_parse_phandle(np, "phy-handle", 0);
+ if (of_property_read_bool(np, "snps,use-ncsi")) {
+ if (!IS_ENABLED(CONFIG_NET_NCSI)) {
+ dev_err(&pdev->dev, "NCSI stack not enabled\n");
+ return ERR_PTR(-EINVAL);
+ }
+ plat->use_ncsi = true;
+ }
+
/* Get max speed of operation from device tree */
of_property_read_u32(np, "max-speed", &plat->max_speed);
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 4430b967abde..8c4f1b0a1a42 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -348,6 +348,7 @@ struct plat_stmmacenet_data {
int mac_port_sel_speed;
u8 vlan_fail_q;
bool provide_bus_info;
+ bool use_ncsi;
int int_snapshot_num;
int msi_mac_vec;
int msi_wol_vec;
--
2.17.1
^ permalink raw reply related
* [PATCH v1 3/3] arm64: dts: imx8mm-var-dart: Add support for Variscite Sonata board
From: Stefano Radaelli @ 2026-06-10 8:58 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Dario Binacchi,
Josua Mayer, Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <cover.1781024557.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite Sonata carrier board with the
DART-MX8M-MINI system on module.
The Sonata board includes
- uSD Card support
- USB ports and OTG
- Uart, SPI and I2C interfaces
- HDMI support
- GPIO Expanders
- RTC module
- TPM module
- CAN peripherals
Link: https://variscite.com/carrier-boards/sonata-board/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8mm-var-dart-sonata.dts | 517 ++++++++++++++++++
2 files changed, 518 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 8ddaab127ab9..694c9aa32779 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -166,6 +166,7 @@ dtb-$(CONFIG_ARCH_MXC) += imx8mm-prt8mm.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-tqma8mqml-mba8mx.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-tx8m-1610-moduline-iv-306-d.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-tx8m-1610-moduline-mini-111.dtb
+dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-dart-sonata.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-var-som-symphony-legacy.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8mm-venice-gw71xx-0x.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts b/arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts
new file mode 100644
index 000000000000..93b0076987b8
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts
@@ -0,0 +1,517 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Variscite Sonata carrier board for DART-MX8M-MINI
+ *
+ * Link: https://variscite.com/carrier-boards/sonata-board/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include <dt-bindings/leds/common.h>
+#include <dt-bindings/phy/phy-imx8-pcie.h>
+#include "imx8mm-var-dart.dtsi"
+
+/ {
+ model = "Variscite DART-MX8M-MINI on Sonata-Board";
+ compatible = "variscite,var-dart-mx8mm-sonata",
+ "variscite,var-dart-mx8mm",
+ "fsl,imx8mm";
+
+ chosen {
+ stdout-path = &uart1;
+ };
+
+ gpio-keys {
+ compatible = "gpio-keys";
+
+ button-home {
+ label = "Home";
+ linux,code = <KEY_HOME>;
+ gpios = <&pca6408_1 4 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-up {
+ label = "Up";
+ linux,code = <KEY_UP>;
+ gpios = <&pca6408_1 5 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-down {
+ label = "Down";
+ linux,code = <KEY_DOWN>;
+ gpios = <&pca6408_1 6 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+
+ button-back {
+ label = "Back";
+ linux,code = <KEY_BACK>;
+ gpios = <&pca6408_1 7 GPIO_ACTIVE_LOW>;
+ wakeup-source;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_gpio_leds>;
+
+ led-emmc {
+ gpios = <&gpio4 18 GPIO_ACTIVE_HIGH>;
+ label = "eMMC";
+ linux,default-trigger = "mmc2";
+ };
+ };
+
+ clk40m: oscillator {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <40000000>;
+ clock-output-names = "can_osc";
+ };
+
+ pcie0_refclk: pcie0-refclk {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <100000000>;
+ };
+
+ reg_usdhc2_vmmc: regulator-vmmc-usdhc2 {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_vmmc_usdhc2>;
+ regulator-name = "VSD_3V3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio2 19 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ startup-delay-us = <100>;
+ off-on-delay-us = <12000>;
+ };
+};
+
+&ecspi1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ecspi1>;
+ cs-gpios = <&gpio5 9 GPIO_ACTIVE_LOW>,
+ <&gpio1 12 GPIO_ACTIVE_LOW>;
+ status = "okay";
+
+ /* Resistive touch controller */
+ ads7846: touchscreen@0 {
+ compatible = "ti,ads7846";
+ reg = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_restouch>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
+ spi-max-frequency = <1500000>;
+ pendown-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
+ ti,x-min = /bits/ 16 <125>;
+ ti,x-max = /bits/ 16 <4008>;
+ ti,y-min = /bits/ 16 <282>;
+ ti,y-max = /bits/ 16 <3864>;
+ ti,x-plate-ohms = /bits/ 16 <180>;
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,debounce-max = /bits/ 16 <10>;
+ ti,debounce-tol = /bits/ 16 <3>;
+ ti,debounce-rep = /bits/ 16 <1>;
+ ti,settle-delay-usec = /bits/ 16 <150>;
+ ti,keep-vref-on;
+ wakeup-source;
+ };
+
+ can0: can@1 {
+ compatible = "microchip,mcp251xfd";
+ reg = <1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_can>;
+ clocks = <&clk40m>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
+ microchip,rx-int-gpios = <&gpio5 4 GPIO_ACTIVE_LOW>;
+ spi-max-frequency = <20000000>;
+ };
+};
+
+ðphy0 {
+ leds {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ led@0 {
+ reg = <0>;
+ color = <LED_COLOR_ID_YELLOW>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+
+ led@1 {
+ reg = <1>;
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_LAN;
+ linux,default-trigger = "netdev";
+ };
+ };
+};
+
+&i2c2 {
+ clock-frequency = <100000>;
+ 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";
+
+ pca9534: gpio@22 {
+ compatible = "nxp,pca9534";
+ reg = <0x22>;
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ /* RGB_SEL */
+ lvds-brg-enable-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ output-low;
+ line-name = "rgb_sel";
+ };
+ };
+
+ /* Capacitive touch controller */
+ ft5x06_ts: touchscreen@38 {
+ compatible = "edt,edt-ft5206";
+ reg = <0x38>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_captouch>;
+ reset-gpios = <&pca6408_2 4 GPIO_ACTIVE_LOW>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <14 IRQ_TYPE_EDGE_FALLING>;
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ touchscreen-inverted-x;
+ touchscreen-inverted-y;
+ wakeup-source;
+ };
+
+ extcon_ptn5150: typec@3d {
+ compatible = "nxp,ptn5150";
+ reg = <0x3d>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_extcon>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <10 IRQ_TYPE_EDGE_FALLING>;
+
+ port {
+ typec1_dr_sw: endpoint {
+ remote-endpoint = <&usb1_drd_sw>;
+ };
+ };
+ };
+
+ rtc@68 {
+ compatible = "dallas,ds1337";
+ reg = <0x68>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rtc>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <15 IRQ_TYPE_EDGE_FALLING>;
+ wakeup-source;
+ };
+};
+
+&i2c4 {
+ clock-frequency = <100000>;
+ pinctrl-names = "default", "gpio";
+ pinctrl-0 = <&pinctrl_i2c4>;
+ pinctrl-1 = <&pinctrl_i2c4_gpio>;
+ scl-gpios = <&gpio5 20 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&gpio5 21 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ pca6408_1: gpio@20 {
+ compatible = "nxp,pcal6408";
+ reg = <0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pca6408>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ pca6408_2: gpio@21 {
+ compatible = "nxp,pcal6408";
+ reg = <0x21>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <5 IRQ_TYPE_LEVEL_LOW>;
+ };
+
+ st33ktpm2xi2c: tpm@2e {
+ compatible = "st,st33ktpm2xi2c", "tcg,tpm-tis-i2c";
+ reg = <0x2e>;
+ label = "tpm";
+ reset-gpios = <&pca9534 0 GPIO_ACTIVE_HIGH>;
+ };
+};
+
+&pcie_phy {
+ fsl,refclk-pad-mode = <IMX8_PCIE_REFCLK_PAD_INPUT>;
+ fsl,tx-deemph-gen1 = <0x2d>;
+ fsl,tx-deemph-gen2 = <0xf>;
+ clocks = <&pcie0_refclk>;
+ status = "okay";
+};
+
+&pcie0 {
+ reset-gpios = <&pca6408_2 3 GPIO_ACTIVE_LOW>;
+ clocks = <&clk IMX8MM_CLK_PCIE1_ROOT>, <&pcie0_refclk>,
+ <&clk IMX8MM_CLK_PCIE1_AUX>;
+ assigned-clocks = <&clk IMX8MM_CLK_PCIE1_AUX>,
+ <&clk IMX8MM_CLK_PCIE1_CTRL>;
+ assigned-clock-rates = <10000000>, <250000000>;
+ assigned-clock-parents = <&clk IMX8MM_SYS_PLL2_50M>,
+ <&clk IMX8MM_SYS_PLL2_250M>;
+ status = "okay";
+};
+
+&pwm1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pwm>;
+ status = "okay";
+};
+
+&snvs_pwrkey {
+ status = "okay";
+};
+
+&snvs_rtc {
+ status = "disabled";
+};
+
+/* Console */
+&uart1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart1>;
+ wakeup-source;
+ status = "okay";
+};
+
+/* Header */
+&uart2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart2>;
+ status = "okay";
+};
+
+/* Header */
+&uart3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart3>;
+ status = "okay";
+};
+
+&usbotg1 {
+ dr_mode = "otg";
+ hnp-disable;
+ srp-disable;
+ adp-disable;
+ usb-role-switch;
+ disable-over-current;
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ status = "okay";
+
+ port {
+ usb1_drd_sw: endpoint {
+ remote-endpoint = <&typec1_dr_sw>;
+ };
+ };
+};
+
+&usbotg2 {
+ dr_mode = "host";
+ samsung,picophy-pre-emp-curr-control = <3>;
+ samsung,picophy-dc-vol-level-adjust = <7>;
+ disable-over-current;
+ status = "okay";
+};
+
+/* SD */
+&usdhc2 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>;
+ pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>;
+ cd-gpios = <&gpio2 12 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
+ vmmc-supply = <®_usdhc2_vmmc>;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_can: cangrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO06_GPIO1_IO6 0x16
+ MX8MM_IOMUXC_SPDIF_RX_GPIO5_IO4 0x16
+ >;
+ };
+
+ pinctrl_captouch: captouchgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO14_GPIO1_IO14 0x16
+ >;
+ };
+
+ pinctrl_ecspi1: ecspi1grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ECSPI1_SCLK_ECSPI1_SCLK 0x13
+ MX8MM_IOMUXC_ECSPI1_MOSI_ECSPI1_MOSI 0x13
+ MX8MM_IOMUXC_ECSPI1_MISO_ECSPI1_MISO 0x13
+ MX8MM_IOMUXC_ECSPI1_SS0_GPIO5_IO9 0x13
+ MX8MM_IOMUXC_GPIO1_IO12_GPIO1_IO12 0x13
+ MX8MM_IOMUXC_SAI2_RXC_GPIO4_IO22 0x13
+ >;
+ };
+
+ pinctrl_extcon: extcongrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO10_GPIO1_IO10 0x19
+ >;
+ };
+
+ pinctrl_gpio_leds: ledgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SAI1_TXD6_GPIO4_IO18 0x1c6
+ >;
+ };
+
+ pinctrl_i2c2: i2c2grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C2_SCL_I2C2_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C2_SDA_I2C2_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c2_gpio: i2c2-gpiogrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C2_SCL_GPIO5_IO16 0x400001c3
+ MX8MM_IOMUXC_I2C2_SDA_GPIO5_IO17 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c4: i2c4grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C4_SCL_I2C4_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C4_SDA_I2C4_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c4_gpio: i2c4-gpiogrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C4_SCL_GPIO5_IO20 0x400001c3
+ MX8MM_IOMUXC_I2C4_SDA_GPIO5_IO21 0x400001c3
+ >;
+ };
+
+ pinctrl_pca6408: pca6408grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO05_GPIO1_IO5 0x1c6
+ >;
+ };
+
+ pinctrl_pwm: pwmgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO01_PWM1_OUT 0x06
+ >;
+ };
+
+ pinctrl_vmmc_usdhc2: regvmmc-usdhc2grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_RESET_B_GPIO2_IO19 0xc1
+ >;
+ };
+
+ pinctrl_restouch: restouchgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO03_GPIO1_IO3 0x1c0
+ >;
+ };
+
+ pinctrl_rtc: rtcgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO15_GPIO1_IO15 0x1c1
+ >;
+ };
+
+ pinctrl_uart1: uart1grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_UART1_RXD_UART1_DCE_RX 0x140
+ MX8MM_IOMUXC_UART1_TXD_UART1_DCE_TX 0x140
+ >;
+ };
+
+ pinctrl_uart2: uart2grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_UART2_RXD_UART2_DCE_RX 0x140
+ MX8MM_IOMUXC_UART2_TXD_UART2_DCE_TX 0x140
+ >;
+ };
+
+ pinctrl_uart3: uart3grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_UART3_RXD_UART3_DCE_RX 0x140
+ MX8MM_IOMUXC_UART3_TXD_UART3_DCE_TX 0x140
+ >;
+ };
+
+ pinctrl_usdhc2: usdhc2grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x190
+ MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d0
+ MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d0
+ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d0
+ MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d0
+ MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d0
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x194
+ MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d4
+ MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d4
+ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d4
+ MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d4
+ MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d4
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CLK_USDHC2_CLK 0x196
+ MX8MM_IOMUXC_SD2_CMD_USDHC2_CMD 0x1d6
+ MX8MM_IOMUXC_SD2_DATA0_USDHC2_DATA0 0x1d6
+ MX8MM_IOMUXC_SD2_DATA1_USDHC2_DATA1 0x1d6
+ MX8MM_IOMUXC_SD2_DATA2_USDHC2_DATA2 0x1d6
+ MX8MM_IOMUXC_SD2_DATA3_USDHC2_DATA3 0x1d6
+ MX8MM_IOMUXC_GPIO1_IO04_USDHC2_VSELECT 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc2_gpio: usdhc2-gpiogrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_CD_B_GPIO2_IO12 0xc1
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 2/3] arm64: dts: freescale: Add support for Variscite DART-MX8M-MINI
From: Stefano Radaelli @ 2026-06-10 8:58 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Dario Binacchi,
Josua Mayer, Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <cover.1781024557.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add device tree support for the Variscite DART-MX8MM system on module.
This SOM is designed to be used with various carrier boards.
The module includes:
- NXP i.MX8M Mini MPU processor
- Up to 4GB of LPDDR4 memory
- Up to 128GB of eMMC storage memory
- Integrated 10/100/1000 Mbps Ethernet Transceiver
- Codec audio WM8904
- WIFI6 dual-band 802.11ax/ac/a/b/g/n with optional 802.15.4 and Bluetooth
Only SOM-specific peripherals are enabled by default. Carrier board
specific interfaces are left disabled to be enabled in the respective
carrier board device trees.
Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-mini/dart-mx8m-mini/
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
.../boot/dts/freescale/imx8mm-var-dart.dtsi | 559 ++++++++++++++++++
1 file changed, 559 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
diff --git a/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi b/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
new file mode 100644
index 000000000000..1b65e2829672
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
@@ -0,0 +1,559 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Common dtsi for Variscite DART-MX8M-MINI
+ *
+ * Link: https://variscite.com/system-on-module-som/i-mx-8/i-mx-8m-mini/dart-mx8m-mini/
+ *
+ * Copyright (C) 2026 Variscite Ltd. - https://www.variscite.com/
+ *
+ */
+
+/dts-v1/;
+
+#include "imx8mm.dtsi"
+
+/ {
+ model = "Variscite DART-MX8M-MINI Module";
+ compatible = "variscite,var-dart-mx8mm", "fsl,imx8mm";
+
+ memory@40000000 {
+ device_type = "memory";
+ reg = <0x0 0x40000000 0 0x80000000>;
+ };
+
+ reg_audio_supply: regulator-3p3v {
+ compatible = "regulator-fixed";
+ regulator-name = "wm8904-supply";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-always-on;
+ };
+
+ reg_eth_phy: regulator-eth-phy {
+ compatible = "regulator-fixed";
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_reg_eth_phy>;
+ regulator-name = "eth_phy_pwr";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-enable-ramp-delay = <20000>;
+ gpio = <&gpio1 7 GPIO_ACTIVE_LOW>;
+ enable-active-high;
+ };
+
+ reg_phy_vddio: regulator-phy-vddio {
+ compatible = "regulator-fixed";
+ regulator-name = "vddio-1v8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ };
+
+ sound-wm8904 {
+ compatible = "simple-audio-card";
+ simple-audio-card,bitclock-master = <&codec_dai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&codec_dai>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "wm8904-audio";
+ simple-audio-card,routing =
+ "Headphone Jack", "HPOUTL",
+ "Headphone Jack", "HPOUTR",
+ "IN2L", "Line In Jack",
+ "IN2R", "Line In Jack",
+ "IN1L", "Microphone Jack",
+ "IN1R", "Microphone Jack";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack",
+ "Line", "Line In Jack";
+
+ codec_dai: simple-audio-card,codec {
+ sound-dai = <&wm8904>;
+ };
+
+ simple-audio-card,cpu {
+ sound-dai = <&sai3>;
+ };
+ };
+
+ wifi_pwrseq: wifi-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ post-power-on-delay-ms = <100>;
+ power-off-delay-us = <10000>;
+ reset-gpios = <&gpio2 10 GPIO_ACTIVE_LOW>, /* WIFI_RESET */
+ <&gpio2 20 GPIO_ACTIVE_LOW>; /* WIFI_PWR_EN */
+ };
+};
+
+&A53_0 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&A53_1 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&A53_2 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&A53_3 {
+ cpu-supply = <&buck2_reg>;
+};
+
+&fec1 {
+ pinctrl-names = "default", "sleep";
+ pinctrl-0 = <&pinctrl_fec1>;
+ pinctrl-1 = <&pinctrl_fec1_sleep>;
+ /*
+ * The required RGMII TX and RX 2ns delays are implemented directly
+ * in hardware via passive delay elements on the SOM PCB.
+ * No delay configuration is needed in software via PHY driver.
+ */
+ phy-mode = "rgmii";
+ phy-handle = <ðphy0>;
+ phy-supply = <®_eth_phy>;
+ status = "okay";
+
+ mdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ethphy0: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ reset-gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
+ reset-assert-us = <10000>;
+ reset-deassert-us = <100000>;
+ vddio-supply = <®_phy_vddio>;
+ };
+ };
+};
+
+&i2c1 {
+ clock-frequency = <100000>;
+ 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";
+
+ pmic@4b {
+ compatible = "rohm,bd71847";
+ reg = <0x4b>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_pmic>;
+ interrupt-parent = <&gpio2>;
+ interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
+ rohm,reset-snvs-powered;
+
+ regulators {
+ buck1_reg: BUCK1 {
+ regulator-name = "buck1";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1250>;
+ };
+
+ buck2_reg: BUCK2 {
+ regulator-name = "buck2";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ regulator-ramp-delay = <1250>;
+ rohm,dvs-run-voltage = <1000000>;
+ rohm,dvs-idle-voltage = <900000>;
+ };
+
+ buck3_reg: BUCK3 {
+ // BUCK5 in datasheet
+ regulator-name = "buck3";
+ regulator-min-microvolt = <700000>;
+ regulator-max-microvolt = <1350000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck4_reg: BUCK4 {
+ // BUCK6 in datasheet
+ regulator-name = "buck4";
+ regulator-min-microvolt = <2600000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck5_reg: BUCK5 {
+ // BUCK7 in datasheet
+ regulator-name = "buck5";
+ regulator-min-microvolt = <1605000>;
+ regulator-max-microvolt = <1995000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ buck6_reg: BUCK6 {
+ // BUCK8 in datasheet
+ regulator-name = "buck6";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo1_reg: LDO1 {
+ regulator-name = "ldo1";
+ regulator-min-microvolt = <1600000>;
+ regulator-max-microvolt = <1900000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo2_reg: LDO2 {
+ regulator-name = "ldo2";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <900000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo3_reg: LDO3 {
+ regulator-name = "ldo3";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+
+ ldo4_reg: LDO4 {
+ regulator-name = "ldo4";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ ldo5_reg: LDO5 {
+ regulator-name = "ldo5";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-always-on;
+ };
+
+ ldo6_reg: LDO6 {
+ regulator-name = "ldo6";
+ regulator-min-microvolt = <900000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-boot-on;
+ regulator-always-on;
+ };
+ };
+ };
+};
+
+&i2c3 {
+ clock-frequency = <100000>;
+ 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";
+
+ wm8904: audio-codec@1a {
+ compatible = "wlf,wm8904";
+ reg = <0x1a>;
+ #sound-dai-cells = <0>;
+ clocks = <&clk IMX8MM_CLK_SAI3_ROOT>;
+ clock-names = "mclk";
+ AVDD-supply = <&ldo5_reg>;
+ CPVDD-supply = <&ldo5_reg>;
+ DBVDD-supply = <®_audio_supply>;
+ DCVDD-supply = <&ldo5_reg>;
+ MICVDD-supply = <&ldo5_reg>;
+ wlf,drc-cfg-names = "default", "peaklimiter", "tradition",
+ "soft", "music";
+ /*
+ * Config registers per name, respectively:
+ * KNEE_IP = 0, KNEE_OP = 0, HI_COMP = 1, LO_COMP = 1
+ * KNEE_IP = -24, KNEE_OP = -6, HI_COMP = 1/4, LO_COMP = 1
+ * KNEE_IP = -42, KNEE_OP = -3, HI_COMP = 0, LO_COMP = 1
+ * KNEE_IP = -45, KNEE_OP = -9, HI_COMP = 1/8, LO_COMP = 1
+ * KNEE_IP = -30, KNEE_OP = -10.5, HI_COMP = 1/4, LO_COMP = 1
+ */
+ wlf,drc-cfg-regs = /bits/ 16 <0x01af 0x3248 0x0000 0x0000>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x0408>,
+ /bits/ 16 <0x04af 0x324b 0x0028 0x0704>,
+ /bits/ 16 <0x04af 0x324b 0x0018 0x078c>,
+ /bits/ 16 <0x04af 0x324b 0x0010 0x050e>;
+ /* GPIO1 = DMIC_CLK, don't touch others */
+ wlf,gpio-cfg = <0x0018>, <0xffff>, <0xffff>, <0xffff>;
+ };
+};
+
+&mu {
+ status = "okay";
+};
+
+&sai3 {
+ #sound-dai-cells = <0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_sai3>;
+ assigned-clocks = <&clk IMX8MM_CLK_SAI3>;
+ assigned-clock-parents = <&clk IMX8MM_AUDIO_PLL1_OUT>;
+ assigned-clock-rates = <1536000>;
+ fsl,sai-mclk-direction-output;
+ status = "okay";
+};
+
+/* BT module */
+&uart4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_uart4>, <&pinctrl_bt>;
+ assigned-clocks = <&clk IMX8MM_CLK_UART4>;
+ assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth_iw61x: bluetooth {
+ compatible = "nxp,88w8987-bt";
+ };
+};
+
+/* WIFI */
+&usdhc1 {
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ pinctrl-0 = <&pinctrl_usdhc1>, <&pinctrl_wifi>;
+ pinctrl-1 = <&pinctrl_usdhc1_100mhz>, <&pinctrl_wifi>;
+ pinctrl-2 = <&pinctrl_usdhc1_200mhz>, <&pinctrl_wifi>;
+ bus-width = <4>;
+ keep-power-in-suspend;
+ mmc-pwrseq = <&wifi_pwrseq>;
+ non-removable;
+ status = "okay";
+};
+
+/* eMMC */
+&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;
+ status = "okay";
+};
+
+&wdog1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_wdog>;
+ fsl,ext-reset-output;
+ status = "okay";
+};
+
+&iomuxc {
+ pinctrl_bt: btgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_DATA4_GPIO2_IO6 0xc1
+ MX8MM_IOMUXC_SPDIF_EXT_CLK_GPIO5_IO5 0xc1
+ >;
+ };
+
+ pinctrl_fec1: fec1grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ENET_MDC_ENET1_MDC 0x3
+ MX8MM_IOMUXC_ENET_MDIO_ENET1_MDIO 0x3
+ MX8MM_IOMUXC_ENET_TD3_ENET1_RGMII_TD3 0x1f
+ MX8MM_IOMUXC_ENET_TD2_ENET1_RGMII_TD2 0x1f
+ MX8MM_IOMUXC_ENET_TD1_ENET1_RGMII_TD1 0x1f
+ MX8MM_IOMUXC_ENET_TD0_ENET1_RGMII_TD0 0x1f
+ MX8MM_IOMUXC_ENET_RD3_ENET1_RGMII_RD3 0x91
+ MX8MM_IOMUXC_ENET_RD2_ENET1_RGMII_RD2 0x91
+ MX8MM_IOMUXC_ENET_RD1_ENET1_RGMII_RD1 0x91
+ MX8MM_IOMUXC_ENET_RD0_ENET1_RGMII_RD0 0x91
+ MX8MM_IOMUXC_ENET_TXC_ENET1_RGMII_TXC 0x1f
+ MX8MM_IOMUXC_ENET_RXC_ENET1_RGMII_RXC 0x91
+ MX8MM_IOMUXC_ENET_RX_CTL_ENET1_RGMII_RX_CTL 0x91
+ MX8MM_IOMUXC_ENET_TX_CTL_ENET1_RGMII_TX_CTL 0x1f
+ MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x19
+ >;
+ };
+
+ pinctrl_fec1_sleep: fec1sleepgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ENET_MDC_GPIO1_IO16 0x120
+ MX8MM_IOMUXC_ENET_MDIO_GPIO1_IO17 0x120
+ MX8MM_IOMUXC_ENET_TD3_GPIO1_IO18 0x120
+ MX8MM_IOMUXC_ENET_TD2_GPIO1_IO19 0x120
+ MX8MM_IOMUXC_ENET_TD1_GPIO1_IO20 0x120
+ MX8MM_IOMUXC_ENET_TD0_GPIO1_IO21 0x120
+ MX8MM_IOMUXC_ENET_RD3_GPIO1_IO29 0x120
+ MX8MM_IOMUXC_ENET_RD2_GPIO1_IO28 0x120
+ MX8MM_IOMUXC_ENET_RD1_GPIO1_IO27 0x120
+ MX8MM_IOMUXC_ENET_RD0_GPIO1_IO26 0x120
+ MX8MM_IOMUXC_ENET_TXC_GPIO1_IO23 0x120
+ MX8MM_IOMUXC_ENET_RXC_GPIO1_IO25 0x120
+ MX8MM_IOMUXC_ENET_RX_CTL_GPIO1_IO24 0x120
+ MX8MM_IOMUXC_ENET_TX_CTL_GPIO1_IO22 0x120
+ MX8MM_IOMUXC_GPIO1_IO09_GPIO1_IO9 0x100
+ >;
+ };
+
+ pinctrl_i2c1: i2c1grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C1_SCL_I2C1_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C1_SDA_I2C1_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c1_gpio: i2c1-gpiogrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C1_SCL_GPIO5_IO14 0x400001c3
+ MX8MM_IOMUXC_I2C1_SDA_GPIO5_IO15 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c3: i2c3grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL 0x400001c3
+ MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA 0x400001c3
+ >;
+ };
+
+ pinctrl_i2c3_gpio: i2c3-gpiogrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_I2C3_SCL_GPIO5_IO18 0x400001c3
+ MX8MM_IOMUXC_I2C3_SDA_GPIO5_IO19 0x400001c3
+ >;
+ };
+
+ pinctrl_pmic: pmicgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_DATA6_GPIO2_IO8 0x140
+ >;
+ };
+
+ pinctrl_reg_eth_phy: regeth-phygrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO07_GPIO1_IO7 0x41
+ >;
+ };
+
+ pinctrl_sai3: sai3grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SAI3_RXFS_SAI3_RX_SYNC 0xd6
+ MX8MM_IOMUXC_SAI3_RXC_SAI3_RX_BCLK 0xd6
+ MX8MM_IOMUXC_SAI3_RXD_SAI3_RX_DATA0 0xd6
+ MX8MM_IOMUXC_SAI3_TXFS_SAI3_TX_SYNC 0xd6
+ MX8MM_IOMUXC_SAI3_TXC_SAI3_TX_BCLK 0xd6
+ MX8MM_IOMUXC_SAI3_TXD_SAI3_TX_DATA0 0xd6
+ MX8MM_IOMUXC_SAI3_MCLK_SAI3_MCLK 0xd6
+ >;
+ };
+
+ pinctrl_uart4: uart4grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_ECSPI2_SCLK_UART4_DCE_RX 0x140
+ MX8MM_IOMUXC_ECSPI2_MOSI_UART4_DCE_TX 0x140
+ MX8MM_IOMUXC_ECSPI2_SS0_UART4_DCE_RTS_B 0x140
+ MX8MM_IOMUXC_ECSPI2_MISO_UART4_DCE_CTS_B 0x140
+ >;
+ };
+
+ pinctrl_usdhc1: usdhc1grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x190
+ MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d0
+ MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d0
+ MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d0
+ MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d0
+ MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d0
+ >;
+ };
+
+ pinctrl_usdhc1_100mhz: usdhc1-100mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x194
+ MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d4
+ MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d4
+ MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d4
+ MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d4
+ MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d4
+ >;
+ };
+
+ pinctrl_usdhc1_200mhz: usdhc1-200mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD1_CLK_USDHC1_CLK 0x196
+ MX8MM_IOMUXC_SD1_CMD_USDHC1_CMD 0x1d6
+ MX8MM_IOMUXC_SD1_DATA0_USDHC1_DATA0 0x1d6
+ MX8MM_IOMUXC_SD1_DATA1_USDHC1_DATA1 0x1d6
+ MX8MM_IOMUXC_SD1_DATA2_USDHC1_DATA2 0x1d6
+ MX8MM_IOMUXC_SD1_DATA3_USDHC1_DATA3 0x1d6
+ >;
+ };
+
+ pinctrl_usdhc3: usdhc3grp {
+ fsl,pins = <
+ MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x190
+ MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d0
+ MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d0
+ MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d0
+ MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d0
+ MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d0
+ MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d0
+ MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d0
+ MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d0
+ MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d0
+ MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x190
+ >;
+ };
+
+ pinctrl_usdhc3_100mhz: usdhc3-100mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x194
+ MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d4
+ MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d4
+ MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d4
+ MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d4
+ MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d4
+ MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d4
+ MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d4
+ MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d4
+ MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d4
+ MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x194
+ >;
+ };
+
+ pinctrl_usdhc3_200mhz: usdhc3-200mhzgrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_NAND_WE_B_USDHC3_CLK 0x196
+ MX8MM_IOMUXC_NAND_WP_B_USDHC3_CMD 0x1d6
+ MX8MM_IOMUXC_NAND_DATA04_USDHC3_DATA0 0x1d6
+ MX8MM_IOMUXC_NAND_DATA05_USDHC3_DATA1 0x1d6
+ MX8MM_IOMUXC_NAND_DATA06_USDHC3_DATA2 0x1d6
+ MX8MM_IOMUXC_NAND_DATA07_USDHC3_DATA3 0x1d6
+ MX8MM_IOMUXC_NAND_RE_B_USDHC3_DATA4 0x1d6
+ MX8MM_IOMUXC_NAND_CE2_B_USDHC3_DATA5 0x1d6
+ MX8MM_IOMUXC_NAND_CE3_B_USDHC3_DATA6 0x1d6
+ MX8MM_IOMUXC_NAND_CLE_USDHC3_DATA7 0x1d6
+ MX8MM_IOMUXC_NAND_CE1_B_USDHC3_STROBE 0x196
+ >;
+ };
+
+ pinctrl_wdog: wdoggrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_GPIO1_IO02_WDOG1_WDOG_B 0xc6
+ >;
+ };
+
+ pinctrl_wifi: wifigrp {
+ fsl,pins = <
+ MX8MM_IOMUXC_SD2_WP_GPIO2_IO20 0x140
+ MX8MM_IOMUXC_SD1_RESET_B_GPIO2_IO10 0xc1
+ >;
+ };
+};
--
2.47.3
^ permalink raw reply related
* [PATCH v1 1/3] dt-bindings: arm: fsl: add Variscite DART-MX8M-MINI Boards
From: Stefano Radaelli @ 2026-06-10 8:58 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Dario Binacchi,
Josua Mayer, Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve
In-Reply-To: <cover.1781024557.git.stefano.r@variscite.com>
From: Stefano Radaelli <stefano.r@variscite.com>
Add DT compatible strings for Variscite DART-MX8MM SoM and Variscite
development carrier Board.
Signed-off-by: Stefano Radaelli <stefano.r@variscite.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 86876311ec59..c942d3d06469 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1064,6 +1064,12 @@ properties:
- const: solidrun,imx8mm-sr-som
- const: fsl,imx8mm
+ - description: Variscite DART-MX8MM based boards
+ items:
+ - const: variscite,var-dart-mx8mm-sonata # Variscite DART-MX8MM on Sonata Development Board
+ - const: variscite,var-dart-mx8mm # Variscite DART-MX8M-MINI SOM
+ - const: fsl,imx8mm
+
- description: Variscite VAR-SOM-MX8MM based boards
items:
- const: variscite,var-som-mx8mm-symphony
--
2.47.3
^ permalink raw reply related
* [PATCH v1 0/3] Add support for Variscite DART-MX8M-MINI and Sonata board
From: Stefano Radaelli @ 2026-06-10 8:58 UTC (permalink / raw)
To: linux-kernel, devicetree, imx, linux-arm-kernel
Cc: pierluigi.p, Stefano Radaelli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, Daniel Baluta, Dario Binacchi,
Josua Mayer, Maud Spierings, Alexander Stein, Ernest Van Hoecke,
Francesco Dolcini, Hugo Villeneuve
This patch series adds support for the Variscite DART-MX8M-MINI
system on module and the Sonata carrier board.
The series includes:
- SOM device tree with on-module peripherals
- Sonata carrier board device tree with board-specific features
The implementation follows the standard SOM + carrier board pattern
where the SOM dtsi contains only peripherals mounted on the module,
while carrier-specific interfaces are enabled in the board dts.
Stefano Radaelli (3):
dt-bindings: arm: fsl: add Variscite DART-MX8M-MINI Boards
arm64: dts: freescale: Add support for Variscite DART-MX8M-MINI
arm64: dts: imx8mm-var-dart: Add support for Variscite Sonata board
.../devicetree/bindings/arm/fsl.yaml | 6 +
arch/arm64/boot/dts/freescale/Makefile | 1 +
.../dts/freescale/imx8mm-var-dart-sonata.dts | 517 ++++++++++++++++
.../boot/dts/freescale/imx8mm-var-dart.dtsi | 559 ++++++++++++++++++
4 files changed, 1083 insertions(+)
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-dart-sonata.dts
create mode 100644 arch/arm64/boot/dts/freescale/imx8mm-var-dart.dtsi
base-commit: 23a7098c710673ce8f245af317903ae46325a694
--
2.47.3
^ permalink raw reply
* [net-next v1 5/6] net: dwmac4: Add NCSI mac speed and duplex setting in NCSI case
From: Minda Chen @ 2026-06-10 7:24 UTC (permalink / raw)
To: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Jose Abreu, Maxime Coquelin, Russell King,
Giuseppe Cavallaro, Alexandre Torgue, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
In-Reply-To: <20260610072420.64699-1-minda.chen@starfivetech.com>
Add dwmac4 mac speed config and duplex setting in NCSI case
because NCSI lack of PHY, will not call stmmac_mac_link_up().
Signed-off-by: Minda Chen <minda.chen@starfivetech.com>
---
drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 15 ++++++++++++++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index c6fcfae27c3d..7db4c5dc1f80 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -46,7 +46,20 @@ static void dwmac4_core_init(struct mac_device_info *hw,
u32 value;
value = readl(ioaddr + GMAC_CONFIG);
- writel(value | GMAC_CORE_INIT, ioaddr + GMAC_CONFIG);
+ if (priv->plat->use_ncsi) {
+ /*
+ * In NCSI case, because lack of PHY, will NOT
+ * set the mac speed config and mac duplex
+ * in stmmac_mac_link_up(). Now set these in
+ * core init function.
+ */
+ value |= GMAC_CORE_INIT;
+ value &= ~priv->hw->link.speed_mask;
+ value |= priv->hw->link.duplex | priv->hw->link.speed100;
+ writel(value, ioaddr + GMAC_CONFIG);
+ } else {
+ writel(value | GMAC_CORE_INIT, ioaddr + GMAC_CONFIG);
+ }
/* Configure LPI 1us counter to number of CSR clock ticks in 1us - 1 */
clk_rate = clk_get_rate(priv->plat->stmmac_clk);
--
2.17.1
^ permalink raw reply related
* [net-next v1 0/6] Add synopsys designware GMAC NCSI support
From: Minda Chen @ 2026-06-10 7:24 UTC (permalink / raw)
To: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Jose Abreu, Maxime Coquelin, Russell King,
Giuseppe Cavallaro, Alexandre Torgue, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev
Cc: linux-kernel, linux-stm32, devicetree, Minda Chen
This patch set is for adding jhb100 GMAC NCSI function.
jhb100 is a Starfive new RISC-V SoC for datacenter BMC (BaseBoard
Managent Controller). Similar with Aspeed 27x0.
jhb100 contains 2 synopsys RMII(RGMII can be use as RMII) interfaces
GMAC, can be use as NCSI GMAC (network controller sideband interface),
do not connect with mdio PHY but connect with host server OCP network
device and share with network port.
The code which calling NCSI netdevice API is similar with
driver/net/ethernet/faraday/ftgmac100.c
The NCSI example:
_________________ _______________
| | | | ___________
| CLK_50M |---------------->| |<--------->| |
| TX_EN |---------------->| |<--------->| |
| TXD0 |---------------->| OCP network|<--------->| RJ45 |
|BMC TXD1 |---------------->| device |<--------->| port |
|RMII CRS_DV |<----------------| |<--------->| |
|port RX_D0 |<----------------| |<--------->| |
| RX_D1 |<----------------| |<--------->|_________|
|_______________| |_____________|
| | | | |
| | | | |
host server
PCIe interface
The jhb100 minimal system upstream is in progress:
https://patchwork.kernel.org/project/linux-riscv/cover/20260508053632.818548-1-changhuang.liang@starfivetech.com/
The patch base net-next (base commit list below)
Minda Chen (6):
dt-bindings: net: dwmac: Add snps,use-ncsi property
net: stmmac: Checking whether priv->phylink if NULL in NCSI case
net: stmmac: Add register NCSI device support
net: stmmac: Add NCSI VLAN setting
net: dwmac4: Add NCSI mac speed and duplex setting in NCSI case
net: stmmac: ethtool: Do NOT call phylink function in NCSI mode.
.../devicetree/bindings/net/snps,dwmac.yaml | 7 ++
.../net/ethernet/stmicro/stmmac/dwmac4_core.c | 15 ++-
drivers/net/ethernet/stmicro/stmmac/stmmac.h | 1 +
.../ethernet/stmicro/stmmac/stmmac_ethtool.c | 32 +++++-
.../net/ethernet/stmicro/stmmac/stmmac_main.c | 108 +++++++++++++-----
.../ethernet/stmicro/stmmac/stmmac_phylink.h | 106 +++++++++++++++++
.../ethernet/stmicro/stmmac/stmmac_platform.c | 10 +-
include/linux/stmmac.h | 1 +
8 files changed, 246 insertions(+), 34 deletions(-)
create mode 100644 drivers/net/ethernet/stmicro/stmmac/stmmac_phylink.h
base-commit: 903db046d5579bef0ea699eae4b279dd6455fc9f
--
2.17.1
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: ipq5424: Move PHYs and PERST# to Root Port node
From: Konrad Dybcio @ 2026-06-10 8:58 UTC (permalink / raw)
To: Kathiravan Thirumoorthy, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov
In-Reply-To: <20260609-move_perst_to_rp-v2-2-6c731523d08c@oss.qualcomm.com>
On 6/9/26 7:04 PM, Kathiravan Thirumoorthy wrote:
> Follow the new binding style by defining PHYs and PERST# (now RESET#)
> under the Root Port node. Avoid mixing styles and move these properties
> to the RP node.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64: dts: qcom: ipq5332: Move PHYs and PERST# to Root Port node
From: Konrad Dybcio @ 2026-06-10 8:57 UTC (permalink / raw)
To: Kathiravan Thirumoorthy, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Dmitry Baryshkov
In-Reply-To: <20260609-move_perst_to_rp-v2-1-6c731523d08c@oss.qualcomm.com>
On 6/9/26 7:04 PM, Kathiravan Thirumoorthy wrote:
> Follow the new binding style by defining PHYs and PERST# (now RESET#)
> under the Root Port node. Avoid mixing styles and move these properties
> to the RP node.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH v4 4/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
From: William Bright @ 2026-06-10 8:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, William Bright
In-Reply-To: <20260610-imdt-qcs8550-sbc-rfc-v4-0-358e71d606bc@imd-tec.com>
The IMDT QCS8550 SBC is a two-board design from IMD Technologies Ltd
built around the Qualcomm QCS8550 SoC. An IMDT QCS8550 SoM is soldered
onto the IMDT QCS8550 carrier board that supplies VPH_PWR and exposes
the off-module peripherals.
With this DTS, the board can boot to shell with a UFS rootfs with
debugging through uart7. USB and ethernet also are fully functional.
Features enabled are:
- On-board regulators
- uSD
- UART
- UFS
- PCIe0
- PCIe1
- USB (gadget only)
- Ethernet via LAN7430 (PCIe1)
- ADSP, CDSP
Assisted-by: Claude:claude-opus-4.7
Signed-off-by: William Bright <william.bright@imd-tec.com>
---
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts | 392 ++++++++++++++++++++++++++
2 files changed, 393 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile
index 6f33c4e2f09c..26b78cd9127e 100644
--- a/arch/arm64/boot/dts/qcom/Makefile
+++ b/arch/arm64/boot/dts/qcom/Makefile
@@ -190,6 +190,7 @@ qcs8300-ride-el2-dtbs := qcs8300-ride.dtb monaco-el2.dtbo
dtb-$(CONFIG_ARCH_QCOM) += qcs8300-ride-el2.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs8550-aim300-aiot.dtb
+dtb-$(CONFIG_ARCH_QCOM) += qcs8550-imdt-sbc.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride.dtb
dtb-$(CONFIG_ARCH_QCOM) += qcs9100-ride-r3.dtb
diff --git a/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts b/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts
new file mode 100644
index 000000000000..e8afe683c962
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts
@@ -0,0 +1,392 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2026 IMD Technologies Ltd
+ */
+
+/dts-v1/;
+
+#include "qcs8550-imdt-som.dtsi"
+
+/ {
+ model = "IMDT QCS8550 SBC";
+ compatible = "imdt,qcs8550-sbc", "imdt,qcs8550-som",
+ "qcom,qcs8550", "qcom,sm8550";
+ chassis-type = "embedded";
+
+ aliases {
+ serial0 = &uart7;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ /* Enables 5V_PER, 3V3_PER and 1V8_PER rails. These rails
+ * aren't used by anything within the device-tree but are used
+ * for on board logic level conversion and as rails for
+ * pull-ups.
+ */
+ per_pwr: regulator-per-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "per_pwr";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwr_per_en_default>;
+
+ gpio = <&tlmm 142 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ sdhci_2_vqmmc: regulator-sdhci-2-vqmmc {
+ compatible = "regulator-gpio";
+
+ regulator-name = "sdhci_2_vqmmc";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-type = "voltage";
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&sd_vset_default>;
+
+ gpios = <&tlmm 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ gpios-states = <0>;
+ states = <3300000 0>,
+ <1800000 1>;
+
+ startup-delay-us = <10000>;
+ };
+
+ vph_pwr: regulator-vph-pwr {
+ compatible = "regulator-fixed";
+ regulator-name = "vph_pwr";
+ regulator-min-microvolt = <3700000>;
+ regulator-max-microvolt = <3700000>;
+ regulator-always-on;
+ regulator-boot-on;
+ };
+};
+
+&apps_rsc {
+ regulators-0 {
+ vdd-bob1-supply = <&vph_pwr>;
+ vdd-bob2-supply = <&vph_pwr>;
+ };
+
+ regulators-3 {
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ };
+
+ regulators-4 {
+ vdd-s4-supply = <&vph_pwr>;
+ };
+
+ regulators-5 {
+ vdd-s1-supply = <&vph_pwr>;
+ vdd-s2-supply = <&vph_pwr>;
+ vdd-s3-supply = <&vph_pwr>;
+ vdd-s4-supply = <&vph_pwr>;
+ vdd-s5-supply = <&vph_pwr>;
+ vdd-s6-supply = <&vph_pwr>;
+ };
+};
+
+&gpi_dma1 {
+ status = "okay";
+};
+
+&gpu {
+ status = "okay";
+};
+
+&gpu_zap_shader {
+ firmware-name = "qcom/sm8550/a740_zap.mbn";
+ /* Zap shader doesn't load so is disabled */
+ status = "disabled";
+};
+
+&i2c_master_hub_0 {
+ status = "okay";
+};
+
+&i2c_hub_2 {
+ clock-frequency = <400000>;
+ status = "okay";
+
+ ptn3222: redriver@43 {
+ compatible = "nxp,ptn3222";
+ reg = <0x43>;
+ #phy-cells = <0>;
+
+ vdd1v8-supply = <&vreg_l15b_1p8>;
+ vdd3v3-supply = <&vreg_l5b_3p1>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&eusb2_repeater_reset_default>;
+
+ reset-gpios = <&pm8550vs_d_gpios 4 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&ipa {
+ qcom,gsi-loader = "self";
+ memory-region = <&ipa_fw_mem>;
+ firmware-name = "qcom/sm8550/ipa_fws.mbn";
+ status = "okay";
+};
+
+&iris {
+ status = "okay";
+};
+
+&pcie0 {
+ wake-gpios = <&tlmm 96 GPIO_ACTIVE_HIGH>;
+ perst-gpios = <&tlmm 94 GPIO_ACTIVE_LOW>;
+
+ /*
+ * pcie0 hosts the M.2 Key-E slot. Apply the SDIO
+ * reset de-assert here so any module's chip enable is settled
+ * before pcie0 trains its link.
+ */
+ pinctrl-0 = <&pcie0_default_state>, <&m2e_sdio_resetn_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie0_phy {
+ vdda-phy-supply = <&vreg_l1e_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&pcie1 {
+ wake-gpios = <&tlmm 99 GPIO_ACTIVE_HIGH>;
+ perst-gpios = <&tlmm 97 GPIO_ACTIVE_LOW>;
+
+ /*
+ * pcie_switch_sel_default and gbe_reset_default are board-init
+ * lines that must be stable before pcie1 trains its link: the
+ * PCIe switch needs its mode-select strap settled, and the
+ * downstream LAN743x must be out of reset to enumerate.
+ * Applying them via pcie1's pinctrl-0 fires them during
+ * qcom-pcie probe, before bus enumeration.
+ */
+ pinctrl-0 = <&pcie1_default_state>,
+ <&pcie_switch_sel_default>,
+ <&gbe_reset_default>;
+ pinctrl-names = "default";
+
+ status = "okay";
+};
+
+&pcie1_phy {
+ vdda-phy-supply = <&vreg_l3c_0p9>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+ vdda-qref-supply = <&vreg_l1e_0p88>;
+
+ status = "okay";
+};
+
+&pm8550_gpios {
+ sd_card_detect_default: sd-card-detect-default-state {
+ pins = "gpio12";
+ function = "normal";
+ input-enable;
+ output-disable;
+ bias-disable;
+ power-source = <1>; /* 1.8 V */
+ };
+};
+
+&pm8550vs_d_gpios {
+ eusb2_repeater_reset_default: eusb2-repeater-reset-default-state {
+ pins = "gpio4";
+ function = "normal";
+
+ input-enable;
+ output-enable;
+ bias-disable;
+
+ drive-push-pull;
+ power-source = <1>; /* 1.8V */
+ qcom,drive-strength = <3>;
+ };
+};
+
+&pon_pwrkey {
+ status = "okay";
+};
+
+&pon_resin {
+ linux,code = <KEY_VOLUMEDOWN>;
+
+ status = "okay";
+};
+
+&qupv3_id_0 {
+ status = "okay";
+};
+
+&qupv3_id_1 {
+ status = "okay";
+};
+
+&remoteproc_adsp {
+ firmware-name = "qcom/sm8550/adsp.mbn",
+ "qcom/sm8550/adsp_dtb.mbn";
+ status = "okay";
+};
+
+&remoteproc_cdsp {
+ firmware-name = "qcom/sm8550/cdsp.mbn",
+ "qcom/sm8550/cdsp_dtb.mbn";
+ status = "okay";
+};
+
+&sdc2_default {
+ clk-pins {
+ drive-strength = <16>;
+ };
+
+ cmd-pins {
+ /delete-property/ bias-pull-up;
+ bias-disable;
+ drive-strength = <16>;
+ };
+
+ data-pins {
+ /delete-property/ bias-pull-up;
+ bias-disable;
+ drive-strength = <16>;
+ };
+};
+
+&sdhc_2 {
+ cd-gpios = <&pm8550_gpios 12 GPIO_ACTIVE_LOW>;
+
+ pinctrl-0 = <&sdc2_default>, <&sd_card_detect_default>;
+ pinctrl-1 = <&sdc2_default>, <&sd_card_detect_default>;
+ pinctrl-names = "default", "sleep";
+
+ vqmmc-supply = <&sdhci_2_vqmmc>;
+
+ bus-width = <4>;
+ no-sdio;
+ no-mmc;
+
+ status = "okay";
+};
+
+&tlmm {
+ /* Reserved I/Os for NFC */
+ gpio-reserved-ranges = <32 8>;
+
+ pwr_per_en_default: pwr-per-en-default-state {
+ pwr-per-en-pins {
+ pins = "gpio142";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+
+ sd_vset_default: sd-vset-default-state {
+ sd-vset-pins {
+ pins = "gpio4";
+ function = "gpio";
+ drive-strength = <16>;
+ bias-disable;
+ };
+ };
+
+ /*
+ * Drive LAN743x reset high (de-asserted) when pcie1 probes,
+ * so the PHY enumerates on the bus.
+ */
+ gbe_reset_default: gbe-reset-default-state {
+ pins = "gpio138";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ /*
+ * We drive this GPIO physically high on the M2 Key-E connector
+ * to make sure the module is enabled. An M2 Key-E module could
+ * be using this pin as a chip enable.
+ */
+ m2e_sdio_resetn_default: m2e-sdio-resetn-default-state {
+ pins = "gpio41";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-high;
+ };
+
+ /* Force the on-board PCIe switch to select the GbE upstream
+ * port.
+ */
+ pcie_switch_sel_default: pcie-switch-sel-default-state {
+ pins = "gpio16";
+ function = "gpio";
+ drive-strength = <2>;
+ bias-disable;
+ output-low;
+ };
+};
+
+&uart7 {
+ status = "okay";
+};
+
+&ufs_mem_hc {
+ reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>;
+
+ vcc-supply = <&vreg_l17b_2p5>;
+ vcc-max-microamp = <1300000>;
+ vccq-supply = <&vreg_l1g_1p2>;
+ vccq-max-microamp = <1200000>;
+ vdd-hba-supply = <&vreg_l3g_1p2>;
+
+ status = "okay";
+};
+
+&ufs_mem_phy {
+ vdda-phy-supply = <&vreg_l1d_0p88>;
+ vdda-pll-supply = <&vreg_l3e_1p2>;
+
+ status = "okay";
+};
+
+&usb_1 {
+ /delete-property/ usb-role-switch;
+ dr_mode = "peripheral";
+
+ status = "okay";
+};
+
+&usb_1_hsphy {
+ vdd-supply = <&vreg_l1e_0p88>;
+ vdda12-supply = <&vreg_l3e_1p2>;
+
+ phys = <&ptn3222>;
+
+ status = "okay";
+};
+
+&usb_dp_qmpphy {
+ vdda-phy-supply = <&vreg_l3e_1p2>;
+ vdda-pll-supply = <&vreg_l3f_0p88>;
+
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 3/4] arm64: dts: qcom: Add IMDT QCS8550 SoM
From: William Bright @ 2026-06-10 8:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, William Bright
In-Reply-To: <20260610-imdt-qcs8550-sbc-rfc-v4-0-358e71d606bc@imd-tec.com>
The IMDT QCS8550 SoM is a System-on-Module from IMD Technologies Ltd
built around the Qualcomm QCS8550 SoC. It is intended to be soldered
onto a carrier board that supplies VPH_PWR and exposes the off-module
peripherals.
Add qcs8550-imdt-som.dtsi describing the SoM's PMICs (PM8550, PM8550VE,
PM8550VS, PMK8550) and the apps_rsc PMIC outputs. Compared to other
SM8550/QCS8550 boards, this SoM excludes the PM8550B charger PMIC.
Assisted-by: Claude:claude-opus-4.7
Signed-off-by: William Bright <william.bright@imd-tec.com>
---
arch/arm64/boot/dts/qcom/qcs8550-imdt-som.dtsi | 319 +++++++++++++++++++++++++
1 file changed, 319 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/qcs8550-imdt-som.dtsi b/arch/arm64/boot/dts/qcom/qcs8550-imdt-som.dtsi
new file mode 100644
index 000000000000..816cbd254dea
--- /dev/null
+++ b/arch/arm64/boot/dts/qcom/qcs8550-imdt-som.dtsi
@@ -0,0 +1,319 @@
+// SPDX-License-Identifier: BSD-3-Clause
+/*
+ * Copyright (c) 2026 IMD Technologies Ltd
+ */
+
+#include <dt-bindings/regulator/qcom,rpmh-regulator.h>
+#include "qcs8550.dtsi"
+#include "pm8550.dtsi"
+#define PMK8550VE_SID 5
+#include "pm8550ve.dtsi"
+#include "pm8550vs.dtsi"
+#include "pmk8550.dtsi"
+
+&apps_rsc {
+ regulators-0 {
+ compatible = "qcom,pm8550-rpmh-regulators";
+ qcom,pmic-id = "b";
+
+ vdd-l1-l4-l10-supply = <&vreg_s6g_1p86>;
+ vdd-l2-l13-l14-supply = <&vreg_bob1>;
+ vdd-l3-supply = <&vreg_s4g_1p25>;
+ vdd-l5-l16-supply = <&vreg_bob1>;
+ vdd-l6-l7-supply = <&vreg_bob1>;
+ vdd-l8-l9-supply = <&vreg_bob1>;
+ vdd-l11-supply = <&vreg_s4g_1p25>;
+ vdd-l12-supply = <&vreg_s6g_1p86>;
+ vdd-l15-supply = <&vreg_s6g_1p86>;
+ vdd-l17-supply = <&vreg_bob2>;
+
+ /*
+ * PMIC outputs whose testpoints lack capacitors are
+ * omitted to prevent accidental use:
+ * L1B_1P8, L4B_1P8, L6B_1P8, L7B_1P8, L8B_1P8,
+ * L13B_3P0, L14B_3P2.
+ * Other outputs are unused.
+ */
+ vreg_bob1: bob1 {
+ regulator-name = "vreg_bob1";
+ regulator-min-microvolt = <3296000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_bob2: bob2 {
+ regulator-name = "vreg_bob2";
+ regulator-min-microvolt = <2720000>;
+ regulator-max-microvolt = <3960000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l5b_3p1: ldo5 {
+ regulator-name = "vreg_l5b_3p1";
+ regulator-min-microvolt = <3104000>;
+ regulator-max-microvolt = <3104000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l15b_1p8: ldo15 {
+ regulator-name = "vreg_l15b_1p8";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l17b_2p5: ldo17 {
+ regulator-name = "vreg_l17b_2p5";
+ regulator-min-microvolt = <2504000>;
+ regulator-max-microvolt = <2504000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-1 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "c";
+
+ vdd-l1-supply = <&vreg_s4g_1p25>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4e_0p95>;
+
+ vreg_l3c_0p9: ldo3 {
+ regulator-name = "vreg_l3c_0p9";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-2 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "d";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4e_0p95>;
+
+ vreg_l1d_0p88: ldo1 {
+ regulator-name = "vreg_l1d_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <920000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ /* ldo2 supplies SM8550 VDD_LPI_MX */
+ };
+
+ regulators-3 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "e";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4g_1p25>;
+
+ vreg_s4e_0p95: smps4 {
+ regulator-name = "vreg_s4e_0p95";
+ regulator-min-microvolt = <904000>;
+ regulator-max-microvolt = <984000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5e_1p08: smps5 {
+ regulator-name = "vreg_s5e_1p08";
+ regulator-min-microvolt = <1080000>;
+ regulator-max-microvolt = <1120000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1e_0p88: ldo1 {
+ regulator-name = "vreg_l1e_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <880000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2e_0p9: ldo2 {
+ regulator-name = "vreg_l2e_0p9";
+ regulator-min-microvolt = <904000>;
+ regulator-max-microvolt = <970000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3e_1p2: ldo3 {
+ regulator-name = "vreg_l3e_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-4 {
+ compatible = "qcom,pm8550ve-rpmh-regulators";
+ qcom,pmic-id = "f";
+
+ vdd-l1-supply = <&vreg_s4e_0p95>;
+ vdd-l2-supply = <&vreg_s4e_0p95>;
+ vdd-l3-supply = <&vreg_s4e_0p95>;
+
+ vreg_s4f_0p5: smps4 {
+ regulator-name = "vreg_s4f_0p5";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <700000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1f_0p9: ldo1 {
+ regulator-name = "vreg_l1f_0p9";
+ regulator-min-microvolt = <912000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l2f_0p88: ldo2 {
+ regulator-name = "vreg_l2f_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3f_0p88: ldo3 {
+ regulator-name = "vreg_l3f_0p88";
+ regulator-min-microvolt = <880000>;
+ regulator-max-microvolt = <912000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+
+ regulators-5 {
+ compatible = "qcom,pm8550vs-rpmh-regulators";
+ qcom,pmic-id = "g";
+
+ vdd-l1-supply = <&vreg_s4g_1p25>;
+ vdd-l2-supply = <&vreg_s4g_1p25>;
+ vdd-l3-supply = <&vreg_s4g_1p25>;
+
+ vreg_s1g_1p25: smps1 {
+ regulator-name = "vreg_s1g_1p25";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1300000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s2g_0p85: smps2 {
+ regulator-name = "vreg_s2g_0p85";
+ regulator-min-microvolt = <800000>;
+ regulator-max-microvolt = <1000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s3g_0p8: smps3 {
+ regulator-name = "vreg_s3g_0p8";
+ regulator-min-microvolt = <300000>;
+ regulator-max-microvolt = <1004000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s4g_1p25: smps4 {
+ regulator-name = "vreg_s4g_1p25";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1352000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s5g_0p85: smps5 {
+ regulator-name = "vreg_s5g_0p85";
+ regulator-min-microvolt = <500000>;
+ regulator-max-microvolt = <1004000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_s6g_1p86: smps6 {
+ regulator-name = "vreg_s6g_1p86";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <2000000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l1g_1p2: ldo1 {
+ regulator-name = "vreg_l1g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+
+ vreg_l3g_1p2: ldo3 {
+ regulator-name = "vreg_l3g_1p2";
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1200000>;
+ regulator-initial-mode = <RPMH_REGULATOR_MODE_HPM>;
+ regulator-allow-set-load;
+ regulator-allowed-modes = <RPMH_REGULATOR_MODE_LPM
+ RPMH_REGULATOR_MODE_HPM>;
+ };
+ };
+};
+
+&pm8550vs_c {
+ status = "okay";
+};
+
+&pm8550vs_d {
+ status = "okay";
+};
+
+&pm8550vs_d_gpios {
+ status = "okay";
+};
+
+&pm8550vs_e {
+ status = "okay";
+};
+
+&pm8550vs_g {
+ status = "okay";
+};
+
+&sleep_clk {
+ clock-frequency = <32764>;
+};
+
+&xo_board {
+ clock-frequency = <76800000>;
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/4] dt-bindings: vendor-prefixes: Add IMDT
From: William Bright @ 2026-06-10 8:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, William Bright
In-Reply-To: <20260610-imdt-qcs8550-sbc-rfc-v4-0-358e71d606bc@imd-tec.com>
Add IMDT (IMD Technologies Ltd) to the vendor prefixes list.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: William Bright <william.bright@imd-tec.com>
---
Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml
index 28784d66ae7b..1484442fa0d9 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.yaml
+++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml
@@ -783,6 +783,8 @@ patternProperties:
description: ILI Technology Corporation (ILITEK)
"^imagis,.*":
description: Imagis Technologies Co., Ltd.
+ "^imdt,.*":
+ description: IMD Technologies Ltd.
"^img,.*":
description: Imagination Technologies Ltd.
"^imi,.*":
--
2.43.0
^ permalink raw reply related
* [PATCH v4 2/4] dt-bindings: arm: qcom: Document IMDT QCS8550 SBC/SoM
From: William Bright @ 2026-06-10 8:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, William Bright
In-Reply-To: <20260610-imdt-qcs8550-sbc-rfc-v4-0-358e71d606bc@imd-tec.com>
Document the IMDT QCS8550 SBC which consists of an IMDT QCS8550 SoM
soldered onto an IMDT QCS8550 carrier board.
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: William Bright <william.bright@imd-tec.com>
---
Documentation/devicetree/bindings/arm/qcom.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml
index 50cc18a6ec5e..ccd7b478e5c9 100644
--- a/Documentation/devicetree/bindings/arm/qcom.yaml
+++ b/Documentation/devicetree/bindings/arm/qcom.yaml
@@ -1105,6 +1105,13 @@ properties:
- sony,pdx234
- const: qcom,sm8550
+ - items:
+ - enum:
+ - imdt,qcs8550-sbc
+ - const: imdt,qcs8550-som
+ - const: qcom,qcs8550
+ - const: qcom,sm8550
+
- items:
- enum:
- qcom,qcs8550-aim300-aiot
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/4] arm64: dts: qcom: Add IMDT QCS8550 SBC
From: William Bright @ 2026-06-10 8:57 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson,
Konrad Dybcio
Cc: devicetree, linux-kernel, linux-arm-msm, William Bright
This patch series adds DT support for the IMD Technologies Ltd (IMDT)
QCS8550 SBC and corresponding SoM. The SBC DTS supports the following
hardware on the SBC:
- Gigabit Ethernet (using a Microchip LAN7430 behind the on-board PCIe
switch on PCIE1)
- USB3 as gadget mode only (No DP alt-mode and flip detection support)
- SD card (SDHC2)
- Regulators
- M.2 Key-E (PCIE0) The SoM DTSI supports the following hardware:
- PM8550 PMICs (similar to the SM8550-HDK)
- QCS8550 and UFS
The IMDT QCS8550 SBC hardware is capable of the following but support is
not included in this patch series:
- USB3 flip detection
- 8 MIPI CSI2 cameras are supported using 8 IAS connectors
- MIPI DSI Displays via a DSI/I2C connector
- Microphone input
- Speaker output
- Fan control
- RS232
- M.2 Key-B (also on PCIE1, selected by toggling the on-board PCIe
switch away from the LAN7430 upstream port)
- Wi-Fi and Bluetooth via SDHC4/UART14 using an NXP-IW416 (SDHC4 patch
[1] is awaiting review)
The DTS files were written using the SM8550-HDK as an initial starting
point with patches ported from downstream [2].
Claude Opus 4.7 was used for formatting and reviewing the device trees
against other QCS/SM8550 boards.
Patch 1 adds the IMDT vendor prefix
Patch 2 adds DT bindings for the SoM and SBC
Patch 3 adds the SoM DTSI
Patch 4 adds the SBC DTS
[1] https://lore.kernel.org/all/20260427-sm8550-sdhc4-support-v2-1-a4241f43ecd5@imd-tec.com
[2] https://github.com/imd-tec/meta-imdt-qcom/tree/kirkstone/patches/msm-kernel-devicetree/files
Signed-off-by: William Bright <william.bright@imd-tec.com>
---
Changes in v4:
- No code changes.
- Collected Rob's Acked-by tags on patches 1 and 2.
- Resubmitting due to inactivity on v3.
- Link to v3: https://patch.msgid.link/20260507-imdt-qcs8550-sbc-rfc-v3-0-47d3d3372b33@imd-tec.com
Changes in v3:
- Dropped backlight node since it's unused.
- Dropped regulators which are dead (no usage or not gpio controllable
whilst also not strictly required by a DT node).
- Dropped SBC modem remoteproc entry since the modem is fused off on the
qcs8550.
- Reformatted commit bodies and DTS comments.
- Replaced open-drain properties with bias-disable due to open-drain not
being supported by the tlmm.
- Dropped tlmm entries which are unused.
- Dropped disabling of LPASS codecs as it was unnecessary.
- Dropped bluetooth usage on uart14 and removed references to uart14
since it became unused.
- Patch 2 renamed to "dt-bindings: arm: qcom: Add IMDT QCS8550 SBC/SoM"
- Patch 2 commit body shortened as it had information already found
within the patch 3 body.
- Link to v2: https://patch.msgid.link/20260505-imdt-qcs8550-sbc-rfc-v2-0-b4767d0dd421@imd-tec.com
Changes in v2:
- Patch 1 relocated to be above qcs8550-aim300-aiot instead of below
- Split the SoM and SBC DT changes into two patches, with patch
3 adding the SoM DTSI and patch 4 adding the SBC DTS.
- Dropped the SDHC4 node in patch 4 to focus on the core
SoM and SBC device trees.
This allows the primary hardware support to progress through
review while waiting for feedback for [1].
- Link to v1: https://patch.msgid.link/20260430-imdt-qcs8550-sbc-rfc-v1-0-4d2b6675eaa3@imd-tec.com
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
To: Bjorn Andersson <andersson@kernel.org>
To: Konrad Dybcio <konradybcio@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-msm@vger.kernel.org
---
William Bright (4):
dt-bindings: vendor-prefixes: Add IMDT
dt-bindings: arm: qcom: Document IMDT QCS8550 SBC/SoM
arm64: dts: qcom: Add IMDT QCS8550 SoM
arm64: dts: qcom: Add IMDT QCS8550 SBC
Documentation/devicetree/bindings/arm/qcom.yaml | 7 +
.../devicetree/bindings/vendor-prefixes.yaml | 2 +
arch/arm64/boot/dts/qcom/Makefile | 1 +
arch/arm64/boot/dts/qcom/qcs8550-imdt-sbc.dts | 392 +++++++++++++++++++++
arch/arm64/boot/dts/qcom/qcs8550-imdt-som.dtsi | 319 +++++++++++++++++
5 files changed, 721 insertions(+)
---
base-commit: 8a4062d204752e0d66a1e7e1a2f8834571a8d40f
change-id: 20260430-imdt-qcs8550-sbc-rfc-4e7cbfbcadd8
Best regards,
--
William Bright <william.bright@imd-tec.com>
^ permalink raw reply
* Re: [PATCH v2 02/16] device property: Add fwnode_graph_get_next_port_endpoint()
From: sashiko-bot @ 2026-06-10 8:57 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260610084053.2059858-3-wenst@chromium.org>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues:
- [Low] The local variable `ep` is declared but never used in `fwnode_graph_get_next_port_endpoint()`.
Pre-existing issues:
- [High] Preexisting Use-After-Free, Double-Free, Memory Leak, and Infinite Loop in `fwnode_get_next_child_node()` when crossing from primary to secondary fwnodes.
--
commit ef024cc56635ec6ba836569acc9c332f8f2249dc
Author: Chen-Yu Tsai <wenst@chromium.org>
device property: Add fwnode_graph_get_next_port_endpoint()
This commit introduces fwnode_graph_get_next_port_endpoint(), a new helper
function that allows consumers to find endpoint nodes under a given port
firmware node. It iterates over the child nodes of the port, checking if
their name matches "endpoint", and returns the matching node.
> diff --git a/drivers/base/property.c b/drivers/base/property.c
> index 8cbf33f3a9428..badb49ac3d8a4 100644
> --- a/drivers/base/property.c
> +++ b/drivers/base/property.c
[ ... ]
> @@ -1099,6 +1099,39 @@ int fwnode_irq_get_byname(const struct fwnode_handle *fwnode, const char *name)
> }
> EXPORT_SYMBOL(fwnode_irq_get_byname);
>
> +/**
> + * fwnode_graph_get_next_port_endpoint - Get next endpoint firmware node in port
> + * @port: Pointer to the target port firmware node
> + * @prev: Previous endpoint node or %NULL to get the first
> + *
> + * The caller is responsible for calling fwnode_handle_put() on the returned
> + * fwnode pointer. Note that this function also puts a reference to @prev
> + * unconditionally.
> + *
> + * Return: an endpoint firmware node pointer or %NULL if no more endpoints
> + * are available.
> + */
> +struct fwnode_handle *fwnode_graph_get_next_port_endpoint(const struct fwnode_handle *port,
> + struct fwnode_handle *prev)
> +{
> + struct fwnode_handle *ep;
[Severity: Low]
Are there plans to use this local variable later? It appears to be declared
here but never used, which could cause a compiler warning.
> +
> + while (1) {
> + prev = fwnode_get_next_child_node(port, prev);
[Severity: High]
This is a pre-existing issue, but does calling fwnode_get_next_child_node()
here expose a use-after-free and double-free when crossing from primary to
secondary fwnodes?
If a fwnode has both primary (OF) and secondary (swnode) children:
1. When reaching the end of the primary OF children,
of_fwnode_get_next_child_node() drops the reference to the last OF child
and returns NULL.
2. fwnode_get_next_child_node() then delegates to the secondary ops
(software_node_get_next_child), passing the exact same child pointer.
Since the OF node was already put, the secondary ops access freed memory
when checking if the child is a software node, causing a use-after-free.
3. software_node_get_next_child() then unconditionally calls
fwnode_handle_put(child), triggering a double-free.
4. It then returns the first secondary software node. On the next iteration,
the caller passes this swnode back.
The primary OF ops evaluate to_of_node(swnode) as NULL, which causes
of_get_next_available_child() to restart iteration and return the first
OF child again. It also fails to put the swnode, causing a memory leak.
Could this create an infinite loop alternating between the first OF child
and the first software node, repeatedly triggering the use-after-free and
double-free on every cycle?
> + if (!prev)
> + break;
> +
> + if (WARN(!fwnode_name_eq(prev, "endpoint"),
> + "non endpoint node is used (%pfw)", prev))
> + continue;
> +
> + break;
> + }
> +
> + return prev;
> +}
> +EXPORT_SYMBOL_GPL(fwnode_graph_get_next_port_endpoint);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610084053.2059858-1-wenst@chromium.org?part=2
^ permalink raw reply
* Re: [PATCH v2 05/16] usb: hub: Associate port@ fwnode with USB port device
From: sashiko-bot @ 2026-06-10 8:56 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260610084053.2059858-6-wenst@chromium.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Leaked firmware node reference obtained from fwnode_graph_get_port_by_id().
--
commit d665d488ed337df469077f70e021bbabc2b8ac61
Author: Chen-Yu Tsai <wenst@chromium.org>
usb: hub: Associate port@ fwnode with USB port device
When a USB hub port is connected to a connector in a firmware node
graph, the port itself has a node in the graph. This commit associates
the port's firmware node with the USB port's device. This is used in
later changes for the M.2 slot power sequencing provider to match
against the requesting port.
> diff --git a/drivers/usb/core/port.c b/drivers/usb/core/port.c
> index b1364f0c384ce..1846eb1206a4d 100644
> --- a/drivers/usb/core/port.c
> +++ b/drivers/usb/core/port.c
> @@ -780,6 +780,8 @@ int usb_hub_create_port_device(struct usb_hub *hub, int port1)
> port_dev->dev.driver = &usb_port_driver;
> dev_set_name(&port_dev->dev, "%s-port%d", dev_name(&hub->hdev->dev),
> port1);
> + device_set_node(&port_dev->dev,
> + fwnode_graph_get_port_by_id(dev_fwnode(&hdev->dev), port1));
[Severity: Medium]
Does this code leak the fwnode reference? fwnode_graph_get_port_by_id()
returns a firmware node with its reference count incremented, and the caller
is expected to drop it using fwnode_handle_put() when it is no longer
needed.
device_set_node() merely assigns the fwnode to the device without taking
ownership of the reference count. If device_register() fails:
drivers/usb/core/port.c:usb_hub_create_port_device() {
...
retval = device_register(&port_dev->dev);
if (retval) {
put_device(&port_dev->dev);
return retval;
}
...
}
put_device() eventually calls usb_port_device_release(), which frees the
device memory but does not release the fwnode:
drivers/usb/core/port.c:usb_port_device_release() {
struct usb_port *port_dev = to_usb_port(dev);
kfree(port_dev->req);
kfree(port_dev);
}
The reference also appears to be permanently leaked upon normal device
removal via usb_hub_remove_port_device(), since usb_port_device_release()
lacks a corresponding fwnode_handle_put(dev_fwnode(dev)) call.
> mutex_init(&port_dev->status_lock);
> retval = device_register(&port_dev->dev);
> if (retval) {
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610084053.2059858-1-wenst@chromium.org?part=5
^ permalink raw reply
* Re: [PATCH 2/2] dt-bindings: crypto: qcom,inline-crypto-engine: Document Maili ICE
From: Krzysztof Kozlowski @ 2026-06-10 8:55 UTC (permalink / raw)
To: Jingyi Wang
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson, aiqun.yu,
tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260609-maili-crypto-v1-2-0f577df56a61@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 02:08:57AM -0700, Jingyi Wang wrote:
> The Inline Crypto Engine found on Maili SoC is compatible with the common
> baseline IP 'qcom,inline-crypto-engine'. Hence, document the compatible as
> such.
>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> index db895c50e2d2..c9489f6b8081 100644
> --- a/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> +++ b/Documentation/devicetree/bindings/crypto/qcom,inline-crypto-engine.yaml
> @@ -16,6 +16,7 @@ properties:
> - qcom,eliza-inline-crypto-engine
> - qcom,hawi-inline-crypto-engine
> - qcom,kaanapali-inline-crypto-engine
> + - qcom,maili-inline-crypto-engine
Why clocks are flexible?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: qcom: ipq5018: Correct CMN PLL reference clock rate
From: Konrad Dybcio @ 2026-06-10 8:55 UTC (permalink / raw)
To: Jie Luo, Kathiravan Thirumoorthy, george.moussalem,
Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <91117dd7-91e1-4c1a-934e-1b6717698377@oss.qualcomm.com>
On 6/10/26 5:10 AM, Jie Luo wrote:
>
>
> On 6/10/2026 12:59 AM, Kathiravan Thirumoorthy wrote:
>>
>> On 6/9/2026 8:42 PM, Konrad Dybcio wrote:
>>> On 5/21/26 9:55 AM, George Moussalem via B4 Relay wrote:
>>>> From: George Moussalem <george.moussalem@outlook.com>
>>>>
>>>> The correct CMN PLL reference clock rate for IPQ5018 is 4.8 GHz.
>>>>
>>>> The CMN PLL driver did not account for the ref clock divider which is 2
>>>> for IPQ5018. Therefore, the computed rate was twice the actual output.
>>>>
>>>> With the driver now accounting for the CMN PLL reference clock
>>>> divider (commit: 88c543fff756), set the correct reference clock rate.
>>>>
>>>> Fixes: c006b249c544 ("arm64: dts: ipq5018: Add CMN PLL node")
>>>> Signed-off-by: George Moussalem <george.moussalem@outlook.com>
>>>> ---
>>>> Changes in v2:
>>>> - Removed line break in commit message between Fixes and SOB tags
>>>> - Link to v1: https://patch.msgid.link/20260519-ipq5018-cmn-pll-rate-
>>>> fix-v1-1-3c83a173c27f@outlook.com
>>>> ---
>>> I have no reference for this, but I trust you.. maybe +Kathiravan
>>> could double-check
>>
>> Thanks Konrad. As per the HW doc and the commit 88c543fff756 ("clk:
>> qcom: cmnpll: Account for reference clock divider"), default ref clock
>> divider is 1 in IPQ5018.
>>
>> @Jie, Can you help here?
>>
>
> Hello Konrad, Kathiravan,
> As confirmed on the IPQ5018 RDP board, the ref clock divider is set to 2.
Thanks
Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2 03/16] power: sequencing: Change CONFIG_POWER_SEQUENCING to bool
From: sashiko-bot @ 2026-06-10 8:55 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: robh, conor+dt, devicetree
In-Reply-To: <20260610084053.2059858-4-wenst@chromium.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The commit message incorrectly justifies changing CONFIG_POWER_SEQUENCING to bool by falsely claiming that USB support is a boolean option, which unnecessarily prevents building the power sequencing subsystem as a module.
--
commit 80f4a7ca3dbefd1dc2ae2274d131e8b5461c5c66
Author: Chen-Yu Tsai <wenst@chromium.org>
power: sequencing: Change CONFIG_POWER_SEQUENCING to bool
This commit changes the POWER_SEQUENCING Kconfig option from tristate
to bool, citing that USB support cannot be built as a module.
> USB support, including the core and hub driver, is bool, no modules. To
> be able to use the power sequencing API in the USB core, the former must
> also be bool to avoid the latter being built as a module.
[Severity: Medium]
Is this description of USB support accurate? Looking at drivers/usb/Kconfig,
CONFIG_USB is actually defined as a tristate:
config USB
tristate "Support for Host-side USB"
Since the USB core can indeed be built as a loadable module, does
POWER_SEQUENCING strictly need to be restricted to bool here? Could standard
Kconfig patterns like depends on POWER_SEQUENCING || POWER_SEQUENCING=n be
used instead if linkage dependencies need to be resolved?
> diff --git a/drivers/power/sequencing/Kconfig b/drivers/power/sequencing/Kconfig
> index 1c5f5820f5b76..27448fba9dc5d 100644
> --- a/drivers/power/sequencing/Kconfig
> +++ b/drivers/power/sequencing/Kconfig
> @@ -1,7 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0-only
>
> menuconfig POWER_SEQUENCING
> - tristate "Power Sequencing support"
> + bool "Power Sequencing support"
[Severity: Medium]
Given that CONFIG_USB is a tristate, does this change unnecessarily prevent
the power sequencing subsystem from being built as a module?
> help
> Say Y here to enable the Power Sequencing subsystem.
>
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260610084053.2059858-1-wenst@chromium.org?part=3
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: crypto: qcom,prng: Document Maili TRNG
From: Krzysztof Kozlowski @ 2026-06-10 8:55 UTC (permalink / raw)
To: Jingyi Wang
Cc: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Bjorn Andersson, aiqun.yu,
tingwei.zhang, trilok.soni, yijie.yang, linux-arm-msm,
linux-crypto, devicetree, linux-kernel
In-Reply-To: <20260609-maili-crypto-v1-1-0f577df56a61@oss.qualcomm.com>
On Tue, Jun 09, 2026 at 02:08:56AM -0700, Jingyi Wang wrote:
> Maili SoC has the True Random Number Generator (TRNG) which is compatible
> with the baseline IP "qcom,trng". Hence, document the compatible as such.
>
> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/crypto/qcom,prng.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox