lkml.org 
[lkml]   [2018]   [Feb]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] PCI: Add quirk for Cavium Thunder-X2 PCIe erratum #173
On Mon, Feb 19, 2018 at 12:21:56PM +0100, Rafael J. Wysocki wrote:
> On Friday, February 16, 2018 9:34:34 PM CET Bjorn Helgaas wrote:
> > On Fri, Feb 16, 2018 at 01:40:37PM +0100, Rafael J. Wysocki wrote:
> > > On Friday, February 16, 2018 12:39:00 AM CET Bjorn Helgaas wrote:
> > > > On Thu, Feb 15, 2018 at 10:57:25PM +0100, Rafael J. Wysocki wrote:
> > > > > On Wednesday, February 14, 2018 9:16:53 PM CET Bjorn Helgaas wrote:
> > > > > > I don't know how this runtime PM works, but maybe Rafael can help
> > > > > > us out.

This has nothing to do with runtime PM AFAICS.

The device seems to be in D3hot on boot, is that correct?
The PCI core assumes that unbound devices remain in D0
(see comments in pci_pm_runtime_resume() / pci_pm_runtime_suspend()).


> > > > > I'm not sure what the question is to be honest.
> > > >
> > > > My questions are basically "What does the PCI core need to do to make
> > > > sure a device is in D0 before it operates on it? And where do we need
> > > > to do that?"

When scanning the bus and discovering the device is not in D0,
call pci_power_up(). This could probably go into pci_init_pm().
Once a driver binds to it, it may choose to runtime suspend it to
D3hot again.

Just an idea anyway.

Thanks,

Lukas

\
 
 \ /
  Last update: 2018-02-20 02:55    [W:0.176 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site