[PATCH AUTOSEL 7.0-6.12] arm64: tegra: Fix snps,blen properties

[PATCH AUTOSEL 7.0-6.12] arm64: tegra: Fix snps,blen properties

[Sasha Levin]

From: Thierry Reding <treding@nvidia.com>

[ Upstream commit 51f10c527a63dc4a71bce4b40fc53eee78bbbd52 ]

The snps,blen property of stmmac-axi-config nodes needs to have 7
entries in total, with unsupported burst lengths listed as 0.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Now I have all the information needed for my analysis.

---

## PHASE 1: COMMIT MESSAGE FORENSICS

**Step 1.1: Subject Line**
- Subsystem: `arm64: tegra` (ARM64 device tree, Tegra SoC)
- Action verb: "Fix" — direct bug fix language
- Summary: Fix the `snps,blen` DT properties for MGBE Ethernet
  controllers
- Record: [arm64: tegra] [fix] [correcting snps,blen DT property to have
  required 7 entries]

**Step 1.2: Tags**
- `Signed-off-by: Thierry Reding <treding@nvidia.com>` — Author is the
  Tegra platform maintainer at NVIDIA.
- No Fixes: tag, no Cc: stable, no Reported-by (expected for auto-
  selection candidates).
- Record: No notable tags beyond authorship. Author is the subsystem
  maintainer.

**Step 1.3: Commit Body**
- States: "The snps,blen property of stmmac-axi-config nodes needs to
  have 7 entries in total, with unsupported burst lengths listed as 0."
- This describes a DT schema violation — the property had 4 entries but
  the driver requires 7.
- Record: Bug is a malformed DT property that doesn't match the driver's
  expectation.

**Step 1.4: Hidden Bug Fix Detection**
- This is NOT a hidden fix — it's explicitly labeled "Fix." The
  underlying bug is that `of_property_read_u32_array(np, "snps,blen",
  axi_blen, 7)` fails silently when the property only has 4 entries,
  leaving the stack buffer uninitialized.
- Record: Direct bug fix, not disguised.

## PHASE 2: DIFF ANALYSIS

**Step 2.1: Inventory**
- 1 file changed: `arch/arm64/boot/dts/nvidia/tegra234.dtsi`
- 3 lines changed (each identical):
  - `snps,blen = <256 128 64 32>;` → `snps,blen = <256 128 64 32 0 0
    0>;`
- Affects MGBE0, MGBE1, MGBE2 stmmac-axi-config nodes.
- Record: Single DT file, 3 identical one-line changes. Scope:
  minimal/surgical.

**Step 2.2: Code Flow**
- Before: DT property has 4 u32 entries.
- After: DT property has 7 u32 entries (3 trailing zeros for unsupported
  burst lengths).
- The stmmac driver calls `of_property_read_u32_array(np, "snps,blen",
  axi_blen, AXI_BLEN)` where `AXI_BLEN = 7`. With only 4 entries,
  `of_find_property_value_of_size()` checks `prop->length (16) < min
  (28)` and returns `-EOVERFLOW`. The stack array `axi_blen[7]` is never
  written. Then `stmmac_axi_blen_to_mask()` processes uninitialized
  stack data.

**Step 2.3: Bug Mechanism**
- Category: **Uninitialized data** / **incorrect DT specification**
- Mechanism: The DT property is too short, causing
  `of_property_read_u32_array()` to fail, leaving a stack buffer
  uninitialized. The uninitialized data is then used to configure the
  AXI DMA burst length register for network hardware.
- Record: Uninitialized stack data used for hardware DMA configuration.
  The fix ensures the property has the correct count.

**Step 2.4: Fix Quality**
- Obviously correct: all other DT files using `snps,blen` have exactly 7
  entries (verified by grep across all arm64 DT files).
- Minimal/surgical: 3 identical one-line changes.
- Zero regression risk: adding trailing zeros only enables the driver to
  read the property successfully, and zero entries are explicitly
  skipped by `stmmac_axi_blen_to_mask()`.
