The Linux Kernel Mailing List
 help / color / mirror / Atom feed
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

  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