From: sashiko-bot@kernel.org
To: "Priyank Rathod" <rathodpriyank@google.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v3 3/3] PCI/pcie: Add PCIe Lane Margining at Receiver (LMR) support
Date: Fri, 04 Sep 2026 05:31:49 +0000 [thread overview]
Message-ID: <20260904053150.6F3041F00A3E@smtp.kernel.org> (raw)
In-Reply-To: <20260904-pcie-link-endpoints-v3-3-4b9a91bd4b35@google.com>
> Per PCIe Base Specification r6.0, sec 8.4.4 ("Lane Margining at
> Receiver"), PCIe devices operating at 16.0 GT/s (Gen 4) or higher data
> rates support the Lane Margining at Receiver Extended Capability
> (ID 0x27), and it is mandatory for receivers operating at 64.0 GT/s
> (Gen 6) or higher data rates. Lane Margining allows software to
> evaluate high-speed link margins by measuring timing and voltage steps
> for each individual physical lane and receiver.
>
> Add driver and debugfs support for PCIe Lane Margining at Receiver:
>
> - Add Lane Margining at Receiver Extended Capability register
> definitions (PCI_EXT_CAP_ID_LMR, PCI_LMR_PORT_CAP, PCI_LMR_PORT_STS,
> PCI_LMR_LANE_CTRL, PCI_LMR_LANE_STS) to <uapi/linux/pci_regs.h>.
> - Add Kconfig option CONFIG_PCIE_LMR (under drivers/pci/pcie/Kconfig)
> dependent on DEBUG_FS.
> - Implement drivers/pci/pcie/margin.c to probe the capability on Gen4+
> links and expose per-device debugfs entries under:
> /sys/kernel/debug/pci/pcie_lmr_<pci_dev_name>/
> providing control over margining enablement, receiver selection, and
> execution of timing/voltage margin step commands. Distinguish
> between missing mandatory LMR capability on Gen6+ vs optional on
> Gen4/Gen5.
> - Hook pci_lmr_init() into pci_init_capabilities() during device probe
> in drivers/pci/probe.c and pci_lmr_exit() into drivers/pci/remove.c.
> - Add kselftest script under tools/testing/selftests/pcie_lmt/pcie_lmt.sh
> to test debugfs capability reads, enablement, and stepping.
> - Add MAINTAINERS entry for PCIe Lane Margining at Receiver (LMR).
>
> Signed-off-by: Priyank Rathod <rathodpriyank@google.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260904-pcie-link-endpoints-v3-0-4b9a91bd4b35@google.com?part=3
prev parent reply other threads:[~2026-09-04 5:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 5:24 [PATCH v3 0/3] PCI/pcie: Add PCIe Lane Margining at Receiver (LMR) support Priyank Rathod
2026-09-04 5:24 ` [PATCH v3 1/3] PCI: Add pcie_get_link_endpoints() helper Priyank Rathod
2026-09-04 5:32 ` sashiko-bot
2026-09-04 5:24 ` [PATCH v3 2/3] PCI/ASPM: Add pci_aspm_inhibit() helper for temporary link state suppression Priyank Rathod
2026-09-04 5:31 ` sashiko-bot
2026-09-04 5:24 ` [PATCH v3 3/3] PCI/pcie: Add PCIe Lane Margining at Receiver (LMR) support Priyank Rathod
2026-09-04 5:31 ` sashiko-bot [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260904053150.6F3041F00A3E@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=rathodpriyank@google.com \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox