Hello,
On the USB ID list, there's the following:
07cf Casio Computer Co., Ltd.
1001 QV-8000SX/3000EX Digicam
2002 E-125 Cassiopeia Pocket PC
This 0x2002 isn't the E-125, it corresponds to the USB cradle itself. Casio
uses the same USB cradle for most of their devices
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-h
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
@@ -0,
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
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
+++
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 Th
Hi,
Here's a patch against 2.5.1-pre11 for the USB catc driver that allows
ethtool to run properly with the driver. It was done by Brad Hards.
thanks,
greg k-h
diff -Nru a/drivers/usb/catc.c b/drivers/usb/catc.c
--- a/drivers/usb/catc.cThu Dec 13 12:52:39 2001
+++ b/drivers/usb/catc
> 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 le
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
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
> > What specific devices that have this problem?
>
> Any storage or communication device that is buspowered and needs
> a firmware download.
And for which bus power was removed by the suspend,
I think you meant to add. For example, ones connected
to bus-powered hubs.
> > Why are they discard
> 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 af
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
On Thu, Dec 13, 2001 at 10:55:54AM +0100, [EMAIL PROTECTED] wrote:
> 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.
I just talked with Pat Mochel about this (the person do
> 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
> > 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
_
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 autom
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 dy
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-Enc
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 loading of different overlaid firmware images at
> > 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
> >
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.
Gre
On Thu, Dec 13, 2001 at 10:55:54AM +0100, [EMAIL PROTECTED] wrote:
> 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
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 or
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 "http://hpoj.sourceforge.net/download/ex
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 35
26 matches
Mail list logo
