[linux-usb-devel] HP Laserjet 1200

2001-12-13 Thread François Patte
Bonjour, I have just read the thread about this printer, is the change of code in printer.c is now available? I have to install linux on a station with this printer. Thank you. -- François Patte. UFR de mathématiques et informatique. 45 rue des St Pères. 75270 Paris Cedex 06 Tél: 01 44 55

Re: [linux-usb-devel] HP Laserjet 1200

2001-12-13 Thread David Paschal
François Patte wrote: I have just read the thread about this printer, is the change of code in printer.c is now available? I have to install linux on a station with this printer. Hi, François. I have a hacked version that has this change in it. See

[linux-usb-devel] why firmware reload must be in kernel space

2001-12-13 Thread Oliver.Neukum
Hi people, it seems my explanation was too short. Firstly, let me clarify that the problem is with _reloading_ firmware due to resumption from power management. During resumption from power save, our ability to allocate memory is severly constrained. We may allocate memory only with GFP_NOIO

[linux-usb-devel] Re: [Linux-IrDA] Re: Re : problem with irda-usb

2001-12-13 Thread Erez Doron
hi thanks all for replying. both usb-irda and usb-ir load automatically usb-ir tells me to use /dev/usb/ttyUSB0 ok , i do: rmmod usb-ir usb-irda irda modprobe usb-irda irattach irda0 -s 1 irdadump hotsync ... it works !!! ( irdadump shows palm III Irobex ) thank you very much erez.

Re: [linux-usb-devel] why firmware reload must be in kernel space

2001-12-13 Thread Oliver.Neukum
To summarise, we can either have firmware handling in user space or power management, but not both. More philosophically speaking, IMHO we have a classical layering violation caused by wishful thinking. To quote Dave: There are many good reasons to have device handling in kernel

Re: [linux-usb-devel] why firmware reload must be in kernel space

2001-12-13 Thread Oliver.Neukum
On Thu, 13 Dec 2001, Martin Diehl wrote: On Thu, 13 Dec 2001 [EMAIL PROTECTED] wrote: Firstly, let me clarify that the problem is with _reloading_ firmware due to resumption from power management. Absolutely. But note, that is not the only problem: If the driver has to manage dynamic

Re: [linux-usb-devel] why firmware reload must be in kernel space

2001-12-13 Thread David Brownell
To summarise, we can either have firmware handling in user space or power management, but not both. What specific devices that have this problem? They'd seem broken. Are they important enough that they deserve to torque the USB subsystem in this way? Why are they discarding their firmware,

Re: [linux-usb-devel] why firmware reload must be in kernel space

2001-12-13 Thread Oliver.Neukum
On Thu, 13 Dec 2001, David Brownell wrote: To summarise, we can either have firmware handling in user space or power management, but not both. What specific devices that have this problem? Any storage or communication device that is buspowered and needs a firmware download. They'd seem

Re: [linux-usb-devel] why firmware reload must be in kernel space

2001-12-13 Thread Oliver.Neukum
And if your swap device is mounted over nfs through a ppp connection on a usb-serial device that needs firmware downloaded to it, you deserve any problems that this might cause :) For a serial device you are probably right. For eg a DSL device you are not right. I'll join the discussion

[linux-usb-devel] Re: PATCH: hcd infrastructure [part 1]

2001-12-13 Thread Greg KH
On Wed, Dec 12, 2001 at 05:38:32PM -0800, David Brownell wrote: Here's a patch against 2.5.1-pre10 that adds the hcd framework into usbcore. Things that aren't done yet: * Some usb.c code is only for HC driver support, and should move into hcd.c. * The same goes for some

[linux-usb-devel] USB drivers and suspend ...

2001-12-13 Thread David Brownell
I'm curious what examples we have of cases where drivers need to do intelligent things at particular levels of suspend. One comes to mind: The hub driver should disconnect all devices connected to some bus-powered hubs, at least for suspend states where the root hub powers down. (I think that's

