From 311aab73d273eb22be976055f6cab224f7279d5e Mon Sep 17 00:00:00 2001 From: Colin Cross Date: Mon, 8 Aug 2011 23:39:36 +0200 Subject: PM / Runtime: Add might_sleep() to runtime PM functions Some of the entry points to pm runtime are not safe to call in atomic context unless pm_runtime_irq_safe() has been called. Inspecting the code, it is not immediately obvious that the functions sleep at all, as they run inside a spin_lock_irqsave, but under some conditions they can drop the lock and turn on irqs. If a driver incorrectly calls the pm_runtime apis, it can cause sleeping and irq processing when it expects to stay in atomic context. Add might_sleep_if to the majority of the __pm_runtime_* entry points to enforce correct usage. Add pm_runtime_put_sync_autosuspend to the list of functions that can be called in atomic context. Signed-off-by: Colin Cross Reviewed-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki --- Documentation/power/runtime_pm.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation/power') diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 4ce5450ab6e8..62f37bc3866f 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -484,6 +484,7 @@ pm_runtime_resume() pm_runtime_get_sync() pm_runtime_put_sync() pm_runtime_put_sync_suspend() +pm_runtime_put_sync_autosuspend() 5. Runtime PM Initialization, Device Probing and Removal -- cgit 1.4.1 From 2e6ba515f50ef7ddf35b2703d014d3216c9b8b24 Mon Sep 17 00:00:00 2001 From: Ming Lei Date: Wed, 21 Sep 2011 22:31:33 +0200 Subject: PM / Runtime: pm_runtime_idle() can be called in atomic context Add to pm_runtime_idle the list of functions that can be called in atomic context if pm_runtime_irq_safe() has been called for the device. Signed-off-by: Ming Lei Signed-off-by: Rafael J. Wysocki --- Documentation/power/runtime_pm.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation/power') diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 62f37bc3866f..1750740b17e8 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -478,6 +478,7 @@ pm_runtime_autosuspend_expiration() If pm_runtime_irq_safe() has been called for a device then the following helper functions may also be used in interrupt context: +pm_runtime_idle() pm_runtime_suspend() pm_runtime_autosuspend() pm_runtime_resume() -- cgit 1.4.1 From 395cf9691d72173d8cdaa613c5f0255f993af94b Mon Sep 17 00:00:00 2001 From: Paul Bolle Date: Mon, 15 Aug 2011 02:02:26 +0200 Subject: doc: fix broken references There are numerous broken references to Documentation files (in other Documentation files, in comments, etc.). These broken references are caused by typo's in the references, and by renames or removals of the Documentation files. Some broken references are simply odd. Fix these broken references, sometimes by dropping the irrelevant text they were part of. Signed-off-by: Paul Bolle Signed-off-by: Jiri Kosina --- Documentation/PCI/pci.txt | 2 +- Documentation/blackfin/bfin-gpio-notes.txt | 2 +- Documentation/block/biodoc.txt | 2 +- Documentation/bus-virt-phys-mapping.txt | 2 +- Documentation/cdrom/packet-writing.txt | 2 +- Documentation/development-process/4.Coding | 2 +- Documentation/devicetree/bindings/gpio/led.txt | 2 +- Documentation/filesystems/caching/object.txt | 6 +++--- Documentation/filesystems/locks.txt | 11 ++++++----- Documentation/filesystems/nfs/idmapper.txt | 2 +- Documentation/filesystems/pohmelfs/design_notes.txt | 5 +++-- Documentation/filesystems/proc.txt | 2 +- Documentation/filesystems/vfs.txt | 3 --- Documentation/frv/booting.txt | 6 ------ Documentation/input/input.txt | 2 +- Documentation/kernel-docs.txt | 4 ++-- Documentation/kernel-parameters.txt | 12 ++++++------ Documentation/laptops/thinkpad-acpi.txt | 4 ++-- Documentation/media-framework.txt | 4 ++-- Documentation/memory-barriers.txt | 2 +- Documentation/networking/scaling.txt | 2 +- Documentation/power/basic-pm-debugging.txt | 2 +- Documentation/power/userland-swsusp.txt | 3 ++- Documentation/rfkill.txt | 3 +-- Documentation/scsi/aic7xxx_old.txt | 2 +- Documentation/scsi/scsi_mid_low_api.txt | 5 ----- Documentation/security/keys-trusted-encrypted.txt | 3 ++- Documentation/sound/oss/PAS16 | 3 +-- Documentation/spi/pxa2xx | 4 ++-- Documentation/timers/highres.txt | 2 +- Documentation/usb/dma.txt | 6 +++--- Documentation/virtual/lguest/lguest.c | 2 +- Documentation/vm/numa | 4 ++-- Documentation/vm/slub.txt | 2 +- arch/alpha/kernel/srm_env.c | 5 ++--- arch/arm/Kconfig | 2 +- arch/arm/include/asm/io.h | 2 +- arch/arm/mach-pxa/xcep.c | 3 +-- arch/ia64/hp/common/sba_iommu.c | 12 ++++++------ arch/m68k/q40/README | 2 +- arch/microblaze/include/asm/dma-mapping.h | 2 +- arch/mips/include/asm/lasat/lasat.h | 6 ++---- arch/mn10300/Kconfig | 2 +- arch/mn10300/kernel/irq.c | 1 - arch/openrisc/Kconfig | 2 +- arch/openrisc/include/asm/dma-mapping.h | 2 +- arch/parisc/include/asm/dma-mapping.h | 2 +- arch/parisc/kernel/pci-dma.c | 2 +- arch/powerpc/include/asm/qe.h | 2 +- arch/powerpc/sysdev/qe_lib/qe.c | 2 +- arch/unicore32/include/asm/io.h | 2 +- arch/x86/Kconfig | 2 +- arch/x86/Kconfig.debug | 2 +- arch/x86/boot/header.S | 2 +- arch/x86/include/asm/dma-mapping.h | 2 +- arch/x86/kernel/amd_gart_64.c | 2 +- arch/x86/kernel/apm_32.c | 2 -- arch/x86/kernel/pci-dma.c | 4 ++-- drivers/char/apm-emulation.c | 5 +---- drivers/input/misc/rotary_encoder.c | 2 +- drivers/leds/Kconfig | 2 +- drivers/media/dvb/dvb-usb/af9005-remote.c | 2 +- drivers/media/dvb/dvb-usb/af9005.c | 2 +- drivers/media/dvb/frontends/dib3000.h | 2 +- drivers/media/dvb/frontends/dib3000mb.c | 2 +- drivers/mtd/Kconfig | 2 +- drivers/net/Kconfig | 3 +-- drivers/net/can/sja1000/sja1000_of_platform.c | 2 +- drivers/net/tulip/21142.c | 3 --- drivers/net/tulip/eeprom.c | 2 -- drivers/net/tulip/interrupt.c | 3 --- drivers/net/tulip/media.c | 3 --- drivers/net/tulip/pnic.c | 3 --- drivers/net/tulip/pnic2.c | 3 --- drivers/net/tulip/timer.c | 3 --- drivers/net/tulip/tulip.h | 3 --- drivers/net/tulip/tulip_core.c | 3 --- drivers/parisc/sba_iommu.c | 16 ++++++++-------- drivers/platform/x86/Kconfig | 5 +---- drivers/scsi/megaraid/megaraid_mbox.c | 2 +- drivers/staging/cxt1e1/Kconfig | 3 +-- drivers/usb/serial/digi_acceleport.c | 2 +- drivers/video/igafb.c | 2 +- drivers/watchdog/smsc37b787_wdt.c | 2 +- fs/configfs/inode.c | 3 ++- fs/configfs/item.c | 2 +- fs/locks.c | 2 +- fs/squashfs/Kconfig | 6 +++--- include/linux/io-mapping.h | 2 +- include/linux/isdn.h | 2 +- include/linux/platform_data/ntc_thermistor.h | 2 +- include/media/videobuf-dma-sg.h | 2 +- include/target/configfs_macros.h | 4 ++-- net/netfilter/Kconfig | 2 +- sound/oss/Kconfig | 4 +--- tools/perf/util/config.c | 4 ++-- 96 files changed, 125 insertions(+), 179 deletions(-) (limited to 'Documentation/power') diff --git a/Documentation/PCI/pci.txt b/Documentation/PCI/pci.txt index 6148d4080f88..aa09e5476bba 100644 --- a/Documentation/PCI/pci.txt +++ b/Documentation/PCI/pci.txt @@ -314,7 +314,7 @@ from the PCI device config space. Use the values in the pci_dev structure as the PCI "bus address" might have been remapped to a "host physical" address by the arch/chip-set specific kernel support. -See Documentation/IO-mapping.txt for how to access device registers +See Documentation/io-mapping.txt for how to access device registers or device memory. The device driver needs to call pci_request_region() to verify diff --git a/Documentation/blackfin/bfin-gpio-notes.txt b/Documentation/blackfin/bfin-gpio-notes.txt index f731c1e56475..d36b01f778b9 100644 --- a/Documentation/blackfin/bfin-gpio-notes.txt +++ b/Documentation/blackfin/bfin-gpio-notes.txt @@ -1,5 +1,5 @@ /* - * File: Documentation/blackfin/bfin-gpio-note.txt + * File: Documentation/blackfin/bfin-gpio-notes.txt * Based on: * Author: * diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index c6d84cfd2f56..e418dc0a7086 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -186,7 +186,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address do not have a corresponding kernel virtual address space mapping) and low-memory pages. -Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion +Note: Please refer to Documentation/DMA-API-HOWTO.txt for a discussion on PCI high mem DMA aspects and mapping of scatter gather lists, and support for 64 bit PCI. diff --git a/Documentation/bus-virt-phys-mapping.txt b/Documentation/bus-virt-phys-mapping.txt index 1b5aa10df845..2bc55ff3b4d1 100644 --- a/Documentation/bus-virt-phys-mapping.txt +++ b/Documentation/bus-virt-phys-mapping.txt @@ -1,6 +1,6 @@ [ NOTE: The virt_to_bus() and bus_to_virt() functions have been superseded by the functionality provided by the PCI DMA interface - (see Documentation/PCI/PCI-DMA-mapping.txt). They continue + (see Documentation/DMA-API-HOWTO.txt). They continue to be documented below for historical purposes, but new code must not use them. --davidm 00/12/12 ] diff --git a/Documentation/cdrom/packet-writing.txt b/Documentation/cdrom/packet-writing.txt index 13c251d5add6..2834170d821e 100644 --- a/Documentation/cdrom/packet-writing.txt +++ b/Documentation/cdrom/packet-writing.txt @@ -109,7 +109,7 @@ this interface. (see http://tom.ist-im-web.de/download/pktcdvd ) For a description of the sysfs interface look into the file: - Documentation/ABI/testing/sysfs-block-pktcdvd + Documentation/ABI/testing/sysfs-class-pktcdvd Using the pktcdvd debugfs interface diff --git a/Documentation/development-process/4.Coding b/Documentation/development-process/4.Coding index 83f5f5b365a3..e3cb6a56653a 100644 --- a/Documentation/development-process/4.Coding +++ b/Documentation/development-process/4.Coding @@ -278,7 +278,7 @@ enabled, a configurable percentage of memory allocations will be made to fail; these failures can be restricted to a specific range of code. Running with fault injection enabled allows the programmer to see how the code responds when things go badly. See -Documentation/fault-injection/fault-injection.text for more information on +Documentation/fault-injection/fault-injection.txt for more information on how to use this facility. Other kinds of errors can be found with the "sparse" static analysis tool. diff --git a/Documentation/devicetree/bindings/gpio/led.txt b/Documentation/devicetree/bindings/gpio/led.txt index 064db928c3c1..141087cf3107 100644 --- a/Documentation/devicetree/bindings/gpio/led.txt +++ b/Documentation/devicetree/bindings/gpio/led.txt @@ -8,7 +8,7 @@ node's name represents the name of the corresponding LED. LED sub-node properties: - gpios : Should specify the LED's GPIO, see "Specifying GPIO information - for devices" in Documentation/powerpc/booting-without-of.txt. Active + for devices" in Documentation/devicetree/booting-without-of.txt. Active low LEDs should be indicated using flags in the GPIO specifier. - label : (optional) The label for this LED. If omitted, the label is taken from the node name (excluding the unit address). diff --git a/Documentation/filesystems/caching/object.txt b/Documentation/filesystems/caching/object.txt index e8b0a35d8fe5..58313348da87 100644 --- a/Documentation/filesystems/caching/object.txt +++ b/Documentation/filesystems/caching/object.txt @@ -127,9 +127,9 @@ fscache_enqueue_object()). PROVISION OF CPU TIME --------------------- -The work to be done by the various states is given CPU time by the threads of -the slow work facility (see Documentation/slow-work.txt). This is used in -preference to the workqueue facility because: +The work to be done by the various states was given CPU time by the threads of +the slow work facility. This was used in preference to the workqueue facility +because: (1) Threads may be completely occupied for very long periods of time by a particular work item. These state actions may be doing sequences of diff --git a/Documentation/filesystems/locks.txt b/Documentation/filesystems/locks.txt index fab857accbd6..2cf81082581d 100644 --- a/Documentation/filesystems/locks.txt +++ b/Documentation/filesystems/locks.txt @@ -53,11 +53,12 @@ fcntl(), with all the problems that implies. 1.3 Mandatory Locking As A Mount Option --------------------------------------- -Mandatory locking, as described in 'Documentation/filesystems/mandatory.txt' -was prior to this release a general configuration option that was valid for -all mounted filesystems. This had a number of inherent dangers, not the -least of which was the ability to freeze an NFS server by asking it to read -a file for which a mandatory lock existed. +Mandatory locking, as described in +'Documentation/filesystems/mandatory-locking.txt' was prior to this release a +general configuration option that was valid for all mounted filesystems. This +had a number of inherent dangers, not the least of which was the ability to +freeze an NFS server by asking it to read a file for which a mandatory lock +existed. From this release of the kernel, mandatory locking can be turned on and off on a per-filesystem basis, using the mount options 'mand' and 'nomand'. diff --git a/Documentation/filesystems/nfs/idmapper.txt b/Documentation/filesystems/nfs/idmapper.txt index 9c8fd6148656..120fd3cf7fd9 100644 --- a/Documentation/filesystems/nfs/idmapper.txt +++ b/Documentation/filesystems/nfs/idmapper.txt @@ -47,7 +47,7 @@ request-key will find the first matching line and corresponding program. In this case, /some/other/program will handle all uid lookups and /usr/sbin/nfs.idmap will handle gid, user, and group lookups. -See for more information +See for more information about the request-key function. diff --git a/Documentation/filesystems/pohmelfs/design_notes.txt b/Documentation/filesystems/pohmelfs/design_notes.txt index dcf833587162..8aef91335701 100644 --- a/Documentation/filesystems/pohmelfs/design_notes.txt +++ b/Documentation/filesystems/pohmelfs/design_notes.txt @@ -58,8 +58,9 @@ data transfers. POHMELFS clients operate with a working set of servers and are capable of balancing read-only operations (like lookups or directory listings) between them according to IO priorities. Administrators can add or remove servers from the set at run-time via special commands (described -in Documentation/pohmelfs/info.txt file). Writes are replicated to all servers, which are connected -with write permission turned on. IO priority and permissions can be changed in run-time. +in Documentation/filesystems/pohmelfs/info.txt file). Writes are replicated to all servers, which +are connected with write permission turned on. IO priority and permissions can be changed in +run-time. POHMELFS is capable of full data channel encryption and/or strong crypto hashing. One can select any kernel supported cipher, encryption mode, hash type and operation mode diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index db3b1aba32a3..0ec91f03422e 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -1263,7 +1263,7 @@ review the kernel documentation in the directory /usr/src/linux/Documentation. This chapter is heavily based on the documentation included in the pre 2.2 kernels, and became part of it in version 2.2.1 of the Linux kernel. -Please see: Documentation/sysctls/ directory for descriptions of these +Please see: Documentation/sysctl/ directory for descriptions of these entries. ------------------------------------------------------------------------------ diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 52d8fb81cfff..43cbd0821721 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -1053,9 +1053,6 @@ manipulate dentries: and the dentry is returned. The caller must use dput() to free the dentry when it finishes using it. -For further information on dentry locking, please refer to the document -Documentation/filesystems/dentry-locking.txt. - Mount Options ============= diff --git a/Documentation/frv/booting.txt b/Documentation/frv/booting.txt index 37c4d84a0e57..9bdf4b46e741 100644 --- a/Documentation/frv/booting.txt +++ b/Documentation/frv/booting.txt @@ -180,9 +180,3 @@ separated by spaces: This tells the kernel what program to run initially. By default this is /sbin/init, but /sbin/sash or /bin/sh are common alternatives. - - (*) vdc=... - - This option configures the MB93493 companion chip visual display - driver. Please see Documentation/frv/mb93493/vdc.txt for more - information. diff --git a/Documentation/input/input.txt b/Documentation/input/input.txt index b93c08442e3c..b3d6787b4fb1 100644 --- a/Documentation/input/input.txt +++ b/Documentation/input/input.txt @@ -111,7 +111,7 @@ LCDs and many other purposes. The monitor and speaker controls should be easy to add to the hid/input interface, but for the UPSs and LCDs it doesn't make much sense. For this, -the hiddev interface was designed. See Documentation/usb/hiddev.txt +the hiddev interface was designed. See Documentation/hid/hiddev.txt for more information about it. The usage of the usbhid module is very simple, it takes no parameters, diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt index 0e0734b509d8..eda1eb1451a0 100644 --- a/Documentation/kernel-docs.txt +++ b/Documentation/kernel-docs.txt @@ -300,7 +300,7 @@ * Title: "The Kernel Hacking HOWTO" Author: Various Talented People, and Rusty. - Location: in kernel tree, Documentation/DocBook/kernel-hacking/ + Location: in kernel tree, Documentation/DocBook/kernel-hacking.tmpl (must be built as "make {htmldocs | psdocs | pdfdocs}) Keywords: HOWTO, kernel contexts, deadlock, locking, modules, symbols, return conventions. @@ -351,7 +351,7 @@ * Title: "Linux Kernel Locking HOWTO" Author: Various Talented People, and Rusty. - Location: in kernel tree, Documentation/DocBook/kernel-locking/ + Location: in kernel tree, Documentation/DocBook/kernel-locking.tmpl (must be built as "make {htmldocs | psdocs | pdfdocs}) Keywords: locks, locking, spinlock, semaphore, atomic, race condition, bottom halves, tasklets, softirqs. diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 854ed5ca7e3f..be9370c764c8 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -163,7 +163,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. rsdt -- prefer RSDT over (default) XSDT copy_dsdt -- copy DSDT to memory - See also Documentation/power/pm.txt, pci=noacpi + See also Documentation/power/runtime_pm.txt, pci=noacpi acpi_rsdp= [ACPI,EFI,KEXEC] Pass the RSDP address to the kernel, mostly used @@ -319,7 +319,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. amijoy.map= [HW,JOY] Amiga joystick support Map of devices attached to JOY0DAT and JOY1DAT Format: , - See also Documentation/kernel/input/joystick.txt + See also Documentation/input/joystick.txt analog.map= [HW,JOY] Analog joystick and gamepad support Specifies type or capabilities of an analog joystick @@ -408,7 +408,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. bttv.radio= Most important insmod options are available as kernel args too. bttv.pll= See Documentation/video4linux/bttv/Insmod-options - bttv.tuner= and Documentation/video4linux/bttv/CARDLIST + bttv.tuner= bulk_remove=off [PPC] This parameter disables the use of the pSeries firmware feature for flushing multiple hpte entries @@ -724,7 +724,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. elevator= [IOSCHED] Format: {"cfq" | "deadline" | "noop"} - See Documentation/block/as-iosched.txt and + See Documentation/block/cfq-iosched.txt and Documentation/block/deadline-iosched.txt for details. elfcorehdr= [IA-64,PPC,SH,X86] @@ -765,7 +765,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. fail_make_request=[KNL] General fault injection mechanism. Format: ,,, - See also /Documentation/fault-injection/. + See also Documentation/fault-injection/. floppy= [HW] See Documentation/blockdev/floppy.txt. @@ -2375,7 +2375,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. Format: sonypi.*= [HW] Sony Programmable I/O Control Device driver - See Documentation/sonypi.txt + See Documentation/laptops/sonypi.txt specialix= [HW,SERIAL] Specialix multi-serial port adapter See Documentation/serial/specialix.txt. diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 61815483efa3..3ff0dad62d36 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -736,7 +736,7 @@ status as "unknown". The available commands are: sysfs notes: The ThinkLight sysfs interface is documented by the LED class -documentation, in Documentation/leds-class.txt. The ThinkLight LED name +documentation, in Documentation/leds/leds-class.txt. The ThinkLight LED name is "tpacpi::thinklight". Due to limitations in the sysfs LED class, if the status of the ThinkLight @@ -833,7 +833,7 @@ All of the above can be turned on and off and can be made to blink. sysfs notes: The ThinkPad LED sysfs interface is described in detail by the LED class -documentation, in Documentation/leds-class.txt. +documentation, in Documentation/leds/leds-class.txt. The LEDs are named (in LED ID order, from 0 to 12): "tpacpi::power", "tpacpi:orange:batt", "tpacpi:green:batt", diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt index 669b5fb03a86..3a0f879533ce 100644 --- a/Documentation/media-framework.txt +++ b/Documentation/media-framework.txt @@ -9,8 +9,8 @@ Introduction ------------ The media controller API is documented in DocBook format in -Documentation/DocBook/v4l/media-controller.xml. This document will focus on -the kernel-side implementation of the media framework. +Documentation/DocBook/media/v4l/media-controller.xml. This document will focus +on the kernel-side implementation of the media framework. Abstract media device model diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index f0d3a8026a56..2759f7c188f0 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -438,7 +438,7 @@ There are certain things that the Linux kernel memory barriers do not guarantee: [*] For information on bus mastering DMA and coherency please read: Documentation/PCI/pci.txt - Documentation/PCI/PCI-DMA-mapping.txt + Documentation/DMA-API-HOWTO.txt Documentation/DMA-API.txt diff --git a/Documentation/networking/scaling.txt b/Documentation/networking/scaling.txt index 58fd7414e6c0..729985ed05bd 100644 --- a/Documentation/networking/scaling.txt +++ b/Documentation/networking/scaling.txt @@ -73,7 +73,7 @@ of queues to IRQs can be determined from /proc/interrupts. By default, an IRQ may be handled on any CPU. Because a non-negligible part of packet processing takes place in receive interrupt handling, it is advantageous to spread receive interrupts between CPUs. To manually adjust the IRQ -affinity of each interrupt see Documentation/IRQ-affinity. Some systems +affinity of each interrupt see Documentation/IRQ-affinity.txt. Some systems will be running irqbalance, a daemon that dynamically optimizes IRQ assignments and as a result may override any manual settings. diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt index ddd78172ef73..05a7fe76232d 100644 --- a/Documentation/power/basic-pm-debugging.txt +++ b/Documentation/power/basic-pm-debugging.txt @@ -173,7 +173,7 @@ kernel messages using the serial console. This may provide you with some information about the reasons of the suspend (resume) failure. Alternatively, it may be possible to use a FireWire port for debugging with firescope (ftp://ftp.firstfloor.org/pub/ak/firescope/). On x86 it is also possible to -use the PM_TRACE mechanism documented in Documentation/s2ram.txt . +use the PM_TRACE mechanism documented in Documentation/power/s2ram.txt . 2. Testing suspend to RAM (STR) diff --git a/Documentation/power/userland-swsusp.txt b/Documentation/power/userland-swsusp.txt index 1101bee4e822..0e870825c1b9 100644 --- a/Documentation/power/userland-swsusp.txt +++ b/Documentation/power/userland-swsusp.txt @@ -77,7 +77,8 @@ SNAPSHOT_SET_SWAP_AREA - set the resume partition and the offset (in resume_swap_area, as defined in kernel/power/suspend_ioctls.h, containing the resume device specification and the offset); for swap partitions the offset is always 0, but it is different from zero for - swap files (see Documentation/swsusp-and-swap-files.txt for details). + swap files (see Documentation/power/swsusp-and-swap-files.txt for + details). SNAPSHOT_PLATFORM_SUPPORT - enable/disable the hibernation platform support, depending on the argument value (enable, if the argument is nonzero) diff --git a/Documentation/rfkill.txt b/Documentation/rfkill.txt index 83668e5dd17f..03c9d9299c6b 100644 --- a/Documentation/rfkill.txt +++ b/Documentation/rfkill.txt @@ -117,5 +117,4 @@ The contents of these variables corresponds to the "name", "state" and "type" sysfs files explained above. -For further details consult Documentation/ABI/stable/dev-rfkill and -Documentation/ABI/stable/sysfs-class-rfkill. +For further details consult Documentation/ABI/stable/sysfs-class-rfkill. diff --git a/Documentation/scsi/aic7xxx_old.txt b/Documentation/scsi/aic7xxx_old.txt index 7bd210ab45a1..ecfc474f36a8 100644 --- a/Documentation/scsi/aic7xxx_old.txt +++ b/Documentation/scsi/aic7xxx_old.txt @@ -444,7 +444,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD Kernel Compile options ------------------------------ The various kernel compile time options for this driver are now fairly - well documented in the file Documentation/Configure.help. In order to + well documented in the file drivers/scsi/Kconfig. In order to see this documentation, you need to use one of the advanced configuration programs (menuconfig and xconfig). If you are using the "make menuconfig" method of configuring your kernel, then you would simply highlight the diff --git a/Documentation/scsi/scsi_mid_low_api.txt b/Documentation/scsi/scsi_mid_low_api.txt index 5f17d29c59b5..a340b18cd4eb 100644 --- a/Documentation/scsi/scsi_mid_low_api.txt +++ b/Documentation/scsi/scsi_mid_low_api.txt @@ -55,11 +55,6 @@ or in the same directory as the C source code. For example to find a url about the USB mass storage driver see the /usr/src/linux/drivers/usb/storage directory. -The Linux kernel source Documentation/DocBook/scsidrivers.tmpl file -refers to this file. With the appropriate DocBook tool-set, this permits -users to generate html, ps and pdf renderings of information within this -file (e.g. the interface functions). - Driver structure ================ Traditionally an LLD for the SCSI subsystem has been at least two files in diff --git a/Documentation/security/keys-trusted-encrypted.txt b/Documentation/security/keys-trusted-encrypted.txt index 5f50ccabfc8a..c9e4855ed3d7 100644 --- a/Documentation/security/keys-trusted-encrypted.txt +++ b/Documentation/security/keys-trusted-encrypted.txt @@ -156,4 +156,5 @@ Load an encrypted key "evm" from saved blob: Other uses for trusted and encrypted keys, such as for disk and file encryption are anticipated. In particular the new format 'ecryptfs' has been defined in in order to use encrypted keys to mount an eCryptfs filesystem. More details -about the usage can be found in the file 'Documentation/keys-ecryptfs.txt'. +about the usage can be found in the file +'Documentation/security/keys-ecryptfs.txt'. diff --git a/Documentation/sound/oss/PAS16 b/Documentation/sound/oss/PAS16 index 951b3dce51b4..3dca4b75988e 100644 --- a/Documentation/sound/oss/PAS16 +++ b/Documentation/sound/oss/PAS16 @@ -60,8 +60,7 @@ With PAS16 you can use two audio device files at the same time. /dev/dsp (and The new stuff for 2.3.99 and later ============================================================================ -The following configuration options from Documentation/Configure.help -are relevant to configuring the PAS16: +The following configuration options are relevant to configuring the PAS16: Sound card support CONFIG_SOUND diff --git a/Documentation/spi/pxa2xx b/Documentation/spi/pxa2xx index 00511e08db78..3352f97430e4 100644 --- a/Documentation/spi/pxa2xx +++ b/Documentation/spi/pxa2xx @@ -2,7 +2,7 @@ PXA2xx SPI on SSP driver HOWTO =================================================== This a mini howto on the pxa2xx_spi driver. The driver turns a PXA2xx synchronous serial port into a SPI master controller -(see Documentation/spi/spi_summary). The driver has the following features +(see Documentation/spi/spi-summary). The driver has the following features - Support for any PXA2xx SSP - SSP PIO and SSP DMA data transfers. @@ -85,7 +85,7 @@ Declaring Slave Devices ----------------------- Typically each SPI slave (chip) is defined in the arch/.../mach-*/board-*.c using the "spi_board_info" structure found in "linux/spi/spi.h". See -"Documentation/spi/spi_summary" for additional information. +"Documentation/spi/spi-summary" for additional information. Each slave device attached to the PXA must provide slave specific configuration information via the structure "pxa2xx_spi_chip" found in diff --git a/Documentation/timers/highres.txt b/Documentation/timers/highres.txt index 21332233cef1..e8789976e77c 100644 --- a/Documentation/timers/highres.txt +++ b/Documentation/timers/highres.txt @@ -30,7 +30,7 @@ hrtimer base infrastructure --------------------------- The hrtimer base infrastructure was merged into the 2.6.16 kernel. Details of -the base implementation are covered in Documentation/hrtimers/hrtimer.txt. See +the base implementation are covered in Documentation/timers/hrtimers.txt. See also figure #2 (OLS slides p. 15) The main differences to the timer wheel, which holds the armed timer_list type diff --git a/Documentation/usb/dma.txt b/Documentation/usb/dma.txt index 84ef865237db..444651e70d95 100644 --- a/Documentation/usb/dma.txt +++ b/Documentation/usb/dma.txt @@ -7,7 +7,7 @@ API OVERVIEW The big picture is that USB drivers can continue to ignore most DMA issues, though they still must provide DMA-ready buffers (see -Documentation/PCI/PCI-DMA-mapping.txt). That's how they've worked through +Documentation/DMA-API-HOWTO.txt). That's how they've worked through the 2.4 (and earlier) kernels. OR: they can now be DMA-aware. @@ -57,7 +57,7 @@ and effects like cache-trashing can impose subtle penalties. force a consistent memory access ordering by using memory barriers. It's not using a streaming DMA mapping, so it's good for small transfers on systems where the I/O would otherwise thrash an IOMMU mapping. (See - Documentation/PCI/PCI-DMA-mapping.txt for definitions of "coherent" and + Documentation/DMA-API-HOWTO.txt for definitions of "coherent" and "streaming" DMA mappings.) Asking for 1/Nth of a page (as well as asking for N pages) is reasonably @@ -88,7 +88,7 @@ WORKING WITH EXISTING BUFFERS Existing buffers aren't usable for DMA without first being mapped into the DMA address space of the device. However, most buffers passed to your driver can safely be used with such DMA mapping. (See the first section -of Documentation/PCI/PCI-DMA-mapping.txt, titled "What memory is DMA-able?") +of Documentation/DMA-API-HOWTO.txt, titled "What memory is DMA-able?") - When you're using scatterlists, you can map everything at once. On some systems, this kicks in an IOMMU and turns the scatterlists into single diff --git a/Documentation/virtual/lguest/lguest.c b/Documentation/virtual/lguest/lguest.c index d928c134dee6..c095d79cae73 100644 --- a/Documentation/virtual/lguest/lguest.c +++ b/Documentation/virtual/lguest/lguest.c @@ -436,7 +436,7 @@ static unsigned long load_bzimage(int fd) /* * Go back to the start of the file and read the header. It should be - * a Linux boot header (see Documentation/x86/i386/boot.txt) + * a Linux boot header (see Documentation/x86/boot.txt) */ lseek(fd, 0, SEEK_SET); read(fd, &boot, sizeof(boot)); diff --git a/Documentation/vm/numa b/Documentation/vm/numa index a200a386429d..ade01274212d 100644 --- a/Documentation/vm/numa +++ b/Documentation/vm/numa @@ -109,11 +109,11 @@ to improve NUMA locality using various CPU affinity command line interfaces, such as taskset(1) and numactl(1), and program interfaces such as sched_setaffinity(2). Further, one can modify the kernel's default local allocation behavior using Linux NUMA memory policy. -[see Documentation/vm/numa_memory_policy.] +[see Documentation/vm/numa_memory_policy.txt.] System administrators can restrict the CPUs and nodes' memories that a non- privileged user can specify in the scheduling or NUMA commands and functions -using control groups and CPUsets. [see Documentation/cgroups/CPUsets.txt] +using control groups and CPUsets. [see Documentation/cgroups/cpusets.txt] On architectures that do not hide memoryless nodes, Linux will include only zones [nodes] with memory in the zonelists. This means that for a memoryless diff --git a/Documentation/vm/slub.txt b/Documentation/vm/slub.txt index 07375e73981a..f464f47bc60d 100644 --- a/Documentation/vm/slub.txt +++ b/Documentation/vm/slub.txt @@ -17,7 +17,7 @@ data and perform operation on the slabs. By default slabinfo only lists slabs that have data in them. See "slabinfo -h" for more options when running the command. slabinfo can be compiled with -gcc -o slabinfo Documentation/vm/slabinfo.c +gcc -o slabinfo tools/slub/slabinfo.c Some of the modes of operation of slabinfo require that slub debugging be enabled on the command line. F.e. no tracking information will be diff --git a/arch/alpha/kernel/srm_env.c b/arch/alpha/kernel/srm_env.c index f0df3fbd8402..b9fc6c309d2e 100644 --- a/arch/alpha/kernel/srm_env.c +++ b/arch/alpha/kernel/srm_env.c @@ -4,9 +4,8 @@ * * (C) 2001,2002,2006 by Jan-Benedict Glaw * - * This driver is at all a modified version of Erik Mouw's - * Documentation/DocBook/procfs_example.c, so: thank - * you, Erik! He can be reached via email at + * This driver is a modified version of Erik Mouw's example proc + * interface, so: thank you, Erik! He can be reached via email at * . It is based on an idea * provided by DEC^WCompaq^WIntel's "Jumpstart" CD. They * included a patch like this as well. Thanks for idea! diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 3269576dbfa8..05b53941b819 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1374,7 +1374,7 @@ config SMP processor machines. On a single processor machine, the kernel will run faster if you say N here. - See also , + See also , and the SMP-HOWTO available at . diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h index d66605dea55a..4bdb77bb5e62 100644 --- a/arch/arm/include/asm/io.h +++ b/arch/arm/include/asm/io.h @@ -238,7 +238,7 @@ extern void _memset_io(volatile void __iomem *, int, size_t); * ioremap and friends. * * ioremap takes a PCI memory address, as specified in - * Documentation/IO-mapping.txt. + * Documentation/io-mapping.txt. * */ #ifndef __arch_ioremap diff --git a/arch/arm/mach-pxa/xcep.c b/arch/arm/mach-pxa/xcep.c index acc600f5e72f..937c42845df9 100644 --- a/arch/arm/mach-pxa/xcep.c +++ b/arch/arm/mach-pxa/xcep.c @@ -142,8 +142,7 @@ static struct platform_device *devices[] __initdata = { /* We have to state that there are HWMON devices on the I2C bus on XCEP. * Drivers for HWMON verify capabilities of the adapter when loading and - * refuse to attach if the adapter doesn't support HWMON class of devices. - * See also Documentation/i2c/porting-clients. */ + * refuse to attach if the adapter doesn't support HWMON class of devices. */ static struct i2c_pxa_platform_data xcep_i2c_platform_data = { .class = I2C_CLASS_HWMON }; diff --git a/arch/ia64/hp/common/sba_iommu.c b/arch/ia64/hp/common/sba_iommu.c index 80241fe03f50..f5f4ef149aac 100644 --- a/arch/ia64/hp/common/sba_iommu.c +++ b/arch/ia64/hp/common/sba_iommu.c @@ -915,7 +915,7 @@ sba_mark_invalid(struct ioc *ioc, dma_addr_t iova, size_t byte_cnt) * @dir: R/W or both. * @attrs: optional dma attributes * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static dma_addr_t sba_map_page(struct device *dev, struct page *page, unsigned long poff, size_t size, @@ -1044,7 +1044,7 @@ sba_mark_clean(struct ioc *ioc, dma_addr_t iova, size_t size) * @dir: R/W or both. * @attrs: optional dma attributes * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static void sba_unmap_page(struct device *dev, dma_addr_t iova, size_t size, enum dma_data_direction dir, struct dma_attrs *attrs) @@ -1127,7 +1127,7 @@ void sba_unmap_single_attrs(struct device *dev, dma_addr_t iova, size_t size, * @size: number of bytes mapped in driver buffer. * @dma_handle: IOVA of new buffer. * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static void * sba_alloc_coherent (struct device *dev, size_t size, dma_addr_t *dma_handle, gfp_t flags) @@ -1190,7 +1190,7 @@ sba_alloc_coherent (struct device *dev, size_t size, dma_addr_t *dma_handle, gfp * @vaddr: virtual address IOVA of "consistent" buffer. * @dma_handler: IO virtual address of "consistent" buffer. * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static void sba_free_coherent (struct device *dev, size_t size, void *vaddr, dma_addr_t dma_handle) @@ -1453,7 +1453,7 @@ static void sba_unmap_sg_attrs(struct device *dev, struct scatterlist *sglist, * @dir: R/W or both. * @attrs: optional dma attributes * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static int sba_map_sg_attrs(struct device *dev, struct scatterlist *sglist, int nents, enum dma_data_direction dir, @@ -1549,7 +1549,7 @@ static int sba_map_sg_attrs(struct device *dev, struct scatterlist *sglist, * @dir: R/W or both. * @attrs: optional dma attributes * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static void sba_unmap_sg_attrs(struct device *dev, struct scatterlist *sglist, int nents, enum dma_data_direction dir, diff --git a/arch/m68k/q40/README b/arch/m68k/q40/README index b26d5f55e91d..93f4c4cd3c45 100644 --- a/arch/m68k/q40/README +++ b/arch/m68k/q40/README @@ -31,7 +31,7 @@ drivers used by the Q40, apart from the very obvious (console etc.): char/joystick/* # most of this should work, not # in default config.in block/q40ide.c # startup for ide - ide* # see Documentation/ide.txt + ide* # see Documentation/ide/ide.txt floppy.c # normal PC driver, DMA emu in asm/floppy.h # and arch/m68k/kernel/entry.S # see drivers/block/README.fd diff --git a/arch/microblaze/include/asm/dma-mapping.h b/arch/microblaze/include/asm/dma-mapping.h index 8fbb0ec10233..a569514cf19f 100644 --- a/arch/microblaze/include/asm/dma-mapping.h +++ b/arch/microblaze/include/asm/dma-mapping.h @@ -16,7 +16,7 @@ #define _ASM_MICROBLAZE_DMA_MAPPING_H /* - * See Documentation/PCI/PCI-DMA-mapping.txt and + * See Documentation/DMA-API-HOWTO.txt and * Documentation/DMA-API.txt for documentation. */ diff --git a/arch/mips/include/asm/lasat/lasat.h b/arch/mips/include/asm/lasat/lasat.h index a1ada1c27c16..e8ff70f80e13 100644 --- a/arch/mips/include/asm/lasat/lasat.h +++ b/arch/mips/include/asm/lasat/lasat.h @@ -41,10 +41,8 @@ enum lasat_mtdparts { /* * The format of the data record in the EEPROM. - * See Documentation/LASAT/eeprom.txt for a detailed description - * of the fields in this struct, and the LASAT Hardware Configuration - * field specification for a detailed description of the config - * field. + * See the LASAT Hardware Configuration field specification for a detailed + * description of the config field. */ #include diff --git a/arch/mn10300/Kconfig b/arch/mn10300/Kconfig index 1f870340ebdd..f093b3a8a4a1 100644 --- a/arch/mn10300/Kconfig +++ b/arch/mn10300/Kconfig @@ -195,7 +195,7 @@ config SMP singleprocessor machines. On a singleprocessor machine, the kernel will run faster if you say N here. - See also , + See also , and the SMP-HOWTO available at . diff --git a/arch/mn10300/kernel/irq.c b/arch/mn10300/kernel/irq.c index 2623d19f4f4c..2381df83bd00 100644 --- a/arch/mn10300/kernel/irq.c +++ b/arch/mn10300/kernel/irq.c @@ -260,7 +260,6 @@ void set_intr_level(int irq, u16 level) /* * mark an interrupt to be ACK'd after interrupt handlers have been run rather * than before - * - see Documentation/mn10300/features.txt */ void mn10300_set_lateack_irq_type(int irq) { diff --git a/arch/openrisc/Kconfig b/arch/openrisc/Kconfig index 4558bafbd1a2..9460e1c266dd 100644 --- a/arch/openrisc/Kconfig +++ b/arch/openrisc/Kconfig @@ -1,6 +1,6 @@ # # For a description of the syntax of this configuration file, -# see Documentation/kbuild/config-language.txt. +# see Documentation/kbuild/kconfig-language.txt. # config OPENRISC diff --git a/arch/openrisc/include/asm/dma-mapping.h b/arch/openrisc/include/asm/dma-mapping.h index 60b472233900..b206ba4608b2 100644 --- a/arch/openrisc/include/asm/dma-mapping.h +++ b/arch/openrisc/include/asm/dma-mapping.h @@ -18,7 +18,7 @@ #define __ASM_OPENRISC_DMA_MAPPING_H /* - * See Documentation/PCI/PCI-DMA-mapping.txt and + * See Documentation/DMA-API-HOWTO.txt and * Documentation/DMA-API.txt for documentation. * * This file is written with the intention of eventually moving over diff --git a/arch/parisc/include/asm/dma-mapping.h b/arch/parisc/include/asm/dma-mapping.h index 890531e32fe8..467bbd510eac 100644 --- a/arch/parisc/include/asm/dma-mapping.h +++ b/arch/parisc/include/asm/dma-mapping.h @@ -5,7 +5,7 @@ #include #include -/* See Documentation/PCI/PCI-DMA-mapping.txt */ +/* See Documentation/DMA-API-HOWTO.txt */ struct hppa_dma_ops { int (*dma_supported)(struct device *dev, u64 mask); void *(*alloc_consistent)(struct device *dev, size_t size, dma_addr_t *iova, gfp_t flag); diff --git a/arch/parisc/kernel/pci-dma.c b/arch/parisc/kernel/pci-dma.c index a029f74a3c5c..d047edea2504 100644 --- a/arch/parisc/kernel/pci-dma.c +++ b/arch/parisc/kernel/pci-dma.c @@ -2,7 +2,7 @@ ** PARISC 1.1 Dynamic DMA mapping support. ** This implementation is for PA-RISC platforms that do not support ** I/O TLBs (aka DMA address translation hardware). -** See Documentation/PCI/PCI-DMA-mapping.txt for interface definitions. +** See Documentation/DMA-API-HOWTO.txt for interface definitions. ** ** (c) Copyright 1999,2000 Hewlett-Packard Company ** (c) Copyright 2000 Grant Grundler diff --git a/arch/powerpc/include/asm/qe.h b/arch/powerpc/include/asm/qe.h index 0947b36e534c..5e0b6d511e14 100644 --- a/arch/powerpc/include/asm/qe.h +++ b/arch/powerpc/include/asm/qe.h @@ -196,7 +196,7 @@ static inline int qe_alive_during_sleep(void) /* Structure that defines QE firmware binary files. * - * See Documentation/powerpc/qe-firmware.txt for a description of these + * See Documentation/powerpc/qe_firmware.txt for a description of these * fields. */ struct qe_firmware { diff --git a/arch/powerpc/sysdev/qe_lib/qe.c b/arch/powerpc/sysdev/qe_lib/qe.c index 904c6cbaf45b..3363fbc964f8 100644 --- a/arch/powerpc/sysdev/qe_lib/qe.c +++ b/arch/powerpc/sysdev/qe_lib/qe.c @@ -382,7 +382,7 @@ static void qe_upload_microcode(const void *base, /* * Upload a microcode to the I-RAM at a specific address. * - * See Documentation/powerpc/qe-firmware.txt for information on QE microcode + * See Documentation/powerpc/qe_firmware.txt for information on QE microcode * uploading. * * Currently, only version 1 is supported, so the 'version' field must be diff --git a/arch/unicore32/include/asm/io.h b/arch/unicore32/include/asm/io.h index 4bd87f3d13d4..1a5c5a5eb39c 100644 --- a/arch/unicore32/include/asm/io.h +++ b/arch/unicore32/include/asm/io.h @@ -32,7 +32,7 @@ extern void __uc32_iounmap(volatile void __iomem *addr); * ioremap and friends. * * ioremap takes a PCI memory address, as specified in - * Documentation/IO-mapping.txt. + * Documentation/io-mapping.txt. * */ #define ioremap(cookie, size) __uc32_ioremap(cookie, size) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 6a47bb22657f..9a4a267a8a55 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -279,7 +279,7 @@ config SMP Y to "Enhanced Real Time Clock Support", below. The "Advanced Power Management" code will be disabled if you say Y here. - See also , + See also , and the SMP-HOWTO available at . diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug index c0f8a5c88910..bf56e1793272 100644 --- a/arch/x86/Kconfig.debug +++ b/arch/x86/Kconfig.debug @@ -139,7 +139,7 @@ config IOMMU_DEBUG code. When you use it make sure you have a big enough IOMMU/AGP aperture. Most of the options enabled by this can be set more finegrained using the iommu= command line - options. See Documentation/x86_64/boot-options.txt for more + options. See Documentation/x86/x86_64/boot-options.txt for more details. config IOMMU_STRESS diff --git a/arch/x86/boot/header.S b/arch/x86/boot/header.S index 93e689f4bd86..bdb4d458ec8c 100644 --- a/arch/x86/boot/header.S +++ b/arch/x86/boot/header.S @@ -129,7 +129,7 @@ start_sys_seg: .word SYSSEG # obsolete and meaningless, but just type_of_loader: .byte 0 # 0 means ancient bootloader, newer # bootloaders know to change this. - # See Documentation/i386/boot.txt for + # See Documentation/x86/boot.txt for # assigned ids # flags, unused bits must be zero (RFU) bit within loadflags diff --git a/arch/x86/include/asm/dma-mapping.h b/arch/x86/include/asm/dma-mapping.h index d4c419f883a0..ed3065fd6314 100644 --- a/arch/x86/include/asm/dma-mapping.h +++ b/arch/x86/include/asm/dma-mapping.h @@ -2,7 +2,7 @@ #define _ASM_X86_DMA_MAPPING_H /* - * IOMMU interface. See Documentation/PCI/PCI-DMA-mapping.txt and + * IOMMU interface. See Documentation/DMA-API-HOWTO.txt and * Documentation/DMA-API.txt for documentation. */ diff --git a/arch/x86/kernel/amd_gart_64.c b/arch/x86/kernel/amd_gart_64.c index 8a439d364b94..b1e7c7f7a0af 100644 --- a/arch/x86/kernel/amd_gart_64.c +++ b/arch/x86/kernel/amd_gart_64.c @@ -5,7 +5,7 @@ * This allows to use PCI devices that only support 32bit addresses on systems * with more than 4GB. * - * See Documentation/PCI/PCI-DMA-mapping.txt for the interface specification. + * See Documentation/DMA-API-HOWTO.txt for the interface specification. * * Copyright 2002 Andi Kleen, SuSE Labs. * Subject to the GNU General Public License v2 only. diff --git a/arch/x86/kernel/apm_32.c b/arch/x86/kernel/apm_32.c index 0371c484bb8a..a46bd383953c 100644 --- a/arch/x86/kernel/apm_32.c +++ b/arch/x86/kernel/apm_32.c @@ -249,8 +249,6 @@ extern int (*console_blank_hook)(int); #define APM_MINOR_DEV 134 /* - * See Documentation/Config.help for the configuration options. - * * Various options can be changed at boot time as follows: * (We allow underscores for compatibility with the modules code) * apm=on/off enable/disable APM diff --git a/arch/x86/kernel/pci-dma.c b/arch/x86/kernel/pci-dma.c index b49d00da2aed..622872054fbe 100644 --- a/arch/x86/kernel/pci-dma.c +++ b/arch/x86/kernel/pci-dma.c @@ -117,8 +117,8 @@ again: } /* - * See for the iommu kernel parameter - * documentation. + * See for the iommu kernel + * parameter documentation. */ static __init int iommu_setup(char *p) { diff --git a/drivers/char/apm-emulation.c b/drivers/char/apm-emulation.c index a7346ab97a3c..ae6a93306325 100644 --- a/drivers/char/apm-emulation.c +++ b/drivers/char/apm-emulation.c @@ -40,10 +40,7 @@ #define APM_MINOR_DEV 134 /* - * See Documentation/Config.help for the configuration options. - * - * Various options can be changed at boot time as follows: - * (We allow underscores for compatibility with the modules code) + * One option can be changed at boot time as follows: * apm=on/off enable/disable APM */ diff --git a/drivers/input/misc/rotary_encoder.c b/drivers/input/misc/rotary_encoder.c index 2c8b84dd9dac..2be21694fac1 100644 --- a/drivers/input/misc/rotary_encoder.c +++ b/drivers/input/misc/rotary_encoder.c @@ -7,7 +7,7 @@ * state machine code inspired by code from Tim Ruetz * * A generic driver for rotary encoders connected to GPIO lines. - * See file:Documentation/input/rotary_encoder.txt for more information + * See file:Documentation/input/rotary-encoder.txt for more information * * 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 diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig index b591e726a6fa..807c875f1c2e 100644 --- a/drivers/leds/Kconfig +++ b/drivers/leds/Kconfig @@ -400,7 +400,7 @@ config LEDS_TRIGGER_TIMER This allows LEDs to be controlled by a programmable timer via sysfs. Some LED hardware can be programmed to start blinking the LED without any further software interaction. - For more details read Documentation/leds-class.txt. + For more details read Documentation/leds/leds-class.txt. If unsure, say Y. diff --git a/drivers/media/dvb/dvb-usb/af9005-remote.c b/drivers/media/dvb/dvb-usb/af9005-remote.c index c3bc64ed405c..7e3961d0db6b 100644 --- a/drivers/media/dvb/dvb-usb/af9005-remote.c +++ b/drivers/media/dvb/dvb-usb/af9005-remote.c @@ -21,7 +21,7 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * - * see Documentation/dvb/REDME.dvb-usb for more information + * see Documentation/dvb/README.dvb-usb for more information */ #include "af9005.h" /* debug */ diff --git a/drivers/media/dvb/dvb-usb/af9005.c b/drivers/media/dvb/dvb-usb/af9005.c index 51f6439dcfd5..0351c0e52dd2 100644 --- a/drivers/media/dvb/dvb-usb/af9005.c +++ b/drivers/media/dvb/dvb-usb/af9005.c @@ -19,7 +19,7 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. * - * see Documentation/dvb/REDME.dvb-usb for more information + * see Documentation/dvb/README.dvb-usb for more information */ #include "af9005.h" diff --git a/drivers/media/dvb/frontends/dib3000.h b/drivers/media/dvb/frontends/dib3000.h index ba917359fa65..404f63a6f26b 100644 --- a/drivers/media/dvb/frontends/dib3000.h +++ b/drivers/media/dvb/frontends/dib3000.h @@ -17,7 +17,7 @@ * Amaury Demol (ademol@dibcom.fr) from DiBcom for providing specs and driver * sources, on which this driver (and the dvb-dibusb) are based. * - * see Documentation/dvb/README.dibusb for more information + * see Documentation/dvb/README.dvb-usb for more information * */ diff --git a/drivers/media/dvb/frontends/dib3000mb.c b/drivers/media/dvb/frontends/dib3000mb.c index e80c59796368..437904cbf3e6 100644 --- a/drivers/media/dvb/frontends/dib3000mb.c +++ b/drivers/media/dvb/frontends/dib3000mb.c @@ -17,7 +17,7 @@ * Amaury Demol (ademol@dibcom.fr) from DiBcom for providing specs and driver * sources, on which this driver (and the dvb-dibusb) are based. * - * see Documentation/dvb/README.dibusb for more information + * see Documentation/dvb/README.dvb-usb for more information * */ diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 4be8373d43e5..66b616ebe536 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -142,7 +142,7 @@ config MTD_OF_PARTS help This provides a partition parsing function which derives the partition map from the children of the flash node, - as described in Documentation/powerpc/booting-without-of.txt. + as described in Documentation/devicetree/booting-without-of.txt. config MTD_AR7_PARTS tristate "TI AR7 partitioning support" diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 8d0314dbd946..8b8efe52b228 100644 --- a/drivers/net/Kconfig +++ b/drivers/net/Kconfig @@ -1063,8 +1063,7 @@ config SMSC911X Say Y here if you want support for SMSC LAN911x and LAN921x families of ethernet controllers. - To compile this driver as a module, choose M here and read - . The module + To compile this driver as a module, choose M here. The module will be called smsc911x. config SMSC911X_ARCH_HOOKS diff --git a/drivers/net/can/sja1000/sja1000_of_platform.c b/drivers/net/can/sja1000/sja1000_of_platform.c index cee6ba2b8b58..c3dd9d09be57 100644 --- a/drivers/net/can/sja1000/sja1000_of_platform.c +++ b/drivers/net/can/sja1000/sja1000_of_platform.c @@ -29,7 +29,7 @@ * nxp,external-clock-frequency = <16000000>; * }; * - * See "Documentation/powerpc/dts-bindings/can/sja1000.txt" for further + * See "Documentation/devicetree/bindings/net/can/sja1000.txt" for further * information. */ diff --git a/drivers/net/tulip/21142.c b/drivers/net/tulip/21142.c index 092c3faa882a..25b8deedbef8 100644 --- a/drivers/net/tulip/21142.c +++ b/drivers/net/tulip/21142.c @@ -7,9 +7,6 @@ This software may be used and distributed according to the terms of the GNU General Public License, incorporated herein by reference. - Please refer to Documentation/DocBook/tulip-user.{pdf,ps,html} - for more information on this driver. - DC21143 manual "21143 PCI/CardBus 10/100Mb/s Ethernet LAN Controller Hardware Reference Manual" is currently available at : http://developer.intel.com/design/network/manuals/278074.htm diff --git a/drivers/net/tulip/eeprom.c b/drivers/net/tulip/eeprom.c index fa5eee925f25..14d5b611783d 100644 --- a/drivers/net/tulip/eeprom.c +++ b/drivers/net/tulip/eeprom.c @@ -7,8 +7,6 @@ This software may be used and distributed according to the terms of the GNU General Public License, incorporated herein by reference. - Please refer to Documentation/DocBook/tulip-user.{pdf,ps,html} - for more information on this driver. Please submit bug reports to http://bugzilla.kernel.org/. */ diff --git a/drivers/net/tulip/interrupt.c b/drivers/net/tulip/interrupt.c index 5350d753e0ff..4fb8c8c0a420 100644 --- a/drivers/net/tulip/interrupt.c +++ b/drivers/net/tulip/interrupt.c @@ -7,10 +7,7 @@ This software may be used and distributed according to the terms of the GNU General Public License, incorporated herein by reference. - Please refer to Documentation/DocBook/tulip-user.{pdf,ps,html} - for more information on this driver. Please submit bugs to http://bugzilla.kernel.org/ . - */ #include diff --git a/drivers/net/tulip/media.c b/drivers/net/tulip/media.c index 4bd13922875d..beeb17b52ad4 100644 --- a/drivers/net/tulip/media.c +++ b/drivers/net/tulip/media.c @@ -7,9 +7,6 @@ This software may be used and distributed according to the terms of the GNU General Public License, incorporated herein by reference. - Please refer to Documentation/DocBook/tulip-user.{pdf,ps,html} - for more information on this driver. - Please submit bugs to http://bugzilla.kernel.org/ . */ diff --git a/drivers/net/tulip/pnic.c b/drivers/net/tulip/pnic.c index 52d898bdbeb4..9c16e4ad02a6 100644 --- a/drivers/net/tulip/pnic.c +++ b/drivers/net/tulip/pnic.c @@ -7,9 +7,6 @@ This software may be used and distributed according to the terms of the GNU General Public License, incorporated herein by reference. - Please refer to Documentation/DocBook/tulip-user.{pdf,ps,html} - for more information on this driver. - Please submit bugs to http://bugzilla.kernel.org/ . */ diff --git a/drivers/net/tulip/pnic2.c b/drivers/net/tulip/pnic2.c index 93358ee4d830..04a7e477eaff 100644 --- a/drivers/net/tulip/pnic2.c +++ b/drivers/net/tulip/pnic2.c @@ -8,9 +8,6 @@ This software may be used and distributed according to the terms of the GNU General Public License, incorporated herein by reference. - Please refer to Documentation/DocBook/tulip-user.{pdf,ps,html} - for more information on this driver. - Please submit bugs to http://bugzilla.kernel.org/ . */ diff --git a/drivers/net/tulip/timer.c b/drivers/net/tulip/timer.c index 2017faf2d0e6..19078d28ffb9 100644 --- a/drivers/net/tulip/timer.c +++ b/drivers/net/tulip/timer.c @@ -7,9 +7,6 @@ This software may be used and distributed according to the terms of the GNU General Public License, incorporated herein by reference. - Please refer to Documentation/DocBook/tulip-user.{pdf,ps,html} - for more information on this driver. - Please submit bugs to http://bugzilla.kernel.org/ . */ diff --git a/drivers/net/tulip/tulip.h b/drivers/net/tulip/tulip.h index 9db528967da9..fb3887c18dc6 100644 --- a/drivers/net/tulip/tulip.h +++ b/drivers/net/tulip/tulip.h @@ -7,9 +7,6 @@ This software may be used and distributed according to the terms of the GNU General Public License, incorporated herein by reference. - Please refer to Documentation/DocBook/tulip-user.{pdf,ps,html} - for more information on this driver. - Please submit bugs to http://bugzilla.kernel.org/ . */ diff --git a/drivers/net/tulip/tulip_core.c b/drivers/net/tulip/tulip_core.c index 1246998a677c..b905c0dc5648 100644 --- a/drivers/net/tulip/tulip_core.c +++ b/drivers/net/tulip/tulip_core.c @@ -6,9 +6,6 @@ This software may be used and distributed according to the terms of the GNU General Public License, incorporated herein by reference. - Please refer to Documentation/DocBook/tulip-user.{pdf,ps,html} - for more information on this driver. - Please submit bugs to http://bugzilla.kernel.org/ . */ diff --git a/drivers/parisc/sba_iommu.c b/drivers/parisc/sba_iommu.c index 57a6d19eba4c..a6f762188bc3 100644 --- a/drivers/parisc/sba_iommu.c +++ b/drivers/parisc/sba_iommu.c @@ -668,7 +668,7 @@ sba_mark_invalid(struct ioc *ioc, dma_addr_t iova, size_t byte_cnt) * @dev: instance of PCI owned by the driver that's asking * @mask: number of address bits this PCI device can handle * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static int sba_dma_supported( struct device *dev, u64 mask) { @@ -680,7 +680,7 @@ static int sba_dma_supported( struct device *dev, u64 mask) return(0); } - /* Documentation/PCI/PCI-DMA-mapping.txt tells drivers to try 64-bit + /* Documentation/DMA-API-HOWTO.txt tells drivers to try 64-bit * first, then fall back to 32-bit if that fails. * We are just "encouraging" 32-bit DMA masks here since we can * never allow IOMMU bypass unless we add special support for ZX1. @@ -706,7 +706,7 @@ static int sba_dma_supported( struct device *dev, u64 mask) * @size: number of bytes to map in driver buffer. * @direction: R/W or both. * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static dma_addr_t sba_map_single(struct device *dev, void *addr, size_t size, @@ -785,7 +785,7 @@ sba_map_single(struct device *dev, void *addr, size_t size, * @size: number of bytes mapped in driver buffer. * @direction: R/W or both. * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static void sba_unmap_single(struct device *dev, dma_addr_t iova, size_t size, @@ -861,7 +861,7 @@ sba_unmap_single(struct device *dev, dma_addr_t iova, size_t size, * @size: number of bytes mapped in driver buffer. * @dma_handle: IOVA of new buffer. * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static void *sba_alloc_consistent(struct device *hwdev, size_t size, dma_addr_t *dma_handle, gfp_t gfp) @@ -892,7 +892,7 @@ static void *sba_alloc_consistent(struct device *hwdev, size_t size, * @vaddr: virtual address IOVA of "consistent" buffer. * @dma_handler: IO virtual address of "consistent" buffer. * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static void sba_free_consistent(struct device *hwdev, size_t size, void *vaddr, @@ -927,7 +927,7 @@ int dump_run_sg = 0; * @nents: number of entries in list * @direction: R/W or both. * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static int sba_map_sg(struct device *dev, struct scatterlist *sglist, int nents, @@ -1011,7 +1011,7 @@ sba_map_sg(struct device *dev, struct scatterlist *sglist, int nents, * @nents: number of entries in list * @direction: R/W or both. * - * See Documentation/PCI/PCI-DMA-mapping.txt + * See Documentation/DMA-API-HOWTO.txt */ static void sba_unmap_sg(struct device *dev, struct scatterlist *sglist, int nents, diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig index 1e88d4785321..10cf2500522b 100644 --- a/drivers/platform/x86/Kconfig +++ b/drivers/platform/x86/Kconfig @@ -31,9 +31,6 @@ config ACER_WMI wireless radio and bluetooth control, and on some laptops, exposes the mail LED and LCD backlight. - For more information about this driver see - - If you have an ACPI-WMI compatible Acer/ Wistron laptop, say Y or M here. @@ -164,7 +161,7 @@ config HP_ACCEL Support for a led indicating disk protection will be provided as hp::hddprotect. For more information on the feature, refer to - Documentation/hwmon/lis3lv02d. + Documentation/misc-devices/lis3lv02d. To compile this driver as a module, choose M here: the module will be called hp_accel. diff --git a/drivers/scsi/megaraid/megaraid_mbox.c b/drivers/scsi/megaraid/megaraid_mbox.c index 2e6619eff3ea..8883ca36f932 100644 --- a/drivers/scsi/megaraid/megaraid_mbox.c +++ b/drivers/scsi/megaraid/megaraid_mbox.c @@ -67,7 +67,7 @@ * * NEC MegaRAID PCI Express ROMB 1000 0408 1033 8287 * - * For history of changes, see Documentation/ChangeLog.megaraid + * For history of changes, see Documentation/scsi/ChangeLog.megaraid */ #include diff --git a/drivers/staging/cxt1e1/Kconfig b/drivers/staging/cxt1e1/Kconfig index 73430ef6ae2b..947f42a65c59 100644 --- a/drivers/staging/cxt1e1/Kconfig +++ b/drivers/staging/cxt1e1/Kconfig @@ -6,8 +6,7 @@ config CXT1E1 channelized stream WAN adapter card which contains a HDLC/Transparent mode controller. - If you want to compile this driver as a module - say M here and read . + If you want to compile this driver as a module say M here. The module will be called 'cxt1e1'. If unsure, say N. diff --git a/drivers/usb/serial/digi_acceleport.c b/drivers/usb/serial/digi_acceleport.c index 86fbba6336c9..e92cbefc0f88 100644 --- a/drivers/usb/serial/digi_acceleport.c +++ b/drivers/usb/serial/digi_acceleport.c @@ -227,7 +227,7 @@ * - All sleeps use a timeout of DIGI_RETRY_TIMEOUT before looping to * recheck the condition they are sleeping on. This is defensive, * in case a wake up is lost. -* - Following Documentation/DocBook/kernel-locking.pdf no spin locks +* - Following Documentation/DocBook/kernel-locking.tmpl no spin locks * are held when calling copy_to/from_user or printk. */ diff --git a/drivers/video/igafb.c b/drivers/video/igafb.c index d885c770eb84..2d97752f79a5 100644 --- a/drivers/video/igafb.c +++ b/drivers/video/igafb.c @@ -428,7 +428,7 @@ static int __init igafb_init(void) * * IGS2000 has its I/O memory mapped and we want * to generate memory cycles on PCI, e.g. do ioremap(), - * then readb/writeb() as in Documentation/IO-mapping.txt. + * then readb/writeb() as in Documentation/io-mapping.txt. * * IGS1682 is more traditional, it responds to PCI I/O * cycles, so we want to access it with inb()/outb(). diff --git a/drivers/watchdog/smsc37b787_wdt.c b/drivers/watchdog/smsc37b787_wdt.c index e97b0499bd0d..97b8184614ae 100644 --- a/drivers/watchdog/smsc37b787_wdt.c +++ b/drivers/watchdog/smsc37b787_wdt.c @@ -40,7 +40,7 @@ * mknod /dev/watchdog c 10 130 * * For an example userspace keep-alive daemon, see: - * Documentation/watchdog/watchdog.txt + * Documentation/watchdog/wdt.txt */ #include diff --git a/fs/configfs/inode.c b/fs/configfs/inode.c index c83f4768eeaa..ca418aaf6352 100644 --- a/fs/configfs/inode.c +++ b/fs/configfs/inode.c @@ -23,7 +23,8 @@ * * configfs Copyright (C) 2005 Oracle. All rights reserved. * - * Please see Documentation/filesystems/configfs.txt for more information. + * Please see Documentation/filesystems/configfs/configfs.txt for more + * information. */ #undef DEBUG diff --git a/fs/configfs/item.c b/fs/configfs/item.c index 76dc4c3e5d51..50cee7f9110b 100644 --- a/fs/configfs/item.c +++ b/fs/configfs/item.c @@ -23,7 +23,7 @@ * * configfs Copyright (C) 2005 Oracle. All rights reserved. * - * Please see the file Documentation/filesystems/configfs.txt for + * Please see the file Documentation/filesystems/configfs/configfs.txt for * critical information about using the config_item interface. */ diff --git a/fs/locks.c b/fs/locks.c index 703f545097de..96b33989147d 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -60,7 +60,7 @@ * * Initial implementation of mandatory locks. SunOS turned out to be * a rotten model, so I implemented the "obvious" semantics. - * See 'Documentation/mandatory.txt' for details. + * See 'Documentation/filesystems/mandatory-locking.txt' for details. * Andy Walker (andy@lysaker.kvaerner.no), April 06, 1996. * * Don't allow mandatory locks on mmap()'ed files. Added simple functions to diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig index 1360d4f88f41..048b59d5b2f0 100644 --- a/fs/squashfs/Kconfig +++ b/fs/squashfs/Kconfig @@ -19,9 +19,9 @@ config SQUASHFS If you want to compile this as a module ( = code which can be inserted in and removed from the running kernel whenever you want), - say M here and read . The module - will be called squashfs. Note that the root file system (the one - containing the directory /) cannot be compiled as a module. + say M here. The module will be called squashfs. Note that the root + file system (the one containing the directory /) cannot be compiled + as a module. If unsure, say N. diff --git a/include/linux/io-mapping.h b/include/linux/io-mapping.h index 8cdcc2a199ad..c81ed2ac16bd 100644 --- a/include/linux/io-mapping.h +++ b/include/linux/io-mapping.h @@ -27,7 +27,7 @@ * The io_mapping mechanism provides an abstraction for mapping * individual pages from an io device to the CPU in an efficient fashion. * - * See Documentation/io_mapping.txt + * See Documentation/io-mapping.txt */ #ifdef CONFIG_HAVE_ATOMIC_IOMAP diff --git a/include/linux/isdn.h b/include/linux/isdn.h index 44cd663c53b6..4ccf95d681b4 100644 --- a/include/linux/isdn.h +++ b/include/linux/isdn.h @@ -68,7 +68,7 @@ #define ISDN_NET_ENCAP_SYNCPPP 4 #define ISDN_NET_ENCAP_UIHDLC 5 #define ISDN_NET_ENCAP_CISCOHDLCK 6 /* With SLARP and keepalive */ -#define ISDN_NET_ENCAP_X25IFACE 7 /* Documentation/networking/x25-iface.txt*/ +#define ISDN_NET_ENCAP_X25IFACE 7 /* Documentation/networking/x25-iface.txt */ #define ISDN_NET_ENCAP_MAX_ENCAP ISDN_NET_ENCAP_X25IFACE /* Facility which currently uses an ISDN-channel */ diff --git a/include/linux/platform_data/ntc_thermistor.h b/include/linux/platform_data/ntc_thermistor.h index abd286215279..88734e871e3a 100644 --- a/include/linux/platform_data/ntc_thermistor.h +++ b/include/linux/platform_data/ntc_thermistor.h @@ -36,7 +36,7 @@ struct ntc_thermistor_platform_data { * read_uV() * * How to setup pullup_ohm, pulldown_ohm, and connect is - * described at Documentation/hwmon/ntc + * described at Documentation/hwmon/ntc_thermistor * * pullup/down_ohm: 0 for infinite / not-connected */ diff --git a/include/media/videobuf-dma-sg.h b/include/media/videobuf-dma-sg.h index 1c647e8148c4..d8fb6012c10d 100644 --- a/include/media/videobuf-dma-sg.h +++ b/include/media/videobuf-dma-sg.h @@ -34,7 +34,7 @@ * does memory allocation too using vmalloc_32(). * * videobuf_dma_*() - * see Documentation/PCI/PCI-DMA-mapping.txt, these functions to + * see Documentation/DMA-API-HOWTO.txt, these functions to * basically the same. The map function does also build a * scatterlist for the buffer (and unmap frees it ...) * diff --git a/include/target/configfs_macros.h b/include/target/configfs_macros.h index 7fe74608b437..a0fc85bbe2da 100644 --- a/include/target/configfs_macros.h +++ b/include/target/configfs_macros.h @@ -30,8 +30,8 @@ * Added CONFIGFS_EATTR() macros from original configfs.h macros * Copright (C) 2008-2009 Nicholas A. Bellinger * - * Please read Documentation/filesystems/configfs.txt before using the - * configfs interface, ESPECIALLY the parts about reference counts and + * Please read Documentation/filesystems/configfs/configfs.txt before using + * the configfs interface, ESPECIALLY the parts about reference counts and * item destructors. */ diff --git a/net/netfilter/Kconfig b/net/netfilter/Kconfig index 32bff6d86cb2..8260b13d93c9 100644 --- a/net/netfilter/Kconfig +++ b/net/netfilter/Kconfig @@ -505,7 +505,7 @@ config NETFILTER_XT_TARGET_LED echo netfilter-ssh > /sys/class/leds//trigger For more information on the LEDs available on your system, see - Documentation/leds-class.txt + Documentation/leds/leds-class.txt config NETFILTER_XT_TARGET_MARK tristate '"MARK" target support' diff --git a/sound/oss/Kconfig b/sound/oss/Kconfig index 6c93e051f9ae..6c9e8e8f45f8 100644 --- a/sound/oss/Kconfig +++ b/sound/oss/Kconfig @@ -432,9 +432,7 @@ config SOUND_SB ALS-007 and ALS-1X0 chips (read ) and for cards based on ESS chips (read and - ). If you have an SB AWE 32 or SB AWE - 64, say Y here and also to "AWE32 synth" below and read - . If you have an IBM Mwave + ). If you have an IBM Mwave card, say Y here and read . If you compile the driver into the kernel and don't want to use diff --git a/tools/perf/util/config.c b/tools/perf/util/config.c index fe02903f7d0f..80d9598db31a 100644 --- a/tools/perf/util/config.c +++ b/tools/perf/util/config.c @@ -341,7 +341,7 @@ const char *perf_config_dirname(const char *name, const char *value) static int perf_default_core_config(const char *var __used, const char *value __used) { - /* Add other config variables here and to Documentation/config.txt. */ + /* Add other config variables here. */ return 0; } @@ -350,7 +350,7 @@ int perf_default_config(const char *var, const char *value, void *dummy __used) if (!prefixcmp(var, "core.")) return perf_default_core_config(var, value); - /* Add other config variables here and to Documentation/config.txt. */ + /* Add other config variables here. */ return 0; } -- cgit 1.4.1 From e3cba3243eb853a052613c804dea033bc4c9cf2d Mon Sep 17 00:00:00 2001 From: Jean Pihet Date: Tue, 4 Oct 2011 21:54:45 +0200 Subject: PM / QoS: Update Documentation for the pm_qos and dev_pm_qos frameworks Update the documentation for the recently updated pm_qos API, kernel and user space. Add documentation for the per-device PM QoS (dev_pm_qos) framework API. Signed-off-by: Jean Pihet Signed-off-by: Rafael J. Wysocki --- Documentation/power/pm_qos_interface.txt | 92 ++++++++++++++++++++++++++++++-- 1 file changed, 87 insertions(+), 5 deletions(-) (limited to 'Documentation/power') diff --git a/Documentation/power/pm_qos_interface.txt b/Documentation/power/pm_qos_interface.txt index bfed898a03fc..17e130a80347 100644 --- a/Documentation/power/pm_qos_interface.txt +++ b/Documentation/power/pm_qos_interface.txt @@ -4,14 +4,19 @@ This interface provides a kernel and user mode interface for registering performance expectations by drivers, subsystems and user space applications on one of the parameters. -Currently we have {cpu_dma_latency, network_latency, network_throughput} as the -initial set of pm_qos parameters. +Two different PM QoS frameworks are available: +1. PM QoS classes for cpu_dma_latency, network_latency, network_throughput. +2. the per-device PM QoS framework provides the API to manage the per-device latency +constraints. Each parameters have defined units: * latency: usec * timeout: usec * throughput: kbs (kilo bit / sec) + +1. PM QoS framework + The infrastructure exposes multiple misc device nodes one per implemented parameter. The set of parameters implement is defined by pm_qos_power_init() and pm_qos_params.h. This is done because having the available parameters @@ -23,14 +28,18 @@ an aggregated target value. The aggregated target value is updated with changes to the request list or elements of the list. Typically the aggregated target value is simply the max or min of the request values held in the parameter list elements. +Note: the aggregated target value is implemented as an atomic variable so that +reading the aggregated value does not require any locking mechanism. + From kernel mode the use of this interface is simple: -handle = pm_qos_add_request(param_class, target_value): -Will insert an element into the list for that identified PM_QOS class with the +void pm_qos_add_request(handle, param_class, target_value): +Will insert an element into the list for that identified PM QoS class with the target value. Upon change to this list the new target is recomputed and any registered notifiers are called only if the target value is now different. -Clients of pm_qos need to save the returned handle. +Clients of pm_qos need to save the returned handle for future use in other +pm_qos API functions. void pm_qos_update_request(handle, new_target_value): Will update the list element pointed to by the handle with the new target value @@ -42,6 +51,20 @@ Will remove the element. After removal it will update the aggregate target and call the notification tree if the target was changed as a result of removing the request. +int pm_qos_request(param_class): +Returns the aggregated value for a given PM QoS class. + +int pm_qos_request_active(handle): +Returns if the request is still active, i.e. it has not been removed from a +PM QoS class constraints list. + +int pm_qos_add_notifier(param_class, notifier): +Adds a notification callback function to the PM QoS class. The callback is +called when the aggregated value for the PM QoS class is changed. + +int pm_qos_remove_notifier(int param_class, notifier): +Removes the notification callback function for the PM QoS class. + From user mode: Only processes can register a pm_qos request. To provide for automatic @@ -63,4 +86,63 @@ To remove the user mode request for a target value simply close the device node. +2. PM QoS per-device latency framework + +For each device a list of performance requests is maintained along with +an aggregated target value. The aggregated target value is updated with +changes to the request list or elements of the list. Typically the +aggregated target value is simply the max or min of the request values held +in the parameter list elements. +Note: the aggregated target value is implemented as an atomic variable so that +reading the aggregated value does not require any locking mechanism. + + +From kernel mode the use of this interface is the following: + +int dev_pm_qos_add_request(device, handle, value): +Will insert an element into the list for that identified device with the +target value. Upon change to this list the new target is recomputed and any +registered notifiers are called only if the target value is now different. +Clients of dev_pm_qos need to save the handle for future use in other +dev_pm_qos API functions. + +int dev_pm_qos_update_request(handle, new_value): +Will update the list element pointed to by the handle with the new target value +and recompute the new aggregated target, calling the notification trees if the +target is changed. + +int dev_pm_qos_remove_request(handle): +Will remove the element. After removal it will update the aggregate target and +call the notification trees if the target was changed as a result of removing +the request. + +s32 dev_pm_qos_read_value(device): +Returns the aggregated value for a given device's constraints list. + + +Notification mechanisms: +The per-device PM QoS framework has 2 different and distinct notification trees: +a per-device notification tree and a global notification tree. + +int dev_pm_qos_add_notifier(device, notifier): +Adds a notification callback function for the device. +The callback is called when the aggregated value of the device constraints list +is changed. + +int dev_pm_qos_remove_notifier(device, notifier): +Removes the notification callback function for the device. + +int dev_pm_qos_add_global_notifier(notifier): +Adds a notification callback function in the global notification tree of the +framework. +The callback is called when the aggregated value for any device is changed. + +int dev_pm_qos_remove_global_notifier(notifier): +Removes the notification callback function from the global notification tree +of the framework. + + +From user mode: +No API for user space access to the per-device latency constraints is provided +yet - still under discussion. -- cgit 1.4.1 From 2c1ba398ac9da3305815f6ae8e95ae2b9fd3b5ff Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Thu, 8 Sep 2011 10:37:31 -0700 Subject: regulator: Fix some bitrot in the machine driver documentation The documentation for the machine driver was rather badly bitrotted, using pointers to struct device rather than dev_name() to hook up the consumers. Update to use dev_name(). Reported-by: Philip Rakity Signed-off-by: Mark Brown --- Documentation/power/regulator/machine.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation/power') diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt index b42419b52e44..311c61f2feaa 100644 --- a/Documentation/power/regulator/machine.txt +++ b/Documentation/power/regulator/machine.txt @@ -16,7 +16,7 @@ initialisation code by creating a struct regulator_consumer_supply for each regulator. struct regulator_consumer_supply { - struct device *dev; /* consumer */ + const char *dev_name; /* consumer dev_name() */ const char *supply; /* consumer supply - e.g. "vcc" */ }; @@ -24,13 +24,13 @@ e.g. for the machine above static struct regulator_consumer_supply regulator1_consumers[] = { { - .dev = &platform_consumerB_device.dev, - .supply = "Vcc", + .dev_name = "dev_name(consumer B)", + .supply = "Vcc", },}; static struct regulator_consumer_supply regulator2_consumers[] = { { - .dev = &platform_consumerA_device.dev, + .dev = "dev_name(consumer A"), .supply = "Vcc", },}; -- cgit 1.4.1 From c3035a232e87f42b81d8ece1980abd0a2f26d792 Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Thu, 8 Sep 2011 10:38:59 -0700 Subject: regulator: Clarify documentation for regulator-regulator supplies The mechanism used for connecting regulators together when one regulator supplies another wasn't clear as the names being used weren't really tied together well. Reported-by: Philip Rakity Signed-off-by: Mark Brown --- Documentation/power/regulator/machine.txt | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) (limited to 'Documentation/power') diff --git a/Documentation/power/regulator/machine.txt b/Documentation/power/regulator/machine.txt index 311c61f2feaa..ce63af0a8e35 100644 --- a/Documentation/power/regulator/machine.txt +++ b/Documentation/power/regulator/machine.txt @@ -43,6 +43,7 @@ to their supply regulator :- static struct regulator_init_data regulator1_data = { .constraints = { + .name = "Regulator-1", .min_uV = 3300000, .max_uV = 3300000, .valid_modes_mask = REGULATOR_MODE_NORMAL, @@ -51,13 +52,19 @@ static struct regulator_init_data regulator1_data = { .consumer_supplies = regulator1_consumers, }; +The name field should be set to something that is usefully descriptive +for the board for configuration of supplies for other regulators and +for use in logging and other diagnostic output. Normally the name +used for the supply rail in the schematic is a good choice. If no +name is provided then the subsystem will choose one. + Regulator-1 supplies power to Regulator-2. This relationship must be registered with the core so that Regulator-1 is also enabled when Consumer A enables its supply (Regulator-2). The supply regulator is set by the supply_regulator -field below:- +field below and co:- static struct regulator_init_data regulator2_data = { - .supply_regulator = "regulator_name", + .supply_regulator = "Regulator-1", .constraints = { .min_uV = 1800000, .max_uV = 2000000, -- cgit 1.4.1 From 2fb242adcaab5defa2f208775ac4f181ac998fdd Mon Sep 17 00:00:00 2001 From: Ming Lei Date: Sun, 9 Oct 2011 11:40:25 +0800 Subject: PM / Runtime: Update document about callbacks Support for device power domains has been introduced in commit 9659cc0678b954f187290c6e8b247a673c5d37e1 (PM: Make system-wide PM and runtime PM treat subsystems consistently), also power domain callbacks will take precedence over subsystem ones from commit 4d27e9dcff00a6425d779b065ec8892e4f391661(PM: Make power domain callbacks take precedence over subsystem ones). So update part of "Device Runtime PM Callbacks" in Documentation/power/runtime_pm.txt. Signed-off-by: Ming Lei Signed-off-by: Rafael J. Wysocki --- Documentation/power/runtime_pm.txt | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-) (limited to 'Documentation/power') diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 1750740b17e8..f670836f8e5f 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -43,13 +43,18 @@ struct dev_pm_ops { ... }; -The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks are -executed by the PM core for either the device type, or the class (if the device -type's struct dev_pm_ops object does not exist), or the bus type (if the -device type's and class' struct dev_pm_ops objects do not exist) of the given -device (this allows device types to override callbacks provided by bus types or -classes if necessary). The bus type, device type and class callbacks are -referred to as subsystem-level callbacks in what follows. +The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks +are executed by the PM core for either the power domain, or the device type +(if the device power domain's struct dev_pm_ops does not exist), or the class +(if the device power domain's and type's struct dev_pm_ops object does not +exist), or the bus type (if the device power domain's, type's and class' +struct dev_pm_ops objects do not exist) of the given device, so the priority +order of callbacks from high to low is that power domain callbacks, device +type callbacks, class callbacks and bus type callbacks, and the high priority +one will take precedence over low priority one. The bus type, device type and +class callbacks are referred to as subsystem-level callbacks in what follows, +and generally speaking, the power domain callbacks are used for representing +power domains within a SoC. By default, the callbacks are always invoked in process context with interrupts enabled. However, subsystems can use the pm_runtime_irq_safe() helper function -- cgit 1.4.1 From 2a77c46de1e3dace73745015635ebbc648eca69c Mon Sep 17 00:00:00 2001 From: ShuoX Liu Date: Wed, 10 Aug 2011 23:01:26 +0200 Subject: PM / Suspend: Add statistics debugfs file for suspend to RAM Record S3 failure time about each reason and the latest two failed devices' names in S3 progress. We can check it through 'suspend_stats' entry in debugfs. The motivation of the patch: We are enabling power features on Medfield. Comparing with PC/notebook, a mobile enters/exits suspend-2-ram (we call it s3 on Medfield) far more frequently. If it can't enter suspend-2-ram in time, the power might be used up soon. We often find sometimes, a device suspend fails. Then, system retries s3 over and over again. As display is off, testers and developers don't know what happens. Some testers and developers complain they don't know if system tries suspend-2-ram, and what device fails to suspend. They need such info for a quick check. The patch adds suspend_stats under debugfs for users to check suspend to RAM statistics quickly. If not using this patch, we have other methods to get info about what device fails. One is to turn on CONFIG_PM_DEBUG, but users would get too much info and testers need recompile the system. In addition, dynamic debug is another good tool to dump debug info. But it still doesn't match our utilization scenario closely. 1) user need write a user space parser to process the syslog output; 2) Our testing scenario is we leave the mobile for at least hours. Then, check its status. No serial console available during the testing. One is because console would be suspended, and the other is serial console connecting with spi or HSU devices would consume power. These devices are powered off at suspend-2-ram. Signed-off-by: ShuoX Liu Signed-off-by: Rafael J. Wysocki --- Documentation/power/basic-pm-debugging.txt | 24 +++++++ drivers/base/power/main.c | 31 +++++++-- include/linux/suspend.h | 52 +++++++++++++++ kernel/power/main.c | 102 +++++++++++++++++++++++++++++ kernel/power/suspend.c | 17 ++++- 5 files changed, 218 insertions(+), 8 deletions(-) (limited to 'Documentation/power') diff --git a/Documentation/power/basic-pm-debugging.txt b/Documentation/power/basic-pm-debugging.txt index ddd78172ef73..62eca080a71b 100644 --- a/Documentation/power/basic-pm-debugging.txt +++ b/Documentation/power/basic-pm-debugging.txt @@ -201,3 +201,27 @@ case, you may be able to search for failing drivers by following the procedure analogous to the one described in section 1. If you find some failing drivers, you will have to unload them every time before an STR transition (ie. before you run s2ram), and please report the problems with them. + +There is a debugfs entry which shows the suspend to RAM statistics. Here is an +example of its output. + # mount -t debugfs none /sys/kernel/debug + # cat /sys/kernel/debug/suspend_stats + success: 20 + fail: 5 + failed_freeze: 0 + failed_prepare: 0 + failed_suspend: 5 + failed_suspend_noirq: 0 + failed_resume: 0 + failed_resume_noirq: 0 + failures: + last_failed_dev: alarm + adc + last_failed_errno: -16 + -16 + last_failed_step: suspend + suspend +Field success means the success number of suspend to RAM, and field fail means +the failure number. Others are the failure number of different steps of suspend +to RAM. suspend_stats just lists the last 2 failed devices, error number and +failed step of suspend. diff --git a/drivers/base/power/main.c b/drivers/base/power/main.c index c6291ab725a3..b1b58260b4ff 100644 --- a/drivers/base/power/main.c +++ b/drivers/base/power/main.c @@ -46,6 +46,7 @@ LIST_HEAD(dpm_prepared_list); LIST_HEAD(dpm_suspended_list); LIST_HEAD(dpm_noirq_list); +struct suspend_stats suspend_stats; static DEFINE_MUTEX(dpm_list_mtx); static pm_message_t pm_transition; @@ -467,8 +468,12 @@ void dpm_resume_noirq(pm_message_t state) mutex_unlock(&dpm_list_mtx); error = device_resume_noirq(dev, state); - if (error) + if (error) { + suspend_stats.failed_resume_noirq++; + dpm_save_failed_step(SUSPEND_RESUME_NOIRQ); + dpm_save_failed_dev(dev_name(dev)); pm_dev_err(dev, state, " early", error); + } mutex_lock(&dpm_list_mtx); put_device(dev); @@ -629,8 +634,12 @@ void dpm_resume(pm_message_t state) mutex_unlock(&dpm_list_mtx); error = device_resume(dev, state, false); - if (error) + if (error) { + suspend_stats.failed_resume++; + dpm_save_failed_step(SUSPEND_RESUME); + dpm_save_failed_dev(dev_name(dev)); pm_dev_err(dev, state, "", error); + } mutex_lock(&dpm_list_mtx); } @@ -805,6 +814,9 @@ int dpm_suspend_noirq(pm_message_t state) mutex_lock(&dpm_list_mtx); if (error) { pm_dev_err(dev, state, " late", error); + suspend_stats.failed_suspend_noirq++; + dpm_save_failed_step(SUSPEND_SUSPEND_NOIRQ); + dpm_save_failed_dev(dev_name(dev)); put_device(dev); break; } @@ -926,8 +938,10 @@ static void async_suspend(void *data, async_cookie_t cookie) int error; error = __device_suspend(dev, pm_transition, true); - if (error) + if (error) { + dpm_save_failed_dev(dev_name(dev)); pm_dev_err(dev, pm_transition, " async", error); + } put_device(dev); } @@ -970,6 +984,7 @@ int dpm_suspend(pm_message_t state) mutex_lock(&dpm_list_mtx); if (error) { pm_dev_err(dev, state, "", error); + dpm_save_failed_dev(dev_name(dev)); put_device(dev); break; } @@ -983,7 +998,10 @@ int dpm_suspend(pm_message_t state) async_synchronize_full(); if (!error) error = async_error; - if (!error) + if (error) { + suspend_stats.failed_suspend++; + dpm_save_failed_step(SUSPEND_SUSPEND); + } else dpm_show_time(starttime, state, NULL); return error; } @@ -1091,7 +1109,10 @@ int dpm_suspend_start(pm_message_t state) int error; error = dpm_prepare(state); - if (!error) + if (error) { + suspend_stats.failed_prepare++; + dpm_save_failed_step(SUSPEND_PREPARE); + } else error = dpm_suspend(state); return error; } diff --git a/include/linux/suspend.h b/include/linux/suspend.h index 6bbcef22e105..76f42e49b72d 100644 --- a/include/linux/suspend.h +++ b/include/linux/suspend.h @@ -34,6 +34,58 @@ typedef int __bitwise suspend_state_t; #define PM_SUSPEND_MEM ((__force suspend_state_t) 3) #define PM_SUSPEND_MAX ((__force suspend_state_t) 4) +enum suspend_stat_step { + SUSPEND_FREEZE = 1, + SUSPEND_PREPARE, + SUSPEND_SUSPEND, + SUSPEND_SUSPEND_NOIRQ, + SUSPEND_RESUME_NOIRQ, + SUSPEND_RESUME +}; + +struct suspend_stats { + int success; + int fail; + int failed_freeze; + int failed_prepare; + int failed_suspend; + int failed_suspend_noirq; + int failed_resume; + int failed_resume_noirq; +#define REC_FAILED_NUM 2 + int last_failed_dev; + char failed_devs[REC_FAILED_NUM][40]; + int last_failed_errno; + int errno[REC_FAILED_NUM]; + int last_failed_step; + enum suspend_stat_step failed_steps[REC_FAILED_NUM]; +}; + +extern struct suspend_stats suspend_stats; + +static inline void dpm_save_failed_dev(const char *name) +{ + strlcpy(suspend_stats.failed_devs[suspend_stats.last_failed_dev], + name, + sizeof(suspend_stats.failed_devs[0])); + suspend_stats.last_failed_dev++; + suspend_stats.last_failed_dev %= REC_FAILED_NUM; +} + +static inline void dpm_save_failed_errno(int err) +{ + suspend_stats.errno[suspend_stats.last_failed_errno] = err; + suspend_stats.last_failed_errno++; + suspend_stats.last_failed_errno %= REC_FAILED_NUM; +} + +static inline void dpm_save_failed_step(enum suspend_stat_step step) +{ + suspend_stats.failed_steps[suspend_stats.last_failed_step] = step; + suspend_stats.last_failed_step++; + suspend_stats.last_failed_step %= REC_FAILED_NUM; +} + /** * struct platform_suspend_ops - Callbacks for managing platform dependent * system sleep states. diff --git a/kernel/power/main.c b/kernel/power/main.c index 6c601f871964..2757acba8e8a 100644 --- a/kernel/power/main.c +++ b/kernel/power/main.c @@ -12,6 +12,8 @@ #include #include #include +#include +#include #include "power.h" @@ -133,6 +135,101 @@ power_attr(pm_test); #endif /* CONFIG_PM_SLEEP */ +#ifdef CONFIG_DEBUG_FS +static char *suspend_step_name(enum suspend_stat_step step) +{ + switch (step) { + case SUSPEND_FREEZE: + return "freeze"; + case SUSPEND_PREPARE: + return "prepare"; + case SUSPEND_SUSPEND: + return "suspend"; + case SUSPEND_SUSPEND_NOIRQ: + return "suspend_noirq"; + case SUSPEND_RESUME_NOIRQ: + return "resume_noirq"; + case SUSPEND_RESUME: + return "resume"; + default: + return ""; + } +} + +static int suspend_stats_show(struct seq_file *s, void *unused) +{ + int i, index, last_dev, last_errno, last_step; + + last_dev = suspend_stats.last_failed_dev + REC_FAILED_NUM - 1; + last_dev %= REC_FAILED_NUM; + last_errno = suspend_stats.last_failed_errno + REC_FAILED_NUM - 1; + last_errno %= REC_FAILED_NUM; + last_step = suspend_stats.last_failed_step + REC_FAILED_NUM - 1; + last_step %= REC_FAILED_NUM; + seq_printf(s, "%s: %d\n%s: %d\n%s: %d\n%s: %d\n" + "%s: %d\n%s: %d\n%s: %d\n%s: %d\n", + "success", suspend_stats.success, + "fail", suspend_stats.fail, + "failed_freeze", suspend_stats.failed_freeze, + "failed_prepare", suspend_stats.failed_prepare, + "failed_suspend", suspend_stats.failed_suspend, + "failed_suspend_noirq", + suspend_stats.failed_suspend_noirq, + "failed_resume", suspend_stats.failed_resume, + "failed_resume_noirq", + suspend_stats.failed_resume_noirq); + seq_printf(s, "failures:\n last_failed_dev:\t%-s\n", + suspend_stats.failed_devs[last_dev]); + for (i = 1; i < REC_FAILED_NUM; i++) { + index = last_dev + REC_FAILED_NUM - i; + index %= REC_FAILED_NUM; + seq_printf(s, "\t\t\t%-s\n", + suspend_stats.failed_devs[index]); + } + seq_printf(s, " last_failed_errno:\t%-d\n", + suspend_stats.errno[last_errno]); + for (i = 1; i < REC_FAILED_NUM; i++) { + index = last_errno + REC_FAILED_NUM - i; + index %= REC_FAILED_NUM; + seq_printf(s, "\t\t\t%-d\n", + suspend_stats.errno[index]); + } + seq_printf(s, " last_failed_step:\t%-s\n", + suspend_step_name( + suspend_stats.failed_steps[last_step])); + for (i = 1; i < REC_FAILED_NUM; i++) { + index = last_step + REC_FAILED_NUM - i; + index %= REC_FAILED_NUM; + seq_printf(s, "\t\t\t%-s\n", + suspend_step_name( + suspend_stats.failed_steps[index])); + } + + return 0; +} + +static int suspend_stats_open(struct inode *inode, struct file *file) +{ + return single_open(file, suspend_stats_show, NULL); +} + +static const struct file_operations suspend_stats_operations = { + .open = suspend_stats_open, + .read = seq_read, + .llseek = seq_lseek, + .release = single_release, +}; + +static int __init pm_debugfs_init(void) +{ + debugfs_create_file("suspend_stats", S_IFREG | S_IRUGO, + NULL, NULL, &suspend_stats_operations); + return 0; +} + +late_initcall(pm_debugfs_init); +#endif /* CONFIG_DEBUG_FS */ + struct kobject *power_kobj; /** @@ -194,6 +291,11 @@ static ssize_t state_store(struct kobject *kobj, struct kobj_attribute *attr, } if (state < PM_SUSPEND_MAX && *s) error = enter_state(state); + if (error) { + suspend_stats.fail++; + dpm_save_failed_errno(error); + } else + suspend_stats.success++; #endif Exit: diff --git a/kernel/power/suspend.c b/kernel/power/suspend.c index b6b71ad2208f..595a3dd56a8a 100644 --- a/kernel/power/suspend.c +++ b/kernel/power/suspend.c @@ -104,7 +104,10 @@ static int suspend_prepare(void) goto Finish; error = suspend_freeze_processes(); - if (!error) + if (error) { + suspend_stats.failed_freeze++; + dpm_save_failed_step(SUSPEND_FREEZE); + } else return 0; suspend_thaw_processes(); @@ -315,8 +318,16 @@ int enter_state(suspend_state_t state) */ int pm_suspend(suspend_state_t state) { - if (state > PM_SUSPEND_ON && state <= PM_SUSPEND_MAX) - return enter_state(state); + int ret; + if (state > PM_SUSPEND_ON && state <= PM_SUSPEND_MAX) { + ret = enter_state(state); + if (ret) { + suspend_stats.fail++; + dpm_save_failed_errno(ret); + } else + suspend_stats.success++; + return ret; + } return -EINVAL; } EXPORT_SYMBOL(pm_suspend); -- cgit 1.4.1 From 8f88893c05f2f677f18f2ce5591b4bed5d4a7535 Mon Sep 17 00:00:00 2001 From: Alan Stern Date: Mon, 26 Sep 2011 17:38:50 +0200 Subject: PM: Update the policy on default wakeup settings This patch (as1485) documents a change to the kernel's default wakeup policy. Devices that forward wakeup requests between buses should be enabled for wakeup by default. Signed-off-by: Alan Stern Signed-off-by: Rafael J. Wysocki --- Documentation/power/devices.txt | 4 +++- drivers/base/power/wakeup.c | 4 +++- 2 files changed, 6 insertions(+), 2 deletions(-) (limited to 'Documentation/power') diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 3384d5996be2..29b7a9817f5a 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -152,7 +152,9 @@ try to use its wakeup mechanism. device_set_wakeup_enable() affects this flag; for the most part drivers should not change its value. The initial value of should_wakeup is supposed to be false for the majority of devices; the major exceptions are power buttons, keyboards, and Ethernet adapters whose WoL -(wake-on-LAN) feature has been set up with ethtool. +(wake-on-LAN) feature has been set up with ethtool. It should also default +to true for devices that don't generate wakeup requests on their own but merely +forward wakeup requests from one bus to another (like PCI bridges). Whether or not a device is capable of issuing wakeup events is a hardware matter, and the kernel is responsible for keeping track of it. By contrast, diff --git a/drivers/base/power/wakeup.c b/drivers/base/power/wakeup.c index 84f7c7d5a098..14ee07e9cc43 100644 --- a/drivers/base/power/wakeup.c +++ b/drivers/base/power/wakeup.c @@ -276,7 +276,9 @@ EXPORT_SYMBOL_GPL(device_set_wakeup_capable); * * By default, most devices should leave wakeup disabled. The exceptions are * devices that everyone expects to be wakeup sources: keyboards, power buttons, - * possibly network interfaces, etc. + * possibly network interfaces, etc. Also, devices that don't generate their + * own wakeup requests but merely forward requests from one bus to another + * (like PCI bridges) should have wakeup enabled by default. */ int device_init_wakeup(struct device *dev, bool enable) { -- cgit 1.4.1 From 2aede851ddf08666f68ffc17be446420e9d2a056 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Mon, 26 Sep 2011 20:32:27 +0200 Subject: PM / Hibernate: Freeze kernel threads after preallocating memory There is a problem with the current ordering of hibernate code which leads to deadlocks in some filesystems' memory shrinkers. Namely, some filesystems use freezable kernel threads that are inactive when the hibernate memory preallocation is carried out. Those same filesystems use memory shrinkers that may be triggered by the hibernate memory preallocation. If those memory shrinkers wait for the frozen kernel threads, the hibernate process deadlocks (this happens with XFS, for one example). Apparently, it is not technically viable to redesign the filesystems in question to avoid the situation described above, so the only possible solution of this issue is to defer the freezing of kernel threads until the hibernate memory preallocation is done, which is implemented by this change. Unfortunately, this requires the memory preallocation to be done before the "prepare" stage of device freeze, so after this change the only way drivers can allocate additional memory for their freeze routines in a clean way is to use PM notifiers. Reported-by: Christoph Signed-off-by: Rafael J. Wysocki --- Documentation/power/devices.txt | 4 ---- include/linux/freezer.h | 4 +++- kernel/power/hibernate.c | 12 ++++++++---- kernel/power/power.h | 3 ++- kernel/power/process.c | 30 ++++++++++++++++++++---------- 5 files changed, 33 insertions(+), 20 deletions(-) (limited to 'Documentation/power') diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 29b7a9817f5a..646a89e0c07d 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -281,10 +281,6 @@ When the system goes into the standby or memory sleep state, the phases are: time.) Unlike the other suspend-related phases, during the prepare phase the device tree is traversed top-down. - In addition to that, if device drivers need to allocate additional - memory to be able to hadle device suspend correctly, that should be - done in the prepare phase. - After the prepare callback method returns, no new children may be registered below the device. The method may also prepare the device or driver in some way for the upcoming system power transition (for diff --git a/include/linux/freezer.h b/include/linux/freezer.h index 1effc8b56b4e..aa56cf31f7ff 100644 --- a/include/linux/freezer.h +++ b/include/linux/freezer.h @@ -49,6 +49,7 @@ extern int thaw_process(struct task_struct *p); extern void refrigerator(void); extern int freeze_processes(void); +extern int freeze_kernel_threads(void); extern void thaw_processes(void); static inline int try_to_freeze(void) @@ -171,7 +172,8 @@ static inline void clear_freeze_flag(struct task_struct *p) {} static inline int thaw_process(struct task_struct *p) { return 1; } static inline void refrigerator(void) {} -static inline int freeze_processes(void) { BUG(); return 0; } +static inline int freeze_processes(void) { return -ENOSYS; } +static inline int freeze_kernel_threads(void) { return -ENOSYS; } static inline void thaw_processes(void) {} static inline int try_to_freeze(void) { return 0; } diff --git a/kernel/power/hibernate.c b/kernel/power/hibernate.c index 8f7b1db1ece1..3a20466015f8 100644 --- a/kernel/power/hibernate.c +++ b/kernel/power/hibernate.c @@ -334,12 +334,16 @@ int hibernation_snapshot(int platform_mode) if (error) goto Close; - error = dpm_prepare(PMSG_FREEZE); - if (error) - goto Complete_devices; - /* Preallocate image memory before shutting down devices. */ error = hibernate_preallocate_memory(); + if (error) + goto Close; + + error = freeze_kernel_threads(); + if (error) + goto Close; + + error = dpm_prepare(PMSG_FREEZE); if (error) goto Complete_devices; diff --git a/kernel/power/power.h b/kernel/power/power.h index 9a00a0a26280..e6206397ce67 100644 --- a/kernel/power/power.h +++ b/kernel/power/power.h @@ -228,7 +228,8 @@ extern int pm_test_level; #ifdef CONFIG_SUSPEND_FREEZER static inline int suspend_freeze_processes(void) { - return freeze_processes(); + int error = freeze_processes(); + return error ? : freeze_kernel_threads(); } static inline void suspend_thaw_processes(void) diff --git a/kernel/power/process.c b/kernel/power/process.c index 0cf3a27a6c9d..addbbe5531bc 100644 --- a/kernel/power/process.c +++ b/kernel/power/process.c @@ -135,7 +135,7 @@ static int try_to_freeze_tasks(bool sig_only) } /** - * freeze_processes - tell processes to enter the refrigerator + * freeze_processes - Signal user space processes to enter the refrigerator. */ int freeze_processes(void) { @@ -143,20 +143,30 @@ int freeze_processes(void) printk("Freezing user space processes ... "); error = try_to_freeze_tasks(true); - if (error) - goto Exit; - printk("done.\n"); + if (!error) { + printk("done."); + oom_killer_disable(); + } + printk("\n"); + BUG_ON(in_atomic()); + + return error; +} + +/** + * freeze_kernel_threads - Make freezable kernel threads go to the refrigerator. + */ +int freeze_kernel_threads(void) +{ + int error; printk("Freezing remaining freezable tasks ... "); error = try_to_freeze_tasks(false); - if (error) - goto Exit; - printk("done."); + if (!error) + printk("done."); - oom_killer_disable(); - Exit: - BUG_ON(in_atomic()); printk("\n"); + BUG_ON(in_atomic()); return error; } -- cgit 1.4.1 From 7fef9fc83fbd7293ea9fe665d14046422ebf4219 Mon Sep 17 00:00:00 2001 From: "Srivatsa S. Bhat" Date: Wed, 19 Oct 2011 23:59:05 +0200 Subject: PM / Documentation: Update docs about suspend and CPU hotplug Update the documentation about the interaction between the suspend (S3) call path and the CPU hotplug infrastructure. This patch focusses only on the activities of the freezer, cpu hotplug and the notifications involved. It outlines how regular CPU hotplug differs from the way it is invoked during suspend and also tries to explain the locking involved. In addition to that, it discusses the issue of microcode update during CPU hotplug operations. Signed-off-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki --- Documentation/power/00-INDEX | 2 + Documentation/power/suspend-and-cpuhotplug.txt | 275 +++++++++++++++++++++++++ 2 files changed, 277 insertions(+) create mode 100644 Documentation/power/suspend-and-cpuhotplug.txt (limited to 'Documentation/power') diff --git a/Documentation/power/00-INDEX b/Documentation/power/00-INDEX index 45e9d4a91284..a4d682f54231 100644 --- a/Documentation/power/00-INDEX +++ b/Documentation/power/00-INDEX @@ -26,6 +26,8 @@ s2ram.txt - How to get suspend to ram working (and debug it when it isn't) states.txt - System power management states +suspend-and-cpuhotplug.txt + - Explains the interaction between Suspend-to-RAM (S3) and CPU hotplug swsusp-and-swap-files.txt - Using swap files with software suspend (to disk) swsusp-dmcrypt.txt diff --git a/Documentation/power/suspend-and-cpuhotplug.txt b/Documentation/power/suspend-and-cpuhotplug.txt new file mode 100644 index 000000000000..f28f9a6f0347 --- /dev/null +++ b/Documentation/power/suspend-and-cpuhotplug.txt @@ -0,0 +1,275 @@ +Interaction of Suspend code (S3) with the CPU hotplug infrastructure + + (C) 2011 Srivatsa S. Bhat + + +I. How does the regular CPU hotplug code differ from how the Suspend-to-RAM + infrastructure uses it internally? And where do they share common code? + +Well, a picture is worth a thousand words... So ASCII art follows :-) + +[This depicts the current design in the kernel, and focusses only on the +interactions involving the freezer and CPU hotplug and also tries to explain +the locking involved. It outlines the notifications involved as well. +But please note that here, only the call paths are illustrated, with the aim +of describing where they take different paths and where they share code. +What happens when regular CPU hotplug and Suspend-to-RAM race with each other +is not depicted here.] + +On a high level, the suspend-resume cycle goes like this: + +|Freeze| -> |Disable nonboot| -> |Do suspend| -> |Enable nonboot| -> |Thaw | +|tasks | | cpus | | | | cpus | |tasks| + + +More details follow: + + Suspend call path + ----------------- + + Write 'mem' to + /sys/power/state + syfs file + | + v + Acquire pm_mutex lock + | + v + Send PM_SUSPEND_PREPARE + notifications + | + v + Freeze tasks + | + | + v + disable_nonboot_cpus() + /* start */ + | + v + Acquire cpu_add_remove_lock + | + v + Iterate over CURRENTLY + online CPUs + | + | + | ---------- + v | L + ======> _cpu_down() | + | [This takes cpuhotplug.lock | + Common | before taking down the CPU | + code | and releases it when done] | O + | While it is at it, notifications | + | are sent when notable events occur, | + ======> by running all registered callbacks. | + | | O + | | + | | + v | + Note down these cpus in | P + frozen_cpus mask ---------- + | + v + Disable regular cpu hotplug + by setting cpu_hotplug_disabled=1 + | + v + Release cpu_add_remove_lock + | + v + /* disable_nonboot_cpus() complete */ + | + v + Do suspend + + + +Resuming back is likewise, with the counterparts being (in the order of +execution during resume): +* enable_nonboot_cpus() which involves: + | Acquire cpu_add_remove_lock + | Reset cpu_hotplug_disabled to 0, thereby enabling regular cpu hotplug + | Call _cpu_up() [for all those cpus in the frozen_cpus mask, in a loop] + | Release cpu_add_remove_lock + v + +* thaw tasks +* send PM_POST_SUSPEND notifications +* Release pm_mutex lock. + + +It is to be noted here that the pm_mutex lock is acquired at the very +beginning, when we are just starting out to suspend, and then released only +after the entire cycle is complete (i.e., suspend + resume). + + + + Regular CPU hotplug call path + ----------------------------- + + Write 0 (or 1) to + /sys/devices/system/cpu/cpu*/online + sysfs file + | + | + v + cpu_down() + | + v + Acquire cpu_add_remove_lock + | + v + If cpu_hotplug_disabled is 1 + return gracefully + | + | + v + ======> _cpu_down() + | [This takes cpuhotplug.lock + Common | before taking down the CPU + code | and releases it when done] + | While it is at it, notifications + | are sent when notable events occur, + ======> by running all registered callbacks. + | + | + v + Release cpu_add_remove_lock + [That's it!, for + regular CPU hotplug] + + + +So, as can be seen from the two diagrams (the parts marked as "Common code"), +regular CPU hotplug and the suspend code path converge at the _cpu_down() and +_cpu_up() functions. They differ in the arguments passed to these functions, +in that during regular CPU hotplug, 0 is passed for the 'tasks_frozen' +argument. But during suspend, since the tasks are already frozen by the time +the non-boot CPUs are offlined or onlined, the _cpu_*() functions are called +with the 'tasks_frozen' argument set to 1. +[See below for some known issues regarding this.] + + +Important files and functions/entry points: +------------------------------------------ + +kernel/power/process.c : freeze_processes(), thaw_processes() +kernel/power/suspend.c : suspend_prepare(), suspend_enter(), suspend_finish() +kernel/cpu.c: cpu_[up|down](), _cpu_[up|down](), [disable|enable]_nonboot_cpus() + + + +II. What are the issues involved in CPU hotplug? + ------------------------------------------- + +There are some interesting situations involving CPU hotplug and microcode +update on the CPUs, as discussed below: + +[Please bear in mind that the kernel requests the microcode images from +userspace, using the request_firmware() function defined in +drivers/base/firmware_class.c] + + +a. When all the CPUs are identical: + + This is the most common situation and it is quite straightforward: we want + to apply the same microcode revision to each of the CPUs. + To give an example of x86, the collect_cpu_info() function defined in + arch/x86/kernel/microcode_core.c helps in discovering the type of the CPU + and thereby in applying the correct microcode revision to it. + But note that the kernel does not maintain a common microcode image for the + all CPUs, in order to handle case 'b' described below. + + +b. When some of the CPUs are different than the rest: + + In this case since we probably need to apply different microcode revisions + to different CPUs, the kernel maintains a copy of the correct microcode + image for each CPU (after appropriate CPU type/model discovery using + functions such as collect_cpu_info()). + + +c. When a CPU is physically hot-unplugged and a new (and possibly different + type of) CPU is hot-plugged into the system: + + In the current design of the kernel, whenever a CPU is taken offline during + a regular CPU hotplug operation, upon receiving the CPU_DEAD notification + (which is sent by the CPU hotplug code), the microcode update driver's + callback for that event reacts by freeing the kernel's copy of the + microcode image for that CPU. + + Hence, when a new CPU is brought online, since the kernel finds that it + doesn't have the microcode image, it does the CPU type/model discovery + afresh and then requests the userspace for the appropriate microcode image + for that CPU, which is subsequently applied. + + For example, in x86, the mc_cpu_callback() function (which is the microcode + update driver's callback registered for CPU hotplug events) calls + microcode_update_cpu() which would call microcode_init_cpu() in this case, + instead of microcode_resume_cpu() when it finds that the kernel doesn't + have a valid microcode image. This ensures that the CPU type/model + discovery is performed and the right microcode is applied to the CPU after + getting it from userspace. + + +d. Handling microcode update during suspend/hibernate: + + Strictly speaking, during a CPU hotplug operation which does not involve + physically removing or inserting CPUs, the CPUs are not actually powered + off during a CPU offline. They are just put to the lowest C-states possible. + Hence, in such a case, it is not really necessary to re-apply microcode + when the CPUs are brought back online, since they wouldn't have lost the + image during the CPU offline operation. + + This is the usual scenario encountered during a resume after a suspend. + However, in the case of hibernation, since all the CPUs are completely + powered off, during restore it becomes necessary to apply the microcode + images to all the CPUs. + + [Note that we don't expect someone to physically pull out nodes and insert + nodes with a different type of CPUs in-between a suspend-resume or a + hibernate/restore cycle.] + + In the current design of the kernel however, during a CPU offline operation + as part of the suspend/hibernate cycle (the CPU_DEAD_FROZEN notification), + the existing copy of microcode image in the kernel is not freed up. + And during the CPU online operations (during resume/restore), since the + kernel finds that it already has copies of the microcode images for all the + CPUs, it just applies them to the CPUs, avoiding any re-discovery of CPU + type/model and the need for validating whether the microcode revisions are + right for the CPUs or not (due to the above assumption that physical CPU + hotplug will not be done in-between suspend/resume or hibernate/restore + cycles). + + +III. Are there any known problems when regular CPU hotplug and suspend race + with each other? + +Yes, they are listed below: + +1. When invoking regular CPU hotplug, the 'tasks_frozen' argument passed to + the _cpu_down() and _cpu_up() functions is *always* 0. + This might not reflect the true current state of the system, since the + tasks could have been frozen by an out-of-band event such as a suspend + operation in progress. Hence, it will lead to wrong notifications being + sent during the cpu online/offline events (eg, CPU_ONLINE notification + instead of CPU_ONLINE_FROZEN) which in turn will lead to execution of + inappropriate code by the callbacks registered for such CPU hotplug events. + +2. If a regular CPU hotplug stress test happens to race with the freezer due + to a suspend operation in progress at the same time, then we could hit the + situation described below: + + * A regular cpu online operation continues its journey from userspace + into the kernel, since the freezing has not yet begun. + * Then freezer gets to work and freezes userspace. + * If cpu online has not yet completed the microcode update stuff by now, + it will now start waiting on the frozen userspace in the + TASK_UNINTERRUPTIBLE state, in order to get the microcode image. + * Now the freezer continues and tries to freeze the remaining tasks. But + due to this wait mentioned above, the freezer won't be able to freeze + the cpu online hotplug task and hence freezing of tasks fails. + + As a result of this task freezing failure, the suspend operation gets + aborted. -- cgit 1.4.1 From e9db50b839c592fcd22952d7f1dccbd0a56da57d Mon Sep 17 00:00:00 2001 From: "Srivatsa S. Bhat" Date: Thu, 3 Nov 2011 00:59:52 +0100 Subject: PM / Sleep: Update freezer documentation This patch: * Substitutes some obsolete references to kernel/power/process.c by kernel/freezer.c. * Mentions kernel/freezer.c as being part of the "freezer" code along with the rest of the files. * Fixes a trivial typo. Signed-off-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki --- Documentation/power/freezing-of-tasks.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation/power') diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt index 38b57248fd61..316c2ba187f4 100644 --- a/Documentation/power/freezing-of-tasks.txt +++ b/Documentation/power/freezing-of-tasks.txt @@ -22,12 +22,12 @@ try_to_freeze_tasks() that sets TIF_FREEZE for all of the freezable tasks and either wakes them up, if they are kernel threads, or sends fake signals to them, if they are user space processes. A task that has TIF_FREEZE set, should react to it by calling the function called refrigerator() (defined in -kernel/power/process.c), which sets the task's PF_FROZEN flag, changes its state +kernel/freezer.c), which sets the task's PF_FROZEN flag, changes its state to TASK_UNINTERRUPTIBLE and makes it loop until PF_FROZEN is cleared for it. Then, we say that the task is 'frozen' and therefore the set of functions handling this mechanism is referred to as 'the freezer' (these functions are -defined in kernel/power/process.c and include/linux/freezer.h). User space -processes are generally frozen before kernel threads. +defined in kernel/power/process.c, kernel/freezer.c & include/linux/freezer.h). +User space processes are generally frozen before kernel threads. It is not recommended to call refrigerator() directly. Instead, it is recommended to use the try_to_freeze() function (defined in @@ -95,7 +95,7 @@ after the memory for the image has been freed, we don't want tasks to allocate additional memory and we prevent them from doing that by freezing them earlier. [Of course, this also means that device drivers should not allocate substantial amounts of memory from their .suspend() callbacks before hibernation, but this -is e separate issue.] +is a separate issue.] 3. The third reason is to prevent user space processes and some kernel threads from interfering with the suspending and resuming of devices. A user space -- cgit 1.4.1 From 886486b792e4f6f96d4fbe8ec5bf20811cab7d6a Mon Sep 17 00:00:00 2001 From: Alan Stern Date: Thu, 3 Nov 2011 23:39:18 +0100 Subject: PM / Runtime: Automatically retry failed autosuspends Originally, the runtime PM core would send an idle notification whenever a suspend attempt failed. The idle callback routine could then schedule a delayed suspend for some time later. However this behavior was changed by commit f71648d73c1650b8b4aceb3856bebbde6daa3b86 (PM / Runtime: Remove idle notification after failing suspend). No notifications were sent, and there was no clear mechanism to retry failed suspends. This caused problems for the usbhid driver, because it fails autosuspend attempts as long as a key is being held down. Therefore this patch (as1492) adds a mechanism for retrying failed autosuspends. If the callback routine updates the last_busy field so that the next autosuspend expiration time is in the future, the autosuspend will automatically be rescheduled. Signed-off-by: Alan Stern Tested-by: Henrik Rydberg Cc: Signed-off-by: Rafael J. Wysocki --- Documentation/power/runtime_pm.txt | 10 ++++++++++ drivers/base/power/runtime.c | 18 ++++++++++++++++-- 2 files changed, 26 insertions(+), 2 deletions(-) (limited to 'Documentation/power') diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 0e856088db7c..5336149f831b 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -789,6 +789,16 @@ will behave normally, not taking the autosuspend delay into account. Similarly, if the power.use_autosuspend field isn't set then the autosuspend helper functions will behave just like the non-autosuspend counterparts. +Under some circumstances a driver or subsystem may want to prevent a device +from autosuspending immediately, even though the usage counter is zero and the +autosuspend delay time has expired. If the ->runtime_suspend() callback +returns -EAGAIN or -EBUSY, and if the next autosuspend delay expiration time is +in the future (as it normally would be if the callback invoked +pm_runtime_mark_last_busy()), the PM core will automatically reschedule the +autosuspend. The ->runtime_suspend() callback can't do this rescheduling +itself because no suspend requests of any kind are accepted while the device is +suspending (i.e., while the callback is running). + The implementation is well suited for asynchronous use in interrupt contexts. However such use inevitably involves races, because the PM core can't synchronize ->runtime_suspend() callbacks with the arrival of I/O requests. diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c index 18ef87e525fa..124dbf60c9bf 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c @@ -293,6 +293,9 @@ static int rpm_callback(int (*cb)(struct device *), struct device *dev) * the callback was running then carry it out, otherwise send an idle * notification for its parent (if the suspend succeeded and both * ignore_children of parent->power and irq_safe of dev->power are not set). + * If ->runtime_suspend failed with -EAGAIN or -EBUSY, and if the RPM_AUTO + * flag is set and the next autosuspend-delay expiration time is in the + * future, schedule another autosuspend attempt. * * This function must be called under dev->power.lock with interrupts disabled. */ @@ -413,10 +416,21 @@ static int rpm_suspend(struct device *dev, int rpmflags) if (retval) { __update_runtime_status(dev, RPM_ACTIVE); dev->power.deferred_resume = false; - if (retval == -EAGAIN || retval == -EBUSY) + if (retval == -EAGAIN || retval == -EBUSY) { dev->power.runtime_error = 0; - else + + /* + * If the callback routine failed an autosuspend, and + * if the last_busy time has been updated so that there + * is a new autosuspend expiration time, automatically + * reschedule another autosuspend. + */ + if ((rpmflags & RPM_AUTO) && + pm_runtime_autosuspend_expiration(dev) != 0) + goto repeat; + } else { pm_runtime_cancel_pending(dev); + } wake_up_all(&dev->power.wait_queue); goto out; } -- cgit 1.4.1