[linux-pm] [patch 2.6.25-rc6 3/7] pci_choose_state() cleanup and fixes
David Brownell
david-b at pacbell.net
Sat Mar 22 10:55:12 PDT 2008
On Friday 21 March 2008, Rafael J. Wysocki wrote:
> >
> > You seem to object to letting drivers offload this particular
> > bit of work to infrastructure.
>
> No, I don't. I just don't think it's a good idea to change the existing and
> widely used function for this purpose. If I needed some specific functionality
> at the infrastructure level, I'd add a new function for that with a new
> changelog etc. Then, made drivers switch to that and remove the old one.
I see that a lot of drivers have at some point, not long ago,
been converted to use this routine. They previously just
used PCI_D3 in all cases.
It seems to me that your objection boils down to the concern
that those drivers may just have pushed their bug out a level,
rather than actually fixing their bugs.
Which I can sympathize with ... but that doesn't change the
fact that any driver in that position *still* has a bug that
needs to be fixed. And if that bug is highlighted by this
patch ... well, there's still a driver bug to be fixed.
> > > [Note that with the new suspend/hibernation callbacks there
> > > won't be the pm_message_t argument to pass to pci_choose_state().]
> >
> > The pm_message_t will necessarily linger until all drivers have
> > been converted and re-tested. Which can't be an overnight thing.
>
> No, it can't. Still, suppose a driver is using the new callbacks. How is
> it supposed to use pci_choose_state()?
Hey, you're the one providing those callbacks. How were you
going to answer that question *before* I posted this overdue
bugfix patch for pci_choose_state()?
- Dave
More information about the linux-pm
mailing list