[linux-usb-devel] Re: PATCH: hcd infrastructure [part 1]

2001-12-13 Thread David Brownell
I added hcd.c and hcd.h to my tree, but will leave them out of the build in the Makefile, as no code needs them yet. Is that ok? I'd actually rather it were in the build, but in any case I plan to send in either EHCI-hcd or OHCI-hcd before much longer anyway. Leaving things out of builds

[linux-usb-devel] [PATCH 2 of 5] USB usbnet driver update

2001-12-13 Thread Greg KH
Hi, Here's a patch against 2.5.1-pre11 to make sure nfs over the usbnet driver does not deadlock. It was done by Oliver Neukum. thanks, greg k-h diff -Nru a/drivers/usb/usbnet.c b/drivers/usb/usbnet.c --- a/drivers/usb/usbnet.c Thu Dec 13 12:52:39 2001 +++ b/drivers/usb/usbnet.c

[linux-usb-devel] [PATCH 3 of 5] USB vicam driver added

2001-12-13 Thread Greg KH
Hi, Here's a patch against 2.5.1-pre11 that adds the USB vicam driver. The driver was written by Christopher Cheney and Pavel Machek. thanks, greg k-h diff -Nru a/Documentation/Configure.help b/Documentation/Configure.help --- a/Documentation/Configure.help Thu Dec 13 12:52:38 2001 +++

[linux-usb-devel] [PATCH 4 of 5] USB usbfs update

2001-12-13 Thread Greg KH
Hi, Here's a patch against 2.5.1-pre11 from me that makes the usbdevfs use the vfs much better. It also removes the usbdevfs structures from the inode and superblock structures, and fixes a bug in which the special files were not getting updated when a USB driver was registered or deregistered.

[linux-usb-devel] [PATCH 5 of 5] USB hcd driver added

2001-12-13 Thread Greg KH
Hi, Here's a patch against 2.5.1-pre11 that adds the generic USB HCD code to the tree. This code was written by David Brownell. thanks, greg k-h diff -Nru a/drivers/usb/hcd.c b/drivers/usb/hcd.c --- /dev/null Wed Dec 31 16:00:00 1969 +++ b/drivers/usb/hcd.c Thu Dec 13 12:52:39 2001 @@

[linux-usb-devel] Re: PATCH: hcd infrastructure [part 1]

2001-12-13 Thread Greg KH
On Thu, Dec 13, 2001 at 01:45:48PM -0800, David Brownell wrote: I added hcd.c and hcd.h to my tree, but will leave them out of the build in the Makefile, as no code needs them yet. Is that ok? I'd actually rather it were in the build, but in any case I plan to send in either EHCI-hcd or

[linux-usb-devel] Re: [Linux-IrDA] Re: Re : problem with irda-usb

2001-12-13 Thread Jean Tourrilhes
On Thu, Dec 13, 2001 at 02:21:16PM +0200, Erez Doron wrote: .cs.UiT.No CC: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: [Linux-IrDA] Re: Re : problem with irda-usb References: [EMAIL PROTECTED] [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding:

[linux-usb-devel] Re: [Linux-IrDA] Re: Re : problem with irda-usb

2001-12-13 Thread Greg KH
On Thu, Dec 13, 2001 at 09:46:21AM -0800, Jean Tourrilhes wrote: What do yoy mean that they load automatically ? Moreover, I'm confused because usb-irda doesn't exist over here... Greg, I'm willing to give you the benefit of the doubt, but if usb-ir *really* load automatically

Re: [linux-usb-devel] Re: [Linux-IrDA] Re: Re : problem with irda-usb

2001-12-13 Thread David Brownell
both usb-irda and usb-ir load automatically What do yoy mean that they load automatically ? Probably: they both get hotplugged. There's an /etc/hotplug/blacklist file, you might try listing the driver(s) you _don't_ want in that file. In the example from Erez, usb-ir. - Dave