> > > I agree. That's why people are still working on the power
> > > management system :)
> >
> > Well, time is not infinite. I doubt the work'll be finished soon
> > enough.
>
> Heh, pessimist :)
Yes, I admit it :-)
> > > > The devices are simply assumed to switch from suspended to working
> > > > in kernel space. Suspended may mean off here.
> > >
> > > If "suspended" means off, then the device should start up in the
> > > powered off state, and re-enumerate as a new usb device on powerup.
> >
> > That exactly you cannot do. The result is file system corruption,
> > interfaces assigned wrong adresses, cameras being switched.
> > You need to retain device<->node correspondences.
>
> Ok, let's state this right now then:
> If you have a USB device that needs firmware downloaded to it
> in order to work properly, do NOT mount any filesystems on that
> type of device and expect software suspend to work properly. In
> fact, do not expect software suspend to work properly at all
> with these types of devices, and remove them before enabling
> software suspend.
>
> Is that acceptable?
Nope. I happen to have one ;-).
I can make it work, provided I keep the firmware in kernel space.
It's no principal problem. It's just ugly.
And the problem is not limited to devices with firmware.
If you have two USB disks, sda must remain sda and not
interchange with sdb after resumption, even if sdb would be reenumerated
later than sda. To do that you need to reidentify devices after resumption,
you cannot equate suspension with disconnection and resumption
with reenumeration.
This applies to all drivers which work with more than one device of a kind.
For disks the results are just more drastic, being two very dead
filesystems.
> Does any other operating systems handle this any better?
How am I suposed to know. Do you imply that I use other
operating systems ;-) ?
> > > If you _have_ to handle this today, then just leave the firmware
> > > within the kernel driver, like all of the usb-serial devices have
> > > done :)
> > >
> > > If you wait a while, the rest of the power management sections of
> > > the kernel will hopefully come together, allowing the various states
> > > of shutdown to work properly, and be enumerated by _userspace_
> > > tools.
> >
> > Shutdown I don't worry about, resumption is anothere matter.
>
> Resumption is part of the userspace solution too.
Which makes me wonder whether you are designing a really
complicated monster. Some kind of resumptionramdisk ?
Regards
Oliver
_______________________________________________________________
Don't miss the 2002 Sprint PCS Application Developer's Conference
August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
