* 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
* Re: [PATCH v6 5/8] clk: qcom: tcsrcc-glymur: Add Mahua QREF regulator support
From: Qiang Yu @ 2026-06-26 3:53 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <cd7619b6-a428-4ad3-9926-52b846953634@oss.qualcomm.com>
On Mon, Jun 22, 2026 at 03:03:39PM +0200, Konrad Dybcio wrote:
> On 6/22/26 2:49 PM, Qiang Yu wrote:
> > On Mon, Jun 22, 2026 at 01:35:45PM +0200, Konrad Dybcio wrote:
> >> On 6/22/26 7:11 AM, Qiang Yu wrote:
> >>> Mahua is based on Glymur but uses a different QREF topology, requiring
> >>> distinct regulator lists and clock descriptors for its PCIe clock
> >>> references.
> >>>
> >>> Add mahua-specific regulator arrays and clk descriptor table, and use
> >>> match_data to select the correct descriptor table per compatible string at
> >>> probe time.
> >>>
> >>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
> >>> ---
>
> [...]
>
> >> You're also missing PCIe_1_CLKREF_EN (+0x48) (for PCIe5)
> >> which goes through CXO1_>TX->RPT0->RPT1->RPT2->RX2
> >
> > I have removed PCIe_1_CLKREF_EN in dts node because PCIe5 PHY doesn't
> > require QREF. So I didn't provide its structure here.
>
> I don't quite get what you mean. I see that it is there in the graph
I double-checked with the HW team — QREF is not required for CXO0. In TCSR
HPG, I think the QREF components you are seeing are in an old version
diagram, but it says the QREF for CXO0 will be removed. In the updated
diagram, PCIe5, USB2_0, USB2_1, USB4_0 and USB4_1 PHYs get refclk directly
from CXO0.
In theory, we don't need to vote clkref_en and QREF LDOs for these PHY
instances, and I got confirmation from the PCIe HW team for PCIe5 PHY.
I also compared the description of the TCSR_CLKREF_EN register between
glymur and mahua on ipcatlog. Unfortunately, only
TCSR_USB4_1_CLKREF_EN_USB4_ENABLE is marked as "not in use". I believe
this is because these registers are not documented well in ipcatlog.
So I think part of the regulator lists you commented for USB instances is
not required, and their dts node also can to be changed to use CXO as
refclk instead of TCSR_CLKREF_EN. But the mapping between the USB instance
names in the QREF diagram and the TCSR_CLKREF_EN registers is not clear —
I cannot find TCSR_USB4_0_CLKREF_EN_USB4_ENABLE, but there is a USB4_0 PHY
in the diagram. Can we leave the USB regulator list as NULL or we just
add them as it is harmless?
- Qaing Yu
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: eliza: Add PCIe PHY and controller nodes
From: Krishna Chaitanya Chundru @ 2026-06-26 4:16 UTC (permalink / raw)
To: Abel Vesa
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <rnwgxeuz6t6cpbcrmcggqtzsfjnur6kmkttgymp6cbglzjva5v@q4cyoq62p3yp>
On 6/25/2026 3:42 PM, Abel Vesa wrote:
> On 26-06-10 17:40:09, Krishna Chaitanya Chundru wrote:
>> Eliza supports two PCIe instances: one 8GT/s x1 (PCIe0) and one 8GT/s x2
>> (PCIe1). Add PCIe controller and PHY nodes for both instances, and update
>> the GCC clock references to use the newly added PHY nodes instead of
>> placeholder zeros.
>>
>> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
>> ---
>> This patch depends on https://lore.kernel.org/all/20260608-eliza-v3-0-9bdeb7434b28@oss.qualcomm.com/
>> ---
>> arch/arm64/boot/dts/qcom/eliza.dtsi | 359 +++++++++++++++++++++++++++++++++++-
>> 1 file changed, 357 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/eliza.dtsi b/arch/arm64/boot/dts/qcom/eliza.dtsi
>> index 7e97361a5dc5..2a51da62270d 100644
>> --- a/arch/arm64/boot/dts/qcom/eliza.dtsi
>> +++ b/arch/arm64/boot/dts/qcom/eliza.dtsi
>> @@ -610,8 +610,8 @@ gcc: clock-controller@100000 {
>>
>> clocks = <&bi_tcxo_div2>,
>> <&sleep_clk>,
>> - <0>,
>> - <0>,
>> + <&pcie0_phy>,
>> + <&pcie1_phy>,
>> <&ufs_mem_phy 0>,
>> <&ufs_mem_phy 1>,
>> <&ufs_mem_phy 2>,
>> @@ -716,6 +716,361 @@ mmss_noc: interconnect@1780000 {
>> #interconnect-cells = <2>;
>> };
>>
>> + pcie0: pcie@1c00000 {
>> + device_type = "pci";
>> + compatible = "qcom,eliza-pcie", "qcom,pcie-sm8550";
>> + reg = <0 0x01c00000 0 0x3000>,
>> + <0 0x40000000 0 0xf1d>,
>> + <0 0x40000f20 0 0xa8>,
>> + <0 0x40001000 0 0x1000>,
>> + <0 0x40100000 0 0x100000>,
>> + <0 0x01c03000 0 0x1000>;
>> + reg-names = "parf",
>> + "dbi",
>> + "elbi",
>> + "atu",
>> + "config",
>> + "mhi";
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + ranges = <0x01000000 0 0x00000000 0 0x40200000 0 0x100000>,
>> + <0x02000000 0 0x40300000 0 0x40300000 0 0x3d00000>;
>> +
>> + interrupts = <GIC_SPI 376 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 535 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 536 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 537 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 540 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 653 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 370 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "msi0",
>> + "msi1",
>> + "msi2",
>> + "msi3",
>> + "msi4",
>> + "msi5",
>> + "msi6",
>> + "msi7",
>> + "global";
>> +
>> + clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
>> + <&gcc GCC_PCIE_0_CFG_AHB_CLK>,
>> + <&gcc GCC_PCIE_0_MSTR_AXI_CLK>,
>> + <&gcc GCC_PCIE_0_SLV_AXI_CLK>,
>> + <&gcc GCC_PCIE_0_SLV_Q2A_AXI_CLK>,
>> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
>> + <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
>> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
>> + clock-names = "aux",
>> + "cfg",
>> + "bus_master",
>> + "bus_slave",
>> + "slave_q2a",
>> + "ddrss_sf_tbu",
>> + "noc_aggr",
>> + "cnoc_sf_axi";
>> +
>> + resets = <&gcc GCC_PCIE_0_BCR>,
>> + <&gcc GCC_PCIE_0_LINK_DOWN_BCR>;
>> + reset-names = "pci",
>> + "link_down";
>> +
>> + interconnects = <&pcie_noc MASTER_PCIE_0 QCOM_ICC_TAG_ALWAYS
>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
>> + &cnoc_main SLAVE_PCIE_0 QCOM_ICC_TAG_ACTIVE_ONLY>;
>> + interconnect-names = "pcie-mem",
>> + "cpu-pcie";
>> +
>> + power-domains = <&gcc GCC_PCIE_0_GDSC>;
>> +
>> + operating-points-v2 = <&pcie0_opp_table>;
>> +
>> + iommu-map = <0 &apps_smmu 0x1480 0x1>,
>> + <0x100 &apps_smmu 0x1481 0x1>;
>> +
>> + interrupt-map = <0 0 0 1 &intc 0 0 0 564 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 2 &intc 0 0 0 565 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 3 &intc 0 0 0 566 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 4 &intc 0 0 0 567 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-map-mask = <0 0 0 0x7>;
>> + #interrupt-cells = <1>;
>> +
>> + linux,pci-domain = <0>;
>> + num-lanes = <1>;
>> + bus-range = <0 0xff>;
>> +
>> + dma-coherent;
>> +
> No pinctrl states?
>
>> +
>> + pcie1: pcie@1c08000 {
>> + device_type = "pci";
>> + compatible = "qcom,eliza-pcie", "qcom,pcie-sm8550";
>> + reg = <0 0x01c08000 0 0x3000>,
>> + <0 0x44000000 0 0xf1d>,
>> + <0 0x44000f20 0 0xa8>,
>> + <0 0x44001000 0 0x1000>,
>> + <0 0x44100000 0 0x100000>,
>> + <0 0x01c0b000 0 0x1000>;
>> + reg-names = "parf",
>> + "dbi",
>> + "elbi",
>> + "atu",
>> + "config",
>> + "mhi";
>> + #address-cells = <3>;
>> + #size-cells = <2>;
>> + ranges = <0x01000000 0 0x00000000 0 0x44200000 0 0x100000>,
>> + <0x02000000 0 0x44300000 0 0x44300000 0 0x3d00000>;
>> +
>> + interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 142 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 143 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 144 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 145 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
>> + <GIC_SPI 140 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-names = "msi0",
>> + "msi1",
>> + "msi2",
>> + "msi3",
>> + "msi4",
>> + "msi5",
>> + "msi6",
>> + "msi7",
>> + "global";
>> +
>> + clocks = <&gcc GCC_PCIE_1_AUX_CLK>,
>> + <&gcc GCC_PCIE_1_CFG_AHB_CLK>,
>> + <&gcc GCC_PCIE_1_MSTR_AXI_CLK>,
>> + <&gcc GCC_PCIE_1_SLV_AXI_CLK>,
>> + <&gcc GCC_PCIE_1_SLV_Q2A_AXI_CLK>,
>> + <&gcc GCC_DDRSS_PCIE_SF_QTB_CLK>,
>> + <&gcc GCC_AGGRE_NOC_PCIE_AXI_CLK>,
>> + <&gcc GCC_CNOC_PCIE_SF_AXI_CLK>;
>> + clock-names = "aux",
>> + "cfg",
>> + "bus_master",
>> + "bus_slave",
>> + "slave_q2a",
>> + "ddrss_sf_tbu",
>> + "noc_aggr",
>> + "cnoc_sf_axi";
>> +
>> + resets = <&gcc GCC_PCIE_1_BCR>,
>> + <&gcc GCC_PCIE_1_LINK_DOWN_BCR>;
>> + reset-names = "pci",
>> + "link_down";
>> +
>> + interconnects = <&pcie_noc MASTER_PCIE_1 QCOM_ICC_TAG_ALWAYS
>> + &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
>> + <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
>> + &cnoc_main SLAVE_PCIE_1 QCOM_ICC_TAG_ACTIVE_ONLY>;
>> + interconnect-names = "pcie-mem",
>> + "cpu-pcie";
>> +
>> + power-domains = <&gcc GCC_PCIE_1_GDSC>;
>> +
>> + operating-points-v2 = <&pcie1_opp_table>;
>> +
>> + iommu-map = <0 &apps_smmu 0x1400 0x1>,
>> + <0x100 &apps_smmu 0x1401 0x1>;
>> +
>> + interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>,
>> + <0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>;
>> + interrupt-map-mask = <0 0 0 0x7>;
>> + #interrupt-cells = <1>;
>> +
>> + linux,pci-domain = <1>;
>> + num-lanes = <2>;
>> + bus-range = <0 0xff>;
>> +
>> + dma-coherent;
> No pinctrl states?
As we are adding perst & wake gpio's in board specific file, it is better to
add the pincntrl also
there only.
- Krishna Chaitanya.
^ permalink raw reply
* [RFC PATCH 0/2] Add Lenovo ThinkEdge SE70 carrier board support
From: Jiqi Li @ 2026-06-26 1:09 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.
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 | 167 ++++++++++++++++++
3 files changed, 172 insertions(+)
create mode 100644 arch/arm64/boot/dts/nvidia/tegra194-lenovo-thinkedge-se70.dts
--
2.43.0
^ permalink raw reply
* [PATCH 1/2] dt-bindings: net: altr,socfpga-stmmac: add more interrupts for Agilex5
From: Dinh Nguyen @ 2026-06-26 4:25 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt
Cc: dinguyen, devicetree, muhammad.nazim.amirul.nazle.asmade
The stmmac hardware on Agilex5 supports 8 TX/RX queue pairs and is
dma-coherent. Update the schema to handle the hardware differences
between SoC variants.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
.../bindings/net/altr,socfpga-stmmac.yaml | 51 +++++++++++++++++--
1 file changed, 46 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
index fc445ad5a1f1..9bae17688992 100644
--- a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
+++ b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
@@ -62,12 +62,28 @@ properties:
- const: stmmaceth
- const: ptp_ref
- interrupts:
- maxItems: 1
-
interrupt-names:
- items:
- - const: macirq
+ oneOf:
+ - items:
+ - const: macirq
+ - items:
+ - const: macirq
+ - const: tx-queue-0
+ - const: tx-queue-1
+ - const: tx-queue-2
+ - const: tx-queue-3
+ - const: tx-queue-4
+ - const: tx-queue-5
+ - const: tx-queue-6
+ - const: tx-queue-7
+ - const: rx-queue-0
+ - const: rx-queue-1
+ - const: rx-queue-2
+ - const: rx-queue-3
+ - const: rx-queue-4
+ - const: rx-queue-5
+ - const: rx-queue-6
+ - const: rx-queue-7
iommus:
minItems: 1
@@ -149,10 +165,35 @@ required:
- clocks
- clock-names
- altr,sysmgr-syscon
+ - interrupts
+ - interrupt-names
allOf:
- $ref: snps,dwmac.yaml#
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: altr,socfpga-stmmac-agilex5
+ then:
+ properties:
+ interrupts:
+ minItems: 17
+ maxItems: 17
+
+ interrupt-names:
+ minItems: 17
+ maxItems: 17
+
+ dma-coherent: true
+ else:
+ properties:
+ interrupts:
+ minItems: 1
+
+ dma-coherent: false
+
unevaluatedProperties: false
examples:
--
2.42.0.411.g813d9a9188
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: socfpga: agilex5: update channel interrupts for gmac1 and gmac2
From: Dinh Nguyen @ 2026-06-26 4:25 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt
Cc: dinguyen, devicetree, muhammad.nazim.amirul.nazle.asmade
In-Reply-To: <20260626042541.1091774-1-dinguyen@kernel.org>
Populate the gmac1 and gmac2 interrupt list to support 8 TX/RX queue
pairs.
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
---
.../arm64/boot/dts/intel/socfpga_agilex5.dtsi | 72 +++++++++++++++++--
1 file changed, 68 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
index 2096decb5655..f54767d1526e 100644
--- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
+++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
@@ -702,8 +702,40 @@ gmac1: ethernet@10820000 {
compatible = "altr,socfpga-stmmac-agilex5",
"snps,dwxgmac-2.10";
reg = <0x10820000 0x3500>;
- interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "macirq";
+ interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 209 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 210 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 211 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 212 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 214 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 215 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 216 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 218 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 219 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 220 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 221 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 222 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 223 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq",
+ "tx-queue-0",
+ "tx-queue-1",
+ "tx-queue-2",
+ "tx-queue-3",
+ "tx-queue-4",
+ "tx-queue-5",
+ "tx-queue-6",
+ "tx-queue-7",
+ "rx-queue-0",
+ "rx-queue-1",
+ "rx-queue-2",
+ "rx-queue-3",
+ "rx-queue-4",
+ "rx-queue-5",
+ "rx-queue-6",
+ "rx-queue-7";
resets = <&rst EMAC1_RESET>, <&rst EMAC1_OCP_RESET>;
reset-names = "stmmaceth", "ahb";
clocks = <&clkmgr AGILEX5_EMAC1_CLK>,
@@ -816,8 +848,40 @@ gmac2: ethernet@10830000 {
compatible = "altr,socfpga-stmmac-agilex5",
"snps,dwxgmac-2.10";
reg = <0x10830000 0x3500>;
- interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "macirq";
+ interrupts = <GIC_SPI 224 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 225 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 226 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 228 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 229 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 230 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 231 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 233 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 234 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 235 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 236 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 237 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 238 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 239 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 240 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "macirq",
+ "tx-queue-0",
+ "tx-queue-1",
+ "tx-queue-2",
+ "tx-queue-3",
+ "tx-queue-4",
+ "tx-queue-5",
+ "tx-queue-6",
+ "tx-queue-7",
+ "rx-queue-0",
+ "rx-queue-1",
+ "rx-queue-2",
+ "rx-queue-3",
+ "rx-queue-4",
+ "rx-queue-5",
+ "rx-queue-6",
+ "rx-queue-7";
resets = <&rst EMAC2_RESET>, <&rst EMAC2_OCP_RESET>;
reset-names = "stmmaceth", "ahb";
clocks = <&clkmgr AGILEX5_EMAC2_CLK>,
--
2.42.0.411.g813d9a9188
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: net: altr,socfpga-stmmac: add more interrupts for Agilex5
From: sashiko-bot @ 2026-06-26 4:31 UTC (permalink / raw)
To: Dinh Nguyen; +Cc: conor+dt, devicetree, robh
In-Reply-To: <20260626042541.1091774-1-dinguyen@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Removing the top-level constraints for `interrupts` and `interrupt-names` without restoring them in the `else` block allows older variants to incorrectly pass schema validation with up to 17 interrupts.
--
commit b9bb703e842480b5efde889d362af4d3e53520cb
Author: Dinh Nguyen <dinguyen@kernel.org>
dt-bindings: net: altr,socfpga-stmmac: add more interrupts for Agilex5
The stmmac hardware on Agilex5 supports 8 TX/RX queue pairs and is
dma-coherent. This commit updates the schema to handle the hardware
differences between SoC variants.
> diff --git a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
> index fc445ad5a1f1a..9bae17688992c 100644
> --- a/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
> +++ b/Documentation/devicetree/bindings/net/altr,socfpga-stmmac.yaml
[ ... ]
> @@ -62,12 +62,28 @@ properties:
> - const: stmmaceth
> - const: ptp_ref
>
> - interrupts:
> - maxItems: 1
> -
> interrupt-names:
[ ... ]
> @@ -149,10 +165,35 @@ required:
[ ... ]
> allOf:
> - $ref: snps,dwmac.yaml#
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: altr,socfpga-stmmac-agilex5
> + then:
> + properties:
> + interrupts:
> + minItems: 17
> + maxItems: 17
> +
> + interrupt-names:
> + minItems: 17
> + maxItems: 17
> +
> + dma-coherent: true
> + else:
> + properties:
> + interrupts:
> + minItems: 1
[Severity: Medium]
Does this missing maxItems constraint allow older variants to incorrectly pass
schema validation with up to 17 interrupts?
Since the top-level maxItems: 1 constraint was removed for interrupts, this
else block applies to all non-Agilex5 variants but only enforces minItems: 1.
Because there are no top-level restrictions stopping it, device trees for
older variants (e.g., altr,socfpga-stmmac-a10-s10) could specify multiple
interrupts and matching interrupt-names without triggering a schema validation
error.
Should maxItems: 1 for interrupts and a matching constraint for
interrupt-names be added to this else block to enforce the original strict
hardware constraints for prior generations?
> +
> + dma-coherent: false
> +
> unevaluatedProperties: false
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626042541.1091774-1-dinguyen@kernel.org?part=1
^ permalink raw reply
* Re: [PATCH 2/2] arm64: dts: socfpga: agilex5: update channel interrupts for gmac1 and gmac2
From: sashiko-bot @ 2026-06-26 4:31 UTC (permalink / raw)
To: Dinh Nguyen; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260626042541.1091774-2-dinguyen@kernel.org>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incomplete DT update: gmac0 is left with an invalid interrupt count that will fail dtbs validation.
--
commit ce31f4c657e3508e9aef68e6da54a09c1d243026
Author: Dinh Nguyen <dinguyen@kernel.org>
arm64: dts: socfpga: agilex5: update channel interrupts for gmac1 and gmac2
Populate the gmac1 and gmac2 interrupt list to support 8 TX/RX queue
pairs.
> diff --git a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> index 02e62d954e949..140e4bf9fb155 100644
> --- a/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> +++ b/arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi
> @@ -670,8 +670,40 @@ gmac1: ethernet@10820000 {
> compatible = "altr,socfpga-stmmac-agilex5",
> "snps,dwxgmac-2.10";
> reg = <0x10820000 0x3500>;
[Severity: Medium]
Should gmac0 also be updated to include 17 interrupts?
Looking earlier in the same file, gmac0 uses the exact same
"altr,socfpga-stmmac-agilex5" compatible string, but this patch
leaves it configured with only a single interrupt:
arch/arm64/boot/dts/intel/socfpga_agilex5.dtsi:
gmac0: ethernet@10810000 {
compatible = "altr,socfpga-stmmac-agilex5",
"snps,dwxgmac-2.10";
reg = <0x10810000 0x3500>;
interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>;
interrupt-names = "macirq";
...
}
Since the device tree binding strictly requires 17 interrupts for this
specific compatible string, won't skipping gmac0 result in dtbs_check
validation errors and leave its queues without dedicated interrupts at
runtime?
> - interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>;
> - interrupt-names = "macirq";
> + interrupts = <GIC_SPI 207 IRQ_TYPE_LEVEL_HIGH>,
> + <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>,
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260626042541.1091774-1-dinguyen@kernel.org?part=2
^ permalink raw reply
* Re: [PATCH v5 1/7] dt-bindings: display: verisilicon,dc: generalize for single-output variants
From: Icenowy Zheng @ 2026-06-26 5:27 UTC (permalink / raw)
To: Conor Dooley, Joey Lu
Cc: maarten.lankhorst, mripard, tzimmermann, airlied, simona, robh,
krzk+dt, conor+dt, ychuang3, schung, yclu4, dri-devel, devicetree,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260625-bobbing-annotate-d1c4d6874ee2@spud>
在 2026-06-25四的 17:33 +0100，Conor Dooley写道：
> On Thu, Jun 25, 2026 at 05:44:43PM +0800, Joey Lu wrote:
> > The verisilicon,dc binding was originally written for the T-Head
> > TH1520
> > SoC carrying a DC8200, and hard-codes five clocks, three resets and
> > two
> > output ports.
> >
> > Add the Nuvoton MA35D1 DCUltraLite (nuvoton,ma35d1-dcu) to the
> > binding.
> > The DCUltraLite uses only two clocks (core, pix0) and one reset
> > (core),
> > with a single output port.
> >
> > Use allOf/if blocks to express per-variant constraints rather than
> > hard-coding the DC8200 topology at the top level. Each
> > compatible's
> > block constrains the clock and reset item counts; the nuvoton block
> > additionally overrides clock-names to the two names it actually
> > uses.
> >
> > Signed-off-by: Joey Lu <a0987203069@gmail.com>
> > ---
> > .../bindings/display/verisilicon,dc.yaml | 57
> > +++++++++++++++++++
> > 1 file changed, 57 insertions(+)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > index 9dc35ab973f2..1e751f3c7ce8 100644
> > --- a/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > +++ b/Documentation/devicetree/bindings/display/verisilicon,dc.yaml
> > @@ -17,6 +17,7 @@ properties:
> > items:
> > - enum:
> > - thead,th1520-dc8200
> > + - nuvoton,ma35d1-dcu
> > - const: verisilicon,dc # DC IPs have discoverable
> > ID/revision registers
> >
> > reg:
> > @@ -77,6 +78,62 @@ required:
> > - clock-names
> > - ports
> >
> > +allOf:
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: thead,th1520-dc8200
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 5
> > + maxItems: 5
> > +
> > + clock-names:
> > + minItems: 5
> > + maxItems: 5
>
> All the maxItems here repeat the maximum constraint and do nothing.
>
> Since you didn't change the minimum constraint at the top level, your
> minItems also do nothing.
>
> > +
> > + resets:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + reset-names:
> > + minItems: 3
> > + maxItems: 3
> > +
> > + required:
> > + - resets
> > + - reset-names
>
> Both conditional sections have this, but the original binding doesn't
> require these for the thead device. This is a functional change
> therefore and shouldn't be in a patch calling itself "generalise for
> single ended variants".
Well yes they're required.
Should I send a patch adding the `thead,th1520-dc8200` part of the
schema?
>
> FWIW, adding your new compatible shouldn't really be in a patch with
> that subject either, it really should say "add support for nuvoton
> ma35d1" or something.
>
> > +
> > + - if:
> > + properties:
> > + compatible:
> > + contains:
> > + const: nuvoton,ma35d1-dcu
> > + then:
> > + properties:
> > + clocks:
> > + minItems: 2
>
> Anything that updates the minimum constraint should be done at the
> top
> level of this schema. The conditional section should then tighten the
> constraint, in this case that means only having maxItems.
>
> > + maxItems: 2
> > +
> > + clock-names:
> > + items:
> > + - const: core
> > + - const: pix0
>
> Does this even work when the top level schema thinks clock 2 should
> be
> called axi?
>
> > +
> > + resets:
> > + minItems: 1
> > + maxItems: 1
> > +
> > + reset-names:
> > + items:
> > + - const: core
>
> This is just maxItems: 1.
Well the implicit rules of DT binding schemas are quite weird...
Thanks,
Icenowy
>
> pw-bot: changes-requested
>
> Thanks,
> Conor.
>
> > +
> > + required:
> > + - resets
> > + - reset-names
> > +
> > additionalProperties: false
> >
> > examples:
> > --
> > 2.43.0
> >
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: input: syna,rmi4: Document syna,rmi4-s3706b
From: Dmitry Torokhov @ 2026-06-26 5:37 UTC (permalink / raw)
To: david
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jason A. Donenfeld, Matthias Schiffer, Vincent Huang,
Bjorn Andersson, Konrad Dybcio, linux-input, devicetree,
linux-kernel, linux-arm-msm, phone-devel, Krzysztof Kozlowski
In-Reply-To: <20260523-synaptics-rmi4-dt-v2-1-0645122babdc@ixit.cz>
On Sat, May 23, 2026 at 11:45:34AM +0200, David Heidelberg via B4 Relay wrote:
> From: David Heidelberg <david@ixit.cz>
>
> Mostly irrelevant for authentic Synaptics touchscreens, but very important
> for applying workarounds to cheap TS knockoffs.
>
> These knockoffs work well with the downstream driver, and since the user
> has no way to distinguish them, later in this patch set, we introduce
> workarounds to ensure they function as well as possible.
>
> Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
> Signed-off-by: David Heidelberg <david@ixit.cz>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: qcom: sdm845-oneplus: Update compatible to include model
From: Dmitry Torokhov @ 2026-06-26 5:38 UTC (permalink / raw)
To: David Heidelberg
Cc: Krzysztof Kozlowski, Krzysztof Kozlowski, Konrad Dybcio,
Rob Herring, Conor Dooley, Jason A. Donenfeld, Matthias Schiffer,
Vincent Huang, Bjorn Andersson, Konrad Dybcio, linux-input,
devicetree, linux-kernel, linux-arm-msm, phone-devel
In-Reply-To: <32affded-bae2-46c4-a702-2054fbfe46a8@ixit.cz>
On Thu, Jun 25, 2026 at 08:39:15PM +0200, David Heidelberg wrote:
> On 25/06/2026 18:57, Dmitry Torokhov wrote:
> > Hi Krzysztof,
> >
> > On Thu, Jun 25, 2026 at 10:23:54AM +0200, Krzysztof Kozlowski wrote:
> > > On 25/06/2026 06:53, Dmitry Torokhov wrote:
> > > > On Wed, Jun 24, 2026 at 04:37:25PM +0200, David Heidelberg wrote:
> > > > > On 24/06/2026 06:28, Dmitry Torokhov wrote:
> > > > > > Hi David,
> > > > > >
> > > > > > On Sun, Jun 21, 2026 at 07:11:45PM +0200, David Heidelberg wrote:
> > > > > > > On 28/05/2026 00:13, David Heidelberg wrote:
> > > > > > > > On 27/05/2026 23:56, Dmitry Torokhov wrote:
> > > > > > > > > Hi David,
> > > > > > > > >
> > > > > > > > > On Sat, May 23, 2026 at 11:45:35AM +0200, David Heidelberg via B4 Relay wrote:
> > > > > > > > > > From: David Heidelberg <david@ixit.cz>
> > > > > > > > > >
> > > > > > > > > > We know the driver is reporting s3706b, introduce the compatible so we
> > > > > > > > > > can more easily introduce quirks for weird touchscreen replacements in
> > > > > > > > > > followup series.
> > > > > > > > > >
> > > > > > > > > > Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> > > > > > > > > > Signed-off-by: David Heidelberg <david@ixit.cz>
> > > > > > > > > > ---
> > > > > > > > > > arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi | 2 +-
> > > > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > > > >
> > > > > > > > > > diff --git a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > > > > > b/arch/ arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > > > > > index 6b7378cf4d493..148164d456a5a 100644
> > > > > > > > > > --- a/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > > > > > +++ b/arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
> > > > > > > > > > @@ -475,17 +475,17 @@ bq27441_fg: bq27441-battery@55 {
> > > > > > > > > > };
> > > > > > > > > > };
> > > > > > > > > > &i2c12 {
> > > > > > > > > > status = "okay";
> > > > > > > > > > clock-frequency = <400000>;
> > > > > > > > > > synaptics-rmi4-i2c@20 {
> > > > > > > > > > - compatible = "syna,rmi4-i2c";
> > > > > > > > > > + compatible = "syna,rmi4-s3706b", "syna,rmi4-i2c";
> > > > > > > > >
> > > > > > > > > So I believe we established that this device (s3706b) does not in fact
> > > > > > > > > implement rmi4 protocol properly. Why do we have "syna,rmi4-i2c" as a
> > > > > > > > > fallback? Shouldn't it be just "syna,rmi4-s3706b"?
> > > > > > > >
> > > > > > > > The vendor supplies s3706b which does implement the RMI4 properly.
> > > > > > > >
> > > > > > > > The 3rd party replacement impersonating original parts may not implement
> > > > > > > > it properly, but I don't address this issue in this initial submission.
> > > > > > > >
> > > > > > > > With this compatible we know which original part is used by the vendor
> > > > > > > > and installed in the phones, so later we can deduct specific sequences
> > > > > > > > for the replacement aftermarket parts to keep phone touchscreen working
> > > > > > > > same as they do on Android without affecting other devices.
> > > > > > >
> > > > > > > Hello Dmitry.
> > > > > > >
> > > > > > > May I ask what is currently preventing this series from moving forward?
> > > > > > >
> > > > > > > The first version was posted in 2023 [1]. I picked it up again in 2025 [2]
> > > > > > > and am now on the 9th iteration (this patchset). At this point, the series
> > > > > > > has been under discussion for well over a year, with relatively little
> > > > > > > feedback and increasingly long gaps between review rounds.
> > > > > > >
> > > > > > > The current approach is based on the guidance I have received so far,
> > > > > > > including suggestions from the device-tree maintainers. When concerns were
> > > > > > > raised, I tried to address them and rework the series accordingly.
> > > > > > >
> > > > > > > What I am struggling with is understanding what specific issue still needs
> > > > > > > to be resolved before these patches can be accepted. If there are remaining
> > > > > > > requirements, objections to the approach, or technical concerns that I have
> > > > > > > not addressed, I would appreciate having them stated explicitly so I can
> > > > > > > work on them.
> > > > > > >
> > > > > > > I also split out the straightforward, self-contained changes in the hope
> > > > > > > that at least those could progress independently while I continued working
> > > > > > > on any follow-up requirements. However, even those patches do not appear to
> > > > > > > be moving forward.
> > > > > > >
> > > > > > > Could you please clarify what outcome you would like to see from this
> > > > > > > series, and what concrete changes would be required to get it accepted?
> > > > > >
> > > > > > I am still confused about how you want to differentiate between the full
> > > > > > RMI4 support vs the OnePlus flavor. The "syna,rmi4-s3706b", as you
> > > > > > mentioned, implements RMI4 protocol properly, so we do not need to
> > > > > > actually have it documented neither in binding nor in DTS.
> > > > >
> > > > > --- part 1 ---
> > > > >
> > > > > This series addresses identification within device-tree. It's normal
> > > > > recommended practice.
> > > > >
> > > > > If we know, the device ships specific, but **compliant** variant, we just
> > > > > put it as compatible = "more-specific", "less-specific"; in this case
> > > > > "syna,rmi4-s3706b", "syna,rmi4-i2c"
> > > > >
> > > > > This approach is used everywhere. This has nothing to do with after-market parts.
> > > >
> > > > We do this in many cases, sometimes when a part has different timings or
> > > > maybe additional functionality compared to the base model.
> > >
> > > Generic expectation is to have always dedicated front compatible for
> > > every device. rmi4-i2c is not really specific enough, more like a
> > > family, thus a specific device compatible is essential by the DT rules.
> >
> > Essential in what way? What will break if such compatible is not there?
> > We have lived without it for many years and will continue live happily
> > without it for years to come.
>
> Hi Dmitry, Krzystof,
>
> Device tree should describe the hardware, rmi4-i2c isn't the exact model of
> hardware used, the real hardware is Synaptics S3706B. Device-tree should,
> where possible, describe the actual hardware used.
>
> >
> > We keep having this conversation each time there is self-describing
> > protocol that does not require knowledge of a specific part number:
> > i2c-hid, rmi4, spi-hid coming over soon.
>
> While the protocol doesn't require this knowledge, where is the issue
> provide the model, at least in the places where we know it?
>
> Does it making things worse to describe hardware in more detail?
OK, I applied the binding change, the dts change should go through some
other tree.
Thanks.
--
Dmitry
^ 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