- 22 9月, 2005 1 次提交
-
-
由 Kevin Vigor 提交于
Addresses some small bugs in the pegasus ethernet-over-USB driver. Specifically, malformed long packets from the adapter could cause a kernel panic; the interrupt interval calculation was inappropriate for high-speed devices; the return code from read_mii_word was tested incorrectly; and failure to unlink outstanding URBs before freeing them could lead to kernel panics when unloading the driver. Signed-off-by: NKevin Vigor <kevin@realmsys.com> Cc: Petko Manolov <petkan@users.sourceforge.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 09 9月, 2005 1 次提交
-
-
由 Alan Stern 提交于
29 July 2005, Cambridge, MA: This afternoon Alan Stern submitted a patch to remove the URB_ASYNC_UNLINK flag from the Linux kernel. Mr. Stern explained, "This flag is a relic from an earlier, less-well-designed system. For over a year it hasn't been used for anything other than printing warning messages." An anonymous spokesman for the Linux kernel development community commented, "This is exactly the sort of thing we see happening all the time. As the kernel evolves, support for old techniques and old code can be jettisoned and replaced by newer, better approaches. Proprietary operating systems do not have the freedom or flexibility to change so quickly." Mr. Stern, a staff member at Harvard University's Rowland Institute who works on Linux only as a hobby, noted that the patch (labelled as548) did not update two files, keyspan.c and option.c, in the USB drivers' "serial" subdirectory. "Those files need more extensive changes," he remarked. "They examine the status field of several URBs at times when they're not supposed to. That will need to be fixed before the URB_ASYNC_UNLINK flag is removed." Greg Kroah-Hartman, the kernel maintainer responsible for overseeing all of Linux's USB drivers, did not respond to our inquiries or return our calls. His only comment was "Applied, thanks." Signed-off-by: NAlan Stern <stern@rowland.harvard.edu> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
-
- 30 7月, 2005 1 次提交
-
-
由 Adrian Bunk 提交于
The only uses of both variables were recently removed. Signed-off-by: NAdrian Bunk <bunk@stusta.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 27 6月, 2005 1 次提交
-
-
由 YOSHIFUJI Hideaki 提交于
Some USB ethernet drivers did not accept multicast frames appropriately. IPv6 did not work with those drivers without this patch. Signed-off-by: NYOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
-
- 26 4月, 2005 1 次提交
-
-
由 Al Viro 提交于
Signed-off-by: NAl Viro <viro@parcelfarce.linux.theplanet.co.uk> Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
-
- 19 4月, 2005 1 次提交
-
-
由 David Brownell 提交于
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: NDavid Brownell <dbrownell@users.sourceforge.net> Signed-off-by: NAndrew Morton <akpm@osdl.org> Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de> Index: gregkh-2.6/drivers/net/irda/stir4200.c ===================================================================
-
- 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!
-