* Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display
From: Krzysztof Kozlowski @ 2026-03-31 15:06 UTC (permalink / raw)
To: Konrad Dybcio, Krzysztof Kozlowski, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa
In-Reply-To: <f4ee7476-74d8-4e88-b14f-64835e6e7fbc@oss.qualcomm.com>
On 31/03/2026 17:03, Konrad Dybcio wrote:
> On 3/31/26 5:01 PM, Krzysztof Kozlowski wrote:
>> On 31/03/2026 16:49, Konrad Dybcio wrote:
>>> On 3/31/26 4:02 PM, Krzysztof Kozlowski wrote:
>>>> Dependency
>>>> ==========
>>>> Depends on USB patches, which are being reviewed, therefore marking it
>>>> as RFC as it cannot be applied.
>>>> https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
>>>>
>>>> Unmerged bindings used here
>>>> ===========================
>>>> dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
>>>> (DRM MDSS bindings were applied)
>>>>
>>>> Description
>>>> ===========
>>>> I did not enable DisplayPort because it does not work on my board and I
>>>> don't know why. I double checked QMP combo phy and other bits, and
>>>> everything is looking fine, but still no USB display, so maybe I miss
>>>> some other dependencies as this is early upstream.
>>>
>>> What was the furthest that you got? We can certainly try to help..
>>>
>>> Got USB Type-C mode mux events?
>>> PHY initialized and configured to 2/4-lane DP mode?
>>> Are the AUX transfers failling?
>>
>> [ 43.975329] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
>> [ 43.975410] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
>> [ 45.780383] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
>> [ 45.780463] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
>> [ 45.780521] msm_dpu ae01000.display-controller: [drm:msm_dp_pm_runtime_suspend] type=10 core_init=1 phy_init=1
>>
>> pastebin: https://pastebin.com/BVXy3Qeq
>>
>> Abel pointed me to the phy problems, so I focused on that.
>> HSR says it is exactly same programming sequence as SM8650
>> and such was used.
>>
>> Just note, that we have ADSP remoteproc up, but no audio including USB mux,
>
> Are you talking about wcd939x-mux?
Yes
>
> If so, you need that or the lanes won't be properly connected
Ha! That would explain, although I had impression that with disabled
WCD939x mux the SM8750 DP still works.
Well, I don't have that WCD939x and it is left for other team to finish
a bit later, so we can leave the USB DP for now. I will re-visit that
when audio progresses.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display
From: Konrad Dybcio @ 2026-03-31 15:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Krzysztof Kozlowski, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa
In-Reply-To: <b3b96c87-83dd-422b-a67c-cfe41ae94a35@kernel.org>
On 3/31/26 5:01 PM, Krzysztof Kozlowski wrote:
> On 31/03/2026 16:49, Konrad Dybcio wrote:
>> On 3/31/26 4:02 PM, Krzysztof Kozlowski wrote:
>>> Dependency
>>> ==========
>>> Depends on USB patches, which are being reviewed, therefore marking it
>>> as RFC as it cannot be applied.
>>> https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
>>>
>>> Unmerged bindings used here
>>> ===========================
>>> dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
>>> (DRM MDSS bindings were applied)
>>>
>>> Description
>>> ===========
>>> I did not enable DisplayPort because it does not work on my board and I
>>> don't know why. I double checked QMP combo phy and other bits, and
>>> everything is looking fine, but still no USB display, so maybe I miss
>>> some other dependencies as this is early upstream.
>>
>> What was the furthest that you got? We can certainly try to help..
>>
>> Got USB Type-C mode mux events?
>> PHY initialized and configured to 2/4-lane DP mode?
>> Are the AUX transfers failling?
>
> [ 43.975329] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
> [ 43.975410] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
> [ 45.780383] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
> [ 45.780463] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
> [ 45.780521] msm_dpu ae01000.display-controller: [drm:msm_dp_pm_runtime_suspend] type=10 core_init=1 phy_init=1
>
> pastebin: https://pastebin.com/BVXy3Qeq
>
> Abel pointed me to the phy problems, so I focused on that.
> HSR says it is exactly same programming sequence as SM8650
> and such was used.
>
> Just note, that we have ADSP remoteproc up, but no audio including USB mux,
Are you talking about wcd939x-mux?
If so, you need that or the lanes won't be properly connected
Konrad
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: display: waveshare,dsp2dpi: describe DSI2LVDS setup
From: Dmitry Baryshkov @ 2026-03-31 15:01 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, dri-devel,
devicetree, linux-kernel
In-Reply-To: <20260331-roaring-carrot-stork-edaef8@quoll>
On Tue, Mar 31, 2026 at 10:40:12AM +0200, Krzysztof Kozlowski wrote:
> On Mon, Mar 30, 2026 at 04:25:50PM +0300, Dmitry Baryshkov wrote:
> > Several the Waveshare DSI LCD panel kits use DSI2LVDS ICN6202 bridge
>
> If you know the hardware bridge used, should not it be the front
> compatible (with waveshare,dsi2lvds fallback)? Or even alone? Can the
> waveshare kits come with different bridges? I guess yes, they could.
I assume so. I have only several samples. Probably we can decode it from
the kit images, when available.
>
> > together with the LVDS panels. Define new compatible for the on-kit
> > bridge setup (it is not defailed and it uses Waveshare prefix since the
>
> typo: detailed
>
> > rest of the integration details are not known).
> >
>
> Please also update at least description:
> "...converts DSI to DPI or LVDS."
> or similar.
>
> Best regards,
> Krzysztof
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display
From: Krzysztof Kozlowski @ 2026-03-31 15:01 UTC (permalink / raw)
To: Konrad Dybcio, Krzysztof Kozlowski, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa
In-Reply-To: <e4cad76c-09ad-45e9-8725-ec156c121bb8@oss.qualcomm.com>
On 31/03/2026 16:49, Konrad Dybcio wrote:
> On 3/31/26 4:02 PM, Krzysztof Kozlowski wrote:
>> Dependency
>> ==========
>> Depends on USB patches, which are being reviewed, therefore marking it
>> as RFC as it cannot be applied.
>> https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
>>
>> Unmerged bindings used here
>> ===========================
>> dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
>> (DRM MDSS bindings were applied)
>>
>> Description
>> ===========
>> I did not enable DisplayPort because it does not work on my board and I
>> don't know why. I double checked QMP combo phy and other bits, and
>> everything is looking fine, but still no USB display, so maybe I miss
>> some other dependencies as this is early upstream.
>
> What was the furthest that you got? We can certainly try to help..
>
> Got USB Type-C mode mux events?
> PHY initialized and configured to 2/4-lane DP mode?
> Are the AUX transfers failling?
[ 43.975329] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
[ 43.975410] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
[ 45.780383] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_access] dpu_dp_aux: Too many retries, giving up. First error: -110
[ 45.780463] msm_dpu ae01000.display-controller: [drm:drm_dp_dpcd_probe] dpu_dp_aux: 0x00102 AUX -> (ret=-110)
[ 45.780521] msm_dpu ae01000.display-controller: [drm:msm_dp_pm_runtime_suspend] type=10 core_init=1 phy_init=1
pastebin: https://pastebin.com/BVXy3Qeq
Abel pointed me to the phy problems, so I focused on that.
HSR says it is exactly same programming sequence as SM8650
and such was used.
Just note, that we have ADSP remoteproc up, but no audio including USB mux,
although that should not affect this, AFAIU.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: media: hisilicon,hix5hd2-ir: convert to YAML
From: Andrea Poldi @ 2026-03-31 14:58 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Shawn Guo
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-media,
devicetree, linux-kernel, Andrea Poldi
Convert the HiSilicon Hix5hd2 IR bindings to DT schema.
Signed-off-by: Andrea Poldi <andrea@riposetti.com>
---
.../bindings/media/hisilicon,hix5hd2-ir.yaml | 53 +++++++++++++++++++
.../devicetree/bindings/media/hix5hd2-ir.txt | 26 ---------
2 files changed, 53 insertions(+), 26 deletions(-)
create mode 100644 Documentation/devicetree/bindings/media/hisilicon,hix5hd2-ir.yaml
delete mode 100644 Documentation/devicetree/bindings/media/hix5hd2-ir.txt
diff --git a/Documentation/devicetree/bindings/media/hisilicon,hix5hd2-ir.yaml b/Documentation/devicetree/bindings/media/hisilicon,hix5hd2-ir.yaml
new file mode 100644
index 000000000000..f5c28603ed0a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/hisilicon,hix5hd2-ir.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/media/hisilicon,hix5hd2-ir.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: HiSilicon Hix5hd2 Infrared Receiver
+
+maintainers:
+ - Shawn Guo <shawn.guo@linaro.org>
+
+allOf:
+ - $ref: rc.yaml#
+
+properties:
+ compatible:
+ enum:
+ - hisilicon,hix5hd2-ir
+ - hisilicon,hi3796cv300-ir
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+ hisilicon,power-syscon:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: phandle of syscon used to control power.
+ deprecated: true
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/arm-gic.h>
+
+ ir@f8001000 {
+ compatible = "hisilicon,hix5hd2-ir";
+ reg = <0xf8001000 0x1000>;
+ interrupts = <0 47 4>;
+ clocks = <&clock 0>;
+ linux,rc-map-name = "rc-tivo";
+ };
diff --git a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt b/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
deleted file mode 100644
index ca4cf774662e..000000000000
--- a/Documentation/devicetree/bindings/media/hix5hd2-ir.txt
+++ /dev/null
@@ -1,26 +0,0 @@
-Device-Tree bindings for hix5hd2 ir IP
-
-Required properties:
- - compatible: Should contain "hisilicon,hix5hd2-ir", or:
- - "hisilicon,hi3796cv300-ir" for Hi3796CV300 IR device.
- - reg: Base physical address of the controller and length of memory
- mapped region.
- - interrupts: interrupt-specifier for the sole interrupt generated by
- the device. The interrupt specifier format depends on the interrupt
- controller parent.
- - clocks: clock phandle and specifier pair.
-
-Optional properties:
- - linux,rc-map-name: see rc.txt file in the same directory.
- - hisilicon,power-syscon: DEPRECATED. Don't use this in new dts files.
- Provide correct clocks instead.
-
-Example node:
-
- ir: ir@f8001000 {
- compatible = "hisilicon,hix5hd2-ir";
- reg = <0xf8001000 0x1000>;
- interrupts = <0 47 4>;
- clocks = <&clock HIX5HD2_IR_CLOCK>;
- linux,rc-map-name = "rc-tivo";
- };
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH 1/2] reset: amlogic: t7: Fix null reset ops
From: Philipp Zabel @ 2026-03-31 14:54 UTC (permalink / raw)
To: Ronald Claveau, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-1-eb95b625234c@aliel.fr>
On Di, 2026-03-31 at 16:24 +0200, Ronald Claveau wrote:
> Fix missing reset ops causing kernel null pointer dereference.
> This SOC's reset is currently not used yet.
>
> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
This is
Fixes: fb4c31587adf ("reset: amlogic: add auxiliary reset driver support")
Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>
regards
Philipp
^ permalink raw reply
* [PATCH] arm64: dts: renesas: rzt2h-n2h-evk: Configure eMMC/SDHI pins
From: Fabrizio Castro @ 2026-03-31 14:52 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Fabrizio Castro, linux-renesas-soc, devicetree, linux-kernel,
Biju Das, Lad Prabhakar
The HW user manual for the Renesas RZ/T2H and the RZ/N2H state
that for SDR104, SDR50, and HS200 to work properly the eMMC/SDHI
interface pins have to be configured as specified below:
* SDn_CLK pin - drive strength: Ultra High, slew rate: fast
* Other SDn_* pins: drive strength: High, slew rate: fast,
Schmitt trigger: disabled (not applicable to SDn_RST pins).
Adjust the pin definitions accordingly.
Signed-off-by: Fabrizio Castro <fabrizio.castro.jz@renesas.com>
---
.../dts/renesas/rzt2h-n2h-evk-common.dtsi | 54 ++++++++++++++++---
1 file changed, 46 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi b/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi
index f87c2492f414..3fae950db603 100644
--- a/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzt2h-n2h-evk-common.dtsi
@@ -275,12 +275,28 @@ data-pins {
<RZT2H_PORT_PINMUX(12, 7, 0x29)>, /* SD0_DATA5 */
<RZT2H_PORT_PINMUX(13, 0, 0x29)>, /* SD0_DATA6 */
<RZT2H_PORT_PINMUX(13, 1, 0x29)>; /* SD0_DATA7 */
+ drive-strength-microamp = <9000>;
+ slew-rate = <1>;
+ input-schmitt-disable;
};
- ctrl-pins {
- pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>, /* SD0_CLK */
- <RZT2H_PORT_PINMUX(12, 1, 0x29)>, /* SD0_CMD */
- <RZT2H_PORT_PINMUX(13, 2, 0x29)>; /* SD0_RST# */
+ clk-pins {
+ pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>; /* SD0_CLK */
+ drive-strength-microamp = <11800>;
+ slew-rate = <1>;
+ };
+
+ cmd-pins {
+ pinmux = <RZT2H_PORT_PINMUX(12, 1, 0x29)>; /* SD0_CMD */
+ drive-strength-microamp = <9000>;
+ slew-rate = <1>;
+ input-schmitt-disable;
+ };
+
+ rst-pins {
+ pinmux = <RZT2H_PORT_PINMUX(13, 2, 0x29)>; /* SD0_RST# */
+ drive-strength-microamp = <9000>;
+ slew-rate = <1>;
};
};
@@ -299,12 +315,23 @@ data-pins {
<RZT2H_PORT_PINMUX(12, 3, 0x29)>, /* SD0_DATA1 */
<RZT2H_PORT_PINMUX(12, 4, 0x29)>, /* SD0_DATA2 */
<RZT2H_PORT_PINMUX(12, 5, 0x29)>; /* SD0_DATA3 */
+ drive-strength-microamp = <9000>;
+ slew-rate = <1>;
+ input-schmitt-disable;
+ };
+
+ clk-pins {
+ pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>; /* SD0_CLK */
+ drive-strength-microamp = <11800>;
+ slew-rate = <1>;
};
ctrl-pins {
- pinmux = <RZT2H_PORT_PINMUX(12, 0, 0x29)>, /* SD0_CLK */
- <RZT2H_PORT_PINMUX(12, 1, 0x29)>, /* SD0_CMD */
+ pinmux = <RZT2H_PORT_PINMUX(12, 1, 0x29)>, /* SD0_CMD */
<RZT2H_PORT_PINMUX(22, 5, 0x29)>; /* SD0_CD */
+ drive-strength-microamp = <9000>;
+ slew-rate = <1>;
+ input-schmitt-disable;
};
};
@@ -323,12 +350,23 @@ data-pins {
<RZT2H_PORT_PINMUX(17, 0, 0x29)>, /* SD1_DATA1 */
<RZT2H_PORT_PINMUX(17, 1, 0x29)>, /* SD1_DATA2 */
<RZT2H_PORT_PINMUX(17, 2, 0x29)>; /* SD1_DATA3 */
+ drive-strength-microamp = <9000>;
+ slew-rate = <1>;
+ input-schmitt-disable;
+ };
+
+ clk-pins {
+ pinmux = <RZT2H_PORT_PINMUX(16, 5, 0x29)>; /* SD1_CLK */
+ drive-strength-microamp = <11800>;
+ slew-rate = <1>;
};
ctrl-pins {
- pinmux = <RZT2H_PORT_PINMUX(16, 5, 0x29)>, /* SD1_CLK */
- <RZT2H_PORT_PINMUX(16, 6, 0x29)>, /* SD1_CMD */
+ pinmux = <RZT2H_PORT_PINMUX(16, 6, 0x29)>, /* SD1_CMD */
<RZT2H_PORT_PINMUX(17, 4, 0x29)>; /* SD1_CD */
+ drive-strength-microamp = <9000>;
+ slew-rate = <1>;
+ input-schmitt-disable;
};
};
};
--
2.34.1
^ permalink raw reply related
* Re: [PATCH RFC 0/2] arm64: dts: qcom: eliza: Add display
From: Konrad Dybcio @ 2026-03-31 14:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Abel Vesa
In-Reply-To: <20260331-dts-qcom-eliza-display-v1-0-856f0b66b282@oss.qualcomm.com>
On 3/31/26 4:02 PM, Krzysztof Kozlowski wrote:
> Dependency
> ==========
> Depends on USB patches, which are being reviewed, therefore marking it
> as RFC as it cannot be applied.
> https://lore.kernel.org/all/20260331-eliza-adsp-usb-v1-0-d8a251be20c3@oss.qualcomm.com/
>
> Unmerged bindings used here
> ===========================
> dispcc: https://lore.kernel.org/all/20260319-clk-qcom-dispcc-eliza-v3-0-d1f2b19a6e6b@oss.qualcomm.com/
> (DRM MDSS bindings were applied)
>
> Description
> ===========
> I did not enable DisplayPort because it does not work on my board and I
> don't know why. I double checked QMP combo phy and other bits, and
> everything is looking fine, but still no USB display, so maybe I miss
> some other dependencies as this is early upstream.
What was the furthest that you got? We can certainly try to help..
Got USB Type-C mode mux events?
PHY initialized and configured to 2/4-lane DP mode?
Are the AUX transfers failling?
Konrad
^ permalink raw reply
* Re: [PATCH v12 2/3] of: Factor arguments passed to of_map_id() into a struct
From: Frank Li @ 2026-03-31 14:43 UTC (permalink / raw)
To: Vijayanand Jitta
Cc: Nipun Gupta, Nikhil Agarwal, Joerg Roedel, Will Deacon,
Robin Murphy, Marc Zyngier, Lorenzo Pieralisi, Thomas Gleixner,
Saravana Kannan, Richard Zhu, Lucas Stach,
Krzysztof Wilczyński, Manivannan Sadhasivam, Bjorn Helgaas,
Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Juergen Gross, Stefano Stabellini, Oleksandr Tyshchenko,
Dmitry Baryshkov, Konrad Dybcio, Bjorn Andersson, Rob Herring,
Conor Dooley, Krzysztof Kozlowski, Prakash Gupta, Vikash Garodia,
linux-kernel, iommu, linux-arm-kernel, devicetree, linux-pci, imx,
xen-devel, linux-arm-msm, Charan Teja Kalla
In-Reply-To: <20260331-parse_iommu_cells-v12-2-decfd305eea9@oss.qualcomm.com>
On Tue, Mar 31, 2026 at 07:34:47PM +0530, Vijayanand Jitta wrote:
> From: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
>
> Change of_map_id() to take a pointer to struct of_phandle_args
> instead of passing target device node and translated IDs separately.
> Update all callers accordingly.
>
> Add an explicit filter_np parameter to of_map_id() and of_map_msi_id()
> to separate the filter input from the output. Previously, the target
> parameter served dual purpose: as an input filter (if non-NULL, only
> match entries targeting that node) and as an output (receiving the
> matched node with a reference held). Now filter_np is the explicit
> input filter and arg->np is the pure output.
>
> Previously, of_map_id() would call of_node_put() on the matched node
> when a filter was provided, making reference ownership inconsistent.
> Remove this internal of_node_put() call so that of_map_id() now always
> transfers ownership of the matched node reference to the caller via
> arg->np. Callers are now consistently responsible for releasing this
> reference with of_node_put(arg->np) when done.
>
> Suggested-by: Rob Herring (Arm) <robh@kernel.org>
> Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Charan Teja Kalla <charan.kalla@oss.qualcomm.com>
> Signed-off-by: Vijayanand Jitta <vijayanand.jitta@oss.qualcomm.com>
> ---
> drivers/cdx/cdx_msi.c | 7 ++--
> drivers/iommu/of_iommu.c | 4 +-
> drivers/irqchip/irq-gic-its-msi-parent.c | 11 ++++--
> drivers/of/base.c | 68 +++++++++++++++++---------------
> drivers/of/irq.c | 10 ++++-
> drivers/pci/controller/dwc/pci-imx6.c | 32 +++++++--------
>
> for imx part.
>
> Reviewed-by: Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* Re: [PATCH ath-next v3 1/6] dt-bindings: net: wireless: add ath12k wifi device IPQ5424
From: Krzysztof Kozlowski @ 2026-03-31 14:42 UTC (permalink / raw)
To: Jeff Johnson, Raj Kumar Bhagat
Cc: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, linux-wireless, devicetree, linux-kernel, ath12k
In-Reply-To: <b1194bdb-75fa-4f2e-b4a3-9565b11bb3e9@oss.qualcomm.com>
On 31/03/2026 16:23, Jeff Johnson wrote:
> On 3/31/2026 12:24 AM, Krzysztof Kozlowski wrote:
>> On Tue, Mar 31, 2026 at 02:09:06AM +0530, Raj Kumar Bhagat wrote:
>>> $id: http://devicetree.org/schemas/net/wireless/qcom,ipq5332-wifi.yaml#
>>> @@ -17,6 +17,7 @@ properties:
>>> compatible:
>>> enum:
>>> - qcom,ipq5332-wifi
>>> + - qcom,ipq5424-wifi
>>
>> No, use previous patch.
>>
>> I am annoyed that you keep making changes even for such trivialities and
>> require re-review from the community. Previous patch was correct. This
>> one doing whatever you want to do in copyrights is too much. You don't
>> change copyrights just because you wrote one device model.
>
> Krzysztof,
>
> FYI here is the guidance I received from Qualcomm legal (links to internal
> documentation, removed -- I've forwarded the entire e-mail to your Qualcomm
> mailbox):
As I explained already more than once, legal can engage in open source
discussions directly. I am not going to discuss with them via proxies.
>
> ... Repos under copyleft license [...] QTI copyright must be added when we
> make significant changes.
>
> ... Repos under friendly license (BSD, Apache, MIT, ...) [...] QTI copyright
> must be added for any changes, not just significant ones.
>
> ... under the regular QUIC to QTI open-source copyright transitioning [...]
> all QUIC Copyright instances should be replaced with year-less QTI OSS Copyright.
>
> I'll follow up with them on this case where there is a dual-license file.
You nicely removed the quote where they ask to follow what the upstream
maintainer asks for. So as one of the maintainers I ask not to change
it, because it is churn and pointless waste of my time.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Liviu Dudau @ 2026-03-31 14:31 UTC (permalink / raw)
To: Guangliu Ding
Cc: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
David Airlie, Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Jiyu Yang
In-Reply-To: <20260331-master-v1-1-65c8e318d462@nxp.com>
On Tue, Mar 31, 2026 at 06:12:38PM +0800, Guangliu Ding wrote:
> Add compatible string of Mali G310 GPU on i.MX952 board.
>
> Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
> Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> index 8eccd4338a2b..6a10843a26e2 100644
> --- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> +++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
> @@ -20,6 +20,7 @@ properties:
> - enum:
> - mediatek,mt8196-mali
> - nxp,imx95-mali # G310
> + - nxp,imx952-mali # G310
Can you explain why this is needed? Can it not be covered by the existing compatible?
Best regards,
Liviu
> - rockchip,rk3588-mali
> - const: arm,mali-valhall-csf # Mali Valhall GPU model/revision is fully discoverable
>
>
> --
> 2.34.1
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
¯\_(ツ)_/¯
^ permalink raw reply
* [PATCH 2/2] arm64: dts: amlogic: t7: Fix missing required reset property
From: Ronald Claveau @ 2026-03-31 14:24 UTC (permalink / raw)
To: Philipp Zabel, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree,
Ronald Claveau
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-0-eb95b625234c@aliel.fr>
CHECK_DTBS shows missing reset required property in T7 DTBS.
A new CHECK_DTBS with this patch does not show this anymore.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
index 02a303d4ec39d..5069f29d2fbb7 100644
--- a/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
+++ b/arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi
@@ -582,6 +582,7 @@ sd_emmc_a: mmc@88000 {
<&clkc_periphs CLKID_SD_EMMC_A>,
<&scmi_clk CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
+ resets = <&reset RESET_SD_EMMC_A>;
assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_A_SEL>;
assigned-clock-parents = <&xtal>;
status = "disabled";
@@ -595,6 +596,7 @@ sd_emmc_b: mmc@8a000 {
<&clkc_periphs CLKID_SD_EMMC_B>,
<&scmi_clk CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
+ resets = <&reset RESET_SD_EMMC_B>;
assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_B_SEL>;
assigned-clock-parents = <&xtal>;
status = "disabled";
@@ -608,6 +610,7 @@ sd_emmc_c: mmc@8c000 {
<&clkc_periphs CLKID_SD_EMMC_C>,
<&scmi_clk CLKID_FCLK_DIV2>;
clock-names = "core", "clkin0", "clkin1";
+ resets = <&reset RESET_SD_EMMC_C>;
assigned-clocks = <&clkc_periphs CLKID_SD_EMMC_C_SEL>;
assigned-clock-parents = <&xtal>;
status = "disabled";
--
2.49.0
^ permalink raw reply related
* [PATCH 1/2] reset: amlogic: t7: Fix null reset ops
From: Ronald Claveau @ 2026-03-31 14:24 UTC (permalink / raw)
To: Philipp Zabel, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree,
Ronald Claveau
In-Reply-To: <20260331-fix-aml-t7-null-reset-v1-0-eb95b625234c@aliel.fr>
Fix missing reset ops causing kernel null pointer dereference.
This SOC's reset is currently not used yet.
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
drivers/reset/amlogic/reset-meson.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/reset/amlogic/reset-meson.c b/drivers/reset/amlogic/reset-meson.c
index 84610365a823c..c303e8590dd68 100644
--- a/drivers/reset/amlogic/reset-meson.c
+++ b/drivers/reset/amlogic/reset-meson.c
@@ -42,6 +42,7 @@ static const struct meson_reset_param meson_s4_param = {
};
static const struct meson_reset_param t7_param = {
+ .reset_ops = &meson_reset_ops,
.reset_num = 224,
.reset_offset = 0x0,
.level_offset = 0x40,
--
2.49.0
^ permalink raw reply related
* [PATCH 0/2] Fix Amlogic T7 null reset ops and DT required property
From: Ronald Claveau @ 2026-03-31 14:24 UTC (permalink / raw)
To: Philipp Zabel, Neil Armstrong, Kevin Hilman, Jerome Brunet,
Martin Blumenstingl, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-kernel, linux-amlogic, linux-kernel, devicetree,
Ronald Claveau
1. As reset is required for MMC DT, this patch series aims to add the currently missing required driver ops.
Whithout this patch the following kernel null error appears:
[ 0.459197] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 0.459978] Mem abort info:
[ 0.460324] ESR = 0x0000000096000004
[ 0.460791] EC = 0x25: DABT (current EL), IL = 32 bits
[ 0.461471] SET = 0, FnV = 0
[ 0.461830] EA = 0, S1PTW = 0
[ 0.462220] FSC = 0x04: level 0 translation fault
[ 0.462722] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 0.462826] Data abort info:
[ 0.462829] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 0.462842] Mem abort info:
[ 0.462849] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 0.462859] ESR = 0x0000000096000004
[ 0.462865] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 0.462874] EC = 0x25: DABT (current EL), IL = 32 bits
[ 0.462882] [0000000000000000] user address but active_mm is swapper
[ 0.462890] SET = 0, FnV = 0
[ 0.462901] Internal error: Oops: 0000000096000004 [#1] SMP
[ 0.462909] EA = 0, S1PTW = 0
[ 0.462917] Modules linked in:
[ 0.462925] FSC = 0x04: level 0 translation fault
[ 0.462932]
[ 0.462939] Data abort info:
[ 0.462951] CPU: 4 UID: 0 PID: 90 Comm: kworker/u34:3 Not tainted 7.0.0-rc4-next-20260319 #41 PREEMPT
[ 0.463920] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 0.463927] Hardware name: Khadas VIM4 (DT)
[ 0.463940] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 0.463951] Workqueue: async async_run_entry_fn
[ 0.464277] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 0.464286]
[ 0.464294] [0000000000000000] user address but active_mm is swapper
[ 0.464304] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.465935] pc : reset_control_reset+0x48/0x1d0
[ 0.466409] lr : reset_control_reset+0x38/0x1d0
[ 0.479907] sp : ffff800083943b60
[ 0.479911] x29: ffff800083943b60 x28: 0000000000000000 x27: 0000000000000000
[ 0.479926] x26: ffff80008310a9c0 x25: 0000000000000000 x24: ffff000100372005
[ 0.481212] x23: ffff0001003a4000 x22: ffff000100fee988 x21: 0000000000000000
[ 0.482976] x20: ffff00023f00a788 x19: ffff000100fee980 x18: 0000000000000006
[ 0.483865] x17: 64656c62616e655f x16: 7469647561206465 x15: ffff800083943530
[ 0.484753] x14: 0000000000000000 x13: 000000000000022d x12: 0000000000002000
[ 0.485642] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
[ 0.486530] x8 : ffff00023efd8a40 x7 : fffffffffffffe70 x6 : ffff00023efd89e0
[ 0.487418] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
[ 0.488307] x2 : ffff000102002488 x1 : ffff8000822248c0 x0 : 0000000000000000
[ 0.489196] Call trace:
[ 0.489500] reset_control_reset+0x48/0x1d0 (P)
[ 0.490062] __device_reset+0xc8/0xfc
[ 0.490517] meson_mmc_probe+0xe8/0x3d4
[ 0.490994] platform_probe+0x5c/0x98
[ 0.491448] really_probe+0xbc/0x298
[ 0.491892] __driver_probe_device+0x78/0x12c
[ 0.492434] driver_probe_device+0xd4/0x164
[ 0.492954] __device_attach_driver+0xb8/0x140
[ 0.493507] bus_for_each_drv+0x84/0xe0
[ 0.493983] __device_attach_async_helper+0xac/0xd0
[ 0.494590] async_run_entry_fn+0x34/0xe0
[ 0.495089] process_one_work+0x158/0x29c
[ 0.495587] worker_thread+0x18c/0x308
[ 0.496053] kthread+0x11c/0x128
[ 0.496453] ret_from_fork+0x10/0x20
[ 0.496904] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
[ 0.497661] ---[ end trace 0000000000000000 ]---
[ 0.498234] Internal error: Oops: 0000000096000004 [#2] SMP
[ 0.498935] Modules linked in:
[ 0.499319] CPU: 1 UID: 0 PID: 88 Comm: kworker/u34:1 Tainted: G D 7.0.0-rc4-next-20260319 #41 PREEMPT
[ 0.500669] Tainted: [D]=DIE
[ 0.501025] Hardware name: Khadas VIM4 (DT)
[ 0.501547] Workqueue: async async_run_entry_fn
[ 0.502109] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 0.502975] pc : reset_control_reset+0x48/0x1d0
[ 0.503538] lr : reset_control_reset+0x38/0x1d0
[ 0.504102] sp : ffff800083903b60
[ 0.504513] x29: ffff800083903b60 x28: 0000000000000000 x27: 0000000000000000
[ 0.505402] x26: ffff000100059028 x25: 0000000000000000 x24: ffff000100372005
[ 0.506290] x23: ffff000100ec9400 x22: ffff0001003f6e08 x21: 0000000000000000
[ 0.507178] x20: ffff00023f00b440 x19: ffff0001003f6e00 x18: 00000000ffffffff
[ 0.508067] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000839037e0
[ 0.508955] x14: 0000000000000000 x13: 0000000000000290 x12: 0000000000002000
[ 0.509843] x11: ffff00023efdc754 x10: ffff00023efdc740 x9 : 0000000000000000
[ 0.510732] x8 : ffff00023efd8bc0 x7 : fffffffffffffe70 x6 : ffff00023efd8b60
[ 0.511620] x5 : 0000000000000001 x4 : 0000000000000000 x3 : 0000000000000001
[ 0.512508] x2 : ffff000102002488 x1 : ffff800082224a40 x0 : 0000000000000000
[ 0.513397] Call trace:
[ 0.513700] reset_control_reset+0x48/0x1d0 (P)
[ 0.514263] __device_reset+0xc8/0xfc
[ 0.514718] meson_mmc_probe+0xe8/0x3d4
[ 0.515195] platform_probe+0x5c/0x98
[ 0.515650] really_probe+0xbc/0x298
[ 0.516094] __driver_probe_device+0x78/0x12c
[ 0.516636] driver_probe_device+0xd4/0x164
[ 0.517156] __device_attach_driver+0xb8/0x140
[ 0.517709] bus_for_each_drv+0x84/0xe0
[ 0.518185] __device_attach_async_helper+0xac/0xd0
[ 0.518792] async_run_entry_fn+0x34/0xe0
[ 0.519290] process_one_work+0x158/0x29c
[ 0.519788] worker_thread+0x18c/0x308
[ 0.520254] kthread+0x11c/0x128
[ 0.520655] ret_from_fork+0x10/0x20
[ 0.521103] Code: f9400262 2a0003f5 b4000902 f9400040 (f9400003)
[ 0.521860] ---[ end trace 0000000000000000 ]---
2. The following patch yet to merge reports a missing required property with CHECK_DTBS=y
https://lore.kernel.org/r/20260326-add-emmc-t7-vim4-v5-3-d3f182b48e9d@aliel.fr/
/home/rony/project/khadas/fenix/build/linux/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: mmc@88000 (amlogic,t7-mmc): 'resets' is a required property
from schema $id: http://devicetree.org/schemas/mmc/amlogic,meson-gx-mmc.yaml
/home/rony/project/khadas/fenix/build/linux/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: mmc@8a000 (amlogic,t7-mmc): 'resets' is a required property
from schema $id: http://devicetree.org/schemas/mmc/amlogic,meson-gx-mmc.yaml
/home/rony/project/khadas/fenix/build/linux/arch/arm64/boot/dts/amlogic/amlogic-t7-a311d2-khadas-vim4.dtb: mmc@8c000 (amlogic,t7-mmc): 'resets' is a required property
from schema $id: http://devicetree.org/schemas/mmc/amlogic,meson-gx-mmc.yaml
Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
---
Ronald Claveau (2):
reset: amlogic: t7: Fix null reset ops
arm64: dts: amlogic: t7: Fix missing required reset property
arch/arm64/boot/dts/amlogic/amlogic-t7.dtsi | 3 +++
drivers/reset/amlogic/reset-meson.c | 1 +
2 files changed, 4 insertions(+)
---
base-commit: f6eb9ae8b9fc13c3971e4a6d1e8442f253001f36
change-id: 20260331-fix-aml-t7-null-reset-2b608ebf9da4
prerequisite-change-id: 20260320-add-emmc-t7-vim4-6ad16e94614f:v5
prerequisite-patch-id: 5b5de77af11747ce964404fb827d2ee2bff47ea5
prerequisite-patch-id: 1e37fc75fed1e533adee0f3e7e6ead1f8ff3c55c
prerequisite-patch-id: 65a5d76ffdbc9b3aab3385bb65cb027004c30e7e
prerequisite-patch-id: 2daf583fb5e7449a02bd217d8aca330171b598aa
prerequisite-patch-id: 237269801826dd3ad7fb16eb4d7d6d4eab504278
prerequisite-patch-id: d1ddf9b7710e91f8062de83bd7ba55afb2c4c112
prerequisite-patch-id: 57e9b08a968aedf543d3d0d56cf1ca4db20b2a16
prerequisite-patch-id: cd98b74fa56af72af2553f391c400981d83cd4f4
prerequisite-patch-id: b730f5e42be1d89d193e63a0265495cdbf2c7d7b
Best regards,
--
Ronald Claveau <linux-kernel-dev@aliel.fr>
^ permalink raw reply
* Re: [PATCH ath-next v3 1/6] dt-bindings: net: wireless: add ath12k wifi device IPQ5424
From: Jeff Johnson @ 2026-03-31 14:23 UTC (permalink / raw)
To: Krzysztof Kozlowski, Raj Kumar Bhagat
Cc: Johannes Berg, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jeff Johnson, linux-wireless, devicetree, linux-kernel, ath12k
In-Reply-To: <20260331-fanatic-elegant-wallaby-913e35@quoll>
On 3/31/2026 12:24 AM, Krzysztof Kozlowski wrote:
> On Tue, Mar 31, 2026 at 02:09:06AM +0530, Raj Kumar Bhagat wrote:
>> $id: http://devicetree.org/schemas/net/wireless/qcom,ipq5332-wifi.yaml#
>> @@ -17,6 +17,7 @@ properties:
>> compatible:
>> enum:
>> - qcom,ipq5332-wifi
>> + - qcom,ipq5424-wifi
>
> No, use previous patch.
>
> I am annoyed that you keep making changes even for such trivialities and
> require re-review from the community. Previous patch was correct. This
> one doing whatever you want to do in copyrights is too much. You don't
> change copyrights just because you wrote one device model.
Krzysztof,
FYI here is the guidance I received from Qualcomm legal (links to internal
documentation, removed -- I've forwarded the entire e-mail to your Qualcomm
mailbox):
... Repos under copyleft license [...] QTI copyright must be added when we
make significant changes.
... Repos under friendly license (BSD, Apache, MIT, ...) [...] QTI copyright
must be added for any changes, not just significant ones.
... under the regular QUIC to QTI open-source copyright transitioning [...]
all QUIC Copyright instances should be replaced with year-less QTI OSS Copyright.
I'll follow up with them on this case where there is a dual-license file.
/jeff
^ permalink raw reply
* [PATCH 7/7] arm64: dts: fsl-lx2160a-tqmlx2160a: Remove deprecated properties
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: linux-arm-kernel, linux, devicetree, linux-kernel, Nora Schiffer
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
Setting #size-cells in MTD nodes itself is deprecated by mtd.yaml.
Remove the deprecated properties. Fixes the warning:
fsl-lx2160a-tqmlx2160a.dtsi:62.18-76.4: Warning
(avoid_unnecessary_addr_size): /soc/spi@20c0000/flash@0: unnecessary
#address-cells/#size-cells without "ranges", "dma-ranges" or child "reg"
or "ranges" property
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi | 2 --
1 file changed, 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
index 5ca950ff908e7..d64879ee5e54a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
@@ -62,8 +62,6 @@ &fspi {
flash0: flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
- #address-cells = <1>;
- #size-cells = <1>;
spi-max-frequency = <10000000>;
spi-rx-bus-width = <1>;
spi-tx-bus-width = <1>;
--
2.43.0
^ permalink raw reply related
* [PATCH 6/7] arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: specify Ethernet PHY reset GPIOs
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Correctly describe the PHY resets.
While the TI DP83867 requires only a 1us reset pulse in RGMII mode, 2.5ms
are needed for SGMII, where series capacitors would result in incorrect
sampling of strap pins if they don't have enough time to discharge.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 35 +++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
index 46a9fdc92bb56..687fd0d62235d 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
@@ -106,36 +106,59 @@ &dpmac18 {
phy-connection-type = "rgmii-id";
};
+/*
+ * Assert reset for 2.5ms on SGMII PHYs to let capacitors discharge before
+ * strap pin sampling
+ */
+
&emdio1 {
status = "okay";
dp83867_1_1: ethernet-phy@1 {
reg = <1>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 1 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_1_2: ethernet-phy@2 {
reg = <2>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 2 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_1_3: ethernet-phy@3 {
reg = <3>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 3 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_1_4: ethernet-phy@4 {
reg = <4>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 4 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_1_5: ethernet-phy@5 {
reg = <5>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 5 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_1_6: ethernet-phy@6 {
reg = <6>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 6 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
};
@@ -145,16 +168,25 @@ &emdio2 {
dp83867_2_1: ethernet-phy@1 {
reg = <1>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 7 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_2_2: ethernet-phy@2 {
reg = <2>;
+ reset-assert-us = <2500>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 8 GPIO_ACTIVE_LOW>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
};
dp83867_2_3: ethernet-phy@3 {
reg = <3>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 9 GPIO_ACTIVE_LOW>;
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
@@ -162,6 +194,9 @@ dp83867_2_3: ethernet-phy@3 {
dp83867_2_4: ethernet-phy@4 {
reg = <4>;
+ reset-assert-us = <1>;
+ reset-deassert-us = <200>;
+ reset-gpios = <&gpioex1 10 GPIO_ACTIVE_LOW>;
ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
ti,clk-output-sel = <DP83867_CLK_O_SEL_OFF>;
--
2.43.0
^ permalink raw reply related
* [PATCH 5/7] arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: enable pcs_mdio17 and pcs_mdio18 in appropriate overlays
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
The pcs_mdio* instances are only needed with phy-connection-type =
"sgmii" and managed = "in-band-status". Move setting status = "okay" for
pcs_mdio17 and pcs_mdio18 to the appropriate overlays, for consistency
with the other pcs_mdio* instances.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 8 --------
.../fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso | 8 ++++++++
.../freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso | 8 ++++++++
3 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
index 431e4ed2a8b86..46a9fdc92bb56 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
@@ -545,14 +545,6 @@ i2c@3 {
};
};
-&pcs_mdio17 {
- status = "okay";
-};
-
-&pcs_mdio18 {
- status = "okay";
-};
-
&uart0 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
index 0847c786dc1ca..497ea4ddef3e6 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
@@ -59,3 +59,11 @@ &pcs_mdio14 {
&pcs_mdio16 {
status = "okay";
};
+
+&pcs_mdio17 {
+ status = "okay";
+};
+
+&pcs_mdio18 {
+ status = "okay";
+};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
index 7520f105d5d8c..a51edef83317f 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
@@ -58,6 +58,14 @@ &pcs_mdio16 {
status = "okay";
};
+&pcs_mdio17 {
+ status = "okay";
+};
+
+&pcs_mdio18 {
+ status = "okay";
+};
+
&sfp_xfi1 {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* [PATCH 4/7] arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: add various GPIO hogs
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Add GPIO hogs for various signals:
- Reset signals not assiciated with a device described in the Device
Tree (SATA, PCIe, ...)
- Inputs that must never be driven to avoid hardware damage
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 259 ++++++++++++++++++
1 file changed, 259 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
index a79290401551e..431e4ed2a8b86 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
@@ -187,6 +187,118 @@ gpioex3: gpio@20 {
#gpio-cells = <2>;
gpio-controller;
vcc-supply = <®_vcc3v3>;
+
+ line0-hog {
+ gpio-hog;
+ gpios = <0 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "NOR_SWAP#";
+ };
+
+ line1-hog {
+ gpio-hog;
+ gpios = <1 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "BOOT_SRC2";
+ };
+
+ line2-hog {
+ gpio-hog;
+ gpios = <2 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "BOOT_SRC1";
+ };
+
+ line3-hog {
+ gpio-hog;
+ gpios = <3 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "BOOT_SRC0";
+ };
+
+ line4-hog {
+ gpio-hog;
+ gpios = <4 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "EMMC_SEL1";
+ };
+
+ line5-hog {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "EMMC_SEL0";
+ };
+
+ line6-hog {
+ gpio-hog;
+ gpios = <6 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD2_4_MUX_SEL";
+ };
+
+ line7-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD2_3_MUX_SEL";
+ };
+
+ line8-hog {
+ gpio-hog;
+ gpios = <8 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD2_2_MUX_SEL";
+ };
+
+ line9-hog {
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD1_MUX_SEL";
+ };
+
+ line10-hog {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "ENABLE_FAN";
+ };
+
+ line11-hog {
+ gpio-hog;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD3_MUX_SEL";
+ };
+
+ line12-hog {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD2_7_MUX_SEL";
+ };
+
+ line13-hog {
+ gpio-hog;
+ gpios = <13 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SD2_6_MUX_SEL";
+ };
+
+ line14-hog {
+ gpio-hog;
+ gpios = <14 GPIO_ACTIVE_HIGH>;
+ input;
+ /* Reserved */
+ };
+
+ line15-hog {
+ gpio-hog;
+ gpios = <15 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "EC2_SEL";
+ };
};
};
@@ -223,6 +335,83 @@ gpioex0: gpio@20 {
#gpio-cells = <2>;
gpio-controller;
vcc-supply = <®_vcc3v3>;
+
+ line2-hog {
+ gpio-hog;
+ gpios = <2 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "QSFP_MODPRS#";
+ };
+
+ line3-hog {
+ gpio-hog;
+ gpios = <3 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "QSFP_INT#";
+ };
+
+ line5-hog {
+ gpio-hog;
+ gpios = <5 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "IRQ_RETIMER_1#";
+ };
+
+ line6-hog {
+ gpio-hog;
+ gpios = <6 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "IRQ_RETIMER_2#";
+ };
+
+ line7-hog {
+ gpio-hog;
+ gpios = <7 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "MPCIE_1_WAKE#";
+ };
+
+ line8-hog {
+ gpio-hog;
+ gpios = <8 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MPCIE_1_DISABLE#";
+ };
+
+ line9-hog {
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MPCIE_1_RESET#";
+ };
+
+ line10-hog {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "MPCIE_2_WAKE#";
+ };
+
+ line11-hog {
+ gpio-hog;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MPCIE_2_DISABLE#";
+ };
+
+ line12-hog {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "MPCIE_2_RESET#";
+ };
+
+ line15-hog {
+ gpio-hog;
+ gpios = <15 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "SIM_CARD_DETECT";
+ };
};
gpioex1: gpio@21 {
@@ -231,6 +420,20 @@ gpioex1: gpio@21 {
#gpio-cells = <2>;
gpio-controller;
vcc-supply = <®_vcc3v3>;
+
+ line13-hog {
+ gpio-hog;
+ gpios = <13 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "RST_M2_SATA_1#";
+ };
+
+ line14-hog {
+ gpio-hog;
+ gpios = <14 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "RST_M2_SATA_2#";
+ };
};
gpioex2: gpio@22 {
@@ -239,6 +442,62 @@ gpioex2: gpio@22 {
#gpio-cells = <2>;
gpio-controller;
vcc-supply = <®_vcc3v3>;
+
+ line8-hog {
+ gpio-hog;
+ gpios = <8 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "XFI1_RET_LOSS";
+ };
+
+ line9-hog {
+ gpio-hog;
+ gpios = <9 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "XFI2_RET_LOSS";
+ };
+
+ line10-hog {
+ gpio-hog;
+ gpios = <10 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "PCIE_1_PERST#";
+ };
+
+ line11-hog {
+ gpio-hog;
+ gpios = <11 GPIO_ACTIVE_HIGH>;
+ output-high;
+ line-name = "PCIE_2_PERST#";
+ };
+
+ line12-hog {
+ gpio-hog;
+ gpios = <12 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "PCIE_WAKE#";
+ };
+
+ line13-hog {
+ gpio-hog;
+ gpios = <13 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "X8_PRSNT1#";
+ };
+
+ line14-hog {
+ gpio-hog;
+ gpios = <14 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "X4_1_PRSNT1#";
+ };
+
+ line15-hog {
+ gpio-hog;
+ gpios = <15 GPIO_ACTIVE_HIGH>;
+ input;
+ line-name = "X4_2_PRSNT1#";
+ };
};
};
--
2.43.0
^ permalink raw reply related
* [PATCH 3/7] arm64: dts: fsl-lx2160a-tqmlx2160a: add aliases for all 18 DPMAC instances
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Each TQMX2160A comes with a block of 18 MAC addresses. Define aliases
to allow firmware to statically assign these addresses to the Ethernet
interfaces.
In addition, udev can use these aliases for predicable interface names.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi | 21 +++++++++++++++++++
1 file changed, 21 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
index 89a4765737b4f..5ca950ff908e7 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi
@@ -8,6 +8,27 @@
#include "fsl-lx2160a.dtsi"
/ {
+ aliases {
+ ethernet0 = &dpmac1;
+ ethernet1 = &dpmac2;
+ ethernet2 = &dpmac3;
+ ethernet3 = &dpmac4;
+ ethernet4 = &dpmac5;
+ ethernet5 = &dpmac6;
+ ethernet6 = &dpmac7;
+ ethernet7 = &dpmac8;
+ ethernet8 = &dpmac9;
+ ethernet9 = &dpmac10;
+ ethernet10 = &dpmac11;
+ ethernet11 = &dpmac12;
+ ethernet12 = &dpmac13;
+ ethernet13 = &dpmac14;
+ ethernet14 = &dpmac15;
+ ethernet15 = &dpmac16;
+ ethernet16 = &dpmac17;
+ ethernet17 = &dpmac18;
+ };
+
reg_vcc3v3: regulator-vcc3v3 {
compatible = "regulator-fixed";
regulator-name = "VCC3V3";
--
2.43.0
^ permalink raw reply related
* [PATCH 1/7] arm64: dts: fsl-lx2160a-tqmlx2160a: fix LED polarity
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Both LEDs are active-high.
Fixes: 04b77e0124ef ("arm64: dts: freescale: add fsl-lx2160a-mblx2160a board")
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
index f6a4f8d543015..a79290401551e 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a.dts
@@ -51,7 +51,7 @@ leds {
compatible = "gpio-leds";
led-user1 {
- gpios = <&gpioex1 15 GPIO_ACTIVE_LOW>;
+ gpios = <&gpioex1 15 GPIO_ACTIVE_HIGH>;
color = <LED_COLOR_ID_BLUE>;
function = LED_FUNCTION_HEARTBEAT;
function-enumerator = <0>;
@@ -59,7 +59,7 @@ led-user1 {
};
led-user2 {
- gpios = <&gpio2 8 GPIO_ACTIVE_LOW>;
+ gpios = <&gpio2 8 GPIO_ACTIVE_HIGH>;
color = <LED_COLOR_ID_BLUE>;
function = LED_FUNCTION_HEARTBEAT;
function-enumerator = <1>;
--
2.43.0
^ permalink raw reply related
* [PATCH 2/7] arm64: dts: fsl-lx2160a-tqmlx2160a-mblx2160a: use DPMAC 17 and 18 for SGMII in SERDES2 configs 7 and 11
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: Nora Schiffer, linux-arm-kernel, linux, devicetree, linux-kernel
In-Reply-To: <20260331141915.2918927-1-alexander.stein@ew.tq-group.com>
From: Nora Schiffer <nora.schiffer@ew.tq-group.com>
We have been informed that using DPMAC 17 and 18 for RGMII when SERDES2
is configured to provide SGMII lanes for these MACs is unsupported and
will cause errors in certain DPAA2 configurations. Update these
configurations to use SGMII instead.
The total number of available Gbit Ethernet ports does not change, but
the PHYs and physical ports corresponding to DPMAC 17 and 18 do.
Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com>
---
.../fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso | 12 ++++++++++++
.../fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso | 12 ++++++++++++
2 files changed, 24 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
index 6d0c808cd840f..0847c786dc1ca 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso
@@ -32,6 +32,18 @@ &dpmac16 {
managed = "in-band-status";
};
+&dpmac17 {
+ phy-handle = <&dp83867_1_2>;
+ phy-connection-type = "sgmii";
+ managed = "in-band-status";
+};
+
+&dpmac18 {
+ phy-handle = <&dp83867_1_3>;
+ phy-connection-type = "sgmii";
+ managed = "in-band-status";
+};
+
&pcs_mdio12 {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
index db88a86ff69cd..7520f105d5d8c 100644
--- a/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
+++ b/arch/arm64/boot/dts/freescale/fsl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso
@@ -30,6 +30,18 @@ &dpmac16 {
managed = "in-band-status";
};
+&dpmac17 {
+ phy-handle = <&dp83867_1_2>;
+ phy-connection-type = "sgmii";
+ managed = "in-band-status";
+};
+
+&dpmac18 {
+ phy-handle = <&dp83867_1_3>;
+ phy-connection-type = "sgmii";
+ managed = "in-band-status";
+};
+
&pcs_mdio12 {
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* [PATCH 0/7] TQMLX2160A-MBLS2160A DT fixes/updates
From: Alexander Stein @ 2026-03-31 14:19 UTC (permalink / raw)
To: Frank Li, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Alexander Stein, Shawn Guo
Cc: linux-arm-kernel, linux, devicetree, linux-kernel, Nora Schiffer
Hi,
this series adds small fixes and improvements for TQMLX2160A DTs.
The DT overlays address specific hardware behaviour when serdes is configured
differently.
Best regards,
Alexander
Alexander Stein (1):
arm64: dts: fsl-lx2160a-tqmlx2160a: Remove deprecated properties
Nora Schiffer (6):
arm64: dts: fsl-lx2160a-tqmlx2160a: fix LED polarity
arm64: dts: fsl-lx2160a-tqmlx2160a-mblx2160a: use DPMAC 17 and 18 for
SGMII in SERDES2 configs 7 and 11
arm64: dts: fsl-lx2160a-tqmlx2160a: add aliases for all 18 DPMAC
instances
arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: add various GPIO hogs
arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: enable pcs_mdio17 and
pcs_mdio18 in appropriate overlays
arm64: dts: fsl-lx2160a-tqmlx2160a-mbls2160a: specify Ethernet PHY
reset GPIOs
.../fsl-lx2160a-tqmlx2160a-mblx2160a.dts | 306 +++++++++++++++++-
...l-lx2160a-tqmlx2160a-mblx2160a_x_11_x.dtso | 20 ++
...sl-lx2160a-tqmlx2160a-mblx2160a_x_7_x.dtso | 20 ++
.../dts/freescale/fsl-lx2160a-tqmlx2160a.dtsi | 23 +-
4 files changed, 357 insertions(+), 12 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH v2] ARM: dts: aspeed: Enable networking for Asus Kommando IPMI Card
From: Anirudh Srinivasan @ 2026-03-31 14:18 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Joel Stanley,
Andrew Jeffery
Cc: Andrew Lunn, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Anirudh Srinivasan
Adds the DT nodes needed for ethernet support for Asus Kommando, with
phy mode set to rgmii-id.
When this DT was originally added, the phy mode was set to rgmii (which
was incorrect). It was suggested to remove networking support from the
DT till the Aspeed networking driver was patched so that the correct phy
mode could be used.
The discussion in [1] mentions that u-boot was inserting clk delays that
weren't needed, which resulted in needing to set the phy mode in linux
to rgmii incorrectly. The solution suggested there was to patch u-boot to
no longer insert these clk delays and use rgmii-id as the phy mode for
any future DTs added to linux.
This DT was tested (on the OpenBMC u-boot fork [2]) with a u-boot DT
modified to insert clk delays of 0 (instead of patching u-boot itself).
[3] adds a u-boot DT for this device (without networking) and describes
how to patch it to add networking support. If this patched DT is used,
then networking works with rgmii-id phy mode in both u-boot and linux.
[1] https://lore.kernel.org/linux-aspeed/ef88bb50-9f2c-458d-a7e5-dc5ecb9c777a@lunn.ch/
[2] https://github.com/openbmc/u-boot/tree/v2019.04-aspeed-openbmc
[3] https://lore.kernel.org/openbmc/20260328-asus-kommando-v2-1-2a656f8cd314@gmail.com/
Signed-off-by: Anirudh Srinivasan <anirudhsriniv@gmail.com>
---
This patch is based off aspeed/arm/dt from bmc tree
---
Changes in v2:
- Commit message now mentions that the u-boot tested against is the
openbmc u-boot fork
- Link to v1: https://lore.kernel.org/r/20260328-asus-kommando-networking-v1-1-66d308b88536@gmail.com
---
.../dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
index ab7ad320067c1ddc0fea9ac386fd488c8ef28184..e0f7d92efa18ccbad2c336236c3b9d01b7de1bba 100644
--- a/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
+++ b/arch/arm/boot/dts/aspeed/aspeed-bmc-asus-kommando-ipmi-card.dts
@@ -107,6 +107,24 @@ &gpio1 {
/*18E0 32*/ "","","","","","","","";
};
+&mac2 {
+ status = "okay";
+
+ phy-mode = "rgmii-id";
+ phy-handle = <ðphy2>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_rgmii3_default>;
+};
+
+&mdio2 {
+ status = "okay";
+
+ ethphy2: ethernet-phy@0 {
+ compatible = "ethernet-phy-ieee802.3-c22";
+ reg = <0>;
+ };
+};
+
&vhub {
status = "okay";
};
---
base-commit: 76b4ec8efdc3887cdbf730da2e55881fc1a18770
change-id: 20260328-asus-kommando-networking-5c0612aa6b8c
Best regards,
--
Anirudh Srinivasan <anirudhsriniv@gmail.com>
^ permalink raw reply related
* Re: [PATCH v3 4/5] clk: spacemit: k3: mark top_dclk as CLK_IS_CRITICAL
From: Brian Masney @ 2026-03-31 14:16 UTC (permalink / raw)
To: Troy Mitchell
Cc: Vinod Koul, Frank Li, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Yixun Lan, Guodong Xu, Michael Turquette,
Stephen Boyd, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Alexandre Ghiti, dmaengine, devicetree, linux-riscv, spacemit,
linux-kernel, linux-clk
In-Reply-To: <20260331-k3-pdma-v3-4-a4e60dd8b4b3@linux.spacemit.com>
On Tue, Mar 31, 2026 at 04:27:07PM +0800, Troy Mitchell wrote:
> top_dclk is the DDR bus clock. If it is gated by clk_disable_unused,
> all memory-mapped bus transactions cease to function, causing DMA
> engines to hang and general system instability.
>
> Mark it CLK_IS_CRITICAL so the CCF never gates it during the
> unused clock sweep.
>
> Fixes: e371a77255b8 ("clk: spacemit: k3: add the clock tree")
> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ 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