> > Don't introduce a config option. If you do this by ifdef, use ifdef on
> > the arches that you used as default. On those arches the memmove is
> > definitely a win.
> > You could even test it unconditionally on i386 or x86_64. A copy may be
> > faster than keeping it in place, as you touch the
> > > Don't introduce a config option. If you do this by ifdef, use ifdef
> > > on the arches that you used as default. On those arches the memmove
> > > is definitely a win.
> > > You could even test it unconditionally on i386 or x86_64. A copy may
> > > be faster than keeping it in place, as you
Hello,
I think there is a possible issue in the mon_get_event and mon_read
functions:
On Tue, 2006-11-21 at 22:56 -0800, Pete Zaitcev wrote:
[...]
> + mutex_lock(&rp->fetch_lock);
> +
> + add_wait_queue(&rp->b_wait, &waita);
> + set_current_state(TASK_INTERRUPTIBLE);
> +
> + spin_
On Thu, Nov 23, 2006 at 05:12:00PM +0100, [EMAIL PROTECTED] wrote:
> From: Nicolas DET <[EMAIL PROTECTED]>
Hm, is this really from you? The copyright doesn't look like it.
I need a signed-off-by: please, along with a good description of what
the patch does.
thanks,
greg k-h
--
On Thu, Nov 23, 2006 at 03:37:08PM +, Alan wrote:
> A small number of USB serial drivers are intercepting TCGETS/TCSETS
> ioctls. All of those that do this are broken.
>
> Specifically
> mos7840.c
> kl5kusb105.c
> kobil_sct.c
> cypress_m8.c
>
> I would be greatful if
On Thu, Nov 23, 2006 at 10:12:08AM +0100, [EMAIL PROTECTED] wrote:
> Hi,
>
> I want to implement a usb host device driver that uses major number 61 and
> minor numbers 1 to 14.
Why would a host driver need a major number, or even a minor number?
You don't directly access them at all.
> I have de
Am Freitag, 24. November 2006 09:48 schrieb Nikita V. Youshchenko:
> I can't do such a test myself - I'm doing my job remotely so I don't have
> physical access to hardware, and people for whom I work are definitly not
> interested in such things so they won't set up needed environment.
Neither
Carsten Beth wrote:
> 1) I found that there is a newer audio device class defined, the
> "Universal Serial Bus Device Class Definition for Audio Devices",
> Release 2.0, May 31, 2006.
I've never heard of this release 2.0 before.
> Are there plans to support this device class in the kernel in the
Hi,
in disconnect you set the interface's private data to NULL. In your IO
methods you unconditionally follow the pointer into never never land.
Regards
Oliver
Signed-off-by: Oliver Neukum <[EMAIL PROTECTED]>
--- drivers/usb/misc/trancevibrator.c~ 2006-11-16 05:03:40.00
hi Pete,
In the hope to make your work easier/faster I merged the latest fix
signaled on the mailing list, the mmap implementation, the mfetch and
mflush ioctl methods, and reworked mon_bin_get_event and mon_bin_read to
use a common helper function to wait for data on the ring buffer.
This is th
From: Nicolas DET <[EMAIL PROTECTED]>
Add USB/OHCI glue for OpenFirmware devices. It takes advantages of the new
of_platform.
This new glue takes advantage of the new of_platform to probe any OHCI
node available into an OpenFirmware device tree and then load and
startup an OHCI HC.
This is particu
This patch adds USB/OHCI HC glue for OpenFirmware. This allows to support any
kind of USB/OHCI controller which is present in an OpenFirmware device tree.
I added a correct description. This code is half copy/paste from
ohci-ppc-soc.c. I added the ofplatform specific part. It has been succefully
On Fri, 24 Nov 2006 09:52:46 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> Before returning the mutex 'fetch_lock' is hold, shouldn't it be
> released ?!?
Thanks, I fixed this by factoring the waiting. I am getting sloppy
with the haste, sorry.
-- Pete
---
On Thu, 23 Nov 2006, DervishD wrote:
> > > kernel: SCSI disk error : host 0 channel 0 id 0 lun 0 return code =
> > > 802
> > > kernel: Current sd08:01: sns = 70 4
> > > kernel: ASC=4b ASCQ= 0
> > > kernel: Raw sense data:0x70 0x00 0x04 0x00 0x00 0x00 0x00 0x0a 0x00
> > >
On Fri, 24 Nov 2006, Oliver Neukum wrote:
> --- drivers/usb/misc/trancevibrator.c~2006-11-16 05:03:40.0
> +0100
> +++ drivers/usb/misc/trancevibrator.c 2006-11-24 12:30:29.0 +0100
> @@ -120,8 +120,8 @@
> struct trancevibrator *dev;
>
> dev = usb_get_intfdata
Sorry for the late reply. I had overlooked this.
Am 08.11.2006 15:34 schrieb Mariusz Kozlowski:
> Hello,
>
> - usb_free_urb() cleanup
> - usb_kill_urb() cleanup
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
Acked-by: Tilman Schmidt <[EMAIL PROTECTED]>
> --- linux-2.6.19-rc4-orig/dri
Am Freitag, 24. November 2006 18:44 schrieb Alan Stern:
> On Fri, 24 Nov 2006, Oliver Neukum wrote:
>
> > --- drivers/usb/misc/trancevibrator.c~ 2006-11-16 05:03:40.0
> > +0100
> > +++ drivers/usb/misc/trancevibrator.c 2006-11-24 12:30:29.0
> > +0100
> > @@ -120,8 +120
On Fri, 2006-11-24 at 00:57 -0800, Greg KH wrote:
> On Thu, Nov 23, 2006 at 05:12:00PM +0100, [EMAIL PROTECTED] wrote:
> > From: Nicolas DET <[EMAIL PROTECTED]>
>
> Hm, is this really from you? The copyright doesn't look like it.
>
> I need a signed-off-by: please, along with a good description
On Fri, 24 Nov 2006, Oliver Neukum wrote:
> > By the way, you should be aware that creating an attribute file in the
> > interface's device directory (like dev_attr_speed above) is inherently
> > unsafe. A user process can open the file, hold it open while the driver
> > is unloaded, and then
On Sat, 25 Nov 2006, Benjamin Herrenschmidt wrote:
> Now, Nico, since the patch has obviously a problem (thouh the problem
> might be generic to the way the USB code handles multiple versions of an
> HCI), it cannot be merged as-is of course.
>
> Alan, what is your approach there ? We can't have
> I haven't been following this very closely. The problem is that you have
> a system with two different kinds of OHCI controllers, thus requiring two
> different and incompatible versions of the driver?
Sort-of. Basically, PowerPC can (and must in some case) build a single
kernel image that c
On Fri, 24 Nov 2006 15:00:29 +0100, Paolo Abeni <[EMAIL PROTECTED]> wrote:
> In the hope to make your work easier/faster I merged the latest fix
> signaled on the mailing list, the mmap implementation, the mfetch and
> mflush ioctl methods, and reworked mon_bin_get_event and mon_bin_read to
> use
Am Freitag, 24. November 2006 21:55 schrieb Alan Stern:
> On Fri, 24 Nov 2006, Oliver Neukum wrote:
>
> > > By the way, you should be aware that creating an attribute file in the
> > > interface's device directory (like dev_attr_speed above) is inherently
> > > unsafe. A user process can open t
On Sat, 25 Nov 2006, Oliver Neukum wrote:
> > > > By the way, you should be aware that creating an attribute file in the
> > > > interface's device directory (like dev_attr_speed above) is inherently
> > > > unsafe. A user process can open the file, hold it open while the
> > > > driver
> > >
I just upgraded from a ps2 keyboard to usb and have been getting these
messages seemingly randomly, which also corresponds to whatever key i'm
pressing at the time they occur to act like it's stuck down.
usb 2-2: reset low speed USB device using ohci_hcd and address 3
usb 2-2: reset low sp
On Friday 24 November 2006 22:41, Ed Sweetman wrote:
>I just upgraded from a ps2 keyboard to usb and have been getting these
>messages seemingly randomly, which also corresponds to whatever key i'm
>pressing at the time they occur to act like it's stuck down.
>
>usb 2-2: reset low speed USB device
26 matches
Mail list logo
