diff -urN linux-2.4.20/CREDITS linux-2.4.21/CREDITS --- linux-2.4.20/CREDITS 2002-11-28 15:53:08.000000000 -0800 +++ linux-2.4.21/CREDITS 2003-06-13 07:51:29.000000000 -0700 @@ -733,7 +733,7 @@ D: Dell PowerEdge server, SCSI layer, misc drivers, and other patches S: Dell Computer Corporation S: One Dell Way -S: Round Rock, TX 78681 +S: Round Rock, TX 78682 S: USA N: Eddie C. Dost @@ -1008,7 +1008,7 @@ S: USA N: Jeff Garzik -E: jgarzik@mandrakesoft.com +E: jgarzik@pobox.com N: Jacques Gelinas E: jacques@solucorp.qc.ca @@ -1065,6 +1065,11 @@ D: Transformed old user space bdflush into 1st kernel thread - kflushd. D: Many other patches, documentation files, mini kernels, utilities, ... +N: Masanori GOTO +E: gotom@debian.or.jp +D: Workbit NinjaSCSI-32Bi/UDE driver +S: Japan + N: John E. Gotts E: jgotts@linuxsavvy.com D: kernel hacker @@ -1169,6 +1174,10 @@ S: Atlanta, Georgia 30332 S: USA +N: Brad Hards +E: bradh@frogmouth.net +D: Various USB bits, other minor patches + N: Angelo Haritsis E: ah@computer.org D: kernel patches (serial, watchdog) @@ -1231,16 +1240,18 @@ N: Christoph Hellwig E: hch@infradead.org -D: misc driver & makefile hacking +E: hch@sgi.com +D: all kinds of driver, filesystem & core kernel hacking D: freevxfs driver D: sysvfs maintainer -S: Triftstraße 26 -S: 38644 Goslar +D: chief codingstyle nitpicker +S: Auweg 38 +S: 85748 Garching S: Germany N: Richard Henderson E: rth@twiddle.net -E: rth@cygnus.com +E: rth@redhat.com D: Alpha hacker, kernel and userland S: 1668 California St. S: Mountain View, California 94041 @@ -1488,7 +1499,7 @@ S: United Kingdom N: Ani Joshi -E: ajoshi@shell.unixbox.com +E: ajoshi@kernel.crashing.org D: fbdev hacking N: Bernhard Kaindl @@ -1888,7 +1899,8 @@ E: pavel@ucw.cz E: pavel@suse.cz D: Softcursor for vga, hypertech cdrom support, vcsa bugfix, nbd -D: sun4/330 port, capabilities for elf, speedup for rm on ext2, USB +D: sun4/330 port, capabilities for elf, speedup for rm on ext2, USB, +D: x86-64 port, software suspend S: Volkova 1131 S: 198 00 Praha 9 S: Czech Republic @@ -1920,6 +1932,11 @@ E: Kai.Makisara@metla.fi D: SCSI Tape Driver +N: Dan Malek +E: dan@mvista.com +D: PowerPC 8xx, 4xx work. +S: USA + N: Asit Mallick E: asit.k.mallick@intel.com D: Linux/IA-64 @@ -2210,11 +2227,12 @@ S: United Kingdom N: Ian S. Nelson -E: ian.nelson@echostar.com +E: nelsonis@earthlink.net D: Minor mmap and ide hacks S: 1370 Atlantis Ave. S: Lafayette CO, 80026 S: USA +P: 1024D/DD478240 4073 9AF8 027F 278D CBBB DA3C 9905 0415 DD47 8240 N: Russell Nelson E: nelson@crynwr.com @@ -2226,6 +2244,15 @@ S: Potsdam, New York 13676 S: USA +N: Dave Neuer +E: dneuer@innovation-charter.com +E: mr_fred_smoothie@yahoo.com +D: Helped implement support for Compaq's H31xx series iPAQs +D: Other mostly minor tweaks & bugfixes +S: 325 E. Main St., Suite 3 +S: Carnegie, PA 15105 +S: USA + N: Michael Neuffer E: mike@i-Connect.Net E: neuffer@goofy.zdv.uni-mainz.de @@ -2397,18 +2424,24 @@ D: CDROM driver "sonycd535" (Sony CDU-535/531) N: Stelian Pop -E: stelian.pop@fr.alcove.com +E: stelian@popies.net P: 1024D/EDBB6147 7B36 0E07 04BC 11DC A7A0 D3F7 7185 9E7A EDBB 6147 D: sonypi, meye drivers, mct_u232 usb serial hacks -S: Alcôve -S: 153, bd. Anatole France -S: 93200 Saint Denis -S: France +S: Paris, France N: Frederic Potter E: fpotter@cirpack.com D: Some PCI kernel support +N: Matt Porter +E: porter@cox.net +E: mporter@mvista.com +D: Motorola PowerPC PReP support +D: cPCI PowerPC support +D: Embedded PowerPC 440/6xx/7xx/74xx support +S: Chandler, Arizona 85249 +S: USA + N: Rui Prior E: rprior@inescn.pt D: ATM device driver for NICStAR based cards @@ -2520,6 +2553,12 @@ S: 70110 Kuopio S: Finland +N: Tom Rini +E: trini@kernel.crashing.org +D: Lots of PowerPC cleanups, minor matroxfb work +S: Tucson, Arizona +S: USA + N: William E. Roadcap E: roadcapw@cfw.com W: http://www.cfw.com/~roadcapw @@ -3282,6 +3321,12 @@ S: Socorro NM, 87801 S: USA +N: Hiroshi YOKOTA +E: yokota@netlab.is.tsukuba.ac.jp +D: Workbit NinjaSCSI-3/32Bi PCMCIA driver +D: Workbit NinjaSCSI-32Bi/UDE driver +S: Japan + N: Eric Youngdale E: eric@andante.org W: http://www.andante.org diff -urN linux-2.4.20/Documentation/BK-usage/00-INDEX linux-2.4.21/Documentation/BK-usage/00-INDEX --- linux-2.4.20/Documentation/BK-usage/00-INDEX 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.4.21/Documentation/BK-usage/00-INDEX 2003-06-13 07:51:29.000000000 -0700 @@ -0,0 +1,38 @@ +bk-kernel-howto.txt: Description of kernel workflow under BitKeeper + +bk-make-sum: Create summary of changesets in one repository and not +another, typically in preparation to be sent to an upstream maintainer. +Typical usage: + cd my-updated-repo + bk-make-sum ~/repo/original-repo + mv /tmp/linus.txt ../original-repo.txt + +bksend: Create readable text output containing summary of changes, GNU +patch of the changes, and BK metadata of changes (as needed for proper +importing into BitKeeper by an upstream maintainer). This output is +suitable for emailing BitKeeper changes. The recipient of this output +may pipe it directly to 'bk receive'. + +bz64wrap: helper script. Uncompressed input is piped to this script, +which compresses its input, and then outputs the uu-/base64-encoded +version of the compressed input. + +csets-to-patches: Produces a delta of two BK repositories, in the form +of individual files, each containing a single cset as a GNU patch. +Output is several files, each with the filename "/tmp/rev-$REV.patch" +Typical usage: + cd my-updated-repo + bk changes -L ~/repo/original-repo 2>&1 | \ + perl csets-to-patches + +cset-to-linus: Produces a delta of two BK repositories, in the form of +changeset descriptions, with 'diffstat' output created for each +individual changset. +Typical usage: + cd my-updated-repo + bk changes -L ~/repo/original-repo 2>&1 | \ + perl cset-to-linus > summary.txt + +unbz64wrap: Reverse an encoded, compressed data stream created by +bz64wrap into an uncompressed, typically text/plain output. + diff -urN linux-2.4.20/Documentation/BK-usage/bk-kernel-howto.txt linux-2.4.21/Documentation/BK-usage/bk-kernel-howto.txt --- linux-2.4.20/Documentation/BK-usage/bk-kernel-howto.txt 2002-11-28 15:53:08.000000000 -0800 +++ linux-2.4.21/Documentation/BK-usage/bk-kernel-howto.txt 2003-06-13 07:51:29.000000000 -0700 @@ -32,7 +32,7 @@ Let's start with this progression: Each BitKeeper source tree on disk is a repository unto itself. -Each repository has a parent. +Each repository has a parent (except the root/original, of course). Each repository contains a set of a changesets ("csets"). Each cset is one or more changed files, bundled together. diff -urN linux-2.4.20/Documentation/Configure.help linux-2.4.21/Documentation/Configure.help --- linux-2.4.20/Documentation/Configure.help 2002-11-28 15:53:08.000000000 -0800 +++ linux-2.4.21/Documentation/Configure.help 2003-06-13 07:51:29.000000000 -0700 @@ -246,14 +246,22 @@ If unsure, say N. -Multiquad support for NUMA systems -CONFIG_MULTIQUAD +Multiquad support for NUMAQ systems +CONFIG_X86_NUMAQ This option is used for getting Linux to run on a (IBM/Sequent) NUMA multiquad box. This changes the way that processors are bootstrapped, and uses Clustered Logical APIC addressing mode instead of Flat Logical. You will need a new lynxer.elf file to flash your firmware with - send email to Martin.Bligh@us.ibm.com +Support for IBM Summit (EXA) systems +CONFIG_X86_SUMMIT + This option is needed for IBM systems that use the Summit/EXA chipset. + (EXA: Extendable Xseries Architecture)In particular, it is needed for + the x440 (even for the 4-CPU model). + + If you don't have this computer, you may safely say N. + IO-APIC support on uniprocessors CONFIG_X86_UP_IOAPIC An IO-APIC (I/O Advanced Programmable Interrupt Controller) is an @@ -1033,7 +1041,7 @@ Pacific Digital A-DMA support (EXPERIMENTAL) CONFIG_BLK_DEV_PDC_ADMA - Please read the comments at the top of . + Please read the comments at the top of . 3ware Hardware ATA-RAID support CONFIG_BLK_DEV_3W_XXXX_RAID @@ -1063,13 +1071,13 @@ The ATP860 is an UltraDMA 66 chipset base. The ATP860M(acintosh) version is an UltraDMA 66 chipset base. - Please read the comments at the top of . + Please read the comments at the top of . If you say Y here, then say Y to "Use DMA by default when available" as well. AEC62XX Tuning support CONFIG_AEC62XX_TUNING - Please read the comments at the top of . + Please read the comments at the top of . If unsure, say N. ALI M15x3 chipset support @@ -1080,7 +1088,7 @@ If you say Y here, you also need to say Y to "Use DMA by default when available", above. Please read the comments at the top of - . + . If unsure, say N. @@ -1097,14 +1105,16 @@ SAY N! -AMD Viper (7401/7409/7411) chipset support +AMD and nVidia IDE support CONFIG_BLK_DEV_AMD74XX - This driver ensures (U)DMA support for the AMD756/760 Viper - chipsets. + This driver adds explicit support for AMD-7xx and AMD-8111 chips + and also for the nVidia nForce chip. This allows the kernel to + change PIO, DMA and UDMA speeds and to configure the chip to + optimum performance. If you say Y here, you also need to say Y to "Use DMA by default when available", above. - Please read the comments at the top of . + Please read the comments at the top of . If unsure, say N. @@ -1114,10 +1124,10 @@ This effect can be also invoked by calling "idex=ata66" If unsure, say N. -CMD64X and CMD680 chipset support +CMD64X/CMD680 chipset support CONFIG_BLK_DEV_CMD64X Say Y here if you have an IDE controller which uses any of these - chipsets: CMD643, CMD646, CMD648, CMD649 or CMD680. + chipsets: CMD643, CMD646 and CMD648. CY82C693 chipset support CONFIG_BLK_DEV_CY82C693 @@ -1148,16 +1158,18 @@ HPT34X AUTODMA support (WIP) CONFIG_HPT34X_AUTODMA This is a dangerous thing to attempt currently! Please read the - comments at the top of . If you say Y + comments at the top of . If you say Y here, then say Y to "Use DMA by default when available" as well. If unsure, say N. -HPT366/368/370 chipset support +HPT36X/37X chipset support CONFIG_BLK_DEV_HPT366 HPT366 is an Ultra DMA chipset for ATA-66. HPT368 is an Ultra DMA chipset for ATA-66 RAID Based. HPT370 is an Ultra DMA chipset for ATA-100. + HPT372 is an Ultra DMA chipset for ATA-133. + HPT374 is an Ultra DMA chipset for ATA-133. This driver adds up to 4 more EIDE devices sharing a single interrupt. @@ -1179,12 +1191,12 @@ This driver adds detection and support for the NS87415 chip (used in SPARC64, among others). - Please read the comments at the top of . + Please read the comments at the top of . OPTi 82C621 chipset enhanced support (EXPERIMENTAL) CONFIG_BLK_DEV_OPTI621 This is a driver for the OPTi 82C621 EIDE controller. - Please read the comments at the top of . + Please read the comments at the top of . ServerWorks OSB4/CSB5 chipset support CONFIG_BLK_DEV_SVWKS @@ -1198,7 +1210,7 @@ PIO 0-4 mode settings, this allows dynamic tuning of the chipset via the standard end-user tool 'hdparm'. - Please read the comments at the top of . + Please read the comments at the top of . If you say Y here, you should also say Y to "PIIXn Tuning support", below. @@ -1218,7 +1230,7 @@ If unsure, say N. PROMISE PDC20246/PDC20262/PDC20265/PDC20267/PDC20268 support -CONFIG_BLK_DEV_PDC202XX +CONFIG_BLK_DEV_PDC202XX_OLD Promise Ultra33 or PDC20246 Promise Ultra66 or PDC20262 Promise Ultra100 or PDC20265/PDC20267/PDC20268 @@ -1236,7 +1248,7 @@ available" as well. Please read the comments at the top of - . + . If unsure, say N. @@ -1251,7 +1263,7 @@ when the PDC20265 BIOS has been disabled (for faster boot up). Please read the comments at the top of - . + . If unsure, say N. @@ -1274,7 +1286,12 @@ If you say Y here, you need to say Y to "Use DMA by default when available" as well. - Please read the comments at the top of . + Please read the comments at the top of . + +Silicon Image chipset support +CONFIG_BLK_DEV_SIIMAGE + This driver provides (U)DMA support for the SII3112 SATA controllers and + for the CMD/SI680 UDMA/DMA ATA controller. SLC90E66 chipset support CONFIG_BLK_DEV_SLC90E66 @@ -1288,7 +1305,7 @@ available" as well. Please read the comments at the top of - . + . Winbond SL82c105 support CONFIG_BLK_DEV_SL82C105 @@ -1301,7 +1318,7 @@ This driver adds support for bus master DMA transfers using the Tekram TRM290 PCI IDE chip. Volunteers are needed for further tweaking and development. - Please read the comments at the top of . + Please read the comments at the top of . VIA82CXXX chipset support CONFIG_BLK_DEV_VIA82CXXX @@ -1313,7 +1330,7 @@ system" support. Please read the comments at the top of - . + . If you say Y here, then say Y to "Use DMA by default when available" as well. @@ -1353,7 +1370,7 @@ boot parameter. It enables support for the secondary IDE interface of the ALI M1439/1443/1445/1487/1489 chipsets, and permits faster I/O speeds to be set as well. See the files - and for + and for more info. DTC-2278 support @@ -1362,7 +1379,7 @@ boot parameter. It enables support for the secondary IDE interface of the DTC-2278 card, and permits faster I/O speeds to be set as well. See the and - files for more info. + files for more info. Holtek HT6560B support CONFIG_BLK_DEV_HT6560B @@ -1370,7 +1387,7 @@ boot parameter. It enables support for the secondary IDE interface of the Holtek card, and permits faster I/O speeds to be set as well. See the and - files for more info. + files for more info. PROMISE DC4030 support (EXPERIMENTAL) CONFIG_BLK_DEV_PDC4030 @@ -1380,14 +1397,14 @@ attached to the secondary interface. CD-ROM and TAPE devices are not supported yet. This driver is enabled at runtime using the "ide0=dc4030" kernel boot parameter. See the - and files + and files for more info. QDI QD65XX support CONFIG_BLK_DEV_QD65XX This driver is enabled at runtime using the "ide0=qd65xx" kernel boot parameter. It permits faster I/O speeds to be set. See the - and for + and for more info. UMC 8672 support @@ -1396,7 +1413,7 @@ boot parameter. It enables support for the secondary IDE interface of the UMC-8672, and permits faster I/O speeds to be set as well. See the files and - for more info. + for more info. Amiga Gayle IDE interface support CONFIG_BLK_DEV_GAYLE @@ -2508,6 +2525,19 @@ If you want to compile it as a module, say M here and read . If unsure, say `N'. +Amanda protocol support +CONFIG_IP_NF_AMANDA + If you are running the Amanda backup package (http://www.amanda.org/) + on this machine or machines that will be MASQUERADED through this + machine, then you may want to enable this feature. This allows the + connection tracking and natting code to allow the sub-channels that + Amanda requires for communication of the backup data, messages and + index. + + If you want to compile it as a module, say M here and read + Documentation/modules.txt. If unsure, say `N'. + + IRC Send/Chat protocol support CONFIG_IP_NF_IRC There is a commonly-used extension to IRC called @@ -2522,6 +2552,16 @@ If you want to compile it as a module, say 'M' here and read Documentation/modules.txt. If unsure, say 'N'. +TFTP protocol support +CONFIG_IP_NF_TFTP + TFTP connection tracking helper, this is required depending + on how restrictive your ruleset is. + If you are using a tftp client behind -j SNAT or -j MASQUERADING + you will need this. + + If you want to compile it as a module, say M here and read + Documentation/modules.txt. If unsure, say `Y'. + FTP protocol support CONFIG_IP_NF_FTP Tracking FTP connections is problematic: special helpers are @@ -3543,6 +3583,13 @@ You should say Y here if you use XFree86 3.3.6 or 4.x and want to use GLX or DRI. If unsure, say N. +CONFIG_AGP_AMD_8151 + This option gives you AGP support for the GLX component of + XFree86 on AMD K8 with an AGP 8151 chipset. + + You should say Y here if you use XFree86 3.3.6 or 4.x and want to + use GLX or DRI. If unsure, say N. + Generic SiS support CONFIG_AGP_SIS This option gives you AGP support for the GLX component of the "soon @@ -4155,6 +4202,7 @@ - "Winchip-2" for IDT Winchip 2. - "Winchip-2A" for IDT Winchips with 3dNow! capabilities. - "CyrixIII" for VIA Cyrix III or VIA C3. + - "VIA C3-2 for VIA C3-2 "Nehemiah" (model 9 and above). If you don't know what to do, choose "386". @@ -4176,6 +4224,13 @@ Select this for a Pentium Classic processor with the RDTSC (Read Time Stamp Counter) instruction for benchmarking. +VIA C3-2 (Nehemiah) +CONFIG_MVIAC3_2 + Select this for a VIA C3 "Nehemiah". Selecting this enables usage of SSE + and tells gcc to treat the CPU as a 686. + + Note, this kernel will not boot on older (pre model 9) C3s. + 32-bit PDC CONFIG_PDC_NARROW Saying Y here will allow developers with a C180, C200, C240, C360, @@ -4416,7 +4471,7 @@ The driver is also available as a module ( = code which can be inserted and removed from the running kernel whenever you want). The - module will be called rivafb.o. If you want to compile it as a + module will be called tridentfb.o. If you want to compile it as a module, say M here and read . ATI Mach64 display support @@ -4563,14 +4618,11 @@ BIOS routines contained in a ROM chip in HP PA-RISC based machines. Enabling this option will implement the linux framebuffer device and an fbcon color text console using calls to the STI BIOS routines. - The HP framebuffer device is usually planar, uses a strange memory + The HP framebuffer device is sometimes planar, using a strange memory layout, and changing the plane mask to create colored pixels - requires a call to the STI routines, so do not expect /dev/fb to - actually be useful. However, it is the best we have as far as - graphics on the HP chipsets due to lack of hardware level - documentation for the various on-board HP chipsets used in these - systems. It is sufficient for basic text console functions, - including fonts. + can require a call to the STI routines, so /dev/fb may not actually + be useful. However, on some systems packed pixel formats are supported. + It is sufficient for basic text console functions, including fonts. You should probably enable this option, unless you are having trouble getting video when booting the kernel (make sure it isn't @@ -7907,6 +7959,17 @@ The common answer here is N, but answering Y is safe. +Workbit NinjaSCSI-32Bi/UDE support +CONFIG_SCSI_NSP32 + This is support for the Workbit NinjaSCSI-32Bi/UDE PCI/Cardbus + SCSI host adapter. Please read the SCSI-HOWTO, available from + . + + If you want to compile this as a module ( = code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read . The module + will be called nsp32.o. + IBMMCA SCSI support CONFIG_SCSI_IBMMCA This is support for the IBM SCSI adapter found in many of the PS/2 @@ -9621,6 +9684,26 @@ should add "alias syncX farsync" to /etc/modules.conf for each interface, where X is 0, 1, 2, ... +CONFIG_HDLC_DEBUG_PKT + This option is for developers only - do NOT use on production + systems. + +CONFIG_HDLC_DEBUG_HARD_HEADER + This option is for developers only - do NOT use on production + systems. + +CONFIG_HDLC_DEBUG_ECN + This option is for developers only - do NOT use on production + systems. + +CONFIG_HDLC_DEBUG_RINGS + If you answer Y here you will be able to get a diagnostic dump of + port's TX and RX packet rings, using "sethdlc hdlcX private" + command. It does not affect normal operations. + + If unsure, say Y here. + + Frame Relay (DLCI) support CONFIG_DLCI This is support for the frame relay protocol; frame relay is a fast @@ -10816,6 +10899,15 @@ say M here and read . This is recommended. The module will be called yellowfin.o. +Realtek 8169 Gigabit Ethernet support +CONFIG_R8169 + Say Y here if you have a Realtek 8169 PCI Gigabit Ethernet adapter. + + If you want to compile this driver as a module ( = code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read . This is + recommended. The module will be called r8169.o. + General Instruments Surfboard 1000 CONFIG_NET_SB1000 This is a driver for the General Instrument (also known as @@ -10875,31 +10967,41 @@ The safe and default value for this is N. -SysKonnect SK-98xx support +SysKonnect SK-98xx and SK-95xx Gigabit Ethernet Adapter family support CONFIG_SK98LIN - Say Y here if you have a SysKonnect SK-98xx Gigabit Ethernet Server - Adapter. The following adapters are supported by this driver: - - SK-9841 (single link 1000Base-LX) - - SK-9842 (dual link 1000Base-LX) - - SK-9843 (single link 1000Base-SX) - - SK-9844 (dual link 1000Base-SX) - - SK-9821 (single link 1000Base-T) - - SK-9822 (dual link 1000Base-T) - - SK-9861 (single link Volition connector) - - SK-9862 (dual link Volition connector) - The driver also supports the following adapters from Allied Telesyn: - - AT2970... - - The dual link adapters support a link-failover feature. Read - for information about + Say Y here if you have a SysKonnect SK-98xx or SK-95xx Gigabit + Ethernet Server Adapter. The following adapters are supported by + this driver: + - SK-9521 10/100/1000Base-T Adapter + - SK-9821 Gigabit Ethernet 1000Base-T Server Adapter + - SK-9822 Gigabit Ethernet 1000Base-T Dual Port Server Adapter + - SK-9841 Gigabit Ethernet 1000Base-LX Server Adapter + - SK-9842 Gigabit Ethernet 1000Base-LX Dual Port Server Adapter + - SK-9843 Gigabit Ethernet 1000Base-SX Server Adapter + - SK-9844 Gigabit Ethernet 1000Base-SX Dual Port Server Adapter + - SK-9861 Gigabit Ethernet 1000Base-SX Server Adapter + - SK-9862 Gigabit Ethernet 1000Base-SX Dual Port Server Adapter + - SK-9871 Gigabit Ethernet 1000Base-ZX Server Adapter + - SK-9872 Gigabit Ethernet 1000Base-ZX Dual Port Server Adapter + - SK-9821 V2.0 Gigabit Ethernet 10/100/1000Base-T Adapter + - SK-9841 V2.0 Gigabit Ethernet 1000Base-LX Adapter + - SK-9843 V2.0 Gigabit Ethernet 1000Base-SX Adapter + - SK-9851 V2.0 Gigabit Ethernet 1000Base-SX Adapter + - SK-9861 V2.0 Gigabit Ethernet 1000Base-SX Adapter + - SK-9871 V2.0 Gigabit Ethernet 1000Base-ZX Adapter + + The adapters support Jumbo Frames. + The dual link adapters support link-failover and dual port features. + The V2.0 adapters support the scatter-gather functionality with + sendfile(). Read Documentation/networking/sk98lin.txt for information about optional driver parameters. Questions concerning this driver may be addressed to: linux@syskonnect.de If you want to compile this driver as a module ( = code which can be inserted in and removed from the running kernel whenever you want), - say M here and read . This is - recommended. The module will be called sk98lin.o. + say M here and read Documentation/modules.txt. This is recommended. + The module will be called sk98lin.o. Sun GEM support CONFIG_SUNGEM @@ -11038,6 +11140,7 @@ 82544 PRO/1000 XF Server Adapter A50484-xxx 82544 PRO/1000 T Desktop Adapter A62947-xxx 82540 PRO/1000 MT Desktop Adapter A78408-xxx + 82541 PRO/1000 MT Desktop Adapter C91016-xxx 82545 PRO/1000 MT Server Adapter A92165-xxx 82546 PRO/1000 MT Dual Port Server Adapter A92111-xxx 82545 PRO/1000 MF Server Adapter A91622-xxx @@ -11227,6 +11330,24 @@ say M here and read . The module will be called 3c59x.o. +3cr990 series "Typhoon" support +CONFIG_TYPHOON + This option enables driver support for the 3cr990 series of cards: + + 3C990-TX, 3CR990-TX-95, 3CR990-TX-97, 3CR990-FX-95, 3CR990-FX-97, + 3CR990SVR, 3CR990SVR95, 3CR990SVR97, 3CR990-FX-95 Server, + 3CR990-FX-97 Server, 3C990B-TX-M, 3C990BSVR + + If you have a network (Ethernet) card of this type, say Y and read + the Ethernet-HOWTO, available from + . + + This driver is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module will be called typhoon.o. If you want to compile it as a + module, say M here and read as well + as . + Other ISA cards CONFIG_NET_ISA If your network (Ethernet) card hasn't been mentioned yet and its @@ -11644,6 +11765,18 @@ module, say M here and read as well as . +AMD 8111 (new PCI lance) support +CONFIG_AMD8111_ETH + If you have an AMD 8111-based PCI lance ethernet card, + answer Y here and read the Ethernet-HOWTO, available from + . + + This driver is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module will be called amd8111e.o. If you want to compile it as a + module, say M here and read as well + as . + Ansel Communications EISA 3200 support CONFIG_AC3200 If you have a network (Ethernet) card of this type, say Y and read @@ -11771,6 +11904,13 @@ a module, say M here and read as well as . +Use PIO instead of MMIO +CONFIG_EEPRO100_PIO + This instructs the driver to use programmed I/O ports (PIO) instead + of PCI shared memory (MMIO). This can possibly solve some problems + in case your mainboard has memory consistency issues. If unsure, + say N. + Enable Power Management CONFIG_EEPRO100_PM Many Intel EtherExpress PRO/100 PCI network cards are capable @@ -13764,6 +13904,21 @@ The module will be called wacom.o. If you want to compile it as a module, say M here and read . +Griffin Technology PowerMate support +CONFIG_USB_POWERMATE + Say Y here if you want to use the Griffin Technology, Inc. USB + PowerMate device. This device is an aluminum dial which can + measure clockwise and anticlockwise rotation. The dial also + acts as a pushbutton. The base contains an LED which can be + instructed to pulse or to switch to a particular intensity. + + You can download userspace tools from http://sowerbutts.com/powermate/ + + This driver is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module will be called powermate.o. If you want to compile it as a + module, say M here and read . + Aiptek 6000U/8000U tablet support CONFIG_USB_AIPTEK Say Y here if you want to use the USB version of the Aiptek 6000U/8000U @@ -13858,8 +14013,8 @@ USB Scanner support CONFIG_USB_SCANNER Say Y here if you want to connect a USB scanner to your computer's - USB port. Please read and - for more information. + USB port. Please read for more + information. This code is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). @@ -13955,10 +14110,10 @@ The module will be called visor.o. If you want to compile it as a module, say M here and read . -USB Compaq iPAQ Driver +USB PocketPC PDA Driver CONFIG_USB_SERIAL_IPAQ - Say Y here if you want to connect to your Compaq iPAQ, HP Jornada 548/568 - or Casio EM500 running Windows CE 3.0 or PocketPC 2002 using a USB + Say Y here if you want to connect to your Compaq iPAQ, HP Jornada, + or any other PDA running Windows CE 3.0 or PocketPC 2002 using a USB cradle/cable. For information on using the driver, read . @@ -14145,6 +14300,17 @@ The module will be called pl2303.o. If you want to compile it as a module, say M here and read . +USB KOBIL chipcard reader +CONFIG_USB_SERIAL_KOBIL_SCT + Say Y here if you want to use one of the following KOBIL USB chipcard + readers: TWIN, KAAN Standard Plus, SecOVID Reader Plus, B1 PRO, KAAN PRO + + Note that you need a current CT-API. + This code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module will be called kobil_sct.o. If you want to compile it as + a module, say M here and read . + USB REINER SCT cyberJack pinpad/e-com chipcard reader CONFIG_USB_SERIAL_CYBERJACK Say Y here if you want to use a cyberJack pinpad/e-com USB chipcard @@ -14235,6 +14401,21 @@ you load the module. Read to learn more. +CONFIG_USB_KONICAWC + Say Y here if you want support for webcams based on a Konica + chipset. This is known to work with the Intel YC76 webcam. + + This driver uses the Video For Linux API. You must enable + (Y or M in config) Video For Linux (under Character Devices) + to use this driver. Information on this API and pointers to + "v4l" programs may be found on the WWW at + . + + This code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module will be called konicawc.o. If you want to compile it as + a module, say M here and read . + USB OV511 Camera support CONFIG_USB_OV511 Say Y here if you want to connect this type of camera to your @@ -14361,7 +14542,7 @@ If in doubt then look at linux/drivers/usb/pegasus.h for the complete list of supported devices. If your particular adapter is not in the list and you are _sure_ it - is Pegasus or Pegasus-II based then send me (pmanolov@users.sourceforge.net) + is Pegasus or Pegasus-II based then send me (petkan@users.sourceforge.net) vendor and device IDs. This code is also available as a module ( = code which can be @@ -14620,7 +14801,7 @@ The module will be called rio500.o. If you want to compile it as a module, say M here and read . -USB Auerswald ISDN device support +Auerswald device support CONFIG_USB_AUERSWALD Say Y here if you want to connect an Auerswald USB ISDN Device to your computer's USB port. @@ -14630,8 +14811,18 @@ The module will be called auerswald.o. If you want to compile it as a module, say M here and read +USB Auerswald ISDN modem support +CONFIG_USB_AUERISDN + Say Y here if you want to enable the ISDN modem option + of your Auerswald ISDN devices. + + This code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module will be called auerswald.o. If you want to compile it as + a module, say M here and read + CONFIG_USB_TIGL - If you own a Texas Instruments graphing calculator and use a + If you own a Texas Instruments graphing calculator and use a TI-GRAPH LINK USB cable (aka SilverLink), then you might be interested in this driver. @@ -14649,6 +14840,28 @@ If unsure, say N. +Texas Instruments parallel link cable support +CONFIG_TIPAR + If you own a Texas Instruments graphing calculator and use a + parallel link cable, then you might be interested in this driver. + + If you enable this driver, you will be able to communicate with + your calculator through a set of device nodes under /dev. The + main advantage of this driver is that you don't have to be root + to use this precise link cable (depending on the permissions on + the device nodes, though). + + This code is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module will be called tipar.o. If you want to compile it as a + module, say M here and read + + If you don't know what a parallel link cable is or what a Texas + Instruments graphing calculator is, then you probably don't need this + driver. + + If unsure, say N. + Tieman Voyager USB Braille display support CONFIG_USB_BRLVOYAGER Say Y here if you want to use the Voyager USB Braille display from @@ -14949,8 +15162,7 @@ CONFIG_USB_BLUETOOTH Say Y here if you want to connect a USB Bluetooth device to your computer's USB port. You will need the Bluetooth stack (available - at ) to fully use - the device. + at ) to fully use the device. This code is also available as a module ( = code which can be inserted in and removed from the running kernel whenever you want). @@ -18959,6 +19171,34 @@ The module is called rtc.o. If you want to compile it as a module, say M here and read . +Generic Real Time Clock Support +CONFIG_GEN_RTC + If you say Y here and create a character special file /dev/rtc with + major number 10 and minor number 135 using mknod ("man mknod"), you + will get access to the real time clock (or hardware clock) built + into your computer. + + In 2.4 and later kernels this is the only way to set and get rtc + time on m68k systems so it is highly recommended. + + It reports status information via the file /proc/driver/rtc and its + behaviour is set by various ioctls on /dev/rtc. If you enable the + "extended RTC operation" below it will also provide an emulation + for RTC_UIE which is required by some programs and may improve + precision in some cases. + + This driver is also available as a module ( = code which can be + inserted in and removed from the running kernel whenever you want). + The module is called genrtc.o. If you want to compile it as a module, + say M here and read . To load the + module automatically add 'alias char-major-10-135 genrtc' to your + /etc/modules.conf + +Extended RTC operation +CONFIG_GEN_RTC_X + Provides an emulation for RTC_UIE which is required by some programs + and may improve precision of the generic RTC support in some cases. + Tadpole ANA H8 Support CONFIG_H8 The Hitachi H8/337 is a microcontroller used to deal with the power @@ -19052,10 +19292,11 @@ The module will be called cs461x.o. If you want to compile it as a module, say M here and read . -Aureal Vortex and Trident 4DWave gameports +Aureal Vortex, Trident 4DWave, and ALi 5451 gameports CONFIG_INPUT_PCIGAME Say Y here if you have a Trident 4DWave DX/NX or Aureal Vortex 1/2 - card. For more information on how to use the driver please read + card or an ALi 5451 chip on your motherboard. For more information + on how to use the driver please read . This driver is also available as a module ( = code which can be @@ -21278,6 +21519,8 @@ HCI Device drivers (interface to the hardware) L2CAP Module (L2CAP protocol) SCO Module (SCO links) + RFCOMM Module (RFCOMM protocol) + BNEP Module (BNEP protocol) Say Y here to enable Linux Bluetooth support and to build BlueZ Core layer. @@ -21306,6 +21549,19 @@ Say Y here to compile SCO support into the kernel or say M to compile it as module (sco.o). +RFCOMM protocol support +CONFIG_BLUEZ_RFCOMM + RFCOMM provides connection oriented stream transport. RFCOMM + support is required for Dialup Networking, OBEX and other Bluetooth + applications. + + Say Y here to compile RFCOMM support into the kernel or say M to + compile it as module (rfcomm.o). + +RFCOMM TTY emulation support +CONFIG_BLUEZ_RFCOMM_TTY + This option enables TTY emulation support for RFCOMM channels. + BNEP protocol support CONFIG_BLUEZ_BNEP BNEP (Bluetooth Network Encapsulation Protocol) is Ethernet @@ -21319,6 +21575,14 @@ Say Y here to compile BNEP support into the kernel or say M to compile it as module (bnep.o). +BNEP multicast filter support +CONFIG_BLUEZ_BNEP_MC_FILTER + This option enables the multicast filter support for BNEP. + +BNEP protocol filter support +CONFIG_BLUEZ_BNEP_PROTO_FILTER + This option enables the protocol filter support for BNEP. + HCI UART driver CONFIG_BLUEZ_HCIUART Bluetooth HCI UART driver. @@ -21333,11 +21597,26 @@ HCI UART (H4) protocol support CONFIG_BLUEZ_HCIUART_H4 UART (H4) is serial protocol for communication between Bluetooth - device and host. This protocol is required for most UART based - Bluetooth device (including PCMCIA and CF). + device and host. This protocol is required for most Bluetooth devices + with UART interface, including PCMCIA and CF cards. Say Y here to compile support for HCI UART (H4) protocol. +HCI BCSP protocol support +CONFIG_BLUEZ_HCIUART_BCSP + BCSP (BlueCore Serial Protocol) is serial protocol for communication + between Bluetooth device and host. This protocol is required for non + USB Bluetooth devices based on CSR BlueCore chip, including PCMCIA and + CF cards. + + Say Y here to compile support for HCI BCSP protocol. + +HCI BCSP transmit CRC with every BCSP packet +CONFIG_BLUEZ_HCIUART_BCSP_TXCRC + If you say Y here, a 16-bit CRC checksum will be transmitted along with + every BCSP (BlueCore Serial Protocol) packet sent to the Bluetooth chip. + This increases reliability, but slightly reduces efficiency. + HCI USB driver CONFIG_BLUEZ_HCIUSB Bluetooth HCI USB driver. @@ -21347,12 +21626,21 @@ Say Y here to compile support for Bluetooth USB devices into the kernel or say M to compile it as module (hci_usb.o). +HCI USB SCO (voice) support +CONFIG_BLUEZ_USB_SCO + This option enables the SCO support in the HCI USB driver. You need this + to transmit voice data with your Bluetooth USB device. And your device + must also support sending SCO data over the HCI layer, because some of + them sends the SCO data to an internal PCM adapter. + + Say Y here to compile support for HCI SCO data. + HCI USB zero packet support CONFIG_BLUEZ_USB_ZERO_PACKET - Support for USB zero packets. This option is provided only as a work around for buggy Bluetooth USB - devices. Do _not_ enable it unless you know for sure that your device + devices. Do NOT enable it unless you know for sure that your device requires zero packets. + Most people should say N here. HCI VHCI Virtual HCI device driver @@ -21399,6 +21687,20 @@ Say Y here to compile support for HCI BlueCard devices into the kernel or say M to compile it as module (bluecard_cs.o). +HCI UART (PC Card) device driver +CONFIG_BLUEZ_HCIBTUART + Bluetooth HCI UART (PC Card) driver. + This driver provides support for Bluetooth PCMCIA devices with + an UART interface: + Xircom CreditCard Bluetooth Adapter + Xircom RealPort2 Bluetooth Adapter + Sphinx PICO Card + H-Soft blue+Card + Cyber-blue Compact Flash Card + + Say Y here to compile support for HCI UART devices into the + kernel or say M to compile it as module (btuart_cs.o). + # The following options are for Linux when running on the Hitachi # SuperH family of RISC microprocessors. @@ -21884,8 +22186,8 @@ Sun3 NCR5380 SCSI CONFIG_SUN3_SCSI This option will enable support for the OBIO (onboard io) NCR5380 - SCSI controller found in the Sun 3/50 and 3/60. Note that this - driver does not provide support for VME SCSI boards. + SCSI controller found in the Sun 3/50 and 3/60, as well as for + "Sun3" type VME scsi controllers also based on the NCR5380. General Linux information on the Sun 3 series (now discontinued) is at . @@ -22610,7 +22912,10 @@ sysctl and with the "keyboard_sends_linux_keycodes=" kernel argument. - If unsure, say Y here. + This option is now deprecated and will be removed in a future + kernel release. + + If unsure, say N here. I2C/SPI Microcode Patch CONFIG_UCODE_PATCH @@ -22888,6 +23193,23 @@ say M here and read . The module will be called radio-sf16fmi.o. +SF16FMR2 Radio +CONFIG_RADIO_SF16FMR2 + Choose Y here if you have one of these FM radio cards. If you + compile the driver into the kernel and your card is not PnP one, you + have to add "sf16fmr2=" to the kernel command line (I/O address is + 0x284 or 0x384, default 0x384). + + In order to control your radio card, you will need to use programs + that are compatible with the Video For Linux API. Information on + this API and pointers to "v4l" programs may be found on the WWW at + . + + If you want to compile this driver as a module ( = code which can be + inserted in and removed from the running kernel whenever you want), + say M here and read . The module + will be called radio-sf16fmr2.o. + Typhoon Radio (a.k.a. EcoRadio) CONFIG_RADIO_TYPHOON Choose Y here if you have one of these FM radio cards, and then fill @@ -24413,13 +24735,24 @@ say M here and read . The module will be called ns83820.o. +Toshiba Type-O IR Port device driver (old driver) +CONFIG_TOSHIBA_OLD + Say Y here if you want to build support for the Toshiba Type-O IR + chipset. This chipset is used by the Toshiba Libretto 100CT, and + many more laptops. This driver is obsolete, will no more be + maintained and will be removed in favor of the new driver. + If you want to compile it as a module, say M here and read + . + The module will be called toshoboe.o. + Toshiba Type-O IR Port device driver CONFIG_TOSHIBA_FIR Say Y here if you want to build support for the Toshiba Type-O IR - chipset. This chipset is used by the Toshiba Libretto 100CT, and - many more laptops. If you want to compile it as a module, say M - here and read . The module will be - called toshoboe.o. + and Donau oboe chipsets. These chipsets are used by the Toshiba + Libretto 100/110CT, Tecra 8100, Portege 7020 and many more laptops. + If you want to compile it as a module, say M here and read + . + The module will be called donauboe.o. SMC IrCC CONFIG_SMC_IRCC_FIR @@ -25438,16 +25771,6 @@ for the zx1 IOMMU and makes root bus bridges appear in PCI config space (required for zx1 agpgart support). -CONFIG_IA64_SGI_SN_SIM - Build a kernel that runs on both the SGI simulator AND on hardware. - There is a very slight performance penalty on hardware for including this - option. - -CONFIG_IA64_SGI_SN_DEBUG - This enables addition debug code that helps isolate - platform/kernel bugs. There is a small but measurable performance - degradation when this option is enabled. - # Choice: pagesize Kernel page size CONFIG_IA64_PAGE_SIZE_4KB @@ -26181,7 +26504,7 @@ If you want to compile this as a module ( = code which can be inserted in and removed from the running kernel whenever you want), say M here and read Documentation/modules.txt. The module - will be called amdtp.o. + will be called cmp.o. OHCI-DV I/O support CONFIG_IEEE1394_DV1394 @@ -26242,6 +26565,90 @@ If unsure, say N. +NatSemi SCx200 support +CONFIG_SCx200 + This provides basic support for the National Semiconductor SCx200 + processor. Right now this is just a driver for the GPIO pins. + + If you don't know what to do here, say N. + + This support is also available as a module. If compiled as a + module, it will be called scx200.o. + +NatSemi SCx200 Watchdog +CONFIG_SCx200_WDT + Enable the built-in watchdog timer support on the National + Semiconductor SCx200 processors. + + If compiled as a module, it will be called scx200_watchdog.o. + +Flash device mapped with DOCCS on NatSemi SCx200 +CONFIG_MTD_SCx200_DOCFLASH + Enable support for a flash chip mapped using the DOCCS signal on a + National Semiconductor SCx200 processor. + + If you don't know what to do here, say N. + + If compiled as a module, it will be called scx200_docflash.o. + +NatSemi SCx200 I2C using GPIO pins +CONFIG_SCx200_GPIO + Enable the use of two GPIO pins of a SCx200 processor as an I2C bus. + + If you don't know what to do here, say N. + + If compiled as a module, it will be called scx200_i2c.o. + +GPIO pin used for SCL +CONFIG_SCx200_I2C_SCL + Enter the GPIO pin number used for the SCL signal. This value can + also be specified with a module parameter. + +GPIO pin used for SDA +CONFIG_SCx200_I2C_SDA + Enter the GPIO pin number used for the SSA signal. This value can + also be specified with a module parameter. + +NatSemi SCx200 ACCESS.bus +CONFIG_SCx200_ACB + Enable the use of the ACCESS.bus controllers of a SCx200 processor. + + If you don't know what to do here, say N. + + If compiled as a module, it will be called scx200_acb.o. + +IPMI top-level message handler +CONFIG_IPMI_HANDLER + This enables the central IPMI message handler, required for IPMI + to work. Note that you must have this enabled to do any other IPMI + things. + + IPMI is a standard for managing sensors (temperature, + voltage, etc.) in a system. + + See Documentation/IPMI.txt for more details on the driver. + + If unsure, say N. + +Generate a panic event to all BMCs on a panic +CONFIG_IPMI_PANIC_EVENT + When a panic occurs, this will cause the IPMI message handler to + generate an IPMI event describing the panic to each interface + registered with the message handler. + +Device interface for IPMI +CONFIG_IPMI_DEVICE_INTERFACE + This provides an IOCTL interface to the IPMI message handler so + userland processes may use IPMI. It supports poll() and select(). + +IPMI KCS handler +CONFIG_IPMI_KCS + Provides a driver for a KCS-style interface to a BMC. + +IPMI Watchdog Timer +CONFIG_IPMI_WATCHDOG + This enables the IPMI watchdog timer. + # # A couple of things I keep forgetting: # capitalize: AppleTalk, Ethernet, DOS, DMA, FAT, FTP, Internet, diff -urN linux-2.4.20/Documentation/DocBook/journal-api.tmpl linux-2.4.21/Documentation/DocBook/journal-api.tmpl --- linux-2.4.20/Documentation/DocBook/journal-api.tmpl 2002-11-28 15:53:08.000000000 -0800 +++ linux-2.4.21/Documentation/DocBook/journal-api.tmpl 2003-06-13 07:51:29.000000000 -0700 @@ -196,6 +196,8 @@ Lock is also providing through journal_{un,}lock_updates(), ext3 uses this when it wants a window with a clean and stable fs for a moment. eg. + + journal_lock_updates() //stop new stuff happening.. @@ -204,11 +206,12 @@ journal_unlock_updates() // carry on with filesystem use. + The opportunities for abuse and DOS attacks with this should be obvious, if you allow unprivileged userspace to trigger codepaths containing these calls. - + Summary @@ -216,9 +219,13 @@ Using the journal is a matter of wrapping the different context changes, being each mount, each modification (transaction) and each changed buffer to tell the journalling layer about them. + + Here is a some pseudo code to give you an idea of how it works, as an example. + + journal_t* my_jnrl = journal_create(); journal_init_{dev,inode}(jnrl,...) @@ -244,6 +251,7 @@ } journal_destroy(my_jrnl); + diff -urN linux-2.4.20/Documentation/DocBook/kernel-api.tmpl linux-2.4.21/Documentation/DocBook/kernel-api.tmpl --- linux-2.4.20/Documentation/DocBook/kernel-api.tmpl 2002-08-02 17:39:42.000000000 -0700 +++ linux-2.4.21/Documentation/DocBook/kernel-api.tmpl 2003-06-13 07:51:29.000000000 -0700 @@ -85,7 +85,11 @@ Memory Management in Linux The Slab Cache !Emm/slab.c - + + User Space Memory Access +!Iinclude/asm-i386/uaccess.h +!Iarch/i386/lib/usercopy.c + diff -urN linux-2.4.20/Documentation/DocBook/kernel-hacking.tmpl linux-2.4.21/Documentation/DocBook/kernel-hacking.tmpl --- linux-2.4.20/Documentation/DocBook/kernel-hacking.tmpl 2002-11-28 15:53:08.000000000 -0800 +++ linux-2.4.21/Documentation/DocBook/kernel-hacking.tmpl 2003-06-13 07:51:29.000000000 -0700 @@ -1139,11 +1139,6 @@ - Labeled elements - - - - typeof diff -urN linux-2.4.20/Documentation/DocBook/kernel-locking.tmpl linux-2.4.21/Documentation/DocBook/kernel-locking.tmpl --- linux-2.4.20/Documentation/DocBook/kernel-locking.tmpl 2002-08-02 17:39:42.000000000 -0700 +++ linux-2.4.21/Documentation/DocBook/kernel-locking.tmpl 2003-06-13 07:51:29.000000000 -0700 @@ -1055,10 +1055,8 @@ Another common problem is deleting timers which restart themselves (by calling add_timer() at the end of their timer function). Because this is a fairly common case - which is prone to races, you can put a call to - timer_exit() at the very end of your timer function, - and user del_timer_sync() - (include/linux/timer.h) + which is prone to races, you should use del_timer_sync() + (include/linux/timer.h) to handle this case. It returns the number of times the timer had to be deleted before we finally stopped it from adding itself back in. diff -urN linux-2.4.20/Documentation/DocBook/mousedrivers.tmpl linux-2.4.21/Documentation/DocBook/mousedrivers.tmpl --- linux-2.4.20/Documentation/DocBook/mousedrivers.tmpl 2001-09-30 12:26:05.000000000 -0700 +++ linux-2.4.21/Documentation/DocBook/mousedrivers.tmpl 2003-06-13 07:51:29.000000000 -0700 @@ -153,11 +153,17 @@ __init ourmouse_init(void) { - if(check_region(OURMOUSE_BASE, 3)) + if (request_region(OURMOUSE_BASE, 3, "ourmouse") < 0) { + printk(KERN_ERR "ourmouse: request_region failed.\n"); return -ENODEV; - request_region(OURMOUSE_BASE, 3, "ourmouse"); + } + + if (misc_register(&our_mouse) < 0) { + printk(KERN_ERR "ourmouse: cannot register misc device.\n"); + release_region(OURMOUSE_BASE, 3); + return -EBUSY; + } - misc_register(&our_mouse); return 0; } @@ -177,18 +183,20 @@ so it is a good idea to obtain a current copy of this file first. - Our code then is fairly simple. We check nobody else has taken our - address space. Having done so we reserve it to ensure nobody stamps - on our device while probing for other ISA bus devices. Such a probe - might confuse our device. + Our code then is fairly simple. We reserve our I/O address space with + request_region, checking to make sure that it succeeded (i.e. the + space wasn't reserved by anyone else). - Then we tell the misc driver that we wish to own a minor number. We also + Then we ask the misc driver to allocate our minor device number. We also hand it our name (which is used in /proc/misc) and a set of file operations that are to be used. The file operations work exactly like the file operations you would register for a normal character device. The misc device itself is simply acting as a redirector for requests. + Since misc_register can fail, it is important to check for failure + and act accordingly (which in the case of a mouse driver is to abort, + since you can't use the mouse without a working device node). Next, in order to be able to use and test our code we need to add some diff -urN linux-2.4.20/Documentation/DocBook/procfs-guide.tmpl linux-2.4.21/Documentation/DocBook/procfs-guide.tmpl --- linux-2.4.20/Documentation/DocBook/procfs-guide.tmpl 2001-09-08 12:20:25.000000000 -0700 +++ linux-2.4.21/Documentation/DocBook/procfs-guide.tmpl 2003-06-13 07:51:29.000000000 -0700 @@ -99,7 +99,7 @@ I'd like to thank Jeff Garzik - jgarzik@mandrakesoft.com and Alexander Viro + jgarzik@pobox.com and Alexander Viro viro@math.psu.edu for their input, Tim Waugh twaugh@redhat.com for his Selfdocbook, diff -urN linux-2.4.20/Documentation/DocBook/tulip-user.tmpl linux-2.4.21/Documentation/DocBook/tulip-user.tmpl --- linux-2.4.20/Documentation/DocBook/tulip-user.tmpl 2001-10-05 12:06:51.000000000 -0700 +++ linux-2.4.21/Documentation/DocBook/tulip-user.tmpl 2003-06-13 07:51:29.000000000 -0700 @@ -10,7 +10,7 @@ Garzik
- jgarzik@mandrakesoft.com + jgarzik@pobox.com
@@ -57,7 +57,7 @@ Introduction The Tulip Ethernet Card Driver -is maintained by Jeff Garzik (jgarzik@mandrakesoft.com). +is maintained by Jeff Garzik (jgarzik@pobox.com). diff -urN linux-2.4.20/Documentation/DocBook/via-audio.tmpl linux-2.4.21/Documentation/DocBook/via-audio.tmpl --- linux-2.4.20/Documentation/DocBook/via-audio.tmpl 2001-12-21 09:41:53.000000000 -0800 +++ linux-2.4.21/Documentation/DocBook/via-audio.tmpl 2003-06-13 07:51:29.000000000 -0700 @@ -2,7 +2,7 @@ - Via 686 Audio Driver for Linux + Via 686/8233/8235 Audio Driver for Linux @@ -54,7 +54,9 @@ The Via VT82C686A "super southbridge" chips contain AC97-compatible audio logic which features dual 16-bit stereo PCM sound channels (full duplex), plus a third PCM channel intended for use - in hardware-assisted FM synthesis. + in hardware-assisted FM synthesis. The VIA VT8233/8235 extends this + support to include six channel output and additional record + facilities. The current Linux kernel audio driver for this family of chips @@ -199,7 +201,9 @@ This driver by default supports all PCI audio devices which report a vendor id of 0x1106, and a device id of 0x3058. Subsystem vendor - and device ids are not examined. + and device ids are not examined. The 8233 support covers all devices + with a device id of 0x3059 and vendor id of 0x1106. Again subsystem + ids are ignored as they usually hold the AC97 codec vendor information. GNU indent formatting options: @@ -224,6 +228,21 @@ Driver ChangeLog + +Version 1.9.1-ac + + + + + Added VIA 8233/8235 support including six channel support. We don't + yet support S/PDIF, EAPD, using the second DSP channel and FM channels + as extra dsp devices, or the extra record channel. New features tested + on a VIA EPIA-M kindly provided by VIA. + + + + + Version 1.9.1 diff -urN linux-2.4.20/Documentation/DocBook/videobook.tmpl linux-2.4.21/Documentation/DocBook/videobook.tmpl --- linux-2.4.20/Documentation/DocBook/videobook.tmpl 2001-07-15 16:15:44.000000000 -0700 +++ linux-2.4.21/Documentation/DocBook/videobook.tmpl 2003-06-13 07:51:29.000000000 -0700 @@ -146,16 +146,17 @@ int __init myradio_init(struct video_init *v) { - if(check_region(io, MY_IO_SIZE)) + if(!request_region(io, MY_IO_SIZE, "myradio")) { printk(KERN_ERR "myradio: port 0x%03X is in use.\n", io); return -EBUSY; } - if(video_device_register(&my_radio, VFL_TYPE_RADIO)==-1) + if(video_device_register(&my_radio, VFL_TYPE_RADIO)==-1) { + release_region(io, MY_IO_SIZE); return -EINVAL; - request_region(io, MY_IO_SIZE, "myradio"); + } return 0; } @@ -920,7 +921,7 @@ int __init mycamera_init(struct video_init *v) { - if(check_region(io, MY_IO_SIZE)) + if(!request_region(io, MY_IO_SIZE, "mycamera")) { printk(KERN_ERR "mycamera: port 0x%03X is in use.\n", io); @@ -928,9 +929,10 @@ } if(video_device_register(&my_camera, - VFL_TYPE_GRABBER)==-1) + VFL_TYPE_GRABBER)==-1) { + release_region(io, MY_IO_SIZE); return -EINVAL; - request_region(io, MY_IO_SIZE, "mycamera"); + } return 0; } diff -urN linux-2.4.20/Documentation/IPMI.txt linux-2.4.21/Documentation/IPMI.txt --- linux-2.4.20/Documentation/IPMI.txt 1969-12-31 16:00:00.000000000 -0800 +++ linux-2.4.21/Documentation/IPMI.txt 2003-06-13 07:51:29.000000000 -0700 @@ -0,0 +1,364 @@ + + The Linux IPMI Driver + --------------------- + Corey Minyard + + + +The Intelligent Platform Management Interface, or IPMI, is a +standard for controlling intelligent devices that monitor a system. +It provides for dynamic discovery of sensors in the system and the +ability to monitor the sensors and be informed when the sensor's +values change or go outside certain boundaries. It also has a +standardized database for field-replacable units (FRUs) and a watchdog +timer. + +To use this, you need an interface to an IPMI controller in your +system (called a Baseboard Management Controller, or BMC) and +management software that can use the IPMI system. + +This document describes how to use the IPMI driver for Linux. If you +are not familiar with IPMI itself, see the web site at +http://www.intel.com/design/servers/ipmi/index.htm. IPMI is a big +subject and I can't cover it all here! + +Basic Design +------------ + +The Linux IPMI driver is designed to be very modular and flexible, you +only need to take the pieces you need and you can use it in many +different ways. Because of that, it's broken into many chunks of +code. These chunks are: + +ipmi_msghandler - This is the central piece of software for the IPMI +system. It handles all messages, message timing, and responses. The +IPMI users tie into this, and the IPMI physical interfaces (called +System Management Interfaces, or SMIs) also tie in here. This +provides the kernelland interface for IPMI, but does not provide an +interface for use by application processes. + +ipmi_devintf - This provides a userland IOCTL interface for the IPMI +driver, each open file for this device ties in to the message handler +as an IPMI user. + +ipmi_kcs_drv - A driver for the KCS SMI. Most system have a KCS +interface for IPMI. + + +Much documentation for the interface is in the include files. The +IPMI include files are: + +ipmi.h - Contains the user interface and IOCTL interface for IPMI. + +ipmi_smi.h - Contains the interface for SMI drivers to use. + +ipmi_msgdefs.h - General definitions for base IPMI messaging. + + +Addressing +---------- + +The IPMI addressing works much like IP addresses, you have an overlay +to handle the different address types. The overlay is: + + struct ipmi_addr + { + int addr_type; + short channel; + char data[IPMI_MAX_ADDR_SIZE]; + }; + +The addr_type determines what the address really is. The driver +currently understands two different types of addresses. + +"System Interface" addresses are defined as: + + struct ipmi_system_interface_addr + { + int addr_type; + short channel; + }; + +and the type is IPMI_SYSTEM_INTERFACE_ADDR_TYPE. This is used for talking +straight to the BMC on the current card. The channel must be +IPMI_BMC_CHANNEL. + +Messages that are destined to go out on the IPMB bus use the +IPMI_IPMB_ADDR_TYPE address type. The format is + + struct ipmi_ipmb_addr + { + int addr_type; + short channel; + unsigned char slave_addr; + unsigned char lun; + }; + +The "channel" here is generally zero, but some devices support more +than one channel, it corresponds to the channel as defined in the IPMI +spec. + + +Messages +-------- + +Messages are defined as: + +struct ipmi_msg +{ + unsigned char netfn; + unsigned char lun; + unsigned char cmd; + unsigned char *data; + int data_len; +}; + +The driver takes care of adding/stripping the header information. The +data portion is just the data to be send (do NOT put addressing info +here) or the response. Note that the completion code of a response is +the first item in "data", it is not stripped out because that is how +all the messages are defined in the spec (and thus makes counting the +offsets a little easier :-). + +When using the IOCTL interface from userland, you must provide a block +of data for "data", fill it, and set data_len to the length of the +block of data, even when receiving messages. Otherwise the driver +will have no place to put the message. + +Messages coming up from the message handler in kernelland will come in +as: + + struct ipmi_recv_msg + { + struct list_head link; + + /* The type of message as defined in the "Receive Types" + defines above. */ + int recv_type; + + ipmi_user_t *user; + struct ipmi_addr addr; + long msgid; + struct ipmi_msg msg; + + /* Call this when done with the message. It will presumably free + the message and do any other necessary cleanup. */ + void (*done)(struct ipmi_recv_msg *msg); + + /* Place-holder for the data, don't make any assumptions about + the size or existence of this, since it may change. */ + unsigned char msg_data[IPMI_MAX_MSG_LENGTH]; + }; + +You should look at the receive type and handle the message +appropriately. + + +The Upper Layer Interface (Message Handler) +------------------------------------------- + +The upper layer of the interface provides the users with a consistent +view of the IPMI interfaces. It allows multiple SMI interfaces to be +addressed (because some boards actually have multiple BMCs on them) +and the user should not have to care what type of SMI is below them. + + +Creating the User + +To user the message handler, you must first create a user using +ipmi_create_user. The interface number specifies which SMI you want +to connect to, and you must supply callback functions to be called +when data comes in. The callback function can run at interrupt level, +so be careful using the callbacks. This also allows to you pass in a +piece of data, the handler_data, that will be passed back to you on +all calls. + +Once you are done, call ipmi_destroy_user() to get rid of the user. + +From userland, opening the device automatically creates a user, and +closing the device automatically destroys the user. + + +Messaging + +To send a message from kernel-land, the ipmi_request() call does +pretty much all message handling. Most of the parameter are +self-explanatory. However, it takes a "msgid" parameter. This is NOT +the sequence number of messages. It is simply a long value that is +passed back when the response for the message is returned. You may +use it for anything you like. + +Responses come back in the function pointed to by the ipmi_recv_hndl +field of the "handler" that you passed in to ipmi_create_user(). +Remember again, these may be running at interrupt level. Remember to +look at the receive type, too. + +From userland, you fill out an ipmi_req_t structure and use the +IPMICTL_SEND_COMMAND ioctl. For incoming stuff, you can use select() +or poll() to wait for messages to come in. However, you cannot use +read() to get them, you must call the IPMICTL_RECEIVE_MSG with the +ipmi_recv_t structure to actually get the message. Remember that you +must supply a pointer to a block of data in the msg.data field, and +you must fill in the msg.data_len field with the size of the data. +This gives the receiver a place to actually put the message. + +If the message cannot fit into the data you provide, you will get an +EMSGSIZE error and the driver will leave the data in the receive +queue. If you want to get it and have it truncate the message, us +the IPMICTL_RECEIVE_MSG_TRUNC ioctl. + +When you send a command (which is defined by the lowest-order bit of +the netfn per the IPMI spec) on the IPMB bus, the driver will +automatically assign the sequence number to the command and save the +command. If the response is not receive in the IPMI-specified 5 +seconds, it will generate a response automatically saying the command +timed out. If an unsolicited response comes in (if it was after 5 +seconds, for instance), that response will be ignored. + +In kernelland, after you receive a message and are done with it, you +MUST call ipmi_free_recv_msg() on it, or you will leak messages. Note +that you should NEVER mess with the "done" field of a message, that is +required to properly clean up the message. + +Note that when sending, there is an ipmi_request_supply_msgs() call +that lets you supply the smi and receive message. This is useful for +pieces of code that need to work even if the system is out of buffers +(the watchdog timer uses this, for instance). You supply your own +buffer and own free routines. This is not recommended for normal use, +though, since it is tricky to manage your own buffers. + + +Events and Incoming Commands + +The driver takes care of polling for IPMI events and receiving +commands (commands are messages that are not responses, they are +commands that other things on the IPMB bus have sent you). To receive +these, you must register for them, they will not automatically be sent +to you. + +To receive events, you must call ipmi_set_gets_events() and set the +"val" to non-zero. Any events that have been received by the driver +since startup will immediately be delivered to the first user that +registers for events. After that, if multiple users are registered +for events, they will all receive all events that come in. + +For receiving commands, you have to individually register commands you +want to receive. Call ipmi_register_for_cmd() and supply the netfn +and command name for each command you want to receive. Only one user +may be registered for each netfn/cmd, but different users may register +for different commands. + +From userland, equivalent IOCTLs are provided to do these functions. + + +The Lower Layer (SMI) Interface +------------------------------- + +As mentioned before, multiple SMI interfaces may be registered to the +message handler, each of these is assigned an interface number when +they register with the message handler. They are generally assigned +in the order they register, although if an SMI unregisters and then +another one registers, all bets are off. + +The ipmi_smi.h defines the interface for SMIs, see that for more +details. + + +The KCS Driver +-------------- + +The KCS driver allows up to 4 KCS interfaces to be configured in the +system. By default, the driver will register one KCS interface at the +spec-specified I/O port 0xca2 without interrupts. You can change this +at module load time (for a module) with: + + insmod ipmi_kcs_drv.o kcs_ports=,... kcs_addrs=, + kcs_irqs=,... kcs_trydefaults=[0|1] + +The KCS driver supports two types of interfaces, ports (for I/O port +based KCS interfaces) and memory addresses (for KCS interfaces in +memory). The driver will support both of them simultaneously, setting +the port to zero (or just not specifying it) will allow the memory +address to be used. The port will override the memory address if it +is specified and non-zero. kcs_trydefaults sets whether the standard +IPMI interface at 0xca2 and any interfaces specified by ACPE are +tried. By default, the driver tries it, set this value to zero to +turn this off. + +When compiled into the kernel, the addresses can be specified on the +kernel command line as: + + ipmi_kcs=:,:....,[nodefault] + +The values is either "p" or "m" for port or memory +addresses. So for instance, a KCS interface at port 0xca2 using +interrupt 9 and a memory interface at address 0xf9827341 with no +interrupt would be specified "ipmi_kcs=p0xca2:9,m0xf9827341". +If you specify zero for in irq or don't specify it, the driver will +run polled unless the software can detect the interrupt to use in the +ACPI tables. + +By default, the driver will attempt to detect a KCS device at the +spec-specified 0xca2 address and any address specified by ACPI. If +you want to turn this off, use the "nodefault" option. + +If you have high-res timers compiled into the kernel, the driver will +use them to provide much better performance. Note that if you do not +have high-res timers enabled in the kernel and you don't have +interrupts enabled, the driver will run VERY slowly. Don't blame me, +the KCS interface sucks. + + +Other Pieces +------------ + +Watchdog + +A watchdog timer is provided that implements the Linux-standard +watchdog timer interface. It has three module parameters that can be +used to control it: + + insmod ipmi_watchdog timeout= pretimeout= action= + preaction= preop= + +The timeout is the number of seconds to the action, and the pretimeout +is the amount of seconds before the reset that the pre-timeout panic will +occur (if pretimeout is zero, then pretimeout will not be enabled). + +The action may be "reset", "power_cycle", or "power_off", and +specifies what to do when the timer times out, and defaults to +"reset". + +The preaction may be "pre_smi" for an indication through the SMI +interface, "pre_int" for an indication through the SMI with an +interrupts, and "pre_nmi" for a NMI on a preaction. This is how +the driver is informed of the pretimeout. + +The preop may be set to "preop_none" for no operation on a pretimeout, +"preop_panic" to set the preoperation to panic, or "preop_give_data" +to provide data to read from the watchdog device when the pretimeout +occurs. A "pre_nmi" setting CANNOT be used with "preop_give_data" +because you can't do data operations from an NMI. + +When preop is set to "preop_give_data", one byte comes ready to read +on the device when the pretimeout occurs. Select and fasync work on +the device, as well. + +When compiled into the kernel, the kernel command line is available +for configuring the watchdog: + + ipmi_wdog=[,[,