public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: "Maksim (Max) Krasnyanskiy" <maxk@qualcomm.com>
Cc: linux-kernel@vger.kernel.org, linux-usb-devel@lists.sourceforge.net
Subject: Re: [linux-usb-devel] Re: What to do with all of the USB UHCI drivers in the kernel ?
Date: Tue, 21 May 2002 21:33:03 -0700	[thread overview]
Message-ID: <3CEB1F7F.4000000@pacbell.net> (raw)
In-Reply-To: <5.1.0.14.2.20020521133408.068d2ef8@mail1.qualcomm.com> <5.1.0.14.2.20020521122422.06b21188@mail1.qualcomm.com> <5.1.0.14.2.20020521122422.06b21188@mail1.qualcomm.com> <20020521195925.GA2623@kroah.com> <5.1.0.14.2.20020521133408.068d2ef8@mail1.qualcomm.com> <5.1.0.14.2.20020521164157.06b68430@mail1.qualcomm.com>

Maksim (Max) Krasnyanskiy wrote:
> 
> One-shot interrupt transfers are broken in *-hcd drivers. core/hcd.c 
> returns EINVAL if urb->interval==0.

Hmm, eventually that automagic resubmit model needs to go away,
in favor of a straight queued transfer model -- where in effect
there are _only_ "one shot" transfers, which for interrupts are
just going to hang out on endpoint queues that are properly
scheduled.  That's needed to make interrupt reads and writes
have the same transfer model ... right now interrupt OUT transfers
don't work very well.  (And they'll be the most common type when
we eventually get those device/target side driver APIs sorted.)

Meanwhile, I suppose I can see wanting access to that UHCI-ism.
However your patch would do that wrong, since it should only
apply to interrupt transfers.


> usb-uhci-hcd has to be fixed.
> btw It tries to round interval value even thought it's done by hcd.c

That was one of my quick-review comments too.  It doesn't hurt,
it's just one of several URB sanity-check/preprocessing steps
that doesn't need to be in every driver.


> On a side note. Why are URBs still not SLABified ?

Hasn't seemed to be necessary.  kmalloc() is slabified already,
so it's not clear that a control/bulk/interrupt URB pool shared
between drivers -- size, maybe a handful -- would be better than
sharing that same memory with other kernel code.

- Dave






  reply	other threads:[~2002-05-22  4:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-21 19:41 What to do with all of the USB UHCI drivers in the kernel ? Maksim (Max) Krasnyanskiy
2002-05-21 19:59 ` Greg KH
2002-05-21 20:43   ` Maksim (Max) Krasnyanskiy
2002-05-21 20:58     ` Johannes Erdfelt
2002-05-22  1:04       ` Maksim (Max) Krasnyanskiy
2002-05-22  4:33         ` David Brownell [this message]
2002-05-22 18:57           ` [linux-usb-devel] " Maksim (Max) Krasnyanskiy
2002-05-22  5:06         ` Greg KH
2002-05-22 19:43           ` Maksim (Max) Krasnyanskiy
2002-05-21 20:00 ` [linux-usb-devel] " Johannes Erdfelt
2002-05-21 21:09   ` Maksim (Max) Krasnyanskiy
  -- strict thread matches above, loose matches on Subject: below --
2002-05-20 22:31 What to do with all of the USB UHCI drivers in the kernel? Greg KH
2002-05-22  1:10 ` André Bonin
2002-05-22 19:21   ` Greg KH
2002-05-22 19:35     ` Andre Bonin
2002-05-22 20:15       ` Greg KH
2002-05-23  6:34         ` Martin Dalecki
2002-05-23 15:16           ` [linux-usb-devel] " David Brownell

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=3CEB1F7F.4000000@pacbell.net \
    --to=david-b@pacbell.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=maxk@qualcomm.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