Stuart MacDonald wrote:
Below you will find the log of a recent 2.5.43 test of the whiteheat driver;
stock kernel, using the driver that's included.
Some automatic checks have been triggered, and I'm wondering where
the error lies.
I don't think I'm calling usb_clear_halt in a an illegal manner
Hi Pavel,
This is zaurus support for usbnet. Unlike usbdnet, it should not eat
disks. Diff against 2.5.42; please apply.
Thanks! How did you know I wanted to see a patch like this? :)
I did some minor cleanups ... can you retest the attached patch?
- your base patch
- adds a more complete
On Thu, Oct 17, 2002 at 06:37:26PM -0700, David Brownell wrote:
> Here's a more complete patch for that driver binding problem.
> Now (a) when scanning for a driver to handle a new device,
> scanning stops after the first successful probe not the
> first successful match; and (b) new drivers get ev
Hi all,
Sorry for the delay in getting some of the more recent patches sent to
me out to Linus, but it's been a busy week...
Anyway, I think I've handled everything that has been sent to me, with
the exception of Oliver's change configuration patch, and my previous
device reference count patch.
Who knows what the story is there ... according to the
USB spec, iso endpoints can't halt, so it's pointless
to even try.
So why does that driver try? Is that product breaking
the spec, or is that logic not necessary?
You probably refer to this:
usb_clear_halt(uvd->dev, usb_rcvisocpipe(uvd->d
On Fri, 2002-10-18 at 10:31, David Brownell wrote:
> Who knows what the story is there ... according to the
> USB spec, iso endpoints can't halt, so it's pointless
> to even try.
>
> So why does that driver try? Is that product breaking
> the spec, or is that logic not necessary?
You probably r
I'd really like an HCD guy to look at this. I've tested this every way I
can think of -- attempts to clear the halt on the bulk-in endpoint all
return -EPIPE. I know that the device is okay, because the same sequence
on 2.4.x works just fine.
I think I got it. Basically, in 2.5 usb_pipein()
Who knows what the story is there ... according to the
USB spec, iso endpoints can't halt, so it's pointless
to even try.
So why does that driver try? Is that product breaking
the spec, or is that logic not necessary?
- Dave
---
This sf.net
ChangeSet 1.781.21.15, 2002/10/17 23:38:08-07:00, [EMAIL PROTECTED]
[PATCH] Add support for JTEC FA8101 USB to Ethernet device
o Add support for JTEC FA8101 USB to Ethernet device
diff -Nru a/drivers/usb/net/pegasus.h b/drivers/usb/net/pegasus.h
--- a/drivers/usb/net/pegasus.h Fri Oct 18 14:4
ChangeSet 1.781.21.17, 2002/10/18 09:34:20-07:00, [EMAIL PROTECTED]
[PATCH] uhci interrupt resubmit fixes
After the interrupt queueing was added, I don't think the old way of
resetting interrupts will work anymore. This patch changes it to simply
do a full unlink and resubmission automatically.
ChangeSet 1.798.4.5, 2002/10/18 14:18:29-07:00, [EMAIL PROTECTED]
[PATCH] char tipar driver minor update
you will find a patch for the tipar char driver.
This patch fixes some typos and add a documentation entry.
diff -Nru a/Documentation/tipar.txt b/Documentation/tipar.txt
--- /dev/null Wed
ChangeSet 1.793.1.19, 2002/10/18 11:35:15-07:00, [EMAIL PROTECTED]
USB: fix problem with removing a USB root hub.
diff -Nru a/drivers/usb/core/usb.c b/drivers/usb/core/usb.c
--- a/drivers/usb/core/usb.cFri Oct 18 14:42:59 2002
+++ b/drivers/usb/core/usb.cFri Oct 18 14:42:59 2002
@@ -790,
ChangeSet 1.798.4.4, 2002/10/18 14:18:15-07:00, [EMAIL PROTECTED]
[PATCH] cpia fix for older compilers
diff -Nru a/drivers/media/video/cpia.h b/drivers/media/video/cpia.h
--- a/drivers/media/video/cpia.hFri Oct 18 14:42:55 2002
+++ b/drivers/media/video/cpia.hFri Oct 18 14:42:55
ChangeSet 1.793.1.18, 2002/10/18 10:13:22-07:00, [EMAIL PROTECTED]
driver core: fix up merge mess
diff -Nru a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c Fri Oct 18 14:43:02 2002
+++ b/drivers/base/core.c Fri Oct 18 14:43:02 2002
@@ -25,46 +25,6 @@
#define
ChangeSet 1.781.39.1, 2002/10/17 23:21:37-07:00, [EMAIL PROTECTED]
Cset exclude: [EMAIL PROTECTED]|ChangeSet|20021015071026|11647
diff -Nru a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c Fri Oct 18 14:43:27 2002
+++ b/drivers/base/core.c Fri Oct 18 14:43:27 200
ChangeSet 1.793.1.17, 2002/10/18 10:00:13-07:00, [EMAIL PROTECTED]
merge between the usb and driver model trees.
diff -Nru a/drivers/base/core.c b/drivers/base/core.c
--- a/drivers/base/core.c Fri Oct 18 14:43:06 2002
+++ b/drivers/base/core.c Fri Oct 18 14:43:06 2002
@@ -19,109 +19,
ChangeSet 1.781.21.16, 2002/10/18 00:05:29-07:00, [EMAIL PROTECTED]
[PATCH] one liner, anti-oops
This fixes a potential oops (depending on how the HCD handles it)
from a recent patch of mine. Evidently I didn't test this bit a
device that'd show the problem, sigh. Luckily Martin Diehl was
testi
ChangeSet 1.781.21.14, 2002/10/17 23:37:50-07:00, [EMAIL PROTECTED]
[PATCH] change devio-disconnect no-driver error code
The talk about disconnect locking reminded me of this - the error code in
the no-driver case for the disconnect ioctl isn't a unique error code.
This changes the error code to
ChangeSet 1.781.21.13, 2002/10/17 23:37:35-07:00, [EMAIL PROTECTED]
[PATCH] LDM and driver binding
Here's a more complete patch for that driver binding problem.
Now (a) when scanning for a driver to handle a new device,
scanning stops after the first successful probe not the
first successful matc
ChangeSet 1.781.21.11, 2002/10/17 17:16:04-07:00, [EMAIL PROTECTED]
[PATCH] usbtest updates
Various small fixes and adds ids for new test firmware.
diff -Nru a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
--- a/drivers/usb/misc/usbtest.cFri Oct 18 14:43:30 2002
+++ b/drivers/
On Thu, Oct 17, 2002 at 09:55:49PM -0400, Ed Tomlinson wrote:
> In the patch fest in the last couple of days usb storage support for sddr09
> has broken. I see the following in the log (2.5.43-mm2):
> Oct 17 21:37:07 oscar kernel: sddr09: Found Flash card, ID = 00 00 00 00: Manuf.
>unknown, 40
On 2002.10.15 19:10 David Brownell wrote:
I don't know if it's important, but I had to enable usb keyboard
legacy mode in the bios to have keyboard support in the bootloader
stage. I had a bad feeling about the option though, a good bios is a
lean bios.
Unless your boot loader has a small
> Yes, but Joe's was there first, based on the original driver, that's why
> I accepted his patch.
I understand that. My code is even based partially on it and wouldn't exist
without the reverse engineering/color decoding information that I found at
his site.
> Could you point out the problems in
On Wed, 16 Oct 2002, David Brownell wrote:
>
> > FILL_CONTROL_URB(dev->ctrl_urb,
> > dev->udev,
> > usb_sndctrlpipe(dev->udev,0),
> > (unsigned char*)&dev->dr,
> > buff,
> > 3,
> >
24 matches
Mail list logo
