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@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.
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
