mbox series

[V1,0/4] GPIO based PCIe Hot-Plug support

Message ID 20220930192747.21471-1-vidyas@nvidia.com (mailing list archive)
Headers show
Series GPIO based PCIe Hot-Plug support | expand

Message

Vidya Sagar Sept. 30, 2022, 7:27 p.m. UTC
To support the Hot-plug feature, PCIe spec has a well-defined model for 
hardware implementation and software programming interface. There are also
some architectures/platforms where the Hot-plug feature is implemented in a
non-standard way and software support for the respective implementations is
available with the kernel. This patch series attempts to add support for one
such non-standard way of supporting the Hot-plug feature where a single GPIO
is used to detect and report the Hot-Plug and Unplug events to the SW.
The platforms that can use this piece of software need to have GPIO routed
from the slot to the controller which can indicate the presence/absence of
the downstream device through its state. This GPIO should also have the
capability to interrupt the system when the connection/disconnection event
takes place.
A GPIO Hot-plug framework is written which looks for a "hotplug-gpios" named
GPIO entry in the corresponding device-tree entry of the controller and
registers a hot-pluggable slot with the Hot-plug framework.
The platform drivers of the PCIe host bridges/root ports can register with the
aforementioned GPIO Hot-Plug framework along with ops to perform any platform
specific tasks during Hot-Plug/Unplug events.

Oza Pawandeep made an attempt to upstream support for a similar Hot-plug
feature implementation at a platform level, but the implementation as such
was very specific to that platform (at least the way I understood it).
https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-2-git-send-email-oza.oza@broadcom.com/
https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-3-git-send-email-oza.oza@broadcom.com/
https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-4-git-send-email-oza.oza@broadcom.com/
This current series also attempts to address that by extracting out all the
common code to do with GPIO and Hot-plug core framework and expecting the
platform drivers to only register/unregister with the GPIO framework. So,
@Oza, could you try using the GPIO framework from this series and enable
Hot-plug support for your platform if it still makes sense?

@Rob,
Regarding the DT documentation change to add about 'hotplug-gpios, I'm not
sure if pci.txt is the right place or the dt-schema repository
i.e https://github.com/devicetree-org/dt-schema
But, in the interest of keeping all the changes related to this feature in the
the same repository, I made the changes to the pci.txt file in this repo itself.
Please let me know if the documentation change needs to be moved to the other
repo.

The Changes have been tested on the Tegra234 platform.

Vidya Sagar (4):
  dt-bindings: Add "hotplug-gpios" PCIe property
  PCI/hotplug: Add GPIO PCIe hotplug driver
  PCI: tegra194: Add support to configure a pluggable slot
  PCI: tegra194: Enable GPIO based Hot-Plug support

 Documentation/devicetree/bindings/pci/pci.txt |   4 +
 drivers/pci/controller/dwc/pcie-tegra194.c    |  85 +++++++-
 drivers/pci/hotplug/Kconfig                   |  11 +
 drivers/pci/hotplug/Makefile                  |   1 +
 drivers/pci/hotplug/gpio_php.c                | 200 ++++++++++++++++++
 drivers/pci/hotplug/gpiophp.h                 |  40 ++++
 6 files changed, 334 insertions(+), 7 deletions(-)
 create mode 100644 drivers/pci/hotplug/gpio_php.c
 create mode 100644 drivers/pci/hotplug/gpiophp.h

Comments

Lukas Wunner Oct. 1, 2022, 4 p.m. UTC | #1
Adding Marek, Pali & Jon to cc as they've worked on somewhat similar
functionality:

https://lore.kernel.org/linux-pci/20220927141926.8895-1-kabel@kernel.org/
https://lore.kernel.org/linux-pci/1581120007-5280-1-git-send-email-jonathan.derrick@intel.com/

