Skip to content

[24.04_linux-nvidia-6.17-next] PCI: mirror PI7C9X3G606GPC Port 4 BAR0#442

Draft
nirmoy wants to merge 1 commit into
NVIDIA:24.04_linux-nvidia-6.17-nextfrom
nirmoy:codex/pericom-msix-bar-war-6.17
Draft

[24.04_linux-nvidia-6.17-next] PCI: mirror PI7C9X3G606GPC Port 4 BAR0#442
nirmoy wants to merge 1 commit into
NVIDIA:24.04_linux-nvidia-6.17-nextfrom
nirmoy:codex/pericom-msix-bar-war-6.17

Conversation

@nirmoy
Copy link
Copy Markdown
Collaborator

@nirmoy nirmoy commented May 27, 2026

Summary

  • Add a PCI final/resume quirk for Pericom/Diodes PI7C9X3G606GPC to mirror the upstream BAR0 value into downstream Port 4 BAR0.
  • Scope the WAR to the Diodes-confirmed OS-visible Tile0/P4 mapping: upstream bus + 1, device 04, function 0.
  • Port 4 BAR0 may read back as zero through normal PCI config space even after a successful write, so the quirk rewrites BAR0 whenever it runs.

Validation

  • Built 6.17.0-1018-nvidia-64k test debs from this WAR path.
  • Expected dmesg when the WAR runs:
pci 0002:a2:04.0: wrote upstream BAR 0 0x10c00000 to Port 4 BAR 0 for PI7C9X3G606GPC workaround
  • The BAR value is platform/boot dependent. In the Quark test run, Linux reassigned upstream BAR0 for 0002:a1:00.0 from 0x10300000 to 0x10c00000, then the quirk wrote 0x10c00000 to 0002:a2:04.0 Port 4 BAR0.
  • Normal config-space readback of Port 4 BAR0 still returns 0 on this device, so setpci readback is not a valid failure signal for the WAR.
  • A Diodes-provided BMC/I2C debug readback sequence returned non-zero Port 4 BAR0 bytes, 0x10 0xc0 0x00 0x00, matching 0x10c00000. That sequence uses special CPED/CDEP programming and is not a supported production validation path on this platform, so further validation should avoid it.

Fresh validation with the exact rebased PR package set is still pending.

References

BugLink: https://nvbugspro.nvidia.com/bug/6205517
BugLink: https://nvbugspro.nvidia.com/bug/6134331

Test artifacts: http://baseos-internal-tools.nvidia.com:8003/

Some Pericom/Diodes PI7C9X3G606GPC switches require downstream Port 4
BAR0 to mirror the upstream port BAR0. Firmware may apply this during
boot, but Linux PCI resource assignment can move the upstream BAR0 and
leave Port 4 without the required mirror.

Add a final and resume quirk for downstream Port 4. The quirk verifies
that the immediate upstream bridge is the same switch, then writes Port 4
BAR0 from the upstream BAR0 after resource assignment and after resume.
Port 4 BAR0 may read back as zero even after a successful write, so the
write must be validated by platform-specific means.

BugLink: https://nvbugspro.nvidia.com/bug/6205517
BugLink: https://nvbugspro.nvidia.com/bug/6134331
Signed-off-by: Nirmoy Das <nirmoyd@nvidia.com>
@nirmoy nirmoy force-pushed the codex/pericom-msix-bar-war-6.17 branch from 44e1553 to 31881cf Compare May 27, 2026 16:08
@nirmoy nirmoy added the help wanted Extra attention is needed label May 27, 2026
@nirmoy
Copy link
Copy Markdown
Collaborator Author

nirmoy commented May 27, 2026

Boro review

Latest watcher review: open review

Head: 31881cfa3dda

This comment is maintained by nv-pr-bot. It is updated when the GitHub watcher publishes a newer review.

@github-actions
Copy link
Copy Markdown
Contributor

github-actions Bot commented May 27, 2026

PR Validation Report

Patchscan ✅ No Missing Fixes

All cherry-picked commits checked — no missing upstream fixes found.

PR Lint ❌ Errors found

Details
Checking 1 commits...

Cherry-pick digest:
┌──────────────┬──────────────────────────────────────────────────────────────────┬────────────┬─────────┬───────────────────────────┐
│ Local        │ Referenced upstream / Patch subject                              │ Patch-ID   │ Subject │ SoB chain                 │
├──────────────┼──────────────────────────────────────────────────────────────────┼────────────┼─────────┼───────────────────────────┤
│ 31881cfa3dda │ [SAUCE] pci: quirks: mirror pi7c9x3g606gpc port 4 bar0           │ N/A        │ N/A     │ nirmoyd                   │
└──────────────┴──────────────────────────────────────────────────────────────────┴────────────┴─────────┴───────────────────────────┘

Lint: all checks passed.

PR metadata:
E: PR targets 24.04_linux-nvidia-6.17-next but body has no https://bugs.launchpad.net/... link

@nvidia-bfigg
Copy link
Copy Markdown
Collaborator

Does this PR need to be applied to the 6.18 reference kernel as well?

@nvidia-bfigg
Copy link
Copy Markdown
Collaborator

Do you have tests (scripts) which can verify this patch set is applied and working?

@nirmoy
Copy link
Copy Markdown
Collaborator Author

nirmoy commented May 27, 2026

Hi @nvidia-bfigg

Does this PR need to be applied to the 6.18 reference kernel as well?

Yes, we need that for 6.18 too. I will create a PR for that as well

Do you have tests (scripts) which can verify this patch set is applied and working?
The kernel WAR will be always applied at the boot time because config read of the effected port always return 0 so we should see the in the dmesg wrote upstream BAR 0 %#x to Port 4 BAR 0 for PI7C

@nvidia-bfigg
Copy link
Copy Markdown
Collaborator

Hi @nvidia-bfigg

Does this PR need to be applied to the 6.18 reference kernel as well?

Yes, we need that for 6.18 too. I will create a PR for that as well

Do you have tests (scripts) which can verify this patch set is applied and working?
The kernel WAR will be always applied at the boot time because config read of the effected port always return 0 so we should see the in the dmesg wrote upstream BAR 0 %#x to Port 4 BAR 0 for PI7C

So if the patch is not applied to the kernel that message will not be in the dmesg. We should have a test that verifies that message is in the dmesg or the test should fail that the patch has not been applied, correct?

@nirmoy
Copy link
Copy Markdown
Collaborator Author

nirmoy commented May 28, 2026

Hi @nvidia-bfigg

Does this PR need to be applied to the 6.18 reference kernel as well?

Yes, we need that for 6.18 too. I will create a PR for that as well

Do you have tests (scripts) which can verify this patch set is applied and working?
The kernel WAR will be always applied at the boot time because config read of the effected port always return 0 so we should see the in the dmesg wrote upstream BAR 0 %#x to Port 4 BAR 0 for PI7C

So if the patch is not applied to the kernel that message will not be in the dmesg. We should have a test that verifies that message is in the dmesg or the test should fail that the patch has not been applied, correct?

Yes, ACK we should have a test may be a greenlit one to check the dmesg to verify the patch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

help wanted Extra attention is needed pending_review_comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants