On Monday 27 September 2004 8:51 am, Alan Stern wrote: > On Sun, 26 Sep 2004, David Brownell wrote: > > > ... if the BIOS took the hardware over > > in the first place -- it would have had to reset USB, to talk even to > > just one USB device. ALSO ... non-buggy BIOS should also notice > > when it comes up but USB is owned by the OS. So there may > > well be no basic problems there, beyond bugs. > > The trick will be determining how buggy the BIOS is
I don't think there are options outside of "it resumes correctly and leaves USB alone" or (buggy) "it resets USB". > > > But what about HCDs that are linked into the boot kernel? During the > > > resume-from-disk bootup ... > > > > OHCI is certainly set up to avoid extra resets, but I don't > > expect all the other parts of system resume behave yet. > > But hci-pci.c calls the driver's reset() in usb_hcd_pci_probe() -- how > does OHCI avoid doing that reset? And that reset() method may be a bit misnamed. The "reset" is just to get it into a known state, which doesn't need to involve chip or USB reset. I don't think either OHCI nor EHCI will do a USB reset... > Well, USB selective suspend now supports putting devices into the USB > suspend state. It could also support turning off Vbus power entirely > (without destroying the struct usb_device -- a true power-off selective > suspend). No, that's a nonsense state for USB ... unless someone creates lots of infrastructure to remember the devices that were present. That got ripped out of usb-storage (on request from Linus, ISTR)... > A related variant would be a reset-suspend. That is, drivers are warned > that the device is going to be unavailable for a brief time because it > will be reset, but Vbus power won't be lost. It's very similar to > power-off selective suspend in that some (but not all) device state will > be lost, and it could be used for notifying drivers when a multi-interface > device is reset. > > Come to think of it, something came up recently that applies here: a > suggestion to add an option to usb_reset_device() for performing a > power-off reset. That goes well with your earlier suggestion for adding a > power-off option to the logical_disconnect() routine. I intended that "power off" to get rid of all the USB state. It'd only need to be re-validated afterwards, and that's a messy (and error prone) game to start playing. - Dave ------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