On Sat, Oct 01, 2022 at 12:57:43AM +0530, Vidya Sagar wrote:
> To support the Hot-plug feature, PCIe spec has a well-defined model for 
> hardware implementation and software programming interface. There are also
> some architectures/platforms where the Hot-plug feature is implemented in a
> non-standard way and software support for the respective implementations is
> available with the kernel. This patch series attempts to add support for one
> such non-standard way of supporting the Hot-plug feature where a single GPIO
> is used to detect and report the Hot-Plug and Unplug events to the SW.
> The platforms that can use this piece of software need to have GPIO routed
> from the slot to the controller which can indicate the presence/absence of
> the downstream device through its state. This GPIO should also have the
> capability to interrupt the system when the connection/disconnection event
> takes place.
> A GPIO Hot-plug framework is written which looks for a "hotplug-gpios" named
> GPIO entry in the corresponding device-tree entry of the controller and
> registers a hot-pluggable slot with the Hot-plug framework.
> The platform drivers of the PCIe host bridges/root ports can register with the
> aforementioned GPIO Hot-Plug framework along with ops to perform any platform
> specific tasks during Hot-Plug/Unplug events.
> 
> Oza Pawandeep made an attempt to upstream support for a similar Hot-plug
> feature implementation at a platform level, but the implementation as such
> was very specific to that platform (at least the way I understood it).
> https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-2-git-send-email-oza.oza@broadcom.com/
> https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-3-git-send-email-oza.oza@broadcom.com/
> https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-4-git-send-email-oza.oza@broadcom.com/
> This current series also attempts to address that by extracting out all the
> common code to do with GPIO and Hot-plug core framework and expecting the
> platform drivers to only register/unregister with the GPIO framework. So,
> @Oza, could you try using the GPIO framework from this series and enable
> Hot-plug support for your platform if it still makes sense?
> 
> @Rob,
> Regarding the DT documentation change to add about 'hotplug-gpios, I'm not
> sure if pci.txt is the right place or the dt-schema repository
> i.e https://github.com/devicetree-org/dt-schema
> But, in the interest of keeping all the changes related to this feature in the
> the same repository, I made the changes to the pci.txt file in this repo itself.
> Please let me know if the documentation change needs to be moved to the other
> repo.
> 
> The Changes have been tested on the Tegra234 platform.
> 
> Vidya Sagar (4):
>   dt-bindings: Add "hotplug-gpios" PCIe property
>   PCI/hotplug: Add GPIO PCIe hotplug driver
>   PCI: tegra194: Add support to configure a pluggable slot
>   PCI: tegra194: Enable GPIO based Hot-Plug support
> 
>  Documentation/devicetree/bindings/pci/pci.txt |   4 +
>  drivers/pci/controller/dwc/pcie-tegra194.c    |  85 +++++++-
>  drivers/pci/hotplug/Kconfig                   |  11 +
>  drivers/pci/hotplug/Makefile                  |   1 +
>  drivers/pci/hotplug/gpio_php.c                | 200 ++++++++++++++++++
>  drivers/pci/hotplug/gpiophp.h                 |  40 ++++
>  6 files changed, 334 insertions(+), 7 deletions(-)
>  create mode 100644 drivers/pci/hotplug/gpio_php.c
>  create mode 100644 drivers/pci/hotplug/gpiophp.h
> 
> -- 
> 2.17.1
>
Pali Rohár Oct. 1, 2022, 4:20 p.m. UTC | #2
On Saturday 01 October 2022 18:00:25 Lukas Wunner wrote:
> Adding Marek, Pali & Jon to cc as they've worked on somewhat similar
> functionality:
> 
> https://lore.kernel.org/linux-pci/20220927141926.8895-1-kabel@kernel.org/
> https://lore.kernel.org/linux-pci/1581120007-5280-1-git-send-email-jonathan.derrick@intel.com/
> 
> On Sat, Oct 01, 2022 at 12:57:43AM +0530, Vidya Sagar wrote:
> > To support the Hot-plug feature, PCIe spec has a well-defined model for 
> > hardware implementation and software programming interface. There are also
> > some architectures/platforms where the Hot-plug feature is implemented in a
> > non-standard way and software support for the respective implementations is
> > available with the kernel. This patch series attempts to add support for one
> > such non-standard way of supporting the Hot-plug feature where a single GPIO
> > is used to detect and report the Hot-Plug and Unplug events to the SW.
> > The platforms that can use this piece of software need to have GPIO routed
> > from the slot to the controller which can indicate the presence/absence of
> > the downstream device through its state. This GPIO should also have the
> > capability to interrupt the system when the connection/disconnection event
> > takes place.
> > A GPIO Hot-plug framework is written which looks for a "hotplug-gpios" named
> > GPIO entry in the corresponding device-tree entry of the controller and
> > registers a hot-pluggable slot with the Hot-plug framework.
> > The platform drivers of the PCIe host bridges/root ports can register with the
> > aforementioned GPIO Hot-Plug framework along with ops to perform any platform
> > specific tasks during Hot-Plug/Unplug events.
> > 
> > Oza Pawandeep made an attempt to upstream support for a similar Hot-plug
> > feature implementation at a platform level, but the implementation as such
> > was very specific to that platform (at least the way I understood it).
> > https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-2-git-send-email-oza.oza@broadcom.com/
> > https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-3-git-send-email-oza.oza@broadcom.com/
> > https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-4-git-send-email-oza.oza@broadcom.com/
> > This current series also attempts to address that by extracting out all the
> > common code to do with GPIO and Hot-plug core framework and expecting the
> > platform drivers to only register/unregister with the GPIO framework. So,
> > @Oza, could you try using the GPIO framework from this series and enable
> > Hot-plug support for your platform if it still makes sense?

