Hi,
In looking at the dc2xx driver I think I found a few potential locking
bugs, and a few "usages after free" problems. Here's a patch against
2.4.5-pre2 that fixes them.
thanks,
greg k-h
diff -Nru a/drivers/usb/dc2xx.c b/drivers/usb/dc2xx.c
--- a/drivers/usb/dc2xx.c Tue May 15 22:37:
Hi,
Here's a small patch to the acm driver that fixes a potential buffer
overrun problem that can occur. It is against 2.4.5-pre2.
thanks,
greg k-h
diff -Nru a/drivers/usb/acm.c b/drivers/usb/acm.c
--- a/drivers/usb/acm.c Tue May 15 22:37:41 2001
+++ b/drivers/usb/acm.c Tue May 15 22:37:41 2
Hi,
Here's a patch against 2.4.5-pre2 by Stelian Pop fixing some problems
for the SiteCom device he has.
thanks,
greg k-h
diff -Nru a/drivers/usb/serial/mct_u232.c b/drivers/usb/serial/mct_u232.c
--- a/drivers/usb/serial/mct_u232.c Tue May 15 22:37:41 2001
+++ b/drivers/usb/serial/mct_u23
OV511 and OV511+ match this description. A few people have told me that
OV511 or OV518 are used in their Webcam GO, but I could never confirm it.
Please post the full descriptor dump here so we can compare the endpoints
and other fields with known devices.
Also, you might want to open it up and
I have a Assabet of intel sa1100 development board.I have download zImage in it.When
I use ifconfig in the Assabet,example:
Assbet side: #ifconfig usbf 1.1.1.1 netmask 255.255.255.0/*It's ok*/
PC side: #ifconfig usb0 1.1.1.2 netmask 255.255.255.0 /*
> I'm writing an application that works with a USB device. The device
> itself is expected to be plugged and unplugged during the lifetime
> of the application, so I'm looking for a way to follow the state of
> the device. It's a GTK application, I have no problem with using
> timers.
>
> I'm con
I'm writing an application that works with a USB device. The device
itself is expected to be plugged and unplugged during the lifetime
of the application, so I'm looking for a way to follow the state of
the device. It's a GTK application, I have no problem with using
timers.
I'm considering usin
On Tue, May 15, 2001 at 02:04:42AM -0400, Pete Zaitcev wrote:
> > From: Mark McClelland <[EMAIL PROTECTED]>
> > To: [EMAIL PROTECTED]
> > Date: Mon, 14 May 2001 21:07:02 -0700
> >
> > > I was looking at the USB printer driver for a quick how-to on devfs'ing
> > > a driver, and in usblp_probe, the
On Mon, May 14, 2001 at 09:01:17PM -0700, Mark McClelland wrote:
> Tom Rini wrote:
>
> > Hello. The attached patch makes the 'normal' USB scanner register w/ devfs.
> > Comments/questions/et al? Thanks..
>
> IIRC, people who had devfs disabled were complaining about getting a similar
> error m
Thiruvengada Govindan wrote:
>
> Hi,
>
> The endpoint descriptor has a bit field that indicates whether the
> device attached is a "low speed" or "full speed" device. Now does the
> host controller interpret this field in any or is it ignored. I check
> the OHCI spec and it does not specify what
The WebcamGO(es) reports it's manufacturer ID as 0x041e (Creative) and
it's product id as 0x4005. I thought it could be the W9968CF because it
can be programmed with an I2C prom to report any vendor/product ID.
There are a few things that make me believe that they're using some
other chipset
On Tue, May 15, 2001 at 02:40:08PM +0200, Oliver Neukum wrote:
> On Monday, 14. May 2001 23:31, Tom Rini wrote:
> > Hello. The attached patch makes the 'normal' USB scanner register w/
> > devfs. Comments/questions/et al? Thanks..
>
> You may pass a null pointer to devfs_unregister is registeri
Hi,
The endpoint descriptor has a bit field that indicates whether the
device attached is a "low speed" or "full speed" device. Now does the
host controller interpret this field in any or is it ignored. I check
the OHCI spec and it does not specify what a controller may use this
information for.
On Monday, 14. May 2001 23:31, Tom Rini wrote:
> Hello. The attached patch makes the 'normal' USB scanner register w/
> devfs. Comments/questions/et al? Thanks..
You may pass a null pointer to devfs_unregister is registering has failed, eg
due to low memory. I don't know whether this is a bug,
Brad Hards wrote:
>
> Greg KH wrote:
> > Finally! A device that uses DFU in the wild! About time... :)
> Naturally, the manufacturer couldn't resist a few additions :(
>
> > Yes, we should probably support this, but probably through libusb, not a
> > kernel driver.
> I'm doing a libusb driver
Greg KH wrote:
> Finally! A device that uses DFU in the wild! About time... :)
Naturally, the manufacturer couldn't resist a few additions :(
> Yes, we should probably support this, but probably through libusb, not a
> kernel driver.
I'm doing a libusb driver for this at the moment.
For those
16 matches
Mail list logo
