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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <22471e26-0451-2b78-2f5d-67aedc7d0736@linux.dev>
Date:   Mon, 3 Oct 2022 13:18:47 -0600
From:   Jonathan Derrick <jonathan.derrick@...ux.dev>
To:     Pali Rohár <pali@...nel.org>,
        Vidya Sagar <vidyas@...dia.com>,
        Bjorn Helgaas <helgaas@...nel.org>
Cc:     Lukas Wunner <lukas@...ner.de>, bhelgaas@...gle.com,
        robh+dt@...nel.org, krzysztof.kozlowski+dt@...aro.org,
        lpieralisi@...nel.org, kw@...ux.com, thierry.reding@...il.com,
        jonathanh@...dia.com, mani@...nel.org,
        Sergey.Semin@...kalelectronics.ru, jszhang@...nel.org,
        linux-pci@...r.kernel.org, linux-tegra@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        kthota@...dia.com, mmaddireddy@...dia.com, sagar.tv@...il.com,
        Marek Behún <kabel@...nel.org>
Subject: Re: [PATCH V1 0/4] GPIO based PCIe Hot-Plug support



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/