Re: [PATCH V1 0/4] GPIO based PCIe Hot-Plug support

From: Vidya Sagar
Date: Tue Oct 04 2022 - 00:05:18 EST



On 10/3/2022 11:51 PM, Pali Rohár wrote:
External email: Use caution opening links or attachments


On Monday 03 October 2022 13:09:49 Bjorn Helgaas wrote:
On Sat, Oct 01, 2022 at 05:50:07PM -0600, Jonathan Derrick wrote:
On 10/1/2022 10:20 AM, Pali Rohár wrote:
...

Would not it better to rather synthesise PCIe Slot Capabilities support
in your PCIe Root Port device (e.g. via pci-bridge-emul.c) and then let
existing PCI hotplug code to take care for hotplugging? Because it
already implements all required stuff for re-scanning, registering and
unregistering PCIe devices for Root Ports with Slot Capabilities. And I
think that there is no need to have just another (GPIO based)
implementation of PCI hotplug.

I did that a few years ago (rejected), but can attest to the robustness of
the pcie hotplug code on non-hotplug slots.
https://lwn.net/Articles/811988/

I think the thread is here:
https://lore.kernel.org/linux-pci/1581120007-5280-1-git-send-email-jonathan.derrick@xxxxxxxxx/
and I'm sorry that my response came across as "rejected". I intended
it as "this is good ideas and good work and we should keep going".

Bjorn

Nice! So we have consensus that this is a good idea. Anyway, if you need
help with designing something here, please let me know as I have good
understanding of all (just two) consumers of pci-bridge-emul.c driver.


Thanks all for your comments.

I would like to hear from Bjorn / Lorenzo if the design of the current patch series is fine at a high level or I should explore emulating the root port's configuration space to fake slot config/control registers (which in turn depend on the hotplug GPIO interrupt & state to update Presence Detect related bits in Slot status register) and use the PCIe native Hot-plug framework itself to carry out with enabling the Hot-plug functionality?

Thanks,
Vidya Sagar