Am Sonntag, 12. Januar 2003 14:01 schrieb Wolfgang Mües:
> Hello Oliver,
>
> On Sunday 12 January 2003 13:18, Oliver Neukum wrote:
> > OK, if we are to do this let's do it right and divorce state from
> > error reporting.
> > As far as I can tell an URB should have four states, with preliminary
> >
Hello Oliver,
On Sunday 12 January 2003 13:18, Oliver Neukum wrote:
> OK, if we are to do this let's do it right and divorce state from
> error reporting.
> As far as I can tell an URB should have four states, with preliminary
> names:
>
> 1 - URB_FREE
> 2 - URB_SUBMITTED
> 3 - URB_COMPLETING
> 4
Am Sonntag, 12. Januar 2003 09:11 schrieb Greg KH:
> On Sat, Jan 11, 2003 at 11:39:55AM +0100, Oliver Neukum wrote:
> > Currently there's no way to tell an urb executing its completion handler
> > from a finished urb. So we wouldn't have to poll, but could wake the task
> > doing the unlink from us
On Sat, Jan 11, 2003 at 11:39:55AM +0100, Oliver Neukum wrote:
> Currently there's no way to tell an urb executing its completion handler
> from a finished urb. So we wouldn't have to poll, but could wake the task
> doing the unlink from usb_hcd_giveback_urb(). In fact we'd have to.
Then why don't
> > - For a successful synchronous unlink, the completion handler did fire
> >before the unlink call returned. Easily proven for HCDs that go
> > through the "hcd.c" logic (*), otherwise you have to take it on faith.
> > (And some older HCD code might bugs here, like not reporting
> > complet
On Saturday 11 January 2003 00:32, David Brownell wrote:
> Oliver Neukum wrote:
> > Am Freitag, 10. Januar 2003 22:16 schrieb Duncan Sands:
> >>Hi Oliver, I decided to see how other drivers deal with this
> >> usb_unlink_urb issue. The first thing I looked was devio.c. And guess
> >> what, it loo
Oliver Neukum wrote:
Now for something related.
From usb_submit_urb():
if (!(op = dev->bus->op) || !op->submit_urb)
return -ENODEV;
urb->status = -EINPROGRESS;
<--- here begins the window
urb->actual_length = 0;
urb->bandwidth = 0;
What happens if usb_unlink_urb() is called right th
> Unlinking is tricky, and my understanding of the current rules are:
>
> - For a successful synchronous unlink, the completion handler did fire
>before the unlink call returned. Easily proven for HCDs that go through
>the "hcd.c" logic (*), otherwise you have to take it on faith. (And
>
Am Samstag, 11. Januar 2003 00:02 schrieb Greg KH:
> On Fri, Jan 10, 2003 at 11:10:58PM +0100, Oliver Neukum wrote:
> > That are good, or bad depending on viewpoint.
> > IIRC we had this discussion already, possibly several times. Has the
> > general consensus changed ? It seems that the old object
Oliver Neukum wrote:
Am Freitag, 10. Januar 2003 22:16 schrieb Duncan Sands:
Hi Oliver, I decided to see how other drivers deal with this usb_unlink_urb
issue. The first thing I looked was devio.c. And guess what, it looks
like it assumes that the completion handler has completed by the time
u
On Fri, Jan 10, 2003 at 11:10:58PM +0100, Oliver Neukum wrote:
>
> That are good, or bad depending on viewpoint.
> IIRC we had this discussion already, possibly several times. Has the general
> consensus changed ? It seems that the old objections about freeing the
> URB from the completion handler
Am Freitag, 10. Januar 2003 22:16 schrieb Duncan Sands:
> Hi Oliver, I decided to see how other drivers deal with this usb_unlink_urb
> issue. The first thing I looked was devio.c. And guess what, it looks
> like it assumes that the completion handler has completed by the time
> usb_unlink_urb fi
Hi Oliver, I decided to see how other drivers deal with this usb_unlink_urb
issue. The first thing I looked was devio.c. And guess what, it looks like
it assumes that the completion handler has completed by the time
usb_unlink_urb finishes:
static void destroy_async (struct dev_state *ps, struct
On Friday 10 January 2003 14:55, Oliver Neukum wrote:
> Am Freitag, 10. Januar 2003 13:21 schrieb Duncan Sands:
> > > I am afraid I do not agree. Your reasoning is correct only on UP.
> > > If the code in question runs on another CPU, you are in trouble.
> >
> > It all depends on the semantics of u
Am Freitag, 10. Januar 2003 13:21 schrieb Duncan Sands:
> > I am afraid I do not agree. Your reasoning is correct only on UP.
> > If the code in question runs on another CPU, you are in trouble.
>
> It all depends on the semantics of usb_unlink_urb. Consider the
> patch below. Is this any better?
> I am afraid I do not agree. Your reasoning is correct only on UP.
> If the code in question runs on another CPU, you are in trouble.
It all depends on the semantics of usb_unlink_urb. Consider the
patch below. Is this any better? Maybe not: if usb_unlink_urb
returns before the completion hand
On Friday 10 January 2003 12:01, Oliver Neukum wrote:
> > Hi Oliver, thanks for looking the patch over. I thought about this issue
> > and came to the conclusion that the tasklet cannot be running. The
> > reason is as follows: the tasklet is only scheduled in the completion
> > handler udsl_usb_
Am Freitag, 10. Januar 2003 11:29 schrieb Duncan Sands:
> On Friday 10 January 2003 00:28, Oliver Neukum wrote:
> > > static void __exit udsl_usb_cleanup (void)
> > > {
> > > - /* killing threads */
> > > - udsl_atm_sar_stop ();
> > > usb_deregister (&udsl_usb_driver);
> >
> > Not quite. You ne
On Friday 10 January 2003 00:28, Oliver Neukum wrote:
> > static void __exit udsl_usb_cleanup (void)
> > {
> > - /* killing threads */
> > - udsl_atm_sar_stop ();
> > usb_deregister (&udsl_usb_driver);
>
> Not quite. You need to make sure that no tasklet is running.
Hi Oliver, thanks for
> static void __exit udsl_usb_cleanup (void)
> {
> - /* killing threads */
> - udsl_atm_sar_stop ();
> usb_deregister (&udsl_usb_driver);
Not quite. You need to make sure that no tasklet is running.
Regards
Oliver
---
speedtouch: remove the kernel thread and all the junk that went with it.
The work it did can all be done in interrupt context, so use a tasklet instead.
speedtouch.c | 79 +--
1 files changed, 7 insertions(+), 72 deletions(-)
diff -
21 matches
Mail list logo
