Am Mittwoch, 5. Juni 2002 16:35 schrieb David Brownell:
> Oliver Neukum wrote:
> > Am Mittwoch, 5. Juni 2002 01:46 schrieb David Brownell:
> >>> http://marc.theaimsgroup.com/?l=linux-kernel&m=102320879912115&w=2
> >>> http://marc.theaimsgroup.com/?l=linux-kernel&m=102320879912113&w=2
> >>> http://marc.theaimsgroup.com/?l=linux-kernel&m=102320879912119&w=2
> >>
> >>By the way, this suggests that USB devices should have two new
> >>optional methods in struct usb_driver:
> >>
> >> int (*suspend) (struct usb_device *dev, u32 state, u32 level);
> >> int (*resume) (struct usb_device *dev, u32 level);
> >>
> >>Currently calls of those names are there, commented out (no
> >>infrastructure), and with slightly different syntax (state/level stuff
> >>unresolved).
> >
> > That sounds reasonable. If you want them optional, you need
> > some reasonable defaults.
>
> Today's defaults are that neither method exists, so both are
> presumed to succeed. Trying to change that would make trouble.
They are ignored. So any device is assumed to retain state, although
it hasn't. I suspect that only the device reconnection hack in the
storage driver has saved us from tons of mail about data loss on
resumption.
The straightforward things would be to tell the generic layer that
the device wasn't restored and should be treated as new.
> >>Seems to me that upcoming USB patches ought to
> >>
> >>(a) add those two calls
> >>(b) add usbcore glue to turn struct device suspend/resume
> >> calls into ones made on usb device drivers
> >>(c) teach at least the "hub" driver what to do there ... like
> >> for starters, suspend should disconnect devices when the
> >> power rules mean they won't be suspending.
> >
> > No, no, no. You walk the subtree below the pivotal hub
> > and tell all devices to suspend into the off state.
>
> No, generic device tree code does that. Though it's not yet
> clear to me how that should map to USB ... the multi-level
> suspend() levels need to accomodate some top-down constraints
> from USB hubs that aren't going to be able to maintain power
> over suspend, but I only noticed a bottom-up model there.
Yes. Can't we just fail at that hub if we are told to go into a state
we can't ?
What determines which power saving states are known to the generic layer ?
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
