From: Priyank Rathod <rathodpriyank@google.com>
To: sashiko-bot@kernel.org, Bjorn Helgaas <bhelgaas@google.com>
Cc: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Lukas Wunner" <lukas@wunner.de>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Shuah Khan" <shuah@kernel.org>,
"Randy Dunlap" <rdunlap@infradead.org>,
linux-pci@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] selftests/pcie_lmr: Add tests for the Lane Margining debugfs interface
Date: Tue, 6 Oct 2026 17:34:15 +0000 [thread overview]
Message-ID: <20261006173415.1002265-1-rathodpriyank@google.com> (raw)
In-Reply-To: <sashiko-outbox-162260@kernel.org>
On Tue, 6 Oct 2026, sashiko-bot@kernel.org wrote:
> > + up=$([ "$rx" = 6 ] && echo "$dev" || echo "$partner")
> > + after="$(link_regs "$dev") $(link_regs "$partner")"
> > + if [ -z "${before// }" ]; then
> > + ktap_test_skip "$dev: setpci not found"
> > + elif [ -n "$up" ] && [ ! -d "/sys/bus/pci/devices/$up/link" ]; then
> > + ktap_test_skip "$dev: no OS ASPM control on link"
>
> [Severity: Medium]
> Is it possible that the logic for identifying the upstream port is reversed?
>
> In active_tests(), the variable up is assigned using the receiver type.
> If rx=6, dev is the Endpoint device, so up becomes the Endpoint.
> If rx=1, dev is the Downstream Port, meaning partner is the Endpoint,
> so up still evaluates to the Endpoint device.
>
> Because up always evaluates to the Endpoint device instead of the
> Downstream Port, the check for the sysfs link directory will always fail,
> as that directory is only present on the Downstream Port. Will this cause
> the test to unconditionally skip the final LNKCTL restoration checks?
For human reviewers: this is a false positive.
In PCIe terminology, the Upstream Port ('up', receiver 6) is the child
device below the Downstream Port (an Endpoint or Switch Upstream Port).
In drivers/pci/pcie/aspm.c, aspm_ctrl_attrs_are_visible() looks up the
link via pcie_aspm_get_link(pdev), which reads
pci_upstream_bridge(pdev)->link_state. So the sysfs 'link/' directory
is attached to the child device below the Downstream Port (receiver 6),
not to the Downstream Port itself.
To avoid any confusion over the variable name 'up', I'll send v5 with
'up' renamed to 'child' and a comment explaining the sysfs 'link/'
lookup.
Thanks,
Priyank
prev parent reply other threads:[~2026-10-06 17:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-06 16:11 [PATCH v4 0/2] PCI: Add Lane Margining at the Receiver debugfs interface Priyank Rathod
2026-10-06 16:11 ` [PATCH v4 1/2] PCI/LMR: " Priyank Rathod
2026-10-06 16:24 ` sashiko-bot
2026-10-06 16:11 ` [PATCH v4 2/2] selftests/pcie_lmr: Add tests for the Lane Margining " Priyank Rathod
2026-10-06 16:33 ` sashiko-bot
2026-10-06 17:34 ` Priyank Rathod [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=20261006173415.1002265-1-rathodpriyank@google.com \
--to=rathodpriyank@google.com \
--cc=bhelgaas@google.com \
--cc=corbet@lwn.net \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lukas@wunner.de \
--cc=mani@kernel.org \
--cc=rdunlap@infradead.org \
--cc=sashiko-bot@kernel.org \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
/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