From: Lukas Wunner <lukas@wunner.de>
To: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
Cc: linux-pci@vger.kernel.org, linux-kernel@vger.kernel.org,
Bjorn Helgaas <bhelgaas@google.com>,
oohall@gmail.com, Mahesh J Salgaonkar <mahesh@linux.ibm.com>,
Kuppuswamy Sathyanarayanan
<sathyanarayanan.kuppuswamy@linux.intel.com>,
Yazen Ghannam <yazen.ghannam@amd.com>,
Fontenot Nathan <Nathan.Fontenot@amd.com>
Subject: Re: [PATCH v3 2/2] PCI: pciehp: Clear the optional capabilities in DEVCTL2 on a hot-plug
Date: Thu, 22 Jun 2023 08:31:05 +0200 [thread overview]
Message-ID: <20230622063105.GA624@wunner.de> (raw)
In-Reply-To: <20230621185152.105320-3-Smita.KoralahalliChannabasappa@amd.com>
On Wed, Jun 21, 2023 at 06:51:52PM +0000, Smita Koralahalli wrote:
> --- a/drivers/pci/hotplug/pciehp_pci.c
> +++ b/drivers/pci/hotplug/pciehp_pci.c
> @@ -102,6 +102,10 @@ void pciehp_unconfigure_device(struct controller *ctrl, bool presence)
>
> pci_lock_rescan_remove();
>
> + pcie_capability_clear_word(ctrl->pcie->port, PCI_EXP_DEVCTL2,
> + (PCI_EXP_DEVCTL2_ARI | PCI_EXP_DEVCTL2_ATOMIC_REQ |
> + PCI_EXP_DEVCTL2_TAG_REQ_EN));
> +
Hm, this will clear the bits while the device may still be present.
Note that the subsequent pci_stop_and_remove_bus_device() will unbind
the driver and may thus cause communication with the device.
Can clearing those bits in the hotplug port hamper communication with
the device?
I'd recommend avoiding that issue altogether by clearing the bits at
the end of the function after the call to pci_unlock_rescan_remove(),
so that negotiated state of the hotplug port gets cleared after all
subordinate devices are de-enumerated.
The commit message doesn't point out that PCI_EXP_DEVCTL2_ARI is
already being taken care of on enumeration of future subordinate
devices in pci_configure_ari() and is only cleared here for good
measure. If you intend to configure 10 bit tags and atomic ops
on enumeration in future patches, I'd recommend omitting
PCI_EXP_DEVCTL2_ARI here and clearing each of the other two bits
in the future patches which configure them on enumeration.
You don't need braces around the "or" operation for the bits.
Thanks,
Lukas
> /*
> * Stopping an SR-IOV PF device removes all the associated VFs,
> * which will update the bus->devices list and confuse the
> diff --git a/include/uapi/linux/pci_regs.h b/include/uapi/linux/pci_regs.h
> index dc2000e0fe3a..6fbc47f23d52 100644
> --- a/include/uapi/linux/pci_regs.h
> +++ b/include/uapi/linux/pci_regs.h
> @@ -668,6 +668,7 @@
> #define PCI_EXP_DEVCTL2_IDO_REQ_EN 0x0100 /* Allow IDO for requests */
> #define PCI_EXP_DEVCTL2_IDO_CMP_EN 0x0200 /* Allow IDO for completions */
> #define PCI_EXP_DEVCTL2_LTR_EN 0x0400 /* Enable LTR mechanism */
> +#define PCI_EXP_DEVCTL2_TAG_REQ_EN 0x1000 /* Allow 10 Tags for Requester */
> #define PCI_EXP_DEVCTL2_OBFF_MSGA_EN 0x2000 /* Enable OBFF Message type A */
> #define PCI_EXP_DEVCTL2_OBFF_MSGB_EN 0x4000 /* Enable OBFF Message type B */
> #define PCI_EXP_DEVCTL2_OBFF_WAKE_EN 0x6000 /* OBFF using WAKE# signaling */
> --
> 2.17.1
next prev parent reply other threads:[~2023-06-22 6:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-21 18:51 [PATCH v3 0/2] PCI: pciehp: Add support for native AER and DPC handling on async remove Smita Koralahalli
2023-06-21 18:51 ` [PATCH v3 1/2] PCI: pciehp: Add support for async hotplug with native AER and DPC/EDR Smita Koralahalli
2023-06-22 9:04 ` Lukas Wunner
2023-06-22 21:02 ` Smita Koralahalli
2023-06-22 21:22 ` Lukas Wunner
2023-06-22 23:22 ` Sathyanarayanan Kuppuswamy
2023-06-27 17:48 ` Smita Koralahalli
2023-06-28 13:29 ` Lukas Wunner
2023-06-21 18:51 ` [PATCH v3 2/2] PCI: pciehp: Clear the optional capabilities in DEVCTL2 on a hot-plug Smita Koralahalli
2023-06-22 6:31 ` Lukas Wunner [this message]
2023-06-22 10:04 ` Lukas Wunner
2023-06-22 21:02 ` Smita Koralahalli
2023-06-22 21:42 ` Lukas Wunner
2023-06-23 3:59 ` Felix Kuehling
2023-06-23 6:06 ` Lukas Wunner
2023-06-23 13:12 ` Jay Cornwall
2023-06-27 17:38 ` Smita Koralahalli
2023-06-28 13:25 ` Lukas Wunner
2023-07-01 6:29 ` Smita Koralahalli
2023-08-15 21:22 ` Smita Koralahalli
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=20230622063105.GA624@wunner.de \
--to=lukas@wunner.de \
--cc=Nathan.Fontenot@amd.com \
--cc=Smita.KoralahalliChannabasappa@amd.com \
--cc=bhelgaas@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mahesh@linux.ibm.com \
--cc=oohall@gmail.com \
--cc=sathyanarayanan.kuppuswamy@linux.intel.com \
--cc=yazen.ghannam@amd.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