[akakum-qualcomm]

The USB memory peak vote of 5500 MB/s, together with the Apps USB bandwidth votes, can raise the interconnect request into the turbo range during USB activity. This causes DDR to operate beyond the nominal range and can result in unnecessary frequency changes and power consumption.

Reduce the USB memory peak vote to 4500 MB/s, clear the Apps USB average vote, and reduce the Apps USB peak vote from 80 MB/s to 40 MB/s. These changes prevent the Apps USB vote from unnecessarily triggering turbo levels and keep the interconnect bandwidth within the nominal range.

Maintaining the bandwidth votes within the nominal range avoids DDR undervolting and improves stability during simultaneous USB audio and high-throughput data transfers.

Link: https://lore.kernel.org/all/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com/

Crs-Fixed: 4700998

[qswat-orbit-external]

Merge Check Failed: No Change Task Found

No associated change tasks found for CR 4700998 on any of the following entities:

Entities:

• kernel.qli.2.0

CR: 4700998

Please ensure the CR has a change task associated with at least one of the entities for this branch.

[qswat-orbit-external]

Merge Check Failed: No Change Task Found

No associated change tasks found for CR 4700998 on any of the following entities:

Entities:

• kernel.qli.2.0

CR: 4700998

Please ensure the CR has a change task associated with at least one of the entities for this branch.

[qlijarvis]

PR #1365 — validate-patch

PR: #1365

Verdict	Issues	Detailed Report
❌	0	Full report

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com/

2. Lore link matches PR commits: ❌ No — The PR implements the exact opposite change: lore increases bandwidth (2500→5500, 0→40, 40→80), PR decreases bandwidth (5500→4500, 40→0, 80→40). All three macro changes are semantically inverted.

3. Upstream patch status: ⏳ Decision Pending — Posted June 11, 2026; received review feedback from Dmitry Baryshkov on June 12, 2026 with unresolved concerns (missing macro, unclear target scope, insufficient justification); no acceptance signals; thread stalled with no author follow-up; contains identified bugs.

4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

Verdict: ❌ — click to expand

🔍 Patch Validation Report

PR: #1365 - usb: dwc3: qcom: Keep USB bandwidth votes in nominal range
Upstream: https://lore.kernel.org/all/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com/
Verdict: ❌ FAIL

---

Critical Issue: PR Implements the OPPOSITE Change

The PR patch and the linked lore patch make completely opposite changes to the same code:

Macro	Lore (upstream)	PR	Direction
USB_MEMORY_PEAK_SS_BW	2500 → 5500	5500 → 4500	⬆️ INCREASE vs ⬇️ DECREASE
APPS_USB_AVG_BW	0 → 40	40 → 0	⬆️ INCREASE vs ⬇️ DECREASE
APPS_USB_PEAK_BW	40 → 80	80 → 40	⬆️ INCREASE vs ⬇️ DECREASE

Lore patch rationale: "Increase nominal max votes to improve DDR performance and USB audio use case handling" — increases bandwidth to fix audio glitches.

PR patch rationale: "Keep USB bandwidth votes in nominal range" — decreases bandwidth to avoid turbo mode and reduce power consumption.

These are contradictory goals with opposite implementations.

---

Commit Message

Check	Status	Note
Subject matches upstream	❌	Lore: "Update nominal max votes for qcom usb" vs PR: "Keep USB bandwidth votes in nominal range" — completely different intent
Body preserves rationale	❌	PR describes reducing bandwidth to avoid turbo; lore describes increasing bandwidth to fix glitches — opposite rationales
Fixes tag present/correct	N/A	Neither patch has a Fixes tag
Authorship preserved	⚠️	Same author (Akash Kumar) but different email addresses: lore uses akash.kumar@oss.qualcomm.com, PR uses akakum@qti.qualcomm.com
Backport note (if applicable)	N/A	Not a backport
Link tag	✅	PR correctly links to the lore thread

---

Diff Comparison

File	Status	Notes
drivers/usb/dwc3/dwc3-qcom.c	❌	All three hunks are inverted — PR decreases values that lore increases, and vice versa

Detailed hunk analysis:

1. USB_MEMORY_PEAK_SS_BW:

   • Lore: MBps_to_icc(2500) → MBps_to_icc(5500) (+3000 MB/s)
   • PR: MBps_to_icc(5500) → MBps_to_icc(4500) (-1000 MB/s)
   • Verdict: Complete semantic reversal

2. APPS_USB_AVG_BW:

   • Lore: 0 → 40 (enables average bandwidth vote)
   • PR: 40 → 0 (disables average bandwidth vote)
   • Verdict: Complete semantic reversal
   • Additional issue: Lore patch is missing MBps_to_icc() macro (bug caught by Dmitry Baryshkov in review)

3. APPS_USB_PEAK_BW:

   • Lore: MBps_to_icc(40) → MBps_to_icc(80) (+40 MB/s)
   • PR: MBps_to_icc(80) → MBps_to_icc(40) (-40 MB/s)
   • Verdict: Complete semantic reversal

---

Upstream Patch Status

Community verdict: ⏳ Decision Pending — under review with unresolved concerns

Evidence:

• Posted: June 11, 2026
• Last activity: June 12, 2026 (Dmitry Baryshkov review)
• No acceptance signals (applied, queued, Reviewed-by, Acked-by) found
• No explicit NAK, but Dmitry raised multiple concerns:
  • Questioned the math behind DDR frequency claims
  • Asked which targets are affected (Agatti? SDX55? IPQ8064?)
  • Identified missing MBps_to_icc() macro on APPS_USB_AVG_BW line
  • Requested explanation for why APPS_USB_*_BW changes are needed
• Thread appears stalled with no follow-up from author addressing concerns
• Sashiko AI bot flagged the missing MBps_to_icc() macro as a High severity issue

Status: The lore patch has not been accepted upstream and has unresolved review feedback.

---

Integration Presence (qcom-next/topics)

Per integration_presence_report.md:

Commit	qcom-next	topics	Final
1/1	partial	missing	partial

Interpretation: Some related change may exist in qcom-next (possibly the lore version or an earlier iteration), but the exact PR change (the reversal) is not present in either qcom-next or kernel-topics.

Status: ⚠️ Partial presence — 0/1 commits fully present, 1/1 commits have partial evidence

---

Issues Found

1. ❌ CRITICAL: Semantic inversion — The PR implements the exact opposite of the linked lore patch. All three macro changes are reversed in direction.

2. ❌ CRITICAL: Contradictory rationale — The PR commit message describes a completely different goal (reduce bandwidth to avoid turbo) than the lore patch (increase bandwidth to fix audio glitches).

3. ❌ Subject line mismatch — PR subject "Keep USB bandwidth votes in nominal range" does not match lore subject "Update nominal max votes for qcom usb" and describes opposite intent.

4. ❌ Upstream patch not accepted — The lore patch has unresolved review concerns and has not been merged into any maintainer tree or mainline.

5. ⚠️ Authorship inconsistency — Email addresses differ between lore (akash.kumar@oss.qualcomm.com) and PR (akakum@qti.qualcomm.com), though both are Akash Kumar.

6. ⚠️ Upstream patch has bugs — Dmitry Baryshkov identified that the lore patch is missing MBps_to_icc() on the APPS_USB_AVG_BW line, which would cause incorrect bandwidth voting.

---

Recommendation

❌ DO NOT MERGE — This PR must be rejected for the following reasons:

1. The PR does not match the linked lore patch — it implements the opposite change. The Link tag is misleading.

2. The upstream patch is not accepted — it has unresolved review concerns and contains bugs identified by maintainers.

3. Unclear intent — It's unclear whether:

   • The PR author intended to revert the lore patch (in which case the commit message should say "Revert" and explain why)
   • The PR author made an error and applied the wrong diff
   • The PR represents a different solution to a different problem (in which case it should not link to the lore patch)

Required actions before this can be reconsidered:

1. Clarify intent: Is this a revert, a mistake, or a different patch?
2. Remove or correct the Link tag: The current lore link is incorrect for this change.
3. If this is a revert: Use proper revert commit format and explain why the original change is being reverted.
4. If this is a new patch: Post to lore.kernel.org for upstream review first, address maintainer feedback, and only then submit to the vendor tree with the correct lore link.
5. Address the base state confusion: The PR assumes a starting state (5500/40/80) that matches the lore patch's end state, suggesting the lore patch may have already been applied somewhere. Clarify the tree state.

---

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com/

2. Lore link matches PR commits: ❌ No — The PR implements the exact opposite change: lore increases bandwidth (2500→5500, 0→40, 40→80), PR decreases bandwidth (5500→4500, 40→0, 80→40). All three macro changes are semantically inverted.

3. Upstream patch status: ⏳ Decision Pending — Posted June 11, 2026; received review feedback from Dmitry Baryshkov on June 12, 2026 with unresolved concerns (missing macro, unclear target scope, insufficient justification); no acceptance signals; thread stalled with no author follow-up; contains identified bugs.

4. PR present in qcom-next/topics: ⚠️ Partial — 0/1 commits fully present; 1/1 commits have partial evidence (possibly the lore version or related change exists, but not this exact reversal).

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: c7896917e523946138ce654d4b6c1e33d5a8f4e5
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit	Subject	qcom-next	topics	Final
1/1	[PATCH] usb: dwc3: qcom: Keep USB bandwidth votes in nominal range	partial - subject or partial tree evidence found, but full change was not verified	missing - no subject, patch-id, or full tree-content match found	partial

Final Status

overall_status: PARTIAL
present_commits: 0/1
partial_commits: 1/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

[qlijarvis]

PR #1365 — checker-log-analyzer

PR: #1365
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/40895328880

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	No binding changes
dtb-check	⏭️	No DTS changes
sparse-check	✅	No new warnings
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	❌	Missing subject prefix
tag-check	❌	Missing subject prefix (mandatory for qcom-6.18.y)

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1365 - usb: dwc3: qcom: Keep USB bandwidth votes in nominal range
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/40895328880
Target branch: qcom-6.18.y

Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	No binding changes
dtb-check	⏭️	No DTS changes
sparse-check	✅	No new warnings
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	❌	Missing subject prefix
tag-check	❌	Missing subject prefix (mandatory for qcom-6.18.y)

---

❌ check-patch-compliance

Root cause: Commit subject does not start with a required prefix tag.

Failure details:

Checking commit: usb: dwc3: qcom: Keep USB bandwidth votes in nominal range
Commit summary does not start with a required prefix

The commit has a Link: tag pointing to lore.kernel.org, indicating this patch was posted upstream, but the subject line is missing the required FROMLIST: prefix.

Fix:

