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

[Jonathan Derrick]

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/