[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-smartcardddk
Subject:    Re: Oggetto: Re: USB and hibernation
From:       "Doron Holan (Exchange)" <doronh () EXCHANGE ! MICROSOFT ! COM>
Date:       1999-11-30 23:46:56
[Download RAW message or body]


if all else fails, re-select your config / interfaces (ie, run whatever code
you have in IRP_MN_START_DEVICE for setting up the config / interface) when
you come out of low power.  If you send a select config URB with a NULL
ConfigDescriptor, that will clear out the current configuration; but you
don't need to send this down the stack before selecting your new config
though.  After reconfiguring your device, restart all of your I/O.

doron

-----Original Message-----
From: Zambelli Giampietro [mailto:gzambelli@EUTRON.IT]
Sent: Tuesday, November 30, 1999 7:12 AM
To: SmartCardDDK@DISCUSS.MICROSOFT.COM
Subject: Oggetto: Re: USB and hibernation


Mr. Dolon Horan,

> when you receive your power down request (ie to go to D3), you must cancel
> all pending I/O on all pipes before sending down the power irp.  upon
> receiving the D0 irp, you send it down the pnp stack, and on the way back
up
> (either in a completion routine or by waiting for it by setting an event
in
> the completion routine), you restart all your cancelled I/O.  This is
fully
> demonstrated in all the USB examples in the win2k DDK.

I'm sorry but if you refer to bulkusb and isousb samples, nothing of what
you
say is implemented as result of a power down or power up request.

I saw instead a similar behavior in PNP STOP, REMOVE and SURPRISE_REMOVE irp
handling ( I mean BulkUsb_CancelPendingIo() and BulkUsb_AbortPipes() ) that
I
never receive in response to an hibernation.

However, as you suggested, I implemented similar routines and when receiving
an IRP_MN_SET_POWER<Device Power State> for state D3, I successfully cancel
the
pending irps and cancel any pending transfers for the used pipe.
Resuming from hibernation, in the completion routine associated with the irp
IRP_MN_SET_POWER<Device Power State> for state D0 I restart my async
interrupt
based I/O mechanism, by issuing the irp that waits for an interrupt from the
USB
channel.

Result :
After resuming Read and Write operation to/from USB channel wait for an
answer that never comes (as in my previous attempts).
Everything re-start running if unplugging and re-plugging the USB device
(re-executing the AddDevice procedure + Pnp start and so on)

We saw that USB address is never refreshed by the system after resuming from
hibernation, and our USB device doesn't record (after the power off) the USB
address previously assigned by the system. Are we due to record this address
?
How can our device communicate with the O.S without a valid address ?

Thank you very much for any kind of further support.
Giampietro



[prev in list] [next in list] [prev in thread] [next in thread]