Since the patch has a lore link (https://lore.kernel.org/all/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com/), it should use the FROMLIST: prefix:

git rebase -i bf8dffb05bda45b8490ab4ee04998dfa9b8be292
# mark commit 727cd6d8857b as 'edit'
git commit --amend -m "FROMLIST: usb: dwc3: qcom: Keep USB bandwidth votes in nominal range

The USB memory peak vote of 5500 MB/s, together with the Apps USB
bandwidth votes, can raise the interconnect request into the turbo
range during USB activity. This causes DDR to operate beyond the
nominal range and can result in unnecessary frequency changes and power
consumption.

Reduce the USB memory peak vote to 4500 MB/s, clear the Apps USB average
vote, and reduce the Apps USB peak vote from 80 MB/s to 40 MB/s. These
changes prevent the Apps USB vote from unnecessarily triggering turbo
levels and keep the interconnect bandwidth within the nominal range.

Maintaining the bandwidth votes within the nominal range avoids DDR
undervolting and improves stability during simultaneous USB audio and
high-throughput data transfers.

Link: https://lore.kernel.org/all/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com/

Signed-off-by: Akash Kumar <akakum@qti.qualcomm.com>"
git rebase --continue

Reproduce locally:

cd /path/to/kernel
./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git bf8dffb05bda..727cd6d8857b
# or use the check-patch-compliance.sh script:
bash kernel-checkers/check-patch-compliance.sh --kernel-src . \
  --base bf8dffb05bda45b8490ab4ee04998dfa9b8be292 \
  --head 727cd6d8857b57a05ab37154963154091c31761b

---

❌ tag-check

Root cause: Target branch qcom-6.18.y requires all commits to have a subject prefix tag.

Failure details:

The PR targets qcom-6.18.y, which is not qcom-next or qcom-next-staging. All commits merged into branches other than those two must start with one of the required prefix tags:

• FROMLIST: — Posted to mailing list (lore.kernel.org)
• FROMGIT: — Taken from a maintainer git tree
• UPSTREAM: — Merged into Linus's mainline tree
• BACKPORT: — Upstream patch backported with modifications
• QCLINUX: — Vendor-only change with no upstream equivalent
• PENDING: — Work-in-progress, not yet posted upstream
• WORKAROUND: — Temporary fix not suitable for upstream

Commit 727cd6d8857b ("usb: dwc3: qcom: Keep USB bandwidth votes in nominal range") is missing this prefix.

Fix:

Same as the check-patch-compliance fix above — add FROMLIST: prefix to the subject line since the patch has been posted to lore.kernel.org.

---

Verdict

1 blocker must be fixed before merge:

The commit subject must be amended to include the FROMLIST: prefix. This is required by both check-patch-compliance and the tag-check policy for the qcom-6.18.y branch.

All other checkers passed cleanly:

• ✅ No checkpatch style issues
• ✅ No sparse warnings introduced
• ✅ No UAPI changes
• ⏭️ No DT binding or DTS changes (skipped)

Once the subject prefix is added, the PR will be ready to merge.

[qswat-orbit-external]

Merge Check Failed: CR Not Eligible for Merge

CR 4700998 is not eligible for merge.

The parent software image for kernel.qli.2.0 is not development complete.

Entity: kernel.qli.2.0
CR: 4700998
Reason: CR_CANNOT_MERGE

Please ensure the CR passes both CCT (ComponentChangeTasks) and ICT (Integration Change Tasks) validations.

[qlijarvis]

PR #1365 — validate-patch

PR: #1365

Verdict	Issues	Detailed Report
❌	0	Full report

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com/
2. Lore link matches PR commits: ❌ No — PR implements the inverse of the lore patch (decreases bandwidth where lore increases it, and vice versa)
3. Upstream patch status: ⏳ Decision Pending — under review with critical bug and unanswered maintainer questions; not accepted
4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

Verdict: ❌ — click to expand

🔍 Patch Validation Report

PR: #1365 - FROMLIST: usb: dwc3: qcom: Keep USB bandwidth votes in nominal range
Upstream commit: https://lore.kernel.org/all/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com/
Verdict: ❌ FAIL

Commit Message

Check	Status	Note
Subject matches upstream	❌	Lore: "usb: dwc3: Update nominal max votes for qcom usb" vs PR: "FROMLIST: usb: dwc3: qcom: Keep USB bandwidth votes in nominal range" — completely different subjects
Body preserves rationale	❌	PR commit message describes reducing bandwidth votes to avoid turbo range; lore describes increasing votes to improve performance — opposite intent
Fixes tag present/correct	✅	No Fixes tag in either (not a bug fix)
Authorship preserved	⚠️	Lore author: akash.kumar@oss.qualcomm.com, PR author: akakum@qti.qualcomm.com — different email domains but same person; lore author's Signed-off-by is present
Backport note (if applicable)	N/A	FROMLIST prefix used (not a backport)

Diff Comparison

File	Status	Notes
drivers/usb/dwc3/dwc3-qcom.c:47	❌	OPPOSITE CHANGE: Lore increases USB_MEMORY_PEAK_SS_BW from 2500→5500; PR decreases it from 5500→4500
drivers/usb/dwc3/dwc3-qcom.c:48	❌	OPPOSITE CHANGE: Lore sets APPS_USB_AVG_BW from 0→40; PR sets it from 40→0
drivers/usb/dwc3/dwc3-qcom.c:49	❌	OPPOSITE CHANGE: Lore increases APPS_USB_PEAK_BW from 40→80; PR decreases it from 80→40

Upstream Patch Status

Community verdict: ⏳ Decision Pending — under review with critical issues raised

Evidence from lore thread:

• Sashiko AI bot (2026-06-11): Flagged APPS_USB_AVG_BW 40 missing MBps_to_icc() macro — would pass 40 kBps instead of 40 MBps
• Dmitry Baryshkov (maintainer, 2026-06-12): Requested MBps_to_icc(40) fix and asked for justification of APPS_USB_*_BW changes
• No acceptance signals (no "applied", "queued", "Reviewed-by", or "Acked-by" from maintainers)
• No rejection signals (no "NAK" or explicit rejection)

The lore patch has a critical bug (missing macro) and unanswered maintainer questions. It is not ready for merge.

Integration Presence (from integration_presence_report.md)

Commit	qcom-next	topics	Final
1/1	partial	missing	PARTIAL

Status: Only partial evidence found in qcom-next; full change not verified in either qcom-next or topic branches.

Issues Found

Critical Issues:

1. The PR patch applies the INVERSE of the lore patch

   • Lore increases bandwidth votes (2500→5500, 0→40, 40→80)
   • PR decreases bandwidth votes (5500→4500, 40→0, 80→40)
   • The commit messages describe opposite goals:
     • Lore: "Increase nominal max votes to improve DDR performance"
     • PR: "Reduce the USB memory peak vote... to keep bandwidth within nominal range"

2. Subject line mismatch

   • Lore: "usb: dwc3: Update nominal max votes for qcom usb"
   • PR: "FROMLIST: usb: dwc3: qcom: Keep USB bandwidth votes in nominal range"
   • These describe fundamentally different changes

3. The lore patch has a critical bug

   • APPS_USB_AVG_BW 40 is missing MBps_to_icc() macro
   • Would vote for 40 kBps instead of 40 MBps (1000× too small)
   • Flagged by both Sashiko AI and maintainer Dmitry Baryshkov
   • The PR patch does NOT have this bug (it correctly uses 0, not 40)

4. The lore patch is under review with unanswered questions

   • Maintainer asked for math explanation and justification
   • No follow-up revision posted
   • Not accepted or merged anywhere

5. Wrong lore link for this PR

   • The PR appears to implement a different change (bandwidth reduction)
   • The linked lore patch implements bandwidth increase
   • These are conflicting approaches to the same problem

Verdict

❌ FAIL — Do not merge

This PR claims to be FROMLIST: from the linked lore patch, but implements the exact opposite change. The lore patch increases bandwidth votes to improve performance; this PR decreases them to stay within nominal range. These are mutually exclusive solutions.

Root cause: Either:

1. The wrong lore link was provided (there may be a different lore patch that matches this PR's intent), OR
2. The PR author changed their approach after posting to lore but reused the old lore link

Required actions:

1. If this PR's approach (reducing bandwidth) is correct:
   • Remove the lore link (this is not a FROMLIST patch)
   • Change prefix to QCLINUX: or PENDING:
   • Provide independent justification for the bandwidth reduction
2. If the lore approach (increasing bandwidth) is correct:
   • Revert this PR's diff to match the lore patch
   • Fix the APPS_USB_AVG_BW bug (add MBps_to_icc(40))
   • Wait for maintainer approval on lore before merging

Final Summary

1. Lore link present: Yes — https://lore.kernel.org/all/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com/
2. Lore link matches PR commits: ❌ No — PR implements the inverse of the lore patch (decreases bandwidth where lore increases it, and vice versa)
3. Upstream patch status: ⏳ Decision Pending — under review with critical bug and unanswered maintainer questions; not accepted
4. PR present in qcom-next/topics: Partial — only partial evidence in qcom-next; full change not verified

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: c7896917e523946138ce654d4b6c1e33d5a8f4e5
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit	Subject	qcom-next	topics	Final
1/1	[PATCH] FROMLIST: usb: dwc3: qcom: Keep USB bandwidth votes in	partial - subject or partial tree evidence found, but full change was not verified	missing - no subject, patch-id, or full tree-content match found	partial

Final Status

overall_status: PARTIAL
present_commits: 0/1
partial_commits: 1/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

[qlijarvis]

PR #1365 — checker-log-analyzer

PR: #1365
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/40904248780

Checker	Result	Summary
Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	Skipped (no DT binding changes)
dtb-check	⏭️	Skipped (no DTS changes)
sparse-check	✅	No static analysis warnings
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	❌	Content mismatch + author mismatch
tag-check	✅	Valid FROMLIST: prefix present

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1365 - FROMLIST: usb: dwc3: qcom: Keep USB bandwidth votes in nominal range
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/40904248780

Checker	Result	Summary
checkpatch	✅	No style issues
dt-binding-check	⏭️	Skipped (no DT binding changes)
dtb-check	⏭️	Skipped (no DTS changes)
sparse-check	✅	No static analysis warnings
check-uapi-headers	✅	No UAPI changes
check-patch-compliance	❌	Content mismatch + author mismatch
tag-check	✅	Valid FROMLIST: prefix present

---

❌ check-patch-compliance

Root cause: Two distinct failures on commit be6aabf — the patch content differs from the upstream lore link, and the commit author email doesn't match the upstream author.

Failure details:

Checking commit: FROMLIST: usb: dwc3: qcom: Keep USB bandwidth votes in nominal range
Change is different from the one mentioned in Link
Author mismatch:
  Original author: Akash Kumar <akash.kumar@oss.qualcomm.com>
  Commit author : Akash Kumar <akakum@qti.qualcomm.com>

Analysis:

Issue 1: Content mismatch
The patch in the PR differs from the upstream patch at:
Link: https://lore.kernel.org/all/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com/

This could be due to:

• Context line differences (line numbers shifted)
• Additional changes not present upstream
• Missing hunks from the upstream patch
• Legitimate adaptation for the vendor tree

Issue 2: Author mismatch

• Upstream author: Akash Kumar <akash.kumar@oss.qualcomm.com>
• Commit author: Akash Kumar <akakum@qti.qualcomm.com>

The email domain changed from @oss.qualcomm.com (upstream) to @qti.qualcomm.com (internal).

Fix:

For content mismatch:

1. Fetch the upstream patch and compare:

   b4 am --single-message -C -l -3 https://lore.kernel.org/all/20260611081831.2743464-1-akash.kumar@oss.qualcomm.com/ -o /tmp/upstream
   git format-patch -1 be6aabf904d8 --stdout > /tmp/pr-patch

2. Compare the actual code changes (ignore context):

   diff <(awk '/^diff/,/^--$/' /tmp/pr-patch | grep -E '^[+-][^+-]') \
        <(awk '/^diff/,/^--$/' /tmp/upstream/*.mbx | grep -E '^[+-][^+-]')

3. If identical: The mismatch is context-only (false positive) — document this in the PR description.

4. If different: Determine if the changes are:

   • Legitimate adaptation → Document the delta in the commit message
   • Missing hunks → Add them
   • Extra changes → Remove or attribute separately

For author mismatch:

git rebase -i bf8dffb05bda   # mark commit as 'edit'
git commit --amend --author="Akash Kumar <akash.kumar@oss.qualcomm.com>"
git rebase --continue

Reproduce locally:

cd /path/to/kernel
bash ../kernel-checkers/check-patch-compliance.sh \
  --kernel-src . \
  --base bf8dffb05bda45b8490ab4ee04998dfa9b8be292 \
  --head be6aabf904d8d5daa1c991d10ab2f59c592c661f

---

Verdict

2 blockers must be fixed before merge:

1. Author email mismatch — Change commit author to match upstream: akash.kumar@oss.qualcomm.com
2. Content mismatch — Verify the patch content matches the upstream lore link. If there are legitimate adaptations, document them in the commit message. If the mismatch is context-only, note this in the PR description.

All other checkers passed cleanly. Once these two issues are resolved, the PR will be ready to merge.