On Mon, Aug 13, 2007, David Brownell <[EMAIL PROTECTED]> wrote:
> I'm also concerned with the reality that the MAINTAINERS file is
> not accurate. The $SUBJECT patch is one example; the named maintainer
> is no longer active (in that area, at least) and the named driver is
> not actually separable
On Wed, Jan 25, 2006, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> The usbfs is basically an equivalent of iopl and mmap(/dev/mem).
> Pushing applications in that direction is deeply troubling for me.
How so?
I'll be the first to admit that usbfs isn't exactly pretty, but it
certainly doesn't have t
On Wed, Jun 15, 2005, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 15 Jun 2005, Pete Zaitcev wrote:
> > Makes sense. I don't need an extra call, everything works as it is.
> > How about this:
> >
> > diff -urp -X dontdiff linux-2.6.12-rc6/drivers/usb/core/message.c
> > linux-2.6.12-rc6-lem/dri
On Thu, Mar 17, 2005, Hou Xiang ZHU <[EMAIL PROTECTED]> wrote:
> Is there anyway to move linux usb subsystem (or part) to grub? I hope to
> communicate with USB mass storage device earlier :) or maybe too earlier!
> Is this a crazy idea? or someone has worked on this before? Please give
> me a hint
On Thu, Jan 27, 2005, Hou Xiang ZHU <[EMAIL PROTECTED]> wrote:
> I am using kernel 2.6.8.1
> I am trying to use libusb to talk to my usb stick. but can't claim interface.
> (before I claim the interface, I can usb_set_configuration successfully!)
>
> here is some info:
> --
On Thu, Nov 11, 2004, Morgan Leah <[EMAIL PROTECTED]> wrote:
> I am using a libusb driver for a custom usb hardware
> device.
Please use the libusb list instead of the Linux USB lists in the future.
> This device is a reel controller unit which will
> occassionally need to be recalibrated. I c
On Fri, Oct 29, 2004, Duncan Sands <[EMAIL PROTECTED]> wrote:
> On Friday 29 October 2004 18:50, Johannes Erdfelt wrote:
> > On Fri, Oct 29, 2004, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > > Hi Johannes, maybe it should allocate multiple pages and then use scatt
On Fri, Oct 29, 2004, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Freitag, 29. Oktober 2004 20:44 schrieb David Brownell:
> > On Friday 29 October 2004 11:13, Johannes Erdfelt wrote:
> > > > If usbfs instead grabbed a bunch of non-contiguous
> > > >
On Fri, Oct 29, 2004, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > It probably will be significantly less. We have buffer size issues with
> > usbfs and libusb.
> >
> > Older versions of libusb used the synchronous bulk read/write calls and
> > those were limited to a page size. We've since switche
On Thu, Oct 28, 2004, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 28. Oktober 2004 17:01 schrieb Alan Stern:
> > On Thu, 28 Oct 2004, Axel Waggershauser wrote:
> > > I have to write a custom driver for a FX2 based camera module that
> > > should be able to reach a bulk throughput of a
On Sun, Sep 12, 2004, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 9 Sep 2004, Dominique Larchey wrote:
>
> > Here is the logs you requested ...
> > I have included a commented /var/log/messages (configured to
> > log kernel message) which includes logs of my driver.
> >
> > There are some che
On Wed, Sep 01, 2004, David Brownell <[EMAIL PROTECTED]> wrote:
> On Tuesday 31 August 2004 12:50 pm, Alan Stern wrote:
>
> > > Anyway, could anyone comment on the problem I discovered ?
> > > Could it be a UHCI/root hub problem ? Or is it certain that the
> > > device is faulty ? If the device is
On Sat, Jun 19, 2004, Markus Raab <[EMAIL PROTECTED]> wrote:
> My 4 port usb card with the chip VT6202 works only with 2 Ports. My Kernel is
> 2.6.7.
>
> Kernel messages:
> Jun 18 16:41:01 superbyte kernel: PCI: Found IRQ 9 for device :00:0c.2
> Jun 18 16:41:01 superbyte kernel: PCI: Sharing
On Thu, Jun 17, 2004, Alan Stern <[EMAIL PROTECTED]> wrote:
> This all sounds very strange. Here's an idea. Add
>
> unsigned char unused[32];
> struct list_head remove_list_copy;
>
> to the end of the uhci_qh structure. The remove_list_copy field will lie
> on a different cache lin
On Wed, Jun 16, 2004, Harald Welte <[EMAIL PROTECTED]> wrote:
> On Tue, Jun 15, 2004 at 03:29:10PM -0700, Johannes Erdfelt wrote:
> > > * How should this relate to "udev"? One implementation
> > > strategy would make "usbfs2" endpoint f
On Tue, Jun 15, 2004, David Brownell <[EMAIL PROTECTED]> wrote:
> Alan Stern wrote:
> >On Thu, 15 Jan 2004, Greg KH wrote:
> >
> >> We really
> >>need to start over and make usbfs2. It should look something like the
> >>gadgetfs interface.
> >
> >What about backward compatibility?
>
> How m
On Tue, Jun 15, 2004, Al Borchers <[EMAIL PROTECTED]> wrote:
> Skimming through the usb-ohci.c code quickly, it seems that OHCI
> calls the interrupt urb completion handlers for periodic interrupt
> urbs with its ohci_t ohci_lock spin lock held. (See hc_interrupt,
> dl_done_list, and sohci_return_
On Tue, Jun 15, 2004, Duncan Sands <[EMAIL PROTECTED]> wrote:
> On Tuesday 15 June 2004 18:01, David Brownell wrote:
> > Duncan Sands wrote:
> > >>Are there plans to replace usbfs with sysfs, or increase sysfs's
> > >>functionality (e.g. I/O with device endpoints)?
> > >
> > >
> > > I have a pla
On Mon, Jun 14, 2004, David Brownell <[EMAIL PROTECTED]> wrote:
> Alan Cox wrote:
> >On Llu, 2004-06-14 at 17:11, Alan Stern wrote:
> >
> >>The computers you mentioned use PPC processors. Do you know if these
> >>cache-line effects are equally important for Intel x86 machines?
> >
> >
> >x86 sys
On Thu, Apr 29, 2004, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 29 Apr 2004, Pete Zaitcev wrote:
>
> > On Wed, 28 Apr 2004 12:27:34 -0400 (EDT)
> > Alan Stern <[EMAIL PROTECTED]> wrote:
> >
> > > Under Linux 2.4, one way to handle this is by preventing the other thread
> > > from issuing th
On Tue, Apr 20, 2004, David Brownell <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
> >
> >Be careful. You can't modify certain values of the QH while it's on the
> >schedule safely. ...
>
> But it's possible to use the "dummy TD"
On Tue, Apr 20, 2004, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 20 Apr 2004, Johannes Erdfelt wrote:
>
> > On Tue, Apr 20, 2004, Alan Stern <[EMAIL PROTECTED]> wrote:
> > > Those are things that will be doable in the future. For now it looks
> > >
On Tue, Apr 20, 2004, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 20 Apr 2004, David Brownell wrote:
> > >>Wouldn't this be better fixed in the USB storage driver?
> > >
> > > Or rather, in the usb_sg_init() routine from the scatter-gather library.
> > > It could arrange to clear the URB_NO_
On Tue, Apr 20, 2004, Alan Stern <[EMAIL PROTECTED]> wrote:
> Following a suggestion of David Brownell's I have decided to remove
> support for the URB_NO_INTERRUPT flag in the UHCI driver. The overall
> effect of the flag is to reduce the number of interrupts, thereby
> improving throughput somew
On Fri, Mar 19, 2004, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> On Fri, 19 Mar 2004 17:07:04 -0500 (EST)
> Alan Stern <[EMAIL PROTECTED]> wrote:
>
> > This patch introduces a major simplification into the UHCI driver by
> > replacing its multiple spinlocks with a single one. []
>
> About time! I
Because uhci_result_interrupt used to be aliased to uhci_result_bulk.
The name got changed at some point at which point using the define
doesn't make much sense anymore.
But it did at one point :)
JE
On Mon, Feb 23, 2004, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> Bulk and interrupt urb's sh
On Mon, Feb 09, 2004, Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> @@ -669,7 +669,6 @@
>
> INIT_LIST_HEAD(&urbp->td_list);
> INIT_LIST_HEAD(&urbp->queue_list);
> - INIT_LIST_HEAD(&urbp->complete_list);
> INIT_LIST_HEAD(&urbp->urb_list);
>
> list_add_tail(&urbp
On Tue, Feb 03, 2004, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Sat, 31 Jan 2004, Charles Lepple wrote:
>
> > I have a ThinkPad 770, and under 2.6.x, the UHCI hardware works fine
> > until I suspend. I have a pair of scripts in
> > /etc/apm/{suspend.d,resume.d} which do 'rmmod uhci_hcd' and 'mo
On Tue, Feb 03, 2004, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 3 Feb 2004, Johannes Erdfelt wrote:
>
> > Root hub is polled, so it doesn't need interrupts.
>
> Of course! And I knew that too... Sometimes I wonder where my head has
> gone.
Happens to
On Mon, Feb 02, 2004, Sancho Dauskardt <[EMAIL PROTECTED]> wrote:
> At 22:38 01.02.04 -0500, Alan Stern wrote:
> >Johannes (or anyone else who can help):
> >
> >I could use some advice on tracking this problem down. You can follow the
> >entire discussion in the thread going forward from
> >
> >ht
On Fri, Jan 30, 2004, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Thu, 29 Jan 2004, Stephen Hemminger wrote:
>
> > Still tracking down the repeatable OOPS in uhci when an receive interrupt
> > transfer is aborted.
> >
> > I noticed that either the comment or the code is wrong about locking
> > ur
On Fri, Dec 12, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 11, 2003 at 02:26:07PM +0100, Duncan Sands wrote:
> > On Tuesday 09 December 2003 11:46, fee mail wrote:
> > > I guess this patch have been missed so I resend it as 2 rc more and still
> > > not applied or rejected. Begin forwar
On Tue, Jan 20, 2004, David Brownell <[EMAIL PROTECTED]> wrote:
> Alan Stern wrote:
> >
> >>This could very easily be the bug where UHCI garbages the USB data
> >>toggle when control queueing is in use ... it shouldn't be patching
> >>the toggles after they're set up, that's only for queues of bul
On Thu, Jan 15, 2004, Marcel Holtmann <[EMAIL PROTECTED]> wrote:
> Hi Philipp,
>
> > This just happend on our IBM X31 running 2.6.1-vanilla when I disabled
> > the internal bluetooth: (copied by hand from screen):
> >
> > usb 4-1: USB disconnected, address 2
> > Unable to handle kernel paging req
On Tue, Dec 30, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> Axel Waggershauser wrote:
> > I have a problem with inadequate throughput when submitting bulk urbs
> > with transfer buffers greater than about 128kB. ...
> >
> > The system looks like this:
> > kernel 2.6.0 with the uhci-hcd modul
On Sat, Dec 27, 2003, Ashley Reed <[EMAIL PROTECTED]> wrote:
> I have an AxisPad game controller from WalMart. The USB driver
> identifies it as "USB HID v1.00 Gamepad [ANKO Corp. Gemini Industries
> Inc. ]". The game pad doesn't work in any kernel after 2.6.0-test5.
> Here is the error message:
On Mon, Dec 08, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>I've thought that OHCI could detect this "IRQs are broken"
> >>problem earlier. I suspect UHCI could use the same kind of
> >>fix that came to mind: as the HCD starts, enable an IRQ
> >>for SOF, and wait a couple milliseconds
On Mon, Dec 08, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> Herbert Xu wrote:
>
> > The problem here is the khubd is stuck in usb_set_address() waiting
> > for the URB to complete, but it never finishes because the UHCI driver
> > isn't getting any interrupts.
>
> OHCI could have the same p
On Mon, Dec 08, 2003, Herbert Xu <[EMAIL PROTECTED]> wrote:
> The UHCI driver only cleans up removed QH/TD/URB entries in the interrupt
> routine. This means that if the interrupts aren't working for whatever
> reason (in my case it's a bug in suspend/resume), these entries will never
> be cleaned
On Wed, Nov 05, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Tue, 4 Nov 2003, Prageeth wrote:
> > thanks for the reply.
> >
> > after the timeout, if i call usb_clear_halt(), it
> > works fine. is there any better method?
> >
> > am suspecting some D0/D1 toggle problem.
> >
> > is there some
On Sun, Sep 14, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> In core/config.c, the descriptor parsing routines store class- and
> vendor-specific descriptors for configurations, interfaces, and endpoints
> using various "extra" pointers. The memory for these "extra" descriptors
> is separately
On Fri, Sep 12, 2003, Jean Tourrilhes <[EMAIL PROTECTED]> wrote:
> I just spent some time tracking a problem with hci_usb (BlueZ
> USB driver) and uhci. This happens on 2 different PCs with different
> hardware and 2.4.X kernels, I describe one here.
>
> UHCI Hardware :
> 00:07.2 USB C
On Tue, Sep 02, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 31, 2003 at 01:36:01AM +0200, Duncan Sands wrote:
> > Does the attached patch help?
>
> Ugh, I've been running a bunch of usb stress tests today and kept having
> the uhci driver halt with this error.
>
> After this patch, it
On Fri, Aug 22, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Fri, 22 Aug 2003, Karsten Wiese wrote:
>
> > hi Maintainers,
> >
> > I'm developing a driver for the tascam us428 audio/midi controller. it works
> > on intel USB BX440 Host controller, but has problems with one VIA USB
> > Contro
On Sat, Jul 26, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> With Duncan away, you're the only other person I know still interested in
> working on this...
>
> Duncan's suggestions gave me some ideas for even more improvements.
> Consider this:
>
> Merge the code that frees QHs, TDs, an
On Thu, Jul 24, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
> > This should probably go into the core since every HCD needs it to be set
> > to 0.
>
> If we keep it, yes. But the only use of error_count seems to be
> in debug prin
On Thu, Jul 24, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 23 Jul 2003, Johannes Erdfelt wrote:
>
> > > UHCI does not initialize urb->error_count to 0 anywhere. Again,
> > > that probably ought to be done in usb_submit_urb(), anyway.
> >
>
On Wed, Jul 23, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> The more I study the UHCI driver source, the more questions and other
> observations come up. I hope you won't mind taking the time to respond.
Nope. I'm actually excited that someone else has taken the time to look
over my code in th
On Tue, Jul 22, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> The current implementation of the Change-Port-Reset bits for the root hub
> in uhci-hub.c is totally bogus. This patch fixes it.
>
> Of course, it's not really necessary to implement those bits at all -- the
> UHCI driver works fine r
On Tue, Jul 22, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> This patch fixes the problems in the UHCI driver I identified last week:
>
> It stores the status for a completed URB in urb rather than urbp.
>
> It avoids setting the status of unlinked URBs to -ECONNRESET,
> since
On Fri, Jul 18, 2003, James Courtier-Dutton <[EMAIL PROTECTED]> wrote:
> See attached file for details.
> Description: Kernel oops when unplugging the usb cable of an active usb
> device.
> It has some explanations of the "uhci.c-oops" attachment, together with
> extract from the source code iden
On Thu, Jul 17, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> A bug has turned up in the UHCI driver. Briefly, when an URB completes,
> uhci_transfer_result() doesn't store the status in urb->status but only in
> urbp->status. urb->status is set just before calling hcd_giveback_urb().
>
> Howeve
On Thu, Jul 17, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> This patch for the UHCI driver changes the test for over current inputs,
> which can cause false Resume indications with some of Intel's USB
> controllers. Previously the code only checked for one specific controller
> chip, but now ano
On Mon, Jun 30, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 30, 2003 at 04:34:42PM -0700, Greg KH wrote:
> > Off to try no serial debug...
>
> Heh, that works just fine. Ok, sorry for the noise here, this really
> isn't a bug :)
>
> Anyway, Johannes, mind if I turn down the debugging
On Mon, Jun 30, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 30, 2003 at 06:09:54PM -0400, Johannes Erdfelt wrote:
> > > I don't think this is a new thing, I think I've seen this in the past,
> > > but haven't really tested removing devices a
On Mon, Jun 30, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 30, 2003 at 05:48:56PM -0400, Johannes Erdfelt wrote:
> > On Mon, Jun 30, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> > > drivers/usb/host/uhci-hcd.c: uhci_result_common() failed with statu
On Mon, Jun 30, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On 2.5.73 (and probably previously, I think I've seen this before), when
> disconnecting a USB device from a UHCI host, I sometimes get the
> following "errors" in my log.
I assume you mean unplug the device?
How reproducible is it now?
On Wed, Jun 25, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Wed, 25 Jun 2003, Johannes Erdfelt wrote:
>
> > I think your analysis is right on target.
> >
> > I think your proposed fix is correct, but the implementation will be
> > tricky. We stor
On Wed, Jun 25, 2003, Alan Stern <[EMAIL PROTECTED]> wrote:
> On Mon, 23 Jun 2003, Duncan Sands wrote:
>
> > On Sunday 22 June 2003 02:00, Johannes Erdfelt wrote:
> > > On Sun, Jun 22, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > > >
> >
On Fri, Jun 20, 2003, Luck, Tony <[EMAIL PROTECTED]> wrote:
> > On Fri, Jun 20, 2003 at 04:11:07PM -0400, Johannes Erdfelt wrote:
> > > Here's a patch from Tony Luck that fixes a problem with the UHCI
> > > debugging code on architectures with big page sizes. W
On Sun, Jun 22, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> On Tuesday 10 June 2003 19:18, Alan Stern wrote:
> > On Tue, 10 Jun 2003, Duncan Sands wrote:
> > > I've tracked it down to the following: the first of two queued urbs
> > > completes, and the HC detects a problem in the following stre
Here's a patch from Tony Luck that fixes a problem with the UHCI
debugging code on architectures with big page sizes. We end up
allocating more than kmalloc allows.
Please apply. Thanks!
JE
= drivers/usb/host/uhci-debug.c 1.5 vs edited =
--- 1.5/drivers/usb/host/uhci-debug.c Mon Dec 30
On Fri, Jun 06, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > It will only set SPD if short packets were ok.
>
> OK, I was confused: I thought SPD meant short packets
> get signalled as an error, but in fact it means they just
> get signalled (a good thing if you want short packets),
> right?
On Fri, Jun 06, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> diff -Nru a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
> --- a/drivers/usb/host/uhci-hcd.c Fri Jun 6 11:35:55 2003
> +++ b/drivers/usb/host/uhci-hcd.c Fri Jun 6 11:35:55 2003
> @@ -831,7 +831,7 @@
>*/
>
On Thu, Jun 05, 2003, Pete Zaitcev <[EMAIL PROTECTED]> wrote:
> > Date: Thu, 5 Jun 2003 02:15:06 -0400
> > From: Johannes Erdfelt <[EMAIL PROTECTED]>
>
> > I didn't see this on x86, but apparentely others have looking at the
> > RedHat 9 kernel sourc
On Thu, Jun 05, 2003, Johannes Erdfelt <[EMAIL PROTECTED]> wrote:
> Here's a patch to fix a race condition in usbdevfs. The fix is in hub.c
> but the race is related to usbdevfs.
>
> The race goes like this:
>
> Process 1 (khubd)
Here's a patch to fix a race condition in usbdevfs. The fix is in hub.c
but the race is related to usbdevfs.
The race goes like this:
Process 1 (khubd) Process 2 (mount)
usb_hub_port_connect_change()
hub->children[port] = dev
usb_new_device()
On Sat, May 31, 2003, David C. Moore <[EMAIL PROTECTED]> wrote:
> uhci.c in the latest stable kernel release candidates seems to have a
> race condition in the suspend code triggered when all devices are
> unplugged.
>
> When the final device is unplugged, suspend_hc() is called to reduce
> bus-ma
On Tue, May 27, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> Johannes Erdfelt wrote:
>
> > I think it should change for 2.5 and 2.4.
>
> I agree that a kernel patch is the right thing here,
> maybe even for 2.2 ... but specifically what patch?
>
> I think
On Tue, May 27, 2003, Randy.Dunlap <[EMAIL PROTECTED]> wrote:
> On Fri, 23 May 2003 16:50:35 -0700 Greg KH <[EMAIL PROTECTED]> wrote:
>
> | On Thu, May 22, 2003 at 02:09:56PM -0400, Johannes Erdfelt wrote:
> | > On Thu, May 22, 2003, Randy.Dunlap <[EMAIL PROTECTED]&g
On Tue, Mar 18, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> This is with latest Linus BK. From the system log, during boot:
>
> kernel: drivers/usb/class/usblp.c: usblp0: nonzero read/write bulk status received:
> -104
> kernel: drivers/usb/class/usblp.c: usblp0: error -104 reading from prin
Here's a patch to finish completions in the order they occur. This
brings uhci.c in line with the other HCDs and what people generally
would expect.
JE
# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.4 USB kernel tree
# This patch format is inte
Here's the 2.5 version of the patch to uhci.c to finish completions in
the correct order.
Please apply.
JE
# This is a BitKeeper generated patch for the following project:
# Project Name: greg k-h's linux 2.5 USB kernel tree
# This patch format is intended for GNU patch command version 2.5 or hi
ms <[EMAIL PROTECTED]> wrote:
> Could this happen with the usb-uhci code as well? I didn't see a
> similar completion list.
>
> Is there a good way to track down how long and where interrupts are
> being disabled?
>
> Thanks.
>
> --Brian
>
> -Origina
On Sun, Mar 09, 2003, Jouni Ryno <[EMAIL PROTECTED]> wrote:
> I'm developing driver for EZUSB-based system. When I use continuous
> iso-transfer (several urbs connected in the ring), every 986 (sometimes
> +-3) I get 1 or more urbs, which complete in reverse order.
>
> For example, start_frames in
On Sat, Mar 01, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> Noticed this through www.theinquirer.net :
>
> http://www.dct-net.co.jp/special/usb_hot.html
>
> But what I want to know is why they advertise
> Windows and Mac support, but not Linux ... does
> a coffee (tea?) cup warmer reall
On Tue, Feb 25, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > The question should be, what a reference may be used for after
> > > disconnect(). To determine requirements we must look at the worst case.
> > > In this case this is reassignment of the interface right after
> > > disconnect(
On Tue, Feb 25, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > The only time a driver would need to get a reference is if it intends to
> > use the device structure past the disconnect() callback.
>
> The question should be, what a reference may be used for after disconnect().
> To determin
On Tue, Feb 25, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> On Monday 24 February 2003 21:11, Johannes Erdfelt wrote:
> > On Mon, Feb 24, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> > > --- bollux-2.5/drivers/usb/core/usb.c.orig2003-02-24 13:52:49.00
On Mon, Feb 24, 2003, Joshua Wise <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> *baff!!* Just sent this to myself, not checking the To: field. Good job me. :)
> Anyway, here's another little piece:
>
> > What does this mean? I am unfamiliar with UHCI internals.
On Sun, Feb 23, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>Why should drivers use usb_get_dev in probe, and usb_put_dev in disconnect?
> >
> >
> > No reason. A reference is already done by the core which covers the
> > reference for that whole period of time.
>
> A reference which is
On Mon, Feb 24, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> --- bollux-2.5/drivers/usb/core/usb.c.orig2003-02-24 13:52:49.0 +0100
> +++ bollux-2.5/drivers/usb/core/usb.c 2003-02-24 13:56:20.0 +0100
> @@ -701,12 +701,6 @@
> * usb_get_dev - increments the reference count of
On Sun, Feb 23, 2003, Duncan Sands <[EMAIL PROTECTED]> wrote:
> The comment for usb_get_dev says:
>
> /**
> * usb_get_dev - increments the reference count of the usb device structure
> * @dev: the device being referenced
> *
> * Each live reference to a device should be refcounted.
> *
> * D
On Sat, Feb 22, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
> >>>Back to the patch I've attached. It's against 2.4.19-pre3 (I'll update
> >>>to Greg's CVS tree) and hasn't had the level of testing necessary to
> >>>call it good. I also want to recheck that I caught all of the necessary
> >>>pat
On Sat, Feb 22, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
>
> > The intent was for 2.4 to have this same contract. Having a reference count
> > on the device structure is pointless if that weren't the case.
> >
> > However, there may be bugs there in HCDs, the core, or drivers with
> > resp
On Sat, Feb 22, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 23, 2003 at 12:36:02AM +0100, Duncan Sands wrote:
> > > The philosophy is often called "programming by contract".
> > >
> > > And the contract is: usbcore agrees to work with your driver
> > > and do everything right, if your d
On Fri, Feb 21, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 21, 2003 at 05:53:24PM +0100, Duncan Sands wrote:
> > > What's the backtrace from the oops?
> >
> > usb_free_dev+19/3c
>
> Hm, wonder if the bus has been cleaned up by the shutdown sequence
> first. That might cause this.
It
On Thu, Feb 20, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
>
> >>Having looked at the history of that misnamed API:
> >>
> >> - Originally provided in 2.2.10 or so, I think OHCI was the only
> >>user. It was misnamed at that time, given that it was used
> >>only to handshake "device
On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > Absolutely right. And IMHO to a device driver that state is reached after
> > > it returns from disconnect().
> >
> > I don't see why that is advantageous.
> >
> > It sounds like it would just complicate the code even more.
>
On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
> Am Donnerstag, 20. Februar 2003 02:25 schrieb Greg KH:
> > On Wed, Feb 19, 2003 at 05:08:14PM -0800, David Brownell wrote:
> > > >But what about drivers that fire off urbs and don't keep a pointer to
> > > >them around? They don't kn
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 19, 2003 at 07:57:29PM -0500, Johannes Erdfelt wrote:
> > >
> > > Heh. No, urbs are referenced counted now. So a driver can do the
> > > following just fine:
> > > -
On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > > Actually, it seems to me that that unlinking after disconnect would
> > > > need to be a requirement for random disconnects to work.
> > >
> > > After physical disconnect, or logical disconnect?
> >
> > Physical. I consider l
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 19, 2003 at 07:57:29PM -0500, Johannes Erdfelt wrote:
> > >
> > > Heh. No, urbs are referenced counted now. So a driver can do the
> > > following just fine:
> > > -
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 19, 2003 at 07:33:57PM -0500, Johannes Erdfelt wrote:
> > > But what about drivers that fire off urbs and don't keep a pointer to
> > > them around? They don't know if all of their urbs a
On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > Does the existing serial driver submit URBs after the device is
> > physically removed? (Like if an application still has an fd open when
> > the device was removed)
>
> Of course it does. _Any_ driver will do so. The window bet
On Wed, Feb 19, 2003, David Brownell <[EMAIL PROTECTED]> wrote:
>
> but the hcd drivers should have already canceled them, right? Hm, but
> >>>
> >>>Nope, the only way an hcd can know the device is gone is by
> >>>calling the misnamed bus->op->deallocate() routine. And
> >>>because of the me
On Thu, Feb 20, 2003, Oliver Neukum <[EMAIL PROTECTED]> wrote:
>
> > > No, some of the hcds die a horrible death if you try to call unlink on a
> > > urb after the device is gone :(
> >
> > They shouldn't. It should be perfectly valid to do that.
> >
> > Actually, it seems to me that that unlinkin
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> > Does the existing serial driver submit URBs after the device is
> > physically removed? (Like if an application still has an fd open when
> > the device was removed)
>
> Yes, some drivers do this, (the keyspan driver is one, and I think
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 19, 2003 at 05:44:54PM -0500, Johannes Erdfelt wrote:
> > On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> > > On Wed, Feb 19, 2003 at 02:21:11PM -0800, David Brownell wrote:
> > &g
On Wed, Feb 19, 2003, Greg KH <[EMAIL PROTECTED]> wrote:
> On Wed, Feb 19, 2003 at 02:21:11PM -0800, David Brownell wrote:
> > Greg KH wrote:
> > >
> > >Hm, maybe we should mark the device gone at the beginning of this call,
> > >or right at the time we realize it's gone in the hub driver. That wo
1 - 100 of 539 matches
Mail list logo
