- 25 Jun, 2003 12 commits
-
-
bk://kernel.bkbits.net/jgarzik/net-drivers-2.5Linus Torvalds authored
into home.osdl.org:/home/torvalds/v2.5/linux
-
Ralf Bächle authored
Add missing CONFIG_TC35805 entry to Kconfig. Update CONFIG_NET_SB1250_MAC Kconfig entry. Minor cosmetic updates to gt96100eth.
-
Ralf Bächle authored
-
Ralf Bächle authored
-
Ralf Bächle authored
-
Ralf Bächle authored
-
Ralf Bächle authored
-
Ralf Bächle authored
-
Ralf Bächle authored
-
Jeff Garzik authored
Submitted by Ralf Baechle <ralf@linux-mips.org>
-
Randy Dunlap authored
[ Registers of the world, unite! ] This makes the IO-APIC data structures use unions, so that we can cleanly access them both as flat "raw" values, and as the bitmap sub-entries.
-
bk://ppc.bkbits.net/for-linus-ppcLinus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
- 26 Jun, 2003 1 commit
-
-
Paul Mackerras authored
This error is handled in the signal delivery code and should never be returned from a syscall unless a signal is pending. Grepping seems to indicate that that is in fact the case (but not for ERESTARTSYS, but that is another problem).
-
- 25 Jun, 2003 1 commit
-
-
Paul Mackerras authored
-
- 24 Jun, 2003 26 commits
-
-
Stephen Hemminger authored
Ignore earlier patch -- this one locks and free's as appropriate. Tested on 2.5.72 with SMP. Of course, it begs the question why have two (now three) versions of drivers for the same hardware...
-
Scott Feldman authored
dev_ioctl already checks capable(CAP_NET_ADMIN), so no need to do so in drivers.
-
Daniel Ritz authored
net_device is no longer allocated as part of the driver's private structure, instead it's allocated via alloc_netdev. compile tested only since no hardware against 2.5.73-bk -daniel ===== smc91c92_cs.c 1.18 vs edited =====
-
Daniel Ritz authored
net_device is no longer allocated as part of the driver's private structure, instead it's allocated via alloc_netdev. compile tested only since no hardware against 2.5.73-bk -daniel ===== nmclan_cs.c 1.14 vs edited =====
-
Daniel Ritz authored
net_device is no longer allocated as part of the driver's private structure, instead it's allocated via alloc_netdev. compile tested only since no hardware against 2.5.73-bk -daniel ===== fmvj18x_cs.c 1.21 vs edited =====
-
Daniel Ritz authored
net_device is no longer allocated as part of the driver's private structure, instead it's allocated via alloc_netdev. compile tested only since no hardware against 2.5.73-bk -daniel ===== drivers/net/pcmcia/3c589_cs.c 1.17 vs edited =====
-
Daniel Ritz authored
net_device is no longer allocated as part of the driver's private structure, instead it's allocated via alloc_netdev. compile tested only since no hardware against 2.5.73-bk -daniel ===== drivers/net/pcmcia/3c574_cs.c 1.17 vs edited =====
-
Paul Mackerras authored
into samba.org:/stuff/paulus/kernel/for-linus-ppc
-
David S. Miller authored
-
David S. Miller authored
-
David S. Miller authored
-
David S. Miller authored
-
David S. Miller authored
-
Randy Dunlap authored
Recently there has been a rash of Unexpected IO APIC reports on the linux-smp mailing list. Most of the most recent ones are due to some newer Intel chipsets (865, 875). The IO APIC Version register doesn't indicate the differences in these IO APICs. I have an patch that addresses these chipsets. It has been tested by a few people with good results and has been blessed by Maciej Rozycki. Other than conditionally decoding IO APIC registers 2 and 3, we could alternately ignore them since Linux doesn't use the values for anything other than printing them. This patch ignores IO APIC register 2 if it's the same value as IO APIC register 1. It also reads IO APIC register 3 if the IO APIC version is >= 0x20, but some chipsets don't support this register, so it is also ignored if its value if the same as IO APIC register 1 or 2. Another possible(?) alternative is to read the PID/VID of the device to determine which registers it supports. However, PCI devices have not been scanned at this point in init, so it would require scanning PCI config space directly and I don't yet see the point of doing that. Oh, and the UNEXPECTED_IO_APIC() function doesn't print anything in 2.5.current and I didn't change that.
-
Andries E. Brouwer authored
This does the following: - IV value is current 512-byte sector relative to start of loop container file. This is what all cryptoloop people have done, if I am not mistaken. Andi or others - if you can demonstrate the need for a more flexible setup an additional ioctl field may be needed. I hope we can do without. - made some things static - made lo_offset a loff_t - added lo_sizelimit If one wanted a (crypto)loop somewhere inside a container file, the old code allowed a starting offset, but no size, so that the cryptoloop always extended to the end of the container file. This field allows one to select an arbitrary interval. Note that this changes struct loop_info64. - improve error handling of loop_init() - removed the unused typedef transfer_proc_t. - added a define for LO_CRYPT_CRYPTOAPI
-
bk://linux-pnp.bkbits.net/pnp-2.5Linus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
Adam Belay authored
The semaphore in pnp_init_resource_table is not needed and, in some cases, can cause resource management lockups. This patch removes the improperly placed semaphore.
-
Adam Belay authored
In the last release, this api was accidently changed and therefore affected some drivers. This patch corrects the issue by renaming the api back to pnp_init_resource_table.
-
bk://kernel.bkbits.net/gregkh/linux/linus-2.5Linus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
Ivan Kokshaysky authored
-
Stephen Frost authored
-
Harald Welte authored
-
Harald Welte authored
-
Harald Welte authored
-
Harald Welte authored
-
Greg Kroah-Hartman authored
into kroah.com:/home/greg/linux/BK/gregkh-2.5
-