On Friday 01 February 2008, Greg Kroah-Hartman wrote:
> From: Marcin Slusarz <[EMAIL PROTECTED]>
>
> fix warning:
> drivers/usb/host/ehci-hcd.c:832:8: warning: symbol 'status' shadows an
> earlier one
> drivers/usb/host/ehci-hcd.c:790:71: originally declared here
>
> Signed-off-by: Marcin Slusar
This limits how long the OHCI port reset loop waits for the hardware
to do its job, if the controller either (a) dies, or (b) can't finish
the reset. Such limits are always a good idea.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
This patch from November seems to have gotten misplaced.
On Fri, 25 Jan 2008 10:02:32 -0800
Greg KH <[EMAIL PROTECTED]> wrote:
> FYI, this is a patch that will be sent out in the next round to Linus
> for inclusion in 2.6.25.
>
> If anyone has any objections about it, please let me know.
Yes, I have objections and I've told you before.
> Over two y
Hi Oliver,
Am Freitag, 1. Februar 2008 15:52:37 schrieben Sie:
> this should implement autosuspend. Could you please test it?
> It's against 1.0.6.
I still don't know yet, what usb autosuspend really does and how I have to
control /sys/bus/usb/devices/*/power/autosuspend.
But anyway... the new f
On Sat, Feb 02, 2008 at 02:36:53AM -0800, David Brownell wrote:
> On Friday 01 February 2008, Greg Kroah-Hartman wrote:
> > From: Marcin Slusarz <[EMAIL PROTECTED]>
> >
> > fix warning:
> > drivers/usb/host/ehci-hcd.c:832:8: warning: symbol 'status' shadows an
> > earlier one
> > drivers/usb/host
On Sat, Feb 02, 2008 at 12:37:10PM +0100, Christer Weinigel wrote:
> On Fri, 25 Jan 2008 10:02:32 -0800
> Greg KH <[EMAIL PROTECTED]> wrote:
>
> > FYI, this is a patch that will be sent out in the next round to Linus
> > for inclusion in 2.6.25.
> >
> > If anyone has any objections about it, plea
A bug every C programmer makes at some point in time...
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/gadget/printer.c b/drivers/usb/gadget/printer.c
index 9fdabc8..4f6bfa1 100644
--- a/drivers/usb/gadget/printer.c
+++ b/drivers/usb/gadget/printer.c
@@ -1299,7 +1299,
On Fri, 2008-02-01 at 15:17 -0800, Greg Kroah-Hartman wrote:
> Note, the module-init-tools package also needs to be changed to properly
> generate the depmod tables.
Noted.
Jon.
-
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [EMAIL PROTECTED]
On Sat, 2 Feb 2008, Robert Spitzenpfeil wrote:
> if I understand right you wanted me to make my system mimic this:
>
> Loop 3 times {
> Get-Max-LUN => STALL
> clear-halt(ep0)
> }
>
> I don't know how to hack usb-storage to run this very l
Hi,
I am implementing a driver for Razer USB mice. These
mice are standard HID input devices with additional features
accessible through USB control commands.
My current prototype driver does this access in userspace
via libusb, but this brings all kinds of issues while the
kernel driver and othe
On Sat, Feb 02, 2008 at 11:31:02PM +0100, Michael Buesch wrote:
> Hi,
>
> I am implementing a driver for Razer USB mice. These
> mice are standard HID input devices with additional features
> accessible through USB control commands.
>
> My current prototype driver does this access in userspace
>
On Sat, 2 Feb 2008, Michael Buesch wrote:
> I am implementing a driver for Razer USB mice. These mice are standard
> HID input devices with additional features accessible through USB
> control commands.
Hi Michael,
what do the control commands look like? (or is there the source code of
your d
On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote:
> IMO this indicates we shouldn't issue any clear-halts at all unless the
> device actually needs it. In general it's not a good idea to do a
> clear-halt for an endpoint that isn't actually halted; devices are
> prone to misinterpret
On Sunday 03 February 2008 00:05:21 Jiri Kosina wrote:
> On Sat, 2 Feb 2008, Michael Buesch wrote:
>
> > I am implementing a driver for Razer USB mice. These mice are standard
> > HID input devices with additional features accessible through USB
> > control commands.
>
> Hi Michael,
>
> what d
On Saturday 02 February 2008 23:46:29 Greg KH wrote:
> On Sat, Feb 02, 2008 at 11:31:02PM +0100, Michael Buesch wrote:
> > Hi,
> >
> > I am implementing a driver for Razer USB mice. These
> > mice are standard HID input devices with additional features
> > accessible through USB control commands.
On Sun, 3 Feb 2008, Michael Buesch wrote:
> Here's the current userspace implementation of the HAL:
> http://bu3sch.de/gitweb?p=razer.git;a=blob;f=librazer/hw_deathadder.c;h=e76d9347552eb5ea33b524a82e33ba869f3e0b3f;hb=HEAD
> The commands changed slightly in latest firmware version and there's
> a
Thanks for catching that :^)
Craig Nadler
Adrian Bunk wrote:
A bug every C programmer makes at some point in time...
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
diff --git a/drivers/usb/gadget/printer.c b/drivers/usb/gadget/printer.c
index 9fdabc8..4f6bfa1 100644
--- a/drivers/usb/gadg
On Sunday 03 February 2008 00:39:26 Jiri Kosina wrote:
> On Sun, 3 Feb 2008, Michael Buesch wrote:
>
> > Here's the current userspace implementation of the HAL:
> > http://bu3sch.de/gitweb?p=razer.git;a=blob;f=librazer/hw_deathadder.c;h=e76d9347552eb5ea33b524a82e33ba869f3e0b3f;hb=HEAD
> > The comm
On Sat, 2 Feb 2008, Matthew Dharm wrote:
> On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote:
> > IMO this indicates we shouldn't issue any clear-halts at all unless the
> > device actually needs it. In general it's not a good idea to do a
> > clear-halt for an endpoint that isn't actu
On Sat, Feb 02, 2008 at 10:30:51PM -0500, Alan Stern wrote:
> On Sat, 2 Feb 2008, Matthew Dharm wrote:
>
> > On Sat, Feb 02, 2008 at 05:12:29PM -0500, Alan Stern wrote:
> > > IMO this indicates we shouldn't issue any clear-halts at all unless the
> > > device actually needs it. In general it's n
20 matches
Mail list logo
