From 2b5adc93aa9f4153657856f7cc74481159104490 Mon Sep 17 00:00:00 2001 From: Linus Torvalds Date: Tue, 13 Sep 2005 09:45:20 -0700 Subject: [PATCH] --- yaml --- r: 8815 b: refs/heads/master c: a8cd2e5045688157479a654786b2c08ab85f4d8f h: refs/heads/master i: 8813: 7615217e8abf22474da46322d5143e46891d1e45 8811: 2edc93ba5301aafc1ca0e2a46d4fc9ae116fb497 8807: 216d9300e09f2b717e7bc48ad2ec9c28cf0b4f36 8799: 6f940ccce34b2f1da38951744fe9535f441771b5 v: v3 --- [refs] | 2 +- trunk/COPYING | 4 +- trunk/Documentation/00-INDEX | 2 +- trunk/Documentation/CodingStyle | 3 + trunk/Documentation/DMA-API.txt | 2 +- trunk/Documentation/DocBook/journal-api.tmpl | 4 +- trunk/Documentation/DocBook/usb.tmpl | 2 +- trunk/Documentation/MSI-HOWTO.txt | 2 +- trunk/Documentation/RCU/RTFP.txt | 36 +- trunk/Documentation/RCU/UP.txt | 79 +- trunk/Documentation/RCU/checklist.txt | 23 +- trunk/Documentation/RCU/rcu.txt | 48 + trunk/Documentation/RCU/whatisRCU.txt | 902 +++++++++ trunk/Documentation/aoe/mkshelf.sh | 6 +- trunk/Documentation/cciss.txt | 4 +- trunk/Documentation/connector/cn_test.c | 194 ++ trunk/Documentation/connector/connector.txt | 133 ++ .../Documentation/cpu-freq/cpufreq-stats.txt | 2 +- trunk/Documentation/cpusets.txt | 2 +- trunk/Documentation/crypto/descore-readme.txt | 2 +- trunk/Documentation/dontdiff | 1 + trunk/Documentation/fb/intel810.txt | 56 +- .../feature-removal-schedule.txt | 17 - .../firmware_class/firmware_sample_driver.c | 8 +- trunk/Documentation/input/appletouch.txt | 84 + trunk/Documentation/ioctl/cdrom.txt | 2 +- trunk/Documentation/kbuild/makefiles.txt | 14 +- trunk/Documentation/kdump/kdump.txt | 11 +- trunk/Documentation/kernel-parameters.txt | 10 + trunk/Documentation/mono.txt | 2 +- trunk/Documentation/networking/bonding.txt | 4 +- trunk/Documentation/networking/wan-router.txt | 4 +- trunk/Documentation/oops-tracing.txt | 25 +- trunk/Documentation/pci.txt | 2 +- trunk/Documentation/pm.txt | 6 + .../powerpc/eeh-pci-error-recovery.txt | 2 +- trunk/Documentation/s390/s390dbf.txt | 2 +- trunk/Documentation/scsi/00-INDEX | 2 + trunk/Documentation/scsi/ibmmca.txt | 2 +- trunk/Documentation/scsi/scsi_eh.txt | 479 +++++ .../sound/alsa/ALSA-Configuration.txt | 2 +- trunk/Documentation/sysrq.txt | 2 +- .../Documentation/uml/UserModeLinux-HOWTO.txt | 2 +- trunk/Documentation/usb/gadget_serial.txt | 2 +- trunk/Documentation/usb/proc_usb_info.txt | 13 +- trunk/Documentation/video4linux/Zoran | 2 +- trunk/Documentation/x86_64/boot-options.txt | 5 + trunk/Kbuild | 5 +- trunk/MAINTAINERS | 7 + trunk/Makefile | 53 +- trunk/REPORTING-BUGS | 14 +- trunk/arch/alpha/kernel/alpha_ksyms.c | 9 - trunk/arch/alpha/kernel/osf_sys.c | 3 +- trunk/arch/alpha/kernel/smp.c | 172 -- trunk/arch/arm/Kconfig | 4 +- trunk/arch/arm/Kconfig.debug | 2 +- trunk/arch/arm/Makefile | 2 +- trunk/arch/arm/common/scoop.c | 2 +- trunk/arch/arm/kernel/calls.S | 5 +- trunk/arch/arm/kernel/entry-common.S | 4 + trunk/arch/arm/mach-pxa/Kconfig | 49 +- trunk/arch/arm/mach-pxa/Makefile | 1 + trunk/arch/arm/mach-pxa/corgi.c | 65 +- trunk/arch/arm/mach-pxa/corgi_lcd.c | 197 +- trunk/arch/arm/mach-pxa/corgi_ssp.c | 66 +- trunk/arch/arm/mach-pxa/sharpsl.h | 34 + trunk/arch/arm/mach-pxa/spitz.c | 380 ++++ trunk/arch/cris/Makefile | 2 +- trunk/arch/i386/kernel/acpi/earlyquirk.c | 10 + trunk/arch/i386/kernel/acpi/wakeup.S | 6 - trunk/arch/i386/kernel/cpu/common.c | 2 +- trunk/arch/i386/kernel/entry.S | 4 +- trunk/arch/i386/kernel/io_apic.c | 7 +- trunk/arch/i386/kernel/reboot.c | 7 +- trunk/arch/i386/kernel/setup.c | 5 + trunk/arch/i386/kernel/smpboot.c | 5 +- trunk/arch/i386/kernel/srat.c | 8 +- trunk/arch/i386/kernel/vmlinux.lds.S | 11 +- trunk/arch/i386/pci/acpi.c | 17 +- trunk/arch/i386/pci/mmconfig.c | 7 - trunk/arch/ia64/Makefile | 2 +- trunk/arch/ia64/hp/sim/boot/boot_head.S | 31 +- trunk/arch/ia64/ia32/sys_ia32.c | 2 +- trunk/arch/ia64/kernel/asm-offsets.c | 40 +- trunk/arch/ia64/kernel/ivt.S | 1 - trunk/arch/ia64/kernel/mca.c | 830 +++++---- trunk/arch/ia64/kernel/mca_asm.S | 1358 +++++++------- trunk/arch/ia64/kernel/mca_drv.c | 37 +- trunk/arch/ia64/kernel/minstate.h | 88 +- trunk/arch/ia64/kernel/palinfo.c | 115 +- trunk/arch/ia64/kernel/salinfo.c | 62 +- trunk/arch/ia64/kernel/unwind.c | 22 - trunk/arch/ia64/mm/init.c | 15 +- trunk/arch/ia64/sn/kernel/setup.c | 30 +- trunk/arch/m32r/Kconfig | 4 +- trunk/arch/m32r/kernel/smp.c | 48 +- .../arch/m68knommu/platform/68328/head-de2.S | 135 ++ .../arch/m68knommu/platform/68360/head-ram.S | 408 ++++ .../arch/m68knommu/platform/68360/head-rom.S | 420 +++++ .../mips/kernel/{offset.c => asm-offsets.c} | 0 trunk/arch/mips/kernel/irixsig.c | 17 +- trunk/arch/mips/kernel/sysirix.c | 3 +- trunk/arch/mips/lib/dec_and_lock.c | 8 - trunk/arch/parisc/lib/Makefile | 2 - trunk/arch/parisc/lib/bitops.c | 4 +- trunk/arch/parisc/lib/debuglocks.c | 277 --- trunk/arch/ppc/Kconfig | 9 + trunk/arch/ppc/Makefile | 18 +- trunk/arch/ppc/kernel/cpu_setup_6xx.S | 1 - trunk/arch/ppc/kernel/cpu_setup_power4.S | 1 - trunk/arch/ppc/kernel/dma-mapping.c | 2 +- trunk/arch/ppc/kernel/head.S | 28 +- trunk/arch/ppc/kernel/idle.c | 6 +- trunk/arch/ppc/kernel/smp.c | 44 +- trunk/arch/ppc/kernel/temp.c | 1 - trunk/arch/ppc/kernel/time.c | 1 - trunk/arch/ppc/kernel/traps.c | 22 + trunk/arch/ppc/kernel/vmlinux.lds.S | 4 + trunk/arch/ppc/lib/Makefile | 1 - trunk/arch/ppc/lib/dec_and_lock.c | 8 - trunk/arch/ppc/mm/fault.c | 6 +- trunk/arch/ppc/platforms/chrp_time.c | 1 - trunk/arch/ppc/platforms/pmac_sleep.S | 2 + trunk/arch/ppc/platforms/pmac_smp.c | 85 +- trunk/arch/ppc/syslib/cpc700_pic.c | 12 +- trunk/arch/ppc/syslib/i8259.c | 13 +- trunk/arch/ppc/syslib/open_pic2.c | 12 +- trunk/arch/ppc/syslib/ppc403_pic.c | 11 +- trunk/arch/ppc/syslib/prep_nvram.c | 1 - trunk/arch/ppc/syslib/xilinx_pic.c | 13 +- trunk/arch/ppc64/Makefile | 13 +- trunk/arch/ppc64/kernel/cpu_setup_power4.S | 1 - trunk/arch/ppc64/kernel/iSeries_pci.c | 2 +- trunk/arch/ppc64/kernel/maple_pci.c | 56 +- trunk/arch/ppc64/kernel/pSeries_setup.c | 10 +- trunk/arch/ppc64/kernel/pSeries_smp.c | 13 +- trunk/arch/ppc64/kernel/pci.c | 425 ++++- trunk/arch/ppc64/kernel/pmac_pci.c | 60 +- trunk/arch/ppc64/kernel/pmac_setup.c | 13 + trunk/arch/ppc64/kernel/process.c | 34 + trunk/arch/ppc64/kernel/ptrace.c | 28 + trunk/arch/ppc64/kernel/ptrace32.c | 34 +- trunk/arch/ppc64/kernel/ras.c | 2 - trunk/arch/ppc64/kernel/setup.c | 16 - trunk/arch/ppc64/kernel/signal.c | 9 + trunk/arch/ppc64/kernel/signal32.c | 8 + trunk/arch/ppc64/kernel/xics.c | 44 +- trunk/arch/ppc64/lib/dec_and_lock.c | 8 - trunk/arch/ppc64/lib/locks.c | 14 +- trunk/arch/ppc64/mm/fault.c | 31 +- trunk/arch/ppc64/xmon/privinst.h | 1 - trunk/arch/ppc64/xmon/xmon.c | 20 +- trunk/arch/s390/kernel/compat_linux.c | 2 +- trunk/arch/s390/lib/spinlock.c | 12 +- trunk/arch/sh/Makefile | 2 +- trunk/arch/sh/boards/adx/irq_maskreg.c | 14 +- trunk/arch/sh/boards/bigsur/io.c | 8 +- trunk/arch/sh/boards/bigsur/irq.c | 28 +- trunk/arch/sh/boards/cqreek/irq.c | 14 +- trunk/arch/sh/boards/harp/irq.c | 14 +- trunk/arch/sh/boards/overdrive/irq.c | 14 +- .../arch/sh/boards/renesas/hs7751rvoip/irq.c | 14 +- trunk/arch/sh/boards/renesas/rts7751r2d/irq.c | 14 +- trunk/arch/sh/boards/renesas/systemh/irq.c | 14 +- trunk/arch/sh/boards/superh/microdev/irq.c | 14 +- trunk/arch/sh/cchips/hd6446x/hd64465/io.c | 8 +- trunk/arch/sh/cchips/voyagergx/irq.c | 14 +- trunk/arch/sh/kernel/cpu/irq_imask.c | 14 +- trunk/arch/sh/kernel/cpu/irq_ipr.c | 28 +- trunk/arch/sh/kernel/cpu/sh4/irq_intc2.c | 14 +- trunk/arch/sh64/Makefile | 2 +- trunk/arch/sh64/kernel/irq_intc.c | 14 +- trunk/arch/sparc/kernel/module.c | 9 +- trunk/arch/sparc/kernel/sparc_ksyms.c | 41 +- trunk/arch/sparc/lib/Makefile | 2 - trunk/arch/sparc/lib/debuglocks.c | 202 -- trunk/arch/sparc/lib/mul.S | 2 + trunk/arch/sparc/lib/rem.S | 2 + trunk/arch/sparc/lib/sdiv.S | 2 + trunk/arch/sparc/lib/udiv.S | 2 + trunk/arch/sparc/lib/umul.S | 2 + trunk/arch/sparc/lib/urem.S | 2 + trunk/arch/sparc64/kernel/process.c | 5 - trunk/arch/sparc64/kernel/sparc64_ksyms.c | 5 - trunk/arch/sparc64/lib/Makefile | 1 - trunk/arch/sparc64/lib/debuglocks.c | 366 ---- trunk/arch/um/Makefile | 9 +- trunk/arch/um/include/mem.h | 12 +- trunk/arch/um/kernel/dyn.lds.S | 37 +- trunk/arch/um/kernel/ksyms.c | 5 - trunk/arch/um/kernel/physmem.c | 35 - trunk/arch/um/kernel/trap_kern.c | 6 +- trunk/arch/um/kernel/uml.lds.S | 14 +- trunk/arch/v850/kernel/irq.c | 14 +- trunk/arch/v850/kernel/setup.c | 14 +- trunk/arch/v850/kernel/sim.c | 14 +- trunk/arch/x86_64/boot/Makefile | 2 +- trunk/arch/x86_64/boot/compressed/misc.c | 6 +- trunk/arch/x86_64/defconfig | 65 +- trunk/arch/x86_64/ia32/ia32entry.S | 51 +- trunk/arch/x86_64/ia32/sys_ia32.c | 2 +- trunk/arch/x86_64/kernel/Makefile | 1 + trunk/arch/x86_64/kernel/acpi/sleep.c | 1 - trunk/arch/x86_64/kernel/aperture.c | 2 + trunk/arch/x86_64/kernel/apic.c | 42 +- trunk/arch/x86_64/kernel/asm-offsets.c | 1 - trunk/arch/x86_64/kernel/crash.c | 1 - trunk/arch/x86_64/kernel/e820.c | 2 +- trunk/arch/x86_64/kernel/early_printk.c | 46 + trunk/arch/x86_64/kernel/entry.S | 222 ++- trunk/arch/x86_64/kernel/genapic.c | 18 +- trunk/arch/x86_64/kernel/genapic_cluster.c | 4 +- trunk/arch/x86_64/kernel/genapic_flat.c | 12 +- trunk/arch/x86_64/kernel/head.S | 2 +- trunk/arch/x86_64/kernel/i8259.c | 23 +- trunk/arch/x86_64/kernel/init_task.c | 2 +- trunk/arch/x86_64/kernel/io_apic.c | 34 +- trunk/arch/x86_64/kernel/irq.c | 1 - trunk/arch/x86_64/kernel/mce.c | 44 +- trunk/arch/x86_64/kernel/mpparse.c | 5 +- trunk/arch/x86_64/kernel/msr.c | 279 --- trunk/arch/x86_64/kernel/nmi.c | 13 +- trunk/arch/x86_64/kernel/pci-gart.c | 8 +- trunk/arch/x86_64/kernel/process.c | 38 +- trunk/arch/x86_64/kernel/setup.c | 89 +- trunk/arch/x86_64/kernel/setup64.c | 3 +- trunk/arch/x86_64/kernel/smp.c | 129 +- trunk/arch/x86_64/kernel/smpboot.c | 47 +- trunk/arch/x86_64/kernel/suspend.c | 17 +- trunk/arch/x86_64/kernel/time.c | 2 - trunk/arch/x86_64/kernel/traps.c | 57 +- trunk/arch/x86_64/kernel/vmlinux.lds.S | 19 +- trunk/arch/x86_64/kernel/vsyscall.c | 8 +- trunk/arch/x86_64/mm/fault.c | 10 +- trunk/arch/x86_64/mm/init.c | 79 +- trunk/arch/x86_64/mm/k8topology.c | 13 +- trunk/arch/x86_64/mm/numa.c | 9 +- trunk/arch/x86_64/mm/srat.c | 68 +- trunk/arch/x86_64/pci/k8-bus.c | 10 +- trunk/arch/x86_64/pci/mmconfig.c | 7 - trunk/arch/xtensa/Makefile | 2 +- trunk/drivers/Kconfig | 2 + trunk/drivers/Makefile | 2 + trunk/drivers/acpi/sleep/main.c | 8 - trunk/drivers/acpi/sleep/poweroff.c | 4 +- trunk/drivers/acpi/sleep/proc.c | 2 - trunk/drivers/base/attribute_container.c | 5 +- trunk/drivers/base/class.c | 10 +- trunk/drivers/base/dmapool.c | 3 +- trunk/drivers/base/firmware_class.c | 9 +- trunk/drivers/base/map.c | 3 +- trunk/drivers/base/platform.c | 3 +- trunk/drivers/block/aoe/aoe.h | 12 +- trunk/drivers/block/cciss.c | 646 ++++--- trunk/drivers/block/cciss.h | 10 +- trunk/drivers/block/cciss_cmd.h | 8 +- trunk/drivers/block/cciss_scsi.c | 69 +- trunk/drivers/block/cfq-iosched.c | 3 + trunk/drivers/block/paride/pcd.c | 3 +- trunk/drivers/block/paride/pf.c | 3 +- trunk/drivers/block/paride/pg.c | 3 +- trunk/drivers/block/paride/pt.c | 3 +- trunk/drivers/block/pktcdvd.c | 85 +- trunk/drivers/block/scsi_ioctl.c | 1 + trunk/drivers/block/swim3.c | 9 +- trunk/drivers/block/swim_iop.c | 3 +- trunk/drivers/block/umem.c | 11 +- trunk/drivers/block/xd.c | 21 +- trunk/drivers/block/z2ram.c | 2 +- trunk/drivers/cdrom/sbpcd.c | 9 +- trunk/drivers/cdrom/sonycd535.c | 3 +- trunk/drivers/char/agp/backend.c | 7 +- trunk/drivers/char/amiserial.c | 4 - trunk/drivers/char/applicom.c | 24 +- trunk/drivers/char/ftape/lowlevel/fdc-io.c | 6 +- trunk/drivers/char/hpet.c | 4 +- trunk/drivers/char/hw_random.c | 5 +- trunk/drivers/char/ip2/i2lib.c | 6 +- trunk/drivers/char/ipmi/ipmi_si_intf.c | 18 +- trunk/drivers/char/ipmi/ipmi_watchdog.c | 6 +- trunk/drivers/char/keyboard.c | 111 +- trunk/drivers/char/lcd.c | 7 +- trunk/drivers/char/lp.c | 3 +- trunk/drivers/char/mxser.c | 12 +- trunk/drivers/char/n_tty.c | 2 +- trunk/drivers/char/pcmcia/synclink_cs.c | 16 +- trunk/drivers/char/watchdog/Kconfig | 9 + trunk/drivers/char/watchdog/Makefile | 1 + trunk/drivers/char/watchdog/mpcore_wdt.c | 434 +++++ trunk/drivers/connector/Kconfig | 13 + trunk/drivers/connector/Makefile | 3 + trunk/drivers/connector/cn_queue.c | 173 ++ trunk/drivers/connector/connector.c | 486 +++++ trunk/drivers/hwmon/Kconfig | 17 + trunk/drivers/hwmon/Makefile | 1 + trunk/drivers/hwmon/hdaps.c | 739 ++++++++ trunk/drivers/hwmon/sis5595.c | 5 - trunk/drivers/hwmon/smsc47m1.c | 4 +- trunk/drivers/hwmon/via686a.c | 5 - trunk/drivers/hwmon/w83627hf.c | 14 +- trunk/drivers/i2c/busses/i2c-keywest.c | 1 - trunk/drivers/i2c/busses/i2c-nforce2.c | 5 - trunk/drivers/ide/ide-io.c | 6 +- trunk/drivers/ide/ide-iops.c | 41 +- trunk/drivers/ide/ide-tape.c | 3 +- trunk/drivers/ide/ide-timing.h | 25 +- trunk/drivers/ide/legacy/ide-cs.c | 4 +- trunk/drivers/ide/pci/cmd64x.c | 2 +- trunk/drivers/ide/pci/hpt34x.c | 2 +- trunk/drivers/ide/pci/hpt366.c | 8 +- trunk/drivers/ieee1394/sbp2.c | 8 +- trunk/drivers/infiniband/Kconfig | 25 +- trunk/drivers/infiniband/core/Makefile | 5 +- trunk/drivers/infiniband/core/cm.c | 5 +- trunk/drivers/infiniband/core/mad_rmpp.c | 4 +- trunk/drivers/infiniband/core/sa_query.c | 30 +- trunk/drivers/infiniband/core/ucm.c | 287 ++- trunk/drivers/infiniband/core/ucm.h | 11 +- trunk/drivers/infiniband/core/uverbs.h | 26 +- trunk/drivers/infiniband/core/uverbs_cmd.c | 155 +- trunk/drivers/infiniband/core/uverbs_main.c | 98 +- trunk/drivers/infiniband/hw/mthca/mthca_qp.c | 45 +- .../drivers/infiniband/ulp/ipoib/ipoib_main.c | 2 + trunk/drivers/input/evdev.c | 2 +- .../input/joystick/iforce/iforce-packets.c | 32 +- .../input/joystick/iforce/iforce-usb.c | 1 + trunk/drivers/input/keyboard/Kconfig | 11 + trunk/drivers/input/keyboard/Makefile | 1 + trunk/drivers/input/keyboard/atkbd.c | 10 +- trunk/drivers/input/keyboard/spitzkbd.c | 478 +++++ trunk/drivers/input/keyboard/sunkbd.c | 2 +- trunk/drivers/input/mouse/Makefile | 2 +- trunk/drivers/input/mouse/alps.c | 2 +- trunk/drivers/input/mouse/logips2pp.c | 13 +- trunk/drivers/input/mouse/psmouse-base.c | 132 +- trunk/drivers/input/mouse/psmouse.h | 52 +- trunk/drivers/input/mouse/trackpoint.c | 304 +++ trunk/drivers/input/mouse/trackpoint.h | 147 ++ trunk/drivers/input/serio/i8042-io.h | 6 +- trunk/drivers/input/serio/i8042-ip22io.h | 2 +- trunk/drivers/input/serio/i8042-jazzio.h | 2 +- trunk/drivers/input/serio/i8042-sparcio.h | 12 +- trunk/drivers/input/serio/i8042-x86ia64io.h | 72 +- trunk/drivers/input/serio/i8042.c | 199 +- trunk/drivers/input/touchscreen/Kconfig | 6 +- trunk/drivers/input/touchscreen/corgi_ts.c | 70 +- trunk/drivers/isdn/i4l/isdn_bsdcomp.c | 14 +- trunk/drivers/isdn/i4l/isdn_common.c | 3 +- trunk/drivers/isdn/sc/init.c | 4 +- trunk/drivers/md/dm-exception-store.c | 9 +- trunk/drivers/md/md.c | 4 +- trunk/drivers/media/common/saa7146_core.c | 6 +- trunk/drivers/media/radio/radio-aimslab.c | 2 +- trunk/drivers/media/radio/radio-aztech.c | 2 +- trunk/drivers/media/radio/radio-cadet.c | 2 +- trunk/drivers/media/radio/radio-gemtek.c | 2 +- trunk/drivers/media/radio/radio-rtrack2.c | 2 +- trunk/drivers/media/radio/radio-sf16fmi.c | 2 +- trunk/drivers/media/radio/radio-sf16fmr2.c | 2 +- trunk/drivers/media/radio/radio-terratec.c | 2 +- trunk/drivers/media/radio/radio-typhoon.c | 2 +- trunk/drivers/media/radio/radio-zoltrix.c | 2 +- trunk/drivers/media/video/cpia_usb.c | 30 +- trunk/drivers/media/video/cx88/cx88-dvb.c | 7 +- trunk/drivers/media/video/stradis.c | 32 +- trunk/drivers/media/video/video-buf.c | 8 +- trunk/drivers/media/video/zoran_driver.c | 2 +- trunk/drivers/media/video/zr36120.c | 6 +- trunk/drivers/mfd/Kconfig | 9 + trunk/drivers/mfd/Makefile | 6 + trunk/drivers/mfd/ucb1x00-assabet.c | 73 + trunk/drivers/mfd/ucb1x00-core.c | 665 +++++++ trunk/drivers/mfd/ucb1x00-ts.c | 399 ++++ trunk/drivers/mfd/ucb1x00.h | 256 +++ trunk/drivers/misc/hdpuftrs/hdpu_cpustate.c | 23 +- trunk/drivers/mmc/wbsd.c | 460 +++-- trunk/drivers/mmc/wbsd.h | 23 +- trunk/drivers/mtd/devices/mtdram.c | 3 +- trunk/drivers/mtd/ftl.c | 11 - trunk/drivers/mtd/maps/uclinux.c | 13 +- trunk/drivers/net/Kconfig | 13 +- trunk/drivers/net/arcnet/com90io.c | 4 +- trunk/drivers/net/bnx2.c | 2 + trunk/drivers/net/bsd_comp.c | 28 +- trunk/drivers/net/fec.c | 478 ++--- trunk/drivers/net/fec.h | 7 +- trunk/drivers/net/hamradio/6pack.c | 2 +- trunk/drivers/net/hamradio/baycom_epp.c | 17 +- trunk/drivers/net/hamradio/bpqether.c | 2 +- trunk/drivers/net/hamradio/dmascc.c | 10 +- trunk/drivers/net/hamradio/hdlcdrv.c | 16 +- trunk/drivers/net/hamradio/mkiss.c | 2 +- trunk/drivers/net/hamradio/scc.c | 2 +- trunk/drivers/net/hamradio/yam.c | 28 +- trunk/drivers/net/ppp_generic.c | 23 +- trunk/drivers/net/sungem.c | 36 +- trunk/drivers/net/sunhme.c | 43 +- trunk/drivers/net/tg3.c | 10 +- trunk/drivers/net/tulip/de4x5.c | 4 +- trunk/drivers/net/wireless/orinoco_cs.c | 1 + trunk/drivers/parisc/lasi.c | 1 - trunk/drivers/parport/ieee1284.c | 7 +- trunk/drivers/parport/ieee1284_ops.c | 10 +- trunk/drivers/parport/parport_pc.c | 3 +- trunk/drivers/pci/pci-sysfs.c | 10 +- trunk/drivers/pci/probe.c | 6 +- trunk/drivers/pcmcia/pcmcia_ioctl.c | 12 + trunk/drivers/sbus/char/bbc_envctrl.c | 3 +- trunk/drivers/sbus/char/bpp.c | 3 +- trunk/drivers/sbus/char/display7seg.c | 2 +- trunk/drivers/sbus/char/envctrl.c | 4 +- trunk/drivers/sbus/char/vfc_i2c.c | 3 +- trunk/drivers/scsi/3w-9xxx.c | 30 +- trunk/drivers/scsi/53c7xx.c | 4 +- trunk/drivers/scsi/Kconfig | 7 + trunk/drivers/scsi/Makefile | 1 + trunk/drivers/scsi/ch.c | 27 +- trunk/drivers/scsi/cpqfcTSinit.c | 3 +- trunk/drivers/scsi/ibmmca.c | 1 - trunk/drivers/scsi/lpfc/lpfc_attr.c | 22 +- trunk/drivers/scsi/lpfc/lpfc_hbadisc.c | 7 +- trunk/drivers/scsi/lpfc/lpfc_hw.h | 17 +- trunk/drivers/scsi/lpfc/lpfc_init.c | 7 +- trunk/drivers/scsi/osst.c | 13 +- trunk/drivers/scsi/qla2xxx/qla_attr.c | 18 +- trunk/drivers/scsi/qla2xxx/qla_init.c | 4 +- trunk/drivers/scsi/scsi_lib.c | 138 +- trunk/drivers/scsi/scsi_priv.h | 1 + trunk/drivers/scsi/scsi_scan.c | 88 +- trunk/drivers/scsi/scsi_sysfs.c | 28 +- trunk/drivers/scsi/scsi_transport_sas.c | 820 ++++++++ trunk/drivers/scsi/sg.c | 4 +- trunk/drivers/serial/8250.c | 2 +- trunk/drivers/serial/mcfserial.c | 13 +- trunk/drivers/tc/zs.c | 2 +- trunk/drivers/telephony/ixj.c | 116 +- trunk/drivers/usb/class/audio.c | 12 +- trunk/drivers/usb/core/hcd.c | 3 +- trunk/drivers/usb/core/hub.c | 11 +- trunk/drivers/usb/gadget/inode.c | 1 + trunk/drivers/usb/host/ehci-hcd.c | 28 +- trunk/drivers/usb/host/ehci-hub.c | 27 +- trunk/drivers/usb/host/ehci.h | 1 + trunk/drivers/usb/host/ohci-dbg.c | 9 +- trunk/drivers/usb/host/ohci-hcd.c | 14 +- trunk/drivers/usb/host/ohci-hub.c | 22 +- trunk/drivers/usb/host/ohci-pxa27x.c | 48 +- trunk/drivers/usb/host/ohci.h | 1 + trunk/drivers/usb/host/uhci-hcd.c | 62 +- trunk/drivers/usb/host/uhci-hcd.h | 11 +- trunk/drivers/usb/host/uhci-hub.c | 11 +- trunk/drivers/usb/host/uhci-q.c | 2 +- trunk/drivers/usb/input/Kconfig | 20 + trunk/drivers/usb/input/Makefile | 1 + trunk/drivers/usb/input/appletouch.c | 469 +++++ trunk/drivers/usb/input/hid-core.c | 76 +- trunk/drivers/usb/input/hid-debug.h | 34 +- trunk/drivers/usb/input/hid-input.c | 66 +- trunk/drivers/usb/input/hid.h | 9 +- trunk/drivers/usb/input/hiddev.c | 1 + trunk/drivers/usb/media/stv680.c | 26 +- trunk/drivers/usb/misc/sisusbvga/Kconfig | 42 +- trunk/drivers/usb/misc/sisusbvga/Makefile | 4 +- trunk/drivers/usb/misc/sisusbvga/sisusb.c | 463 ++++- trunk/drivers/usb/misc/sisusbvga/sisusb.h | 73 +- trunk/drivers/usb/misc/sisusbvga/sisusb_con.c | 1658 +++++++++++++++++ .../drivers/usb/misc/sisusbvga/sisusb_init.c | 1047 +++++++++++ .../drivers/usb/misc/sisusbvga/sisusb_init.h | 830 +++++++++ .../usb/misc/sisusbvga/sisusb_struct.h | 169 ++ trunk/drivers/usb/misc/uss720.c | 393 ++-- trunk/drivers/usb/mon/mon_text.c | 2 +- trunk/drivers/usb/serial/cp2101.c | 5 +- trunk/drivers/usb/serial/cypress_m8.c | 3 +- trunk/drivers/usb/serial/ftdi_sio.c | 2 +- trunk/drivers/usb/serial/pl2303.c | 4 +- trunk/drivers/usb/serial/pl2303.h | 4 + trunk/drivers/usb/storage/scsiglue.c | 20 +- trunk/drivers/usb/storage/unusual_devs.h | 35 + trunk/drivers/usb/storage/usb.c | 11 +- trunk/drivers/video/Kconfig | 3 +- trunk/drivers/video/backlight/corgi_bl.c | 25 +- trunk/drivers/video/console/Kconfig | 2 +- trunk/drivers/video/console/Makefile | 4 + trunk/drivers/video/console/fbcon.c | 18 +- trunk/drivers/video/console/fbcon.h | 2 +- trunk/drivers/video/console/font_10x18.c | 4 +- trunk/drivers/video/console/font_6x11.c | 4 +- trunk/drivers/video/console/font_7x14.c | 4 +- trunk/drivers/video/console/font_8x16.c | 4 +- trunk/drivers/video/console/font_8x8.c | 4 +- trunk/drivers/video/console/font_acorn_8x8.c | 4 +- trunk/drivers/video/console/font_mini_4x6.c | 4 +- trunk/drivers/video/console/font_pearl_8x8.c | 4 +- trunk/drivers/video/console/font_sun12x22.c | 4 +- trunk/drivers/video/console/font_sun8x16.c | 4 +- trunk/drivers/video/console/fonts.c | 9 +- trunk/drivers/video/i810/i810_main.c | 74 +- trunk/drivers/video/matrox/matroxfb_base.c | 13 +- trunk/drivers/video/nvidia/nv_of.c | 3 +- trunk/drivers/video/pm3fb.c | 3 +- trunk/drivers/video/vgastate.c | 15 +- trunk/drivers/w1/w1_ds2433.c | 6 +- trunk/fs/buffer.c | 1 + trunk/fs/cifs/connect.c | 6 +- trunk/fs/cramfs/uncompress.c | 1 + trunk/fs/dcache.c | 16 +- trunk/fs/jbd/transaction.c | 3 +- trunk/fs/jffs/intrep.c | 22 +- trunk/fs/jfs/acl.c | 24 +- trunk/fs/jfs/inode.c | 26 +- trunk/fs/jfs/jfs_acl.h | 12 +- trunk/fs/jfs/jfs_xattr.h | 14 +- trunk/fs/jfs/namei.c | 85 +- trunk/fs/jfs/xattr.c | 94 +- trunk/fs/lockd/clntproc.c | 3 +- trunk/fs/namespace.c | 4 +- trunk/fs/nfs/nfs3proc.c | 3 +- trunk/fs/nfs/nfs4proc.c | 12 +- trunk/fs/nfsd/nfs4proc.c | 24 +- trunk/fs/nfsd/nfs4state.c | 90 +- trunk/fs/ntfs/ChangeLog | 9 +- trunk/fs/ntfs/aops.c | 1 + trunk/fs/ntfs/malloc.h | 2 +- trunk/fs/ntfs/super.c | 14 +- trunk/fs/open.c | 98 +- trunk/fs/pipe.c | 6 +- trunk/fs/reiserfs/file.c | 11 +- trunk/fs/reiserfs/inode.c | 16 +- trunk/fs/reiserfs/journal.c | 3 +- trunk/fs/reiserfs/super.c | 3 +- trunk/fs/smbfs/proc.c | 3 +- trunk/fs/xfs/linux-2.6/time.h | 3 +- trunk/fs/xfs/linux-2.6/xfs_buf.c | 6 +- trunk/fs/xfs/linux-2.6/xfs_super.c | 12 +- trunk/include/asm-alpha/pgtable.h | 7 - trunk/include/asm-alpha/spinlock.h | 96 +- trunk/include/asm-alpha/spinlock_types.h | 20 + trunk/include/asm-arm/arch-pxa/akita.h | 30 + trunk/include/asm-arm/arch-pxa/corgi.h | 12 - trunk/include/asm-arm/arch-pxa/sharpsl.h | 32 + trunk/include/asm-arm/arch-pxa/spitz.h | 158 ++ trunk/include/asm-arm/pgtable.h | 5 +- trunk/include/asm-arm/spinlock.h | 50 +- trunk/include/asm-arm/spinlock_types.h | 20 + trunk/include/asm-arm/unistd.h | 3 + trunk/include/asm-arm26/hardirq.h | 2 - trunk/include/asm-arm26/pgtable.h | 5 +- trunk/include/asm-frv/pgtable.h | 3 - trunk/include/asm-generic/tlb.h | 6 +- trunk/include/asm-generic/vmlinux.lds.h | 38 + trunk/include/asm-h8300/pgtable.h | 2 - trunk/include/asm-i386/apic.h | 2 + trunk/include/asm-i386/div64.h | 2 +- trunk/include/asm-i386/numa.h | 3 + trunk/include/asm-i386/pgtable.h | 3 - trunk/include/asm-i386/processor.h | 4 +- trunk/include/asm-i386/spinlock.h | 200 +- trunk/include/asm-i386/spinlock_types.h | 20 + trunk/include/asm-i386/topology.h | 2 +- trunk/include/asm-i386/unistd.h | 12 +- trunk/include/asm-ia64/mca.h | 102 +- trunk/include/asm-ia64/mca_asm.h | 125 +- trunk/include/asm-ia64/pgtable.h | 4 - trunk/include/asm-ia64/ptrace.h | 2 +- trunk/include/asm-ia64/sn/sn_feature_sets.h | 57 + trunk/include/asm-ia64/sn/sn_sal.h | 36 +- trunk/include/asm-ia64/spinlock.h | 69 +- trunk/include/asm-ia64/spinlock_types.h | 21 + trunk/include/asm-ia64/thread_info.h | 2 + trunk/include/asm-ia64/unwind.h | 7 - trunk/include/asm-m32r/pgtable.h | 3 - trunk/include/asm-m32r/spinlock.h | 127 +- trunk/include/asm-m32r/spinlock_types.h | 23 + trunk/include/asm-m68k/pgtable.h | 3 - trunk/include/asm-m68knommu/bitops.h | 2 +- trunk/include/asm-m68knommu/cacheflush.h | 29 +- trunk/include/asm-m68knommu/checksum.h | 7 +- trunk/include/asm-m68knommu/m527xsim.h | 21 +- trunk/include/asm-m68knommu/m528xsim.h | 112 ++ trunk/include/asm-m68knommu/mcfcache.h | 25 +- trunk/include/asm-m68knommu/mcfdma.h | 2 +- trunk/include/asm-m68knommu/pgtable.h | 2 - trunk/include/asm-m68knommu/scatterlist.h | 6 + trunk/include/asm-m68knommu/system.h | 54 +- trunk/include/asm-mips/pgtable.h | 12 - trunk/include/asm-mips/spinlock.h | 75 +- trunk/include/asm-mips/spinlock_types.h | 20 + trunk/include/asm-parisc/atomic.h | 12 +- trunk/include/asm-parisc/bitops.h | 2 +- trunk/include/asm-parisc/cacheflush.h | 1 + trunk/include/asm-parisc/pgtable.h | 3 - trunk/include/asm-parisc/processor.h | 1 + trunk/include/asm-parisc/spinlock.h | 163 +- trunk/include/asm-parisc/spinlock_types.h | 21 + trunk/include/asm-parisc/system.h | 24 +- trunk/include/asm-powerpc/siginfo.h | 8 + trunk/include/asm-ppc/pgtable.h | 11 - trunk/include/asm-ppc/ptrace.h | 7 + trunk/include/asm-ppc/segment.h | 1 - trunk/include/asm-ppc/smp.h | 6 + trunk/include/asm-ppc/spinlock.h | 91 +- trunk/include/asm-ppc/spinlock_types.h | 20 + trunk/include/asm-ppc/system.h | 1 + trunk/include/asm-ppc64/hvcall.h | 6 + trunk/include/asm-ppc64/machdep.h | 5 +- trunk/include/asm-ppc64/pci-bridge.h | 5 + trunk/include/asm-ppc64/plpar_wrappers.h | 9 + trunk/include/asm-ppc64/processor.h | 1 + trunk/include/asm-ppc64/ptrace-common.h | 92 + trunk/include/asm-ppc64/ptrace.h | 128 +- trunk/include/asm-ppc64/spinlock.h | 191 +- trunk/include/asm-ppc64/spinlock_types.h | 20 + trunk/include/asm-ppc64/system.h | 3 + trunk/include/asm-s390/spinlock.h | 63 +- trunk/include/asm-s390/spinlock_types.h | 21 + trunk/include/asm-sh/pgtable.h | 3 - trunk/include/asm-sh/spinlock.h | 61 +- trunk/include/asm-sh/spinlock_types.h | 22 + trunk/include/asm-sh64/pgtable.h | 3 - trunk/include/asm-sparc/spinlock.h | 140 +- trunk/include/asm-sparc/spinlock_types.h | 20 + trunk/include/asm-sparc64/spinlock.h | 160 +- trunk/include/asm-sparc64/spinlock_types.h | 20 + trunk/include/asm-um/page.h | 3 +- trunk/include/asm-um/pgtable.h | 16 +- trunk/include/asm-um/spinlock_types.h | 6 + trunk/include/asm-x86_64/apic.h | 3 +- trunk/include/asm-x86_64/apicdef.h | 1 + trunk/include/asm-x86_64/bug.h | 10 +- trunk/include/asm-x86_64/calling.h | 23 +- trunk/include/asm-x86_64/desc.h | 2 +- trunk/include/asm-x86_64/dma-mapping.h | 5 + trunk/include/asm-x86_64/dwarf2.h | 8 + trunk/include/asm-x86_64/fixmap.h | 2 +- trunk/include/asm-x86_64/hardirq.h | 9 +- trunk/include/asm-x86_64/hw_irq.h | 18 +- trunk/include/asm-x86_64/io.h | 14 +- trunk/include/asm-x86_64/ipi.h | 23 +- trunk/include/asm-x86_64/kdebug.h | 4 +- trunk/include/asm-x86_64/local.h | 4 +- trunk/include/asm-x86_64/mmzone.h | 4 +- trunk/include/asm-x86_64/msr.h | 49 +- trunk/include/asm-x86_64/numa.h | 3 + trunk/include/asm-x86_64/page.h | 4 +- trunk/include/asm-x86_64/pci.h | 6 +- trunk/include/asm-x86_64/pda.h | 14 +- trunk/include/asm-x86_64/pgalloc.h | 8 +- trunk/include/asm-x86_64/pgtable.h | 9 +- trunk/include/asm-x86_64/processor.h | 12 +- trunk/include/asm-x86_64/proto.h | 6 - trunk/include/asm-x86_64/signal.h | 10 +- trunk/include/asm-x86_64/smp.h | 2 +- trunk/include/asm-x86_64/spinlock.h | 164 +- trunk/include/asm-x86_64/spinlock_types.h | 20 + trunk/include/asm-x86_64/system.h | 8 +- trunk/include/asm-x86_64/timex.h | 1 - trunk/include/asm-x86_64/tlbflush.h | 4 + trunk/include/asm-x86_64/topology.h | 3 +- trunk/include/asm-x86_64/vsyscall.h | 1 - trunk/include/asm-xtensa/pgtable.h | 6 +- trunk/include/linux/bio.h | 7 +- trunk/include/linux/bit_spinlock.h | 77 + trunk/include/linux/blkdev.h | 2 +- trunk/include/linux/chio.h | 2 +- trunk/include/linux/connector.h | 158 ++ trunk/include/linux/crc16.h | 16 +- trunk/include/linux/dmapool.h | 3 +- trunk/include/linux/dmi.h | 2 +- trunk/include/linux/fb.h | 2 +- trunk/include/linux/font.h | 10 +- trunk/include/linux/fs.h | 2 - trunk/include/linux/in6.h | 56 +- trunk/include/linux/input.h | 8 + trunk/include/linux/interrupt.h | 7 +- trunk/include/linux/ipv6.h | 2 +- trunk/include/linux/jbd.h | 1 + trunk/include/linux/jiffies.h | 40 +- trunk/include/linux/kernel.h | 4 +- trunk/include/linux/netlink.h | 1 + trunk/include/linux/nfsd/xdr4.h | 15 +- trunk/include/linux/pci_ids.h | 4 +- trunk/include/linux/pktcdvd.h | 3 + trunk/include/linux/radix-tree.h | 4 +- trunk/include/linux/reiserfs_fs.h | 6 +- trunk/include/linux/sched.h | 16 + trunk/include/linux/slab.h | 3 +- trunk/include/linux/spinlock.h | 627 ++----- trunk/include/linux/spinlock_api_smp.h | 57 + trunk/include/linux/spinlock_api_up.h | 80 + trunk/include/linux/spinlock_types.h | 67 + trunk/include/linux/spinlock_types_up.h | 51 + trunk/include/linux/spinlock_up.h | 74 + trunk/include/linux/sysctl.h | 3 +- trunk/include/linux/time.h | 9 +- trunk/include/linux/usbdevice_fs.h | 2 +- trunk/include/linux/videodev2.h | 109 +- trunk/include/linux/writeback.h | 2 - trunk/include/net/ax25.h | 31 +- trunk/include/net/netrom.h | 32 +- trunk/include/rdma/ib_cm.h | 1 + trunk/include/rdma/ib_mad.h | 21 + trunk/include/rdma/ib_sa.h | 31 +- trunk/include/rdma/ib_user_cm.h | 72 +- trunk/include/rdma/ib_user_verbs.h | 21 +- trunk/include/scsi/scsi_device.h | 4 +- trunk/include/scsi/scsi_transport_fc.h | 8 + trunk/include/scsi/scsi_transport_sas.h | 100 + trunk/include/video/pm3fb.h | 3 - trunk/include/video/w100fb.h | 1 + trunk/init/initramfs.c | 12 +- trunk/ipc/mqueue.c | 2 +- trunk/kernel/Makefile | 1 + trunk/kernel/acct.c | 43 +- trunk/kernel/compat.c | 9 +- trunk/kernel/cpuset.c | 105 +- trunk/kernel/module.c | 11 +- trunk/kernel/sched.c | 276 ++- trunk/kernel/signal.c | 3 +- trunk/kernel/softirq.c | 2 +- trunk/kernel/spinlock.c | 15 +- trunk/kernel/timer.c | 37 +- trunk/lib/Kconfig.debug | 8 +- trunk/lib/Makefile | 1 + trunk/lib/dec_and_lock.c | 3 - trunk/lib/kernel_lock.c | 3 +- trunk/lib/radix-tree.c | 2 +- trunk/lib/sort.c | 5 +- trunk/lib/spinlock_debug.c | 257 +++ trunk/mm/bootmem.c | 14 +- trunk/mm/filemap.c | 17 +- trunk/mm/memory.c | 2 +- trunk/mm/mempolicy.c | 7 +- trunk/mm/nommu.c | 17 +- trunk/mm/oom_kill.c | 3 +- trunk/mm/page_alloc.c | 5 +- trunk/mm/slab.c | 4 +- trunk/mm/swap_state.c | 4 +- trunk/mm/swapfile.c | 3 +- trunk/mm/vmscan.c | 4 +- trunk/net/ax25/af_ax25.c | 46 +- trunk/net/ax25/ax25_ip.c | 6 +- trunk/net/core/pktgen.c | 13 +- trunk/net/dccp/ccids/ccid3.c | 170 +- trunk/net/dccp/ccids/ccid3.h | 2 + trunk/net/dccp/ipv4.c | 4 - trunk/net/dccp/output.c | 3 - trunk/net/ipv4/ipconfig.c | 6 +- trunk/net/ipv4/tcp_output.c | 5 - trunk/net/ipv6/exthdrs.c | 3 +- trunk/net/ipv6/netfilter/ip6t_rt.c | 14 +- trunk/net/irda/ircomm/ircomm_tty.c | 9 +- trunk/net/netrom/af_netrom.c | 28 +- trunk/net/netrom/nr_dev.c | 54 +- trunk/net/netrom/nr_in.c | 15 + trunk/net/netrom/nr_subr.c | 7 +- trunk/net/netrom/sysctl_net_netrom.c | 12 + trunk/net/rose/af_rose.c | 8 +- trunk/net/rose/rose_dev.c | 2 +- trunk/net/sunrpc/svcsock.c | 86 +- trunk/scripts/Kbuild.include | 3 + trunk/scripts/mod/modpost.c | 6 + trunk/scripts/reference_discarded.pl | 7 +- trunk/sound/isa/sb/sb16_csp.c | 44 +- trunk/sound/oss/skeleton.c | 219 --- 764 files changed, 24501 insertions(+), 9827 deletions(-) create mode 100644 trunk/Documentation/RCU/whatisRCU.txt create mode 100644 trunk/Documentation/connector/cn_test.c create mode 100644 trunk/Documentation/connector/connector.txt create mode 100644 trunk/Documentation/input/appletouch.txt create mode 100644 trunk/Documentation/scsi/scsi_eh.txt create mode 100644 trunk/arch/arm/mach-pxa/sharpsl.h create mode 100644 trunk/arch/arm/mach-pxa/spitz.c create mode 100644 trunk/arch/m68knommu/platform/68328/head-de2.S create mode 100644 trunk/arch/m68knommu/platform/68360/head-ram.S create mode 100644 trunk/arch/m68knommu/platform/68360/head-rom.S rename trunk/arch/mips/kernel/{offset.c => asm-offsets.c} (100%) delete mode 100644 trunk/arch/parisc/lib/debuglocks.c delete mode 100644 trunk/arch/sparc/lib/debuglocks.c delete mode 100644 trunk/arch/sparc64/lib/debuglocks.c delete mode 100644 trunk/arch/x86_64/kernel/msr.c create mode 100644 trunk/drivers/char/watchdog/mpcore_wdt.c create mode 100644 trunk/drivers/connector/Kconfig create mode 100644 trunk/drivers/connector/Makefile create mode 100644 trunk/drivers/connector/cn_queue.c create mode 100644 trunk/drivers/connector/connector.c create mode 100644 trunk/drivers/hwmon/hdaps.c create mode 100644 trunk/drivers/input/keyboard/spitzkbd.c create mode 100644 trunk/drivers/input/mouse/trackpoint.c create mode 100644 trunk/drivers/input/mouse/trackpoint.h create mode 100644 trunk/drivers/mfd/ucb1x00-assabet.c create mode 100644 trunk/drivers/mfd/ucb1x00-core.c create mode 100644 trunk/drivers/mfd/ucb1x00-ts.c create mode 100644 trunk/drivers/mfd/ucb1x00.h create mode 100644 trunk/drivers/scsi/scsi_transport_sas.c create mode 100644 trunk/drivers/usb/input/appletouch.c create mode 100644 trunk/drivers/usb/misc/sisusbvga/sisusb_con.c create mode 100644 trunk/drivers/usb/misc/sisusbvga/sisusb_init.c create mode 100644 trunk/drivers/usb/misc/sisusbvga/sisusb_init.h create mode 100644 trunk/drivers/usb/misc/sisusbvga/sisusb_struct.h create mode 100644 trunk/include/asm-alpha/spinlock_types.h create mode 100644 trunk/include/asm-arm/arch-pxa/akita.h create mode 100644 trunk/include/asm-arm/arch-pxa/sharpsl.h create mode 100644 trunk/include/asm-arm/arch-pxa/spitz.h create mode 100644 trunk/include/asm-arm/spinlock_types.h create mode 100644 trunk/include/asm-i386/numa.h create mode 100644 trunk/include/asm-i386/spinlock_types.h create mode 100644 trunk/include/asm-ia64/sn/sn_feature_sets.h create mode 100644 trunk/include/asm-ia64/spinlock_types.h create mode 100644 trunk/include/asm-m32r/spinlock_types.h create mode 100644 trunk/include/asm-mips/spinlock_types.h create mode 100644 trunk/include/asm-parisc/spinlock_types.h delete mode 100644 trunk/include/asm-ppc/segment.h create mode 100644 trunk/include/asm-ppc/spinlock_types.h create mode 100644 trunk/include/asm-ppc64/spinlock_types.h create mode 100644 trunk/include/asm-s390/spinlock_types.h create mode 100644 trunk/include/asm-sh/spinlock_types.h create mode 100644 trunk/include/asm-sparc/spinlock_types.h create mode 100644 trunk/include/asm-sparc64/spinlock_types.h create mode 100644 trunk/include/asm-um/spinlock_types.h create mode 100644 trunk/include/asm-x86_64/spinlock_types.h create mode 100644 trunk/include/linux/bit_spinlock.h create mode 100644 trunk/include/linux/connector.h create mode 100644 trunk/include/linux/spinlock_api_smp.h create mode 100644 trunk/include/linux/spinlock_api_up.h create mode 100644 trunk/include/linux/spinlock_types.h create mode 100644 trunk/include/linux/spinlock_types_up.h create mode 100644 trunk/include/linux/spinlock_up.h create mode 100644 trunk/include/scsi/scsi_transport_sas.h create mode 100644 trunk/lib/spinlock_debug.c delete mode 100644 trunk/sound/oss/skeleton.c diff --git a/[refs] b/[refs] index 2392d92ff49c..84f72494844b 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: c315b7e840a1f336ffefb21d3130f9799af2ecd6 +refs/heads/master: a8cd2e5045688157479a654786b2c08ab85f4d8f diff --git a/trunk/COPYING b/trunk/COPYING index 2a7e338ec2fc..ca442d313d86 100644 --- a/trunk/COPYING +++ b/trunk/COPYING @@ -18,7 +18,7 @@ Version 2, June 1991 Copyright (C) 1989, 1991 Free Software Foundation, Inc. - 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. @@ -321,7 +321,7 @@ the "copyright" line and a pointer to where the full notice is found. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software - Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA Also add information on how to contact you by electronic and paper mail. diff --git a/trunk/Documentation/00-INDEX b/trunk/Documentation/00-INDEX index f6de52b01059..433cf5e9ae04 100644 --- a/trunk/Documentation/00-INDEX +++ b/trunk/Documentation/00-INDEX @@ -277,7 +277,7 @@ tty.txt unicode.txt - info on the Unicode character/font mapping used in Linux. uml/ - - directory with infomation about User Mode Linux. + - directory with information about User Mode Linux. usb/ - directory with info regarding the Universal Serial Bus. video4linux/ diff --git a/trunk/Documentation/CodingStyle b/trunk/Documentation/CodingStyle index f25b3953f513..22e5f9036f3c 100644 --- a/trunk/Documentation/CodingStyle +++ b/trunk/Documentation/CodingStyle @@ -236,6 +236,9 @@ ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does it. +When commenting the kernel API functions, please use the kerneldoc format. +See the files Documentation/kernel-doc-nano-HOWTO.txt and scripts/kernel-doc +for details. Chapter 8: You've made a mess of it diff --git a/trunk/Documentation/DMA-API.txt b/trunk/Documentation/DMA-API.txt index 6ee3cd6134df..1af0f2d50220 100644 --- a/trunk/Documentation/DMA-API.txt +++ b/trunk/Documentation/DMA-API.txt @@ -121,7 +121,7 @@ pool's device. dma_addr_t addr); This puts memory back into the pool. The pool is what was passed to -the the pool allocation routine; the cpu and dma addresses are what +the pool allocation routine; the cpu and dma addresses are what were returned when that routine allocated the memory being freed. diff --git a/trunk/Documentation/DocBook/journal-api.tmpl b/trunk/Documentation/DocBook/journal-api.tmpl index 1ef6f43c6d8f..341aaa4ce481 100644 --- a/trunk/Documentation/DocBook/journal-api.tmpl +++ b/trunk/Documentation/DocBook/journal-api.tmpl @@ -116,7 +116,7 @@ filesystem. Almost. You still need to actually journal your filesystem changes, this is done by wrapping them into transactions. Additionally you -also need to wrap the modification of each of the the buffers +also need to wrap the modification of each of the buffers with calls to the journal layer, so it knows what the modifications you are actually making are. To do this use journal_start() which returns a transaction handle. @@ -128,7 +128,7 @@ and its counterpart journal_stop(), which indicates the end of a transaction are nestable calls, so you can reenter a transaction if necessary, but remember you must call journal_stop() the same number of times as journal_start() before the transaction is completed (or more accurately -leaves the the update phase). Ext3/VFS makes use of this feature to simplify +leaves the update phase). Ext3/VFS makes use of this feature to simplify quota support. diff --git a/trunk/Documentation/DocBook/usb.tmpl b/trunk/Documentation/DocBook/usb.tmpl index f3ef0bf435e9..705c442c7bf4 100644 --- a/trunk/Documentation/DocBook/usb.tmpl +++ b/trunk/Documentation/DocBook/usb.tmpl @@ -841,7 +841,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) File modification time is not updated by this request. Those struct members are from some interface descriptor - applying to the the current configuration. + applying to the current configuration. The interface number is the bInterfaceNumber value, and the altsetting number is the bAlternateSetting value. (This resets each endpoint in the interface.) diff --git a/trunk/Documentation/MSI-HOWTO.txt b/trunk/Documentation/MSI-HOWTO.txt index d5032eb480aa..63edc5f847c4 100644 --- a/trunk/Documentation/MSI-HOWTO.txt +++ b/trunk/Documentation/MSI-HOWTO.txt @@ -430,7 +430,7 @@ which may result in system hang. The software driver of specific MSI-capable hardware is responsible for whether calling pci_enable_msi or not. A return of zero indicates the kernel successfully initializes the MSI/MSI-X capability structure of the -device funtion. The device function is now running on MSI/MSI-X mode. +device function. The device function is now running on MSI/MSI-X mode. 5.6 How to tell whether MSI/MSI-X is enabled on device function diff --git a/trunk/Documentation/RCU/RTFP.txt b/trunk/Documentation/RCU/RTFP.txt index 9c6d450138ea..fcbcbc35b122 100644 --- a/trunk/Documentation/RCU/RTFP.txt +++ b/trunk/Documentation/RCU/RTFP.txt @@ -2,7 +2,8 @@ Read the F-ing Papers! This document describes RCU-related publications, and is followed by -the corresponding bibtex entries. +the corresponding bibtex entries. A number of the publications may +be found at http://www.rdrop.com/users/paulmck/RCU/. The first thing resembling RCU was published in 1980, when Kung and Lehman [Kung80] recommended use of a garbage collector to defer destruction @@ -113,6 +114,10 @@ describing how to make RCU safe for soft-realtime applications [Sarma04c], and a paper describing SELinux performance with RCU [JamesMorris04b]. +2005 has seen further adaptation of RCU to realtime use, permitting +preemption of RCU realtime critical sections [PaulMcKenney05a, +PaulMcKenney05b]. + Bibtex Entries @article{Kung80 @@ -410,3 +415,32 @@ Oregon Health and Sciences University" \url{http://www.livejournal.com/users/james_morris/2153.html} [Viewed December 10, 2004]" } + +@unpublished{PaulMcKenney05a +,Author="Paul E. McKenney" +,Title="{[RFC]} {RCU} and {CONFIG\_PREEMPT\_RT} progress" +,month="May" +,year="2005" +,note="Available: +\url{http://lkml.org/lkml/2005/5/9/185} +[Viewed May 13, 2005]" +,annotation=" + First publication of working lock-based deferred free patches + for the CONFIG_PREEMPT_RT environment. +" +} + +@conference{PaulMcKenney05b +,Author="Paul E. McKenney and Dipankar Sarma" +,Title="Towards Hard Realtime Response from the Linux Kernel on SMP Hardware" +,Booktitle="linux.conf.au 2005" +,month="April" +,year="2005" +,address="Canberra, Australia" +,note="Available: +\url{http://www.rdrop.com/users/paulmck/RCU/realtimeRCU.2005.04.23a.pdf} +[Viewed May 13, 2005]" +,annotation=" + Realtime turns into making RCU yet more realtime friendly. +" +} diff --git a/trunk/Documentation/RCU/UP.txt b/trunk/Documentation/RCU/UP.txt index 3bfb84b3b7db..aab4a9ec3931 100644 --- a/trunk/Documentation/RCU/UP.txt +++ b/trunk/Documentation/RCU/UP.txt @@ -8,7 +8,7 @@ is that since there is only one CPU, it should not be necessary to wait for anything else to get done, since there are no other CPUs for anything else to be happening on. Although this approach will -sort- -of- work a surprising amount of the time, it is a very bad idea in general. -This document presents two examples that demonstrate exactly how bad an +This document presents three examples that demonstrate exactly how bad an idea this is. @@ -26,6 +26,9 @@ from softirq, the list scan would find itself referencing a newly freed element B. This situation can greatly decrease the life expectancy of your kernel. +This same problem can occur if call_rcu() is invoked from a hardware +interrupt handler. + Example 2: Function-Call Fatality @@ -44,8 +47,37 @@ its arguments would cause it to fail to make the fundamental guarantee underlying RCU, namely that call_rcu() defers invoking its arguments until all RCU read-side critical sections currently executing have completed. -Quick Quiz: why is it -not- legal to invoke synchronize_rcu() in -this case? +Quick Quiz #1: why is it -not- legal to invoke synchronize_rcu() in + this case? + + +Example 3: Death by Deadlock + +Suppose that call_rcu() is invoked while holding a lock, and that the +callback function must acquire this same lock. In this case, if +call_rcu() were to directly invoke the callback, the result would +be self-deadlock. + +In some cases, it would possible to restructure to code so that +the call_rcu() is delayed until after the lock is released. However, +there are cases where this can be quite ugly: + +1. If a number of items need to be passed to call_rcu() within + the same critical section, then the code would need to create + a list of them, then traverse the list once the lock was + released. + +2. In some cases, the lock will be held across some kernel API, + so that delaying the call_rcu() until the lock is released + requires that the data item be passed up via a common API. + It is far better to guarantee that callbacks are invoked + with no locks held than to have to modify such APIs to allow + arbitrary data items to be passed back up through them. + +If call_rcu() directly invokes the callback, painful locking restrictions +or API changes would be required. + +Quick Quiz #2: What locking restriction must RCU callbacks respect? Summary @@ -53,12 +85,35 @@ Summary Permitting call_rcu() to immediately invoke its arguments or permitting synchronize_rcu() to immediately return breaks RCU, even on a UP system. So do not do it! Even on a UP system, the RCU infrastructure -must- -respect grace periods. - - -Answer to Quick Quiz - -The calling function is scanning an RCU-protected linked list, and -is therefore within an RCU read-side critical section. Therefore, -the called function has been invoked within an RCU read-side critical -section, and is not permitted to block. +respect grace periods, and -must- invoke callbacks from a known environment +in which no locks are held. + + +Answer to Quick Quiz #1: + Why is it -not- legal to invoke synchronize_rcu() in this case? + + Because the calling function is scanning an RCU-protected linked + list, and is therefore within an RCU read-side critical section. + Therefore, the called function has been invoked within an RCU + read-side critical section, and is not permitted to block. + +Answer to Quick Quiz #2: + What locking restriction must RCU callbacks respect? + + Any lock that is acquired within an RCU callback must be + acquired elsewhere using an _irq variant of the spinlock + primitive. For example, if "mylock" is acquired by an + RCU callback, then a process-context acquisition of this + lock must use something like spin_lock_irqsave() to + acquire the lock. + + If the process-context code were to simply use spin_lock(), + then, since RCU callbacks can be invoked from softirq context, + the callback might be called from a softirq that interrupted + the process-context critical section. This would result in + self-deadlock. + + This restriction might seem gratuitous, since very few RCU + callbacks acquire locks directly. However, a great many RCU + callbacks do acquire locks -indirectly-, for example, via + the kfree() primitive. diff --git a/trunk/Documentation/RCU/checklist.txt b/trunk/Documentation/RCU/checklist.txt index 8f3fb77c9cd3..e118a7c1a092 100644 --- a/trunk/Documentation/RCU/checklist.txt +++ b/trunk/Documentation/RCU/checklist.txt @@ -43,6 +43,10 @@ over a rather long period of time, but improvements are always welcome! rcu_read_lock_bh()) in the read-side critical sections, and are also an excellent aid to readability. + As a rough rule of thumb, any dereference of an RCU-protected + pointer must be covered by rcu_read_lock() or rcu_read_lock_bh() + or by the appropriate update-side lock. + 3. Does the update code tolerate concurrent accesses? The whole point of RCU is to permit readers to run without @@ -90,7 +94,11 @@ over a rather long period of time, but improvements are always welcome! The rcu_dereference() primitive is used by the various "_rcu()" list-traversal primitives, such as the - list_for_each_entry_rcu(). + list_for_each_entry_rcu(). Note that it is perfectly + legal (if redundant) for update-side code to use + rcu_dereference() and the "_rcu()" list-traversal + primitives. This is particularly useful in code + that is common to readers and updaters. b. If the list macros are being used, the list_add_tail_rcu() and list_add_rcu() primitives must be used in order @@ -150,16 +158,9 @@ over a rather long period of time, but improvements are always welcome! Use of the _rcu() list-traversal primitives outside of an RCU read-side critical section causes no harm other than - a slight performance degradation on Alpha CPUs and some - confusion on the part of people trying to read the code. - - Another way of thinking of this is "If you are holding the - lock that prevents the data structure from changing, why do - you also need RCU-based protection?" That said, there may - well be situations where use of the _rcu() list-traversal - primitives while the update-side lock is held results in - simpler and more maintainable code. The jury is still out - on this question. + a slight performance degradation on Alpha CPUs. It can + also be quite helpful in reducing code bloat when common + code is shared between readers and updaters. 10. Conversely, if you are in an RCU read-side critical section, you -must- use the "_rcu()" variants of the list macros. diff --git a/trunk/Documentation/RCU/rcu.txt b/trunk/Documentation/RCU/rcu.txt index eb444006683e..6fa092251586 100644 --- a/trunk/Documentation/RCU/rcu.txt +++ b/trunk/Documentation/RCU/rcu.txt @@ -64,6 +64,54 @@ o I hear that RCU is patented? What is with that? Of these, one was allowed to lapse by the assignee, and the others have been contributed to the Linux kernel under GPL. +o I hear that RCU needs work in order to support realtime kernels? + + Yes, work in progress. + o Where can I find more information on RCU? See the RTFP.txt file in this directory. + Or point your browser at http://www.rdrop.com/users/paulmck/RCU/. + +o What are all these files in this directory? + + + NMI-RCU.txt + + Describes how to use RCU to implement dynamic + NMI handlers, which can be revectored on the fly, + without rebooting. + + RTFP.txt + + List of RCU-related publications and web sites. + + UP.txt + + Discussion of RCU usage in UP kernels. + + arrayRCU.txt + + Describes how to use RCU to protect arrays, with + resizeable arrays whose elements reference other + data structures being of the most interest. + + checklist.txt + + Lists things to check for when inspecting code that + uses RCU. + + listRCU.txt + + Describes how to use RCU to protect linked lists. + This is the simplest and most common use of RCU + in the Linux kernel. + + rcu.txt + + You are reading it! + + whatisRCU.txt + + Overview of how the RCU implementation works. Along + the way, presents a conceptual view of RCU. diff --git a/trunk/Documentation/RCU/whatisRCU.txt b/trunk/Documentation/RCU/whatisRCU.txt new file mode 100644 index 000000000000..354d89c78377 --- /dev/null +++ b/trunk/Documentation/RCU/whatisRCU.txt @@ -0,0 +1,902 @@ +What is RCU? + +RCU is a synchronization mechanism that was added to the Linux kernel +during the 2.5 development effort that is optimized for read-mostly +situations. Although RCU is actually quite simple once you understand it, +getting there can sometimes be a challenge. Part of the problem is that +most of the past descriptions of RCU have been written with the mistaken +assumption that there is "one true way" to describe RCU. Instead, +the experience has been that different people must take different paths +to arrive at an understanding of RCU. This document provides several +different paths, as follows: + +1. RCU OVERVIEW +2. WHAT IS RCU'S CORE API? +3. WHAT ARE SOME EXAMPLE USES OF CORE RCU API? +4. WHAT IF MY UPDATING THREAD CANNOT BLOCK? +5. WHAT ARE SOME SIMPLE IMPLEMENTATIONS OF RCU? +6. ANALOGY WITH READER-WRITER LOCKING +7. FULL LIST OF RCU APIs +8. ANSWERS TO QUICK QUIZZES + +People who prefer starting with a conceptual overview should focus on +Section 1, though most readers will profit by reading this section at +some point. People who prefer to start with an API that they can then +experiment with should focus on Section 2. People who prefer to start +with example uses should focus on Sections 3 and 4. People who need to +understand the RCU implementation should focus on Section 5, then dive +into the kernel source code. People who reason best by analogy should +focus on Section 6. Section 7 serves as an index to the docbook API +documentation, and Section 8 is the traditional answer key. + +So, start with the section that makes the most sense to you and your +preferred method of learning. If you need to know everything about +everything, feel free to read the whole thing -- but if you are really +that type of person, you have perused the source code and will therefore +never need this document anyway. ;-) + + +1. RCU OVERVIEW + +The basic idea behind RCU is to split updates into "removal" and +"reclamation" phases. The removal phase removes references to data items +within a data structure (possibly by replacing them with references to +new versions of these data items), and can run concurrently with readers. +The reason that it is safe to run the removal phase concurrently with +readers is the semantics of modern CPUs guarantee that readers will see +either the old or the new version of the data structure rather than a +partially updated reference. The reclamation phase does the work of reclaiming +(e.g., freeing) the data items removed from the data structure during the +removal phase. Because reclaiming data items can disrupt any readers +concurrently referencing those data items, the reclamation phase must +not start until readers no longer hold references to those data items. + +Splitting the update into removal and reclamation phases permits the +updater to perform the removal phase immediately, and to defer the +reclamation phase until all readers active during the removal phase have +completed, either by blocking until they finish or by registering a +callback that is invoked after they finish. Only readers that are active +during the removal phase need be considered, because any reader starting +after the removal phase will be unable to gain a reference to the removed +data items, and therefore cannot be disrupted by the reclamation phase. + +So the typical RCU update sequence goes something like the following: + +a. Remove pointers to a data structure, so that subsequent + readers cannot gain a reference to it. + +b. Wait for all previous readers to complete their RCU read-side + critical sections. + +c. At this point, there cannot be any readers who hold references + to the data structure, so it now may safely be reclaimed + (e.g., kfree()d). + +Step (b) above is the key idea underlying RCU's deferred destruction. +The ability to wait until all readers are done allows RCU readers to +use much lighter-weight synchronization, in some cases, absolutely no +synchronization at all. In contrast, in more conventional lock-based +schemes, readers must use heavy-weight synchronization in order to +prevent an updater from deleting the data structure out from under them. +This is because lock-based updaters typically update data items in place, +and must therefore exclude readers. In contrast, RCU-based updaters +typically take advantage of the fact that writes to single aligned +pointers are atomic on modern CPUs, allowing atomic insertion, removal, +and replacement of data items in a linked structure without disrupting +readers. Concurrent RCU readers can then continue accessing the old +versions, and can dispense with the atomic operations, memory barriers, +and communications cache misses that are so expensive on present-day +SMP computer systems, even in absence of lock contention. + +In the three-step procedure shown above, the updater is performing both +the removal and the reclamation step, but it is often helpful for an +entirely different thread to do the reclamation, as is in fact the case +in the Linux kernel's directory-entry cache (dcache). Even if the same +thread performs both the update step (step (a) above) and the reclamation +step (step (c) above), it is often helpful to think of them separately. +For example, RCU readers and updaters need not communicate at all, +but RCU provides implicit low-overhead communication between readers +and reclaimers, namely, in step (b) above. + +So how the heck can a reclaimer tell when a reader is done, given +that readers are not doing any sort of synchronization operations??? +Read on to learn about how RCU's API makes this easy. + + +2. WHAT IS RCU'S CORE API? + +The core RCU API is quite small: + +a. rcu_read_lock() +b. rcu_read_unlock() +c. synchronize_rcu() / call_rcu() +d. rcu_assign_pointer() +e. rcu_dereference() + +There are many other members of the RCU API, but the rest can be +expressed in terms of these five, though most implementations instead +express synchronize_rcu() in terms of the call_rcu() callback API. + +The five core RCU APIs are described below, the other 18 will be enumerated +later. See the kernel docbook documentation for more info, or look directly +at the function header comments. + +rcu_read_lock() + + void rcu_read_lock(void); + + Used by a reader to inform the reclaimer that the reader is + entering an RCU read-side critical section. It is illegal + to block while in an RCU read-side critical section, though + kernels built with CONFIG_PREEMPT_RCU can preempt RCU read-side + critical sections. Any RCU-protected data structure accessed + during an RCU read-side critical section is guaranteed to remain + unreclaimed for the full duration of that critical section. + Reference counts may be used in conjunction with RCU to maintain + longer-term references to data structures. + +rcu_read_unlock() + + void rcu_read_unlock(void); + + Used by a reader to inform the reclaimer that the reader is + exiting an RCU read-side critical section. Note that RCU + read-side critical sections may be nested and/or overlapping. + +synchronize_rcu() + + void synchronize_rcu(void); + + Marks the end of updater code and the beginning of reclaimer + code. It does this by blocking until all pre-existing RCU + read-side critical sections on all CPUs have completed. + Note that synchronize_rcu() will -not- necessarily wait for + any subsequent RCU read-side critical sections to complete. + For example, consider the following sequence of events: + + CPU 0 CPU 1 CPU 2 + ----------------- ------------------------- --------------- + 1. rcu_read_lock() + 2. enters synchronize_rcu() + 3. rcu_read_lock() + 4. rcu_read_unlock() + 5. exits synchronize_rcu() + 6. rcu_read_unlock() + + To reiterate, synchronize_rcu() waits only for ongoing RCU + read-side critical sections to complete, not necessarily for + any that begin after synchronize_rcu() is invoked. + + Of course, synchronize_rcu() does not necessarily return + -immediately- after the last pre-existing RCU read-side critical + section completes. For one thing, there might well be scheduling + delays. For another thing, many RCU implementations process + requests in batches in order to improve efficiencies, which can + further delay synchronize_rcu(). + + Since synchronize_rcu() is the API that must figure out when + readers are done, its implementation is key to RCU. For RCU + to be useful in all but the most read-intensive situations, + synchronize_rcu()'s overhead must also be quite small. + + The call_rcu() API is a callback form of synchronize_rcu(), + and is described in more detail in a later section. Instead of + blocking, it registers a function and argument which are invoked + after all ongoing RCU read-side critical sections have completed. + This callback variant is particularly useful in situations where + it is illegal to block. + +rcu_assign_pointer() + + typeof(p) rcu_assign_pointer(p, typeof(p) v); + + Yes, rcu_assign_pointer() -is- implemented as a macro, though it + would be cool to be able to declare a function in this manner. + (Compiler experts will no doubt disagree.) + + The updater uses this function to assign a new value to an + RCU-protected pointer, in order to safely communicate the change + in value from the updater to the reader. This function returns + the new value, and also executes any memory-barrier instructions + required for a given CPU architecture. + + Perhaps more important, it serves to document which pointers + are protected by RCU. That said, rcu_assign_pointer() is most + frequently used indirectly, via the _rcu list-manipulation + primitives such as list_add_rcu(). + +rcu_dereference() + + typeof(p) rcu_dereference(p); + + Like rcu_assign_pointer(), rcu_dereference() must be implemented + as a macro. + + The reader uses rcu_dereference() to fetch an RCU-protected + pointer, which returns a value that may then be safely + dereferenced. Note that rcu_deference() does not actually + dereference the pointer, instead, it protects the pointer for + later dereferencing. It also executes any needed memory-barrier + instructions for a given CPU architecture. Currently, only Alpha + needs memory barriers within rcu_dereference() -- on other CPUs, + it compiles to nothing, not even a compiler directive. + + Common coding practice uses rcu_dereference() to copy an + RCU-protected pointer to a local variable, then dereferences + this local variable, for example as follows: + + p = rcu_dereference(head.next); + return p->data; + + However, in this case, one could just as easily combine these + into one statement: + + return rcu_dereference(head.next)->data; + + If you are going to be fetching multiple fields from the + RCU-protected structure, using the local variable is of + course preferred. Repeated rcu_dereference() calls look + ugly and incur unnecessary overhead on Alpha CPUs. + + Note that the value returned by rcu_dereference() is valid + only within the enclosing RCU read-side critical section. + For example, the following is -not- legal: + + rcu_read_lock(); + p = rcu_dereference(head.next); + rcu_read_unlock(); + x = p->address; + rcu_read_lock(); + y = p->data; + rcu_read_unlock(); + + Holding a reference from one RCU read-side critical section + to another is just as illegal as holding a reference from + one lock-based critical section to another! Similarly, + using a reference outside of the critical section in which + it was acquired is just as illegal as doing so with normal + locking. + + As with rcu_assign_pointer(), an important function of + rcu_dereference() is to document which pointers are protected + by RCU. And, again like rcu_assign_pointer(), rcu_dereference() + is typically used indirectly, via the _rcu list-manipulation + primitives, such as list_for_each_entry_rcu(). + +The following diagram shows how each API communicates among the +reader, updater, and reclaimer. + + + rcu_assign_pointer() + +--------+ + +---------------------->| reader |---------+ + | +--------+ | + | | | + | | | Protect: + | | | rcu_read_lock() + | | | rcu_read_unlock() + | rcu_dereference() | | + +---------+ | | + | updater |<---------------------+ | + +---------+ V + | +-----------+ + +----------------------------------->| reclaimer | + +-----------+ + Defer: + synchronize_rcu() & call_rcu() + + +The RCU infrastructure observes the time sequence of rcu_read_lock(), +rcu_read_unlock(), synchronize_rcu(), and call_rcu() invocations in +order to determine when (1) synchronize_rcu() invocations may return +to their callers and (2) call_rcu() callbacks may be invoked. Efficient +implementations of the RCU infrastructure make heavy use of batching in +order to amortize their overhead over many uses of the corresponding APIs. + +There are no fewer than three RCU mechanisms in the Linux kernel; the +diagram above shows the first one, which is by far the most commonly used. +The rcu_dereference() and rcu_assign_pointer() primitives are used for +all three mechanisms, but different defer and protect primitives are +used as follows: + + Defer Protect + +a. synchronize_rcu() rcu_read_lock() / rcu_read_unlock() + call_rcu() + +b. call_rcu_bh() rcu_read_lock_bh() / rcu_read_unlock_bh() + +c. synchronize_sched() preempt_disable() / preempt_enable() + local_irq_save() / local_irq_restore() + hardirq enter / hardirq exit + NMI enter / NMI exit + +These three mechanisms are used as follows: + +a. RCU applied to normal data structures. + +b. RCU applied to networking data structures that may be subjected + to remote denial-of-service attacks. + +c. RCU applied to scheduler and interrupt/NMI-handler tasks. + +Again, most uses will be of (a). The (b) and (c) cases are important +for specialized uses, but are relatively uncommon. + + +3. WHAT ARE SOME EXAMPLE USES OF CORE RCU API? + +This section shows a simple use of the core RCU API to protect a +global pointer to a dynamically allocated structure. More typical +uses of RCU may be found in listRCU.txt, arrayRCU.txt, and NMI-RCU.txt. + + struct foo { + int a; + char b; + long c; + }; + DEFINE_SPINLOCK(foo_mutex); + + struct foo *gbl_foo; + + /* + * Create a new struct foo that is the same as the one currently + * pointed to by gbl_foo, except that field "a" is replaced + * with "new_a". Points gbl_foo to the new structure, and + * frees up the old structure after a grace period. + * + * Uses rcu_assign_pointer() to ensure that concurrent readers + * see the initialized version of the new structure. + * + * Uses synchronize_rcu() to ensure that any readers that might + * have references to the old structure complete before freeing + * the old structure. + */ + void foo_update_a(int new_a) + { + struct foo *new_fp; + struct foo *old_fp; + + new_fp = kmalloc(sizeof(*fp), GFP_KERNEL); + spin_lock(&foo_mutex); + old_fp = gbl_foo; + *new_fp = *old_fp; + new_fp->a = new_a; + rcu_assign_pointer(gbl_foo, new_fp); + spin_unlock(&foo_mutex); + synchronize_rcu(); + kfree(old_fp); + } + + /* + * Return the value of field "a" of the current gbl_foo + * structure. Use rcu_read_lock() and rcu_read_unlock() + * to ensure that the structure does not get deleted out + * from under us, and use rcu_dereference() to ensure that + * we see the initialized version of the structure (important + * for DEC Alpha and for people reading the code). + */ + int foo_get_a(void) + { + int retval; + + rcu_read_lock(); + retval = rcu_dereference(gbl_foo)->a; + rcu_read_unlock(); + return retval; + } + +So, to sum up: + +o Use rcu_read_lock() and rcu_read_unlock() to guard RCU + read-side critical sections. + +o Within an RCU read-side critical section, use rcu_dereference() + to dereference RCU-protected pointers. + +o Use some solid scheme (such as locks or semaphores) to + keep concurrent updates from interfering with each other. + +o Use rcu_assign_pointer() to update an RCU-protected pointer. + This primitive protects concurrent readers from the updater, + -not- concurrent updates from each other! You therefore still + need to use locking (or something similar) to keep concurrent + rcu_assign_pointer() primitives from interfering with each other. + +o Use synchronize_rcu() -after- removing a data element from an + RCU-protected data structure, but -before- reclaiming/freeing + the data element, in order to wait for the completion of all + RCU read-side critical sections that might be referencing that + data item. + +See checklist.txt for additional rules to follow when using RCU. + + +4. WHAT IF MY UPDATING THREAD CANNOT BLOCK? + +In the example above, foo_update_a() blocks until a grace period elapses. +This is quite simple, but in some cases one cannot afford to wait so +long -- there might be other high-priority work to be done. + +In such cases, one uses call_rcu() rather than synchronize_rcu(). +The call_rcu() API is as follows: + + void call_rcu(struct rcu_head * head, + void (*func)(struct rcu_head *head)); + +This function invokes func(head) after a grace period has elapsed. +This invocation might happen from either softirq or process context, +so the function is not permitted to block. The foo struct needs to +have an rcu_head structure added, perhaps as follows: + + struct foo { + int a; + char b; + long c; + struct rcu_head rcu; + }; + +The foo_update_a() function might then be written as follows: + + /* + * Create a new struct foo that is the same as the one currently + * pointed to by gbl_foo, except that field "a" is replaced + * with "new_a". Points gbl_foo to the new structure, and + * frees up the old structure after a grace period. + * + * Uses rcu_assign_pointer() to ensure that concurrent readers + * see the initialized version of the new structure. + * + * Uses call_rcu() to ensure that any readers that might have + * references to the old structure complete before freeing the + * old structure. + */ + void foo_update_a(int new_a) + { + struct foo *new_fp; + struct foo *old_fp; + + new_fp = kmalloc(sizeof(*fp), GFP_KERNEL); + spin_lock(&foo_mutex); + old_fp = gbl_foo; + *new_fp = *old_fp; + new_fp->a = new_a; + rcu_assign_pointer(gbl_foo, new_fp); + spin_unlock(&foo_mutex); + call_rcu(&old_fp->rcu, foo_reclaim); + } + +The foo_reclaim() function might appear as follows: + + void foo_reclaim(struct rcu_head *rp) + { + struct foo *fp = container_of(rp, struct foo, rcu); + + kfree(fp); + } + +The container_of() primitive is a macro that, given a pointer into a +struct, the type of the struct, and the pointed-to field within the +struct, returns a pointer to the beginning of the struct. + +The use of call_rcu() permits the caller of foo_update_a() to +immediately regain control, without needing to worry further about the +old version of the newly updated element. It also clearly shows the +RCU distinction between updater, namely foo_update_a(), and reclaimer, +namely foo_reclaim(). + +The summary of advice is the same as for the previous section, except +that we are now using call_rcu() rather than synchronize_rcu(): + +o Use call_rcu() -after- removing a data element from an + RCU-protected data structure in order to register a callback + function that will be invoked after the completion of all RCU + read-side critical sections that might be referencing that + data item. + +Again, see checklist.txt for additional rules governing the use of RCU. + + +5. WHAT ARE SOME SIMPLE IMPLEMENTATIONS OF RCU? + +One of the nice things about RCU is that it has extremely simple "toy" +implementations that are a good first step towards understanding the +production-quality implementations in the Linux kernel. This section +presents two such "toy" implementations of RCU, one that is implemented +in terms of familiar locking primitives, and another that more closely +resembles "classic" RCU. Both are way too simple for real-world use, +lacking both functionality and performance. However, they are useful +in getting a feel for how RCU works. See kernel/rcupdate.c for a +production-quality implementation, and see: + + http://www.rdrop.com/users/paulmck/RCU + +for papers describing the Linux kernel RCU implementation. The OLS'01 +and OLS'02 papers are a good introduction, and the dissertation provides +more details on the current implementation. + + +5A. "TOY" IMPLEMENTATION #1: LOCKING + +This section presents a "toy" RCU implementation that is based on +familiar locking primitives. Its overhead makes it a non-starter for +real-life use, as does its lack of scalability. It is also unsuitable +for realtime use, since it allows scheduling latency to "bleed" from +one read-side critical section to another. + +However, it is probably the easiest implementation to relate to, so is +a good starting point. + +It is extremely simple: + + static DEFINE_RWLOCK(rcu_gp_mutex); + + void rcu_read_lock(void) + { + read_lock(&rcu_gp_mutex); + } + + void rcu_read_unlock(void) + { + read_unlock(&rcu_gp_mutex); + } + + void synchronize_rcu(void) + { + write_lock(&rcu_gp_mutex); + write_unlock(&rcu_gp_mutex); + } + +[You can ignore rcu_assign_pointer() and rcu_dereference() without +missing much. But here they are anyway. And whatever you do, don't +forget about them when submitting patches making use of RCU!] + + #define rcu_assign_pointer(p, v) ({ \ + smp_wmb(); \ + (p) = (v); \ + }) + + #define rcu_dereference(p) ({ \ + typeof(p) _________p1 = p; \ + smp_read_barrier_depends(); \ + (_________p1); \ + }) + + +The rcu_read_lock() and rcu_read_unlock() primitive read-acquire +and release a global reader-writer lock. The synchronize_rcu() +primitive write-acquires this same lock, then immediately releases +it. This means that once synchronize_rcu() exits, all RCU read-side +critical sections that were in progress before synchonize_rcu() was +called are guaranteed to have completed -- there is no way that +synchronize_rcu() would have been able to write-acquire the lock +otherwise. + +It is possible to nest rcu_read_lock(), since reader-writer locks may +be recursively acquired. Note also that rcu_read_lock() is immune +from deadlock (an important property of RCU). The reason for this is +that the only thing that can block rcu_read_lock() is a synchronize_rcu(). +But synchronize_rcu() does not acquire any locks while holding rcu_gp_mutex, +so there can be no deadlock cycle. + +Quick Quiz #1: Why is this argument naive? How could a deadlock + occur when using this algorithm in a real-world Linux + kernel? How could this deadlock be avoided? + + +5B. "TOY" EXAMPLE #2: CLASSIC RCU + +This section presents a "toy" RCU implementation that is based on +"classic RCU". It is also short on performance (but only for updates) and +on features such as hotplug CPU and the ability to run in CONFIG_PREEMPT +kernels. The definitions of rcu_dereference() and rcu_assign_pointer() +are the same as those shown in the preceding section, so they are omitted. + + void rcu_read_lock(void) { } + + void rcu_read_unlock(void) { } + + void synchronize_rcu(void) + { + int cpu; + + for_each_cpu(cpu) + run_on(cpu); + } + +Note that rcu_read_lock() and rcu_read_unlock() do absolutely nothing. +This is the great strength of classic RCU in a non-preemptive kernel: +read-side overhead is precisely zero, at least on non-Alpha CPUs. +And there is absolutely no way that rcu_read_lock() can possibly +participate in a deadlock cycle! + +The implementation of synchronize_rcu() simply schedules itself on each +CPU in turn. The run_on() primitive can be implemented straightforwardly +in terms of the sched_setaffinity() primitive. Of course, a somewhat less +"toy" implementation would restore the affinity upon completion rather +than just leaving all tasks running on the last CPU, but when I said +"toy", I meant -toy-! + +So how the heck is this supposed to work??? + +Remember that it is illegal to block while in an RCU read-side critical +section. Therefore, if a given CPU executes a context switch, we know +that it must have completed all preceding RCU read-side critical sections. +Once -all- CPUs have executed a context switch, then -all- preceding +RCU read-side critical sections will have completed. + +So, suppose that we remove a data item from its structure and then invoke +synchronize_rcu(). Once synchronize_rcu() returns, we are guaranteed +that there are no RCU read-side critical sections holding a reference +to that data item, so we can safely reclaim it. + +Quick Quiz #2: Give an example where Classic RCU's read-side + overhead is -negative-. + +Quick Quiz #3: If it is illegal to block in an RCU read-side + critical section, what the heck do you do in + PREEMPT_RT, where normal spinlocks can block??? + + +6. ANALOGY WITH READER-WRITER LOCKING + +Although RCU can be used in many different ways, a very common use of +RCU is analogous to reader-writer locking. The following unified +diff shows how closely related RCU and reader-writer locking can be. + + @@ -13,15 +14,15 @@ + struct list_head *lp; + struct el *p; + + - read_lock(); + - list_for_each_entry(p, head, lp) { + + rcu_read_lock(); + + list_for_each_entry_rcu(p, head, lp) { + if (p->key == key) { + *result = p->data; + - read_unlock(); + + rcu_read_unlock(); + return 1; + } + } + - read_unlock(); + + rcu_read_unlock(); + return 0; + } + + @@ -29,15 +30,16 @@ + { + struct el *p; + + - write_lock(&listmutex); + + spin_lock(&listmutex); + list_for_each_entry(p, head, lp) { + if (p->key == key) { + list_del(&p->list); + - write_unlock(&listmutex); + + spin_unlock(&listmutex); + + synchronize_rcu(); + kfree(p); + return 1; + } + } + - write_unlock(&listmutex); + + spin_unlock(&listmutex); + return 0; + } + +Or, for those who prefer a side-by-side listing: + + 1 struct el { 1 struct el { + 2 struct list_head list; 2 struct list_head list; + 3 long key; 3 long key; + 4 spinlock_t mutex; 4 spinlock_t mutex; + 5 int data; 5 int data; + 6 /* Other data fields */ 6 /* Other data fields */ + 7 }; 7 }; + 8 spinlock_t listmutex; 8 spinlock_t listmutex; + 9 struct el head; 9 struct el head; + + 1 int search(long key, int *result) 1 int search(long key, int *result) + 2 { 2 { + 3 struct list_head *lp; 3 struct list_head *lp; + 4 struct el *p; 4 struct el *p; + 5 5 + 6 read_lock(); 6 rcu_read_lock(); + 7 list_for_each_entry(p, head, lp) { 7 list_for_each_entry_rcu(p, head, lp) { + 8 if (p->key == key) { 8 if (p->key == key) { + 9 *result = p->data; 9 *result = p->data; +10 read_unlock(); 10 rcu_read_unlock(); +11 return 1; 11 return 1; +12 } 12 } +13 } 13 } +14 read_unlock(); 14 rcu_read_unlock(); +15 return 0; 15 return 0; +16 } 16 } + + 1 int delete(long key) 1 int delete(long key) + 2 { 2 { + 3 struct el *p; 3 struct el *p; + 4 4 + 5 write_lock(&listmutex); 5 spin_lock(&listmutex); + 6 list_for_each_entry(p, head, lp) { 6 list_for_each_entry(p, head, lp) { + 7 if (p->key == key) { 7 if (p->key == key) { + 8 list_del(&p->list); 8 list_del(&p->list); + 9 write_unlock(&listmutex); 9 spin_unlock(&listmutex); + 10 synchronize_rcu(); +10 kfree(p); 11 kfree(p); +11 return 1; 12 return 1; +12 } 13 } +13 } 14 } +14 write_unlock(&listmutex); 15 spin_unlock(&listmutex); +15 return 0; 16 return 0; +16 } 17 } + +Either way, the differences are quite small. Read-side locking moves +to rcu_read_lock() and rcu_read_unlock, update-side locking moves from +from a reader-writer lock to a simple spinlock, and a synchronize_rcu() +precedes the kfree(). + +However, there is one potential catch: the read-side and update-side +critical sections can now run concurrently. In many cases, this will +not be a problem, but it is necessary to check carefully regardless. +For example, if multiple independent list updates must be seen as +a single atomic update, converting to RCU will require special care. + +Also, the presence of synchronize_rcu() means that the RCU version of +delete() can now block. If this is a problem, there is a callback-based +mechanism that never blocks, namely call_rcu(), that can be used in +place of synchronize_rcu(). + + +7. FULL LIST OF RCU APIs + +The RCU APIs are documented in docbook-format header comments in the +Linux-kernel source code, but it helps to have a full list of the +APIs, since there does not appear to be a way to categorize them +in docbook. Here is the list, by category. + +Markers for RCU read-side critical sections: + + rcu_read_lock + rcu_read_unlock + rcu_read_lock_bh + rcu_read_unlock_bh + +RCU pointer/list traversal: + + rcu_dereference + list_for_each_rcu (to be deprecated in favor of + list_for_each_entry_rcu) + list_for_each_safe_rcu (deprecated, not used) + list_for_each_entry_rcu + list_for_each_continue_rcu (to be deprecated in favor of new + list_for_each_entry_continue_rcu) + hlist_for_each_rcu (to be deprecated in favor of + hlist_for_each_entry_rcu) + hlist_for_each_entry_rcu + +RCU pointer update: + + rcu_assign_pointer + list_add_rcu + list_add_tail_rcu + list_del_rcu + list_replace_rcu + hlist_del_rcu + hlist_add_head_rcu + +RCU grace period: + + synchronize_kernel (deprecated) + synchronize_net + synchronize_sched + synchronize_rcu + call_rcu + call_rcu_bh + +See the comment headers in the source code (or the docbook generated +from them) for more information. + + +8. ANSWERS TO QUICK QUIZZES + +Quick Quiz #1: Why is this argument naive? How could a deadlock + occur when using this algorithm in a real-world Linux + kernel? [Referring to the lock-based "toy" RCU + algorithm.] + +Answer: Consider the following sequence of events: + + 1. CPU 0 acquires some unrelated lock, call it + "problematic_lock". + + 2. CPU 1 enters synchronize_rcu(), write-acquiring + rcu_gp_mutex. + + 3. CPU 0 enters rcu_read_lock(), but must wait + because CPU 1 holds rcu_gp_mutex. + + 4. CPU 1 is interrupted, and the irq handler + attempts to acquire problematic_lock. + + The system is now deadlocked. + + One way to avoid this deadlock is to use an approach like + that of CONFIG_PREEMPT_RT, where all normal spinlocks + become blocking locks, and all irq handlers execute in + the context of special tasks. In this case, in step 4 + above, the irq handler would block, allowing CPU 1 to + release rcu_gp_mutex, avoiding the deadlock. + + Even in the absence of deadlock, this RCU implementation + allows latency to "bleed" from readers to other + readers through synchronize_rcu(). To see this, + consider task A in an RCU read-side critical section + (thus read-holding rcu_gp_mutex), task B blocked + attempting to write-acquire rcu_gp_mutex, and + task C blocked in rcu_read_lock() attempting to + read_acquire rcu_gp_mutex. Task A's RCU read-side + latency is holding up task C, albeit indirectly via + task B. + + Realtime RCU implementations therefore use a counter-based + approach where tasks in RCU read-side critical sections + cannot be blocked by tasks executing synchronize_rcu(). + +Quick Quiz #2: Give an example where Classic RCU's read-side + overhead is -negative-. + +Answer: Imagine a single-CPU system with a non-CONFIG_PREEMPT + kernel where a routing table is used by process-context + code, but can be updated by irq-context code (for example, + by an "ICMP REDIRECT" packet). The usual way of handling + this would be to have the process-context code disable + interrupts while searching the routing table. Use of + RCU allows such interrupt-disabling to be dispensed with. + Thus, without RCU, you pay the cost of disabling interrupts, + and with RCU you don't. + + One can argue that the overhead of RCU in this + case is negative with respect to the single-CPU + interrupt-disabling approach. Others might argue that + the overhead of RCU is merely zero, and that replacing + the positive overhead of the interrupt-disabling scheme + with the zero-overhead RCU scheme does not constitute + negative overhead. + + In real life, of course, things are more complex. But + even the theoretical possibility of negative overhead for + a synchronization primitive is a bit unexpected. ;-) + +Quick Quiz #3: If it is illegal to block in an RCU read-side + critical section, what the heck do you do in + PREEMPT_RT, where normal spinlocks can block??? + +Answer: Just as PREEMPT_RT permits preemption of spinlock + critical sections, it permits preemption of RCU + read-side critical sections. It also permits + spinlocks blocking while in RCU read-side critical + sections. + + Why the apparent inconsistency? Because it is it + possible to use priority boosting to keep the RCU + grace periods short if need be (for example, if running + short of memory). In contrast, if blocking waiting + for (say) network reception, there is no way to know + what should be boosted. Especially given that the + process we need to boost might well be a human being + who just went out for a pizza or something. And although + a computer-operated cattle prod might arouse serious + interest, it might also provoke serious objections. + Besides, how does the computer know what pizza parlor + the human being went to??? + + +ACKNOWLEDGEMENTS + +My thanks to the people who helped make this human-readable, including +Jon Walpole, Josh Triplett, Serge Hallyn, and Suzanne Wood. + + +For more information, see http://www.rdrop.com/users/paulmck/RCU. diff --git a/trunk/Documentation/aoe/mkshelf.sh b/trunk/Documentation/aoe/mkshelf.sh index 8bacf9f2c7cc..32615814271c 100644 --- a/trunk/Documentation/aoe/mkshelf.sh +++ b/trunk/Documentation/aoe/mkshelf.sh @@ -8,13 +8,15 @@ fi n_partitions=${n_partitions:-16} dir=$1 shelf=$2 +nslots=16 +maxslot=`echo $nslots 1 - p | dc` MAJOR=152 set -e -minor=`echo 10 \* $shelf \* $n_partitions | bc` +minor=`echo $nslots \* $shelf \* $n_partitions | bc` endp=`echo $n_partitions - 1 | bc` -for slot in `seq 0 9`; do +for slot in `seq 0 $maxslot`; do for part in `seq 0 $endp`; do name=e$shelf.$slot test "$part" != "0" && name=${name}p$part diff --git a/trunk/Documentation/cciss.txt b/trunk/Documentation/cciss.txt index c8f9a73111da..68a711fb82cf 100644 --- a/trunk/Documentation/cciss.txt +++ b/trunk/Documentation/cciss.txt @@ -17,7 +17,9 @@ This driver is known to work with the following cards: * SA P600 * SA P800 * SA E400 - * SA E300 + * SA P400i + * SA E200 + * SA E200i If nodes are not already created in the /dev/cciss directory, run as root: diff --git a/trunk/Documentation/connector/cn_test.c b/trunk/Documentation/connector/cn_test.c new file mode 100644 index 000000000000..b7de82e9c0e0 --- /dev/null +++ b/trunk/Documentation/connector/cn_test.c @@ -0,0 +1,194 @@ +/* + * cn_test.c + * + * 2004-2005 Copyright (c) Evgeniy Polyakov + * All rights reserved. + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA + */ + +#include +#include +#include +#include +#include + +#include "connector.h" + +static struct cb_id cn_test_id = { 0x123, 0x456 }; +static char cn_test_name[] = "cn_test"; +static struct sock *nls; +static struct timer_list cn_test_timer; + +void cn_test_callback(void *data) +{ + struct cn_msg *msg = (struct cn_msg *)data; + + printk("%s: %lu: idx=%x, val=%x, seq=%u, ack=%u, len=%d: %s.\n", + __func__, jiffies, msg->id.idx, msg->id.val, + msg->seq, msg->ack, msg->len, (char *)msg->data); +} + +static int cn_test_want_notify(void) +{ + struct cn_ctl_msg *ctl; + struct cn_notify_req *req; + struct cn_msg *msg = NULL; + int size, size0; + struct sk_buff *skb; + struct nlmsghdr *nlh; + u32 group = 1; + + size0 = sizeof(*msg) + sizeof(*ctl) + 3 * sizeof(*req); + + size = NLMSG_SPACE(size0); + + skb = alloc_skb(size, GFP_ATOMIC); + if (!skb) { + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n", + size); + + return -ENOMEM; + } + + nlh = NLMSG_PUT(skb, 0, 0x123, NLMSG_DONE, size - sizeof(*nlh)); + + msg = (struct cn_msg *)NLMSG_DATA(nlh); + + memset(msg, 0, size0); + + msg->id.idx = -1; + msg->id.val = -1; + msg->seq = 0x123; + msg->ack = 0x345; + msg->len = size0 - sizeof(*msg); + + ctl = (struct cn_ctl_msg *)(msg + 1); + + ctl->idx_notify_num = 1; + ctl->val_notify_num = 2; + ctl->group = group; + ctl->len = msg->len - sizeof(*ctl); + + req = (struct cn_notify_req *)(ctl + 1); + + /* + * Idx. + */ + req->first = cn_test_id.idx; + req->range = 10; + + /* + * Val 0. + */ + req++; + req->first = cn_test_id.val; + req->range = 10; + + /* + * Val 1. + */ + req++; + req->first = cn_test_id.val + 20; + req->range = 10; + + NETLINK_CB(skb).dst_groups = ctl->group; + //netlink_broadcast(nls, skb, 0, ctl->group, GFP_ATOMIC); + netlink_unicast(nls, skb, 0, 0); + + printk(KERN_INFO "Request was sent. Group=0x%x.\n", ctl->group); + + return 0; + +nlmsg_failure: + printk(KERN_ERR "Failed to send %u.%u\n", msg->seq, msg->ack); + kfree_skb(skb); + return -EINVAL; +} + +static u32 cn_test_timer_counter; +static void cn_test_timer_func(unsigned long __data) +{ + struct cn_msg *m; + char data[32]; + + m = kmalloc(sizeof(*m) + sizeof(data), GFP_ATOMIC); + if (m) { + memset(m, 0, sizeof(*m) + sizeof(data)); + + memcpy(&m->id, &cn_test_id, sizeof(m->id)); + m->seq = cn_test_timer_counter; + m->len = sizeof(data); + + m->len = + scnprintf(data, sizeof(data), "counter = %u", + cn_test_timer_counter) + 1; + + memcpy(m + 1, data, m->len); + + cn_netlink_send(m, 0, gfp_any()); + kfree(m); + } + + cn_test_timer_counter++; + + mod_timer(&cn_test_timer, jiffies + HZ); +} + +static int cn_test_init(void) +{ + int err; + + err = cn_add_callback(&cn_test_id, cn_test_name, cn_test_callback); + if (err) + goto err_out; + cn_test_id.val++; + err = cn_add_callback(&cn_test_id, cn_test_name, cn_test_callback); + if (err) { + cn_del_callback(&cn_test_id); + goto err_out; + } + + init_timer(&cn_test_timer); + cn_test_timer.function = cn_test_timer_func; + cn_test_timer.expires = jiffies + HZ; + cn_test_timer.data = 0; + add_timer(&cn_test_timer); + + return 0; + + err_out: + if (nls && nls->sk_socket) + sock_release(nls->sk_socket); + + return err; +} + +static void cn_test_fini(void) +{ + del_timer_sync(&cn_test_timer); + cn_del_callback(&cn_test_id); + cn_test_id.val--; + cn_del_callback(&cn_test_id); + if (nls && nls->sk_socket) + sock_release(nls->sk_socket); +} + +module_init(cn_test_init); +module_exit(cn_test_fini); + +MODULE_LICENSE("GPL"); +MODULE_AUTHOR("Evgeniy Polyakov "); +MODULE_DESCRIPTION("Connector's test module"); diff --git a/trunk/Documentation/connector/connector.txt b/trunk/Documentation/connector/connector.txt new file mode 100644 index 000000000000..54a0a14bfbe3 --- /dev/null +++ b/trunk/Documentation/connector/connector.txt @@ -0,0 +1,133 @@ +/*****************************************/ +Kernel Connector. +/*****************************************/ + +Kernel connector - new netlink based userspace <-> kernel space easy +to use communication module. + +Connector driver adds possibility to connect various agents using +netlink based network. One must register callback and +identifier. When driver receives special netlink message with +appropriate identifier, appropriate callback will be called. + +From the userspace point of view it's quite straightforward: + + socket(); + bind(); + send(); + recv(); + +But if kernelspace want to use full power of such connections, driver +writer must create special sockets, must know about struct sk_buff +handling... Connector allows any kernelspace agents to use netlink +based networking for inter-process communication in a significantly +easier way: + +int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); +void cn_netlink_send(struct cn_msg *msg, u32 __group, int gfp_mask); + +struct cb_id +{ + __u32 idx; + __u32 val; +}; + +idx and val are unique identifiers which must be registered in +connector.h for in-kernel usage. void (*callback) (void *) - is a +callback function which will be called when message with above idx.val +will be received by connector core. Argument for that function must +be dereferenced to struct cn_msg *. + +struct cn_msg +{ + struct cb_id id; + + __u32 seq; + __u32 ack; + + __u32 len; /* Length of the following data */ + __u8 data[0]; +}; + +/*****************************************/ +Connector interfaces. +/*****************************************/ + +int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *)); + +Registers new callback with connector core. + +struct cb_id *id - unique connector's user identifier. + It must be registered in connector.h for legal in-kernel users. +char *name - connector's callback symbolic name. +void (*callback) (void *) - connector's callback. + Argument must be dereferenced to struct cn_msg *. + +void cn_del_callback(struct cb_id *id); + +Unregisters new callback with connector core. + +struct cb_id *id - unique connector's user identifier. + +void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask); + +Sends message to the specified groups. It can be safely called from +any context, but may silently fail under strong memory pressure. + +struct cn_msg * - message header(with attached data). +u32 __group - destination group. + If __group is zero, then appropriate group will + be searched through all registered connector users, + and message will be delivered to the group which was + created for user with the same ID as in msg. + If __group is not zero, then message will be delivered + to the specified group. +int gfp_mask - GFP mask. + +Note: When registering new callback user, connector core assigns +netlink group to the user which is equal to it's id.idx. + +/*****************************************/ +Protocol description. +/*****************************************/ + +Current offers transport layer with fixed header. Recommended +protocol which uses such header is following: + +msg->seq and msg->ack are used to determine message genealogy. When +someone sends message it puts there locally unique sequence and random +acknowledge numbers. Sequence number may be copied into +nlmsghdr->nlmsg_seq too. + +Sequence number is incremented with each message to be sent. + +If we expect reply to our message, then sequence number in received +message MUST be the same as in original message, and acknowledge +number MUST be the same + 1. + +If we receive message and it's sequence number is not equal to one we +are expecting, then it is new message. If we receive message and it's +sequence number is the same as one we are expecting, but it's +acknowledge is not equal acknowledge number in original message + 1, +then it is new message. + +Obviously, protocol header contains above id. + +connector allows event notification in the following form: kernel +driver or userspace process can ask connector to notify it when +selected id's will be turned on or off(registered or unregistered it's +callback). It is done by sending special command to connector +driver(it also registers itself with id={-1, -1}). + +As example of usage Documentation/connector now contains cn_test.c - +testing module which uses connector to request notification and to +send messages. + +/*****************************************/ +Reliability. +/*****************************************/ + +Netlink itself is not reliable protocol, that means that messages can +be lost due to memory pressure or process' receiving queue overflowed, +so caller is warned must be prepared. That is why struct cn_msg [main +connector's message header] contains u32 seq and u32 ack fields. diff --git a/trunk/Documentation/cpu-freq/cpufreq-stats.txt b/trunk/Documentation/cpu-freq/cpufreq-stats.txt index e2d1e760b4ba..6a82948ff4bd 100644 --- a/trunk/Documentation/cpu-freq/cpufreq-stats.txt +++ b/trunk/Documentation/cpu-freq/cpufreq-stats.txt @@ -36,7 +36,7 @@ cpufreq stats provides following statistics (explained in detail below). All the statistics will be from the time the stats driver has been inserted to the time when a read of a particular statistic is done. Obviously, stats -driver will not have any information about the the frequcny transitions before +driver will not have any information about the frequency transitions before the stats driver insertion. -------------------------------------------------------------------------------- diff --git a/trunk/Documentation/cpusets.txt b/trunk/Documentation/cpusets.txt index 47f4114fbf54..d17b7d2dd771 100644 --- a/trunk/Documentation/cpusets.txt +++ b/trunk/Documentation/cpusets.txt @@ -277,7 +277,7 @@ rewritten to the 'tasks' file of its cpuset. This is done to avoid impacting the scheduler code in the kernel with a check for changes in a tasks processor placement. -There is an exception to the above. If hotplug funtionality is used +There is an exception to the above. If hotplug functionality is used to remove all the CPUs that are currently assigned to a cpuset, then the kernel will automatically update the cpus_allowed of all tasks attached to CPUs in that cpuset to allow all CPUs. When memory diff --git a/trunk/Documentation/crypto/descore-readme.txt b/trunk/Documentation/crypto/descore-readme.txt index 166474c2ee0b..16e9e6350755 100644 --- a/trunk/Documentation/crypto/descore-readme.txt +++ b/trunk/Documentation/crypto/descore-readme.txt @@ -1,4 +1,4 @@ -Below is the orginal README file from the descore.shar package. +Below is the original README file from the descore.shar package. ------------------------------------------------------------------------------ des - fast & portable DES encryption & decryption. diff --git a/trunk/Documentation/dontdiff b/trunk/Documentation/dontdiff index 96bea278bbf6..24adfe9af3ca 100644 --- a/trunk/Documentation/dontdiff +++ b/trunk/Documentation/dontdiff @@ -55,6 +55,7 @@ aic7*seq.h* aicasm aicdb.h* asm +asm-offsets.* asm_offsets.* autoconf.h* bbootsect diff --git a/trunk/Documentation/fb/intel810.txt b/trunk/Documentation/fb/intel810.txt index fd68b162e4a1..4f0d6bc789ef 100644 --- a/trunk/Documentation/fb/intel810.txt +++ b/trunk/Documentation/fb/intel810.txt @@ -5,6 +5,7 @@ Intel 810/815 Framebuffer driver March 17, 2002 First Released: July 2001 + Last Update: September 12, 2005 ================================================================ A. Introduction @@ -44,6 +45,8 @@ B. Features - Hardware Cursor Support + - Supports EDID probing either by DDC/I2C or through the BIOS + C. List of available options a. "video=i810fb" @@ -52,14 +55,17 @@ C. List of available options Recommendation: required b. "xres:" - select horizontal resolution in pixels + select horizontal resolution in pixels. (This parameter will be + ignored if 'mode_option' is specified. See 'o' below). Recommendation: user preference (default = 640) c. "yres:" select vertical resolution in scanlines. If Discrete Video Timings - is enabled, this will be ignored and computed as 3*xres/4. + is enabled, this will be ignored and computed as 3*xres/4. (This + parameter will be ignored if 'mode_option' is specified. See 'o' + below) Recommendation: user preference (default = 480) @@ -86,7 +92,8 @@ C. List of available options g. "hsync1/hsync2:" select the minimum and maximum Horizontal Sync Frequency of the monitor in KHz. If a using a fixed frequency monitor, hsync1 must - be equal to hsync2. + be equal to hsync2. If EDID probing is successful, these will be + ignored and values will be taken from the EDID block. Recommendation: check monitor manual for correct values default (29/30) @@ -94,7 +101,8 @@ C. List of available options h. "vsync1/vsync2:" select the minimum and maximum Vertical Sync Frequency of the monitor in Hz. You can also use this option to lock your monitor's refresh - rate. + rate. If EDID probing is successful, these will be ignored and values + will be taken from the EDID block. Recommendation: check monitor manual for correct values (default = 60/60) @@ -154,7 +162,11 @@ C. List of available options Recommendation: do not set (default = not set) - + o. x[-][@] + The driver will now accept specification of boot mode option. If this + is specified, the options 'xres' and 'yres' will be ignored. See + Documentation/fb/modedb.txt for usage. + D. Kernel booting Separate each option/option-pair by commas (,) and the option from its value @@ -176,7 +188,10 @@ will be computed based on the hsync1/hsync2 and vsync1/vsync2 values. IMPORTANT: You must include hsync1, hsync2, vsync1 and vsync2 to enable video modes -better than 640x480 at 60Hz. +better than 640x480 at 60Hz. HOWEVER, if your chipset/display combination +supports I2C and has an EDID block, you can safely exclude hsync1, hsync2, +vsync1 and vsync2 parameters. These parameters will be taken from the EDID +block. E. Module options @@ -217,32 +232,21 @@ F. Setup This is required. The option is under "Character Devices" d. Under "Graphics Support", select "Intel 810/815" either statically - or as a module. Choose "use VESA GTF for video timings" if you - need to maximize the capability of your display. To be on the + or as a module. Choose "use VESA Generalized Timing Formula" if + you need to maximize the capability of your display. To be on the safe side, you can leave this unselected. - e. If you want a framebuffer console, enable it under "Console + e. If you want support for DDC/I2C probing (Plug and Play Displays), + set 'Enable DDC Support' to 'y'. To make this option appear, set + 'use VESA Generalized Timing Formula' to 'y'. + + f. If you want a framebuffer console, enable it under "Console Drivers" - f. Compile your kernel. + g. Compile your kernel. - g. Load the driver as described in section D and E. + h. Load the driver as described in section D and E. - Optional: - h. If you are going to run XFree86 with its native drivers, the - standard XFree86 4.1.0 and 4.2.0 drivers should work as is. - However, there's a bug in the XFree86 i810 drivers. It attempts - to use XAA even when switched to the console. This will crash - your server. I have a fix at this site: - - http://i810fb.sourceforge.net. - - You can either use the patch, or just replace - - /usr/X11R6/lib/modules/drivers/i810_drv.o - - with the one provided at the website. - i. Try the DirectFB (http://www.directfb.org) + the i810 gfxdriver patch to see the chipset in action (or inaction :-). diff --git a/trunk/Documentation/feature-removal-schedule.txt b/trunk/Documentation/feature-removal-schedule.txt index 5f95d4b3cab1..b67189a8d8d4 100644 --- a/trunk/Documentation/feature-removal-schedule.txt +++ b/trunk/Documentation/feature-removal-schedule.txt @@ -17,23 +17,6 @@ Who: Greg Kroah-Hartman --------------------------- -What: ACPI S4bios support -When: May 2005 -Why: Noone uses it, and it probably does not work, anyway. swsusp is - faster, more reliable, and people are actually using it. -Who: Pavel Machek - ---------------------------- - -What: io_remap_page_range() (macro or function) -When: September 2005 -Why: Replaced by io_remap_pfn_range() which allows more memory space - addressabilty (by using a pfn) and supports sparc & sparc64 - iospace as part of the pfn. -Who: Randy Dunlap - ---------------------------- - What: RAW driver (CONFIG_RAW_DRIVER) When: December 2005 Why: declared obsolete since kernel 2.6.3 diff --git a/trunk/Documentation/firmware_class/firmware_sample_driver.c b/trunk/Documentation/firmware_class/firmware_sample_driver.c index e1c56a7e6583..4bef8c25172c 100644 --- a/trunk/Documentation/firmware_class/firmware_sample_driver.c +++ b/trunk/Documentation/firmware_class/firmware_sample_driver.c @@ -32,14 +32,14 @@ static void sample_firmware_load(char *firmware, int size) u8 buf[size+1]; memcpy(buf, firmware, size); buf[size] = '\0'; - printk("firmware_sample_driver: firmware: %s\n", buf); + printk(KERN_INFO "firmware_sample_driver: firmware: %s\n", buf); } static void sample_probe_default(void) { /* uses the default method to get the firmware */ const struct firmware *fw_entry; - printk("firmware_sample_driver: a ghost device got inserted :)\n"); + printk(KERN_INFO "firmware_sample_driver: a ghost device got inserted :)\n"); if(request_firmware(&fw_entry, "sample_driver_fw", &ghost_device)!=0) { @@ -61,7 +61,7 @@ static void sample_probe_specific(void) /* NOTE: This currently doesn't work */ - printk("firmware_sample_driver: a ghost device got inserted :)\n"); + printk(KERN_INFO "firmware_sample_driver: a ghost device got inserted :)\n"); if(request_firmware(NULL, "sample_driver_fw", &ghost_device)!=0) { @@ -83,7 +83,7 @@ static void sample_probe_async_cont(const struct firmware *fw, void *context) return; } - printk("firmware_sample_driver: device pointer \"%s\"\n", + printk(KERN_INFO "firmware_sample_driver: device pointer \"%s\"\n", (char *)context); sample_firmware_load(fw->data, fw->size); } diff --git a/trunk/Documentation/input/appletouch.txt b/trunk/Documentation/input/appletouch.txt new file mode 100644 index 000000000000..b48d11d0326d --- /dev/null +++ b/trunk/Documentation/input/appletouch.txt @@ -0,0 +1,84 @@ +Apple Touchpad Driver (appletouch) +---------------------------------- + Copyright (C) 2005 Stelian Pop + +appletouch is a Linux kernel driver for the USB touchpad found on post +February 2005 Apple Alu Powerbooks. + +This driver is derived from Johannes Berg's appletrackpad driver[1], but it has +been improved in some areas: + * appletouch is a full kernel driver, no userspace program is necessary + * appletouch can be interfaced with the synaptics X11 driver, in order + to have touchpad acceleration, scrolling, etc. + +Credits go to Johannes Berg for reverse-engineering the touchpad protocol, +Frank Arnold for further improvements, and Alex Harper for some additional +information about the inner workings of the touchpad sensors. + +Usage: +------ + +In order to use the touchpad in the basic mode, compile the driver and load +the module. A new input device will be detected and you will be able to read +the mouse data from /dev/input/mice (using gpm, or X11). + +In X11, you can configure the touchpad to use the synaptics X11 driver, which +will give additional functionalities, like acceleration, scrolling, 2 finger +tap for middle button mouse emulation, 3 finger tap for right button mouse +emulation, etc. In order to do this, make sure you're using a recent version of +the synaptics driver (tested with 0.14.2, available from [2]), and configure a +new input device in your X11 configuration file (take a look below for an +example). For additional configuration, see the synaptics driver documentation. + + Section "InputDevice" + Identifier "Synaptics Touchpad" + Driver "synaptics" + Option "SendCoreEvents" "true" + Option "Device" "/dev/input/mice" + Option "Protocol" "auto-dev" + Option "LeftEdge" "0" + Option "RightEdge" "850" + Option "TopEdge" "0" + Option "BottomEdge" "645" + Option "MinSpeed" "0.4" + Option "MaxSpeed" "1" + Option "AccelFactor" "0.02" + Option "FingerLow" "0" + Option "FingerHigh" "30" + Option "MaxTapMove" "20" + Option "MaxTapTime" "100" + Option "HorizScrollDelta" "0" + Option "VertScrollDelta" "30" + Option "SHMConfig" "on" + EndSection + + Section "ServerLayout" + ... + InputDevice "Mouse" + InputDevice "Synaptics Touchpad" + ... + EndSection + +Fuzz problems: +-------------- + +The touchpad sensors are very sensitive to heat, and will generate a lot of +noise when the temperature changes. This is especially true when you power-on +the laptop for the first time. + +The appletouch driver tries to handle this noise and auto adapt itself, but it +is not perfect. If finger movements are not recognized anymore, try reloading +the driver. + +You can activate debugging using the 'debug' module parameter. A value of 0 +deactivates any debugging, 1 activates tracing of invalid samples, 2 activates +full tracing (each sample is being traced): + modprobe appletouch debug=1 + or + echo "1" > /sys/module/appletouch/parameters/debug + +Links: +------ + +[1]: http://johannes.sipsolutions.net/PowerBook/touchpad/ +[2]: http://web.telia.com/~u89404340/touchpad/index.html diff --git a/trunk/Documentation/ioctl/cdrom.txt b/trunk/Documentation/ioctl/cdrom.txt index 4ccdcc6fe364..8ec32cc49eb1 100644 --- a/trunk/Documentation/ioctl/cdrom.txt +++ b/trunk/Documentation/ioctl/cdrom.txt @@ -878,7 +878,7 @@ DVD_READ_STRUCT Read structure error returns: EINVAL physical.layer_num exceeds number of layers - EIO Recieved invalid response from drive + EIO Received invalid response from drive diff --git a/trunk/Documentation/kbuild/makefiles.txt b/trunk/Documentation/kbuild/makefiles.txt index 9a1586590d82..d802ce88bedc 100644 --- a/trunk/Documentation/kbuild/makefiles.txt +++ b/trunk/Documentation/kbuild/makefiles.txt @@ -31,7 +31,7 @@ This document describes the Linux kernel Makefiles. === 6 Architecture Makefiles --- 6.1 Set variables to tweak the build to the architecture - --- 6.2 Add prerequisites to prepare: + --- 6.2 Add prerequisites to archprepare: --- 6.3 List directories to visit when descending --- 6.4 Architecture specific boot images --- 6.5 Building non-kbuild targets @@ -734,18 +734,18 @@ When kbuild executes the following steps are followed (roughly): for loadable kernel modules. ---- 6.2 Add prerequisites to prepare: +--- 6.2 Add prerequisites to archprepare: - The prepare: rule is used to list prerequisites that needs to be + The archprepare: rule is used to list prerequisites that needs to be built before starting to descend down in the subdirectories. This is usual header files containing assembler constants. Example: - #arch/s390/Makefile - prepare: include/asm-$(ARCH)/offsets.h + #arch/arm/Makefile + archprepare: maketools - In this example the file include/asm-$(ARCH)/offsets.h will - be built before descending down in the subdirectories. + In this example the file target maketools will be processed + before descending down in the subdirectories. See also chapter XXX-TODO that describe how kbuild supports generating offset header files. diff --git a/trunk/Documentation/kdump/kdump.txt b/trunk/Documentation/kdump/kdump.txt index 1f5f7d28c9e6..5f08f9ce6046 100644 --- a/trunk/Documentation/kdump/kdump.txt +++ b/trunk/Documentation/kdump/kdump.txt @@ -66,11 +66,11 @@ SETUP c) Enable "/proc/vmcore support" (Optional, in Pseudo filesystems). CONFIG_PROC_VMCORE=y d) Disable SMP support and build a UP kernel (Until it is fixed). - CONFIG_SMP=n + CONFIG_SMP=n e) Enable "Local APIC support on uniprocessors". - CONFIG_X86_UP_APIC=y + CONFIG_X86_UP_APIC=y f) Enable "IO-APIC support on uniprocessors" - CONFIG_X86_UP_IOAPIC=y + CONFIG_X86_UP_IOAPIC=y Note: i) Options a) and b) depend upon "Configure standard kernel features (for small systems)" (under General setup). @@ -95,6 +95,11 @@ SETUP hence have memory less than 4GB. iii) Specify "irqpoll" as command line parameter. This reduces driver initialization failures in second kernel due to shared interrupts. + iv) needs to be specified in a format corresponding to + the root device name in the output of mount command. + v) If you have built the drivers required to mount root file + system as modules in , then, specify + --initrd=. 5) System reboots into the second kernel when a panic occurs. A module can be written to force the panic or "ALT-SysRq-c" can be used initiate a crash diff --git a/trunk/Documentation/kernel-parameters.txt b/trunk/Documentation/kernel-parameters.txt index d2f0c67ba1fb..7086f0a90d14 100644 --- a/trunk/Documentation/kernel-parameters.txt +++ b/trunk/Documentation/kernel-parameters.txt @@ -164,6 +164,15 @@ running once the system is up. over-ride platform specific driver. See also Documentation/acpi-hotkey.txt. + enable_timer_pin_1 [i386,x86-64] + Enable PIN 1 of APIC timer + Can be useful to work around chipset bugs (in particular on some ATI chipsets) + The kernel tries to set a reasonable default. + + disable_timer_pin_1 [i386,x86-64] + Disable PIN 1 of APIC timer + Can be useful to work around chipset bugs. + ad1816= [HW,OSS] Format: ,,, See also Documentation/sound/oss/AD1816. @@ -549,6 +558,7 @@ running once the system is up. keyboard and can not control its state (Don't attempt to blink the leds) i8042.noaux [HW] Don't check for auxiliary (== mouse) port + i8042.nokbd [HW] Don't check/create keyboard port i8042.nomux [HW] Don't check presence of an active multiplexing controller i8042.nopnp [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX diff --git a/trunk/Documentation/mono.txt b/trunk/Documentation/mono.txt index 6739ab9615ef..807a0c7b4737 100644 --- a/trunk/Documentation/mono.txt +++ b/trunk/Documentation/mono.txt @@ -30,7 +30,7 @@ other program after you have done the following: Read the file 'binfmt_misc.txt' in this directory to know more about the configuration process. -3) Add the following enries to /etc/rc.local or similar script +3) Add the following entries to /etc/rc.local or similar script to be run at system startup: # Insert BINFMT_MISC module into the kernel diff --git a/trunk/Documentation/networking/bonding.txt b/trunk/Documentation/networking/bonding.txt index 24d029455baa..a55f0f95b171 100644 --- a/trunk/Documentation/networking/bonding.txt +++ b/trunk/Documentation/networking/bonding.txt @@ -1241,7 +1241,7 @@ traffic while still maintaining carrier on. If running SNMP agents, the bonding driver should be loaded before any network drivers participating in a bond. This requirement -is due to the the interface index (ipAdEntIfIndex) being associated to +is due to the interface index (ipAdEntIfIndex) being associated to the first interface found with a given IP address. That is, there is only one ipAdEntIfIndex for each IP address. For example, if eth0 and eth1 are slaves of bond0 and the driver for eth0 is loaded before the @@ -1937,7 +1937,7 @@ switches currently available support 802.3ad. If not explicitly configured (with ifconfig or ip link), the MAC address of the bonding device is taken from its first slave device. This MAC address is then passed to all following slaves and -remains persistent (even if the the first slave is removed) until the +remains persistent (even if the first slave is removed) until the bonding device is brought down or reconfigured. If you wish to change the MAC address, you can set it with diff --git a/trunk/Documentation/networking/wan-router.txt b/trunk/Documentation/networking/wan-router.txt index aea20cd2a56e..c96897aa08b6 100644 --- a/trunk/Documentation/networking/wan-router.txt +++ b/trunk/Documentation/networking/wan-router.txt @@ -355,7 +355,7 @@ REVISION HISTORY There is no functional difference between the two packages 2.0.7 Aug 26, 1999 o Merged X25API code into WANPIPE. - o Fixed a memeory leak for X25API + o Fixed a memory leak for X25API o Updated the X25API code for 2.2.X kernels. o Improved NEM handling. @@ -514,7 +514,7 @@ beta2-2.2.0 Jan 8 2001 o Patches for 2.4.0 kernel o Patches for 2.2.18 kernel o Minor updates to PPP and CHLDC drivers. - Note: No functinal difference. + Note: No functional difference. beta3-2.2.9 Jan 10 2001 o I missed the 2.2.18 kernel patches in beta2-2.2.0 diff --git a/trunk/Documentation/oops-tracing.txt b/trunk/Documentation/oops-tracing.txt index da711028e5f7..66eaaab7773d 100644 --- a/trunk/Documentation/oops-tracing.txt +++ b/trunk/Documentation/oops-tracing.txt @@ -205,8 +205,8 @@ Phone: 701-234-7556 Tainted kernels: Some oops reports contain the string 'Tainted: ' after the program -counter, this indicates that the kernel has been tainted by some -mechanism. The string is followed by a series of position sensitive +counter. This indicates that the kernel has been tainted by some +mechanism. The string is followed by a series of position-sensitive characters, each representing a particular tainted value. 1: 'G' if all modules loaded have a GPL or compatible license, 'P' if @@ -214,16 +214,25 @@ characters, each representing a particular tainted value. MODULE_LICENSE or with a MODULE_LICENSE that is not recognised by insmod as GPL compatible are assumed to be proprietary. - 2: 'F' if any module was force loaded by insmod -f, ' ' if all + 2: 'F' if any module was force loaded by "insmod -f", ' ' if all modules were loaded normally. 3: 'S' if the oops occurred on an SMP kernel running on hardware that - hasn't been certified as safe to run multiprocessor. - Currently this occurs only on various Athlons that are not - SMP capable. + hasn't been certified as safe to run multiprocessor. + Currently this occurs only on various Athlons that are not + SMP capable. + + 4: 'R' if a module was force unloaded by "rmmod -f", ' ' if all + modules were unloaded normally. + + 5: 'M' if any processor has reported a Machine Check Exception, + ' ' if no Machine Check Exceptions have occurred. + + 6: 'B' if a page-release function has found a bad page reference or + some unexpected page flags. The primary reason for the 'Tainted: ' string is to tell kernel debuggers if this is a clean kernel or if anything unusual has -occurred. Tainting is permanent, even if an offending module is -unloading the tainted value remains to indicate that the kernel is not +occurred. Tainting is permanent: even if an offending module is +unloaded, the tainted value remains to indicate that the kernel is not trustworthy. diff --git a/trunk/Documentation/pci.txt b/trunk/Documentation/pci.txt index 76d28d033657..711210b38f5f 100644 --- a/trunk/Documentation/pci.txt +++ b/trunk/Documentation/pci.txt @@ -84,7 +84,7 @@ Each entry consists of: Most drivers don't need to use the driver_data field. Best practice for use of driver_data is to use it as an index into a static list of -equivalant device types, not to use it as a pointer. +equivalent device types, not to use it as a pointer. Have a table entry {PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID, PCI_ANY_ID} to have probe() called for every PCI device known to the system. diff --git a/trunk/Documentation/pm.txt b/trunk/Documentation/pm.txt index cc63ae18d147..2ea1149bf6b0 100644 --- a/trunk/Documentation/pm.txt +++ b/trunk/Documentation/pm.txt @@ -38,6 +38,12 @@ system the associated daemon will exit gracefully. Driver Interface -- OBSOLETE, DO NOT USE! ----------------************************* + +Note: pm_register(), pm_access(), pm_dev_idle() and friends are +obsolete. Please do not use them. Instead you should properly hook +your driver into the driver model, and use its suspend()/resume() +callbacks to do this kind of stuff. + If you are writing a new driver or maintaining an old driver, it should include power management support. Without power management support, a single driver may prevent a system with power management diff --git a/trunk/Documentation/powerpc/eeh-pci-error-recovery.txt b/trunk/Documentation/powerpc/eeh-pci-error-recovery.txt index 2bfe71beec5b..e75d7474322c 100644 --- a/trunk/Documentation/powerpc/eeh-pci-error-recovery.txt +++ b/trunk/Documentation/powerpc/eeh-pci-error-recovery.txt @@ -134,7 +134,7 @@ pci_get_device_by_addr() will find the pci device associated with that address (if any). The default include/asm-ppc64/io.h macros readb(), inb(), insb(), -etc. include a check to see if the the i/o read returned all-0xff's. +etc. include a check to see if the i/o read returned all-0xff's. If so, these make a call to eeh_dn_check_failure(), which in turn asks the firmware if the all-ff's value is the sign of a true EEH error. If it is not, processing continues as normal. The grand diff --git a/trunk/Documentation/s390/s390dbf.txt b/trunk/Documentation/s390/s390dbf.txt index e24fdeada970..e321a8ed2a2d 100644 --- a/trunk/Documentation/s390/s390dbf.txt +++ b/trunk/Documentation/s390/s390dbf.txt @@ -468,7 +468,7 @@ The hex_ascii view shows the data field in hex and ascii representation The raw view returns a bytestream as the debug areas are stored in memory. The sprintf view formats the debug entries in the same way as the sprintf -function would do. The sprintf event/expection fuctions write to the +function would do. The sprintf event/expection functions write to the debug entry a pointer to the format string (size = sizeof(long)) and for each vararg a long value. So e.g. for a debug entry with a format string plus two varargs one would need to allocate a (3 * sizeof(long)) diff --git a/trunk/Documentation/scsi/00-INDEX b/trunk/Documentation/scsi/00-INDEX index f9cb5bdcce41..fef92ebf266f 100644 --- a/trunk/Documentation/scsi/00-INDEX +++ b/trunk/Documentation/scsi/00-INDEX @@ -60,6 +60,8 @@ scsi.txt - short blurb on using SCSI support as a module. scsi_mid_low_api.txt - info on API between SCSI layer and low level drivers +scsi_eh.txt + - info on SCSI midlayer error handling infrastructure st.txt - info on scsi tape driver sym53c500_cs.txt diff --git a/trunk/Documentation/scsi/ibmmca.txt b/trunk/Documentation/scsi/ibmmca.txt index 2814491600ff..2ffb3ae0ef4d 100644 --- a/trunk/Documentation/scsi/ibmmca.txt +++ b/trunk/Documentation/scsi/ibmmca.txt @@ -344,7 +344,7 @@ /proc/scsi/ibmmca/. ibmmca_proc_info() provides this information. This table is quite informative for interested users. It shows the load - of commands on the subsystem and wether you are running the bypassed + of commands on the subsystem and whether you are running the bypassed (software) or integrated (hardware) SCSI-command set (see below). The amount of accesses is shown. Read, write, modeselect is shown separately in order to help debugging problems with CD-ROMs or tapedrives. diff --git a/trunk/Documentation/scsi/scsi_eh.txt b/trunk/Documentation/scsi/scsi_eh.txt new file mode 100644 index 000000000000..534a50922a7b --- /dev/null +++ b/trunk/Documentation/scsi/scsi_eh.txt @@ -0,0 +1,479 @@ + +SCSI EH +====================================== + + This document describes SCSI midlayer error handling infrastructure. +Please refer to Documentation/scsi/scsi_mid_low_api.txt for more +information regarding SCSI midlayer. + +TABLE OF CONTENTS + +[1] How SCSI commands travel through the midlayer and to EH + [1-1] struct scsi_cmnd + [1-2] How do scmd's get completed? + [1-2-1] Completing a scmd w/ scsi_done + [1-2-2] Completing a scmd w/ timeout + [1-3] How EH takes over +[2] How SCSI EH works + [2-1] EH through fine-grained callbacks + [2-1-1] Overview + [2-1-2] Flow of scmds through EH + [2-1-3] Flow of control + [2-2] EH through hostt->eh_strategy_handler() + [2-2-1] Pre hostt->eh_strategy_handler() SCSI midlayer conditions + [2-2-2] Post hostt->eh_strategy_handler() SCSI midlayer conditions + [2-2-3] Things to consider + + +[1] How SCSI commands travel through the midlayer and to EH + +[1-1] struct scsi_cmnd + + Each SCSI command is represented with struct scsi_cmnd (== scmd). A +scmd has two list_head's to link itself into lists. The two are +scmd->list and scmd->eh_entry. The former is used for free list or +per-device allocated scmd list and not of much interest to this EH +discussion. The latter is used for completion and EH lists and unless +otherwise stated scmds are always linked using scmd->eh_entry in this +discussion. + + +[1-2] How do scmd's get completed? + + Once LLDD gets hold of a scmd, either the LLDD will complete the +command by calling scsi_done callback passed from midlayer when +invoking hostt->queuecommand() or SCSI midlayer will time it out. + + +[1-2-1] Completing a scmd w/ scsi_done + + For all non-EH commands, scsi_done() is the completion callback. It +does the following. + + 1. Delete timeout timer. If it fails, it means that timeout timer + has expired and is going to finish the command. Just return. + + 2. Link scmd to per-cpu scsi_done_q using scmd->en_entry + + 3. Raise SCSI_SOFTIRQ + + SCSI_SOFTIRQ handler scsi_softirq calls scsi_decide_disposition() to +determine what to do with the command. scsi_decide_disposition() +looks at the scmd->result value and sense data to determine what to do +with the command. + + - SUCCESS + scsi_finish_command() is invoked for the command. The + function does some maintenance choirs and notify completion by + calling scmd->done() callback, which, for fs requests, would + be HLD completion callback - sd:sd_rw_intr, sr:rw_intr, + st:st_intr. + + - NEEDS_RETRY + - ADD_TO_MLQUEUE + scmd is requeued to blk queue. + + - otherwise + scsi_eh_scmd_add(scmd, 0) is invoked for the command. See + [1-3] for details of this funciton. + + +[1-2-2] Completing a scmd w/ timeout + + The timeout handler is scsi_times_out(). When a timeout occurs, this +function + + 1. invokes optional hostt->eh_timedout() callback. Return value can + be one of + + - EH_HANDLED + This indicates that eh_timedout() dealt with the timeout. The + scmd is passed to __scsi_done() and thus linked into per-cpu + scsi_done_q. Normal command completion described in [1-2-1] + follows. + + - EH_RESET_TIMER + This indicates that more time is required to finish the + command. Timer is restarted. This action is counted as a + retry and only allowed scmd->allowed + 1(!) times. Once the + limit is reached, action for EH_NOT_HANDLED is taken instead. + + *NOTE* This action is racy as the LLDD could finish the scmd + after the timeout has expired but before it's added back. In + such cases, scsi_done() would think that timeout has occurred + and return without doing anything. We lose completion and the + command will time out again. + + - EH_NOT_HANDLED + This is the same as when eh_timedout() callback doesn't exist. + Step #2 is taken. + + 2. scsi_eh_scmd_add(scmd, SCSI_EH_CANCEL_CMD) is invoked for the + command. See [1-3] for more information. + + +[1-3] How EH takes over + + scmds enter EH via scsi_eh_scmd_add(), which does the following. + + 1. Turns on scmd->eh_eflags as requested. It's 0 for error + completions and SCSI_EH_CANCEL_CMD for timeouts. + + 2. Links scmd->eh_entry to shost->eh_cmd_q + + 3. Sets SHOST_RECOVERY bit in shost->shost_state + + 4. Increments shost->host_failed + + 5. Wakes up SCSI EH thread if shost->host_busy == shost->host_failed + + As can be seen above, once any scmd is added to shost->eh_cmd_q, +SHOST_RECOVERY shost_state bit is turned on. This prevents any new +scmd to be issued from blk queue to the host; eventually, all scmds on +the host either complete normally, fail and get added to eh_cmd_q, or +time out and get added to shost->eh_cmd_q. + + If all scmds either complete or fail, the number of in-flight scmds +becomes equal to the number of failed scmds - i.e. shost->host_busy == +shost->host_failed. This wakes up SCSI EH thread. So, once woken up, +SCSI EH thread can expect that all in-flight commands have failed and +are linked on shost->eh_cmd_q. + + Note that this does not mean lower layers are quiescent. If a LLDD +completed a scmd with error status, the LLDD and lower layers are +assumed to forget about the scmd at that point. However, if a scmd +has timed out, unless hostt->eh_timedout() made lower layers forget +about the scmd, which currently no LLDD does, the command is still +active as long as lower layers are concerned and completion could +occur at any time. Of course, all such completions are ignored as the +timer has already expired. + + We'll talk about how SCSI EH takes actions to abort - make LLDD +forget about - timed out scmds later. + + +[2] How SCSI EH works + + LLDD's can implement SCSI EH actions in one of the following two +ways. + + - Fine-grained EH callbacks + LLDD can implement fine-grained EH callbacks and let SCSI + midlayer drive error handling and call appropriate callbacks. + This will be dicussed further in [2-1]. + + - eh_strategy_handler() callback + This is one big callback which should perform whole error + handling. As such, it should do all choirs SCSI midlayer + performs during recovery. This will be discussed in [2-2]. + + Once recovery is complete, SCSI EH resumes normal operation by +calling scsi_restart_operations(), which + + 1. Checks if door locking is needed and locks door. + + 2. Clears SHOST_RECOVERY shost_state bit + + 3. Wakes up waiters on shost->host_wait. This occurs if someone + calls scsi_block_when_processing_errors() on the host. + (*QUESTION* why is it needed? All operations will be blocked + anyway after it reaches blk queue.) + + 4. Kicks queues in all devices on the host in the asses + + +[2-1] EH through fine-grained callbacks + +[2-1-1] Overview + + If eh_strategy_handler() is not present, SCSI midlayer takes charge +of driving error handling. EH's goals are two - make LLDD, host and +device forget about timed out scmds and make them ready for new +commands. A scmd is said to be recovered if the scmd is forgotten by +lower layers and lower layers are ready to process or fail the scmd +again. + + To achieve these goals, EH performs recovery actions with increasing +severity. Some actions are performed by issueing SCSI commands and +others are performed by invoking one of the following fine-grained +hostt EH callbacks. Callbacks may be omitted and omitted ones are +considered to fail always. + +int (* eh_abort_handler)(struct scsi_cmnd *); +int (* eh_device_reset_handler)(struct scsi_cmnd *); +int (* eh_bus_reset_handler)(struct scsi_cmnd *); +int (* eh_host_reset_handler)(struct scsi_cmnd *); + + Higher-severity actions are taken only when lower-severity actions +cannot recover some of failed scmds. Also, note that failure of the +highest-severity action means EH failure and results in offlining of +all unrecovered devices. + + During recovery, the following rules are followed + + - Recovery actions are performed on failed scmds on the to do list, + eh_work_q. If a recovery action succeeds for a scmd, recovered + scmds are removed from eh_work_q. + + Note that single recovery action on a scmd can recover multiple + scmds. e.g. resetting a device recovers all failed scmds on the + device. + + - Higher severity actions are taken iff eh_work_q is not empty after + lower severity actions are complete. + + - EH reuses failed scmds to issue commands for recovery. For + timed-out scmds, SCSI EH ensures that LLDD forgets about a scmd + before reusing it for EH commands. + + When a scmd is recovered, the scmd is moved from eh_work_q to EH +local eh_done_q using scsi_eh_finish_cmd(). After all scmds are +recovered (eh_work_q is empty), scsi_eh_flush_done_q() is invoked to +either retry or error-finish (notify upper layer of failure) recovered +scmds. + + scmds are retried iff its sdev is still online (not offlined during +EH), REQ_FAILFAST is not set and ++scmd->retries is less than +scmd->allowed. + + +[2-1-2] Flow of scmds through EH + + 1. Error completion / time out + ACTION: scsi_eh_scmd_add() is invoked for scmd + - set scmd->eh_eflags + - add scmd to shost->eh_cmd_q + - set SHOST_RECOVERY + - shost->host_failed++ + LOCKING: shost->host_lock + + 2. EH starts + ACTION: move all scmds to EH's local eh_work_q. shost->eh_cmd_q + is cleared. + LOCKING: shost->host_lock (not strictly necessary, just for + consistency) + + 3. scmd recovered + ACTION: scsi_eh_finish_cmd() is invoked to EH-finish scmd + - shost->host_failed-- + - clear scmd->eh_eflags + - scsi_setup_cmd_retry() + - move from local eh_work_q to local eh_done_q + LOCKING: none + + 4. EH completes + ACTION: scsi_eh_flush_done_q() retries scmds or notifies upper + layer of failure. + - scmd is removed from eh_done_q and scmd->eh_entry is cleared + - if retry is necessary, scmd is requeued using + scsi_queue_insert() + - otherwise, scsi_finish_command() is invoked for scmd + LOCKING: queue or finish function performs appropriate locking + + +[2-1-3] Flow of control + + EH through fine-grained callbacks start from scsi_unjam_host(). + +<> + + 1. Lock shost->host_lock, splice_init shost->eh_cmd_q into local + eh_work_q and unlock host_lock. Note that shost->eh_cmd_q is + cleared by this action. + + 2. Invoke scsi_eh_get_sense. + + <> + + This action is taken for each error-completed + (!SCSI_EH_CANCEL_CMD) commands without valid sense data. Most + SCSI transports/LLDDs automatically acquire sense data on + command failures (autosense). Autosense is recommended for + performance reasons and as sense information could get out of + sync inbetween occurrence of CHECK CONDITION and this action. + + Note that if autosense is not supported, scmd->sense_buffer + contains invalid sense data when error-completing the scmd + with scsi_done(). scsi_decide_disposition() always returns + FAILED in such cases thus invoking SCSI EH. When the scmd + reaches here, sense data is acquired and + scsi_decide_disposition() is called again. + + 1. Invoke scsi_request_sense() which issues REQUEST_SENSE + command. If fails, no action. Note that taking no action + causes higher-severity recovery to be taken for the scmd. + + 2. Invoke scsi_decide_disposition() on the scmd + + - SUCCESS + scmd->retries is set to scmd->allowed preventing + scsi_eh_flush_done_q() from retrying the scmd and + scsi_eh_finish_cmd() is invoked. + + - NEEDS_RETRY + scsi_eh_finish_cmd() invoked + + - otherwise + No action. + + 3. If !list_empty(&eh_work_q), invoke scsi_eh_abort_cmds(). + + <> + + This action is taken for each timed out command. + hostt->eh_abort_handler() is invoked for each scmd. The + handler returns SUCCESS if it has succeeded to make LLDD and + all related hardware forget about the scmd. + + If a timedout scmd is successfully aborted and the sdev is + either offline or ready, scsi_eh_finish_cmd() is invoked for + the scmd. Otherwise, the scmd is left in eh_work_q for + higher-severity actions. + + Note that both offline and ready status mean that the sdev is + ready to process new scmds, where processing also implies + immediate failing; thus, if a sdev is in one of the two + states, no further recovery action is needed. + + Device readiness is tested using scsi_eh_tur() which issues + TEST_UNIT_READY command. Note that the scmd must have been + aborted successfully before reusing it for TEST_UNIT_READY. + + 4. If !list_empty(&eh_work_q), invoke scsi_eh_ready_devs() + + <> + + This function takes four increasingly more severe measures to + make failed sdevs ready for new commands. + + 1. Invoke scsi_eh_stu() + + <> + + For each sdev which has failed scmds with valid sense data + of which scsi_check_sense()'s verdict is FAILED, + START_STOP_UNIT command is issued w/ start=1. Note that + as we explicitly choose error-completed scmds, it is known + that lower layers have forgotten about the scmd and we can + reuse it for STU. + + If STU succeeds and the sdev is either offline or ready, + all failed scmds on the sdev are EH-finished with + scsi_eh_finish_cmd(). + + *NOTE* If hostt->eh_abort_handler() isn't implemented or + failed, we may still have timed out scmds at this point + and STU doesn't make lower layers forget about those + scmds. Yet, this function EH-finish all scmds on the sdev + if STU succeeds leaving lower layers in an inconsistent + state. It seems that STU action should be taken only when + a sdev has no timed out scmd. + + 2. If !list_empty(&eh_work_q), invoke scsi_eh_bus_device_reset(). + + <> + + This action is very similar to scsi_eh_stu() except that, + instead of issuing STU, hostt->eh_device_reset_handler() + is used. Also, as we're not issuing SCSI commands and + resetting clears all scmds on the sdev, there is no need + to choose error-completed scmds. + + 3. If !list_empty(&eh_work_q), invoke scsi_eh_bus_reset() + + <> + + hostt->eh_bus_reset_handler() is invoked for each channel + with failed scmds. If bus reset succeeds, all failed + scmds on all ready or offline sdevs on the channel are + EH-finished. + + 4. If !list_empty(&eh_work_q), invoke scsi_eh_host_reset() + + <> + + This is the last resort. hostt->eh_host_reset_handler() + is invoked. If host reset succeeds, all failed scmds on + all ready or offline sdevs on the host are EH-finished. + + 5. If !list_empty(&eh_work_q), invoke scsi_eh_offline_sdevs() + + <> + + Take all sdevs which still have unrecovered scmds offline + and EH-finish the scmds. + + 5. Invoke scsi_eh_flush_done_q(). + + <> + + At this point all scmds are recovered (or given up) and + put on eh_done_q by scsi_eh_finish_cmd(). This function + flushes eh_done_q by either retrying or notifying upper + layer of failure of the scmds. + + +[2-2] EH through hostt->eh_strategy_handler() + + hostt->eh_strategy_handler() is invoked in the place of +scsi_unjam_host() and it is responsible for whole recovery process. +On completion, the handler should have made lower layers forget about +all failed scmds and either ready for new commands or offline. Also, +it should perform SCSI EH maintenance choirs to maintain integrity of +SCSI midlayer. IOW, of the steps described in [2-1-2], all steps +except for #1 must be implemented by eh_strategy_handler(). + + +[2-2-1] Pre hostt->eh_strategy_handler() SCSI midlayer conditions + + The following conditions are true on entry to the handler. + + - Each failed scmd's eh_flags field is set appropriately. + + - Each failed scmd is linked on scmd->eh_cmd_q by scmd->eh_entry. + + - SHOST_RECOVERY is set. + + - shost->host_failed == shost->host_busy + + +[2-2-2] Post hostt->eh_strategy_handler() SCSI midlayer conditions + + The following conditions must be true on exit from the handler. + + - shost->host_failed is zero. + + - Each scmd's eh_eflags field is cleared. + + - Each scmd is in such a state that scsi_setup_cmd_retry() on the + scmd doesn't make any difference. + + - shost->eh_cmd_q is cleared. + + - Each scmd->eh_entry is cleared. + + - Either scsi_queue_insert() or scsi_finish_command() is called on + each scmd. Note that the handler is free to use scmd->retries and + ->allowed to limit the number of retries. + + +[2-2-3] Things to consider + + - Know that timed out scmds are still active on lower layers. Make + lower layers forget about them before doing anything else with + those scmds. + + - For consistency, when accessing/modifying shost data structure, + grab shost->host_lock. + + - On completion, each failed sdev must have forgotten about all + active scmds. + + - On completion, each failed sdev must be ready for new commands or + offline. + + +-- +Tejun Heo +htejun@gmail.com +11th September 2005 diff --git a/trunk/Documentation/sound/alsa/ALSA-Configuration.txt b/trunk/Documentation/sound/alsa/ALSA-Configuration.txt index 5c49ba07e709..ebfcdf28485f 100644 --- a/trunk/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/trunk/Documentation/sound/alsa/ALSA-Configuration.txt @@ -1459,7 +1459,7 @@ devices where %i is sound card number from zero to seven. To auto-load an ALSA driver for OSS services, define the string 'sound-slot-%i' where %i means the slot number for OSS, which corresponds to the card index of ALSA. Usually, define this -as the the same card module. +as the same card module. An example configuration for a single emu10k1 card is like below: ----- /etc/modprobe.conf diff --git a/trunk/Documentation/sysrq.txt b/trunk/Documentation/sysrq.txt index 136d817c01ba..baf17b381588 100644 --- a/trunk/Documentation/sysrq.txt +++ b/trunk/Documentation/sysrq.txt @@ -171,7 +171,7 @@ the header 'include/linux/sysrq.h', this will define everything else you need. Next, you must create a sysrq_key_op struct, and populate it with A) the key handler function you will use, B) a help_msg string, that will print when SysRQ prints help, and C) an action_msg string, that will print right before your -handler is called. Your handler must conform to the protoype in 'sysrq.h'. +handler is called. Your handler must conform to the prototype in 'sysrq.h'. After the sysrq_key_op is created, you can call the macro register_sysrq_key(int key, struct sysrq_key_op *op_p) that is defined in diff --git a/trunk/Documentation/uml/UserModeLinux-HOWTO.txt b/trunk/Documentation/uml/UserModeLinux-HOWTO.txt index 0c7b654fec99..544430e39980 100644 --- a/trunk/Documentation/uml/UserModeLinux-HOWTO.txt +++ b/trunk/Documentation/uml/UserModeLinux-HOWTO.txt @@ -2176,7 +2176,7 @@ If you want to access files on the host machine from inside UML, you can treat it as a separate machine and either nfs mount directories from the host or copy files into the virtual machine with scp or rcp. - However, since UML is running on the the host, it can access those + However, since UML is running on the host, it can access those files just like any other process and make them available inside the virtual machine without needing to use the network. diff --git a/trunk/Documentation/usb/gadget_serial.txt b/trunk/Documentation/usb/gadget_serial.txt index a938c3dd13d6..815f5c2301ff 100644 --- a/trunk/Documentation/usb/gadget_serial.txt +++ b/trunk/Documentation/usb/gadget_serial.txt @@ -20,7 +20,7 @@ License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA. -This document and the the gadget serial driver itself are +This document and the gadget serial driver itself are Copyright (C) 2004 by Al Borchers (alborchers@steinerpoint.com). If you have questions, problems, or suggestions for this driver diff --git a/trunk/Documentation/usb/proc_usb_info.txt b/trunk/Documentation/usb/proc_usb_info.txt index 729c72d34c89..f86550fe38ee 100644 --- a/trunk/Documentation/usb/proc_usb_info.txt +++ b/trunk/Documentation/usb/proc_usb_info.txt @@ -20,7 +20,7 @@ the /proc/bus/usb/BBB/DDD files. to /etc/fstab. This will mount usbfs at each reboot. You can then issue `cat /proc/bus/usb/devices` to extract - USB device information, and user mode drivers can use usbfs + USB device information, and user mode drivers can use usbfs to interact with USB devices. There are a number of mount options supported by usbfs. @@ -32,7 +32,7 @@ the /proc/bus/usb/BBB/DDD files. still see references to the older "usbdevfs" name. For more information on mounting the usbfs file system, see the -"USB Device Filesystem" section of the USB Guide. The latest copy +"USB Device Filesystem" section of the USB Guide. The latest copy of the USB Guide can be found at http://www.linux-usb.org/ @@ -133,7 +133,7 @@ B: Alloc=ddd/ddd us (xx%), #Int=ddd, #Iso=ddd are the only transfers that reserve bandwidth. Control and bulk transfers use all other bandwidth, including reserved bandwidth that is not used for transfers (such as for short packets). - + The percentage is how much of the "reserved" bandwidth is scheduled by those transfers. For a low or full speed bus (loosely, "USB 1.1"), 90% of the bus bandwidth is reserved. For a high speed bus (loosely, @@ -197,7 +197,7 @@ C:* #Ifs=dd Cfg#=dd Atr=xx MPwr=dddmA | | |__NumberOfInterfaces | |__ "*" indicates the active configuration (others are " ") |__Config info tag - + USB devices may have multiple configurations, each of which act rather differently. For example, a bus-powered configuration might be much less capable than one that is self-powered. Only @@ -228,7 +228,7 @@ I: If#=dd Alt=dd #EPs=dd Cls=xx(sssss) Sub=xx Prot=xx Driver=ssss For example, default settings may not use more than a small amount of periodic bandwidth. To use significant fractions of bus bandwidth, drivers must select a non-default altsetting. - + Only one setting for an interface may be active at a time, and only one driver may bind to an interface at a time. Most devices have only one alternate setting per interface. @@ -297,18 +297,21 @@ S: SerialNumber=dce0 C:* #Ifs= 1 Cfg#= 1 Atr=40 MxPwr= 0mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 8 Ivl=255ms + T: Bus=00 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=12 MxCh= 4 D: Ver= 1.00 Cls=09(hub ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0451 ProdID=1446 Rev= 1.00 C:* #Ifs= 1 Cfg#= 1 Atr=e0 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=09(hub ) Sub=00 Prot=00 Driver=hub E: Ad=81(I) Atr=03(Int.) MxPS= 1 Ivl=255ms + T: Bus=00 Lev=02 Prnt=02 Port=00 Cnt=01 Dev#= 3 Spd=1.5 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=04b4 ProdID=0001 Rev= 0.00 C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=100mA I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=01 Prot=02 Driver=mouse E: Ad=81(I) Atr=03(Int.) MxPS= 3 Ivl= 10ms + T: Bus=00 Lev=02 Prnt=02 Port=02 Cnt=02 Dev#= 4 Spd=12 MxCh= 0 D: Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS= 8 #Cfgs= 1 P: Vendor=0565 ProdID=0001 Rev= 1.08 diff --git a/trunk/Documentation/video4linux/Zoran b/trunk/Documentation/video4linux/Zoran index 01425c21986b..52c94bd7dca1 100644 --- a/trunk/Documentation/video4linux/Zoran +++ b/trunk/Documentation/video4linux/Zoran @@ -222,7 +222,7 @@ was introduced in 1991, is used in the DC10 old can generate: PAL , NTSC , SECAM The adv717x, should be able to produce PAL N. But you find nothing PAL N -specific in the the registers. Seem that you have to reuse a other standard +specific in the registers. Seem that you have to reuse a other standard to generate PAL N, maybe it would work if you use the PAL M settings. ========================== diff --git a/trunk/Documentation/x86_64/boot-options.txt b/trunk/Documentation/x86_64/boot-options.txt index 678e8f192db2..ffe1c062088b 100644 --- a/trunk/Documentation/x86_64/boot-options.txt +++ b/trunk/Documentation/x86_64/boot-options.txt @@ -11,6 +11,11 @@ Machine check If your BIOS doesn't do that it's a good idea to enable though to make sure you log even machine check events that result in a reboot. + mce=tolerancelevel (number) + 0: always panic, 1: panic if deadlock possible, + 2: try to avoid panic, 3: never panic or exit (for testing) + default is 1 + Can be also set using sysfs which is preferable. nomce (for compatibility with i386): same as mce=off diff --git a/trunk/Kbuild b/trunk/Kbuild index 1880e6f760aa..79003918f37f 100644 --- a/trunk/Kbuild +++ b/trunk/Kbuild @@ -4,7 +4,7 @@ # 1) Generate asm-offsets.h ##### -# 1) Generate asm-offsets.h +# 1) Generate asm-offsets.h # offsets-file := include/asm-$(ARCH)/asm-offsets.h @@ -22,6 +22,7 @@ sed-$(CONFIG_MIPS) := "/^@@@/s///p" quiet_cmd_offsets = GEN $@ define cmd_offsets + mkdir -p $(dir $@); \ cat $< | \ (set -e; \ echo "#ifndef __ASM_OFFSETS_H__"; \ @@ -43,6 +44,6 @@ arch/$(ARCH)/kernel/asm-offsets.s: arch/$(ARCH)/kernel/asm-offsets.c FORCE $(Q)mkdir -p $(dir $@) $(call if_changed_dep,cc_s_c) -$(srctree)/$(offsets-file): arch/$(ARCH)/kernel/asm-offsets.s Kbuild +$(obj)/$(offsets-file): arch/$(ARCH)/kernel/asm-offsets.s Kbuild $(call cmd,offsets) diff --git a/trunk/MAINTAINERS b/trunk/MAINTAINERS index f038dca34ee8..a67bf7d315d7 100644 --- a/trunk/MAINTAINERS +++ b/trunk/MAINTAINERS @@ -964,6 +964,13 @@ L: lm-sensors@lm-sensors.org W: http://www.lm-sensors.nu/ S: Maintained +HARD DRIVE ACTIVE PROTECTION SYSTEM (HDAPS) DRIVER +P: Robert Love +M: rlove@rlove.org +M: linux-kernel@vger.kernel.org +W: http://www.kernel.org/pub/linux/kernel/people/rml/hdaps/ +S: Maintained + HARMONY SOUND DRIVER P: Kyle McMartin M: kyle@parisc-linux.org diff --git a/trunk/Makefile b/trunk/Makefile index 2402430c87e6..4e0d7c68d223 100644 --- a/trunk/Makefile +++ b/trunk/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 -SUBLEVEL = 13 -EXTRAVERSION = +SUBLEVEL = 14 +EXTRAVERSION =-rc1 NAME=Affluent Albatross # *DOCUMENTATION* @@ -334,7 +334,7 @@ KALLSYMS = scripts/kallsyms PERL = perl CHECK = sparse -CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ +CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ $(CF) MODFLAGS = -DMODULE CFLAGS_MODULE = $(MODFLAGS) AFLAGS_MODULE = $(MODFLAGS) @@ -382,6 +382,9 @@ RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn --exclude CV scripts_basic: $(Q)$(MAKE) $(build)=scripts/basic +# To avoid any implicit rule to kick in, define an empty command. +scripts/basic/%: scripts_basic ; + .PHONY: outputmakefile # outputmakefile generate a Makefile to be placed in output directory, if # using a seperate output directory. This allows convinient use @@ -444,9 +447,8 @@ ifeq ($(config-targets),1) include $(srctree)/arch/$(ARCH)/Makefile export KBUILD_DEFCONFIG -config: scripts_basic outputmakefile FORCE - $(Q)$(MAKE) $(build)=scripts/kconfig $@ -%config: scripts_basic outputmakefile FORCE +config %config: scripts_basic outputmakefile FORCE + $(Q)mkdir -p include/linux $(Q)$(MAKE) $(build)=scripts/kconfig $@ else @@ -489,6 +491,7 @@ include .config # If .config is newer than include/linux/autoconf.h, someone tinkered # with it and forgot to run make oldconfig include/linux/autoconf.h: .config + $(Q)mkdir -p include/linux $(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig else # Dummy target needed, because used as prerequisite @@ -641,8 +644,13 @@ quiet_cmd_vmlinux__ ?= LD $@ # Generate new vmlinux version quiet_cmd_vmlinux_version = GEN .version cmd_vmlinux_version = set -e; \ - . $(srctree)/scripts/mkversion > .tmp_version; \ - mv -f .tmp_version .version; \ + if [ ! -r .version ]; then \ + rm -f .version; \ + echo 1 >.version; \ + else \ + mv .version .old_version; \ + expr 0$$(cat .old_version) + 1 >.version; \ + fi; \ $(MAKE) $(build)=init # Generate System.map @@ -756,6 +764,7 @@ endif # ifdef CONFIG_KALLSYMS # vmlinux image - including updated kernel symbols vmlinux: $(vmlinux-lds) $(vmlinux-init) $(vmlinux-main) $(kallsyms.o) FORCE $(call if_changed_rule,vmlinux__) + $(Q)rm -f .old_version # The actual objects are generated when descending, # make sure no implicit rule kicks in @@ -768,15 +777,20 @@ $(sort $(vmlinux-init) $(vmlinux-main)) $(vmlinux-lds): $(vmlinux-dirs) ; # Error messages still appears in the original language .PHONY: $(vmlinux-dirs) -$(vmlinux-dirs): prepare-all scripts +$(vmlinux-dirs): prepare scripts $(Q)$(MAKE) $(build)=$@ # Things we need to do before we recursively start building the kernel -# or the modules are listed in "prepare-all". -# A multi level approach is used. prepare1 is updated first, then prepare0. -# prepare-all is the collection point for the prepare targets. +# or the modules are listed in "prepare". +# A multi level approach is used. prepareN is processed before prepareN-1. +# archprepare is used in arch Makefiles and when processed asm symlink, +# version.h and scripts_basic is processed / created. -.PHONY: prepare-all prepare prepare0 prepare1 prepare2 prepare3 +# Listed in dependency order +.PHONY: prepare archprepare prepare0 prepare1 prepare2 prepare3 + +# prepare-all is deprecated, use prepare as valid replacement +.PHONY: prepare-all # prepare3 is used to check if we are building in a separate output directory, # and if so do: @@ -805,11 +819,13 @@ ifneq ($(KBUILD_MODULES),) $(Q)mkdir -p $(MODVERDIR) endif -prepare0: prepare prepare1 FORCE - $(Q)$(MAKE) $(build)=$(srctree) +archprepare: prepare1 scripts_basic + +prepare0: archprepare FORCE + $(Q)$(MAKE) $(build)=. # All the preparing.. -prepare-all: prepare0 +prepare prepare-all: prepare0 # Leave this as default for preprocessing vmlinux.lds.S, which is now # done in arch/$(ARCH)/kernel/Makefile @@ -848,7 +864,7 @@ include/asm: # Split autoconf.h into include/linux/config/* -include/config/MARKER: include/linux/autoconf.h +include/config/MARKER: scripts/basic/split-include include/linux/autoconf.h @echo ' SPLIT include/linux/autoconf.h -> include/config/*' @scripts/basic/split-include include/linux/autoconf.h include/config @touch $@ @@ -900,7 +916,7 @@ modules: $(vmlinux-dirs) $(if $(KBUILD_BUILTIN),vmlinux) # Target to prepare building external modules .PHONY: modules_prepare -modules_prepare: prepare-all scripts +modules_prepare: prepare scripts # Target to install modules .PHONY: modules_install @@ -1053,6 +1069,7 @@ help: @echo ' rpm - Build a kernel as an RPM package' @echo ' tags/TAGS - Generate tags file for editors' @echo ' cscope - Generate cscope index' + @echo ' kernelrelease - Output the release version string' @echo '' @echo 'Static analysers' @echo ' buildcheck - List dangling references to vmlinux discarded sections' diff --git a/trunk/REPORTING-BUGS b/trunk/REPORTING-BUGS index 224c34741d32..f9da827a0c18 100644 --- a/trunk/REPORTING-BUGS +++ b/trunk/REPORTING-BUGS @@ -9,7 +9,7 @@ screen please read "Documentation/oops-tracing.txt" before posting your bug report. This explains what you should do with the "Oops" information to make it useful to the recipient. - Send the output the maintainer of the kernel area that seems to + Send the output to the maintainer of the kernel area that seems to be involved with the problem. Don't worry too much about getting the wrong person. If you are unsure send it to the person responsible for the code relevant to what you were doing. If it occurs repeatably try and @@ -18,15 +18,15 @@ The list of maintainers is in the MAINTAINERS file in this directory. If it is a security bug, please copy the Security Contact listed in the MAINTAINERS file. They can help coordinate bugfix and disclosure. -See Documentation/SecurityBugs for more infomation. +See Documentation/SecurityBugs for more information. If you are totally stumped as to whom to send the report, send it to linux-kernel@vger.kernel.org. (For more information on the linux-kernel mailing list see http://www.tux.org/lkml/). -This is a suggested format for a bug report sent to the Linux kernel mailing -list. Having a standardized bug report form makes it easier for you not to -overlook things, and easier for the developers to find the pieces of +This is a suggested format for a bug report sent to the Linux kernel mailing +list. Having a standardized bug report form makes it easier for you not to +overlook things, and easier for the developers to find the pieces of information they're really interested in. Don't feel you have to follow it. First run the ver_linux script included as scripts/ver_linux, which @@ -35,9 +35,9 @@ the command "sh scripts/ver_linux". Use that information to fill in all fields of the bug report form, and post it to the mailing list with a subject of "PROBLEM: " for easy identification by the developers +summary from [1.]>" for easy identification by the developers. -[1.] One line summary of the problem: +[1.] One line summary of the problem: [2.] Full description of the problem/report: [3.] Keywords (i.e., modules, networking, kernel): [4.] Kernel version (from /proc/version): diff --git a/trunk/arch/alpha/kernel/alpha_ksyms.c b/trunk/arch/alpha/kernel/alpha_ksyms.c index fc5ef90c4fc9..24ae9a366073 100644 --- a/trunk/arch/alpha/kernel/alpha_ksyms.c +++ b/trunk/arch/alpha/kernel/alpha_ksyms.c @@ -185,15 +185,6 @@ EXPORT_SYMBOL(smp_num_cpus); EXPORT_SYMBOL(smp_call_function); EXPORT_SYMBOL(smp_call_function_on_cpu); EXPORT_SYMBOL(_atomic_dec_and_lock); -#ifdef CONFIG_DEBUG_SPINLOCK -EXPORT_SYMBOL(_raw_spin_unlock); -EXPORT_SYMBOL(debug_spin_lock); -EXPORT_SYMBOL(debug_spin_trylock); -#endif -#ifdef CONFIG_DEBUG_RWLOCK -EXPORT_SYMBOL(_raw_write_lock); -EXPORT_SYMBOL(_raw_read_lock); -#endif EXPORT_SYMBOL(cpu_present_mask); #endif /* CONFIG_SMP */ diff --git a/trunk/arch/alpha/kernel/osf_sys.c b/trunk/arch/alpha/kernel/osf_sys.c index 2b034182a0ca..0636116210d2 100644 --- a/trunk/arch/alpha/kernel/osf_sys.c +++ b/trunk/arch/alpha/kernel/osf_sys.c @@ -1154,8 +1154,7 @@ osf_usleep_thread(struct timeval32 __user *sleep, struct timeval32 __user *remai ticks = timeval_to_jiffies(&tmp); - current->state = TASK_INTERRUPTIBLE; - ticks = schedule_timeout(ticks); + ticks = schedule_timeout_interruptible(ticks); if (remain) { jiffies_to_timeval(ticks, &tmp); diff --git a/trunk/arch/alpha/kernel/smp.c b/trunk/arch/alpha/kernel/smp.c index e211aa7404e6..da0be3465791 100644 --- a/trunk/arch/alpha/kernel/smp.c +++ b/trunk/arch/alpha/kernel/smp.c @@ -989,175 +989,3 @@ flush_icache_user_range(struct vm_area_struct *vma, struct page *page, preempt_enable(); } - -#ifdef CONFIG_DEBUG_SPINLOCK -void -_raw_spin_unlock(spinlock_t * lock) -{ - mb(); - lock->lock = 0; - - lock->on_cpu = -1; - lock->previous = NULL; - lock->task = NULL; - lock->base_file = "none"; - lock->line_no = 0; -} - -void -debug_spin_lock(spinlock_t * lock, const char *base_file, int line_no) -{ - long tmp; - long stuck; - void *inline_pc = __builtin_return_address(0); - unsigned long started = jiffies; - int printed = 0; - int cpu = smp_processor_id(); - - stuck = 1L << 30; - try_again: - - /* Use sub-sections to put the actual loop at the end - of this object file's text section so as to perfect - branch prediction. */ - __asm__ __volatile__( - "1: ldl_l %0,%1\n" - " subq %2,1,%2\n" - " blbs %0,2f\n" - " or %0,1,%0\n" - " stl_c %0,%1\n" - " beq %0,3f\n" - "4: mb\n" - ".subsection 2\n" - "2: ldl %0,%1\n" - " subq %2,1,%2\n" - "3: blt %2,4b\n" - " blbs %0,2b\n" - " br 1b\n" - ".previous" - : "=r" (tmp), "=m" (lock->lock), "=r" (stuck) - : "m" (lock->lock), "2" (stuck) : "memory"); - - if (stuck < 0) { - printk(KERN_WARNING - "%s:%d spinlock stuck in %s at %p(%d)" - " owner %s at %p(%d) %s:%d\n", - base_file, line_no, - current->comm, inline_pc, cpu, - lock->task->comm, lock->previous, - lock->on_cpu, lock->base_file, lock->line_no); - stuck = 1L << 36; - printed = 1; - goto try_again; - } - - /* Exiting. Got the lock. */ - lock->on_cpu = cpu; - lock->previous = inline_pc; - lock->task = current; - lock->base_file = base_file; - lock->line_no = line_no; - - if (printed) { - printk(KERN_WARNING - "%s:%d spinlock grabbed in %s at %p(%d) %ld ticks\n", - base_file, line_no, current->comm, inline_pc, - cpu, jiffies - started); - } -} - -int -debug_spin_trylock(spinlock_t * lock, const char *base_file, int line_no) -{ - int ret; - if ((ret = !test_and_set_bit(0, lock))) { - lock->on_cpu = smp_processor_id(); - lock->previous = __builtin_return_address(0); - lock->task = current; - } else { - lock->base_file = base_file; - lock->line_no = line_no; - } - return ret; -} -#endif /* CONFIG_DEBUG_SPINLOCK */ - -#ifdef CONFIG_DEBUG_RWLOCK -void _raw_write_lock(rwlock_t * lock) -{ - long regx, regy; - int stuck_lock, stuck_reader; - void *inline_pc = __builtin_return_address(0); - - try_again: - - stuck_lock = 1<<30; - stuck_reader = 1<<30; - - __asm__ __volatile__( - "1: ldl_l %1,%0\n" - " blbs %1,6f\n" - " blt %1,8f\n" - " mov 1,%1\n" - " stl_c %1,%0\n" - " beq %1,6f\n" - "4: mb\n" - ".subsection 2\n" - "6: blt %3,4b # debug\n" - " subl %3,1,%3 # debug\n" - " ldl %1,%0\n" - " blbs %1,6b\n" - "8: blt %4,4b # debug\n" - " subl %4,1,%4 # debug\n" - " ldl %1,%0\n" - " blt %1,8b\n" - " br 1b\n" - ".previous" - : "=m" (*(volatile int *)lock), "=&r" (regx), "=&r" (regy), - "=&r" (stuck_lock), "=&r" (stuck_reader) - : "m" (*(volatile int *)lock), "3" (stuck_lock), "4" (stuck_reader) : "memory"); - - if (stuck_lock < 0) { - printk(KERN_WARNING "write_lock stuck at %p\n", inline_pc); - goto try_again; - } - if (stuck_reader < 0) { - printk(KERN_WARNING "write_lock stuck on readers at %p\n", - inline_pc); - goto try_again; - } -} - -void _raw_read_lock(rwlock_t * lock) -{ - long regx; - int stuck_lock; - void *inline_pc = __builtin_return_address(0); - - try_again: - - stuck_lock = 1<<30; - - __asm__ __volatile__( - "1: ldl_l %1,%0;" - " blbs %1,6f;" - " subl %1,2,%1;" - " stl_c %1,%0;" - " beq %1,6f;" - "4: mb\n" - ".subsection 2\n" - "6: ldl %1,%0;" - " blt %2,4b # debug\n" - " subl %2,1,%2 # debug\n" - " blbs %1,6b;" - " br 1b\n" - ".previous" - : "=m" (*(volatile int *)lock), "=&r" (regx), "=&r" (stuck_lock) - : "m" (*(volatile int *)lock), "2" (stuck_lock) : "memory"); - - if (stuck_lock < 0) { - printk(KERN_WARNING "read_lock stuck at %p\n", inline_pc); - goto try_again; - } -} -#endif /* CONFIG_DEBUG_RWLOCK */ diff --git a/trunk/arch/arm/Kconfig b/trunk/arch/arm/Kconfig index 0f2899b4159d..11fff042aa81 100644 --- a/trunk/arch/arm/Kconfig +++ b/trunk/arch/arm/Kconfig @@ -326,8 +326,8 @@ config SMP processor machines. On a single processor machine, the kernel will run faster if you say N here. - See also the , - , , + See also the , + , and the SMP-HOWTO available at . diff --git a/trunk/arch/arm/Kconfig.debug b/trunk/arch/arm/Kconfig.debug index 45a5709eaaa4..5d3acff8c596 100644 --- a/trunk/arch/arm/Kconfig.debug +++ b/trunk/arch/arm/Kconfig.debug @@ -53,7 +53,7 @@ config DEBUG_LL bool "Kernel low-level debugging functions" depends on DEBUG_KERNEL help - Say Y here to include definitions of printascii, printchar, printhex + Say Y here to include definitions of printascii, printch, printhex in the kernel. This is helpful if you are debugging code that executes before the console is initialized. diff --git a/trunk/arch/arm/Makefile b/trunk/arch/arm/Makefile index e625ac66f49b..130e6228b587 100644 --- a/trunk/arch/arm/Makefile +++ b/trunk/arch/arm/Makefile @@ -175,7 +175,7 @@ else endif @touch $@ -prepare: maketools include/asm-arm/.arch +archprepare: maketools include/asm-arm/.arch .PHONY: maketools FORCE maketools: include/linux/version.h FORCE diff --git a/trunk/arch/arm/common/scoop.c b/trunk/arch/arm/common/scoop.c index 688a595598c8..d3a04c2a2c85 100644 --- a/trunk/arch/arm/common/scoop.c +++ b/trunk/arch/arm/common/scoop.c @@ -91,7 +91,7 @@ EXPORT_SYMBOL(read_scoop_reg); EXPORT_SYMBOL(write_scoop_reg); #ifdef CONFIG_PM -static int scoop_suspend(struct device *dev, uint32_t state, uint32_t level) +static int scoop_suspend(struct device *dev, pm_message_t state, uint32_t level) { if (level == SUSPEND_POWER_DOWN) { struct scoop_dev *sdev = dev_get_drvdata(dev); diff --git a/trunk/arch/arm/kernel/calls.S b/trunk/arch/arm/kernel/calls.S index db07ce42b3b2..949ec4427f21 100644 --- a/trunk/arch/arm/kernel/calls.S +++ b/trunk/arch/arm/kernel/calls.S @@ -10,7 +10,7 @@ * This file is included twice in entry-common.S */ #ifndef NR_syscalls -#define NR_syscalls 320 +#define NR_syscalls 328 #else __syscall_start: @@ -333,6 +333,9 @@ __syscall_start: .long sys_inotify_init .long sys_inotify_add_watch .long sys_inotify_rm_watch + .long sys_mbind_wrapper +/* 320 */ .long sys_get_mempolicy + .long sys_set_mempolicy __syscall_end: .rept NR_syscalls - (__syscall_end - __syscall_start) / 4 diff --git a/trunk/arch/arm/kernel/entry-common.S b/trunk/arch/arm/kernel/entry-common.S index 6281d488ac97..db302c6e5343 100644 --- a/trunk/arch/arm/kernel/entry-common.S +++ b/trunk/arch/arm/kernel/entry-common.S @@ -269,6 +269,10 @@ sys_arm_fadvise64_64_wrapper: str r5, [sp, #4] @ push r5 to stack b sys_arm_fadvise64_64 +sys_mbind_wrapper: + str r5, [sp, #4] + b sys_mbind + /* * Note: off_4k (r5) is always units of 4K. If we can't do the requested * offset, we return EINVAL. diff --git a/trunk/arch/arm/mach-pxa/Kconfig b/trunk/arch/arm/mach-pxa/Kconfig index 405a55f2287c..3e5f69bb5ac4 100644 --- a/trunk/arch/arm/mach-pxa/Kconfig +++ b/trunk/arch/arm/mach-pxa/Kconfig @@ -20,40 +20,66 @@ config ARCH_PXA_IDP select PXA25x config PXA_SHARPSL - bool "SHARP SL-5600 and SL-C7xx Models" - select PXA25x + bool "SHARP Zaurus SL-5600, SL-C7xx and SL-Cxx00 Models" select SHARP_SCOOP select SHARP_PARAM help Say Y here if you intend to run this kernel on a - Sharp SL-5600 (Poodle), Sharp SL-C700 (Corgi), - SL-C750 (Shepherd) or a Sharp SL-C760 (Husky) - handheld computer. + Sharp Zaurus SL-5600 (Poodle), SL-C700 (Corgi), + SL-C750 (Shepherd), SL-C760 (Husky), SL-C1000 (Akita), + SL-C3000 (Spitz) or SL-C3100 (Borzoi) handheld computer. endchoice +if PXA_SHARPSL + +choice + prompt "Select target Sharp Zaurus device range" + +config PXA_SHARPSL_25x + bool "Sharp PXA25x models (SL-5600 and SL-C7xx)" + select PXA25x + +config PXA_SHARPSL_27x + bool "Sharp PXA270 models (SL-Cxx00)" + select PXA27x + +endchoice + +endif + endmenu config MACH_POODLE bool "Enable Sharp SL-5600 (Poodle) Support" - depends PXA_SHARPSL + depends PXA_SHARPSL_25x select SHARP_LOCOMO config MACH_CORGI bool "Enable Sharp SL-C700 (Corgi) Support" - depends PXA_SHARPSL + depends PXA_SHARPSL_25x select PXA_SHARP_C7xx config MACH_SHEPHERD bool "Enable Sharp SL-C750 (Shepherd) Support" - depends PXA_SHARPSL + depends PXA_SHARPSL_25x select PXA_SHARP_C7xx config MACH_HUSKY bool "Enable Sharp SL-C760 (Husky) Support" - depends PXA_SHARPSL + depends PXA_SHARPSL_25x select PXA_SHARP_C7xx +config MACH_SPITZ + bool "Enable Sharp Zaurus SL-3000 (Spitz) Support" + depends PXA_SHARPSL_27x + select PXA_SHARP_Cxx00 + +config MACH_BORZOI + bool "Enable Sharp Zaurus SL-3100 (Borzoi) Support" + depends PXA_SHARPSL_27x + select PXA_SHARP_Cxx00 + config PXA25x bool help @@ -74,4 +100,9 @@ config PXA_SHARP_C7xx help Enable support for all Sharp C7xx models +config PXA_SHARP_Cxx00 + bool + help + Enable common support for Sharp Cxx00 models + endif diff --git a/trunk/arch/arm/mach-pxa/Makefile b/trunk/arch/arm/mach-pxa/Makefile index 33dae99ec2d8..f609a0f232cb 100644 --- a/trunk/arch/arm/mach-pxa/Makefile +++ b/trunk/arch/arm/mach-pxa/Makefile @@ -12,6 +12,7 @@ obj-$(CONFIG_ARCH_LUBBOCK) += lubbock.o obj-$(CONFIG_MACH_MAINSTONE) += mainstone.o obj-$(CONFIG_ARCH_PXA_IDP) += idp.o obj-$(CONFIG_PXA_SHARP_C7xx) += corgi.o corgi_ssp.o corgi_lcd.o ssp.o +obj-$(CONFIG_PXA_SHARP_Cxx00) += spitz.o corgi_ssp.o corgi_lcd.o ssp.o obj-$(CONFIG_MACH_POODLE) += poodle.o # Support for blinky lights diff --git a/trunk/arch/arm/mach-pxa/corgi.c b/trunk/arch/arm/mach-pxa/corgi.c index 29185acdd9e1..426c2bc517eb 100644 --- a/trunk/arch/arm/mach-pxa/corgi.c +++ b/trunk/arch/arm/mach-pxa/corgi.c @@ -41,6 +41,7 @@ #include #include "generic.h" +#include "sharpsl.h" /* @@ -94,14 +95,30 @@ struct platform_device corgissp_device = { .id = -1, }; +struct corgissp_machinfo corgi_ssp_machinfo = { + .port = 1, + .cs_lcdcon = CORGI_GPIO_LCDCON_CS, + .cs_ads7846 = CORGI_GPIO_ADS7846_CS, + .cs_max1111 = CORGI_GPIO_MAX1111_CS, + .clk_lcdcon = 76, + .clk_ads7846 = 2, + .clk_max1111 = 8, +}; + /* * Corgi Backlight Device */ +static struct corgibl_machinfo corgi_bl_machinfo = { + .max_intensity = 0x2f, + .set_bl_intensity = corgi_bl_set_intensity, +}; + static struct platform_device corgibl_device = { .name = "corgi-bl", .dev = { .parent = &corgifb_device.dev, + .platform_data = &corgi_bl_machinfo, }, .id = -1, }; @@ -119,39 +136,41 @@ static struct platform_device corgikbd_device = { /* * Corgi Touch Screen Device */ +static struct resource corgits_resources[] = { + [0] = { + .start = CORGI_IRQ_GPIO_TP_INT, + .end = CORGI_IRQ_GPIO_TP_INT, + .flags = IORESOURCE_IRQ, + }, +}; + +static struct corgits_machinfo corgi_ts_machinfo = { + .get_hsync_len = corgi_get_hsync_len, + .put_hsync = corgi_put_hsync, + .wait_hsync = corgi_wait_hsync, +}; + static struct platform_device corgits_device = { .name = "corgi-ts", .dev = { .parent = &corgissp_device.dev, + .platform_data = &corgi_ts_machinfo, }, .id = -1, + .num_resources = ARRAY_SIZE(corgits_resources), + .resource = corgits_resources, }; /* * MMC/SD Device * - * The card detect interrupt isn't debounced so we delay it by HZ/4 + * The card detect interrupt isn't debounced so we delay it by 250ms * to give the card a chance to fully insert/eject. */ -static struct mmc_detect { - struct timer_list detect_timer; - void *devid; -} mmc_detect; - -static void mmc_detect_callback(unsigned long data) -{ - mmc_detect_change(mmc_detect.devid); -} +static struct pxamci_platform_data corgi_mci_platform_data; -static irqreturn_t corgi_mmc_detect_int(int irq, void *devid, struct pt_regs *regs) -{ - mmc_detect.devid=devid; - mod_timer(&mmc_detect.detect_timer, jiffies + HZ/4); - return IRQ_HANDLED; -} - -static int corgi_mci_init(struct device *dev, irqreturn_t (*unused_detect_int)(int, void *, struct pt_regs *), void *data) +static int corgi_mci_init(struct device *dev, irqreturn_t (*corgi_detect_int)(int, void *, struct pt_regs *), void *data) { int err; @@ -161,11 +180,9 @@ static int corgi_mci_init(struct device *dev, irqreturn_t (*unused_detect_int)(i pxa_gpio_mode(CORGI_GPIO_nSD_DETECT | GPIO_IN); pxa_gpio_mode(CORGI_GPIO_SD_PWR | GPIO_OUT); - init_timer(&mmc_detect.detect_timer); - mmc_detect.detect_timer.function = mmc_detect_callback; - mmc_detect.detect_timer.data = (unsigned long) &mmc_detect; + corgi_mci_platform_data.detect_delay = msecs_to_jiffies(250); - err = request_irq(CORGI_IRQ_GPIO_nSD_DETECT, corgi_mmc_detect_int, SA_INTERRUPT, + err = request_irq(CORGI_IRQ_GPIO_nSD_DETECT, corgi_detect_int, SA_INTERRUPT, "MMC card detect", data); if (err) { printk(KERN_ERR "corgi_mci_init: MMC/SD: can't request MMC card detect IRQ\n"); @@ -198,7 +215,6 @@ static int corgi_mci_get_ro(struct device *dev) static void corgi_mci_exit(struct device *dev, void *data) { free_irq(CORGI_IRQ_GPIO_nSD_DETECT, data); - del_timer(&mmc_detect.detect_timer); } static struct pxamci_platform_data corgi_mci_platform_data = { @@ -243,7 +259,10 @@ static struct platform_device *devices[] __initdata = { static void __init corgi_init(void) { + corgi_ssp_set_machinfo(&corgi_ssp_machinfo); + pxa_gpio_mode(CORGI_GPIO_USB_PULLUP | GPIO_OUT); + pxa_gpio_mode(CORGI_GPIO_HSYNC | GPIO_IN); pxa_set_udc_info(&udc_info); pxa_set_mci_info(&corgi_mci_platform_data); diff --git a/trunk/arch/arm/mach-pxa/corgi_lcd.c b/trunk/arch/arm/mach-pxa/corgi_lcd.c index deac29c00290..c5efcd04fcbc 100644 --- a/trunk/arch/arm/mach-pxa/corgi_lcd.c +++ b/trunk/arch/arm/mach-pxa/corgi_lcd.c @@ -1,10 +1,14 @@ /* * linux/drivers/video/w100fb.c * - * Corgi LCD Specific Code for ATI Imageon w100 (Wallaby) + * Corgi/Spitz LCD Specific Code * * Copyright (C) 2005 Richard Purdie * + * Connectivity: + * Corgi - LCD to ATI Imageon w100 (Wallaby) + * Spitz - LCD to PXA Framebuffer + * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. @@ -14,9 +18,17 @@ #include #include #include +#include +#include +#include #include +#include +#include +#include +#include +#include #include -#include