Add the USB HID quirk HID_QUIRK_SONY_PS3_CONTROLLER. This sends an
HID_REQ_GET_REPORT to the the PS3 controller to put the device into
'operational mode'.
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
drivers/usb/input/hid-core.c | 34 ++
include/linux/hi
USB OHCI driver bus glue for the PS3 game console.
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig|3
drivers/usb/host/ohci-hcd.c | 21
drivers/usb/host/ohci-ps3.c | 196
3 files changed, 219 insertions(+)
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Restructure the ohci_hcd_mod_init error handling code in to better support
the multiple platform drivers. This does not change the functionality.
Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Signed-off-by: Geoff Levand <[EMAIL PROTEC
This set of four patches adds support for the PS3 game
console. Please consider for inclusion in 2.6.21.
-Geoff
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the c
Add the USB HID quirk HID_QUIRK_SONY_PS3_CONTROLLER. This sends an
HID_REQ_GET_REPORT to the the PS3 controller to put the device into
'operational mode'.
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
drivers/usb/input/hid-core.c | 34 ++
include/linux/hi
USB EHCI driver bus glue for the PS3 game console.
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig|2
drivers/usb/host/ehci-hcd.c | 25 +
drivers/usb/host/ehci-ps3.c | 193
3 files changed, 219 insertions(+
This set of four patches adds support for the PS3 game
console. Please consider for inclusion in 2.6.21.
-Geoff
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the
from: Kevin Lloyd <[EMAIL PROTECTED]>
This patch ensures that the device is turned on when inserted into the
system (which mostly affects the EM5725 and MC5720. It also adds more
VID/PIDs and matches the N_OUT_URB with the airprime driver.
Signed-off-by: Kevin Lloyd <[EMAIL PROTECTED]>
---
--
> + *Called when opening the input device. This will submit the URB to
> + *the usb system so we start getting reports
> + */
> +static int gtco_input_open(struct input_dev *inputdev)
> +{
> + struct gtco *device;
> + device = inputdev->private;
> +
> + /* Prevent us from sub
From: Jeremy Roberson <[EMAIL PROTECTED]>
Added a kernel module (gtco) to the USB Input subsystem. This kernel
module adds support for all GTCO CalComp USB InterWrite School products.
Signed-off-by: Jeremy A. Roberson <[EMAIL PROTECTED]>
---
diff -uprN a/drivers/usb/input/gtco.c b/drivers/usb/
On Friday 05 January 2007 10:33 am, Oliver Neukum wrote:
> >
> > Are all of these prototypes really needed?
>
> Yes. Compilation breaks without them.
No. Fixable by a better sequencing of functions.
Maybe one or two should be needed, at most; it's
unusual to need more than that, and atypical t
On Friday 12 January 2007 2:12 pm, Alan Stern wrote:
> On the other hand, I did find (another) bug in the async I/O handling in
> inode.c. If you aren't using the AIO code in usb.c then it shouldn't
> affect you, but you might want to give it a try anyway.
Alan, could you explain what the bug
From: "Phil Endecott" <[EMAIL PROTECTED]>
Gadgetfs had a mode in which endpoint descriptors were written by the user
program before connection. This mode had some bugs, and hasn't seen much
(if any) use. This patch removes that mode, leaving the mode of operation
where the user program waits for
Remove some whitespace bugs in gadgetfs (mostly from someone's
patch updating the AIO support).
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
Index: at91/drivers/usb/gadget/inode.c
===
--- at91.orig/drivers/usb/gadget/inode.c
On Monday 15 January 2007 9:11 am, Phil Endecott wrote:
> David Brownell wrote:
> > Further testing on my system turned up more information:
> >
> > - The string fetches done during device enumeration fail sometimes too.
> >This leads to delays, timeouts, resubmissions ... it's not just these
On Mon, Jan 15, 2007 at 11:03:35AM -0500, Alan Stern wrote:
> On Mon, 15 Jan 2007, Oliver Neukum wrote:
>
> > Am Sonntag, 14. Januar 2007 20:47 schrieb [EMAIL PROTECTED]:
> > > > Can anyone suggest another approach?
> > > >
> > > > Alan Stern
> > >
> > > Just a thought, you could use both a black
David Brownell wrote:
> Further testing on my system turned up more information:
>
> - The string fetches done during device enumeration fail sometimes too.
>This leads to delays, timeouts, resubmissions ... it's not just these
>cases in test #10. Do you see messages about khubd timeouts
On Mon, 15 Jan 2007, Oliver Neukum wrote:
> Am Montag, 15. Januar 2007 17:03 schrieb Alan Stern:
> > On Mon, 15 Jan 2007, Oliver Neukum wrote:
>
> > > Upon further thought, a module parameter won't do as the problem
> > > will arise without a driver loaded. A sysfs parameter turns the whole
> > >
Am Montag, 15. Januar 2007 17:03 schrieb Alan Stern:
> On Mon, 15 Jan 2007, Oliver Neukum wrote:
> > Upon further thought, a module parameter won't do as the problem
> > will arise without a driver loaded. A sysfs parameter turns the whole
> > affair into a race condition. Will you set the guard p
Am Montag, 15. Januar 2007 16:34 schrieb David Brownell:
> On Monday 15 January 2007 2:05 am, Oliver Neukum wrote:
> > // as long as data wanted
> > down_interruptible(&dev->sem_wantdata);
> >
> > You cannot use semaphores in interrupt context. Please read the kernel
> > documentation abou
On Mon, 15 Jan 2007, Oliver Neukum wrote:
> Am Sonntag, 14. Januar 2007 20:47 schrieb [EMAIL PROTECTED]:
> > > Can anyone suggest another approach?
> > >
> > > Alan Stern
> >
> > Just a thought, you could use both a blacklist approach, and a module
> > paramater, or something in sysfs, to allow
On Sun, 14 Jan 2007, Florin Iucha wrote:
> Jiri and Trond,
>
> On Mon, Jan 15, 2007 at 01:14:09AM +0100, Jiri Kosina wrote:
> > On Sun, 14 Jan 2007, Florin Iucha wrote:
> >
> > > All the testing was done via a ssh into the workstation. The console
> > > was left as booted into, with the gdm ru
On Sun, Jan 14, 2007 at 11:11:13PM -0300, Horst H. von Brand wrote:
> Florin Iucha <[EMAIL PROTECTED]> wrote:
>
> [...]
>
> > Based on this info, I think we can rule out any USB. I will try
> > testing with NFS3 to see if the problem persists. Unfortunately there
> > is no oops or anything in "
On Monday 15 January 2007 2:05 am, Oliver Neukum wrote:
> // as long as data wanted
> down_interruptible(&dev->sem_wantdata);
>
> You cannot use semaphores in interrupt context. Please read the kernel
> documentation about spinlocks and locking in general.
ISTR that you can up() a sem
On Monday 15 January 2007 3:35 am, Phil Endecott wrote:
>
> Actually this varies from run to run. The most common case is for subtest 2
> to fail;
> subtest 12 has failed in just a couple of runs.
Those are the only two calls in that test which go up to userspace.
> In most cases it also re
Florin Iucha <[EMAIL PROTECTED]> wrote:
[...]
> Based on this info, I think we can rule out any USB. I will try
> testing with NFS3 to see if the problem persists. Unfortunately there
> is no oops or anything in "dmesg".
Take a look at bz #7796, a NFS bug + fix. But my feelin is that this is
o
Earlier I wrote:
> Jan 15 11:15:18 egypt kernel: drivers/usb/misc/usbtest.c: subtest 12 error,
> status -71
> Jan 15 11:15:18 egypt kernel: drivers/usb/misc/usbtest.c: control queue
> 80.06, err -71, 28516 left
> Jan 15 11:15:18 egypt kernel: drivers/usb/misc/usbtest.c: subcase 13
> completed ou
David Brownell wrote:
> On Monday 08 January 2007 5:55 am, Phil Endecott wrote:
>> # ./testusb -D /proc/bus/usb/004/010 -t10
>> (Never completes, no output)
>> dmesg:
>>
>> Jan 8 12:37:38 egypt kernel: usbtest 4-4:3.0: TEST 10: queue 32
>> control calls, 1000 times
>> (no further output)
>
> Ac
Am Sonntag, 14. Januar 2007 20:47 schrieb [EMAIL PROTECTED]:
> > Can anyone suggest another approach?
> >
> > Alan Stern
>
> Just a thought, you could use both a blacklist approach, and a module
> paramater, or something in sysfs, to allow specifying devices that won't
> be suspend and resume co
Am Montag, 15. Januar 2007 09:10 schrieb Guenther Sohler:
> Unfortunately it does not work yet. It hangs as soon the driver internally
> sees the first data arriving via USB cable.
>
> Could anybody have a look at the code to see if there are basic mistakes ?
static void openradio_read_bulk_cal
Hallo,
I have got a FX2 Board from Cypress, which is connected to the PC
using USB2.0.
My goal is to get quite a big bandwidth transmitted from the FX2 to the PC
(my goal is actually about 15 MB/s, and many people told me that this is
posible)
My first attemts have been using libusb with a progr
31 matches
Mail list logo
