* Re: [PATCH v3 5/5] arm64: dts: qcom: Add Shikra EVK boards
From: Komal Bajaj @ 2026-05-24 13:07 UTC (permalink / raw)
To: sashiko-reviews
Cc: vkoul, devicetree, linux-phy, conor+dt, neil.armstrong, olteanv,
robh
In-Reply-To: <20260522193943.660811F000E9@smtp.kernel.org>
On 5/23/2026 1:09 AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The device tree file shikra-cqs-evk.dts incorrectly includes the CQM SoM device tree (shikra-cqm-som.dtsi) instead of the expected CQS SoM device tree (shikra-cqs-som.dtsi).
> --
>
> commit cb9ff9c76f4ee019113138237f57794fa621d71f
> Author: Komal Bajaj <komal.bajaj@oss.qualcomm.com>
>
> arm64: dts: qcom: Add Shikra EVK boards
>
> This commit adds device trees for the Shikra EVK platform, combining
> Shikra SoM variants with a common carrier board. It introduces three EVK
> boards: CQM (retail with modem), CQS (retail without modem), and IQS
> (industrial without modem).
>
> [ ... ]
>
>> diff --git a/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
>> new file mode 100644
>> index 0000000000000..b3f19a64d7aed
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/qcom/shikra-cqs-evk.dts
>> @@ -0,0 +1,40 @@
>> +// SPDX-License-Identifier: BSD-3-Clause
>> +/*
>> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include "shikra-cqm-som.dtsi"
> [Severity: High]
> The commit message states that shikra-cqs-evk.dts pairs with the CQ2390S
> SoM (retail, without modem). Does this file include the incorrect SoM dtsi?
>
> Including shikra-cqm-som.dtsi here seems like it would pull in the hardware
> description of the modem-enabled CQM SoM instead of the expected CQS variant.
>
> Could this cause boot issues or lead to loading drivers for hardware that
> isn't actually present on the CQS board?
Already discussed, refer:
https://lore.kernel.org/all/4787d5f9-601a-4d27-91d3-33216ee6f64d@oss.qualcomm.com/
Thanks
Komal
>
>> +#include "shikra-evk.dtsi"
>> +
>> +/ {
>> + model = "Qualcomm Technologies, Inc. Shikra CQS EVK";
>> + compatible = "qcom,shikra-cqs-evk", "qcom,shikra-cqs-som", "qcom,shikra";
> [ ... ]
>
^ permalink raw reply
* Re: [PATCH] arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
From: sashiko-bot @ 2026-05-24 13:04 UTC (permalink / raw)
To: Aleksander Jan Bajkowski; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260524124456.350659-1-olek2@wp.pl>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Incorrectly marking the crypto engine as `dma-coherent` on the non-coherent Armada 37xx SoC bypasses necessary software cache maintenance, leading to silent data corruption.
--
commit cb353bcdff0077f7b4e65e2e644ffb6462f3946f
Author: Aleksander Jan Bajkowski <olek2@wp.pl>
Subject: arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
This commit marks the crypto engine (EIP97) on the Armada 37xx SoC as
dma-coherent to skip software cache synchronization.
> diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> index 360fc24fdde22..8418777042b85 100644
> --- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> +++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
> @@ -437,6 +437,7 @@ crypto: crypto@90000 {
> interrupt-names = "ring0", "ring1", "ring2",
> "ring3", "eip", "mem";
> clocks = <&nb_periph_clk 15>;
> + dma-coherent;
[Severity: Critical]
Could this bypass necessary software cache maintenance on the non-coherent
Armada 37xx SoC?
Unlike the Armada 7k/8k, the Armada 37xx SoC does not appear to support
hardware I/O cache coherency for its peripheral interconnect.
Adding the dma-coherent property to the crypto node instructs the DMA API to
skip software cache maintenance, such as cleaning dirty CPU cache lines to
RAM before DMA transmission and invalidating them before CPU reads.
The observed performance improvement likely comes from bypassing these
essential CPU operations.
Without cache maintenance, could the crypto engine read stale data from
memory, and the CPU read stale data from its caches, resulting in silent
cryptographic data corruption?
Passing testmgr selftests is a common false positive for this regression,
as small test payloads often happen to be clean in the cache or benefit
from incidental cache states during early boot.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260524124456.350659-1-olek2@wp.pl?part=1
^ permalink raw reply
* Re: [PATCH v3] dt-bindings: clock: via,vt8500: Convert to DT Schema
From: Rob Herring (Arm) @ 2026-05-24 12:55 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: mturquette, conor+dt, krzk+dt, linux-kernel, skhan, devicetree,
sboyd, linux-rtc, me
In-Reply-To: <20260524111813.39810-1-challauday369@gmail.com>
On Sun, 24 May 2026 16:47:57 +0530, Udaya Kiran Challa wrote:
> Convert the VIA/Wondermedia VT8500 and Wondermedia WM8xxx series SoCs clock
> controller binding from the legacy text format to DT schema.
>
> Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
> ---
> Changelog:
> Changes since v2:
> - Drop redundant description for clocks
> - Disable reg property for device clocks
> - Fix schema hierarchy to match actual DTS structure
>
> Link to v2:https://lore.kernel.org/all/20260521170810.19702-1-challauday369@gmail.com/
>
> Changes since v1:
> - Add default value for divisor-mask
> - Add required properties compatible and model
> - Fix example node name
> - Update example size cells and reg value
>
> Link to v1:https://lore.kernel.org/all/20260520025131.17772-1-challauday369@gmail.com/
> ---
> .../bindings/clock/via,vt8500-clock.yaml | 179 ++++++++++++++++++
> .../devicetree/bindings/clock/vt8500.txt | 74 --------
> 2 files changed, 179 insertions(+), 74 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
> delete mode 100644 Documentation/devicetree/bindings/clock/vt8500.txt
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
Documentation/devicetree/bindings/clock/via,vt8500-clock.example.dtb: /example-0/pmc@d8130000: failed to match any schema with compatible: ['via,vt8500-pmc']
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260524111813.39810-1-challauday369@gmail.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* [PATCH] arm64: dts: marvell: armada-37xx: mark EIP97 as dma-coherent
From: Aleksander Jan Bajkowski @ 2026-05-24 12:44 UTC (permalink / raw)
To: andrew, gregory.clement, sebastian.hesselbarth, robh, krzk+dt,
conor+dt, linux-arm-kernel, devicetree, linux-kernel
Cc: Aleksander Jan Bajkowski
Armada 37xx has coherent bus, similar to Armada 7k/8k. Cache
synchronization consumes a lot of CPU cycles. Enabling coherent DMA
increases IOPS performance up to 4 times. Some numbers:
Data length
Algo MB 16 64 128 256 1024 1424 4096
DES-ECB 1 +21 % +5 % +5 % +7 % +7 % +3 % +20 %
AES-ECB-128 1 +21 % +6 % +6 % +6 % +9 % +8 % +22 %
AES-CBC-128 1 +21 % +5 % +5 % +5 % +6 % +7 % +23 %
AES-CBC-256 1 +23 % +7 % +8 % +6 % +11 % +13 % +20 %
Data length
Algo MB 16 64 256 512 1024 1420 4096 8192
AES-GCM-128 1 +44 % +42 % +31 % +32 % +27 % +30 % +32 % +30 %
AES-GCM-128 8 +319 % +326 % +163 % +148 % +75 % +72 % +74 % +41 %
AES-GCM-128 4096 +123 % +128 % +90 % +83 % +116 % +59 % +38 % +28 %
Data length
Algo MB 16 64 256 1024 2048 4096 8192
MD5 1 +21 % +15 % +29 % +25 % +50 % +16 % +20 %
SHA1 1 +24 % +22 % +27 % +22 % +18 % +20 % +20 %
SHA256 1 +30 % +24 % +25 % +26 % +21 % +41 % +19 %
SHA512 1 +4 % +3 % +8 % +10 % +24 % +10 % +11 %
Tested on Armada 3720. Platform passes testmgr selftests.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
---
arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index 360fc24fdde2..8418777042b8 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -437,6 +437,7 @@ crypto: crypto@90000 {
interrupt-names = "ring0", "ring1", "ring2",
"ring3", "eip", "mem";
clocks = <&nb_periph_clk 15>;
+ dma-coherent;
};
rwtm: mailbox@b0000 {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] ASoC: dt-bindings: sound: asahi-kasei,ak4118: Convert DT schema
From: sashiko-bot @ 2026-05-24 12:44 UTC (permalink / raw)
To: Manish Baing; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260524123415.108301-1-manishbaing2789@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Critical] The schema conversion incorrectly replaces the 'irq-gpios' property with 'interrupts', breaking compatibility with existing device trees and the driver.
- [High] The 'reset-gpios' and 'irq-gpios' properties are missing from the YAML 'required' list, weakening schema constraints.
--
commit 0e4f9fd8065be8e0dd8e4f0d56bb269c25f2d4bb
Author: Manish Baing <manishbaing2789@gmail.com>
ASoC: dt-bindings: sound: asahi-kasei,ak4118: Convert DT schema
Convert the Asahi Kasei AK4118 S/PDIF transceiver bindings from text format
to YAML schema.
> diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4118.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4118.yaml
> new file mode 100644
> index 0000000000000..54cee45ac0513
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4118.yaml
[ ... ]
> @@ -0,0 +1,57 @@
[ ... ]
> + "#sound-dai-cells":
> + const: 0
> +
> + interrupts:
> + maxItems: 1
[Severity: Critical]
Does changing the property from irq-gpios to interrupts cause a regression
for existing device trees and the driver?
Looking at the original text binding, irq-gpios was specified. The driver in
sound/soc/codecs/ak4118.c fetches the interrupt line as a gpio:
devm_gpiod_get(&i2c->dev, "irq", GPIOD_IN)
Since the schema sets unevaluatedProperties to false, existing device trees
containing irq-gpios will fail validation.
Additionally, if new device trees use interrupts instead, won't the driver
fail during probe due to a missing gpio?
> +
> + reset-gpios:
> + maxItems: 1
> + description: GPIO used for the Reset pin
> +
> +required:
> + - compatible
> + - reg
> + - "#sound-dai-cells"
[Severity: High]
Should reset-gpios and irq-gpios be included in this required list?
The original ak4118.txt binding marked both of these as required properties.
The driver unconditionally calls devm_gpiod_get() for both reset and irq
rather than the optional variants.
Omitting them here could allow incomplete device trees to silently pass
schema validation but still fail at runtime during the driver probe.
> +
> +unevaluatedProperties: false
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260524123415.108301-1-manishbaing2789@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v6 10/10] arm64: dts: Add support for LX2160 Twins board in single configuration
From: Josua Mayer @ 2026-05-24 12:37 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: Frank.Li@kernel.org, krzk+dt@kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev, robh@kernel.org,
conor+dt@kernel.org
In-Reply-To: <20260513232246.B98BDC19425@smtp.kernel.org>
Am 14.05.26 um 01:22 schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] Unused USB port left enabled despite the board only having a single port.
> --
>
> commit f3287c94b8a1489521dd5dfc2f4009ec55b9a33c
> Author: Josua Mayer <josua@solid-run.com>
>
> arm64: dts: Add support for LX2160 Twins board in single configuration
>
> This commit adds device tree support for the SolidRun LX2160A Twins board
> in a single CPU configuration. It defines the various hardware interfaces
> available on the board.
>
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
>> new file mode 100644
>> index 0000000000000..ee1867f5b2b6b
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
>> @@ -0,0 +1,826 @@
>> +// SPDX-License-Identifier: (GPL-2.0 OR MIT)
>> +//
>> +// Device Tree file for single LX2160A CEX-7 on Twins board.
>> +//
>> +// Copyright 2022 SolidRun Ltd.
>> +
>> +/dts-v1/;
>> +
>> +#include <dt-bindings/leds/common.h>
>> +
>> +#include "fsl-lx2160a-rev2.dtsi"
>> +#include "fsl-lx2160a-cex7.dtsi"
> The commit message states the configuration features a "USB-3.0 front-panel
> header with single port", and no other USB ports are listed.
>
> Since the included fsl-lx2160a-cex7.dtsi unconditionally sets the status to
> "okay" for both usb0 and usb1, does this regression leave the non-existent
> second USB port enabled?
The CEX-7 module has an on-board USB Hub.
It does not disappear just because the carrier board wires no connector.
>
> Should this board-specific device tree explicitly disable the unused port,
> perhaps by adding &usb1 { status = "disabled"; }; ?
>
Probably not.
^ permalink raw reply
* [PATCH] ASoC: dt-bindings: sound: asahi-kasei,ak4118: Convert DT schema
From: Manish Baing @ 2026-05-24 12:33 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt, peron.clem
Cc: linux-sound, devicetree, linux-kernel, manishbaing2789
Convert the Asahi Kasei AK4118 S/PDIF transceiver bindings from
text format to YAML schema.
Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
.../devicetree/bindings/sound/ak4118.txt | 22 -------
.../bindings/sound/asahi-kasei,ak4118.yaml | 57 +++++++++++++++++++
2 files changed, 57 insertions(+), 22 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/ak4118.txt
create mode 100644 Documentation/devicetree/bindings/sound/asahi-kasei,ak4118.yaml
diff --git a/Documentation/devicetree/bindings/sound/ak4118.txt b/Documentation/devicetree/bindings/sound/ak4118.txt
deleted file mode 100644
index 6e11a2f7404c..000000000000
--- a/Documentation/devicetree/bindings/sound/ak4118.txt
+++ /dev/null
@@ -1,22 +0,0 @@
-AK4118 S/PDIF transceiver
-
-This device supports I2C mode.
-
-Required properties:
-
-- compatible : "asahi-kasei,ak4118"
-- reg : The I2C address of the device for I2C
-- reset-gpios: A GPIO specifier for the reset pin
-- irq-gpios: A GPIO specifier for the IRQ pin
-
-Example:
-
-&i2c {
- ak4118: ak4118@13 {
- #sound-dai-cells = <0>;
- compatible = "asahi-kasei,ak4118";
- reg = <0x13>;
- reset-gpios = <&gpio 0 GPIO_ACTIVE_LOW>
- irq-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
- };
-};
diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak4118.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4118.yaml
new file mode 100644
index 000000000000..54cee45ac051
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak4118.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/asahi-kasei,ak4118.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Asahi Kasei AK4118 Digital Audio Transceiver
+
+maintainers:
+ - Clément Péron <peron.clem@gmail.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: asahi-kasei,ak4118
+
+ reg:
+ maxItems: 1
+ description: I2C address of the device
+
+ "#sound-dai-cells":
+ const: 0
+
+ interrupts:
+ maxItems: 1
+
+ reset-gpios:
+ maxItems: 1
+ description: GPIO used for the Reset pin
+
+required:
+ - compatible
+ - reg
+ - "#sound-dai-cells"
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ audio-codec@13 {
+ compatible = "asahi-kasei,ak4118";
+ reg = <0x13>;
+ #sound-dai-cells = <0>;
+ interrupt-parent = <&gpio1>;
+ interrupts = <0 IRQ_TYPE_EDGE_RISING>;
+ reset-gpios = <&gpio1 1 GPIO_ACTIVE_LOW>;
+ };
+ };
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v14 08/12] iio: frequency: adf41513: driver implementation
From: Rodrigo Alencar @ 2026-05-24 12:34 UTC (permalink / raw)
To: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc
Cc: Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260524-adf41513-iio-driver-v14-8-06824d9c15f4@analog.com>
On 26/05/24 11:12AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] The driver fails to restore the hardware register state during pm_resume if the device was placed in a software power-down state, leading to power leaks and cache corruption.
> --
>
> commit 829389d24bcc81427dbc259466ce431d38418a05
> Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> iio: frequency: adf41513: driver implementation
>
> This commit introduces a new driver for the Analog Devices ADF41513 PLL
> Frequency Synthesizer. It supports Integer-N and fractional-N synthesis
> modes, high-resolution frequency calculations, IIO debugfs interface,
> and power management.
>
> > diff --git a/drivers/iio/frequency/adf41513.c b/drivers/iio/frequency/adf41513.c
> > new file mode 100644
> > index 0000000000000..6f952ccc675e0
> > --- /dev/null
> > +++ b/drivers/iio/frequency/adf41513.c
> [ ... ]
> > +static int adf41513_pm_resume(struct device *dev)
> > +{
> > + struct adf41513_state *st = dev_get_drvdata(dev);
> > +
> > + guard(mutex)(&st->lock);
> > + if (st->powerdown)
> > + return 0; /* nothing to do */
>
> [Severity: High]
> Does returning early here when the device is in software power-down fail to
> restore the hardware register state?
>
> If the system loses power to the device during suspend, the hardware
> registers will reset to their Power-On Reset defaults.
>
> By returning immediately without writing any state to the hardware, won't
> the hardware wake up in an unconfigured state rather than the requested
> power-down state?
>
> Additionally, the software cache regs_hw is not invalidated and still
> holds the pre-suspend values. If a parameter is subsequently modified,
> the sync function uses ADF41513_SYNC_DIFF and skips writing unmodified
> registers since they falsely appear up-to-date in regs_hw.
>
> Could this leave the hardware permanently in a corrupted mixed state of
> reset defaults and newly written values?
This is a similar concern raised before. Any resume path will program
all the registers, which is essentially a power-up sequence. Partial
writes could happen, but they would not be important.
> > +
> > + return adf41513_resume(st);
> > +}
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260524-adf41513-iio-driver-v14-0-06824d9c15f4@analog.com?part=8
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v14 10/12] iio: frequency: adf41513: features on frequency change
From: Rodrigo Alencar @ 2026-05-24 12:29 UTC (permalink / raw)
To: rodrigo.alencar, linux-kernel, linux-iio, devicetree, linux-doc
Cc: Jonathan Cameron, David Lechner, Andy Shevchenko,
Lars-Peter Clausen, Michael Hennerich, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet, Andrew Morton,
Petr Mladek, Steven Rostedt, Andy Shevchenko, Rasmus Villemoes,
Sergey Senozhatsky, Shuah Khan
In-Reply-To: <20260524-adf41513-iio-driver-v14-10-06824d9c15f4@analog.com>
On 26/05/24 11:15AM, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [High] Bleed current is not computed or updated when switching from Integer-N to Fractional-N mode if the PFD frequency remains unchanged.
> --
>
> commit 299bd27511dd5b2a2354c749631d53bcff158e2b
> Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
>
> iio: frequency: adf41513: features on frequency change
>
> This commit adds bleed current configuration, lock detector window adjustments,
> and phase resync support to the ADF41513 driver when changing the PFD
> frequency.
>
> > diff --git a/drivers/iio/frequency/adf41513.c b/drivers/iio/frequency/adf41513.c
> > --- a/drivers/iio/frequency/adf41513.c
> > +++ b/drivers/iio/frequency/adf41513.c
>
> [ ... ]
>
> > +static void adf41513_set_bleed_val(struct adf41513_state *st)
> > +{
> > + u32 bleed_value, cp_index;
> > +
> > + if (!(st->regs[ADF41513_REG6] & ADF41513_REG6_BLEED_ENABLE_MSK))
> > + return;
>
> [ ... ]
>
> > @@ -630,6 +725,14 @@ static int adf41513_set_frequency(struct adf41513_state *st, u64 freq_uhz, u16 s
> > st->regs[ADF41513_REG6] |= ADF41513_REG6_BLEED_ENABLE_MSK;
> > }
> >
> > + if (pfd_change) {
> > + adf41513_set_bleed_val(st);
>
> [Severity: High]
> Will the bleed current be properly configured if the device switches
> from Integer-N to Fractional-N mode without changing the PFD frequency?
>
> In adf41513_set_bleed_val(), if the device is previously in Integer-N mode,
> ADF41513_REG6_BLEED_ENABLE_MSK is cleared. If the PFD frequency changes
> while in Integer-N mode, adf41513_set_bleed_val() returns early without
> updating the register.
>
> If a subsequent frequency change switches the PLL to Fractional-N mode but
> maintains the exact same PFD frequency, pfd_change will be false. Since
> adf41513_set_bleed_val() is only called when pfd_change is true, the bleed
> value configuration gets skipped entirely.
>
> Could this leave the bleed circuit enabled with a stale or uninitialized
> current value, potentially preventing the PLL from locking?
This make sense. After adding the suggested guard for bleed enabled I should
have move adf41513_set_bleed_val() to be called bellow...
> > + adf41513_set_phase_resync(st);
> > + }
> > +
> > + if (pfd_change || mode_change)
here..
> > + adf41513_set_ld_window(st);
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260524-adf41513-iio-driver-v14-0-06824d9c15f4@analog.com?part=10
At least, that would be a quick one. We can have another round of reviews on
the decimal parse function... worst case, we can have another week.
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v6 08/10] arm64: dts: lx2160a: add labels to thermal trip-point nodes
From: Josua Mayer @ 2026-05-24 12:12 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Shawn Guo, Li Yang, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Herring, Krzysztof Kozlowski, Frank Li,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Yazan Shhady, Jon Nettleton, linux-arm-kernel@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
imx@lists.linux.dev
In-Reply-To: <20260514-kind-antique-ocelot-d34abe@quoll>
Am 14.05.26 um 08:41 schrieb Krzysztof Kozlowski:
> On Tue, May 12, 2026 at 04:39:03PM +0200, Josua Mayer wrote:
>> LX2160A SoC dtsi defines rather conservative thermal trip points,
>> alert at 85°C and critical at 95°C.
>>
>> This is okay for most boards, however the SoC maximum junction
>> temperature is 105°C in both commercial and industrial version.
>>
>> Industrial grade boards need to change the thresholds to avoid premature
>> thermal shutdown in high-temeprature environments.
>>
>> Add labels to all thermal trip point nodes, enabling board dts to
>> reference them and modify properties.
> This is dead code or no-op. Labels should be referenced, otherwise you
> are changing here nothing.
>
> Squash the patches with the user of this label.
Will do, thanks.
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: hamoa: Set MDP MMCX corners to LOW_SVS per Windows
From: sashiko-bot @ 2026-05-24 12:10 UTC (permalink / raw)
To: Daniel J Blueman; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260524115704.9442-1-daniel@quora.org>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] The commit incorrectly applies a Windows ACPI sleep/idle-state voltage vote as the active-state voltage requirement for all MDP MMCX operating frequencies, severely breaking the DVFS curve and risking hardware instability.
- [Medium] Board-specific power optimizations derived from a single device's ACPI tables are inappropriately applied globally to the SoC base device tree.
- [Low] The commit message claims to update 7 MMCX OPP packages, but the implementation differs.
--
commit 4a04fd599f313f3ace74e7b33f9120e9295f92fa
Author: Daniel J Blueman <daniel@quora.org>
arm64: dts: qcom: hamoa: Set MDP MMCX corners to LOW_SVS per Windows
This commit updates the MDP MMCX operating performance points to use the
LOW_SVS voltage corner based on Windows ACPI DSDT F-state tables.
> On the Lenovo Slim 7x with Qualcomm X1 E80100, the current Windows ACPI
> DSDT votes LOW_SVS (0x40) for all 7 MMCX OPP packages in the _SB.PEP0.G0MD
[Severity: Low]
Is this description accurate? The commit message states it updates 7 MMCX OPP
packages, but the mdp_opp_table in hamoa.dtsi only contains 5 OPP entries and
this patch modifies 4 of them.
> F-state EXIT package:
>
> "FSTATE",
> Zero,
> Package (...)
> {
> "EXIT",
> Package (0x02)
> {
> "NPARESOURCE",
> Package (0x03)
> {
> One,
> "/arc/client/rail_mmcx",
> 0x40
> }
> },
> ...
> },
>
> Apply the same in Linux for power saving opportunity.
[Severity: High]
Does this apply an idle state voltage requirement to active operating
performance points?
The F-state EXIT package defines the power requirements when a device
transitions out of a functional state into idle. By mapping this low power
state to active OPPs up to 575MHz, could this regression severely undervolt the
MDP?
During the multi-monitor high-resolution validation, the DisplayPort
controllers may have independently cast high voltage votes on the shared
RPMHPD_MMCX power domain, masking the MDP's lower vote. Would a user
connecting a low-resolution display experience regressions like hard lockups or
visual artifacts due to this voltage drop?
> diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> --- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
> +++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
> @@ -5657,22 +5657,22 @@ opp-200000000 {
>
> opp-325000000 {
> opp-hz = /bits/ 64 <325000000>;
> - required-opps = <&rpmhpd_opp_svs>;
> + required-opps = <&rpmhpd_opp_low_svs>;
> };
[Severity: Medium]
Since this voltage optimization was derived from the ACPI tables of the Lenovo
Slim 7x, should it be applied as an override in the board-specific .dts file
rather than globally in the SoC base device tree?
Could applying this to the base hamoa.dtsi cause regressions across all
Snapdragon X Elite/Plus devices, which might have different power delivery
designs?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260524115704.9442-1-daniel@quora.org?part=1
^ permalink raw reply
* [PATCH v6 2/2] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Josua Mayer @ 2026-05-24 12:03 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel, Vladimir Oltean,
Conor Dooley, Krzysztof Kozlowski, netdev, Josua Mayer
In-Reply-To: <20260524-imx8dxl-sr-som-v6-0-37932c6eb7e4@solid-run.com>
Add support for the SolidRun i.MX8DXL System-on-Module (revision 2.1)
and its corresponding evaluation carrier board, the HummingBoard
Telematics (revision 2.0).
The SoM features:
- eMMC
- GNSS with 1PPS
- V2X DSRC Radio
- Secure Element for V2X Applications
- Inertial Sensor
- Pressure Sensor
- Compass
The HummingBoard Telematics carrier board features:
- Cellular Modem
- WiFi & Bluetooth
- RTC with backup battery
- CAN
- 100Base-TX Ethernet
- 100Base-T1 Ethernet
- Multi-interface I/O connector
- Multi-interface add-on board connector
The multi-interface I/O connector supplies power and provides basic I/O
(Console UART, 100Base-TX, 100Base-T1, CAN, and power-supply logic level
GPIOs). The SolidRun Evaluation Kit includes a suitable cable and
adapter board that breaks these out into RJ45, USB Type-A, microUSB
Console, and Terminal Block connectors.
The multi-interface add-on board connector provides additional
interfaces (5x 100Base-T1, 2x SGMII, USB 2.0 shared with the cellular
modem, CAN, MDIO, SPI, UART, PCIe, I2C, and GPIO). These add-on
interfaces are disabled by default in the base device tree and are
intended to be enabled and extended via device tree overlays.
Note that a few components physically present on the SoM were omitted
from this description due to a lack of upstream bindings and drivers:
- Pressure Sensor
- V2X DSRC Radio
- Secure Element
Acked-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../freescale/imx8dxl-hummingboard-telematics.dts | 560 +++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi | 458 +++++++++++++++++
3 files changed, 1020 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/Makefile b/arch/arm64/boot/dts/freescale/Makefile
index 711e36cc2c990..7db459f666610 100644
--- a/arch/arm64/boot/dts/freescale/Makefile
+++ b/arch/arm64/boot/dts/freescale/Makefile
@@ -111,6 +111,8 @@ dtb-$(CONFIG_ARCH_MXC) += imx8dxl-evk.dtb
imx8dxl-evk-pcie-ep-dtbs += imx8dxl-evk.dtb imx-pcie0-ep.dtbo
dtb-$(CONFIG_ARCH_MXC) += imx8dxl-evk-pcie-ep.dtb
+DTC_FLAGS_imx8dxl-hummingboard-telematics := -@
+dtb-$(CONFIG_ARCH_MXC) += imx8dxl-hummingboard-telematics.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8dxp-tqma8xdp-mba8xx.dtb
dtb-$(CONFIG_ARCH_MXC) += imx8dxp-tqma8xdps-mb-smarc-2.dtb
diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts b/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts
new file mode 100644
index 0000000000000..3095dc87f188d
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts
@@ -0,0 +1,560 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022-2026 Josua Mayer <josua@solid-run.com>
+ */
+
+/dts-v1/;
+
+#include "imx8dxl-sr-som.dtsi"
+
+/ {
+ compatible = "solidrun,imx8dxl-hummingboard-telematics",
+ "solidrun,imx8dxl-sr-som", "fsl,imx8dxl";
+ model = "SolidRun i.MX8DXL HummingBoard Telematics";
+
+ aliases {
+ /* override ethernet aliases from imx8dxl.dtsi */
+ ethernet0 = &eqos;
+ ethernet1 = &switch_port1;
+ ethernet2 = &switch_port2;
+ ethernet3 = &switch_port3;
+ ethernet4 = &switch_port4;
+ ethernet5 = &switch_port5;
+ ethernet6 = &switch_port6;
+ ethernet7 = &switch_port7;
+ ethernet8 = &switch_port8;
+ ethernet9 = &switch_port9;
+ ethernet10 = &switch_port10;
+ gpio8 = &tca6408_u2;
+ mmc2 = &usdhc3;
+ rtc0 = &carrier_rtc;
+ rtc1 = &rtc;
+ serial1 = &lpuart1;
+ };
+
+ osc_32k: clock-osc-32k {
+ compatible = "fixed-clock";
+ clock-frequency = <32768>;
+ #clock-cells = <0>;
+ };
+
+ v_1_1: regulator-1-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v1";
+ pinctrl-0 = <®ulator_1v1_pins>;
+ pinctrl-names = "default";
+ regulator-always-on;
+ regulator-max-microvolt = <1100000>;
+ regulator-min-microvolt = <1100000>;
+ vin-supply = <&v_5_0>;
+ gpio = <&lsio_gpio4 5 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_5_0: regulator-5-0 {
+ compatible = "regulator-fixed";
+ regulator-name = "5v0";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ };
+
+ /* can transceiver builtin regulator (STBN1 pin) */
+ reg_flexcan1_stby: regulator-flexcan1-standby {
+ compatible = "regulator-fixed";
+ regulator-name = "flexcan1-standby";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&tca6408_u2 2 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ /* can transceiver builtin regulator (STBN2 pin) */
+ reg_flexcan2_stby: regulator-flexcan2-standby {
+ compatible = "regulator-fixed";
+ regulator-name = "flexcan2-standby";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ gpio = <&tca6408_u2 3 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ modem_vbat: regulator-modem-vbat {
+ compatible = "regulator-fixed";
+ regulator-name = "modem-vbat";
+ pinctrl-0 = <®ulator_modem_vbat_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <3600000>;
+ regulator-min-microvolt = <3600000>;
+ vin-supply = <&v_5_0>;
+ gpio = <&lsio_gpio0 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ /*
+ * Cellular Modem uses VBAT, RESET_N and PWRKEY for
+ * power-sequencing. USB core does not currently
+ * support this, keep vbat on permanently and let
+ * userspace deal with reset/pwrkey.
+ */
+ regulator-always-on;
+ regulator-boot-on;
+ };
+
+ vbus1: regulator-vbus-1 {
+ compatible = "regulator-fixed";
+ regulator-name = "vbus1";
+ pinctrl-0 = <®ulator_usb1_vbus_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ gpio = <&lsio_gpio0 16 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ usdhc3_pwrseq: usdhc3-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ reset-gpios = <&lsio_gpio0 15 GPIO_ACTIVE_LOW>;
+ };
+};
+
+&dma_apbh {
+ status = "disabled";
+};
+
+&eqos {
+ /* delays are added by connected ethernet-switch cpu port */
+ phy-mode = "rgmii-id";
+ rx-internal-delay-ps = <0>;
+ tx-internal-delay-ps = <0>;
+ pinctrl-0 = <&eqos_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ fixed-link {
+ full-duplex;
+ speed = <1000>;
+ };
+};
+
+&flexcan1 {
+ pinctrl-0 = <&flexcan1_pins>;
+ pinctrl-names = "default";
+ xceiver-supply = <®_flexcan1_stby>;
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <5000000>;
+ };
+};
+
+&flexcan2 {
+ pinctrl-0 = <&flexcan2_pins>;
+ pinctrl-names = "default";
+ xceiver-supply = <®_flexcan2_stby>;
+ status = "okay";
+
+ can-transceiver {
+ max-bitrate = <5000000>;
+ };
+};
+
+&i2c2 {
+ /* routed to J14: SDA(51), SCL(53) */
+
+ /* regulator@18 */
+
+ tca6408_u2: gpio@20 {
+ compatible = "ti,tca6408";
+ reg = <0x20>;
+ #interrupt-cells = <2>;
+ interrupt-controller;
+ #gpio-cells = <2>;
+ gpio-controller;
+ gpio-line-names = "DIG_IN1", "DIG_IN2", "CAN_STNB1", "CAN_STNB2",
+ "DIG_OUT1", "DIG_OUT2", "", "";
+ interrupts-extended = <&lsio_gpio0 20 IRQ_TYPE_EDGE_FALLING>;
+ pinctrl-0 = <&tca6408_u2_int_pins>;
+ pinctrl-names = "default";
+ };
+
+ carrier_rtc: rtc@32 {
+ compatible = "epson,rx8111";
+ reg = <0x32>;
+ };
+};
+
+&iomuxc {
+ bluetooth_pins: pinctrl-bluetooth-grp {
+ fsl,pins = <
+ /* BT_REG_ON: io without pull (module integrates pd) */
+ IMX8DXL_SPI3_SCK_LSIO_GPIO0_IO13 0x0000061
+ >;
+ };
+
+ eqos_pins: pinctrl-eqos-grp {
+ fsl,pins = <
+ /* MDIO to Switch */
+ /* enet0 mdio pads supplied with 3.3v */
+ /* IMX8DXL_COMP_CTL_GPIO_1V8_3V3_GPIOCT */
+ IMX8DXL_ENET0_MDC_CONN_EQOS_MDC 0x06000020
+ IMX8DXL_ENET0_MDIO_CONN_EQOS_MDIO 0x06000020
+ /* RGMII to Switch */
+ IMX8DXL_ENET1_RGMII_TX_CTL_CONN_EQOS_RGMII_TX_CTL 0x06000020
+ IMX8DXL_ENET1_RGMII_TXC_CONN_EQOS_RGMII_TXC 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD0_CONN_EQOS_RGMII_TXD0 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD1_CONN_EQOS_RGMII_TXD1 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD2_CONN_EQOS_RGMII_TXD2 0x06000020
+ IMX8DXL_ENET1_RGMII_TXD3_CONN_EQOS_RGMII_TXD3 0x06000020
+ IMX8DXL_ENET1_RGMII_RXC_CONN_EQOS_RGMII_RXC 0x06000020
+ IMX8DXL_ENET1_RGMII_RX_CTL_CONN_EQOS_RGMII_RX_CTL 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD0_CONN_EQOS_RGMII_RXD0 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD1_CONN_EQOS_RGMII_RXD1 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD2_CONN_EQOS_RGMII_RXD2 0x06000020
+ IMX8DXL_ENET1_RGMII_RXD3_CONN_EQOS_RGMII_RXD3 0x06000020
+ >;
+ };
+
+ flexcan1_pins: pinctrl-flexcan1-grp {
+ fsl,pins = <
+ IMX8DXL_FLEXCAN0_TX_ADMA_FLEXCAN0_TX 0x00000021
+ IMX8DXL_FLEXCAN0_RX_ADMA_FLEXCAN0_RX 0x00000021
+ >;
+ };
+
+ flexcan2_pins: pinctrl-flexcan2-grp {
+ fsl,pins = <
+ IMX8DXL_FLEXCAN1_TX_ADMA_FLEXCAN1_TX 0x00000021
+ IMX8DXL_FLEXCAN1_RX_ADMA_FLEXCAN1_RX 0x00000021
+ >;
+ };
+
+ lpspi0_pins: pinctrl-lpspi0-grp {
+ fsl,pins = <
+ IMX8DXL_SPI0_SCK_ADMA_SPI0_SCK 0x600004c
+ IMX8DXL_SPI0_SDO_ADMA_SPI0_SDO 0x600004c
+ IMX8DXL_SPI0_SDI_ADMA_SPI0_SDI 0x600004c
+ IMX8DXL_SPI0_CS0_LSIO_GPIO1_IO08 0x0000021
+ IMX8DXL_SPI0_CS1_LSIO_GPIO1_IO07 0x0000021
+ >;
+ };
+
+ lpuart1_pins: pinctrl-lpuart1-grp {
+ fsl,pins = <
+ IMX8DXL_UART1_RX_ADMA_UART1_RX 0x06000020
+ IMX8DXL_UART1_TX_ADMA_UART1_TX 0x06000020
+ IMX8DXL_UART1_CTS_B_ADMA_UART1_CTS_B 0x06000020
+ IMX8DXL_UART1_RTS_B_ADMA_UART1_RTS_B 0x06000020
+ >;
+ };
+
+ modem_pins: pinctrl-lte-grp {
+ fsl,pins = <
+ /* modem RESET_N: io open drain drive 2mA */
+ IMX8DXL_ADC_IN3_LSIO_GPIO1_IO11 0x2000061
+
+ /* modem PWRKEY: io open drain with pull-up, drive 2mA */
+ IMX8DXL_ADC_IN2_LSIO_GPIO1_IO12 0x2000021
+ >;
+ };
+
+ regulator_1v1_pins: pinctrl-regulator-1-1-grp {
+ fsl,pins = <
+ /* SW_PE: io without pull-up */
+ IMX8DXL_USB_SS3_TC2_LSIO_GPIO4_IO05 0x0000061
+ >;
+ };
+
+ regulator_modem_vbat_pins: pinctrl-regulator-modem-vbat-grp {
+ fsl,pins = <
+ /*
+ * RF_PWR: io without pull-up,
+ * has either external pull-up (R1117) or pull-down (R1118).
+ * With pull-up Modem will boot at system power-up,
+ * with pull-down modem will enter power-down mode once
+ * vbat is enabled -> toggle pwrkey to boot modem.
+ * Hence pull-up (R1117) is preferred.
+ */
+ IMX8DXL_SPI3_SDO_LSIO_GPIO0_IO14 0x0000061
+ >;
+ };
+
+ regulator_usb1_vbus_pins: pinctrl-regulator-usb1-vbus-grp {
+ fsl,pins = <
+ /* regulator enable: open-drain with pull-up & low drive strength */
+ IMX8DXL_SPI3_CS0_LSIO_GPIO0_IO16 0x2000021
+ >;
+ };
+
+ switch_pins: pinctrl-switch-grp {
+ fsl,pins = <
+ /* SW_RSTn: io without pull-up */
+ IMX8DXL_USB_SS3_TC0_LSIO_GPIO4_IO03 0x0000021
+
+ /* SW_CORE_RSTn: io without pull-up */
+ IMX8DXL_USB_SS3_TC1_LSIO_GPIO4_IO04 0x0000021
+
+ /* INT_N: io without pull-up */
+ IMX8DXL_USB_SS3_TC3_LSIO_GPIO4_IO06 0x0000021
+ >;
+ };
+
+ tca6408_u2_int_pins: pinctrl-tca6408-u2-int-grp {
+ fsl,pins = <
+ /* gpio-expander interrupt: io with pull-up */
+ IMX8DXL_MCLK_OUT0_LSIO_GPIO0_IO20 0x0000021
+ >;
+ };
+
+ usdhc3_pins: pinctrl-usdhc3-grp {
+ fsl,pins = <
+ IMX8DXL_ENET0_RGMII_TXC_CONN_USDHC2_CLK 0x06000040
+ IMX8DXL_ENET0_RGMII_TX_CTL_CONN_USDHC2_CMD 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD0_CONN_USDHC2_DATA0 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD1_CONN_USDHC2_DATA1 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD2_CONN_USDHC2_DATA2 0x00000021
+ IMX8DXL_ENET0_RGMII_TXD3_CONN_USDHC2_DATA3 0x00000021
+ >;
+ };
+
+ wifi_pins: pinctrl-wifi-grp {
+ fsl,pins = <
+ /* WL_REG_ON: io without pull (module integrates pd) */
+ IMX8DXL_SPI3_SDI_LSIO_GPIO0_IO15 0x0000061
+ >;
+ };
+};
+
+&lpspi0 {
+ cs-gpios = <&lsio_gpio1 8 GPIO_ACTIVE_LOW>, <&lsio_gpio1 7 GPIO_ACTIVE_LOW>;
+ pinctrl-0 = <&lpspi0_pins>, <&switch_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+
+ ethernet-switch@0 {
+ compatible = "nxp,sja1110a";
+ reg = <0>;
+ reset-gpios = <&lsio_gpio4 3 GPIO_ACTIVE_LOW>;
+ spi-max-frequency = <4000000>;
+
+ ethernet-ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 100Base-TX on connector J26 */
+ switch_port1: port@1 {
+ reg = <0x1>;
+ phy-handle = <&switch_port1_base_tx_phy>;
+ phy-mode = "internal";
+ };
+
+ /* CPU */
+ switch_port2: port@2 {
+ reg = <0x2>;
+ ethernet = <&eqos>;
+ phy-mode = "rgmii-id";
+ rx-internal-delay-ps = <2000>;
+ tx-internal-delay-ps = <2000>;
+
+ fixed-link {
+ full-duplex;
+ speed = <1000>;
+ };
+ };
+
+ /* sgmii on addon board connector J21 */
+ switch_port3: port@3 {
+ reg = <0x3>;
+ status = "disabled";
+ };
+
+ /* sgmii on addon board connector J21 */
+ switch_port4: port@4 {
+ reg = <0x4>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port5: port@5 {
+ reg = <0x5>;
+ phy-handle = <&switch_port5_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port6: port@6 {
+ reg = <0x6>;
+ phy-handle = <&switch_port6_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port7: port@7 {
+ reg = <0x7>;
+ phy-handle = <&switch_port7_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port8: port@8 {
+ reg = <0x8>;
+ phy-handle = <&switch_port8_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port9: port@9 {
+ reg = <0x9>;
+ phy-handle = <&switch_port9_base_t1_phy>;
+ phy-mode = "internal";
+ status = "disabled";
+ };
+
+ /* 100Base-T1 on connector J26 */
+ switch_port10: port@a {
+ reg = <0xa>;
+ phy-handle = <&switch_port10_base_t1_phy>;
+ phy-mode = "internal";
+ };
+ };
+
+ mdios {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mdio@0 {
+ compatible = "nxp,sja1110-base-t1-mdio";
+ reg = <0>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port5_base_t1_phy: ethernet-phy@1 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x1>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port6_base_t1_phy: ethernet-phy@2 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x2>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port7_base_t1_phy: ethernet-phy@3 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x3>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port8_base_t1_phy: ethernet-phy@4 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x4>;
+ status = "disabled";
+ };
+
+ /* 100base-t1 on addon board connector J21 */
+ switch_port9_base_t1_phy: ethernet-phy@5 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x5>;
+ status = "disabled";
+ };
+
+ /* 100Base-T1 on connector J26 */
+ switch_port10_base_t1_phy: ethernet-phy@6 {
+ compatible = "ethernet-phy-ieee802.3-c45";
+ reg = <0x6>;
+ };
+ };
+
+ mdio@1 {
+ compatible = "nxp,sja1110-base-tx-mdio";
+ reg = <1>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ /* 100Base-TX on connector J26 */
+ switch_port1_base_tx_phy: ethernet-phy@1 {
+ reg = <0x1>;
+ };
+ };
+ };
+ };
+};
+
+/* bluetooth */
+&lpuart1 {
+ pinctrl-0 = <&lpuart1_pins>, <&bluetooth_pins>;
+ pinctrl-names = "default";
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4345c5";
+ clocks = <&osc_32k>;
+ clock-names = "lpo";
+ /* Murata 1MW module supports max. 3M baud */
+ max-speed = <3000000>;
+ shutdown-gpios = <&lsio_gpio0 13 GPIO_ACTIVE_HIGH>;
+ /* link fixed supplies to avoid fall-back lookup by name */
+ vbat-supply = <&v_3_3>;
+ vddio-supply = <&v_1_8>;
+ };
+};
+
+&lsio_gpio1 {
+ gpio-line-names = "", "", "", "", "", "", "", "",
+ "", "", "", "CELL_RESET_N", "CELL_PWRKEY", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "";
+};
+
+&usbotg1 {
+ dr_mode = "host";
+ vbus-supply = <&vbus1>;
+};
+
+/* cellular modem */
+&usbotg2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ adp-disable;
+ disable-over-current;
+ dr_mode = "host";
+ hnp-disable;
+ pinctrl-0 = <&modem_pins>;
+ pinctrl-names = "default";
+ power-active-high;
+ srp-disable;
+ vbus-supply = <&v_5_0>;
+ status = "okay";
+
+ usb-device@1 {
+ compatible = "usb2c7c,125";
+ reg = <1>;
+ vbus-supply = <&v_3_3>;
+ vdd-supply = <&modem_vbat>;
+ };
+};
+
+&usbphy2 {
+ status = "okay";
+};
+
+/* WiFi */
+&usdhc3 {
+ bus-width = <4>;
+ cap-sdio-irq;
+ mmc-pwrseq = <&usdhc3_pwrseq>;
+ non-removable;
+ no-sd;
+ pinctrl-0 = <&usdhc3_pins>, <&wifi_pins>;
+ pinctrl-names = "default";
+ vmmc-supply = <&v_3_3>;
+ vqmmc-supply = <&v_1_8>;
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi b/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi
new file mode 100644
index 0000000000000..93a0eb4d7f770
--- /dev/null
+++ b/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi
@@ -0,0 +1,458 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Copyright 2022-2026 Josua Mayer <josua@solid-run.com>
+ */
+
+#include "imx8dxl.dtsi"
+/ {
+ compatible = "solidrun,imx8dxl-sr-som", "fsl,imx8dxl";
+ model = "SolidRun i.MX8DXL SoM";
+
+ aliases {
+ i2c2 = &i2c2;
+ i2c3 = &i2c3;
+ mmc0 = &usdhc1;
+ mmc1 = &usdhc2;
+ serial0 = &lpuart0;
+ serial2 = &lpuart2;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ imx8dxl-cm4 {
+ compatible = "fsl,imx8qxp-cm4";
+ clocks = <&clk_dummy>;
+ mboxes = <&lsio_mu5 0 1 &lsio_mu5 1 1 &lsio_mu5 3 1>;
+ mbox-names = "tx", "rx", "rxdb";
+ memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>,
+ <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>;
+ power-domains = <&pd IMX_SC_R_M4_0_PID0>, <&pd IMX_SC_R_M4_0_MU_1A>;
+ fsl,entry-address = <0x34fe0000>;
+ fsl,resource-id = <IMX_SC_R_M4_0_PID0>;
+ };
+
+ pps {
+ compatible = "pps-gpio";
+ gpios = <&lsio_gpio2 6 GPIO_ACTIVE_HIGH>;
+ pinctrl-0 = <&gnss_pps_pins>;
+ pinctrl-names = "default";
+ };
+
+ v_1_2: regulator-1-2 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v2";
+ pinctrl-0 = <®ulator_1_2_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <1200000>;
+ regulator-min-microvolt = <1200000>;
+ gpio = <&lsio_gpio1 13 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_1_6: regulator-1-6 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v6";
+ pinctrl-0 = <®ulator_1_6_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <1600000>;
+ regulator-min-microvolt = <1600000>;
+ vin-supply = <&v_1_8>;
+ gpio = <&lsio_gpio1 14 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_1_8: regulator-1-8 {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ };
+
+ v_1_8_se: regulator-1-8-secure-element {
+ compatible = "regulator-fixed";
+ regulator-name = "1v8-se";
+ pinctrl-0 = <®ulator_1_8_se_pins>;
+ pinctrl-names = "default";
+ regulator-max-microvolt = <1800000>;
+ regulator-min-microvolt = <1800000>;
+ vin-supply = <&v_1_8>;
+ gpio = <&lsio_gpio3 18 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+ };
+
+ v_3_3: regulator-3-3 {
+ compatible = "regulator-fixed";
+ regulator-name = "3v3";
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ };
+
+ reserved-memory {
+ ranges;
+ #address-cells = <2>;
+ #size-cells = <2>;
+
+ /* global autoconfigured region for contiguous allocations */
+ linux,cma {
+ compatible = "shared-dma-pool";
+ alloc-ranges = <0 0x98000000 0 0x14000000>;
+ reusable;
+ size = <0 0x14000000>;
+ linux,cma-default;
+ };
+
+ vdev0vring0: memory0@90000000 {
+ reg = <0 0x90000000 0 0x8000>;
+ no-map;
+ };
+
+ vdev0vring1: memory@90008000 {
+ reg = <0 0x90008000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring0: memory@90010000 {
+ reg = <0 0x90010000 0 0x8000>;
+ no-map;
+ };
+
+ vdev1vring1: memory@90018000 {
+ reg = <0 0x90018000 0 0x8000>;
+ no-map;
+ };
+
+ rsc_table: memory-rsc-table@900ff000 {
+ reg = <0 0x900ff000 0 0x1000>;
+ no-map;
+ };
+
+ vdevbuffer: memory-vdevbuffer@90400000 {
+ compatible = "shared-dma-pool";
+ reg = <0 0x90400000 0 0x100000>;
+ no-map;
+ };
+
+ /*
+ * Memory reserved for optee usage. Please do not use.
+ * This will be automatically added to dtb if OP-TEE is installed.
+ * optee@96000000 {
+ * reg = <0 0x96000000 0 0x2000000>;
+ * no-map;
+ * };
+ */
+ };
+
+ memory@80000000 {
+ reg = <0x00000000 0x80000000 0 0x40000000>;
+ device_type = "memory";
+ };
+};
+
+&i2c2 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c2_pins>;
+ pinctrl-1 = <&i2c2_gpio_pins>;
+ pinctrl-names = "default", "gpio";
+ scl-gpios = <&lsio_gpio3 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&lsio_gpio3 0 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+};
+
+&i2c3 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ clock-frequency = <100000>;
+ pinctrl-0 = <&i2c3_pins>;
+ pinctrl-1 = <&i2c3_gpio_pins>;
+ pinctrl-names = "default", "gpio";
+ scl-gpios = <&lsio_gpio3 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ sda-gpios = <&lsio_gpio3 3 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ status = "okay";
+
+ magnetometer@1e {
+ compatible = "st,iis2mdc";
+ reg = <0x1e>;
+ interrupt-parent = <&lsio_gpio2>;
+ interrupts = <10 IRQ_TYPE_EDGE_RISING>;
+ pinctrl-0 = <&magnetometer_pins>;
+ pinctrl-names = "default";
+ st,drdy-int-pin = <1>;
+ };
+
+ /* pressure-sensor@5c */
+
+ inertial-sensor@6b {
+ compatible = "st,ism330dhcx";
+ reg = <0x6b>;
+ interrupt-parent = <&lsio_gpio2>;
+ interrupts = <11 IRQ_TYPE_EDGE_RISING>;
+ pinctrl-0 = <&imu_pins>;
+ pinctrl-names = "default";
+ st,drdy-int-pin = <1>;
+ };
+};
+
+&iomuxc {
+ pinctrl-0 = <&pinctrl_hog>;
+ pinctrl-names = "default";
+
+ pinctrl_hog: hoggrp {
+ fsl,pins = <
+ IMX8DXL_COMP_CTL_GPIO_1V8_3V3_GPIORHB_PAD 0x000514a0
+ IMX8DXL_COMP_CTL_GPIO_1V8_3V3_GPIORHK_PAD 0x000014a0
+ >;
+ };
+
+ dsrc_pins: pinctrl-dsrc-grp {
+ fsl,pins = <
+ /* reset: io without pull */
+ IMX8DXL_ADC_IN0_LSIO_GPIO1_IO10 0x0000060
+
+ /*
+ * boot0: io without pull
+ * After reset, this pin selects radio boot media:
+ * - 0: flash spi
+ * - 1: slave sdio
+ * Once the firmware boots however, the radio controls
+ * this pin for flow-control to signal readiness.
+ */
+ IMX8DXL_ADC_IN1_LSIO_GPIO1_IO09 0x0000060
+ >;
+ };
+
+ gnss_pins: pinctrl-gnss-grp {
+ fsl,pins = <
+ /* gps reset: input with pull-up */
+ IMX8DXL_SNVS_TAMPER_OUT4_LSIO_GPIO2_IO08_IN 0x0000021
+ /* gps interrupt: io without pull-up */
+ IMX8DXL_SNVS_TAMPER_IN0_LSIO_GPIO2_IO09_IN 0x0000061
+ >;
+ };
+
+ gnss_pps_pins: pinctrl-gnss-pps-grp {
+ fsl,pins = <
+ /* gps timepulse: input without pull-up */
+ IMX8DXL_SNVS_TAMPER_OUT2_LSIO_GPIO2_IO06_IN 0x0000061
+ >;
+ };
+
+ i2c2_gpio_pins: pinctrl-i2c2-gpio-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_SCK_LSIO_GPIO3_IO00 0x00000021
+ /* io with pull-up, weak drive, open-drain */
+ IMX8DXL_SPI1_SDO_LSIO_GPIO3_IO01 0x02000021
+ >;
+ };
+
+ i2c2_pins: pinctrl-i2c2-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_SCK_ADMA_I2C2_SDA 0x06000021
+ IMX8DXL_SPI1_SDO_ADMA_I2C2_SCL 0x06000021
+ >;
+ };
+
+ i2c3_gpio_pins: pinctrl-i2c3-gpio-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_CS0_LSIO_GPIO3_IO03 0x00000021
+ /* io with pull-up, weak drive, open-drain */
+ IMX8DXL_SPI1_SDI_LSIO_GPIO3_IO02 0x02000021
+ >;
+ };
+
+ i2c3_pins: pinctrl-i2c3-grp {
+ fsl,pins = <
+ /* io with pull-up and weak drive */
+ IMX8DXL_SPI1_CS0_ADMA_I2C3_SDA 0x06000021
+ IMX8DXL_SPI1_SDI_ADMA_I2C3_SCL 0x06000021
+ >;
+ };
+
+ imu_pins: pinctrl-imu-grp {
+ fsl,pins = <
+ /* interrupt: io with pull-down */
+ IMX8DXL_SNVS_TAMPER_IN2_LSIO_GPIO2_IO11_IN 0x0000041
+ >;
+ };
+
+ lpspi2_pins: pinctrl-lpspi2-grp {
+ fsl,pins = <
+ IMX8DXL_USDHC1_RESET_B_ADMA_SPI2_SCK 0x600004c
+ IMX8DXL_USDHC1_VSELECT_ADMA_SPI2_SDO 0x600004c
+ IMX8DXL_USDHC1_WP_ADMA_SPI2_SDI 0x600004c
+ IMX8DXL_USDHC1_CD_B_LSIO_GPIO4_IO22 0x6000021
+ >;
+ };
+
+ lpuart0_pins: pinctrl-lpuart0-grp {
+ fsl,pins = <
+ IMX8DXL_UART0_RX_ADMA_UART0_RX 0x06000020
+ IMX8DXL_UART0_TX_ADMA_UART0_TX 0x06000020
+ >;
+ };
+
+ lpuart2_pins: pinctrl-lpuart2-grp {
+ fsl,pins = <
+ IMX8DXL_UART2_TX_ADMA_UART2_TX 0x06000020
+ IMX8DXL_UART2_RX_ADMA_UART2_RX 0x06000020
+ >;
+ };
+
+ magnetometer_pins: pinctrl-magnetometer-grp {
+ fsl,pins = <
+ /* interrupt: io with pull-down */
+ IMX8DXL_SNVS_TAMPER_IN1_LSIO_GPIO2_IO10_IN 0x0000041
+ >;
+ };
+
+ regulator_1_2_pins: pinctrl-regulator-1-2-grp {
+ fsl,pins = <
+ /* io without pull-up */
+ /* has etxernal pull-down */
+ IMX8DXL_ADC_IN5_LSIO_GPIO1_IO13 0x0000061
+ >;
+ };
+
+ regulator_1_6_pins: pinctrl-regulator-1-6-grp {
+ fsl,pins = <
+ /* io without pull-up */
+ /* has etxernal pull-down */
+ IMX8DXL_ADC_IN4_LSIO_GPIO1_IO14 0x0000061
+ >;
+ };
+
+ regulator_1_8_se_pins: pinctrl-regulator-1-8-secure-element-grp {
+ fsl,pins = <
+ /* v2x-secure-element power switch: io with pull-down */
+ IMX8DXL_QSPI0B_DATA0_LSIO_GPIO3_IO18 0x0000041
+ >;
+ };
+
+ se_pins: pinctrl-secure-element-grp {
+ fsl,pins = <
+ /* v2x-secure-element reset: io with pull-up */
+ IMX8DXL_QSPI0B_DATA1_LSIO_GPIO3_IO19 0x0000021
+
+ /*
+ * v2x-secure-element gpio0: io with pull-up
+ * pulled low by sxf after boot indicating ready for commands
+ */
+ IMX8DXL_QSPI0B_DATA2_LSIO_GPIO3_IO20 0x0000021
+
+ /* v2x-secure-element gpio1: io with pull-up */
+ IMX8DXL_QSPI0B_DATA3_LSIO_GPIO3_IO21 0x0000021
+ >;
+ };
+
+ usdhc1_pins: pinctrl-usdhc1-grp {
+ fsl,pins = <
+ IMX8DXL_EMMC0_CLK_CONN_EMMC0_CLK 0x06000041
+ IMX8DXL_EMMC0_CMD_CONN_EMMC0_CMD 0x00000021
+ IMX8DXL_EMMC0_DATA0_CONN_EMMC0_DATA0 0x00000021
+ IMX8DXL_EMMC0_DATA1_CONN_EMMC0_DATA1 0x00000021
+ IMX8DXL_EMMC0_DATA2_CONN_EMMC0_DATA2 0x00000021
+ IMX8DXL_EMMC0_DATA3_CONN_EMMC0_DATA3 0x00000021
+ IMX8DXL_EMMC0_DATA4_CONN_EMMC0_DATA4 0x00000021
+ IMX8DXL_EMMC0_DATA5_CONN_EMMC0_DATA5 0x00000021
+ IMX8DXL_EMMC0_DATA6_CONN_EMMC0_DATA6 0x00000021
+ IMX8DXL_EMMC0_DATA7_CONN_EMMC0_DATA7 0x00000021
+ IMX8DXL_EMMC0_STROBE_CONN_EMMC0_STROBE 0x00000041
+ IMX8DXL_EMMC0_RESET_B_CONN_EMMC0_RESET_B 0x00000061
+ >;
+ };
+
+ usdhc2_pins: pinctrl-usdhc2-grp {
+ fsl,pins = <
+ IMX8DXL_ENET0_RGMII_RXC_CONN_USDHC1_CLK 0x06000040
+ IMX8DXL_ENET0_RGMII_RX_CTL_CONN_USDHC1_CMD 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD0_CONN_USDHC1_DATA0 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD1_CONN_USDHC1_DATA1 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD2_CONN_USDHC1_DATA2 0x00000021
+ IMX8DXL_ENET0_RGMII_RXD3_CONN_USDHC1_DATA3 0x00000021
+ >;
+ };
+};
+
+&lpspi2 {
+ cs-gpios = <&lsio_gpio4 22 GPIO_ACTIVE_LOW>;
+ num-cs = <1>;
+ pinctrl-0 = <&lpspi2_pins>, <&se_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+/* console */
+&lpuart0 {
+ pinctrl-0 = <&lpuart0_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+/* gnss */
+&lpuart2 {
+ pinctrl-0 = <&lpuart2_pins>, <&gnss_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&lsio_gpio3 {
+ gpio-line-names = "", "", "", "", "", "", "", "",
+ "", "", "", "", "", "", "", "",
+ "", "", "", "SXF_RST", "SXF_GPIO0", "SXF_GPIO1", "", "",
+ "", "", "", "", "", "", "", "";
+};
+
+&lsio_mu5 {
+ status = "okay";
+};
+
+/* OTG port for boot */
+&usbotg1 {
+ adp-disable;
+ disable-over-current;
+ dr_mode = "peripheral";
+ hnp-disable;
+ power-active-high;
+ srp-disable;
+ status = "okay";
+};
+
+&usbphy1 {
+ status = "okay";
+};
+
+/* eMMC */
+&usdhc1 {
+ bus-width = <8>;
+ cap-mmc-hw-reset;
+ non-removable;
+ no-sd;
+ no-sdio;
+ pinctrl-0 = <&usdhc1_pins>;
+ pinctrl-1 = <&usdhc1_pins>;
+ pinctrl-2 = <&usdhc1_pins>;
+ pinctrl-names = "default", "state_100mhz", "state_200mhz";
+ vmmc-supply = <&v_3_3>;
+ vqmmc-supply = <&v_1_8>;
+ status = "okay";
+};
+
+/* DSRC Radio */
+&usdhc2 {
+ bus-width = <4>;
+ keep-power-in-suspend;
+ max-frequency = <40000000>;
+ non-removable;
+ no-sd;
+ pinctrl-0 = <&usdhc2_pins>, <&dsrc_pins>;
+ pinctrl-names = "default";
+ vmmc-supply = <&v_3_3>;
+ vqmmc-supply = <&v_1_8>;
+ status = "okay";
+};
--
2.51.0
^ permalink raw reply related
* [PATCH v6 1/2] dt-bindings: arm: fsl: Add SolidRun i.MX8DXL SoM and HummingBoard
From: Josua Mayer @ 2026-05-24 12:03 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel, Vladimir Oltean,
Conor Dooley, Krzysztof Kozlowski, netdev, Josua Mayer,
Krzysztof Kozlowski
In-Reply-To: <20260524-imx8dxl-sr-som-v6-0-37932c6eb7e4@solid-run.com>
Add binding for the SolidRun i.MX8DXL based System on Module, and the
reference HummingBoard Telematics.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Documentation/devicetree/bindings/arm/fsl.yaml | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml
index 0023cd1268075..17cd47e8efce8 100644
--- a/Documentation/devicetree/bindings/arm/fsl.yaml
+++ b/Documentation/devicetree/bindings/arm/fsl.yaml
@@ -1394,6 +1394,13 @@ properties:
- fsl,imx8dxl-evk # i.MX8DXL EVK Board
- const: fsl,imx8dxl
+ - description: SolidRun i.MX8DXL SoM based boards
+ items:
+ - enum:
+ - solidrun,imx8dxl-hummingboard-telematics # SolidRun i.MX8DXL SoM EVK Board
+ - const: solidrun,imx8dxl-sr-som
+ - const: fsl,imx8dxl
+
- description: i.MX8QXP/i.MX8DX Boards with Toradex Colibri iMX8X Modules
items:
- enum:
--
2.51.0
^ permalink raw reply related
* [PATCH v6 0/2] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Josua Mayer @ 2026-05-24 12:03 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Shawn Guo,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Andrew Lunn, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
Cc: Yazan Shhady, Mikhail Anikin, Alexander Dahl, devicetree,
linux-kernel, imx, linux-arm-kernel, Vladimir Oltean,
Conor Dooley, Krzysztof Kozlowski, netdev, Josua Mayer,
Krzysztof Kozlowski
Add bindings and description for SolidRUn i.MX8DXL based SoM and
HummingBoard Telematics.
Modify SJA1110 Ethernet Switch bindings to allow SPI Mode 0.
This patch-set is based on v7.0-rc2, because rc1 was experiencing
deadlocks with imx8qxp clock driver.
Signed-off-by: Josua Mayer <josua@solid-run.com>
---
Changes in v6:
- Remove stray /delete-property/ from aliases.
- Fix name collision for bluetooth "vbat" regulator.
- Kernel can't power-sequence cellular modem, ensure userspace can:
Drop reset-gpios, set vbat always-on, define gpio line-name for
powerkey and reset.
- Link to v5: https://lore.kernel.org/r/20260513-imx8dxl-sr-som-v5-0-d0899b371c38@solid-run.com
Changes in v5:
- Change cpu port phy-mode to rgmii-id, and set zero delays. Delays are
added by connected ethernet switch port.
- Added ethernet aliases for all switch ports.
- Removed undocumented reset-duration-us property from usb modem node.
- Fix T1 interface count in commit message.
- Change USB-A Port dr_mode to host.
- Add cap-sdio-irq for wifi.
- Link to v4: https://lore.kernel.org/r/20260511-imx8dxl-sr-som-v4-0-64381b3bf80d@solid-run.com
Changes in v4:
- picked up acked-by adnrew lunn
- Link to v3: https://lore.kernel.org/r/20260430-imx8dxl-sr-som-v3-0-ce2b86cf75bc@solid-run.com
Changes in v3:
- rebased on v7.1-rc1.
- dropped dsa swtch port labels, should be handled by udev rules if
required.
- Fixed spelling error in alias comment.
- Dropped superfluous status okay properties from switch sub-nodes.
- Link to v2: https://lore.kernel.org/r/20260409-imx8dxl-sr-som-v2-0-83ff20629ba0@solid-run.com
Changes in v2:
- Dropped accidental change to unrelated imx8mp-sr-som.dtsi file.
- Fixed phy-mode on fixed link between cpu and ethernet switch.
(Reported-by: Andrew Lunn <andrew@lunn.ch>)
- Removed spi-cpol property from ethernet-switch on spi bus, fixing
sja1110a driver probe.
- Changed SJA1110 bindings to allow removing spi-cpol property.
- Aligned comments on all ethernet switch port nodes to be consistent.
- Dropped regulator-always-on from dsrc radio power-supplies.
- Link to v1: https://lore.kernel.org/r/20260408-imx8dxl-sr-som-v1-0-ce5a39acd713@solid-run.com
---
Josua Mayer (2):
dt-bindings: arm: fsl: Add SolidRun i.MX8DXL SoM and HummingBoard
arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
Documentation/devicetree/bindings/arm/fsl.yaml | 7 +
arch/arm64/boot/dts/freescale/Makefile | 2 +
.../freescale/imx8dxl-hummingboard-telematics.dts | 560 +++++++++++++++++++++
arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi | 458 +++++++++++++++++
4 files changed, 1027 insertions(+)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260408-imx8dxl-sr-som-f141ec343173
Best regards,
--
Josua Mayer <josua@solid-run.com>
^ permalink raw reply
* [PATCH] arm64: dts: qcom: hamoa: Set MDP MMCX corners to LOW_SVS per Windows
From: Daniel J Blueman @ 2026-05-24 11:57 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, linux-arm-msm
Cc: Krzysztof Kozlowski, Conor Dooley, devicetree, linux-kernel,
Daniel J Blueman
On the Lenovo Slim 7x with Qualcomm X1 E80100, the current Windows ACPI
DSDT votes LOW_SVS (0x40) for all 7 MMCX OPP packages in the _SB.PEP0.G0MD
F-state EXIT package:
"FSTATE",
Zero,
Package (...)
{
"EXIT",
Package (0x02)
{
"NPARESOURCE",
Package (0x03)
{
One,
"/arc/client/rail_mmcx",
0x40
}
},
...
},
Apply the same in Linux for power saving opportunity. Validated on Lenovo
Slim7x across daily workloads over 2 weeks with the internal 2944x1840
panel @ 90Hz and a 3840x2160 @ 60Hz monitor over USB-C MST DP alt.
Signed-off-by: Daniel J Blueman <daniel@quora.org>
---
arch/arm64/boot/dts/qcom/hamoa.dtsi | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/hamoa.dtsi b/arch/arm64/boot/dts/qcom/hamoa.dtsi
index 051dee076416..bdd9e7e0768c 100644
--- a/arch/arm64/boot/dts/qcom/hamoa.dtsi
+++ b/arch/arm64/boot/dts/qcom/hamoa.dtsi
@@ -5657,22 +5657,22 @@ opp-200000000 {
opp-325000000 {
opp-hz = /bits/ 64 <325000000>;
- required-opps = <&rpmhpd_opp_svs>;
+ required-opps = <&rpmhpd_opp_low_svs>;
};
opp-375000000 {
opp-hz = /bits/ 64 <375000000>;
- required-opps = <&rpmhpd_opp_svs_l1>;
+ required-opps = <&rpmhpd_opp_low_svs>;
};
opp-514000000 {
opp-hz = /bits/ 64 <514000000>;
- required-opps = <&rpmhpd_opp_nom>;
+ required-opps = <&rpmhpd_opp_low_svs>;
};
opp-575000000 {
opp-hz = /bits/ 64 <575000000>;
- required-opps = <&rpmhpd_opp_nom_l1>;
+ required-opps = <&rpmhpd_opp_low_svs>;
};
};
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3] dt-bindings: clock: via,vt8500: Convert to DT Schema
From: sashiko-bot @ 2026-05-24 11:27 UTC (permalink / raw)
To: Udaya Kiran Challa; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260524111813.39810-1-challauday369@gmail.com>
Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] Broken DT Schema Structure and Selection
- [Low] Incorrect Regex Pattern for Node Names
- [Low] Missing Dependency Logic for Gated Clock Properties
--
commit 009c99928a4e9dc4ede2113118b784ee611924f0
Author: Udaya Kiran Challa <challauday369@gmail.com>
dt-bindings: clock: via,vt8500: Convert to DT Schema
Convert the VIA/Wondermedia VT8500 and Wondermedia WM8xxx series SoCs clock
controller binding from the legacy text format to DT schema.
> diff --git a/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml b/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
> new file mode 100644
> index 0000000000000..035925969655e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
> @@ -0,0 +1,179 @@
[ ... ]
> +description:
> + Clock controller bindings for VIA/Wondermedia VT8500 and Wondermedia WM8xxx
> + series SoCs.
> +
> +properties:
> + clocks:
[Severity: Medium]
Is this schema structured correctly? By wrapping the node definitions inside
a parent clocks object, the root level lacks a compatible property or a
custom select statement. Will dt-validate ever automatically apply this
schema to devicetree nodes in practice?
Also, since the root level has additionalProperties: false (at the bottom
of the file) but lacks definitions for compatible and reg, won't the provided
example fail dt_binding_check since it includes compatible = "via,vt8500-pmc"
and reg?
> + type: object
> + additionalProperties: true
> +
> + properties:
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + required:
> + - "#address-cells"
> + - "#size-cells"
> +
> + patternProperties:
> + "^[a-z0-9]+(@[0-9a-f]+)?$":
[Severity: Low]
Does this regex inadvertently exclude hyphens? Standard devicetree node names,
such as clock-24000000 found in the example below, contain hyphens. Since
the parent clocks object uses additionalProperties: true, do these nodes
silently fall through and bypass schema validation entirely?
> + type: object
> +
> + properties:
[ ... ]
> + - if:
> + properties:
> + compatible:
> + const: via,vt8500-device-clock
> + then:
> + properties:
> + reg: false
> +
> + required:
> + - clocks
> +
> + anyOf:
> + - required:
> + - enable-reg
> + - enable-bit
> +
> + - required:
> + - divisor-reg
[Severity: Low]
If a clock implements both features, does this anyOf condition allow it
to provide divisor-reg and enable-reg, but illegally omit enable-bit
without failing validation? Should this relationship be enforced using
dependentRequired for enable-reg to require enable-bit?
> +
> + additionalProperties: false
> +
> +required:
> + - clocks
> +
> +additionalProperties: false
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260524111813.39810-1-challauday369@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH] dt-bindings: arm: vt8500: via,vt8500-pmc: Convert to DT Schema
From: sashiko-bot @ 2026-05-24 11:23 UTC (permalink / raw)
To: Udaya Kiran Challa; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260524110047.37590-1-challauday369@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Redefining the standard 'clocks' property as an object violates the core DT meta-schema and bypasses child node validation.
--
commit 1dba768055c24a5e16b0109bd342a32c68535b08
Author: Udaya Kiran Challa <challauday369@gmail.com>
dt-bindings: arm: vt8500: via,vt8500-pmc: Convert to DT Schema
This commit converts the VIA/Wondermedia VT8500 Power Management controller
binding from the legacy text format to the new DT schema format.
> diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.yaml b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.yaml
> new file mode 100644
> index 0000000000000..ac603fd4efec9
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.yaml
[ ... ]
> +properties:
> + compatible:
> + const: via,vt8500-pmc
> +
> + reg:
> + maxItems: 1
> +
> + clocks:
> + type: object
> + additionalProperties: true
[Severity: Medium]
Does redefining the standard clocks property as an object conflict with the
core DT meta-schema?
The clocks property is globally defined by the core dtschema as an array of
phandles. Defining it here as an object creates a type conflict, which will
cause validation to fail since the schema will require it to be both an
array and an object. Furthermore, using additionalProperties: true disables
schema validation for nested properties and child nodes.
If the intention is to document a legacy child node named clocks, should it
be defined using patternProperties (like "^clocks$") to avoid conflicting
with the standard property definition?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260524110047.37590-1-challauday369@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v4 2/2] dt-bindings: pwm: stmpe: drop legacy binding
From: Uwe Kleine-König @ 2026-05-24 11:21 UTC (permalink / raw)
To: Manish Baing
Cc: lee, robh, krzk+dt, conor+dt, mcoquelin.stm32, alexandre.torgue,
linusw, linux-pwm, devicetree, linux-stm32, linux-arm-kernel,
linux-kernel, Conor Dooley
In-Reply-To: <20260523173251.72540-3-manishbaing2789@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 554 bytes --]
On Sat, May 23, 2026 at 05:32:51PM +0000, Manish Baing wrote:
> The st,stmpe-pwm binding is already covered by the MFD schema
> Documentation/devicetree/bindings/mfd/st,stmpe.yaml. Remove the
> obsolete and redundant text binding file.
>
> Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Reviewed-by: Uwe Kleine-König <ukleinek@kernel.org>
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/ukleinek/linux.git pwm/for-next
with Rob's ack from v2.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [PATCH v3] dt-bindings: clock: via,vt8500: Convert to DT Schema
From: Udaya Kiran Challa @ 2026-05-24 11:17 UTC (permalink / raw)
To: mturquette, sboyd, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa
Convert the VIA/Wondermedia VT8500 and Wondermedia WM8xxx series SoCs clock
controller binding from the legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
Changelog:
Changes since v2:
- Drop redundant description for clocks
- Disable reg property for device clocks
- Fix schema hierarchy to match actual DTS structure
Link to v2:https://lore.kernel.org/all/20260521170810.19702-1-challauday369@gmail.com/
Changes since v1:
- Add default value for divisor-mask
- Add required properties compatible and model
- Fix example node name
- Update example size cells and reg value
Link to v1:https://lore.kernel.org/all/20260520025131.17772-1-challauday369@gmail.com/
---
.../bindings/clock/via,vt8500-clock.yaml | 179 ++++++++++++++++++
.../devicetree/bindings/clock/vt8500.txt | 74 --------
2 files changed, 179 insertions(+), 74 deletions(-)
create mode 100644 Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
delete mode 100644 Documentation/devicetree/bindings/clock/vt8500.txt
diff --git a/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml b/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
new file mode 100644
index 000000000000..035925969655
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/via,vt8500-clock.yaml
@@ -0,0 +1,179 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/clock/via,vt8500-clock.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VIA/Wondermedia VT8500 Clock Controller
+
+maintainers:
+ - Michael Turquette <mturquette@baylibre.com>
+ - Stephen Boyd <sboyd@kernel.org>
+
+description:
+ Clock controller bindings for VIA/Wondermedia VT8500 and Wondermedia WM8xxx
+ series SoCs.
+
+properties:
+ clocks:
+ type: object
+ additionalProperties: true
+
+ properties:
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+ required:
+ - "#address-cells"
+ - "#size-cells"
+
+ patternProperties:
+ "^[a-z0-9]+(@[0-9a-f]+)?$":
+ type: object
+
+ properties:
+ compatible:
+ enum:
+ - via,vt8500-pll-clock
+ - wm,wm8650-pll-clock
+ - wm,wm8750-pll-clock
+ - wm,wm8850-pll-clock
+ - via,vt8500-device-clock
+
+ reg:
+ maxItems: 1
+ description:
+ Offset of the PLL register within the PMC register space.
+
+ clocks:
+ maxItems: 1
+
+ "#clock-cells":
+ const: 0
+
+ enable-reg:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset of the clock enable register within the PMC
+ register space.
+
+ enable-bit:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ maximum: 31
+ description:
+ Bit index controlling clock enable.
+
+ divisor-reg:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ description:
+ Offset of the clock divisor register within the PMC
+ register space.
+
+ divisor-mask:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ default: 0x1f
+ description:
+ Bitmask describing the divisor field inside divisor-reg.
+
+ required:
+ - compatible
+ - "#clock-cells"
+
+ allOf:
+ - if:
+ properties:
+ compatible:
+ enum:
+ - via,vt8500-pll-clock
+ - wm,wm8650-pll-clock
+ - wm,wm8750-pll-clock
+ - wm,wm8850-pll-clock
+ then:
+ required:
+ - reg
+ - clocks
+
+ - if:
+ properties:
+ compatible:
+ const: via,vt8500-device-clock
+ then:
+ properties:
+ reg: false
+
+ required:
+ - clocks
+
+ anyOf:
+ - required:
+ - enable-reg
+ - enable-bit
+
+ - required:
+ - divisor-reg
+
+ additionalProperties: false
+
+required:
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ pmc@d8130000 {
+ compatible = "via,vt8500-pmc";
+ reg = <0xd8130000 0x1000>;
+
+ clocks {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ ref24: clock-24000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24000000>;
+ };
+
+ ref25: clock-25000000 {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <25000000>;
+ };
+
+ plla: clock@200 {
+ compatible = "wm,wm8650-pll-clock";
+ #clock-cells = <0>;
+ clocks = <&ref25>;
+ reg = <0x200>;
+ };
+
+ clkarm: arm {
+ compatible = "via,vt8500-device-clock";
+ #clock-cells = <0>;
+ clocks = <&plla>;
+ divisor-reg = <0x300>;
+ };
+
+ clkuart0: uart0 {
+ compatible = "via,vt8500-device-clock";
+ #clock-cells = <0>;
+ clocks = <&ref24>;
+ enable-reg = <0x250>;
+ enable-bit = <1>;
+ };
+
+ clksdhc: sdhc {
+ compatible = "via,vt8500-device-clock";
+ #clock-cells = <0>;
+ clocks = <&plla>;
+ divisor-reg = <0x328>;
+ divisor-mask = <0x3f>;
+ enable-reg = <0x254>;
+ enable-bit = <18>;
+ };
+ };
+ };
diff --git a/Documentation/devicetree/bindings/clock/vt8500.txt b/Documentation/devicetree/bindings/clock/vt8500.txt
deleted file mode 100644
index 91d71cc0314a..000000000000
--- a/Documentation/devicetree/bindings/clock/vt8500.txt
+++ /dev/null
@@ -1,74 +0,0 @@
-Device Tree Clock bindings for arch-vt8500
-
-This binding uses the common clock binding[1].
-
-[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
-
-Required properties:
-- compatible : shall be one of the following:
- "via,vt8500-pll-clock" - for a VT8500/WM8505 PLL clock
- "wm,wm8650-pll-clock" - for a WM8650 PLL clock
- "wm,wm8750-pll-clock" - for a WM8750 PLL clock
- "wm,wm8850-pll-clock" - for a WM8850 PLL clock
- "via,vt8500-device-clock" - for a VT/WM device clock
-
-Required properties for PLL clocks:
-- reg : shall be the control register offset from PMC base for the pll clock.
-- clocks : shall be the input parent clock phandle for the clock. This should
- be the reference clock.
-- #clock-cells : from common clock binding; shall be set to 0.
-
-Required properties for device clocks:
-- clocks : shall be the input parent clock phandle for the clock. This should
- be a pll output.
-- #clock-cells : from common clock binding; shall be set to 0.
-
-
-Device Clocks
-
-Device clocks are required to have one or both of the following sets of
-properties:
-
-
-Gated device clocks:
-
-Required properties:
-- enable-reg : shall be the register offset from PMC base for the enable
- register.
-- enable-bit : shall be the bit within enable-reg to enable/disable the clock.
-
-
-Divisor device clocks:
-
-Required property:
-- divisor-reg : shall be the register offset from PMC base for the divisor
- register.
-Optional property:
-- divisor-mask : shall be the mask for the divisor register. Defaults to 0x1f
- if not specified.
-
-
-For example:
-
-ref25: ref25M {
- #clock-cells = <0>;
- compatible = "fixed-clock";
- clock-frequency = <25000000>;
-};
-
-plla: plla {
- #clock-cells = <0>;
- compatible = "wm,wm8650-pll-clock";
- clocks = <&ref25>;
- reg = <0x200>;
-};
-
-sdhc: sdhc {
- #clock-cells = <0>;
- compatible = "via,vt8500-device-clock";
- clocks = <&pllb>;
- divisor-reg = <0x328>;
- divisor-mask = <0x3f>;
- enable-reg = <0x254>;
- enable-bit = <18>;
-};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v14 10/12] iio: frequency: adf41513: features on frequency change
From: sashiko-bot @ 2026-05-24 11:15 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260524-adf41513-iio-driver-v14-10-06824d9c15f4@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Bleed current is not computed or updated when switching from Integer-N to Fractional-N mode if the PFD frequency remains unchanged.
--
commit 299bd27511dd5b2a2354c749631d53bcff158e2b
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: frequency: adf41513: features on frequency change
This commit adds bleed current configuration, lock detector window adjustments,
and phase resync support to the ADF41513 driver when changing the PFD
frequency.
> diff --git a/drivers/iio/frequency/adf41513.c b/drivers/iio/frequency/adf41513.c
> --- a/drivers/iio/frequency/adf41513.c
> +++ b/drivers/iio/frequency/adf41513.c
[ ... ]
> +static void adf41513_set_bleed_val(struct adf41513_state *st)
> +{
> + u32 bleed_value, cp_index;
> +
> + if (!(st->regs[ADF41513_REG6] & ADF41513_REG6_BLEED_ENABLE_MSK))
> + return;
[ ... ]
> @@ -630,6 +725,14 @@ static int adf41513_set_frequency(struct adf41513_state *st, u64 freq_uhz, u16 s
> st->regs[ADF41513_REG6] |= ADF41513_REG6_BLEED_ENABLE_MSK;
> }
>
> + if (pfd_change) {
> + adf41513_set_bleed_val(st);
[Severity: High]
Will the bleed current be properly configured if the device switches
from Integer-N to Fractional-N mode without changing the PFD frequency?
In adf41513_set_bleed_val(), if the device is previously in Integer-N mode,
ADF41513_REG6_BLEED_ENABLE_MSK is cleared. If the PFD frequency changes
while in Integer-N mode, adf41513_set_bleed_val() returns early without
updating the register.
If a subsequent frequency change switches the PLL to Fractional-N mode but
maintains the exact same PFD frequency, pfd_change will be false. Since
adf41513_set_bleed_val() is only called when pfd_change is true, the bleed
value configuration gets skipped entirely.
Could this leave the bleed circuit enabled with a stale or uninitialized
current value, potentially preventing the PLL from locking?
> + adf41513_set_phase_resync(st);
> + }
> +
> + if (pfd_change || mode_change)
> + adf41513_set_ld_window(st);
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260524-adf41513-iio-driver-v14-0-06824d9c15f4@analog.com?part=10
^ permalink raw reply
* [PATCH v2] dt-bindings: mmc: mellanox,bluefield-dw-mshc: Convert DT schema
From: Manish Baing @ 2026-05-24 11:15 UTC (permalink / raw)
To: ulfh, robh, krzk+dt, conor+dt, kblaiech
Cc: linux-mmc, devicetree, linux-kernel, manishbaing2789
Convert the Mellanox BlueField SoC extensions for the Synopsys
Designware Mobile Storage Host Controller from text format
to YAML schema.
Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
Changes in v2:
- Fixed unit-address mismatch in the YAML example block per Sashiko bot review.
.../bindings/mmc/bluefield-dw-mshc.txt | 29 -----------
.../mmc/mellanox,bluefield-dw-mshc.yaml | 49 +++++++++++++++++++
2 files changed, 49 insertions(+), 29 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
create mode 100644 Documentation/devicetree/bindings/mmc/mellanox,bluefield-dw-mshc.yaml
diff --git a/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt b/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
deleted file mode 100644
index b0f0999ea1a9..000000000000
--- a/Documentation/devicetree/bindings/mmc/bluefield-dw-mshc.txt
+++ /dev/null
@@ -1,29 +0,0 @@
-* Mellanox Bluefield SoC specific extensions to the Synopsys Designware
- Mobile Storage Host Controller
-
-Read synopsys-dw-mshc.txt for more details
-
-The Synopsys designware mobile storage host controller is used to interface
-a SoC with storage medium such as eMMC or SD/MMC cards. This file documents
-differences between the core Synopsys dw mshc controller properties described
-by synopsys-dw-mshc.txt and the properties used by the Mellanox Bluefield SoC
-specific extensions to the Synopsys Designware Mobile Storage Host Controller.
-
-Required Properties:
-
-* compatible: should be one of the following.
- - "mellanox,bluefield-dw-mshc": for controllers with Mellanox Bluefield SoC
- specific extensions.
-
-Example:
-
- /* Mellanox Bluefield SoC MMC */
- mmc@6008000 {
- compatible = "mellanox,bluefield-dw-mshc";
- reg = <0x6008000 0x400>;
- interrupts = <32>;
- fifo-depth = <0x100>;
- clock-frequency = <24000000>;
- bus-width = <8>;
- cap-mmc-highspeed;
- };
diff --git a/Documentation/devicetree/bindings/mmc/mellanox,bluefield-dw-mshc.yaml b/Documentation/devicetree/bindings/mmc/mellanox,bluefield-dw-mshc.yaml
new file mode 100644
index 000000000000..a992a4a00460
--- /dev/null
+++ b/Documentation/devicetree/bindings/mmc/mellanox,bluefield-dw-mshc.yaml
@@ -0,0 +1,49 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mmc/mellanox,bluefield-dw-mshc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Mellanox BlueField SoC extensions for Synopsys DesignWare MSHC
+
+maintainers:
+ - Khalil Blaiech <kblaiech@nvidia.com>
+
+description:
+ The Synopsys Designware Mobile Storage Host Controller (MSHC) on Mellanox
+ BlueField SoCs is used to interface with storage media such as eMMC or
+ SD/MMC cards. This binding documents the BlueField-specific extensions
+ and the differences from the core Synopsys DW MSHC schema.
+
+allOf:
+ - $ref: synopsys-dw-mshc-common.yaml#
+
+properties:
+ compatible:
+ const: mellanox,bluefield-dw-mshc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ /* Mellanox BlueField SoC MMC */
+ mmc@6008000 {
+ compatible = "mellanox,bluefield-dw-mshc";
+ reg = <0x6008000 0x400>;
+ interrupts = <32>;
+ fifo-depth = <0x100>;
+ clock-frequency = <24000000>;
+ bus-width = <8>;
+ cap-mmc-highspeed;
+ };
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v14 08/12] iio: frequency: adf41513: driver implementation
From: sashiko-bot @ 2026-05-24 11:12 UTC (permalink / raw)
To: Rodrigo Alencar via B4 Relay; +Cc: devicetree, conor+dt, robh
In-Reply-To: <20260524-adf41513-iio-driver-v14-8-06824d9c15f4@analog.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The driver fails to restore the hardware register state during pm_resume if the device was placed in a software power-down state, leading to power leaks and cache corruption.
--
commit 829389d24bcc81427dbc259466ce431d38418a05
Author: Rodrigo Alencar <rodrigo.alencar@analog.com>
iio: frequency: adf41513: driver implementation
This commit introduces a new driver for the Analog Devices ADF41513 PLL
Frequency Synthesizer. It supports Integer-N and fractional-N synthesis
modes, high-resolution frequency calculations, IIO debugfs interface,
and power management.
> diff --git a/drivers/iio/frequency/adf41513.c b/drivers/iio/frequency/adf41513.c
> new file mode 100644
> index 0000000000000..6f952ccc675e0
> --- /dev/null
> +++ b/drivers/iio/frequency/adf41513.c
[ ... ]
> +static int adf41513_pm_resume(struct device *dev)
> +{
> + struct adf41513_state *st = dev_get_drvdata(dev);
> +
> + guard(mutex)(&st->lock);
> + if (st->powerdown)
> + return 0; /* nothing to do */
[Severity: High]
Does returning early here when the device is in software power-down fail to
restore the hardware register state?
If the system loses power to the device during suspend, the hardware
registers will reset to their Power-On Reset defaults.
By returning immediately without writing any state to the hardware, won't
the hardware wake up in an unconfigured state rather than the requested
power-down state?
Additionally, the software cache regs_hw is not invalidated and still
holds the pre-suspend values. If a parameter is subsequently modified,
the sync function uses ADF41513_SYNC_DIFF and skips writing unmodified
registers since they falsely appear up-to-date in regs_hw.
Could this leave the hardware permanently in a corrupted mixed state of
reset defaults and newly written values?
> +
> + return adf41513_resume(st);
> +}
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260524-adf41513-iio-driver-v14-0-06824d9c15f4@analog.com?part=8
^ permalink raw reply
* [PATCH] dt-bindings: arm: vt8500: via,vt8500-pmc: Convert to DT Schema
From: Udaya Kiran Challa @ 2026-05-24 11:00 UTC (permalink / raw)
To: linux, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa
Convert the VIA/Wondermedia VT8500 Power Management controller binding
from the legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
.../bindings/arm/vt8500/via,vt8500-pmc.txt | 13 -------
.../bindings/arm/vt8500/via,vt8500-pmc.yaml | 38 +++++++++++++++++++
2 files changed, 38 insertions(+), 13 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
create mode 100644 Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.yaml
diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
deleted file mode 100644
index 521b9c7de933..000000000000
--- a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.txt
+++ /dev/null
@@ -1,13 +0,0 @@
-VIA/Wondermedia VT8500 Power Management Controller
------------------------------------------------------
-
-Required properties:
-- compatible : "via,vt8500-pmc"
-- reg : Should contain 1 register ranges(address and length)
-
-Example:
-
- pmc@d8130000 {
- compatible = "via,vt8500-pmc";
- reg = <0xd8130000 0x1000>;
- };
diff --git a/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.yaml b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.yaml
new file mode 100644
index 000000000000..ac603fd4efec
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/vt8500/via,vt8500-pmc.yaml
@@ -0,0 +1,38 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/arm/vt8500/via,vt8500-pmc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: VIA/Wondermedia VT8500 Power Management Controller
+
+maintainers:
+ - Tony Prisk <linux@prisktech.co.nz>
+
+description:
+ The VIA/Wondermedia Power Management Controller provides register access for
+ clock and power management functions on VT8500 and WM8xxx series SoCs.
+
+properties:
+ compatible:
+ const: via,vt8500-pmc
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ type: object
+ additionalProperties: true
+
+required:
+ - compatible
+ - reg
+
+additionalProperties: false
+
+examples:
+ - |
+ pmc@d8130000 {
+ compatible = "via,vt8500-pmc";
+ reg = <0xd8130000 0x1000>;
+ };
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 2/2] arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
From: Josua Mayer @ 2026-05-24 11:00 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org,
Frank.Li@kernel.org, imx@lists.linux.dev, krzk+dt@kernel.org
In-Reply-To: <20260514103504.A1F8FC2BCB3@smtp.kernel.org>
Am 14.05.26 um 12:35 schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [High] The Quectel cellular modem (`usb-device@1`) will never be powered on because its DT node is unhandled.
> - [High] The `ethernet1` alias is explicitly assigned but then immediately deleted within the same node block, breaking MAC address assignment.
> - [Medium] The `usdhc2` host controller is enabled and marked `non-removable` for omitted hardware.
> --
>
> commit a7ba7e5c27b439ec498400fe760e61ca8b0b035c
> Author: Josua Mayer <josua@solid-run.com>
>
> arm64: dts: imx8dxl: Add SolidRun SoM and HummingBoard
>
> Add support for the SolidRun i.MX8DXL System-on-Module (revision 2.1)
> and its corresponding evaluation carrier board, the HummingBoard
> Telematics (revision 2.0).
>
>> diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts b/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts
>> new file mode 100644
>> index 0000000000000..5f42c4f2e3be9
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/imx8dxl-hummingboard-telematics.dts
>> @@ -0,0 +1,536 @@
> [ ... ]
>> + aliases {
>> + /* override ethernet aliases from imx8dxl.dtsi */
>> + ethernet0 = &eqos;
>> + ethernet1 = &switch_port1;
>> + ethernet2 = &switch_port2;
>> + ethernet3 = &switch_port3;
>> + ethernet4 = &switch_port4;
>> + ethernet5 = &switch_port5;
>> + ethernet6 = &switch_port6;
>> + ethernet7 = &switch_port7;
>> + ethernet8 = &switch_port8;
>> + ethernet9 = &switch_port9;
>> + ethernet10 = &switch_port10;
>> + /delete-property/ ethernet1;
Leftover from previous revision before switch ports had aliases.
Dropping in v6.
> Will deleting this alias break MAC address assignment?
>
> Because the Device Tree Compiler evaluates properties sequentially within the
> same node block, this removes the ethernet1 alias from the final compiled
> device tree.
>
> Since bootloaders typically iterate over ethernet%d aliases starting from 0,
> won't breaking the sequence cause the iteration to abort prematurely and
> leave ports 2 through 10 without MAC addresses?
>
> [ ... ]
>> +/* cellular modem */
>> +&usbotg2 {
> [ ... ]
>> + usb-device@1 {
>> + compatible = "usb2c7c,125";
>> + reg = <1>;
>> + reset-gpios = <&lsio_gpio1 11 GPIO_ACTIVE_LOW>;
>> + vbus-supply = <&v_3_3>;
>> + vdd-supply = <&modem_vbat>;
>> + };
>> +};
> Will this Quectel cellular modem ever be powered on?
Yes. By the bluetooth driver because of the name "vbat" :(
root@58581b109b8e:~# cat /sys/class/regulator/regulator.8/uevent
OF_NAME=regulator-modem-vbat
OF_FULLNAME=/regulator-modem-vbat
OF_COMPATIBLE_0=regulator-fixed
OF_COMPATIBLE_N=1
root@58581b109b8e:~# cat /sys/class/regulator/regulator.8/state
enabled
root@58581b109b8e:~# cat /sys/class/regulator/regulator.8/consumer\:serial\:serial0-0/consumer/uevent
DRIVER=hci_uart_bcm
OF_NAME=bluetooth
OF_FULLNAME=/bus@5a000000/serial@5a070000/bluetooth
OF_COMPATIBLE_0=brcm,bcm4345c5
OF_COMPATIBLE_N=1
MODALIAS=of:NbluetoothT(null)Cbrcm,bcm4345c5
I will change this for v6, however getting the modem to actually power on
is not a priority while writing hardware description.
>
> Since generic USB devices are dynamically enumerated by the host, the kernel
> relies exclusively on the onboard_usb_dev platform driver to power them up
> before enumeration.
>
> Since usb2c7c,125 is not in the onboard_dev_match table and there is no
> generic power sequence fallback in the USB core, won't this node be ignored?
> This would leave modem_vbat disabled, the reset pin unhandled, and the modem
> physically unpowered and invisible to the USB host.
>
>> diff --git a/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi b/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi
>> new file mode 100644
>> index 0000000000000..93a0eb4d7f770
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/imx8dxl-sr-som.dtsi
>> @@ -0,0 +1,458 @@
> [ ... ]
>> +/* DSRC Radio */
>> +&usdhc2 {
>> + bus-width = <4>;
>> + keep-power-in-suspend;
>> + max-frequency = <40000000>;
>> + non-removable;
> Does this cause boot delays and MMC enumeration timeouts?
No.
[ 12.853689] mmc2: SDHCI controller on 5b030000.mmc [5b030000.mmc] using ADMA
[ 13.038719] mmc2: new high speed SDIO card at address 0001
>
> The commit message notes the V2X DSRC Radio peripheral device node is
> intentionally omitted due to a lack of upstream bindings.
>
> Because the controller expects a permanently attached card and is marked as
> non-removable, won't the MMC core attempt to initialize it during boot and
> fail since the peripheral power sequence and resets are not driven by any
> node?
>
> Should the host controller be marked with status = "disabled" until the
> peripheral is actually supported and present in the DT?
No. The card is detected, just no driver binds to it beyond sdhi.
>
>> + no-sd;
>> + pinctrl-0 = <&usdhc2_pins>, <&dsrc_pins>;
>> + pinctrl-names = "default";
>> + vmmc-supply = <&v_3_3>;
>> + vqmmc-supply = <&v_1_8>;
>> + status = "okay";
>> +};
^ permalink raw reply
* Re: [PATCH v8 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Bryan O'Donoghue @ 2026-05-24 10:59 UTC (permalink / raw)
To: sashiko-reviews
Cc: neil.armstrong, robh, devicetree, linux-phy, olteanv, vkoul,
conor+dt
In-Reply-To: <20260523030420.045501F000E9@smtp.kernel.org>
On 23/05/2026 04:04, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
> - [Medium] Using the literal `endpoint:` property name inside ports bypasses constraint validation for endpoints with unit addresses.
> - [Medium] The `data-lanes` property on `port@1` is overly restricted to `maxItems: 1`, which will break multi-lane DPHY split-mode configurations.
> - [Low] The example uses a non-generic device tree node name `csiphy@...` instead of the standard `phy@...`.
> - [Low] Mismatch between the `vdda-0p9-supply` property name and the actual 0.8V hardware supply used on the x1e80100 platform.
> --
>
> commit 10936c65e44aeea784cc13676d51700996cf6559
> Author: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
>
> dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
>
> Add a base schema initially compatible with x1e80100 to describe MIPI CSI2
> PHY devices.
>
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
>> new file mode 100644
>> index 0000000000000..270375f949880
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,x1e80100-csi2-phy.yaml
> [ ... ]
>> + power-domain-names:
>> + items:
>> + - const: mmcx
>> + - const: mx
>> +
>> + vdda-0p9-supply:
>> + description: Phandle to a 0.9V regulator supply to a PHY.
>
> [Severity: Low]
> Does this property name mismatch the actual hardware supply voltage for the
> x1e80100 platform?
>
> The example later in this schema uses <&vreg_l2c_0p8>, which indicates an
> 0.8V rail. Should this be updated to reflect the 0.8V voltage?
This was feedback I forgot to implement yes.
>> +
>> + vdda-1p2-supply:
>> + description: Phandle to 1.2V regulator supply to a PHY.
>> +
>> + ports:
>> + $ref: /schemas/graph.yaml#/properties/ports
>> +
>> + properties:
>> + port@0:
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + description: Sensor input. Always present.
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + endpoint:
>
> [Severity: Medium]
> Will using the literal endpoint: key bypass constraint validation if an
> endpoint with a unit address (e.g., endpoint@0) is used?
>
> Because the port references port-base, such an endpoint will pass the
> unevaluatedProperties: false check, but its specific constraints wouldn't
> be validated. Could this use patternProperties: "^endpoint(@[0-9a-f]+)?$":
> instead?
Not sure about the answer to that. Also feels like the tool could have
made this suggestion at v7, definitely room for improvement.
>
>> + $ref: /schemas/media/video-interfaces.yaml#
>> + unevaluatedProperties: false
> [ ... ]
>> + port@1:
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + description:
>> + Second sensor input. When present, indicates DPHY split mode.
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + endpoint:
>
> [Severity: Medium]
> As with port@0, should this use patternProperties: "^endpoint(@[0-9a-f]+)?$":
> to ensure endpoints with unit addresses are properly validated?
>
>> + $ref: /schemas/media/video-interfaces.yaml#
>> + unevaluatedProperties: false
>> + properties:
>> + data-lanes:
>> + maxItems: 1
>
> [Severity: Medium]
> Is maxItems: 1 too restrictive for multi-lane DPHY split-mode configurations?
>
> Split-mode typically divides a 4-lane PHY into two independent 2-lane
> interfaces (e.g., data-lanes = <2 3>). This configuration would fail
> dt_binding_check validation with a single item limit.
Not sure where Sashiko is getting this "typically" stuff from since
split-mode is a qcomism.
But no in split mode port@1 is specifically restricted this way.
Is there a way to give definitive feedback - with a meta comment perhaps
- that stops the tool continually giving the same feedback ?
>
>> + clock-lanes:
>> + maxItems: 1
> [ ... ]
>> + port@2:
>> + $ref: /schemas/graph.yaml#/$defs/port-base
>> + description: Output to CAMSS controller.
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + endpoint:
>
> [Severity: Medium]
> As above, should this use patternProperties: "^endpoint(@[0-9a-f]+)?$":?
>
>> + $ref: /schemas/graph.yaml#/$defs/endpoint-base
>> + unevaluatedProperties: false
> [ ... ]
>> +examples:
>> + - |
>> + #include <dt-bindings/interrupt-controller/arm-gic.h>
>> + #include <dt-bindings/clock/qcom,x1e80100-camcc.h>
>> + #include <dt-bindings/clock/qcom,x1e80100-gcc.h>
>> + #include <dt-bindings/power/qcom,rpmhpd.h>
>> +
>> + csiphy4: csiphy@ace4000 {
>
> [Severity: Low]
> Does this node name violate the standard naming convention for PHY providers?
In the example does that matter ? Passes the dt checker anyway.
> The core phy-provider.yaml schema expects node names to match the generic
> pattern ^phy(@.*)?$. The current name csiphy@ace4000 will likely trigger a
> dt_binding_check warning.
>
>> + compatible = "qcom,x1e80100-csi2-phy";
>> + reg = <0x0ace4000 0x2000>;
>> + #phy-cells = <1>;
>
^ 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