- 19 Apr, 2005 40 commits
-
-
Linus Torvalds authored
for 11 aoe bugfix patches.
-
Linus Torvalds authored
-
Linus Torvalds authored
Yah, it does work to merge. Knock wood.
-
ecashin@coraid.com authored
I can't use list.h, since sk_buff doesn't have a list_head but instead has two struct sk_buff pointers, and I want to avoid any extra memory allocation. send outgoing packets in order Signed-off-by:
Ed L. Cashin <ecashin@coraid.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@suse.de>
-
ecashin@coraid.com authored
add support for disk statistics Signed-off-by:
-
ecashin@coraid.com authored
add note about the need for deadlock-free sk_buff allocation Signed-off-by:
-
ecashin@coraid.com authored
document env var for specifying number of partitions per dev Signed-off-by:
-
ecashin@coraid.com authored
Alexey Dobriyan sparse cleanup Signed-off-by:
Alexey Dobriyan <adobriyan@mail.ru> Signed-off-by:
-
ecashin@coraid.com authored
don't try to free null bufpool Signed-off-by:
-
ecashin@coraid.com authored
handle distros that have a udev rules file instead of dir Signed-off-by:
-
ecashin@coraid.com authored
update driver version to 6 Signed-off-by:
-
ecashin@coraid.com authored
allow multiple aoe devices with same MAC addr Signed-off-by:
-
ecashin@coraid.com authored
remove too-low cap on minor number Signed-off-by:
-
Jean Delvare authored
The it87 and via686a hardware monitoring drivers each create a sysfs file named "alarms" in R/W mode, while they should really create it in read-only mode. Since we don't provide a store function for these files, write attempts to these files will do something undefined (I guess) and bad (I am sure). My own try resulted in a locked terminal (where I attempted the write) and a 100% CPU load until next reboot. As a side note, wouldn't it make sense to check, when creating sysfs files, that readable files have a non-NULL show method, and writable files have a non-NULL store method? I know drivers are not supposed to do stupid things, but there is already a BUG_ON for several conditions in sysfs_create_file, so maybe we could add two more? Signed-off-by:
Jean Delvare <khali@linux-fr.org> Signed-off-by:
-
Jean Delvare authored
Here comes a small cleanup patch for the via686a driver. I noticed the following two non-fatal problems: 1* The device parent is explicitely set, but it's not needed because the i2c core will do as the client is registered. 2* snprintf is used where strlcpy would suffice. Fixing them brings the via686a driver in line with what other similar drivers do. Signed-off-by:
-
johnpol@2ka.mipt.ru authored
w1 ID is only 8 bytes long. Signed-off-by:
Evgeniy Polyakov <johnpol@2ka.mipt.ru> Signed-off-by:
-
johnpol@2ka.mipt.ru authored
Real fix for big endian machines - crc must be calculated using little endian byte order. Signed-off-by:
-
James Bottomley authored
-
Viktor A. Danilov authored
[PATCH] USB: fix AIPTEK input doesn`t register `device` & `driver` section in sysfs (/sys/class/input/event#) PROBLEM: aiptek input doesn`t register `device` & `driver` section in sysfs (/sys/class/input/event#) REASON: `dev` - field not filled... SOLUTION: in linux/drivers/usb/input/aiptek.c write aiptek->inputdev.dev = &intf->dev; before calling input_register_device(&aiptek->inputdev); From: "Viktor A. Danilov" <__die@mail.ru> Signed-off-by: -
David Brownell authored
Updates to the Ethernet/RNDIS gadget driver (mostly for RNDIS): - Fix brown-paper bag goof with RNDIS packet TX ... the wrong length field got set, so Windows would ignore data packets it received. - More consistent handling of CDC output filters (but not yet hooking things up so RNDIS uses the mechanism). - Zerocopy RX for RNDIS packets too (saving CPU cycles). - Use the pre-allocated interrupt/status request and buffer, rather than allocating and freeing one of each every few seconds (which could fail). - Some more "sparse" tweaks, making both dual-speed and single-speed configurations happier. - RNDIS speeds are reported in units of 100bps, not bps. Plus two minor cleanups (whitespace, messaging). Signed-off-by:David Brownell <dbrownell@users.sourceforge.net> Signed-off-by:
-
Jesper Juhl authored
Get rid of a bunch of redundant NULL pointer checks in drivers/usb/*, there's no need to check a pointer for NULL before calling kfree() on it. Signed-off-by:
Jesper Juhl <juhl-lkml@dif.dk> Signed-off-by:
-
Jesper Juhl authored
Checking for NULL before calling kfree() is redundant. This patch removes these redundant checks and also makes a few tiny whitespace changes. Signed-off-by:
-
Peter Favrholdt authored
Please accept the attached patch which adds the vendorid 0x0745 and modelid 0x0001 (ID 0745:0001) "Syntech Information Co., Ltd." The device is an USB IR cradle for a barcode scanner (CPT-8001C) from Cipherlab. From: Peter Favrholdt <pfavr@mip.sdu.dk> Signed-off-by: -
Flavio Leitner authored
I'm attaching a patch to fix status when using Siemens X65 mobile. This mobile use first byte instead of normal UART_STATE byte. From: Flavio Leitner <fbl@conectiva.com.br> Signed-off-by: -
Flavio Leitner authored
It's possible to unplug usb device and do tiocmset() and tiocmget() without valid interface in pl2303 module. The patch below check this and return -ENODEV if interface was removed. From: Flavio Leitner <fbl@conectiva.com.br> Signed-off-by: -
Alan Stern authored
In response to complaints about excessive latency in the uhci-hcd driver I'm planning to convert it to a top-half/bottom-half design. It turns out that to do this, the USB API has to be modified slightly since the driver will not be able to meet one of the guarantees in the current API. This patch changes some kerneldoc, specifying the weaker guarantee. Signed-off-by:
Alan Stern <stern@rowland.harvard.edu> Signed-off-by:
-
David Brownell authored
This adds a quirk to the OHCI driver that lets it work with an old Compaq implementation. It also removes some needless strings from the non-debug version of the driver. Signed-off-by:
Chris Clayton <chris_clayton@f1internet.com> Signed-off-by:
-
David Brownell authored
Hmm, another case of a Zaurus ROM not telling the expected conformance lie; this patch handles the lies told by the SL5600. From: bender647@gmail.com Signed-off-by:
-
Thomas Winischhofer authored
the attached patch adds another USB device ID to the list. Seems the device is known under multiple IDs. Signed-off-by:
Thomas Winischhofer <thomas@winischhofer.net> Signed-off-by:
-
felix@derklecks.de authored
Signed-off-by:
Phil Dibowitz <phil@ipom.com> Signed-off-by:
-
Phil Dibowitz authored
This patch changes the delay for the US_FL_GO_SLOW patch from 110us to 125. Some delays need this extra delay includign Jan De Luyck's drive which spawned the original increase from 110 to 110us. 125 is a microframe, so this delay seems to make sense more than just be a random delay (thanks to David Brownell for pointing that out after my original patch). Signed-off-by:
-
akpm@osdl.org authored
On ppc64: drivers/usb/net/usbnet.c: In function `skb_return': drivers/usb/net/usbnet.c:429: warning: int format, different type arg (arg 3) drivers/usb/net/usbnet.c:429: warning: int format, different type arg (arg 3) Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
-
Christopher Li authored
I am sorry that the last patch about 32 bit compat ioctl on 64 bit kernel actually breaks the usbdevfs. That is on the current BK tree. I am retarded. Here is the patch to fix it. Tested with USB hard disk and webcam in both 32bit compatible mode and native 64bit mode. Again, sorry about that. From: Christopher Li <chrisl@vmware.com> Signed-off-by: -
David Brownell authored
This reverts a recent change to usb_set_interface(). The change worked around a quirk in certain devices, but doing this in usbcore creates needless regressions for other devices. More appropriate fixes won't put such handling in usbcore. Basically it's tricky to do a full software reset of USB device state, since the devices don't all act the same. This adds a note to the kerneldoc for the usb_reset_configuration() call to highlight the quirk this was working around: endpoint data toggles not being reset. Signed-off-by:
-
Nishanth Aravamudan authored
First patch incorrectly changed state of the wait-queue usage to TASK_UNINTERRUPTIBLE. Reverted to TASK_INTERRUPTIBLE. Signed-off-by:
Nishanth Aravamudan <nacc@us.ibm.com> Signed-off-by:
-
Greg KH authored
Signed-off-by: -
Pavel Machek authored
Signed-off-by: -
David Brownell authored
This patch includes minor "sparse -Wbitwise" updates for the PCI based HCDs. Almost all of them involve just changing the second parameter of the suspend() method to a pm_message_t ... the others relate to how the EHCI code walks in-memory data structures. (There's a minor bug fixed there too ... affecting the big-endian sysfs async schedule dump.) Signed-off-by:
-
David Brownell authored
This is the first of a few installments of PM API updates to match the recent switch to "pm_message_t". This installment primarily affects USB device drivers (for USB interfaces), and it changes the handful of drivers which currently implement suspend methods: - <linux/usb.h> and usbcore, signature change - Some drivers only changed the signature, net effect this just shuts up "sparse -Wbitwise": * hid-core * stir4200 - Two network drivers did that, and also grew slightly more featureful suspend code ... they now properly shut down their activities. (As should stir4200...) * pegasus * usbnet Note that the Wake-On-Lan (WOL) support in pegasus doesn't yet work; looks to me like it's missing a request to turn it on, vs just configuring it. The ASIX code in usbnet also has WOL hooks that are ready to use; untested. Signed-off-by: -
David Brownell authored
This has a variety of updates to the shared suspend/resume code for PCI based USB host controllers. - Cope with pm_message_t replacing the target system state. This is actually a loss of functionality; PCI D1 and D2 states will no longer be used, and it's no longer knowable that D3cold is on the way so power will be lost. - Most importantly, some of the resume paths are reworked and cleaned up. They're now an exact mirror of suspend paths, and more care is taken to ensure the hardware is reactivated before the hardware re-enables interrupts. Plus comment and diagnostic cleanups; there are some nasty cases here especially combined with swsusp, now they're somewhat commented. Signed-off-by:
-
