Lines Matching refs:we

192 So let's say we connect a dongle to the system: it is detected and
195 Now we have a real HWA device connected and
214 So assuming we have devices and we have agreed for a channel to connect
215 on (let's say 9), we put the new RC to beacon:
283 ID and tell the HC to use all that. Then we start it. This means the HC
309 the device. First we allocate a /fake port/ and assign an
310 unauthenticated address (128 to 255--what we really do is
314 So now we are in the reset path -- we know we have a non-yet enumerated
315 device with an unauthorized address; we ask user space to authenticate
316 (FIXME: not yet done, similar to bluetooth pairing), then we do the key
321 has seen the port status changes, as we have been toggling them. It will
327 Every time there is a successful transfer to/from a device, we update a
328 per-device activity timestamp. If not, every now and then we check and
329 if the activity timestamp gets old, we ping the device by sending it a
332 devconnect.c:wusb_handle_dn_alive(). If a device times out, we
351 prepared (buffers assigned), then we can start queueing requests for
354 Data buffers have to be segmented out before sending--so we send first a
357 buffer is bigger than the max segment size, then we just do multiple
364 If reading, we don't send data buffers, just the segment headers saying
365 we want to read segments.
367 When the xfer is executed, we receive a notification that says data is
369 xfer.c:wa_handle_notif_xfer()). In there we read from the DTI endpoint a
371 (given when we issued it) and the segment number. If it was a data read,
372 we issue another URB to read into the destination buffer the chunk of
389 one of buffer URB. When submitting, we submit URBs for segment request
390 1, buffer 1, segment 2, buffer 2...etc. Then we wait on the DTI for xfer
391 result data; when all the segments are complete, we call the callback to
394 For IN xfers, we only issue URBs for the segments we want to read and
399 This is done by hwahc_op_urb_[en|de]queue(). In enqueue() we aim an
400 rpipe to the endpoint where we have to transmit, create a transfer
402 called and we assign the status bits and release the xfer resources.
404 In dequeue() we are basically cancelling/aborting the transfer. We issue
405 a xfer abort request to the HC, cancel all the URBs we had submitted