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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 10/3/2022 12:21 PM, Pali Rohár wrote:
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.

I haven't looked at the changes required to conform to 6.0. My implementation was more or less a filter driver on top of the pciehp slot (if it existed or had to be emulated). It's not really a hack for anything and was intended for use with an interposer to a bunch of M.2 that a OEM wanted to hotplug without adding slot hardware. (Yes I know M.2 is not technically hot-pluggable. OEM ended up with sysfs managed hotplug with this patchset).

But there are systems out there with U.2 without slot logic that could likely survive the event gracefully, given that modern CPUs expect this thing in the same way that modern kernels don't rely on Surprise+.


My implementation is a bit of overkill if we'd want to strip it from the gpio implementation. If we want to include and extend it, we can make the gpio_isr another caller of pciehp_ist() (via [1])

[1] https://lore.kernel.org/linux-pci/1581120007-5280-7-git-send-email-jonathan.derrick@xxxxxxxxx/



[Index of Archives]     [DMA Engine]     [Linux Coverity]     [Linux USB]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Greybus]

  Powered by Linux