Linux PCI subsystem development
 help / color / mirror / Atom feed
From: Felix Kuehling <felix.kuehling@amd.com>
To: Lukas Wunner <lukas@wunner.de>,
	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>,
	Jay Cornwall <Jay.Cornwall@amd.com>
Subject: Re: [PATCH v3 2/2] PCI: pciehp: Clear the optional capabilities in DEVCTL2 on a hot-plug
Date: Fri, 23 Jun 2023 05:59:55 +0200	[thread overview]
Message-ID: <8bb20976-97ec-0c5c-adc8-183896de6768@amd.com> (raw)
In-Reply-To: <20230622214247.GB11993@wunner.de>

On 2023-06-22 23:42, Lukas Wunner wrote:
> [cc += Jay, Felix]
>
> On Thu, Jun 22, 2023 at 02:02:12PM -0700, Smita Koralahalli wrote:
>> Would it be fair to just reuse pci_enable_atomic_ops_to_root() for
>> Atomic_Ops configuration?
> Hm, that's a good question.  I'm not an expert on that corner of
> the PCI core.
>
> But indeed what you could try is amend that function to not only
> *set* PCI_EXP_DEVCTL2_ATOMIC_REQ if it's supported, but to also
> *clear* it if it's not supported.
>
> And you'd have to call pci_enable_atomic_ops_to_root() on enumeration,
> e.g. from pci_init_capabilities().
>
> That should obviate the need to call pci_enable_atomic_ops_to_root()
> from drivers, so you could probably remove the call from all the
> drivers which currently call it (amdgpu, infiniband, mellanox),
> in one separate patch per driver.
>
> An then you could drop the EXPORT clause for pci_enable_atomic_ops_to_root()
> and make it private to the PCI core.
Then our driver would need an alternative way to determine whether 
atomic capabilities are enabled for a device. We currently use the 
return value from pci_enable_atomic_ops_to_root to determine this.

Regards,
   Felix


>
> So that would be 5 patches (enablement/disablement on enumeration,
> amendmend of the 3 drivers, making the call private).
>
> I'm not sure if anyone will cry foul if you do that but if you want
> to give it a try, go for it. :)
>
> I don't now why commit 430a23689dea, which introduced
> pci_enable_atomic_ops_to_root(), chose to add it as a library function
> which is only called from specific drivers, instead of universally
> enabling the feature for all devices.  Adding the commit authors to cc
> so they can chime in.
>
> Thanks,
>
> Lukas

  reply	other threads:[~2023-06-23  4:00 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
2023-06-22 21:42       ` Lukas Wunner
2023-06-23  3:59         ` Felix Kuehling [this message]
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=8bb20976-97ec-0c5c-adc8-183896de6768@amd.com \
    --to=felix.kuehling@amd.com \
    --cc=Jay.Cornwall@amd.com \
    --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=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