On Thu, Feb 08, 2024 at 05:02:01PM +0530, Manivannan Sadhasivam wrote: > On Fri, Feb 02, 2024 at 10:52:11AM -0600, Bjorn Andersson wrote: > > On Fri, Feb 02, 2024 at 10:11:42AM +0100, Bartosz Golaszewski wrote: > > > On Fri, Feb 2, 2024 at 4:53 AM Bjorn Andersson <andersson@xxxxxxxxxx> wrote: > > [..] > > > > > + break; > > > > > + } > > > > > + > > > > > + return NOTIFY_DONE; > > > > > +} > > > > > + > > > > > +int pci_pwrctl_device_enable(struct pci_pwrctl *pwrctl) > > > > > > > > This function doesn't really "enable the device", looking at the example > > > > driver it's rather "device_enabled" than "device_enable"... > > > > > > > > > > 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()? > > > > Currently, we don't power cycle while resetting the devices. Most of the drivers > just do a software reset using some register writes. Part of the reason for > that is, the drivers themselves don't control the power to the devices and there > would be no way to let the parent know about the firmware crash. > I don't know what the appropriate design for this is, but we do have a need for being able to recover from this state by the means of power-cycling the device. If it's not possible to let the device do it (in any fashion), then perhaps a user-space-assisted model is needed? Turning on power is an important first step, but please do consider the full scope of the known problem space. Regards, Bjorn
