Hi!
> What did seem to be missing was anything saying whether
> those device methods would be called in_interrupt() or
> whether instead they could sleep. I'd hope all of them
> would be specified to allow blocking as needed, like their
> current analogues in PCI and USB.
Look better, it was there.
> Also, there was some mention not that long ago about
> desirability of some kind of device abort() call. That
> would differ from the current remove() call because an
> abort() would pass the explicit knowledge that hardware
> was gone ... unplugged before driver shutdown, for one
> example. That could also be achieved using some kind
> of mode parameter to remove() -- perhaps three values,
> saying whether the hardware was present, removed, or
> in some indeterminate state.
I'd prefer parameter to remove...
Your hardware may die physically, and driver should try to be able to
remove() even if hardware dies.
Pavel
--
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
_______________________________________________________________
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
