Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Smita Koralahalli <Smita.KoralahalliChannabasappa@amd.com>
To: Lukas Wunner <lukas@wunner.de>
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 14:02:12 -0700	[thread overview]
Message-ID: <d64f8de4-cac1-ccca-33fe-1fda418837e2@amd.com> (raw)
In-Reply-To: <20230622063105.GA624@wunner.de>

On 6/21/2023 11:31 PM, Lukas Wunner wrote:
> 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.

This is a good point. Thanks!

> 
> 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.

Would it be fair to just reuse pci_enable_atomic_ops_to_root() for
Atomic_Ops configuration?

> 
> You don't need braces around the "or" operation for the bits.

Sure!

Thanks,
Smita

> 
> 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


  parent reply	other threads:[~2023-06-22 21:11 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
2023-06-22 10:04     ` Lukas Wunner
2023-06-22 21:02     ` Smita Koralahalli [this message]
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=d64f8de4-cac1-ccca-33fe-1fda418837e2@amd.com \
    --to=smita.koralahallichannabasappa@amd.com \
    --cc=Nathan.Fontenot@amd.com \
    --cc=bhelgaas@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lukas@wunner.de \
    --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