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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
