On Monday 20 September 2004 12:28 pm, Alan Stern wrote: > > For some unknown reason the rule seems to be that transitions are allowed > between fully-powered and any of the low-power states, but not between > different low-power states. This seems like a mistake; the PM core > shouldn't make any such assumptions about the capabilities of different > devices. If some device can't make these transitions, its driver should > interpolate the intermediate power-on state automatically or should inform > the PM core somehow.
Some basic rules need to exist, but the current one is annoying even for PCI. Given numbers, I think "only goes up, or to zero" is an OK policy, with the advantage that it's what PCI does. > Looking more at the USB code, I found some rhyme & reason behind the > behavior. Power state levels are sent to the interface drivers, but for > the whole usb_devices they aren't sent (because USB only defines two power > levels, on or suspended). There's also "power off" (ACPI D3), but until that's supported usbcore only has analogues of ACPI D0 (on) and D2 (low power suspend) for devices. No matter what the "upper" level code asks for, that's all that'll work. > That brings up another question: Why do we have all these > suspend()/resume() pairs? Why not just a single set_power() routine, that > takes the desired new power level as an argument and maybe also a flag > stating whether the actual new power level must be <=, ==, or >= the > desired level? Is this historical baggage? I think history and training are about right. I don't see a reason to try changing how people think about those actions; the code paths are pretty different, and it's cheap to show that in the APIs. > > Oh yes, and there's also the fact that the PM core currently insists > > there be a flat namespace of state numbers. As Linus has observed, > > given that assumption, and the number of PM-aware drivers in Linux, > > there is only one suitable answer: the numbers must match what > > PCI uses. Yet it doesn't. (See OSDL bugid 2886.) > > To fix these problems will require getting a consensus among a reasonably > large number of people. Do you know of anyone actively working on it? On that particular issue? Not any more; my question is who will merge the patch to fixes that issue! Maybe it'll be part of a short set of updates to make USB_SUSPEND behave OK with swsusp. (It was in the bunch I just sent.) - Dave ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
