On Wed, Mar 20, 2002, Maksim Krasnyanskiy <[EMAIL PROTECTED]> wrote:
>
> > > I meant any part of USB core. Whoever calls disconnect
> > > could potentially tell HCD to cancel all requests on this device.
> >
> >The "potential" is that substantial (b) rework.
> Ok. I'll give it more thinking and m
> > I meant any part of USB core. Whoever calls disconnect
> > could potentially tell HCD to cancel all requests on this device.
>
>The "potential" is that substantial (b) rework.
Ok. I'll give it more thinking and may be propose something later. Gotta
study USB code a bit more :).
Just to give
On Sun, Mar 17, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > There is one small problem with uhci.c (patch appended) where it checks
> > urb->status after the completion handler. It should only do this if it's
> > an auto resubmitting interrupt URB, but we always checked it.
> >
> > Other
On Sun, Mar 17, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > Also it's not clear whether completion handler can free urb or not.
> > > > usb-uhci and usb-ohci don't seem to use
> > > > urb after calling completion handler (except interrupt and ring transfers
> > > > where you obviosly m
> > >Not entirely true. OHCI tries to safeguard against broken drivers,
> > >and in 2.5 anything using the new HCD code in usbcore does the
> > >same safeguarding. (Such as EHCI ...) The UHCI drivers may do
> > >things differently.
> >
> > Actually I would not call it broken driver. I think it
On Friday 15 March 2002 23:04, Maksim Krasnyanskiy wrote:
> > > Is it valid to assume that if disconnect method is running completion
> > > handler for bulk transfers will be called _only_ as a result of
> >
> > usb_unlink_urb ?
> >
> > > assuming that urb doesn't have a timeout of course.
> >
> >
> > Is it valid to assume that if disconnect method is running completion
> > handler for bulk transfers will be called _only_ as a result of
> usb_unlink_urb ?
> > assuming that urb doesn't have a timeout of course.
>
>No, this is not the case.
>The only guarantee you have to make. On return fr
> > HCD and USB core do not unlink URBs on device disconnect because currently
> > it is driver's responsibility.
>
>Not entirely true. OHCI tries to safeguard against broken drivers,
>and in 2.5 anything using the new HCD code in usbcore does the
>same safeguarding. (Such as EHCI ...) The UHC
On Fri, Mar 15, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > HCD and USB core do not unlink URBs on device disconnect because currently
> > > > it is driver's responsibility.
> > >
> > > Not entirely true. OHCI tries to safeguard against broken drivers,
> > > and in 2.5 anything usin
> Is it valid to assume that if disconnect method is running completion
> handler for bulk transfers will be called
> _only_ as a result of usb_unlink_urb ? assuming that urb doesn't have a
> timeout of course.
No, this is not the case.
The only guarantee you have to make. On return from disconn
On Fri, Mar 15, 2002, David Brownell <[EMAIL PROTECTED]> wrote:
> Maksim Krasnyanskiy <[EMAIL PROTECTED]> asks:
>
> > HCD and USB core do not unlink URBs on device disconnect because currently
> > it is driver's responsibility.
>
> Not entirely true. OHCI tries to safeguard against broken driv
> > btw What will happen if unlink_urb is called while completion handler is
> > running ?
>
>An error code will be returned.
Good.
One more question.
HCD and USB core do not unlink URBs on device disconnect because currently
it is driver's responsibility.
Is it valid to assume that if disconne
> Take a look here
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bluez/kernel/drivers/hci_usb
>.c?rev=1.1.1.1&content-type=text/vnd.viewcvs-markup hci_usb_unlink_urbs does
> unlinking on disconnect.
> hci_usb_tx_complete is a completion handler for bulk out transfers.
> I don't have to hold qu
> > Sure. I meant that control transaction has not completed.
> > It doesn't make sense to start new transfer before acknowledging current
> > one. Or does it ?
>
>Somebody in the device firmware has exchanged two lines.
>You have to deal with it. The world is unfair :-)
Yeah. I found a work arou
On Thursday 14 March 2002 01:39, Maksim Krasnyanskiy wrote:
> > > Which doesn't make sense to me. I mean how can device send an event if
> > > it didn't yet receive a command.
> > > I'm not sure who's bug is it and is it a bug at all :)
> >
> >Probably the device _has_ gotten the command. It just
> > Which doesn't make sense to me. I mean how can device send an event if it
> > didn't yet receive a command.
> > I'm not sure who's bug is it and is it a bug at all :)
>
>Probably the device _has_ gotten the command. It just has not yet
>acknowledged.
Sure. I meant that control transaction ha
16 matches
Mail list logo