Hello!

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.

Similar thing Marek and me have implemented for PCIe link state events
in patch series with Lukas pointed.

> > @Rob,
> > Regarding the DT documentation change to add about 'hotplug-gpios, I'm not
> > sure if pci.txt is the right place or the dt-schema repository
> > i.e https://github.com/devicetree-org/dt-schema
> > But, in the interest of keeping all the changes related to this feature in the
> > the same repository, I made the changes to the pci.txt file in this repo itself.
> > Please let me know if the documentation change needs to be moved to the other
> > repo.
> > 
> > The Changes have been tested on the Tegra234 platform.
> > 
> > Vidya Sagar (4):
> >   dt-bindings: Add "hotplug-gpios" PCIe property
> >   PCI/hotplug: Add GPIO PCIe hotplug driver
> >   PCI: tegra194: Add support to configure a pluggable slot
> >   PCI: tegra194: Enable GPIO based Hot-Plug support
> > 
> >  Documentation/devicetree/bindings/pci/pci.txt |   4 +
> >  drivers/pci/controller/dwc/pcie-tegra194.c    |  85 +++++++-
> >  drivers/pci/hotplug/Kconfig                   |  11 +
> >  drivers/pci/hotplug/Makefile                  |   1 +
> >  drivers/pci/hotplug/gpio_php.c                | 200 ++++++++++++++++++
> >  drivers/pci/hotplug/gpiophp.h                 |  40 ++++
> >  6 files changed, 334 insertions(+), 7 deletions(-)
> >  create mode 100644 drivers/pci/hotplug/gpio_php.c
> >  create mode 100644 drivers/pci/hotplug/gpiophp.h
> > 
> > -- 
> > 2.17.1
> >
Jonathan Derrick Oct. 1, 2022, 11:50 p.m. UTC | #3
On 10/1/2022 10:20 AM, Pali Rohár wrote:
> On Saturday 01 October 2022 18:00:25 Lukas Wunner wrote:
>> Adding Marek, Pali & Jon to cc as they've worked on somewhat similar
>> functionality:
>>
>> https://lore.kernel.org/linux-pci/20220927141926.8895-1-kabel@kernel.org/
>> https://lore.kernel.org/linux-pci/1581120007-5280-1-git-send-email-jonathan.derrick@intel.com/
>>
>> On Sat, Oct 01, 2022 at 12:57:43AM +0530, Vidya Sagar wrote:
>>> To support the Hot-plug feature, PCIe spec has a well-defined model for
>>> hardware implementation and software programming interface. There are also
>>> some architectures/platforms where the Hot-plug feature is implemented in a
>>> non-standard way and software support for the respective implementations is
>>> available with the kernel. This patch series attempts to add support for one
>>> such non-standard way of supporting the Hot-plug feature where a single GPIO
>>> is used to detect and report the Hot-Plug and Unplug events to the SW.
>>> The platforms that can use this piece of software need to have GPIO routed
>>> from the slot to the controller which can indicate the presence/absence of
>>> the downstream device through its state. This GPIO should also have the
>>> capability to interrupt the system when the connection/disconnection event
>>> takes place.
>>> A GPIO Hot-plug framework is written which looks for a "hotplug-gpios" named
>>> GPIO entry in the corresponding device-tree entry of the controller and
>>> registers a hot-pluggable slot with the Hot-plug framework.
>>> The platform drivers of the PCIe host bridges/root ports can register with the
>>> aforementioned GPIO Hot-Plug framework along with ops to perform any platform
>>> specific tasks during Hot-Plug/Unplug events.
>>>
>>> Oza Pawandeep made an attempt to upstream support for a similar Hot-plug
>>> feature implementation at a platform level, but the implementation as such
>>> was very specific to that platform (at least the way I understood it).
>>> https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-2-git-send-email-oza.oza@broadcom.com/
>>> https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-3-git-send-email-oza.oza@broadcom.com/
>>> https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-4-git-send-email-oza.oza@broadcom.com/
>>> This current series also attempts to address that by extracting out all the
>>> common code to do with GPIO and Hot-plug core framework and expecting the
>>> platform drivers to only register/unregister with the GPIO framework. So,
>>> @Oza, could you try using the GPIO framework from this series and enable
>>> Hot-plug support for your platform if it still makes sense?
> 
> Hello!
> 
> 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/


