Re: [RFC][PATCH 5/10] PCI PM: Avoid touching devices behind bridges in unknown state (rev. 2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday 05 January 2009, Pavel Machek wrote:
> Hi!
> 
> > Subject: PCI PM: Avoid touching devices behind bridges in unknown state (rev. 2)
> > From: Rafael J. Wysocki <rjw@xxxxxxx>
> > 
> > It generally is better to avoid accessing devices behind bridges that
> > may not be in the D0 power state, because in that case the bridges'
> > secondary buses may not be accessible.  For this reason, during the
> > early phase of resume (ie. with interrupts disabled), before
> > restoring the standard config registers of a device, check the power
> > state of the bridge the device is behind and postpone the restoration
> > of the device's config space, as well as any other operations that
> > would involve accessing the device, if that state is not D0.
> 
> I'm not sure if this is good idea.
> 
> Either pci config space needs to be restored early, or it can wait.
> 
> Sometimes restoring it early and sometimes restoring it late seems
> harmful: it will make code harder to understand and harder to test.

Unfortunately, we need to restore it early at least for some devices (bridges
and PCI Express ports) and I don't think it is generally safe to go and restore
it early for every device (as explained in this changelog).

> > In such cases the restoration of the device's config space will be
> > retried during the "normal" phase of resume (ie. with interrupts
> > enabled), so that the bridge can be put into D0 before that happens.
> 
> If drivers have to assume it is restored late, anyway... why not do it
> late, always?

Because it breaks.

Thanks,
Rafael
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/linux-pm

[Index of Archives]     [Linux ACPI]     [Netdev]     [Ethernet Bridging]     [Linux Wireless]     [CPU Freq]     [Kernel Newbies]     [Fedora Kernel]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux