- 21 Sep, 2002 3 commits
-
-
bk://linux.bkbits.net/linux-2.5Petr Vandrovec authored
into vc.cvut.cz:/mnt2/usr/src/bk/linus/ncpfs
-
Petr Vandrovec authored
deliver server messages to logged-in users even with UDP or TCP transport.
-
Petr Vandrovec authored
-
- 20 Sep, 2002 10 commits
-
-
Petr Vandrovec authored
ncpfs: Add support for packet signatures when using TCP transport.
-
Petr Vandrovec authored
-
Petr Vandrovec authored
-
Petr Vandrovec authored
-
Patrick Mochel authored
This adds the basic driver model support for the IDE subsystem. Basically, it registers the controllers and devices with the driver model core, which puts them in the device tree and gets them a directory in driverfs. The driverfs layout looks like this (on my workstation): [mochel@cherise mochel]$ tree -d /sys/root/pci0/ /sys/root/pci0/ |-- 00:00.0 |-- 00:01.0 | `-- 01:00.0 |-- 00:02.0 | `-- 02:1f.0 | `-- 03:00.0 |-- 00:1e.0 | `-- 04:04.0 |-- 00:1f.0 |-- 00:1f.1 | |-- ide0 | | |-- 0.0 | | `-- 0.1 | `-- ide1 | |-- 1.0 | `-- 1.1 The drive bus IDs (the directory names) are created using this: sprintf(bus_id,"%u.%u",hwif->index,unit); which should give each drive a unique name for the entire system, right? I've also created a struct bus_type for IDE, which gives ide a directory in the driverfs bus/ directory. The layout of that is: [mochel@cherise mochel]$ tree -d /sys/bus/ide/ /sys/bus/ide/ |-- devices | |-- 0.0 -> ../../../root/pci0/00:1f.1/ide0/0.0 | |-- 0.1 -> ../../../root/pci0/00:1f.1/ide0/0.1 | |-- 1.0 -> ../../../root/pci0/00:1f.1/ide1/1.0 | `-- 1.1 -> ../../../root/pci0/00:1f.1/ide1/1.1 `-- drivers Those are symlinks under devices/ (which is why the drive names must be unique..). When drivers are registered with the IDE core, they should also be passed through the core, which will give them a directory in the drivers/ directory just above. In general, there is a bit of code that can be cleaned up, and some explicit calls removed, because of the way the driver model core works. Most of these are pretty simple, and barring any objections, I will implement and send them to you.
-
Jens Axboe authored
starting from 2.5.35 IDE stopped working on my alphas because of following problems: - ide_hwif_configure() ignores BARs for IDE base/control registers and assumes legacy 0x1f0/0x170 ports, unless controller reports native PCI mode (ProgIf bits 0 and 2). This is incorrect, as there are quite a few IDE chips operating in "semi-legacy" mode, i.e. legacy interrupts, but functional BAR0-3, like cy82c693 and ali5229. I guess Andre could give a lot more examples. :-) This happens to work on i386 simply because BIOS usually assigns legacy values to BAR0-3, but we can't rely on it. Just checking respective resource->start for zero should work in all cases. - ide_pci_check_iomem(): resource->flags == 0 means "unconfigured" as well. Thus we avoid false positives. - Apparently cut'n'paste typo in cy82c693.c - wrong PCI IDs.
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Jens Axboe authored
-
http://ppc.bkbits.net/for-linus-ppc64Linus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
- 21 Sep, 2002 11 commits
-
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64_new
-
Anton Blanchard authored
-
Anton Blanchard authored
-
Anton Blanchard authored
-
Anton Blanchard authored
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64_new
-
Anton Blanchard authored
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64_Makefilecleanup
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64_Makefilecleanup
-
- 20 Sep, 2002 9 commits
-
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64_new
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64_new
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64_Makefilecleanup
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64_Makefilecleanup
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64_new
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64_new
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64
-
Ingo Molnar authored
the attached patch (against BK-curr) fixes a bug in the new PID allocator, which bug can cause incorrect hashing of the PID structure which causes infinite loops in find_pid(). [and potentially other problems.]
-
- 19 Sep, 2002 7 commits
-
-
Anton Blanchard authored
-
Anton Blanchard authored
into samba.org:/scratch/anton/linux-2.5_ppc64_new
-
Linus Torvalds authored
into home.transmeta.com:/home/torvalds/v2.5/linux
-
Andrew Morton authored
Patch from Rohit Seth: allow hugetlb pages to be allocated from the highmem zone.
-
Andrew Morton authored
From Marcus Alanen <maalanen@ra.abo.fi> Don't retake the zone lock after spilling a batch of pages into the buddy. Instead, just clear local variable `zone' to indicate that no lock is held. This is actually a common case - whenever release_pages() is called with exactly 16 pages (truncate, page reclaim..) Marcus' patch will save a lock and an unlock. Also, remove some lock-avoidance heuristics in pagevec_deactivate_inactive(): the caller has already made these checks, and the chance of the check here actually doing anything useful is negligible.
-
Andrew Morton authored
- Spell Jeremy's name correctly. - Fix compile warning in raw.c - Do a waitqueue_active() test before waking klogd in printk. Not only is is negligibly faster, but the wake_up() in there causes deadlocks when you try to print debug info out from inside scheduler code. This patch gives a delightfully obscure way of avoiding the deadlock: kill off klogd. - Fix a couple of compile warnings in the mtrr code.
-
Andrew Morton authored
From Christoph Hellwig, acked by Jens. - remove some unneeded runtime initializers. - remove the explicit call to hd_init() - it already goes through module_init(), so we're currently running hd_init() twice.
-