lkml.org 
[lkml]   [2022]   [Oct]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH V1 0/4] GPIO based PCIe Hot-Plug support
From


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@intel.com/
>> 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@intel.com/

\
 
 \ /
  Last update: 2022-10-03 21:19    [W:0.120 / U:0.220 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site