On Fri, Feb 09, 2024 at 10:04:33AM +0100, Lukas Wunner wrote: > On Wed, Feb 07, 2024 at 05:26:16PM +0100, Bartosz Golaszewski wrote: > > On Fri, Feb 2, 2024 at 5:52???PM Bjorn Andersson <andersson@xxxxxxxxxx> wrote: > > > On Fri, Feb 02, 2024 at 10:11:42AM +0100, Bartosz Golaszewski wrote: > > > > I was also thinking about pci_pwrctl_device_ready() or > > > > pci_pwrctl_device_prepared(). > > > > > > I like both of these. > > > > > > I guess the bigger question is how the flow would look like in the event > > > that we need to power-cycle the attached PCIe device, e.g. because > > > firmware has gotten into a really bad state. > > > > > > Will we need an operation that removes the device first, and then cut > > > the power, or do we cut the power and then call unprepared()? > > > > How would the core be notified about this power-cycle from the PCI > > subsystem? I honestly don't know. Is there a notifier we could > > subscribe to? Is the device unbound and rebound in such case? > > To power-manage the PCI device for runtime PM (suspend to D3cold) > or system sleep, you need to amend: > > platform_pci_power_manageable() > platform_pci_set_power_state() > platform_pci_get_power_state() > platform_pci_refresh_power_state() > platform_pci_choose_state() > > E.g. platform_pci_power_manageable() would check for presence of a > regulator in the DT and platform_pci_set_power_state() would disable > or enable the regulator. > This will work if the sole control of the resources lies in these platform_*() APIs. But in reality, the controller drivers are the ones controlling the power supply to the devices and with this series, the control would be shifted partly to pwrctl driver. I think what we need is to call in the callbacks of the drivers in a hierarchial order. - Mani > To reset the device by power cycling it, amend pci_reset_fn_methods[] > to provide a reset method which disables and re-enables the regulator. > Then you can choose that reset method via sysfs and power-cycle the > device. The PCI core will also automatically use that reset method > if there's nothing else available (e.g. if no Secondary Bus Reset > is available because the device has siblings or children, or if FLR > is not supported). > > Thanks, > > Lukas -- மணிவண்ணன் சதாசிவம்
