diff options
Diffstat (limited to 'Documentation')
124 files changed, 3805 insertions, 1151 deletions
diff --git a/Documentation/ABI/obsolete/proc-pid-oom_adj b/Documentation/ABI/obsolete/proc-pid-oom_adj index cf63f264ce0f..9a3cb88ade47 100644 --- a/Documentation/ABI/obsolete/proc-pid-oom_adj +++ b/Documentation/ABI/obsolete/proc-pid-oom_adj @@ -14,7 +14,7 @@ Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's A much more powerful interface, /proc/<pid>/oom_score_adj, was introduced with the oom killer rewrite that allows users to increase or - decrease the badness() score linearly. This interface will replace + decrease the badness score linearly. This interface will replace /proc/<pid>/oom_adj. A warning will be emitted to the kernel log if an application uses this diff --git a/Documentation/ABI/stable/firewire-cdev b/Documentation/ABI/stable/firewire-cdev new file mode 100644 index 000000000000..16d030827368 --- /dev/null +++ b/Documentation/ABI/stable/firewire-cdev @@ -0,0 +1,103 @@ +What: /dev/fw[0-9]+ +Date: May 2007 +KernelVersion: 2.6.22 +Contact: linux1394-devel@lists.sourceforge.net +Description: + The character device files /dev/fw* are the interface between + firewire-core and IEEE 1394 device drivers implemented in + userspace. The ioctl(2)- and read(2)-based ABI is defined and + documented in <linux/firewire-cdev.h>. + + This ABI offers most of the features which firewire-core also + exposes to kernelspace IEEE 1394 drivers. + + Each /dev/fw* is associated with one IEEE 1394 node, which can + be remote or local nodes. Operations on a /dev/fw* file have + different scope: + - The 1394 node which is associated with the file: + - Asynchronous request transmission + - Get the Configuration ROM + - Query node ID + - Query maximum speed of the path between this node + and local node + - The 1394 bus (i.e. "card") to which the node is attached to: + - Isochronous stream transmission and reception + - Asynchronous stream transmission and reception + - Asynchronous broadcast request transmission + - PHY packet transmission and reception + - Allocate, reallocate, deallocate isochronous + resources (channels, bandwidth) at the bus's IRM + - Query node IDs of local node, root node, IRM, bus + manager + - Query cycle time + - Bus reset initiation, bus reset event reception + - All 1394 buses: + - Allocation of IEEE 1212 address ranges on the local + link layers, reception of inbound requests to such + an address range, asynchronous response transmission + to inbound requests + - Addition of descriptors or directories to the local + nodes' Configuration ROM + + Due to the different scope of operations and in order to let + userland implement different access permission models, some + operations are restricted to /dev/fw* files that are associated + with a local node: + - Addition of descriptors or directories to the local + nodes' Configuration ROM + - PHY packet transmission and reception + + A /dev/fw* file remains associated with one particular node + during its entire life time. Bus topology changes, and hence + node ID changes, are tracked by firewire-core. ABI users do not + need to be aware of topology. + + The following file operations are supported: + + open(2) + Currently the only useful flags are O_RDWR. + + ioctl(2) + Initiate various actions. Some take immediate effect, others + are performed asynchronously while or after the ioctl returns. + See the inline documentation in <linux/firewire-cdev.h> for + descriptions of all ioctls. + + poll(2), select(2), epoll_wait(2) etc. + Watch for events to become available to be read. + + read(2) + Receive various events. There are solicited events like + outbound asynchronous transaction completion or isochronous + buffer completion, and unsolicited events such as bus resets, + request reception, or PHY packet reception. Always use a read + buffer which is large enough to receive the largest event that + could ever arrive. See <linux/firewire-cdev.h> for descriptions + of all event types and for which ioctls affect reception of + events. + + mmap(2) + Allocate a DMA buffer for isochronous reception or transmission + and map it into the process address space. The arguments should + be used as follows: addr = NULL, length = the desired buffer + size, i.e. number of packets times size of largest packet, + prot = at least PROT_READ for reception and at least PROT_WRITE + for transmission, flags = MAP_SHARED, fd = the handle to the + /dev/fw*, offset = 0. + + Isochronous reception works in packet-per-buffer fashion except + for multichannel reception which works in buffer-fill mode. + + munmap(2) + Unmap the isochronous I/O buffer from the process address space. + + close(2) + Besides stopping and freeing I/O contexts that were associated + with the file descriptor, back out any changes to the local + nodes' Configuration ROM. Deallocate isochronous channels and + bandwidth at the IRM that were marked for kernel-assisted + re- and deallocation. + +Users: libraw1394 + libdc1394 + tools like jujuutils, fwhack, ... diff --git a/Documentation/ABI/stable/sysfs-bus-firewire b/Documentation/ABI/stable/sysfs-bus-firewire new file mode 100644 index 000000000000..3d484e5dc846 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-bus-firewire @@ -0,0 +1,122 @@ +What: /sys/bus/firewire/devices/fw[0-9]+/ +Date: May 2007 +KernelVersion: 2.6.22 +Contact: linux1394-devel@lists.sourceforge.net +Description: + IEEE 1394 node device attributes. + Read-only. Mutable during the node device's lifetime. + See IEEE 1212 for semantic definitions. + + config_rom + Contents of the Configuration ROM register. + Binary attribute; an array of host-endian u32. + + guid + The node's EUI-64 in the bus information block of + Configuration ROM. + Hexadecimal string representation of an u64. + + +What: /sys/bus/firewire/devices/fw[0-9]+/units +Date: June 2009 +KernelVersion: 2.6.31 +Contact: linux1394-devel@lists.sourceforge.net +Description: + IEEE 1394 node device attribute. + Read-only. Mutable during the node device's lifetime. + See IEEE 1212 for semantic definitions. + + units + Summary of all units present in an IEEE 1394 node. + Contains space-separated tuples of specifier_id and + version of each unit present in the node. Specifier_id + and version are hexadecimal string representations of + u24 of the respective unit directory entries. + Specifier_id and version within each tuple are separated + by a colon. + +Users: udev rules to set ownership and access permissions or ACLs of + /dev/fw[0-9]+ character device files + + +What: /sys/bus/firewire/devices/fw[0-9]+[.][0-9]+/ +Date: May 2007 +KernelVersion: 2.6.22 +Contact: linux1394-devel@lists.sourceforge.net +Description: + IEEE 1394 unit device attributes. + Read-only. Immutable during the unit device's lifetime. + See IEEE 1212 for semantic definitions. + + modalias + Same as MODALIAS in the uevent at device creation. + + rom_index + Offset of the unit directory within the parent device's + (node device's) Configuration ROM, in quadlets. + Decimal string representation. + + +What: /sys/bus/firewire/devices/*/ +Date: May 2007 +KernelVersion: 2.6.22 +Contact: linux1394-devel@lists.sourceforge.net +Description: + Attributes common to IEEE 1394 node devices and unit devices. + Read-only. Mutable during the node device's lifetime. + Immutable during the unit device's lifetime. + See IEEE 1212 for semantic definitions. + + These attributes are only created if the root directory of an + IEEE 1394 node or the unit directory of an IEEE 1394 unit + actually contains according entries. + + hardware_version + Hexadecimal string representation of an u24. + + hardware_version_name + Contents of a respective textual descriptor leaf. + + model + Hexadecimal string representation of an u24. + + model_name + Contents of a respective textual descriptor leaf. + + specifier_id + Hexadecimal string representation of an u24. + Mandatory in unit directories according to IEEE 1212. + + vendor + Hexadecimal string representation of an u24. + Mandatory in the root directory according to IEEE 1212. + + vendor_name + Contents of a respective textual descriptor leaf. + + version + Hexadecimal string representation of an u24. + Mandatory in unit directories according to IEEE 1212. + + +What: /sys/bus/firewire/drivers/sbp2/fw*/host*/target*/*:*:*:*/ieee1394_id + formerly + /sys/bus/ieee1394/drivers/sbp2/fw*/host*/target*/*:*:*:*/ieee1394_id +Date: Feb 2004 +KernelVersion: 2.6.4 +Contact: linux1394-devel@lists.sourceforge.net +Description: + SCSI target port identifier and logical unit identifier of a + logical unit of an SBP-2 target. The identifiers are specified + in SAM-2...SAM-4 annex A. They are persistent and world-wide + unique properties the SBP-2 attached target. + + Read-only attribute, immutable during the target's lifetime. + Format, as exposed by firewire-sbp2 since 2.6.22, May 2007: + Colon-separated hexadecimal string representations of + u64 EUI-64 : u24 directory_ID : u16 LUN + without 0x prefixes, without whitespace. The former sbp2 driver + (removed in 2.6.37 after being superseded by firewire-sbp2) used + a somewhat shorter format which was not as close to SAM. + +Users: udev rules to create /dev/disk/by-id/ symlinks diff --git a/Documentation/ABI/stable/vdso b/Documentation/ABI/stable/vdso new file mode 100644 index 000000000000..8a1cbb594497 --- /dev/null +++ b/Documentation/ABI/stable/vdso @@ -0,0 +1,27 @@ +On some architectures, when the kernel loads any userspace program it +maps an ELF DSO into that program's address space. This DSO is called +the vDSO and it often contains useful and highly-optimized alternatives +to real syscalls. + +These functions are called just like ordinary C function according to +your platform's ABI. Call them from a sensible context. (For example, +if you set CS on x86 to something strange, the vDSO functions are +within their rights to crash.) In addition, if you pass a bad +pointer to a vDSO function, you might get SIGSEGV instead of -EFAULT. + +To find the DSO, parse the auxiliary vector passed to the program's +entry point. The AT_SYSINFO_EHDR entry will point to the vDSO. + +The vDSO uses symbol versioning; whenever you request a symbol from the +vDSO, specify the version you are expecting. + +Programs that dynamically link to glibc will use the vDSO automatically. +Otherwise, you can use the reference parser in Documentation/vDSO/parse_vdso.c. + +Unless otherwise noted, the set of symbols with any given version and the +ABI of those symbols is considered stable. It may vary across architectures, +though. + +(As of this writing, this ABI documentation as been confirmed for x86_64. + The maintainers of the other vDSO-using architectures should confirm + that it is correct for their architecture.)
\ No newline at end of file diff --git a/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480 b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480 new file mode 100644 index 000000000000..9de269bb0ae5 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-i2c-devices-fsa9480 @@ -0,0 +1,21 @@ +What: /sys/bus/i2c/devices/.../device +Date: February 2011 +Contact: Minkyu Kang <mk7.kang@samsung.com> +Description: + show what device is attached + NONE - no device + USB - USB device is attached + UART - UART is attached + CHARGER - Charger is attaced + JIG - JIG is attached + +What: /sys/bus/i2c/devices/.../switch +Date: February 2011 +Contact: Minkyu Kang <mk7.kang@samsung.com> +Description: + show or set the state of manual switch + VAUDIO - switch to VAUDIO path + UART - switch to UART path + AUDIO - switch to AUDIO path + DHOST - switch to DHOST path + AUTO - switch automatically by device diff --git a/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 b/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 new file mode 100644 index 000000000000..aa11dbdd794b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-backlight-driver-adp8870 @@ -0,0 +1,56 @@ +What: /sys/class/backlight/<backlight>/<ambient light zone>_max +What: /sys/class/backlight/<backlight>/l1_daylight_max +What: /sys/class/backlight/<backlight>/l2_bright_max +What: /sys/class/backlight/<backlight>/l3_office_max +What: /sys/class/backlight/<backlight>/l4_indoor_max +What: /sys/class/backlight/<backlight>/l5_dark_max +Date: Mai 2011 +KernelVersion: 2.6.40 +Contact: device-drivers-devel@blackfin.uclinux.org +Description: + Control the maximum brightness for <ambient light zone> + on this <backlight>. Values are between 0 and 127. This file + will also show the brightness level stored for this + <ambient light zone>. + +What: /sys/class/backlight/<backlight>/<ambient light zone>_dim +What: /sys/class/backlight/<backlight>/l2_bright_dim +What: /sys/class/backlight/<backlight>/l3_office_dim +What: /sys/class/backlight/<backlight>/l4_indoor_dim +What: /sys/class/backlight/<backlight>/l5_dark_dim +Date: Mai 2011 +KernelVersion: 2.6.40 +Contact: device-drivers-devel@blackfin.uclinux.org +Description: + Control the dim brightness for <ambient light zone> + on this <backlight>. Values are between 0 and 127, typically + set to 0. Full off when the backlight is disabled. + This file will also show the dim brightness level stored for + this <ambient light zone>. + +What: /sys/class/backlight/<backlight>/ambient_light_level +Date: Mai 2011 +KernelVersion: 2.6.40 +Contact: device-drivers-devel@blackfin.uclinux.org +Description: + Get conversion value of the light sensor. + This value is updated every 80 ms (when the light sensor + is enabled). Returns integer between 0 (dark) and + 8000 (max ambient brightness) + +What: /sys/class/backlight/<backlight>/ambient_light_zone +Date: Mai 2011 +KernelVersion: 2.6.40 +Contact: device-drivers-devel@blackfin.uclinux.org +Description: + Get/Set current ambient light zone. Reading returns + integer between 1..5 (1 = daylight, 2 = bright, ..., 5 = dark). + Writing a value between 1..5 forces the backlight controller + to enter the corresponding ambient light zone. + Writing 0 returns to normal/automatic ambient light level + operation. The ambient light sensing feature on these devices + is an extension to the API documented in + Documentation/ABI/stable/sysfs-class-backlight. + It can be enabled by writing the value stored in + /sys/class/backlight/<backlight>/max_brightness to + /sys/class/backlight/<backlight>/brightness.
\ No newline at end of file diff --git a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus index c1b53b8bc2ae..65e6e5dd67e8 100644 --- a/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus +++ b/Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus @@ -92,6 +92,14 @@ Description: The mouse has a tracking- and a distance-control-unit. These This file is writeonly. Users: http://roccat.sourceforge.net +What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/talk +Date: May 2011 +Contact: Stefan Achatz <erazor_de@users.sourceforge.net> +Description: Used to active some easy* functions of the mouse from outside. + The data has to be 16 bytes long. + This file is writeonly. +Users: http://roccat.sourceforge.net + What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu Date: October 2010 Contact: Stefan Achatz <erazor_de@users.sourceforge.net> diff --git a/Documentation/ABI/testing/sysfs-driver-hid-wiimote b/Documentation/ABI/testing/sysfs-driver-hid-wiimote new file mode 100644 index 000000000000..5d5a16ea57c6 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-hid-wiimote @@ -0,0 +1,10 @@ +What: /sys/bus/hid/drivers/wiimote/<dev>/led1 +What: /sys/bus/hid/drivers/wiimote/<dev>/led2 +What: /sys/bus/hid/drivers/wiimote/<dev>/led3 +What: /sys/bus/hid/drivers/wiimote/<dev>/led4 +Date: July 2011 +KernelVersion: 3.1 +Contact: David Herrmann <dh.herrmann@googlemail.com> +Description: Make it possible to set/get current led state. Reading from it + returns 0 if led is off and 1 if it is on. Writing 0 to it + disables the led, writing 1 enables it. diff --git a/Documentation/ABI/testing/sysfs-module b/Documentation/ABI/testing/sysfs-module index cfcec3bffc0a..9489ea8e294c 100644 --- a/Documentation/ABI/testing/sysfs-module +++ b/Documentation/ABI/testing/sysfs-module @@ -10,3 +10,26 @@ KernelVersion: 2.6.35 Contact: masa-korg@dsn.okisemi.com Description: Write/read Option ROM data. + +What: /sys/module/ehci_hcd/drivers/.../uframe_periodic_max +Date: July 2011 +KernelVersion: 3.1 +Contact: Kirill Smelkov <kirr@mns.spb.ru> +Description: Maximum time allowed for periodic transfers per microframe (渭s) + + [ USB 2.0 sets maximum allowed time for periodic transfers per + microframe to be 80%, that is 100 microseconds out of 125 + microseconds (full microframe). + + However there are cases, when 80% max isochronous bandwidth is + too limiting. For example two video streams could require 110 + microseconds of isochronous bandwidth per microframe to work + together. ] + + Through this setting it is possible to raise the limit so that + the host controller would allow allocating more than 100 + microseconds of periodic bandwidth per microframe. + + Beware, non-standard modes are usually not thoroughly tested by + hardware designers, and the hardware can malfunction when this + setting differ from default 100. diff --git a/Documentation/Changes b/Documentation/Changes index 5f4828a034e3..b17580885273 100644 --- a/Documentation/Changes +++ b/Documentation/Changes @@ -2,13 +2,7 @@ Intro ===== This document is designed to provide a list of the minimum levels of -software necessary to run the 2.6 kernels, as well as provide brief -instructions regarding any other "Gotchas" users may encounter when -trying life on the Bleeding Edge. If upgrading from a pre-2.4.x -kernel, please consult the Changes file included with 2.4.x kernels for -additional information; most of that information will not be repeated -here. Basically, this document assumes that your system is already -functional and running at least 2.4.x kernels. +software necessary to run the 3.0 kernels. This document is originally based on my "Changes" file for 2.0.x kernels and therefore owes credit to the same people as that file (Jared Mauch, @@ -22,11 +16,10 @@ Upgrade to at *least* these software revisions before thinking you've encountered a bug! If you're unsure what version you're currently running, the suggested command should tell you. -Again, keep in mind that this list assumes you are already -functionally running a Linux 2.4 kernel. Also, not all tools are -necessary on all systems; obviously, if you don't have any ISDN -hardware, for example, you probably needn't concern yourself with -isdn4k-utils. +Again, keep in mind that this list assumes you are already functionally +running a Linux kernel. Also, not all tools are necessary on all +systems; obviously, if you don't have any ISDN hardware, for example, +you probably needn't concern yourself with isdn4k-utils. o Gnu C 3.2 # gcc --version o Gnu make 3.80 # make --version @@ -114,12 +107,12 @@ Ksymoops If the unthinkable happens and your kernel oopses, you may need the ksymoops tool to decode it, but in most cases you don't. -In the 2.6 kernel it is generally preferred to build the kernel with -CONFIG_KALLSYMS so that it produces readable dumps that can be used as-is -(this also produces better output than ksymoops). -If for some reason your kernel is not build with CONFIG_KALLSYMS and -you have no way to rebuild and reproduce the Oops with that option, then -you can still decode that Oops with ksymoops. +It is generally preferred to build the kernel with CONFIG_KALLSYMS so +that it produces readable dumps that can be used as-is (this also +produces better output than ksymoops). If for some reason your kernel +is not build with CONFIG_KALLSYMS and you have no way to rebuild and +reproduce the Oops with that option, then you can still decode that Oops +with ksymoops. Module-Init-Tools ----------------- @@ -261,8 +254,8 @@ needs to be recompiled or (preferably) upgraded. NFS-utils --------- -In 2.4 and earlier kernels, the nfs server needed to know about any -client that expected to be able to access files via NFS. This +In ancient (2.4 and earlier) kernels, the nfs server needed to know +about any client that expected to be able to access files via NFS. This information would be given to the kernel by "mountd" when the client mounted the filesystem, or by "exportfs" at system startup. exportfs would take information about active clients from /var/lib/nfs/rmtab. @@ -272,11 +265,11 @@ which is not always easy, particularly when trying to implement fail-over. Even when the system is working well, rmtab suffers from getting lots of old entries that never get removed. -With 2.6 we have the option of having the kernel tell mountd when it -gets a request from an unknown host, and mountd can give appropriate -export information to the kernel. This removes the dependency on -rmtab and means that the kernel only needs to know about currently -active clients. +With modern kernels we have the option of having the kernel tell mountd +when it gets a request from an unknown host, and mountd can give +appropriate export information to the kernel. This removes the +dependency on rmtab and means that the kernel only needs to know about +currently active clients. To enable this new functionality, you need to: diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 58b0bf917834..fa6e25b94a54 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -680,8 +680,8 @@ ones already enabled by DEBUG. Chapter 14: Allocating memory The kernel provides the following general purpose memory allocators: -kmalloc(), kzalloc(), kcalloc(), and vmalloc(). Please refer to the API -documentation for further information about them. +kmalloc(), kzalloc(), kcalloc(), vmalloc(), and vzalloc(). Please refer to +the API documentation for further information about them. The preferred form for passing a size of a struct is the following: diff --git a/Documentation/DMA-API-HOWTO.txt b/Documentation/DMA-API-HOWTO.txt index d568bc235bc0..a0b6250add79 100644 --- a/Documentation/DMA-API-HOWTO.txt +++ b/Documentation/DMA-API-HOWTO.txt @@ -613,13 +613,13 @@ to use the dma_sync_*() interfaces. pass_to_upper_layers(cp->rx_buf); make_and_setup_new_rx_buf(cp); } else { - /* Just sync the buffer and give it back - * to the card. + /* CPU should not write to + * DMA_FROM_DEVICE-mapped area, + * so dma_sync_single_for_device() is + * not needed here. It would be required + * for DMA_BIDIRECTIONAL mapping if + * the memory was modified. */ - dma_sync_single_for_device(&cp->dev, - cp->rx_dma, - cp->rx_len, - DMA_FROM_DEVICE); give_rx_buf_to_card(cp); } } diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index 8906648f962b..445289cd0e65 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -402,8 +402,9 @@ !Finclude/net/mac80211.h set_key_cmd !Finclude/net/mac80211.h ieee80211_key_conf !Finclude/net/mac80211.h ieee80211_key_flags -!Finclude/net/mac80211.h ieee80211_tkip_key_type -!Finclude/net/mac80211.h ieee80211_get_tkip_key +!Finclude/net/mac80211.h ieee80211_get_tkip_p1k +!Finclude/net/mac80211.h ieee80211_get_tkip_p1k_iv +!Finclude/net/mac80211.h ieee80211_get_tkip_p2k !Finclude/net/mac80211.h ieee80211_key_removed </chapter> diff --git a/Documentation/DocBook/kernel-hacking.tmpl b/Documentation/DocBook/kernel-hacking.tmpl index 7b3f49363413..07a9c48de5a2 100644 --- a/Documentation/DocBook/kernel-hacking.tmpl +++ b/Documentation/DocBook/kernel-hacking.tmpl @@ -409,7 +409,7 @@ cond_resched(); /* Will sleep */ <para> You should always compile your kernel - <symbol>CONFIG_DEBUG_SPINLOCK_SLEEP</symbol> on, and it will warn + <symbol>CONFIG_DEBUG_ATOMIC_SLEEP</symbol> on, and it will warn you if you break these rules. If you <emphasis>do</emphasis> break the rules, you will eventually lock up your box. </para> diff --git a/Documentation/DocBook/v4l/io.xml b/Documentation/DocBook/v4l/io.xml index 227e7ac45a06..c57d1ec6291c 100644 --- a/Documentation/DocBook/v4l/io.xml +++ b/Documentation/DocBook/v4l/io.xml @@ -210,7 +210,7 @@ for (i = 0; i < reqbuf.count; i++) <programlisting> &v4l2-requestbuffers; reqbuf; /* Our current format uses 3 planes per buffer */ -#define FMT_NUM_PLANES = 3; +#define FMT_NUM_PLANES = 3 struct { void *start[FMT_NUM_PLANES]; diff --git a/Documentation/RCU/NMI-RCU.txt b/Documentation/RCU/NMI-RCU.txt index a8536cb88091..bf82851a0e57 100644 --- a/Documentation/RCU/NMI-RCU.txt +++ b/Documentation/RCU/NMI-RCU.txt @@ -5,8 +5,8 @@ Although RCU is usually used to protect read-mostly data structures, it is possible to use RCU to provide dynamic non-maskable interrupt handlers, as well as dynamic irq handlers. This document describes how to do this, drawing loosely from Zwane Mwaikambo's NMI-timer -work in "arch/i386/oprofile/nmi_timer_int.c" and in -"arch/i386/kernel/traps.c". +work in "arch/x86/oprofile/nmi_timer_int.c" and in +"arch/x86/kernel/traps.c". The relevant pieces of code are listed below, each followed by a brief explanation. diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist index da0382daa395..dc0e33210d7e 100644 --- a/Documentation/SubmitChecklist +++ b/Documentation/SubmitChecklist @@ -53,8 +53,8 @@ kernel patches. 12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, - CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP all simultaneously - enabled. + CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_ATOMIC_SLEEP, CONFIG_PROVE_RCU + and CONFIG_DEBUG_OBJECTS_RCU_HEAD all simultaneously enabled. 13: Has been build- and runtime tested with and without CONFIG_SMP and CONFIG_PREEMPT. diff --git a/Documentation/accounting/cgroupstats.txt b/Documentation/accounting/cgroupstats.txt index eda40fd39cad..d16a9849e60e 100644 --- a/Documentation/accounting/cgroupstats.txt +++ b/Documentation/accounting/cgroupstats.txt @@ -21,7 +21,7 @@ information will not be available. To extract cgroup statistics a utility very similar to getdelays.c has been developed, the sample output of the utility is shown below -~/balbir/cgroupstats # ./getdelays -C "/cgroup/a" +~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup/a" sleeping 1, blocked 0, running 1, stopped 0, uninterruptible 0 -~/balbir/cgroupstats # ./getdelays -C "/cgroup" +~/balbir/cgroupstats # ./getdelays -C "/sys/fs/cgroup" sleeping 155, blocked 0, running 1, stopped 0, uninterruptible 2 diff --git a/Documentation/arm/Booting b/Documentation/arm/Booting index 4e686a2ed91e..a341d87d276e 100644 --- a/Documentation/arm/Booting +++ b/Documentation/arm/Booting @@ -164,3 +164,8 @@ In either case, the following conditions must be met: - The boot loader is expected to call the kernel image by jumping directly to the first instruction of the kernel image. + On CPUs supporting the ARM instruction set, the entry must be + made in ARM state, even for a Thumb-2 kernel. + + On CPUs supporting only the Thumb instruction set such as + Cortex-M class CPUs, the entry must be made in Thumb state. diff --git a/Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt b/Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt new file mode 100644 index 000000000000..441959846e1a --- /dev/null +++ b/Documentation/arm/SH-Mobile/zboot-rom-sdhi.txt @@ -0,0 +1,42 @@ +ROM-able zImage boot from eSD +----------------------------- + +An ROM-able zImage compiled with ZBOOT_ROM_SDHI may be written to eSD and +SuperH Mobile ARM will to boot directly from the SDHI hardware block. + +This is achieved by the mask ROM loading the first portion of the image into +MERAM and then jumping to it. This portion contains loader code which +copies the entire image to SDRAM and jumps to it. From there the zImage +boot code proceeds as normal, uncompressing the image into its final +location and then jumping to it. + +This code has been tested on an mackerel board using the developer 1A eSD +boot mode which is configured using the following jumper settings. + + 8 7 6 5 4 3 2 1 + x|x|x|x| |x|x| +S4 -+-+-+-+-+-+-+- + | | | |x| | |x on + +The eSD card needs to be present in SDHI slot 1 (CN7). +As such S1 and S33 also need to be configured as per +the notes in arch/arm/mach-shmobile/board-mackerel.c. + +A partial zImage must be written to physical partition #1 (boot) +of the eSD at sector 0 in vrl4 format. A utility vrl4 is supplied to +accomplish this. + +e.g. + vrl4 < zImage | dd of=/dev/sdX bs=512 count=17 + +A full copy of _the same_ zImage should be written to physical partition #1 +(boot) of the eSD at sector 0. This should _not_ be in vrl4 format. + + vrl4 < zImage | dd of=/dev/sdX bs=512 + +Note: The commands above assume that the physical partition has been +switched. No such facility currently exists in the Linux Kernel. + +Physical partitions are described in the eSD specification. At the time of +writing they are not the same as partitions that are typically configured +using fdisk and visible through /proc/partitions diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt index c12bfc1a00c9..359587b2367b 100644 --- a/Documentation/arm/Samsung-S3C24XX/Overview.txt +++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt @@ -8,10 +8,13 @@ Introduction The Samsung S3C24XX range of ARM9 System-on-Chip CPUs are supported by the 's3c2410' architecture of ARM Linux. Currently the S3C2410, - S3C2412, S3C2413, S3C2416 S3C2440, S3C2442, S3C2443 and S3C2450 devices + S3C2412, S3C2413, S3C2416, S3C2440, S3C2442, S3C2443 and S3C2450 devices are supported. - Support for the S3C2400 and S3C24A0 series are in progress. + Support for the S3C2400 and S3C24A0 series was never completed and the + corresponding code has been removed after a while. If someone wishes to + revive this effort, partial support can be retrieved from earlier Linux + versions. The S3C2416 and S3C2450 devices are very similar and S3C2450 support is included under the arch/arm/mach-s3c2416 directory. Note, whilst core diff --git a/Documentation/arm/kernel_user_helpers.txt b/Documentation/arm/kernel_user_helpers.txt new file mode 100644 index 000000000000..a17df9f91d16 --- /dev/null +++ b/Documentation/arm/kernel_user_helpers.txt @@ -0,0 +1,267 @@ +Kernel-provided User Helpers +============================ + +These are segment of kernel provided user code reachable from user space +at a fixed address in kernel memory. This is used to provide user space +with some operations which require kernel help because of unimplemented +native feature and/or instructions in many ARM CPUs. The idea is for this +code to be executed directly in user mode for best efficiency but which is +too intimate with the kernel counter part to be left to user libraries. +In fact this code might even differ from one CPU to another depending on +the available instruction set, or whether it is a SMP systems. In other +words, the kernel reserves the right to change this code as needed without +warning. Only the entry points and their results as documented here are +guaranteed to be stable. + +This is different from (but doesn't preclude) a full blown VDSO +implementation, however a VDSO would prevent some assembly tricks with +constants that allows for efficient branching to those code segments. And +since those code segments only use a few cycles before returning to user +code, the overhead of a VDSO indirect far call would add a measurable +overhead to such minimalistic operations. + +User space is expected to bypass those helpers and implement those things +inline (either in the code emitted directly by the compiler, or part of +the implementation of a library call) when optimizing for a recent enough +processor that has the necessary native support, but only if resulting +binaries are already to be incompatible with earlier ARM processors due to +useage of similar native instructions for other things. In other words +don't make binaries unable to run on earlier processors just for the sake +of not using these kernel helpers if your compiled code is not going to +use new instructions for other purpose. + +New helpers may be added over time, so an older kernel may be missing some +helpers present in a newer kernel. For this reason, programs must check +the value of __kuser_helper_version (see below) before assuming that it is +safe to call any particular helper. This check should ideally be +performed only once at process startup time, and execution aborted early +if the required helpers are not provided by the kernel version that +process is running on. + +kuser_helper_version +-------------------- + +Location: 0xffff0ffc + +Reference declaration: + + extern int32_t __kuser_helper_version; + +Definition: + + This field contains the number of helpers being implemented by the + running kernel. User space may read this to determine the availability + of a particular helper. + +Usage example: + +#define __kuser_helper_version (*(int32_t *)0xffff0ffc) + +void check_kuser_version(void) +{ + if (__kuser_helper_version < 2) { + fprintf(stderr, "can't do atomic operations, kernel too old\n"); + abort(); + } +} + +Notes: + + User space may assume that the value of this field never changes + during the lifetime of any single process. This means that this + field can be read once during the initialisation of a library or + startup phase of a program. + +kuser_get_tls +------------- + +Location: 0xffff0fe0 + +Reference prototype: + + void * __kuser_get_tls(void); + +Input: + + lr = return address + +Output: + + r0 = TLS value + +Clobbered registers: + + none + +Definition: + + Get the TLS value as previously set via the __ARM_NR_set_tls syscall. + +Usage example: + +typedef void * (__kuser_get_tls_t)(void); +#define __kuser_get_tls (*(__kuser_get_tls_t *)0xffff0fe0) + +void foo() +{ + void *tls = __kuser_get_tls(); + printf("TLS = %p\n", tls); +} + +Notes: + + - Valid only if __kuser_helper_version >= 1 (from kernel version 2.6.12). + +kuser_cmpxchg +------------- + +Location: 0xffff0fc0 + +Reference prototype: + + int __kuser_cmpxchg(int32_t oldval, int32_t newval, volatile int32_t *ptr); + +Input: + + r0 = oldval + r1 = newval + r2 = ptr + lr = return address + +Output: + + r0 = success code (zero or non-zero) + C flag = set if r0 == 0, clear if r0 != 0 + +Clobbered registers: + + r3, ip, flags + +Definition: + + Atomically store newval in *ptr only if *ptr is equal to oldval. + Return zero if *ptr was changed or non-zero if no exchange happened. + The C flag is also set if *ptr was changed to allow for assembly + optimization in the calling code. + +Usage example: + +typedef int (__kuser_cmpxchg_t)(int oldval, int newval, volatile int *ptr); +#define __kuser_cmpxchg (*(__kuser_cmpxchg_t *)0xffff0fc0) + +int atomic_add(volatile int *ptr, int val) +{ + int old, new; + + do { + old = *ptr; + new = old + val; + } while(__kuser_cmpxchg(old, new, ptr)); + + return new; +} + +Notes: + + - This routine already includes memory barriers as needed. + + - Valid only if __kuser_helper_version >= 2 (from kernel version 2.6.12). + +kuser_memory_barrier +-------------------- + +Location: 0xffff0fa0 + +Reference prototype: + + void __kuser_memory_barrier(void); + +Input: + + lr = return address + +Output: + + none + +Clobbered registers: + + none + +Definition: + + Apply any needed memory barrier to preserve consistency with data modified + manually and __kuser_cmpxchg usage. + +Usage example: + +typedef void (__kuser_dmb_t)(void); +#define __kuser_dmb (*(__kuser_dmb_t *)0xffff0fa0) + +Notes: + + - Valid only if __kuser_helper_version >= 3 (from kernel version 2.6.15). + +kuser_cmpxchg64 +--------------- + +Location: 0xffff0f60 + +Reference prototype: + + int __kuser_cmpxchg64(const int64_t *oldval, + const int64_t *newval, + volatile int64_t *ptr); + +Input: + + r0 = pointer to oldval + r1 = pointer to newval + r2 = pointer to target value + lr = return address + +Output: + + r0 = success code (zero or non-zero) + C flag = set if r0 == 0, clear if r0 != 0 + +Clobbered registers: + + r3, lr, flags + +Definition: + + Atomically store the 64-bit value pointed by *newval in *ptr only if *ptr + is equal to the 64-bit value pointed by *oldval. Return zero if *ptr was + changed or non-zero if no exchange happened. + + The C flag is also set if *ptr was changed to allow for assembly + optimization in the calling code. + +Usage example: + +typedef int (__kuser_cmpxchg64_t)(const int64_t *oldval, + const int64_t *newval, + volatile int64_t *ptr); +#define __kuser_cmpxchg64 (*(__kuser_cmpxchg64_t *)0xffff0f60) + +int64_t atomic_add64(volatile int64_t *ptr, int64_t val) +{ + int64_t old, new; + + do { + old = *ptr; + new = old + val; + } while(__kuser_cmpxchg64(&old, &new, ptr)); + + return new; +} + +Notes: + + - This routine already includes memory barriers as needed. + + - Due to the length of this sequence, this spans 2 conventional kuser + "slots", therefore 0xffff0f80 is not used as a valid entry point. + + - Valid only if __kuser_helper_version >= 5 (from kernel version 3.1). diff --git a/Documentation/blackfin/bfin-spi-notes.txt b/Documentation/blackfin/bfin-spi-notes.txt index 556fa877f2e8..eae6eaf2a09d 100644 --- a/Documentation/blackfin/bfin-spi-notes.txt +++ b/Documentation/blackfin/bfin-spi-notes.txt @@ -9,6 +9,8 @@ the entire SPI transfer. - And not just bits_per_word duration. In most cases you can utilize SPI MODE_3 instead of MODE_0 to work-around this behavior. If your SPI slave device in question requires SPI MODE_0 or MODE_2 timing, you can utilize the GPIO controlled SPI Slave Select option instead. +In this case, you should use GPIO based CS for all of your slaves and not just +the ones using mode 0 or 2 in order to guarantee correct CS toggling behavior. You can even use the same pin whose peripheral role is a SSEL, but use it as a GPIO instead. diff --git a/Documentation/block/queue-sysfs.txt b/Documentation/block/queue-sysfs.txt index f65274081c8d..d8147b336c35 100644 --- a/Documentation/block/queue-sysfs.txt +++ b/Documentation/block/queue-sysfs.txt @@ -45,9 +45,13 @@ device. rq_affinity (RW) ---------------- -If this option is enabled, the block layer will migrate request completions -to the CPU that originally submitted the request. For some workloads -this provides a significant reduction in CPU cycles due to caching effects. +If this option is '1', the block layer will migrate request completions to the +cpu "group" that originally submitted the request. For some workloads this +provides a significant reduction in CPU cycles due to caching effects. + +For storage configurations that need to maximize distribution of completion +processing setting this option to '2' forces the completion to run on the +requesting cpu (bypassing the "group" aggregation logic). scheduler (RW) -------------- diff --git a/Documentation/blockdev/README.DAC960 b/Documentation/blockdev/README.DAC960 index 0e8f618ab534..bd85fb9dc6e5 100644 --- a/Documentation/blockdev/README.DAC960 +++ b/Documentation/blockdev/README.DAC960 @@ -214,7 +214,7 @@ replacing "/usr/src" with wherever you keep your Linux kernel source tree: make config make bzImage (or zImage) -Then install "arch/i386/boot/bzImage" or "arch/i386/boot/zImage" as your +Then install "arch/x86/boot/bzImage" or "arch/x86/boot/zImage" as your standard kernel, run lilo if appropriate, and reboot. To create the necessary devices in /dev, the "make_rd" script included in diff --git a/Documentation/blockdev/ramdisk.txt b/Documentation/blockdev/ramdisk.txt index 6c820baa19a6..fa72e97dd669 100644 --- a/Documentation/blockdev/ramdisk.txt +++ b/Documentation/blockdev/ramdisk.txt @@ -64,9 +64,9 @@ the RAM disk dynamically grows as data is being written into it, a size field is not required. Bits 11 to 13 are not currently used and may as well be zero. These numbers are no magical secrets, as seen below: -./arch/i386/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK 0x07FF -./arch/i386/kernel/setup.c:#define RAMDISK_PROMPT_FLAG 0x8000 -./arch/i386/kernel/setup.c:#define RAMDISK_LOAD_FLAG 0x4000 +./arch/x86/kernel/setup.c:#define RAMDISK_IMAGE_START_MASK 0x07FF +./arch/x86/kernel/setup.c:#define RAMDISK_PROMPT_FLAG 0x8000 +./arch/x86/kernel/setup.c:#define RAMDISK_LOAD_FLAG 0x4000 Consider a typical two floppy disk setup, where you will have the kernel on disk one, and have already put a RAM disk image onto disk #2. @@ -85,7 +85,7 @@ The command line equivalent is: "prompt_ramdisk=1" Putting that together gives 2^15 + 2^14 + 0 = 49152 for an rdev word. So to create disk one of the set, you would do: - /usr/src/linux# cat arch/i386/boot/zImage > /dev/fd0 + /usr/src/linux# cat arch/x86/boot/zImage > /dev/fd0 /usr/src/linux# rdev /dev/fd0 /dev/fd0 /usr/src/linux# rdev -r /dev/fd0 49152 diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index 465351d4cf85..84f0a15fc210 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt @@ -28,16 +28,19 @@ cgroups. Here is what you can do. - Enable group scheduling in CFQ CONFIG_CFQ_GROUP_IOSCHED=y -- Compile and boot into kernel and mount IO controller (blkio). +- Compile and boot into kernel and mount IO controller (blkio); see + cgroups.txt, Why are cgroups needed?. - mount -t cgroup -o blkio none /cgroup + mount -t tmpfs cgroup_root /sys/fs/cgroup + mkdir /sys/fs/cgroup/blkio + mount -t cgroup -o blkio none /sys/fs/cgroup/blkio - Create two cgroups - mkdir -p /cgroup/test1/ /cgroup/test2 + mkdir -p /sys/fs/cgroup/blkio/test1/ /sys/fs/cgroup/blkio/test2 - Set weights of group test1 and test2 - echo 1000 > /cgroup/test1/blkio.weight - echo 500 > /cgroup/test2/blkio.weight + echo 1000 > /sys/fs/cgroup/blkio/test1/blkio.weight + echo 500 > /sys/fs/cgroup/blkio/test2/blkio.weight - Create two same size files (say 512MB each) on same disk (file1, file2) and launch two dd threads in different cgroup to read those files. @@ -46,12 +49,12 @@ cgroups. Here is what you can do. echo 3 > /proc/sys/vm/drop_caches dd if=/mnt/sdb/zerofile1 of=/dev/null & - echo $! > /cgroup/test1/tasks - cat /cgroup/test1/tasks + echo $! > /sys/fs/cgroup/blkio/test1/tasks + cat /sys/fs/cgroup/blkio/test1/tasks dd if=/mnt/sdb/zerofile2 of=/dev/null & - echo $! > /cgroup/test2/tasks - cat /cgroup/test2/tasks + echo $! > /sys/fs/cgroup/blkio/test2/tasks + cat /sys/fs/cgroup/blkio/test2/tasks - At macro level, first dd should finish first. To get more precise data, keep on looking at (with the help of script), at blkio.disk_time and @@ -68,13 +71,13 @@ Throttling/Upper Limit policy - Enable throttling in block layer CONFIG_BLK_DEV_THROTTLING=y -- Mount blkio controller - mount -t cgroup -o blkio none /cgroup/blkio +- Mount blkio controller (see cgroups.txt, Why are cgroups needed?) + mount -t cgroup -o blkio none /sys/fs/cgroup/blkio - Specify a bandwidth rate on particular device for root group. The format for policy is "<major>:<minor> <byes_per_second>". - echo "8:16 1048576" > /cgroup/blkio/blkio.read_bps_device + echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device Above will put a limit of 1MB/second on reads happening for root group on device having major/minor number 8:16. @@ -87,7 +90,7 @@ Throttling/Upper Limit policy 1024+0 records out 4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s - Limits for writes can be put using blkio.write_bps_device file. + Limits for writes can be put using blkio.throttle.write_bps_device file. Hierarchical Cgroups ==================== @@ -108,7 +111,7 @@ Hierarchical Cgroups CFQ and throttling will practically treat all groups at same level. pivot - / | \ \ + / / \ \ root test1 test2 test3 Down the line we can implement hierarchical accounting/control support @@ -149,7 +152,7 @@ Proportional weight policy files Following is the format. - #echo dev_maj:dev_minor weight > /path/to/cgroup/blkio.weight_device + # echo dev_maj:dev_minor weight > blkio.weight_device Configure weight=300 on /dev/sdb (8:16) in this cgroup # echo 8:16 300 > blkio.weight_device # cat blkio.weight_device @@ -283,28 +286,28 @@ Throttling/Upper limit policy files specified in bytes per second. Rules are per deivce. Following is the format. - echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.read_bps_device + echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.read_bps_device - blkio.throttle.write_bps_device - Specifies upper limit on WRITE rate to the device. IO rate is specified in bytes per second. Rules are per deivce. Following is the format. - echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.write_bps_device + echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.write_bps_device - blkio.throttle.read_iops_device - Specifies upper limit on READ rate from the device. IO rate is specified in IO per second. Rules are per deivce. Following is the format. - echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.read_iops_device + echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.read_iops_device - blkio.throttle.write_iops_device - Specifies upper limit on WRITE rate to the device. IO rate is specified in io per second. Rules are per deivce. Following is the format. - echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.write_iops_device + echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.write_iops_device Note: If both BW and IOPS rules are specified for a device, then IO is subjectd to both the constraints. diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index 0ed99f08f1f3..cd67e90003c0 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -138,11 +138,11 @@ With the ability to classify tasks differently for different resources the admin can easily set up a script which receives exec notifications and depending on who is launching the browser he can - # echo browser_pid > /mnt/<restype>/<userclass>/tasks + # echo browser_pid > /sys/fs/cgroup/<restype>/<userclass>/tasks With only a single hierarchy, he now would potentially have to create a separate cgroup for every browser launched and associate it with -approp network and other resource class. This may lead to +appropriate network and other resource class. This may lead to proliferation of such cgroups. Also lets say that the administrator would like to give enhanced network @@ -153,9 +153,9 @@ apps enhanced CPU power, With ability to write pids directly to resource classes, it's just a matter of : - # echo pid > /mnt/network/<new_class>/tasks + # echo pid > /sys/fs/cgroup/network/<new_class>/tasks (after some time) - # echo pid > /mnt/network/<orig_class>/tasks + # echo pid > /sys/fs/cgroup/network/<orig_class>/tasks Without this ability, he would have to split the cgroup into multiple separate ones and then associate the new cgroups with the @@ -310,21 +310,24 @@ subsystem, this is the case for the cpuset. To start a new job that is to be contained within a cgroup, using the "cpuset" cgroup subsystem, the steps are something like: - 1) mkdir /dev/cgroup - 2) mount -t cgroup -ocpuset cpuset /dev/cgroup - 3) Create the new cgroup by doing mkdir's and write's (or echo's) in - the /dev/cgroup virtual file system. - 4) Start a task that will be the "founding father" of the new job. - 5) Attach that task to the new cgroup by writing its pid to the - /dev/cgroup tasks file for that cgroup. - 6) fork, exec or clone the job tasks from this founding father task. + 1) mount -t tmpfs cgroup_root /sys/fs/cgroup + 2) mkdir /sys/fs/cgroup/cpuset + 3) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset + 4) Create the new cgroup by doing mkdir's and write's (or echo's) in + the /sys/fs/cgroup virtual file system. + 5) Start a task that will be the "founding father" of the new job. + 6) Attach that task to the new cgroup by writing its pid to the + /sys/fs/cgroup/cpuset/tasks file for that cgroup. + 7) fork, exec or clone the job tasks from this founding father task. For example, the following sequence of commands will setup a cgroup named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, and then start a subshell 'sh' in that cgroup: - mount -t cgroup cpuset -ocpuset /dev/cgroup - cd /dev/cgroup + mount -t tmpfs cgroup_root /sys/fs/cgroup + mkdir /sys/fs/cgroup/cpuset + mount -t cgroup cpuset -ocpuset /sys/fs/cgroup/cpuset + cd /sys/fs/cgroup/cpuset mkdir Charlie cd Charlie /bin/echo 2-3 > cpuset.cpus @@ -345,7 +348,7 @@ Creating, modifying, using the cgroups can be done through the cgroup virtual filesystem. To mount a cgroup hierarchy with all available subsystems, type: -# mount -t cgroup xxx /dev/cgroup +# mount -t cgroup xxx /sys/fs/cgroup The "xxx" is not interpreted by the cgroup code, but will appear in /proc/mounts so may be any useful identifying string that you like. @@ -354,23 +357,32 @@ Note: Some subsystems do not work without some user input first. For instance, if cpusets are enabled the user will have to populate the cpus and mems files for each new cgroup created before that group can be used. +As explained in section `1.2 Why are cgroups needed?' you should create +different hierarchies of cgroups for each single resource or group of +resources you want to control. Therefore, you should mount a tmpfs on +/sys/fs/cgroup and create directories for each cgroup resource or resource +group. + +# mount -t tmpfs cgroup_root /sys/fs/cgroup +# mkdir /sys/fs/cgroup/rg1 + To mount a cgroup hierarchy with just the cpuset and memory subsystems, type: -# mount -t cgroup -o cpuset,memory hier1 /dev/cgroup +# mount -t cgroup -o cpuset,memory hier1 /sys/fs/cgroup/rg1 To change the set of subsystems bound to a mounted hierarchy, just remount with different options: -# mount -o remount,cpuset,blkio hier1 /dev/cgroup +# mount -o remount,cpuset,blkio hier1 /sys/fs/cgroup/rg1 Now memory is removed from the hierarchy and blkio is added. Note this will add blkio to the hierarchy but won't remove memory or cpuset, because the new options are appended to the old ones: -# mount -o remount,blkio /dev/cgroup +# mount -o remount,blkio /sys/fs/cgroup/rg1 To Specify a hierarchy's release_agent: # mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \ - xxx /dev/cgroup + xxx /sys/fs/cgroup/rg1 Note that specifying 'release_agent' more than once will return failure. @@ -379,17 +391,17 @@ when the hierarchy consists of a single (root) cgroup. Supporting the ability to arbitrarily bind/unbind subsystems from an existing cgroup hierarchy is intended to be implemented in the future. -Then under /dev/cgroup you can find a tree that corresponds to the -tree of the cgroups in the system. For instance, /dev/cgroup +Then under /sys/fs/cgroup/rg1 you can find a tree that corresponds to the +tree of the cgroups in the system. For instance, /sys/fs/cgroup/rg1 is the cgroup that holds the whole system. If you want to change the value of release_agent: -# echo "/sbin/new_release_agent" > /dev/cgroup/release_agent +# echo "/sbin/new_release_agent" > /sys/fs/cgroup/rg1/release_agent It can also be changed via remount. -If you want to create a new cgroup under /dev/cgroup: -# cd /dev/cgroup +If you want to create a new cgroup under /sys/fs/cgroup/rg1: +# cd /sys/fs/cgroup/rg1 # mkdir my_cgroup Now you want to do something with this cgroup. diff --git a/Documentation/cgroups/cpuacct.txt b/Documentation/cgroups/cpuacct.txt index 8b930946c52a..9d73cc0cadb9 100644 --- a/Documentation/cgroups/cpuacct.txt +++ b/Documentation/cgroups/cpuacct.txt @@ -10,26 +10,25 @@ directly present in its group. Accounting groups can be created by first mounting the cgroup filesystem. -# mkdir /cgroups -# mount -t cgroup -ocpuacct none /cgroups - -With the above step, the initial or the parent accounting group -becomes visible at /cgroups. At bootup, this group includes all the -tasks in the system. /cgroups/tasks lists the tasks in this cgroup. -/cgroups/cpuacct.usage gives the CPU time (in nanoseconds) obtained by -this group which is essentially the CPU time obtained by all the tasks +# mount -t cgroup -ocpuacct none /sys/fs/cgroup + +With the above step, the initial or the parent accounting group becomes +visible at /sys/fs/cgroup. At bootup, this group includes all the tasks in +the system. /sys/fs/cgroup/tasks lists the tasks in this cgroup. +/sys/fs/cgroup/cpuacct.usage gives the CPU time (in nanoseconds) obtained +by this group which is essentially the CPU time obtained by all the tasks in the system. -New accounting groups can be created under the parent group /cgroups. +New accounting groups can be created under the parent group /sys/fs/cgroup. -# cd /cgroups +# cd /sys/fs/cgroup # mkdir g1 -# echo $$ > g1 +# echo $$ > g1/tasks The above steps create a new group g1 and move the current shell process (bash) into it. CPU time consumed by this bash and its children can be obtained from g1/cpuacct.usage and the same is accumulated in -/cgroups/cpuacct.usage also. +/sys/fs/cgroup/cpuacct.usage also. cpuacct.stat file lists a few statistics which further divide the CPU time obtained by the cgroup into user and system times. Currently diff --git a/Documentation/cgroups/cpusets.txt b/Documentation/cgroups/cpusets.txt index 98a30829af7a..5c51ed406d1d 100644 --- a/Documentation/cgroups/cpusets.txt +++ b/Documentation/cgroups/cpusets.txt @@ -180,7 +180,7 @@ files describing that cpuset: - cpuset.sched_load_balance flag: if set, load balance within CPUs on that cpuset - cpuset.sched_relax_domain_level: the searching range when migrating tasks -In addition, the root cpuset only has the following file: +In addition, only the root cpuset has the following file: - cpuset.memory_pressure_enabled flag: compute memory_pressure? New cpusets are created using the mkdir system call or shell @@ -661,21 +661,21 @@ than stress the kernel. To start a new job that is to be contained within a cpuset, the steps are: - 1) mkdir /dev/cpuset - 2) mount -t cgroup -ocpuset cpuset /dev/cpuset + 1) mkdir /sys/fs/cgroup/cpuset + 2) mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset 3) Create the new cpuset by doing mkdir's and write's (or echo's) in - the /dev/cpuset virtual file system. + the /sys/fs/cgroup/cpuset virtual file system. 4) Start a task that will be the "founding father" of the new job. 5) Attach that task to the new cpuset by writing its pid to the - /dev/cpuset tasks file for that cpuset. + /sys/fs/cgroup/cpuset tasks file for that cpuset. 6) fork, exec or clone the job tasks from this founding father task. For example, the following sequence of commands will setup a cpuset named "Charlie", containing just CPUs 2 and 3, and Memory Node 1, and then start a subshell 'sh' in that cpuset: - mount -t cgroup -ocpuset cpuset /dev/cpuset - cd /dev/cpuset + mount -t cgroup -ocpuset cpuset /sys/fs/cgroup/cpuset + cd /sys/fs/cgroup/cpuset mkdir Charlie cd Charlie /bin/echo 2-3 > cpuset.cpus @@ -710,14 +710,14 @@ Creating, modifying, using the cpusets can be done through the cpuset virtual filesystem. To mount it, type: -# mount -t cgroup -o cpuset cpuset /dev/cpuset +# mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset -Then under /dev/cpuset you can find a tree that corresponds to the -tree of the cpusets in the system. For instance, /dev/cpuset +Then under /sys/fs/cgroup/cpuset you can find a tree that corresponds to the +tree of the cpusets in the system. For instance, /sys/fs/cgroup/cpuset is the cpuset that holds the whole system. -If you want to create a new cpuset under /dev/cpuset: -# cd /dev/cpuset +If you want to create a new cpuset under /sys/fs/cgroup/cpuset: +# cd /sys/fs/cgroup/cpuset # mkdir my_cpuset Now you want to do something with this cpuset. @@ -765,12 +765,12 @@ wrapper around the cgroup filesystem. The command -mount -t cpuset X /dev/cpuset +mount -t cpuset X /sys/fs/cgroup/cpuset is equivalent to -mount -t cgroup -ocpuset,noprefix X /dev/cpuset -echo "/sbin/cpuset_release_agent" > /dev/cpuset/release_agent +mount -t cgroup -ocpuset,noprefix X /sys/fs/cgroup/cpuset +echo "/sbin/cpuset_release_agent" > /sys/fs/cgroup/cpuset/release_agent 2.2 Adding/removing cpus ------------------------ diff --git a/Documentation/cgroups/devices.txt b/Documentation/cgroups/devices.txt index 57ca4c89fe5c..16624a7f8222 100644 --- a/Documentation/cgroups/devices.txt +++ b/Documentation/cgroups/devices.txt @@ -22,16 +22,16 @@ removed from the child(ren). An entry is added using devices.allow, and removed using devices.deny. For instance - echo 'c 1:3 mr' > /cgroups/1/devices.allow + echo 'c 1:3 mr' > /sys/fs/cgroup/1/devices.allow allows cgroup 1 to read and mknod the device usually known as /dev/null. Doing - echo a > /cgroups/1/devices.deny + echo a > /sys/fs/cgroup/1/devices.deny will remove the default 'a *:* rwm' entry. Doing - echo a > /cgroups/1/devices.allow + echo a > /sys/fs/cgroup/1/devices.allow will add the 'a *:* rwm' entry to the whitelist. diff --git a/Documentation/cgroups/freezer-subsystem.txt b/Documentation/cgroups/freezer-subsystem.txt index 41f37fea1276..c21d77742a07 100644 --- a/Documentation/cgroups/freezer-subsystem.txt +++ b/Documentation/cgroups/freezer-subsystem.txt @@ -59,28 +59,28 @@ is non-freezable. * Examples of usage : - # mkdir /containers - # mount -t cgroup -ofreezer freezer /containers - # mkdir /containers/0 - # echo $some_pid > /containers/0/tasks + # mkdir /sys/fs/cgroup/freezer + # mount -t cgroup -ofreezer freezer /sys/fs/cgroup/freezer + # mkdir /sys/fs/cgroup/freezer/0 + # echo $some_pid > /sys/fs/cgroup/freezer/0/tasks to get status of the freezer subsystem : - # cat /containers/0/freezer.state + # cat /sys/fs/cgroup/freezer/0/freezer.state THAWED to freeze all tasks in the container : - # echo FROZEN > /containers/0/freezer.state - # cat /containers/0/freezer.state + # echo FROZEN > /sys/fs/cgroup/freezer/0/freezer.state + # cat /sys/fs/cgroup/freezer/0/freezer.state FREEZING - # cat /containers/0/freezer.state + # cat /sys/fs/cgroup/freezer/0/freezer.state FROZEN to unfreeze all tasks in the container : - # echo THAWED > /containers/0/freezer.state - # cat /containers/0/freezer.state + # echo THAWED > /sys/fs/cgroup/freezer/0/freezer.state + # cat /sys/fs/cgroup/freezer/0/freezer.state THAWED This is the basic mechanism which should do the right thing for user space task diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt index 7c163477fcd8..6f3c598971fc 100644 --- a/Documentation/cgroups/memory.txt +++ b/Documentation/cgroups/memory.txt @@ -1,8 +1,8 @@ Memory Resource Controller -NOTE: The Memory Resource Controller has been generically been referred - to as the memory controller in this document. Do not confuse memory - controller used here with the memory controller that is used in hardware. +NOTE: The Memory Resource Controller has generically been referred to as the + memory controller in this document. Do not confuse memory controller + used here with the memory controller that is used in hardware. (For editors) In this document: @@ -70,6 +70,7 @@ Brief summary of control files. (See sysctl's vm.swappiness) memory.move_charge_at_immigrate # set/show controls of moving charges memory.oom_control # set/show oom controls. + memory.numa_stat # show the number of memory usage per numa node 1. History @@ -181,7 +182,7 @@ behind this approach is that a cgroup that aggressively uses a shared page will eventually get charged for it (once it is uncharged from the cgroup that brought it in -- this will happen on memory pressure). -Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used.. +Exception: If CONFIG_CGROUP_CGROUP_MEM_RES_CTLR_SWAP is not used. When you do swapoff and make swapped-out pages of shmem(tmpfs) to be backed into memory in force, charges for pages are accounted against the caller of swapoff rather than the users of shmem. @@ -213,7 +214,7 @@ affecting global LRU, memory+swap limit is better than just limiting swap from OS point of view. * What happens when a cgroup hits memory.memsw.limit_in_bytes -When a cgroup his memory.memsw.limit_in_bytes, it's useless to do swap-out +When a cgroup hits memory.memsw.limit_in_bytes, it's useless to do swap-out in this cgroup. Then, swap-out will not be done by cgroup routine and file caches are dropped. But as mentioned above, global LRU can do swapout memory from it for sanity of the system's memory management state. You can't forbid @@ -263,16 +264,17 @@ b. Enable CONFIG_RESOURCE_COUNTERS c. Enable CONFIG_CGROUP_MEM_RES_CTLR d. Enable CONFIG_CGROUP_MEM_RES_CTLR_SWAP (to use swap extension) -1. Prepare the cgroups -# mkdir -p /cgroups -# mount -t cgroup none /cgroups -o memory +1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?) +# mount -t tmpfs none /sys/fs/cgroup +# mkdir /sys/fs/cgroup/memory +# mount -t cgroup none /sys/fs/cgroup/memory -o memory 2. Make the new group and move bash into it -# mkdir /cgroups/0 -# echo $$ > /cgroups/0/tasks +# mkdir /sys/fs/cgroup/memory/0 +# echo $$ > /sys/fs/cgroup/memory/0/tasks Since now we're in the 0 cgroup, we can alter the memory limit: -# echo 4M > /cgroups/0/memory.limit_in_bytes +# echo 4M > /sys/fs/cgroup/memory/0/memory.limit_in_bytes NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo, mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.) @@ -280,11 +282,11 @@ mega or gigabytes. (Here, Kilo, Mega, Giga are Kibibytes, Mebibytes, Gibibytes.) NOTE: We can write "-1" to reset the *.limit_in_bytes(unlimited). NOTE: We cannot set limits on the root cgroup any more. -# cat /cgroups/0/memory.limit_in_bytes +# cat /sys/fs/cgroup/memory/0/memory.limit_in_bytes 4194304 We can check the usage: -# cat /cgroups/0/memory.usage_in_bytes +# cat /sys/fs/cgroup/memory/0/memory.usage_in_bytes 1216512 A successful write to this file does not guarantee a successful set of @@ -378,7 +380,7 @@ will be charged as a new owner of it. 5.2 stat file -memory.stat file includes following statistics +5.2.1 memory.stat file includes following statistics # per-memory cgroup local status cache - # of bytes of page cache memory. @@ -436,6 +438,89 @@ Note: file_mapped is accounted only when the memory cgroup is owner of page cache.) +5.2.2 memory.vmscan_stat + +memory.vmscan_stat includes statistics information for memory scanning and +freeing, reclaiming. The statistics shows memory scanning information since +memory cgroup creation and can be reset to 0 by writing 0 as + + #echo 0 > ../memory.vmscan_stat + +This file contains following statistics. + +[param]_[file_or_anon]_pages_by_[reason]_[under_heararchy] +[param]_elapsed_ns_by_[reason]_[under_hierarchy] + +For example, + + scanned_file_pages_by_limit indicates the number of scanned + file pages at vmscan. + +Now, 3 parameters are supported + + scanned - the number of pages scanned by vmscan + rotated - the number of pages activated at vmscan + freed - the number of pages freed by vmscan + +If "rotated" is high against scanned/freed, the memcg seems busy. + +Now, 2 reason are supported + + limit - the memory cgroup's limit + system - global memory pressure + softlimit + (global memory pressure not under softlimit is not handled now) + +When under_hierarchy is added in the tail, the number indicates the +total memcg scan of its children and itself. + +elapsed_ns is a elapsed time in nanosecond. This may include sleep time +and not indicates CPU usage. So, please take this as just showing +latency. + +Here is an example. + +# cat /cgroup/memory/A/memory.vmscan_stat +scanned_pages_by_limit 9471864 +scanned_anon_pages_by_limit 6640629 +scanned_file_pages_by_limit 2831235 +rotated_pages_by_limit 4243974 +rotated_anon_pages_by_limit 3971968 +rotated_file_pages_by_limit 272006 +freed_pages_by_limit 2318492 +freed_anon_pages_by_limit 962052 +freed_file_pages_by_limit 1356440 +elapsed_ns_by_limit 351386416101 +scanned_pages_by_system 0 +scanned_anon_pages_by_system 0 +scanned_file_pages_by_system 0 +rotated_pages_by_system 0 +rotated_anon_pages_by_system 0 +rotated_file_pages_by_system 0 +freed_pages_by_system 0 +freed_anon_pages_by_system 0 +freed_file_pages_by_system 0 +elapsed_ns_by_system 0 +scanned_pages_by_limit_under_hierarchy 9471864 +scanned_anon_pages_by_limit_under_hierarchy 6640629 +scanned_file_pages_by_limit_under_hierarchy 2831235 +rotated_pages_by_limit_under_hierarchy 4243974 +rotated_anon_pages_by_limit_under_hierarchy 3971968 +rotated_file_pages_by_limit_under_hierarchy 272006 +freed_pages_by_limit_under_hierarchy 2318492 +freed_anon_pages_by_limit_under_hierarchy 962052 +freed_file_pages_by_limit_under_hierarchy 1356440 +elapsed_ns_by_limit_under_hierarchy 351386416101 +scanned_pages_by_system_under_hierarchy 0 +scanned_anon_pages_by_system_under_hierarchy 0 +scanned_file_pages_by_system_under_hierarchy 0 +rotated_pages_by_system_under_hierarchy 0 +rotated_anon_pages_by_system_under_hierarchy 0 +rotated_file_pages_by_system_under_hierarchy 0 +freed_pages_by_system_under_hierarchy 0 +freed_anon_pages_by_system_under_hierarchy 0 +freed_file_pages_by_system_under_hierarchy 0 +elapsed_ns_by_system_under_hierarchy 0 + 5.3 swappiness Similar to /proc/sys/vm/swappiness, but affecting a hierarchy of groups only. @@ -464,6 +549,24 @@ value for efficient access. (Of course, when necessary, it's synchronized.) If you want to know more exact memory usage, you should use RSS+CACHE(+SWAP) value in memory.stat(see 5.2). +5.6 numa_stat + +This is similar to numa_maps but operates on a per-memcg basis. This is +useful for providing visibility into the numa locality information within +an memcg since the pages are allowed to be allocated from any physical +node. One of the usecases is evaluating application performance by +combining this information with the application's cpu allocation. + +We export "total", "file", "anon" and "unevictable" pages per-node for +each memcg. The ouput format of memory.numa_stat is: + +total=<total pages> N0=<node 0 pages> N1=<node 1 pages> ... +file=<total file pages> N0=<node 0 pages> N1=<node 1 pages> ... +anon=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ... +unevictable=<total anon pages> N0=<node 0 pages> N1=<node 1 pages> ... + +And we have total = file + anon + unevictable. + 6. Hierarchy support The memory controller supports a deep hierarchy and hierarchical accounting. @@ -471,13 +574,13 @@ The hierarchy is created by creating the appropriate cgroups in the cgroup filesystem. Consider for example, the following cgroup filesystem hierarchy - root + root / | \ - / | \ - a b c - | \ - | \ - d e + / | \ + a b c + | \ + | \ + d e In the diagram above, with hierarchical accounting enabled, all memory usage of e, is accounted to its ancestors up until the root (i.e, c and root), diff --git a/Documentation/cpu-freq/cpu-drivers.txt b/Documentation/cpu-freq/cpu-drivers.txt index 6c30e930c122..c436096351f8 100644 --- a/Documentation/cpu-freq/cpu-drivers.txt +++ b/Documentation/cpu-freq/cpu-drivers.txt @@ -168,7 +168,7 @@ in-chipset dynamic frequency switching to policy->min, the upper limit to policy->max, and -if supported- select a performance-oriented setting when policy->policy is CPUFREQ_POLICY_PERFORMANCE, and a powersaving-oriented setting when CPUFREQ_POLICY_POWERSAVE. Also check -the reference implementation in arch/i386/kernel/cpu/cpufreq/longrun.c +the reference implementation in drivers/cpufreq/longrun.c diff --git a/Documentation/development-process/4.Coding b/Documentation/development-process/4.Coding index f3f1a469443c..83f5f5b365a3 100644 --- a/Documentation/development-process/4.Coding +++ b/Documentation/development-process/4.Coding @@ -244,7 +244,7 @@ testing purposes. In particular, you should turn on: - DEBUG_SLAB can find a variety of memory allocation and use errors; it should be used on most development kernels. - - DEBUG_SPINLOCK, DEBUG_SPINLOCK_SLEEP, and DEBUG_MUTEXES will find a + - DEBUG_SPINLOCK, DEBUG_ATOMIC_SLEEP, and DEBUG_MUTEXES will find a number of common locking errors. There are quite a few other debugging options, some of which will be diff --git a/Documentation/devicetree/bindings/arm/pmu.txt b/Documentation/devicetree/bindings/arm/pmu.txt new file mode 100644 index 000000000000..1c044eb320cc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/pmu.txt @@ -0,0 +1,21 @@ +* ARM Performance Monitor Units + +ARM cores often have a PMU for counting cpu and cache events like cache misses +and hits. The interface to the PMU is part of the ARM ARM. The ARM PMU +representation in the device tree should be done as under:- + +Required properties: + +- compatible : should be one of + "arm,cortex-a9-pmu" + "arm,cortex-a8-pmu" + "arm,arm1176-pmu" + "arm,arm1136-pmu" +- interrupts : 1 combined interrupt or 1 per core. + +Example: + +pmu { + compatible = "arm,cortex-a9-pmu"; + interrupts = <100 101>; +}; diff --git a/Documentation/devicetree/bindings/arm/primecell.txt b/Documentation/devicetree/bindings/arm/primecell.txt new file mode 100644 index 000000000000..1d5d7a870ec7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/primecell.txt @@ -0,0 +1,21 @@ +* ARM Primecell Peripherals + +ARM, Ltd. Primecell peripherals have a standard id register that can be used to +identify the peripheral type, vendor, and revision. This value can be used for +driver matching. + +Required properties: + +- compatible : should be a specific value for peripheral and "arm,primecell" + +Optional properties: + +- arm,primecell-periphid : Value to override the h/w value with + +Example: + +serial@fff36000 { + compatible = "arm,pl011", "arm,primecell"; + arm,primecell-periphid = <0x00341011>; +}; + diff --git a/Documentation/devicetree/bindings/arm/sirf.txt b/Documentation/devicetree/bindings/arm/sirf.txt new file mode 100644 index 000000000000..6b07f65b32de --- /dev/null +++ b/Documentation/devicetree/bindings/arm/sirf.txt @@ -0,0 +1,3 @@ +prima2 "cb" evalutation board +Required root node properties: + - compatible = "sirf,prima2-cb", "sirf,prima2"; diff --git a/Documentation/devicetree/bindings/arm/xilinx.txt b/Documentation/devicetree/bindings/arm/xilinx.txt new file mode 100644 index 000000000000..6f1ed830b4f7 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/xilinx.txt @@ -0,0 +1,7 @@ +Xilinx Zynq EP107 Emulation Platform board + +This board is an emulation platform for the Zynq product which is +based on an ARM Cortex A9 processor. + +Required root node properties: + - compatible = "xlnx,zynq-ep107"; diff --git a/Documentation/devicetree/bindings/powerpc/fsl/sec.txt b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt index 2b6f2d45c45a..38988ef1336b 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/sec.txt +++ b/Documentation/devicetree/bindings/crypto/fsl-sec2.txt @@ -1,4 +1,4 @@ -Freescale SoC SEC Security Engines +Freescale SoC SEC Security Engines versions 2.x-3.x Required properties: diff --git a/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt new file mode 100644 index 000000000000..4363ae4b3c14 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/fsl-imx-gpio.txt @@ -0,0 +1,22 @@ +* Freescale i.MX/MXC GPIO controller + +Required properties: +- compatible : Should be "fsl,<soc>-gpio" +- reg : Address and length of the register set for the device +- interrupts : Should be the port interrupt shared by all 32 pins, if + one number. If two numbers, the first one is the interrupt shared + by low 16 pins and the second one is for high 16 pins. +- gpio-controller : Marks the device node as a gpio controller. +- #gpio-cells : Should be two. The first cell is the pin number and + the second cell is used to specify optional parameters (currently + unused). + +Example: + +gpio0: gpio@73f84000 { + compatible = "fsl,imx51-gpio", "fsl,imx31-gpio"; + reg = <0x73f84000 0x4000>; + interrupts = <50 51>; + gpio-controller; + #gpio-cells = <2>; +}; diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index edaa84d288a1..4e16ba4feab0 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -4,17 +4,45 @@ Specifying GPIO information for devices 1) gpios property ----------------- -Nodes that makes use of GPIOs should define them using `gpios' property, -format of which is: <&gpio-controller1-phandle gpio1-specifier - &gpio-controller2-phandle gpio2-specifier - 0 /* holes are permitted, means no GPIO 3 */ - &gpio-controller4-phandle gpio4-specifier - ...>; +Nodes that makes use of GPIOs should specify them using one or more +properties, each containing a 'gpio-list': -Note that gpio-specifier length is controller dependent. + gpio-list ::= <single-gpio> [gpio-list] + single-gpio ::= <gpio-phandle> <gpio-specifier> + gpio-phandle : phandle to gpio controller node + gpio-specifier : Array of #gpio-cells specifying specific gpio + (controller specific) + +GPIO properties should be named "[<name>-]gpios". Exact +meaning of each gpios property must be documented in the device tree +binding for each device. + +For example, the following could be used to describe gpios pins to use +as chip select lines; with chip selects 0, 1 and 3 populated, and chip +select 2 left empty: + + gpio1: gpio1 { + gpio-controller + #gpio-cells = <2>; + }; + gpio2: gpio2 { + gpio-controller + #gpio-cells = <1>; + }; + [...] + chipsel-gpios = <&gpio1 12 0>, + <&gpio1 13 0>, + <0>, /* holes are permitted, means no GPIO 2 */ + <&gpio2 2>; + +Note that gpio-specifier length is controller dependent. In the +above example, &gpio1 uses 2 cells to specify a gpio, while &gpio2 +only uses one. gpio-specifier may encode: bank, pin position inside the bank, whether pin is open-drain and whether pin is logically inverted. +Exact meaning of each specifier cell is controller specific, and must +be documented in the device tree binding for the device. Example of the node using GPIOs: @@ -28,8 +56,8 @@ and empty GPIO flags as accepted by the "qe_pio_e" gpio-controller. 2) gpio-controller nodes ------------------------ -Every GPIO controller node must have #gpio-cells property defined, -this information will be used to translate gpio-specifiers. +Every GPIO controller node must both an empty "gpio-controller" +property, and have #gpio-cells contain the size of the gpio-specifier. Example of two SOC GPIO banks defined as gpio-controller nodes: diff --git a/Documentation/devicetree/bindings/gpio/gpio_keys.txt b/Documentation/devicetree/bindings/gpio/gpio_keys.txt new file mode 100644 index 000000000000..7190c99d7611 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio_keys.txt @@ -0,0 +1,36 @@ +Device-Tree bindings for input/gpio_keys.c keyboard driver + +Required properties: + - compatible = "gpio-keys"; + +Optional properties: + - autorepeat: Boolean, Enable auto repeat feature of Linux input + subsystem. + +Each button (key) is represented as a sub-node of "gpio-keys": +Subnode properties: + + - gpios: OF devcie-tree gpio specificatin. + - label: Descriptive name of the key. + - linux,code: Keycode to emit. + +Optional subnode-properties: + - linux,input-type: Specify event type this button/key generates. + If not specified defaults to <1> == EV_KEY. + - debounce-interval: Debouncing interval time in milliseconds. + If not specified defaults to 5. + - gpio-key,wakeup: Boolean, button can wake-up the system. + +Example nodes: + + gpio_keys { + compatible = "gpio-keys"; + #address-cells = <1>; + #size-cells = <0>; + autorepeat; + button@21 { + label = "GPIO Key UP"; + linux,code = <103>; + gpios = <&gpio1 0 1>; + }; + ... diff --git a/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt b/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt new file mode 100644 index 000000000000..eb4b530d64e1 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio_nvidia.txt @@ -0,0 +1,8 @@ +NVIDIA Tegra 2 GPIO controller + +Required properties: +- compatible : "nvidia,tegra20-gpio" +- #gpio-cells : Should be two. The first cell is the pin number and the + second cell is used to specify optional parameters: + - bit 0 specifies polarity (0 for normal, 1 for inverted) +- gpio-controller : Marks the device node as a GPIO controller. diff --git a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt index 1a729f089866..1a729f089866 100755..100644 --- a/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt +++ b/Documentation/devicetree/bindings/net/can/fsl-flexcan.txt diff --git a/Documentation/devicetree/bindings/rtc/olpc-xo1-rtc.txt b/Documentation/devicetree/bindings/rtc/olpc-xo1-rtc.txt new file mode 100644 index 000000000000..a2891ceb6344 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/olpc-xo1-rtc.txt @@ -0,0 +1,5 @@ +OLPC XO-1 RTC +~~~~~~~~~~~~~ + +Required properties: + - compatible : "olpc,xo1-rtc" diff --git a/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt new file mode 100644 index 000000000000..9841057d112b --- /dev/null +++ b/Documentation/devicetree/bindings/spi/fsl-imx-cspi.txt @@ -0,0 +1,22 @@ +* Freescale (Enhanced) Configurable Serial Peripheral Interface + (CSPI/eCSPI) for i.MX + +Required properties: +- compatible : Should be "fsl,<soc>-cspi" or "fsl,<soc>-ecspi" +- reg : Offset and length of the register set for the device +- interrupts : Should contain CSPI/eCSPI interrupt +- fsl,spi-num-chipselects : Contains the number of the chipselect +- cs-gpios : Specifies the gpio pins to be used for chipselects. + +Example: + +ecspi@70010000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "fsl,imx51-ecspi"; + reg = <0x70010000 0x4000>; + interrupts = <36>; + fsl,spi-num-chipselects = <2>; + cs-gpios = <&gpio3 24 0>, /* GPIO4_24 */ + <&gpio3 25 0>; /* GPIO4_25 */ +}; diff --git a/Documentation/devicetree/bindings/spi/spi_nvidia.txt b/Documentation/devicetree/bindings/spi/spi_nvidia.txt new file mode 100644 index 000000000000..6b9e51896693 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi_nvidia.txt @@ -0,0 +1,5 @@ +NVIDIA Tegra 2 SPI device + +Required properties: +- compatible : should be "nvidia,tegra20-spi". +- gpios : should specify GPIOs used for chipselect. diff --git a/Documentation/devicetree/bindings/tty/serial/of-serial.txt b/Documentation/devicetree/bindings/tty/serial/of-serial.txt new file mode 100644 index 000000000000..b8b27b0aca10 --- /dev/null +++ b/Documentation/devicetree/bindings/tty/serial/of-serial.txt @@ -0,0 +1,36 @@ +* UART (Universal Asynchronous Receiver/Transmitter) + +Required properties: +- compatible : one of: + - "ns8250" + - "ns16450" + - "ns16550a" + - "ns16550" + - "ns16750" + - "ns16850" + - "nvidia,tegra20-uart" + - "ibm,qpace-nwp-serial" + - "serial" if the port type is unknown. +- reg : offset and length of the register set for the device. +- interrupts : should contain uart interrupt. +- clock-frequency : the input clock frequency for the UART. + +Optional properties: +- current-speed : the current active speed of the UART. +- reg-offset : offset to apply to the mapbase from the start of the registers. +- reg-shift : quantity to shift the register offsets by. +- reg-io-width : the size (in bytes) of the IO accesses that should be + performed on the device. There are some systems that require 32-bit + accesses to the UART (e.g. TI davinci). +- used-by-rtas : set to indicate that the port is in use by the OpenFirmware + RTAS and should not be registered. + +Example: + + uart@80230000 { + compatible = "ns8250"; + reg = <0x80230000 0x100>; + clock-frequency = <3686400>; + interrupts = <10>; + reg-shift = <2>; + }; diff --git a/Documentation/driver-model/device.txt b/Documentation/driver-model/device.txt index b2ff42685bcb..bdefe728a737 100644 --- a/Documentation/driver-model/device.txt +++ b/Documentation/driver-model/device.txt @@ -104,4 +104,4 @@ Then in the module init function is would do: And assuming 'dev' is the struct device passed into the probe hook, the driver probe function would do something like: - create_device(&mydriver_class, dev, chrdev, &private_data, "my_name"); + device_create(&mydriver_class, dev, chrdev, &private_data, "my_name"); diff --git a/Documentation/driver-model/overview.txt b/Documentation/driver-model/overview.txt index 07236ed968da..6a8f9a8075d8 100644 --- a/Documentation/driver-model/overview.txt +++ b/Documentation/driver-model/overview.txt @@ -30,7 +30,7 @@ management, and hot plug. In particular, the model dictated by Intel and Microsoft (namely ACPI) ensures that almost every device on almost any bus on an x86-compatible system can work within this paradigm. Of course, not every bus is able to support all such operations, although most -buses support a most of those operations. +buses support most of those operations. Downstream Access @@ -46,25 +46,29 @@ struct pci_dev now looks like this: struct pci_dev { ... - struct device dev; + struct device dev; /* Generic device interface */ + ... }; -Note first that it is statically allocated. This means only one allocation on -device discovery. Note also that it is at the _end_ of struct pci_dev. This is -to make people think about what they're doing when switching between the bus -driver and the global driver; and to prevent against mindless casts between -the two. +Note first that the struct device dev within the struct pci_dev is +statically allocated. This means only one allocation on device discovery. + +Note also that that struct device dev is not necessarily defined at the +front of the pci_dev structure. This is to make people think about what +they're doing when switching between the bus driver and the global driver, +and to discourage meaningless and incorrect casts between the two. The PCI bus layer freely accesses the fields of struct device. It knows about the structure of struct pci_dev, and it should know the structure of struct device. Individual PCI device drivers that have been converted to the current driver model generally do not and should not touch the fields of struct device, -unless there is a strong compelling reason to do so. +unless there is a compelling reason to do so. -This abstraction is prevention of unnecessary pain during transitional phases. -If the name of the field changes or is removed, then every downstream driver -will break. On the other hand, if only the bus layer (and not the device -layer) accesses struct device, it is only that layer that needs to change. +The above abstraction prevents unnecessary pain during transitional phases. +If it were not done this way, then when a field was renamed or removed, every +downstream driver would break. On the other hand, if only the bus layer +(and not the device layer) accesses the struct device, it is only the bus +layer that needs to change. User Interface @@ -73,15 +77,27 @@ User Interface By virtue of having a complete hierarchical view of all the devices in the system, exporting a complete hierarchical view to userspace becomes relatively easy. This has been accomplished by implementing a special purpose virtual -file system named sysfs. It is hence possible for the user to mount the -whole sysfs filesystem anywhere in userspace. +file system named sysfs. + +Almost all mainstream Linux distros mount this filesystem automatically; you +can see some variation of the following in the output of the "mount" command: + +$ mount +... +none on /sys type sysfs (rw,noexec,nosuid,nodev) +... +$ + +The auto-mounting of sysfs is typically accomplished by an entry similar to +the following in the /etc/fstab file: + +none /sys sysfs defaults 0 0 -This can be done permanently by providing the following entry into the -/etc/fstab (under the provision that the mount point does exist, of course): +or something similar in the /lib/init/fstab file on Debian-based systems: -none /sys sysfs defaults 0 0 +none /sys sysfs nodev,noexec,nosuid 0 0 -Or by hand on the command line: +If sysfs is not automatically mounted, you can always do it manually with: # mount -t sysfs sysfs /sys diff --git a/Documentation/fb/modedb.txt b/Documentation/fb/modedb.txt index ec4dee75a354..16aa08453911 100644 --- a/Documentation/fb/modedb.txt +++ b/Documentation/fb/modedb.txt @@ -20,7 +20,7 @@ in a video= option, fbmem considers that to be a global video mode option. Valid mode specifiers (mode_option argument): - <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m] + <xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd] <name>[-<bpp>][@<refresh>] with <xres>, <yres>, <bpp> and <refresh> decimal numbers and <name> a string. @@ -36,6 +36,21 @@ pixels and 1.8% of yres). Sample usage: 1024x768M@60m - CVT timing with margins +DRM drivers also add options to enable or disable outputs: + +'e' will force the display to be enabled, i.e. it will override the detection +if a display is connected. 'D' will force the display to be enabled and use +digital output. This is useful for outputs that have both analog and digital +signals (e.g. HDMI and DVI-I). For other outputs it behaves like 'e'. If 'd' +is specified the output is disabled. + +You can additionally specify which output the options matches to. +To force the VGA output to be enabled and drive a specific mode say: + video=VGA-1:1280x1024@60me + +Specifying the option multiple times for different ports is possible, e.g.: + video=LVDS-1:d video=HDMI-1:D + ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** oOo ***** What is the VESA(TM) Coordinated Video Timings (CVT)? @@ -132,5 +147,5 @@ There may be more modes. tridentfb - Trident (Cyber)blade chipset frame buffer vt8623fb - VIA 8623 frame buffer -BTW, only a few drivers use this at the moment. Others are to follow -(feel free to send patches). +BTW, only a few fb drivers use this at the moment. Others are to follow +(feel free to send patches). The DRM drivers also support this. diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 1a9446b59153..dfd6a9f4a583 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -184,7 +184,7 @@ Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's A much more powerful interface, /proc/<pid>/oom_score_adj, was introduced with the oom killer rewrite that allows users to increase or - decrease the badness() score linearly. This interface will replace + decrease the badness score linearly. This interface will replace /proc/<pid>/oom_adj. A warning will be emitted to the kernel log if an application uses this @@ -193,20 +193,6 @@ Why: /proc/<pid>/oom_adj allows userspace to influence the oom killer's --------------------------- -What: CS5535/CS5536 obsolete GPIO driver -When: June 2011 -Files: drivers/staging/cs5535_gpio/* -Check: drivers/staging/cs5535_gpio/cs5535_gpio.c -Why: A newer driver replaces this; it is drivers/gpio/cs5535-gpio.c, and - integrates with the Linux GPIO subsystem. The old driver has been - moved to staging, and will be removed altogether around 2.6.40. - Please test the new driver, and ensure that the functionality you - need and any bugfixes from the old driver are available in the new - one. -Who: Andres Salomon <dilinger@queued.net> - --------------------------- - What: remove EXPORT_SYMBOL(kernel_thread) When: August 2006 Files: arch/*/kernel/*_ksyms.c @@ -294,7 +280,7 @@ When: The schedule was July 2008, but it was decided that we are going to keep t Why: The support code for the old firmware hurts code readability/maintainability and slightly hurts runtime performance. Bugfixes for the old firmware are not provided by Broadcom anymore. -Who: Michael Buesch <mb@bu3sch.de> +Who: Michael Buesch <m@bues.ch> --------------------------- @@ -430,7 +416,7 @@ Who: Avi Kivity <avi@redhat.com> ---------------------------- What: iwlwifi 50XX module parameters -When: 2.6.40 +When: 3.0 Why: The "..50" modules parameters were used to configure 5000 series and up devices; different set of module parameters also available for 4965 with same functionalities. Consolidate both set into single place @@ -441,7 +427,7 @@ Who: Wey-Yi Guy <wey-yi.w.guy@intel.com> ---------------------------- What: iwl4965 alias support -When: 2.6.40 +When: 3.0 Why: Internal alias support has been present in module-init-tools for some time, the MODULE_ALIAS("iwl4965") boilerplate aliases can be removed with no impact. @@ -474,32 +460,8 @@ Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> ---------------------------- -What: DMA_xxBIT_MASK macros -When: Jun 2011 -Why: DMA_xxBIT_MASK macros were replaced with DMA_BIT_MASK() macros. -Who: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> - ----------------------------- - -What: namespace cgroup (ns_cgroup) -When: 2.6.38 -Why: The ns_cgroup leads to some problems: - * cgroup creation is out-of-control - * cgroup name can conflict when pids are looping - * it is not possible to have a single process handling - a lot of namespaces without falling in a exponential creation time - * we may want to create a namespace without creating a cgroup - - The ns_cgroup is replaced by a compatibility flag 'clone_children', - where a newly created cgroup will copy the parent cgroup values. - The userspace has to manually create a cgroup and add a task to - the 'tasks' file. -Who: Daniel Lezcano <daniel.lezcano@free.fr> - ----------------------------- - What: iwlwifi disable_hw_scan module parameters -When: 2.6.40 +When: 3.0 Why: Hareware scan is the prefer method for iwlwifi devices for scanning operation. Remove software scan support for all the iwlwifi devices. @@ -508,26 +470,6 @@ Who: Wey-Yi Guy <wey-yi.w.guy@intel.com> ---------------------------- -What: access to nfsd auth cache through sys_nfsservctl or '.' files - in the 'nfsd' filesystem. -When: 2.6.40 -Why: This is a legacy interface which have been replaced by a more - dynamic cache. Continuing to maintain this interface is an - unnecessary burden. -Who: NeilBrown <neilb@suse.de> - ----------------------------- - -What: cancel_rearming_delayed_work[queue]() -When: 2.6.39 - -Why: The functions have been superceded by cancel_delayed_work_sync() - quite some time ago. The conversion is trivial and there is no - in-kernel user left. -Who: Tejun Heo <tj@kernel.org> - ----------------------------- - What: Legacy, non-standard chassis intrusion detection interface. When: June 2011 Why: The adm9240, w83792d and w83793 hardware monitoring drivers have @@ -545,22 +487,6 @@ Files: net/netfilter/xt_connlimit.c ---------------------------- -What: noswapaccount kernel command line parameter -When: 2.6.40 -Why: The original implementation of memsw feature enabled by - CONFIG_CGROUP_MEM_RES_CTLR_SWAP could be disabled by the noswapaccount - kernel parameter (introduced in 2.6.29-rc1). Later on, this decision - turned out to be not ideal because we cannot have the feature compiled - in and disabled by default and let only interested to enable it - (e.g. general distribution kernels might need it). Therefore we have - added swapaccount[=0|1] parameter (introduced in 2.6.37) which provides - the both possibilities. If we remove noswapaccount we will have - less command line parameters with the same functionality and we - can also cleanup the parameter handling a bit (). -Who: Michal Hocko <mhocko@suse.cz> - ----------------------------- - What: ipt_addrtype match include file When: 2012 Why: superseded by xt_addrtype @@ -579,7 +505,7 @@ Who: Jean Delvare <khali@linux-fr.org> ---------------------------- What: Support for UVCIOC_CTRL_ADD in the uvcvideo driver -When: 2.6.42 +When: 3.2 Why: The information passed to the driver by this ioctl is now queried dynamically from the device. Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com> @@ -587,7 +513,7 @@ Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com> ---------------------------- What: Support for UVCIOC_CTRL_MAP_OLD in the uvcvideo driver -When: 2.6.42 +When: 3.2 Why: Used only by applications compiled against older driver versions. Superseded by UVCIOC_CTRL_MAP which supports V4L2 menu controls. Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com> @@ -595,8 +521,37 @@ Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com> ---------------------------- What: Support for UVCIOC_CTRL_GET and UVCIOC_CTRL_SET in the uvcvideo driver -When: 2.6.42 +When: 3.2 Why: Superseded by the UVCIOC_CTRL_QUERY ioctl. Who: Laurent Pinchart <laurent.pinchart@ideasonboard.com> ---------------------------- + +What: For VIDIOC_S_FREQUENCY the type field must match the device node's type. + If not, return -EINVAL. +When: 3.2 +Why: It makes no sense to switch the tuner to radio mode by calling + VIDIOC_S_FREQUENCY on a video node, or to switch the tuner to tv mode by + calling VIDIOC_S_FREQUENCY on a radio node. This is the first step of a + move to more consistent handling of tv and radio tuners. +Who: Hans Verkuil <hans.verkuil@cisco.com> + +---------------------------- + +What: Opening a radio device node will no longer automatically switch the + tuner mode from tv to radio. +When: 3.3 +Why: Just opening a V4L device should not change the state of the hardware + like that. It's very unexpected and against the V4L spec. Instead, you + switch to radio mode by calling VIDIOC_S_FREQUENCY. This is the second + and last step of the move to consistent handling of tv and radio tuners. +Who: Hans Verkuil <hans.verkuil@cisco.com> + +---------------------------- + +What: g_file_storage driver +When: 3.8 +Why: This driver has been superseded by g_mass_storage. +Who: Alan Stern <stern@rowland.harvard.edu> + +---------------------------- diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 57d827d6071d..653380793a6c 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -52,7 +52,7 @@ ata *); void (*put_link) (struct dentry *, struct nameidata *, void *); void (*truncate) (struct inode *); int (*permission) (struct inode *, int, unsigned int); - int (*check_acl)(struct inode *, int, unsigned int); + int (*get_acl)(struct inode *, int); int (*setattr) (struct dentry *, struct iattr *); int (*getattr) (struct vfsmount *, struct dentry *, struct kstat *); int (*setxattr) (struct dentry *, const char *,const void *,size_t,int); @@ -80,7 +80,7 @@ put_link: no truncate: yes (see below) setattr: yes permission: no (may not block if called in rcu-walk mode) -check_acl: no +get_acl: no getattr: no setxattr: yes getxattr: no @@ -338,21 +338,21 @@ fl_release_private: maybe no ----------------------- lock_manager_operations --------------------------- prototypes: - int (*fl_compare_owner)(struct file_lock *, struct file_lock *); - void (*fl_notify)(struct file_lock *); /* unblock callback */ - int (*fl_grant)(struct file_lock *, struct file_lock *, int); - void (*fl_release_private)(struct file_lock *); - void (*fl_break)(struct file_lock *); /* break_lease callback */ - int (*fl_change)(struct file_lock **, int); + int (*lm_compare_owner)(struct file_lock *, struct file_lock *); + void (*lm_notify)(struct file_lock *); /* unblock callback */ + int (*lm_grant)(struct file_lock *, struct file_lock *, int); + void (*lm_release_private)(struct file_lock *); + void (*lm_break)(struct file_lock *); /* break_lease callback */ + int (*lm_change)(struct file_lock **, int); locking rules: file_lock_lock may block -fl_compare_owner: yes no -fl_notify: yes no -fl_grant: no no -fl_release_private: maybe no -fl_break: yes no -fl_change yes no +lm_compare_owner: yes no +lm_notify: yes no +lm_grant: no no +lm_release_private: maybe no +lm_break: yes no +lm_change yes no --------------------------- buffer_head ----------------------------------- prototypes: @@ -412,7 +412,7 @@ prototypes: int (*open) (struct inode *, struct file *); int (*flush) (struct file *); int (*release) (struct inode *, struct file *); - int (*fsync) (struct file *, int datasync); + int (*fsync) (struct file *, loff_t start, loff_t end, int datasync); int (*aio_fsync) (struct kiocb *, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); @@ -438,9 +438,7 @@ prototypes: locking rules: All may block except for ->setlease. - No VFS locks held on entry except for ->fsync and ->setlease. - -->fsync() has i_mutex on inode. + No VFS locks held on entry except for ->setlease. ->setlease has the file_list_lock held and must not sleep. diff --git a/Documentation/filesystems/caching/netfs-api.txt b/Documentation/filesystems/caching/netfs-api.txt index a167ab876c35..7cc6bf2871eb 100644 --- a/Documentation/filesystems/caching/netfs-api.txt +++ b/Documentation/filesystems/caching/netfs-api.txt @@ -673,6 +673,22 @@ storage request to complete, or it may attempt to cancel the storage request - in which case the page will not be stored in the cache this time. +BULK INODE PAGE UNCACHE +----------------------- + +A convenience routine is provided to perform an uncache on all the pages +attached to an inode. This assumes that the pages on the inode correspond on a +1:1 basis with the pages in the cache. + + void fscache_uncache_all_inode_pages(struct fscache_cookie *cookie, + struct inode *inode); + +This takes the netfs cookie that the pages were cached with and the inode that +the pages are attached to. This function will wait for pages to finish being +written to the cache and for the cache to finish with the page generally. No +error is returned. + + ========================== INDEX AND DATA FILE UPDATE ========================== diff --git a/Documentation/filesystems/debugfs.txt b/Documentation/filesystems/debugfs.txt index ed52af60c2d8..742cc06e138f 100644 --- a/Documentation/filesystems/debugfs.txt +++ b/Documentation/filesystems/debugfs.txt @@ -73,8 +73,8 @@ the following functions can be used instead: struct dentry *parent, u16 *value); struct dentry *debugfs_create_x32(const char *name, mode_t mode, struct dentry *parent, u32 *value); - -Note that there is no debugfs_create_x64(). + struct dentry *debugfs_create_x64(const char *name, mode_t mode, + struct dentry *parent, u64 *value); These functions are useful as long as the developer knows the size of the value to be exported. Some types can have different widths on different diff --git a/Documentation/filesystems/ext3.txt b/Documentation/filesystems/ext3.txt index 272f80d5f966..22f3a0eda1d2 100644 --- a/Documentation/filesystems/ext3.txt +++ b/Documentation/filesystems/ext3.txt @@ -147,15 +147,6 @@ grpjquota=<file> during journal replay. They replace the above package for more details (http://sourceforge.net/projects/linuxquota). -bh (*) ext3 associates buffer heads to data pages to -nobh (a) cache disk block mapping information - (b) link pages into transaction to provide - ordering guarantees. - "bh" option forces use of buffer heads. - "nobh" option tries to avoid associating buffer - heads (supported only for "writeback" mode). - - Specification ============= Ext3 shares all disk implementation with the ext2 filesystem, and adds @@ -227,5 +218,5 @@ kernel source: <file:fs/ext3/> programs: http://e2fsprogs.sourceforge.net/ http://ext2resize.sourceforge.net -useful links: http://www.ibm.com/developerworks/library/l-fs7.html - http://www.ibm.com/developerworks/library/l-fs8.html +useful links: http://www.ibm.com/developerworks/library/l-fs7/index.html + http://www.ibm.com/developerworks/library/l-fs8/index.html diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 3ae9bc94352a..232a575a0c48 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -68,12 +68,12 @@ Note: More extensive information for getting started with ext4 can be '-o barriers=[0|1]' mount option for both ext3 and ext4 filesystems for a fair comparison. When tuning ext3 for best benchmark numbers, it is often worthwhile to try changing the data journaling mode; '-o - data=writeback,nobh' can be faster for some workloads. (Note - however that running mounted with data=writeback can potentially - leave stale data exposed in recently written files in case of an - unclean shutdown, which could be a security exposure in some - situations.) Configuring the filesystem with a large journal can - also be helpful for metadata-intensive workloads. + data=writeback' can be faster for some workloads. (Note however that + running mounted with data=writeback can potentially leave stale data + exposed in recently written files in case of an unclean shutdown, + which could be a security exposure in some situations.) Configuring + the filesystem with a large journal can also be helpful for + metadata-intensive workloads. 2. Features =========== @@ -272,14 +272,6 @@ grpjquota=<file> during journal replay. They replace the above package for more details (http://sourceforge.net/projects/linuxquota). -bh (*) ext4 associates buffer heads to data pages to -nobh (a) cache disk block mapping information - (b) link pages into transaction to provide - ordering guarantees. - "bh" option forces use of buffer heads. - "nobh" option tries to avoid associating buffer - heads (supported only for "writeback" mode). - stripe=n Number of filesystem blocks that mballoc will try to use for allocation size and alignment. For RAID5/6 systems this should be the number of data @@ -393,8 +385,7 @@ dioread_nolock locking. If the dioread_nolock option is specified write and convert the extent to initialized after IO completes. This approach allows ext4 code to avoid using inode mutex, which improves scalability on high - speed storages. However this does not work with nobh - option and the mount will fail. Nor does it work with + speed storages. However this does not work with data journaling and dioread_nolock option will be ignored with kernel warning. Note that dioread_nolock code path is only used for extent-based files. diff --git a/Documentation/filesystems/nfs/Exporting b/Documentation/filesystems/nfs/Exporting index 87019d2b5981..09994c247289 100644 --- a/Documentation/filesystems/nfs/Exporting +++ b/Documentation/filesystems/nfs/Exporting @@ -92,7 +92,14 @@ For a filesystem to be exportable it must: 1/ provide the filehandle fragment routines described below. 2/ make sure that d_splice_alias is used rather than d_add when ->lookup finds an inode for a given parent and name. - Typically the ->lookup routine will end with a: + + If inode is NULL, d_splice_alias(inode, dentry) is eqivalent to + + d_add(dentry, inode), NULL + + Similarly, d_splice_alias(ERR_PTR(err), dentry) = ERR_PTR(err) + + Typically the ->lookup routine will simply end with a: return d_splice_alias(inode, dentry); } diff --git a/Documentation/filesystems/nfs/nfs41-server.txt b/Documentation/filesystems/nfs/nfs41-server.txt index 04884914a1c8..092fad92a3f0 100644 --- a/Documentation/filesystems/nfs/nfs41-server.txt +++ b/Documentation/filesystems/nfs/nfs41-server.txt @@ -39,27 +39,17 @@ interoperability problems with future clients. Known issues: from a linux client are possible, but we aren't really conformant with the spec (for example, we don't use kerberos on the backchannel correctly). - - no trunking support: no clients currently take advantage of - trunking, but this is a mandatory feature, and its use is - recommended to clients in a number of places. (E.g. to ensure - timely renewal in case an existing connection's retry timeouts - have gotten too long; see section 8.3 of the RFC.) - Therefore, lack of this feature may cause future clients to - fail. - Incomplete backchannel support: incomplete backchannel gss support and no support for BACKCHANNEL_CTL mean that callbacks (hence delegations and layouts) may not be available and clients confused by the incomplete implementation may fail. - - Server reboot recovery is unsupported; if the server reboots, - clients may fail. - We do not support SSV, which provides security for shared client-server state (thus preventing unauthorized tampering with locks and opens, for example). It is mandatory for servers to support this, though no clients use it yet. - Mandatory operations which we do not support, such as - DESTROY_CLIENTID, FREE_STATEID, SECINFO_NO_NAME, and - TEST_STATEID, are not currently used by clients, but will be + DESTROY_CLIENTID, are not currently used by clients, but will be (and the spec recommends their uses in common cases), and clients should not be expected to know how to recover from the case where they are not supported. This will eventually cause @@ -69,8 +59,9 @@ In addition, some limitations are inherited from the current NFSv4 implementation: - Incomplete delegation enforcement: if a file is renamed or - unlinked, a client holding a delegation may continue to - indefinitely allow opens of the file under the old name. + unlinked by a local process, a client holding a delegation may + continue to indefinitely allow opens of the file under the old + name. The table below, taken from the NFSv4.1 document, lists the operations that are mandatory to implement (REQ), optional @@ -99,7 +90,7 @@ Operations +----------------------+------------+--------------+----------------+ | ACCESS | REQ | | Section 18.1 | NS | BACKCHANNEL_CTL | REQ | | Section 18.33 | -NS | BIND_CONN_TO_SESSION | REQ | | Section 18.34 | +I | BIND_CONN_TO_SESSION | REQ | | Section 18.34 | | CLOSE | REQ | | Section 18.2 | | COMMIT | REQ | | Section 18.3 | | CREATE | REQ | | Section 18.4 | @@ -111,7 +102,7 @@ NS*| DELEGPURGE | OPT | FDELG (REQ) | Section 18.5 | NS | DESTROY_CLIENTID | REQ | | Section 18.50 | I | DESTROY_SESSION | REQ | | Section 18.37 | I | EXCHANGE_ID | REQ | | Section 18.35 | -NS | FREE_STATEID | REQ | | Section 18.38 | +I | FREE_STATEID | REQ | | Section 18.38 | | GETATTR | REQ | | Section 18.7 | P | GETDEVICEINFO | OPT | pNFS (REQ) | Section 18.40 | P | GETDEVICELIST | OPT | pNFS (OPT) | Section 18.41 | @@ -145,14 +136,14 @@ NS*| OPENATTR | OPT | | Section 18.17 | | RESTOREFH | REQ | | Section 18.27 | | SAVEFH | REQ | | Section 18.28 | | SECINFO | REQ | | Section 18.29 | -NS | SECINFO_NO_NAME | REC | pNFS files | Section 18.45, | +I | SECINFO_NO_NAME | REC | pNFS files | Section 18.45, | | | | layout (REQ) | Section 13.12 | I | SEQUENCE | REQ | | Section 18.46 | | SETATTR | REQ | | Section 18.30 | | SETCLIENTID | MNI | | N/A | | SETCLIENTID_CONFIRM | MNI | | N/A | NS | SET_SSV | REQ | | Section 18.47 | -NS | TEST_STATEID | REQ | | Section 18.48 | +I | TEST_STATEID | REQ | | Section 18.48 | | VERIFY | REQ | | Section 18.31 | NS*| WANT_DELEGATION | OPT | FDELG (OPT) | Section 18.49 | | WRITE | REQ | | Section 18.32 | @@ -206,12 +197,6 @@ CREATE_SESSION: SEQUENCE: * no support for dynamic slot table renegotiation (optional) -nfsv4.1 COMPOUND rules: -The following cases aren't supported yet: -* Enforcing of NFS4ERR_NOT_ONLY_OP for: BIND_CONN_TO_SESSION, CREATE_SESSION, - DESTROY_CLIENTID, DESTROY_SESSION, EXCHANGE_ID. -* DESTROY_SESSION MUST be the final operation in the COMPOUND request. - Nonstandard compound limitations: * No support for a sessions fore channel RPC compound that requires both a ca_maxrequestsize request and a ca_maxresponsesize reply, so we may @@ -219,3 +204,5 @@ Nonstandard compound limitations: negotiation. * No more than one IO operation (read, write, readdir) allowed per compound. + +See also http://wiki.linux-nfs.org/wiki/index.php/Server_4.0_and_4.1_issues. diff --git a/Documentation/filesystems/nfs/nfsroot.txt b/Documentation/filesystems/nfs/nfsroot.txt index 90c71c6f0d00..ffdd9d866ad7 100644 --- a/Documentation/filesystems/nfs/nfsroot.txt +++ b/Documentation/filesystems/nfs/nfsroot.txt @@ -226,7 +226,7 @@ They depend on various facilities being available: cdrecord. e.g. - cdrecord dev=ATAPI:1,0,0 arch/i386/boot/image.iso + cdrecord dev=ATAPI:1,0,0 arch/x86/boot/image.iso For more information on isolinux, including how to create bootdisks for prebuilt kernels, see http://syslinux.zytor.com/ diff --git a/Documentation/filesystems/nilfs2.txt b/Documentation/filesystems/nilfs2.txt index d5c0cef38a71..873a2ab2e9f8 100644 --- a/Documentation/filesystems/nilfs2.txt +++ b/Documentation/filesystems/nilfs2.txt @@ -40,7 +40,6 @@ Features which NILFS2 does not support yet: - POSIX ACLs - quotas - fsck - - resize - defragmentation Mount options diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index 6e29954851a2..b4a3d765ff9a 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -400,10 +400,32 @@ a file off. -- [mandatory] - --- -[mandatory] ->get_sb() is gone. Switch to use of ->mount(). Typically it's just a matter of switching from calling get_sb_... to mount_... and changing the function type. If you were doing it manually, just switch from setting ->mnt_root to some pointer to returning that pointer. On errors return ERR_PTR(...). + +-- +[mandatory] + ->permission() and generic_permission()have lost flags +argument; instead of passing IPERM_FLAG_RCU we add MAY_NOT_BLOCK into mask. + generic_permission() has also lost the check_acl argument; ACL checking +has been taken to VFS and filesystems need to provide a non-NULL ->i_op->get_acl +to read an ACL from disk. + +-- +[mandatory] + If you implement your own ->llseek() you must handle SEEK_HOLE and +SEEK_DATA. You can hanle this by returning -EINVAL, but it would be nicer to +support it in some way. The generic handler assumes that the entire file is +data and there is a virtual hole at the end of the file. So if the provided +offset is less than i_size and SEEK_DATA is specified, return the same offset. +If the above is true for the offset and you are given SEEK_HOLE, return the end +of the file. If the offset is i_size or greater return -ENXIO in either case. + +[mandatory] + If you have your own ->fsync() you must make sure to call +filemap_write_and_wait_range() so that all dirty pages are synced out properly. +You must also keep in mind that ->fsync() is not called with i_mutex held +anymore, so if you require i_mutex locking you must make sure to take it and +release it yourself. diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index f48178024067..db3b1aba32a3 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -843,6 +843,7 @@ Provides counts of softirq handlers serviced since boot time, for each cpu. TASKLET: 0 0 0 290 SCHED: 27035 26983 26971 26746 HRTIMER: 0 0 0 0 + RCU: 1678 1769 2178 2250 1.3 IDE devices in /proc/ide diff --git a/Documentation/filesystems/squashfs.txt b/Documentation/filesystems/squashfs.txt index d4d41465a0b1..7db3ebda5a4c 100644 --- a/Documentation/filesystems/squashfs.txt +++ b/Documentation/filesystems/squashfs.txt @@ -2,7 +2,7 @@ SQUASHFS 4.0 FILESYSTEM ======================= Squashfs is a compressed read-only filesystem for Linux. -It uses zlib/lzo compression to compress files, inodes and directories. +It uses zlib/lzo/xz compression to compress files, inodes and directories. Inodes in the system are very small and all blocks are packed to minimise data overhead. Block sizes greater than 4K are supported up to a maximum of 1Mbytes (default block size 128K). @@ -55,6 +55,8 @@ create populated squashfs filesystems. This and other squashfs utilities can be obtained from http://www.squashfs.org. Usage instructions can be obtained from this site also. +The squashfs-tools development tree is now located on kernel.org + git://git.kernel.org/pub/scm/fs/squashfs/squashfs-tools.git 3. SQUASHFS FILESYSTEM DESIGN ----------------------------- diff --git a/Documentation/filesystems/ubifs.txt b/Documentation/filesystems/ubifs.txt index 8e4fab639d9c..a0a61d2f389f 100644 --- a/Documentation/filesystems/ubifs.txt +++ b/Documentation/filesystems/ubifs.txt @@ -111,34 +111,6 @@ The following is an example of the kernel boot arguments to attach mtd0 to UBI and mount volume "rootfs": ubi.mtd=0 root=ubi0:rootfs rootfstype=ubifs - -Module Parameters for Debugging -=============================== - -When UBIFS has been compiled with debugging enabled, there are 2 module -parameters that are available to control aspects of testing and debugging. - -debug_chks Selects extra checks that UBIFS can do while running: - - Check Flag value - - General checks 1 - Check Tree Node Cache (TNC) 2 - Check indexing tree size 4 - Check orphan area 8 - Check old indexing tree 16 - Check LEB properties (lprops) 32 - Check leaf nodes and inodes 64 - -debug_tsts Selects a mode of testing, as follows: - - Test mode Flag value - - Failure mode for recovery testing 4 - -For example, set debug_chks to 3 to enable general and TNC checks. - - References ========== diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 88b9f5519af9..52d8fb81cfff 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -229,6 +229,8 @@ struct super_operations { ssize_t (*quota_read)(struct super_block *, int, char *, size_t, loff_t); ssize_t (*quota_write)(struct super_block *, int, const char *, size_t, loff_t); + int (*nr_cached_objects)(struct super_block *); + void (*free_cached_objects)(struct super_block *, int); }; All methods are called without any locks being held, unless otherwise @@ -301,6 +303,26 @@ or bottom half). quota_write: called by the VFS to write to filesystem quota file. + nr_cached_objects: called by the sb cache shrinking function for the + filesystem to return the number of freeable cached objects it contains. + Optional. + + free_cache_objects: called by the sb cache shrinking function for the + filesystem to scan the number of objects indicated to try to free them. + Optional, but any filesystem implementing this method needs to also + implement ->nr_cached_objects for it to be called correctly. + + We can't do anything with any errors that the filesystem might + encountered, hence the void return type. This will never be called if + the VM is trying to reclaim under GFP_NOFS conditions, hence this + method does not need to handle that situation itself. + + Implementations must include conditional reschedule calls inside any + scanning loop that is done. This allows the VFS to determine + appropriate scan batch sizes without having to worry about whether + implementations will cause holdoff problems due to large scan batch + sizes. + Whoever sets up the inode is responsible for filling in the "i_op" field. This is a pointer to a "struct inode_operations" which describes the methods that can be performed on individual inodes. @@ -333,8 +355,8 @@ struct inode_operations { void * (*follow_link) (struct dentry *, struct nameidata *); void (*put_link) (struct dentry *, struct nameidata *, void *); void (*truncate) (struct inode *); - int (*permission) (struct inode *, int, unsigned int); - int (*check_acl)(struct inode *, int, unsigned int); + int (*permission) (struct inode *, int); + int (*get_acl)(struct inode *, int); int (*setattr) (struct dentry *, struct iattr *); int (*getattr) (struct vfsmount *mnt, struct dentry *, struct kstat *); int (*setxattr) (struct dentry *, const char *,const void *,size_t,int); @@ -423,7 +445,7 @@ otherwise noted. permission: called by the VFS to check for access rights on a POSIX-like filesystem. - May be called in rcu-walk mode (flags & IPERM_FLAG_RCU). If in rcu-walk + May be called in rcu-walk mode (mask & MAY_NOT_BLOCK). If in rcu-walk mode, the filesystem must check the permission without blocking or storing to the inode. @@ -755,7 +777,7 @@ struct file_operations { int (*open) (struct inode *, struct file *); int (*flush) (struct file *); int (*release) (struct inode *, struct file *); - int (*fsync) (struct file *, int datasync); + int (*fsync) (struct file *, loff_t, loff_t, int datasync); int (*aio_fsync) (struct kiocb *, int datasync); int (*fasync) (int, struct file *, int); int (*lock) (struct file *, int, struct file_lock *); diff --git a/Documentation/hwmon/f71882fg b/Documentation/hwmon/f71882fg index 84d2623810f3..de91c0db5846 100644 --- a/Documentation/hwmon/f71882fg +++ b/Documentation/hwmon/f71882fg @@ -22,6 +22,10 @@ Supported chips: Prefix: 'f71869' Addresses scanned: none, address read from Super I/O config space Datasheet: Available from the Fintek website + * Fintek F71869A + Prefix: 'f71869a' + Addresses scanned: none, address read from Super I/O config space + Datasheet: Not public * Fintek F71882FG and F71883FG Prefix: 'f71882fg' Addresses scanned: none, address read from Super I/O config space diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index 38425f0f2645..6f496a586732 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -76,7 +76,8 @@ IT8718F, IT8720F, IT8721F, IT8726F, IT8758E and SiS950 chips. These chips are 'Super I/O chips', supporting floppy disks, infrared ports, joysticks and other miscellaneous stuff. For hardware monitoring, they include an 'environment controller' with 3 temperature sensors, 3 fan -rotation speed sensors, 8 voltage sensors, and associated alarms. +rotation speed sensors, 8 voltage sensors, associated alarms, and chassis +intrusion detection. The IT8712F and IT8716F additionally feature VID inputs, used to report the Vcore voltage of the processor. The early IT8712F have 5 VID pins, diff --git a/Documentation/hwmon/k10temp b/Documentation/hwmon/k10temp index 0393c89277c0..a10f73624ad3 100644 --- a/Documentation/hwmon/k10temp +++ b/Documentation/hwmon/k10temp @@ -9,8 +9,8 @@ Supported chips: Socket S1G3: Athlon II, Sempron, Turion II * AMD Family 11h processors: Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra) -* AMD Family 12h processors: "Llano" -* AMD Family 14h processors: "Brazos" (C/E/G-Series) +* AMD Family 12h processors: "Llano" (E2/A4/A6/A8-Series) +* AMD Family 14h processors: "Brazos" (C/E/G/Z-Series) * AMD Family 15h processors: "Bulldozer" Prefix: 'k10temp' @@ -20,12 +20,16 @@ Supported chips: http://support.amd.com/us/Processor_TechDocs/31116.pdf BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors: http://support.amd.com/us/Processor_TechDocs/41256.pdf + BIOS and Kernel Developer's Guide (BKDG) for AMD Family 12h Processors: + http://support.amd.com/us/Processor_TechDocs/41131.pdf BIOS and Kernel Developer's Guide (BKDG) for AMD Family 14h Models 00h-0Fh Processors: http://support.amd.com/us/Processor_TechDocs/43170.pdf Revision Guide for AMD Family 10h Processors: http://support.amd.com/us/Processor_TechDocs/41322.pdf Revision Guide for AMD Family 11h Processors: http://support.amd.com/us/Processor_TechDocs/41788.pdf + Revision Guide for AMD Family 12h Processors: + http://support.amd.com/us/Processor_TechDocs/44739.pdf Revision Guide for AMD Family 14h Models 00h-0Fh Processors: http://support.amd.com/us/Processor_TechDocs/47534.pdf AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks: diff --git a/Documentation/hwmon/lm78 b/Documentation/hwmon/lm78 index 60932e26abaa..2bdc881a0c12 100644 --- a/Documentation/hwmon/lm78 +++ b/Documentation/hwmon/lm78 @@ -13,7 +13,8 @@ Supported chips: Datasheet: Publicly available at the National Semiconductor website http://www.national.com/ -Author: Frodo Looijaard <frodol@dds.nl> +Authors: Frodo Looijaard <frodol@dds.nl> + Jean Delvare <khali@linux-fr.org> Description ----------- diff --git a/Documentation/hwmon/sch5636 b/Documentation/hwmon/sch5636 new file mode 100644 index 000000000000..f83bd1c260f0 --- /dev/null +++ b/Documentation/hwmon/sch5636 @@ -0,0 +1,31 @@ +Kernel driver sch5636 +===================== + +Supported chips: + * SMSC SCH5636 + Prefix: 'sch5636' + Addresses scanned: none, address read from Super I/O config space + +Author: Hans de Goede <hdegoede@redhat.com> + + +Description +----------- + +SMSC SCH5636 Super I/O chips include an embedded microcontroller for +hardware monitoring solutions, allowing motherboard manufacturers to create +their own custom hwmon solution based upon the SCH5636. + +Currently the sch5636 driver only supports the Fujitsu Theseus SCH5636 based +hwmon solution. The sch5636 driver runs a sanity check on loading to ensure +it is dealing with a Fujitsu Theseus and not with another custom SCH5636 based +hwmon solution. + +The Fujitsu Theseus can monitor up to 5 voltages, 8 fans and 16 +temperatures. Note that the driver detects how many fan headers / +temperature sensors are actually implemented on the motherboard, so you will +likely see fewer temperature and fan inputs. + +An application note describing the Theseus' registers, as well as an +application note describing the protocol for communicating with the +microcontroller is available upon request. Please mail me if you want a copy. diff --git a/Documentation/i2o/ioctl b/Documentation/i2o/ioctl index 1e77fac4e120..22ca53a67e23 100644 --- a/Documentation/i2o/ioctl +++ b/Documentation/i2o/ioctl @@ -110,7 +110,7 @@ V. Getting Logical Configuration Table ENOBUFS Buffer not large enough. If this occurs, the required buffer length is written into *(lct->reslen) -VI. Settting Parameters +VI. Setting Parameters SYNOPSIS diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 3a46e360496d..72ba8d51dbc1 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -301,6 +301,7 @@ Code Seq#(hex) Include File Comments <mailto:rusty@rustcorp.com.au> 0xAE all linux/kvm.h Kernel-based Virtual Machine <mailto:kvm@vger.kernel.org> +0xAF 00-1F linux/fsl_hypervisor.h Freescale hypervisor 0xB0 all RATIO devices in development: <mailto:vgo@ratio.de> 0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca> diff --git a/Documentation/isdn/README.HiSax b/Documentation/isdn/README.HiSax index 99e87a61897d..b1a573cf4472 100644 --- a/Documentation/isdn/README.HiSax +++ b/Documentation/isdn/README.HiSax @@ -506,7 +506,7 @@ to e.g. the Internet: <ISDN subsystem - ISDN support -- HiSax> make clean; make zImage; make modules; make modules_install 2. Install the new kernel - cp /usr/src/linux/arch/i386/boot/zImage /etc/kernel/linux.isdn + cp /usr/src/linux/arch/x86/boot/zImage /etc/kernel/linux.isdn vi /etc/lilo.conf <add new kernel in the bootable image section> lilo diff --git a/Documentation/ja_JP/SubmitChecklist b/Documentation/ja_JP/SubmitChecklist index 2df4576f1173..cb5507b1ac81 100644 --- a/Documentation/ja_JP/SubmitChecklist +++ b/Documentation/ja_JP/SubmitChecklist @@ -68,7 +68,7 @@ Linux 銈兗銉嶃儷銉戙儍銉佹姇绋胯呭悜銇戙儊銈с儍銈儶銈广儓 12: CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, CONFIG_DEBUG_SPINLOCK, - CONFIG_DEBUG_SPINLOCK_SLEEP 銇撱倢銈夊叏銇︺倰鍚屾檪銇湁鍔广伀銇椼仸鍕曚綔纰鸿獚銈 + CONFIG_DEBUG_ATOMIC_SLEEP 銇撱倢銈夊叏銇︺倰鍚屾檪銇湁鍔广伀銇椼仸鍕曚綔纰鸿獚銈 琛屻仯銇︺亸銇犮仌銇勩 13: CONFIG_SMP, CONFIG_PREEMPT 銈掓湁鍔广伀銇椼仧鍫村悎銇ㄧ劇鍔广伀銇椼仧鍫村悎銇浮鏂广仹 diff --git a/Documentation/ja_JP/SubmittingPatches b/Documentation/ja_JP/SubmittingPatches index f107c834d242..97f78dd0c085 100644 --- a/Documentation/ja_JP/SubmittingPatches +++ b/Documentation/ja_JP/SubmittingPatches @@ -11,16 +11,18 @@ for non English (read: Japanese) speakers and is not intended as a fork. So if you have any comments or updates of this file, please try to update the original English file first. -Last Updated: 2007/10/24 +Last Updated: 2011/06/09 + ================================== 銇撱倢銇 -linux-2.6.23/Documentation/SubmittingPatches 銇拰瑷 +linux-2.6.39/Documentation/SubmittingPatches 銇拰瑷 銇с仚銆 缈昏ǔ鍥ｄ綋锛 JF 銉椼儹銈搞偋銈儓 < http://www.linux.or.jp/JF/ > -缈昏ǔ鏃ワ細 2007/10/17 +缈昏ǔ鏃ワ細 2011/06/09 缈昏ǔ鑰咃細 Keiichi Kii <k-keiichi at bx dot jp dot nec dot com> 鏍℃鑰咃細 Masanari Kobayashi 銇曘倱 <zap03216 at nifty dot ne dot jp> Matsukura 銇曘倱 <nbh--mats at nifty dot com> + Takeshi Hamasaki 銇曘倱 <hmatrjp at users dot sourceforge dot jp> ================================== Linux 銈兗銉嶃儷銇鏇淬倰鍔犮亪銈嬨仧銈併伄 Howto @@ -97,7 +99,7 @@ Quilt: http://savannah.nongnu.org/projects/quilt Andrew Morton's patch scripts: -http://userweb.kernel.org/~akpm/stuff/tpp.txt +http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz 銇撱伄銉兂銈伄鍏堛伄銈广偗銉儣銉堛伄浠ｃ倧銈娿仺銇椼仸銆乹uilt 銇屻儜銉冦儊銉炪儘銈搞儭銉炽儓 銉勩兗銉仺銇椼仸鎺ㄥエ銇曘倢銇︺亜銇俱仚(涓娿伄銉兂銈倰瑕嬨仸銇忋仩銇曘亜)銆 @@ -109,9 +111,25 @@ http://userweb.kernel.org/~akpm/stuff/tpp.txt 銆屻儔銉┿偆銉愩兗 X 銇銇欍倠銉愩偘銉曘偅銉冦偗銈广嶃亗銈嬨亜銇屻亾銇儜銉冦儊銇偟銉栥偡銈 銉嗐儬 X 銇銇欍倠鏇存柊銈掑惈銈撱仹銇勩伨銇欍傘仼銇嗐亱鍙栥倞鍏ャ倢銇︺亸銇犮仌銇勩傘嶃仾銇┿仹銇欍 +銉戙儍銉併伄瑾槑銈 Linux 銈兗銉嶃儷銇偨銉笺偣銈炽兗銉夈優銉嶃偢銉°兂銉堛偡銈广儐銉犮 git 銆嶃伄 +銈炽儫銉冦儓銉偘銇ㄣ仐銇︾啊鍗樸伀寮曠敤銇с亶銈嬪舰銇ф浉銇戙伆銆併儭銉炽儐銉娿亱銈夋劅璎濄仌銈屻倠銇с仐銈囥亞銆 +浠ヤ笅銇 #15 銈掕銇︺亸銇犮仌銇勩 + 瑾槑銇岄暦銇忋仾銈娿仩銇椼仧銇仹銇傘倢銇般併亰銇濄倝銇忋仢銈屻伅銉戙儍銉併倰鍒嗐亼銈嬪繀瑕併亴銇傘倠 銇ㄣ亜銇嗗厗鍊欍仹銇欍傛銇 #3 銈掕銇︺亸銇犮仌銇勩 +銉戙儍銉(銈枫儶銉笺偤)銈(鍐)鎶曠ǹ銇欍倠鏅傘佸崄鍒嗐仾銉戙儍銉併伄瑾槑銇ㄣ仢銇儜銉冦儊銇屽繀瑕併仾鐞嗙敱銈 +銉戙儍銉併伀鍚倎銇︺亸銇犮仌銇勩傘仧銇犮屻亾銈屻伅銉戙儍銉(銈枫儶銉笺偤)銇儛銉笺偢銉с兂 N銆嶃仺銇犮亼 +鏇搞亱銇亜銇с亸銇犮仌銇勩傘仢銇椼仸銆併儜銉冦儊銈掋優銉笺偢銇欍倠浜恒伀銉戙儍銉併伄瑾槑銈掓帰銇曘仜銇濄倢銈 +銉戙儍銉併伀杩借銇曘仜銈嬨仧銈併侀亷鍘汇伄銉愩兗銈搞儳銉炽伄銉戙儍銉併倓銇濄伄銉戙儍銉併伄 URL 銈掑弬鐓с仚銈 +鎵嬮枔銈掋亱銇戙仌銇涖仾銇勩仹銇忋仩銇曘亜銆 +銇ゃ伨銈娿併儜銉冦儊銈枫儶銉笺偤銇ㄣ仢銇鏄庛伅涓绶掋伀銇傘倠銇广亶銇с仚銆傘亾銈屻伅銉戙儍銉併倰銉炪兗銈搞仚銈 +浜恒併儸銉撱儱銉笺仚銈嬩汉銆併仼銇°倝銇仧銈併伀銈傘仾銈娿伨銇欍傘儸銉撱儱銉笺仚銈嬩汉銇腑銇伅銆併亰銇濄倝銇 +閬庡幓銇儛銉笺偢銉с兂銇儜銉冦儊銈掑彈銇戝彇銇ｃ仸銈傘亜銇亜浜恒亴銇勩伨銇欍 + +鐧婚尣娓堛伩銇儛銈般偍銉炽儓銉倰淇銇欍倠銉戙儍銉併仹銇傘倢銇般併仢銇儛銈般偍銉炽儓銉倰绀恒仚銉愩偘 ID +銈 URL 銈掓槑瑷樸仐銇︺亸銇犮仌銇勩 + 3) 銉戙儍銉併伄鍒嗗壊 鎰忓懗銇亗銈嬨伈銇ㄣ伨銇ㄣ伨銈娿仈銇ㄣ伀澶夋洿銈掑嬨呫伄銉戙儍銉併儠銈°偆銉伀鍒嗐亼銇︺亸銇犮仌銇勩 @@ -141,7 +159,7 @@ http://userweb.kernel.org/~akpm/stuff/tpp.txt 鎷掑惁銇曘倢銈嬨仹銇椼倗銇嗐 銇傘仾銇熴伅銉戙儍銉併倰鎶曠ǹ銇欍倠鍓嶃伀鏈浣庨檺銉戙儍銉併偣銈裤偆銉儊銈с儍銈兗 -( scripts/patchcheck.pl )銈掑埄鐢ㄣ仐銇︺儜銉冦儊銈掋儊銈с儍銈仚銇广亶銇с仚銆 +( scripts/checkpatch.pl )銈掑埄鐢ㄣ仐銇︺儜銉冦儊銈掋儊銈с儍銈仚銇广亶銇с仚銆 銈傘仐銉戙儍銉併伀閬曞弽銇屻伄銇撱仯銇︺亜銈嬨仾銈夈伆銆併仢銈屻倝銇叏銇︺伀銇ゃ亜銇︺亗銇仧銇褰撱仾 鐞嗙敱銈掔ず銇涖倠銈堛亞銇仐銇︺亰銇忓繀瑕併亴銇傘倞銇俱仚銆 @@ -192,13 +210,13 @@ VGER.KERNEL.ORG 銇с儧銈广儐銈ｃ兂銈般仌銈屻仸銇勩倠銉°兗銉兂銈般儶銈广儓銇 鎯呭牨銇屻優銉嬨儱銈€儷銉氥兗銈搞伄涓伀鍏ャ仯銇︺亸銈嬨倛銇嗐伀銆佸鏇淬亴璧枫亶銇熴仺銇勩亞 閫氱煡銈掗併仯銇︺亸銇犮仌銇勩 -銇熴仺銇堛併儭銉炽儐銉娿亴 #4 銇у弽蹇溿亴銇亱銇ｃ仧銇ㄣ仐銇︺倐銆併儭銉炽儐銉娿伄銈炽兗銉夈伀澶夋洿銈 +銇熴仺銇堛併儭銉炽儐銉娿亴 #5 銇у弽蹇溿亴銇亱銇ｃ仧銇ㄣ仐銇︺倐銆併儭銉炽儐銉娿伄銈炽兗銉夈伀澶夋洿銈 鍔犮亪銇熴仺銇嶃伀銇併亜銇ゃ倐銉°兂銉嗐儕銇 CC 銇欍倠銇倰蹇樸倢銇亜銈堛亞銇仐銇︺亸銇犮仌銇勩 -灏忋仌銇儜銉冦儊銇с亗銈屻伆銆丄drian Bunk 銇岀鐞嗐仐銇︺亜銈 Trivial Patch Monkey -(銇°倗銇ｃ仺銇椼仧銉戙儍銉併倰闆嗐倎銇︺亜銈)<trivial@kernel.org>銇 CC 銇椼仸銈傘亜銇 -銇с仚銆傘仭銈囥仯銇ㄣ仐銇熴儜銉冦儊銇ㄣ伅浠ヤ笅銇儷銉笺儷銇仼銈屻亱1銇ゃ倰婧銇熴仐銇︺亜銇亼 -銈屻伆銇倞銇俱仜銈撱 +灏忋仌銇儜銉冦儊銇с亗銈屻伆銆乀rivial Patch Monkey(銇°倗銇ｃ仺銇椼仧銉戙儍銉併倰闆嗐倎銇︺亜銈) +<trivial@kernel.org>銇 CC 銇椼仸銈傘亜銇勩仹銇欍傘仢銇従绠＄悊鑰呫伀銇ゃ亜銇︺伅 MAINTAINERS +銉曘偂銈ゃ儷銈掕銇︺亸銇犮仌銇勩傘仭銈囥仯銇ㄣ仐銇熴儜銉冦儊銇ㄣ伅浠ヤ笅銇儷銉笺儷銇仼銈屻亱1銇ゃ倰婧銇熴仐銇 +銇勩仾銇戙倢銇般仾銈娿伨銇涖倱銆 銉汇儔銈儱銉°兂銉堛伄銈广儦銉儫銈广伄淇 銉籫rep(1) 銈炽優銉炽儔銇倛銈嬫绱€倰鍥伴洠銇仐銇︺亜銈嬨偣銉氥儷銇慨姝 銉汇偝銉炽儜銈ゃ儷鏅傘伄璀﹀憡銇慨姝(鐒￠銇鍛娿亴鏁ｄ贡銇欍倠銇撱仺銇ソ銇俱仐銇忋仾銇勩仧 @@ -210,7 +228,6 @@ VGER.KERNEL.ORG 銇с儧銈广儐銈ｃ兂銈般仌銈屻仸銇勩倠銉°兗銉兂銈般儶銈广儓銇 銉荤Щ妞嶆с伄銇亜銈炽兗銉夈亱銈夌Щ妞嶆с伄銇傘倠銈炽兗銉夈伕銇疆銇嶆彌銇(灏忋仌銇勭瘎鍥层仹 銇傘倢銇般偄銉笺偔銉嗐偗銉併儯鐗规湁銇亾銇ㄣ仹銈備粬銇汉銇屻偝銉斻兗銇с亶銇俱仚) 銉讳綔鑰呫倓銉°兂銉嗐儕銇倛銈嬩慨姝(銇欍仾銈忋仭 patch monkey 銇啀杌㈤併儮銉笺儔) -EMAIL: <trivial@kernel.org> 7) MIME 銈勩儶銉炽偗銈勫湩绺儠銈°偆銉倓娣讳粯銉曘偂銈ゃ儷銇с伅銇亸銉椼儸銈ゃ兂銉嗐偔銈广儓銇伩 @@ -233,26 +250,15 @@ MIME 褰㈠紡銇坊浠樸儠銈°偆銉伅 Linus 銇墜闁撱倰鍙栥倝銇涖倠銇撱仺銇仾銈 渚嬪锛氥亰浣裤亜銇浕瀛愩儭銉笺儷銈儵銈ゃ偄銉炽儓銇屻儜銉冦儊銈掋倎銇°們銇忋仭銈冦伀銇欍倠銇仹 銇傘倢銇般佽銇嬨亴 MIME 褰㈠紡銇儜銉冦儊銈掑啀閫併仚銈嬨倛銇嗘眰銈併倠銇嬨倐銇椼倢銇俱仜銈撱 -璀﹀憡锛 Mozilla 銇倛銇嗐仾鐗瑰畾銇浕瀛愩儭銉笺儷銈儵銈ゃ偄銉炽儓銇浕瀛愩儭銉笺儷銇 -銉樸儍銉銇互涓嬨伄銈傘伄銈掍粯鍔犮仐銇﹂併倞銇俱仚銆 ----- message header ---- -Content-Type: text/plain; charset=us-ascii; format=flowed ----- message header ---- -鍟忛銇併 format=flowed 銆嶃亴浠樸亜銇熼浕瀛愩儭銉笺儷銈掔壒瀹氥伄鍙椾俊鍋淬伄闆诲瓙銉°兗銉 -銈儵銈ゃ偄銉炽儓銇屻偪銉栥倰銈广儦銉笺偣銇疆銇嶆彌銇堛倠銇ㄣ亜銇嗐倛銇嗐仾澶夋洿銈掋仚銈嬨亾銇ㄣ仹銇欍 -銇椼仧銇屻仯銇﹂併倝銈屻仸銇嶃仧銉戙儍銉併伅澹娿倢銇︺亜銈嬨倛銇嗐伀瑕嬨亪銈嬨仹銇椼倗銇嗐 - -銇撱倢銈掍慨姝ｃ仚銈嬨伀銇乵ozilla 銇 defaults/pref/mailnews.js 銉曘偂銈ゃ儷銈 -浠ヤ笅銇倛銇嗐伀淇銇椼伨銇欍 -pref("mailnews.send_plaintext_flowed", false); // RFC 2646======= -pref("mailnews.display.disable_format_flowed_support", true); +浣欒▓銇鏇淬倰鍔犮亪銇氥伀銇傘仾銇熴伄銉戙儍銉併倰閫佷俊銇欍倠銇熴倎銇浕瀛愩儭銉笺儷銈儵銈ゃ偄銉炽儓銇ō瀹 +銇儝銉炽儓銇仱銇勩仸銇 Documentation/email-clients.txt 銈掑弬鐓с仐銇︺亸銇犮仌銇勩 8) 闆诲瓙銉°兗銉伄銈点偆銈 銉戙儍銉併倰 Linus 銇搁併倠銇ㄣ亶銇父銇 #7 銇墜闋嗐伀寰撱仯銇︺亸銇犮仌銇勩 澶с亶銇儜銉冦儊銇儭銉笺儶銉炽偘銉偣銉堛倓銉°兂銉嗐儕銇仺銇ｃ仸涓嶈Κ鍒囥仹銇欍傘儜銉冦儊銇 -鏈湩绺仹 40KB 銈掕秴銇堛倠銈堛亞銇с亗銈嬨仾銈夈併偆銉炽偪銉笺儘銉冦儓涓娿伄銈€偗銈汇偣鍙兘銇 +鏈湩绺仹 300KB 銈掕秴銇堛倠銈堛亞銇с亗銈嬨仾銈夈併偆銉炽偪銉笺儘銉冦儓涓娿伄銈€偗銈汇偣鍙兘銇 銈点兗銉愩伀淇濆瓨銇椼佷繚瀛樺牬鎵銈掔ず銇 URL 銈掍紳銇堛倠銇汇亞銇岄仼鍒囥仹銇欍 9) 銈兗銉嶃儷銉愩兗銈搞儳銉炽伄鏄庤 @@ -324,7 +330,7 @@ Linus 銈 LKML 銇搞伄澶ч噺銇浕瀛愩儭銉笺儷銇仧銈併伀銆併偟銉栥偢銈с偗銉堛 (c) 鏈瘎涓庛伅(a)銆(b)銆(c)銈掕鏄庛仚銈嬬3鑰呫亱銈夌銇哥洿鎺ユ彁渚涖仌銈屻仧 銈傘伄銇с亗銈娿佺銇仢銈屻伀澶夋洿銈掑姞銇堛仸銇勩仾銇勩 - (d) 绉併伅銇撱伄銉椼儹銈搞偋銈儓銇ㄦ湰瀵勪笌銇屽叕銇倐銇仹銇傘倠銇撱仺銇悊瑙ｅ強銇冲悓鎰忋仚 + (d) 绉併伅銇撱伄銉椼儹銈搞偋銈儓銇ㄦ湰瀵勪笌銇屽叕銇倐銇仹銇傘倠銇撱仺銇悊瑙ｅ強銇冲悓鎰忋仚 銈嬨傚悓鏅傘伀銆侀枹涓庛仐銇熻閷(鎶曠ǹ銇殯銇叏銇︺伄鍊嬩汉鎯呭牨銇 sign-off 銈 鍚個)銇岀劇鏈熼檺銇繚鍏ㄣ仌銈屻倠銇撱仺銇ㄣ佸綋瑭层儣銉偢銈с偗銉堝張銇枹閫ｃ仚銈 銈兗銉椼兂銈姐兗銈广儵銈ゃ偦銉炽偣銇部銇ｃ仧褰€仹鍐嶉厤甯冦仌銈屻倠銇撱仺銇悊瑙ｅ強銇 @@ -340,7 +346,51 @@ Linus 銈 LKML 銇搞伄澶ч噺銇浕瀛愩儭銉笺儷銇仧銈併伀銆併偟銉栥偢銈с偗銉堛 鐒¤銇曘倢銇俱仚銇屻併亗銇仧銇仢銇偪銈般倰绀惧唴銇墜缍氥亶銇埄鐢ㄣ仐銇熴倞銆乻ign-off 銇壒鍒 銇儏鍫便倰绀恒仐銇熴倞銇欍倠銇撱仺銇屻仹銇嶃伨銇欍 -13) 銇勩仱 Acked-by: 銈掍娇銇嗐伄銇 +銇傘仾銇熴亴銈点儢銈枫偣銉嗐儬銇俱仧銇儢銉┿兂銉併伄銉°兂銉嗐儕銇с亗銈屻伆銆佸彈銇戝彇銇ｃ仧銉戙儍銉併倰鑷韩銇 +銉勩儶銉笺伀銉炪兗銈搞仚銈嬨仧銈併伀銆併倧銇氥亱銇鏇淬亴蹇呰銇ㄣ仾銈嬪牬鍚堛亴銇傘倞銇俱仚銆傘仾銇溿仾銈 +銇傘仾銇熴伄銉勩儶銉笺伄涓伄銈炽兗銉夈仺鎶曠ǹ鑰呫伄銉勩儶銉笺伄涓伄銈炽兗銉夈伅鍚屼竴銇с伅銇亜銇熴倎銇с仚銆 +銈傘仐銆併亗銇仧銇屽幊瀵嗐伀涓婅銉兗銉(c)銇亾銇犮倧銈嬨伄銇с亗銈屻伆銆佹姇绋胯呫伀鍐嶅害宸垎銈 +銇ㄣ倠銈堛亞渚濋牸銇欍伖銇嶃仹銇欍傘仐銇嬨仐銆併亾銈屻伅鏅傞枔銇ㄣ偍銉嶃儷銈兗銈掗潪鐢熺敚鐨勩伀娴不銇欍倠 +銇撱仺銇仾銈娿伨銇欍傘儷銉笺儷(b)銇亗銇仧銇偝銉笺儔銈掍慨姝ｃ仚銈嬫ī鍒┿倰涓庛亪銇︺亸銈屻伨銇欍 +銇椼亱銇椼佹姇绋胯呫伄銈炽兗銉夈倰淇銇椼併仢銇慨姝ｃ伀銈堛倠銉愩偘銈掓姇绋胯呫伀鎶笺仐浠樸亼銇︺仐銇俱亞 +銇撱仺銇仺銇︺倐澶辩ぜ銇亾銇ㄣ仹銇欍傘亾銇晱椤屻倰瑙ｆ焙銇欍倠銇熴倎銇佹湯灏俱伄鎶曠ǹ鑰呫伄 +Signed-off-by 銇ㄣ亗銇仧銇屻仢銇湯灏俱伀杩藉姞銇欍倠 Signed-off-by 銇枔銇佷慨姝ｃ倰 +鍔犮亪銇熴亾銇ㄣ倰绀恒仚1琛屻倰杩藉姞銇欍倠銇撱仺銇屾帹濂ㄣ仌銈屻仸銇勩伨銇欍 +(銇濄伄1琛屻伄鏇搞亶鏂广伀)姹恒伨銈娿伅銇傘倞銇俱仜銈撱亴銆佸ぇ鎷姬銇腑銇浕瀛愩儭銉笺儷銈€儔銉偣銈勬皬鍚 +銇ㄤ慨姝ｅ唴瀹广倰瑷樿級銇欍倠銈勩倞鏂广伅鐩伀銇ゃ亶銈勩仚銇忋佹渶绲傛闅庛仹銇鏇淬伄璨换銇屻亗銇仧銇 +銇傘倠銇撱仺銈掓槑纰恒伀銇欍倠銇伀鍗佸垎銇柟娉曘伄銈堛亞銇с仚銆備緥銇堛伆銆 + + Signed-off-by: Random J Developer <random@developer.example.org> + [lucky@maintainer.example.org: struct foo moved from foo.c to foo.h] + Signed-off-by: Lucky K Maintainer <lucky@maintainer.example.org> + +銇傘仾銇熴亴瀹夊畾鐗堛伄銉栥儵銉炽儊銈掔鐞嗐仐銇︺亰銈娿佷綔鎴愯呫伄銈儸銈搞儍銉堛佸鏇淬伄杩借贰銆 +淇銇優銉笺偢銆併仺鍚屾檪銇嫤鎯呫亱銈夈伄鎶曠ǹ鑰呫伄淇濊銈掕銇勩仧銇勫牬鍚堛併亾銇叄缈掋伅鐗广伀 +鏈夌敤銇ㄣ仾銈娿伨銇欍傘亜銇嬨仾銈嬩簨鎯呫亴銇傘仯銇︺倐銉併偋銉炽偢銉偘銇嚭銇︺亸銈嬩綔鎴愯呫伄 +銈€偆銉囥兂銉嗐偅銉嗐偅鎯呭牨(From 銉樸儍銉)銇鏇淬仹銇嶃仾銇勩亾銇ㄣ伀娉ㄦ剰銇椼仸銇忋仩銇曘亜銆 + +銉愩儍銈儩銉笺儓銇欍倠浜恒伄銇熴倎銇壒鍒ャ仾娉ㄦ剰浜嬮爡銆傝拷璺°倰瀹规槗銇銇嗐仧銈併伀銆併偝銉熴儍銉 +銉°儍銈汇兗銈搞伄銉堛儍銉(銈点儢銈搞偋銈儓琛屻伄銇欍亹寰)銇儜銉冦儊銇捣婧愩倰绀恒仚鎯呭牨銈掕杩般仚銈 +銇撱仺銇竴鑸殑銇ф湁鐢ㄣ仾鎱ｇ繏銇с仚銆備緥銇堛伆銆併亾銈屻伅 2.6-stable 銉勩儶銉笺仹銇竴渚嬨仹銇欍 + + Date: Tue May 13 19:10:30 2008 +0000 + + SCSI: libiscsi regression in 2.6.25: fix nop timer handling + + commit 4cf1043593db6a337f10e006c23c69e5fc93e722 upstream + +銇濄仐銇︺併亾銈屻伅 2.4 銉勩儶銉笺仹銇竴渚嬨仹銇欍 + + Date: Tue May 13 22:12:27 2008 +0200 + + wireless, airo: waitbusy() won't delay + + [backport of 2.6 commit b7acbdfbd1f277c1eb23f344f899cfa4cd0bf36a] + +銇┿倱銇舰寮忋仹銇傘倢銆併亾銇儏鍫便伅銇傘仾銇熴伄銉勩儶銉笺倰杩借贰銇欍倠浜恒倓銇傘仾銇熴伄銉勩儶銉笺伄銉愩偘銈 +瑙ｆ焙銇椼倛銇嗐仺銇椼仸銇勩倠浜恒伀銇ㄣ仯銇︿尽鍊ゃ伄銇傘倠鏀彺銇ㄣ仾銈娿伨銇欍 + +13) 銇勩仱 Acked-by: 銇 Cc: 銈掍娇銇嗐伄銇 銆 Signed-off-by: 銆嶃偪銈般伅銇濄伄缃插悕鑰呫亴銉戙儍銉併伄闁嬬櫤銇枹銈忋仯銇︺亜銇熴亾銇ㄣ倓銉戙儍銉 銇紳鎾儜銈广伀銇勩仧銇撱仺銈掔ず銇椼仸銇勩伨銇欍 @@ -354,7 +404,7 @@ Linus 銈 LKML 銇搞伄澶ч噺銇浕瀛愩儭銉笺儷銇仧銈併伀銆併偟銉栥偢銈с偗銉堛 Acked-by: 銇 Signed-off-by: 銇倛銇嗐伀鍏紡銇偪銈般仹銇亗銈娿伨銇涖倱銆傘仢銈屻伅銉°兂銉嗐儕銇 灏戙仾銇忋仺銈傘儜銉冦儊銈掋儸銉撱儱銉笺仐銆佸悓鎰忋倰绀恒仐銇︺亜銈嬨仺銇勩亞瑷橀尣銇с仚銆傘仢銇倛銇嗐仾 -銇撱仺銇嬨倝銉戙儍銉併伄绲卞悎鑰呫亴銉°兂銉嗐儕銇屻亞銈撱佽壇銇勩仺鎬濄亞銈堛嶃仺銇勩亞鐧鸿█銈 +銇撱仺銇嬨倝銉戙儍銉併倰銉炪兗銈搞仚銈嬩汉銇屻儭銉炽儐銉娿伄銆屻亞銈撱佽壇銇勩仺鎬濄亞銈堛嶃仺銇勩亞鐧鸿█銈 Acked-by: 銇哥疆銇嶆彌銇堛倠銇撱仺銇屻亗銈娿伨銇欍 Acked-by: 銇屽繀銇氥仐銈傘儜銉冦儊鍏ㄤ綋銇壙瑾嶃倰绀恒仐銇︺亜銈嬨倧銇戙仹銇亗銈娿伨銇涖倱銆備緥銇堛伆銆 @@ -364,7 +414,62 @@ Acked-by: 銇屽繀銇氥仐銈傘儜銉冦儊鍏ㄤ綋銇壙瑾嶃倰绀恒仐銇︺亜銈嬨倧銇戙仹銇 銇撱伄鐐广伅銆併仈鑷垎銇у垽鏂仐銇︺亸銇犮仌銇勩(銇濄伄 Acked-by: 銇)鐤戙倧銇椼亜鍫村悎銇 銉°兗銉兂銈般儶銈广儓銈€兗銈偆銉栥伄涓伄澶у厓銇璜栥倰鍙傜収銇欍伖銇嶃仹銇欍 -14) 妯欐簴鐨勩仾銉戙儍銉併伄銉曘偐銉笺優銉冦儓 +銉戙儍銉併伀銈炽儭銉炽儓銇欍倠姗熶細銈掓寔銇ｃ仸銇勩仧銇屻併仢銇檪銇偝銉°兂銉堛仐銇亱銇ｃ仧浜恒亴銇勩倢銇般 +銇濄伄浜恒倰鎸囥仚銆孋c:銆嶃偪銈般倰浠绘剰銇ц拷鍔犮仐銇︺倐銇嬨伨銇勩伨銇涖倱銆傘亾銈屻伅鎸囧畾銇曘倢銇熶汉銇嬨倝銇 +鏄庣⒑銇偄銈偡銉с兂銇仐銇粯涓庛仹銇嶃倠鍞竴銇偪銈般仹銇欍 +銇撱伄銈裤偘銇儜銉冦儊銇枹蹇冦亴銇傘倠銇ㄦ濄倧銈屻倠浜洪仈銇屻仢銇儜銉冦儊銇璜栥伀鍚伨銈屻仸銇勩仧銇撱仺 +銈掓槑鏂囧寲銇椼伨銇欍 + +14) Reported-by 銇 Tested-by: 銇 Reviewed-by: 銇埄鐢 + +浠栥伄瑾般亱銇倛銇ｃ仸鍫卞憡銇曘倢銇熷晱椤屻倰淇銇欍倠銉戙儍銉併仹銇傘倢銇般佸晱椤屽牨鍛婅呫仺銇勩亞瀵勪笌銈 +銈儸銈搞儍銉堛仚銈嬨仧銈併伀銆丷eported-by: 銈裤偘銈掕拷鍔犮仚銈嬨亾銇ㄣ倰妞滆◣銇椼仸銇忋仩銇曘亜銆 +銇撱伨銈併伀銉愩偘鍫卞憡鑰呫倰銈儸銈搞儍銉堛仐銇︺亜銇忋亾銇ㄣ仹銆併亞銇俱亸銇勩亼銇般仢銇汉銇熴仭銇屽皢鏉ュ啀銇 +銈炽儫銉ャ儖銉嗐偅銇姏銇ㄣ仾銇ｃ仸銇忋倢銈嬨仹銇椼倗銇嗐 +銇熴仩銇椼佸牨鍛婅呫伄瑷卞彲鐒°亸銇撱伄銈裤偘銈掕拷鍔犮仐銇亜銈堛亞銇敞鎰忋仐銇︺亸銇犮仌銇勩傜壒銇 +鍟忛銇屽叕銇牬銇у牨鍛娿仌銈屻仸銇勩仾銇嬨仯銇熴伄銇с亗銈屻伆銆 + +Tested-by: 銈裤偘銇偪銈般仹鎸囧畾銇曘倢銇熶汉銇倛銇ｃ仸(銇傘倠鐠板涓嬨仹)銉戙儍銉併伄銉嗐偣銉堛伀鎴愬姛 +銇椼仸銇勩倠銇撱仺銈掔ず銇椼伨銇欍傘亾銇偪銈般伅銉°兂銉嗐儕銇儐銈广儓銇屽疅鏂芥笀銇裤仹銇傘倠銇撱仺銈 +鐭ャ倝銇涖佸皢鏉ャ伄闁㈤ｃ儜銉冦儊銇儐銈广儓鍗斿姏鑰呫倰瑕嬨仱銇戙倠鏂规硶銈掓彁渚涖仐銆併儐銈广儓瀹熸柦鑰呫伀 +瀵俱仚銈嬨偗銉偢銉冦儓銈掍繚瑷笺仐銇俱仚銆 + +Reviewed-by: 銈裤偘銇併仢銈屻仺銇暟銇倞銆佷笅瑷樸伄銉儞銉ャ兗銈㈠瑷銇笅銇儸銉撱儱銉笺仌銈屻 +鍙椼亼鍏ャ倢鍙兘銇ㄣ伩銇仌銈屻仧銉戙儍銉併仹銇傘倠銇撱仺銈掔ず銇椼伨銇欍 + + 銉儞銉ャ兗銈€伀銈堛倠鐩ｇ潱瀹ｈ█ + + 绉併伅 Reviewed-by: 銈裤偘銈掓彁绀恒仚銈嬨亾銇ㄣ伀銈堛仯銇︺佷互涓嬨伄銇撱仺銈掓槑瑷銇欍倠銆 + + (a) 绉併伅銉°偆銉炽儵銈ゃ兂銈兗銉嶃儷銇搞伄绲卞悎銇悜銇戙併仢銇Ε褰撴у強銇炽屽嵆蹇滄 + (瑷虫敞)銆嶃倰妞滆銇椼佹妧琛撶殑鍋撮潰銇嬨倝銉戙儍銉併倰銉儞銉ャ兗娓堛伩銇с亗銈嬨 + + 瑷虫敞: + 銆屽嵆蹇滄с嶃伄鍘熸枃銇 "readiness"銆 + 銉戙儍銉併亴鍗佸垎銇搧璩倰鎸併仯銇︺亰銈娿併儭銈ゃ兂銉┿偆銉炽偒銉笺儘銉伕銇当鍚堛倰鍗冲骇銇 + 琛屻亞銇撱仺銇屻仹銇嶃倠鐘舵厠銇с亗銈嬨亱銇┿亞銇嬨倰 "readiness" 銇ㄣ亜銇嗗崢瑾炪仹琛ㄧ従 + 銇椼仸銇勩倠銆 + + (b) 銉戙儍銉併伀闁€仚銈嬨亗銈夈倖銈嬪晱椤屻佹嚫蹇点併亗銈嬨亜銇佺枒鍟忋伅鎶曠ǹ鑰呫伕浼濋仈娓堛伩 + 銇с亗銈嬨傜銇仢銈屻倝銇偝銉°兂銉堛伀瀵俱仚銈嬫姇绋胯呫伄杩旂瓟銇簚瓒炽仐銇︺亜銈嬨 + + (c) 鎶曠ǹ銇即銇勬敼鑹仌銈屻倠銈炽兗銉夈亴銇傘倠涓鏂广仹銆佺従鏅傜偣銇с佺銇(1)銇濄倢銇 + 銈兗銉嶃儷銇仺銇ｃ仸渚″ゃ伄銇傘倠澶夋洿銇с亗銈嬨亾銇ㄣ併仢銇椼仸銆(2)绲卞悎銇殯銇椼仸 + 璀拌珫銇仾銈婂緱銈嬨倛銇嗐仾鍟忛銇仾銇勩倐銇仺纰轰俊銇椼仸銇勩倠銆 + + (d) 绉併伅銉戙儍銉併倰銉儞銉ャ兗銇楅仼鍒囥仹銇傘倠銇ㄧ⒑淇°仐銇︺亜銈嬩竴鏂广仹銆併亗銈夈倖銈 + 鐘舵硜銇亰銇勩仸銇濄伄瀹ｈ█銇椼仧鐩殑銈勬鑳姐亴姝ｃ仐銇忓疅鐝俱仚銈嬨亾銇ㄣ伀闁€仐銇︺ + 銇勩亱銇倠淇濊銈傘仐銇亜(鐗广伀銇┿亾銇嬨仹鏄庣ず銇椼仾銇勯檺銈)銆 + +Reviewd-by 銈裤偘銇仢銇儜銉冦儊銇屻偒銉笺儘銉伀瀵俱仐銇﹂仼鍒囥仾淇銇с亗銇ｃ仸銆佹繁鍒汇仾鎶琛撶殑 +鍟忛銈掓畫銇椼仸銇勩仾銇勩仺銇勩亞鎰忚銇瑷銇с仚銆傝垐鍛炽伄銇傘倠銉儞銉ャ兗銈€伅瑾般仹銈(銉儞銉ャ兗 +浣滄キ銈掔祩銇堛仧銈)銉戙儍銉併伀瀵俱仐銇 Reviewed-by 銈裤偘銈掓彁绀恒仹銇嶃伨銇欍傘亾銇偪銈般伅 +銉儞銉ャ兗銈€伄瀵勪笌銈掋偗銉偢銉冦儓銇欍倠鍍嶃亶銆併儸銉撱儱銉笺伄閫叉崡銇害鍚堛亜銈掋儭銉炽儐銉娿伀 +鐭ャ倝銇涖倠鍍嶃亶銈掓寔銇°伨銇欍傘仢銇儜銉冦儊銇牁鍩熴伀瑭炽仐銇忋併仢銇椼仸銆併仐銇ｃ亱銈娿仺銇椼仧 +銉儞銉ャ兗銈掑疅鏂姐仐銇熴儸銉撱儱銉笺偄銇倛銇ｃ仸鎻愪緵銇曘倢銈嬫檪銆丷eviewed-by: 銈裤偘銇屻亗銇仧銇 +銉戙儍銉併倰銈兗銉嶃儷銇優銉笺偢銇欍倠鍙兘鎬с倰楂樸倎銈嬨仹銇椼倗銇嗐 + +15) 妯欐簴鐨勩仾銉戙儍銉併伄銉曘偐銉笺優銉冦儓 妯欐簴鐨勩仾銉戙儍銉併伄銈点儢銈搞偋銈儓銇互涓嬨伄銇ㄣ亰銈娿仹銇欍 @@ -396,18 +501,37 @@ Acked-by: 銇屽繀銇氥仐銈傘儜銉冦儊鍏ㄤ綋銇壙瑾嶃倰绀恒仐銇︺亜銈嬨倧銇戙仹銇 闆诲瓙銉°兗銉伄銈点儢銈搞偋銈儓鍐呫伄銈点儢銈枫偣銉嗐儬琛ㄨ銇併儜銉冦儊銇岄仼鐢ㄣ仌銈屻倠 鍒嗛噹銇俱仧銇偟銉栥偡銈广儐銉犮倰璀樺垾銇с亶銈嬨倛銇嗐伀銇欍伖銇嶃仹銇欍 -闆诲瓙銉°兗銉伄銈点儢銈搞偋銈儓銇屾瑕併伄瑷銇勫洖銇椼嶃伅銇濄伄銉戙儍銉併伄姒傝銈掓纰 -銇〃鐝俱仐銇亼銈屻伆銇倞銇俱仜銈撱傘屾瑕併伄瑷銇勫洖銇椼嶃倰銉曘偂銈ゃ儷鍚嶃伀銇椼仸銇亜 -銇戙伨銇涖倱銆備竴閫ｃ伄銉戙儍銉佷腑銇с仢銈屻仦銈屻伄銉戙儍銉併伅鍚屻仒銆屾瑕併伄瑷銇勫洖銇椼嶃倰 -浣裤仯銇︺伅銇勩亼銇俱仜銈(銆屼竴閫ｃ伄銉戙儍銉併嶃仺銇爢搴忎粯銇戙倝銈屻仧闁㈤ｃ伄銇傘倠瑜囨暟銇 +闆诲瓙銉°兗銉伄銈点儢銈搞偋銈儓銇宻ummary phrase銆嶃伅銇濄伄銉戙儍銉併伄姒傝銈掓纰 +銇〃鐝俱仐銇亼銈屻伆銇倞銇俱仜銈撱傘宻ummary phrase銆嶃倰銉曘偂銈ゃ儷鍚嶃伀銇椼仸銇亜 +銇戙伨銇涖倱銆傘儜銉冦儊銈枫儶銉笺偤涓仹銇濄倢銇炪倢銇儜銉冦儊銇悓銇樸宻ummary phrase銆嶃倰 +浣裤仯銇︺伅銇勩亼銇俱仜銈(銆屻儜銉冦儊銈枫儶銉笺偤銆嶃仺銇爢搴忎粯銇戙倝銈屻仧闁㈤ｃ伄銇傘倠瑜囨暟銇 銉戙儍銉佺兢銇с仚)銆 -銇傘仾銇熴伄闆诲瓙銉°兗銉伄銆屾瑕併伄瑷銇勫洖銇椼嶃亴銇濄伄銉戙儍銉併伀銇ㄣ仯銇︿笘鐣屻仹鍞 -涓銇瓨鍒ュ瓙銇仾銈嬨倛銇嗐伀蹇冦亴銇戙仸銇忋仩銇曘亜銆傘屾瑕併伄瑷銇勫洖銇椼嶃伅 git 銇 -銉併偋銉炽偢銉偘銇腑銇搞仛銇ｃ仺浼濇挱銇椼仸銇勩亶銇俱仚銆傘屾瑕併伄瑷銇勫洖銇椼嶃伅銆侀枊 -鐧鸿呫亴寰屻仹銉戙儍銉併倰鍙傜収銇欍倠銇熴倎銇璜栥伄涓仹鍒╃敤銇欍倠銇嬨倐銇椼倢銇俱仜銈撱 -浜恒呫伅銇濄伄銉戙儍銉併伀闁㈤ｃ仐銇熻璜栥倰瑾個銇熴倎銇屾瑕併伄瑷銇勫洖銇椼嶃倰浣裤仯銇 -google 銇ф绱€仐銇熴亴銈嬨仹銇椼倗銇嗐 +銇傘仾銇熴伄闆诲瓙銉°兗銉伄銆宻ummary phrase銆嶃亴銇濄伄銉戙儍銉併伀銇ㄣ仯銇︿笘鐣屻仹鍞竴銇瓨鍒ュ瓙銇 +銇倠銈堛亞銇績銇屻亼銇︺亸銇犮仌銇勩傘宻ummary phrase銆嶃伅 git 銇儊銈с兂銈搞儹銈般伄涓伕 +銇氥仯銇ㄤ紳鎾仐銇︺亜銇嶃伨銇欍傘宻ummary phrase銆嶃伅銆侀枊鐧鸿呫亴寰屻仹銉戙儍銉併倰鍙傜収銇欍倠 +銇熴倎銇璜栥伄涓仹鍒╃敤銇欍倠銇嬨倐銇椼倢銇俱仜銈撱 +浜恒呫伅銇濄伄銉戙儍銉併伀闁㈤ｃ仐銇熻璜栥倰瑾個銇熴倎銇宻ummary phrase銆嶃倰浣裤仯銇 google 銇 +妞滅储銇椼仧銇屻倠銇с仐銈囥亞銆傘仢銈屻伅銇俱仧2銆3銉舵湀銇傘仺銇с佷汉銆呫亴銆実itk銆嶃倓 +銆実it log --oneline銆嶃伄銈堛亞銇儎銉笺儷銈掍娇鐢ㄣ仐銇︿綍鍗冦倐銇儜銉冦儊銇洰銈掗氥仚鏅傘 +鍞竴鐩伀銇ㄣ伨銈嬫儏鍫便仺銇倠銇с仐銈囥亞銆 + +銇撱倢銈夈伄鐞嗙敱銇仧銈併併宻ummary phrase銆嶃伅銇仠銉戙儍銉併亴蹇呰銇с亗銈嬨亱銆併儜銉冦儊銇屼綍銈 +澶夋洿銇欍倠銇嬨伄2銇ゃ伄鎯呭牨銈掋仜銇勩仠銇70銆75鏂囧瓧銇ц〃鐝俱仐銇︺亜銇亼銈屻伆銇倞銇俱仜銈撱 +銆宻ummary phrase銆嶃伅绨℃綌銇с亗銈婅鏄庣殑銇с亗銈嬭〃鐝俱倰鐩寚銇椼仱銇ゃ併亞銇俱亸 +銇俱仺銈併倝銈屻仸銇勩倠姒傝銇ㄣ仾銈嬨伖銇嶃仹銇欍 + +銆宻ummary phrase銆嶃伅銆孲ubject: [PATCH tag] <summary phrase>銆嶃伄銈堛亞銇 +澶ф嫭寮с仹闁夈仒銈夈倢銇熴偪銈般倰鎺ラ牠杈炪仺銇椼仸浠樺姞銇椼仸銈傘亱銇俱亜銇俱仜銈撱傘亾銇偪銈般伅 +銆宻ummary phrase銆嶃伄涓閮ㄣ仺銇冦亪銇俱仜銈撱亴銆併儜銉冦儊銈掋仼銇倛銇嗐伀鍙栥倞鎵便亞銇广亶銇嬨倰 +琛ㄧ従銇椼伨銇欍 +涓鑸殑銇伅銆寁1, v2, v3銆嶃伄銈堛亞銇儛銉笺偢銉с兂鎯呭牨銈掕〃銇欍偪銈(閬庡幓銇儜銉冦儊銇銇欍倠 +銈炽儭銉炽儓銈掑弽鏄犮仚銈嬨仧銈併伀瑜囨暟銇儛銉笺偢銉с兂銇儜銉冦儊銇屾姇绋裤仌銈屻仸銇勩倠銇仹銇傘倢銇)銆 +銆孯FC銆嶃伄銈堛亞銇偝銉°兂銉堛倰瑕佹眰銇欍倠銈裤偘銇屾寵銇掋倝銈屻伨銇欍傘儜銉冦儊銈枫儶銉笺偤銇ㄣ仐銇4銇ゃ伄 +銉戙儍銉併亴銇傘倢銇般佸嬨呫伄銉戙儍銉併伀銆1/4, 2/4, 3/4, 4/4銆嶃伄銈堛亞銇暘鍙枫倰浠樸亼銇︺倐 +銇嬨伨銇勩伨銇涖倱銆傘亾銈屻伅闁嬬櫤鑰呫亴銉戙儍銉併倰閬╃敤銇欍倠闋嗙暘銈掔⒑瀹熴伀鎶婃彙銇欍倠銇熴倎銇с仚銆 +銇濄仐銇︺侀枊鐧鸿呫亴銉戙儍銉併偡銉兗銈恒伄涓伄銇欍伖銇︺伄銉戙儍銉併倰銈傘倝銇曘仛銉儞銉ャ兗鎴栥亜銇 +閬╃敤銇欍倠銇倰淇濊銇欍倠銇熴倎銇с仚銆 銈点儢銈搞偋銈儓銇緥銈掍簩銇 @@ -426,7 +550,12 @@ google 銇ф绱€仐銇熴亴銈嬨仹銇椼倗銇嗐 瑾槑鏈綋銇劇鏈熼檺銇偨銉笺偣銇儊銈с兂銈搞儹銈般伀銈炽儫銉冦儓銇曘倢銇俱仚銆傘仾銇仹銆佽鏄 鏈綋銇仢銇儜銉冦儊銇嚦銇ｃ仧璀拌珫銇┏绱般倰蹇樸倢銇︺亜銈嬨亗銈嬬▼搴︺伄鎶閲忋倰鎸併仯銇︺亜銈嬩汉 -銇屻仢銇┏绱般倰鎬濄亜鍑恒仚銇撱仺銇屻仹銇嶃倠銈傘伄銇с仾銇戙倢銇般仾銈娿伨銇涖倱銆 +銇屻仢銇┏绱般倰鎬濄亜鍑恒仚銇撱仺銇屻仹銇嶃倠銈傘伄銇с仾銇戙倢銇般仾銈娿伨銇涖倱銆傘儜銉冦儊銇屽鍑︺仚銈 +闅滃銇棁鐘(銈兗銉嶃儷銉偘銉°儍銈汇兗銈搞倓 oops 銉°儍銈汇兗銈哥瓑)銈掕杓夈仚銈嬨亾銇ㄣ伅鍟忛銇 +瀵惧嚘鍙兘銇儜銉冦儊銈掓眰銈併仸銈炽儫銉冦儓銉偘銈掓绱€仚銈嬩汉銆呫伀銇ㄣ仯銇︾壒銇湁鐢ㄣ仹銇欍 +銉戙儍銉併亴銈炽兂銉戙偆銉晱椤屻倰瑙ｆ焙銇欍倠銇仹銇傘倢銇般併仢銇儜銉冦儊銈掓帰銇椼仸銇勩倠浜恒亴瑕嬨仱銇戙倠 +銇撱仺銇屻仹銇嶃倠鎯呭牨銇犮亼銇у崄鍒嗐仹銇傘倞銆併偝銉炽儜銈ゃ儷鏅傘伄鍏ㄣ仸銇偍銉┿兗銈掑惈銈併倠蹇呰銇 +銇傘倞銇俱仜銈撱傘宻ummary phrase銆嶃仺鍚屾銇佺啊娼斻仹銇傘倞瑾槑鐨勩仹銇傘倠銇撱仺銇岄噸瑕併仹銇欍 銆 --- 銆嶃優銉笺偒銉艰銇儜銉冦儊鍑︾悊銉勩兗銉伀瀵俱仐銇︺併儊銈с兂銈搞儹銈般儭銉冦偦銉笺偢銇祩绔 閮ㄥ垎銈掕獚璀樸仌銇涖倠銇ㄣ亜銇嗛噸瑕併仾褰圭洰銈掓灉銇熴仐銇俱仚銆 @@ -436,14 +565,46 @@ google 銇ф绱€仐銇熴亴銈嬨仹銇椼倗銇嗐 杩藉姞銇曘倢浣曡娑堛仌銈屻仧銇嬨倰绀恒仚銈傘伄銇с仚銆俤iffstat 銈炽優銉炽儔銇壒銇ぇ銇嶃仾銉戙儍銉併伀 銇娿亜銇﹀焦绔嬨仭銇俱仚銆傘仢銇檪鐐广仹銇犮亼鍙堛伅銉°兂銉嗐儕銇仺銇ｃ仸銇伩闁總銇亗銈嬨偝銉°兂銉 銇劇鏈熼檺銇繚瀛樸仌銈屻倠銉併偋銉炽偢銉偘銇仺銇ｃ仸閬╁垏銇с伅銇傘倞銇俱仜銈撱傘仢銇仧銈併併亾銇 -銈堛亞銇偝銉°兂銉堛倐銉炪兗銈兗琛屻伄寰屻伀鏇搞亱銈屻倠銇广亶銇с仚銆傘儠銈°偆銉悕銇偒銉笺儘銉偨銉 -銈广儎銉兗銇儓銉冦儣銉囥偅銉偗銉堛儶銇嬨倝銇〃瑷樸仹銉偣銉堛仌銈屻倠銇熴倎銆佹í鏂瑰悜銇偣銉氥兗銈 -銈掋仺銈婇亷銇庛仾銇勩倛銇嗐伀銆乨iffstat 銈炽優銉炽儔銇偑銉椼偡銉с兂銆 -p 1 -w 70 銆嶃倰鎸囧畾銇 -銇︺亸銇犮仌銇(銈ゃ兂銉囥兂銉堛倰鍚倎銇︺仭銈囥亞銇80鍒椼伀鍚堛亞銇с仐銈囥亞)銆 +銈堛亞銇偝銉°兂銉堛倐銉炪兗銈兗琛屻伄寰屻伀鏇搞亱銈屻倠銇广亶銇с仚銆 +銇撱伄銈堛亞銇偝銉°兂銉堛伄鑹亜渚嬨仺銇椼仸銆乿1 銇 v2 銇儛銉笺偢銉с兂闁撱仹浣曘亴澶夋洿銇曘倢銇熴亱銈 +琛ㄣ仚銆屻儜銉冦儊銇鏇村饱姝淬嶃亴鎸欍亽銈夈倢銇俱仚銆 + +銆 --- 銆嶃優銉笺偒銉艰銇緦銇 diffstat 銈炽優銉炽儔銇祼鏋溿倰鍚倎銈嬨伄銇с亗銈屻伆銆併儠銈°偆銉 +鍚嶃伅銈兗銉嶃儷銈姐兗銈广儎銉兗銇儓銉冦儣銉囥偅銉偗銉堛儶銇嬨倝銇〃瑷樸仹鍒楄銇曘倢銈嬨仧銈併佹í鏂瑰悜 +銇偣銉氥兗銈广倰銇ㄣ倞閬庛亷銇亜銈堛亞銇乨iffstat 銈炽優銉炽儔銇偑銉椼偡銉с兂銆 -p 1 -w 70 銆 +銈掓寚瀹氥仐銇︺亸銇犮仌銇(銈ゃ兂銉囥兂銉堛倰鍚倎銇︺仭銈囥亞銇80鍒椼伀鍚堛亞銇с仐銈囥亞)銆 閬╁垏銇儜銉冦儊銇儠銈┿兗銉炪儍銉堛伄瑭崇窗銇仱銇勩仸銇偦銈偡銉с兂3銇弬鑰冩枃鐚倰鍙傜収銇椼仸 銇忋仩銇曘亜銆 +16) 銆実it pull銆嶈姹傘伄閫併倞鏂(Linus 銇浕瀛愩儭銉笺儷銇嬨倝) + +闁撻仌銇ｃ仧銉栥儵銉炽儊銇嬨倝寮曘仯寮点倠銇倰闃层亹銇熴倎銇乬it 銉儩銈搞儓銉伄銈€儔銉偣銇 +銉栥儵銉炽儊鍚嶃倰鍚屻仒琛屻伀1琛屻仹瑷樿級銇椼仸銇忋仩銇曘亜銆傘仢銇嗐仚銈嬨亾銇ㄣ仹銆3鍥炪伄閫ｇ稓銈儶銉冦偗 +銇у叏銇﹂伕鎶炪仹銇嶃伨銇欍 + +姝ｃ仐銇勫舰寮忋伅涓嬭銇氥倞銇с仚銆 + + "Please pull from + + git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus + + to get these changes:" + +銇濄伄绲愭灉銆併偄銉夈儸銈广倰鑷垎鑷韩銇с偪銈ゃ償銉炽偘銇椼仸闁撻仌銇堛倠銇撱仺銇仾銇忋仾銈娿伨銇(瀹熼殯銇 +浣曞害銇嬮枔閬曘仯銇熴儢銉┿兂銉併亱銈夊紩銇ｅ嫉銇ｃ仸銇嶃仸銇椼伨銇勩併仢銇檪銇 diffstat 銇祼鏋溿倰 +妞滆銇椼仸闁撻仌銇ｃ仸銇勩倠銇撱仺銇皸銇ャ亜銇熴亾銇ㄣ亴銇傘倞銇俱仚銆傘仼銇撱亱銈変綍銈掑紩銇ｅ嫉銈嬨伖銇嶃亱銈 +銆屾帰銇椼仧銈娿嶃佹銇椼亜銉栥儵銉炽儊鍚嶃亱銇┿亞銇嬨倰閲嶃伃銇︺儊銈с儍銈仐銇熴倞銇欍倠蹇呰銇 +銇亸銇倢銇般倛銈婂揩閬┿伀銇倠銇с仐銈囥亞)銆 + +diffstat 銇祼鏋溿倰鐢熸垚銇欍倠銇熴倎銇 git diff -M --stat --summary 銆嶃倰浣裤仯銇 +銇忋仩銇曘亜銆-M 銈儣銈枫儳銉炽伅銉曘偂銈ゃ儷鍚嶃伄澶夋洿銈掓鐭ャ仹銇嶃--summary 銈儣銈枫儳銉炽伅 +鏂拌銉曘偂銈ゃ儷銆佸墛闄ゃ仌銈屻仧銉曘偂銈ゃ儷銆佸悕鍓嶃亴澶夋洿銇曘倢銇熴儠銈°偆銉伄姒傝銈掔敓鎴愩仐銇俱仚銆 + +-M 銈儣銈枫儳銉(銉曘偂銈ゃ儷鍚嶃伄澶夋洿妞滅煡)銈掓寚瀹氥仚銈嬨仺銆乨iffstat 銇祼鏋溿伅銇嬨仾銈 +鐣般仾銇ｃ仸銇嶃伨銇欍俫it 銇ぇ瑕忔ā銇鏇(杩藉姞銇ㄥ墛闄ゃ伄銉氥偄)銈掋儠銈°偆銉悕銇鏇淬仺 +鍒ゆ柇銇欍倠銇熴倎銇с仚銆 + ------------------------------------ 銈汇偗銈枫儳銉2 - 銉掋兂銉堛仺TIPS銇ㄥ皬鎶 ------------------------------------ @@ -459,7 +620,7 @@ google 銇ф绱€仐銇熴亴銈嬨仹銇椼倗銇嗐 銈傞歌劚銇椼仸銇勩倠銇ㄣ併儸銉撱儱銉笺倓銈炽儭銉炽儓銇仐銇彈銇戝彇銇ｃ仸銈傘倝銇堛仾銇勩亱銈傘仐 銈屻伨銇涖倱銆 -鍞竴銇壒绛嗐仚銇广亶渚嬪銇併偝銉笺儔銈掋亗銈嬨儠銈°偆銉亱銈夊垾銇儠銈°偆銉伀绉诲嫊 +鐗圭瓎銇欍伖銇嶄緥澶栥伅銆併偝銉笺儔銈掋亗銈嬨儠銈°偆銉亱銈夊垾銇儠銈°偆銉伀绉诲嫊 銇欍倠銇ㄣ亶銇с仚銆傘亾銇牬鍚堛併偝銉笺儔銈掔Щ鍕曘仚銈嬨儜銉冦儊銇с伅銆佺Щ鍕曘仌銈屻倠銈炽兗銉 銇枹銇椼仸绉诲嫊浠ュ銇鏇淬倰涓鍒囧姞銇堛倠銇广亶銇с伅銇傘倞銇俱仜銈撱傘亾銈屻伀銈堛倞銆 銈炽兗銉夈伄绉诲嫊銇ㄣ亗銇仧銇岃銇ｃ仧銈炽兗銉夈伄淇銈掓槑纰恒伀鍖哄垾銇с亶銈嬨倛銇嗐伀銇 @@ -553,4 +714,11 @@ Kernel Documentation/CodingStyle: Linus Torvalds's mail on the canonical patch format: <http://lkml.org/lkml/2005/4/7/183> + +Andi Kleen, "On submitting kernel patches" + Some strategies to get difficult or controversial changes in. + http://halobates.de/on-submitting-patches.pdf + -- + + diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index 47435e56c5da..f47cdefb4d1e 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -441,7 +441,7 @@ more details, with real examples. specified if first option are not supported. Example: - #arch/i386/kernel/Makefile + #arch/x86/kernel/Makefile vsyscall-flags += $(call cc-ldoption, -Wl$(comma)--hash-style=sysv) In the above example, vsyscall-flags will be assigned the option @@ -460,7 +460,7 @@ more details, with real examples. supported to use an optional second option. Example: - #arch/i386/Makefile + #arch/x86/Makefile cflags-y += $(call cc-option,-march=pentium-mmx,-march=i586) In the above example, cflags-y will be assigned the option @@ -522,7 +522,7 @@ more details, with real examples. even though the option was accepted by gcc. Example: - #arch/i386/Makefile + #arch/x86/Makefile cflags-y += $(shell \ if [ $(call cc-version) -ge 0300 ] ; then \ echo "-mregparm=3"; fi ;) @@ -802,7 +802,7 @@ but in the architecture makefiles where the kbuild infrastructure is not sufficient this sometimes needs to be explicit. Example: - #arch/i386/boot/Makefile + #arch/x86/boot/Makefile subdir- := compressed/ The above assignment instructs kbuild to descend down in the @@ -812,12 +812,12 @@ To support the clean infrastructure in the Makefiles that builds the final bootimage there is an optional target named archclean: Example: - #arch/i386/Makefile + #arch/x86/Makefile archclean: - $(Q)$(MAKE) $(clean)=arch/i386/boot + $(Q)$(MAKE) $(clean)=arch/x86/boot -When "make clean" is executed, make will descend down in arch/i386/boot, -and clean as usual. The Makefile located in arch/i386/boot/ may use +When "make clean" is executed, make will descend down in arch/x86/boot, +and clean as usual. The Makefile located in arch/x86/boot/ may use the subdir- trick to descend further down. Note 1: arch/$(ARCH)/Makefile cannot use "subdir-", because that file is @@ -882,7 +882,7 @@ When kbuild executes, the following steps are followed (roughly): LDFLAGS_vmlinux uses the LDFLAGS_$@ support. Example: - #arch/i386/Makefile + #arch/x86/Makefile LDFLAGS_vmlinux := -e stext OBJCOPYFLAGS objcopy flags @@ -920,14 +920,14 @@ When kbuild executes, the following steps are followed (roughly): Often, the KBUILD_CFLAGS variable depends on the configuration. Example: - #arch/i386/Makefile + #arch/x86/Makefile cflags-$(CONFIG_M386) += -march=i386 KBUILD_CFLAGS += $(cflags-y) Many arch Makefiles dynamically run the target C compiler to probe supported options: - #arch/i386/Makefile + #arch/x86/Makefile ... cflags-$(CONFIG_MPENTIUMII) += $(call cc-option,\ @@ -1038,8 +1038,8 @@ When kbuild executes, the following steps are followed (roughly): into the arch/$(ARCH)/boot/Makefile. Example: - #arch/i386/Makefile - boot := arch/i386/boot + #arch/x86/Makefile + boot := arch/x86/boot bzImage: vmlinux $(Q)$(MAKE) $(build)=$(boot) $(boot)/$@ @@ -1051,7 +1051,7 @@ When kbuild executes, the following steps are followed (roughly): To support this, $(archhelp) must be defined. Example: - #arch/i386/Makefile + #arch/x86/Makefile define archhelp echo '* bzImage - Image (arch/$(ARCH)/boot/bzImage)' endif @@ -1065,7 +1065,7 @@ When kbuild executes, the following steps are followed (roughly): from vmlinux. Example: - #arch/i386/Makefile + #arch/x86/Makefile all: bzImage When "make" is executed without arguments, bzImage will be built. @@ -1083,7 +1083,7 @@ When kbuild executes, the following steps are followed (roughly): 2) kbuild knows what files to delete during "make clean" Example: - #arch/i386/kernel/Makefile + #arch/x86/kernel/Makefile extra-y := head.o init_task.o In this example, extra-y is used to list object files that @@ -1133,7 +1133,7 @@ When kbuild executes, the following steps are followed (roughly): Compress target. Use maximum compression to compress target. Example: - #arch/i386/boot/Makefile + #arch/x86/boot/Makefile LDFLAGS_bootsect := -Ttext 0x0 -s --oformat binary LDFLAGS_setup := -Ttext 0x0 -s --oformat binary -e begtext @@ -1193,7 +1193,7 @@ When kbuild executes, the following steps are followed (roughly): When updating the $(obj)/bzImage target, the line - BUILD arch/i386/boot/bzImage + BUILD arch/x86/boot/bzImage will be displayed with "make KBUILD_VERBOSE=0". @@ -1207,7 +1207,7 @@ When kbuild executes, the following steps are followed (roughly): kbuild knows .lds files and includes a rule *lds.S -> *lds. Example: - #arch/i386/kernel/Makefile + #arch/x86/kernel/Makefile always := vmlinux.lds #Makefile diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d9a203b058f1..4ca93898fbd3 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1159,10 +1159,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. for all guests. Default is 1 (enabled) if in 64bit or 32bit-PAE mode - kvm-intel.bypass_guest_pf= - [KVM,Intel] Disables bypassing of guest page faults - on Intel chips. Default is 1 (enabled) - kvm-intel.ept= [KVM,Intel] Disable extended page tables (virtualized MMU) support on capable Intel chips. Default is 1 (enabled) @@ -1737,6 +1733,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. no-kvmapf [X86,KVM] Disable paravirtualized asynchronous page fault handling. + no-steal-acc [X86,KVM] Disable paravirtualized steal time accounting. + steal time is computed, but won't influence scheduler + behaviour + nolapic [X86-32,APIC] Do not enable or use the local APIC. nolapic_timer [X86-32,APIC] Do not use the local APIC timer. @@ -1846,7 +1846,9 @@ bytes respectively. Such letter suffixes can also be entirely omitted. See Documentation/sound/oss/oss-parameters.txt panic= [KNL] Kernel behaviour on panic: delay <timeout> - seconds before rebooting + timeout > 0: seconds before rebooting + timeout = 0: wait forever + timeout < 0: reboot immediately Format: <timeout> parkbd.port= [HW] Parallel port number the keyboard adapter is @@ -2015,6 +2017,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. the default. off: Turn ECRC off on: Turn ECRC on. + realloc reallocate PCI resources if allocations done by BIOS + are erroneous. pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power Management. @@ -2524,6 +2528,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. <port#>,<js1>,<js2>,<js3>,<js4>,<js5>,<js6>,<js7> See also Documentation/input/joystick-parport.txt + udbg-immortal [PPC] When debugging early kernel crashes that + happen after console_init() and before a proper + console driver takes over, this boot options might + help "seeing" what's going on. + uhash_entries= [KNL,NET] Set number of hash buckets for UDP/UDP-Lite connections @@ -2538,6 +2547,11 @@ bytes respectively. Such letter suffixes can also be entirely omitted. unknown_nmi_panic [X86] Cause panic on unknown NMI. + usbcore.authorized_default= + [USB] Default USB device authorization: + (default -1 = authorized except for wireless USB, + 0 = not authorized, 1 = authorized) + usbcore.autosuspend= [USB] The autosuspend time delay (in seconds) used for newly-detected USB devices (default 2). This @@ -2598,6 +2612,8 @@ bytes respectively. Such letter suffixes can also be entirely omitted. unlock ejectable media); m = MAX_SECTORS_64 (don't transfer more than 64 sectors = 32 KB at a time); + n = INITIAL_READ10 (force a retry of the + initial READ(10) command); o = CAPACITY_OK (accept the capacity reported by the device); r = IGNORE_RESIDUE (the device reports diff --git a/Documentation/kmemleak.txt b/Documentation/kmemleak.txt index 090e6ee04536..51063e681ca4 100644 --- a/Documentation/kmemleak.txt +++ b/Documentation/kmemleak.txt @@ -11,7 +11,9 @@ with the difference that the orphan objects are not freed but only reported via /sys/kernel/debug/kmemleak. A similar method is used by the Valgrind tool (memcheck --leak-check) to detect the memory leaks in user-space applications. -Kmemleak is supported on x86, arm, powerpc, sparc, sh, microblaze and tile. + +Please check DEBUG_KMEMLEAK dependencies in lib/Kconfig.debug for supported +architectures. Usage ----- diff --git a/Documentation/laptops/thinkpad-acpi.txt b/Documentation/laptops/thinkpad-acpi.txt index 1565eefd6fd5..61815483efa3 100644 --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -534,6 +534,8 @@ Events that are never propagated by the driver: 0x2404 System is waking up from hibernation to undock 0x2405 System is waking up from hibernation to eject bay 0x5010 Brightness level changed/control event +0x6000 KEYBOARD: Numlock key pressed +0x6005 KEYBOARD: Fn key pressed (TO BE VERIFIED) Events that are propagated by the driver to userspace: @@ -545,6 +547,8 @@ Events that are propagated by the driver to userspace: 0x3006 Bay hotplug request (hint to power up SATA link when the optical drive tray is ejected) 0x4003 Undocked (see 0x2x04), can sleep again +0x4010 Docked into hotplug port replicator (non-ACPI dock) +0x4011 Undocked from hotplug port replicator (non-ACPI dock) 0x500B Tablet pen inserted into its storage bay 0x500C Tablet pen removed from its storage bay 0x6011 ALARM: battery is too hot @@ -552,6 +556,7 @@ Events that are propagated by the driver to userspace: 0x6021 ALARM: a sensor is too hot 0x6022 ALARM: a sensor is extremely hot 0x6030 System thermal table changed +0x6040 Nvidia Optimus/AC adapter related (TO BE VERIFIED) Battery nearly empty alarms are a last resort attempt to get the operating system to hibernate or shutdown cleanly (0x2313), or shutdown diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt index 4b12abcb2ad3..abf481f780ec 100644 --- a/Documentation/magic-number.txt +++ b/Documentation/magic-number.txt @@ -66,7 +66,7 @@ MKISS_DRIVER_MAGIC 0x04bf mkiss_channel drivers/net/mkiss.h RISCOM8_MAGIC 0x0907 riscom_port drivers/char/riscom8.h SPECIALIX_MAGIC 0x0907 specialix_port drivers/char/specialix_io8.h HDLC_MAGIC 0x239e n_hdlc drivers/char/n_hdlc.c -APM_BIOS_MAGIC 0x4101 apm_user arch/i386/kernel/apm.c +APM_BIOS_MAGIC 0x4101 apm_user arch/x86/kernel/apm_32.c CYCLADES_MAGIC 0x4359 cyclades_port include/linux/cyclades.h DB_MAGIC 0x4442 fc_info drivers/net/iph5526_novram.c DL_MAGIC 0x444d fc_info drivers/net/iph5526_novram.c diff --git a/Documentation/mca.txt b/Documentation/mca.txt index 510375d4209a..dfd130c2207d 100644 --- a/Documentation/mca.txt +++ b/Documentation/mca.txt @@ -11,7 +11,7 @@ Adapter Detection The ideal MCA adapter detection is done through the use of the Programmable Option Select registers. Generic functions for doing -this have been added in include/linux/mca.h and arch/i386/kernel/mca.c. +this have been added in include/linux/mca.h and arch/x86/kernel/mca_32.c. Everything needed to detect adapters and read (and write) configuration information is there. A number of MCA-specific drivers already use this. The typical probe code looks like the following: @@ -81,7 +81,7 @@ more people use shared IRQs on PCI machines. In general, an interrupt must be acknowledged not only at the ICU (which is done automagically by the kernel), but at the device level. In particular, IRQ 0 must be reset after a timer interrupt (now done in -arch/i386/kernel/time.c) or the first timer interrupt hangs the system. +arch/x86/kernel/time.c) or the first timer interrupt hangs the system. There were also problems with the 1.3.x floppy drivers, but that seems to have been fixed. diff --git a/Documentation/md.txt b/Documentation/md.txt index 2366b1c8cf19..f0eee83ff78a 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -555,7 +555,7 @@ also have sync_min sync_max The two values, given as numbers of sectors, indicate a range - withing the array where 'check'/'repair' will operate. Must be + within the array where 'check'/'repair' will operate. Must be a multiple of chunk_size. When it reaches "sync_max" it will pause, rather than complete. You can use 'select' or 'poll' on "sync_completed" to wait for diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX index 93dd7a714075..a9ba6720ffdf 100644 --- a/Documentation/mmc/00-INDEX +++ b/Documentation/mmc/00-INDEX @@ -4,3 +4,5 @@ mmc-dev-attrs.txt - info on SD and MMC device attributes mmc-dev-parts.txt - info on SD and MMC device partitions +mmc-async-req.txt + - info on mmc asynchronous requests diff --git a/Documentation/mmc/mmc-async-req.txt b/Documentation/mmc/mmc-async-req.txt new file mode 100644 index 000000000000..ae1907b10e4a --- /dev/null +++ b/Documentation/mmc/mmc-async-req.txt @@ -0,0 +1,87 @@ +Rationale +========= + +How significant is the cache maintenance overhead? +It depends. Fast eMMC and multiple cache levels with speculative cache +pre-fetch makes the cache overhead relatively significant. If the DMA +preparations for the next request are done in parallel with the current +transfer, the DMA preparation overhead would not affect the MMC performance. +The intention of non-blocking (asynchronous) MMC requests is to minimize the +time between when an MMC request ends and another MMC request begins. +Using mmc_wait_for_req(), the MMC controller is idle while dma_map_sg and +dma_unmap_sg are processing. Using non-blocking MMC requests makes it +possible to prepare the caches for next job in parallel with an active +MMC request. + +MMC block driver +================ + +The mmc_blk_issue_rw_rq() in the MMC block driver is made non-blocking. +The increase in throughput is proportional to the time it takes to +prepare (major part of preparations are dma_map_sg() and dma_unmap_sg()) +a request and how fast the memory is. The faster the MMC/SD is the +more significant the prepare request time becomes. Roughly the expected +performance gain is 5% for large writes and 10% on large reads on a L2 cache +platform. In power save mode, when clocks run on a lower frequency, the DMA +preparation may cost even more. As long as these slower preparations are run +in parallel with the transfer performance won't be affected. + +Details on measurements from IOZone and mmc_test +================================================ + +https://wiki.linaro.org/WorkingGroups/Kernel/Specs/StoragePerfMMC-async-req + +MMC core API extension +====================== + +There is one new public function mmc_start_req(). +It starts a new MMC command request for a host. The function isn't +truly non-blocking. If there is an ongoing async request it waits +for completion of that request and starts the new one and returns. It +doesn't wait for the new request to complete. If there is no ongoing +request it starts the new request and returns immediately. + +MMC host extensions +=================== + +There are two optional members in the mmc_host_ops -- pre_req() and +post_req() -- that the host driver may implement in order to move work +to before and after the actual mmc_host_ops.request() function is called. +In the DMA case pre_req() may do dma_map_sg() and prepare the DMA +descriptor, and post_req() runs the dma_unmap_sg(). + +Optimize for the first request +============================== + +The first request in a series of requests can't be prepared in parallel +with the previous transfer, since there is no previous request. +The argument is_first_req in pre_req() indicates that there is no previous +request. The host driver may optimize for this scenario to minimize +the performance loss. A way to optimize for this is to split the current +request in two chunks, prepare the first chunk and start the request, +and finally prepare the second chunk and start the transfer. + +Pseudocode to handle is_first_req scenario with minimal prepare overhead: + +if (is_first_req && req->size > threshold) + /* start MMC transfer for the complete transfer size */ + mmc_start_command(MMC_CMD_TRANSFER_FULL_SIZE); + + /* + * Begin to prepare DMA while cmd is being processed by MMC. + * The first chunk of the request should take the same time + * to prepare as the "MMC process command time". + * If prepare time exceeds MMC cmd time + * the transfer is delayed, guesstimate max 4k as first chunk size. + */ + prepare_1st_chunk_for_dma(req); + /* flush pending desc to the DMAC (dmaengine.h) */ + dma_issue_pending(req->dma_desc); + + prepare_2nd_chunk_for_dma(req); + /* + * The second issue_pending should be called before MMC runs out + * of the first chunk. If the MMC runs out of the first data chunk + * before this call, the transfer is delayed. + */ + dma_issue_pending(req->dma_desc); diff --git a/Documentation/networking/ifenslave.c b/Documentation/networking/ifenslave.c index 2bac9618c345..65968fbf1e49 100644 --- a/Documentation/networking/ifenslave.c +++ b/Documentation/networking/ifenslave.c @@ -260,7 +260,7 @@ int main(int argc, char *argv[]) case 'V': opt_V++; exclusive++; break; case '?': - fprintf(stderr, usage_msg); + fprintf(stderr, "%s", usage_msg); res = 2; goto out; } @@ -268,13 +268,13 @@ int main(int argc, char *argv[]) /* options check */ if (exclusive > 1) { - fprintf(stderr, usage_msg); + fprintf(stderr, "%s", usage_msg); res = 2; goto out; } if (opt_v || opt_V) { - printf(version); + printf("%s", version); if (opt_V) { res = 0; goto out; @@ -282,14 +282,14 @@ int main(int argc, char *argv[]) } if (opt_u) { - printf(usage_msg); + printf("%s", usage_msg); res = 0; goto out; } if (opt_h) { - printf(usage_msg); - printf(help_msg); + printf("%s", usage_msg); + printf("%s", help_msg); res = 0; goto out; } @@ -309,7 +309,7 @@ int main(int argc, char *argv[]) goto out; } else { /* Just show usage */ - fprintf(stderr, usage_msg); + fprintf(stderr, "%s", usage_msg); res = 2; goto out; } @@ -320,7 +320,7 @@ int main(int argc, char *argv[]) master_ifname = *spp++; if (master_ifname == NULL) { - fprintf(stderr, usage_msg); + fprintf(stderr, "%s", usage_msg); res = 2; goto out; } @@ -339,7 +339,7 @@ int main(int argc, char *argv[]) if (slave_ifname == NULL) { if (opt_d || opt_c) { - fprintf(stderr, usage_msg); + fprintf(stderr, "%s", usage_msg); res = 2; goto out; } diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index d3d653a5f9b9..db2a4067013c 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -106,16 +106,6 @@ inet_peer_maxttl - INTEGER when the number of entries in the pool is very small). Measured in seconds. -inet_peer_gc_mintime - INTEGER - Minimum interval between garbage collection passes. This interval is - in effect under high memory pressure on the pool. - Measured in seconds. - -inet_peer_gc_maxtime - INTEGER - Minimum interval between garbage collection passes. This interval is - in effect under low (or absent) memory pressure on the pool. - Measured in seconds. - TCP variables: somaxconn - INTEGER @@ -346,7 +336,7 @@ tcp_orphan_retries - INTEGER when RTO retransmissions remain unacknowledged. See tcp_retries2 for more details. - The default value is 7. + The default value is 8. If your machine is a loaded WEB server, you should think about lowering this value, such sockets may consume significant resources. Cf. tcp_max_orphans. @@ -394,7 +384,7 @@ tcp_rmem - vector of 3 INTEGERs: min, default, max min: Minimal size of receive buffer used by TCP sockets. It is guaranteed to each TCP socket, even under moderate memory pressure. - Default: 8K + Default: 1 page default: initial size of receive buffer used by TCP sockets. This value overrides net.core.rmem_default used by other protocols. @@ -483,7 +473,7 @@ tcp_window_scaling - BOOLEAN tcp_wmem - vector of 3 INTEGERs: min, default, max min: Amount of memory reserved for send buffers for TCP sockets. Each TCP socket has rights to use it due to fact of its birth. - Default: 4K + Default: 1 page default: initial size of send buffer used by TCP sockets. This value overrides net.core.wmem_default used by other protocols. @@ -553,13 +543,13 @@ udp_rmem_min - INTEGER Minimal size of receive buffer used by UDP sockets in moderation. Each UDP socket is able to use the size for receiving data, even if total pages of UDP sockets exceed udp_mem pressure. The unit is byte. - Default: 4096 + Default: 1 page udp_wmem_min - INTEGER Minimal size of send buffer used by UDP sockets in moderation. Each UDP socket is able to use the size for sending data, even if total pages of UDP sockets exceed udp_mem pressure. The unit is byte. - Default: 4096 + Default: 1 page CIPSOv4 Variables: @@ -1465,10 +1455,17 @@ sctp_mem - vector of 3 INTEGERs: min, pressure, max Default is calculated at boot time from amount of available memory. sctp_rmem - vector of 3 INTEGERs: min, default, max - See tcp_rmem for a description. + Only the first value ("min") is used, "default" and "max" are + ignored. + + min: Minimal size of receive buffer used by SCTP socket. + It is guaranteed to each SCTP socket (but not association) even + under moderate memory pressure. + + Default: 1 page sctp_wmem - vector of 3 INTEGERs: min, default, max - See tcp_wmem for a description. + Currently this tunable has no effect. addr_scope_policy - INTEGER Control IPv4 address scoping - draft-stewart-tsvwg-sctp-ipv4-00 diff --git a/Documentation/networking/netdev-features.txt b/Documentation/networking/netdev-features.txt new file mode 100644 index 000000000000..4b1c0dcef84c --- /dev/null +++ b/Documentation/networking/netdev-features.txt @@ -0,0 +1,154 @@ +Netdev features mess and how to get out from it alive +===================================================== + +Author: + Micha艂 Miros艂aw <mirq-linux@rere.qmqm.pl> + + + + Part I: Feature sets +====================== + +Long gone are the days when a network card would just take and give packets +verbatim. Today's devices add multiple features and bugs (read: offloads) +that relieve an OS of various tasks like generating and checking checksums, +splitting packets, classifying them. Those capabilities and their state +are commonly referred to as netdev features in Linux kernel world. + +There are currently three sets of features relevant to the driver, and +one used internally by network core: + + 1. netdev->hw_features set contains features whose state may possibly + be changed (enabled or disabled) for a particular device by user's + request. This set should be initialized in ndo_init callback and not + changed later. + + 2. netdev->features set contains features which are currently enabled + for a device. This should be changed only by network core or in + error paths of ndo_set_features callback. + + 3. netdev->vlan_features set contains features whose state is inherited + by child VLAN devices (limits netdev->features set). This is currently + used for all VLAN devices whether tags are stripped or inserted in + hardware or software. + + 4. netdev->wanted_features set contains feature set requested by user. + This set is filtered by ndo_fix_features callback whenever it or + some device-specific conditions change. This set is internal to + networking core and should not be referenced in drivers. + + + + Part II: Controlling enabled features +======================================= + +When current feature set (netdev->features) is to be changed, new set +is calculated and filtered by calling ndo_fix_features callback +and netdev_fix_features(). If the resulting set differs from current +set, it is passed to ndo_set_features callback and (if the callback +returns success) replaces value stored in netdev->features. +NETDEV_FEAT_CHANGE notification is issued after that whenever current +set might have changed. + +The following events trigger recalculation: + 1. device's registration, after ndo_init returned success + 2. user requested changes in features state + 3. netdev_update_features() is called + +ndo_*_features callbacks are called with rtnl_lock held. Missing callbacks +are treated as always returning success. + +A driver that wants to trigger recalculation must do so by calling +netdev_update_features() while holding rtnl_lock. This should not be done +from ndo_*_features callbacks. netdev->features should not be modified by +driver except by means of ndo_fix_features callback. + + + + Part III: Implementation hints +================================ + + * ndo_fix_features: + +All dependencies between features should be resolved here. The resulting +set can be reduced further by networking core imposed limitations (as coded +in netdev_fix_features()). For this reason it is safer to disable a feature +when its dependencies are not met instead of forcing the dependency on. + +This callback should not modify hardware nor driver state (should be +stateless). It can be called multiple times between successive +ndo_set_features calls. + +Callback must not alter features contained in NETIF_F_SOFT_FEATURES or +NETIF_F_NEVER_CHANGE sets. The exception is NETIF_F_VLAN_CHALLENGED but +care must be taken as the change won't affect already configured VLANs. + + * ndo_set_features: + +Hardware should be reconfigured to match passed feature set. The set +should not be altered unless some error condition happens that can't +be reliably detected in ndo_fix_features. In this case, the callback +should update netdev->features to match resulting hardware state. +Errors returned are not (and cannot be) propagated anywhere except dmesg. +(Note: successful return is zero, >0 means silent error.) + + + + Part IV: Features +=================== + +For current list of features, see include/linux/netdev_features.h. +This section describes semantics of some of them. + + * Transmit checksumming + +For complete description, see comments near the top of include/linux/skbuff.h. + +Note: NETIF_F_HW_CSUM is a superset of NETIF_F_IP_CSUM + NETIF_F_IPV6_CSUM. +It means that device can fill TCP/UDP-like checksum anywhere in the packets +whatever headers there might be. + + * Transmit TCP segmentation offload + +NETIF_F_TSO_ECN means that hardware can properly split packets with CWR bit +set, be it TCPv4 (when NETIF_F_TSO is enabled) or TCPv6 (NETIF_F_TSO6). + + * Transmit DMA from high memory + +On platforms where this is relevant, NETIF_F_HIGHDMA signals that +ndo_start_xmit can handle skbs with frags in high memory. + + * Transmit scatter-gather + +Those features say that ndo_start_xmit can handle fragmented skbs: +NETIF_F_SG --- paged skbs (skb_shinfo()->frags), NETIF_F_FRAGLIST --- +chained skbs (skb->next/prev list). + + * Software features + +Features contained in NETIF_F_SOFT_FEATURES are features of networking +stack. Driver should not change behaviour based on them. + + * LLTX driver (deprecated for hardware drivers) + +NETIF_F_LLTX should be set in drivers that implement their own locking in +transmit path or don't need locking at all (e.g. software tunnels). +In ndo_start_xmit, it is recommended to use a try_lock and return +NETDEV_TX_LOCKED when the spin lock fails. The locking should also properly +protect against other callbacks (the rules you need to find out). + +Don't use it for new drivers. + + * netns-local device + +NETIF_F_NETNS_LOCAL is set for devices that are not allowed to move between +network namespaces (e.g. loopback). + +Don't use it in drivers. + + * VLAN challenged + +NETIF_F_VLAN_CHALLENGED should be set for devices which can't cope with VLAN +headers. Some drivers set this because the cards can't handle the bigger MTU. +[FIXME: Those cases could be fixed in VLAN code by allowing only reduced-MTU +VLANs. This may be not useful, though.] diff --git a/Documentation/networking/nfc.txt b/Documentation/networking/nfc.txt new file mode 100644 index 000000000000..b24c29bdae27 --- /dev/null +++ b/Documentation/networking/nfc.txt @@ -0,0 +1,128 @@ +Linux NFC subsystem +=================== + +The Near Field Communication (NFC) subsystem is required to standardize the +NFC device drivers development and to create an unified userspace interface. + +This document covers the architecture overview, the device driver interface +description and the userspace interface description. + +Architecture overview +--------------------- + +The NFC subsystem is responsible for: + - NFC adapters management; + - Polling for targets; + - Low-level data exchange; + +The subsystem is divided in some parts. The 'core' is responsible for +providing the device driver interface. On the other side, it is also +responsible for providing an interface to control operations and low-level +data exchange. + +The control operations are available to userspace via generic netlink. + +The low-level data exchange interface is provided by the new socket family +PF_NFC. The NFC_SOCKPROTO_RAW performs raw communication with NFC targets. + + + +--------------------------------------+ + | USER SPACE | + +--------------------------------------+ + ^ ^ + | low-level | control + | data exchange | operations + | | + | v + | +-----------+ + | AF_NFC | netlink | + | socket +-----------+ + | raw ^ + | | + v v + +---------+ +-----------+ + | rawsock | <--------> | core | + +---------+ +-----------+ + ^ + | + v + +-----------+ + | driver | + +-----------+ + +Device Driver Interface +----------------------- + +When registering on the NFC subsystem, the device driver must inform the core +of the set of supported NFC protocols and the set of ops callbacks. The ops +callbacks that must be implemented are the following: + +* start_poll - setup the device to poll for targets +* stop_poll - stop on progress polling operation +* activate_target - select and initialize one of the targets found +* deactivate_target - deselect and deinitialize the selected target +* data_exchange - send data and receive the response (transceive operation) + +Userspace interface +-------------------- + +The userspace interface is divided in control operations and low-level data +exchange operation. + +CONTROL OPERATIONS: + +Generic netlink is used to implement the interface to the control operations. +The operations are composed by commands and events, all listed below: + +* NFC_CMD_GET_DEVICE - get specific device info or dump the device list +* NFC_CMD_START_POLL - setup a specific device to polling for targets +* NFC_CMD_STOP_POLL - stop the polling operation in a specific device +* NFC_CMD_GET_TARGET - dump the list of targets found by a specific device + +* NFC_EVENT_DEVICE_ADDED - reports an NFC device addition +* NFC_EVENT_DEVICE_REMOVED - reports an NFC device removal +* NFC_EVENT_TARGETS_FOUND - reports START_POLL results when 1 or more targets +are found + +The user must call START_POLL to poll for NFC targets, passing the desired NFC +protocols through NFC_ATTR_PROTOCOLS attribute. The device remains in polling +state until it finds any target. However, the user can stop the polling +operation by calling STOP_POLL command. In this case, it will be checked if +the requester of STOP_POLL is the same of START_POLL. + +If the polling operation finds one or more targets, the event TARGETS_FOUND is +sent (including the device id). The user must call GET_TARGET to get the list of +all targets found by such device. Each reply message has target attributes with +relevant information such as the supported NFC protocols. + +All polling operations requested through one netlink socket are stopped when +it's closed. + +LOW-LEVEL DATA EXCHANGE: + +The userspace must use PF_NFC sockets to perform any data communication with +targets. All NFC sockets use AF_NFC: + +struct sockaddr_nfc { + sa_family_t sa_family; + __u32 dev_idx; + __u32 target_idx; + __u32 nfc_protocol; +}; + +To establish a connection with one target, the user must create an +NFC_SOCKPROTO_RAW socket and call the 'connect' syscall with the sockaddr_nfc +struct correctly filled. All information comes from NFC_EVENT_TARGETS_FOUND +netlink event. As a target can support more than one NFC protocol, the user +must inform which protocol it wants to use. + +Internally, 'connect' will result in an activate_target call to the driver. +When the socket is closed, the target is deactivated. + +The data format exchanged through the sockets is NFC protocol dependent. For +instance, when communicating with MIFARE tags, the data exchanged are MIFARE +commands and their responses. + +The first received package is the response to the first sent package and so +on. In order to allow valid "empty" responses, every data received has a NULL +header of 1 byte. diff --git a/Documentation/networking/stmmac.txt b/Documentation/networking/stmmac.txt index 80a7a3454902..57a24108b845 100644 --- a/Documentation/networking/stmmac.txt +++ b/Documentation/networking/stmmac.txt @@ -7,7 +7,7 @@ This is the driver for the MAC 10/100/1000 on-chip Ethernet controllers (Synopsys IP blocks); it has been fully tested on STLinux platforms. Currently this network device driver is for all STM embedded MAC/GMAC -(7xxx SoCs). Other platforms start using it i.e. ARM SPEAr. +(i.e. 7xxx/5xxx SoCs) and it's known working on other platforms i.e. ARM SPEAr. DWC Ether MAC 10/100/1000 Universal version 3.41a and DWC Ether MAC 10/100 Universal version 4.0 have been used for developing the first code @@ -71,7 +71,7 @@ Several performance tests on STM platforms showed this optimisation allows to sp the CPU while having the maximum throughput. 4.4) WOL -Wake up on Lan feature through Magic Frame is only supported for the GMAC +Wake up on Lan feature through Magic and Unicast frames are supported for the GMAC core. 4.5) DMA descriptors @@ -91,11 +91,15 @@ LRO is not supported. The driver is compatible with PAL to work with PHY and GPHY devices. 4.9) Platform information -Several information came from the platform; please refer to the -driver's Header file in include/linux directory. +Several driver's information can be passed through the platform +These are included in the include/linux/stmmac.h header file +and detailed below as well: -struct plat_stmmacenet_data { + struct plat_stmmacenet_data { int bus_id; + int phy_addr; + int interface; + struct stmmac_mdio_bus_data *mdio_bus_data; int pbl; int clk_csr; int has_gmac; @@ -103,67 +107,135 @@ struct plat_stmmacenet_data { int tx_coe; int bugged_jumbo; int pmt; - void (*fix_mac_speed)(void *priv, unsigned int speed); - void (*bus_setup)(unsigned long ioaddr); -#ifdef CONFIG_STM_DRIVERS - struct stm_pad_config *pad_config; -#endif - void *bsp_priv; -}; + int force_sf_dma_mode; + void (*fix_mac_speed)(void *priv, unsigned int speed); + void (*bus_setup)(void __iomem *ioaddr); + int (*init)(struct platform_device *pdev); + void (*exit)(struct platform_device *pdev); + void *bsp_priv; + }; Where: -- pbl (Programmable Burst Length) is maximum number of - beats to be transferred in one DMA transaction. - GMAC also enables the 4xPBL by default. -- fix_mac_speed and bus_setup are used to configure internal target - registers (on STM platforms); -- has_gmac: GMAC core is on board (get it at run-time in the next step); -- bus_id: bus identifier. -- tx_coe: core is able to perform the tx csum in HW. -- enh_desc: if sets the MAC will use the enhanced descriptor structure. -- clk_csr: CSR Clock range selection. -- bugged_jumbo: some HWs are not able to perform the csum in HW for - over-sized frames due to limited buffer sizes. Setting this - flag the csum will be done in SW on JUMBO frames. - -struct plat_stmmacphy_data { - int bus_id; - int phy_addr; - unsigned int phy_mask; - int interface; - int (*phy_reset)(void *priv); - void *priv; -}; + o bus_id: bus identifier. + o phy_addr: the physical address can be passed from the platform. + If it is set to -1 the driver will automatically + detect it at run-time by probing all the 32 addresses. + o interface: PHY device's interface. + o mdio_bus_data: specific platform fields for the MDIO bus. + o pbl: the Programmable Burst Length is maximum number of beats to + be transferred in one DMA transaction. + GMAC also enables the 4xPBL by default. + o clk_csr: CSR Clock range selection. + o has_gmac: uses the GMAC core. + o enh_desc: if sets the MAC will use the enhanced descriptor structure. + o tx_coe: core is able to perform the tx csum in HW. + o bugged_jumbo: some HWs are not able to perform the csum in HW for + over-sized frames due to limited buffer sizes. + Setting this flag the csum will be done in SW on + JUMBO frames. + o pmt: core has the embedded power module (optional). + o force_sf_dma_mode: force DMA to use the Store and Forward mode + instead of the Threshold. + o fix_mac_speed: this callback is used for modifying some syscfg registers + (on ST SoCs) according to the link speed negotiated by the + physical layer . + o bus_setup: perform HW setup of the bus. For example, on some ST platforms + this field is used to configure the AMBA bridge to generate more + efficient STBus traffic. + o init/exit: callbacks used for calling a custom initialisation; + this is sometime necessary on some platforms (e.g. ST boxes) + where the HW needs to have set some PIO lines or system cfg + registers. + o custom_cfg: this is a custom configuration that can be passed while + initialising the resources. + +The we have: + + struct stmmac_mdio_bus_data { + int bus_id; + int (*phy_reset)(void *priv); + unsigned int phy_mask; + int *irqs; + int probed_phy_irq; + }; Where: -- bus_id: bus identifier; -- phy_addr: physical address used for the attached phy device; - set it to -1 to get it at run-time; -- interface: physical MII interface mode; -- phy_reset: hook to reset HW function. - -SOURCES: -- Kconfig -- Makefile -- stmmac_main.c: main network device driver; -- stmmac_mdio.c: mdio functions; -- stmmac_ethtool.c: ethtool support; -- stmmac_timer.[ch]: timer code used for mitigating the driver dma interrupts - Only tested on ST40 platforms based. -- stmmac.h: private driver structure; -- common.h: common definitions and VFTs; -- descs.h: descriptor structure definitions; -- dwmac1000_core.c: GMAC core functions; -- dwmac1000_dma.c: dma functions for the GMAC chip; -- dwmac1000.h: specific header file for the GMAC; -- dwmac100_core: MAC 100 core and dma code; -- dwmac100_dma.c: dma funtions for the MAC chip; -- dwmac1000.h: specific header file for the MAC; -- dwmac_lib.c: generic DMA functions shared among chips -- enh_desc.c: functions for handling enhanced descriptors -- norm_desc.c: functions for handling normal descriptors - -TODO: -- XGMAC controller is not supported. -- Review the timer optimisation code to use an embedded device that seems to be + o bus_id: bus identifier; + o phy_reset: hook to reset the phy device attached to the bus. + o phy_mask: phy mask passed when register the MDIO bus within the driver. + o irqs: list of IRQs, one per PHY. + o probed_phy_irq: if irqs is NULL, use this for probed PHY. + +Below an example how the structures above are using on ST platforms. + + static struct plat_stmmacenet_data stxYYY_ethernet_platform_data = { + .pbl = 32, + .has_gmac = 0, + .enh_desc = 0, + .fix_mac_speed = stxYYY_ethernet_fix_mac_speed, + | + |-> to write an internal syscfg + | on this platform when the + | link speed changes from 10 to + | 100 and viceversa + .init = &stmmac_claim_resource, + | + |-> On ST SoC this calls own "PAD" + | manager framework to claim + | all the resources necessary + | (GPIO ...). The .custom_cfg field + | is used to pass a custom config. +}; + +Below the usage of the stmmac_mdio_bus_data: on this SoC, in fact, +there are two MAC cores: one MAC is for MDIO Bus/PHY emulation +with fixed_link support. + +static struct stmmac_mdio_bus_data stmmac1_mdio_bus = { + .bus_id = 1, + | + |-> phy device on the bus_id 1 + .phy_reset = phy_reset; + | + |-> function to provide the phy_reset on this board + .phy_mask = 0, +}; + +static struct fixed_phy_status stmmac0_fixed_phy_status = { + .link = 1, + .speed = 100, + .duplex = 1, +}; + +During the board's device_init we can configure the first +MAC for fixed_link by calling: + fixed_phy_add(PHY_POLL, 1, &stmmac0_fixed_phy_status));) +and the second one, with a real PHY device attached to the bus, +by using the stmmac_mdio_bus_data structure (to provide the id, the +reset procedure etc). + +4.10) List of source files: + o Kconfig + o Makefile + o stmmac_main.c: main network device driver; + o stmmac_mdio.c: mdio functions; + o stmmac_ethtool.c: ethtool support; + o stmmac_timer.[ch]: timer code used for mitigating the driver dma interrupts + Only tested on ST40 platforms based. + o stmmac.h: private driver structure; + o common.h: common definitions and VFTs; + o descs.h: descriptor structure definitions; + o dwmac1000_core.c: GMAC core functions; + o dwmac1000_dma.c: dma functions for the GMAC chip; + o dwmac1000.h: specific header file for the GMAC; + o dwmac100_core: MAC 100 core and dma code; + o dwmac100_dma.c: dma funtions for the MAC chip; + o dwmac1000.h: specific header file for the MAC; + o dwmac_lib.c: generic DMA functions shared among chips + o enh_desc.c: functions for handling enhanced descriptors + o norm_desc.c: functions for handling normal descriptors + +5) TODO: + o XGMAC is not supported. + o Review the timer optimisation code to use an embedded device that will be available in new chip generations. diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 88880839ece4..3384d5996be2 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -506,8 +506,8 @@ routines. Nevertheless, different callback pointers are used in case there is a situation where it actually matters. -Device Power Domains --------------------- +Device Power Management Domains +------------------------------- Sometimes devices share reference clocks or other power resources. In those cases it generally is not possible to put devices into low-power states individually. Instead, a set of devices sharing a power resource can be put @@ -516,63 +516,24 @@ power resource. Of course, they also need to be put into the full-power state together, by turning the shared power resource on. A set of devices with this property is often referred to as a power domain. -Support for power domains is provided through the pwr_domain field of struct -device. This field is a pointer to an object of type struct dev_power_domain, +Support for power domains is provided through the pm_domain field of struct +device. This field is a pointer to an object of type struct dev_pm_domain, defined in include/linux/pm.h, providing a set of power management callbacks analogous to the subsystem-level and device driver callbacks that are executed -for the given device during all power transitions, in addition to the respective -subsystem-level callbacks. Specifically, the power domain "suspend" callbacks -(i.e. ->runtime_suspend(), ->suspend(), ->freeze(), ->poweroff(), etc.) are -executed after the analogous subsystem-level callbacks, while the power domain -"resume" callbacks (i.e. ->runtime_resume(), ->resume(), ->thaw(), ->restore, -etc.) are executed before the analogous subsystem-level callbacks. Error codes -returned by the "suspend" and "resume" power domain callbacks are ignored. - -Power domain ->runtime_idle() callback is executed before the subsystem-level -->runtime_idle() callback and the result returned by it is not ignored. Namely, -if it returns error code, the subsystem-level ->runtime_idle() callback will not -be called and the helper function rpm_idle() executing it will return error -code. This mechanism is intended to help platforms where saving device state -is a time consuming operation and should only be carried out if all devices -in the power domain are idle, before turning off the shared power resource(s). -Namely, the power domain ->runtime_idle() callback may return error code until -the pm_runtime_idle() helper (or its asychronous version) has been called for -all devices in the power domain (it is recommended that the returned error code -be -EBUSY in those cases), preventing the subsystem-level ->runtime_idle() -callback from being run prematurely. - -The support for device power domains is only relevant to platforms needing to -use the same subsystem-level (e.g. platform bus type) and device driver power -management callbacks in many different power domain configurations and wanting -to avoid incorporating the support for power domains into the subsystem-level -callbacks. The other platforms need not implement it or take it into account -in any way. - - -System Devices --------------- -System devices (sysdevs) follow a slightly different API, which can be found in - - include/linux/sysdev.h - drivers/base/sys.c - -System devices will be suspended with interrupts disabled, and after all other -devices have been suspended. On resume, they will be resumed before any other -devices, and also with interrupts disabled. These things occur in special -"sysdev_driver" phases, which affect only system devices. - -Thus, after the suspend_noirq (or freeze_noirq or poweroff_noirq) phase, when -the non-boot CPUs are all offline and IRQs are disabled on the remaining online -CPU, then a sysdev_driver.suspend phase is carried out, and the system enters a -sleep state (or a system image is created). During resume (or after the image -has been created or loaded) a sysdev_driver.resume phase is carried out, IRQs -are enabled on the only online CPU, the non-boot CPUs are enabled, and the -resume_noirq (or thaw_noirq or restore_noirq) phase begins. - -Code to actually enter and exit the system-wide low power state sometimes -involves hardware details that are only known to the boot firmware, and -may leave a CPU running software (from SRAM or flash memory) that monitors -the system and manages its wakeup sequence. +for the given device during all power transitions, instead of the respective +subsystem-level callbacks. Specifically, if a device's pm_domain pointer is +not NULL, the ->suspend() callback from the object pointed to by it will be +executed instead of its subsystem's (e.g. bus type's) ->suspend() callback and +anlogously for all of the remaining callbacks. In other words, power management +domain callbacks, if defined for the given device, always take precedence over +the callbacks provided by the device's subsystem (e.g. bus type). + +The support for device power management domains is only relevant to platforms +needing to use the same device driver power management callbacks in many +different power domain configurations and wanting to avoid incorporating the +support for power domains into subsystem-level callbacks, for example by +modifying the platform bus type. Other platforms need not implement it or take +it into account in any way. Device Low Power (suspend) States @@ -643,7 +604,7 @@ state temporarily, for example so that its system wakeup capability can be disabled. This all depends on the hardware and the design of the subsystem and device driver in question. -During system-wide resume from a sleep state it's best to put devices into the -full-power state, as explained in Documentation/power/runtime_pm.txt. Refer to -that document for more information regarding this particular issue as well as +During system-wide resume from a sleep state it's easiest to put devices into +the full-power state, as explained in Documentation/power/runtime_pm.txt. Refer +to that document for more information regarding this particular issue as well as for information on the device runtime power management framework in general. diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt index 5ae70a12c1e2..3035d00757ad 100644 --- a/Documentation/power/opp.txt +++ b/Documentation/power/opp.txt @@ -321,6 +321,8 @@ opp_init_cpufreq_table - cpufreq framework typically is initialized with addition to CONFIG_PM as power management feature is required to dynamically scale voltage and frequency in a system. +opp_free_cpufreq_table - Free up the table allocated by opp_init_cpufreq_table + 7. Data Structures ================== Typically an SoC contains multiple voltage domains which are variable. Each diff --git a/Documentation/power/runtime_pm.txt b/Documentation/power/runtime_pm.txt index 654097b130b4..14dd3c6ad97e 100644 --- a/Documentation/power/runtime_pm.txt +++ b/Documentation/power/runtime_pm.txt @@ -1,39 +1,39 @@ -Run-time Power Management Framework for I/O Devices +Runtime Power Management Framework for I/O Devices (C) 2009-2011 Rafael J. Wysocki <rjw@sisk.pl>, Novell Inc. (C) 2010 Alan Stern <stern@rowland.harvard.edu> 1. Introduction -Support for run-time power management (run-time PM) of I/O devices is provided +Support for runtime power management (runtime PM) of I/O devices is provided at the power management core (PM core) level by means of: * The power management workqueue pm_wq in which bus types and device drivers can put their PM-related work items. It is strongly recommended that pm_wq be - used for queuing all work items related to run-time PM, because this allows + used for queuing all work items related to runtime PM, because this allows them to be synchronized with system-wide power transitions (suspend to RAM, hibernation and resume from system sleep states). pm_wq is declared in include/linux/pm_runtime.h and defined in kernel/power/main.c. -* A number of run-time PM fields in the 'power' member of 'struct device' (which +* A number of runtime PM fields in the 'power' member of 'struct device' (which is of the type 'struct dev_pm_info', defined in include/linux/pm.h) that can - be used for synchronizing run-time PM operations with one another. + be used for synchronizing runtime PM operations with one another. -* Three device run-time PM callbacks in 'struct dev_pm_ops' (defined in +* Three device runtime PM callbacks in 'struct dev_pm_ops' (defined in include/linux/pm.h). * A set of helper functions defined in drivers/base/power/runtime.c that can be - used for carrying out run-time PM operations in such a way that the + used for carrying out runtime PM operations in such a way that the synchronization between them is taken care of by the PM core. Bus types and device drivers are encouraged to use these functions. -The run-time PM callbacks present in 'struct dev_pm_ops', the device run-time PM +The runtime PM callbacks present in 'struct dev_pm_ops', the device runtime PM fields of 'struct dev_pm_info' and the core helper functions provided for -run-time PM are described below. +runtime PM are described below. -2. Device Run-time PM Callbacks +2. Device Runtime PM Callbacks -There are three device run-time PM callbacks defined in 'struct dev_pm_ops': +There are three device runtime PM callbacks defined in 'struct dev_pm_ops': struct dev_pm_ops { ... @@ -72,11 +72,11 @@ knows what to do to handle the device). not mean that the device has been put into a low power state. It is supposed to mean, however, that the device will not process data and will not communicate with the CPU(s) and RAM until the subsystem-level resume - callback is executed for it. The run-time PM status of a device after + callback is executed for it. The runtime PM status of a device after successful execution of the subsystem-level suspend callback is 'suspended'. * If the subsystem-level suspend callback returns -EBUSY or -EAGAIN, - the device's run-time PM status is 'active', which means that the device + the device's runtime PM status is 'active', which means that the device _must_ be fully operational afterwards. * If the subsystem-level suspend callback returns an error code different @@ -104,7 +104,7 @@ the device). * Once the subsystem-level resume callback has completed successfully, the PM core regards the device as fully operational, which means that the device - _must_ be able to complete I/O operations as needed. The run-time PM status + _must_ be able to complete I/O operations as needed. The runtime PM status of the device is then 'active'. * If the subsystem-level resume callback returns an error code, the PM core @@ -130,7 +130,7 @@ device in that case. The value returned by this callback is ignored by the PM core. The helper functions provided by the PM core, described in Section 4, guarantee -that the following constraints are met with respect to the bus type's run-time +that the following constraints are met with respect to the bus type's runtime PM callbacks: (1) The callbacks are mutually exclusive (e.g. it is forbidden to execute @@ -142,7 +142,7 @@ PM callbacks: (2) ->runtime_idle() and ->runtime_suspend() can only be executed for 'active' devices (i.e. the PM core will only execute ->runtime_idle() or - ->runtime_suspend() for the devices the run-time PM status of which is + ->runtime_suspend() for the devices the runtime PM status of which is 'active'). (3) ->runtime_idle() and ->runtime_suspend() can only be executed for a device @@ -151,7 +151,7 @@ PM callbacks: flag of which is set. (4) ->runtime_resume() can only be executed for 'suspended' devices (i.e. the - PM core will only execute ->runtime_resume() for the devices the run-time + PM core will only execute ->runtime_resume() for the devices the runtime PM status of which is 'suspended'). Additionally, the helper functions provided by the PM core obey the following @@ -171,9 +171,9 @@ rules: scheduled requests to execute the other callbacks for the same device, except for scheduled autosuspends. -3. Run-time PM Device Fields +3. Runtime PM Device Fields -The following device run-time PM fields are present in 'struct dev_pm_info', as +The following device runtime PM fields are present in 'struct dev_pm_info', as defined in include/linux/pm.h: struct timer_list suspend_timer; @@ -205,7 +205,7 @@ defined in include/linux/pm.h: unsigned int disable_depth; - used for disabling the helper funcions (they work normally if this is - equal to zero); the initial value of it is 1 (i.e. run-time PM is + equal to zero); the initial value of it is 1 (i.e. runtime PM is initially disabled for all devices) unsigned int runtime_error; @@ -229,10 +229,10 @@ defined in include/linux/pm.h: suspend to complete; means "start a resume as soon as you've suspended" unsigned int run_wake; - - set if the device is capable of generating run-time wake-up events + - set if the device is capable of generating runtime wake-up events enum rpm_status runtime_status; - - the run-time PM status of the device; this field's initial value is + - the runtime PM status of the device; this field's initial value is RPM_SUSPENDED, which means that each device is initially regarded by the PM core as 'suspended', regardless of its real hardware status @@ -243,7 +243,7 @@ defined in include/linux/pm.h: and pm_runtime_forbid() helper functions unsigned int no_callbacks; - - indicates that the device does not use the run-time PM callbacks (see + - indicates that the device does not use the runtime PM callbacks (see Section 8); it may be modified only by the pm_runtime_no_callbacks() helper function @@ -270,16 +270,16 @@ defined in include/linux/pm.h: All of the above fields are members of the 'power' member of 'struct device'. -4. Run-time PM Device Helper Functions +4. Runtime PM Device Helper Functions -The following run-time PM helper functions are defined in +The following runtime PM helper functions are defined in drivers/base/power/runtime.c and include/linux/pm_runtime.h: void pm_runtime_init(struct device *dev); - - initialize the device run-time PM fields in 'struct dev_pm_info' + - initialize the device runtime PM fields in 'struct dev_pm_info' void pm_runtime_remove(struct device *dev); - - make sure that the run-time PM of the device will be disabled after + - make sure that the runtime PM of the device will be disabled after removing the device from device hierarchy int pm_runtime_idle(struct device *dev); @@ -289,9 +289,10 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: int pm_runtime_suspend(struct device *dev); - execute the subsystem-level suspend callback for the device; returns 0 on - success, 1 if the device's run-time PM status was already 'suspended', or + success, 1 if the device's runtime PM status was already 'suspended', or error code on failure, where -EAGAIN or -EBUSY means it is safe to attempt - to suspend the device again in future + to suspend the device again in future and -EACCES means that + 'power.disable_depth' is different from 0 int pm_runtime_autosuspend(struct device *dev); - same as pm_runtime_suspend() except that the autosuspend delay is taken @@ -301,10 +302,11 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: int pm_runtime_resume(struct device *dev); - execute the subsystem-level resume callback for the device; returns 0 on - success, 1 if the device's run-time PM status was already 'active' or + success, 1 if the device's runtime PM status was already 'active' or error code on failure, where -EAGAIN means it may be safe to attempt to resume the device again in future, but 'power.runtime_error' should be - checked additionally + checked additionally, and -EACCES means that 'power.disable_depth' is + different from 0 int pm_request_idle(struct device *dev); - submit a request to execute the subsystem-level idle callback for the @@ -321,7 +323,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: device in future, where 'delay' is the time to wait before queuing up a suspend work item in pm_wq, in milliseconds (if 'delay' is zero, the work item is queued up immediately); returns 0 on success, 1 if the device's PM - run-time status was already 'suspended', or error code if the request + runtime status was already 'suspended', or error code if the request hasn't been scheduled (or queued up if 'delay' is 0); if the execution of ->runtime_suspend() is already scheduled and not yet expired, the new value of 'delay' will be used as the time to wait @@ -329,7 +331,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: int pm_request_resume(struct device *dev); - submit a request to execute the subsystem-level resume callback for the device (the request is represented by a work item in pm_wq); returns 0 on - success, 1 if the device's run-time PM status was already 'active', or + success, 1 if the device's runtime PM status was already 'active', or error code if the request hasn't been queued up void pm_runtime_get_noresume(struct device *dev); @@ -367,22 +369,32 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: pm_runtime_autosuspend(dev) and return its result void pm_runtime_enable(struct device *dev); - - enable the run-time PM helper functions to run the device bus type's - run-time PM callbacks described in Section 2 + - decrement the device's 'power.disable_depth' field; if that field is equal + to zero, the runtime PM helper functions can execute subsystem-level + callbacks described in Section 2 for the device int pm_runtime_disable(struct device *dev); - - prevent the run-time PM helper functions from running subsystem-level - run-time PM callbacks for the device, make sure that all of the pending - run-time PM operations on the device are either completed or canceled; + - increment the device's 'power.disable_depth' field (if the value of that + field was previously zero, this prevents subsystem-level runtime PM + callbacks from being run for the device), make sure that all of the pending + runtime PM operations on the device are either completed or canceled; returns 1 if there was a resume request pending and it was necessary to execute the subsystem-level resume callback for the device to satisfy that request, otherwise 0 is returned + int pm_runtime_barrier(struct device *dev); + - check if there's a resume request pending for the device and resume it + (synchronously) in that case, cancel any other pending runtime PM requests + regarding it and wait for all runtime PM operations on it in progress to + complete; returns 1 if there was a resume request pending and it was + necessary to execute the subsystem-level resume callback for the device to + satisfy that request, otherwise 0 is returned + void pm_suspend_ignore_children(struct device *dev, bool enable); - set/unset the power.ignore_children flag of the device int pm_runtime_set_active(struct device *dev); - - clear the device's 'power.runtime_error' flag, set the device's run-time + - clear the device's 'power.runtime_error' flag, set the device's runtime PM status to 'active' and update its parent's counter of 'active' children as appropriate (it is only valid to use this function if 'power.runtime_error' is set or 'power.disable_depth' is greater than @@ -390,7 +402,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: which is not active and the 'power.ignore_children' flag of which is unset void pm_runtime_set_suspended(struct device *dev); - - clear the device's 'power.runtime_error' flag, set the device's run-time + - clear the device's 'power.runtime_error' flag, set the device's runtime PM status to 'suspended' and update its parent's counter of 'active' children as appropriate (it is only valid to use this function if 'power.runtime_error' is set or 'power.disable_depth' is greater than @@ -400,6 +412,9 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: - return true if the device's runtime PM status is 'suspended' and its 'power.disable_depth' field is equal to zero, or false otherwise + bool pm_runtime_status_suspended(struct device *dev); + - return true if the device's runtime PM status is 'suspended' + void pm_runtime_allow(struct device *dev); - set the power.runtime_auto flag for the device and decrease its usage counter (used by the /sys/devices/.../power/control interface to @@ -411,7 +426,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: effectively prevent the device from being power managed at run time) void pm_runtime_no_callbacks(struct device *dev); - - set the power.no_callbacks flag for the device and remove the run-time + - set the power.no_callbacks flag for the device and remove the runtime PM attributes from /sys/devices/.../power (or prevent them from being added when the device is registered) @@ -431,7 +446,7 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h: void pm_runtime_set_autosuspend_delay(struct device *dev, int delay); - set the power.autosuspend_delay value to 'delay' (expressed in - milliseconds); if 'delay' is negative then run-time suspends are + milliseconds); if 'delay' is negative then runtime suspends are prevented unsigned long pm_runtime_autosuspend_expiration(struct device *dev); @@ -470,76 +485,92 @@ pm_runtime_resume() pm_runtime_get_sync() pm_runtime_put_sync_suspend() -5. Run-time PM Initialization, Device Probing and Removal +5. Runtime PM Initialization, Device Probing and Removal -Initially, the run-time PM is disabled for all devices, which means that the -majority of the run-time PM helper funtions described in Section 4 will return +Initially, the runtime PM is disabled for all devices, which means that the +majority of the runtime PM helper funtions described in Section 4 will return -EAGAIN until pm_runtime_enable() is called for the device. -In addition to that, the initial run-time PM status of all devices is +In addition to that, the initial runtime PM status of all devices is 'suspended', but it need not reflect the actual physical state of the device. Thus, if the device is initially active (i.e. it is able to process I/O), its -run-time PM status must be changed to 'active', with the help of +runtime PM status must be changed to 'active', with the help of pm_runtime_set_active(), before pm_runtime_enable() is called for the device. -However, if the device has a parent and the parent's run-time PM is enabled, +However, if the device has a parent and the parent's runtime PM is enabled, calling pm_runtime_set_active() for the device will affect the parent, unless the parent's 'power.ignore_children' flag is set. Namely, in that case the parent won't be able to suspend at run time, using the PM core's helper functions, as long as the child's status is 'active', even if the child's -run-time PM is still disabled (i.e. pm_runtime_enable() hasn't been called for +runtime PM is still disabled (i.e. pm_runtime_enable() hasn't been called for the child yet or pm_runtime_disable() has been called for it). For this reason, once pm_runtime_set_active() has been called for the device, pm_runtime_enable() -should be called for it too as soon as reasonably possible or its run-time PM +should be called for it too as soon as reasonably possible or its runtime PM status should be changed back to 'suspended' with the help of pm_runtime_set_suspended(). -If the default initial run-time PM status of the device (i.e. 'suspended') +If the default initial runtime PM status of the device (i.e. 'suspended') reflects the actual state of the device, its bus type's or its driver's ->probe() callback will likely need to wake it up using one of the PM core's helper functions described in Section 4. In that case, pm_runtime_resume() -should be used. Of course, for this purpose the device's run-time PM has to be +should be used. Of course, for this purpose the device's runtime PM has to be enabled earlier by calling pm_runtime_enable(). -If the device bus type's or driver's ->probe() or ->remove() callback runs +If the device bus type's or driver's ->probe() callback runs pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts, they will fail returning -EAGAIN, because the device's usage counter is -incremented by the core before executing ->probe() and ->remove(). Still, it -may be desirable to suspend the device as soon as ->probe() or ->remove() has -finished, so the PM core uses pm_runtime_idle_sync() to invoke the -subsystem-level idle callback for the device at that time. +incremented by the driver core before executing ->probe(). Still, it may be +desirable to suspend the device as soon as ->probe() has finished, so the driver +core uses pm_runtime_put_sync() to invoke the subsystem-level idle callback for +the device at that time. + +Moreover, the driver core prevents runtime PM callbacks from racing with the bus +notifier callback in __device_release_driver(), which is necessary, because the +notifier is used by some subsystems to carry out operations affecting the +runtime PM functionality. It does so by calling pm_runtime_get_sync() before +driver_sysfs_remove() and the BUS_NOTIFY_UNBIND_DRIVER notifications. This +resumes the device if it's in the suspended state and prevents it from +being suspended again while those routines are being executed. + +To allow bus types and drivers to put devices into the suspended state by +calling pm_runtime_suspend() from their ->remove() routines, the driver core +executes pm_runtime_put_sync() after running the BUS_NOTIFY_UNBIND_DRIVER +notifications in __device_release_driver(). This requires bus types and +drivers to make their ->remove() callbacks avoid races with runtime PM directly, +but also it allows of more flexibility in the handling of devices during the +removal of their drivers. The user space can effectively disallow the driver of the device to power manage it at run time by changing the value of its /sys/devices/.../power/control attribute to "on", which causes pm_runtime_forbid() to be called. In principle, this mechanism may also be used by the driver to effectively turn off the -run-time power management of the device until the user space turns it on. -Namely, during the initialization the driver can make sure that the run-time PM +runtime power management of the device until the user space turns it on. +Namely, during the initialization the driver can make sure that the runtime PM status of the device is 'active' and call pm_runtime_forbid(). It should be noted, however, that if the user space has already intentionally changed the value of /sys/devices/.../power/control to "auto" to allow the driver to power manage the device at run time, the driver may confuse it by using pm_runtime_forbid() this way. -6. Run-time PM and System Sleep +6. Runtime PM and System Sleep -Run-time PM and system sleep (i.e., system suspend and hibernation, also known +Runtime PM and system sleep (i.e., system suspend and hibernation, also known as suspend-to-RAM and suspend-to-disk) interact with each other in a couple of ways. If a device is active when a system sleep starts, everything is straightforward. But what should happen if the device is already suspended? -The device may have different wake-up settings for run-time PM and system sleep. -For example, remote wake-up may be enabled for run-time suspend but disallowed +The device may have different wake-up settings for runtime PM and system sleep. +For example, remote wake-up may be enabled for runtime suspend but disallowed for system sleep (device_may_wakeup(dev) returns 'false'). When this happens, the subsystem-level system suspend callback is responsible for changing the device's wake-up setting (it may leave that to the device driver's system suspend routine). It may be necessary to resume the device and suspend it again in order to do so. The same is true if the driver uses different power levels -or other settings for run-time suspend and system sleep. +or other settings for runtime suspend and system sleep. -During system resume, devices generally should be brought back to full power, -even if they were suspended before the system sleep began. There are several -reasons for this, including: +During system resume, the simplest approach is to bring all devices back to full +power, even if they had been suspended before the system suspend began. There +are several reasons for this, including: * The device might need to switch power levels, wake-up settings, etc. @@ -554,22 +585,49 @@ reasons for this, including: * The device might need to be reset. * Even though the device was suspended, if its usage counter was > 0 then most - likely it would need a run-time resume in the near future anyway. - - * Always going back to full power is simplest. + likely it would need a runtime resume in the near future anyway. -If the device was suspended before the sleep began, then its run-time PM status -will have to be updated to reflect the actual post-system sleep status. The way -to do this is: +If the device had been suspended before the system suspend began and it's +brought back to full power during resume, then its runtime PM status will have +to be updated to reflect the actual post-system sleep status. The way to do +this is: pm_runtime_disable(dev); pm_runtime_set_active(dev); pm_runtime_enable(dev); -The PM core always increments the run-time usage counter before calling the -->prepare() callback and decrements it after calling the ->complete() callback. -Hence disabling run-time PM temporarily like this will not cause any run-time -suspend callbacks to be lost. +The PM core always increments the runtime usage counter before calling the +->suspend() callback and decrements it after calling the ->resume() callback. +Hence disabling runtime PM temporarily like this will not cause any runtime +suspend attempts to be permanently lost. If the usage count goes to zero +following the return of the ->resume() callback, the ->runtime_idle() callback +will be invoked as usual. + +On some systems, however, system sleep is not entered through a global firmware +or hardware operation. Instead, all hardware components are put into low-power +states directly by the kernel in a coordinated way. Then, the system sleep +state effectively follows from the states the hardware components end up in +and the system is woken up from that state by a hardware interrupt or a similar +mechanism entirely under the kernel's control. As a result, the kernel never +gives control away and the states of all devices during resume are precisely +known to it. If that is the case and none of the situations listed above takes +place (in particular, if the system is not waking up from hibernation), it may +be more efficient to leave the devices that had been suspended before the system +suspend began in the suspended state. + +The PM core does its best to reduce the probability of race conditions between +the runtime PM and system suspend/resume (and hibernation) callbacks by carrying +out the following operations: + + * During system suspend it calls pm_runtime_get_noresume() and + pm_runtime_barrier() for every device right before executing the + subsystem-level .suspend() callback for it. In addition to that it calls + pm_runtime_disable() for every device right after executing the + subsystem-level .suspend() callback for it. + + * During system resume it calls pm_runtime_enable() and pm_runtime_put_sync() + for every device right before and right after executing the subsystem-level + .resume() callback for it, respectively. 7. Generic subsystem callbacks @@ -595,40 +653,68 @@ driver/base/power/generic_ops.c: callback provided by its driver and return its result, or return 0 if not defined + int pm_generic_suspend_noirq(struct device *dev); + - if pm_runtime_suspended(dev) returns "false", invoke the ->suspend_noirq() + callback provided by the device's driver and return its result, or return + 0 if not defined + int pm_generic_resume(struct device *dev); - invoke the ->resume() callback provided by the driver of this device and, if successful, change the device's runtime PM status to 'active' + int pm_generic_resume_noirq(struct device *dev); + - invoke the ->resume_noirq() callback provided by the driver of this device + int pm_generic_freeze(struct device *dev); - if the device has not been suspended at run time, invoke the ->freeze() callback provided by its driver and return its result, or return 0 if not defined + int pm_generic_freeze_noirq(struct device *dev); + - if pm_runtime_suspended(dev) returns "false", invoke the ->freeze_noirq() + callback provided by the device's driver and return its result, or return + 0 if not defined + int pm_generic_thaw(struct device *dev); - if the device has not been suspended at run time, invoke the ->thaw() callback provided by its driver and return its result, or return 0 if not defined + int pm_generic_thaw_noirq(struct device *dev); + - if pm_runtime_suspended(dev) returns "false", invoke the ->thaw_noirq() + callback provided by the device's driver and return its result, or return + 0 if not defined + int pm_generic_poweroff(struct device *dev); - if the device has not been suspended at run time, invoke the ->poweroff() callback provided by its driver and return its result, or return 0 if not defined + int pm_generic_poweroff_noirq(struct device *dev); + - if pm_runtime_suspended(dev) returns "false", run the ->poweroff_noirq() + callback provided by the device's driver and return its result, or return + 0 if not defined + int pm_generic_restore(struct device *dev); - invoke the ->restore() callback provided by the driver of this device and, if successful, change the device's runtime PM status to 'active' + int pm_generic_restore_noirq(struct device *dev); + - invoke the ->restore_noirq() callback provided by the device's driver + These functions can be assigned to the ->runtime_idle(), ->runtime_suspend(), -->runtime_resume(), ->suspend(), ->resume(), ->freeze(), ->thaw(), ->poweroff(), -or ->restore() callback pointers in the subsystem-level dev_pm_ops structures. +->runtime_resume(), ->suspend(), ->suspend_noirq(), ->resume(), +->resume_noirq(), ->freeze(), ->freeze_noirq(), ->thaw(), ->thaw_noirq(), +->poweroff(), ->poweroff_noirq(), ->restore(), ->restore_noirq() callback +pointers in the subsystem-level dev_pm_ops structures. If a subsystem wishes to use all of them at the same time, it can simply assign the GENERIC_SUBSYS_PM_OPS macro, defined in include/linux/pm.h, to its dev_pm_ops structure pointer. Device drivers that wish to use the same function as a system suspend, freeze, -poweroff and run-time suspend callback, and similarly for system resume, thaw, -restore, and run-time resume, can achieve this with the help of the +poweroff and runtime suspend callback, and similarly for system resume, thaw, +restore, and runtime resume, can achieve this with the help of the UNIVERSAL_DEV_PM_OPS macro defined in include/linux/pm.h (possibly setting its last argument to NULL). @@ -638,7 +724,7 @@ Some "devices" are only logical sub-devices of their parent and cannot be power-managed on their own. (The prototype example is a USB interface. Entire USB devices can go into low-power mode or send wake-up requests, but neither is possible for individual interfaces.) The drivers for these devices have no -need of run-time PM callbacks; if the callbacks did exist, ->runtime_suspend() +need of runtime PM callbacks; if the callbacks did exist, ->runtime_suspend() and ->runtime_resume() would always return 0 without doing anything else and ->runtime_idle() would always call pm_runtime_suspend(). @@ -646,7 +732,7 @@ Subsystems can tell the PM core about these devices by calling pm_runtime_no_callbacks(). This should be done after the device structure is initialized and before it is registered (although after device registration is also okay). The routine will set the device's power.no_callbacks flag and -prevent the non-debugging run-time PM sysfs attributes from being created. +prevent the non-debugging runtime PM sysfs attributes from being created. When power.no_callbacks is set, the PM core will not invoke the ->runtime_idle(), ->runtime_suspend(), or ->runtime_resume() callbacks. @@ -654,7 +740,7 @@ Instead it will assume that suspends and resumes always succeed and that idle devices should be suspended. As a consequence, the PM core will never directly inform the device's subsystem -or driver about run-time power changes. Instead, the driver for the device's +or driver about runtime power changes. Instead, the driver for the device's parent must take responsibility for telling the device's driver when the parent's power state changes. @@ -665,13 +751,13 @@ A device should be put in a low-power state only when there's some reason to think it will remain in that state for a substantial time. A common heuristic says that a device which hasn't been used for a while is liable to remain unused; following this advice, drivers should not allow devices to be suspended -at run-time until they have been inactive for some minimum period. Even when +at runtime until they have been inactive for some minimum period. Even when the heuristic ends up being non-optimal, it will still prevent devices from "bouncing" too rapidly between low-power and full-power states. The term "autosuspend" is an historical remnant. It doesn't mean that the device is automatically suspended (the subsystem or driver still has to call -the appropriate PM routines); rather it means that run-time suspends will +the appropriate PM routines); rather it means that runtime suspends will automatically be delayed until the desired period of inactivity has elapsed. Inactivity is determined based on the power.last_busy field. Drivers should diff --git a/Documentation/printk-formats.txt b/Documentation/printk-formats.txt index 1b5a5ddbc3ef..5df176ed59b8 100644 --- a/Documentation/printk-formats.txt +++ b/Documentation/printk-formats.txt @@ -9,7 +9,121 @@ If variable is of Type, use printk format specifier: size_t %zu or %zx ssize_t %zd or %zx -Raw pointer value SHOULD be printed with %p. +Raw pointer value SHOULD be printed with %p. The kernel supports +the following extended format specifiers for pointer types: + +Symbols/Function Pointers: + + %pF versatile_init+0x0/0x110 + %pf versatile_init + %pS versatile_init+0x0/0x110 + %ps versatile_init + %pB prev_fn_of_versatile_init+0x88/0x88 + + For printing symbols and function pointers. The 'S' and 's' specifiers + result in the symbol name with ('S') or without ('s') offsets. Where + this is used on a kernel without KALLSYMS - the symbol address is + printed instead. + + The 'B' specifier results in the symbol name with offsets and should be + used when printing stack backtraces. The specifier takes into + consideration the effect of compiler optimisations which may occur + when tail-call's are used and marked with the noreturn GCC attribute. + + On ia64, ppc64 and parisc64 architectures function pointers are + actually function descriptors which must first be resolved. The 'F' and + 'f' specifiers perform this resolution and then provide the same + functionality as the 'S' and 's' specifiers. + +Kernel Pointers: + + %pK 0x01234567 or 0x0123456789abcdef + + For printing kernel pointers which should be hidden from unprivileged + users. The behaviour of %pK depends on the kptr_restrict sysctl - see + Documentation/sysctl/kernel.txt for more details. + +Struct Resources: + + %pr [mem 0x60000000-0x6fffffff flags 0x2200] or + [mem 0x0000000060000000-0x000000006fffffff flags 0x2200] + %pR [mem 0x60000000-0x6fffffff pref] or + [mem 0x0000000060000000-0x000000006fffffff pref] + + For printing struct resources. The 'R' and 'r' specifiers result in a + printed resource with ('R') or without ('r') a decoded flags member. + +MAC/FDDI addresses: + + %pM 00:01:02:03:04:05 + %pMF 00-01-02-03-04-05 + %pm 000102030405 + + For printing 6-byte MAC/FDDI addresses in hex notation. The 'M' and 'm' + specifiers result in a printed address with ('M') or without ('m') byte + separators. The default byte separator is the colon (':'). + + Where FDDI addresses are concerned the 'F' specifier can be used after + the 'M' specifier to use dash ('-') separators instead of the default + separator. + +IPv4 addresses: + + %pI4 1.2.3.4 + %pi4 001.002.003.004 + %p[Ii][hnbl] + + For printing IPv4 dot-separated decimal addresses. The 'I4' and 'i4' + specifiers result in a printed address with ('i4') or without ('I4') + leading zeros. + + The additional 'h', 'n', 'b', and 'l' specifiers are used to specify + host, network, big or little endian order addresses respectively. Where + no specifier is provided the default network/big endian order is used. + +IPv6 addresses: + + %pI6 0001:0002:0003:0004:0005:0006:0007:0008 + %pi6 00010002000300040005000600070008 + %pI6c 1:2:3:4:5:6:7:8 + + For printing IPv6 network-order 16-bit hex addresses. The 'I6' and 'i6' + specifiers result in a printed address with ('I6') or without ('i6') + colon-separators. Leading zeros are always used. + + The additional 'c' specifier can be used with the 'I' specifier to + print a compressed IPv6 address as described by + http://tools.ietf.org/html/rfc5952 + +UUID/GUID addresses: + + %pUb 00010203-0405-0607-0809-0a0b0c0d0e0f + %pUB 00010203-0405-0607-0809-0A0B0C0D0E0F + %pUl 03020100-0504-0706-0809-0a0b0c0e0e0f + %pUL 03020100-0504-0706-0809-0A0B0C0E0E0F + + For printing 16-byte UUID/GUIDs addresses. The additional 'l', 'L', + 'b' and 'B' specifiers are used to specify a little endian order in + lower ('l') or upper case ('L') hex characters - and big endian order + in lower ('b') or upper case ('B') hex characters. + + Where no additional specifiers are used the default little endian + order with lower case hex characters will be printed. + +struct va_format: + + %pV + + For printing struct va_format structures. These contain a format string + and va_list as follows: + + struct va_format { + const char *fmt; + va_list *va; + }; + + Do not use this feature without some mechanism to verify the + correctness of the format string and va_list arguments. u64 SHOULD be printed with %llu/%llx, (unsigned long long): @@ -32,4 +146,5 @@ Reminder: sizeof() result is of type size_t. Thank you for your cooperation and attention. -By Randy Dunlap <rdunlap@xenotime.net> +By Randy Dunlap <rdunlap@xenotime.net> and +Andrew Murray <amurray@mpc-data.co.uk> diff --git a/Documentation/rbtree.txt b/Documentation/rbtree.txt index 19f8278c3854..8d32d85a5234 100644 --- a/Documentation/rbtree.txt +++ b/Documentation/rbtree.txt @@ -196,15 +196,20 @@ Support for Augmented rbtrees Augmented rbtree is an rbtree with "some" additional data stored in each node. This data can be used to augment some new functionality to rbtree. Augmented rbtree is an optional feature built on top of basic rbtree -infrastructure. rbtree user who wants this feature will have an augment -callback function in rb_root initialized. - -This callback function will be called from rbtree core routines whenever -a node has a change in one or both of its children. It is the responsibility -of the callback function to recalculate the additional data that is in the -rb node using new children information. Note that if this new additional -data affects the parent node's additional data, then callback function has -to handle it and do the recursive updates. +infrastructure. An rbtree user who wants this feature will have to call the +augmentation functions with the user provided augmentation callback +when inserting and erasing nodes. + +On insertion, the user must call rb_augment_insert() once the new node is in +place. This will cause the augmentation function callback to be called for +each node between the new node and the root which has been affected by the +insertion. + +When erasing a node, the user must call rb_augment_erase_begin() first to +retrieve the deepest node on the rebalance path. Then, after erasing the +original node, the user must call rb_augment_erase_end() with the deepest +node found earlier. This will cause the augmentation function to be called +for each affected node between the deepest node and the root. Interval tree is an example of augmented rb tree. Reference - diff --git a/Documentation/s390/TAPE b/Documentation/s390/TAPE deleted file mode 100644 index c639aa5603ff..000000000000 --- a/Documentation/s390/TAPE +++ /dev/null @@ -1,122 +0,0 @@ -Channel attached Tape device driver - ------------------------------WARNING----------------------------------------- -This driver is considered to be EXPERIMENTAL. Do NOT use it in -production environments. Feel free to test it and report problems back to us. ------------------------------------------------------------------------------ - -The LINUX for zSeries tape device driver manages channel attached tape drives -which are compatible to IBM 3480 or IBM 3490 magnetic tape subsystems. This -includes various models of these devices (for example the 3490E). - - -Tape driver features - -The device driver supports a maximum of 128 tape devices. -No official LINUX device major number is assigned to the zSeries tape device -driver. It allocates major numbers dynamically and reports them on system -startup. -Typically it will get major number 254 for both the character device front-end -and the block device front-end. - -The tape device driver needs no kernel parameters. All supported devices -present are detected on driver initialization at system startup or module load. -The devices detected are ordered by their subchannel numbers. The device with -the lowest subchannel number becomes device 0, the next one will be device 1 -and so on. - - -Tape character device front-end - -The usual way to read or write to the tape device is through the character -device front-end. The zSeries tape device driver provides two character devices -for each physical device -- the first of these will rewind automatically when -it is closed, the second will not rewind automatically. - -The character device nodes are named /dev/rtibm0 (rewinding) and /dev/ntibm0 -(non-rewinding) for the first device, /dev/rtibm1 and /dev/ntibm1 for the -second, and so on. - -The character device front-end can be used as any other LINUX tape device. You -can write to it and read from it using LINUX facilities such as GNU tar. The -tool mt can be used to perform control operations, such as rewinding the tape -or skipping a file. - -Most LINUX tape software should work with either tape character device. - - -Tape block device front-end - -The tape device may also be accessed as a block device in read-only mode. -This could be used for software installation in the same way as it is used with -other operation systems on the zSeries platform (and most LINUX -distributions are shipped on compact disk using ISO9660 filesystems). - -One block device node is provided for each physical device. These are named -/dev/btibm0 for the first device, /dev/btibm1 for the second and so on. -You should only use the ISO9660 filesystem on LINUX for zSeries tapes because -the physical tape devices cannot perform fast seeks and the ISO9660 system is -optimized for this situation. - - -Tape block device example - -In this example a tape with an ISO9660 filesystem is created using the first -tape device. ISO9660 filesystem support must be built into your system kernel -for this. -The mt command is used to issue tape commands and the mkisofs command to -create an ISO9660 filesystem: - -- create a LINUX directory (somedir) with the contents of the filesystem - mkdir somedir - cp contents somedir - -- insert a tape - -- ensure the tape is at the beginning - mt -f /dev/ntibm0 rewind - -- set the blocksize of the character driver. The blocksize 2048 bytes - is commonly used on ISO9660 CD-Roms - mt -f /dev/ntibm0 setblk 2048 - -- write the filesystem to the character device driver - mkisofs -o /dev/ntibm0 somedir - -- rewind the tape again - mt -f /dev/ntibm0 rewind - -- Now you can mount your new filesystem as a block device: - mount -t iso9660 -o ro,block=2048 /dev/btibm0 /mnt - -TODO List - - - Driver has to be stabilized still - -BUGS - -This driver is considered BETA, which means some weaknesses may still -be in it. -If an error occurs which cannot be handled by the code you will get a -sense-data dump.In that case please do the following: - -1. set the tape driver debug level to maximum: - echo 6 >/proc/s390dbf/tape/level - -2. re-perform the actions which produced the bug. (Hopefully the bug will - reappear.) - -3. get a snapshot from the debug-feature: - cat /proc/s390dbf/tape/hex_ascii >somefile - -4. Now put the snapshot together with a detailed description of the situation - that led to the bug: - - Which tool did you use? - - Which hardware do you have? - - Was your tape unit online? - - Is it a shared tape unit? - -5. Send an email with your bug report to: - mailto:Linux390@de.ibm.com - - diff --git a/Documentation/scheduler/sched-arch.txt b/Documentation/scheduler/sched-arch.txt index d43dbcbd163b..28aa1075e291 100644 --- a/Documentation/scheduler/sched-arch.txt +++ b/Documentation/scheduler/sched-arch.txt @@ -66,7 +66,7 @@ Your cpu_idle routines need to obey the following rules: barrier issued (followed by a test of need_resched with interrupts disabled, as explained in 3). -arch/i386/kernel/process.c has examples of both polling and +arch/x86/kernel/process.c has examples of both polling and sleeping idle functions. diff --git a/Documentation/scheduler/sched-design-CFS.txt b/Documentation/scheduler/sched-design-CFS.txt index 99961993257a..91ecff07cede 100644 --- a/Documentation/scheduler/sched-design-CFS.txt +++ b/Documentation/scheduler/sched-design-CFS.txt @@ -223,9 +223,10 @@ When CONFIG_FAIR_GROUP_SCHED is defined, a "cpu.shares" file is created for each group created using the pseudo filesystem. See example steps below to create task groups and modify their CPU share using the "cgroups" pseudo filesystem. - # mkdir /dev/cpuctl - # mount -t cgroup -ocpu none /dev/cpuctl - # cd /dev/cpuctl + # mount -t tmpfs cgroup_root /sys/fs/cgroup + # mkdir /sys/fs/cgroup/cpu + # mount -t cgroup -ocpu none /sys/fs/cgroup/cpu + # cd /sys/fs/cgroup/cpu # mkdir multimedia # create "multimedia" group of tasks # mkdir browser # create "browser" group of tasks diff --git a/Documentation/scheduler/sched-rt-group.txt b/Documentation/scheduler/sched-rt-group.txt index 605b0d40329d..71b54d549987 100644 --- a/Documentation/scheduler/sched-rt-group.txt +++ b/Documentation/scheduler/sched-rt-group.txt @@ -129,9 +129,8 @@ priority! Enabling CONFIG_RT_GROUP_SCHED lets you explicitly allocate real CPU bandwidth to task groups. -This uses the /cgroup virtual file system and -"/cgroup/<cgroup>/cpu.rt_runtime_us" to control the CPU time reserved for each -control group. +This uses the cgroup virtual file system and "<cgroup>/cpu.rt_runtime_us" +to control the CPU time reserved for each control group. For more information on working with control groups, you should read Documentation/cgroups/cgroups.txt as well. @@ -150,7 +149,7 @@ For now, this can be simplified to just the following (but see Future plans): =============== There is work in progress to make the scheduling period for each group -("/cgroup/<cgroup>/cpu.rt_period_us") configurable as well. +("<cgroup>/cpu.rt_period_us") configurable as well. The constraint on the period is that a subgroup must have a smaller or equal period to its parent. But realistically its not very useful _yet_ diff --git a/Documentation/scsi/BusLogic.txt b/Documentation/scsi/BusLogic.txt index d7fbc9488b98..48e982cd6fe7 100644 --- a/Documentation/scsi/BusLogic.txt +++ b/Documentation/scsi/BusLogic.txt @@ -553,7 +553,7 @@ replacing "/usr/src" with wherever you keep your Linux kernel source tree: make config make zImage -Then install "arch/i386/boot/zImage" as your standard kernel, run lilo if +Then install "arch/x86/boot/zImage" as your standard kernel, run lilo if appropriate, and reboot. diff --git a/Documentation/serial/computone.txt b/Documentation/serial/computone.txt index c57ea4781e5d..60a6f657c37d 100644 --- a/Documentation/serial/computone.txt +++ b/Documentation/serial/computone.txt @@ -87,7 +87,7 @@ c) Set address on ISA cards then: edit /usr/src/linux/drivers/char/ip2.c (Optional - may be specified on kernel command line now) d) Run "make zImage" or whatever target you prefer. -e) mv /usr/src/linux/arch/i386/boot/zImage to /boot. +e) mv /usr/src/linux/arch/x86/boot/zImage to /boot. f) Add new config for this kernel into /etc/lilo.conf, run "lilo" or copy to a floppy disk and boot from that floppy disk. g) Reboot using this kernel diff --git a/Documentation/spi/ep93xx_spi b/Documentation/spi/ep93xx_spi index 6325f5b48635..d8eb01c15db1 100644 --- a/Documentation/spi/ep93xx_spi +++ b/Documentation/spi/ep93xx_spi @@ -88,6 +88,16 @@ static void __init ts72xx_init_machine(void) ARRAY_SIZE(ts72xx_spi_devices)); } +The driver can use DMA for the transfers also. In this case ts72xx_spi_info +becomes: + +static struct ep93xx_spi_info ts72xx_spi_info = { + .num_chipselect = ARRAY_SIZE(ts72xx_spi_devices), + .use_dma = true; +}; + +Note that CONFIG_EP93XX_DMA should be enabled as well. + Thanks to ========= Martin Guy, H. Hartley Sweeten and others who helped me during development of diff --git a/Documentation/spi/pxa2xx b/Documentation/spi/pxa2xx index 493dada57372..00511e08db78 100644 --- a/Documentation/spi/pxa2xx +++ b/Documentation/spi/pxa2xx @@ -22,15 +22,11 @@ Typically a SPI master is defined in the arch/.../mach-*/board-*.c as a found in include/linux/spi/pxa2xx_spi.h: struct pxa2xx_spi_master { - enum pxa_ssp_type ssp_type; u32 clock_enable; u16 num_chipselect; u8 enable_dma; }; -The "pxa2xx_spi_master.ssp_type" field must have a value between 1 and 3 and -informs the driver which features a particular SSP supports. - The "pxa2xx_spi_master.clock_enable" field is used to enable/disable the corresponding SSP peripheral block in the "Clock Enable Register (CKEN"). See the "PXA2xx Developer Manual" section "Clocks and Power Management". @@ -61,7 +57,6 @@ static struct resource pxa_spi_nssp_resources[] = { }; static struct pxa2xx_spi_master pxa_nssp_master_info = { - .ssp_type = PXA25x_NSSP, /* Type of SSP */ .clock_enable = CKEN_NSSP, /* NSSP Peripheral clock */ .num_chipselect = 1, /* Matches the number of chips attached to NSSP */ .enable_dma = 1, /* Enables NSSP DMA */ diff --git a/Documentation/spinlocks.txt b/Documentation/spinlocks.txt index 2e3c64b1a6a5..9dbe885ecd8d 100644 --- a/Documentation/spinlocks.txt +++ b/Documentation/spinlocks.txt @@ -13,18 +13,8 @@ static DEFINE_SPINLOCK(xxx_lock); The above is always safe. It will disable interrupts _locally_, but the spinlock itself will guarantee the global lock, so it will guarantee that there is only one thread-of-control within the region(s) protected by that -lock. This works well even under UP. The above sequence under UP -essentially is just the same as doing - - unsigned long flags; - - save_flags(flags); cli(); - ... critical section ... - restore_flags(flags); - -so the code does _not_ need to worry about UP vs SMP issues: the spinlocks -work correctly under both (and spinlocks are actually more efficient on -architectures that allow doing the "save_flags + cli" in one operation). +lock. This works well even under UP also, so the code does _not_ need to +worry about UP vs SMP issues: the spinlocks work correctly under both. NOTE! Implications of spin_locks for memory are further described in: @@ -36,27 +26,7 @@ The above is usually pretty simple (you usually need and want only one spinlock for most things - using more than one spinlock can make things a lot more complex and even slower and is usually worth it only for sequences that you _know_ need to be split up: avoid it at all cost if you -aren't sure). HOWEVER, it _does_ mean that if you have some code that does - - cli(); - .. critical section .. - sti(); - -and another sequence that does - - spin_lock_irqsave(flags); - .. critical section .. - spin_unlock_irqrestore(flags); - -then they are NOT mutually exclusive, and the critical regions can happen -at the same time on two different CPU's. That's fine per se, but the -critical regions had better be critical for different things (ie they -can't stomp on each other). - -The above is a problem mainly if you end up mixing code - for example the -routines in ll_rw_block() tend to use cli/sti to protect the atomicity of -their actions, and if a driver uses spinlocks instead then you should -think about issues like the above. +aren't sure). This is really the only really hard part about spinlocks: once you start using spinlocks they tend to expand to areas you might not have noticed @@ -120,11 +90,10 @@ Lesson 3: spinlocks revisited. The single spin-lock primitives above are by no means the only ones. They are the most safe ones, and the ones that work under all circumstances, -but partly _because_ they are safe they are also fairly slow. They are -much faster than a generic global cli/sti pair, but slower than they'd -need to be, because they do have to disable interrupts (which is just a -single instruction on a x86, but it's an expensive one - and on other -architectures it can be worse). +but partly _because_ they are safe they are also fairly slow. They are slower +than they'd need to be, because they do have to disable interrupts +(which is just a single instruction on a x86, but it's an expensive one - +and on other architectures it can be worse). If you have a case where you have to protect a data structure across several CPU's and you want to use spinlocks you can potentially use diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt index 5e7cb39ad195..704e474a93df 100644 --- a/Documentation/sysctl/kernel.txt +++ b/Documentation/sysctl/kernel.txt @@ -17,23 +17,21 @@ before actually making adjustments. Currently, these files might (depending on your configuration) show up in /proc/sys/kernel: -- acpi_video_flags + - acct +- acpi_video_flags +- auto_msgmni - bootloader_type [ X86 only ] - bootloader_version [ X86 only ] - callhome [ S390 only ] -- auto_msgmni - core_pattern - core_pipe_limit - core_uses_pid - ctrl-alt-del -- dentry-state - dmesg_restrict - domainname - hostname - hotplug -- java-appletviewer [ binfmt_java, obsolete ] -- java-interpreter [ binfmt_java, obsolete ] - kptr_restrict - kstack_depth_to_print [ X86 only ] - l2cr [ PPC only ] @@ -48,10 +46,14 @@ show up in /proc/sys/kernel: - overflowgid - overflowuid - panic +- panic_on_oops +- panic_on_unrecovered_nmi - pid_max - powersave-nap [ PPC only ] -- panic_on_unrecovered_nmi - printk +- printk_delay +- printk_ratelimit +- printk_ratelimit_burst - randomize_va_space - real-root-dev ==> Documentation/initrd.txt - reboot-cmd [ SPARC only ] @@ -59,9 +61,11 @@ show up in /proc/sys/kernel: - rtsig-nr - sem - sg-big-buff [ generic SCSI device (sg) ] +- shm_rmid_forced - shmall - shmmax [ sysv ipc ] - shmmni +- softlockup_thresh - stop-a [ SPARC only ] - sysrq ==> Documentation/sysrq.txt - tainted @@ -71,15 +75,6 @@ show up in /proc/sys/kernel: ============================================================== -acpi_video_flags: - -flags - -See Doc*/kernel/power/video.txt, it allows mode of video boot to be -set during run time. - -============================================================== - acct: highwater lowwater frequency @@ -97,6 +92,25 @@ valid for 30 seconds. ============================================================== +acpi_video_flags: + +flags + +See Doc*/kernel/power/video.txt, it allows mode of video boot to be +set during run time. + +============================================================== + +auto_msgmni: + +Enables/Disables automatic recomputing of msgmni upon memory add/remove +or upon ipc namespace creation/removal (see the msgmni description +above). Echoing "1" into this file enables msgmni automatic recomputing. +Echoing "0" turns it off. auto_msgmni default value is 1. + + +============================================================== + bootloader_type: x86 bootloader identification @@ -172,22 +186,24 @@ core_pattern is used to specify a core dumpfile pattern name. core_pipe_limit: -This sysctl is only applicable when core_pattern is configured to pipe core -files to a user space helper (when the first character of core_pattern is a '|', -see above). When collecting cores via a pipe to an application, it is -occasionally useful for the collecting application to gather data about the -crashing process from its /proc/pid directory. In order to do this safely, the -kernel must wait for the collecting process to exit, so as not to remove the -crashing processes proc files prematurely. This in turn creates the possibility -that a misbehaving userspace collecting process can block the reaping of a -crashed process simply by never exiting. This sysctl defends against that. It -defines how many concurrent crashing processes may be piped to user space -applications in parallel. If this value is exceeded, then those crashing -processes above that value are noted via the kernel log and their cores are -skipped. 0 is a special value, indicating that unlimited processes may be -captured in parallel, but that no waiting will take place (i.e. the collecting -process is not guaranteed access to /proc/<crashing pid>/). This value defaults -to 0. +This sysctl is only applicable when core_pattern is configured to pipe +core files to a user space helper (when the first character of +core_pattern is a '|', see above). When collecting cores via a pipe +to an application, it is occasionally useful for the collecting +application to gather data about the crashing process from its +/proc/pid directory. In order to do this safely, the kernel must wait +for the collecting process to exit, so as not to remove the crashing +processes proc files prematurely. This in turn creates the +possibility that a misbehaving userspace collecting process can block +the reaping of a crashed process simply by never exiting. This sysctl +defends against that. It defines how many concurrent crashing +processes may be piped to user space applications in parallel. If +this value is exceeded, then those crashing processes above that value +are noted via the kernel log and their cores are skipped. 0 is a +special value, indicating that unlimited processes may be captured in +parallel, but that no waiting will take place (i.e. the collecting +process is not guaranteed access to /proc/<crashing pid>/). This +value defaults to 0. ============================================================== @@ -218,14 +234,14 @@ to decide what to do with it. dmesg_restrict: -This toggle indicates whether unprivileged users are prevented from using -dmesg(8) to view messages from the kernel's log buffer. When -dmesg_restrict is set to (0) there are no restrictions. When +This toggle indicates whether unprivileged users are prevented +from using dmesg(8) to view messages from the kernel's log buffer. +When dmesg_restrict is set to (0) there are no restrictions. When dmesg_restrict is set set to (1), users must have CAP_SYSLOG to use dmesg(8). -The kernel config option CONFIG_SECURITY_DMESG_RESTRICT sets the default -value of dmesg_restrict. +The kernel config option CONFIG_SECURITY_DMESG_RESTRICT sets the +default value of dmesg_restrict. ============================================================== @@ -256,13 +272,6 @@ Default value is "/sbin/hotplug". ============================================================== -l2cr: (PPC only) - -This flag controls the L2 cache of G3 processor boards. If -0, the cache is disabled. Enabled if nonzero. - -============================================================== - kptr_restrict: This toggle indicates whether restrictions are placed on @@ -283,6 +292,13 @@ kernel stack. ============================================================== +l2cr: (PPC only) + +This flag controls the L2 cache of G3 processor boards. If +0, the cache is disabled. Enabled if nonzero. + +============================================================== + modules_disabled: A toggle value indicating if modules are allowed to be loaded @@ -293,6 +309,21 @@ to false. ============================================================== +nmi_watchdog: + +Enables/Disables the NMI watchdog on x86 systems. When the value is +non-zero the NMI watchdog is enabled and will continuously test all +online cpus to determine whether or not they are still functioning +properly. Currently, passing "nmi_watchdog=" parameter at boot time is +required for this function to work. + +If LAPIC NMI watchdog method is in use (nmi_watchdog=2 kernel +parameter), the NMI watchdog shares registers with oprofile. By +disabling the NMI watchdog, oprofile may have more registers to +utilize. + +============================================================== + osrelease, ostype & version: # cat osrelease @@ -312,10 +343,10 @@ The only way to tune these values is to rebuild the kernel :-) overflowgid & overflowuid: -if your architecture did not always support 32-bit UIDs (i.e. arm, i386, -m68k, sh, and sparc32), a fixed UID and GID will be returned to -applications that use the old 16-bit UID/GID system calls, if the actual -UID or GID would exceed 65535. +if your architecture did not always support 32-bit UIDs (i.e. arm, +i386, m68k, sh, and sparc32), a fixed UID and GID will be returned to +applications that use the old 16-bit UID/GID system calls, if the +actual UID or GID would exceed 65535. These sysctls allow you to change the value of the fixed UID and GID. The default is 65534. @@ -324,9 +355,22 @@ The default is 65534. panic: -The value in this file represents the number of seconds the -kernel waits before rebooting on a panic. When you use the -software watchdog, the recommended setting is 60. +The value in this file represents the number of seconds the kernel +waits before rebooting on a panic. When you use the software watchdog, +the recommended setting is 60. + +============================================================== + +panic_on_unrecovered_nmi: + +The default Linux behaviour on an NMI of either memory or unknown is +to continue operation. For many environments such as scientific +computing it is preferable that the box is taken out and the error +dealt with than an uncorrected parity/ECC error get propagated. + +A small number of systems do generate NMI's for bizarre random reasons +such as power management so the default is off. That sysctl works like +the existing panic controls already in that directory. ============================================================== @@ -376,6 +420,14 @@ the different loglevels. ============================================================== +printk_delay: + +Delay each printk message in printk_delay milliseconds + +Value from 0 - 10000 is allowed. + +============================================================== + printk_ratelimit: Some warning messages are rate limited. printk_ratelimit specifies @@ -395,15 +447,7 @@ send before ratelimiting kicks in. ============================================================== -printk_delay: - -Delay each printk message in printk_delay milliseconds - -Value from 0 - 10000 is allowed. - -============================================================== - -randomize-va-space: +randomize_va_space: This option can be used to select the type of process address space randomization that is used in the system, for architectures @@ -466,15 +510,36 @@ are doing anyway :) ============================================================== -shmmax: +shmmax: This value can be used to query and set the run time limit on the maximum shared memory segment size that can be created. -Shared memory segments up to 1Gb are now supported in the +Shared memory segments up to 1Gb are now supported in the kernel. This value defaults to SHMMAX. ============================================================== +shm_rmid_forced: + +Linux lets you set resource limits, including how much memory one +process can consume, via setrlimit(2). Unfortunately, shared memory +segments are allowed to exist without association with any process, and +thus might not be counted against any resource limits. If enabled, +shared memory segments are automatically destroyed when their attach +count becomes zero after a detach or a process termination. It will +also destroy segments that were created, but never attached to, on exit +from the process. The only use left for IPC_RMID is to immediately +destroy an unattached segment. Of course, this breaks the way things are +defined, so some applications might stop working. Note that this +feature will do you no good unless you also configure your resource +limits (in particular, RLIMIT_AS and RLIMIT_NPROC). Most systems don't +need this. + +Note that if you change this from 0 to 1, already created segments +without users and with a dead originative process will be destroyed. + +============================================================== + softlockup_thresh: This value can be used to lower the softlockup tolerance threshold. The @@ -484,7 +549,7 @@ tunable to zero will disable the softlockup detection altogether. ============================================================== -tainted: +tainted: Non-zero if the kernel has been tainted. Numeric values, which can be ORed together: @@ -509,49 +574,11 @@ can be ORed together: ============================================================== -auto_msgmni: - -Enables/Disables automatic recomputing of msgmni upon memory add/remove or -upon ipc namespace creation/removal (see the msgmni description above). -Echoing "1" into this file enables msgmni automatic recomputing. -Echoing "0" turns it off. -auto_msgmni default value is 1. - -============================================================== - -nmi_watchdog: - -Enables/Disables the NMI watchdog on x86 systems. When the value is non-zero -the NMI watchdog is enabled and will continuously test all online cpus to -determine whether or not they are still functioning properly. Currently, -passing "nmi_watchdog=" parameter at boot time is required for this function -to work. - -If LAPIC NMI watchdog method is in use (nmi_watchdog=2 kernel parameter), the -NMI watchdog shares registers with oprofile. By disabling the NMI watchdog, -oprofile may have more registers to utilize. - -============================================================== - unknown_nmi_panic: -The value in this file affects behavior of handling NMI. When the value is -non-zero, unknown NMI is trapped and then panic occurs. At that time, kernel -debugging information is displayed on console. - -NMI switch that most IA32 servers have fires unknown NMI up, for example. -If a system hangs up, try pressing the NMI switch. - -============================================================== - -panic_on_unrecovered_nmi: - -The default Linux behaviour on an NMI of either memory or unknown is to continue -operation. For many environments such as scientific computing it is preferable -that the box is taken out and the error dealt with than an uncorrected -parity/ECC error get propogated. - -A small number of systems do generate NMI's for bizarre random reasons such as -power management so the default is off. That sysctl works like the existing -panic controls already in that directory. +The value in this file affects behavior of handling NMI. When the +value is non-zero, unknown NMI is trapped and then panic occurs. At +that time, kernel debugging information is displayed on console. +NMI switch that most IA32 servers have fires unknown NMI up, for +example. If a system hangs up, try pressing the NMI switch. diff --git a/Documentation/trace/kprobetrace.txt b/Documentation/trace/kprobetrace.txt index c83bd6b4e6e8..d0d0bb9e3e25 100644 --- a/Documentation/trace/kprobetrace.txt +++ b/Documentation/trace/kprobetrace.txt @@ -22,14 +22,15 @@ current_tracer. Instead of that, add probe points via Synopsis of kprobe_events ------------------------- - p[:[GRP/]EVENT] SYMBOL[+offs]|MEMADDR [FETCHARGS] : Set a probe - r[:[GRP/]EVENT] SYMBOL[+0] [FETCHARGS] : Set a return probe + p[:[GRP/]EVENT] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS] : Set a probe + r[:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS] : Set a return probe -:[GRP/]EVENT : Clear a probe GRP : Group name. If omitted, use "kprobes" for it. EVENT : Event name. If omitted, the event name is generated - based on SYMBOL+offs or MEMADDR. - SYMBOL[+offs] : Symbol+offset where the probe is inserted. + based on SYM+offs or MEMADDR. + MOD : Module name which has given SYM. + SYM[+offs] : Symbol+offset where the probe is inserted. MEMADDR : Address where the probe is inserted. FETCHARGS : Arguments. Each probe can have up to 128 args. diff --git a/Documentation/usb/ehci.txt b/Documentation/usb/ehci.txt index 9dcafa7d930d..160bd6c3ab7b 100644 --- a/Documentation/usb/ehci.txt +++ b/Documentation/usb/ehci.txt @@ -210,3 +210,5 @@ TBD: Interrupt and ISO transfer performance issues. Those periodic transfers are fully scheduled, so the main issue is likely to be how to trigger "high bandwidth" modes. +TBD: More than standard 80% periodic bandwidth allocation is possible +through sysfs uframe_periodic_max parameter. Describe that. diff --git a/Documentation/usb/error-codes.txt b/Documentation/usb/error-codes.txt index d83703ea74b2..b3f606b81a03 100644 --- a/Documentation/usb/error-codes.txt +++ b/Documentation/usb/error-codes.txt @@ -76,6 +76,13 @@ A transfer's actual_length may be positive even when an error has been reported. That's because transfers often involve several packets, so that one or more packets could finish before an error stops further endpoint I/O. +For isochronous URBs, the urb status value is non-zero only if the URB is +unlinked, the device is removed, the host controller is disabled, or the total +transferred length is less than the requested length and the URB_SHORT_NOT_OK +flag is set. Completion handlers for isochronous URBs should only see +urb->status set to zero, -ENOENT, -ECONNRESET, -ESHUTDOWN, or -EREMOTEIO. +Individual frame descriptor status fields may report more status codes. + 0 Transfer completed successfully @@ -132,7 +139,7 @@ one or more packets could finish before an error stops further endpoint I/O. device removal events immediately. -EXDEV ISO transfer only partially completed - look at individual frame status for details + (only set in iso_frame_desc[n].status, not urb->status) -EINVAL ISO madness, if this happens: Log off and go home diff --git a/Documentation/usb/gadget_hid.txt b/Documentation/usb/gadget_hid.txt index f4a51f567427..12696c2e43fb 100644 --- a/Documentation/usb/gadget_hid.txt +++ b/Documentation/usb/gadget_hid.txt @@ -81,8 +81,8 @@ Send and receive HID reports to do this. hid_gadget_test is a small interactive program to test the HID - gadget driver. To use, point it at a hidg device and set the - device type (keyboard / mouse / joystick) - E.G.: + gadget driver. To use, point it at a hidg device and set the + device type (keyboard / mouse / joystick) - E.G.: # hid_gadget_test /dev/hidg0 keyboard @@ -97,7 +97,7 @@ Send and receive HID reports HID gadget. Another interesting example is the caps lock test. Type - -鈥揷aps-lock and hit return. A report is then sent by the + --caps-lock and hit return. A report is then sent by the gadget and you should receive the host answer, corresponding to the caps lock LED status. diff --git a/Documentation/vDSO/parse_vdso.c b/Documentation/vDSO/parse_vdso.c new file mode 100644 index 000000000000..85870208edcf --- /dev/null +++ b/Documentation/vDSO/parse_vdso.c @@ -0,0 +1,256 @@ +/* + * parse_vdso.c: Linux reference vDSO parser + * Written by Andrew Lutomirski, 2011. + * + * This code is meant to be linked in to various programs that run on Linux. + * As such, it is available with as few restrictions as possible. This file + * is licensed under the Creative Commons Zero License, version 1.0, + * available at http://creativecommons.org/publicdomain/zero/1.0/legalcode + * + * The vDSO is a regular ELF DSO that the kernel maps into user space when + * it starts a program. It works equally well in statically and dynamically + * linked binaries. + * + * This code is tested on x86_64. In principle it should work on any 64-bit + * architecture that has a vDSO. + */ + +#include <stdbool.h> +#include <stdint.h> +#include <string.h> +#include <elf.h> + +/* + * To use this vDSO parser, first call one of the vdso_init_* functions. + * If you've already parsed auxv, then pass the value of AT_SYSINFO_EHDR + * to vdso_init_from_sysinfo_ehdr. Otherwise pass auxv to vdso_init_from_auxv. + * Then call vdso_sym for each symbol you want. For example, to look up + * gettimeofday on x86_64, use: + * + * <some pointer> = vdso_sym("LINUX_2.6", "gettimeofday"); + * or + * <some pointer> = vdso_sym("LINUX_2.6", "__vdso_gettimeofday"); + * + * vdso_sym will return 0 if the symbol doesn't exist or if the init function + * failed or was not called. vdso_sym is a little slow, so its return value + * should be cached. + * + * vdso_sym is threadsafe; the init functions are not. + * + * These are the prototypes: + */ +extern void vdso_init_from_auxv(void *auxv); +extern void vdso_init_from_sysinfo_ehdr(uintptr_t base); +extern void *vdso_sym(const char *version, const char *name); + + +/* And here's the code. */ + +#ifndef __x86_64__ +# error Not yet ported to non-x86_64 architectures +#endif + +static struct vdso_info +{ + bool valid; + + /* Load information */ + uintptr_t load_addr; + uintptr_t load_offset; /* load_addr - recorded vaddr */ + + /* Symbol table */ + Elf64_Sym *symtab; + const char *symstrings; + Elf64_Word *bucket, *chain; + Elf64_Word nbucket, nchain; + + /* Version table */ + Elf64_Versym *versym; + Elf64_Verdef *verdef; +} vdso_info; + +/* Straight from the ELF specification. */ +static unsigned long elf_hash(const unsigned char *name) +{ + unsigned long h = 0, g; + while (*name) + { + h = (h << 4) + *name++; + if (g = h & 0xf0000000) + h ^= g >> 24; + h &= ~g; + } + return h; +} + +void vdso_init_from_sysinfo_ehdr(uintptr_t base) +{ + size_t i; + bool found_vaddr = false; + + vdso_info.valid = false; + + vdso_info.load_addr = base; + + Elf64_Ehdr *hdr = (Elf64_Ehdr*)base; + Elf64_Phdr *pt = (Elf64_Phdr*)(vdso_info.load_addr + hdr->e_phoff); + Elf64_Dyn *dyn = 0; + + /* + * We need two things from the segment table: the load offset + * and the dynamic table. + */ + for (i = 0; i < hdr->e_phnum; i++) + { + if (pt[i].p_type == PT_LOAD && !found_vaddr) { + found_vaddr = true; + vdso_info.load_offset = base + + (uintptr_t)pt[i].p_offset + - (uintptr_t)pt[i].p_vaddr; + } else if (pt[i].p_type == PT_DYNAMIC) { + dyn = (Elf64_Dyn*)(base + pt[i].p_offset); + } + } + + if (!found_vaddr || !dyn) + return; /* Failed */ + + /* + * Fish out the useful bits of the dynamic table. + */ + Elf64_Word *hash = 0; + vdso_info.symstrings = 0; + vdso_info.symtab = 0; + vdso_info.versym = 0; + vdso_info.verdef = 0; + for (i = 0; dyn[i].d_tag != DT_NULL; i++) { + switch (dyn[i].d_tag) { + case DT_STRTAB: + vdso_info.symstrings = (const char *) + ((uintptr_t)dyn[i].d_un.d_ptr + + vdso_info.load_offset); + break; + case DT_SYMTAB: + vdso_info.symtab = (Elf64_Sym *) + ((uintptr_t)dyn[i].d_un.d_ptr + + vdso_info.load_offset); + break; + case DT_HASH: + hash = (Elf64_Word *) + ((uintptr_t)dyn[i].d_un.d_ptr + + vdso_info.load_offset); + break; + case DT_VERSYM: + vdso_info.versym = (Elf64_Versym *) + ((uintptr_t)dyn[i].d_un.d_ptr + + vdso_info.load_offset); + break; + case DT_VERDEF: + vdso_info.verdef = (Elf64_Verdef *) + ((uintptr_t)dyn[i].d_un.d_ptr + + vdso_info.load_offset); + break; + } + } + if (!vdso_info.symstrings || !vdso_info.symtab || !hash) + return; /* Failed */ + + if (!vdso_info.verdef) + vdso_info.versym = 0; + + /* Parse the hash table header. */ + vdso_info.nbucket = hash[0]; + vdso_info.nchain = hash[1]; + vdso_info.bucket = &hash[2]; + vdso_info.chain = &hash[vdso_info.nbucket + 2]; + + /* That's all we need. */ + vdso_info.valid = true; +} + +static bool vdso_match_version(Elf64_Versym ver, + const char *name, Elf64_Word hash) +{ + /* + * This is a helper function to check if the version indexed by + * ver matches name (which hashes to hash). + * + * The version definition table is a mess, and I don't know how + * to do this in better than linear time without allocating memory + * to build an index. I also don't know why the table has + * variable size entries in the first place. + * + * For added fun, I can't find a comprehensible specification of how + * to parse all the weird flags in the table. + * + * So I just parse the whole table every time. + */ + + /* First step: find the version definition */ + ver &= 0x7fff; /* Apparently bit 15 means "hidden" */ + Elf64_Verdef *def = vdso_info.verdef; + while(true) { + if ((def->vd_flags & VER_FLG_BASE) == 0 + && (def->vd_ndx & 0x7fff) == ver) + break; + + if (def->vd_next == 0) + return false; /* No definition. */ + + def = (Elf64_Verdef *)((char *)def + def->vd_next); + } + + /* Now figure out whether it matches. */ + Elf64_Verdaux *aux = (Elf64_Verdaux*)((char *)def + def->vd_aux); + return def->vd_hash == hash + && !strcmp(name, vdso_info.symstrings + aux->vda_name); +} + +void *vdso_sym(const char *version, const char *name) +{ + unsigned long ver_hash; + if (!vdso_info.valid) + return 0; + + ver_hash = elf_hash(version); + Elf64_Word chain = vdso_info.bucket[elf_hash(name) % vdso_info.nbucket]; + + for (; chain != STN_UNDEF; chain = vdso_info.chain[chain]) { + Elf64_Sym *sym = &vdso_info.symtab[chain]; + + /* Check for a defined global or weak function w/ right name. */ + if (ELF64_ST_TYPE(sym->st_info) != STT_FUNC) + continue; + if (ELF64_ST_BIND(sym->st_info) != STB_GLOBAL && + ELF64_ST_BIND(sym->st_info) != STB_WEAK) + continue; + if (sym->st_shndx == SHN_UNDEF) + continue; + if (strcmp(name, vdso_info.symstrings + sym->st_name)) + continue; + + /* Check symbol version. */ + if (vdso_info.versym + && !vdso_match_version(vdso_info.versym[chain], + version, ver_hash)) + continue; + + return (void *)(vdso_info.load_offset + sym->st_value); + } + + return 0; +} + +void vdso_init_from_auxv(void *auxv) +{ + Elf64_auxv_t *elf_auxv = auxv; + for (int i = 0; elf_auxv[i].a_type != AT_NULL; i++) + { + if (elf_auxv[i].a_type == AT_SYSINFO_EHDR) { + vdso_init_from_sysinfo_ehdr(elf_auxv[i].a_un.a_val); + return; + } + } + + vdso_info.valid = false; +} diff --git a/Documentation/vDSO/vdso_test.c b/Documentation/vDSO/vdso_test.c new file mode 100644 index 000000000000..fff633432dff --- /dev/null +++ b/Documentation/vDSO/vdso_test.c @@ -0,0 +1,111 @@ +/* + * vdso_test.c: Sample code to test parse_vdso.c on x86_64 + * Copyright (c) 2011 Andy Lutomirski + * Subject to the GNU General Public License, version 2 + * + * You can amuse yourself by compiling with: + * gcc -std=gnu99 -nostdlib + * -Os -fno-asynchronous-unwind-tables -flto + * vdso_test.c parse_vdso.c -o vdso_test + * to generate a small binary with no dependencies at all. + */ + +#include <sys/syscall.h> +#include <sys/time.h> +#include <unistd.h> +#include <stdint.h> + +extern void *vdso_sym(const char *version, const char *name); +extern void vdso_init_from_sysinfo_ehdr(uintptr_t base); +extern void vdso_init_from_auxv(void *auxv); + +/* We need a libc functions... */ +int strcmp(const char *a, const char *b) +{ + /* This implementation is buggy: it never returns -1. */ + while (*a || *b) { + if (*a != *b) + return 1; + if (*a == 0 || *b == 0) + return 1; + a++; + b++; + } + + return 0; +} + +/* ...and two syscalls. This is x86_64-specific. */ +static inline long linux_write(int fd, const void *data, size_t len) +{ + + long ret; + asm volatile ("syscall" : "=a" (ret) : "a" (__NR_write), + "D" (fd), "S" (data), "d" (len) : + "cc", "memory", "rcx", + "r8", "r9", "r10", "r11" ); + return ret; +} + +static inline void linux_exit(int code) +{ + asm volatile ("syscall" : : "a" (__NR_exit), "D" (code)); +} + +void to_base10(char *lastdig, uint64_t n) +{ + while (n) { + *lastdig = (n % 10) + '0'; + n /= 10; + lastdig--; + } +} + +__attribute__((externally_visible)) void c_main(void **stack) +{ + /* Parse the stack */ + long argc = (long)*stack; + stack += argc + 2; + + /* Now we're pointing at the environment. Skip it. */ + while(*stack) + stack++; + stack++; + + /* Now we're pointing at auxv. Initialize the vDSO parser. */ + vdso_init_from_auxv((void *)stack); + + /* Find gettimeofday. */ + typedef long (*gtod_t)(struct timeval *tv, struct timezone *tz); + gtod_t gtod = (gtod_t)vdso_sym("LINUX_2.6", "__vdso_gettimeofday"); + + if (!gtod) + linux_exit(1); + + struct timeval tv; + long ret = gtod(&tv, 0); + + if (ret == 0) { + char buf[] = "The time is .000000\n"; + to_base10(buf + 31, tv.tv_sec); + to_base10(buf + 38, tv.tv_usec); + linux_write(1, buf, sizeof(buf) - 1); + } else { + linux_exit(ret); + } + + linux_exit(0); +} + +/* + * This is the real entry point. It passes the initial stack into + * the C entry point. + */ +asm ( + ".text\n" + ".global _start\n" + ".type _start,@function\n" + "_start:\n\t" + "mov %rsp,%rdi\n\t" + "jmp c_main" + ); diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt index 42542eb802ca..b0e4b9cd6a66 100644 --- a/Documentation/virtual/kvm/api.txt +++ b/Documentation/virtual/kvm/api.txt @@ -180,6 +180,19 @@ KVM_CHECK_EXTENSION ioctl() to determine the value for max_vcpus at run-time. If the KVM_CAP_NR_VCPUS does not exist, you should assume that max_vcpus is 4 cpus max. +On powerpc using book3s_hv mode, the vcpus are mapped onto virtual +threads in one or more virtual CPU cores. (This is because the +hardware requires all the hardware threads in a CPU core to be in the +same partition.) The KVM_CAP_PPC_SMT capability indicates the number +of vcpus per virtual core (vcore). The vcore id is obtained by +dividing the vcpu id by the number of vcpus per vcore. The vcpus in a +given vcore will always be in the same physical core as each other +(though that might be a different physical core from time to time). +Userspace can control the threading (SMT) mode of the guest by its +allocation of vcpu ids. For example, if userspace wants +single-threaded guest vcpus, it should make all vcpu ids be a multiple +of the number of vcpus per vcore. + 4.8 KVM_GET_DIRTY_LOG (vm ioctl) Capability: basic @@ -1143,15 +1156,10 @@ Assigns an IRQ to a passed-through device. struct kvm_assigned_irq { __u32 assigned_dev_id; - __u32 host_irq; + __u32 host_irq; /* ignored (legacy field) */ __u32 guest_irq; __u32 flags; union { - struct { - __u32 addr_lo; - __u32 addr_hi; - __u32 data; - } guest_msi; __u32 reserved[12]; }; }; @@ -1239,8 +1247,10 @@ Type: vm ioctl Parameters: struct kvm_assigned_msix_nr (in) Returns: 0 on success, -1 on error -Set the number of MSI-X interrupts for an assigned device. This service can -only be called once in the lifetime of an assigned device. +Set the number of MSI-X interrupts for an assigned device. The number is +reset again by terminating the MSI-X assignment of the device via +KVM_DEASSIGN_DEV_IRQ. Calling this service more than once at any earlier +point will fail. struct kvm_assigned_msix_nr { __u32 assigned_dev_id; @@ -1291,6 +1301,135 @@ Returns the tsc frequency of the guest. The unit of the return value is KHz. If the host has unstable tsc this ioctl returns -EIO instead as an error. +4.56 KVM_GET_LAPIC + +Capability: KVM_CAP_IRQCHIP +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_lapic_state (out) +Returns: 0 on success, -1 on error + +#define KVM_APIC_REG_SIZE 0x400 +struct kvm_lapic_state { + char regs[KVM_APIC_REG_SIZE]; +}; + +Reads the Local APIC registers and copies them into the input argument. The +data format and layout are the same as documented in the architecture manual. + +4.57 KVM_SET_LAPIC + +Capability: KVM_CAP_IRQCHIP +Architectures: x86 +Type: vcpu ioctl +Parameters: struct kvm_lapic_state (in) +Returns: 0 on success, -1 on error + +#define KVM_APIC_REG_SIZE 0x400 +struct kvm_lapic_state { + char regs[KVM_APIC_REG_SIZE]; +}; + +Copies the input argument into the the Local APIC registers. The data format +and layout are the same as documented in the architecture manual. + +4.58 KVM_IOEVENTFD + +Capability: KVM_CAP_IOEVENTFD +Architectures: all +Type: vm ioctl +Parameters: struct kvm_ioeventfd (in) +Returns: 0 on success, !0 on error + +This ioctl attaches or detaches an ioeventfd to a legal pio/mmio address +within the guest. A guest write in the registered address will signal the +provided event instead of triggering an exit. + +struct kvm_ioeventfd { + __u64 datamatch; + __u64 addr; /* legal pio/mmio address */ + __u32 len; /* 1, 2, 4, or 8 bytes */ + __s32 fd; + __u32 flags; + __u8 pad[36]; +}; + +The following flags are defined: + +#define KVM_IOEVENTFD_FLAG_DATAMATCH (1 << kvm_ioeventfd_flag_nr_datamatch) +#define KVM_IOEVENTFD_FLAG_PIO (1 << kvm_ioeventfd_flag_nr_pio) +#define KVM_IOEVENTFD_FLAG_DEASSIGN (1 << kvm_ioeventfd_flag_nr_deassign) + +If datamatch flag is set, the event will be signaled only if the written value +to the registered address is equal to datamatch in struct kvm_ioeventfd. + +4.62 KVM_CREATE_SPAPR_TCE + +Capability: KVM_CAP_SPAPR_TCE +Architectures: powerpc +Type: vm ioctl +Parameters: struct kvm_create_spapr_tce (in) +Returns: file descriptor for manipulating the created TCE table + +This creates a virtual TCE (translation control entry) table, which +is an IOMMU for PAPR-style virtual I/O. It is used to translate +logical addresses used in virtual I/O into guest physical addresses, +and provides a scatter/gather capability for PAPR virtual I/O. + +/* for KVM_CAP_SPAPR_TCE */ +struct kvm_create_spapr_tce { + __u64 liobn; + __u32 window_size; +}; + +The liobn field gives the logical IO bus number for which to create a +TCE table. The window_size field specifies the size of the DMA window +which this TCE table will translate - the table will contain one 64 +bit TCE entry for every 4kiB of the DMA window. + +When the guest issues an H_PUT_TCE hcall on a liobn for which a TCE +table has been created using this ioctl(), the kernel will handle it +in real mode, updating the TCE table. H_PUT_TCE calls for other +liobns will cause a vm exit and must be handled by userspace. + +The return value is a file descriptor which can be passed to mmap(2) +to map the created TCE table into userspace. This lets userspace read +the entries written by kernel-handled H_PUT_TCE calls, and also lets +userspace update the TCE table directly which is useful in some +circumstances. + +4.63 KVM_ALLOCATE_RMA + +Capability: KVM_CAP_PPC_RMA +Architectures: powerpc +Type: vm ioctl +Parameters: struct kvm_allocate_rma (out) +Returns: file descriptor for mapping the allocated RMA + +This allocates a Real Mode Area (RMA) from the pool allocated at boot +time by the kernel. An RMA is a physically-contiguous, aligned region +of memory used on older POWER processors to provide the memory which +will be accessed by real-mode (MMU off) accesses in a KVM guest. +POWER processors support a set of sizes for the RMA that usually +includes 64MB, 128MB, 256MB and some larger powers of two. + +/* for KVM_ALLOCATE_RMA */ +struct kvm_allocate_rma { + __u64 rma_size; +}; + +The return value is a file descriptor which can be passed to mmap(2) +to map the allocated RMA into userspace. The mapped area can then be +passed to the KVM_SET_USER_MEMORY_REGION ioctl to establish it as the +RMA for a virtual machine. The size of the RMA in bytes (which is +fixed at host kernel boot time) is returned in the rma_size field of +the argument structure. + +The KVM_CAP_PPC_RMA capability is 1 or 2 if the KVM_ALLOCATE_RMA ioctl +is supported; 2 if the processor requires all virtual machines to have +an RMA, or 1 if the processor can use an RMA but doesn't require it, +because it supports the Virtual RMA (VRMA) facility. + 5. The kvm_run structure Application code obtains a pointer to the kvm_run structure by @@ -1473,6 +1612,23 @@ Userspace can now handle the hypercall and when it's done modify the gprs as necessary. Upon guest entry all guest GPRs will then be replaced by the values in this struct. + /* KVM_EXIT_PAPR_HCALL */ + struct { + __u64 nr; + __u64 ret; + __u64 args[9]; + } papr_hcall; + +This is used on 64-bit PowerPC when emulating a pSeries partition, +e.g. with the 'pseries' machine type in qemu. It occurs when the +guest does a hypercall using the 'sc 1' instruction. The 'nr' field +contains the hypercall number (from the guest R3), and 'args' contains +the arguments (from the guest R4 - R12). Userspace should put the +return code in 'ret' and any extra returned values in args[]. +The possible hypercalls are defined in the Power Architecture Platform +Requirements (PAPR) document available from www.power.org (free +developer registration required to access it). + /* Fix the size of the union. */ char padding[256]; }; diff --git a/Documentation/virtual/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt index f46aa58389ca..5dc972c09b55 100644 --- a/Documentation/virtual/kvm/mmu.txt +++ b/Documentation/virtual/kvm/mmu.txt @@ -165,6 +165,10 @@ Shadow pages contain the following information: Contains the value of efer.nxe for which the page is valid. role.cr0_wp: Contains the value of cr0.wp for which the page is valid. + role.smep_andnot_wp: + Contains the value of cr4.smep && !cr0.wp for which the page is valid + (pages for which this is true are different from other pages; see the + treatment of cr0.wp=0 below). gfn: Either the guest page table containing the translations shadowed by this page, or the base page frame for linear translations. See role.direct. @@ -317,6 +321,20 @@ on fault type: (user write faults generate a #PF) +In the first case there is an additional complication if CR4.SMEP is +enabled: since we've turned the page into a kernel page, the kernel may now +execute it. We handle this by also setting spte.nx. If we get a user +fetch or read fault, we'll change spte.u=1 and spte.nx=gpte.nx back. + +To prevent an spte that was converted into a kernel page with cr0.wp=0 +from being written by the kernel after cr0.wp has changed to 1, we make +the value of cr0.wp part of the page role. This means that an spte created +with one value of cr0.wp cannot be used when cr0.wp has a different value - +it will simply be missed by the shadow page lookup code. A similar issue +exists when an spte created with cr0.wp=0 and cr4.smep=0 is used after +changing cr4.smep to 1. To avoid this, the value of !cr0.wp && cr4.smep +is also made a part of the page role. + Large pages =========== diff --git a/Documentation/virtual/kvm/msr.txt b/Documentation/virtual/kvm/msr.txt index d079aed27e03..50317809113d 100644 --- a/Documentation/virtual/kvm/msr.txt +++ b/Documentation/virtual/kvm/msr.txt @@ -185,3 +185,37 @@ MSR_KVM_ASYNC_PF_EN: 0x4b564d02 Currently type 2 APF will be always delivered on the same vcpu as type 1 was, but guest should not rely on that. + +MSR_KVM_STEAL_TIME: 0x4b564d03 + + data: 64-byte alignment physical address of a memory area which must be + in guest RAM, plus an enable bit in bit 0. This memory is expected to + hold a copy of the following structure: + + struct kvm_steal_time { + __u64 steal; + __u32 version; + __u32 flags; + __u32 pad[12]; + } + + whose data will be filled in by the hypervisor periodically. Only one + write, or registration, is needed for each VCPU. The interval between + updates of this structure is arbitrary and implementation-dependent. + The hypervisor may update this structure at any time it sees fit until + anything with bit0 == 0 is written to it. Guest is required to make sure + this structure is initialized to zero. + + Fields have the following meanings: + + version: a sequence counter. In other words, guest has to check + this field before and after grabbing time information and make + sure they are both equal and even. An odd version indicates an + in-progress update. + + flags: At this point, always zero. May be used to indicate + changes in this structure in the future. + + steal: the amount of time in which this vCPU did not run, in + nanoseconds. Time during which the vcpu is idle, will not be + reported as steal time. diff --git a/Documentation/virtual/kvm/nested-vmx.txt b/Documentation/virtual/kvm/nested-vmx.txt new file mode 100644 index 000000000000..8ed937de1163 --- /dev/null +++ b/Documentation/virtual/kvm/nested-vmx.txt @@ -0,0 +1,251 @@ +Nested VMX +========== + +Overview +--------- + +On Intel processors, KVM uses Intel's VMX (Virtual-Machine eXtensions) +to easily and efficiently run guest operating systems. Normally, these guests +*cannot* themselves be hypervisors running their own guests, because in VMX, +guests cannot use VMX instructions. + +The "Nested VMX" feature adds this missing capability - of running guest +hypervisors (which use VMX) with their own nested guests. It does so by +allowing a guest to use VMX instructions, and correctly and efficiently +emulating them using the single level of VMX available in the hardware. + +We describe in much greater detail the theory behind the nested VMX feature, +its implementation and its performance characteristics, in the OSDI 2010 paper +"The Turtles Project: Design and Implementation of Nested Virtualization", +available at: + + http://www.usenix.org/events/osdi10/tech/full_papers/Ben-Yehuda.pdf + + +Terminology +----------- + +Single-level virtualization has two levels - the host (KVM) and the guests. +In nested virtualization, we have three levels: The host (KVM), which we call +L0, the guest hypervisor, which we call L1, and its nested guest, which we +call L2. + + +Known limitations +----------------- + +The current code supports running Linux guests under KVM guests. +Only 64-bit guest hypervisors are supported. + +Additional patches for running Windows under guest KVM, and Linux under +guest VMware server, and support for nested EPT, are currently running in +the lab, and will be sent as follow-on patchsets. + + +Running nested VMX +------------------ + +The nested VMX feature is disabled by default. It can be enabled by giving +the "nested=1" option to the kvm-intel module. + +No modifications are required to user space (qemu). However, qemu's default +emulated CPU type (qemu64) does not list the "VMX" CPU feature, so it must be +explicitly enabled, by giving qemu one of the following options: + + -cpu host (emulated CPU has all features of the real CPU) + + -cpu qemu64,+vmx (add just the vmx feature to a named CPU type) + + +ABIs +---- + +Nested VMX aims to present a standard and (eventually) fully-functional VMX +implementation for the a guest hypervisor to use. As such, the official +specification of the ABI that it provides is Intel's VMX specification, +namely volume 3B of their "Intel 64 and IA-32 Architectures Software +Developer's Manual". Not all of VMX's features are currently fully supported, +but the goal is to eventually support them all, starting with the VMX features +which are used in practice by popular hypervisors (KVM and others). + +As a VMX implementation, nested VMX presents a VMCS structure to L1. +As mandated by the spec, other than the two fields revision_id and abort, +this structure is *opaque* to its user, who is not supposed to know or care +about its internal structure. Rather, the structure is accessed through the +VMREAD and VMWRITE instructions. +Still, for debugging purposes, KVM developers might be interested to know the +internals of this structure; This is struct vmcs12 from arch/x86/kvm/vmx.c. + +The name "vmcs12" refers to the VMCS that L1 builds for L2. In the code we +also have "vmcs01", the VMCS that L0 built for L1, and "vmcs02" is the VMCS +which L0 builds to actually run L2 - how this is done is explained in the +aforementioned paper. + +For convenience, we repeat the content of struct vmcs12 here. If the internals +of this structure changes, this can break live migration across KVM versions. +VMCS12_REVISION (from vmx.c) should be changed if struct vmcs12 or its inner +struct shadow_vmcs is ever changed. + + typedef u64 natural_width; + struct __packed vmcs12 { + /* According to the Intel spec, a VMCS region must start with + * these two user-visible fields */ + u32 revision_id; + u32 abort; + + u32 launch_state; /* set to 0 by VMCLEAR, to 1 by VMLAUNCH */ + u32 padding[7]; /* room for future expansion */ + + u64 io_bitmap_a; + u64 io_bitmap_b; + u64 msr_bitmap; + u64 vm_exit_msr_store_addr; + u64 vm_exit_msr_load_addr; + u64 vm_entry_msr_load_addr; + u64 tsc_offset; + u64 virtual_apic_page_addr; + u64 apic_access_addr; + u64 ept_pointer; + u64 guest_physical_address; + u64 vmcs_link_pointer; + u64 guest_ia32_debugctl; + u64 guest_ia32_pat; + u64 guest_ia32_efer; + u64 guest_pdptr0; + u64 guest_pdptr1; + u64 guest_pdptr2; + u64 guest_pdptr3; + u64 host_ia32_pat; + u64 host_ia32_efer; + u64 padding64[8]; /* room for future expansion */ + natural_width cr0_guest_host_mask; + natural_width cr4_guest_host_mask; + natural_width cr0_read_shadow; + natural_width cr4_read_shadow; + natural_width cr3_target_value0; + natural_width cr3_target_value1; + natural_width cr3_target_value2; + natural_width cr3_target_value3; + natural_width exit_qualification; + natural_width guest_linear_address; + natural_width guest_cr0; + natural_width guest_cr3; + natural_width guest_cr4; + natural_width guest_es_base; + natural_width guest_cs_base; + natural_width guest_ss_base; + natural_width guest_ds_base; + natural_width guest_fs_base; + natural_width guest_gs_base; + natural_width guest_ldtr_base; + natural_width guest_tr_base; + natural_width guest_gdtr_base; + natural_width guest_idtr_base; + natural_width guest_dr7; + natural_width guest_rsp; + natural_width guest_rip; + natural_width guest_rflags; + natural_width guest_pending_dbg_exceptions; + natural_width guest_sysenter_esp; + natural_width guest_sysenter_eip; + natural_width host_cr0; + natural_width host_cr3; + natural_width host_cr4; + natural_width host_fs_base; + natural_width host_gs_base; + natural_width host_tr_base; + natural_width host_gdtr_base; + natural_width host_idtr_base; + natural_width host_ia32_sysenter_esp; + natural_width host_ia32_sysenter_eip; + natural_width host_rsp; + natural_width host_rip; + natural_width paddingl[8]; /* room for future expansion */ + u32 pin_based_vm_exec_control; + u32 cpu_based_vm_exec_control; + u32 exception_bitmap; + u32 page_fault_error_code_mask; + u32 page_fault_error_code_match; + u32 cr3_target_count; + u32 vm_exit_controls; + u32 vm_exit_msr_store_count; + u32 vm_exit_msr_load_count; + u32 vm_entry_controls; + u32 vm_entry_msr_load_count; + u32 vm_entry_intr_info_field; + u32 vm_entry_exception_error_code; + u32 vm_entry_instruction_len; + u32 tpr_threshold; + u32 secondary_vm_exec_control; + u32 vm_instruction_error; + u32 vm_exit_reason; + u32 vm_exit_intr_info; + u32 vm_exit_intr_error_code; + u32 idt_vectoring_info_field; + u32 idt_vectoring_error_code; + u32 vm_exit_instruction_len; + u32 vmx_instruction_info; + u32 guest_es_limit; + u32 guest_cs_limit; + u32 guest_ss_limit; + u32 guest_ds_limit; + u32 guest_fs_limit; + u32 guest_gs_limit; + u32 guest_ldtr_limit; + u32 guest_tr_limit; + u32 guest_gdtr_limit; + u32 guest_idtr_limit; + u32 guest_es_ar_bytes; + u32 guest_cs_ar_bytes; + u32 guest_ss_ar_bytes; + u32 guest_ds_ar_bytes; + u32 guest_fs_ar_bytes; + u32 guest_gs_ar_bytes; + u32 guest_ldtr_ar_bytes; + u32 guest_tr_ar_bytes; + u32 guest_interruptibility_info; + u32 guest_activity_state; + u32 guest_sysenter_cs; + u32 host_ia32_sysenter_cs; + u32 padding32[8]; /* room for future expansion */ + u16 virtual_processor_id; + u16 guest_es_selector; + u16 guest_cs_selector; + u16 guest_ss_selector; + u16 guest_ds_selector; + u16 guest_fs_selector; + u16 guest_gs_selector; + u16 guest_ldtr_selector; + u16 guest_tr_selector; + u16 host_es_selector; + u16 host_cs_selector; + u16 host_ss_selector; + u16 host_ds_selector; + u16 host_fs_selector; + u16 host_gs_selector; + u16 host_tr_selector; + }; + + +Authors +------- + +These patches were written by: + Abel Gordon, abelg <at> il.ibm.com + Nadav Har'El, nyh <at> il.ibm.com + Orit Wasserman, oritw <at> il.ibm.com + Ben-Ami Yassor, benami <at> il.ibm.com + Muli Ben-Yehuda, muli <at> il.ibm.com + +With contributions by: + Anthony Liguori, aliguori <at> us.ibm.com + Mike Day, mdday <at> us.ibm.com + Michael Factor, factor <at> il.ibm.com + Zvi Dubitzky, dubi <at> il.ibm.com + +And valuable reviews by: + Avi Kivity, avi <at> redhat.com + Gleb Natapov, gleb <at> redhat.com + Marcelo Tosatti, mtosatti <at> redhat.com + Kevin Tian, kevin.tian <at> intel.com + and others. diff --git a/Documentation/virtual/kvm/ppc-pv.txt b/Documentation/virtual/kvm/ppc-pv.txt index 3ab969c59046..2b7ce190cde4 100644 --- a/Documentation/virtual/kvm/ppc-pv.txt +++ b/Documentation/virtual/kvm/ppc-pv.txt @@ -68,9 +68,11 @@ page that contains parts of supervisor visible register state. The guest can map this shared page using the KVM hypercall KVM_HC_PPC_MAP_MAGIC_PAGE. With this hypercall issued the guest always gets the magic page mapped at the -desired location in effective and physical address space. For now, we always -map the page to -4096. This way we can access it using absolute load and store -functions. The following instruction reads the first field of the magic page: +desired location. The first parameter indicates the effective address when the +MMU is enabled. The second parameter indicates the address in real mode, if +applicable to the target. For now, we always map the page to -4096. This way we +can access it using absolute load and store functions. The following +instruction reads the first field of the magic page: ld rX, -4096(0) diff --git a/Documentation/virtual/lguest/lguest.c b/Documentation/virtual/lguest/lguest.c index cd9d6af61d07..043bd7df3139 100644 --- a/Documentation/virtual/lguest/lguest.c +++ b/Documentation/virtual/lguest/lguest.c @@ -51,7 +51,7 @@ #include <asm/bootparam.h> #include "../../../include/linux/lguest_launcher.h" /*L:110 - * We can ignore the 42 include files we need for this program, but I do want + * We can ignore the 43 include files we need for this program, but I do want * to draw attention to the use of kernel-style types. * * As Linus said, "C is a Spartan language, and so should your naming be." I @@ -65,7 +65,6 @@ typedef uint16_t u16; typedef uint8_t u8; /*:*/ -#define PAGE_PRESENT 0x7 /* Present, RW, Execute */ #define BRIDGE_PFX "bridge:" #ifndef SIOCBRADDIF #define SIOCBRADDIF 0x89a2 /* add interface to bridge */ @@ -861,8 +860,10 @@ static void console_output(struct virtqueue *vq) /* writev can return a partial write, so we loop here. */ while (!iov_empty(iov, out)) { int len = writev(STDOUT_FILENO, iov, out); - if (len <= 0) - err(1, "Write to stdout gave %i", len); + if (len <= 0) { + warn("Write to stdout gave %i (%d)", len, errno); + break; + } iov_consume(iov, out, len); } @@ -898,7 +899,7 @@ static void net_output(struct virtqueue *vq) * same format: what a coincidence! */ if (writev(net_info->tunfd, iov, out) < 0) - errx(1, "Write to tun failed?"); + warnx("Write to tun failed (%d)?", errno); /* * Done with that one; wait_for_vq_desc() will send the interrupt if @@ -955,7 +956,7 @@ static void net_input(struct virtqueue *vq) */ len = readv(net_info->tunfd, iov, in); if (len <= 0) - err(1, "Failed to read from tun."); + warn("Failed to read from tun (%d).", errno); /* * Mark that packet buffer as used, but don't interrupt here. We want @@ -1093,9 +1094,10 @@ static void update_device_status(struct device *dev) warnx("Device %s configuration FAILED", dev->name); if (dev->running) reset_device(dev); - } else if (dev->desc->status & VIRTIO_CONFIG_S_DRIVER_OK) { - if (!dev->running) - start_device(dev); + } else { + if (dev->running) + err(1, "Device %s features finalized twice", dev->name); + start_device(dev); } } @@ -1120,25 +1122,11 @@ static void handle_output(unsigned long addr) return; } - /* - * Devices *can* be used before status is set to DRIVER_OK. - * The original plan was that they would never do this: they - * would always finish setting up their status bits before - * actually touching the virtqueues. In practice, we allowed - * them to, and they do (eg. the disk probes for partition - * tables as part of initialization). - * - * If we see this, we start the device: once it's running, we - * expect the device to catch all the notifications. - */ + /* Devices should not be used before features are finalized. */ for (vq = i->vq; vq; vq = vq->next) { if (addr != vq->config.pfn*getpagesize()) continue; - if (i->running) - errx(1, "Notification on running %s", i->name); - /* This just calls create_thread() for each virtqueue */ - start_device(i); - return; + errx(1, "Notification on %s before setup!", i->name); } } @@ -1370,7 +1358,7 @@ static void setup_console(void) * --sharenet=<name> option which opens or creates a named pipe. This can be * used to send packets to another guest in a 1:1 manner. * - * More sopisticated is to use one of the tools developed for project like UML + * More sophisticated is to use one of the tools developed for project like UML * to do networking. * * Faster is to do virtio bonding in kernel. Doing this 1:1 would be @@ -1380,7 +1368,7 @@ static void setup_console(void) * multiple inter-guest channels behind one interface, although it would * require some manner of hotplugging new virtio channels. * - * Finally, we could implement a virtio network switch in the kernel. + * Finally, we could use a virtio network switch in the kernel, ie. vhost. :*/ static u32 str2ip(const char *ipaddr) @@ -2017,10 +2005,7 @@ int main(int argc, char *argv[]) /* Tell the entry path not to try to reload segment registers. */ boot->hdr.loadflags |= KEEP_SEGMENTS; - /* - * We tell the kernel to initialize the Guest: this returns the open - * /dev/lguest file descriptor. - */ + /* We tell the kernel to initialize the Guest. */ tell_kernel(start); /* Ensure that we terminate if a device-servicing child dies. */ diff --git a/Documentation/vm/hwpoison.txt b/Documentation/vm/hwpoison.txt index 12f9ba20ccb7..550068466605 100644 --- a/Documentation/vm/hwpoison.txt +++ b/Documentation/vm/hwpoison.txt @@ -129,12 +129,12 @@ Limit injection to pages owned by memgroup. Specified by inode number of the memcg. Example: - mkdir /cgroup/hwpoison + mkdir /sys/fs/cgroup/mem/hwpoison usemem -m 100 -s 1000 & - echo `jobs -p` > /cgroup/hwpoison/tasks + echo `jobs -p` > /sys/fs/cgroup/mem/hwpoison/tasks - memcg_ino=$(ls -id /cgroup/hwpoison | cut -f1 -d' ') + memcg_ino=$(ls -id /sys/fs/cgroup/mem/hwpoison | cut -f1 -d' ') echo $memcg_ino > /debug/hwpoison/corrupt-filter-memcg page-types -p `pidof init` --hwpoison # shall do nothing diff --git a/Documentation/x86/boot.txt b/Documentation/x86/boot.txt index 9b7221a86df2..7c3a8801b7ce 100644 --- a/Documentation/x86/boot.txt +++ b/Documentation/x86/boot.txt @@ -674,7 +674,7 @@ Protocol: 2.10+ Field name: init_size Type: read -Offset/size: 0x25c/4 +Offset/size: 0x260/4 This field indicates the amount of linear contiguous memory starting at the kernel runtime start address that the kernel needs before it diff --git a/Documentation/x86/entry_64.txt b/Documentation/x86/entry_64.txt new file mode 100644 index 000000000000..7869f14d055c --- /dev/null +++ b/Documentation/x86/entry_64.txt @@ -0,0 +1,98 @@ +This file documents some of the kernel entries in +arch/x86/kernel/entry_64.S. A lot of this explanation is adapted from +an email from Ingo Molnar: + +http://lkml.kernel.org/r/<20110529191055.GC9835%40elte.hu> + +The x86 architecture has quite a few different ways to jump into +kernel code. Most of these entry points are registered in +arch/x86/kernel/traps.c and implemented in arch/x86/kernel/entry_64.S +and arch/x86/ia32/ia32entry.S. + +The IDT vector assignments are listed in arch/x86/include/irq_vectors.h. + +Some of these entries are: + + - system_call: syscall instruction from 64-bit code. + + - ia32_syscall: int 0x80 from 32-bit or 64-bit code; compat syscall + either way. + + - ia32_syscall, ia32_sysenter: syscall and sysenter from 32-bit + code + + - interrupt: An array of entries. Every IDT vector that doesn't + explicitly point somewhere else gets set to the corresponding + value in interrupts. These point to a whole array of + magically-generated functions that make their way to do_IRQ with + the interrupt number as a parameter. + + - emulate_vsyscall: int 0xcc, a special non-ABI entry used by + vsyscall emulation. + + - APIC interrupts: Various special-purpose interrupts for things + like TLB shootdown. + + - Architecturally-defined exceptions like divide_error. + +There are a few complexities here. The different x86-64 entries +have different calling conventions. The syscall and sysenter +instructions have their own peculiar calling conventions. Some of +the IDT entries push an error code onto the stack; others don't. +IDT entries using the IST alternative stack mechanism need their own +magic to get the stack frames right. (You can find some +documentation in the AMD APM, Volume 2, Chapter 8 and the Intel SDM, +Volume 3, Chapter 6.) + +Dealing with the swapgs instruction is especially tricky. Swapgs +toggles whether gs is the kernel gs or the user gs. The swapgs +instruction is rather fragile: it must nest perfectly and only in +single depth, it should only be used if entering from user mode to +kernel mode and then when returning to user-space, and precisely +so. If we mess that up even slightly, we crash. + +So when we have a secondary entry, already in kernel mode, we *must +not* use SWAPGS blindly - nor must we forget doing a SWAPGS when it's +not switched/swapped yet. + +Now, there's a secondary complication: there's a cheap way to test +which mode the CPU is in and an expensive way. + +The cheap way is to pick this info off the entry frame on the kernel +stack, from the CS of the ptregs area of the kernel stack: + + xorl %ebx,%ebx + testl $3,CS+8(%rsp) + je error_kernelspace + SWAPGS + +The expensive (paranoid) way is to read back the MSR_GS_BASE value +(which is what SWAPGS modifies): + + movl $1,%ebx + movl $MSR_GS_BASE,%ecx + rdmsr + testl %edx,%edx + js 1f /* negative -> in kernel */ + SWAPGS + xorl %ebx,%ebx +1: ret + +and the whole paranoid non-paranoid macro complexity is about whether +to suffer that RDMSR cost. + +If we are at an interrupt or user-trap/gate-alike boundary then we can +use the faster check: the stack will be a reliable indicator of +whether SWAPGS was already done: if we see that we are a secondary +entry interrupting kernel mode execution, then we know that the GS +base has already been switched. If it says that we interrupted +user-space execution then we must do the SWAPGS. + +But if we are in an NMI/MCE/DEBUG/whatever super-atomic entry context, +which might have triggered right after a normal entry wrote CS to the +stack but before we executed SWAPGS, then the only safe way to check +for GS is the slower method: the RDMSR. + +So we try only to mark those entry methods 'paranoid' that absolutely +need the more expensive check for the GS base - and we generate all +'normal' entry points with the regular (faster) entry macros. diff --git a/Documentation/zh_CN/SubmitChecklist b/Documentation/zh_CN/SubmitChecklist index 951415bbab0c..4c741d6bc048 100644 --- a/Documentation/zh_CN/SubmitChecklist +++ b/Documentation/zh_CN/SubmitChecklist @@ -67,7 +67,7 @@ Linux内核提交清单 12：已经通过CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT, CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES, - CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_SPINLOCK_SLEEP测试，并且同时都 + CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_ATOMIC_SLEEP测试，并且同时都 使能。 13：已经都构建并且使用或者不使用 CONFIG_SMP 和 CONFIG_PREEMPT测试执行时间。 diff --git a/Documentation/zh_CN/email-clients.txt b/Documentation/zh_CN/email-clients.txt index 5d65e323d060..b9a1a3e6c78d 100644 --- a/Documentation/zh_CN/email-clients.txt +++ b/Documentation/zh_CN/email-clients.txt @@ -1,4 +1,4 @@ -閿?Chinese translated version of Documentation/email-clients.txt +锘緾hinese translated version of Documentation/email-clients.txt If you have any comment or update to the content, please contact the original document maintainer directly. However, if you have a problem @@ -8,203 +8,203 @@ or if there is a problem with the translation. Chinese maintainer: Harry Wei <harryxiyou@gmail.com> --------------------------------------------------------------------- -Documentation/email-clients.txt ???娑????缂堟槒?? +Documentation/email-clients.txt 鐨勪腑鏂囩炕璇 -婵??????瀹??鐠佺儤????瀛?鐗???????????鐎圭櫢??鐠囬?瀛?銉??缁?????濡楋絿??缂佸瓨?銈?????婵????娴?娴ｈ法?銊?杈?? -娴溿倖???????浼?鍓??鐠?閿?娑????娴犮儱??娑???????缂佸瓨?銈??濮???鈹??婵???????缂堟槒????瀛?棰???????鑸?????缂? -鐠?鐎???銊??妫?閿?鐠囩柉??缁鑵??????缂佸瓨?銈????? +濡傛灉鎯宠瘎璁烘垨鏇存柊鏈枃鐨勫唴瀹癸紝璇风洿鎺ヨ仈绯诲師鏂囨。鐨勭淮鎶よ呫傚鏋滀綘浣跨敤鑻辨枃 +浜ゆ祦鏈夊洶闅剧殑璇濓紝涔熷彲浠ュ悜涓枃鐗堢淮鎶よ呮眰鍔┿傚鏋滄湰缈昏瘧鏇存柊涓嶅強鏃舵垨鑰呯炕 +璇戝瓨鍦ㄩ棶棰橈紝璇疯仈绯讳腑鏂囩増缁存姢鑰呫 -娑???????缂佸瓨?銈??閿? 鐠愭儳??婵? Harry Wei <harryxiyou@gmail.com> -娑???????缂堟槒?????閿? 鐠愭儳??婵? Harry Wei <harryxiyou@gmail.com> -娑?????????陇?????閿? Yinglin Luan <synmyth@gmail.com> +涓枃鐗堢淮鎶よ咃細 璐惧▉濞 Harry Wei <harryxiyou@gmail.com> +涓枃鐗堢炕璇戣咃細 璐惧▉濞 Harry Wei <harryxiyou@gmail.com> +涓枃鐗堟牎璇戣咃細 Yinglin Luan <synmyth@gmail.com> Xiaochen Wang <wangxiaochen0@gmail.com> yaxinsn <yaxinsn@163.com> -娴犮儰??娑撶儤?锝?? +浠ヤ笅涓烘鏂 --------------------------------------------------------------------- -Linux???娴犺泛?銏?椋?????缂?娣団剝?? +Linux閭欢瀹㈡埛绔厤缃俊鎭 ====================================================================== -?????????缂? +鏅氶厤缃 ---------------------------------------------------------------------- -Linux?????姝屗夋稉???????鏉????娴犳儼?????娴溿倗??閿????婵傝姤??鐞涖儰??娴?娑撴椽??娴犳湹????????瀹?????????????娴?缂佸瓨?銈?? -??銉?鍫??娴犺??娴???????娴犲墎?????鐎硅?鐓??鎼?鐠囥儲??"text/plain"?????鎯??閿????娴犳湹????????娑?鐠???????閿? -???娑撻缚??娴?娴ｈ儻藟娑????瀵???銊?銊????銊??鐠侀缚??缁?娑???????瀵???浼?淇?? +Linux鍐呮牳琛ヤ竵鏄氳繃閭欢琚彁浜ょ殑锛屾渶濂芥妸琛ヤ竵浣滀负閭欢浣撶殑鍐呭祵鏂囨湰銆傛湁浜涚淮鎶よ +鎺ユ敹闄勪欢锛屼絾鏄檮浠剁殑鍐呭鏍煎紡搴旇鏄"text/plain"銆傜劧鑰岋紝闄勪欢涓鑸槸涓嶈禐鎴愮殑锛 +鍥犱负杩欎細浣胯ˉ涓佺殑寮曠敤閮ㄥ垎鍦ㄨ瘎璁鸿繃绋嬩腑鍙樼殑寰堝洶闅俱 -??銊?銉?????Linux?????姝屗夋稉???????娴犺泛?銏?椋????銊?????鐞涖儰????璺??鐠囥儱??娴?????????????婵???鑸?????娓?婵?閿? -娴?娴?娑???鑺?鐟?????????????銈?鎯般冪粭???????缁岀儤?纭???????铏????銊??娑?鐞????瀵?婢跺瓨?????缂?鐏忎勘?? +鐢ㄦ潵鍙戦丩inux鍐呮牳琛ヤ竵鐨勯偖浠跺鎴风鍦ㄥ彂閫佽ˉ涓佹椂搴旇澶勪簬鏂囨湰鐨勫師濮嬬姸鎬併備緥濡傦紝 +浠栦滑涓嶈兘鏀瑰彉鎴栬呭垹闄ゅ埗琛ㄧ鎴栬呯┖鏍硷紝鐢氳嚦鏄湪姣忎竴琛岀殑寮澶存垨鑰呯粨灏俱 -娑?鐟????鏉?"format=flowed"濡????????鐞涖儰?????鏉???铚??瀵?鐠ц渹?????妫????娴犮儱?????鐎瑰磭?????鐞???? +涓嶈閫氳繃"format=flowed"妯″紡鍙戦佽ˉ涓併傝繖鏍蜂細寮曡捣涓嶅彲棰勬湡浠ュ強鏈夊鐨勬柇琛屻 -娑?鐟?鐠佲晙????????娴犺泛?銏?椋??鏉?鐞??????銊?銏?????鏉???铚??娴???鏉??娴????鐞涖儰????? +涓嶈璁╀綘鐨勯偖浠跺鎴风杩涜鑷姩鎹㈣銆傝繖鏍蜂篃浼氱牬鍧忎綘鐨勮ˉ涓併 -???娴犺泛?銏?椋??娑???鑺?鐟???????????鐎?缁????缂??????鐟?????鐟??????????鐞涖儰???????鑺??ASCII??????UTF-8缂??????鐟??閿? -婵????娴?娴ｈ法??UTF-8缂??????鐟???????????娴犺????锝??娴?鐏?娴???鍨??娑?娴??????钘????????鐎?缁???????妫???? +閭欢瀹㈡埛绔笉鑳芥敼鍙樻枃鏈殑瀛楃闆嗙紪鐮佹柟寮忋傝鍙戦佺殑琛ヤ竵鍙兘鏄疉SCII鎴栬匲TF-8缂栫爜鏂瑰紡锛 +濡傛灉浣犱娇鐢║TF-8缂栫爜鏂瑰紡鍙戦侀偖浠讹紝閭ｄ箞浣犲皢浼氶伩鍏嶄竴浜涘彲鑳藉彂鐢熺殑瀛楃闆嗛棶棰樸 -???娴犺泛?銏?椋??鎼?鐠囥儱鑸???楠炴湹??娣???? References: ?????? In-Reply-To: ???妫?閿???锝?? -???娴犳儼??妫?鐏忓彉??娴?娑??????? +閭欢瀹㈡埛绔簲璇ュ舰鎴愬苟涓斾繚鎸 References: 鎴栬 In-Reply-To: 鏍囬锛岄偅涔 +閭欢璇濋灏变笉浼氫腑鏂 -婢???鍓??鐢?(?????????鐠愬??鐢?)???鐢晲????鐣?銊??鐞涖儰??閿????娑撳搫?鎯般冪粭?娴?鏉????娑撹櫣鈹??绗??娴ｈ法??xclipboard, xclip -??????xcutsel娑?鐠佺ǹ??娴犮儻??娴???????婵傝姤??鐠?娑?娑?????????鍨??娴ｈ法?銊????鍓??鐢???? +澶嶅埗绮樺笘(鎴栬呭壀璐寸矘甯)閫氬父涓嶈兘鐢ㄤ簬琛ヤ竵锛屽洜涓哄埗琛ㄧ浼氳浆鎹负绌烘牸銆備娇鐢▁clipboard, xclip +鎴栬厁cutsel涔熻鍙互锛屼絾鏄渶濂芥祴璇曚竴涓嬫垨鑰呴伩鍏嶄娇鐢ㄥ鍒剁矘甯栥 -娑?鐟???銊ゅ▏???PGP/GPG缂冩彃????????娴犳湹鑵??????鐞涖儰?????鏉???铚??娴ｅ灝??瀵?婢???????娑???鍊?璇??????????銊??娴????鐞涖儰????? -閿?鏉?娑????妫?鎼?鐠囥儲?????娴犮儰鎱ㄦ径????閿? +涓嶈鍦ㄤ娇鐢≒GP/GPG缃插悕鐨勯偖浠朵腑鍖呭惈琛ヤ竵銆傝繖鏍蜂細浣垮緱寰堝鑴氭湰涓嶈兘璇诲彇鍜岄傜敤浜庝綘鐨勮ˉ涓併 +锛堣繖涓棶棰樺簲璇ユ槸鍙互淇鐨勶級 -??銊???????鎼??娴犺泛??鐞涖劌?????鐞涖儰??娑????閿?缂????瀹稿崬?????娑?娑?鐞涖儰?????娑?娑???????娑撶粯??閿?娣?鐎???銉?璺?鎵?? -???娴犺??鐏?鐞涖儰?????'patch'??鎴掓姢???娑?閿?婵??????????娴?閿????缂??????鎼??娴犺泛??鐞涖劌???????? +鍦ㄧ粰鍐呮牳閭欢鍒楄〃鍙戦佽ˉ涓佷箣鍓嶏紝缁欒嚜宸卞彂閫佷竴涓ˉ涓佹槸涓笉閿欑殑涓绘剰锛屼繚瀛樻帴鏀跺埌鐨 +閭欢锛屽皢琛ヤ竵鐢'patch'鍛戒护鎵撲笂锛屽鏋滄垚鍔熶簡锛屽啀缁欏唴鏍搁偖浠跺垪琛ㄥ彂閫併 -娑?娴????娴犺泛?銏?椋?????缁? +涓浜涢偖浠跺鎴风鎻愮ず ---------------------------------------------------------------------- -鏉????缂???杞??娴?鐠?缂????MUA???缂????缁鐚?????娴犮儳?銊??缂?Linux?????绋?????鐞涖儰?????鏉?娴?楠炴湹???????铏?? -?????????鏉?娴犺泛?????缂???鑽????? +杩欓噷缁欏嚭涓浜涜缁嗙殑MUA閰嶇疆鎻愮ず锛屽彲浠ョ敤浜庣粰Linux鍐呮牳鍙戦佽ˉ涓併傝繖浜涘苟涓嶆剰鍛虫槸 +鎵鏈夌殑杞欢鍖呴厤缃荤粨銆 -鐠囧瓨??閿? -TUI = 娴犮儲?????娑撳搫?铏???????銊?閿?銉?? -GUI = ??鎯ц埌?????銏?銊?閿?銉?? +璇存槑锛 +TUI = 浠ユ枃鏈负鍩虹鐨勭敤鎴锋帴鍙 +GUI = 鍥惧舰鐣岄潰鐢ㄦ埛鎺ュ彛 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Alpine (TUI) -???缂????妞ょ櫢?? -???"Sending Preferences"??銊??閿? +閰嶇疆閫夐」锛 +鍦"Sending Preferences"閮ㄥ垎锛 -- "Do Not Send Flowed Text"韫?妞よ????? -- "Strip Whitespace Before Sending"韫?妞よ?鎶?? +- "Do Not Send Flowed Text"蹇呴』寮鍚 +- "Strip Whitespace Before Sending"蹇呴』鍏抽棴 -瑜???????娴犺埖?璁????????鎼?鐠囥儲?鎯?銊ㄋ夋稉?娴???铏?鎵????鐗?鐧????璺?????娑?CTRL-R缂???????閿?娴ｆ寧??鐎???? -鐞涖儰?????娴犺泛????銉?浼??娴犳湹鑵??? +褰撳啓閭欢鏃讹紝鍏夋爣搴旇鏀惧湪琛ヤ竵浼氬嚭鐜扮殑鍦版柟锛岀劧鍚庢寜涓婥TRL-R缁勫悎閿紝浣挎寚瀹氱殑 +琛ヤ竵鏂囦欢宓屽叆鍒伴偖浠朵腑銆 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Evolution (GUI) -娑?娴?瀵????????????????娴ｈ法?銊????????鐞涖儰?? +涓浜涘紑鍙戣呮垚鍔熺殑浣跨敤瀹冨彂閫佽ˉ涓 -瑜??????鈺??娴犲爼??妞ょ櫢??Preformat - 娴?Format->Heading->Preformatted (Ctrl-7)??????瀹搞儱?閿?? +褰撻夋嫨閭欢閫夐」锛歅reformat + 浠嶧ormat->Heading->Preformatted (Ctrl-7)鎴栬呭伐鍏锋爮 -??璺??娴ｈ法??閿? - Insert->Text File... (Alt-n x)?????銉ㄋ夋稉????娴犺翰?? +鐒跺悗浣跨敤锛 + Insert->Text File... (Alt-n x)鎻掑叆琛ヤ竵鏂囦欢銆 -娴?鏉????娴?"diff -Nru old.c new.c | xclip"閿???????Preformat閿???璺??娴ｈ法?銊よ厬??鎾??鏉?鐞?缁?鐢???? +浣犺繕鍙互"diff -Nru old.c new.c | xclip"锛岄夋嫨Preformat锛岀劧鍚庝娇鐢ㄤ腑闂撮敭杩涜绮樺笘銆 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kmail (GUI) -娑?娴?瀵????????????????娴ｈ法?銊????????鐞涖儰????? +涓浜涘紑鍙戣呮垚鍔熺殑浣跨敤瀹冨彂閫佽ˉ涓併 -姒?鐠併倛?鍓х枂娑?娑?HTML??鐓??????????????閿?娑?鐟??????銊????? +榛樿璁剧疆涓嶄负HTML鏍煎紡鏄悎閫傜殑锛涗笉瑕佸惎鐢ㄥ畠銆 -瑜?娑????娑?鐏????娴犲墎????璺??閿???銊??妞ら?????娑?鐟??????鈺????銊?銏????????娑????缂傝櫣?鐟版皑???娴???銊??娴犳湹鑵戞潏???銉??娴犺???????? -??鎴??娴?鐞??????銊?銏??閿????濮濄倓??韫?妞よ?銊?????鐞涖儰??娑?????????銊?銏????????缁?????????瑙??鐏忚鲸???????銊????銊?銏????銉ゅ姛??????娴犺?? -??璺?????鐎?娣?鐎?娑撻缚??缁嬭￥??娑????娴???銊??缁嬪じ鑵???濞嗏剝??瀵?鐎?閿?鐎?瀹歌尙????銊?銊????銊?銏??娴?閿???锝??娴???????娴犳儼?鐣?鑸电梾??? -?????鈺????銊?銏??閿?娴????鏉?娑?娴?婢跺崬?璇插嚒???????????銊?銏????? +褰撲功鍐欎竴灏侀偖浠剁殑鏃跺欙紝鍦ㄩ夐」涓嬮潰涓嶈閫夋嫨鑷姩鎹㈣銆傚敮涓鐨勭己鐐瑰氨鏄綘鍦ㄩ偖浠朵腑杈撳叆鐨勪换浣曟枃鏈 +閮戒笉浼氳鑷姩鎹㈣锛屽洜姝や綘蹇呴』鍦ㄥ彂閫佽ˉ涓佷箣鍓嶆墜鍔ㄦ崲琛屻傛渶绠鍗曠殑鏂规硶灏辨槸鍚敤鑷姩鎹㈣鏉ヤ功鍐欓偖浠讹紝 +鐒跺悗鎶婂畠淇濆瓨涓鸿崏绋裤備竴鏃︿綘鍦ㄨ崏绋夸腑鍐嶆鎵撳紑瀹冿紝瀹冨凡缁忓叏閮ㄨ嚜鍔ㄦ崲琛屼簡锛岄偅涔堜綘鐨勯偖浠惰櫧鐒舵病鏈 +閫夋嫨鑷姩鎹㈣锛屼絾鏄繕涓嶄細澶卞幓宸叉湁鐨勮嚜鍔ㄦ崲琛屻 -??銊??娴犲墎??鎼????閿??????銉ㄋ夋稉?娑????閿???鍙??鐢摜?銊??鐞涖儰??鐎????缁?閿?娑?娑?鏉?鐎????(---)??? +鍦ㄩ偖浠剁殑搴曢儴锛屾彃鍏ヨˉ涓佷箣鍓嶏紝鏀句笂甯哥敤鐨勮ˉ涓佸畾鐣岀锛氫笁涓繛瀛楀彿(---)銆 -??璺?????"Message"????????锛??閿??????鈺????銉??娴犺????銉????????娴????鐞涖儰?????娴犺翰??鏉????娑?娑?妫?婢???????妞ょ櫢??娴????娴? -???鏉?鐎????缂?娴???????娴犺泛缂撶粩?瀹搞儱?閿????????閿?鏉????娴犮儱鐢稉?"insert file"??鐐????? +鐒跺悗鍦"Message"鑿滃崟鏉＄洰锛岄夋嫨鎻掑叆鏂囦欢锛屾帴鐫閫夊彇浣犵殑琛ヤ竵鏂囦欢銆傝繕鏈変竴涓澶栫殑閫夐」锛屼綘鍙互 +閫氳繃瀹冮厤缃綘鐨勯偖浠跺缓绔嬪伐鍏锋爮鑿滃崟锛岃繕鍙互甯︿笂"insert file"鍥炬爣銆 -娴????娴犮儱????銊?浼??鏉?GPG???鐠佷即??娴犺??娴???????瀹?鐞涖儰?????婵傛垝??鐟?娴ｈ法??GPG???鐠佹澘??娴????娴?娑撳搫??瀹??????????缁涙儳??鐞涖儰??閿? -瑜?娴?GPG娑???????7娴?缂??????鏈??娴ｅじ??娴?????????鏉??婢??????? +浣犲彲浠ュ畨鍏ㄥ湴閫氳繃GPG鏍囪闄勪欢锛屼絾鏄唴宓岃ˉ涓佹渶濂戒笉瑕佷娇鐢℅PG鏍囪瀹冧滑銆備綔涓哄唴宓屾枃鏈殑绛惧彂琛ヤ竵锛 +褰撲粠GPG涓彁鍙7浣嶇紪鐮佹椂浼氫娇浠栦滑鍙樼殑鏇村姞澶嶆潅銆 -婵????娴????鐟?娴犮儵??娴犲墎??瑜般垹????????鐞涖儰??閿???锝??鐏忓崬?鎶????鐟?濠??娴犺????璺?????娑?鐏???褝??缁????"Suggest automatic -display"閿?鏉???宄??瀹????娴犺埖?鏉?瑙??鐠佲晞?鏄???????鑸?? +濡傛灉浣犻潪瑕佷互闄勪欢鐨勫舰寮忓彂閫佽ˉ涓侊紝閭ｄ箞灏卞彸閿偣鍑婚檮浠讹紝鐒跺悗閫変腑灞炴э紝绐佸嚭"Suggest automatic +display"锛岃繖鏍峰唴宓岄檮浠舵洿瀹规槗璁╄鑰呯湅鍒般 -瑜?娴?鐟?娣?鐎?鐏?鐟?????????????瀹???????鐞涖儰??閿?娴????娴犮儰??濞???????鐞涖劎????濂????鈺?????鐞涖儰????????娴犺????璺????鍐?濠????? -"save as"???娴????娴犮儰濞??銊??娑?濞屸剝????瀛?鍦????????鐞涖儰????????娴犺??婵????鐎????娴犮儲?锝団???瑜般垹??缂???????瑜?娴?濮濓絿????銊?? -???瀹歌京??缁???锝??娑?鐎????閿???锝?鑸电梾??????妞ょ懓??娴犮儰??鐎????娴?--瀹歌尙?????娑?娑?鏉???椋??bug鐞?濮???銉?棰??kmail???bugzilla -楠炴湹??鐢????鏉?鐏?娴?鐞?婢??????????娴犺埖??娴犮儱?????鐎佃??娑???銊?宄??鐠囪???????????鐞?娣?鐎????閿????娴犮儱?????娴???铏?????娴犺泛????璺?鏉?鏈????鐗?鐧?? -娴?娑?瀵?娑????娴?娴????????????閫涜礋缂?????????缈?????鐠囨眹?? +褰撲綘瑕佷繚瀛樺皢瑕佸彂閫佺殑鍐呭祵鏂囨湰琛ヤ竵锛屼綘鍙互浠庢秷鎭垪琛ㄧ獥鏍奸夋嫨鍖呭惈琛ヤ竵鐨勯偖浠讹紝鐒跺悗鍙冲嚮閫夋嫨 +"save as"銆備綘鍙互浣跨敤涓涓病鏈夋洿鏀圭殑鍖呭惈琛ヤ竵鐨勯偖浠讹紝濡傛灉瀹冩槸浠ユ纭殑褰㈠紡缁勬垚銆傚綋浣犳鐪熷湪瀹 +鑷繁鐨勭獥鍙ｄ箣涓嬪療鐪嬶紝閭ｆ椂娌℃湁閫夐」鍙互淇濆瓨閭欢--宸茬粡鏈変竴涓繖鏍风殑bug琚眹鎶ュ埌浜唊mail鐨刡ugzilla +骞朵笖甯屾湜杩欏皢浼氳澶勭悊銆傞偖浠舵槸浠ュ彧閽堝鏌愪釜鐢ㄦ埛鍙鍐欑殑鏉冮檺琚繚瀛樼殑锛屾墍浠ュ鏋滀綘鎯虫妸閭欢澶嶅埗鍒板叾浠栧湴鏂癸紝 +浣犱笉寰椾笉鎶婁粬浠殑鏉冮檺鏀逛负缁勬垨鑰呮暣浣撳彲璇汇 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Lotus Notes (GUI) -娑?鐟?娴ｈ法?銊????? +涓嶈浣跨敤瀹冦 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mutt (TUI) -瀵?婢?Linux瀵????娴滃搫??娴ｈ法??mutt鐎广垺?椋??閿????娴犮儴?????鐎????鐎?瀹搞儰????????鐢憡??娴???? +寰堝Linux寮鍙戜汉鍛樹娇鐢╩utt瀹㈡埛绔紝鎵浠ヨ瘉鏄庡畠鑲畾宸ヤ綔鐨勯潪甯告紓浜 -Mutt娑????鐢?缂?鏉????閿????娴犮儰??缁犫??娴ｈ法?銊??娑?缂?鏉???銊?鎴??鎼?鐠囥儱鐢????????銊??鐞????婢堆????鎵??鏉???銊?钘夌敨??? -娑?娑?"insert file"???妞ょ櫢??鐎????娴犮儵??鏉?娑???鐟?????娴犺泛??鐎瑰湱????鐟???????銉??娴犺翰?? +Mutt涓嶈嚜甯︾紪杈戝櫒锛屾墍浠ヤ笉绠′綘浣跨敤浠涔堢紪杈戝櫒閮戒笉搴旇甯︽湁鑷姩鏂銆傚ぇ澶氭暟缂栬緫鍣ㄩ兘甯︽湁 +涓涓"insert file"閫夐」锛屽畠鍙互閫氳繃涓嶆敼鍙樻枃浠跺唴瀹圭殑鏂瑰紡鎻掑叆鏂囦欢銆 -'vim'娴?娑?mutt???缂?鏉????閿? +'vim'浣滀负mutt鐨勭紪杈戝櫒锛 set editor="vi" - 婵????娴ｈ法??xclip閿???鎻?銉や簰娑???鎴掓姢 + 濡傛灉浣跨敤xclip锛屾暡鍏ヤ互涓嬪懡浠 :set paste - ???娑????娑??????????shift-insert??????娴ｈ法?? + 鎸変腑閿箣鍓嶆垨鑰卻hift-insert鎴栬呬娇鐢 :r filename -婵??????瀹?????鐞涖儰??娴?娑撳搫??瀹?????????? -(a)ttach瀹搞儰?????瀵?婵傛枻??娑?鐢????"set paste"??? +濡傛灉鎯宠鎶婅ˉ涓佷綔涓哄唴宓屾枃鏈 +(a)ttach宸ヤ綔鐨勫緢濂斤紝涓嶅甫鏈"set paste"銆 -???缂????妞ょ櫢?? -鐎?鎼?鐠囥儰浜掓?鐠併倛?鍓х枂???瑜般垹??瀹搞儰????? -??鎯??閿????"send_charset"鐠佸墽鐤嗘稉?"us-ascii::utf-8"娑????娑?娑?娑???????娑撶粯????? +閰嶇疆閫夐」锛 +瀹冨簲璇ヤ互榛樿璁剧疆鐨勫舰寮忓伐浣溿 +鐒惰岋紝鎶"send_charset"璁剧疆涓"us-ascii::utf-8"涔熸槸涓涓笉閿欑殑涓绘剰銆 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Pine (TUI) -Pine鏉???缁??娑?娴?缁岀儤?鐓????????妫?閿?娴????鏉?娴???鏉?銊??鐠囥儵?鍊??娣?婢?娴???? +Pine杩囧幓鏈変竴浜涚┖鏍煎垹鍑忛棶棰橈紝浣嗘槸杩欎簺鐜板湪搴旇閮借淇浜嗐 -婵???????娴犮儻??鐠囪渹濞???alpine(pine???缂佈?鑳??) +濡傛灉鍙互锛岃浣跨敤alpine(pine鐨勭户鎵胯) -???缂????妞ょ櫢?? -- ???鏉?????????????鐟?濞???銈??缁??????? -- "no-strip-whitespace-before-send"???妞ら????????鐟??????? +閰嶇疆閫夐」锛 +- 鏈杩戠殑鐗堟湰闇瑕佹秷闄ゆ祦绋嬫枃鏈 +- "no-strip-whitespace-before-send"閫夐」涔熸槸闇瑕佺殑銆 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Sylpheed (GUI) -- ???瀹??????????娴犮儱??婵傜晫??瀹搞儰??閿???????娴ｈ法?銊??娴犺????? -- ???鐠侀晲濞??銊????銊??缂?鏉???銊?? -- 鐎甸?????瑜?鏉?婢???鍫??鐢憡????? -- 婵???????鏉?non-SSL鏉???銉?????濞?娴ｈ法??TLS SMTP????????? -- ??銊?????缁???锝勮厬???娑?娑?瀵??????銊??ruler bar??? -- 缂???鏉?????娑?濞ｈ????鏉??鐏忓彉??娴?濮濓絿鈥???娴?鐟欙絾?鍓с仛?????? +- 鍐呭祵鏂囨湰鍙互寰堝ソ鐨勫伐浣滐紙鎴栬呬娇鐢ㄩ檮浠讹級銆 +- 鍏佽浣跨敤澶栭儴鐨勭紪杈戝櫒銆 +- 瀵逛簬鐩綍杈冨鏃堕潪甯告參銆 +- 濡傛灉閫氳繃non-SSL杩炴帴锛屾棤娉曚娇鐢═LS SMTP鎺堟潈銆 +- 鍦ㄧ粍鎴愮獥鍙ｄ腑鏈変竴涓緢鏈夌敤鐨剅uler bar銆 +- 缁欏湴鍧鏈腑娣诲姞鍦板潃灏变笉浼氭纭殑浜嗚В鏄剧ず鍚嶃 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Thunderbird (GUI) -姒?鐠併倖????鍏??閿?thunderbird瀵?鐎硅??????????????閿?娴????鏉????娑?娴???瑙?????娴犮儱宸??璺?????瀵???鏉戙偨??? +榛樿鎯呭喌涓嬶紝thunderbird寰堝鏄撴崯鍧忔枃鏈紝浣嗘槸杩樻湁涓浜涙柟娉曞彲浠ュ己鍒跺畠鍙樺緱鏇村ソ銆 -- ??銊?銊?宄????鐤?鍓х枂???閿?缂???????鐎佃??閿?娑?鐟???????"Compose messages in HTML format"??? +- 鍦ㄧ敤鎴峰笎鍙疯缃噷锛岀粍鎴愬拰瀵诲潃锛屼笉瑕侀夋嫨"Compose messages in HTML format"銆 -- 缂?鏉?娴????Thunderbird???缂?鐠佸墽鐤??銉ゅ▏鐎?娑?鐟????鐞?娴ｈ法??閿?user_pref("mailnews.wraplength", 0); +- 缂栬緫浣犵殑Thunderbird閰嶇疆璁剧疆鏉ヤ娇瀹冧笉瑕佹媶琛屼娇鐢細user_pref("mailnews.wraplength", 0); -- 缂?鏉?娴????Thunderbird???缂?鐠佸墽鐤嗛敍?娴ｅ灝??娑?鐟?娴ｈ法??"format=flowed"??鐓??閿?user_pref("mailnews. +- 缂栬緫浣犵殑Thunderbird閰嶇疆璁剧疆锛屼娇瀹冧笉瑕佷娇鐢"format=flowed"鏍煎紡锛歶ser_pref("mailnews. send_plaintext_flowed", false); -- 娴????鐟?娴?Thunderbird???娑撴椽???????鐓????鐟??閿? - 婵????姒?鐠併倖????鍏??娴?娑??????????HTML??鐓??閿???锝?????瀵???淇??娴?娴?娴????妫???????娑????濡?娑???????"Preformat"??鐓????? - 婵????姒?鐠併倖????鍏??娴?娑??????????????????鐓??閿?娴?娑?瀵????鐎???閫涜礋HTML??鐓??閿?娴?娴?娴?娑撹桨??濞嗏剝?褏??閿???銉ゅ姛?????鎵??濞????閿? - ??璺??瀵搫?鏈靛▏鐎??????鐗???????鐓??閿???????鐎?鐏忓彉?????鐞????鐟?鐎???鏉??閿???銊??娣囷紕????鐐??娑?娴ｈ法??shift?????銉ゅ▏鐎????娑?HTML - ??鐓??閿???璺?????妫???????娑????濡?娑???????"Preformat"??鐓????? +- 浣犻渶瑕佷娇Thunderbird鍙樹负棰勫厛鏍煎紡鏂瑰紡锛 + 濡傛灉榛樿鎯呭喌涓嬩綘涔﹀啓鐨勬槸HTML鏍煎紡锛岄偅涓嶆槸寰堥毦銆備粎浠呬粠鏍囬鏍忕殑涓嬫媺妗嗕腑閫夋嫨"Preformat"鏍煎紡銆 + 濡傛灉榛樿鎯呭喌涓嬩綘涔﹀啓鐨勬槸鏂囨湰鏍煎紡锛屼綘涓嶅緱鎶婂畠鏀逛负HTML鏍煎紡锛堜粎浠呬綔涓轰竴娆℃х殑锛夋潵涔﹀啓鏂扮殑娑堟伅锛 + 鐒跺悗寮哄埗浣垮畠鍥炲埌鏂囨湰鏍煎紡锛屽惁鍒欏畠灏变細鎷嗚銆傝瀹炵幇瀹冿紝鍦ㄥ啓淇＄殑鍥炬爣涓婁娇鐢╯hift閿潵浣垮畠鍙樹负HTML + 鏍煎紡锛岀劧鍚庢爣棰樻爮鐨勪笅鎷夋涓夋嫨"Preformat"鏍煎紡銆 -- ???鐠侀晲濞??銊????銊??缂?鏉????閿? - ???鐎?Thunderbird???鐞涖儰?????缁?????????瑙??鐏忚鲸??娴ｈ法?銊??娑?"external editor"??鈺??閿???璺??娴ｈ法?銊????????濞嗐垻?? - $EDITOR??銉?璇???????????楠炴儼藟娑???鐗?????娑????鐟?鐎???鏉??閿????娴犮儰??鏉炶棄鑻熸稉?鐎?鐟?鏉?娑???鈺??閿???璺??濞ｈ??娑?娑?娴ｈ法?銊????? - ??????View->Toolbars->Customize...??????瑜?娴?娑????娣団剝???????璺??娴?娴???鐟?璇??鐏忓崬??娴犮儰????? +- 鍏佽浣跨敤澶栭儴鐨勭紪杈戝櫒锛 + 閽堝Thunderbird鎵撹ˉ涓佹渶绠鍗曠殑鏂规硶灏辨槸浣跨敤涓涓"external editor"鎵╁睍锛岀劧鍚庝娇鐢ㄤ綘鏈鍠滄鐨 + $EDITOR鏉ヨ鍙栨垨鑰呭悎骞惰ˉ涓佸埌鏂囨湰涓傝瀹炵幇瀹冿紝鍙互涓嬭浇骞朵笖瀹夎杩欎釜鎵╁睍锛岀劧鍚庢坊鍔犱竴涓娇鐢ㄥ畠鐨 + 鎸夐敭View->Toolbars->Customize...鏈鍚庡綋浣犱功鍐欎俊鎭殑鏃跺欎粎浠呯偣鍑诲畠灏卞彲浠ヤ簡銆 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ TkRat (GUI) -???娴犮儰濞??銊?????娴ｈ法??"Insert file..."??????婢???銊??缂?鏉???銊?? +鍙互浣跨敤瀹冦備娇鐢"Insert file..."鎴栬呭閮ㄧ殑缂栬緫鍣ㄣ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Gmail (Web GUI) -娑?鐟?娴ｈ法?銊????????鐞涖儰????? +涓嶈浣跨敤瀹冨彂閫佽ˉ涓併 -Gmail缂?妞ら潧?銏?椋???????銊?鐗????鎯般冪粭?鏉????娑撹櫣鈹??绗?? +Gmail缃戦〉瀹㈡埛绔嚜鍔ㄥ湴鎶婂埗琛ㄧ杞崲涓虹┖鏍笺 -??鐣?璺?鎯般冪粭?鏉????娑撹櫣鈹??濂??妫????娴犮儴??婢???銊??鏉???銊ㄐ??绛???????璺??鏉?娴?娴ｈ法?銊??鏉???銏?????濮?鐞???????娑?78娑?鐎?缁???? +铏界劧鍒惰〃绗﹁浆鎹负绌烘牸闂鍙互琚閮ㄧ紪杈戝櫒瑙ｅ喅锛屽悓鏃跺畠杩樹細浣跨敤鍥炶溅鎹㈣鎶婃瘡琛屾媶鍒嗕负78涓瓧绗︺ -???娑?娑????妫????Gmail鏉?娴????娴犺??娑????ASCII???鐎?缁????娣団剝????閫涜礋base64缂???????鐎????娑?鐟楀灝????????濞喲勫簥娴滆櫣?????鐎???? +鍙︿竴涓棶棰樻槸Gmail杩樹細鎶婁换浣曚笉鏄疉SCII鐨勫瓧绗︾殑淇℃伅鏀逛负base64缂栫爜銆傚畠鎶婁笢瑗垮彉鐨勫儚娆ф床浜虹殑鍚嶅瓧銆 ### diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt index 4c4ce853577b..c278f412dc65 100644 --- a/Documentation/zh_CN/magic-number.txt +++ b/Documentation/zh_CN/magic-number.txt @@ -66,7 +66,7 @@ MKISS_DRIVER_MAGIC 0x04bf mkiss_channel drivers/net/mkiss.h RISCOM8_MAGIC 0x0907 riscom_port drivers/char/riscom8.h SPECIALIX_MAGIC 0x0907 specialix_port drivers/char/specialix_io8.h HDLC_MAGIC 0x239e n_hdlc drivers/char/n_hdlc.c -APM_BIOS_MAGIC 0x4101 apm_user arch/i386/kernel/apm.c +APM_BIOS_MAGIC 0x4101 apm_user arch/x86/kernel/apm_32.c CYCLADES_MAGIC 0x4359 cyclades_port include/linux/cyclades.h DB_MAGIC 0x4442 fc_info drivers/net/iph5526_novram.c DL_MAGIC 0x444d fc_info drivers/net/iph5526_novram.c |