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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox