On 15-Nov-2002 Randy.Dunlap wrote:
On Thu, 14 Nov 2002, Duncan Haldane wrote:
|
| any ideas?
Hi,
I think that the usb_bus_list_lock semaphore just isn't
initialized yet.
This can happen because we don't have much control over
the order of initcalls in 2.4. There is more control
over
Yes, I think you are right.
To test your idea, I moved the initialization
init_MUTEX(usb_bus_list_lock);
from usb_init() to just before the call to usb_scan_devices()
in usb_register() and the oops went away and cpia worked.
I see that in the working code prior to 2.4.13,
Hello!
Pasi Matilainen already posted a patch on the linux-usb-devel list but it
was not included in the kernel, so i guess it has been forgotten.
It makes the USB mass storage device on he Nokia 5510 cellular phone work
because it doesn't support the START_STOP command.
This is a linux kernel
Hi,
On Thu, Nov 14, 2002 at 04:18:45PM -0800, Greg KH wrote:
On Wed, Nov 13, 2002 at 03:39:38PM +0100, Henning Meier-Geinitz wrote:
Thanks for the pointer. Now that SANE 1.0.9 has been released, are
there any objections to me removing the scanner driver in 2.5?
Users who
On Fri, 15 Nov 2002, Oliver Neukum wrote:
|
| Yes, I think you are right.
| To test your idea, I moved the initialization
|
| init_MUTEX(usb_bus_list_lock);
|
| from usb_init() to just before the call to usb_scan_devices()
| in usb_register() and the oops went away and cpia worked.
From: Randy.Dunlap [EMAIL PROTECTED]
Date: Fri, 15 Nov 2002 08:40:36 -0800 (PST)
| Yes, I think you are right.
| To test your idea, I moved the initialization
|
| init_MUTEX(usb_bus_list_lock);
|
| from usb_init() to just before the call to usb_scan_devices()
| in
On 15-Nov-2002 Oliver Neukum wrote:
Yes, I think you are right.
To test your idea, I moved the initialization
init_MUTEX(usb_bus_list_lock);
from usb_init() to just before the call to usb_scan_devices()
in usb_register() and the oops went away and cpia worked.
I see that in
On 15-Nov-2002 Randy.Dunlap wrote:
On Fri, 15 Nov 2002, Pete Zaitcev wrote:
| From: Randy.Dunlap [EMAIL PROTECTED]
| Date: Fri, 15 Nov 2002 08:40:36 -0800 (PST)
| This is the way it used to be many many moons ago.
|
| VERY many moons ago. Today, the same effect is accomplished by
|
On Fri, 15 Nov 2002, Duncan Haldane wrote:
|
| On 15-Nov-2002 Randy.Dunlap wrote:
| On Fri, 15 Nov 2002, Pete Zaitcev wrote:
|
| | VERY many moons ago. Today, the same effect is accomplished by
| | module_init() without #ifdef bracket. If the module is compiled
| | into the kernel, do_initcalls
I'm assuming moving parport drivers down the list to after usb wont
break them, though.
Can you compile uss720 into the kernel if you don't do that?
Regards
Oliver
---
This sf.net email is sponsored by: To learn
Date: Fri, 15 Nov 2002 14:38:05 -0500 (EST)
From: Duncan Haldane [EMAIL PROTECTED]
| Also, the order in which cpia and usbcore are listed in the Makefile
| is significant, it determines the order in which do_initcalls
| calls them in case of them being 'y'.
The case is both cpia and usb
I'm assuming moving parport drivers down the list to after usb wont
break them, though.
Can you compile uss720 into the kernel if you don't do that?
I'll test.
But how about just moving DRIVERS +=/drivers/usb/usbdrv.o much higher up the Makefile
DRIVERS list? or adding usb_init()
On Fri, 15 Nov 2002 [EMAIL PROTECTED] wrote:
| I'm assuming moving parport drivers down the list to after usb wont
| break them, though.
|
| Can you compile uss720 into the kernel if you don't do that?
|
|
| I'll test.
|
| But how about just moving DRIVERS +=/drivers/usb/usbdrv.o much
Is there support for the Belkin F5U222 PCMCIA-USB adapter?
I don't see it on the device list, but I can always hope...
I want to play with my USB stuff on my (old) notebook... but
since I am doing development work on a USB driver, would this be
a silly plan to add another device into the mix?
Am Freitag, 15. November 2002 22:09 schrieb [EMAIL PROTECTED]:
I'm assuming moving parport drivers down the list to after usb wont
break them, though.
Can you compile uss720 into the kernel if you don't do that?
I'll test.
But how about just moving DRIVERS +=/drivers/usb/usbdrv.o
Hi
I'm writing a driver based on usb-skelton.c.This is
my problem
I need to read/write chunks of data, but in the
skel_write() function(usb-skelton.c) the maximum data
I can read/write is 512.What is teh best way to add
this feature?
1. split data as 512 chunks inside this function and
On Fri, 2002-11-15 at 19:56, Pete Zaitcev wrote:
I wrote Randy and proposed to move cpia_usb.c over to the
drivers/usb directory. The problem is that supporting
dependencies between drivers/media and drivers/usb is fragile:
someone can break them later as a side effect.
That media is not
On 16 Nov 2002, Alan Cox wrote:
| On Fri, 2002-11-15 at 19:56, Pete Zaitcev wrote:
| I wrote Randy and proposed to move cpia_usb.c over to the
| drivers/usb directory. The problem is that supporting
| dependencies between drivers/media and drivers/usb is fragile:
| someone can break them
On 15-Nov-2002 Pete Zaitcev wrote:
I wrote Randy and proposed to move cpia_usb.c over to the
drivers/usb directory. The problem is that supporting
dependencies between drivers/media and drivers/usb is fragile:
someone can break them later as a side effect.
OK. I tested this and it seems
On Fri, 15 Nov 2002, Duncan Haldane wrote:
| On 15-Nov-2002 Pete Zaitcev wrote:
|
| I wrote Randy and proposed to move cpia_usb.c over to the
| drivers/usb directory. The problem is that supporting
| dependencies between drivers/media and drivers/usb is fragile:
| someone can break them
On 16-Nov-2002 Alan Cox wrote:
On Fri, 2002-11-15 at 19:56, Pete Zaitcev wrote:
I wrote Randy and proposed to move cpia_usb.c over to the
drivers/usb directory. The problem is that supporting
dependencies between drivers/media and drivers/usb is fragile:
someone can break them later as a
21 matches
Mail list logo
