- 17 2月, 2007 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
A simple driver to turn on the charging capability of a USB BlackBerry device when it is plugged into the machine. It does not bind to the device, so all userspace programs can still sync properly with it. Note, if CONFIG_USB_SUSPEND is enabled, it can play havoc with this device as the power to the port will be shut down. This device id will have to be added to the global blacklist table when it is created. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 02 12月, 2006 1 次提交
-
-
由 Adrian Bunk 提交于
We do already have both the code and a config option, so why not build this driver? ;-) Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 18 10月, 2006 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
It's not a input driver, so it doesn't belong in the input directory. Cc: Sam Hocevar <sam@zoy.org> Cc: Dmitry Torokhov <dtor@insightbb.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 28 9月, 2006 4 次提交
-
-
由 Tony Olech 提交于
This "ftdi-elan" module is one half of the "driver" for ELAN's Uxxx series adapters which are USB to PCMCIA CardBus adapters. Currently only the U132 adapter is available and it's module is called "u132-hcd". When the USB hot plug subsystem detects a Uxxx series adapter it should load this module. Upon a successful device probe() the jtag device file interface is created and the status workqueue started up. The jtag device file interface exists for the purpose of updating the firmware in the Uxxx series adapter, but as yet it had never been used. The status workqueue initializes the Uxxx and then sits there polling the Uxxx until a supported PCMCIA CardBus device is detected it will start the command and respond workqueues and then load the module that handles the device. This will initially be only the u132-hcd module. The status workqueue then just polls the Uxxx looking for card ejects. The command and respond workqueues implement a command sequencer for communicating with the firmware on the other side of the FTDI chip in the Uxxx. This "ftdi-elan" module exports some functions to interface with the sequencer. Note that this module is a USB client driver. Note that the "u132-hcd" module is a (cut-down OHCI) host controller. Thus we have a topology with the parent of a host controller being a USB client! This really stresses the USB subsystem semaphore/mutex handling in the module removal. Signed-off-by: NTony Olech <tony.olech@elandigitalsystems.com> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Steven Haigh 提交于
This patch adds support for Ontrak ADU USB devices. Fixed for printk issues by Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: NSteven Haigh <netwiz@crc.id.au> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Sean Young 提交于
This patch creates a device class phidget and add the phidget drivers to them. Signed-off-by: NSean Young <sean@mess.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 Sean Young 提交于
This driver add support for the Phidgets Inc., MotorControl via sysfs. Also some minor fixes for the InterfaceKit. Signed-off-by: NSean Young <sean@mess.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 13 7月, 2006 1 次提交
-
-
由 Oliver Bock 提交于
This is a new driver for the Cypress CY7C63xxx mirco controller series. It currently supports the pre-programmed CYC63001A-PC by AK Modul-Bus GmbH. It's based on a kernel 2.4 driver (cyport) by Marcus Maul which I ported to kernel 2.6 using sysfs. I intend to support more controllers of this family (and more features) as soon as I get hold of the required IDs etc. Please see the source code's header for more information. Signed-off-by: NOliver Bock <o.bock@fh-wolfenbuettel.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 22 6月, 2006 2 次提交
-
-
由 Oliver Bock 提交于
This is a new driver for the Cypress CY7C63xxx mirco controller series. It currently supports the pre-programmed CYC63001A-PC by AK Modul-Bus GmbH. It's based on a kernel 2.4 driver (cyport) by Marcus Maul which I ported to kernel 2.6 using sysfs. I intend to support more controllers of this family (and more features) as soon as I get hold of the required IDs etc. Please see the source code's header for more information. Signed-off-by: NOliver Bock <o.bock@fh-wolfenbuettel.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
由 akpm@osdl.org 提交于
This is a driver to control the brightness of an Apple Cinema Display over USB. It updates the local brightness value if the user presses a button on the display. Signed-off-by: NMichael Hanselmann <linux-kernel@hansmi.ch> Cc: Oliver Neukum <oliver@neukum.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 18 11月, 2005 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
This lets us remove a lot of code in the drivers that were all checking the same thing. It also found some bugs in a few of the drivers, which has been fixed up. Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 13 7月, 2005 1 次提交
-
-
由 Michael Hund 提交于
The following driver provides complete interrupt-in and interrupt-out reports (raw data) to a user program. Until now it uses the HIDIOCGDEVINFO ioctl call, because I don't know better :-(. Perhaps, it will be ok for you - and I will be happy, if you assign 8 minor numbers. I have tested it in several environments and it works very well for me. However, it has a problem with two or more devices at the same hub, if the two or more devices need 1 ms interrupt-in transfers. Unfortunately more than one interrupt-in transfer every ms isn't possible (ehci driver?). This is why the min_interrupt_in_interval and min_interrupt_out_interval are increased to 2 ms (see the corresponding module parameters). This way, I can use two devices simultaneously at the same hub. Signed-off-by: NMichael Hund <mhund@ld-didactic.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 17 4月, 2005 1 次提交
-
-
由 Linus Torvalds 提交于
Initial git repository build. I'm not bothering with the full history, even though we have it. We can create a separate "historical" git archive of that later if we want to, and in the meantime it's about 3.2GB when imported into git - space that would just make the early git days unnecessarily complicated, when we don't have a lot of good infrastructure for it. Let it rip!
-