From: Lukas Wunner <lukas@wunner.de>
To: Vidya Sagar <vidyas@nvidia.com>
Cc: bhelgaas@google.com, vsethi@nvidia.com, sdonthineni@nvidia.com,
kthota@nvidia.com, mmaddireddy@nvidia.com, kumarahul@nvidia.com,
sagar.tv@gmail.com, linux-pci@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH V3 3/5] PCI: Save and restore the Device 3 Control register
Date: Sat, 15 Aug 2026 08:53:39 +0200 [thread overview]
Message-ID: <aoAM8x1JPzCDTaBf@wunner.de> (raw)
In-Reply-To: <20260814201621.2281245-4-vidyas@nvidia.com>
On Sat, Aug 15, 2026 at 01:46:19AM +0530, Vidya Sagar wrote:
> +static void pci_restore_dev3_state(struct pci_dev *dev)
[...]
> + /*
> + * DEV3_CTL.14-Bit Tag Requester Enable is only meaningful in flit
> + * mode. On devices that advertise 14-Bit Tag Requester support,
> + * sanitize the saved value before writing it back, so that callers
> + * that issue further TLPs through this device after restore see a
> + * coherent enable state. Every other bit of DEV3_CTL (DMWr
> + * Requester Enable, DMWr Egress Blocking, L0p Enable, Target Link
> + * Width and any future addition) is written back unchanged.
> + *
> + * Only the value written to hardware is adjusted. The save buffer
> + * keeps what was saved, so the decision is taken afresh on every
> + * restore and the originally programmed value is not lost.
> + */
This is quite verbose, can you condense it a bit? E.g. it's not
necessary to say that every other bit is written back unchanged.
That's the default. Just say e.g.:
/* Clear 14-Bit Tag Requester Enable if link is no longer in Flit Mode */
> + pci_read_config_dword(dev, pos + PCI_DEV3_CAP, &dev3_cap);
> + if (dev3_cap & PCI_DEV3_CAP_14BIT_TAG_REQ) {
PCIe r7.0 sec 7.7.10.3 says the bit is "VF RsvdP", so you need
to check !dev->is_virtfn here.
> + /*
> + * Check both LNKSTA2.Flit_Mode (link-level) and
> + * DEV3_STA.Segment Captured (end-to-end); both must be
> + * active for 14-bit tags. Refresh bus->flit_mode and
> + * dev->fm_enabled in lock-step.
> + */
Why do we have to check both?
We usually spell out the register names fully or leave them out.
Using "LNKSTA2.Flit_Mode" and "DEV3_STA.Segment Captured" instead looks
odd to me.
> + pci_read_config_dword(dev, pos + PCI_DEV3_STA, &dev3_sta);
> + dev->fm_enabled = !!(dev3_sta & PCI_DEV3_STA_SEGMENT);
> +
> + pcie_capability_read_word(dev, PCI_EXP_LNKSTA2, &lnksta2);
> + flit_now = !!(lnksta2 & PCI_EXP_LNKSTA2_FLIT);
> + if (dev->bus)
> + dev->bus->flit_mode = flit_now;
When can dev->bus be NULL?
> +
> + if ((!dev->fm_enabled || !flit_now) &&
> + (val & PCI_DEV3_CTL_14BIT_TAG_REQ_EN)) {
> + val &= ~PCI_DEV3_CTL_14BIT_TAG_REQ_EN;
> + pci_info(dev, "clearing 14-Bit Tag Requester Enable: flit mode no longer active (LNKSTA2=%#06x, DEV3_STA=%#010x)\n",
> + lnksta2, dev3_sta);
pci_dbg() please.
> + /*
> + * Save buffer for DEV3_CTL only. Every field in DEV3_STA is
> + * read-only status reported by hardware, so there is nothing there
> + * to restore.
> + */
The code comment seems unnecessary because that policy applies
to every other Extended Capability as well. We only save
mutable registers, that's the default.
Thanks,
Lukas
next prev parent reply other threads:[~2026-08-15 6:53 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 20:16 [PATCH V3 0/5] PCI: Re-evaluate DEV3 14-Bit Tag Requester Enable on link mode changes Vidya Sagar
2026-08-14 20:16 ` [PATCH V3 1/5] PCI: Add DEV3 14-Bit Tag Requester register definitions Vidya Sagar
2026-08-14 20:16 ` [PATCH V3 2/5] PCI: Move __pcie_update_link_speed() out of line Vidya Sagar
2026-08-14 20:16 ` [PATCH V3 3/5] PCI: Save and restore the Device 3 Control register Vidya Sagar
2026-08-15 6:53 ` Lukas Wunner [this message]
2026-08-14 20:16 ` [PATCH V3 4/5] PCI: Clear stale 14-Bit Tag Requester Enable when a link leaves Flit Mode Vidya Sagar
2026-08-15 7:20 ` Lukas Wunner
2026-08-14 20:16 ` [PATCH V3 5/5] PCI: pciehp: Clear stale 14-Bit Tag Requester Enable on hot add Vidya Sagar
2026-08-15 7:24 ` Lukas Wunner
2026-08-15 7:14 ` [PATCH V3 0/5] PCI: Re-evaluate DEV3 14-Bit Tag Requester Enable on link mode changes Lukas Wunner
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=aoAM8x1JPzCDTaBf@wunner.de \
--to=lukas@wunner.de \
--cc=bhelgaas@google.com \
--cc=kthota@nvidia.com \
--cc=kumarahul@nvidia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mmaddireddy@nvidia.com \
--cc=sagar.tv@gmail.com \
--cc=sdonthineni@nvidia.com \
--cc=vidyas@nvidia.com \
--cc=vsethi@nvidia.com \
/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