> 
> Similar thing Marek and me have implemented for PCIe link state events
> in patch series with Lukas pointed.
> 
>>> @Rob,
>>> Regarding the DT documentation change to add about 'hotplug-gpios, I'm not
>>> sure if pci.txt is the right place or the dt-schema repository
>>> i.e https://github.com/devicetree-org/dt-schema
>>> But, in the interest of keeping all the changes related to this feature in the
>>> the same repository, I made the changes to the pci.txt file in this repo itself.
>>> Please let me know if the documentation change needs to be moved to the other
>>> repo.
>>>
>>> The Changes have been tested on the Tegra234 platform.
>>>
>>> Vidya Sagar (4):
>>>    dt-bindings: Add "hotplug-gpios" PCIe property
>>>    PCI/hotplug: Add GPIO PCIe hotplug driver
>>>    PCI: tegra194: Add support to configure a pluggable slot
>>>    PCI: tegra194: Enable GPIO based Hot-Plug support
>>>
>>>   Documentation/devicetree/bindings/pci/pci.txt |   4 +
>>>   drivers/pci/controller/dwc/pcie-tegra194.c    |  85 +++++++-
>>>   drivers/pci/hotplug/Kconfig                   |  11 +
>>>   drivers/pci/hotplug/Makefile                  |   1 +
>>>   drivers/pci/hotplug/gpio_php.c                | 200 ++++++++++++++++++
>>>   drivers/pci/hotplug/gpiophp.h                 |  40 ++++
>>>   6 files changed, 334 insertions(+), 7 deletions(-)
>>>   create mode 100644 drivers/pci/hotplug/gpio_php.c
>>>   create mode 100644 drivers/pci/hotplug/gpiophp.h
>>>
>>> -- 
>>> 2.17.1
>>>
Rob Herring Oct. 3, 2022, 5:04 p.m. UTC | #4
On Sat, Oct 01, 2022 at 12:57:43AM +0530, Vidya Sagar wrote:
> To support the Hot-plug feature, PCIe spec has a well-defined model for 
> hardware implementation and software programming interface. There are also
> some architectures/platforms where the Hot-plug feature is implemented in a
> non-standard way and software support for the respective implementations is
> available with the kernel. This patch series attempts to add support for one
> such non-standard way of supporting the Hot-plug feature where a single GPIO
> is used to detect and report the Hot-Plug and Unplug events to the SW.
> The platforms that can use this piece of software need to have GPIO routed
> from the slot to the controller which can indicate the presence/absence of
> the downstream device through its state. This GPIO should also have the
> capability to interrupt the system when the connection/disconnection event
> takes place.
> A GPIO Hot-plug framework is written which looks for a "hotplug-gpios" named
> GPIO entry in the corresponding device-tree entry of the controller and
> registers a hot-pluggable slot with the Hot-plug framework.
> The platform drivers of the PCIe host bridges/root ports can register with the
> aforementioned GPIO Hot-Plug framework along with ops to perform any platform
> specific tasks during Hot-Plug/Unplug events.
> 
> Oza Pawandeep made an attempt to upstream support for a similar Hot-plug
> feature implementation at a platform level, but the implementation as such
> was very specific to that platform (at least the way I understood it).
> https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-2-git-send-email-oza.oza@broadcom.com/
> https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-3-git-send-email-oza.oza@broadcom.com/
> https://patchwork.kernel.org/project/linux-pci/patch/1504155029-24729-4-git-send-email-oza.oza@broadcom.com/
> This current series also attempts to address that by extracting out all the
> common code to do with GPIO and Hot-plug core framework and expecting the
> platform drivers to only register/unregister with the GPIO framework. So,
> @Oza, could you try using the GPIO framework from this series and enable
> Hot-plug support for your platform if it still makes sense?
> 
> @Rob,
> Regarding the DT documentation change to add about 'hotplug-gpios, I'm not
> sure if pci.txt is the right place or the dt-schema repository
> i.e https://github.com/devicetree-org/dt-schema
> But, in the interest of keeping all the changes related to this feature in the
> the same repository, I made the changes to the pci.txt file in this repo itself.
> Please let me know if the documentation change needs to be moved to the other
> repo.

