On Wednesday, February 16, 2011, Alan Stern wrote: > On Wed, 16 Feb 2011, Rafael J. Wysocki wrote: > > > On Wednesday, February 16, 2011, Alan Stern wrote: > > > On Wed, 16 Feb 2011, Rafael J. Wysocki wrote: > > > > > > > Unfortunately, it doesn't work on my Acer Ferrari One. The problem is that > > > > hcd_pci_suspend() fails for the EHCI controller, apparently because the root > > > > hub is not suspended. Do root hubs need both class suspend and bus type > > > > suspend to work at the same time? > > > > > > No, only the bus type suspend method is needed. > > > > Bus type or device type? It appears to be the latter from reading the code > > (although admittedly not too thorough). > > You're right. I forgot about how the PM methods were split up. :-( > > > > Can you provide the dmesg log using a kernel built with CONFIG_USB_DEBUG? > > > > Well, I know what the problem is. > > > > USB defines usb_device_type pointing to usb_device_pm_ops that provides > > system-wide PM callbacks only and usb_bus_type pointing to > > usb_bus_pm_ops that provides runtime PM callbacks only. So it looks like > > we should move either the system-wide PM callbacks to usb_bus_pm_ops, > > or the runtime PM callbacks to usb_device_pm_ops. > > Yes. IIRC, I did it that way so that the runtime PM routines could be > static. Making them non-static isn't a big deal, though. > > > FWIW, the appended patch helps on my test machine, but I'm not sure if it > > is the right thing to do. > > It is. Except that the inline stubs aren't needed for anything; they > don't have to be added to usb.h. OK, I'll remove them, add a changelog and repost. > > Apart from this I think the order of checks introduced by the $subject patch > > should be: > > (1) If dev->class != NULL and dev->class->pm != NULL, use dev->class, > > or otherwise > > (2) if dev->type != NULL and dev->type->pm != NULL, use dev->type, > > or otherwise > > (3) use dev->bus (if present). > > as that would allow classes and device types to override bus type PM > > callbacks if they wish to. > > I haven't heard of any device types being present on more than one kind > of bus, so it makes sense for device types to override bus types. OK > But I'm not so sure about the priority we should give to classes. On the > other hand, if no classes define a dev_pm_ops then of course it doesn't > matter. The change will also affect classes that provide "legacy" suspend-resume (if there are any, which I'm totally unsure of). Anyway, I think we need to choose one ordering. :-) What about type / bus / class , then? Rafael _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
