On Wed, Jan 17, 2024 at 10:08 AM Bartosz Golaszewski <brgl@xxxxxxxx> wrote: > > From: Bartosz Golaszewski <bartosz.golaszewski@xxxxxxxxxx> > > The responses to the RFC were rather positive so here's a proper series. Thanks for tackling this. > During last year's Linux Plumbers we had several discussions centered > around the need to power-on PCI devices before they can be detected on > the bus. > > The consensus during the conference was that we need to introduce a > class of "PCI slot drivers" that would handle the power-sequencing. > > After some additional brain-storming with Manivannan and the realization > that DT maintainers won't like adding any "fake" nodes not representing > actual devices, we decided to reuse existing PCI infrastructure. Thank you. :) > The general idea is to instantiate platform devices for child nodes of > the PCIe port DT node. For those nodes for which a power-sequencing > driver exists, we bind it and let it probe. The driver then triggers a > rescan of the PCI bus with the aim of detecting the now powered-on > device. The device will consume the same DT node as the platform, > power-sequencing device. We use device links to make the latter become > the parent of the former. > > The main advantage of this approach is not modifying the existing DT in > any way and especially not adding any "fake" platform devices. Suspend/resume has been brought up already, but I disagree we can worry about that later unless there is and always will be no power sequencing during suspend/resume for all devices ever. Given the supplies aren't standard, it wouldn't surprise me if standard PCI power management isn't either. The primary issue I see with this design is we will end up with 2 drivers doing the same power sequencing: the platform driver for initial power on and the device's PCI driver for suspend/resume. Rob