Nothing should be added to pci.txt. So yes, dt-schema is where this 
needs to end up.

Rob
Bjorn Helgaas Oct. 3, 2022, 6:09 p.m. UTC | #5
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
Pali Rohár Oct. 3, 2022, 6:21 p.m. UTC | #6
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.
Jonathan Derrick Oct. 3, 2022, 7:18 p.m. UTC | #7
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/
Vidya Sagar Oct. 4, 2022, 4:04 a.m. UTC | #8
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@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.
> 

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
Vidya Sagar Oct. 10, 2022, 6:14 a.m. UTC | #9
On 10/4/2022 9:34 AM, Vidya Sagar wrote:
> 
> 
> 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@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.
>>
> 
> 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?

Bjorn / Lorenzo,
Could you please take time to comment on the discussion happened here 
and the right approach to be followed?

Thanks,
Vidya Sagar

> 
> Thanks,
> Vidya Sagar
> 
>
Vidya Sagar Oct. 17, 2022, 2:46 a.m. UTC | #10
On 10/10/2022 11:44 AM, Vidya Sagar wrote:
> 
> 
> On 10/4/2022 9:34 AM, Vidya Sagar wrote:
>>
>>
>> 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@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.
>>>
>>
>> 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?
> 
> Bjorn / Lorenzo,
> Could you please take time to comment on the discussion happened here 
> and the right approach to be followed?

I'm really sorry to bug you on this, but would like to hear your 
comments on the approach to be taken. So, I would really like to hear 
your take on this.

Thanks,
Vidya Sagar

> 
> Thanks,
> Vidya Sagar
> 
>>
>> Thanks,
>> Vidya Sagar
>>
>>
Manivannan Sadhasivam Nov. 9, 2022, 3:35 p.m. UTC | #11
On Mon, Oct 17, 2022 at 08:16:06AM +0530, Vidya Sagar wrote:
> 
> 
> On 10/10/2022 11:44 AM, Vidya Sagar wrote:
> > 
> > 
> > On 10/4/2022 9:34 AM, Vidya Sagar wrote:
> > > 
> > > 
> > > 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@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.
> > > > 
> > > 
> > > 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?
> > 
> > Bjorn / Lorenzo,
> > Could you please take time to comment on the discussion happened here
> > and the right approach to be followed?
> 
> I'm really sorry to bug you on this, but would like to hear your comments on
> the approach to be taken. So, I would really like to hear your take on this.
> 

Since Bjorn already expressed his good will about the approach, I think you
can just proceed with the emulation layer. I don't think there will be any
controversy.

Thanks,
Mani

> Thanks,
> Vidya Sagar
> 
> > 
> > Thanks,
> > Vidya Sagar
> > 
> > > 
> > > Thanks,
> > > Vidya Sagar
> > > 
> > >