From: Johannes Erdfelt <johannes@erdfelt.com>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: alan@lxorguk.ukuu.org.uk, Linux Kernel <linux-kernel@vger.kernel.org>
Subject: Re: PROBLEM: usb not working with 2.4.8-ac8
Date: Fri, 24 Aug 2001 14:05:08 -0400 [thread overview]
Message-ID: <20010824140508.E4961@sventech.com> (raw)
In-Reply-To: <mailman.998431141.21252.linux-kernel2news@redhat.com> <200108220004.f7M04Qx01206@devserv.devel.redhat.com> <3B8355D9.7DE64E38@home.com> <20010822165853.A24726@devserv.devel.redhat.com>
In-Reply-To: <20010822165853.A24726@devserv.devel.redhat.com>; from zaitcev@redhat.com on Wed, Aug 22, 2001 at 04:58:53PM -0400
On Wed, Aug 22, 2001, Pete Zaitcev <zaitcev@redhat.com> wrote:
> The usb-uhci and ohci worked fine, so I poked uhci a little bit
> and made it all work, at least with my setup. Apparently,
> sometimes uhci returns a success (0) from submit_urb, but
> forgets to deliver a completion callback.
>
> The fix is a Johannes' territory and I not so sure of my way there,
> so perhaps a better one may be forthcoming.
Forgets may or may not be true. Success (0) from submit_urb only means
the URB was scheduled.
You may not receive a completion callback if the device NAK's the
transfer forever, or if there is a bug in uhci.c where the URB didn't
really get scheduled.
What was you test scenario where you didn't see a completion callback?
> diff -ur -X dontdiff linux-2.4.8-ac9/drivers/usb/uhci.c linux-2.4.8-ac9-niph/drivers/usb/uhci.c
> --- linux-2.4.8-ac9/drivers/usb/uhci.c Wed Aug 22 11:01:57 2001
> +++ linux-2.4.8-ac9-niph/drivers/usb/uhci.c Wed Aug 22 13:25:00 2001
> @@ -1471,6 +1471,7 @@
>
> static int uhci_submit_urb(struct urb *urb)
> {
> + struct usb_device *dev;
> int ret = -EINVAL;
> struct uhci *uhci;
> unsigned long flags;
> @@ -1480,15 +1481,16 @@
> if (!urb)
> return -EINVAL;
>
> - if (!urb->dev || !urb->dev->bus || !urb->dev->bus->hcpriv) {
> + dev = urb->dev;
> + if (!dev || !dev->bus || !dev->bus->hcpriv) {
> warn("uhci_submit_urb: urb %p belongs to disconnected device or bus?", urb);
> return -ENODEV;
> }
>
> - uhci = (struct uhci *)urb->dev->bus->hcpriv;
> + uhci = (struct uhci *)dev->bus->hcpriv;
>
> INIT_LIST_HEAD(&urb->urb_list);
> - usb_inc_dev_use(urb->dev);
> + usb_inc_dev_use(dev);
>
> spin_lock_irqsave(&urb->lock, flags);
>
> @@ -1497,7 +1499,7 @@
> dbg("uhci_submit_urb: urb not available to submit (status = %d)", urb->status);
> /* Since we can have problems on the out path */
> spin_unlock_irqrestore(&urb->lock, flags);
> - usb_dec_dev_use(urb->dev);
> + usb_dec_dev_use(dev);
>
> return ret;
> }
> @@ -1516,7 +1518,7 @@
> }
>
> /* Short circuit the virtual root hub */
> - if (urb->dev == uhci->rh.dev) {
> + if (dev == uhci->rh.dev) {
> ret = rh_submit_urb(urb);
>
> goto out;
> @@ -1528,13 +1530,13 @@
> break;
> case PIPE_INTERRUPT:
> if (urb->bandwidth == 0) { /* not yet checked/allocated */
> - bustime = usb_check_bandwidth(urb->dev, urb);
> + bustime = usb_check_bandwidth(dev, urb);
> if (bustime < 0)
> ret = bustime;
> else {
> ret = uhci_submit_interrupt(urb);
> if (ret == -EINPROGRESS)
> - usb_claim_bandwidth(urb->dev, urb, bustime, 0);
> + usb_claim_bandwidth(dev, urb, bustime, 0);
> }
> } else /* bandwidth is already set */
> ret = uhci_submit_interrupt(urb);
> @@ -1548,7 +1550,7 @@
> ret = -EINVAL;
> break;
> }
> - bustime = usb_check_bandwidth(urb->dev, urb);
> + bustime = usb_check_bandwidth(dev, urb);
> if (bustime < 0) {
> ret = bustime;
> break;
> @@ -1556,7 +1558,7 @@
>
> ret = uhci_submit_isochronous(urb);
> if (ret == -EINPROGRESS)
> - usb_claim_bandwidth(urb->dev, urb, bustime, 1);
> + usb_claim_bandwidth(dev, urb, bustime, 1);
> } else /* bandwidth is already set */
> ret = uhci_submit_isochronous(urb);
> break;
> @@ -1578,8 +1580,14 @@
>
> uhci_unlink_generic(uhci, urb);
> uhci_destroy_urb_priv(urb);
> + if (ret == 0) { /* N.B. Done, must notify */
> + /* uhci_call_completion(urb); */ /* ->> uhci_destroy_urb_priv */
> + urb->dev = NULL;
> + if (urb->complete)
> + urb->complete(urb);
> + }
>
> - usb_dec_dev_use(urb->dev);
> + usb_dec_dev_use(dev);
>
> return ret;
> }
What's all of this for? Protecting against an urb->dev race condition?
JE
next prev parent reply other threads:[~2001-08-24 18:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.998431141.21252.linux-kernel2news@redhat.com>
2001-08-22 0:04 ` PROBLEM: usb not working with 2.4.8-ac8 Pete Zaitcev
2001-08-22 6:48 ` Jordan Breeding
2001-08-22 7:13 ` Pete Zaitcev
2001-08-22 20:58 ` Pete Zaitcev
2001-08-24 18:05 ` Johannes Erdfelt [this message]
[not found] ` <mailman.998676421.4273.linux-kernel2news@redhat.com>
2001-08-24 21:38 ` Pete Zaitcev
2001-08-24 21:56 ` Johannes Erdfelt
2001-08-21 20:37 Tobias Diedrich
2001-08-21 21:59 ` Alan Cox
2001-08-21 23:04 ` Tobias Diedrich
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010824140508.E4961@sventech.com \
--to=johannes@erdfelt.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.