On Tue, 2003-10-28 at 08:48, Holger Schurig wrote:
Rudolf Ladyzhenskii wrote:
I am working on this driver (porting it to a custom hardware). It looks
like I am missing some files.
Does
http://lists.arm.linux.org.uk/pipermail/linux-arm-kernel/2003-October/017809.html
help you?
I've
The following patch was created by Benoit PAPILLAULT
(http://benoit.papillault.free.fr).
It corrects the following bug : it initializes the value of interval for
iso urb otherwise it would be 0 and would
produce an error.
This bug only shows up with our driver (eciadsl,
David Mosberger wrote:
After spending a bit more time on this, it looks to me like the
keyboard is crashing the system very early on.
I think there are some devices that choke the HID
code; I recall someone reporting a mouse that did the
same kind of thing. Do other kinds of keyboards do
the
Hello,
I am using a custom board with a an2131 usb controller. To access this
controller I use a file called usblinux.c from the ezusb2131 driver.
This file uses ioctl calls like USBDEVFS_BULK to access a bulk endpoint
via /proc/bus/usb/*/*. I developped the an2131-software under a 2.5
kernel and
On Fri, 31 Oct 2003 08:23:54 -0800, David Brownell [EMAIL PROTECTED] said:
David.B David Mosberger wrote:
After spending a bit more time on this, it looks to me like the
keyboard is crashing the system very early on.
David.B I think there are some devices that choke the HID
David.B
On Wed, 29 Oct 2003, Greg KH wrote:
On Wed, Oct 29, 2003 at 04:01:06PM -0500, Alan Stern wrote:
This patch should fix the problem reported below by Daniel Dorau. The
oops was caused by inadequate synchronization between khubd and
hub_disconnect(). The hub interface-data pointer was
On Fri, 31 Oct 2003 10:34:22 PST, David Mosberger said:
And nobody is alarmed by this? Surely crashing the kernel by plugging
in a USB device must be considered a MUST-FIX item. Perhaps I missed
something, but I never saw this mentioned before.
Bill Gates. Comdex. Printer. :)
pgp0.pgp
On Wed, 29 Oct 2003, Greg KH wrote:
Hm, looks like this patch does 3 different things, right? Care to send
3 different patches? :)
This is the second of three. It changes spin_lock_save() to spin_lock()
within the completion routine and list_del()/INIT_LIST_HEAD() to
list_del_init().
On Wed, 29 Oct 2003, Greg KH wrote:
Hm, looks like this patch does 3 different things, right? Care to send
3 different patches? :)
This is the third of three. It improves synchronization with hub_irq()
and guarantees that the hub disconnect() routine doesn't exit until the
URB's
David Mosberger wrote:
On Fri, 31 Oct 2003 08:23:54 -0800, David Brownell [EMAIL PROTECTED] said:
David.B David Mosberger wrote:
After spending a bit more time on this, it looks to me like the
keyboard is crashing the system very early on.
David.B I think there are some devices that
On Fri, 31 Oct 2003 11:28:20 -0800, David Brownell [EMAIL PROTECTED] said:
David.B You sound alarmed! If that's alarmed enough to find out
David.B what the real problem is, maybe you'll end up fixing it
David.B ... :)
Except I know almost nothing about the USB stack.
David.B Agreed,
On Fri, 31 Oct 2003 11:50:01 -0800
David Mosberger [EMAIL PROTECTED] wrote:
On Fri, 31 Oct 2003 11:28:20 -0800, David Brownell [EMAIL PROTECTED] said:
David.B You sound alarmed! If that's alarmed enough to find out
David.B what the real problem is, maybe you'll end up fixing it
Yes on paper the 1999 Sep 31 BOT 1.0 (aka BBB = command/ data/
status by bulk/ bulk/ bulk) allows stall-free device, provided such
a device reports accurate dCSWDataResidue.
My current patch only does this for successful commands which return
short data (such as Mode Sense). But the
18.6.2 Forcible Stall by Application
...
looks like clearing a halt requires letting the device software know
by sending some vendor-specific message, in addition to simply sending
a Clear Feature command. You have to wonder why they designed their
controller that way.
I held on to these
I implement a new version of my library using FTDI_SIO and USBSERIAL
modules. I've used the open,close,read and write commands to access the
port. Unfortunately, the new update rate is 25 Hz (compared to 900 Hz
under Windows). As my device use bulk read/write to transfer data I
really do not know
Here is a patch to 2.6.0-test9 that addresses mips bit-endian bus accesses breaking
endianness in EHCI and OHCI. It also fixes a problem with ohci_dbg() not endian
swapping the frame number field in a debug print.
Untested on x86, but the changes are trivial so it should work there as well. I
This patch fixes a WARN_ON triggered by cdc-acm, over about
the past four months or so of kernels. Sample call stack:
[c012046c] local_bh_enable+0x8c/0x90
[f8991452] ppp_asynctty_receive+0x62/0xb0 [ppp_async]
[c02144f3] flush_to_ldisc+0xa3/0x120
[f891f20f] acm_read_bulk+0xbf/0x140
17 matches
Mail list logo
