On Tue, Oct 21, 2025 at 2:53 PM Manivannan Sadhasivam <[email protected]> wrote: > > On Tue, Oct 21, 2025 at 02:22:46PM +0200, Bartosz Golaszewski wrote: > > On Tue, Oct 21, 2025 at 2:20 PM Manivannan Sadhasivam <[email protected]> > > wrote: > > > > > > > > > > > And with the implementation this series proposes it would mean that > > > > the perst signal will go high after the first endpoint pwrctl driver > > > > sets it to high and only go down once the last driver sets it to low. > > > > The only thing I'm not sure about is the synchronization between the > > > > endpoints - how do we wait for all of them to be powered-up before > > > > calling the last gpiod_set_value()? > > > > > > > > > > That will be handled by the pwrctrl core. Not today, but in the coming > > > days. > > > > > > > But is this the right approach or are you doing it this way *because* > > there's no support for enable-counted GPIOs as of yet? > > > > This is the right approach since as of today, pwrctrl core scans the bus, > tries > to probe the pwrctrl driver (if one exists for the device to be scanned), > powers > it ON, and deasserts the PERST#. If the device is a PCI bridge/switch, then > the > devices underneath the downstream bus will only be powered ON after the > further > rescan of the downstream bus. But the pwrctrl drivers for those devices might > get loaded at any time (even after the bus rescan). > > This causes several issues with the PCI core as this behavior sort of emulates > the PCI hot-plug (devices showing up at random times after bus scan). If the > upstream PCI bridge/switch is not hot-plug capable, then the devices that were > showing up later will fail to enumerate due to lack of resources. The failure > is due to PCI core limiting the resources for non hot-plug PCI bridges as it > doesn't expect the devices to show up later in the downstream port. > > One way to fix this issue is by making sure all the pwrctrl capable devices > underneath a PCI bridge getting probed, powered ON, and finally deasserting > the > PERST# for each one of them. If the PERST# happens to be shared, it will be > deasserted once at the last. And this order has to be ensured by the pwrctrl > core irrespective of the shared PERST#. >
Ok, makes sense. In that case this series probably doesn't affect your work or PCI in general. Bartosz
