* [PATCH] dt-bindings: gpio: meson-axg: Fix whitespace issue
From: Jun Yan @ 2026-05-24 15:49 UTC (permalink / raw)
To: Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Neil Armstrong, Kevin Hilman,
Jerome Brunet, Martin Blumenstingl
Cc: Jun Yan, linux-gpio, devicetree, linux-arm-kernel, linux-amlogic,
linux-kernel
Clean up whitespace misalignment in meson-axg-gpio.h
Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
---
include/dt-bindings/gpio/meson-axg-gpio.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/dt-bindings/gpio/meson-axg-gpio.h b/include/dt-bindings/gpio/meson-axg-gpio.h
index 25bb1fffa97a..a0d42bcd9bd3 100644
--- a/include/dt-bindings/gpio/meson-axg-gpio.h
+++ b/include/dt-bindings/gpio/meson-axg-gpio.h
@@ -23,7 +23,7 @@
#define GPIOAO_11 11
#define GPIOAO_12 12
#define GPIOAO_13 13
-#define GPIO_TEST_N 14
+#define GPIO_TEST_N 14
/* Second GPIO chip */
#define GPIOZ_0 0
@@ -52,7 +52,7 @@
#define BOOT_12 23
#define BOOT_13 24
#define BOOT_14 25
-#define GPIOA_0 26
+#define GPIOA_0 26
#define GPIOA_1 27
#define GPIOA_2 28
#define GPIOA_3 29
--
2.54.0
^ permalink raw reply related
* [PATCH] ASoC: dt-bindings: sound: asahi-kasei,ak5386: Convert DT schema
From: Manish Baing @ 2026-05-24 16:01 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt, zonque
Cc: linux-sound, devicetree, linux-kernel, manishbaing2789
Convert the Asahi Kasei AK5386 ADC binding from text format
to YAML schema.
Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
.../devicetree/bindings/sound/ak5386.txt | 23 ----------
.../bindings/sound/asahi-kasei,ak5386.yaml | 44 +++++++++++++++++++
2 files changed, 44 insertions(+), 23 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/ak5386.txt
create mode 100644 Documentation/devicetree/bindings/sound/asahi-kasei,ak5386.yaml
diff --git a/Documentation/devicetree/bindings/sound/ak5386.txt b/Documentation/devicetree/bindings/sound/ak5386.txt
deleted file mode 100644
index ec3df3abba0c..000000000000
--- a/Documentation/devicetree/bindings/sound/ak5386.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-AK5386 Single-ended 24-Bit 192kHz delta-sigma ADC
-
-This device has no control interface.
-
-Required properties:
-
- - compatible : "asahi-kasei,ak5386"
-
-Optional properties:
-
- - reset-gpio : a GPIO spec for the reset/power down pin.
- If specified, it will be deasserted at probe time.
- - va-supply : a regulator spec, providing 5.0V
- - vd-supply : a regulator spec, providing 3.3V
-
-Example:
-
-spdif: ak5386@0 {
- compatible = "asahi-kasei,ak5386";
- reset-gpio = <&gpio0 23>;
- va-supply = <&vdd_5v0_reg>;
- vd-supply = <&vdd_3v3_reg>;
-};
diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak5386.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak5386.yaml
new file mode 100644
index 000000000000..df896f3a5e08
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak5386.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/asahi-kasei,ak5386.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Asahi Kasei AK5386 ADC
+
+maintainers:
+ - Daniel Mack <zonque@gmail.com>
+
+description:
+ The Asahi Kasei AK5386 is a single-ended 24-Bit 192kHz delta-sigma
+ analog-to-digital converter (ADC).This device has no control interface.
+
+properties:
+ compatible:
+ const: asahi-kasei,ak5386
+
+ reset-gpios:
+ maxItems: 1
+ description: A GPIO spec for the reset/power down pin.
+
+ va-supply:
+ description: Power supply for the analog section.
+
+ vd-supply:
+ description: Power supply for the digital section.
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ adc {
+ compatible = "asahi-kasei,ak5386";
+ reset-gpios = <&gpio0 23 GPIO_ACTIVE_LOW>;
+ va-supply = <&vdd_5v0_reg>;
+ vd-supply = <&vdd_3v3_reg>;
+ };
--
2.43.0
^ permalink raw reply related
* 【自動返信メール】お問い合わせいただきありがとうございます
From: Windy's LIFE @ 2026-05-24 12:29 UTC (permalink / raw)
To: devicetree
メッセージ本文:
Photos for my escort application are uploaded.
Let me know if the quality is good.
Preview: https://tinyurl.com/yc87v2ht#63axSn
--
あなたのメールアドレスを使用して、私たちのウェブサイト (Windy's LIFE https://windyblog.org) のコンタクトフォームに送信がありましたので、その控えとして本メールを送ります。もしもその送信について心当たりのない場合は、どうぞこのメッセージを無視してください。
^ permalink raw reply
* Re: [PATCH] ASoC: dt-bindings: sound: asahi-kasei,ak5386: Convert DT schema
From: sashiko-bot @ 2026-05-24 16:17 UTC (permalink / raw)
To: Manish Baing; +Cc: conor+dt, robh, devicetree
In-Reply-To: <20260524160158.109983-1-manishbaing2789@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The schema uses `additionalProperties: false` but omits a reference to `dai-common.yaml#` and the `#sound-dai-cells` property, which will cause validation failures for valid audio configurations.
- [Medium] The new schema breaks backward compatibility by rejecting the legacy `reset-gpio` property that was documented in the original text binding.
--
commit 53f12bd4c4466e68926d73a25cd532a103036343
Author: Manish Baing <manishbaing2789@gmail.com>
ASoC: dt-bindings: sound: asahi-kasei,ak5386: Convert DT schema
This commit converts the Asahi Kasei AK5386 ADC binding from the legacy
text format to the YAML schema format.
> diff --git a/Documentation/devicetree/bindings/sound/ak5386.txt b/Documentation/devicetree/bindings/sound/ak5386.txt
> deleted file mode 100644
> --- a/Documentation/devicetree/bindings/sound/ak5386.txt
> +++ /dev/null
[ ... ]
> -Optional properties:
> -
> - - reset-gpio : a GPIO spec for the reset/power down pin.
> - If specified, it will be deasserted at probe time.
[ ... ]
> diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak5386.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak5386.yaml
> new file mode 100644
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak5386.yaml
[ ... ]
> +properties:
> + compatible:
> + const: asahi-kasei,ak5386
> +
> + reset-gpios:
> + maxItems: 1
> + description: A GPIO spec for the reset/power down pin.
[Severity: Medium]
Does this break backward compatibility with existing device trees?
The original text binding explicitly documented the reset pin as
reset-gpio (singular), and existing device trees may be using that
property.
Since the driver uses devm_gpiod_get_optional() which handles the legacy
-gpio suffix automatically, the driver still works, but the new schema
will reject it due to additionalProperties: false.
Should the legacy reset-gpio property be defined here, perhaps marked as
deprecated, to maintain DT ABI backwards compatibility?
> +
> + va-supply:
> + description: Power supply for the analog section.
> +
> + vd-supply:
> + description: Power supply for the digital section.
> +
> +required:
> + - compatible
> +
> +additionalProperties: false
[Severity: Medium]
Will this reject valid audio configurations?
The AK5386 functions as an audio codec and Digital Audio Interface (DAI)
provider. Standard ASoC generic sound cards require the codec node to have
the #sound-dai-cells property to resolve the codec phandle.
Because the schema enforces additionalProperties: false without defining
#sound-dai-cells or referencing dai-common.yaml#, it seems dtbs_check
will fail on valid device trees.
Should this include a reference to dai-common.yaml# and use
unevaluatedProperties: false instead?
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260524160158.109983-1-manishbaing2789@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH v7 9/9] arm64: dts: Add support for LX2160 Twins board in single configuration
From: sashiko-bot @ 2026-05-24 16:19 UTC (permalink / raw)
To: Josua Mayer; +Cc: robh, devicetree, Frank.Li, imx, conor+dt
In-Reply-To: <20260524-lx2160-pci-v7-9-09370c23b952@solid-run.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The `gpio-mux` node for the fan tachometer multiplexer lacks an in-kernel consumer, which permanently locks the GPIOs and prevents the mux from being switched.
--
commit 3c28f80d13a11b4ba012fa933362f3d2ffeec63c
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 adds hardware support for various
interfaces including SFP ports, OCP, USB, microSD, and power supplies.
> 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..d16e273072754
> --- /dev/null
> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
[ ... ]
> + mux-controller {
> + compatible = "gpio-mux";
> + #mux-control-cells = <0>;
> + /*
> + * This gpio controlled mux can route the tacho signals of 6 PWM FAN connectors
> + * to the tacho inputs of both CEX-7 modules (twins).
> + *
> + * The first twin controls this mux and monitors four fan connectors, two intended
> + * for itself, and two for the OCP card.
> + *
> + * The second twin monitors only two fan connectors intended for itself.
> + *
> + * The table below maps selector GPIO states to monitored fan connector per twin:
> + *
> + * | SEL1 | SEL0 | Twin 1 | Twin 2 |
> + * | ---: | ---: | :------| ------ |
> + * | 0 | 0 | J10 | J5024 |
> + * | 0 | 1 | J5016 | J5024 |
> + * | 1 | 0 | J5026 | J5025 |
> + * | 1 | 1 | J5013 | J5025 |
> + */
> + mux-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>, /* SEL0 */
> + <&expander0 15 GPIO_ACTIVE_HIGH>; /* SEL1 */
> + };
[Severity: Medium]
Does this mux-controller lack an in-kernel consumer?
When the gpio-mux driver probes, it exclusively requests and locks these GPIOs.
However, there appears to be no consumer node in the device tree referencing
this multiplexer to actually switch it.
Since the Linux mux subsystem doesn't provide a userspace interface for
switching, and the GPIO subsystem denies userspace access to locked pins, does
this completely prevent both the kernel and userspace from switching the fan
tachometer multiplexer?
If so, doesn't this permanently lock the fan monitoring functionality in its
default state?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260524-lx2160-pci-v7-0-09370c23b952@solid-run.com?part=9
^ permalink raw reply
* Re: [PATCH 2/6] firmware: qcom: scm: Allow EFI variable access on Radxa Dragon Q6A
From: Dmitry Baryshkov @ 2026-05-24 16:33 UTC (permalink / raw)
To: Graham O'Connor
Cc: linux-arm-msm, andersson, konradybcio, robin.clark, lumag,
abhinav.kumar, robh, krzk+dt, conor+dt, dri-devel, devicetree,
linux-kernel
In-Reply-To: <20260522060645.4399-3-graham.oconnor@gmail.com>
On Fri, May 22, 2026 at 06:06:41PM +1200, Graham O'Connor wrote:
> Add the Radxa Dragon Q6A compatible string to the SCM allowlist to
> enable EFI variable access on this platform. Without this entry,
> the SCM driver refuses to service EFI variable requests, preventing
> the system from reading and writing UEFI variables.
Which medium is used by Q6A to store UEFI vars?
>
> Tested on Radxa Dragon Q6A (QCS6490)
>
> Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
> ---
> drivers/firmware/qcom/qcom_scm.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/firmware/qcom/qcom_scm.c b/drivers/firmware/qcom/qcom_scm.c
> index 6b601a4b8..4702ad898 100644
> --- a/drivers/firmware/qcom/qcom_scm.c
> +++ b/drivers/firmware/qcom/qcom_scm.c
> @@ -2320,6 +2320,7 @@ static const struct of_device_id qcom_scm_qseecom_allowlist[] __maybe_unused = {
> { .compatible = "qcom,x1e80100-crd" },
> { .compatible = "qcom,x1e80100-qcp" },
> { .compatible = "qcom,x1p42100-crd" },
> + { .compatible = "radxa,dragon-q6a" },
> { }
> };
>
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 4/6] arm64: dts: qcom: qcs6490-radxa-dragon-q6a: Add regulator supplies and disable EUD
From: Dmitry Baryshkov @ 2026-05-24 16:38 UTC (permalink / raw)
To: Graham O'Connor
Cc: linux-arm-msm, andersson, konradybcio, robin.clark, lumag,
abhinav.kumar, robh, krzk+dt, conor+dt, dri-devel, devicetree,
linux-kernel
In-Reply-To: <20260522060645.4399-5-graham.oconnor@gmail.com>
On Fri, May 22, 2026 at 06:06:43PM +1200, Graham O'Connor wrote:
> Add missing regulator supplies for qfprom and the PCIe controllers.
> The qfprom node requires vcc-supply for correct eFuse reading. The
> PCIe controllers require vdda and vddpe-3v3 supplies for the PHY and
> connector power rails.
vddpe-3v3 is a legacy property for specifying power rails for connected
devices rather than the controller.
>
> Disable the Embedded USB Debugger (EUD) as it conflicts with normal
> USB operation on this board.
Separate commot please, with the description of the conflict.
>
> Tested on Radxa Dragon Q6A (QCS6490)
>
> Signed-off-by: Graham O'Connor <graham.oconnor@gmail.com>
> ---
> .../dts/qcom/qcs6490-radxa-dragon-q6a.dts | 20 +++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> index bb5a42b03..4003837ad 100644
> --- a/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> +++ b/arch/arm64/boot/dts/qcom/qcs6490-radxa-dragon-q6a.dts
> @@ -1093,3 +1093,23 @@ &sdc2_data {
> bias-pull-up;
> drive-strength = <10>;
> };
> +
> +/* Provide required regulator supplies for qfprom and PCIe controllers */
> +&qfprom {
> + vcc-supply = <&vreg_l1c_1p8>;
> +};
Please keep the nodes sorted.
> +
> +&pcie0 {
> + vdda-supply = <&vreg_l1c_1p8>;
> + vddpe-3v3-supply = <&vreg_bob_3p296>;
> +};
> +
> +&pcie1 {
> + vdda-supply = <&vreg_l1c_1p8>;
> + vddpe-3v3-supply = <&vreg_bob_3p296>;
> +};
> +
> +/* Disable EUD as it conflicts with USB operation */
> +&eud {
> + status = "disabled";
> +};
> --
> 2.53.0
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] crypto: Delete Qualcomm crypto engine driver
From: Dmitry Baryshkov @ 2026-05-24 16:42 UTC (permalink / raw)
To: demiobenour
Cc: Herbert Xu, David S. Miller, Thara Gopinath, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Bjorn Andersson, Konrad Dybcio,
Russell King, linux-kernel, linux-crypto, linux-arm-msm,
Eric Biggers, Ard Biesheuvel, devicetree, linux-arm-kernel
In-Reply-To: <20260523-delete-qce-v1-1-86105cd7f406@gmail.com>
On Sat, May 23, 2026 at 03:03:56PM -0400, Demi Marie Obenour via B4 Relay wrote:
> From: Demi Marie Obenour <demiobenour@gmail.com>
>
> It's slower than the generic C code and causes problems.
Which problems?
Also in the security world faster and safer are two orthogonal axis with
very limited correlation.
>
> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
> ---
> MAINTAINERS | 8 -
> arch/arm/configs/multi_v7_defconfig | 1 -
> arch/arm64/configs/defconfig | 1 -
> drivers/crypto/Kconfig | 111 -----
> drivers/crypto/Makefile | 1 -
> drivers/crypto/qce/Makefile | 9 -
> drivers/crypto/qce/aead.c | 841 ------------------------------------
> drivers/crypto/qce/aead.h | 56 ---
> drivers/crypto/qce/cipher.h | 56 ---
> drivers/crypto/qce/common.c | 595 -------------------------
> drivers/crypto/qce/common.h | 104 -----
> drivers/crypto/qce/core.c | 271 ------------
> drivers/crypto/qce/core.h | 64 ---
> drivers/crypto/qce/dma.c | 135 ------
> drivers/crypto/qce/dma.h | 47 --
> drivers/crypto/qce/regs-v5.h | 326 --------------
> drivers/crypto/qce/sha.c | 545 -----------------------
> drivers/crypto/qce/sha.h | 72 ---
> drivers/crypto/qce/skcipher.c | 529 -----------------------
> 19 files changed, 3772 deletions(-)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v7 9/9] arm64: dts: Add support for LX2160 Twins board in single configuration
From: Josua Mayer @ 2026-05-24 17:10 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: robh@kernel.org, devicetree@vger.kernel.org, Frank.Li@kernel.org,
imx@lists.linux.dev, conor+dt@kernel.org
In-Reply-To: <20260524161958.342981F000E9@smtp.kernel.org>
Am 24.05.26 um 18:19 schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The `gpio-mux` node for the fan tachometer multiplexer lacks an in-kernel consumer, which permanently locks the GPIOs and prevents the mux from being switched.
> --
>
> commit 3c28f80d13a11b4ba012fa933362f3d2ffeec63c
> 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 adds hardware support for various
> interfaces including SFP ports, OCP, USB, microSD, and power supplies.
>
>> 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..d16e273072754
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-half-twins.dts
> [ ... ]
>
>> + mux-controller {
>> + compatible = "gpio-mux";
>> + #mux-control-cells = <0>;
>> + /*
>> + * This gpio controlled mux can route the tacho signals of 6 PWM FAN connectors
>> + * to the tacho inputs of both CEX-7 modules (twins).
>> + *
>> + * The first twin controls this mux and monitors four fan connectors, two intended
>> + * for itself, and two for the OCP card.
>> + *
>> + * The second twin monitors only two fan connectors intended for itself.
>> + *
>> + * The table below maps selector GPIO states to monitored fan connector per twin:
>> + *
>> + * | SEL1 | SEL0 | Twin 1 | Twin 2 |
>> + * | ---: | ---: | :------| ------ |
>> + * | 0 | 0 | J10 | J5024 |
>> + * | 0 | 1 | J5016 | J5024 |
>> + * | 1 | 0 | J5026 | J5025 |
>> + * | 1 | 1 | J5013 | J5025 |
>> + */
>> + mux-gpios = <&expander0 8 GPIO_ACTIVE_HIGH>, /* SEL0 */
>> + <&expander0 15 GPIO_ACTIVE_HIGH>; /* SEL1 */
>> + };
> [Severity: Medium]
> Does this mux-controller lack an in-kernel consumer?
>
> When the gpio-mux driver probes, it exclusively requests and locks these GPIOs.
> However, there appears to be no consumer node in the device tree referencing
> this multiplexer to actually switch it.
>
> Since the Linux mux subsystem doesn't provide a userspace interface for
> switching, and the GPIO subsystem denies userspace access to locked pins, does
> this completely prevent both the kernel and userspace from switching the fan
> tachometer multiplexer?
>
> If so, doesn't this permanently lock the fan monitoring functionality in its
> default state?
>
As stated in previous version, the topology is too complex for hwmon
framework to utilize, so there is no in-kernel consumer.
The mux exists however and should be described.
^ permalink raw reply
* Re: [PATCH v7 1/9] arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions
From: Josua Mayer @ 2026-05-24 17:12 UTC (permalink / raw)
To: sashiko-reviews@lists.linux.dev
Cc: conor+dt@kernel.org, robh@kernel.org, Frank.Li@kernel.org,
devicetree@vger.kernel.org, imx@lists.linux.dev
In-Reply-To: <20260524151347.BD92A1F000E9@smtp.kernel.org>
Am 24.05.26 um 17:13 schrieb sashiko-bot@kernel.org:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] Expanding the 32-bit PCI outbound window to 3GB causes it to overlap with the inbound system memory address space, breaking DMA.
> - [High] The introduction of the 64-bit PCI memory range causes existing U-Boot bootloaders to fail device tree patching, breaking MSI and IOMMU.
> --
>
> commit a80e2e3f97808fdad781240469c5e07e019191e9
> Author: Josua Mayer <josua@solid-run.com>
>
> arm64: dts: lx2160a-rev2: extend 32-bit, and add 64-bit pci regions
>
> This commit extends the 32-bit PCIe memory regions to 3GB and adds 64-bit
> PCIe memory regions for LX2160A rev2. This allows allocation of large BARs
> requested by graphics processors or AI accelerators.
>
>> [4] pci bootloaderp atching related errors with IORESOURCE_MEM_64 flag:
>> [ 0.967809] layerscape-pcie 3800000.pcie: host bridge /soc/pcie@3800000 ranges:
>> [ 0.967830] layerscape-pcie 3800000.pcie: MEM 0xa400000000..0xa7ffffffff -> 0xa400000000
>> [ 0.967842] layerscape-pcie 3800000.pcie: MEM 0xa040000000..0xa0ffffffff -> 0x0040000000
>> [ 0.967849] layerscape-pcie 3800000.pcie: IO 0xa000010000..0xa00001ffff -> 0x0000000000
>> [ 1.169315] pci 0000:01:00.0: [8086:1572] type 00 class 0x020000 PCIe Endpoint
>> [ 1.169733] pci 0000:01:00.0: BAR 0 [mem 0x00000000-0x00ffffff 64bit pref]
>> [ 1.169771] pci 0000:01:00.0: BAR 3 [mem 0x00000000-0x00007fff 64bit pref]
>> [ 1.169796] pci 0000:01:00.0: ROM [mem 0x00000000-0x0007ffff pref]
>> [ 1.173389] OF: /soc/pcie@3800000: no msi-map translation for id 0x100 on (null)
>> [ 1.173515] OF: /soc/pcie@3800000: no iommu-map translation for id 0x100 on (null)
> [Severity: High]
> Does adding the 64-bit PCI memory range cause existing U-Boot bootloaders to
> fail device tree patching?
>
> When U-Boot encounters the 64-bit range, it appears fdt_fixup_pcie() aborts
> and fails to append the msi-map and iommu-map properties.
>
> Without iommu-map, the kernel will not attach the SMMU to the PCIe devices.
> Without msi-map, the kernel cannot translate PCIe Requester IDs to ITS
> Device IDs, which breaks MSI/MSI-X allocations.
>
> Could this prevent devices like NVMe drives from initializing and break
> compatibility with existing deployed bootloaders?
This was a stray error from previous version and was resolved by passing
correct flags, as present in v7.
>
>> diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
>> index f54005e37924b..db1ebee53f6f0 100644
>> --- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
>> +++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-rev2.dtsi
>> @@ -14,8 +14,9 @@ &pcie1 {
>> 0x80 0x00000000 0x0 0x00002000>; /* configuration space */
>> reg-names = "regs", "config";
>>
>> - ranges = <0x81000000 0x0 0x00000000 0x80 0x00010000 0x0 0x00010000
>> - 0x82000000 0x0 0x40000000 0x80 0x40000000 0x0 0x40000000>;
>> + ranges = <0x81000000 0x00 0x00000000 0x80 0x00010000 0x00 0x00010000>, /* 16-Bit IO Window */
>> + <0x82000000 0x00 0x40000000 0x80 0x40000000 0x00 0xc0000000>, /* 32-Bit - non-prefetchable */
>> + <0xC3000000 0x84 0x00000000 0x84 0x00000000 0x04 0x00000000>; /* 64-Bit - prefetchable - 16GB */
> [Severity: High]
> Does expanding the 32-bit PCI outbound window to 3GB (0xc0000000) cause it to
> overlap with inbound system memory?
>
> System memory starts at physical address 0x80000000. Since there isn't a
> dma-ranges property mapping inbound DMA to a different bus address, system
> memory uses a 1:1 mapping, meaning inbound DMA targets 0x80000000 and above.
>
> If a PCIe device requests a large 32-bit BAR, the kernel might allocate it
> within this 0x40000000-0xffffffff range. This causes the Root Port's
> downstream bridge Memory Limit register to be programmed to a value >=
> 0x80000000.
>
> A Root Port won't forward upstream memory transactions if the address falls
> within its programmed downstream window, as it assumes it is peer-to-peer
> traffic.
>
> Could this intercept endpoint DMA targeting system memory in the overlapped
> range and cause system hangs?
This configuration was tested with NVMe and GPUs,
the SMMU should ensure isolation pci bus addresses do not overlap with
physical ram base address.
^ permalink raw reply
* [PATCH v2] ASoC: dt-bindings: sound: asahi-kasei,ak5386: Convert DT schema
From: Manish Baing @ 2026-05-24 17:29 UTC (permalink / raw)
To: lgirdwood, broonie, robh, krzk+dt, conor+dt, zonque
Cc: linux-sound, devicetree, linux-kernel, manishbaing2789
Convert the Asahi Kasei AK5386 ADC binding from text format
to YAML schema.
Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
Changes in v2:
- Added dai-common.yaml reference and #sound-dai-cells to support
generic sound card DAI links.
- Changed additionalProperties to unevaluatedProperties: false.
- Restored legacy reset-gpio property as deprecated to maintain DT ABI
backward compatibility.
.../devicetree/bindings/sound/ak5386.txt | 23 --------
.../bindings/sound/asahi-kasei,ak5386.yaml | 56 +++++++++++++++++++
2 files changed, 56 insertions(+), 23 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/sound/ak5386.txt
create mode 100644 Documentation/devicetree/bindings/sound/asahi-kasei,ak5386.yaml
diff --git a/Documentation/devicetree/bindings/sound/ak5386.txt b/Documentation/devicetree/bindings/sound/ak5386.txt
deleted file mode 100644
index ec3df3abba0c..000000000000
--- a/Documentation/devicetree/bindings/sound/ak5386.txt
+++ /dev/null
@@ -1,23 +0,0 @@
-AK5386 Single-ended 24-Bit 192kHz delta-sigma ADC
-
-This device has no control interface.
-
-Required properties:
-
- - compatible : "asahi-kasei,ak5386"
-
-Optional properties:
-
- - reset-gpio : a GPIO spec for the reset/power down pin.
- If specified, it will be deasserted at probe time.
- - va-supply : a regulator spec, providing 5.0V
- - vd-supply : a regulator spec, providing 3.3V
-
-Example:
-
-spdif: ak5386@0 {
- compatible = "asahi-kasei,ak5386";
- reset-gpio = <&gpio0 23>;
- va-supply = <&vdd_5v0_reg>;
- vd-supply = <&vdd_3v3_reg>;
-};
diff --git a/Documentation/devicetree/bindings/sound/asahi-kasei,ak5386.yaml b/Documentation/devicetree/bindings/sound/asahi-kasei,ak5386.yaml
new file mode 100644
index 000000000000..8b9b9bdb3609
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/asahi-kasei,ak5386.yaml
@@ -0,0 +1,56 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/asahi-kasei,ak5386.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Asahi Kasei AK5386 ADC
+
+maintainers:
+ - Daniel Mack <zonque@gmail.com>
+
+description:
+ The Asahi Kasei AK5386 is a single-ended 24-Bit 192kHz delta-sigma
+ analog-to-digital converter (ADC). This device has no control interface.
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: asahi-kasei,ak5386
+
+ "#sound-dai-cells":
+ const: 0
+
+ reset-gpios:
+ maxItems: 1
+ description: A GPIO spec for the reset/power down pin.
+
+ reset-gpio:
+ maxItems: 1
+ deprecated: true
+ description: Legacy property, use reset-gpios instead.
+
+ va-supply:
+ description: Power supply for the analog section.
+
+ vd-supply:
+ description: Power supply for the digital section.
+
+required:
+ - compatible
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ adc {
+ compatible = "asahi-kasei,ak5386";
+ #sound-dai-cells = <0>;
+ reset-gpios = <&gpio0 23 GPIO_ACTIVE_LOW>;
+ va-supply = <&vdd_5v0_reg>;
+ vd-supply = <&vdd_3v3_reg>;
+ };
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] arm64: dts: allwinner: sun50i-a64: Enable DT overlays
From: Chen-Yu Tsai @ 2026-05-24 17:33 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jernej Skrabec,
Samuel Holland, devicetree, linux-arm-kernel, linux-sunxi,
Peter Robinson
In-Reply-To: <20260518220455.156874-1-pbrobinson@gmail.com>
On Mon, 18 May 2026 23:04:49 +0100, Peter Robinson wrote:
> Enable DT overlays on some of the Pine64 devices to enable
> use of addon accessories such as WiFi or audio modules.
>
>
Applied to sunxi/dt-for-7.2 in local tree, thanks!
[1/1] arm64: dts: allwinner: sun50i-a64: Enable DT overlays
commit: 3a6ffc1b4fcecd021361393d7294badb0d89e5b0
Best regards,
--
Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 5/9] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
From: Chen-Yu Tsai @ 2026-05-24 17:49 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: linux-sunxi, conor+dt, robh, devicetree, sashiko-reviews
In-Reply-To: <20260518161130.F0A4CC2BCB7@smtp.kernel.org>
On Mon, May 18, 2026 at 6:12 PM <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The `dphy` node is missing the required `interrupts` property and a SoC-specific compatible string.
> --
>
> commit ceae1b5da24380c4a30d9a8b480a23eaee3c0814
> Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>
> ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
>
> This commit adds MIPI CSI-2 support to the Allwinner V3s SoC. It introduces
> the device tree nodes for the CSI0 controller, the MIPI CSI-2 bridge, and
> the D-PHY block.
>
> > diff --git a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> > --- a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> > +++ b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> [ ... ]
> > + dphy: d-phy@1cb2000 {
> > + compatible = "allwinner,sun6i-a31-mipi-dphy";
>
> Should a SoC-specific compatible string like "allwinner,sun8i-v3s-mipi-dphy"
> be included here alongside the generic a31 fallback?
Following our general guideline, I believe it should.
> > + reg = <0x01cb2000 0x1000>;
> > + clocks = <&ccu CLK_BUS_CSI>,
> > + <&ccu CLK_MIPI_CSI>;
> > + clock-names = "bus", "mod";
> > + resets = <&ccu RST_BUS_CSI>;
>
> Will this node fail dtbs_check schema validation? The existing device tree
> binding schema for "allwinner,sun6i-a31-mipi-dphy" requires an interrupts
> property, which appears to be missing here.
Yeah, this is definitely going to fail validation.
> If the V3s hardware physically lacks a D-PHY interrupt, would it be better
> to add the V3s-specific compatible string and update the binding schema
> to make the interrupts property conditionally optional for the V3s?
FWIW the vendor kernel has some code for the D-PHY's interrupt bits [1].
Could you add the interrupt (I'm guessing the MIPI-CSI interrupt?) and
give it a quick test?
Thanks
ChenYu
[1] https://github.com/gediz/v3s-linux-sdk/blob/master/linux-3.4/drivers/media/video/sunxi-vfe/mipi_csi/dphy/dphy_reg.c
> > + allwinner,direction = "rx";
> > + status = "disabled";
> > + #phy-cells = <0>;
> > + };
> > +
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260518153339.619947-1-paulk@sys-base.io?part=5
>
^ permalink raw reply
* [PATCH] ARM: dts: imx7d-pico-pi: add OV5645 camera support
From: Lech Perczak @ 2026-05-24 17:53 UTC (permalink / raw)
To: devicetree, imx
Cc: Fabio Estevam, Frank Li, Sascha Hauer, Rob Herring,
Krzysztof Kozlowski, Lech Perczak, Lech Perczak
Add OV5645 camera device node and enable relevant components in the
video capture data path, so output stream can be captured, and the
camera itself can be controlled over I²C bus.
This is roughly based on descriptions found in downstream kernel tree [1],
adapted to match upstream bindings.
The camera can probe successfully and establish an image path through
MIPI-CSI and CSI peripherals, but so far I wasn't able to transfer the
actual image, probably due to pixel format incompatibilities between
the camera and CSI peripheral drivers - yet I'm hoping, that submitting
this will eventually help getting full support.
Link: https://github.com/technexion-android/kernel_imx/blob/ce8fd74abf518dac0a09e8dcb37f3496f6375124/arch/arm/boot/dts/imx7d-pico.dtsi#L874 [1]
Signed-off-by: Lech Perczak <lech.perczak@gmail.com>
---
arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts | 60 +++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts b/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
index 62221131336f..b36936ecfa4b 100644
--- a/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
+++ b/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
@@ -59,6 +59,33 @@ polytouch: touchscreen@38 {
touchscreen-size-x = <800>;
touchscreen-size-y = <480>;
};
+
+ camera@3c {
+ compatible = "ovti,ov5645";
+ reg = <0x3c>;
+
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_camera>;
+
+ clocks = <&clks IMX7D_CLKO1_ROOT_DIV>;
+ assigned-clocks = <&clks IMX7D_CLKO1_ROOT_DIV>;
+ assigned-clock-rates = <24000000>;
+
+ enable-gpios = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ reset-gpios = <&gpio1 5 GPIO_ACTIVE_LOW>;
+
+ vdda-supply = <®_2p5v>;
+ vdddo-supply = <®_vref_1v8>;
+ vddd-supply = <®_vref_1v8>;
+
+ port {
+ ov5645_to_mipi_csi2: endpoint {
+ remote-endpoint = <&mipi_csi2_in>;
+ clock-lanes = <0>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
};
&usdhc1 {
@@ -93,5 +120,38 @@ MX7D_PAD_EPDC_DATA04__GPIO2_IO4 0x14
MX7D_PAD_EPDC_DATA13__GPIO2_IO13 0x14
>;
};
+};
+
+&iomuxc_lpsr {
+ pinctrl_camera: cameragrp {
+ fsl,pins = <
+ MX7D_PAD_LPSR_GPIO1_IO04__GPIO1_IO4 0x15
+ MX7D_PAD_LPSR_GPIO1_IO05__GPIO1_IO5 0x15
+ MX7D_PAD_LPSR_GPIO1_IO02__CCM_CLKO1 0x7d
+ >;
+ };
+};
+
+&csi {
+ status = "okay";
+};
+
+&mipi_csi {
+ status = "okay";
+ clock-frequency = <24000000>;
+
+ ports {
+ port@0 {
+ reg = <0>;
+
+ mipi_csi2_in: endpoint {
+ remote-endpoint = <&ov5645_to_mipi_csi2>;
+ data-lanes = <1 2>;
+ };
+ };
+ };
+};
+&video_mux {
+ status = "okay";
};
base-commit: 79bd2dded182b1d458b18e62684b7f82ffc682e5
--
2.47.3
^ permalink raw reply related
* [PATCH 0/2] Add EPSS L3 provider support on Qualcomm Shikra SoC
From: Raviteja Laggyshetty @ 2026-05-24 18:03 UTC (permalink / raw)
To: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel,
Raviteja Laggyshetty, Odelu Kukatla
Add Epoch Subsystem (EPSS) L3 scaling support on Qualcomm Shikra SoC.
EPSS hardware on Shikra is similar to other SoCs but supports only twelve
L3 frequency entries (LUT). Reading the LUT beyond supported frequencies
can expose incorrect frequencies.
Introduce new dt-bindings and compatible to represent this constrained
variant of EPSS.
Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
---
Raviteja Laggyshetty (2):
dt-bindings: interconnect: qcom,shikra-epss-l3: Add EPSS L3 DT binding
interconnect: qcom: Add EPSS L3 scaling support for Shikra SoC
.../bindings/interconnect/qcom,shikra-epss-l3.yaml | 60 ++++++++++++++++++++++
drivers/interconnect/qcom/osm-l3.c | 16 +++++-
2 files changed, 75 insertions(+), 1 deletion(-)
---
base-commit: c1ecb239fa3456529a32255359fc78b69eb9d847
change-id: 20260524-shikra_epss_l3-522afe4fb8f5
Best regards,
--
Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: interconnect: qcom,shikra-epss-l3: Add EPSS L3 DT binding
From: Raviteja Laggyshetty @ 2026-05-24 18:03 UTC (permalink / raw)
To: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel,
Raviteja Laggyshetty, Odelu Kukatla
In-Reply-To: <20260524-shikra_epss_l3-v1-0-b1528a436134@oss.qualcomm.com>
Document the EPSS L3 interconnect provider binding for Qualcomm
Shikra SoC.
The Shikra EPSS L3 block is similar to existing Qualcomm EPSS/OSM L3
providers, but supports only up to 12 frequency lookup table entries.
Introduce Shikra specific bindings to represent this constrained
EPSS variant.
Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
---
.../bindings/interconnect/qcom,shikra-epss-l3.yaml | 60 ++++++++++++++++++++++
1 file changed, 60 insertions(+)
diff --git a/Documentation/devicetree/bindings/interconnect/qcom,shikra-epss-l3.yaml b/Documentation/devicetree/bindings/interconnect/qcom,shikra-epss-l3.yaml
new file mode 100644
index 000000000000..333ed40ea8e9
--- /dev/null
+++ b/Documentation/devicetree/bindings/interconnect/qcom,shikra-epss-l3.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/interconnect/qcom,shikra-epss-l3.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Epoch Subsystem (EPSS) L3 Shikra Interconnect Provider
+
+maintainers:
+ - Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
+
+description:
+ L3 cache bandwidth requirements on Qualcomm SoCs is serviced by the EPSS.
+ The EPSS L3 interconnect provider aggregates the L3 bandwidth requests
+ from CPU/GPU and relays it to the EPSS HW.
+
+ The Qualcomm Shikra SoC EPSS L3 supports up to twelve frequency lookup
+ table (LUT) entries.
+
+properties:
+ compatible:
+ enum:
+ - qcom,shikra-epss-l3
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ items:
+ - description: xo clock
+ - description: alternate clock
+
+ clock-names:
+ items:
+ - const: xo
+ - const: alternate
+
+ '#interconnect-cells':
+ const: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+ - clock-names
+ - '#interconnect-cells'
+
+additionalProperties: false
+
+examples:
+ - |
+ epss_l3: interconnect@fd90000 {
+ compatible = "qcom,shikra-epss-l3";
+ reg = <0xfd90000 0x1000>;
+
+ clocks = <&rpm_smd_xo_clk_src>, <&gpll0>;
+ clock-names = "xo", "alternate";
+
+ #interconnect-cells = <1>;
+ };
--
2.43.0
^ permalink raw reply related
* [PATCH 2/2] interconnect: qcom: Add EPSS L3 scaling support for Shikra SoC
From: Raviteja Laggyshetty @ 2026-05-24 18:03 UTC (permalink / raw)
To: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel,
Raviteja Laggyshetty, Odelu Kukatla
In-Reply-To: <20260524-shikra_epss_l3-v1-0-b1528a436134@oss.qualcomm.com>
Add Epoch Subsystem (EPSS) L3 interconnect provider support on
Qualcomm Shikra SoC.
The EPSS L3 block on Shikra SoC is similar to existing Qualcomm EPSS/OSM
L3 providers, but supports only up to 12 frequency lookup table entries.
Reading beyond the supported LUT entries can expose incorrect frequencies.
Add shikra-specific EPSS descriptor shikra_epss_l3_perf_state that reuses
existing EPSS configuration with appropriate LUT entries limit.
Co-developed-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
Signed-off-by: Odelu Kukatla <odelu.kukatla@oss.qualcomm.com>
Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
---
drivers/interconnect/qcom/osm-l3.c | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/interconnect/qcom/osm-l3.c b/drivers/interconnect/qcom/osm-l3.c
index b33f00da1880..ecad636b53e0 100644
--- a/drivers/interconnect/qcom/osm-l3.c
+++ b/drivers/interconnect/qcom/osm-l3.c
@@ -60,6 +60,7 @@ struct qcom_osm_l3_desc {
unsigned int lut_row_size;
unsigned int reg_freq_lut;
unsigned int reg_perf_state;
+ unsigned int lut_max_entries;
};
#define DEFINE_QNODE(_name, _buswidth) \
@@ -90,6 +91,7 @@ static const struct qcom_osm_l3_desc osm_l3 = {
.lut_row_size = OSM_LUT_ROW_SIZE,
.reg_freq_lut = OSM_REG_FREQ_LUT,
.reg_perf_state = OSM_REG_PERF_STATE,
+ .lut_max_entries = LUT_MAX_ENTRIES,
};
static const struct qcom_osm_l3_desc epss_l3_perf_state = {
@@ -98,6 +100,16 @@ static const struct qcom_osm_l3_desc epss_l3_perf_state = {
.lut_row_size = EPSS_LUT_ROW_SIZE,
.reg_freq_lut = EPSS_REG_FREQ_LUT,
.reg_perf_state = EPSS_REG_PERF_STATE,
+ .lut_max_entries = LUT_MAX_ENTRIES,
+};
+
+static const struct qcom_osm_l3_desc shikra_epss_l3_perf_state = {
+ .nodes = epss_l3_nodes,
+ .num_nodes = ARRAY_SIZE(epss_l3_nodes),
+ .lut_row_size = EPSS_LUT_ROW_SIZE,
+ .reg_freq_lut = EPSS_REG_FREQ_LUT,
+ .reg_perf_state = EPSS_REG_PERF_STATE,
+ .lut_max_entries = 12,
};
static const struct qcom_osm_l3_desc epss_l3_l3_vote = {
@@ -106,6 +118,7 @@ static const struct qcom_osm_l3_desc epss_l3_l3_vote = {
.lut_row_size = EPSS_LUT_ROW_SIZE,
.reg_freq_lut = EPSS_REG_FREQ_LUT,
.reg_perf_state = EPSS_REG_L3_VOTE,
+ .lut_max_entries = LUT_MAX_ENTRIES,
};
static int qcom_osm_l3_set(struct icc_node *src, struct icc_node *dst)
@@ -189,7 +202,7 @@ static int qcom_osm_l3_probe(struct platform_device *pdev)
qp->reg_perf_state = desc->reg_perf_state;
- for (i = 0; i < LUT_MAX_ENTRIES; i++) {
+ for (i = 0; i < desc->lut_max_entries; i++) {
info = readl_relaxed(qp->base + desc->reg_freq_lut +
i * desc->lut_row_size);
src = FIELD_GET(LUT_SRC, info);
@@ -272,6 +285,7 @@ static const struct of_device_id osm_l3_of_match[] = {
{ .compatible = "qcom,sc7180-osm-l3", .data = &osm_l3 },
{ .compatible = "qcom,sc7280-epss-l3", .data = &epss_l3_perf_state },
{ .compatible = "qcom,sdm845-osm-l3", .data = &osm_l3 },
+ { .compatible = "qcom,shikra-epss-l3", .data = &shikra_epss_l3_perf_state },
{ .compatible = "qcom,sm8150-osm-l3", .data = &osm_l3 },
{ .compatible = "qcom,sc8180x-osm-l3", .data = &osm_l3 },
{ .compatible = "qcom,sm8250-epss-l3", .data = &epss_l3_perf_state },
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 00/17] arm64: Use EL2 virtual timer when running VHE
From: Krzysztof Kozlowski @ 2026-05-24 18:17 UTC (permalink / raw)
To: Marc Zyngier, linux-arm-kernel, linux-acpi, linux-kernel,
devicetree
Cc: Lorenzo Pieralisi, Hanjun Guo, Sudeep Holla, Catalin Marinas,
Will Deacon, Rafael J. Wysocki, Mark Rutland, Daniel Lezcano,
Thomas Gleixner, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Chen-Yu Tsai, Jernej Skrabec, Samuel Holland, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, Ge Gordon,
BST Linux Kernel Upstream Group, Jesper Nilsson, Lars Persson,
Alim Akhtar, Ivaylo Ivanov, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Dinh Nguyen,
Matthias Brugger, AngeloGioacchino Del Regno, Thierry Reding,
Jonathan Hunter, Bjorn Andersson, Konrad Dybcio,
Andreas Färber, Yu-Chun Lin [林祐君],
Heiko Stuebner, Shawn Lin, Orson Zhai, Baolin Wang, Michal Simek
In-Reply-To: <20260523140242.586031-1-maz@kernel.org>
On 23/05/2026 16:02, Marc Zyngier wrote:
> This is the third version of the series initially posted at [1],
> which
>
> - updates the ACPI GTDT parsing to deal the v3 layout and the EL2
> virtual timer,
> - moves the architected timer driver to use it when running VHE,
> - fixes a number of DTs to reflect the reality of the HW.
>
Please mention here what do you expect SoC maintainer to do with this -
apply individual patches, wait for dependencies, ack etc.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] ARM: dts: imx7d-pico-pi: add OV5645 camera support
From: sashiko-bot @ 2026-05-24 18:20 UTC (permalink / raw)
To: Lech Perczak; +Cc: robh, conor+dt, devicetree, Frank.Li, imx
In-Reply-To: <20260524175312.10952-1-lech.perczak@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incorrect `clock-frequency` assignment in the `&mipi_csi` node drastically reduces the MIPI CSI wrapper clock, causing image capture failures.
--
commit aa98f4a3e7fa5b72ccc19a9fd456c518fe7ea6ff
Author: Lech Perczak <lech.perczak@gmail.com>
ARM: dts: imx7d-pico-pi: add OV5645 camera support
This commit adds the OV5645 camera device node and enables the relevant
components in the video capture data path for the imx7d-pico-pi. The
author noted that the camera probes successfully but image transfer fails,
suspecting pixel format incompatibilities.
Link: https://github.com/technexion-android/kernel_imx/blob/ce8fd74abf518dac0a09e8dcb37f3496f6375124/arch/arm/boot/dts/imx7d-pico.dtsi#L874 [1]
> diff --git a/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts b/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
> index 62221131336f1..b36936ecfa4ba 100644
> --- a/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
> +++ b/arch/arm/boot/dts/nxp/imx/imx7d-pico-pi.dts
[ ... ]
> @@ -93,5 +120,38 @@ MX7D_PAD_EPDC_DATA04__GPIO2_IO4 0x14
[ ... ]
> +&mipi_csi {
> + status = "okay";
> + clock-frequency = <24000000>;
[Severity: Medium]
Could this clock-frequency assignment be the cause of the image capture
failures mentioned in the commit message?
According to the nxp,imx-mipi-csi2.yaml binding schema and the
imx-mipi-csis.c driver, this deprecated property overrides the MIPI CSI-2
receiver's internal wrap clock.
By forcing this clock to 24 MHz, it drastically underclocks the peripheral
from its default of 166 MHz. This renders it too slow to process incoming
high-speed MIPI CSI-2 data.
Removing this property should allow the peripheral to use its proper
high-speed default clock.
> +
> + ports {
> + port@0 {
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260524175312.10952-1-lech.perczak@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 2/5] dt-bindings: connector: Add fsl,io-connector binding
From: Krzysztof Kozlowski @ 2026-05-24 18:20 UTC (permalink / raw)
To: Frank Li
Cc: Chancel Liu (OSS), Chancel Liu, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, s.hauer@pengutronix.de,
festevam@gmail.com, mturquette@baylibre.com, sboyd@kernel.org,
kernel@pengutronix.de, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, linux-clk@vger.kernel.org
In-Reply-To: <ag3GMdmxw60B15Oe@lizhi-Precision-Tower-5810>
On 20/05/2026 16:33, Frank Li wrote:
> On Wed, May 20, 2026 at 09:08:42AM +0200, Krzysztof Kozlowski wrote:
>> On 20/05/2026 07:02, Chancel Liu (OSS) wrote:
>>>>>>>>> +description:
>>>>>>>>> + The NXP I/O connector represents a physically present I/O
>>>>>>>>> +connector on the
>>>>>>>>> + base board. It acts as a nexus that exposes a constrained set
>>>> of
>>>>>>>>> +I/O
>>>>>>>>> + resources, such as GPIOs, clocks, PWMs and interrupts, through
>>>>>>>>> +fixed
>>>>>>>>> + electrical wiring. All actual hardware providers reside on the
>>>> base
>>>>>> board.
>>>>>>>>> + The connector node only defines index-based mappings to those
>>>>>>>> providers.
>>>>>>>>> +
>>>>>>>>> +properties:
>>>>>>>>> + compatible:
>>>>>>>>> + const: fsl,io-connector
>>>>>>>>
>>>>>>>> Everything is IO. Everything is connector, so your compatible does
>>>>>>>> not match requirements from writing bindings.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, this compatible is too generic. I will rename the compatible to
>>>>>>> fsl,aud-io-connector.
>>>>>>
>>>>>> aud is not much better. Which boards have it? What's the pinout?
>>>> What's
>>>>>> standard? Is it described anywhere? If so, provide reference to
>>>> spec/docs.
>>>>>>
>>>>>
>>>>> This is not an industry standard electrical interface. This connector
>>>>
>>>> Then if you do not have standard, then you have board specific layouts
>>>> thus you need board-specific compatibles. You can use fallbacks. Generic
>>>> fallback could work, but both io-connector and aud-io-connector are just
>>>> too generic. Every connector is "connector" and "io", thus absolutely
>>>> anything can be "io-connector". "aud" improves it only a bit, thus
>>>> honestly I would go with board specific fallback as well.
>>>>
>>>
>>> How about board specific + common fallback compatible like this:
>>> compatible:
>>> items:
>>> - enum:
>>> - fsl,imx95-19x19-evk-aud-io-connector
>>> - fsl,imx952-evk-aud-io-connector
>>> - const: fsl,imx-aud-io-connector
>>> Since the daughter board is named “IMX-AUD-IO” in publicly available
>>
>> I don't think it is named like that.
>>
>> git grep -i imx-aud-io
>>
>>> documentation, common compatible clearly indicates that this connector
>>> is intended for that.
>>>
>>> Also, I want to talk about the topic of generic connector. It's a common
>>> design that daughter board is connected to base board through a
>>> connector. This connector more often acts as a nexus that exposes a
>>> constrained subset of GPIO, clock, PWM and interrupt resources to the
>>> daughter board. Can we document this kind of connector as a generic
>>> binding?
>>
>> So this binding is the connector between carrier and some addon? Then
>> you don't get a compatible for that at all, because it is not necessary,
>> not useful and NEVER used. Do you see socket LGA "connector" bindings? No.
>
> Not exactly. Any connector connects a carrier board with an add-on board.
> The key point here is that this connector type is reused across different
> boards, even though it is not an industry-standard connector. Both the
> signal definitions and the mechanical layout are defined.
>
> The same add-on boards can therefore be reused across different base boards
> that use this type of connector.
>
> There are also GPIO mappings involved. For example, pin 1 on the connector
> may represent reset-gpios, but it could be connected to GPIO0 on board A
> and GPIO1 on board B.
>
> Without a connector definition layer, this would create an N × M
> combination problem. The Nexus node discussion already covered this topic:
> https://osseu2025.sched.com/event/25Vrw
>
> An LGA socket is a CPU socket, where the signals are completely transparent
> to software, so it is not a good comparison. A PCIe M.2 Key-M/E connector
> would be a more appropriate comparison.
>
So the terminology of daughter and carrier boards was confusing. If this
is a hat, mezzanine or other addon, it's fine.
I still insist on board specific compatibles - fallback and specific.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] arm64: dts: qcom: Move board nodes to common DTSI
From: Krzysztof Kozlowski @ 2026-05-24 18:23 UTC (permalink / raw)
To: Pankaj Patil, Dmitry Baryshkov, Gopikrishna Garmidi
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel,
sibi.sankar, rajendra.nayak
In-Reply-To: <05c377ab-33ef-44e7-8708-575647de088e@oss.qualcomm.com>
On 15/05/2026 11:14, Pankaj Patil wrote:
> On 3/29/2026 4:27 PM, Dmitry Baryshkov wrote:
>> On Fri, Mar 27, 2026 at 06:16:59PM +0530, Gopikrishna Garmidi wrote:
>>>
>>>
>>> On 3/26/2026 7:55 PM, Krzysztof Kozlowski wrote:
>>>> On 26/03/2026 15:21, Gopikrishna Garmidi wrote:
>>>>> The display, peripherals (touchpad/touchscreen/keypad), usb and their
>>>>> dependent device nodes are common to both Glymur and Mahua CRDs,
>>>>> so move them from glymur-crd.dts to glymur-crd.dtsi to enable code
>>>>> reuse.
>>>>>
>>>>
>>>> Same questions as for earlier tries (why this has to be repeated?), e.g.
>>>> x1-crd: Please describe here what is the actual common hardware. In
>>>> terms of physical hardware, not what you want to share.
>>>>
>>>
>>> Hi krzysztof,
>>>
>>> Thanks for the review,
>>>
>>> Will update the commit message in the next re-spin.
>>
>> Before you respin, you can actually respond to the question. Do Glymur
>> and Mahua CRD actually share those devices (in case of USB that would
>> mean having the same baseboard with different SoCs being wired) or is it
>> just "oh, this looks similar enough, let's create a common file".
>>
>
> Hello,
> Yes we've verified across glymur crd and mahua crd schematics, the regulator supply
> and data lines are common across both targets for the nodes in the patch
That's not an answer to the question. Or rather you just confirmed -
they are similar, so let's create a common file.
That's not a valid reason. Don't create common parts just because a few
nodes are the same.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] ASoC: dt-bindings: sound: atmel_ac97c: Convert to DT schema
From: Manish Baing @ 2026-05-24 18:33 UTC (permalink / raw)
To: claudiu.beznea, andrei.simion, lgirdwood, broonie, robh, krzk+dt,
conor+dt, nicolas.ferre, alexandre.belloni
Cc: linux-sound, devicetree, linux-arm-kernel, linux-kernel,
manishbaing2789
Convert the Atmel AC97 controller binding from text
format to YAML schema.
Signed-off-by: Manish Baing <manishbaing2789@gmail.com>
---
.../sound/atmel,at91sam9263-ac97c.yaml | 60 +++++++++++++++++++
.../devicetree/bindings/sound/atmel_ac97c.txt | 20 -------
2 files changed, 60 insertions(+), 20 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml
delete mode 100644 Documentation/devicetree/bindings/sound/atmel_ac97c.txt
diff --git a/Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml b/Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml
new file mode 100644
index 000000000000..870532927164
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/atmel,at91sam9263-ac97c.yaml
@@ -0,0 +1,60 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/atmel,at91sam9263-ac97c.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Atmel AC97 Controller
+
+maintainers:
+ - Nicolas Ferre <nicolas.ferre@microchip.com>
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+allOf:
+ - $ref: dai-common.yaml#
+
+properties:
+ compatible:
+ const: atmel,at91sam9263-ac97c
+
+ reg:
+ maxItems: 1
+ description: Address and length of the register set for the device.
+
+ interrupts:
+ maxItems: 1
+ description: Should contain the AC97 interrupt.
+
+ ac97-gpios:
+ minItems: 3
+ maxItems: 4
+ description: |
+ AC97 link GPIOs- sync, sdata_out, reset, and optional sdata_in.
+ The driver primarily uses the reset pin.
+
+ pinctrl-0: true
+
+ pinctrl-names:
+ const: default
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - ac97-gpios
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+ #include <dt-bindings/gpio/gpio.h>
+
+ sound@fffa0000 {
+ compatible = "atmel,at91sam9263-ac97c";
+ reg = <0xfffa0000 0x4000>;
+ interrupts = <18 IRQ_TYPE_LEVEL_HIGH 5>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_ac97>;
+ ac97-gpios = <&pioB 0 0>, <&pioB 2 0>, <&pioC 29 GPIO_ACTIVE_LOW>;
+ };
diff --git a/Documentation/devicetree/bindings/sound/atmel_ac97c.txt b/Documentation/devicetree/bindings/sound/atmel_ac97c.txt
deleted file mode 100644
index b151bd902ce3..000000000000
--- a/Documentation/devicetree/bindings/sound/atmel_ac97c.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-* Atmel AC97 controller
-
-Required properties:
- - compatible: "atmel,at91sam9263-ac97c"
- - reg: Address and length of the register set for the device
- - interrupts: Should contain AC97 interrupt
- - ac97-gpios: Please refer to soc-ac97link.txt, only ac97-reset is used
-Optional properties:
- - pinctrl-names, pinctrl-0: Please refer to pinctrl-bindings.txt
-
-Example:
-sound@fffa0000 {
- compatible = "atmel,at91sam9263-ac97c";
- pinctrl-names = "default";
- pinctrl-0 = <&pinctrl_ac97>;
- reg = <0xfffa0000 0x4000>;
- interrupts = <18 IRQ_TYPE_LEVEL_HIGH 5>;
-
- ac97-gpios = <&pioB 0 0 &pioB 2 0 &pioC 29 GPIO_ACTIVE_LOW>;
-};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 1/4] dt-bindings: clock: qcom: Add QREF regulator supplies for glymur
From: Krzysztof Kozlowski @ 2026-05-24 18:38 UTC (permalink / raw)
To: Manivannan Sadhasivam, Qiang Yu
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Taniya Das,
Konrad Dybcio, linux-arm-msm, linux-clk, devicetree, linux-kernel,
krishna.chundru
In-Reply-To: <4byxm3ybi5eqrsqmqi6u4abd37uxliagyolsqs6rtrexut6p5f@uotbli3vh6ja>
On 19/05/2026 13:25, Manivannan Sadhasivam wrote:
> On Mon, May 18, 2026 at 12:26:22AM -0700, Qiang Yu wrote:
>> On Mon, May 18, 2026 at 09:00:33AM +0200, Krzysztof Kozlowski wrote:
>>> On 18/05/2026 05:50, Qiang Yu wrote:
>>>> On Sun, May 17, 2026 at 10:27:39AM +0200, Krzysztof Kozlowski wrote:
>>>>> On 17/05/2026 07:39, Qiang Yu wrote:
>>>>>> On Thu, May 14, 2026 at 12:22:17PM +0200, Krzysztof Kozlowski wrote:
>>>>>>> On Wed, May 06, 2026 at 01:43:51AM -0700, Qiang Yu wrote:
>>>>>>>> Add regulator supply properties for the Glymur TCSR QREF/REFGEN blocks
>>>>>>>> required by clkref clocks.
>>>>>>>>
>>>>>>>> The vdda-qreftx*, vdda-qrefrpt*, and vdda-qrefrx* supplies map to common
>>>>>>>> QREF TX/RPT/RX components, while SoC-specific topology and instance count
>>>>>>>> differ. Document them here for qcom,glymur-tcsr.
>>>>>>>>
>>>>>>>> Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
>>>>>>>> ---
>>>>>>>> .../bindings/clock/qcom,sm8550-tcsr.yaml | 57 ++++++++++++++++++++++
>>>>>>>> 1 file changed, 57 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>>>>> index 1ccdf4b0f5dd..57921cb63230 100644
>>>>>>>> --- a/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>>>>> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8550-tcsr.yaml
>>>>>>>> @@ -51,6 +51,63 @@ properties:
>>>>>>>> '#reset-cells':
>>>>>>>> const: 1
>>>>>>>>
>>>>>>>> + vdda-refgen-0p9-supply: true
>>>>>>>> + vdda-refgen-1p2-supply: true
>>>>>>>> + vdda-qrefrx0-0p9-supply: true
>>>>>>>> + vdda-qrefrx1-0p9-supply: true
>>>>>>>> + vdda-qrefrx2-0p9-supply: true
>>>>>>>> + vdda-qrefrx4-0p9-supply: true
>>>>>>>> + vdda-qrefrx5-0p9-supply: true
>>>>>>>> + vdda-qreftx0-0p9-supply: true
>>>>>>>> + vdda-qreftx0-1p2-supply: true
>>>>>>>> + vdda-qreftx1-0p9-supply: true
>>>>>>>> + vdda-qrefrpt0-0p9-supply: true
>>>>>>>> + vdda-qrefrpt1-0p9-supply: true
>>>>>>>> + vdda-qrefrpt2-0p9-supply: true
>>>>>>>> + vdda-qrefrpt3-0p9-supply: true
>>>>>>>> + vdda-qrefrpt4-0p9-supply: true
>>>>>>>
>>>>>>> Either I do not understand your previous explanation:
>>>>>>> CXO -> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 -> PCIe4_PHY
>>>>>>>
>>>>>>> or this is still wrong. There is no TCSR here, so this proves nothing.
>>>>>>> If TCSR is TX0, then you do not have five of them...
>>>>>>>
>>>>>>> My previous comment stay - you are not describing the actual hardware
>>>>>>> here.
>>>>>>>
>>>>>> The CXO network "-> TX0 -> RPT0 -> RPT1 -> RPT2 -> RX2 ->" is referred to
>>>>>> as the QREF block, and each component is controlled by the tcsr_clkref_en
>>>>>> registers.
>>>>>
>>>>> Still no clue what this -> relation is. Again, describe the hardware.
>>>>>
>>>>>>
>>>>>> If a PHY receives its reference clock from QREF, it will have a clkref_en
>>>>>> register. However, this register may be located in different regions
>>>>>> depending on the target. On glymur it resides in TCSR, so I added these
>>>>>> LDOs QREF required in tcsr yaml.
>>>>> Registers are not described as supplies.
>>>>
>>>> I'm not descirbing register as supply.
>>>>
>>>> tx0-0p9/1p2 rpt0-0p9 rpt1-0p9 rpt2-0p9 rx2-0p9
>>>> | | | | |
>>>> | | | | |
>>>> CXO -> TX0 -------> RPT0 ------> RPT1 -> RPT2 -----> RX2 -> PCIe4_PHY
>>>> | | | | |
>>>> | | | | |
>>>> ---------------------------------------------------tcsr_clkref_en
>>>>
>>>> These components(TX/RTP/RX) can be disabled/enabled by tcsr_clkref_en
>>>> register, and they require power supplies.
>>>
>>> So I told you more than once - none of these are supplies to the TCSR.
>>> You clearly misunderstand what a supply is.
>>>
>>
>> The TCSR binding here describes the tcsr_clkref_en clock gate, not the
>> TCSR register block itself. The clock gate controls whether the reference
>> clock is forwarded through the QREF chain to the PHY.
>>
>> The QREF components (TX/RPT/RX) sit between the clock gate and the PHY.
>> They require LDO supplies to operate, and those supplies must be enabled
>> before the clock gate is asserted and disabled after it is deasserted.
>> This enable/disable sequencing is the responsibility of the clock gate
>> driver, not the PHY driver.
>>
>> Since the supplies are managed as part of the clock gate operation, they
>> are modeled as properties of the clock gate node. The node happens to live
>> in TCSR on glymur, but the supplies describe what the clock gate needs to
>> do its job, not what TCSR itself needs.
>>
>
> Just to add a bit more context:
>
> The QREF block supplies the reference clock to the PHY IPs. But the digital
> logic (register interface) to control this QREF block lives inside TCSR in some
> SoCs like Glymur. But AFAIK, the analog QREF circuitry is not inside TCSR, but
> somewhere near to PHYs.
>
> Also, QREF needs its own LDOs to operate and supply reference clocks to PHYs.
> Initially, we tried to add these QREF supplies to PHY node itself. But that was
> pushed back by Johan [1]. His argument was that since these LDOs power QREFs,
> not the PHY IPs, these supplies should not be added to the PHY nodes. And since
> we do not have a dedicated QREF DT node due to the fact that the QREF registers
> gets moved between various IPs based on the available space in the RTL. (It used
> to live in GCC, but now it is in TCSR and in the future it could be in some
> other IPs. Unfortunately, we cannot control this design)
>
> So he suggested to add these supplies to TCSR node which acts as a control
> interface to QREF, even though it is not an accurate hw representation either.
>
> And this patchset is based on that feedback only.
>
> But your argument is also valid that these supplies are not supplying the TCSR
> block in hw, but just the QREF analog circuitry living close to PHY.
>
> We are open to suggestions here as we do not know what is the accurate hardware
> description for these supplies/QREF.
As I understood these are real supplies to QREF which on these SoCs is
part of TCSR, so in general it is fine. Should be in its own binding
file, though.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/4] i3c: dw: Remove core reset "_rst" suffix
From: Krzysztof Kozlowski @ 2026-05-24 18:41 UTC (permalink / raw)
To: Jisheng Zhang
Cc: Alexandre Belloni, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, linux-i3c, devicetree, linux-kernel
In-Reply-To: <ag2eUlweJdgWRKUG@xhacker>
On 20/05/2026 13:43, Jisheng Zhang wrote:
> On Wed, May 20, 2026 at 09:13:58AM +0200, Krzysztof Kozlowski wrote:
>> On Tue, May 19, 2026 at 01:51:02PM +0800, Jisheng Zhang wrote:
>>> It's redundant. This suffix has been in the code from day1, fortunately
>>> there's no such dt property usage in all dw i3c users after grepping all
>>> dts files, so we can remove it.
>>
>> Hm, how could you grep all 3rd party / out of tree users of this?
>>
>>>
>>> Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
>>> ---
>>> drivers/i3c/master/dw-i3c-master.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/i3c/master/dw-i3c-master.c b/drivers/i3c/master/dw-i3c-master.c
>>> index 655693a2187e..c4a848cc978a 100644
>>> --- a/drivers/i3c/master/dw-i3c-master.c
>>> +++ b/drivers/i3c/master/dw-i3c-master.c
>>> @@ -1587,7 +1587,7 @@ int dw_i3c_common_probe(struct dw_i3c_master *master,
>>> return PTR_ERR(master->pclk);
>>>
>>> master->core_rst = devm_reset_control_get_optional_exclusive_deasserted(&pdev->dev,
>>> - "core_rst");
>>> + "core");
>>
>> ABI impact for something released since 2018. Cleanup of name is not
>> really worth affecting users. core_rst is not the best name but it is
>> not incorrect, either.
>>
> Hmm make sense.
> Two questions: if the ABI is introduced but never used by any intree
> users, is modifying the ABI taken as "ABI breakage"?
Yes. The out of tree user was working before. Now it is not working. How
is it not a "breakage"?
>
> if the ABI is only used by outtree users, can we modify the ABI?
Yes and no. Depends. It's up to platform maintainer and you need
reasons. The reasons MUST be documented. See writing-bindings. I do not
see here a good reason.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: interconnect: qcom,x1e80100-rpmh: add clocks property to enable QoS
From: Raviteja Laggyshetty @ 2026-05-24 18:44 UTC (permalink / raw)
To: Dmitry Baryshkov, Krzysztof Kozlowski
Cc: Georgi Djakov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rajendra Nayak, Abel Vesa, Bjorn Andersson, Konrad Dybcio,
Odelu Kukatla, linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <nr62mvz6qrpb6moqyasniqcqtfltsx4qtr3lteeixwutindqri@5joujdvn4r3q>
On 5/21/2026 5:26 AM, Dmitry Baryshkov wrote:
> On Wed, May 20, 2026 at 09:33:52PM +0200, Krzysztof Kozlowski wrote:
>> On 20/05/2026 21:27, Dmitry Baryshkov wrote:
>>> On Wed, May 20, 2026 at 10:11:47PM +0300, Georgi Djakov wrote:
>>>> On 5/20/26 9:51 PM, Krzysztof Kozlowski wrote:
>>>>> On 23/04/2026 10:38, Krzysztof Kozlowski wrote:
>>>>>> On Wed, Apr 22, 2026 at 02:05:11AM +0000, Raviteja Laggyshetty wrote:
>>>>>>> Some interconnect nodes on X1E80100 have QoS registers located inside
>>>>>>> a block whose interface is clock-gated. For those nodes, driver
>>>>>>> must enable the corresponding clock(s) before accessing the
>>>>>>> registers. Add the 'clocks' property so the driver can obtain
>>>>>>> and enable the required clock(s).
>>>>>>>
>>>>>>> Only interconnects that have clock-gated QoS register interface
>>>>>>> use this property; it is not applicable to all interconnect nodes.
>>>>>>>
>>>>>>> Signed-off-by: Raviteja Laggyshetty <raviteja.laggyshetty@oss.qualcomm.com>
>>>>>>> ---
>>>>>>> .../bindings/interconnect/qcom,x1e80100-rpmh.yaml | 62 ++++++++++++++++++++++
>>>>>>> 1 file changed, 62 insertions(+)
>>>>>>
>>>>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>>
>>>>> And unreviewed as it breaks users:
>>>>> https://krzk.eu/#/builders/102/builds/70/steps/23/logs/warnings__3_
>>>>>
>>>>
>>>> I will just drop these patches for now, i have put them in a separate branch anyway.
>>>
>>> I think, dropping 'required' clause would be the easiest fix. Or just
>>> wait for Bjorn to pick up the DT changes.
>>
>> Could be, initially I thought this is actual impact on users, but indeed
>> now I recall that driver prints "info" message and continues. So the
>> binding is not correct.
>
> I'd say, the binding was not correct: the hardware has the clocks and
> the requires them to function completely correctly. I think, the problem
> is that we allowed incomplete drivers and incomplete bindings (Without
> QoS support).
>
Thanks for pointing this out, and sorry for the breakage caused.
This is one of the earlier targets where interconnect support was
upstreamed without QoS support. Making the `clocks` property required broke
existing DTs for that target, if the corresponding DT changes are not
picked.
For newer targets, this should not be an issue as QoS support is introduced
along with interconnect.
I will respin the patch following commit
e07f3b8c9e1c ("dt-bindings: interconnect: qcom,qcs615-rpmh: add clocks
property to enable QoS"),
keeping the QoS-related clocks optional to maintain backward compatibility.
Thanks,
Raviteja.
^ 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