- 06 Jun, 2002 4 commits
-
-
David Woodhouse authored
This switches linux/zlib.h to include zconf.h as <linux/zconf.h> instead of just "zconf.h".
-
Linus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
Linus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
Linus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
- 05 Jun, 2002 19 commits
-
-
David S. Miller authored
-
David S. Miller authored
printing Sparc IRQ.
-
David S. Miller authored
-
David S. Miller authored
-
David S. Miller authored
-
David S. Miller authored
-
David S. Miller authored
-
David S. Miller authored
-
David S. Miller authored
-
David S. Miller authored
Generic BUS objects have to be registered before devices assosciated with them are probed. Therefore subsys_initcall is inappropriate for such setups. It does not work to use core_initcall for this because the generic device layer bits need to be setup first too. So we rename unused_initcall to postcore_initcall and use this new initcall level for generic BUS object init. This fixes bootup on Alpha, and Sparc64. X86 was working by what looks to be luck in link order.
-
David S. Miller authored
-
David S. Miller authored
HAVE_ARCH_SIGINFO_T platforms.
-
Rob Radez authored
-
Tom Rini authored
The following patch cleans up the i386 usage of <linux/init.h>. This remove <linux/init.h> from <asm-i386/system.h> which did not need it, <asm-i386/highmem.h> which only had it due to an extern using __init, which is not needed. This adds <linux/init.h> to <asm-i386/bugs.h> which actually has numerous __init functions and adds <linux/init.h> to 9 files inside of arch/i386 which were indirectly including <linux/init.h> previously.
-
Russell King authored
When trying to build mpage.c for ARM, I get errors from bio.h since kdev_t isn't defined. The following fixes this. (I fail to see how this can build for anyone as it currently stands; its probably something x86 specific buried in the asm-i386 includes.)
-
Stephen Rothwell authored
Another simple part of a Matthew Wilcox patch. We do not need to pass the file descriptor to the fcntl_[sg]etlk functions, only the struct file * which we have already got from the file descriptor and verified.
-
Stephen Rothwell authored
Trivial part of a patch by Matthew Wilcox
-
Brian Gerst authored
A few cases of list_del(x) + INIT_LIST_HEAD(x) crept in recently which can be replaced with list_del_init(x).
-
Martin Dalecki authored
- Work a bit on the automatic CRC error recovery handling. System still hangs. But one thing for sure - we don't have to use any specialized irq handler for it. - Since ioctl don't any longer submit requests to the queue without rq->special set, we can safely remove args_error handling from start_request. - Make REQ_SPECIAL usage in ide-floppy obvious. - Use REQ_SPECIAL everywhere instead of REQ_DRIVE_ACB. This is actually a bit dangerous but should work as far as I can see. - Unfold the now not REQ_SPECIAL specific dequeing part of ide_end_drive_cmd(). Turns out that we can thereafter remove the calls to ide_end_drice_cmd() at places where the request type isn't REQ_SPECIAL all any longer. (tcq.c) - After the above operation it turns out that there are just two places where ide_end_drive_cmd remains, namely: ata_error, task_no_data_intr drive_cmd_intr. We can avoid it by changing the logics in ata_error a slightly. So now just to cases remain where ide_end_drive_cmd remains used: drive_cmd_intr and task_no_data_intr. - Now looking a bit closer we can realize that drive_cmd_intr and task_no_data_intr can be easly merged together, since the usage of task_no_data_intr implied taskfile.sector_number == 0. - Use one single ata_special_intr function for the handling of interrupts submitted through ide_raw_cmd. - Move the remaining artefacts of ide_end_drive_cmd directly to ata_special_intr. Oh we don't need to check for REQ_SPECIAL any longer there, since the context is already known. - Set the ata_special_intr handler and command type directly inside ide_raw_taskfile to save code.
-
- 04 Jun, 2002 1 commit
-
-
- 05 Jun, 2002 4 commits
-
-
Nicolas Pitre authored
Same thing as patch #1165/1 but for 2.5.x
-
Russell King authored
The kernel expects these to return values in unsigned long types.
-
Russell King authored
- remove LAST_DESC in favour of passing the array size to iotable_init - replace domain and permission bits/cache attributes with a generic "type", which can be easily converted to the required domain and permission bits/cache attributes at run time. It also removes the possibility for getting such things wrong and (accidentally) allowing all user space to fiddle with devices directly.
-
Russell King authored
-
- 04 Jun, 2002 7 commits
-
-
Robert Love authored
This patch removes fsuser(). Now both suser() and fsuser() are gone and all permission checks use an appropriate capable() call.
-
Robert Love authored
Attached patch replaces the lone remaining suser() call with capable() and then removes suser() itself in a triumphant celebration of the glory of capable(). Or something. ;-) Small cleanup of capable() and some comments, too.
-
David S. Miller authored
-
Martin Dalecki authored
- Simplify ide_cmd_type_parse by removing the handling of commands which we never use. - Realize that pre_task_out_intr and pre_task_mulout_intr are semanticaly identical. Use only pre_task_out_intr(). This allowed us to eliminate the prehandler altogether. - Updated fix for misconfigured host chips by Vojtech Pavlik. - Be more permissive about ioctl handling to allow device type drivers to do they own checks. - ali14xx cleanups by Andrej Panin. - Unfold usage ide_cmd_type_parser in tcq.c code. This makes this operation local to ide-disk.c. Move it as well as the interrupt handlers used only for the handling of disk requests there too. - Guard against calling handler before the drive is ready for it in ata_taskfile()! Well this bug was there before, but right now we inform about it. - Unfold ide_cmd_type_praser in ide-disk.c. Merge the remaining bits of it with get_command. Well it's no more. - Move recal_intr to ide.c - the only place where it's used. This doesn't change the "mechanics" of the code but it makes it a lot more "obvious" what's going on.
-
Russell King authored
2.5.20 seems to be incapable of executing binaries in a ramdisk-based root filesystem. The ramdisk in question is an ext2fs, with a 1K block size loaded via the compressed ramdisk loader in do_mounts(). It appears that, in the case of a 1K block sized filesystem, we attempt to read two 512-byte sectors into a BIO vector. The first one is copied into the first 512 bytes. The second sector, however, is copied over the first 512 bytes. Obviously not what we really want. Rev. 2, slightly cleaned up:
-
bk://ldm.bkbits.net/linux-2.5Linus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
Linus Torvalds authored
Noted by Alexey Vyskubov
-
- 03 Jun, 2002 5 commits
-
-
David S. Miller authored
-
Patrick Mochel authored
- Make sure proper pci id is passed to probe() - make sure pci_dev->driver is set and reset on driver registration/unregistration - call remove_driver to force unload of driver on unregistration
-
Patrick Mochel authored
driver_unbind was called when drv->refcount == 0. It would call driver_for_each_dev to do the unbinding The first thing that would do was get_device, which... BUG()'d if drv->refcount == 0. Duh.
-
Patrick Mochel authored
- make sure drv->devices is initialized on registration (from Peter Osterlund) - add remove_driver for forcing removal of driver There was a potential race with the module unload code. When a pci driver was unloaded, it would call pci_unregister_driver, which would simply call put_driver. If the driver's refcount wasn't 0, it wouldn't unbind it from devices, but the module unload would still continue. If something tried to access the driver later (since everyone thinks its still there), Bad Things would happen. This fixes it until there can be tighter integration between the device model and module unload code.
-
Pavel Machek authored
Here's followup patch that makes it work. Notice freeze_processes() -- if you don't do that you risk data corruption.
-