* [PATCH V3 0/8] Add PCIe M.2 Key E connector support for NXP i.MX boards
From: Sherry Sun (OSS) @ 2026-06-26 2:31 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
From: Sherry Sun <sherry.sun@nxp.com>
This series adds support for NXP Wi-Fi/BT combo chips (88W9098, AW693)
inserted into PCIe M.2 Key E connectors on several i.MX EVK/MEK boards.
For M.2 cards that rely on PCIe L2 link state and wake-up mechanisms, the
card must remain powered during suspend. Patch #1 uses the existing
dw_pcie_rp::skip_pwrctrl_off flag to skip power-off during suspend and skip
power-on during the init path.
Also the btnxpuart driver is extended to obtain a pwrseq descriptor via the
OF graph on the UART controller device in patch #3.
Note: Patch #4-8 in this patch set depends on the following [1] and [2]
DTS patches.
[1] https://lore.kernel.org/all/20260616105201.3214395-1-sherry.sun@oss.nxp.com/
[2] https://lore.kernel.org/all/20260520084904.2424253-1-sherry.sun@oss.nxp.com/
---
Changes in V3:
1. Move pci_pwrctrl_create_devices() to imx_pcie_probe() in parch #1,
similar to other regulator_get calls as suggested by Frank.
2. Collected the tags.
Changes in V2:
1. Rebased on top of 7.1.0.
2. Removed the power_off error handling in patch #3 because pwrseq_put()
would call pwrseq_power_off() to automatically clean.
3. Collected the tags.
---
Sherry Sun (8):
PCI: imx6: Add skip_pwrctrl_off flag support
power: sequencing: pcie-m2: Add PCI ID for NXP 88W9098 and AW693
Bluetooth
Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq
arm64: dts: imx8mq-evk: Describe the PCIe M.2 Key E connector
arm64: dts: imx95-19x19-evk: Describe the PCIe M.2 Key E connector
arm64: dts: imx8dxl-evk: Describe the PCIe M.2 Key E connector
arm64: dts: imx8qm-mek: Describe the PCIe M.2 Key E connector
arm64: dts: imx8qxp-mek: Describe the PCIe M.2 Key E connector
arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 56 +++++++++++++-----
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 44 ++++++++++++--
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 58 ++++++++++++++-----
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 54 ++++++++++++-----
.../boot/dts/freescale/imx95-19x19-evk.dts | 55 +++++++++++++-----
drivers/bluetooth/btnxpuart.c | 14 +++++
drivers/pci/controller/dwc/pci-imx6.c | 43 ++++++++------
drivers/power/sequencing/pwrseq-pcie-m2.c | 4 ++
8 files changed, 250 insertions(+), 78 deletions(-)
--
2.50.1
^ permalink raw reply
* [PATCH V3 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Sherry Sun (OSS) @ 2026-06-26 2:31 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
suspend to preserve wakeup capability of the devices and also not to power
on the devices in the init path.
This allows controller power-off to be skipped when some devices(e.g. M.2
cards key E without auxiliary power) required to support PCIe L2 link state
and wake-up mechanisms.
Move pci_pwrctrl_create_devices() to imx_pcie_probe() so that it is only
called once during probe, similar to other regulator_get calls.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
drivers/pci/controller/dwc/pci-imx6.c | 43 ++++++++++++++++-----------
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
index 0fa716d1ed75..0685573fee71 100644
--- a/drivers/pci/controller/dwc/pci-imx6.c
+++ b/drivers/pci/controller/dwc/pci-imx6.c
@@ -1382,16 +1382,12 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
}
}
- ret = pci_pwrctrl_create_devices(dev);
- if (ret) {
- dev_err(dev, "failed to create pwrctrl devices\n");
- goto err_reg_disable;
- }
-
- ret = pci_pwrctrl_power_on_devices(dev);
- if (ret) {
- dev_err(dev, "failed to power on pwrctrl devices\n");
- goto err_pwrctrl_destroy;
+ if (!pp->skip_pwrctrl_off) {
+ ret = pci_pwrctrl_power_on_devices(dev);
+ if (ret) {
+ dev_err(dev, "failed to power on pwrctrl devices\n");
+ goto err_reg_disable;
+ }
}
ret = imx_pcie_clk_enable(imx_pcie);
@@ -1460,10 +1456,8 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
err_clk_disable:
imx_pcie_clk_disable(imx_pcie);
err_pwrctrl_power_off:
- pci_pwrctrl_power_off_devices(dev);
-err_pwrctrl_destroy:
- if (ret != -EPROBE_DEFER)
- pci_pwrctrl_destroy_devices(dev);
+ if (!pp->skip_pwrctrl_off)
+ pci_pwrctrl_power_off_devices(dev);
err_reg_disable:
if (imx_pcie->vpcie)
regulator_disable(imx_pcie->vpcie);
@@ -1482,7 +1476,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp *pp)
}
imx_pcie_clk_disable(imx_pcie);
- pci_pwrctrl_power_off_devices(pci->dev);
+ if (!pci->pp.skip_pwrctrl_off)
+ pci_pwrctrl_power_off_devices(pci->dev);
if (imx_pcie->vpcie)
regulator_disable(imx_pcie->vpcie);
}
@@ -1954,11 +1949,15 @@ static int imx_pcie_probe(struct platform_device *pdev)
if (ret)
return ret;
+ ret = pci_pwrctrl_create_devices(dev);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to create pwrctrl devices\n");
+
pci->use_parent_dt_ranges = true;
if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
ret = imx_add_pcie_ep(imx_pcie, pdev);
if (ret < 0)
- return ret;
+ goto err_pwrctrl_destroy;
/*
* FIXME: Only single Device (EPF) is supported due to the
@@ -1973,7 +1972,7 @@ static int imx_pcie_probe(struct platform_device *pdev)
pci->pp.use_atu_msg = true;
ret = dw_pcie_host_init(&pci->pp);
if (ret < 0)
- return ret;
+ goto err_pwrctrl_destroy;
if (pci_msi_enabled()) {
u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
@@ -1985,16 +1984,24 @@ static int imx_pcie_probe(struct platform_device *pdev)
}
return 0;
+
+err_pwrctrl_destroy:
+ if (ret != -EPROBE_DEFER)
+ pci_pwrctrl_destroy_devices(dev);
+ return ret;
}
static void imx_pcie_shutdown(struct platform_device *pdev)
{
struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
+ struct dw_pcie *pci = imx_pcie->pci;
+ struct dw_pcie_rp *pp = &pci->pp;
/* bring down link, so bootloader gets clean state in case of reboot */
imx_pcie_assert_core_reset(imx_pcie);
imx_pcie_assert_perst(imx_pcie, true);
- pci_pwrctrl_power_off_devices(&pdev->dev);
+ if (!pp->skip_pwrctrl_off)
+ pci_pwrctrl_power_off_devices(&pdev->dev);
pci_pwrctrl_destroy_devices(&pdev->dev);
}
--
2.50.1
^ permalink raw reply related
* [PATCH V3 2/8] power: sequencing: pcie-m2: Add PCI ID for NXP 88W9098 and AW693 Bluetooth
From: Sherry Sun (OSS) @ 2026-06-26 2:31 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
88W9098 is a NXP Wi-Fi/BT combo chip with PCI device ID 0x2b43 under
Marvell Extended vendor ID. AW693 is a NXP Wi-Fi/BT combo chip with
PCI device ID 0x3003 under NXP/Philips vendor ID.
Add both chips to pwrseq_m2_pci_ids[] so that the pwrseq-pcie-m2 driver
can create the Bluetooth serdev device when these cards are inserted into
a PCIe M.2 Key E connector.
Both chips use "nxp,88w8987-bt" as the serdev compatible string, which
is the entry point for the btnxpuart driver. The driver identifies the
actual chip variant at runtime via chip ID auto-detection and loads the
appropriate firmware accordingly.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
---
drivers/power/sequencing/pwrseq-pcie-m2.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/power/sequencing/pwrseq-pcie-m2.c b/drivers/power/sequencing/pwrseq-pcie-m2.c
index b5ed80d03953..e3ba9169144d 100644
--- a/drivers/power/sequencing/pwrseq-pcie-m2.c
+++ b/drivers/power/sequencing/pwrseq-pcie-m2.c
@@ -186,6 +186,10 @@ static int pwrseq_pcie_m2_match(struct pwrseq_device *pwrseq,
}
static const struct pci_device_id pwrseq_m2_pci_ids[] = {
+ { PCI_DEVICE(PCI_VENDOR_ID_MARVELL_EXT, 0x2b43),
+ .driver_data = (kernel_ulong_t)"nxp,88w8987-bt" },
+ { PCI_DEVICE(PCI_VENDOR_ID_PHILIPS, 0x3003),
+ .driver_data = (kernel_ulong_t)"nxp,88w8987-bt" },
{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x1103),
.driver_data = (kernel_ulong_t)"qcom,wcn6855-bt" },
{ PCI_DEVICE(PCI_VENDOR_ID_QCOM, 0x1107),
--
2.50.1
^ permalink raw reply related
* [PATCH V3 3/8] Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq
From: Sherry Sun (OSS) @ 2026-06-26 2:31 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
Power supply to the M.2 Bluetooth device attached to the host using M.2
connector is controlled using the 'uart' pwrseq device. So add support for
getting the pwrseq device if the OF graph link is present. Once obtained,
pwrseq_power_on() is called to power up the M.2 Bluetooth card. The power
sequencer descriptor is obtained via devm_pwrseq_get(), so the power-off
and cleanup are handled automatically when the device is unbound.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
---
drivers/bluetooth/btnxpuart.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/drivers/bluetooth/btnxpuart.c b/drivers/bluetooth/btnxpuart.c
index e7036a48ce48..438ccaa2b56d 100644
--- a/drivers/bluetooth/btnxpuart.c
+++ b/drivers/bluetooth/btnxpuart.c
@@ -9,6 +9,8 @@
#include <linux/serdev.h>
#include <linux/of.h>
+#include <linux/of_graph.h>
+#include <linux/pwrseq/consumer.h>
#include <linux/skbuff.h>
#include <linux/unaligned.h>
#include <linux/firmware.h>
@@ -1866,6 +1868,18 @@ static int nxp_serdev_probe(struct serdev_device *serdev)
return err;
}
+ if (of_graph_is_present(dev_of_node(&serdev->ctrl->dev))) {
+ struct pwrseq_desc *pwrseq;
+
+ pwrseq = devm_pwrseq_get(&serdev->ctrl->dev, "uart");
+ if (IS_ERR(pwrseq))
+ return PTR_ERR(pwrseq);
+
+ err = pwrseq_power_on(pwrseq);
+ if (err)
+ return err;
+ }
+
/* Initialize and register HCI device */
hdev = hci_alloc_dev();
if (!hdev) {
--
2.50.1
^ permalink raw reply related
* [PATCH V3 4/8] arm64: dts: imx8mq-evk: Describe the PCIe M.2 Key E connector
From: Sherry Sun (OSS) @ 2026-06-26 2:31 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
The i.MX8MQ-EVK has the PCIe M.2 Mechanical Key E connector to connect
wireless connectivity cards over PCIe and UART interfaces. Hence,
describe the connector node and link it with the PCIe 1 Root Port and
UART3 nodes through graph port/endpoint.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 44 ++++++++++++++++++--
1 file changed, 40 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
index 71504a0af87f..482e5203e879 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8mq-evk.dts
@@ -21,6 +21,36 @@ memory@40000000 {
reg = <0x00000000 0x40000000 0 0xc0000000>;
};
+ m2-connector {
+ compatible = "pcie-m2-e-connector";
+ vpcie3v3-supply = <®_pcie1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ m2_e_pcie_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&pcie1_port0_ep>;
+ };
+ };
+
+ port@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ m2_e_uart_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&uart3_ep>;
+ };
+ };
+ };
+ };
+
pcie0_refclk: pcie0-refclk {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -420,8 +450,12 @@ &pcie1_ep {
&pcie1_port0 {
reset-gpios = <&gpio5 12 GPIO_ACTIVE_LOW>;
- vpcie-supply = <®_pcie1>;
- vpcie3v3aux-supply = <®_pcie1>;
+
+ port {
+ pcie1_port0_ep: endpoint {
+ remote-endpoint = <&m2_e_pcie_ep>;
+ };
+ };
};
&pgc_gpu {
@@ -506,8 +540,10 @@ &uart3 { /* BT */
uart-has-rtscts;
status = "okay";
- bluetooth {
- compatible = "nxp,88w8987-bt";
+ port {
+ uart3_ep: endpoint {
+ remote-endpoint = <&m2_e_uart_ep>;
+ };
};
};
--
2.50.1
^ permalink raw reply related
* [PATCH V3 5/8] arm64: dts: imx95-19x19-evk: Describe the PCIe M.2 Key E connector
From: Sherry Sun (OSS) @ 2026-06-26 2:31 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
The i.MX95-19x19-EVK has the PCIe M.2 Mechanical Key E connector to
connect wireless connectivity cards over PCIe and UART interfaces. Hence,
describe the connector node and link it with the PCIe 0 Root Port and
LPUART5 nodes through graph port/endpoint.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
.../boot/dts/freescale/imx95-19x19-evk.dts | 55 ++++++++++++++-----
1 file changed, 41 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
index c08731dfb1ee..d2c0345f0d61 100644
--- a/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx95-19x19-evk.dts
@@ -57,6 +57,37 @@ memory@80000000 {
reg = <0x0 0x80000000 0 0x80000000>;
};
+ m2-connector {
+ compatible = "pcie-m2-e-connector";
+ vpcie3v3-supply = <®_m2_pwr>;
+ w-disable1-gpios = <&i2c7_pcal6524 6 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ m2_e_pcie_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&pcie0_port0_ep>;
+ };
+ };
+
+ port@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ m2_e_uart_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&lpuart5_ep>;
+ };
+ };
+ };
+ };
+
fan0: pwm-fan {
compatible = "pwm-fan";
#cooling-cells = <2>;
@@ -145,16 +176,6 @@ reg_m2_pwr: regulator-m2-pwr {
startup-delay-us = <5000>;
};
- reg_pcie0: regulator-pcie {
- compatible = "regulator-fixed";
- regulator-name = "PCIE_WLAN_EN";
- regulator-min-microvolt = <3300000>;
- regulator-max-microvolt = <3300000>;
- vin-supply = <®_m2_pwr>;
- gpio = <&i2c7_pcal6524 6 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
reg_slot_pwr: regulator-slot-pwr {
compatible = "regulator-fixed";
regulator-name = "PCIe slot-power";
@@ -477,8 +498,10 @@ &lpuart5 {
pinctrl-0 = <&pinctrl_uart5>;
status = "okay";
- bluetooth {
- compatible = "nxp,88w8987-bt";
+ port {
+ lpuart5_ep: endpoint {
+ remote-endpoint = <&m2_e_uart_ep>;
+ };
};
};
@@ -555,8 +578,12 @@ &pcie0_ep {
&pcie0_port0 {
reset-gpios = <&i2c7_pcal6524 5 GPIO_ACTIVE_LOW>;
- vpcie-supply = <®_pcie0>;
- vpcie3v3aux-supply = <®_pcie0>;
+
+ port {
+ pcie0_port0_ep: endpoint {
+ remote-endpoint = <&m2_e_pcie_ep>;
+ };
+ };
};
&pcie1 {
--
2.50.1
^ permalink raw reply related
* [PATCH V3 6/8] arm64: dts: imx8dxl-evk: Describe the PCIe M.2 Key E connector
From: Sherry Sun (OSS) @ 2026-06-26 2:31 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
The i.MX8DXL-EVK has the PCIe M.2 Mechanical Key E connector to connect
wireless connectivity cards over PCIe and UART interfaces. Hence,
describe the connector node and link it with the PCIe b Root Port and
LPUART1 nodes through graph port/endpoint.
The M.2 Key E connector is powered by a 3.3V fixed regulator
(reg_audio_3v3), add a reg_3v3 label to avoid confusion.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 56 ++++++++++++++-----
1 file changed, 42 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
index 1084164d1381..6afee1f1a9fc 100644
--- a/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
+++ b/arch/arm64/boot/dts/freescale/imx8dxl-evk.dts
@@ -42,6 +42,37 @@ memory@80000000 {
reg = <0x00000000 0x80000000 0 0x40000000>;
};
+ m2-connector {
+ compatible = "pcie-m2-e-connector";
+ vpcie3v3-supply = <®_3v3>;
+ w-disable1-gpios = <&pca6416_1 13 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ m2_e_pcie_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&pcieb_port0_ep>;
+ };
+ };
+
+ port@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ m2_e_uart_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&lpuart1_ep>;
+ };
+ };
+ };
+ };
+
reserved-memory {
#address-cells = <2>;
#size-cells = <2>;
@@ -182,15 +213,6 @@ mii_select: regulator-4 {
regulator-always-on;
};
- reg_pcieb: regulator-pcieb {
- compatible = "regulator-fixed";
- regulator-max-microvolt = <3300000>;
- regulator-min-microvolt = <3300000>;
- regulator-name = "reg_pcieb";
- gpio = <&pca6416_1 13 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
reg_audio_5v: regulator-audio-pwr {
compatible = "regulator-fixed";
regulator-name = "audio-5v";
@@ -200,7 +222,7 @@ reg_audio_5v: regulator-audio-pwr {
regulator-boot-on;
};
- reg_audio_3v3: regulator-audio-3v3 {
+ reg_3v3: reg_audio_3v3: regulator-audio-3v3 {
compatible = "regulator-fixed";
regulator-name = "audio-3v3";
regulator-min-microvolt = <3300000>;
@@ -623,8 +645,10 @@ &lpuart1 {
pinctrl-0 = <&pinctrl_lpuart1>;
status = "okay";
- bluetooth {
- compatible = "nxp,88w8987-bt";
+ port {
+ lpuart1_ep: endpoint {
+ remote-endpoint = <&m2_e_uart_ep>;
+ };
};
};
@@ -690,8 +714,12 @@ &pcie0_ep {
&pcieb_port0 {
reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
- vpcie-supply = <®_pcieb>;
- vpcie3v3aux-supply = <®_pcieb>;
+
+ port {
+ pcieb_port0_ep: endpoint {
+ remote-endpoint = <&m2_e_pcie_ep>;
+ };
+ };
};
&sai0 {
--
2.50.1
^ permalink raw reply related
* [PATCH V3 7/8] arm64: dts: imx8qm-mek: Describe the PCIe M.2 Key E connector
From: Sherry Sun (OSS) @ 2026-06-26 2:31 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
The i.MX8QM-MEK has the PCIe M.2 Mechanical Key E connector to connect
wireless connectivity cards over PCIe and UART interfaces. Hence,
describe the connector node and link it with the PCIe a Root Port and
LPUART1 nodes through graph port/endpoint.
The M.2 Key E connector is powered by a 3.3V fixed regulator
(reg_3v3) on board.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 58 +++++++++++++++-----
1 file changed, 43 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
index 5e725ad8aef9..4c02592cfe14 100644
--- a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts
@@ -32,6 +32,39 @@ memory@80000000 {
reg = <0x00000000 0x80000000 0 0x40000000>;
};
+ m2-connector {
+ compatible = "pcie-m2-e-connector";
+ pinctrl-0 = <&pinctrl_pciea_reg>;
+ pinctrl-names = "default";
+ vpcie3v3-supply = <®_3v3>;
+ w-disable1-gpios = <&lsio_gpio1 13 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ m2_e_pcie_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&pciea_port0_ep>;
+ };
+ };
+
+ port@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ m2_e_uart_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&lpuart1_ep>;
+ };
+ };
+ };
+ };
+
xtal24m: clock-xtal24m {
compatible = "fixed-clock";
#clock-cells = <0>;
@@ -320,17 +353,6 @@ reg_can2_stby: regulator-can2-stby {
vin-supply = <®_can2_en>;
};
- reg_pciea: regulator-pcie {
- compatible = "regulator-fixed";
- pinctrl-0 = <&pinctrl_pciea_reg>;
- pinctrl-names = "default";
- regulator-max-microvolt = <3300000>;
- regulator-min-microvolt = <3300000>;
- regulator-name = "mpcie_3v3";
- gpio = <&lsio_gpio1 13 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
reg_usb_otg1_vbus: regulator-usbotg1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb_otg1_vbus";
@@ -718,8 +740,10 @@ &lpuart1 {
pinctrl-0 = <&pinctrl_lpuart1>;
status = "okay";
- bluetooth {
- compatible = "nxp,88w8987-bt";
+ port {
+ lpuart1_ep: endpoint {
+ remote-endpoint = <&m2_e_uart_ep>;
+ };
};
};
@@ -818,8 +842,12 @@ &pciea {
&pciea_port0 {
reset-gpios = <&lsio_gpio4 29 GPIO_ACTIVE_LOW>;
- vpcie-supply = <®_pciea>;
- vpcie3v3aux-supply = <®_pciea>;
+
+ port {
+ pciea_port0_ep: endpoint {
+ remote-endpoint = <&m2_e_pcie_ep>;
+ };
+ };
};
&pcieb {
--
2.50.1
^ permalink raw reply related
* [PATCH V3 8/8] arm64: dts: imx8qxp-mek: Describe the PCIe M.2 Key E connector
From: Sherry Sun (OSS) @ 2026-06-26 2:31 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-1-sherry.sun@oss.nxp.com>
From: Sherry Sun <sherry.sun@nxp.com>
The i.MX8QXP-MEK has the PCIe M.2 Mechanical Key E connector to connect
wireless connectivity cards over PCIe and UART interfaces. Hence,
describe the connector node and link it with the PCIe b Root Port and
LPUART1 nodes through graph port/endpoint.
The M.2 Key E connector is powered by a 3.3V fixed regulator
(reg_3v3) on board.
Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
---
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 54 ++++++++++++++-----
1 file changed, 41 insertions(+), 13 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index a9b967d0a9be..c9fe4034cc2d 100644
--- a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
+++ b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
@@ -40,6 +40,37 @@ memory@80000000 {
reg = <0x00000000 0x80000000 0 0x40000000>;
};
+ m2-connector {
+ compatible = "pcie-m2-e-connector";
+ vpcie3v3-supply = <®_3v3>;
+ w-disable1-gpios = <&pca9557_a 2 GPIO_ACTIVE_LOW>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+ m2_e_pcie_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&pcieb_port0_ep>;
+ };
+ };
+
+ port@3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <3>;
+ m2_e_uart_ep: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&lpuart1_ep>;
+ };
+ };
+ };
+ };
+
reg_usdhc2_vmmc: usdhc2-vmmc {
compatible = "regulator-fixed";
regulator-name = "SD1_SPWR";
@@ -157,15 +188,6 @@ reg_3v3: regulator-3v3 {
regulator-max-microvolt = <3300000>;
};
- reg_pcieb: regulator-pcie {
- compatible = "regulator-fixed";
- regulator-max-microvolt = <3300000>;
- regulator-min-microvolt = <3300000>;
- regulator-name = "mpcie_3v3";
- gpio = <&pca9557_a 2 GPIO_ACTIVE_HIGH>;
- enable-active-high;
- };
-
reg_audio: regulator-audio {
compatible = "regulator-fixed";
regulator-max-microvolt = <3300000>;
@@ -696,8 +718,10 @@ &lpuart1 {
pinctrl-0 = <&pinctrl_lpuart1>;
status = "okay";
- bluetooth {
- compatible = "nxp,88w8987-bt";
+ port {
+ lpuart1_ep: endpoint {
+ remote-endpoint = <&m2_e_uart_ep>;
+ };
};
};
@@ -746,8 +770,12 @@ &pcie0_ep {
&pcieb_port0 {
reset-gpios = <&lsio_gpio4 0 GPIO_ACTIVE_LOW>;
- vpcie-supply = <®_pcieb>;
- vpcie3v3aux-supply = <®_pcieb>;
+
+ port {
+ pcieb_port0_ep: endpoint {
+ remote-endpoint = <&m2_e_pcie_ep>;
+ };
+ };
};
&scu_key {
--
2.50.1
^ permalink raw reply related
* Re: [PATCH v3 3/9] ASoC: loongson: Add Loongson-2K0300 I2S controller support
From: sashiko-bot @ 2026-06-26 2:37 UTC (permalink / raw)
To: Binbin Zhou; +Cc: robh, devicetree, conor+dt
In-Reply-To: <4d3caa62d4275e1495505387198408f4d30d453c.1782439646.git.zhoubinbin@loongson.cn>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
New issues:
- [High] Missing hardware quirk reset sequence on system resume.
- [Medium] Read-Modify-Write on a volatile control register can unintentionally re-enable transient hardware states during soft reset.
Pre-existing issues:
- [High] Illegal overriding of platform device name during probe leading to Use-After-Free and sysfs corruption.
--
commit b9499f3634cc6b7a7bad0f418f80a05c56aa0954
Author: Binbin Zhou <zhoubinbin@loongson.cn>
ASoC: loongson: Add Loongson-2K0300 I2S controller support
The Loongson-2K0300 I2S interface differs significantly from the
Loongson-2K1000. Although both utilize external DMA controllers, the
Loongson-2K0300 does not require additional registers for routing
configuration.
Due to hardware design flaw, an extra controller reset sequence is
required during probe.
> diff --git a/sound/soc/loongson/loongson_i2s_plat.c b/sound/soc/loongson/loongson_i2s_plat.c
> index ac054b6ce6322..82d95c6644ef0 100644
> --- a/sound/soc/loongson/loongson_i2s_plat.c
> +++ b/sound/soc/loongson/loongson_i2s_plat.c
[ ... ]
> @@ -87,11 +108,17 @@ static int loongson_i2s_plat_probe(struct platform_device *pdev)
> if (IS_ERR(i2s_clk))
> return dev_err_probe(dev, PTR_ERR(i2s_clk), "clock property invalid\n");
> i2s->clk_rate = clk_get_rate(i2s_clk);
> + i2s->rev_id = plat_config->rev_id;
>
> dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
> dev_set_name(dev, LS_I2S_DRVNAME);
[Severity: High]
This is a pre-existing issue, but does calling dev_set_name() on an already
registered platform device cause a use-after-free?
Calling dev_set_name() here frees the existing kobj->name without renaming
the underlying sysfs directory.
Could this corrupt the kobject state and lead to kernel warnings upon device
removal?
> dev_set_drvdata(dev, i2s);
>
> + if (i2s->rev_id == 1) {
> + regmap_update_bits(i2s->regmap, LS_I2S_CTRL, I2S_CTRL_RESET, I2S_CTRL_RESET);
[Severity: High]
Since this controller requires a reset due to a hardware flaw, does it also
need this reset applied in the resume path?
When the system suspends, power to the controller is typically lost. Upon
resume, the shared i2s_resume() function is called:
sound/soc/loongson/loongson_i2s.c:i2s_resume() {
struct loongson_i2s *i2s = dev_get_drvdata(dev);
regcache_cache_only(i2s->regmap, false);
return regcache_sync(i2s->regmap);
}
Because LS_I2S_CTRL is typically a volatile register, regcache_sync() will
not automatically restore it. Will this leave the hardware design flaw
unmitigated after a suspend/resume cycle?
[Severity: Medium]
Does using regmap_update_bits() on a volatile control register risk
preserving unintended active states during the soft reset?
Since this performs a read-modify-write, if the bootloader or previous
uninitialized state left other functional bits active, they might be
logically preserved and kept enabled during the reset sequence.
Would it be safer to use regmap_write() to assert the reset while explicitly
ensuring all other functional bits are zeroed out?
> + fsleep(200);
> + }
> +
> ret = devm_snd_soc_register_component(dev, &loongson_i2s_edma_component,
> &loongson_i2s_dai, 1);
> if (ret)
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782439646.git.zhoubinbin@loongson.cn?part=3
^ permalink raw reply
* Re: [PATCH v3 4/9] ASoC: dt-bindings: loongson,ls-audio-card: Use common sound card
From: sashiko-bot @ 2026-06-26 2:37 UTC (permalink / raw)
To: Binbin Zhou; +Cc: devicetree, robh, conor+dt
In-Reply-To: <fa72a429a9d076d381f7d514184f19d5a35ffa51.1782439646.git.zhoubinbin@loongson.cn>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
Pre-existing issues:
- [High] Global state corruption via in-place modification of static DAI links array and codec string buffer.
- [High] Sysfs and ASoC component name collision via illegal `dev_set_name` override during probe.
- [High] Bitwise read-modify-write bug without clearing target bitfields causes incorrect APB DMA routing.
--
commit 864c9404304a7ef17062fbe81f6d13b229c50a0d
Author: Binbin Zhou <zhoubinbin@loongson.cn>
Subject: ASoC: dt-bindings: loongson,ls-audio-card: Use common sound card
This commit updates the loongson,ls-audio-card binding to reference the common
sound card schema. It removes the user specified model property and
transitions to evaluating additional properties via unevaluatedProperties.
> diff --git a/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
> index 61e8babed402f..e1b7445a8b22f 100644
> --- a/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
> +++ b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
[ ... ]
While reviewing the related sound driver for this binding, I noticed a few
pre-existing items in the driver code.
[Severity: High]
This is a pre-existing issue, but I noticed a potential problem in the
sound card driver when handling multiple instances.
In sound/soc/loongson/loongson_card.c:loongson_card_parse_acpi():
loongson_dai_links[i].platforms->name = dev_name(phy_dev);
loongson_dai_links[i].codecs->name = codec_name;
loongson_dai_links[i].codecs->dai_name = codec_dai_name;
And similarly in sound/soc/loongson/loongson_card.c:loongson_card_parse_of():
ret = snd_soc_of_get_dlc(cpu, NULL, loongson_dai_links[i].cpus, 0);
...
loongson_dai_links[i].platforms->of_node =
loongson_dai_links[i].cpus->of_node;
ret = snd_soc_of_get_dlc(codec, NULL, loongson_dai_links[i].codecs, 0);
Will this corrupt the shared static loongson_dai_links array if multiple
sound cards are instantiated via the device tree or ACPI tables?
If multiple instances are probed, they might overwrite each other's
DAI links and codec strings. Should these structures be dynamically
allocated instead of mutating shared static memory?
[Severity: High]
This is a pre-existing issue, but there might be a sysfs naming collision
in the I2S platform driver.
In sound/soc/loongson/loongson_i2s_plat.c:loongson_i2s_plat_probe():
dev_set_name(dev, LS_I2S_DRVNAME);
Could this override cause duplicate ASoC component names if multiple I2S
controllers are instantiated in the device tree?
Calling dev_set_name during probe after the device is added to sysfs might
break internal kernel tracking and cause probe failures for subsequent
instances.
[Severity: High]
This is a pre-existing issue, but there appears to be a bitwise
read-modify-write problem in the APB DMA configuration.
In sound/soc/loongson/loongson_i2s_plat.c:loongson_i2s_apbdma_config():
val |= LOONGSON_DMA2_CONF << LOONGSON_I2S_TX_DMA_OFFSET;
val |= LOONGSON_DMA3_CONF << LOONGSON_I2S_RX_DMA_OFFSET;
Does this code correctly handle cases where the bootloader or previous
firmware left the DMA configuration register in a non-zero state?
Since LOONGSON_DMA2_CONF occupies multiple bits, if other bits are
already set, the bitwise OR will blend the values instead of strictly
setting the field.
Should the target bitfields be cleared via a bitwise AND mask before
applying the new configuration?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782439646.git.zhoubinbin@loongson.cn?part=4
^ permalink raw reply
* Re: [PATCH v3 6/9] ASoC: loongson: Add Loongson-2K0300 CTCISZ Forever Pi sound card support
From: sashiko-bot @ 2026-06-26 2:38 UTC (permalink / raw)
To: Binbin Zhou; +Cc: devicetree, robh, conor+dt
In-Reply-To: <ed1314e1d3275fd20aff47397345a88fad6e9368.1782439646.git.zhoubinbin@loongson.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] DAI format configuration is entirely bypassed if `mclk-fs` is 0.
--
commit 00af2efc83640c13d13fd25311896531fc01a8e7
Author: Binbin Zhou <zhoubinbin@loongson.cn>
ASoC: loongson: Add Loongson-2K0300 CTCISZ Forever Pi sound card support
The Loongson-2K0300 audio card uses a different DAI format compared to
existing Loongson platforms. Move the dai_fmt setting from the static
DAI link to runtime hw_params via snd_soc_runtime_set_dai_fmt(), and pass
the correct format through driver match data.
> diff --git a/sound/soc/loongson/loongson_card.c b/sound/soc/loongson/loongson_card.c
> index ea895fe6b5e97..0e63cbcad57ac 100644
> --- a/sound/soc/loongson/loongson_card.c
> +++ b/sound/soc/loongson/loongson_card.c
[ ... ]
> @@ -45,7 +59,7 @@ static int loongson_card_hw_params(struct snd_pcm_substream *substream,
> return ret;
> }
>
> - return 0;
> + return snd_soc_runtime_set_dai_fmt(rtd, ls_card->cfg->fmt);
> }
[Severity: Medium]
If a platform's firmware explicitly sets the mclk-fs property to 0,
loongson_card_hw_params() will exit early:
if (!ls_card->mclk_fs)
return 0;
By moving the format configuration to the end of this function, will
the CPU and CODEC DAIs fail to be configured with the correct format when
mclk-fs is 0, since the early return bypasses this new call?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782439646.git.zhoubinbin@loongson.cn?part=6
^ permalink raw reply
* Re: [PATCH v3 1/9] ASoC: loongson: Fix error handling in ACPI property parsing
From: sashiko-bot @ 2026-06-26 2:38 UTC (permalink / raw)
To: Binbin Zhou; +Cc: robh, devicetree, conor+dt
In-Reply-To: <08e44a54708eae053be148524346bb8dfcd55b03.1782439646.git.zhoubinbin@loongson.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The driver statically allocates global variables (`codec_name`, `loongson_dai_links`) and modifies them locklessly during the device probe phase without creating instance-specific copies. This leads to data races, state corruption on probe deferral, and a use-after-free vulnerability upon device unbind.
--
commit b0aab833787c20534a1a8d5a4fb96b7f089e37e4
Author: Binbin Zhou <zhoubinbin@loongson.cn>
ASoC: loongson: Fix error handling in ACPI property parsing
This commit fixes a missing error check for device_property_read_string()
in loongson_card_parse_acpi(). It propagates the error if the codec-dai-name
property is missing or invalid, preventing the use of an uninitialized
pointer.
Closes: https://sashiko.dev/#/patchset/cover.1780538113.git.zhoubinbin@loongson.cn?part=5
> diff --git a/sound/soc/loongson/loongson_card.c b/sound/soc/loongson/loongson_card.c
> --- a/sound/soc/loongson/loongson_card.c
> +++ b/sound/soc/loongson/loongson_card.c
[ ... ]
> @@ -108,7 +108,9 @@ static int loongson_card_parse_acpi(struct loongson_card_data *data)
> return -ENOENT;
> snprintf(codec_name, sizeof(codec_name), "i2c-%s", acpi_dev_name(adev));
>
> - device_property_read_string(card->dev, "codec-dai-name", &codec_dai_name);
> + ret = device_property_read_string(card->dev, "codec-dai-name", &codec_dai_name);
> + if (ret)
> + return ret;
>
> for (i = 0; i < card->num_links; i++) {
> loongson_dai_links[i].platforms->name = dev_name(phy_dev);
[Severity: High]
This is a pre-existing issue, but I noticed that loongson_dai_links appears
to be a statically allocated global array being modified locklessly here with
instance-specific pointers like dev_name(phy_dev).
If the device is unbound, could this leave a dangling pointer in the global
array?
Additionally, if multiple audio cards are instantiated, could they overwrite
each other's state in this shared array?
Similarly, in loongson_card_parse_of(), snd_soc_of_get_dlc() acquires a
reference to an of_node and stores it in this global array. If probe defers,
does the error path fail to clean up the globally stored refcount, causing
a memory leak?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782439646.git.zhoubinbin@loongson.cn?part=1
^ permalink raw reply
* Re: [PATCH v3 7/9] ASoC: dt-bindings: loongson,ls-audio-card: Add ATK-DL2K0300B compatible
From: sashiko-bot @ 2026-06-26 2:38 UTC (permalink / raw)
To: Binbin Zhou; +Cc: robh, conor+dt, devicetree
In-Reply-To: <71430fcee5951fb7a7d52e2091a87707db85e06c.1782439646.git.zhoubinbin@loongson.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Custom GPIO properties lack a vendor prefix.
--
commit ad0ddc0bcb1797ef1e44f8d7b02415a3c55eb74b
Author: Binbin Zhou <zhoubinbin@loongson.cn>
ASoC: dt-bindings: loongson,ls-audio-card: Add ATK-DL2K0300B compatible
This commit adds a new compatible string for the ATK-DL2K0300B development
board based on Loongson-2K0300. It also introduces several new GPIO
properties to support hardware features like speaker enable and headphone
detection.
> diff --git a/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
> --- a/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
> +++ b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
[ ... ]
> @@ -47,6 +48,18 @@ properties:
> required:
> - sound-dai
>
> + spkr-en-gpios:
> + maxItems: 1
> + description: The GPIO that enables the speakers
> +
> + hp-ctl-gpios:
> + maxItems: 1
> + description: The GPIO that control the headphones
[Severity: Low]
This isn't a bug, but should these custom board-specific GPIO properties
include a vendor prefix?
Since they are unique and non-standard properties, using a prefix like
loongson,spkr-en-gpios and loongson,hp-ctl-gpios would better align with
device tree naming conventions.
> +
> + hp-det-gpios:
> + maxItems: 1
> + description: The GPIO that detect headphones are plugged in
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782439646.git.zhoubinbin@loongson.cn?part=7
^ permalink raw reply
* Re: [PATCH v3 9/9] ASoC: es8328: Add DAPM routes from MIC inputs to Mic Bias
From: sashiko-bot @ 2026-06-26 2:40 UTC (permalink / raw)
To: Binbin Zhou; +Cc: conor+dt, robh, devicetree
In-Reply-To: <dcf1f8ae4f1f192a1d63e9fe7044b0218119b5eb.1782439646.git.zhoubinbin@loongson.cn>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Hardcoding board-specific 'Mic Bias' routes to generic multipurpose input pins in the codec driver violates DAPM architecture and causes a power regression.
--
commit 864cdd66179a2d1429284999cab86b202f471e82
Author: Binbin Zhou <zhoubinbin@loongson.cn>
ASoC: es8328: Add DAPM routes from MIC inputs to Mic Bias
This commit adds DAPM routes connecting the ES8328 generic microphone input
pins (LINPUT1/2, RINPUT1/2) directly to the internal Mic Bias generator.
This is intended to ensure proper bias voltage is applied when these pins
are used for microphone recording.
> diff --git a/sound/soc/codecs/es8328.c b/sound/soc/codecs/es8328.c
> index 9838fe42cb6fc..aaa6646ad4c5e 100644
> --- a/sound/soc/codecs/es8328.c
> +++ b/sound/soc/codecs/es8328.c
[ ... ]
> @@ -405,6 +405,11 @@ static const struct snd_soc_dapm_route es8328_dapm_routes[] = {
>
> { "Mic Bias", NULL, "Mic Bias Gen" },
>
> + { "LINPUT1", NULL, "Mic Bias" },
> + { "RINPUT1", NULL, "Mic Bias" },
> + { "LINPUT2", NULL, "Mic Bias" },
> + { "RINPUT2", NULL, "Mic Bias" },
[Severity: Medium]
Does adding these unconditional routes in the codec driver violate DAPM
architectural guidelines by hardcoding board-specific external connections?
Since LINPUT1/2 and RINPUT1/2 are generic multipurpose analog inputs that
can be configured as either microphones or line-level inputs, forcing DAPM
to always power the internal Mic Bias generator when these inputs are active
could cause a power regression on boards that use them as Line-In.
Should this external physical connection between a microphone bias pin and the
microphone jack be specified in the machine driver's device tree via the
audio-routing property (for example, "Mic Jack", "Mic Bias") instead of being
hardcoded globally in the generic codec driver?
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782439646.git.zhoubinbin@loongson.cn?part=9
^ permalink raw reply
* Re: [PATCH v3 8/9] ASoC: loongson: Add headphone jack detection and DAPM routing
From: sashiko-bot @ 2026-06-26 2:44 UTC (permalink / raw)
To: Binbin Zhou; +Cc: devicetree, conor+dt, robh
In-Reply-To: <c4b1503220b6fb433ecdcb881556827579041c3d.1782439646.git.zhoubinbin@loongson.cn>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Double-free of the hp-det GPIO descriptor on probe failure or driver unbind.
- [High] Global state mutation via static global instance structures.
- [Low] Misleading DAPM event handler name and widget array typos due to copy-pasting.
--
commit 96bfdeee5a35a70f217e0f245943a82eb9a7ce3b
Author: Binbin Zhou <zhoubinbin@loongson.cn>
ASoC: loongson: Add headphone jack detection and DAPM routing
Extend the Loongson audio machine driver with jack detection, DAPM
widgets support, enabling proper switching between headphones and
speakers on the Loongson-2K0300 ATK-DL2K0300B board.
> diff --git a/sound/soc/loongson/loongson_card.c b/sound/soc/loongson/loongson_card.c
> index 0e63cbcad57ac..25cd12eab4b1f 100644
> --- a/sound/soc/loongson/loongson_card.c
> +++ b/sound/soc/loongson/loongson_card.c
[ ... ]
> +static int tegra_machine_event(struct snd_soc_dapm_widget *w,
> + struct snd_kcontrol *k, int event)
> +{
[Severity: Low]
This isn't a bug, but should this function be renamed to match the loongson
namespace instead of keeping the tegra_ prefix from a copied driver?
> + struct snd_soc_card *card = snd_soc_dapm_to_card(w->dapm);
> + struct loongson_card_data *priv = snd_soc_card_get_drvdata(card);
> +
> + if (!snd_soc_dapm_widget_name_cmp(w, "Speaker"))
> + gpiod_set_value_cansleep(priv->gpiod_spkr_en,
> + SND_SOC_DAPM_EVENT_ON(event));
[ ... ]
> +static const struct snd_soc_dapm_widget loongson_aosc_dapm_widgets[] = {
[Severity: Low]
This isn't a bug, but there is a typo here (aosc instead of asoc).
> + SND_SOC_DAPM_HP("Headphone", tegra_machine_event),
> + SND_SOC_DAPM_SPK("Speaker", tegra_machine_event),
> +};
> +
> +/* Headphones Jack */
> +
> +static struct snd_soc_jack loongson_asoc_hp_jack;
> +
> +static struct snd_soc_jack_pin loongson_asoc_hp_jack_pins[] = {
[ ... ]
> +static struct snd_soc_jack_gpio loongson_asoc_hp_jack_gpio = {
> + .name = "Headphones detection",
> + .report = SND_JACK_HEADPHONE,
> + .debounce_time = 150,
> +};
[Severity: High]
Will using a static global instance for snd_soc_jack_gpio cause cross-device
state corruption?
The ASoC core function snd_soc_jack_add_gpios() takes ownership of this
struct and initializes a delayed_work structure inside it. If multiple
instances of this driver probe concurrently or across unbind/rebind cycles,
multiple driver instances might mutate and re-initialize the same global
static struct and its workqueue list head.
Could this be moved to the instance-specific loongson_card_data instead?
> +
> +static int loongson_asoc_machine_init(struct snd_soc_pcm_runtime *rtd)
> +{
> + struct snd_soc_card *card = rtd->card;
> + struct loongson_card_data *ls_priv = snd_soc_card_get_drvdata(card);
> + int ret = 0;
[ ... ]
> @@ -135,16 +229,35 @@ static int loongson_card_parse_acpi(struct loongson_card_data *data)
>
> static int loongson_card_parse_of(struct loongson_card_data *data)
> {
> - struct device_node *cpu, *codec;
> struct snd_soc_card *card = &data->snd_card;
> + struct device_node *cpu, *codec;
> struct device *dev = card->dev;
> int ret, i;
>
> + data->gpiod_hp_det = devm_gpiod_get_optional(dev, "hp-det", GPIOD_IN);
[Severity: High]
Will this devm-managed GPIO descriptor trigger a double-free on driver unbind
or probe deferral?
When devm_gpiod_get_optional() requests the GPIO, it registers a devres
cleanup action. Later in loongson_asoc_machine_init():
loongson_asoc_machine_init() {
...
loongson_asoc_hp_jack_gpio.desc = ls_priv->gpiod_hp_det;
ret = snd_soc_jack_add_gpios(&loongson_asoc_hp_jack, 1,
&loongson_asoc_hp_jack_gpio);
...
}
The snd_soc_jack_add_gpios() call registers a second overlapping devres action
that unconditionally frees the GPIO descriptor. When the device is unbound,
won't both cleanup actions attempt to free the same gpio_device, leading to
a Use-After-Free?
> + if (IS_ERR(data->gpiod_hp_det))
> + return PTR_ERR(data->gpiod_hp_det);
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782439646.git.zhoubinbin@loongson.cn?part=8
^ permalink raw reply
* [PATCH 1/2] dt-bindings: arm: tegra: Add lenovo,thinkedge-se70 compatible string
From: Jiqi Li @ 2026-06-26 3:34 UTC (permalink / raw)
To: linux-tegra
Cc: devicetree, robh+dt, krzk+dt, conor+dt, jonathanh, thierry.reding,
mpearson-lenovo, Jiqi Li
In-Reply-To: <20260626033418.520762-1-lijq9@lenovo.com>
Lenovo ThinkEdge SE70 is a fanless industrial edge gateway carrier
board based on NVIDIA Tegra194 (Xavier NX) SOM.
Add the corresponding compatible string for device tree validation.
Signed-off-by: Jiqi Li <lijq9@lenovo.com>
---
Documentation/devicetree/bindings/arm/tegra.yaml | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml
index 033a63f6c068..960c604ef9a3 100644
--- a/Documentation/devicetree/bindings/arm/tegra.yaml
+++ b/Documentation/devicetree/bindings/arm/tegra.yaml
@@ -268,6 +268,10 @@ properties:
items:
- const: nvidia,p3509-0000+p3668-0001
- const: nvidia,tegra194
+ - description: Lenovo ThinkEdge SE70
+ items:
+ - const: lenovo,thinkedge-se70
+ - const: nvidia,tegra194
- items:
- const: nvidia,tegra234-vdk
- const: nvidia,tegra234
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] arm64: tegra: Add Lenovo ThinkEdge SE70 carrier board DTS
From: Jiqi Li @ 2026-06-26 3:34 UTC (permalink / raw)
To: linux-tegra
Cc: devicetree, robh+dt, krzk+dt, conor+dt, jonathanh, thierry.reding,
mpearson-lenovo, Jiqi Li
In-Reply-To: <20260626033418.520762-1-lijq9@lenovo.com>
ThinkEdge SE70 is a fanless industrial edge gateway built around
NVIDIA Tegra194 Xavier NX SOM. This patch adds a standalone device
tree file describing core carrier board peripherals:
- Custom 40-pin header pinmux configuration
- External SD card slot with dedicated 3.3V fixed regulator
No fan, PWM, tachometer, extra camera/spi peripherals are present
on this passively cooled platform, so unused nodes are explicitly
disabled following mainline device tree best practices.
Static verification passed: dt_binding_check and dtbs compilation
complete without errors.
Signed-off-by: Jiqi Li <lijq9@lenovo.com>
---
arch/arm64/boot/dts/nvidia/Makefile | 1 +
.../nvidia/tegra194-lenovo-thinkedge-se70.dts | 164 ++++++++++++++++++
2 files changed, 165 insertions(+)
create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
diff --git a/arch/arm64/boot/dts/nvidia/Makefile b/arch/arm64/boot/dts/nvidia/Makefile
index 72c0cb5efa47..736a3f8a923f 100644
--- a/arch/arm64/boot/dts/nvidia/Makefile
+++ b/arch/arm64/boot/dts/nvidia/Makefile
@@ -29,6 +29,7 @@ dtb-$(CONFIG_ARCH_TEGRA_186_SOC) += tegra186-p3509-0000+p3636-0001.dtb
dtb-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra194-p2972-0000.dtb
dtb-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra194-p3509-0000+p3668-0000.dtb
dtb-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra194-p3509-0000+p3668-0001.dtb
+dtb-$(CONFIG_ARCH_TEGRA_194_SOC) += tegra194-lenovo-thinkedge-se70.dtb
dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-sim-vdk.dtb
dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3737-0000+p3701-0000.dtb
dtb-$(CONFIG_ARCH_TEGRA_234_SOC) += tegra234-p3737-0000+p3701-0008.dtb
diff --git a/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts b/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
new file mode 100644
index 000000000000..d44eb7c9b474
--- /dev/null
+++ b/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
@@ -0,0 +1,164 @@
+// SPDX-License-Identifier: GPL-2.0
+/dts-v1/;
+
+#include "tegra194-p3668-0001.dtsi"
+#include "tegra194-p3509-0000.dtsi"
+
+/ {
+ model = "Lenovo ThinkEdge SE70";
+ compatible = "lenovo,thinkedge-se70", "nvidia,tegra194";
+
+ chosen {
+ bootargs = "console=ttyTCU0,115200";
+ };
+
+ /* Fixed 3.3V regulator for external SD card slot */
+ fixed-regulators {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <0>;
+ ap2306gn_3v3_sd: ap2306gn-3v3-sd {
+ compatible = "regulator-fixed";
+ regulator-name = "ap2306gn-3v3-sd";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ gpio = <&gpio TEGRA194_MAIN_GPIO(Q, 5) GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ status = "okay";
+ };
+ };
+
+ bus@0 {
+
+ /* Custom pinmux configurations for 40-pin expansion header */
+ pinmux@c302000 {
+ status = "okay";
+ touch-clk-pcc4 {
+ nvidia,pins = "touch_clk_pcc4";
+ nvidia,function = "rsvd2";
+ nvidia,pull = <TEGRA_PIN_PULL_UP>;
+ nvidia,tristate = <TEGRA_PIN_ENABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ };
+ };
+
+ pinmux@2430028 {
+ status = "okay";
+ soc-gpio41-pq5 {
+ nvidia,pins = "soc_gpio41_pq5";
+ nvidia,function = "rsvd2";
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ };
+ };
+
+ pinmux@2430000 {
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hdr40_pinmux>;
+
+ hdr40_pinmux: header-40pin-pinmux {
+ pin7 {
+ nvidia,pins = "aud_mclk_ps4";
+ nvidia,function = "aud";
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ };
+ pin11 {
+ nvidia,pins = "uart1_rts_pr4";
+ nvidia,function = "uarta";
+ nvidia,pull = <TEGRA_PIN_PULL_NONE>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ };
+ pin12 {
+ nvidia,pins = "dap5_sclk_pt5";
+ nvidia,function = "i2s5";
+ nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ };
+ pin35 {
+ nvidia,pins = "dap5_fs_pu0";
+ nvidia,function = "i2s5";
+ nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ };
+ pin36 {
+ nvidia,pins = "uart1_cts_pr5";
+ nvidia,function = "uarta";
+ nvidia,pull = <TEGRA_PIN_PULL_UP>;
+ nvidia,tristate = <TEGRA_PIN_ENABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ };
+ pin38 {
+ nvidia,pins = "dap5_din_pt7";
+ nvidia,function = "i2s5";
+ nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
+ nvidia,tristate = <TEGRA_PIN_ENABLE>;
+ nvidia,enable-input = <TEGRA_PIN_ENABLE>;
+ };
+ pin40 {
+ nvidia,pins = "dap5_dout_pt6";
+ nvidia,function = "i2s5";
+ nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
+ nvidia,tristate = <TEGRA_PIN_DISABLE>;
+ nvidia,enable-input = <TEGRA_PIN_DISABLE>;
+ };
+ };
+ };
+
+ /* Configure i2c bus clock to 400kHz for carrier board peripherals */
+ i2c@3160000 {
+ clock-frequency = <400000>;
+ status = "okay";
+ };
+
+ /* SDMMC3 for external user SD card slot with dedicated 3.3V power */
+ sdhci@3440000 {
+ vmmc-supply = <&ap2306gn_3v3_sd>;
+ cd-gpios = <&gpio_aon TEGRA194_AON_GPIO(CC, 4) GPIO_ACTIVE_HIGH>;
+ status = "okay";
+ };
+
+ /* Disable fan and tachometer hardware not populated on SE70 carrier board */
+ pwm-fan {
+ status = "disabled";
+ };
+ thermal-fan-est {
+ status = "disabled";
+ };
+ tachometer@39c0000 {
+ status = "disabled";
+ };
+ pwm@c340000 {
+ status = "disabled";
+ };
+ pwm@3280000 {
+ status = "disabled";
+ };
+ pwm@32c0000 {
+ status = "disabled";
+ };
+ pwm@32d0000 {
+ status = "disabled";
+ };
+ pwm@32f0000 {
+ status = "disabled";
+ };
+ generic-pwm-tachometer {
+ status = "disabled";
+ };
+
+ /* Disable unused SPI interfaces on 40-pin header */
+ spi@3210000 {
+ status = "disabled";
+ };
+ spi@3230000 {
+ status = "disabled";
+ };
+ };
+};
--
2.43.0
^ permalink raw reply related
* [RFC v2 PATCH 0/2] Add Lenovo ThinkEdge SE70 carrier board support
From: Jiqi Li @ 2026-06-26 3:34 UTC (permalink / raw)
To: linux-tegra
Cc: devicetree, robh+dt, krzk+dt, conor+dt, jonathanh, thierry.reding,
mpearson-lenovo, Jiqi Li
This series adds device tree bindings and standalone DTS for the Lenovo
ThinkEdge SE70 fanless industrial edge gateway based on NVIDIA Tegra194
Xavier NX SOM.
Patch 1 adds the board compatible string to tegra.yaml for dt-schema
validation.
Patch 2 introduces the carrier board DTS with 40-pin header pinmux and
external SD card power regulator, disables unused fan/PWM/spi peripherals.
Static verification passed: dt_binding_check and dtbs compilation
complete without errors.
We maintain downstream DTS for mass-deployed SE70 hardware internally.
Upstreaming aligns with existing OEM board contributions (Google/Xiaomi)
in the Tegra tree, cuts long-term out-of-tree patch maintenance overhead.
This industrial platform has a full 7-year support lifecycle until 2028;
Lenovo will keep backporting DT fixes throughout its service window.
All peripherals use generic upstream drivers with no proprietary extensions.
Changes in v2:
- Wrap all memory-mapped peripherals under root bus@0 node to match upstream
tegra194.dtsi hardware topology
- Add missing tegra194.dtsi include to resolve undefined GPIO/pinctrl macros
- Fix regulator label syntax error (illegal hyphens replaced with underscores),
sync supply reference in sdhci node
- Remove downstream L4T-only nvidia,lpdr pinmux property which lacks upstream binding
- Fix SD card detect double inversion logic: drop cd-inverted property,
set cd-gpios to GPIO_ACTIVE_HIGH
- Add required simple-bus properties (#address-cells, #size-cells) to fixed-regulators
- Unify all node labels to underscore naming per devicetree specification
- Correct mismatched 2.3V -> 3.3V regulator comment
- Trim compound SOM compatible string to eliminate un-documented binding warning
Jiqi Li (2):
dt-bindings: arm: tegra: Add lenovo,thinkedge-se70 compatible string
arm64: tegra: Add Lenovo ThinkEdge SE70 carrier board DTS
.../devicetree/bindings/arm/tegra.yaml | 4 +
arch/arm64/boot/dts/nvidia/Makefile | 1 +
.../nvidia/tegra194-lenovo-thinkedge-se70.dts | 164 ++++++++++++++++++
3 files changed, 169 insertions(+)
create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
--
2.43.0
^ permalink raw reply
* [PATCH v2 0/2] rtq2208: Remove the unnecessary MTP_SEL property
From: cy_huang @ 2026-06-26 3:38 UTC (permalink / raw)
To: Mark Brown, Krzysztof Kozlowski
Cc: Rob Herring, Conor Dooley, Liam Girdwood, ChiYuan Huang,
Yoon Dong Min, edward_kim, devicetree, linux-kernel
From: ChiYuan Huang <cy_huang@richtek.com>
This patch series remove the 'richtek,mtp-sel-high' property usage.
v2:
- Remove'richtek,mtp-sel-high' from yaml example block
ChiYuan Huang (2):
regulator: dt-bindings: rtq2208: Label mtp-sel-high property as
deprecated
regualtor: rtq2208: Initiate the default MTP_SEL state by hardware
register
.../devicetree/bindings/regulator/richtek,rtq2208.yaml | 4 +++-
drivers/regulator/rtq2208-regulator.c | 7 ++++++-
2 files changed, 9 insertions(+), 2 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2 1/2] regulator: dt-bindings: rtq2208: Label mtp-sel-high property as deprecated
From: cy_huang @ 2026-06-26 3:38 UTC (permalink / raw)
To: Mark Brown, Krzysztof Kozlowski
Cc: Rob Herring, Conor Dooley, Liam Girdwood, ChiYuan Huang,
Yoon Dong Min, edward_kim, devicetree, linux-kernel
In-Reply-To: <cover.1782444299.git.cy_huang@richtek.com>
From: ChiYuan Huang <cy_huang@richtek.com>
Since it can be identified by hardware register, label the unnecessary
property 'richtek,mtp-sel-high' as deprecated.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
v2
- Following by AI Robot suggestion
https://sashiko.dev/#/patchset/cover.1782353659.git.cy_huang@richtek.com?part=1
Remove'richtek,mtp-sel-high' from yaml example block
---
.../devicetree/bindings/regulator/richtek,rtq2208.yaml | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
index 022c1f197364..25b0865d4c04 100644
--- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
+++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
@@ -42,11 +42,14 @@ properties:
richtek,mtp-sel-high:
type: boolean
+ deprecated: true
description:
vout register selection based on this boolean value.
false - Using DVS0 register setting to adjust vout
true - Using DVS1 register setting to adjust vout
+ The property is now deprecated. Will be identified by RG HW register.
+
regulators:
type: object
additionalProperties: false
@@ -100,7 +103,6 @@ examples:
compatible = "richtek,rtq2208";
reg = <0x10>;
interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>;
- richtek,mtp-sel-high;
regulators {
buck-a {
--
2.43.0
^ permalink raw reply related
* [PATCH v2 2/2] regualtor: rtq2208: Initiate the default MTP_SEL state by hardware register
From: cy_huang @ 2026-06-26 3:38 UTC (permalink / raw)
To: Mark Brown, Krzysztof Kozlowski
Cc: Rob Herring, Conor Dooley, Liam Girdwood, ChiYuan Huang,
Yoon Dong Min, edward_kim, devicetree, linux-kernel
In-Reply-To: <cover.1782444299.git.cy_huang@richtek.com>
From: ChiYuan Huang <cy_huang@richtek.com>
Read the initial MTP_SEL state by hardware register to prevent the wrong
specified property value from the conflict of hardware pin assignment.
Signed-off-by: ChiYuan Huang <cy_huang@richtek.com>
---
drivers/regulator/rtq2208-regulator.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/regulator/rtq2208-regulator.c b/drivers/regulator/rtq2208-regulator.c
index f669a562f036..7fe082def494 100644
--- a/drivers/regulator/rtq2208-regulator.c
+++ b/drivers/regulator/rtq2208-regulator.c
@@ -12,6 +12,7 @@
#include <linux/mod_devicetable.h>
/* Register */
+#define RTQ2208_REG_FSOUTB_CNTL 0x11
#define RTQ2208_REG_GLOBAL_INT1 0x12
#define RTQ2208_REG_FLT_RECORDBUCK_CB 0x18
#define RTQ2208_REG_GLOBAL_INT1_MASK 0x1D
@@ -34,6 +35,7 @@
#define RTQ2208_REG_HIDDEN1 0xFF
/* Mask */
+#define RTQ2208_MTP_SEL_RO_MASK BIT(7)
#define RTQ2208_BUCK_NR_MTP_SEL_MASK GENMASK(7, 0)
#define RTQ2208_BUCK_EN_NR_MTP_SEL0_MASK BIT(0)
#define RTQ2208_BUCK_EN_NR_MTP_SEL1_MASK BIT(1)
@@ -465,10 +467,13 @@ static int rtq2208_parse_regulator_dt_data(int n_regulator, const unsigned int *
struct rtq2208_regulator_desc *rdesc[RTQ2208_LDO_MAX], struct device *dev,
unsigned int ldo1_fixed, unsigned int ldo2_fixed)
{
+ struct regmap *regmap = dev_get_regmap(dev, NULL);
int mtp_sel, i, idx;
/* get mtp_sel0 or mtp_sel1 */
- mtp_sel = device_property_read_bool(dev, "richtek,mtp-sel-high");
+ mtp_sel = regmap_test_bits(regmap, RTQ2208_REG_FSOUTB_CNTL, RTQ2208_MTP_SEL_RO_MASK);
+ if (mtp_sel < 0)
+ return dev_err_probe(dev, mtp_sel, "Failed to init mtp_sel state\n");
for (i = 0; i < n_regulator; i++) {
idx = regulator_idx_table[i];
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: arm: tegra: Add lenovo,thinkedge-se70 compatible string
From: sashiko-bot @ 2026-06-26 3:43 UTC (permalink / raw)
To: Jiqi Li; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260626033418.520762-2-lijq9@lenovo.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The compatible string array for the Lenovo ThinkEdge SE70 omits the underlying Xavier NX SOM compatible string.
--
commit bdfb0a0b8f7c5312dd01ccd7b35c0e589b16d8f5
Author: Jiqi Li <lijq9@lenovo.com>
dt-bindings: arm: tegra: Add lenovo,thinkedge-se70 compatible string
This commit adds the compatible string for the Lenovo ThinkEdge SE70 carrier
board, which is based on the NVIDIA Tegra194 (Xavier NX) SOM, to the ARM
Tegra device tree bindings schema.
> diff --git a/Documentation/devicetree/bindings/arm/tegra.yaml b/Documentation/devicetree/bindings/arm/tegra.yaml
> index 033a63f6c0687..960c604ef9a3a 100644
> --- a/Documentation/devicetree/bindings/arm/tegra.yaml
> +++ b/Documentation/devicetree/bindings/arm/tegra.yaml
> @@ -268,6 +268,10 @@ properties:
> items:
> - const: nvidia,p3509-0000+p3668-0001
> - const: nvidia,tegra194
> + - description: Lenovo ThinkEdge SE70
> + items:
> + - const: lenovo,thinkedge-se70
> + - const: nvidia,tegra194
[Severity: Low]
Since the Lenovo ThinkEdge SE70 is a carrier board based on the NVIDIA
Tegra194 (Xavier NX) SOM, should this items list also require the underlying
SOM compatible string (nvidia,p3668-0001)?
Restricting the array to exactly two elements here implies the corresponding
device tree will omit the SOM fallback string. Omitting the intermediate SOM
string prevents the OS from natively identifying the underlying module and
could cause drivers or quirks targeting the Xavier NX SOM to fail to match
on this board.
> - items:
> - const: nvidia,tegra234-vdk
> - const: nvidia,tegra234
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626033418.520762-1-lijq9@lenovo.com?part=1
^ permalink raw reply
* Re: [PATCH v2 1/2] regulator: dt-bindings: rtq2208: Label mtp-sel-high property as deprecated
From: sashiko-bot @ 2026-06-26 3:46 UTC (permalink / raw)
To: cy_huang; +Cc: devicetree, robh, conor+dt
In-Reply-To: <594ebe167b33ca885c040984624e4b5d1382c0e2.1782444299.git.cy_huang@richtek.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing block scalar indicator (`|`) in the `description` property causes a fatal YAML parsing error.
--
commit 5c227b25d25e534f0fd83cfc25a3a064d6084614
Author: ChiYuan Huang <cy_huang@richtek.com>
regulator: dt-bindings: rtq2208: Label mtp-sel-high property as deprecated
This commit marks the richtek,mtp-sel-high property as deprecated in the
rtq2208 device tree binding schema. It adds the deprecated flag and updates
the description to indicate that the property can now be identified by a
hardware register.
> diff --git a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> --- a/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> +++ b/Documentation/devicetree/bindings/regulator/richtek,rtq2208.yaml
> @@ -42,11 +42,14 @@ properties:
>
> richtek,mtp-sel-high:
> type: boolean
> + deprecated: true
> description:
> vout register selection based on this boolean value.
> false - Using DVS0 register setting to adjust vout
> true - Using DVS1 register setting to adjust vout
>
> + The property is now deprecated. Will be identified by RG HW register.
[Severity: Low]
Does the addition of this blank line break the YAML syntax?
Because the description field lacks a block scalar indicator (| or >), it is
parsed as a plain scalar. Plain scalars cannot contain blank lines, which
causes a parsing error during make dt_binding_check. Adding a block scalar
indicator to the description field would resolve the issue.
> +
> regulators:
> type: object
> additionalProperties: false
--
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1782444299.git.cy_huang@richtek.com?part=1
^ permalink raw reply
* Re: [PATCH 2/2] arm64: tegra: Add Lenovo ThinkEdge SE70 carrier board DTS
From: sashiko-bot @ 2026-06-26 3:47 UTC (permalink / raw)
To: Jiqi Li; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260626033418.520762-3-lijq9@lenovo.com>
Thank you for your contribution! Sashiko AI review found 5 potential issue(s) to consider:
- [High] Pin configurations are instantiated as standalone dummy nodes instead of subnodes of the pinctrl controllers.
- [High] SD card controller override fails due to a node name mismatch (`sdhci` vs `mmc`).
- [High] The pwm-fan status override fails because it is incorrectly nested under bus@0.
- [Medium] Device tree contains dead overrides for non-existent downstream nodes.
- [Medium] The fixed-regulators node incorrectly uses simple-bus with `#address-cells = <1>` for a sizeless child.
--
commit 124a29c4818b88a33b77f6bc336c64c7bd9a06ec
Author: Jiqi Li <lijq9@lenovo.com>
arm64: tegra: Add Lenovo ThinkEdge SE70 carrier board DTS
ThinkEdge SE70 is a fanless industrial edge gateway built around
NVIDIA Tegra194 Xavier NX SOM. This patch adds a standalone device
tree file describing core carrier board peripherals.
> diff --git a/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts b/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
> new file mode 100644
> index 0000000000000..d44eb7c9b4742
> --- /dev/null
> +++ b/arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
[ ... ]
> + /* Fixed 3.3V regulator for external SD card slot */
> + fixed-regulators {
> + compatible = "simple-bus";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + ap2306gn_3v3_sd: ap2306gn-3v3-sd {
[Severity: Medium]
The fixed-regulators node is marked as compatible = "simple-bus" and sets
#address-cells = <1>, but its child ap2306gn-3v3-sd does not have a unit
address or a reg property.
Since the simple-bus binding requires children to have a reg or ranges
property, will this cause dtbs_check validation to fail?
[ ... ]
> + bus@0 {
> +
> + /* Custom pinmux configurations for 40-pin expansion header */
> + pinmux@c302000 {
> + status = "okay";
> + touch-clk-pcc4 {
> + nvidia,pins = "touch_clk_pcc4";
> + nvidia,function = "rsvd2";
> + nvidia,pull = <TEGRA_PIN_PULL_UP>;
> + nvidia,tristate = <TEGRA_PIN_ENABLE>;
> + nvidia,enable-input = <TEGRA_PIN_ENABLE>;
> + };
> + };
> +
> + pinmux@2430028 {
> + status = "okay";
> + soc-gpio41-pq5 {
[Severity: High]
Is it intended to create standalone nodes at the exact register offsets of
the individual pins (pinmux@c302000 and pinmux@2430028), instead of placing
them as subnodes under the main pinctrl controllers (which reside at
pinmux@c300000 and pinmux@2430000 in tegra194.dtsi)?
Because they are standalone nodes and lack a pinctrl-0 reference, the pinctrl
driver won't parse them, which will cause these pinmux configurations to be
ignored.
[ ... ]
> + /* SDMMC3 for external user SD card slot with dedicated 3.3V power */
> + sdhci@3440000 {
> + vmmc-supply = <&ap2306gn_3v3_sd>;
> + cd-gpios = <&gpio_aon TEGRA194_AON_GPIO(CC, 4) GPIO_ACTIVE_HIGH>;
> + status = "okay";
> + };
[Severity: High]
In the upstream tegra194.dtsi, the SDMMC3 controller is defined as
mmc@3440000.
Does using sdhci@3440000 here create a new, inert dummy node instead of
overriding the existing mmc@3440000 node? This would leave the actual
controller in its default disabled state.
> +
> + /* Disable fan and tachometer hardware not populated on SE70 carrier board */
> + pwm-fan {
> + status = "disabled";
> + };
[Severity: High]
In tegra194-p3509-0000.dtsi, the pwm-fan node is located at the root of the
device tree (/pwm-fan).
Since this override is nested inside /bus@0/, doesn't this create a new dummy
node at /bus@0/pwm-fan while leaving the actual root /pwm-fan node enabled?
> + thermal-fan-est {
> + status = "disabled";
> + };
> + tachometer@39c0000 {
> + status = "disabled";
> + };
[Severity: Medium]
It looks like nodes such as thermal-fan-est, tachometer@39c0000,
generic-pwm-tachometer, spi@3210000, and spi@3230000 do not exist in the
upstream tegra194 device tree sources.
Does overriding them here just create new dummy disabled nodes instead of
affecting real hardware?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626033418.520762-1-lijq9@lenovo.com?part=2
^ 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