- Record: Fix is obviously correct, minimal, zero regression risk.

## PHASE 3: GIT HISTORY

**Step 3.1: Blame**
- The buggy `snps,blen = <256 128 64 32>` was introduced by commit
  `81695da63b977` ("arm64: tegra: Add AXI configuration for Tegra234
  MGBE") by Thierry Reding, dated 2024-02-21, merged in v6.9.
- Record: Bug introduced in v6.9 by the same author who is now fixing
  it.

**Step 3.2: Fixes tag**
- No Fixes: tag present. The implicit fix target is `81695da63b977`.

**Step 3.3: File History**
- Recent changes to `tegra234.dtsi` are mostly DT cleanup/additions. No
  related fixes.
- Record: Standalone fix, no prerequisites.

**Step 3.4: Author**
- Thierry Reding is the Tegra platform maintainer at NVIDIA. He wrote
  the original buggy commit and is now fixing it.
- Record: Subsystem maintainer self-fix.

**Step 3.5: Dependencies**
- None. The fix is a pure DT property value change that applies
  independently.
- Record: No dependencies, applies cleanly standalone.

## PHASE 4: MAILING LIST RESEARCH

**Step 4.1: Original Submission**
- Found via web search: patch is `[PATCH 09/10]` in a series "dt-
  bindings: Various cleanups for Tegra-related bindings" posted
  2026-02-23.
- Part of a v3 cleanup series. While most patches in the series are DT
  binding cleanups, this specific patch (09/10) is a genuine bug fix.
- Record: Part of a larger DT cleanup series, but this patch is an
  independent bug fix.

**Step 4.2: Reviewers**
- b4 dig found the original commit (81695da63b977) was reviewed and
  tested by Jon Hunter (NVIDIA Tegra co-maintainer). The fix itself is
  straightforward enough that formal review was likely implicit.
- Record: Original buggy code was reviewed by Jon Hunter.

**Step 4.3-4.5: Bug Reports / Stable History**
- No specific bug report found. Likely discovered by the author during
  code review / DT validation.
- No prior stable discussion found.

## PHASE 5: CODE SEMANTIC ANALYSIS

**Step 5.1-5.4: Key Functions**
- `stmmac_axi_setup()` in `stmmac_platform.c` parses the DT property.
- Called during stmmac platform driver probe for any device using
  `snps,axi-config` DT phandle.
- `stmmac_axi_blen_to_mask()` converts the burst length array to
  register value.
- The register value is written to hardware in `dwxgmac2_dma_init()` /
  `dwmac4_dma_init()` / `dwmac1000_dma_init()`.
- Impact: Affects AXI DMA configuration for MGBE Ethernet on Tegra234.

**Step 5.5: Similar Patterns**
- All other arm64 DT files consistently use 7 entries for `snps,blen`.
  Tegra234 was the ONLY outlier with 4 entries.

## PHASE 6: STABLE TREE ANALYSIS

**Step 6.1: Buggy Code in Stable**
- Commit `81695da63b977` was introduced in v6.9. It exists in stable
  trees v6.12.y and any newer LTS branches.
- It does NOT exist in v6.6.y (confirmed via `git merge-base --is-
  ancestor`).
- Record: Bug affects v6.9+ stable trees (v6.12.y at minimum).

**Step 6.2: Backport Complications**
- Pure DT change with no code dependencies. Should apply cleanly.
- Record: Clean apply expected.

**Step 6.3: Related Fixes**
- No prior fix for this issue found in any tree.

## PHASE 7: SUBSYSTEM CONTEXT

**Step 7.1: Subsystem**
- ARM64 Device Tree for Tegra234 MGBE (Multi-Gigabit Ethernet).
- Criticality: IMPORTANT — affects Tegra234 network hardware users
  (NVIDIA Jetson AGX Orin, etc.).
- Record: [arm64/tegra DT] [IMPORTANT — Jetson platform network
  hardware]

## PHASE 8: IMPACT AND RISK ASSESSMENT

**Step 8.1: Affected Users**
- Users of NVIDIA Tegra234 platforms (Jetson AGX Orin) using MGBE
  Ethernet controllers.
- Platform-specific but widely deployed in industrial/embedded
  applications.

**Step 8.2: Trigger Conditions**
- Triggered on every boot when the MGBE driver probes. No special
  configuration needed.
- The AXI burst length read fails silently, so uninitialized data
  configures DMA hardware.

**Step 8.3: Failure Mode**
- Uninitialized stack data used for DMA hardware configuration.
- Could result in suboptimal network performance, potential DMA errors,
  or undefined hardware behavior depending on what stack values happen
  to be.
- Severity: **HIGH** (hardware misconfiguration from uninitialized data,
  affecting network DMA)

**Step 8.4: Risk-Benefit**
- BENEFIT: High — fixes broken AXI DMA configuration for 3 MGBE Ethernet
  controllers on Tegra234.
- RISK: Very low — 3 identical one-line DT property changes, adding
  trailing zeros, no code change.
- Record: Very favorable risk-benefit ratio.

## PHASE 9: FINAL SYNTHESIS

**Step 9.1: Evidence Summary**

FOR backporting:
- Fixes real bug: `of_property_read_u32_array()` fails with only 4/7
  entries, leading to uninitialized stack data being used for hardware
  DMA configuration
- Minimal, surgical fix: 3 identical one-line DT changes
- Obviously correct: all other DT files use 7 entries
- Written by subsystem maintainer (Thierry Reding, NVIDIA Tegra
  maintainer)
- Zero regression risk: trailing zeros are explicitly handled ("Burst
  values of zero must be skipped")
- Applies to v6.12.y+ stable trees

AGAINST backporting:
- No explicit user report of symptoms (could mean it works by luck with
  stack data)
- Part of a larger series (but this patch is independent)

**Step 9.2: Stable Rules Checklist**
1. Obviously correct? **YES** — all other DT files have 7 entries
2. Fixes a real bug? **YES** — uninitialized data used for HW
   configuration
3. Important issue? **YES** — hardware DMA misconfiguration
4. Small and contained? **YES** — 3 one-line changes in 1 DT file
5. No new features? **YES** — pure DT fix
6. Can apply to stable? **YES** — clean DT-only change

**Step 9.3: Exception Category**
- DT update fixing existing hardware description — automatic YES
  category

## Verification

- [Phase 1] Parsed subject: "Fix" verb, arm64 tegra subsystem, snps,blen
  property
- [Phase 2] Diff: 3 lines changed in tegra234.dtsi, each adds `0 0 0` to
  snps,blen property
- [Phase 2] Verified AXI_BLEN=7 in `include/linux/stmmac.h` line 109
- [Phase 2] Verified `of_property_read_u32_array()` calls
  `of_find_property_value_of_size()` with min=28 bytes; property has 16
  bytes (4 entries), so it returns -EOVERFLOW
- [Phase 2] Verified `stmmac_axi_blen_to_mask()` skips zero entries
  ("Burst values of zero must be skipped")
- [Phase 3] git blame: buggy code from 81695da63b977 (v6.9), author:
  Thierry Reding
- [Phase 3] git merge-base: confirmed 81695da63b977 is in v6.12 but not
  v6.6
- [Phase 4] b4 dig: found original commit submission at lore (patch-id
  match)
- [Phase 4] Web search: fix is PATCH 09/10 of "dt-bindings: Various
  cleanups for Tegra-related bindings"
- [Phase 5] Verified all other arm64 DT snps,blen entries have exactly 7
  values (grep across arch/arm64/boot/dts)
- [Phase 5] Traced call chain: stmmac_axi_setup →
  of_property_read_u32_array → of_find_property_value_of_size
- [Phase 6] Bug exists in v6.9+ stable trees
- [Phase 8] Failure mode: uninitialized stack data used for AXI DMA
  register, severity HIGH

**YES**

 arch/arm64/boot/dts/nvidia/tegra234.dtsi | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/nvidia/tegra234.dtsi b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
index 850c473235e36..04a95b6658caa 100644
--- a/arch/arm64/boot/dts/nvidia/tegra234.dtsi
+++ b/arch/arm64/boot/dts/nvidia/tegra234.dtsi
@@ -3621,7 +3621,7 @@ ethernet@6800000 {
 			snps,axi-config = <&mgbe0_axi_setup>;
 
 			mgbe0_axi_setup: stmmac-axi-config {
-				snps,blen = <256 128 64 32>;
+				snps,blen = <256 128 64 32 0 0 0>;
 				snps,rd_osr_lmt = <63>;
 				snps,wr_osr_lmt = <63>;
 			};
@@ -3663,7 +3663,7 @@ ethernet@6900000 {
 			snps,axi-config = <&mgbe1_axi_setup>;
 
 			mgbe1_axi_setup: stmmac-axi-config {
-				snps,blen = <256 128 64 32>;
+				snps,blen = <256 128 64 32 0 0 0>;
 				snps,rd_osr_lmt = <63>;
 				snps,wr_osr_lmt = <63>;
 			};
@@ -3705,7 +3705,7 @@ ethernet@6a00000 {
 			snps,axi-config = <&mgbe2_axi_setup>;
 
 			mgbe2_axi_setup: stmmac-axi-config {
-				snps,blen = <256 128 64 32>;
+				snps,blen = <256 128 64 32 0 0 0>;
 				snps,rd_osr_lmt = <63>;
 				snps,wr_osr_lmt = <63>;
 			};
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: qcom: monaco: Reserve full Gunyah metadata region

[Sasha Levin]

From: Loic Poulain <loic.poulain@oss.qualcomm.com>

[ Upstream commit 85d98669fa7f1d3041d962515e45ee6e392db6f8 ]

We observe spurious "Synchronous External Abort" exceptions
(ESR=0x96000010) and kernel crashes on Monaco-based platforms.
These faults are caused by the kernel inadvertently accessing
hypervisor-owned memory that is not properly marked as reserved.

>From boot log, The Qualcomm hypervisor reports the memory range
at 0x91a80000 of size 0x80000 (512 KiB) as hypervisor-owned:
qhee_hyp_assign_remove_memory: 0x91a80000/0x80000 -> ret 0

However, the EFI memory map provided by firmware only reserves the
subrange 0x91a40000–0x91a87fff (288 KiB). The remaining portion
(0x91a88000–0x91afffff) is incorrectly reported as conventional
memory (from efi debug):
efi:   0x000091a40000-0x000091a87fff [Reserved...]
efi:   0x000091a88000-0x0000938fffff [Conventional...]

As a result, the allocator may hand out PFNs inside the hypervisor
owned region, causing fatal aborts when the kernel accesses those
addresses.

Add a reserved-memory carveout for the Gunyah hypervisor metadata
at 0x91a80000 (512 KiB) and mark it as no-map so Linux does not
map or allocate from this area.

For the record:
Hyp version: gunyah-e78adb36e debug (2025-11-17 05:38:05 UTC)
UEFI Ver: 6.0.260122.BOOT.MXF.1.0.c1-00449-KODIAKLA-1

Fixes: 7be190e4bdd2 ("arm64: dts: qcom: add QCS8300 platform")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260302142603.1113355-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 arch/arm64/boot/dts/qcom/qcs8300.dtsi | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/qcs8300.dtsi b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
index b8d4a75baee22..7a4c3e872d8ee 100644
--- a/arch/arm64/boot/dts/qcom/qcs8300.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
@@ -756,6 +756,11 @@ smem_mem: smem@90900000 {
 			hwlocks = <&tcsr_mutex 3>;
 		};
 
+		gunyah_md_mem: gunyah-md-region@91a80000 {
+			reg = <0x0 0x91a80000 0x0 0x80000>;
+			no-map;
+		};
+
 		lpass_machine_learning_mem: lpass-machine-learning-region@93b00000 {
 			reg = <0x0 0x93b00000 0x0 0xf00000>;
 			no-map;
-- 
2.53.0

[PATCH AUTOSEL 6.18] ARM: dts: microchip: sam9x7: fix gpio-lines count for pioB

[Sasha Levin]

From: Mihai Sain <mihai.sain@microchip.com>

[ Upstream commit 907150bbe566e23714a25d7bcb910f236c3c44c0 ]

The pioB controller on the SAM9X7 SoC actually supports 27 GPIO lines.
The previous value of 26 was incorrect, leading to the last pin being
unavailable for use by the GPIO subsystem.
Update the #gpio-lines property to reflect
the correct hardware specification.

Fixes: 41af45af8bc3 ("ARM: dts: at91: sam9x7: add device tree for SoC")
Signed-off-by: Mihai Sain <mihai.sain@microchip.com>
Link: https://lore.kernel.org/r/20260209090735.2016-1-mihai.sain@microchip.com
Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 arch/arm/boot/dts/microchip/sam9x7.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/microchip/sam9x7.dtsi b/arch/arm/boot/dts/microchip/sam9x7.dtsi
index 46dacbbd201dd..d242d7a934d0f 100644
--- a/arch/arm/boot/dts/microchip/sam9x7.dtsi
+++ b/arch/arm/boot/dts/microchip/sam9x7.dtsi
@@ -1226,7 +1226,7 @@ pioB: gpio@fffff600 {
 				interrupt-controller;
 				#gpio-cells = <2>;
 				gpio-controller;
-				#gpio-lines = <26>;
+				#gpio-lines = <27>;
 				clocks = <&pmc PMC_TYPE_PERIPHERAL 3>;
 			};
 
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: qcom: hamoa/x1: fix idle exit latency

[Sasha Levin]

From: Daniel J Blueman <daniel@quora.org>

[ Upstream commit 3ecea84d2b90bbf934d5ca75514fa902fd71e03f ]

Designs based on the Qualcomm X1 Hamoa reference platform report:
driver: Idle state 1 target residency too low

This is because the declared X1 idle entry plus exit latency of 680us
exceeds the declared minimum 600us residency time:
  entry-latency-us = <180>;
  exit-latency-us = <500>;
  min-residency-us = <600>;

Fix this to be 320us so the sum of the entry and exit latencies matches
the downstream 500us exit latency, as directed by Maulik.

Tested on a Lenovo Yoga Slim 7x with Qualcomm X1E-80-100.

Fixes: 2e65616ef07f ("arm64: dts: qcom: x1e80100: Update C4/C5 residency/exit numbers")
Signed-off-by: Daniel J Blueman <daniel@quora.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260220124626.8611-1-daniel@quora.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 arch/arm64/boot/dts/qcom/x1e80100.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
index 6d97329995fe7..efe8d5e7079fe 100644
--- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
+++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
@@ -281,7 +281,7 @@ cluster_c4: cpu-sleep-0 {
 				idle-state-name = "ret";
 				arm,psci-suspend-param = <0x00000004>;
 				entry-latency-us = <180>;
-				exit-latency-us = <500>;
+				exit-latency-us = <320>;
 				min-residency-us = <600>;
 			};
 		};
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: imx93-9x9-qsb: change usdhc tuning step for eMMC and SD

[Sasha Levin]

From: Luke Wang <ziniu.wang_1@nxp.com>

[ Upstream commit 08903184553def7ba1ad6ba4fa8afe1ba2ee0a21 ]

During system resume, the following errors occurred:

  [  430.638625] mmc1: error -84 writing Cache Enable bit
  [  430.643618] mmc1: error -84 doing runtime resume

For eMMC and SD, there are two tuning pass windows and the gap between
those two windows may only have one cell. If tuning step > 1, the gap may
just be skipped and host assumes those two windows as a continuous
windows. This will cause a wrong delay cell near the gap to be selected.

Set the tuning step to 1 to avoid selecting the wrong delay cell.

For SDIO, the gap is sufficiently large, so the default tuning step does
not cause this issue.

Fixes: 0565d20cd8c2 ("arm64: dts: freescale: Support i.MX93 9x9 Quick Start Board")
Signed-off-by: Luke Wang <ziniu.wang_1@nxp.com>
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts
index 0852067eab2cb..197c8f8b7f669 100644
--- a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts
+++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts
@@ -507,6 +507,7 @@ &usdhc1 {
 	pinctrl-2 = <&pinctrl_usdhc1_200mhz>;
 	bus-width = <8>;
 	non-removable;
+	fsl,tuning-step = <1>;
 	status = "okay";
 };
 
@@ -519,6 +520,7 @@ &usdhc2 {
 	vmmc-supply = <&reg_usdhc2_vmmc>;
 	bus-width = <4>;
 	no-mmc;
+	fsl,tuning-step = <1>;
 	status = "okay";
 };
 
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: qcom: qcm6490-idp: Fix WCD9370 reset GPIO polarity

[Sasha Levin]

From: Ravi Hothi <ravi.hothi@oss.qualcomm.com>

[ Upstream commit b7df21c59739cceb7b866c6c5e8a6ba03875ab71 ]

The WCD9370 audio codec reset line on QCM6490 IDP should be active-low, but
the device tree described it as active-high. As a result, the codec is
kept in reset and fails to reset the SoundWire, leading to timeouts
and ASoC card probe failure (-ETIMEDOUT).

Fix the reset GPIO polarity to GPIO_ACTIVE_LOW so the codec can properly
initialize.

Fixes: aa04c298619f ("arm64: dts: qcom: qcm6490-idp: Add WSA8830 speakers and WCD9370 headset codec")
Signed-off-by: Ravi Hothi <ravi.hothi@oss.qualcomm.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260220090220.2992193-1-ravi.hothi@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 arch/arm64/boot/dts/qcom/qcm6490-idp.dts | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
index 73fce639370cd..214671b462770 100644
--- a/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
+++ b/arch/arm64/boot/dts/qcom/qcm6490-idp.dts
@@ -177,7 +177,7 @@ wcd9370: audio-codec-0 {
 		pinctrl-0 = <&wcd_default>;
 		pinctrl-names = "default";
 
-		reset-gpios = <&tlmm 83 GPIO_ACTIVE_HIGH>;
+		reset-gpios = <&tlmm 83 GPIO_ACTIVE_LOW>;
 
 		vdd-buck-supply = <&vreg_l17b_1p7>;
 		vdd-rxtx-supply = <&vreg_l18b_1p8>;
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: qcom: monaco: Fix UART10 pinconf

[Sasha Levin]

From: Loic Poulain <loic.poulain@oss.qualcomm.com>

[ Upstream commit 5b2a16ab0dbd090dc545c05ee79a077cc7a9c1e0 ]

UART10 RTS and TX pins were incorrectly mapped to gpio84 and gpio85.
Correct them to gpio85 (RTS) and gpio86 (TX) to match the hardware
I/O mapping.

Fixes: 467284a3097f ("arm64: dts: qcom: qcs8300: Add QUPv3 configuration")
Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20260202155611.1568-1-loic.poulain@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 arch/arm64/boot/dts/qcom/qcs8300.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/qcs8300.dtsi b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
index 8d78ccac411e4..b8d4a75baee22 100644
--- a/arch/arm64/boot/dts/qcom/qcs8300.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs8300.dtsi
@@ -5430,12 +5430,12 @@ qup_uart10_cts: qup-uart10-cts-state {
 			};
 
 			qup_uart10_rts: qup-uart10-rts-state {
-				pins = "gpio84";
+				pins = "gpio85";
 				function = "qup1_se2";
 			};
 
 			qup_uart10_tx: qup-uart10-tx-state {
-				pins = "gpio85";
+				pins = "gpio86";
 				function = "qup1_se2";
 			};
 
-- 
2.53.0

[PATCH AUTOSEL 6.18] dt-bindings: net: Fix Tegra234 MGBE PTP clock

[Sasha Levin]

From: Jon Hunter <jonathanh@nvidia.com>

[ Upstream commit fb22b1fc5bca3c0aad95388933497ceb30f1fb26 ]

The PTP clock for the Tegra234 MGBE device is incorrectly named
'ptp-ref' and should be 'ptp_ref'. This is causing the following
warning to be observed on Tegra234 platforms that use this device:

 ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate
 WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed

Although this constitutes an ABI breakage in the binding for this
device, PTP support has clearly never worked and so fix this now
so we can correct the device-tree for this device. Note that the
MGBE driver still supports the legacy 'ptp-ref' clock name and so
older/existing device-trees will still work, but given that this
is not the correct name, there is no point to advertise this in the
binding.

Fixes: 189c2e5c7669 ("dt-bindings: net: Add Tegra234 MGBE")
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Link: https://patch.msgid.link/20260401102941.17466-3-jonathanh@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 .../devicetree/bindings/net/nvidia,tegra234-mgbe.yaml         | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml b/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
index 2bd3efff2485e..215f14d1897d2 100644
--- a/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
+++ b/Documentation/devicetree/bindings/net/nvidia,tegra234-mgbe.yaml
@@ -42,7 +42,7 @@ properties:
       - const: mgbe
       - const: mac
       - const: mac-divider
-      - const: ptp-ref
+      - const: ptp_ref
       - const: rx-input-m
       - const: rx-input
       - const: tx
@@ -133,7 +133,7 @@ examples:
                  <&bpmp TEGRA234_CLK_MGBE0_RX_PCS_M>,
                  <&bpmp TEGRA234_CLK_MGBE0_RX_PCS>,
                  <&bpmp TEGRA234_CLK_MGBE0_TX_PCS>;
-        clock-names = "mgbe", "mac", "mac-divider", "ptp-ref", "rx-input-m",
+        clock-names = "mgbe", "mac", "mac-divider", "ptp_ref", "rx-input-m",
                       "rx-input", "tx", "eee-pcs", "rx-pcs-input", "rx-pcs-m",
                       "rx-pcs", "tx-pcs";
         resets = <&bpmp TEGRA234_RESET_MGBE0_MAC>,
-- 
2.53.0

[PATCH AUTOSEL 6.18] arm64: dts: imx8mq: Set the correct gpu_ahb clock frequency

[Sasha Levin]

From: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>

[ Upstream commit 1f99b5d93d99ca17d50b386a674d0ce1f20932d8 ]

According to i.MX 8M Quad Reference Manual, GPU_AHB_CLK_ROOT's maximum
frequency is 400MHz.

Fixes: 45d2c84eb3a2 ("arm64: dts: imx8mq: add GPU node")
Reviewed-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sebastian Krzyszkowiak <sebastian.krzyszkowiak@puri.sm>
Reviewed-by: Peng Fan <peng.fan@nxp.com>
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Signed-off-by: Frank Li <Frank.Li@nxp.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

Error: Failed to generate final synthesis

 arch/arm64/boot/dts/freescale/imx8mq.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/freescale/imx8mq.dtsi b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
index 607962f807beb..6a25e219832ce 100644
--- a/arch/arm64/boot/dts/freescale/imx8mq.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx8mq.dtsi
@@ -1632,7 +1632,7 @@ gpu: gpu@38000000 {
 			                         <&clk IMX8MQ_GPU_PLL_OUT>,
 			                         <&clk IMX8MQ_GPU_PLL>;
 			assigned-clock-rates = <800000000>, <800000000>,
-			                       <800000000>, <800000000>, <0>;
+			                       <800000000>, <400000000>, <0>;
 			power-domains = <&pgc_gpu>;
 		};
 
-- 
2.53.0