From 700920eb5ba4de5417b446c9a8bb008df2b973e0 Mon Sep 17 00:00:00 2001 From: David Howells Date: Wed, 18 Jan 2012 15:31:45 +0000 Subject: KEYS: Allow special keyrings to be cleared The kernel contains some special internal keyrings, for instance the DNS resolver keyring : 2a93faf1 I----- 1 perm 1f030000 0 0 keyring .dns_resolver: empty It would occasionally be useful to allow the contents of such keyrings to be flushed by root (cache invalidation). Allow a flag to be set on a keyring to mark that someone possessing the sysadmin capability can clear the keyring, even without normal write access to the keyring. Set this flag on the special keyrings created by the DNS resolver, the NFS identity mapper and the CIFS identity mapper. Signed-off-by: David Howells Acked-by: Jeff Layton Acked-by: Steve Dickson Signed-off-by: James Morris --- Documentation/networking/dns_resolver.txt | 4 ++++ Documentation/security/keys.txt | 4 ++++ 2 files changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/dns_resolver.txt b/Documentation/networking/dns_resolver.txt index 7f531ad..d86adcd 100644 --- a/Documentation/networking/dns_resolver.txt +++ b/Documentation/networking/dns_resolver.txt @@ -102,6 +102,10 @@ implemented in the module can be called after doing: If _expiry is non-NULL, the expiry time (TTL) of the result will be returned also. +The kernel maintains an internal keyring in which it caches looked up keys. +This can be cleared by any process that has the CAP_SYS_ADMIN capability by +the use of KEYCTL_KEYRING_CLEAR on the keyring ID. + =============================== READING DNS KEYS FROM USERSPACE diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt index 4d75931..713ec23 100644 --- a/Documentation/security/keys.txt +++ b/Documentation/security/keys.txt @@ -554,6 +554,10 @@ The keyctl syscall functions are: process must have write permission on the keyring, and it must be a keyring (or else error ENOTDIR will result). + This function can also be used to clear special kernel keyrings if they + are appropriately marked if the user has CAP_SYS_ADMIN capability. The + DNS resolver cache keyring is an example of this. + (*) Link a key into a keyring: -- cgit v1.1 From 070b9079226d4f3e3e7c9f4eb81f2e02e7d99572 Mon Sep 17 00:00:00 2001 From: Stephen Boyd Date: Mon, 16 Jan 2012 19:39:58 -0800 Subject: regulator: Add devm_regulator_get() Add a resource managed regulator_get() to simplify regulator usage in drivers. This allows driver authors to "get and forget" about their regulators by automatically calling regulator_put() when the driver is detached. [Fixed up a couple of coding style issues -- broonie] Signed-off-by: Stephen Boyd Signed-off-by: Mark Brown --- Documentation/driver-model/devres.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 10c64c8..016fd2b 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -267,3 +267,6 @@ IOMAP pcim_iounmap() pcim_iomap_table() : array of mapped addresses indexed by BAR pcim_iomap_regions() : do request_region() and iomap() on multiple BARs + +REGULATOR + devm_regulator_get() -- cgit v1.1 From 583aa3a9b5ca846a84f7dd87bdc4b75dca07b011 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Wed, 11 Jan 2012 06:45:05 -0300 Subject: [media] V4L2: Add per-device-node capabilities If V4L2_CAP_DEVICE_CAPS is set, then the new device_caps field is filled with the capabilities of the opened device node. The capabilities field traditionally contains the capabilities of the physical device, being a superset of all capabilities available at the several device nodes. E.g., if you open /dev/video0, then if it contains VBI caps then that means that there is a corresponding vbi node as well. And the capabilities field of both the video and vbi nodes should contain identical caps. However, it would be very useful to also have a capabilities field that contains just the caps for the currently open device, hence the new CAP bit and field. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/compat.xml | 4 +++ Documentation/DocBook/media/v4l/v4l2.xml | 9 +++++- .../DocBook/media/v4l/vidioc-querycap.xml | 36 ++++++++++++++++++++-- 3 files changed, 45 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index c736380..c93298f 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2393,6 +2393,10 @@ details. to the User controls class. + + Added the device_caps field to struct v4l2_capabilities and added the new + V4L2_CAP_DEVICE_CAPS capability. + diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index e97c512..dce3fef 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -128,6 +128,13 @@ structs, ioctls) must be noted in more detail in the history chapter applications. --> + 3.3 + 2012-01-11 + hv + Added device_caps field to struct v4l2_capabilities. + + + 3.2 2011-08-26 hv @@ -417,7 +424,7 @@ and discussions on the V4L mailing list. Video for Linux Two API Specification - Revision 3.2 + Revision 3.3 &sub-common; diff --git a/Documentation/DocBook/media/v4l/vidioc-querycap.xml b/Documentation/DocBook/media/v4l/vidioc-querycap.xml index e3664d6..4643505 100644 --- a/Documentation/DocBook/media/v4l/vidioc-querycap.xml +++ b/Documentation/DocBook/media/v4l/vidioc-querycap.xml @@ -124,12 +124,35 @@ printf ("Version: %u.%u.%u\n", __u32 capabilities - Device capabilities, see . + Available capabilities of the physical device as a whole, see . The same physical device can export + multiple devices in /dev (e.g. /dev/videoX, /dev/vbiY and /dev/radioZ). + The capabilities field should contain a union + of all capabilities available around the several V4L2 devices exported + to userspace. + For all those devices the capabilities field + returns the same set of capabilities. This allows applications to open + just one of the devices (typically the video device) and discover whether + video, vbi and/or radio are also supported. + __u32 - reserved[4] + device_caps + Device capabilities of the opened device, see . Should contain the available capabilities + of that specific device node. So, for example, device_caps + of a radio device will only contain radio related capabilities and + no video or vbi capabilities. This field is only set if the capabilities + field contains the V4L2_CAP_DEVICE_CAPS capability. + Only the capabilities field can have the + V4L2_CAP_DEVICE_CAPS capability, device_caps + will never set V4L2_CAP_DEVICE_CAPS. + + + + __u32 + reserved[3] Reserved for future extensions. Drivers must set this array to zero. @@ -276,6 +299,13 @@ linkend="async">asynchronous I/O methods. The device supports the streaming I/O method. + + V4L2_CAP_DEVICE_CAPS + 0x80000000 + The driver fills the device_caps + field. This capability can only appear in the capabilities + field and never in the device_caps field. + -- cgit v1.1 From 3167760f83899ccda312b9ad9306ec9e5dda06d4 Mon Sep 17 00:00:00 2001 From: Dan Magenheimer Date: Wed, 21 Sep 2011 11:56:28 -0400 Subject: mm: cleancache: s/flush/invalidate/ Per akpm suggestions alter the use of the term flush to be invalidate. The next patch will do this across all MM. This change is completely cosmetic. [v9: akpm@linux-foundation.org: change "flush" to "invalidate", part 3] Signed-off-by: Dan Magenheimer Cc: Kamezawa Hiroyuki Cc: Jan Beulich Reviewed-by: Seth Jennings Cc: Jeremy Fitzhardinge Cc: Hugh Dickins Cc: Johannes Weiner Cc: Nitin Gupta Cc: Matthew Wilcox Cc: Chris Mason Cc: Rik Riel Cc: Andrew Morton [v10: Fixed fs: move code out of buffer.c conflict change] Signed-off-by: Konrad Rzeszutek Wilk --- Documentation/vm/cleancache.txt | 37 +++++++++++++++++++------------------ 1 file changed, 19 insertions(+), 18 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/cleancache.txt b/Documentation/vm/cleancache.txt index 36c367c..e0a5356 100644 --- a/Documentation/vm/cleancache.txt +++ b/Documentation/vm/cleancache.txt @@ -46,10 +46,11 @@ a negative return value indicates failure. A "put_page" will copy a the pool id, a file key, and a page index into the file. (The combination of a pool id, a file key, and an index is sometimes called a "handle".) A "get_page" will copy the page, if found, from cleancache into kernel memory. -A "flush_page" will ensure the page no longer is present in cleancache; -a "flush_inode" will flush all pages associated with the specified file; -and, when a filesystem is unmounted, a "flush_fs" will flush all pages in -all files specified by the given pool id and also surrender the pool id. +An "invalidate_page" will ensure the page no longer is present in cleancache; +an "invalidate_inode" will invalidate all pages associated with the specified +file; and, when a filesystem is unmounted, an "invalidate_fs" will invalidate +all pages in all files specified by the given pool id and also surrender +the pool id. An "init_shared_fs", like init_fs, obtains a pool id but tells cleancache to treat the pool as shared using a 128-bit UUID as a key. On systems @@ -62,12 +63,12 @@ of the kernel (e.g. by "tools" that control cleancache). Or a cleancache implementation can simply disable shared_init by always returning a negative value. -If a get_page is successful on a non-shared pool, the page is flushed (thus -making cleancache an "exclusive" cache). On a shared pool, the page -is NOT flushed on a successful get_page so that it remains accessible to +If a get_page is successful on a non-shared pool, the page is invalidated +(thus making cleancache an "exclusive" cache). On a shared pool, the page +is NOT invalidated on a successful get_page so that it remains accessible to other sharers. The kernel is responsible for ensuring coherency between cleancache (shared or not), the page cache, and the filesystem, using -cleancache flush operations as required. +cleancache invalidate operations as required. Note that cleancache must enforce put-put-get coherency and get-get coherency. For the former, if two puts are made to the same handle but @@ -77,7 +78,7 @@ if a get for a given handle fails, subsequent gets for that handle will never succeed unless preceded by a successful put with that handle. Last, cleancache provides no SMP serialization guarantees; if two -different Linux threads are simultaneously putting and flushing a page +different Linux threads are simultaneously putting and invalidating a page with the same handle, the results are indeterminate. Callers must lock the page to ensure serial behavior. @@ -90,7 +91,7 @@ can be measured (across all filesystems) with: succ_gets - number of gets that were successful failed_gets - number of gets that failed puts - number of puts attempted (all "succeed") -flushes - number of flushes attempted +invalidates - number of invalidates attempted A backend implementatation may provide additional metrics. @@ -143,7 +144,7 @@ systems. The core hooks for cleancache in VFS are in most cases a single line and the minimum set are placed precisely where needed to maintain -coherency (via cleancache_flush operations) between cleancache, +coherency (via cleancache_invalidate operations) between cleancache, the page cache, and disk. All hooks compile into nothingness if cleancache is config'ed off and turn into a function-pointer- compare-to-NULL if config'ed on but no backend claims the ops @@ -184,15 +185,15 @@ or for real kernel-addressable RAM, it makes perfect sense for transcendent memory. 4) Why is non-shared cleancache "exclusive"? And where is the - page "flushed" after a "get"? (Minchan Kim) + page "invalidated" after a "get"? (Minchan Kim) The main reason is to free up space in transcendent memory and -to avoid unnecessary cleancache_flush calls. If you want inclusive, +to avoid unnecessary cleancache_invalidate calls. If you want inclusive, the page can be "put" immediately following the "get". If put-after-get for inclusive becomes common, the interface could -be easily extended to add a "get_no_flush" call. +be easily extended to add a "get_no_invalidate" call. -The flush is done by the cleancache backend implementation. +The invalidate is done by the cleancache backend implementation. 5) What's the performance impact? @@ -222,7 +223,7 @@ Some points for a filesystem to consider: as tmpfs should not enable cleancache) - To ensure coherency/correctness, the FS must ensure that all file removal or truncation operations either go through VFS or - add hooks to do the equivalent cleancache "flush" operations + add hooks to do the equivalent cleancache "invalidate" operations - To ensure coherency/correctness, either inode numbers must be unique across the lifetime of the on-disk file OR the FS must provide an "encode_fh" function. @@ -243,11 +244,11 @@ If cleancache would use the inode virtual address instead of inode/filehandle, the pool id could be eliminated. But, this won't work because cleancache retains pagecache data pages persistently even when the inode has been pruned from the -inode unused list, and only flushes the data page if the file +inode unused list, and only invalidates the data page if the file gets removed/truncated. So if cleancache used the inode kva, there would be potential coherency issues if/when the inode kva is reused for a different file. Alternately, if cleancache -flushed the pages when the inode kva was freed, much of the value +invalidated the pages when the inode kva was freed, much of the value of cleancache would be lost because the cache of pages in cleanache is potentially much larger than the kernel pagecache and is most useful if the pages survive inode cache removal. -- cgit v1.1 From 417fc2caef268ed23169316f6c5e3a33775bfae5 Mon Sep 17 00:00:00 2001 From: Dan Magenheimer Date: Wed, 21 Sep 2011 12:28:04 -0400 Subject: mm: cleancache: report statistics via debugfs instead of sysfs. [v9: akpm@linux-foundation.org: sysfs->debugfs; no longer need Doc/ABI file] Signed-off-by: Dan Magenheimer Signed-off-by: Konrad Wilk Cc: Jan Beulich Acked-by: Seth Jennings Cc: Jeremy Fitzhardinge Cc: Hugh Dickins Cc: Johannes Weiner Cc: Nitin Gupta Cc: Matthew Wilcox Cc: Chris Mason Cc: Rik Riel Cc: Andrew Morton --- Documentation/ABI/testing/sysfs-kernel-mm-cleancache | 11 ----------- Documentation/vm/cleancache.txt | 4 ++-- 2 files changed, 2 insertions(+), 13 deletions(-) delete mode 100644 Documentation/ABI/testing/sysfs-kernel-mm-cleancache (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-cleancache b/Documentation/ABI/testing/sysfs-kernel-mm-cleancache deleted file mode 100644 index 662ae64..0000000 --- a/Documentation/ABI/testing/sysfs-kernel-mm-cleancache +++ /dev/null @@ -1,11 +0,0 @@ -What: /sys/kernel/mm/cleancache/ -Date: April 2011 -Contact: Dan Magenheimer -Description: - /sys/kernel/mm/cleancache/ contains a number of files which - record a count of various cleancache operations - (sum across all filesystems): - succ_gets - failed_gets - puts - flushes diff --git a/Documentation/vm/cleancache.txt b/Documentation/vm/cleancache.txt index e0a5356..f726717 100644 --- a/Documentation/vm/cleancache.txt +++ b/Documentation/vm/cleancache.txt @@ -84,8 +84,8 @@ lock the page to ensure serial behavior. CLEANCACHE PERFORMANCE METRICS -Cleancache monitoring is done by sysfs files in the -/sys/kernel/mm/cleancache directory. The effectiveness of cleancache +If properly configured, monitoring of cleancache is done via debugfs in +the /sys/kernel/debug/mm/cleancache directory. The effectiveness of cleancache can be measured (across all filesystems) with: succ_gets - number of gets that were successful -- cgit v1.1 From 2b6783191da7211c88f98eb1a2bd2027bff36e30 Mon Sep 17 00:00:00 2001 From: Jim Cromie Date: Mon, 19 Dec 2011 17:13:12 -0500 Subject: dynamic_debug: add trim_prefix() to provide source-root relative paths trim_prefix(path) skips past the absolute source path root, and returns the pointer to the relative path from there. It is used to shorten the displayed path in $DBGMT/dynamic_debug/control via ddebug_proc_show(), and in ddebug_change() to allow relative filenames to be used in applied queries. For example: ~# echo file kernel/freezer.c +p > $DBGMT/dynamic_debug/control kernel/freezer.c:128 [freezer]cancel_freezing p " clean up: %s\012" trim_prefix(path) insures common prefix before trimming it, so out-of-tree module paths are shown as full absolute paths. Signed-off-by: Jim Cromie Signed-off-by: Jason Baron Signed-off-by: Greg Kroah-Hartman --- Documentation/dynamic-debug-howto.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt index f959909..378b5d1 100644 --- a/Documentation/dynamic-debug-howto.txt +++ b/Documentation/dynamic-debug-howto.txt @@ -144,11 +144,12 @@ func func svc_tcp_accept file - The given string is compared against either the full - pathname or the basename of the source file of each - callsite. Examples: + The given string is compared against either the full pathname, the + src-root relative pathname, or the basename of the source file of + each callsite. Examples: file svcsock.c + file kernel/freezer.c file /usr/src/packages/BUILD/sgi-enhancednfs-1.4/default/net/sunrpc/svcsock.c module -- cgit v1.1 From 85f7f6c0edb8414053d788229c97d5ecff21efab Mon Sep 17 00:00:00 2001 From: Jim Cromie Date: Mon, 19 Dec 2011 17:13:21 -0500 Subject: dynamic_debug: process multiple debug-queries on a line Insert ddebug_exec_queries() in place of ddebug_exec_query(). It splits the query string on [;\n], and calls ddebug_exec_query() on each. All queries are processed independent of errors, allowing a query to fail, for example when a module is not installed. Empty lines and comments are skipped. Errors are counted, and the last error seen (negative) or the number of callsites found (0 or positive) is returned. Return code checks are altered accordingly. With this, multiple queries can be given in ddebug_query, allowing more selective enabling of callsites. As a side effect, a set of commands can be batched in: cat cmd-file > $DBGMT/dynamic_debug/control We dont want a ddebug_query syntax error to kill the dynamic debug facility, so dynamic_debug_init() zeros ddebug_exec_queries()'s return code after logging the appropriate message, so that ddebug tables are preserved and $DBGMT/dynamic_debug/control file is created. This would be appropriate even without accepting multiple queries. This patch also alters ddebug_change() to return number of callsites matched (which typically is the same as number of callsites changed). ddebug_exec_query() also returns the number found, or a negative value if theres a parse error on the query. Splitting on [;\n] prevents their use in format-specs, but selecting callsites on punctuation is brittle anyway, meaningful and selective substrings are more typical. Note: splitting queries on ';' before handling trailing #comments means that a ';' also terminates a comment, and text after the ';' is treated as another query. This trailing query will almost certainly result in a parse error and thus have no effect other than the error message. The double corner case with unexpected results is: ddebug_query="func foo +p # enable foo ; +p" Signed-off-by: Jim Cromie Signed-off-by: Jason Baron Signed-off-by: Greg Kroah-Hartman --- Documentation/dynamic-debug-howto.txt | 23 ++++++++--------------- 1 file changed, 8 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/dynamic-debug-howto.txt b/Documentation/dynamic-debug-howto.txt index 378b5d1..74e6c77 100644 --- a/Documentation/dynamic-debug-howto.txt +++ b/Documentation/dynamic-debug-howto.txt @@ -12,7 +12,7 @@ dynamically enabled per-callsite. Dynamic debug has even more useful features: * Simple query language allows turning on and off debugging statements by - matching any combination of: + matching any combination of 0 or 1 of: - source filename - function name @@ -79,31 +79,24 @@ Command Language Reference ========================== At the lexical level, a command comprises a sequence of words separated -by whitespace characters. Note that newlines are treated as word -separators and do *not* end a command or allow multiple commands to -be done together. So these are all equivalent: +by spaces or tabs. So these are all equivalent: nullarbor:~ # echo -c 'file svcsock.c line 1603 +p' > /dynamic_debug/control nullarbor:~ # echo -c ' file svcsock.c line 1603 +p ' > /dynamic_debug/control -nullarbor:~ # echo -c 'file svcsock.c\nline 1603 +p' > - /dynamic_debug/control nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' > /dynamic_debug/control -Commands are bounded by a write() system call. If you want to do -multiple commands you need to do a separate "echo" for each, like: +Command submissions are bounded by a write() system call. +Multiple commands can be written together, separated by ';' or '\n'. -nullarbor:~ # echo 'file svcsock.c line 1603 +p' > /proc/dprintk ;\ -> echo 'file svcsock.c line 1563 +p' > /proc/dprintk + ~# echo "func pnpacpi_get_resources +p; func pnp_assign_mem +p" \ + > /dynamic_debug/control -or even like: +If your query set is big, you can batch them too: -nullarbor:~ # ( -> echo 'file svcsock.c line 1603 +p' ;\ -> echo 'file svcsock.c line 1563 +p' ;\ -> ) > /proc/dprintk + ~# cat query-batch-file > /dynamic_debug/control At the syntactical level, a command comprises a sequence of match specifications, followed by a flags change specification. -- cgit v1.1 From d6e486868cde585842d55ba3b6ec57af090fc343 Mon Sep 17 00:00:00 2001 From: Ludwig Nussel Date: Wed, 25 Jan 2012 11:52:28 +0100 Subject: debugfs: add mode, uid and gid options Cautious admins may want to restrict access to debugfs. Currently a manual chown/chmod e.g. in an init script is needed to achieve that. Distributions that want to make the mount options configurable need to add extra config files. By allowing to set the root inode's uid, gid and mode via mount options no such hacks are needed anymore. Instead configuration becomes straight forward via fstab. Signed-off-by: Ludwig Nussel Signed-off-by: Greg Kroah-Hartman --- Documentation/filesystems/debugfs.txt | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/debugfs.txt b/Documentation/filesystems/debugfs.txt index 6872c91..4e25758 100644 --- a/Documentation/filesystems/debugfs.txt +++ b/Documentation/filesystems/debugfs.txt @@ -14,7 +14,10 @@ Debugfs is typically mounted with a command like: mount -t debugfs none /sys/kernel/debug -(Or an equivalent /etc/fstab line). +(Or an equivalent /etc/fstab line). +The debugfs root directory is accessible by anyone by default. To +restrict access to the tree the "uid", "gid" and "mode" mount +options can be used. Note that the debugfs API is exported GPL-only to modules. -- cgit v1.1 From 3afbd89c9639c344300dcdd7d4e5e18dda559fd4 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= Date: Wed, 25 Jan 2012 09:05:04 +0100 Subject: serial/efm32: add new driver MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Uwe Kleine-König Signed-off-by: Greg Kroah-Hartman --- .../devicetree/bindings/tty/serial/efm32-uart.txt | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/tty/serial/efm32-uart.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt b/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt new file mode 100644 index 0000000..6588b69 --- /dev/null +++ b/Documentation/devicetree/bindings/tty/serial/efm32-uart.txt @@ -0,0 +1,14 @@ +* Energymicro efm32 UART + +Required properties: +- compatible : Should be "efm32,uart" +- reg : Address and length of the register set +- interrupts : Should contain uart interrupt + +Example: + +uart@0x4000c400 { + compatible = "efm32,uart"; + reg = <0x4000c400 0x400>; + interrupts = <15>; +}; -- cgit v1.1 From 91cfbd4ee0875f8a826731983378670012ba6e01 Mon Sep 17 00:00:00 2001 From: Thomas Abraham Date: Fri, 27 Jan 2012 15:25:00 +0900 Subject: ARM: EXYNOS: Hook up power domains to generic power domain infrastructure Add support for generic power domain for Exynos4 platforms and remove the Samsung specific power domain control for Exynos4. The generic power domain infrastructure is used to control the power domains available on Exynos4. For non-dt platforms, the power domains are statically instantiated. For dt platforms, the power domain nodes found in the device tree are instantiated. Cc: Kyungmin Park Cc: Rob Herring Cc: Grant Likely Signed-off-by: Thomas Abraham Acked-by: Rafael J. Wysocki Signed-off-by: Kukjin Kim --- .../devicetree/bindings/arm/exynos/power_domain.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) create mode 100644 Documentation/devicetree/bindings/arm/exynos/power_domain.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/exynos/power_domain.txt b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt new file mode 100644 index 0000000..6528e21 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/exynos/power_domain.txt @@ -0,0 +1,21 @@ +* Samsung Exynos Power Domains + +Exynos processors include support for multiple power domains which are used +to gate power to one or more peripherals on the processor. + +Required Properties: +- compatiable: should be one of the following. + * samsung,exynos4210-pd - for exynos4210 type power domain. +- reg: physical base address of the controller and length of memory mapped + region. + +Optional Properties: +- samsung,exynos4210-pd-off: Specifies that the power domain is in turned-off + state during boot and remains to be turned-off until explicitly turned-on. + +Example: + + lcd0: power-domain-lcd0 { + compatible = "samsung,exynos4210-pd"; + reg = <0x10023C00 0x10>; + }; -- cgit v1.1 From cf579dfb82550e34de7ccf3ef090d8b834ccd3a9 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Sun, 29 Jan 2012 20:38:29 +0100 Subject: PM / Sleep: Introduce "late suspend" and "early resume" of devices The current device suspend/resume phases during system-wide power transitions appear to be insufficient for some platforms that want to use the same callback routines for saving device states and related operations during runtime suspend/resume as well as during system suspend/resume. In principle, they could point their .suspend_noirq() and .resume_noirq() to the same callback routines as their .runtime_suspend() and .runtime_resume(), respectively, but at least some of them require device interrupts to be enabled while the code in those routines is running. It also makes sense to have device suspend-resume callbacks that will be executed with runtime PM disabled and with device interrupts enabled in case someone needs to run some special code in that context during system-wide power transitions. Apart from this, .suspend_noirq() and .resume_noirq() were introduced as a workaround for drivers using shared interrupts and failing to prevent their interrupt handlers from accessing suspended hardware. It appears to be better not to use them for other porposes, or we may have to deal with some serious confusion (which seems to be happening already). For the above reasons, introduce new device suspend/resume phases, "late suspend" and "early resume" (and analogously for hibernation) whose callback will be executed with runtime PM disabled and with device interrupts enabled and whose callback pointers generally may point to runtime suspend/resume routines. Signed-off-by: Rafael J. Wysocki Reviewed-by: Mark Brown Reviewed-by: Kevin Hilman --- Documentation/power/devices.txt | 93 +++++++++++++++++++++++++++-------------- 1 file changed, 61 insertions(+), 32 deletions(-) (limited to 'Documentation') diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index 20af7de..872815c 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -96,6 +96,12 @@ struct dev_pm_ops { int (*thaw)(struct device *dev); int (*poweroff)(struct device *dev); int (*restore)(struct device *dev); + int (*suspend_late)(struct device *dev); + int (*resume_early)(struct device *dev); + int (*freeze_late)(struct device *dev); + int (*thaw_early)(struct device *dev); + int (*poweroff_late)(struct device *dev); + int (*restore_early)(struct device *dev); int (*suspend_noirq)(struct device *dev); int (*resume_noirq)(struct device *dev); int (*freeze_noirq)(struct device *dev); @@ -305,7 +311,7 @@ Entering System Suspend ----------------------- When the system goes into the standby or memory sleep state, the phases are: - prepare, suspend, suspend_noirq. + prepare, suspend, suspend_late, suspend_noirq. 1. The prepare phase is meant to prevent races by preventing new devices from being registered; the PM core would never know that all the @@ -324,7 +330,12 @@ When the system goes into the standby or memory sleep state, the phases are: appropriate low-power state, depending on the bus type the device is on, and they may enable wakeup events. - 3. The suspend_noirq phase occurs after IRQ handlers have been disabled, + 3 For a number of devices it is convenient to split suspend into the + "quiesce device" and "save device state" phases, in which cases + suspend_late is meant to do the latter. It is always executed after + runtime power management has been disabled for all devices. + + 4. The suspend_noirq phase occurs after IRQ handlers have been disabled, which means that the driver's interrupt handler will not be called while the callback method is running. The methods should save the values of the device's registers that weren't saved previously and finally put the @@ -359,7 +370,7 @@ Leaving System Suspend ---------------------- When resuming from standby or memory sleep, the phases are: - resume_noirq, resume, complete. + resume_noirq, resume_early, resume, complete. 1. The resume_noirq callback methods should perform any actions needed before the driver's interrupt handlers are invoked. This generally @@ -375,14 +386,18 @@ When resuming from standby or memory sleep, the phases are: device driver's ->pm.resume_noirq() method to perform device-specific actions. - 2. The resume methods should bring the the device back to its operating + 2. The resume_early methods should prepare devices for the execution of + the resume methods. This generally involves undoing the actions of the + preceding suspend_late phase. + + 3 The resume methods should bring the the device back to its operating state, so that it can perform normal I/O. This generally involves undoing the actions of the suspend phase. - 3. The complete phase uses only a bus callback. The method should undo the - actions of the prepare phase. Note, however, that new children may be - registered below the device as soon as the resume callbacks occur; it's - not necessary to wait until the complete phase. + 4. The complete phase should undo the actions of the prepare phase. Note, + however, that new children may be registered below the device as soon as + the resume callbacks occur; it's not necessary to wait until the + complete phase. At the end of these phases, drivers should be as functional as they were before suspending: I/O can be performed using DMA and IRQs, and the relevant clocks are @@ -429,8 +444,8 @@ an image of the system memory while everything is stable, reactivate all devices (thaw), write the image to permanent storage, and finally shut down the system (poweroff). The phases used to accomplish this are: - prepare, freeze, freeze_noirq, thaw_noirq, thaw, complete, - prepare, poweroff, poweroff_noirq + prepare, freeze, freeze_late, freeze_noirq, thaw_noirq, thaw_early, + thaw, complete, prepare, poweroff, poweroff_late, poweroff_noirq 1. The prepare phase is discussed in the "Entering System Suspend" section above. @@ -441,7 +456,11 @@ system (poweroff). The phases used to accomplish this are: save time it's best not to do so. Also, the device should not be prepared to generate wakeup events. - 3. The freeze_noirq phase is analogous to the suspend_noirq phase discussed + 3. The freeze_late phase is analogous to the suspend_late phase described + above, except that the device should not be put in a low-power state and + should not be allowed to generate wakeup events by it. + + 4. The freeze_noirq phase is analogous to the suspend_noirq phase discussed above, except again that the device should not be put in a low-power state and should not be allowed to generate wakeup events. @@ -449,15 +468,19 @@ At this point the system image is created. All devices should be inactive and the contents of memory should remain undisturbed while this happens, so that the image forms an atomic snapshot of the system state. - 4. The thaw_noirq phase is analogous to the resume_noirq phase discussed + 5. The thaw_noirq phase is analogous to the resume_noirq phase discussed above. The main difference is that its methods can assume the device is in the same state as at the end of the freeze_noirq phase. - 5. The thaw phase is analogous to the resume phase discussed above. Its + 6. The thaw_early phase is analogous to the resume_early phase described + above. Its methods should undo the actions of the preceding + freeze_late, if necessary. + + 7. The thaw phase is analogous to the resume phase discussed above. Its methods should bring the device back to an operating state, so that it can be used for saving the image if necessary. - 6. The complete phase is discussed in the "Leaving System Suspend" section + 8. The complete phase is discussed in the "Leaving System Suspend" section above. At this point the system image is saved, and the devices then need to be @@ -465,16 +488,19 @@ prepared for the upcoming system shutdown. This is much like suspending them before putting the system into the standby or memory sleep state, and the phases are similar. - 7. The prepare phase is discussed above. + 9. The prepare phase is discussed above. + + 10. The poweroff phase is analogous to the suspend phase. - 8. The poweroff phase is analogous to the suspend phase. + 11. The poweroff_late phase is analogous to the suspend_late phase. - 9. The poweroff_noirq phase is analogous to the suspend_noirq phase. + 12. The poweroff_noirq phase is analogous to the suspend_noirq phase. -The poweroff and poweroff_noirq callbacks should do essentially the same things -as the suspend and suspend_noirq callbacks. The only notable difference is that -they need not store the device register values, because the registers should -already have been stored during the freeze or freeze_noirq phases. +The poweroff, poweroff_late and poweroff_noirq callbacks should do essentially +the same things as the suspend, suspend_late and suspend_noirq callbacks, +respectively. The only notable difference is that they need not store the +device register values, because the registers should already have been stored +during the freeze, freeze_late or freeze_noirq phases. Leaving Hibernation @@ -518,22 +544,25 @@ To achieve this, the image kernel must restore the devices' pre-hibernation functionality. The operation is much like waking up from the memory sleep state, although it involves different phases: - restore_noirq, restore, complete + restore_noirq, restore_early, restore, complete 1. The restore_noirq phase is analogous to the resume_noirq phase. - 2. The restore phase is analogous to the resume phase. + 2. The restore_early phase is analogous to the resume_early phase. + + 3. The restore phase is analogous to the resume phase. - 3. The complete phase is discussed above. + 4. The complete phase is discussed above. -The main difference from resume[_noirq] is that restore[_noirq] must assume the -device has been accessed and reconfigured by the boot loader or the boot kernel. -Consequently the state of the device may be different from the state remembered -from the freeze and freeze_noirq phases. The device may even need to be reset -and completely re-initialized. In many cases this difference doesn't matter, so -the resume[_noirq] and restore[_norq] method pointers can be set to the same -routines. Nevertheless, different callback pointers are used in case there is a -situation where it actually matters. +The main difference from resume[_early|_noirq] is that restore[_early|_noirq] +must assume the device has been accessed and reconfigured by the boot loader or +the boot kernel. Consequently the state of the device may be different from the +state remembered from the freeze, freeze_late and freeze_noirq phases. The +device may even need to be reset and completely re-initialized. In many cases +this difference doesn't matter, so the resume[_early|_noirq] and +restore[_early|_norq] method pointers can be set to the same routines. +Nevertheless, different callback pointers are used in case there is a situation +where it actually does matter. Device Power Management Domains -- cgit v1.1 From 3396c7823efb3a5b8630388c464e1034ea031ced Mon Sep 17 00:00:00 2001 From: Paul Gortmaker Date: Fri, 27 Jan 2012 13:36:01 +0000 Subject: drivers/net: fix up stale paths from driver reorg The reorganization of the driver layout in drivers/net left behind some stale paths in comments and in Kconfig help text. Bring them up to date. No actual change to any code takes place here. Signed-off-by: Paul Gortmaker CC: Jeff Kirsher Signed-off-by: David S. Miller --- Documentation/magic-number.txt | 2 +- Documentation/networking/phy.txt | 3 ++- Documentation/zh_CN/magic-number.txt | 2 +- 3 files changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/magic-number.txt b/Documentation/magic-number.txt index abf481f..82761a3 100644 --- a/Documentation/magic-number.txt +++ b/Documentation/magic-number.txt @@ -89,7 +89,7 @@ TTY_DRIVER_MAGIC 0x5402 tty_driver include/linux/tty_driver.h MGSLPC_MAGIC 0x5402 mgslpc_info drivers/char/pcmcia/synclink_cs.c TTY_LDISC_MAGIC 0x5403 tty_ldisc include/linux/tty_ldisc.h USB_SERIAL_MAGIC 0x6702 usb_serial drivers/usb/serial/usb-serial.h -FULL_DUPLEX_MAGIC 0x6969 drivers/net/tulip/de2104x.c +FULL_DUPLEX_MAGIC 0x6969 drivers/net/ethernet/dec/tulip/de2104x.c USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth drivers/usb/class/bluetty.c RFCOMM_TTY_MAGIC 0x6d02 net/bluetooth/rfcomm/tty.c USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port drivers/usb/serial/usb-serial.h diff --git a/Documentation/networking/phy.txt b/Documentation/networking/phy.txt index 9eb1ba5..95e5f59 100644 --- a/Documentation/networking/phy.txt +++ b/Documentation/networking/phy.txt @@ -62,7 +62,8 @@ The MDIO bus 5) The bus must also be declared somewhere as a device, and registered. As an example for how one driver implemented an mdio bus driver, see - drivers/net/gianfar_mii.c and arch/ppc/syslib/mpc85xx_devices.c + drivers/net/ethernet/freescale/fsl_pq_mdio.c and an associated DTS file + for one of the users. (e.g. "git grep fsl,.*-mdio arch/powerpc/boot/dts/") Connecting to a PHY diff --git a/Documentation/zh_CN/magic-number.txt b/Documentation/zh_CN/magic-number.txt index c278f41..f606ba8 100644 --- a/Documentation/zh_CN/magic-number.txt +++ b/Documentation/zh_CN/magic-number.txt @@ -89,7 +89,7 @@ TTY_DRIVER_MAGIC 0x5402 tty_driver include/linux/tty_driver.h MGSLPC_MAGIC 0x5402 mgslpc_info drivers/char/pcmcia/synclink_cs.c TTY_LDISC_MAGIC 0x5403 tty_ldisc include/linux/tty_ldisc.h USB_SERIAL_MAGIC 0x6702 usb_serial drivers/usb/serial/usb-serial.h -FULL_DUPLEX_MAGIC 0x6969 drivers/net/tulip/de2104x.c +FULL_DUPLEX_MAGIC 0x6969 drivers/net/ethernet/dec/tulip/de2104x.c USB_BLUETOOTH_MAGIC 0x6d02 usb_bluetooth drivers/usb/class/bluetty.c RFCOMM_TTY_MAGIC 0x6d02 net/bluetooth/rfcomm/tty.c USB_SERIAL_PORT_MAGIC 0x7301 usb_serial_port drivers/usb/serial/usb-serial.h -- cgit v1.1 From c1432b1ebc684890ac81915695617ff4adfec357 Mon Sep 17 00:00:00 2001 From: Axel Lin Date: Tue, 31 Jan 2012 14:44:01 +0800 Subject: regulator: add devm_regulator_* to the list of managed interfaces Add devm_regulator_put() and devm_regulator_bulk_get() to the list of managed interfaces. Signed-off-by: Axel Lin Acked-by: Tejun Heo Signed-off-by: Mark Brown --- Documentation/driver-model/devres.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/driver-model/devres.txt b/Documentation/driver-model/devres.txt index 016fd2b..0cab4af 100644 --- a/Documentation/driver-model/devres.txt +++ b/Documentation/driver-model/devres.txt @@ -270,3 +270,5 @@ IOMAP REGULATOR devm_regulator_get() + devm_regulator_put() + devm_regulator_bulk_get() -- cgit v1.1 From 919c1e541dd766085546a620bd5569506d9033ce Mon Sep 17 00:00:00 2001 From: Leon Romanovsky Date: Tue, 31 Jan 2012 09:29:45 +0200 Subject: ASoC: ALC5632: Add device tree binding documentation Document the device tree binding for the ALC5632 codec and update vendor specific prefix for the Realtek. Signed-off-by: Leon Romanovsky Acked-by: Stephen Warren Signed-off-by: Mark Brown --- .../devicetree/bindings/sound/alc5632.txt | 24 ++++++++++++++++++++++ .../devicetree/bindings/vendor-prefixes.txt | 1 + 2 files changed, 25 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/alc5632.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/alc5632.txt b/Documentation/devicetree/bindings/sound/alc5632.txt new file mode 100644 index 0000000..8608f74 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/alc5632.txt @@ -0,0 +1,24 @@ +ALC5632 audio CODEC + +This device supports I2C only. + +Required properties: + + - compatible : "realtek,alc5632" + + - reg : the I2C address of the device. + + - gpio-controller : Indicates this device is 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: + +alc5632: alc5632@1e { + compatible = "realtek,alc5632"; + reg = <0x1a>; + + gpio-controller; + #gpio-cells = <2>; +}; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ecc6a6c..ca8ee14 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -33,6 +33,7 @@ nxp NXP Semiconductors powervr Imagination Technologies qcom Qualcomm, Inc. ramtron Ramtron International +realtek Realtek Semiconductor Corp. samsung Samsung Semiconductor sbs Smart Battery System schindler Schindler -- cgit v1.1 From 761bfdd91184c6662a9233976e855b4ccb883c96 Mon Sep 17 00:00:00 2001 From: Leon Romanovsky Date: Tue, 31 Jan 2012 09:30:40 +0200 Subject: ASoC: Tegra+ALC5632 machine: Add device tree binding documentation Document device tree binding for the tegra board with ALC5632 codec according to datasheet functional block description. Signed-off-by: Leon Romanovsky Acked-by: Stephen Warren Signed-off-by: Mark Brown --- .../bindings/sound/tegra-audio-alc5632.txt | 57 ++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt b/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt new file mode 100644 index 0000000..65b001e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt @@ -0,0 +1,57 @@ +NVIDIA Tegra audio complex + +Required properties: +- compatible : "nvidia,tegra-audio-alc5632" +- nvidia,model : The user-visible name of this sound complex. +- nvidia,audio-routing : A list of the connections between audio components. + Each entry is a pair of strings, the first being the connection's sink, + the second being the connection's source. Valid names for sources and + sinks are the ALC5632's pins: + + ALC5632 pins: + + * SPK_OUTP + * SPK_OUTN + * HP_OUT_L + * HP_OUT_R + * AUX_OUT_P + * AUX_OUT_N + * LINE_IN_L + * LINE_IN_R + * PHONE_P + * PHONE_N + * MIC1_P + * MIC1_N + * MIC2_P + * MIC2_N + * MICBIAS1 + + Board connectors: + + * Headset Stereophone + * Int Spk + * Headset Mic + +- nvidia,i2s-controller : The phandle of the Tegra I2S controller +- nvidia,audio-codec : The phandle of the ALC5632 audio codec + +Example: + +sound { + compatible = "nvidia,tegra-audio-alc5632-paz00", + "nvidia,tegra-audio-alc5632"; + + nvidia,model = "Compal PAZ00"; + + nvidia,audio-routing = + "Int Spk", "SPK_OUTP", + "Int Spk", "SPK_OUTN", + "Headset Mic","MICBIAS1", + "MIC1_N", "Headset Mic", + "MIC1_P", "Headset Mic", + "Headset Stereophone", "HP_OUT_R", + "Headset Stereophone", "HP_OUT_L"; + + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&alc5632>; +}; -- cgit v1.1 From 9dfac4fd7f8cdcdf734dff2ccc7ca467f53f1cfd Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Wed, 1 Feb 2012 18:02:47 +0100 Subject: pinctrl: delete raw device pointers in pinmux maps After discussion with Mark Brown in an unrelated thread about ADC lookups, it came to my knowledge that the ability to pass a struct device * in the regulator consumers is just a historical artifact, and not really recommended. Since there are no in-kernel users of these pointers, we just kill them right now, before someone starts to use them. Reviewed-by: Mark Brown Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 150fd38..14aecd2 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -805,10 +805,7 @@ must match a function provided by the pinmux driver handling this pin range. As you can see we may have several pin controllers on the system and thus we need to specify which one of them that contain the functions we wish -to map. The map can also use struct device * directly, so there is no -inherent need to use strings to specify .dev_name or .ctrl_dev_name, these -are for the situation where you do not have a handle to the struct device *, -for example if they are not yet instantiated or cumbersome to obtain. +to map. You register this pinmux mapping to the pinmux subsystem by simply: -- cgit v1.1 From 5411972995b27a9074062b6d8e106fc15bd1cd44 Mon Sep 17 00:00:00 2001 From: Vaibhav Hiremath Date: Wed, 1 Feb 2012 11:57:00 +0530 Subject: arm/dts: OMAP3: Add omap3evm and am335xevm support TI's OMAP3EVM and AM335xEVM are software development boards available for OMAP35x(AM/DM37x) and AM335x devices respectively; and these devices are considered under omap3 family. Signed-off-by: Vaibhav Hiremath Cc: Benoit Cousson Cc: Grant Likely Cc: Tony Lindgren Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/arm/omap/omap.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index dbdab40..ce78498 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -41,3 +41,9 @@ Boards: - OMAP4 PandaBoard : Low cost community board compatible = "ti,omap4-panda", "ti,omap4430" + +- OMAP3 EVM : Software Developement Board for OMAP35x, AM/DM37x + compatible = "ti,omap3-evm", "ti,omap3" + +- AM335X EVM : Software Developement Board for AM335x + compatible = "ti,am335x-evm", "ti,am33xx", "ti,omap3" -- cgit v1.1 From 761b3ef50e1c2649cffbfa67a4dcb2dcdb7982ed Mon Sep 17 00:00:00 2001 From: Li Zefan Date: Tue, 31 Jan 2012 13:47:36 +0800 Subject: cgroup: remove cgroup_subsys argument from callbacks The argument is not used at all, and it's not necessary, because a specific callback handler of course knows which subsys it belongs to. Now only ->pupulate() takes this argument, because the handlers of this callback always call cgroup_add_file()/cgroup_add_files(). So we reduce a few lines of code, though the shrinking of object size is minimal. 16 files changed, 113 insertions(+), 162 deletions(-) text data bss dec hex filename 5486240 656987 7039960 13183187 c928d3 vmlinux.o.orig 5486170 656987 7039960 13183117 c9288d vmlinux.o Signed-off-by: Li Zefan Signed-off-by: Tejun Heo --- Documentation/cgroups/cgroups.txt | 26 +++++++++++--------------- 1 file changed, 11 insertions(+), 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index a7c96ae..8e74980 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -558,8 +558,7 @@ Each subsystem may export the following methods. The only mandatory methods are create/destroy. Any others that are null are presumed to be successful no-ops. -struct cgroup_subsys_state *create(struct cgroup_subsys *ss, - struct cgroup *cgrp) +struct cgroup_subsys_state *create(struct cgroup *cgrp) (cgroup_mutex held by caller) Called to create a subsystem state object for a cgroup. The @@ -574,7 +573,7 @@ identified by the passed cgroup object having a NULL parent (since it's the root of the hierarchy) and may be an appropriate place for initialization code. -void destroy(struct cgroup_subsys *ss, struct cgroup *cgrp) +void destroy(struct cgroup *cgrp) (cgroup_mutex held by caller) The cgroup system is about to destroy the passed cgroup; the subsystem @@ -585,7 +584,7 @@ cgroup->parent is still valid. (Note - can also be called for a newly-created cgroup if an error occurs after this subsystem's create() method has been called for the new cgroup). -int pre_destroy(struct cgroup_subsys *ss, struct cgroup *cgrp); +int pre_destroy(struct cgroup *cgrp); Called before checking the reference count on each subsystem. This may be useful for subsystems which have some extra references even if @@ -593,8 +592,7 @@ there are not tasks in the cgroup. If pre_destroy() returns error code, rmdir() will fail with it. From this behavior, pre_destroy() can be called multiple times against a cgroup. -int can_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, - struct cgroup_taskset *tset) +int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset) (cgroup_mutex held by caller) Called prior to moving one or more tasks into a cgroup; if the @@ -615,8 +613,7 @@ fork. If this method returns 0 (success) then this should remain valid while the caller holds cgroup_mutex and it is ensured that either attach() or cancel_attach() will be called in future. -void cancel_attach(struct cgroup_subsys *ss, struct cgroup *cgrp, - struct cgroup_taskset *tset) +void cancel_attach(struct cgroup *cgrp, struct cgroup_taskset *tset) (cgroup_mutex held by caller) Called when a task attach operation has failed after can_attach() has succeeded. @@ -625,23 +622,22 @@ function, so that the subsystem can implement a rollback. If not, not necessary. This will be called only about subsystems whose can_attach() operation have succeeded. The parameters are identical to can_attach(). -void attach(struct cgroup_subsys *ss, struct cgroup *cgrp, - struct cgroup_taskset *tset) +void attach(struct cgroup *cgrp, struct cgroup_taskset *tset) (cgroup_mutex held by caller) Called after the task has been attached to the cgroup, to allow any post-attachment activity that requires memory allocations or blocking. The parameters are identical to can_attach(). -void fork(struct cgroup_subsy *ss, struct task_struct *task) +void fork(struct task_struct *task) Called when a task is forked into a cgroup. -void exit(struct cgroup_subsys *ss, struct task_struct *task) +void exit(struct task_struct *task) Called during task exit. -int populate(struct cgroup_subsys *ss, struct cgroup *cgrp) +int populate(struct cgroup *cgrp) (cgroup_mutex held by caller) Called after creation of a cgroup to allow a subsystem to populate @@ -651,7 +647,7 @@ include/linux/cgroup.h for details). Note that although this method can return an error code, the error code is currently not always handled well. -void post_clone(struct cgroup_subsys *ss, struct cgroup *cgrp) +void post_clone(struct cgroup *cgrp) (cgroup_mutex held by caller) Called during cgroup_create() to do any parameter @@ -659,7 +655,7 @@ initialization which might be required before a task could attach. For example in cpusets, no task may attach before 'cpus' and 'mems' are set up. -void bind(struct cgroup_subsys *ss, struct cgroup *root) +void bind(struct cgroup *root) (cgroup_mutex and ss->hierarchy_mutex held by caller) Called when a cgroup subsystem is rebound to a different hierarchy -- cgit v1.1 From 97bf2262e7f8177706ecdac897be165c0b455c6f Mon Sep 17 00:00:00 2001 From: Sritej Velaga Date: Fri, 3 Feb 2012 14:06:48 +0000 Subject: qlge: Updating Schultz LICENSE.qlge file. Signed-off-by: Sritej Velaga Signed-off-by: Jitendra Kalsaria Signed-off-by: David S. Miller --- Documentation/networking/LICENSE.qlge | 328 +++++++++++++++++++++++++++++----- 1 file changed, 285 insertions(+), 43 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/LICENSE.qlge b/Documentation/networking/LICENSE.qlge index 123b6ed..ce64e4d 100644 --- a/Documentation/networking/LICENSE.qlge +++ b/Documentation/networking/LICENSE.qlge @@ -1,46 +1,288 @@ -Copyright (c) 2003-2008 QLogic Corporation -QLogic Linux Networking HBA Driver +Copyright (c) 2003-2011 QLogic Corporation +QLogic Linux qlge NIC Driver -This program includes a device driver for Linux 2.6 that may be -distributed with QLogic hardware specific firmware binary file. You may modify and redistribute the device driver code under the -GNU General Public License as published by the Free Software -Foundation (version 2 or a later version). - -You may redistribute the hardware specific firmware binary file -under the following terms: - - 1. Redistribution of source code (only if applicable), - must retain the above copyright notice, this list of - conditions and the following disclaimer. - - 2. Redistribution in binary form must reproduce the above - copyright notice, this list of conditions and the - following disclaimer in the documentation and/or other - materials provided with the distribution. - - 3. The name of QLogic Corporation may not be used to - endorse or promote products derived from this software - without specific prior written permission - -REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE, -THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY -EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A -PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR -BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, -EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED -TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON -ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, -OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE -POSSIBILITY OF SUCH DAMAGE. - -USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT -CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR -OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT, -TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN -ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN -COMBINATION WITH THIS PROGRAM. +GNU General Public License (a copy of which is attached hereto as +Exhibit A) published by the Free Software Foundation (version 2). + +EXHIBIT A + + GNU GENERAL PUBLIC LICENSE + Version 2, June 1991 + + Copyright (C) 1989, 1991 Free Software Foundation, Inc. + 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + Everyone is permitted to copy and distribute verbatim copies + of this license document, but changing it is not allowed. + + Preamble + + The licenses for most software are designed to take away your +freedom to share and change it. By contrast, the GNU General Public +License is intended to guarantee your freedom to share and change free +software--to make sure the software is free for all its users. This +General Public License applies to most of the Free Software +Foundation's software and to any other program whose authors commit to +using it. (Some other Free Software Foundation software is covered by +the GNU Lesser General Public License instead.) You can apply it to +your programs, too. + + When we speak of free software, we are referring to freedom, not +price. Our General Public Licenses are designed to make sure that you +have the freedom to distribute copies of free software (and charge for +this service if you wish), that you receive source code or can get it +if you want it, that you can change the software or use pieces of it +in new free programs; and that you know you can do these things. + + To protect your rights, we need to make restrictions that forbid +anyone to deny you these rights or to ask you to surrender the rights. +These restrictions translate to certain responsibilities for you if you +distribute copies of the software, or if you modify it. + + For example, if you distribute copies of such a program, whether +gratis or for a fee, you must give the recipients all the rights that +you have. You must make sure that they, too, receive or can get the +source code. And you must show them these terms so they know their +rights. + + We protect your rights with two steps: (1) copyright the software, and +(2) offer you this license which gives you legal permission to copy, +distribute and/or modify the software. + + Also, for each author's protection and ours, we want to make certain +that everyone understands that there is no warranty for this free +software. If the software is modified by someone else and passed on, we +want its recipients to know that what they have is not the original, so +that any problems introduced by others will not reflect on the original +authors' reputations. + + Finally, any free program is threatened constantly by software +patents. We wish to avoid the danger that redistributors of a free +program will individually obtain patent licenses, in effect making the +program proprietary. To prevent this, we have made it clear that any +patent must be licensed for everyone's free use or not licensed at all. + + The precise terms and conditions for copying, distribution and +modification follow. + + GNU GENERAL PUBLIC LICENSE + TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION + + 0. This License applies to any program or other work which contains +a notice placed by the copyright holder saying it may be distributed +under the terms of this General Public License. The "Program", below, +refers to any such program or work, and a "work based on the Program" +means either the Program or any derivative work under copyright law: +that is to say, a work containing the Program or a portion of it, +either verbatim or with modifications and/or translated into another +language. (Hereinafter, translation is included without limitation in +the term "modification".) Each licensee is addressed as "you". + +Activities other than copying, distribution and modification are not +covered by this License; they are outside its scope. The act of +running the Program is not restricted, and the output from the Program +is covered only if its contents constitute a work based on the +Program (independent of having been made by running the Program). +Whether that is true depends on what the Program does. + + 1. You may copy and distribute verbatim copies of the Program's +source code as you receive it, in any medium, provided that you +conspicuously and appropriately publish on each copy an appropriate +copyright notice and disclaimer of warranty; keep intact all the +notices that refer to this License and to the absence of any warranty; +and give any other recipients of the Program a copy of this License +along with the Program. + +You may charge a fee for the physical act of transferring a copy, and +you may at your option offer warranty protection in exchange for a fee. + + 2. You may modify your copy or copies of the Program or any portion +of it, thus forming a work based on the Program, and copy and +distribute such modifications or work under the terms of Section 1 +above, provided that you also meet all of these conditions: + + a) You must cause the modified files to carry prominent notices + stating that you changed the files and the date of any change. + + b) You must cause any work that you distribute or publish, that in + whole or in part contains or is derived from the Program or any + part thereof, to be licensed as a whole at no charge to all third + parties under the terms of this License. + + c) If the modified program normally reads commands interactively + when run, you must cause it, when started running for such + interactive use in the most ordinary way, to print or display an + announcement including an appropriate copyright notice and a + notice that there is no warranty (or else, saying that you provide + a warranty) and that users may redistribute the program under + these conditions, and telling the user how to view a copy of this + License. (Exception: if the Program itself is interactive but + does not normally print such an announcement, your work based on + the Program is not required to print an announcement.) + +These requirements apply to the modified work as a whole. If +identifiable sections of that work are not derived from the Program, +and can be reasonably considered independent and separate works in +themselves, then this License, and its terms, do not apply to those +sections when you distribute them as separate works. But when you +distribute the same sections as part of a whole which is a work based +on the Program, the distribution of the whole must be on the terms of +this License, whose permissions for other licensees extend to the +entire whole, and thus to each and every part regardless of who wrote it. + +Thus, it is not the intent of this section to claim rights or contest +your rights to work written entirely by you; rather, the intent is to +exercise the right to control the distribution of derivative or +collective works based on the Program. + +In addition, mere aggregation of another work not based on the Program +with the Program (or with a work based on the Program) on a volume of +a storage or distribution medium does not bring the other work under +the scope of this License. + + 3. You may copy and distribute the Program (or a work based on it, +under Section 2) in object code or executable form under the terms of +Sections 1 and 2 above provided that you also do one of the following: + + a) Accompany it with the complete corresponding machine-readable + source code, which must be distributed under the terms of Sections + 1 and 2 above on a medium customarily used for software interchange; or, + + b) Accompany it with a written offer, valid for at least three + years, to give any third party, for a charge no more than your + cost of physically performing source distribution, a complete + machine-readable copy of the corresponding source code, to be + distributed under the terms of Sections 1 and 2 above on a medium + customarily used for software interchange; or, + + c) Accompany it with the information you received as to the offer + to distribute corresponding source code. (This alternative is + allowed only for noncommercial distribution and only if you + received the program in object code or executable form with such + an offer, in accord with Subsection b above.) + +The source code for a work means the preferred form of the work for +making modifications to it. For an executable work, complete source +code means all the source code for all modules it contains, plus any +associated interface definition files, plus the scripts used to +control compilation and installation of the executable. However, as a +special exception, the source code distributed need not include +anything that is normally distributed (in either source or binary +form) with the major components (compiler, kernel, and so on) of the +operating system on which the executable runs, unless that component +itself accompanies the executable. + +If distribution of executable or object code is made by offering +access to copy from a designated place, then offering equivalent +access to copy the source code from the same place counts as +distribution of the source code, even though third parties are not +compelled to copy the source along with the object code. + + 4. You may not copy, modify, sublicense, or distribute the Program +except as expressly provided under this License. Any attempt +otherwise to copy, modify, sublicense or distribute the Program is +void, and will automatically terminate your rights under this License. +However, parties who have received copies, or rights, from you under +this License will not have their licenses terminated so long as such +parties remain in full compliance. + + 5. You are not required to accept this License, since you have not +signed it. However, nothing else grants you permission to modify or +distribute the Program or its derivative works. These actions are +prohibited by law if you do not accept this License. Therefore, by +modifying or distributing the Program (or any work based on the +Program), you indicate your acceptance of this License to do so, and +all its terms and conditions for copying, distributing or modifying +the Program or works based on it. + + 6. Each time you redistribute the Program (or any work based on the +Program), the recipient automatically receives a license from the +original licensor to copy, distribute or modify the Program subject to +these terms and conditions. You may not impose any further +restrictions on the recipients' exercise of the rights granted herein. +You are not responsible for enforcing compliance by third parties to +this License. + + 7. If, as a consequence of a court judgment or allegation of patent +infringement or for any other reason (not limited to patent issues), +conditions are imposed on you (whether by court order, agreement or +otherwise) that contradict the conditions of this License, they do not +excuse you from the conditions of this License. If you cannot +distribute so as to satisfy simultaneously your obligations under this +License and any other pertinent obligations, then as a consequence you +may not distribute the Program at all. For example, if a patent +license would not permit royalty-free redistribution of the Program by +all those who receive copies directly or indirectly through you, then +the only way you could satisfy both it and this License would be to +refrain entirely from distribution of the Program. + +If any portion of this section is held invalid or unenforceable under +any particular circumstance, the balance of the section is intended to +apply and the section as a whole is intended to apply in other +circumstances. + +It is not the purpose of this section to induce you to infringe any +patents or other property right claims or to contest validity of any +such claims; this section has the sole purpose of protecting the +integrity of the free software distribution system, which is +implemented by public license practices. Many people have made +generous contributions to the wide range of software distributed +through that system in reliance on consistent application of that +system; it is up to the author/donor to decide if he or she is willing +to distribute software through any other system and a licensee cannot +impose that choice. + +This section is intended to make thoroughly clear what is believed to +be a consequence of the rest of this License. + + 8. If the distribution and/or use of the Program is restricted in +certain countries either by patents or by copyrighted interfaces, the +original copyright holder who places the Program under this License +may add an explicit geographical distribution limitation excluding +those countries, so that distribution is permitted only in or among +countries not thus excluded. In such case, this License incorporates +the limitation as if written in the body of this License. + + 9. The Free Software Foundation may publish revised and/or new versions +of the General Public License from time to time. Such new versions will +be similar in spirit to the present version, but may differ in detail to +address new problems or concerns. + +Each version is given a distinguishing version number. If the Program +specifies a version number of this License which applies to it and "any +later version", you have the option of following the terms and conditions +either of that version or of any later version published by the Free +Software Foundation. If the Program does not specify a version number of +this License, you may choose any version ever published by the Free Software +Foundation. + + 10. If you wish to incorporate parts of the Program into other free +programs whose distribution conditions are different, write to the author +to ask for permission. For software which is copyrighted by the Free +Software Foundation, write to the Free Software Foundation; we sometimes +make exceptions for this. Our decision will be guided by the two goals +of preserving the free status of all derivatives of our free software and +of promoting the sharing and reuse of software generally. + + NO WARRANTY + + 11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY +FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN +OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES +PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED +OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS +TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE +PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, +REPAIR OR CORRECTION. + + 12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING +WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR +REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, +INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING +OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED +TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY +YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER +PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE +POSSIBILITY OF SUCH DAMAGES. -- cgit v1.1 From 95de817b9034d50860319f6033ec85d25024694c Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Fri, 20 Jan 2012 13:55:25 +0100 Subject: cfg80211: stop tracking authenticated state To track authenticated state seems to have been a design mistake in cfg80211. It is possible to have out of band authentication (FT), tracking multiple authentications caused more problems than it ever helped, and the implementation in mac80211 is too complex. Remove all this complexity, and let userspace do whatever it wants to, mac80211 can deal with that just fine. Association is still tracked of course, but authentication no longer is. Local auth state changes are thus no longer of value, so ignore them completely. This will also help implement SAE -- asking the driver to do an authentication is now almost equivalent to sending an authentication frame, with the exception of shared key authentication which is still handled completely. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville --- Documentation/DocBook/80211.tmpl | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/80211.tmpl b/Documentation/DocBook/80211.tmpl index 2014155..c5ac692 100644 --- a/Documentation/DocBook/80211.tmpl +++ b/Documentation/DocBook/80211.tmpl @@ -129,7 +129,6 @@ !Finclude/net/cfg80211.h cfg80211_pmksa !Finclude/net/cfg80211.h cfg80211_send_rx_auth !Finclude/net/cfg80211.h cfg80211_send_auth_timeout -!Finclude/net/cfg80211.h __cfg80211_auth_canceled !Finclude/net/cfg80211.h cfg80211_send_rx_assoc !Finclude/net/cfg80211.h cfg80211_send_assoc_timeout !Finclude/net/cfg80211.h cfg80211_send_deauth -- cgit v1.1 From a602bea3e7ccc5ce3da61d2c18245c4058983926 Mon Sep 17 00:00:00 2001 From: Bryan Schumaker Date: Thu, 26 Jan 2012 16:54:25 -0500 Subject: NFS: Update idmapper documentation Signed-off-by: Bryan Schumaker Signed-off-by: Trond Myklebust --- Documentation/filesystems/nfs/idmapper.txt | 20 ++++++++++++++------ 1 file changed, 14 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/nfs/idmapper.txt b/Documentation/filesystems/nfs/idmapper.txt index 120fd3c..fe03d10 100644 --- a/Documentation/filesystems/nfs/idmapper.txt +++ b/Documentation/filesystems/nfs/idmapper.txt @@ -4,13 +4,21 @@ ID Mapper ========= Id mapper is used by NFS to translate user and group ids into names, and to translate user and group names into ids. Part of this translation involves -performing an upcall to userspace to request the information. Id mapper will -user request-key to perform this upcall and cache the result. The program -/usr/sbin/nfs.idmap should be called by request-key, and will perform the -translation and initialize a key with the resulting information. +performing an upcall to userspace to request the information. There are two +ways NFS could obtain this information: placing a call to /sbin/request-key +or by placing a call to the rpc.idmap daemon. + +NFS will attempt to call /sbin/request-key first. If this succeeds, the +result will be cached using the generic request-key cache. This call should +only fail if /etc/request-key.conf is not configured for the id_resolver key +type, see the "Configuring" section below if you wish to use the request-key +method. + +If the call to /sbin/request-key fails (if /etc/request-key.conf is not +configured with the id_resolver key type), then the idmapper will ask the +legacy rpc.idmap daemon for the id mapping. This result will be stored +in a custom NFS idmap cache. - NFS_USE_NEW_IDMAPPER must be selected when configuring the kernel to use this - feature. =========== Configuring -- cgit v1.1 From 0846e7e9856c0928223447d9349a877202a63f24 Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Fri, 3 Feb 2012 17:11:54 -0500 Subject: usb: Add support for indicating whether a port is removable Userspace may want to make policy decisions based on whether or not a given USB device is removable. Add a per-device member and support for exposing it in sysfs. Information sources to populate it will be added later. Signed-off-by: Matthew Garrett Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-bus-usb | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index b4f5487..7c22a532 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -182,3 +182,14 @@ Description: USB2 hardware LPM is enabled for the device. Developer can write y/Y/1 or n/N/0 to the file to enable/disable the feature. + +What: /sys/bus/usb/devices/.../removable +Date: February 2012 +Contact: Matthew Garrett +Description: + Some information about whether a given USB device is + physically fixed to the platform can be inferred from a + combination of hub decriptor bits and platform-specific data + such as ACPI. This file will read either "removable" or + "fixed" if the information is available, and "unknown" + otherwise. \ No newline at end of file -- cgit v1.1 From 3cd0b6252ebfaf65226a30e00a2d7535f66adb0e Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Wed, 8 Feb 2012 23:22:21 +0900 Subject: mm: Fix typo in unevictable-lru.txt Correct spelling "semphore" to "semaphore" in Documentation/vm/unevictable-lru.txt Signed-off-by: Masanari Iida Signed-off-by: Jiri Kosina --- Documentation/vm/unevictable-lru.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/vm/unevictable-lru.txt b/Documentation/vm/unevictable-lru.txt index 97bae3c..609d1a3 100644 --- a/Documentation/vm/unevictable-lru.txt +++ b/Documentation/vm/unevictable-lru.txt @@ -538,7 +538,7 @@ different reverse map mechanisms. process because mlocked pages are migratable. However, for reclaim, if the page is mapped into a VM_LOCKED VMA, the scan stops. - try_to_unmap_anon() attempts to acquire in read mode the mmap semphore of + try_to_unmap_anon() attempts to acquire in read mode the mmap semaphore of the mm_struct to which the VMA belongs. If this is successful, it will mlock the page via mlock_vma_page() - we wouldn't have gotten to try_to_unmap_anon() if the page were already mlocked - and will return @@ -623,7 +623,7 @@ mapped file pages with an additional argument specifing unlock versus unmap processing. Again, these functions walk the respective reverse maps looking for VM_LOCKED VMAs. When such a VMA is found for anonymous pages and file pages mapped in linear VMAs, as in the try_to_unmap() case, the functions -attempt to acquire the associated mmap semphore, mlock the page via +attempt to acquire the associated mmap semaphore, mlock the page via mlock_vma_page() and return SWAP_MLOCK. This effectively undoes the pre-clearing of the page's PG_mlocked done by munlock_vma_page. @@ -641,7 +641,7 @@ with it - the usual fallback position. Note that try_to_munlock()'s reverse map walk must visit every VMA in a page's reverse map to determine that a page is NOT mapped into any VM_LOCKED VMA. However, the scan can terminate when it encounters a VM_LOCKED VMA and can -successfully acquire the VMA's mmap semphore for read and mlock the page. +successfully acquire the VMA's mmap semaphore for read and mlock the page. Although try_to_munlock() might be called a great many times when munlocking a large region or tearing down a large address space that has been mlocked via mlockall(), overall this is a fairly rare event. -- cgit v1.1 From 2d514487faf188938a4ee4fb3464eeecfbdcf8eb Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Wed, 21 Dec 2011 12:17:04 -0800 Subject: security: Yama LSM This adds the Yama Linux Security Module to collect DAC security improvements (specifically just ptrace restrictions for now) that have existed in various forms over the years and have been carried outside the mainline kernel by other Linux distributions like Openwall and grsecurity. Signed-off-by: Kees Cook Acked-by: John Johansen Signed-off-by: James Morris --- Documentation/security/00-INDEX | 2 ++ Documentation/security/Yama.txt | 60 +++++++++++++++++++++++++++++++++++++++++ 2 files changed, 62 insertions(+) create mode 100644 Documentation/security/Yama.txt (limited to 'Documentation') diff --git a/Documentation/security/00-INDEX b/Documentation/security/00-INDEX index 99b85d3..eeed1de 100644 --- a/Documentation/security/00-INDEX +++ b/Documentation/security/00-INDEX @@ -6,6 +6,8 @@ SELinux.txt - how to get started with the SELinux security enhancement. Smack.txt - documentation on the Smack Linux Security Module. +Yama.txt + - documentation on the Yama Linux Security Module. apparmor.txt - documentation on the AppArmor security extension. credentials.txt diff --git a/Documentation/security/Yama.txt b/Documentation/security/Yama.txt new file mode 100644 index 0000000..4f0b789 --- /dev/null +++ b/Documentation/security/Yama.txt @@ -0,0 +1,60 @@ +Yama is a Linux Security Module that collects a number of system-wide DAC +security protections that are not handled by the core kernel itself. To +select it at boot time, specify "security=yama" (though this will disable +any other LSM). + +Yama is controlled through sysctl in /proc/sys/kernel/yama: + +- ptrace_scope + +============================================================== + +ptrace_scope: + +As Linux grows in popularity, it will become a larger target for +malware. One particularly troubling weakness of the Linux process +interfaces is that a single user is able to examine the memory and +running state of any of their processes. For example, if one application +(e.g. Pidgin) was compromised, it would be possible for an attacker to +attach to other running processes (e.g. Firefox, SSH sessions, GPG agent, +etc) to extract additional credentials and continue to expand the scope +of their attack without resorting to user-assisted phishing. + +This is not a theoretical problem. SSH session hijacking +(http://www.storm.net.nz/projects/7) and arbitrary code injection +(http://c-skills.blogspot.com/2007/05/injectso.html) attacks already +exist and remain possible if ptrace is allowed to operate as before. +Since ptrace is not commonly used by non-developers and non-admins, system +builders should be allowed the option to disable this debugging system. + +For a solution, some applications use prctl(PR_SET_DUMPABLE, ...) to +specifically disallow such ptrace attachment (e.g. ssh-agent), but many +do not. A more general solution is to only allow ptrace directly from a +parent to a child process (i.e. direct "gdb EXE" and "strace EXE" still +work), or with CAP_SYS_PTRACE (i.e. "gdb --pid=PID", and "strace -p PID" +still work as root). + +For software that has defined application-specific relationships +between a debugging process and its inferior (crash handlers, etc), +prctl(PR_SET_PTRACER, pid, ...) can be used. An inferior can declare which +other process (and its descendents) are allowed to call PTRACE_ATTACH +against it. Only one such declared debugging process can exists for +each inferior at a time. For example, this is used by KDE, Chromium, and +Firefox's crash handlers, and by Wine for allowing only Wine processes +to ptrace each other. + +0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other + process running under the same uid, as long as it is dumpable (i.e. + did not transition uids, start privileged, or have called + prctl(PR_SET_DUMPABLE...) already). + +1 - restricted ptrace: a process must have a predefined relationship + with the inferior it wants to call PTRACE_ATTACH on. By default, + this relationship is that of only its descendants when the above + classic criteria is also met. To change the relationship, an + inferior can call prctl(PR_SET_PTRACER, debugger, ...) to declare + an allowed debugger PID to call PTRACE_ATTACH on the inferior. + +The original children-only logic was based on the restrictions in grsecurity. + +============================================================== -- cgit v1.1 From 9045a05044268b075c13bb0284601b24959dc3c6 Mon Sep 17 00:00:00 2001 From: "Srivatsa S. Bhat" Date: Sat, 4 Feb 2012 22:26:26 +0100 Subject: PM / Freezer / Docs: Document the beauty of freeze/thaw semantics The way the different freeze/thaw functions encapsulate each other are quite lovely from a design point of view. And as a side-effect, the way in which they are invoked (cleaning up on failure for example) differs significantly from how usual functions are dealt with. This is because of the underlying semantics that govern the freezing and thawing of various tasks. This subtle aspect that differentiates these functions from the rest, is worth documenting. Many thanks to Tejun Heo for providing enlightenment on this topic. Signed-off-by: Srivatsa S. Bhat Signed-off-by: Rafael J. Wysocki --- Documentation/power/freezing-of-tasks.txt | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) (limited to 'Documentation') diff --git a/Documentation/power/freezing-of-tasks.txt b/Documentation/power/freezing-of-tasks.txt index ebd7490..ec715cd 100644 --- a/Documentation/power/freezing-of-tasks.txt +++ b/Documentation/power/freezing-of-tasks.txt @@ -63,6 +63,27 @@ devices have been reinitialized, the function thaw_processes() is called in order to clear the PF_FROZEN flag for each frozen task. Then, the tasks that have been frozen leave __refrigerator() and continue running. + +Rationale behind the functions dealing with freezing and thawing of tasks: +------------------------------------------------------------------------- + +freeze_processes(): + - freezes only userspace tasks + +freeze_kernel_threads(): + - freezes all tasks (including kernel threads) because we can't freeze + kernel threads without freezing userspace tasks + +thaw_kernel_threads(): + - thaws only kernel threads; this is particularly useful if we need to do + anything special in between thawing of kernel threads and thawing of + userspace tasks, or if we want to postpone the thawing of userspace tasks + +thaw_processes(): + - thaws all tasks (including kernel threads) because we can't thaw userspace + tasks without thawing kernel threads + + III. Which kernel threads are freezable? Kernel threads are not freezable by default. However, a kernel thread may clear -- cgit v1.1 From 26725f2ad6be4a002ab9e9c00a6410715ed18962 Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Thu, 9 Feb 2012 23:58:28 +0900 Subject: Documentation: Fix typo in tcm_mod_builder.py Correct spelling "alocate" to "allocate" in Documentation/target/tcm_mod_builder.py Signed-off-by: Masanari Iida Signed-off-by: Jiri Kosina --- Documentation/target/tcm_mod_builder.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/target/tcm_mod_builder.py b/Documentation/target/tcm_mod_builder.py index 6e21b8b..a78879b 100755 --- a/Documentation/target/tcm_mod_builder.py +++ b/Documentation/target/tcm_mod_builder.py @@ -775,7 +775,7 @@ def tcm_mod_dump_fabric_ops(proto_ident, fabric_mod_dir_var, fabric_mod_name): buf += " struct " + fabric_mod_name + "_nacl *nacl;\n\n" buf += " nacl = kzalloc(sizeof(struct " + fabric_mod_name + "_nacl), GFP_KERNEL);\n" buf += " if (!nacl) {\n" - buf += " printk(KERN_ERR \"Unable to alocate struct " + fabric_mod_name + "_nacl\\n\");\n" + buf += " printk(KERN_ERR \"Unable to allocate struct " + fabric_mod_name + "_nacl\\n\");\n" buf += " return NULL;\n" buf += " }\n\n" buf += " return &nacl->se_node_acl;\n" -- cgit v1.1 From d65657c8621d133f4feed4f20c0ce7ba175a8d03 Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Wed, 8 Feb 2012 23:10:14 +0900 Subject: mm: Fix typo in cleancache.txt Correct spelling "implementatation" to "implementation" in Documentation/vm/cleancache.txt Signed-off-by: Masanari Iida Signed-off-by: Jiri Kosina --- Documentation/vm/cleancache.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/vm/cleancache.txt b/Documentation/vm/cleancache.txt index 36c367c..d5c615a 100644 --- a/Documentation/vm/cleancache.txt +++ b/Documentation/vm/cleancache.txt @@ -92,7 +92,7 @@ failed_gets - number of gets that failed puts - number of puts attempted (all "succeed") flushes - number of flushes attempted -A backend implementatation may provide additional metrics. +A backend implementation may provide additional metrics. FAQ -- cgit v1.1 From da5a70f3519fd6f73ece3eea261a861c9a4d6bbd Mon Sep 17 00:00:00 2001 From: Lee Jones Date: Mon, 6 Feb 2012 11:22:23 -0800 Subject: Documentation: add information for new sysfs soc bus functionality This change applies the required documentation for each new attribute recenty added by the new System-On-Chip (SoC) information export bus driver. Signed-off-by: Lee Jones Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/testing/sysfs-devices-soc | 58 +++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-devices-soc (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-soc b/Documentation/ABI/testing/sysfs-devices-soc new file mode 100644 index 0000000..6d9cc25 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-soc @@ -0,0 +1,58 @@ +What: /sys/devices/socX +Date: January 2012 +contact: Lee Jones +Description: + The /sys/devices/ directory contains a sub-directory for each + System-on-Chip (SoC) device on a running platform. Information + regarding each SoC can be obtained by reading sysfs files. This + functionality is only available if implemented by the platform. + + The directory created for each SoC will also house information + about devices which are commonly contained in /sys/devices/platform. + It has been agreed that if an SoC device exists, its supported + devices would be better suited to appear as children of that SoC. + +What: /sys/devices/socX/machine +Date: January 2012 +contact: Lee Jones +Description: + Read-only attribute common to all SoCs. Contains the SoC machine + name (e.g. Ux500). + +What: /sys/devices/socX/family +Date: January 2012 +contact: Lee Jones +Description: + Read-only attribute common to all SoCs. Contains SoC family name + (e.g. DB8500). + +What: /sys/devices/socX/soc_id +Date: January 2012 +contact: Lee Jones +Description: + Read-only attribute supported by most SoCs. In the case of + ST-Ericsson's chips this contains the SoC serial number. + +What: /sys/devices/socX/revision +Date: January 2012 +contact: Lee Jones +Description: + Read-only attribute supported by most SoCs. Contains the SoC's + manufacturing revision number. + +What: /sys/devices/socX/process +Date: January 2012 +contact: Lee Jones +Description: + Read-only attribute supported ST-Ericsson's silicon. Contains the + the process by which the silicon chip was manufactured. + +What: /sys/bus/soc +Date: January 2012 +contact: Lee Jones +Description: + The /sys/bus/soc/ directory contains the usual sub-folders + expected under most buses. /sys/bus/soc/devices is of particular + interest, as it contains a symlink for each SoC device found on + the system. Each symlink points back into the aforementioned + /sys/devices/socX devices. -- cgit v1.1 From 28a8d14cc74a0180323d9150c3d3dbf9dd60d55a Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 9 Feb 2012 01:52:22 +0100 Subject: pinctrl: break out a pinctrl consumer header This breaks out a header to be used by all pinmux and pinconfig alike, so drivers needing services from pinctrl does not need to include different headers. This is similar to the approach taken by the regulator API. Acked-by: Stephen Warren Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 14aecd2..b268832 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -208,6 +208,8 @@ unconnected. For example, a platform may do this: +#include + ret = pin_config_set("foo-dev", "FOO_GPIO_PIN", PLATFORM_X_PULL_UP); To pull up a pin to VDD. The pin configuration driver implements callbacks for @@ -920,7 +922,7 @@ this is not possible. A driver may request a certain mux to be activated, usually just the default mux like this: -#include +#include struct foo_state { struct pinmux *pmx; @@ -1019,6 +1021,8 @@ function, but with different named in the mapping as described under This snippet first muxes the function in the pins defined by group A, enables it, disables and releases it, and muxes it in on the pins defined by group B: +#include + foo_switch() { struct pinmux *pmx; -- cgit v1.1 From e93bcee00c43e2bd4037291262111016f4c05793 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Thu, 9 Feb 2012 07:23:28 +0100 Subject: pinctrl: move generic functions to the pinctrl_ namespace Since we want to use the former pinmux handles and mapping tables for generic control involving both muxing and configuration we begin refactoring by renaming them from pinmux_* to pinctrl_*. ChangeLog v1->v2: - Also rename the PINMUX_* macros in machine.h to PIN_ as indicated in the documentation so as to reflect the generic nature of these mapping entries from now on. Acked-by: Stephen Warren Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 118 +++++++++++++++++++++++----------------------- 1 file changed, 59 insertions(+), 59 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index b268832..2e71323 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -728,19 +728,19 @@ same time. All the above functions are mandatory to implement for a pinmux driver. -Pinmux interaction with the GPIO subsystem -========================================== +Pin control interaction with the GPIO subsystem +=============================================== -The public pinmux API contains two functions named pinmux_request_gpio() -and pinmux_free_gpio(). These two functions shall *ONLY* be called from +The public pinmux API contains two functions named pinctrl_request_gpio() +and pinctrl_free_gpio(). These two functions shall *ONLY* be called from gpiolib-based drivers as part of their gpio_request() and -gpio_free() semantics. Likewise the pinmux_gpio_direction_[input|output] +gpio_free() semantics. Likewise the pinctrl_gpio_direction_[input|output] shall only be called from within respective gpio_direction_[input|output] gpiolib implementation. NOTE that platforms and individual drivers shall *NOT* request GPIO pins to be -muxed in. Instead, implement a proper gpiolib driver and have that driver -request proper muxing for its pins. +controlled e.g. muxed in. Instead, implement a proper gpiolib driver and have +that driver request proper muxing and other control for its pins. The function list could become long, especially if you can convert every individual pin into a GPIO pin independent of any other pins, and then try @@ -749,7 +749,7 @@ the approach to define every pin as a function. In this case, the function array would become 64 entries for each GPIO setting and then the device functions. -For this reason there are two functions a pinmux driver can implement +For this reason there are two functions a pin control driver can implement to enable only GPIO on an individual pin: .gpio_request_enable() and .gpio_disable_free(). @@ -764,7 +764,7 @@ gpiolib driver and the affected GPIO range, pin offset and desired direction will be passed along to this function. Alternatively to using these special functions, it is fully allowed to use -named functions for each GPIO pin, the pinmux_request_gpio() will attempt to +named functions for each GPIO pin, the pinctrl_request_gpio() will attempt to obtain the function "gpioN" where "N" is the global GPIO pin number if no special GPIO-handler is registered. @@ -783,7 +783,7 @@ spi on the second function mapping: #include -static const struct pinmux_map __initdata pmx_mapping[] = { +static const struct pinctrl_map __initdata mapping[] = { { .ctrl_dev_name = "pinctrl-foo", .function = "spi0", @@ -811,14 +811,14 @@ to map. You register this pinmux mapping to the pinmux subsystem by simply: - ret = pinmux_register_mappings(pmx_mapping, ARRAY_SIZE(pmx_mapping)); + ret = pinctrl_register_mappings(mapping, ARRAY_SIZE(mapping)); Since the above construct is pretty common there is a helper macro to make it even more compact which assumes you want to use pinctrl-foo and position 0 for mapping, for example: -static struct pinmux_map __initdata pmx_mapping[] = { - PINMUX_MAP("I2CMAP", "pinctrl-foo", "i2c0", "foo-i2c.0"), +static struct pinctrl_map __initdata mapping[] = { + PIN_MAP("I2CMAP", "pinctrl-foo", "i2c0", "foo-i2c.0"), }; @@ -901,7 +901,7 @@ case), we define a mapping like this: The result of grabbing this mapping from the device with something like this (see next paragraph): - pmx = pinmux_get(&device, "8bit"); + p = pinctrl_get(&device, "8bit"); Will be that you activate all the three bottom records in the mapping at once. Since they share the same name, pin controller device, funcion and @@ -913,44 +913,44 @@ pinmux core. Pinmux requests from drivers ============================ -Generally it is discouraged to let individual drivers get and enable pinmuxes. -So if possible, handle the pinmuxes in platform code or some other place where -you have access to all the affected struct device * pointers. In some cases -where a driver needs to switch between different mux mappings at runtime -this is not possible. +Generally it is discouraged to let individual drivers get and enable pin +control. So if possible, handle the pin control in platform code or some other +place where you have access to all the affected struct device * pointers. In +some cases where a driver needs to e.g. switch between different mux mappings +at runtime this is not possible. -A driver may request a certain mux to be activated, usually just the default -mux like this: +A driver may request a certain control state to be activated, usually just the +default state like this: #include struct foo_state { - struct pinmux *pmx; + struct pinctrl *p; ... }; foo_probe() { /* Allocate a state holder named "state" etc */ - struct pinmux pmx; + struct pinctrl p; - pmx = pinmux_get(&device, NULL); - if IS_ERR(pmx) - return PTR_ERR(pmx); - pinmux_enable(pmx); + p = pinctrl_get(&device, NULL); + if IS_ERR(p) + return PTR_ERR(p); + pinctrl_enable(p); - state->pmx = pmx; + state->p = p; } foo_remove() { - pinmux_disable(state->pmx); - pinmux_put(state->pmx); + pinctrl_disable(state->p); + pinctrl_put(state->p); } -If you want to grab a specific mux mapping and not just the first one found for -this device you can specify a specific mapping name, for example in the above -example the second i2c0 setting: pinmux_get(&device, "spi0-pos-B"); +If you want to grab a specific control mapping and not just the first one +found for this device you can specify a specific mapping name, for example in +the above example the second i2c0 setting: pinctrl_get(&device, "spi0-pos-B"); This get/enable/disable/put sequence can just as well be handled by bus drivers if you don't want each and every driver to handle it and you know the @@ -958,35 +958,35 @@ arrangement on your bus. The semantics of the get/enable respective disable/put is as follows: -- pinmux_get() is called in process context to reserve the pins affected with +- pinctrl_get() is called in process context to reserve the pins affected with a certain mapping and set up the pinmux core and the driver. It will allocate a struct from the kernel memory to hold the pinmux state. -- pinmux_enable()/pinmux_disable() is quick and can be called from fastpath +- pinctrl_enable()/pinctrl_disable() is quick and can be called from fastpath (irq context) when you quickly want to set up/tear down the hardware muxing when running a device driver. Usually it will just poke some values into a register. -- pinmux_disable() is called in process context to tear down the pin requests - and release the state holder struct for the mux setting. +- pinctrl_disable() is called in process context to tear down the pin requests + and release the state holder struct for the mux setting etc. -Usually the pinmux core handled the get/put pair and call out to the device -drivers bookkeeping operations, like checking available functions and the -associated pins, whereas the enable/disable pass on to the pin controller +Usually the pin control core handled the get/put pair and call out to the +device drivers bookkeeping operations, like checking available functions and +the associated pins, whereas the enable/disable pass on to the pin controller driver which takes care of activating and/or deactivating the mux setting by quickly poking some registers. -The pins are allocated for your device when you issue the pinmux_get() call, +The pins are allocated for your device when you issue the pinctrl_get() call, after this you should be able to see this in the debugfs listing of all pins. -System pinmux hogging -===================== +System pin control hogging +========================== -A system pinmux map entry, i.e. a pinmux setting that does not have a device -associated with it, can be hogged by the core when the pin controller is -registered. This means that the core will attempt to call pinmux_get() and -pinmux_enable() on it immediately after the pin control device has been +A system pin control map entry, i.e. a pin control setting that does not have +a device associated with it, can be hogged by the core when the pin controller +is registered. This means that the core will attempt to call pinctrl_get() and +pinctrl_enable() on it immediately after the pin control device has been registered. This is enabled by simply setting the .hog_on_boot field in the map to true, @@ -1003,7 +1003,7 @@ Since it may be common to request the core to hog a few always-applicable mux settings on the primary pin controller, there is a convenience macro for this: -PINMUX_MAP_PRIMARY_SYS_HOG("POWERMAP", "power_func") +PIN_MAP_PRIMARY_SYS_HOG("POWERMAP", "power_func") This gives the exact same result as the above construction. @@ -1025,23 +1025,23 @@ it, disables and releases it, and muxes it in on the pins defined by group B: foo_switch() { - struct pinmux *pmx; + struct pinctrl *p; /* Enable on position A */ - pmx = pinmux_get(&device, "spi0-pos-A"); - if IS_ERR(pmx) - return PTR_ERR(pmx); - pinmux_enable(pmx); + p = pinctrl_get(&device, "spi0-pos-A"); + if IS_ERR(p) + return PTR_ERR(p); + pinctrl_enable(p); /* This releases the pins again */ - pinmux_disable(pmx); - pinmux_put(pmx); + pinctrl_disable(p); + pinctrl_put(p); /* Enable on position B */ - pmx = pinmux_get(&device, "spi0-pos-B"); - if IS_ERR(pmx) - return PTR_ERR(pmx); - pinmux_enable(pmx); + p = pinctrl_get(&device, "spi0-pos-B"); + if IS_ERR(p) + return PTR_ERR(p); + pinctrl_enable(p); ... } -- cgit v1.1 From 77a5988355f993840928d195f790a939200a4ff0 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Fri, 10 Feb 2012 01:34:12 +0100 Subject: pinctrl: changes hog mechanism to be self-referential Instead of a specific boolean field to indicate if a map entry shall be hogged, treat self-reference as an indication of desired hogging. This drops one field off the map struct and has a nice Douglas R. Hofstadter-feel to it. Acked-by: Dong Aisheng Acked-by: Stephen Warren Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 2e71323..ee3266b 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -989,21 +989,21 @@ is registered. This means that the core will attempt to call pinctrl_get() and pinctrl_enable() on it immediately after the pin control device has been registered. -This is enabled by simply setting the .hog_on_boot field in the map to true, -like this: +This is enabled by simply setting the .dev_name field in the map to the name +of the pin controller itself, like this: { .name = "POWERMAP" .ctrl_dev_name = "pinctrl-foo", .function = "power_func", - .hog_on_boot = true, + .dev_name = "pinctrl-foo", }, Since it may be common to request the core to hog a few always-applicable mux settings on the primary pin controller, there is a convenience macro for this: -PIN_MAP_PRIMARY_SYS_HOG("POWERMAP", "power_func") +PIN_MAP_PRIMARY_SYS_HOG("POWERMAP", "pinctrl-foo", "power_func") This gives the exact same result as the above construction. -- cgit v1.1 From 6b4f12523db46536c750473abdd380763cb0409b Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Thu, 24 Nov 2011 09:55:53 -0300 Subject: [media] v4l spec: document VIDIOC_(TRY_)DECODER_CMD Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/v4l2.xml | 1 + .../DocBook/media/v4l/vidioc-decoder-cmd.xml | 256 +++++++++++++++++++++ .../DocBook/media/v4l/vidioc-encoder-cmd.xml | 9 +- 3 files changed, 262 insertions(+), 4 deletions(-) create mode 100644 Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index dce3fef..dcf9e33 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -480,6 +480,7 @@ and discussions on the V4L mailing list. &sub-cropcap; &sub-dbg-g-chip-ident; &sub-dbg-g-register; + &sub-decoder-cmd; &sub-dqevent; &sub-encoder-cmd; &sub-enumaudio; diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml new file mode 100644 index 0000000..466fe27 --- /dev/null +++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml @@ -0,0 +1,256 @@ + + + ioctl VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD + &manvol; + + + + VIDIOC_DECODER_CMD + VIDIOC_TRY_DECODER_CMD + Execute an decoder command + + + + + + int ioctl + int fd + int request + struct v4l2_decoder_cmd *argp + + + + + + Arguments + + + + fd + + &fd; + + + + request + + VIDIOC_DECODER_CMD, VIDIOC_TRY_DECODER_CMD + + + + argp + + + + + + + + + Description + + + Experimental + + This is an experimental +interface and may change in the future. + + + These ioctls control an audio/video (usually MPEG-) decoder. +VIDIOC_DECODER_CMD sends a command to the +decoder, VIDIOC_TRY_DECODER_CMD can be used to +try a command without actually executing it. To send a command applications +must initialize all fields of a &v4l2-decoder-cmd; and call +VIDIOC_DECODER_CMD or VIDIOC_TRY_DECODER_CMD +with a pointer to this structure. + + The cmd field must contain the +command code. Some commands use the flags field for +additional information. + + + A write() or &VIDIOC-STREAMON; call sends an implicit +START command to the decoder if it has not been started yet. + + + A close() or &VIDIOC-STREAMOFF; call of a streaming +file descriptor sends an implicit immediate STOP command to the decoder, and all +buffered data is discarded. + + These ioctls are optional, not all drivers may support +them. They were introduced in Linux 3.3. + + + struct <structname>v4l2_decoder_cmd</structname> + + &cs-str; + + + __u32 + cmd + + + The decoder command, see . + + + __u32 + flags + + + Flags to go with the command. If no flags are defined for +this command, drivers and applications must set this field to zero. + + + union + (anonymous) + + + + + + + struct + start + + Structure containing additional data for the +V4L2_DEC_CMD_START command. + + + + + __u32 + speed + Playback speed and direction. The playback speed is defined as +speed/1000 of the normal speed. So 1000 is normal playback. +Negative numbers denote reverse playback, so -1000 does reverse playback at normal +speed. Speeds -1, 0 and 1 have special meanings: speed 0 is shorthand for 1000 +(normal playback). A speed of 1 steps just one frame forward, a speed of -1 steps +just one frame back. + + + + + + __u32 + format + Format restrictions. This field is set by the driver, not the +application. Possible values are V4L2_DEC_START_FMT_NONE if +there are no format restrictions or V4L2_DEC_START_FMT_GOP +if the decoder operates on full GOPs (Group Of Pictures). +This is usually the case for reverse playback: the decoder needs full GOPs, which +it can then play in reverse order. So to implement reverse playback the application +must feed the decoder the last GOP in the video file, then the GOP before that, etc. etc. + + + + + struct + stop + + Structure containing additional data for the +V4L2_DEC_CMD_STOP command. + + + + + __u64 + pts + Stop playback at this pts or immediately +if the playback is already past that timestamp. Leave to 0 if you want to stop after the +last frame was decoded. + + + + + struct + raw + + + + + + + __u32 + data[16] + Reserved for future extensions. Drivers and +applications must set the array to zero. + + + +
+ + + Decoder Commands + + &cs-def; + + + V4L2_DEC_CMD_START + 0 + Start the decoder. When the decoder is already +running or paused, this command will just change the playback speed. +That means that calling V4L2_DEC_CMD_START when +the decoder was paused will not resume the decoder. +You have to explicitly call V4L2_DEC_CMD_RESUME for that. +This command has one flag: +V4L2_DEC_CMD_START_MUTE_AUDIO. If set, then audio will +be muted when playing back at a non-standard speed. + + + + V4L2_DEC_CMD_STOP + 1 + Stop the decoder. When the decoder is already stopped, +this command does nothing. This command has two flags: +if V4L2_DEC_CMD_STOP_TO_BLACK is set, then the decoder will +set the picture to black after it stopped decoding. Otherwise the last image will +repeat. If V4L2_DEC_CMD_STOP_IMMEDIATELY is set, then the decoder +stops immediately (ignoring the pts value), otherwise it +will keep decoding until timestamp >= pts or until the last of the pending data from +its internal buffers was decoded. + + + + V4L2_DEC_CMD_PAUSE + 2 + Pause the decoder. When the decoder has not been +started yet, the driver will return an &EPERM;. When the decoder is +already paused, this command does nothing. This command has one flag: +if V4L2_DEC_CMD_PAUSE_TO_BLACK is set, then set the +decoder output to black when paused. + + + + V4L2_DEC_CMD_RESUME + 3 + Resume decoding after a PAUSE command. When the +decoder has not been started yet, the driver will return an &EPERM;. +When the decoder is already running, this command does nothing. No +flags are defined for this command. + + + +
+ + + + + &return-value; + + + + EINVAL + + The cmd field is invalid. + + + + EPERM + + The application sent a PAUSE or RESUME command when +the decoder was not running. + + + + + diff --git a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml index af7f3f2..f431b3b 100644 --- a/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-encoder-cmd.xml @@ -74,15 +74,16 @@ only used by the STOP command and contains one bit: If the encoding will continue until the end of the current Group Of Pictures, otherwise it will stop immediately. - A read() call sends a START command to -the encoder if it has not been started yet. After a STOP command, + A read() or &VIDIOC-STREAMON; call sends an implicit +START command to the encoder if it has not been started yet. After a STOP command, read() calls will read the remaining data buffered by the driver. When the buffer is empty, read() will return zero and the next read() call will restart the encoder. - A close() call sends an immediate STOP -to the encoder, and all buffered data is discarded. + A close() or &VIDIOC-STREAMOFF; call of a streaming +file descriptor sends an implicit immediate STOP to the encoder, and all buffered +data is discarded. These ioctls are optional, not all drivers may support them. They were introduced in Linux 2.6.21. -- cgit v1.1 From 77bd4c0ff1671214ee026c175b4a5e1cc8776a0a Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Thu, 15 Dec 2011 10:52:57 -0300 Subject: [media] Document decoder controls Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/controls.xml | 59 ++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index a1be378..3f3d2e2 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -1286,6 +1286,49 @@ produce a slight hiss, but in the encoder itself, guaranteeing a fixed and reproducible audio bitstream. 0 = unmuted, 1 = muted. + + V4L2_CID_MPEG_AUDIO_DEC_PLAYBACK  + enum v4l2_mpeg_audio_dec_playback + Determines how monolingual audio should be played back. +Possible values are: + + + + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_AUTO  + Automatically determines the best playback mode. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_STEREO  + Stereo playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_LEFT  + Left channel playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_RIGHT  + Right channel playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_MONO  + Mono playback. + + + V4L2_MPEG_AUDIO_DEC_PLAYBACK_SWAPPED_STEREO  + Stereo playback with swapped left and right channels. + + + + + + + V4L2_CID_MPEG_AUDIO_DEC_MULTILINGUAL_PLAYBACK  + enum v4l2_mpeg_audio_dec_playback + Determines how multilingual audio should be played back. + + V4L2_CID_MPEG_VIDEO_ENCODING  enum v4l2_mpeg_video_encoding @@ -1447,6 +1490,22 @@ of the video. The supplied 32-bit integer is interpreted as follows (bit + + + V4L2_CID_MPEG_VIDEO_DEC_PTS  + integer64 + This read-only control returns the +33-bit video Presentation Time Stamp as defined in ITU T-REC-H.222.0 and ISO/IEC 13818-1 of +the currently displayed frame. This is the same PTS as is used in &VIDIOC-DECODER-CMD;. + + + + V4L2_CID_MPEG_VIDEO_DEC_FRAME  + integer64 + This read-only control returns the +frame counter of the frame that is currently displayed (decoded). This value is reset to 0 whenever +the decoder is started. + -- cgit v1.1 From 7ab3a837adfc502913e0101d83bd3f4692b690b6 Mon Sep 17 00:00:00 2001 From: Grant Likely Date: Tue, 14 Feb 2012 14:06:47 -0700 Subject: irq_domain: add documentation and MAINTAINERS entry. Documentation for irq_domain library which will be created in subsequent patches. v4: editorial changes Signed-off-by: Grant Likely Reviewed-by: Randy Dunlap Cc: Benjamin Herrenschmidt Cc: Thomas Gleixner Cc: Rob Herring Cc: Milton Miller Tested-by: Olof Johansson --- Documentation/IRQ-domain.txt | 117 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 Documentation/IRQ-domain.txt (limited to 'Documentation') diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt new file mode 100644 index 0000000..27dcaab --- /dev/null +++ b/Documentation/IRQ-domain.txt @@ -0,0 +1,117 @@ +irq_domain interrupt number mapping library + +The current design of the Linux kernel uses a single large number +space where each separate IRQ source is assigned a different number. +This is simple when there is only one interrupt controller, but in +systems with multiple interrupt controllers the kernel must ensure +that each one gets assigned non-overlapping allocations of Linux +IRQ numbers. + +The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of +irq numbers, but they don't provide any support for reverse mapping of +the controller-local IRQ (hwirq) number into the Linux IRQ number +space. + +The irq_domain library adds mapping between hwirq and IRQ numbers on +top of the irq_alloc_desc*() API. An irq_domain to manage mapping is +preferred over interrupt controller drivers open coding their own +reverse mapping scheme. + +irq_domain also implements translation from Device Tree interrupt +specifiers to hwirq numbers, and can be easily extended to support +other IRQ topology data sources. + +=== irq_domain usage === +An interrupt controller driver creates and registers an irq_domain by +calling one of the irq_domain_add_*() functions (each mapping method +has a different allocator function, more on that later). The function +will return a pointer to the irq_domain on success. The caller must +provide the allocator function with an irq_domain_ops structure with +the .map callback populated as a minimum. + +In most cases, the irq_domain will begin empty without any mappings +between hwirq and IRQ numbers. Mappings are added to the irq_domain +by calling irq_create_mapping() which accepts the irq_domain and a +hwirq number as arguments. If a mapping for the hwirq doesn't already +exist then it will allocate a new Linux irq_desc, associate it with +the hwirq, and call the .map() callback so the driver can perform any +required hardware setup. + +When an interrupt is received, irq_find_mapping() function should +be used to find the Linux IRQ number from the hwirq number. + +If the driver has the Linux IRQ number or the irq_data pointer, and +needs to know the associated hwirq number (such as in the irq_chip +callbacks) then it can be directly obtained from irq_data->hwirq. + +=== Types of irq_domain mappings === +There are several mechanisms available for reverse mapping from hwirq +to Linux irq, and each mechanism uses a different allocation function. +Which reverse map type should be used depends on the use case. Each +of the reverse map types are described below: + +==== Linear ==== +irq_domain_add_linear() + +The linear reverse map maintains a fixed size table indexed by the +hwirq number. When a hwirq is mapped, an irq_desc is allocated for +the hwirq, and the IRQ number is stored in the table. + +The Linear map is a good choice when the maximum number of hwirqs is +fixed and a relatively small number (~ < 256). The advantages of this +map are fixed time lookup for IRQ numbers, and irq_descs are only +allocated for in-use IRQs. The disadvantage is that the table must be +as large as the largest possible hwirq number. + +The majority of drivers should use the linear map. + +==== Tree ==== +irq_domain_add_tree() + +The irq_domain maintains a radix tree map from hwirq numbers to Linux +IRQs. When an hwirq is mapped, an irq_desc is allocated and the +hwirq is used as the lookup key for the radix tree. + +The tree map is a good choice if the hwirq number can be very large +since it doesn't need to allocate a table as large as the largest +hwirq number. The disadvantage is that hwirq to IRQ number lookup is +dependent on how many entries are in the table. + +Very few drivers should need this mapping. At the moment, powerpc +iseries is the only user. + +==== No Map ===- +irq_domain_add_nomap() + +The No Map mapping is to be used when the hwirq number is +programmable in the hardware. In this case it is best to program the +Linux IRQ number into the hardware itself so that no mapping is +required. Calling irq_create_direct_mapping() will allocate a Linux +IRQ number and call the .map() callback so that driver can program the +Linux IRQ number into the hardware. + +Most drivers cannot use this mapping. + +==== Legacy ==== +irq_domain_add_legacy() +irq_domain_add_legacy_isa() + +The Legacy mapping is a special case for drivers that already have a +range of irq_descs allocated for the hwirqs. It is used when the +driver cannot be immediately converted to use the linear mapping. For +example, many embedded system board support files use a set of #defines +for IRQ numbers that are passed to struct device registrations. In that +case the Linux IRQ numbers cannot be dynamically assigned and the legacy +mapping should be used. + +The legacy map assumes a contiguous range of IRQ numbers has already +been allocated for the controller and that the IRQ number can be +calculated by adding a fixed offset to the hwirq number, and +visa-versa. The disadvantage is that it requires the interrupt +controller to manage IRQ allocations and it requires an irq_desc to be +allocated for every hwirq, even if it is unused. + +The legacy map should only be used if fixed IRQ mappings must be +supported. For example, ISA controllers would use the legacy map for +mapping Linux IRQs 0-15 so that existing ISA drivers get the correct IRQ +numbers. -- cgit v1.1 From ef159e9177cc5a09e6174796dde0b2d243ddf28b Mon Sep 17 00:00:00 2001 From: Trond Myklebust Date: Mon, 6 Feb 2012 19:50:40 -0500 Subject: NFSv4.1: Add a module parameter to set the number of session slots Add the module parameter 'max_session_slots' to set the initial number of slots that the NFSv4.1 client will attempt to negotiate with the server. Signed-off-by: Trond Myklebust --- Documentation/kernel-parameters.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 033d4e6..1d369c6 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1657,6 +1657,14 @@ bytes respectively. Such letter suffixes can also be entirely omitted. of returning the full 64-bit number. The default is to return 64-bit inode numbers. + nfs.max_session_slots= + [NFSv4.1] Sets the maximum number of session slots + the client will attempt to negotiate with the server. + This limits the number of simultaneous RPC requests + that the client can send to the NFSv4.1 server. + Note that there is little point in setting this + value higher than the max_tcp_slot_table_limit. + nfs.nfs4_disable_idmapping= [NFSv4] When set to the default of '1', this option ensures that both the RPC level authentication -- cgit v1.1 From d5a8003135da7afe311e4e13ff42000ab7cd2078 Mon Sep 17 00:00:00 2001 From: Benoit Cousson Date: Wed, 15 Feb 2012 18:37:34 +0100 Subject: spi/omap: Add DT support to McSPI driver Add device tree support to the OMAP2+ McSPI driver. Add the bindings documentation. Based on original code from Rajendra. Signed-off-by: Benoit Cousson Cc: Grant Likely Cc: Rajendra Nayak Signed-off-by: Grant Likely --- Documentation/devicetree/bindings/spi/omap-spi.txt | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) create mode 100644 Documentation/devicetree/bindings/spi/omap-spi.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/spi/omap-spi.txt b/Documentation/devicetree/bindings/spi/omap-spi.txt new file mode 100644 index 0000000..81df374 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/omap-spi.txt @@ -0,0 +1,20 @@ +OMAP2+ McSPI device + +Required properties: +- compatible : + - "ti,omap2-spi" for OMAP2 & OMAP3. + - "ti,omap4-spi" for OMAP4+. +- ti,spi-num-cs : Number of chipselect supported by the instance. +- ti,hwmods: Name of the hwmod associated to the McSPI + + +Example: + +mcspi1: mcspi@1 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "ti,omap4-mcspi"; + ti,hwmods = "mcspi1"; + ti,spi-num-cs = <4>; +}; + -- cgit v1.1 From bc5bca53cca350eb90fc9f84c2e37ba6383807c3 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Wed, 15 Feb 2012 14:48:01 -0800 Subject: driver-core: documentation: fix up Greg's email address My old email address was used in a lot of documentation files, so fix this up to point to the correct one now. Signed-off-by: Greg Kroah-Hartman --- Documentation/ABI/removed/devfs | 2 +- Documentation/ABI/stable/sysfs-driver-usb-usbtmc | 10 +++++----- Documentation/ABI/testing/sysfs-class | 2 +- Documentation/ABI/testing/sysfs-devices | 2 +- Documentation/ABI/testing/sysfs-driver-samsung-laptop | 2 +- Documentation/ioctl/ioctl-number.txt | 2 +- Documentation/ko_KR/HOWTO | 2 +- Documentation/kobject.txt | 2 +- Documentation/zh_CN/HOWTO | 2 +- 9 files changed, 13 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/removed/devfs b/Documentation/ABI/removed/devfs index 8ffd28b..0020c49 100644 --- a/Documentation/ABI/removed/devfs +++ b/Documentation/ABI/removed/devfs @@ -1,6 +1,6 @@ What: devfs Date: July 2005 (scheduled), finally removed in kernel v2.6.18 -Contact: Greg Kroah-Hartman +Contact: Greg Kroah-Hartman Description: devfs has been unmaintained for a number of years, has unfixable races, contains a naming policy within the kernel that is diff --git a/Documentation/ABI/stable/sysfs-driver-usb-usbtmc b/Documentation/ABI/stable/sysfs-driver-usb-usbtmc index 9a75fb2..23a43b8 100644 --- a/Documentation/ABI/stable/sysfs-driver-usb-usbtmc +++ b/Documentation/ABI/stable/sysfs-driver-usb-usbtmc @@ -1,7 +1,7 @@ What: /sys/bus/usb/drivers/usbtmc/devices/*/interface_capabilities What: /sys/bus/usb/drivers/usbtmc/devices/*/device_capabilities Date: August 2008 -Contact: Greg Kroah-Hartman +Contact: Greg Kroah-Hartman Description: These files show the various USB TMC capabilities as described by the device itself. The full description of the bitfields @@ -15,7 +15,7 @@ Description: What: /sys/bus/usb/drivers/usbtmc/devices/*/usb488_interface_capabilities What: /sys/bus/usb/drivers/usbtmc/devices/*/usb488_device_capabilities Date: August 2008 -Contact: Greg Kroah-Hartman +Contact: Greg Kroah-Hartman Description: These files show the various USB TMC capabilities as described by the device itself. The full description of the bitfields @@ -29,7 +29,7 @@ Description: What: /sys/bus/usb/drivers/usbtmc/devices/*/TermChar Date: August 2008 -Contact: Greg Kroah-Hartman +Contact: Greg Kroah-Hartman Description: This file is the TermChar value to be sent to the USB TMC device as described by the document, "Universal Serial Bus Test @@ -42,7 +42,7 @@ Description: What: /sys/bus/usb/drivers/usbtmc/devices/*/TermCharEnabled Date: August 2008 -Contact: Greg Kroah-Hartman +Contact: Greg Kroah-Hartman Description: This file determines if the TermChar is to be sent to the device on every transaction or not. For more details about @@ -53,7 +53,7 @@ Description: What: /sys/bus/usb/drivers/usbtmc/devices/*/auto_abort Date: August 2008 -Contact: Greg Kroah-Hartman +Contact: Greg Kroah-Hartman Description: This file determines if the the transaction of the USB TMC device is to be automatically aborted if there is any error. diff --git a/Documentation/ABI/testing/sysfs-class b/Documentation/ABI/testing/sysfs-class index 4b0cb89..676530f 100644 --- a/Documentation/ABI/testing/sysfs-class +++ b/Documentation/ABI/testing/sysfs-class @@ -1,6 +1,6 @@ What: /sys/class/ Date: Febuary 2006 -Contact: Greg Kroah-Hartman +Contact: Greg Kroah-Hartman Description: The /sys/class directory will consist of a group of subdirectories describing individual classes of devices diff --git a/Documentation/ABI/testing/sysfs-devices b/Documentation/ABI/testing/sysfs-devices index 6a25671..5fcc943 100644 --- a/Documentation/ABI/testing/sysfs-devices +++ b/Documentation/ABI/testing/sysfs-devices @@ -1,6 +1,6 @@ What: /sys/devices Date: February 2006 -Contact: Greg Kroah-Hartman +Contact: Greg Kroah-Hartman Description: The /sys/devices tree contains a snapshot of the internal state of the kernel device tree. Devices will diff --git a/Documentation/ABI/testing/sysfs-driver-samsung-laptop b/Documentation/ABI/testing/sysfs-driver-samsung-laptop index 0a81023..e82e7c2 100644 --- a/Documentation/ABI/testing/sysfs-driver-samsung-laptop +++ b/Documentation/ABI/testing/sysfs-driver-samsung-laptop @@ -1,7 +1,7 @@ What: /sys/devices/platform/samsung/performance_level Date: January 1, 2010 KernelVersion: 2.6.33 -Contact: Greg Kroah-Hartman +Contact: Greg Kroah-Hartman Description: Some Samsung laptops have different "performance levels" that are can be modified by a function key, and by this sysfs file. These values don't always make a whole lot diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 4840334..5dbd906 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -189,7 +189,7 @@ Code Seq#(hex) Include File Comments 'Y' all linux/cyclades.h 'Z' 14-15 drivers/message/fusion/mptctl.h '[' 00-07 linux/usb/tmc.h USB Test and Measurement Devices - + 'a' all linux/atm*.h, linux/sonet.h ATM on linux 'b' 00-FF conflict! bit3 vme host bridge diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO index ab5189a..2f48f20 100644 --- a/Documentation/ko_KR/HOWTO +++ b/Documentation/ko_KR/HOWTO @@ -354,7 +354,7 @@ Andrew Morton에 의해 배포된 실험적인 커널 패치들이다. Andrew는 git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git quilt trees: - - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman < gregkh@suse.de> + - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman < gregkh@linuxfoundation.org> kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ - x86-64, partly i386, Andi Kleen < ak@suse.de> ftp.firstfloor.org:/pub/ak/x86_64/quilt/ diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt index 3ab2472..49578cf 100644 --- a/Documentation/kobject.txt +++ b/Documentation/kobject.txt @@ -1,6 +1,6 @@ Everything you never wanted to know about kobjects, ksets, and ktypes -Greg Kroah-Hartman +Greg Kroah-Hartman Based on an original article by Jon Corbet for lwn.net written October 1, 2003 and located at http://lwn.net/Articles/51437/ diff --git a/Documentation/zh_CN/HOWTO b/Documentation/zh_CN/HOWTO index faf976c..7fba5aa 100644 --- a/Documentation/zh_CN/HOWTO +++ b/Documentation/zh_CN/HOWTO @@ -316,7 +316,7 @@ linux-kernel邮件列表中提供反馈，告诉大家你遇到了问题还是 git.kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git 使用quilt管理的补丁集： - - USB, PCI, 驱动程序核心和I2C, Greg Kroah-Hartman + - USB, PCI, 驱动程序核心和I2C, Greg Kroah-Hartman kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ - x86-64, 部分i386, Andi Kleen ftp.firstfloor.org:/pub/ak/x86_64/quilt/ -- cgit v1.1 From bf06189e4d14641c0148bea16e9dd24943862215 Mon Sep 17 00:00:00 2001 From: Kees Cook Date: Tue, 14 Feb 2012 16:48:09 -0800 Subject: Yama: add PR_SET_PTRACER_ANY For a process to entirely disable Yama ptrace restrictions, it can use the special PR_SET_PTRACER_ANY pid to indicate that any otherwise allowed process may ptrace it. This is stronger than calling PR_SET_PTRACER with pid "1" because it includes processes in external pid namespaces. This is currently needed by the Chrome renderer, since its crash handler (Breakpad) runs external to the renderer's pid namespace. Signed-off-by: Kees Cook Signed-off-by: James Morris --- Documentation/security/Yama.txt | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/security/Yama.txt b/Documentation/security/Yama.txt index 4f0b789..a9511f1 100644 --- a/Documentation/security/Yama.txt +++ b/Documentation/security/Yama.txt @@ -41,7 +41,12 @@ other process (and its descendents) are allowed to call PTRACE_ATTACH against it. Only one such declared debugging process can exists for each inferior at a time. For example, this is used by KDE, Chromium, and Firefox's crash handlers, and by Wine for allowing only Wine processes -to ptrace each other. +to ptrace each other. If a process wishes to entirely disable these ptrace +restrictions, it can call prctl(PR_SET_PTRACER, PR_SET_PTRACER_ANY, ...) +so that any otherwise allowed process (even those in external pid namespaces) +may attach. + +The sysctl settings are: 0 - classic ptrace permissions: a process can PTRACE_ATTACH to any other process running under the same uid, as long as it is dumpable (i.e. -- cgit v1.1 From ca8f04247eaaec554528279686a514c6ce087bb9 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 16 Feb 2012 11:51:19 +0100 Subject: ALSA: hda/realtek - Add the fixup codes for ALC260 model=will The model=will for ALC260 requires the pin 0x0f to be a headphone and some special verbs for the COEF to turn on the amp. Now added these as fixup entries and removed the static model quirk. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index c8c5454..fd09f05 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -31,7 +31,6 @@ ALC260 ====== fujitsu Fujitsu S7020 acer Acer TravelMate - will Will laptops (PB V7900) replacer Replacer 672V favorit100 Maxdata Favorit 100XS basic fixed pin assignment (old default model) -- cgit v1.1 From 15317ab21686044f1af96dd329ba809a08f04b89 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 16 Feb 2012 12:02:53 +0100 Subject: ALSA: hda/realtek - Replace ALC260 model=acer with the auto-parser The ALC260 model=acer needs GPIO1 setup. It could be selected well if the codec SSID is set properly by BIOS, but to make sure, enable it forcibly. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index fd09f05..5cc7609 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -30,7 +30,6 @@ ALC880 ALC260 ====== fujitsu Fujitsu S7020 - acer Acer TravelMate replacer Replacer 672V favorit100 Maxdata Favorit 100XS basic fixed pin assignment (old default model) -- cgit v1.1 From 20f7d928fa6e51ca81648946ead6244c58a0b4c0 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 16 Feb 2012 12:35:16 +0100 Subject: ALSA: hda/realtek - Replace ALC260 model=replacer with the auto-parser The support for Replacer 627V in the auto-parser needs the unique unsol event handling: although the machine has a single output pin 0x0f, it's used for both the headphone and the speaker, and the driver needs to toggle the output route via GPIO 1. In addition, it needs a special COEF setup with 0x3050. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 5cc7609..870cb1a 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -30,7 +30,6 @@ ALC880 ALC260 ====== fujitsu Fujitsu S7020 - replacer Replacer 672V favorit100 Maxdata Favorit 100XS basic fixed pin assignment (old default model) test for testing/debugging purpose, almost all controls can -- cgit v1.1 From b1f58085a9c01e8ffab954fd77a45f1143edf34d Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 16 Feb 2012 12:45:03 +0100 Subject: ALSA: hda/realtek - Drop model=favorit100 for ALC260 It's working with the auto-parser just with the standard GPIO 1 setup. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 870cb1a..e63d5e2 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -30,7 +30,6 @@ ALC880 ALC260 ====== fujitsu Fujitsu S7020 - favorit100 Maxdata Favorit 100XS basic fixed pin assignment (old default model) test for testing/debugging purpose, almost all controls can adjusted. Appearing only when compiled with -- cgit v1.1 From c29b3f6dd7798964d77199af4925be72a3a48349 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 16 Feb 2012 12:47:36 +0100 Subject: ALSA: hda/realtek - Drop model=fujitsu from ALC260 static quirks The model works with the auto-parser as is, thus now good to drop. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index e63d5e2..5370339 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -29,7 +29,6 @@ ALC880 ALC260 ====== - fujitsu Fujitsu S7020 basic fixed pin assignment (old default model) test for testing/debugging purpose, almost all controls can adjusted. Appearing only when compiled with -- cgit v1.1 From c3c2c9e7ff3e38bd9ff5b721b6ae8634fce42802 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Thu, 16 Feb 2012 12:59:55 +0100 Subject: ALSA: hda/realtek - Remove leftover static quirks for ALC260 Now we can clean up all static quirks for ALC260. Also many codes in alc_quirks.c can be ripped off since they have been used only by ALC260 static quirks. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 5370339..2d34be3 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -29,11 +29,7 @@ ALC880 ALC260 ====== - basic fixed pin assignment (old default model) - test for testing/debugging purpose, almost all controls can - adjusted. Appearing only when compiled with - $CONFIG_SND_DEBUG=y - auto auto-config reading BIOS (default) + N/A ALC262 ====== -- cgit v1.1 From ea3d2fd1b11fb3ef8706a48ece0a49a61bcd08bc Mon Sep 17 00:00:00 2001 From: Marek Lindner Date: Tue, 29 Nov 2011 00:15:37 +0800 Subject: batman-adv: export used routing algorithm via sysfs Signed-off-by: Marek Lindner --- Documentation/ABI/testing/sysfs-class-net-mesh | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-class-net-mesh b/Documentation/ABI/testing/sysfs-class-net-mesh index b020014..b218e0f 100644 --- a/Documentation/ABI/testing/sysfs-class-net-mesh +++ b/Documentation/ABI/testing/sysfs-class-net-mesh @@ -65,6 +65,13 @@ Description: Defines the penalty which will be applied to an originator message's tq-field on every hop. +What: /sys/class/net//mesh/routing_algo +Date: Dec 2011 +Contact: Marek Lindner +Description: + Defines the routing procotol this mesh instance + uses to find the optimal paths through the mesh. + What: /sys/class/net//mesh/vis_mode Date: May 2010 Contact: Marek Lindner -- cgit v1.1 From dc6af52dea5ada1269095cad5ed2c04e92114399 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Fri, 17 Feb 2012 16:18:59 +0100 Subject: ALSA: hda/realtek - Rewrite ALC880 model=lg with the auto-parser ALC880 model=lg could work fine with the auto-parser due to the recent rewrite, but it still needs the manual adjustment; namely, the BIOS leaves unused pins as some real active jacks. This confuses the parser. Thus we just cover these pins and override the pin-configs as a fix-up. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 2d34be3..6387b41 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -17,7 +17,6 @@ ALC880 uniwill 3-jack fujitsu Fujitsu Laptops (Pi1536) F1734 2-jack - lg LG laptop (m1 express dual) lg-lw LG LW20/LW25 laptop tcl TCL S700 clevo Clevo laptops (m520G, m665n) -- cgit v1.1 From f02aab5d7fd53da95a78bb27bfbacc972ed75c10 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Fri, 17 Feb 2012 16:33:56 +0100 Subject: ALSA: hda/realtek - Rewrite ALC880 model=w810 with auto-parser The Medion W810 with ALC880 has a typical BIOS bug, copying the pin-defaults without disabling the unused pins. At least, the pin 0x17 must be disabled. Also, it requires GPIO-2 setup. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 6387b41..24df3ab 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -8,7 +8,6 @@ ALC880 5stack-digout 5-jack in back, 2-jack in front, a SPDIF out 6stack 6-jack in back, 2-jack in front 6stack-digout 6-jack with a SPDIF out - w810 3-jack z71v 3-jack (HP shared SPDIF) asus 3-jack (ASUS Mobo) asus-w1v ASUS W1V -- cgit v1.1 From 27e917f82bfcf8c51a2c025ddfb69e0b5947f50b Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Fri, 17 Feb 2012 17:49:54 +0100 Subject: ALSA: hda/realtek - Drop ALC880 model=clevo Clevo machines with ALC880 are all well with proper BIOS setup. It seems still requiring the additional COEF setup for the EAPD. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 24df3ab..58e8aac 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -18,7 +18,6 @@ ALC880 F1734 2-jack lg-lw LG LW20/LW25 laptop tcl TCL S700 - clevo Clevo laptops (m520G, m665n) medion Medion Rim 2150 test for testing/debugging purpose, almost all controls can be adjusted. Appearing only when compiled with -- cgit v1.1 From b9368f5c10b15f2b79a58666849827edc1f2f3d4 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Fri, 17 Feb 2012 17:54:44 +0100 Subject: ALSA: hda/realtek - Replace ALC880 model=tcl with auto-parser It needs a few extra setups for EAPD, but others look fairly straightforward. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 58e8aac..fd3b3b2 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -16,9 +16,6 @@ ALC880 uniwill 3-jack fujitsu Fujitsu Laptops (Pi1536) F1734 2-jack - lg-lw LG LW20/LW25 laptop - tcl TCL S700 - medion Medion Rim 2150 test for testing/debugging purpose, almost all controls can be adjusted. Appearing only when compiled with $CONFIG_SND_DEBUG=y -- cgit v1.1 From 1ec90174bdb4d8798299aebdcc078c3ac7e2e2c4 Mon Sep 17 00:00:00 2001 From: Jing Huang Date: Fri, 27 Jan 2012 16:51:51 -0800 Subject: [SCSI] bfa: add readme file This patch add bfa driver readme file to Documentation/scsi Signed-off-by: Jing Huang Signed-off-by: James Bottomley --- Documentation/scsi/bfa.txt | 82 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 Documentation/scsi/bfa.txt (limited to 'Documentation') diff --git a/Documentation/scsi/bfa.txt b/Documentation/scsi/bfa.txt new file mode 100644 index 0000000..f2d6e9d --- /dev/null +++ b/Documentation/scsi/bfa.txt @@ -0,0 +1,82 @@ +Linux driver for Brocade FC/FCOE adapters + + +Supported Hardware +------------------ + +bfa 3.0.2.2 driver supports all Brocade FC/FCOE adapters. Below is a list of +adapter models with corresponding PCIIDs. + + PCIID Model + + 1657:0013:1657:0014 425 4Gbps dual port FC HBA + 1657:0013:1657:0014 825 8Gbps PCIe dual port FC HBA + 1657:0013:103c:1742 HP 82B 8Gbps PCIedual port FC HBA + 1657:0013:103c:1744 HP 42B 4Gbps dual port FC HBA + 1657:0017:1657:0014 415 4Gbps single port FC HBA + 1657:0017:1657:0014 815 8Gbps single port FC HBA + 1657:0017:103c:1741 HP 41B 4Gbps single port FC HBA + 1657:0017:103c 1743 HP 81B 8Gbps single port FC HBA + 1657:0021:103c:1779 804 8Gbps FC HBA for HP Bladesystem c-class + + 1657:0014:1657:0014 1010 10Gbps single port CNA - FCOE + 1657:0014:1657:0014 1020 10Gbps dual port CNA - FCOE + 1657:0014:1657:0014 1007 10Gbps dual port CNA - FCOE + 1657:0014:1657:0014 1741 10Gbps dual port CNA - FCOE + + 1657:0022:1657:0024 1860 16Gbps FC HBA + 1657:0022:1657:0022 1860 10Gbps CNA - FCOE + + +Firmware download +----------------- + +The latest Firmware package for 3.0.2.2 bfa driver can be found at: + +http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page + +and then click following respective util package link: + + Version Link + + v3.0.0.0 Linux Adapter Firmware package for RHEL 6.2, SLES 11SP2 + + +Configuration & Management utility download +------------------------------------------- + +The latest driver configuration & management utility for 3.0.2.2 bfa driver can +be found at: + +http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page + +and then click following respective util pacakge link + + Version Link + + v3.0.2.0 Linux Adapter Firmware package for RHEL 6.2, SLES 11SP2 + + +Documentation +------------- + +The latest Administration's Guide, Installation and Reference Manual, +Troubleshooting Guide, and Release Notes for the corresponding out-of-box +driver can be found at: + +http://www.brocade.com/services-support/drivers-downloads/adapters/Linux.page + +and use the following inbox and out-of-box driver version mapping to find +the corresponding documentation: + + Inbox Version Out-of-box Version + + v3.0.2.2 v3.0.0.0 + + +Support +------- + +For general product and support info, go to the Brocade website at: + +http://www.brocade.com/services-support/index.page -- cgit v1.1 From bc3f957c069f4a678e9d250e4979e2344755913a Mon Sep 17 00:00:00 2001 From: Chad Dupuis Date: Thu, 9 Feb 2012 11:15:54 -0800 Subject: [SCSI] qla2xxx: Update LICENSE.qla2xxx. Signed-off-by: Giridhar Malavali Signed-off-by: Chad Dupuis Signed-off-by: James Bottomley --- Documentation/scsi/LICENSE.qla2xxx | 41 ++------------------------------------ 1 file changed, 2 insertions(+), 39 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scsi/LICENSE.qla2xxx b/Documentation/scsi/LICENSE.qla2xxx index 19e7cd4..ce0fdf3 100644 --- a/Documentation/scsi/LICENSE.qla2xxx +++ b/Documentation/scsi/LICENSE.qla2xxx @@ -1,48 +1,11 @@ Copyright (c) 2003-2011 QLogic Corporation -QLogic Linux/ESX Fibre Channel HBA Driver +QLogic Linux FC-FCoE Driver -This program includes a device driver for Linux 2.6/ESX that may be -distributed with QLogic hardware specific firmware binary file. +This program includes a device driver for Linux 3.x. You may modify and redistribute the device driver code under the GNU General Public License (a copy of which is attached hereto as Exhibit A) published by the Free Software Foundation (version 2). -You may redistribute the hardware specific firmware binary file -under the following terms: - - 1. Redistribution of source code (only if applicable), - must retain the above copyright notice, this list of - conditions and the following disclaimer. - - 2. Redistribution in binary form must reproduce the above - copyright notice, this list of conditions and the - following disclaimer in the documentation and/or other - materials provided with the distribution. - - 3. The name of QLogic Corporation may not be used to - endorse or promote products derived from this software - without specific prior written permission - -REGARDLESS OF WHAT LICENSING MECHANISM IS USED OR APPLICABLE, -THIS PROGRAM IS PROVIDED BY QLOGIC CORPORATION "AS IS'' AND ANY -EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE -IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A -PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR -BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, -EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED -TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, -DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON -ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, -OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY -OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE -POSSIBILITY OF SUCH DAMAGE. - -USER ACKNOWLEDGES AND AGREES THAT USE OF THIS PROGRAM WILL NOT -CREATE OR GIVE GROUNDS FOR A LICENSE BY IMPLICATION, ESTOPPEL, OR -OTHERWISE IN ANY INTELLECTUAL PROPERTY RIGHTS (PATENT, COPYRIGHT, -TRADE SECRET, MASK WORK, OR OTHER PROPRIETARY RIGHT) EMBODIED IN -ANY OTHER QLOGIC HARDWARE OR SOFTWARE EITHER SOLELY OR IN -COMBINATION WITH THIS PROGRAM. EXHIBIT A -- cgit v1.1 From 735f7d2fedf57380214221be7bed7f62d729e262 Mon Sep 17 00:00:00 2001 From: Dan Williams Date: Thu, 17 Nov 2011 17:59:47 -0800 Subject: [SCSI] libsas: fix domain_device leak Arrange for the deallocation of a struct domain_device object when it no longer has: 1/ any children 2/ references by any scsi_targets 3/ references by a lldd The comment about domain_device lifetime in Documentation/scsi/libsas.txt is stale as it appears mainline never had a version of a struct domain_device that was registered as a kobject. We now manage domain_device reference counts on behalf of external agents. Reviewed-by: Jack Wang Signed-off-by: Dan Williams Signed-off-by: James Bottomley --- Documentation/scsi/libsas.txt | 15 --------------- 1 file changed, 15 deletions(-) (limited to 'Documentation') diff --git a/Documentation/scsi/libsas.txt b/Documentation/scsi/libsas.txt index aa54f54..3cc9c78 100644 --- a/Documentation/scsi/libsas.txt +++ b/Documentation/scsi/libsas.txt @@ -398,21 +398,6 @@ struct sas_task { task_done -- callback when the task has finished execution }; -When an external entity, entity other than the LLDD or the -SAS Layer, wants to work with a struct domain_device, it -_must_ call kobject_get() when getting a handle on the -device and kobject_put() when it is done with the device. - -This does two things: - A) implements proper kfree() for the device; - B) increments/decrements the kref for all players: - domain_device - all domain_device's ... (if past an expander) - port - host adapter - pci device - and up the ladder, etc. - DISCOVERY --------- -- cgit v1.1 From cf5a22793cfa54c056655d374722dc5dfd496eca Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Mon, 20 Feb 2012 16:31:07 +0100 Subject: ALSA: hda/realtek - Rewrite ALC880 model=futjisu with auto-parser Now adding the support for the volume-knob widget, we can move the static quirk for ALC880 model=fujitsu to the auto-parser completely. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index fd3b3b2..936eef3 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -14,7 +14,6 @@ ALC880 asus-dig ASUS with SPDIF out asus-dig2 ASUS with SPDIF out (using GPIO2) uniwill 3-jack - fujitsu Fujitsu Laptops (Pi1536) F1734 2-jack test for testing/debugging purpose, almost all controls can be adjusted. Appearing only when compiled with -- cgit v1.1 From ba5338185dd522696f1c0d0957a724a1fdd1f39d Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Mon, 20 Feb 2012 16:36:52 +0100 Subject: ALSA: hda/realtek - Rewrite ALC880 model=F1734 with auto-parser Similar as the previous patch for model=fujitsu, we can now move the static quirk for F1734 to the auto-parser. The only difference is the default pin configurations: F1734 has less pins than Amilo's. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 936eef3..a57d771 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -14,7 +14,6 @@ ALC880 asus-dig ASUS with SPDIF out asus-dig2 ASUS with SPDIF out (using GPIO2) uniwill 3-jack - F1734 2-jack test for testing/debugging purpose, almost all controls can be adjusted. Appearing only when compiled with $CONFIG_SND_DEBUG=y -- cgit v1.1 From 817de92f1b52358f28534bb0b0c373f75e4b4baa Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Mon, 20 Feb 2012 17:20:48 +0100 Subject: ALSA: hda/realtek - Rewrite ALC880 model=uniwill with auto-parser The model=uniwill would work almost as is, but a couple of adjustments are needed to make the mutli-io working correctly. The headphone and speaker pins have to be marked properly in pin configs. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index a57d771..1af6354 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -13,7 +13,6 @@ ALC880 asus-w1v ASUS W1V asus-dig ASUS with SPDIF out asus-dig2 ASUS with SPDIF out (using GPIO2) - uniwill 3-jack test for testing/debugging purpose, almost all controls can be adjusted. Appearing only when compiled with $CONFIG_SND_DEBUG=y -- cgit v1.1 From 96e225f6922ecf3afafb55fdb0e6e771b3f71e94 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Mon, 20 Feb 2012 17:41:51 +0100 Subject: ALSA: hda/realtek - Rewrite ALC880 model=z71v with auto-parser ASUS Z71V has a totally broken BIOS setup (at least the info I got), thus we need to override the whole pin-config table to make the auto-parser working correctly. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 1af6354..43f3c71 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -8,7 +8,6 @@ ALC880 5stack-digout 5-jack in back, 2-jack in front, a SPDIF out 6stack 6-jack in back, 2-jack in front 6stack-digout 6-jack with a SPDIF out - z71v 3-jack (HP shared SPDIF) asus 3-jack (ASUS Mobo) asus-w1v ASUS W1V asus-dig ASUS with SPDIF out -- cgit v1.1 From 411225a01e57189b4116d5c61c0d64bd4b76e602 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Mon, 20 Feb 2012 17:48:19 +0100 Subject: ALSA: hda/realtek - Rewrite ALC880 model=asus-w1v with auto-parser ASUS W1V has a sane pin-config table set by BIOS. The only missing piece is the setup of GPIO1. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 43f3c71..f182067 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -9,7 +9,6 @@ ALC880 6stack 6-jack in back, 2-jack in front 6stack-digout 6-jack with a SPDIF out asus 3-jack (ASUS Mobo) - asus-w1v ASUS W1V asus-dig ASUS with SPDIF out asus-dig2 ASUS with SPDIF out (using GPIO2) test for testing/debugging purpose, almost all controls can be -- cgit v1.1 From 29e3fdcc84e5da04cb7e6a36fee0a772c91d3b28 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Mon, 20 Feb 2012 17:56:57 +0100 Subject: ALSA: hda/realtek - Drop model=asus* from ALC880 It turned out that BIOS on most of ASUS mobo's set the pin-config tables reasonably well for the auto-parser. We'd need GPIO setups, but should work as is other than that. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 3 --- 1 file changed, 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index f182067..62a6789 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -8,9 +8,6 @@ ALC880 5stack-digout 5-jack in back, 2-jack in front, a SPDIF out 6stack 6-jack in back, 2-jack in front 6stack-digout 6-jack with a SPDIF out - asus 3-jack (ASUS Mobo) - asus-dig ASUS with SPDIF out - asus-dig2 ASUS with SPDIF out (using GPIO2) test for testing/debugging purpose, almost all controls can be adjusted. Appearing only when compiled with $CONFIG_SND_DEBUG=y -- cgit v1.1 From 67b6ec3196da235317ff1b9474f17379b78f3294 Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Mon, 20 Feb 2012 18:20:42 +0100 Subject: ALSA: hda/realtek - Drop all ALC880 static quirks Finally the all static quirks for ALC880 are converted to the auto-parser. Since we are never sure whether the BIOS on so many old machines are really correct, the quirk table entries are copied as they are, but just providing the proper pin-config values accordingly. Since alc880_quirks.c is removed, alc882_quirks.c has to be adjusted slightly to be built again. There might be some compile warnings due to the remaining alc882 quirks, but these shall be killed sooner or later, I don't care it much at this point. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 4 ---- 1 file changed, 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 62a6789..1f64fb8 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -8,10 +8,6 @@ ALC880 5stack-digout 5-jack in back, 2-jack in front, a SPDIF out 6stack 6-jack in back, 2-jack in front 6stack-digout 6-jack with a SPDIF out - test for testing/debugging purpose, almost all controls can be - adjusted. Appearing only when compiled with - $CONFIG_SND_DEBUG=y - auto auto-config reading BIOS (default) ALC260 ====== -- cgit v1.1 From 1a97b7f22774b454531f013638b181803fba470f Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Tue, 21 Feb 2012 11:11:48 +0100 Subject: ALSA: hda/realtek - Remove the last static quirks for ALC882 Resitance is futile. The remaining static model quirks for Apple machines with ALC882-compatible codecs are converted to the auto-parser now. We can remove all alc*_quirks.c finally. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/HD-Audio-Models.txt | 50 +--------------------------- 1 file changed, 1 insertion(+), 49 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/HD-Audio-Models.txt b/Documentation/sound/alsa/HD-Audio-Models.txt index 1f64fb8..d97d992 100644 --- a/Documentation/sound/alsa/HD-Audio-Models.txt +++ b/Documentation/sound/alsa/HD-Audio-Models.txt @@ -43,55 +43,7 @@ ALC680 ALC882/883/885/888/889 ====================== - 3stack-dig 3-jack with SPDIF I/O - 6stack-dig 6-jack digital with SPDIF I/O - arima Arima W820Di1 - targa Targa T8, MSI-1049 T8 - asus-a7j ASUS A7J - asus-a7m ASUS A7M - macpro MacPro support - mb5 Macbook 5,1 - macmini3 Macmini 3,1 - mba21 Macbook Air 2,1 - mbp3 Macbook Pro rev3 - imac24 iMac 24'' with jack detection - imac91 iMac 9,1 - w2jc ASUS W2JC - 3stack-2ch-dig 3-jack with SPDIF I/O (ALC883) - alc883-6stack-dig 6-jack digital with SPDIF I/O (ALC883) - 3stack-6ch 3-jack 6-channel - 3stack-6ch-dig 3-jack 6-channel with SPDIF I/O - 6stack-dig-demo 6-jack digital for Intel demo board - acer Acer laptops (Travelmate 3012WTMi, Aspire 5600, etc) - acer-aspire Acer Aspire 9810 - acer-aspire-4930g Acer Aspire 4930G - acer-aspire-6530g Acer Aspire 6530G - acer-aspire-7730g Acer Aspire 7730G - acer-aspire-8930g Acer Aspire 8930G - medion Medion Laptops - targa-dig Targa/MSI - targa-2ch-dig Targa/MSI with 2-channel - targa-8ch-dig Targa/MSI with 8-channel (MSI GX620) - laptop-eapd 3-jack with SPDIF I/O and EAPD (Clevo M540JE, M550JE) - lenovo-101e Lenovo 101E - lenovo-nb0763 Lenovo NB0763 - lenovo-ms7195-dig Lenovo MS7195 - lenovo-sky Lenovo Sky - haier-w66 Haier W66 - 3stack-hp HP machines with 3stack (Lucknow, Samba boards) - 6stack-dell Dell machines with 6stack (Inspiron 530) - mitac Mitac 8252D - clevo-m540r Clevo M540R (6ch + digital) - clevo-m720 Clevo M720 laptop series - fujitsu-pi2515 Fujitsu AMILO Pi2515 - fujitsu-xa3530 Fujitsu AMILO XA3530 - 3stack-6ch-intel Intel DG33* boards - intel-alc889a Intel IbexPeak with ALC889A - intel-x58 Intel DX58 with ALC889 - asus-p5q ASUS P5Q-EM boards - mb31 MacBook 3,1 - sony-vaio-tt Sony VAIO TT - auto auto-config reading BIOS (default) + N/A ALC861/660 ========== -- cgit v1.1 From e19865219d2090e60ca1debd12d9d1e6e7a11a43 Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Sat, 11 Feb 2012 00:09:20 +0900 Subject: Documentation: Fix typo in watchdog-kernel-api.txt Correct spelling "retruns" to "returns" in Documentations/watchdog/watchdog-kernel-api.txt Signed-off-by: Masanari Iida Signed-off-by: Jiri Kosina --- Documentation/watchdog/watchdog-kernel-api.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/watchdog/watchdog-kernel-api.txt b/Documentation/watchdog/watchdog-kernel-api.txt index 4b93c28..9e16246 100644 --- a/Documentation/watchdog/watchdog-kernel-api.txt +++ b/Documentation/watchdog/watchdog-kernel-api.txt @@ -167,4 +167,4 @@ driver specific data to and a pointer to the data itself. The watchdog_get_drvdata function allows you to retrieve driver specific data. The argument of this function is the watchdog device where you want to retrieve -data from. The function retruns the pointer to the driver specific data. +data from. The function returns the pointer to the driver specific data. -- cgit v1.1 From 45f3122622e92fda1ee590ba740fa7cbd82d6ee3 Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Wed, 15 Feb 2012 23:59:47 +0900 Subject: Documentation: Fix typo in power-management.txt Correct spelling "diconnect()" to "disconnect()" in Documentation/usb/power-management.txt Signed-off-by: Masanari Iida Signed-off-by: Jiri Kosina --- Documentation/usb/power-management.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/usb/power-management.txt b/Documentation/usb/power-management.txt index 12511c9..817df29 100644 --- a/Documentation/usb/power-management.txt +++ b/Documentation/usb/power-management.txt @@ -345,7 +345,7 @@ autosuspend the device. Drivers need not be concerned about balancing changes to the usage counter; the USB core will undo any remaining "get"s when a driver is unbound from its interface. As a corollary, drivers must not call -any of the usb_autopm_* functions after their diconnect() routine has +any of the usb_autopm_* functions after their disconnect() routine has returned. Drivers using the async routines are responsible for their own -- cgit v1.1 From 4998d8ed54f5ebca49b7493c8f646344e6597a3e Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Thu, 16 Feb 2012 22:14:34 +0900 Subject: Documentation: Fix typo in thin-provisioning.txt Correct spelling "descibes" to "describes" in Documentation/device-mapper/thin-provisioning.txt Signed-off-by: Masanari Iida Signed-off-by: Jiri Kosina --- Documentation/device-mapper/thin-provisioning.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/device-mapper/thin-provisioning.txt b/Documentation/device-mapper/thin-provisioning.txt index 801d9d1..1ff044d 100644 --- a/Documentation/device-mapper/thin-provisioning.txt +++ b/Documentation/device-mapper/thin-provisioning.txt @@ -1,7 +1,7 @@ Introduction ============ -This document descibes a collection of device-mapper targets that +This document describes a collection of device-mapper targets that between them implement thin-provisioning and snapshots. The main highlight of this implementation, compared to the previous -- cgit v1.1 From edbfc1ba08b7cc4677fb1f781bd94dc154142215 Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Thu, 16 Feb 2012 23:19:56 +0900 Subject: Documentation: Fix typo in events-power.txt Correct spelling "Fequency" to "Frequency" in Documentation/trace/events-power.txt Signed-off-by: Masanari Iida Signed-off-by: Jiri Kosina --- Documentation/trace/events-power.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/trace/events-power.txt b/Documentation/trace/events-power.txt index 96d87b6..cf794af 100644 --- a/Documentation/trace/events-power.txt +++ b/Documentation/trace/events-power.txt @@ -57,7 +57,7 @@ power_end "cpu_id=%lu" The 'type' parameter takes one of those macros: . POWER_NONE = 0, . POWER_CSTATE = 1, /* C-State */ - . POWER_PSTATE = 2, /* Fequency change or DVFS */ + . POWER_PSTATE = 2, /* Frequency change or DVFS */ The 'state' parameter is set depending on the type: . Target C-state for type=POWER_CSTATE, -- cgit v1.1 From 67748df83055cea4598e7f7099f1f061cf61f530 Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Fri, 17 Feb 2012 23:42:34 +0900 Subject: Documentation: Fix typo in proc_usb_info.txt Correct typo "filsystem" to "filesystem" in Documentation/usb/proc_usb_info.txt Signed-off-by: Masanari Iida Signed-off-by: Jiri Kosina --- Documentation/usb/proc_usb_info.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/usb/proc_usb_info.txt b/Documentation/usb/proc_usb_info.txt index afe596d..c9c3f0f 100644 --- a/Documentation/usb/proc_usb_info.txt +++ b/Documentation/usb/proc_usb_info.txt @@ -7,7 +7,7 @@ The usbfs filesystem for USB devices is traditionally mounted at /proc/bus/usb. It provides the /proc/bus/usb/devices file, as well as the /proc/bus/usb/BBB/DDD files. -In many modern systems the usbfs filsystem isn't used at all. Instead +In many modern systems the usbfs filesystem isn't used at all. Instead USB device nodes are created under /dev/usb/ or someplace similar. The "devices" file is available in debugfs, typically as /sys/kernel/debug/usb/devices. -- cgit v1.1 From 1f8ee46b40efb13f8ce0d69ec6360badc7a39663 Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Mon, 13 Feb 2012 22:42:58 +0900 Subject: Documentation: Fix Broken URL "freshmeat" Fix broken URL in documents "freshmeat" to "freecode" in Documentation/filesystems/ramfs-rootfs-initramfs.txt, Documentation/scsi/scsi-generic.txt Documentation/usb/mtouchusb.txt Signed-off-by: Masanari Iida Acked-by: Randy Dunlap Signed-off-by: Jiri Kosina --- Documentation/filesystems/ramfs-rootfs-initramfs.txt | 2 +- Documentation/scsi/scsi-generic.txt | 2 +- Documentation/usb/mtouchusb.txt | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/ramfs-rootfs-initramfs.txt b/Documentation/filesystems/ramfs-rootfs-initramfs.txt index a8273d5..59b4a096 100644 --- a/Documentation/filesystems/ramfs-rootfs-initramfs.txt +++ b/Documentation/filesystems/ramfs-rootfs-initramfs.txt @@ -297,7 +297,7 @@ the above threads) is: either way about the archive format, and there are alternative tools, such as: - http://freshmeat.net/projects/afio/ + http://freecode.com/projects/afio 2) The cpio archive format chosen by the kernel is simpler and cleaner (and thus easier to create and parse) than any of the (literally dozens of) diff --git a/Documentation/scsi/scsi-generic.txt b/Documentation/scsi/scsi-generic.txt index 0a22ab8..51be20a 100644 --- a/Documentation/scsi/scsi-generic.txt +++ b/Documentation/scsi/scsi-generic.txt @@ -62,7 +62,7 @@ There are two packages of sg utilities: and earlier Both packages will work in the lk 2.4 series however sg3_utils offers more capabilities. They can be found at: http://sg.danny.cz/sg/sg3_utils.html and -freshmeat.net +freecode.com Another approach is to look at the applications that use the sg driver. These include cdrecord, cdparanoia, SANE and cdrdao. diff --git a/Documentation/usb/mtouchusb.txt b/Documentation/usb/mtouchusb.txt index 86302cd..a91adb2 100644 --- a/Documentation/usb/mtouchusb.txt +++ b/Documentation/usb/mtouchusb.txt @@ -1,7 +1,7 @@ CHANGES - 0.3 - Created based off of scanner & INSTALL from the original touchscreen - driver on freshmeat (http://freshmeat.net/projects/3mtouchscreendriver) + driver on freecode (http://freecode.com/projects/3mtouchscreendriver) - Amended for linux-2.4.18, then 2.4.19 - 0.5 - Complete rewrite using Linux Input in 2.6.3 -- cgit v1.1 From 010f4564b97931a22bb50be84f6010412b0bb74d Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Tue, 14 Feb 2012 23:19:07 +0900 Subject: Documentation: Fix broken URL "JF" Fix broken URL for JF (Japanese FAQ) and its e-mail address. Signed-off-by: Masanari Iida Acked-by: Randy Dunlap Signed-off-by: Jiri Kosina --- Documentation/00-INDEX | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index 65bbd26..a1a6432 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -7,8 +7,8 @@ Please try and keep the descriptions small enough to fit on one line. Following translations are available on the WWW: - - Japanese, maintained by the JF Project (JF@linux.or.jp), at - http://www.linux.or.jp/JF/ + - Japanese, maintained by the JF Project (jf@listserv.linux.or.jp), at + http://linuxjf.sourceforge.jp/ 00-INDEX - this file. -- cgit v1.1 From 24775d652b4dc52cc8dbcbdd20a732e5bdcc416a Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Wed, 15 Feb 2012 00:26:42 +0900 Subject: Documentation: Fix typo in kernel-parameters.txt Correct spelling "mininum" to "minimum", "conroller" to "controller" and "explicitely" to "explicitly" in Documentation/kernel-parameters.txt Signed-off-by: Masanari Iida Acked-by: Randy Dunlap Signed-off-by: Jiri Kosina --- Documentation/kernel-parameters.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 033d4e6..cfcc73f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -950,7 +950,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. controller i8042.nopnp [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX controllers - i8042.notimeout [HW] Ignore timeout condition signalled by conroller + i8042.notimeout [HW] Ignore timeout condition signalled by controller i8042.reset [HW] Reset the controller during init and cleanup i8042.unlock [HW] Unlock (ignore) the keylock @@ -2434,7 +2434,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. For more information see Documentation/vm/slub.txt. slub_min_order= [MM, SLUB] - Determines the mininum page order for slabs. Must be + Determines the minimum page order for slabs. Must be lower than slub_max_order. For more information see Documentation/vm/slub.txt. @@ -2600,7 +2600,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. threadirqs [KNL] Force threading of all interrupt handlers except those - marked explicitely IRQF_NO_THREAD. + marked explicitly IRQF_NO_THREAD. topology= [S390] Format: {off | on} -- cgit v1.1 From 98cca250aecaf3f1b2fec003e1c0ce0bfaa4be36 Mon Sep 17 00:00:00 2001 From: Kyle Moffett Date: Thu, 22 Dec 2011 10:19:10 +0000 Subject: fsl/mpic: Document and use the "big-endian" device-tree flag The MPIC code checks for a "big-endian" property and sets the flag MPIC_BIG_ENDIAN if one is present, although prior to the "mpic->flags" fixup that would never have worked anways. Unfortunately, even now that it works properly, the Freescale mpic device-node (the "PowerQUICC-III"-compatible one) does not specify it, so all of the board ports need to manually pass it to mpic_alloc(). Document the flag and add it to the pq3 device tree. Existing code will still need to pass the MPIC_BIG_ENDIAN flag because their dtb may not have this property, but new platforms shouldn't need to do so. Signed-off-by: Kyle Moffett Signed-off-by: Benjamin Herrenschmidt --- Documentation/devicetree/bindings/powerpc/fsl/mpic.txt | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt index 2cf38bd..ebafba2 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt @@ -56,7 +56,14 @@ PROPERTIES to the client. The presence of this property also mandates that any initialization related to interrupt sources shall be limited to sources explicitly referenced in the device tree. - + + - big-endian + Usage: optional + Value type: + If present the MPIC will be assumed to be big-endian. Some + device-trees omit this property on MPIC nodes even when the MPIC is + in fact big-endian, so certain boards override this property. + INTERRUPT SPECIFIER DEFINITION Interrupt specifiers consists of 4 cells encoded as -- cgit v1.1 From 9ca163c8602681ad098910f48f89b97f0cb87c4f Mon Sep 17 00:00:00 2001 From: Kyle Moffett Date: Thu, 22 Dec 2011 10:19:11 +0000 Subject: fsl/mpic: Create and document the "single-cpu-affinity" device-tree flag The Freescale MPIC (and perhaps others in the future) is incapable of routing non-IPI interrupts to more than once CPU at a time. Currently all of the Freescale boards msut pass the MPIC_SINGLE_DEST_CPU flag to mpic_alloc(), but that information should really be present in the device-tree. Older board code can't rely on the device-tree having the property set, but newer platforms won't need it manually specified in the code. [BenH: Remove unrelated changes, folded in a different patch] Signed-off-by: Kyle Moffett Signed-off-by: Benjamin Herrenschmidt --- Documentation/devicetree/bindings/powerpc/fsl/mpic.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt index ebafba2..b393ccf 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt @@ -64,6 +64,12 @@ PROPERTIES device-trees omit this property on MPIC nodes even when the MPIC is in fact big-endian, so certain boards override this property. + - single-cpu-affinity + Usage: optional + Value type: + If present the MPIC will be assumed to only be able to route + non-IPI interrupts to a single CPU at a time (EG: Freescale MPIC). + INTERRUPT SPECIFIER DEFINITION Interrupt specifiers consists of 4 cells encoded as -- cgit v1.1 From c1b8d45db4dbc64cc6015f97922f767fdf782f64 Mon Sep 17 00:00:00 2001 From: Kyle Moffett Date: Thu, 22 Dec 2011 10:19:13 +0000 Subject: powerpc/mpic: Add "last-interrupt-source" property to override hardware The FreeScale PowerQUICC-III-compatible (mpc85xx/mpc86xx) MPICs do not correctly report the number of hardware interrupt sources, so software needs to override the detected value with "256". To avoid needing to write custom board-specific code to detect that scenario, allow it to be easily overridden in the device-tree. Signed-off-by: Kyle Moffett Signed-off-by: Benjamin Herrenschmidt --- Documentation/devicetree/bindings/powerpc/fsl/mpic.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt index b393ccf..dc57446 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic.txt @@ -70,6 +70,13 @@ PROPERTIES If present the MPIC will be assumed to only be able to route non-IPI interrupts to a single CPU at a time (EG: Freescale MPIC). + - last-interrupt-source + Usage: optional + Value type: + Some MPICs do not correctly report the number of hardware sources + in the global feature registers. If specified, this field will + override the value read from MPIC_GREG_FEATURE_LAST_SRC. + INTERRUPT SPECIFIER DEFINITION Interrupt specifiers consists of 4 cells encoded as -- cgit v1.1 From 8e0aa6d436f303a37df7ec68758883ade077d123 Mon Sep 17 00:00:00 2001 From: Mahesh Salgaonkar Date: Thu, 16 Feb 2012 01:14:14 +0000 Subject: fadump: Add documentation for firmware-assisted dump. Documentation for firmware-assisted dump. This document is based on the original documentation written for phyp assisted dump by Linas Vepstas and Manish Ahuja, with few changes to reflect the current implementation. Signed-off-by: Mahesh Salgaonkar Signed-off-by: Benjamin Herrenschmidt --- Documentation/powerpc/firmware-assisted-dump.txt | 270 +++++++++++++++++++++++ 1 file changed, 270 insertions(+) create mode 100644 Documentation/powerpc/firmware-assisted-dump.txt (limited to 'Documentation') diff --git a/Documentation/powerpc/firmware-assisted-dump.txt b/Documentation/powerpc/firmware-assisted-dump.txt new file mode 100644 index 0000000..3007bc9 --- /dev/null +++ b/Documentation/powerpc/firmware-assisted-dump.txt @@ -0,0 +1,270 @@ + + Firmware-Assisted Dump + ------------------------ + July 2011 + +The goal of firmware-assisted dump is to enable the dump of +a crashed system, and to do so from a fully-reset system, and +to minimize the total elapsed time until the system is back +in production use. + +- Firmware assisted dump (fadump) infrastructure is intended to replace + the existing phyp assisted dump. +- Fadump uses the same firmware interfaces and memory reservation model + as phyp assisted dump. +- Unlike phyp dump, fadump exports the memory dump through /proc/vmcore + in the ELF format in the same way as kdump. This helps us reuse the + kdump infrastructure for dump capture and filtering. +- Unlike phyp dump, userspace tool does not need to refer any sysfs + interface while reading /proc/vmcore. +- Unlike phyp dump, fadump allows user to release all the memory reserved + for dump, with a single operation of echo 1 > /sys/kernel/fadump_release_mem. +- Once enabled through kernel boot parameter, fadump can be + started/stopped through /sys/kernel/fadump_registered interface (see + sysfs files section below) and can be easily integrated with kdump + service start/stop init scripts. + +Comparing with kdump or other strategies, firmware-assisted +dump offers several strong, practical advantages: + +-- Unlike kdump, the system has been reset, and loaded + with a fresh copy of the kernel. In particular, + PCI and I/O devices have been reinitialized and are + in a clean, consistent state. +-- Once the dump is copied out, the memory that held the dump + is immediately available to the running kernel. And therefore, + unlike kdump, fadump doesn't need a 2nd reboot to get back + the system to the production configuration. + +The above can only be accomplished by coordination with, +and assistance from the Power firmware. The procedure is +as follows: + +-- The first kernel registers the sections of memory with the + Power firmware for dump preservation during OS initialization. + These registered sections of memory are reserved by the first + kernel during early boot. + +-- When a system crashes, the Power firmware will save + the low memory (boot memory of size larger of 5% of system RAM + or 256MB) of RAM to the previous registered region. It will + also save system registers, and hardware PTE's. + + NOTE: The term 'boot memory' means size of the low memory chunk + that is required for a kernel to boot successfully when + booted with restricted memory. By default, the boot memory + size will be the larger of 5% of system RAM or 256MB. + Alternatively, user can also specify boot memory size + through boot parameter 'fadump_reserve_mem=' which will + override the default calculated size. Use this option + if default boot memory size is not sufficient for second + kernel to boot successfully. + +-- After the low memory (boot memory) area has been saved, the + firmware will reset PCI and other hardware state. It will + *not* clear the RAM. It will then launch the bootloader, as + normal. + +-- The freshly booted kernel will notice that there is a new + node (ibm,dump-kernel) in the device tree, indicating that + there is crash data available from a previous boot. During + the early boot OS will reserve rest of the memory above + boot memory size effectively booting with restricted memory + size. This will make sure that the second kernel will not + touch any of the dump memory area. + +-- User-space tools will read /proc/vmcore to obtain the contents + of memory, which holds the previous crashed kernel dump in ELF + format. The userspace tools may copy this info to disk, or + network, nas, san, iscsi, etc. as desired. + +-- Once the userspace tool is done saving dump, it will echo + '1' to /sys/kernel/fadump_release_mem to release the reserved + memory back to general use, except the memory required for + next firmware-assisted dump registration. + + e.g. + # echo 1 > /sys/kernel/fadump_release_mem + +Please note that the firmware-assisted dump feature +is only available on Power6 and above systems with recent +firmware versions. + +Implementation details: +---------------------- + +During boot, a check is made to see if firmware supports +this feature on that particular machine. If it does, then +we check to see if an active dump is waiting for us. If yes +then everything but boot memory size of RAM is reserved during +early boot (See Fig. 2). This area is released once we finish +collecting the dump from user land scripts (e.g. kdump scripts) +that are run. If there is dump data, then the +/sys/kernel/fadump_release_mem file is created, and the reserved +memory is held. + +If there is no waiting dump data, then only the memory required +to hold CPU state, HPTE region, boot memory dump and elfcore +header, is reserved at the top of memory (see Fig. 1). This area +is *not* released: this region will be kept permanently reserved, +so that it can act as a receptacle for a copy of the boot memory +content in addition to CPU state and HPTE region, in the case a +crash does occur. + + o Memory Reservation during first kernel + + Low memory Top of memory + 0 boot memory size | + | | |<--Reserved dump area -->| + V V | Permanent Reservation V + +-----------+----------/ /----------+---+----+-----------+----+ + | | |CPU|HPTE| DUMP |ELF | + +-----------+----------/ /----------+---+----+-----------+----+ + | ^ + | | + \ / + ------------------------------------------- + Boot memory content gets transferred to + reserved area by firmware at the time of + crash + Fig. 1 + + o Memory Reservation during second kernel after crash + + Low memory Top of memory + 0 boot memory size | + | |<------------- Reserved dump area ----------- -->| + V V V + +-----------+----------/ /----------+---+----+-----------+----+ + | | |CPU|HPTE| DUMP |ELF | + +-----------+----------/ /----------+---+----+-----------+----+ + | | + V V + Used by second /proc/vmcore + kernel to boot + Fig. 2 + +Currently the dump will be copied from /proc/vmcore to a +a new file upon user intervention. The dump data available through +/proc/vmcore will be in ELF format. Hence the existing kdump +infrastructure (kdump scripts) to save the dump works fine with +minor modifications. + +The tools to examine the dump will be same as the ones +used for kdump. + +How to enable firmware-assisted dump (fadump): +------------------------------------- + +1. Set config option CONFIG_FA_DUMP=y and build kernel. +2. Boot into linux kernel with 'fadump=on' kernel cmdline option. +3. Optionally, user can also set 'fadump_reserve_mem=' kernel cmdline + to specify size of the memory to reserve for boot memory dump + preservation. + +NOTE: If firmware-assisted dump fails to reserve memory then it will + fallback to existing kdump mechanism if 'crashkernel=' option + is set at kernel cmdline. + +Sysfs/debugfs files: +------------ + +Firmware-assisted dump feature uses sysfs file system to hold +the control files and debugfs file to display memory reserved region. + +Here is the list of files under kernel sysfs: + + /sys/kernel/fadump_enabled + + This is used to display the fadump status. + 0 = fadump is disabled + 1 = fadump is enabled + + This interface can be used by kdump init scripts to identify if + fadump is enabled in the kernel and act accordingly. + + /sys/kernel/fadump_registered + + This is used to display the fadump registration status as well + as to control (start/stop) the fadump registration. + 0 = fadump is not registered. + 1 = fadump is registered and ready to handle system crash. + + To register fadump echo 1 > /sys/kernel/fadump_registered and + echo 0 > /sys/kernel/fadump_registered for un-register and stop the + fadump. Once the fadump is un-registered, the system crash will not + be handled and vmcore will not be captured. This interface can be + easily integrated with kdump service start/stop. + + /sys/kernel/fadump_release_mem + + This file is available only when fadump is active during + second kernel. This is used to release the reserved memory + region that are held for saving crash dump. To release the + reserved memory echo 1 to it: + + echo 1 > /sys/kernel/fadump_release_mem + + After echo 1, the content of the /sys/kernel/debug/powerpc/fadump_region + file will change to reflect the new memory reservations. + + The existing userspace tools (kdump infrastructure) can be easily + enhanced to use this interface to release the memory reserved for + dump and continue without 2nd reboot. + +Here is the list of files under powerpc debugfs: +(Assuming debugfs is mounted on /sys/kernel/debug directory.) + + /sys/kernel/debug/powerpc/fadump_region + + This file shows the reserved memory regions if fadump is + enabled otherwise this file is empty. The output format + is: + : [-] bytes, Dumped: + + e.g. + Contents when fadump is registered during first kernel + + # cat /sys/kernel/debug/powerpc/fadump_region + CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x0 + HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x0 + DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x0 + + Contents when fadump is active during second kernel + + # cat /sys/kernel/debug/powerpc/fadump_region + CPU : [0x0000006ffb0000-0x0000006fff001f] 0x40020 bytes, Dumped: 0x40020 + HPTE: [0x0000006fff0020-0x0000006fff101f] 0x1000 bytes, Dumped: 0x1000 + DUMP: [0x0000006fff1020-0x0000007fff101f] 0x10000000 bytes, Dumped: 0x10000000 + : [0x00000010000000-0x0000006ffaffff] 0x5ffb0000 bytes, Dumped: 0x5ffb0000 + +NOTE: Please refer to Documentation/filesystems/debugfs.txt on + how to mount the debugfs filesystem. + + +TODO: +----- + o Need to come up with the better approach to find out more + accurate boot memory size that is required for a kernel to + boot successfully when booted with restricted memory. + o The fadump implementation introduces a fadump crash info structure + in the scratch area before the ELF core header. The idea of introducing + this structure is to pass some important crash info data to the second + kernel which will help second kernel to populate ELF core header with + correct data before it gets exported through /proc/vmcore. The current + design implementation does not address a possibility of introducing + additional fields (in future) to this structure without affecting + compatibility. Need to come up with the better approach to address this. + The possible approaches are: + 1. Introduce version field for version tracking, bump up the version + whenever a new field is added to the structure in future. The version + field can be used to find out what fields are valid for the current + version of the structure. + 2. Reserve the area of predefined size (say PAGE_SIZE) for this + structure and have unused area as reserved (initialized to zero) + for future field additions. + The advantage of approach 1 over 2 is we don't need to reserve extra space. +--- +Author: Mahesh Salgaonkar +This document is based on the original documentation written for phyp +assisted dump by Linas Vepstas and Manish Ahuja. -- cgit v1.1 From 12d9299241241200e4f34f3b02f206fa8384a923 Mon Sep 17 00:00:00 2001 From: Mahesh Salgaonkar Date: Thu, 16 Feb 2012 01:15:23 +0000 Subject: fadump: Remove the phyp assisted dump code. Remove the phyp assisted dump implementation which is not is use. Signed-off-by: Mahesh Salgaonkar Signed-off-by: Benjamin Herrenschmidt --- Documentation/powerpc/phyp-assisted-dump.txt | 127 --------------------------- 1 file changed, 127 deletions(-) delete mode 100644 Documentation/powerpc/phyp-assisted-dump.txt (limited to 'Documentation') diff --git a/Documentation/powerpc/phyp-assisted-dump.txt b/Documentation/powerpc/phyp-assisted-dump.txt deleted file mode 100644 index ad34020..0000000 --- a/Documentation/powerpc/phyp-assisted-dump.txt +++ /dev/null @@ -1,127 +0,0 @@ - - Hypervisor-Assisted Dump - ------------------------ - November 2007 - -The goal of hypervisor-assisted dump is to enable the dump of -a crashed system, and to do so from a fully-reset system, and -to minimize the total elapsed time until the system is back -in production use. - -As compared to kdump or other strategies, hypervisor-assisted -dump offers several strong, practical advantages: - --- Unlike kdump, the system has been reset, and loaded - with a fresh copy of the kernel. In particular, - PCI and I/O devices have been reinitialized and are - in a clean, consistent state. --- As the dump is performed, the dumped memory becomes - immediately available to the system for normal use. --- After the dump is completed, no further reboots are - required; the system will be fully usable, and running - in its normal, production mode on its normal kernel. - -The above can only be accomplished by coordination with, -and assistance from the hypervisor. The procedure is -as follows: - --- When a system crashes, the hypervisor will save - the low 256MB of RAM to a previously registered - save region. It will also save system state, system - registers, and hardware PTE's. - --- After the low 256MB area has been saved, the - hypervisor will reset PCI and other hardware state. - It will *not* clear RAM. It will then launch the - bootloader, as normal. - --- The freshly booted kernel will notice that there - is a new node (ibm,dump-kernel) in the device tree, - indicating that there is crash data available from - a previous boot. It will boot into only 256MB of RAM, - reserving the rest of system memory. - --- Userspace tools will parse /sys/kernel/release_region - and read /proc/vmcore to obtain the contents of memory, - which holds the previous crashed kernel. The userspace - tools may copy this info to disk, or network, nas, san, - iscsi, etc. as desired. - - For Example: the values in /sys/kernel/release-region - would look something like this (address-range pairs). - CPU:0x177fee000-0x10000: HPTE:0x177ffe020-0x1000: / - DUMP:0x177fff020-0x10000000, 0x10000000-0x16F1D370A - --- As the userspace tools complete saving a portion of - dump, they echo an offset and size to - /sys/kernel/release_region to release the reserved - memory back to general use. - - An example of this is: - "echo 0x40000000 0x10000000 > /sys/kernel/release_region" - which will release 256MB at the 1GB boundary. - -Please note that the hypervisor-assisted dump feature -is only available on Power6-based systems with recent -firmware versions. - -Implementation details: ----------------------- - -During boot, a check is made to see if firmware supports -this feature on this particular machine. If it does, then -we check to see if a active dump is waiting for us. If yes -then everything but 256 MB of RAM is reserved during early -boot. This area is released once we collect a dump from user -land scripts that are run. If there is dump data, then -the /sys/kernel/release_region file is created, and -the reserved memory is held. - -If there is no waiting dump data, then only the highest -256MB of the ram is reserved as a scratch area. This area -is *not* released: this region will be kept permanently -reserved, so that it can act as a receptacle for a copy -of the low 256MB in the case a crash does occur. See, -however, "open issues" below, as to whether -such a reserved region is really needed. - -Currently the dump will be copied from /proc/vmcore to a -a new file upon user intervention. The starting address -to be read and the range for each data point in provided -in /sys/kernel/release_region. - -The tools to examine the dump will be same as the ones -used for kdump. - -General notes: --------------- -Security: please note that there are potential security issues -with any sort of dump mechanism. In particular, plaintext -(unencrypted) data, and possibly passwords, may be present in -the dump data. Userspace tools must take adequate precautions to -preserve security. - -Open issues/ToDo: ------------- - o The various code paths that tell the hypervisor that a crash - occurred, vs. it simply being a normal reboot, should be - reviewed, and possibly clarified/fixed. - - o Instead of using /sys/kernel, should there be a /sys/dump - instead? There is a dump_subsys being created by the s390 code, - perhaps the pseries code should use a similar layout as well. - - o Is reserving a 256MB region really required? The goal of - reserving a 256MB scratch area is to make sure that no - important crash data is clobbered when the hypervisor - save low mem to the scratch area. But, if one could assure - that nothing important is located in some 256MB area, then - it would not need to be reserved. Something that can be - improved in subsequent versions. - - o Still working the kdump team to integrate this with kdump, - some work remains but this would not affect the current - patches. - - o Still need to write a shell script, to copy the dump away. - Currently I am parsing it manually. -- cgit v1.1 From 7570a333d8b00e7fd4b05d898e353000a70210ce Mon Sep 17 00:00:00 2001 From: MUNEDA Takahiro Date: Thu, 2 Feb 2012 11:09:22 -0500 Subject: PCI: Add pcie_hp=nomsi to disable MSI/MSI-X for pciehp driver Add a parameter to avoid using MSI/MSI-X for PCIe native hotplug; it's known to be buggy on some platforms. In my environment, while shutting down, following stack trace is shown sometimes. irq 16: nobody cared (try booting with the "irqpoll" option) Pid: 1081, comm: reboot Not tainted 3.2.0 #1 Call Trace: [] __report_bad_irq+0x3d/0xe0 [] note_interrupt+0x15c/0x210 [] handle_irq_event_percpu+0xb5/0x210 [] handle_irq_event+0x41/0x70 [] handle_fasteoi_irq+0x55/0xc0 [] handle_irq+0x46/0xb0 [] do_IRQ+0x5d/0xe0 [] common_interrupt+0x6e/0x6e [] ? __do_softirq+0x60/0x210 [] ? hrtimer_interrupt+0x151/0x240 [] call_softirq+0x1c/0x30 [] do_softirq+0x65/0xa0 [] irq_exit+0xbd/0xe0 [] smp_apic_timer_interrupt+0x6e/0x99 [] apic_timer_interrupt+0x6e/0x80 [] ? _raw_spin_unlock_irqrestore+0x11/0x20 [] pci_bus_write_config_word+0x6c/0x80 [] pci_intx+0x52/0xa0 [] pci_intx_for_msi+0x1d/0x30 [] pci_msi_shutdown+0x7b/0x110 [] pci_device_shutdown+0x34/0x50 [] device_shutdown+0x2f/0x140 [] kernel_restart_prepare+0x31/0x40 [] kernel_restart+0x16/0x60 [] sys_reboot+0x1ad/0x220 [] ? do_page_fault+0x1e0/0x460 [] ? __sync_filesystem+0x90/0x90 [] ? __cond_resched+0x2a/0x40 [] ? _cond_resched+0x30/0x40 [] ? iterate_supers+0xb7/0xd0 [] system_call_fastpath+0x16/0x1b handlers: [] usb_hcd_irq [] usb_hcd_irq [] usb_hcd_irq Disabling IRQ #16 An un-wanted interrupt is generated when PCI driver switches from MSI/MSI-X to INTx while shutting down the device. The interrupt does not happen if MSI/MSI-X is not used on the device. I confirmed that this problem does not happen if pcie_hp=nomsi was specified and hotplug operation worked fine as usual. v2: Automatically disable MSI/MSI-X against following device: PCI bridge: Integrated Device Technology, Inc. Device 807f (rev 02) v3: Based on the review comment, combile the if statements. v4: Removed module parameter. Move some code to build pciehp as a module. Move device specific code to driver/pci/quirks.c. v5: Drop a device specific code until getting a vendor statement. Reviewed-by: Kenji Kaneshige Signed-off-by: MUNEDA Takahiro Signed-off-by: Jesse Barnes --- Documentation/kernel-parameters.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 033d4e6..7fb7a4b 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2118,6 +2118,10 @@ bytes respectively. Such letter suffixes can also be entirely omitted. force Enable ASPM even on devices that claim not to support it. WARNING: Forcing ASPM on may cause system lockups. + pcie_hp= [PCIE] PCI Express Hotplug driver options: + nomsi Do not use MSI for PCI Express Native Hotplug (this + makes all PCIe ports use INTx for hotplug services). + pcie_ports= [PCIE] PCIe ports handling: auto Ask the BIOS whether or not to use native PCIe services associated with PCIe ports (PME, hot-plug, AER). Use -- cgit v1.1 From 1681f5ae4ca25bddb6f7b6d4f463cc83e3d1ad01 Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Wed, 22 Feb 2012 14:25:58 -0700 Subject: pinctrl: disallow map table entries with NULL dev_name field Hog entries are mapping table entries with .ctrl_dev_name == .dev_name. All other mapping table entries need .dev_name set so that they will match some pinctrl_get() call. All extant PIN_MAP*() macros set .dev_name. So, there is no reason to allow mapping table entries without .dev_name set. Update the code and documentation to disallow this. Signed-off-by: Stephen Warren Acked-by: Dong Aisheng Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 15 +++++---------- 1 file changed, 5 insertions(+), 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index ee3266b..fa9163a 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -494,14 +494,10 @@ Definitions: {"map-i2c0", i2c0, pinctrl0, fi2c0, gi2c0} } - Every map must be assigned a symbolic name, pin controller and function. - The group is not compulsory - if it is omitted the first group presented by - the driver as applicable for the function will be selected, which is - useful for simple cases. - - The device name is present in map entries tied to specific devices. Maps - without device names are referred to as SYSTEM pinmuxes, such as can be taken - by the machine implementation on boot and not tied to any specific device. + Every map must be assigned a state name, pin controller, device and + function. The group is not compulsory - if it is omitted the first group + presented by the driver as applicable for the function will be selected, + which is useful for simple cases. It is possible to map several groups to the same combination of device, pin controller and function. This is for cases where a certain function on @@ -983,8 +979,7 @@ after this you should be able to see this in the debugfs listing of all pins. System pin control hogging ========================== -A system pin control map entry, i.e. a pin control setting that does not have -a device associated with it, can be hogged by the core when the pin controller +Pin control map entries can be hogged by the core when the pin controller is registered. This means that the core will attempt to call pinctrl_get() and pinctrl_enable() on it immediately after the pin control device has been registered. -- cgit v1.1 From 36eabda3d094dae30a74350c6289c163349b744d Mon Sep 17 00:00:00 2001 From: Ben Greear Date: Sat, 11 Feb 2012 15:39:14 +0000 Subject: net: Support RXFCS feature flag. When set on hardware that supports the feature, this causes the Ethernet FCS to be appended to the end of the skb. Useful for sniffing packets. Signed-off-by: Ben Greear Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher --- Documentation/networking/netdev-features.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-features.txt b/Documentation/networking/netdev-features.txt index 4b1c0dc..7d27812 100644 --- a/Documentation/networking/netdev-features.txt +++ b/Documentation/networking/netdev-features.txt @@ -152,3 +152,9 @@ 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.] + +* rx-fcs + +This requests that the NIC append the Ethernet Frame Checksum (FCS) +to the end of the skb data. This allows sniffers and other tools to +read the CRC recorded by the NIC on receipt of the packet. -- cgit v1.1 From 5e0c03c8cd40e5c3b7ba624b8ba9a343de79ade1 Mon Sep 17 00:00:00 2001 From: Ben Greear Date: Sat, 11 Feb 2012 15:39:45 +0000 Subject: net: Support RX-ALL feature flag. This flag requests that network devices pass all received frames up the stack, even ones with errors such as invalid FCS (frame check sum). This will allow sniffers to see bad packets and perhaps give the user some idea how to fix the problem. Signed-off-by: Ben Greear Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher --- Documentation/networking/netdev-features.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/networking/netdev-features.txt b/Documentation/networking/netdev-features.txt index 7d27812..4164f5c 100644 --- a/Documentation/networking/netdev-features.txt +++ b/Documentation/networking/netdev-features.txt @@ -158,3 +158,10 @@ VLANs. This may be not useful, though.] This requests that the NIC append the Ethernet Frame Checksum (FCS) to the end of the skb data. This allows sniffers and other tools to read the CRC recorded by the NIC on receipt of the packet. + +* rx-all + +This requests that the NIC receive all possible frames, including errored +frames (such as bad FCS, etc). This can be helpful when sniffing a link with +bad packets on it. Some NICs may receive more packets if also put into normal +PROMISC mdoe. -- cgit v1.1 From b55438fdd5173a367659a7e200acea6c9f77b8cb Mon Sep 17 00:00:00 2001 From: Yinghai Lu Date: Thu, 23 Feb 2012 19:23:30 -0800 Subject: PCI: prepare pci=realloc for multiple options Let the user could enable and disable with pci=realloc=on or pci=realloc=off Also 1. move variable and functions near the place they are used. 2. change macro to function 3. change related functions and variable to static and _init 4. update parameter description accordingly. This will let us add a config option to control default behavior, and still allow the user to turn off automatic reallocation if it fails on their platform until a permanent solution is found. -v2: still honor pci=realloc, and treat it as pci=realloc=on also use enum instead of ... -v3: update kernel-paramenters.txt according to Jesse. Signed-off-by: Yinghai Lu Acked-by: Jesse Barnes Signed-off-by: Jesse Barnes --- Documentation/kernel-parameters.txt | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 7fb7a4b..7dc523e 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2109,8 +2109,13 @@ 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. + realloc= Enable/disable reallocating PCI bridge resources + if allocations done by BIOS are too small to + accommodate resources required by all child + devices. + off: Turn realloc off + on: Turn realloc on + realloc same as realloc=on pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power Management. -- cgit v1.1 From a6f2fd557f993aecc93d51afd9e339524107937f Mon Sep 17 00:00:00 2001 From: Takashi Iwai Date: Tue, 28 Feb 2012 11:58:40 +0100 Subject: ALSA: hda - Add position_fix=4 (COMBO) option This patch adds a new position_fix option value, 4, as a combo mode to use LPIB for playbacks and POSBUF for captures. It's the way recommended by Intel hardware guys. Signed-off-by: Takashi Iwai --- Documentation/sound/alsa/ALSA-Configuration.txt | 8 +++++++- Documentation/sound/alsa/HD-Audio.txt | 7 ++++++- 2 files changed, 13 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 936699e..9af64c5 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -860,7 +860,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. [Multiple options for each card instance] model - force the model name - position_fix - Fix DMA pointer (0 = auto, 1 = use LPIB, 2 = POSBUF) + position_fix - Fix DMA pointer (0 = auto, 1 = use LPIB, 2 = POSBUF, + 3 = VIACOMBO, 4 = COMBO) probe_mask - Bitmask to probe codecs (default = -1, meaning all slots) When the bit 8 (0x100) is set, the lower 8 bits are used as the "fixed" codec slots; i.e. the driver probes the @@ -925,6 +926,11 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. (Usually SD_LPIB register is more accurate than the position buffer.) + position_fix=3 is specific to VIA devices. The position + of the capture stream is checked from both LPIB and POSBUF + values. position_fix=4 is a combination mode, using LPIB + for playback and POSBUF for capture. + NB: If you get many "azx_get_response timeout" messages at loading, it's likely a problem of interrupts (e.g. ACPI irq routing). Try to boot with options like "pci=noacpi". Also, you diff --git a/Documentation/sound/alsa/HD-Audio.txt b/Documentation/sound/alsa/HD-Audio.txt index 91fee3b..7813c06 100644 --- a/Documentation/sound/alsa/HD-Audio.txt +++ b/Documentation/sound/alsa/HD-Audio.txt @@ -59,7 +59,12 @@ a case, you can change the default method via `position_fix` option. `position_fix=1` means to use LPIB method explicitly. `position_fix=2` means to use the position-buffer. `position_fix=3` means to use a combination of both methods, needed -for some VIA and ATI controllers. 0 is the default value for all other +for some VIA controllers. The capture stream position is corrected +by comparing both LPIB and position-buffer values. +`position_fix=4` is another combination available for all controllers, +and uses LPIB for the playback and the position-buffer for the capture +streams. +0 is the default value for all other controllers, the automatic check and fallback to LPIB as described in the above. If you get a problem of repeated sounds, this option might help. -- cgit v1.1 From 6334018f70ca61bcf86194bf5c04d1ac6bd6ec1b Mon Sep 17 00:00:00 2001 From: Leon Romanovsky Date: Mon, 27 Feb 2012 21:18:19 +0200 Subject: ASoC: DT: Update digital microphone binding documentation to PAZ00 board. This patch updates device tree binding documentation to add digital microphone to PAZ00 board. Signed-off-by: Leon Romanovsky Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt b/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt index 65b001e..b77a97c 100644 --- a/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt +++ b/Documentation/devicetree/bindings/sound/tegra-audio-alc5632.txt @@ -25,12 +25,14 @@ Required properties: * MIC2_P * MIC2_N * MICBIAS1 + * DMICDAT Board connectors: * Headset Stereophone * Int Spk * Headset Mic + * Digital Mic - nvidia,i2s-controller : The phandle of the Tegra I2S controller - nvidia,audio-codec : The phandle of the ALC5632 audio codec -- cgit v1.1 From 96824f4bc1a20c0dad844196f8d90fa8ceb7ea45 Mon Sep 17 00:00:00 2001 From: Michael Opdenacker Date: Wed, 15 Feb 2012 07:11:56 +0100 Subject: Documentation: broken URL in filesystems.tmpl Fix broken link in Documentation/filesystem, replacing ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/journal-design.ps.gz by a URL on http://kernel.org Thanks to Randy Dunlap for his advise on the best replacement URL to use. Signed-off-by: Michael Opdenacker Signed-off-by: Jiri Kosina --- Documentation/DocBook/filesystems.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/filesystems.tmpl b/Documentation/DocBook/filesystems.tmpl index f51f285..3fca32c 100644 --- a/Documentation/DocBook/filesystems.tmpl +++ b/Documentation/DocBook/filesystems.tmpl @@ -387,7 +387,7 @@ an example. See also - + Journaling the Linux ext2fs Filesystem, LinuxExpo 98, Stephen Tweedie -- cgit v1.1 From 4ff162f0795ae962d90f7b0931db03221fa0ac18 Mon Sep 17 00:00:00 2001 From: Michael Opdenacker Date: Wed, 15 Feb 2012 07:14:39 +0100 Subject: Documentation: broken URL in libata.tmpl The text for version 1.1 of the Open Sofware license doesn't seem to be available anywhere on http://www.opensource.org/ any more. Replace it with an URL on fedora.org. Thanks to Randy Dunlap for his advise choosing the most appropriate replacement URL. Signed-off-by: Michael Opdenacker Signed-off-by: Jiri Kosina --- Documentation/DocBook/libata.tmpl | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index cdd1bb9..880c956 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -22,8 +22,8 @@ The contents of this file are subject to the Open Software License version 1.1 that can be found at - http://www.opensource.org/licenses/osl-1.1.txt and is included herein - by reference. + http://fedoraproject.org/wiki/Licensing:OSL1.1 + and is included herein by reference. -- cgit v1.1 From 36519c9eee16bd497e72837658dcee9cbec20b98 Mon Sep 17 00:00:00 2001 From: Geunsik Lim Date: Sat, 25 Feb 2012 11:12:23 +0900 Subject: Doc: Update numastat.txt The existing numactl website is no longer working. Change website information of numactl/libnuma utility. And, Rearrange tab space for readability. Signed-off-by: Geunsik Lim Signed-off-by: Jiri Kosina --- Documentation/numastat.txt | 27 ++++++++++++++++----------- 1 file changed, 16 insertions(+), 11 deletions(-) (limited to 'Documentation') diff --git a/Documentation/numastat.txt b/Documentation/numastat.txt index 9fcc9a6..5203277 100644 --- a/Documentation/numastat.txt +++ b/Documentation/numastat.txt @@ -5,18 +5,23 @@ Numa policy hit/miss statistics All units are pages. Hugepages have separate counters. -numa_hit A process wanted to allocate memory from this node, - and succeeded. -numa_miss A process wanted to allocate memory from another node, - but ended up with memory from this node. -numa_foreign A process wanted to allocate on this node, - but ended up with memory from another one. -local_node A process ran on this node and got memory from it. -other_node A process ran on this node and got memory from another node. -interleave_hit Interleaving wanted to allocate from this node - and succeeded. +numa_hit A process wanted to allocate memory from this node, + and succeeded. + +numa_miss A process wanted to allocate memory from another node, + but ended up with memory from this node. + +numa_foreign A process wanted to allocate on this node, + but ended up with memory from another one. + +local_node A process ran on this node and got memory from it. + +other_node A process ran on this node and got memory from another node. + +interleave_hit Interleaving wanted to allocate from this node + and succeeded. For easier reading you can use the numastat utility from the numactl package -(ftp://ftp.suse.com/pub/people/ak/numa/numactl*). Note that it only works +(http://oss.sgi.com/projects/libnuma/). Note that it only works well right now on machines with a small number of CPUs. -- cgit v1.1 From 29fa0eedd4703b0c7c93738faf28ac9d6f930224 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Fri, 20 Jan 2012 15:38:50 -0300 Subject: [media] V4L: Add JPEG compression control class documentation Add DocBook entries for the JPEG control class. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/biblio.xml | 20 +++ Documentation/DocBook/media/v4l/compat.xml | 10 ++ Documentation/DocBook/media/v4l/controls.xml | 161 +++++++++++++++++++++ Documentation/DocBook/media/v4l/v4l2.xml | 9 ++ .../DocBook/media/v4l/vidioc-g-jpegcomp.xml | 16 +- 5 files changed, 214 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/biblio.xml b/Documentation/DocBook/media/v4l/biblio.xml index cea6fd3..7dc65c5 100644 --- a/Documentation/DocBook/media/v4l/biblio.xml +++ b/Documentation/DocBook/media/v4l/biblio.xml @@ -128,6 +128,26 @@ url="http://www.ijg.org">http://www.ijg.org) Version 1.02 + + ITU-T.81 + + International Telecommunication Union +(http://www.itu.int) + + ITU-T Recommendation T.81 +"Information Technology — Digital Compression and Coding of Continous-Tone +Still Images — Requirements and Guidelines" + + + + W3C JPEG JFIF + + The World Wide Web Consortium (http://www.w3.org) + + JPEG JFIF + + SMPTE 12M diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index c93298f..dd958b5 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -2400,6 +2400,16 @@ details. +
+ V4L2 in Linux 3.4 + + + Added JPEG compression control + class. + + +
+
Relation of V4L2 to other Linux multimedia APIs diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 3f3d2e2..b84f25e 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3436,6 +3436,167 @@ interface and may change in the future. +
+ +
+ JPEG Control Reference + The JPEG class includes controls for common features of JPEG + encoders and decoders. Currently it includes features for codecs + implementing progressive baseline DCT compression process with + Huffman entrophy coding. + + JPEG Control IDs + + + + + + + + + + + ID + Type + Description + + + + + + V4L2_CID_JPEG_CLASS  + class + The JPEG class descriptor. Calling + &VIDIOC-QUERYCTRL; for this control will return a description of this + control class. + + + + + V4L2_CID_JPEG_CHROMA_SUBSAMPLING + menu + + + The chroma subsampling factors describe how + each component of an input image is sampled, in respect to maximum + sample rate in each spatial dimension. See , + clause A.1.1. for more details. The + V4L2_CID_JPEG_CHROMA_SUBSAMPLING control determines how + Cb and Cr components are downsampled after coverting an input image + from RGB to Y'CbCr color space. + + + + + + + V4L2_JPEG_CHROMA_SUBSAMPLING_444 + No chroma subsampling, each pixel has + Y, Cr and Cb values. + + + V4L2_JPEG_CHROMA_SUBSAMPLING_422 + Horizontally subsample Cr, Cb components + by a factor of 2. + + + V4L2_JPEG_CHROMA_SUBSAMPLING_420 + Subsample Cr, Cb components horizontally + and vertically by 2. + + + V4L2_JPEG_CHROMA_SUBSAMPLING_411 + Horizontally subsample Cr, Cb components + by a factor of 4. + + + V4L2_JPEG_CHROMA_SUBSAMPLING_410 + Subsample Cr, Cb components horizontally + by 4 and vertically by 2. + + + V4L2_JPEG_CHROMA_SUBSAMPLING_GRAY + Use only luminance component. + + + + + + V4L2_CID_JPEG_RESTART_INTERVAL + integer + + + The restart interval determines an interval of inserting RSTm + markers (m = 0..7). The purpose of these markers is to additionally + reinitialize the encoder process, in order to process blocks of + an image independently. + For the lossy compression processes the restart interval unit is + MCU (Minimum Coded Unit) and its value is contained in DRI + (Define Restart Interval) marker. If + V4L2_CID_JPEG_RESTART_INTERVAL control is set to 0, + DRI and RSTm markers will not be inserted. + + + + V4L2_CID_JPEG_COMPRESION_QUALITY + integer + + + + V4L2_CID_JPEG_COMPRESION_QUALITY control + determines trade-off between image quality and size. + It provides simpler method for applications to control image quality, + without a need for direct reconfiguration of luminance and chrominance + quantization tables. + + In cases where a driver uses quantization tables configured directly + by an application, using interfaces defined elsewhere, + V4L2_CID_JPEG_COMPRESION_QUALITY control should be set + by driver to 0. + The value range of this control is driver-specific. Only + positive, non-zero values are meaningful. The recommended range + is 1 - 100, where larger values correspond to better image quality. + + + + + V4L2_CID_JPEG_ACTIVE_MARKER + bitmask + + + Specify which JPEG markers are included + in compressed stream. This control is valid only for encoders. + + + + + + + V4L2_JPEG_ACTIVE_MARKER_APP0 + Application data segment APP0. + + V4L2_JPEG_ACTIVE_MARKER_APP1 + Application data segment APP1. + + V4L2_JPEG_ACTIVE_MARKER_COM + Comment segment. + + V4L2_JPEG_ACTIVE_MARKER_DQT + Quantization tables segment. + + V4L2_JPEG_ACTIVE_MARKER_DHT + Huffman tables segment. + + + + + + + +
+ For more details about JPEG specification, refer + to , , + .
diff --git a/Documentation/DocBook/media/v4l/v4l2.xml b/Documentation/DocBook/media/v4l/v4l2.xml index dcf9e33..8ae3887 100644 --- a/Documentation/DocBook/media/v4l/v4l2.xml +++ b/Documentation/DocBook/media/v4l/v4l2.xml @@ -128,6 +128,15 @@ structs, ioctls) must be noted in more detail in the history chapter applications. --> + 3.4 + 2012-01-25 + sn + Added JPEG compression + control class. + + + + 3.3 2012-01-11 hv diff --git a/Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml b/Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml index 01ea24b..4874849 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-jpegcomp.xml @@ -57,6 +57,11 @@ Description + These ioctls are deprecated. + New drivers and applications should use + JPEG class controls for image quality and JPEG markers control. + + [to do] Ronald Bultje elaborates: @@ -86,7 +91,10 @@ to add them. int quality - + Deprecated. If + V4L2_CID_JPEG_IMAGE_QUALITY control is exposed by + a driver applications should use it instead and ignore this field. + int @@ -116,7 +124,11 @@ to add them. __u32 jpeg_markers - See . + See . Deprecated. + If + V4L2_CID_JPEG_ACTIVE_MARKER control + is exposed by a driver applications should use it instead + and ignore this field. -- cgit v1.1 From 806d314325812fb8ffe7059bd84a23d334350c21 Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Thu, 23 Feb 2012 17:04:39 -0700 Subject: pinctrl: re-order struct pinctrl_map The lookup key in struct pinctrl_map is (.dev_name, .name). Re-order the struct definition to put the lookup key fields first, and the result values afterwards. To me at least, this slightly better reflects the lookup process. Update the documentation in a similar fashion. Note: PIN_MAP*() macros aren't updated; I plan to update this once later when enhancing the mapping table format to support pin config to reduce churn. Signed-off-by: Stephen Warren Acked-by: Dong Aisheng [Rebased for cherry-picking] Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index fa9163a..5e314ce 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -781,19 +781,19 @@ spi on the second function mapping: static const struct pinctrl_map __initdata mapping[] = { { + .dev_name = "foo-spi.0", .ctrl_dev_name = "pinctrl-foo", .function = "spi0", - .dev_name = "foo-spi.0", }, { + .dev_name = "foo-i2c.0", .ctrl_dev_name = "pinctrl-foo", .function = "i2c0", - .dev_name = "foo-i2c.0", }, { + .dev_name = "foo-mmc.0", .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", - .dev_name = "foo-mmc.0", }, }; @@ -826,18 +826,18 @@ As it is possible to map a function to different groups of pins an optional ... { + .dev_name = "foo-spi.0", .name = "spi0-pos-A", .ctrl_dev_name = "pinctrl-foo", .function = "spi0", .group = "spi0_0_grp", - .dev_name = "foo-spi.0", }, { + .dev_name = "foo-spi.0", .name = "spi0-pos-B", .ctrl_dev_name = "pinctrl-foo", .function = "spi0", .group = "spi0_1_grp", - .dev_name = "foo-spi.0", }, ... @@ -852,45 +852,45 @@ case), we define a mapping like this: ... { + .dev_name = "foo-mmc.0", .name = "2bit" .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", .group = "mmc0_1_grp", - .dev_name = "foo-mmc.0", }, { + .dev_name = "foo-mmc.0", .name = "4bit" .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", .group = "mmc0_1_grp", - .dev_name = "foo-mmc.0", }, { + .dev_name = "foo-mmc.0", .name = "4bit" .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", .group = "mmc0_2_grp", - .dev_name = "foo-mmc.0", }, { + .dev_name = "foo-mmc.0", .name = "8bit" .ctrl_dev_name = "pinctrl-foo", .group = "mmc0_1_grp", - .dev_name = "foo-mmc.0", }, { + .dev_name = "foo-mmc.0", .name = "8bit" .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", .group = "mmc0_2_grp", - .dev_name = "foo-mmc.0", }, { + .dev_name = "foo-mmc.0", .name = "8bit" .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", .group = "mmc0_3_grp", - .dev_name = "foo-mmc.0", }, ... @@ -988,10 +988,10 @@ This is enabled by simply setting the .dev_name field in the map to the name of the pin controller itself, like this: { + .dev_name = "pinctrl-foo", .name = "POWERMAP" .ctrl_dev_name = "pinctrl-foo", .function = "power_func", - .dev_name = "pinctrl-foo", }, Since it may be common to request the core to hog a few always-applicable -- cgit v1.1 From 1b741bc3db4ffd43abdfdaa74445338480366c55 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Mon, 30 Jan 2012 11:38:21 -0300 Subject: [media] s5p-fimc: Add driver documentation Add short documentation providing the driver usage details. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/fimc.txt | 178 +++++++++++++++++++++++++++++++++++++ 1 file changed, 178 insertions(+) create mode 100644 Documentation/video4linux/fimc.txt (limited to 'Documentation') diff --git a/Documentation/video4linux/fimc.txt b/Documentation/video4linux/fimc.txt new file mode 100644 index 0000000..eb04970 --- /dev/null +++ b/Documentation/video4linux/fimc.txt @@ -0,0 +1,178 @@ +Samsung S5P/EXYNOS4 FIMC driver + +Copyright (C) 2012 Samsung Electronics Co., Ltd. +--------------------------------------------------------------------------- + +The FIMC (Fully Interactive Mobile Camera) device available in Samsung +SoC Application Processors is an integrated camera host interface, color +space converter, image resizer and rotator. It's also capable of capturing +data from LCD controller (FIMD) through the SoC internal writeback data +path. There are multiple FIMC instances in the SoCs (up to 4), having +slightly different capabilities, like pixel alignment constraints, rotator +availability, LCD writeback support, etc. The driver is located at +drivers/media/video/s5p-fimc directory. + +1. Supported SoCs +================= + +S5PC100 (mem-to-mem only), S5PV210, EXYNOS4210 + +2. Supported features +===================== + + - camera parallel interface capture (ITU-R.BT601/565); + - camera serial interface capture (MIPI-CSI2); + - memory-to-memory processing (color space conversion, scaling, mirror + and rotation); + - dynamic pipeline re-configuration at runtime (re-attachment of any FIMC + instance to any parallel video input or any MIPI-CSI front-end); + - runtime PM and system wide suspend/resume + +Not currently supported: + - LCD writeback input + - per frame clock gating (mem-to-mem) + +3. Files partitioning +===================== + +- media device driver + drivers/media/video/s5p-fimc/fimc-mdevice.[ch] + + - camera capture video device driver + drivers/media/video/s5p-fimc/fimc-capture.c + + - MIPI-CSI2 receiver subdev + drivers/media/video/s5p-fimc/mipi-csis.[ch] + + - video post-processor (mem-to-mem) + drivers/media/video/s5p-fimc/fimc-core.c + + - common files + drivers/media/video/s5p-fimc/fimc-core.h + drivers/media/video/s5p-fimc/fimc-reg.h + drivers/media/video/s5p-fimc/regs-fimc.h + +4. User space interfaces +======================== + +4.1. Media device interface + +The driver supports Media Controller API as defined at +http://http://linuxtv.org/downloads/v4l-dvb-apis/media_common.html +The media device driver name is "SAMSUNG S5P FIMC". + +The purpose of this interface is to allow changing assignment of FIMC instances +to the SoC peripheral camera input at runtime and optionally to control internal +connections of the MIPI-CSIS device(s) to the FIMC entities. + +The media device interface allows to configure the SoC for capturing image +data from the sensor through more than one FIMC instance (e.g. for simultaneous +viewfinder and still capture setup). +Reconfiguration is done by enabling/disabling media links created by the driver +during initialization. The internal device topology can be easily discovered +through media entity and links enumeration. + +4.2. Memory-to-memory video node + +V4L2 memory-to-memory interface at /dev/video? device node. This is standalone +video device, it has no media pads. However please note the mem-to-mem and +capture video node operation on same FIMC instance is not allowed. The driver +detects such cases but the applications should prevent them to avoid an +undefined behaviour. + +4.3. Capture video node + +The driver supports V4L2 Video Capture Interface as defined at: +http://linuxtv.org/downloads/v4l-dvb-apis/devices.html + +At the capture and mem-to-mem video nodes only the multi-planar API is +supported. For more details see: +http://linuxtv.org/downloads/v4l-dvb-apis/planar-apis.html + +4.4. Camera capture subdevs + +Each FIMC instance exports a sub-device node (/dev/v4l-subdev?), a sub-device +node is also created per each available and enabled at the platform level +MIPI-CSI receiver device (currently up to two). + +4.5. sysfs + +In order to enable more precise camera pipeline control through the sub-device +API the driver creates a sysfs entry associated with "s5p-fimc-md" platform +device. The entry path is: /sys/platform/devices/s5p-fimc-md/subdev_conf_mode. + +In typical use case there could be a following capture pipeline configuration: +sensor subdev -> mipi-csi subdev -> fimc subdev -> video node + +When we configure these devices through sub-device API at user space, the +configuration flow must be from left to right, and the video node is +configured as last one. +When we don't use sub-device user space API the whole configuration of all +devices belonging to the pipeline is done at the video node driver. +The sysfs entry allows to instruct the capture node driver not to configure +the sub-devices (format, crop), to avoid resetting the subdevs' configuration +when the last configuration steps at the video node is performed. + +For full sub-device control support (subdevs configured at user space before +starting streaming): +# echo "sub-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode + +For V4L2 video node control only (subdevs configured internally by the host +driver): +# echo "vid-dev" > /sys/platform/devices/s5p-fimc-md/subdev_conf_mode +This is a default option. + +5. Device mapping to video and subdev device nodes +================================================== + +There are associated two video device nodes with each device instance in +hardware - video capture and mem-to-mem and additionally a subdev node for +more precise FIMC capture subsystem control. In addition a separate v4l2 +sub-device node is created per each MIPI-CSIS device. + +How to find out which /dev/video? or /dev/v4l-subdev? is assigned to which +device? + +You can either grep through the kernel log to find relevant information, i.e. +# dmesg | grep -i fimc +(note that udev, if present, might still have rearranged the video nodes), + +or retrieve the information from /dev/media? with help of the media-ctl tool: +# media-ctl -p + +6. Platform support +=================== + +The machine code (plat-s5p and arch/arm/mach-*) must select following options + +CONFIG_S5P_DEV_FIMC0 mandatory +CONFIG_S5P_DEV_FIMC1 \ +CONFIG_S5P_DEV_FIMC2 | optional +CONFIG_S5P_DEV_FIMC3 | +CONFIG_S5P_SETUP_FIMC / +CONFIG_S5P_SETUP_MIPIPHY \ +CONFIG_S5P_DEV_CSIS0 | optional for MIPI-CSI interface +CONFIG_S5P_DEV_CSIS1 / + +Except that, relevant s5p_device_fimc? should be registered in the machine code +in addition to a "s5p-fimc-md" platform device to which the media device driver +is bound. The "s5p-fimc-md" device instance is required even if only mem-to-mem +operation is used. + +The description of sensor(s) attached to FIMC/MIPI-CSIS camera inputs should be +passed as the "s5p-fimc-md" device platform_data. The platform data structure +is defined in file include/media/s5p_fimc.h. + +7. Build +======== + +This driver depends on following config options: +PLAT_S5P, +PM_RUNTIME, +I2C, +REGULATOR, +VIDEO_V4L2_SUBDEV_API, + +If the driver is built as a loadable kernel module (CONFIG_VIDEO_SAMSUNG_S5P_FIMC=m) +two modules are created (in addition to the core v4l2 modules): s5p-fimc.ko and +optional s5p-csis.ko (MIPI-CSI receiver subdev). -- cgit v1.1 From 6748dcc269e52925993e0d68447858b41b88b4be Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Thu, 1 Mar 2012 00:06:33 +0100 Subject: PCI / PCIe: Introduce command line option to disable ARI There are PCIe devices on the market that report ARI support but then fail to initialize correctly when ARI is actually used. This leads to situations in which kernels 2.6.34 and newer fail to handle systems where the previous kernels worked without any apparent problems. Unfortunately, it is currently unknown how many such devices are there. For this reason, introduce a new kernel command line option, pci=noari, allowing users to disable PCIe ARI altogether if they see problems with PCIe device initialization. Signed-off-by: Rafael J. Wysocki Signed-off-by: Jesse Barnes --- Documentation/kernel-parameters.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 7dc523e..3d153e5 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2116,6 +2116,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted. off: Turn realloc off on: Turn realloc on realloc same as realloc=on + noari do not use PCIe ARI. pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power Management. -- cgit v1.1 From db8ac8ba871ae7b97118cfb2913b4986867f09a7 Mon Sep 17 00:00:00 2001 From: Weston Andros Adamson Date: Fri, 17 Feb 2012 15:20:24 -0500 Subject: NFSv4: Send implementation id with exchange_id Send the nfs implementation id in EXCHANGE_ID requests unless the module parameter nfs.send_implementation_id is 0. This adds a CONFIG variable for the nii_domain that defaults to "kernel.org". Signed-off-by: Weston Andros Adamson Signed-off-by: Trond Myklebust --- Documentation/kernel-parameters.txt | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 1d369c6..7bae0fd 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1678,6 +1678,15 @@ bytes respectively. Such letter suffixes can also be entirely omitted. back to using the idmapper. To turn off this behaviour, set the value to '0'. + nfs.send_implementation_id = + [NFSv4.1] Send client implementation identification + information in exchange_id requests. + If zero, no implementation identification information + will be sent. + The default is to send the implementation identification + information. + + nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take when a NMI is triggered. Format: [state][,regs][,debounce][,die] -- cgit v1.1 From 46919ae63d4820e76724beb655274ce143f0da0b Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Thu, 1 Mar 2012 18:48:32 -0700 Subject: pinctrl: introduce PINCTRL_STATE_DEFAULT, define hogs as that state This provides a single centralized name for the default state. Update PIN_MAP_* macros to use this state name, instead of requiring the user to pass a state name in. With this change, hog entries in the mapping table are defined as those with state name PINCTRL_STATE_DEFAULT, i.e. all entries have the same name. This interacts badly with the nested iteration over mapping table entries in pinctrl_hog_maps() and pinctrl_hog_map() which would now attempt to claim each hog mapping table entry multiple times. Replacing the custom hog code with a simple pinctrl_get()/pinctrl_enable(). Update documentation and mapping tables to use this. Signed-off-by: Stephen Warren Acked-by: Dong Aisheng Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 5e314ce..6fe3232 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -814,7 +814,7 @@ it even more compact which assumes you want to use pinctrl-foo and position 0 for mapping, for example: static struct pinctrl_map __initdata mapping[] = { - PIN_MAP("I2CMAP", "pinctrl-foo", "i2c0", "foo-i2c.0"), + PIN_MAP(PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", "foo-i2c.0"), }; @@ -930,7 +930,7 @@ foo_probe() /* Allocate a state holder named "state" etc */ struct pinctrl p; - p = pinctrl_get(&device, NULL); + p = pinctrl_get(&device, PINCTRL_STATE_DEFAULT); if IS_ERR(p) return PTR_ERR(p); pinctrl_enable(p); @@ -989,7 +989,7 @@ of the pin controller itself, like this: { .dev_name = "pinctrl-foo", - .name = "POWERMAP" + .name = PINCTRL_STATE_DEFAULT, .ctrl_dev_name = "pinctrl-foo", .function = "power_func", }, @@ -998,7 +998,7 @@ Since it may be common to request the core to hog a few always-applicable mux settings on the primary pin controller, there is a convenience macro for this: -PIN_MAP_PRIMARY_SYS_HOG("POWERMAP", "pinctrl-foo", "power_func") +PIN_MAP_SYS_HOG("pinctrl-foo", "power_func") This gives the exact same result as the above construction. -- cgit v1.1 From 110e4ec5a1cfe20190e7f8c2b8b4eef369de3c99 Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Thu, 1 Mar 2012 18:48:33 -0700 Subject: pinctrl: assume map table entries can't have a NULL name field pinctrl_register_mappings() already requires that every mapping table entry have a non-NULL name field. Logically, this makes sense too; drivers should always request a specific named state so they know what they're getting. Relying on getting the first mentioned state in the mapping table is error-prone, and a nasty special case to implement, given that a given the mapping table may define multiple states for a device. Remove a small part of the documentation that talked about optionally requesting a specific state; it's mandatory now. Signed-off-by: Stephen Warren Acked-by: Dong Aisheng Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 6fe3232..558aac5 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -782,16 +782,19 @@ spi on the second function mapping: static const struct pinctrl_map __initdata mapping[] = { { .dev_name = "foo-spi.0", + .name = PINCTRL_STATE_DEFAULT, .ctrl_dev_name = "pinctrl-foo", .function = "spi0", }, { .dev_name = "foo-i2c.0", + .name = PINCTRL_STATE_DEFAULT, .ctrl_dev_name = "pinctrl-foo", .function = "i2c0", }, { .dev_name = "foo-mmc.0", + .name = PINCTRL_STATE_DEFAULT, .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", }, @@ -944,10 +947,6 @@ foo_remove() pinctrl_put(state->p); } -If you want to grab a specific control mapping and not just the first one -found for this device you can specify a specific mapping name, for example in -the above example the second i2c0 setting: pinctrl_get(&device, "spi0-pos-B"); - This get/enable/disable/put sequence can just as well be handled by bus drivers if you don't want each and every driver to handle it and you know the arrangement on your bus. -- cgit v1.1 From 4bdd47997f110ee06ed8a1c6668d12106936ba12 Mon Sep 17 00:00:00 2001 From: Shawn Guo Date: Sat, 3 Mar 2012 23:20:00 +0800 Subject: ASoC: sgtl5000: rename device tree binding document It moves and renames sgtl5000 device tree binding document to make it aligned with other codecs. Signed-off-by: Shawn Guo Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/sgtl5000.txt | 11 +++++++++++ .../devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt | 11 ----------- 2 files changed, 11 insertions(+), 11 deletions(-) create mode 100644 Documentation/devicetree/bindings/sound/sgtl5000.txt delete mode 100644 Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.txt b/Documentation/devicetree/bindings/sound/sgtl5000.txt new file mode 100644 index 0000000..2c3cd41 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/sgtl5000.txt @@ -0,0 +1,11 @@ +* Freescale SGTL5000 Stereo Codec + +Required properties: +- compatible : "fsl,sgtl5000". + +Example: + +codec: sgtl5000@0a { + compatible = "fsl,sgtl5000"; + reg = <0x0a>; +}; diff --git a/Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt b/Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt deleted file mode 100644 index 2c3cd41..0000000 --- a/Documentation/devicetree/bindings/sound/soc/codecs/fsl-sgtl5000.txt +++ /dev/null @@ -1,11 +0,0 @@ -* Freescale SGTL5000 Stereo Codec - -Required properties: -- compatible : "fsl,sgtl5000". - -Example: - -codec: sgtl5000@0a { - compatible = "fsl,sgtl5000"; - reg = <0x0a>; -}; -- cgit v1.1 From bf7daebb9fba540cb8864f435f153678b3e5c171 Mon Sep 17 00:00:00 2001 From: Paul Mackerras Date: Sun, 4 Mar 2012 12:56:04 +0000 Subject: ppp: Move ioctl definitions from if_ppp.h to new ppp-ioctl.h This moves the definitions of the ioctls, constants and structures relating to the ppp_generic interface to userspace out from if_ppp.h to a new file, ppp-ioctl.h. The new file has my copyright since I designed and implemented the ppp_generic interface in the late 1990s. None of the contents of this file comes from the original if_ppp.h published by Carnegie Mellon University. Of the remainder of if_ppp.h, only the PPP_MTU definition was being used, and this replaces the uses of it with PPP_MRU (which is identical). Therefore, this replaces the entire file with the single line #include which clearly doesn't contain any CMU code. Thus I have removed the CMU copyright notice with its problematic advertising clause, and in fact since it's only one trivial line I have not added any other copyright notice. Signed-off-by: Paul Mackerras Signed-off-by: David S. Miller --- Documentation/ioctl/ioctl-number.txt | 2 +- Documentation/networking/ppp_generic.txt | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 4840334..85af548 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -255,7 +255,7 @@ Code Seq#(hex) Include File Comments linux/ixjuser.h 'r' 00-1F linux/msdos_fs.h and fs/fat/dir.c 's' all linux/cdk.h -'t' 00-7F linux/if_ppp.h +'t' 00-7F linux/ppp-ioctl.h 't' 80-8F linux/isdn_ppp.h 't' 90 linux/toshiba.h 'u' 00-1F linux/smb_fs.h gone diff --git a/Documentation/networking/ppp_generic.txt b/Documentation/networking/ppp_generic.txt index 15b5172..091d202 100644 --- a/Documentation/networking/ppp_generic.txt +++ b/Documentation/networking/ppp_generic.txt @@ -342,7 +342,7 @@ an interface unit are: numbers on received multilink fragments SC_MP_XSHORTSEQ transmit short multilink sequence nos. - The values of these flags are defined in . Note + The values of these flags are defined in . Note that the values of the SC_MULTILINK, SC_MP_SHORTSEQ and SC_MP_XSHORTSEQ bits are ignored if the CONFIG_PPP_MULTILINK option is not selected. @@ -358,7 +358,7 @@ an interface unit are: * PPPIOCSCOMPRESS sets the parameters for packet compression or decompression. The argument should point to a ppp_option_data - structure (defined in ), which contains a + structure (defined in ), which contains a pointer/length pair which should describe a block of memory containing a CCP option specifying a compression method and its parameters. The ppp_option_data struct also contains a `transmit' @@ -395,7 +395,7 @@ an interface unit are: * PPPIOCSNPMODE sets the network-protocol mode for a given network protocol. The argument should point to an npioctl struct (defined - in ). The `protocol' field gives the PPP protocol + in ). The `protocol' field gives the PPP protocol number for the protocol to be affected, and the `mode' field specifies what to do with packets for that protocol: -- cgit v1.1 From 4b32da2bcf1de2b7a196a0e48389d231b4472c36 Mon Sep 17 00:00:00 2001 From: Paul Mackerras Date: Sun, 4 Mar 2012 12:56:55 +0000 Subject: ppp: Replace uses of with Since all that include/linux/if_ppp.h does is #include , this replaces the occurrences of #include with #include . It also corrects an error in Documentation/networking/l2tp.txt, where it referenced include/linux/if_ppp.h as the source of some definitions that are actually now defined in include/linux/if_pppol2tp.h. Signed-off-by: Paul Mackerras Signed-off-by: David S. Miller --- Documentation/networking/l2tp.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/networking/l2tp.txt b/Documentation/networking/l2tp.txt index e7bf397..e63fc1f 100644 --- a/Documentation/networking/l2tp.txt +++ b/Documentation/networking/l2tp.txt @@ -111,7 +111,7 @@ When creating PPPoL2TP sockets, the application provides information to the driver about the socket in a socket connect() call. Source and destination tunnel and session ids are provided, as well as the file descriptor of a UDP socket. See struct pppol2tp_addr in -include/linux/if_ppp.h. Note that zero tunnel / session ids are +include/linux/if_pppol2tp.h. Note that zero tunnel / session ids are treated specially. When creating the per-tunnel PPPoL2TP management socket in Step 2 above, zero source and destination session ids are specified, which tells the driver to prepare the supplied UDP file -- cgit v1.1 From 6e5e959dde0d92d177f035652aeaa77f9330c9c6 Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Fri, 2 Mar 2012 13:05:47 -0700 Subject: pinctrl: API changes to support multiple states per device The API model is changed from: p = pinctrl_get(dev, "state1"); pinctrl_enable(p); ... pinctrl_disable(p); pinctrl_put(p); p = pinctrl_get(dev, "state2"); pinctrl_enable(p); ... pinctrl_disable(p); pinctrl_put(p); to this: p = pinctrl_get(dev); s1 = pinctrl_lookup_state(p, "state1"); s2 = pinctrl_lookup_state(p, "state2"); pinctrl_select_state(p, s1); ... pinctrl_select_state(p, s2); ... pinctrl_put(p); This allows devices to directly transition between states without disabling the pin controller programming and put()/get()ing the configuration data each time. This model will also better suit pinconf programming, which doesn't have a concept of "disable". The special-case hogging feature of pin controllers is re-written to use the regular APIs instead of special-case code. Hence, the pinmux-hogs debugfs file is removed; see the top-level pinctrl-handles files for equivalent data. Signed-off-by: Stephen Warren Acked-by: Dong Aisheng Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 120 ++++++++++++++++++++++++++++++---------------- 1 file changed, 79 insertions(+), 41 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 558aac5..23426c7 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -847,8 +847,8 @@ As it is possible to map a function to different groups of pins an optional This example mapping is used to switch between two positions for spi0 at runtime, as described further below under the heading "Runtime pinmuxing". -Further it is possible to match several groups of pins to the same function -for a single device, say for example in the mmc0 example above, where you can +Further it is possible for one named state to affect the muxing of several +groups of pins, say for example in the mmc0 example above, where you can additively expand the mmc0 bus from 2 to 4 to 8 pins. If we want to use all three groups for a total of 2+2+4 = 8 pins (for an 8-bit MMC bus as is the case), we define a mapping like this: @@ -879,6 +879,7 @@ case), we define a mapping like this: .dev_name = "foo-mmc.0", .name = "8bit" .ctrl_dev_name = "pinctrl-foo", + .function = "mmc0", .group = "mmc0_1_grp", }, { @@ -900,10 +901,16 @@ case), we define a mapping like this: The result of grabbing this mapping from the device with something like this (see next paragraph): - p = pinctrl_get(&device, "8bit"); + p = pinctrl_get(dev); + s = pinctrl_lookup_state(p, "8bit"); + ret = pinctrl_select_state(p, s); + +or more simply: + + p = pinctrl_get_select(dev, "8bit"); Will be that you activate all the three bottom records in the mapping at -once. Since they share the same name, pin controller device, funcion and +once. Since they share the same name, pin controller device, function and device, and since we allow multiple groups to match to a single device, they all get selected, and they all get enabled and disable simultaneously by the pinmux core. @@ -925,45 +932,63 @@ default state like this: struct foo_state { struct pinctrl *p; + struct pinctrl_state *s; ... }; foo_probe() { - /* Allocate a state holder named "state" etc */ - struct pinctrl p; + /* Allocate a state holder named "foo" etc */ + struct foo_state *foo = ...; + + foo->p = pinctrl_get(&device); + if (IS_ERR(foo->p)) { + /* FIXME: clean up "foo" here */ + return PTR_ERR(foo->p); + } - p = pinctrl_get(&device, PINCTRL_STATE_DEFAULT); - if IS_ERR(p) - return PTR_ERR(p); - pinctrl_enable(p); + foo->s = pinctrl_lookup_state(foo->p, PINCTRL_STATE_DEFAULT); + if (IS_ERR(foo->s)) { + pinctrl_put(foo->p); + /* FIXME: clean up "foo" here */ + return PTR_ERR(s); + } - state->p = p; + ret = pinctrl_select_state(foo->s); + if (ret < 0) { + pinctrl_put(foo->p); + /* FIXME: clean up "foo" here */ + return ret; + } } foo_remove() { - pinctrl_disable(state->p); pinctrl_put(state->p); } -This get/enable/disable/put sequence can just as well be handled by bus drivers +This get/lookup/select/put sequence can just as well be handled by bus drivers if you don't want each and every driver to handle it and you know the arrangement on your bus. -The semantics of the get/enable respective disable/put is as follows: +The semantics of the pinctrl APIs are: + +- pinctrl_get() is called in process context to obtain a handle to all pinctrl + information for a given client device. It will allocate a struct from the + kernel memory to hold the pinmux state. All mapping table parsing or similar + slow operations take place within this API. -- pinctrl_get() is called in process context to reserve the pins affected with - a certain mapping and set up the pinmux core and the driver. It will allocate - a struct from the kernel memory to hold the pinmux state. +- pinctrl_lookup_state() is called in process context to obtain a handle to a + specific state for a the client device. This operation may be slow too. -- pinctrl_enable()/pinctrl_disable() is quick and can be called from fastpath - (irq context) when you quickly want to set up/tear down the hardware muxing - when running a device driver. Usually it will just poke some values into a - register. +- pinctrl_select_state() programs pin controller hardware according to the + definition of the state as given by the mapping table. In theory this is a + fast-path operation, since it only involved blasting some register settings + into hardware. However, note that some pin controllers may have their + registers on a slow/IRQ-based bus, so client devices should not assume they + can call pinctrl_select_state() from non-blocking contexts. -- pinctrl_disable() is called in process context to tear down the pin requests - and release the state holder struct for the mux setting etc. +- pinctrl_put() frees all information associated with a pinctrl handle. Usually the pin control core handled the get/put pair and call out to the device drivers bookkeeping operations, like checking available functions and @@ -979,12 +1004,12 @@ System pin control hogging ========================== Pin control map entries can be hogged by the core when the pin controller -is registered. This means that the core will attempt to call pinctrl_get() and -pinctrl_enable() on it immediately after the pin control device has been -registered. +is registered. This means that the core will attempt to call pinctrl_get(), +lookup_state() and select_state() on it immediately after the pin control +device has been registered. -This is enabled by simply setting the .dev_name field in the map to the name -of the pin controller itself, like this: +This occurs for mapping table entries where the client device name is equal +to the pin controller device name, and the state name is PINCTRL_STATE_DEFAULT. { .dev_name = "pinctrl-foo", @@ -1009,8 +1034,8 @@ It is possible to mux a certain function in and out at runtime, say to move an SPI port from one set of pins to another set of pins. Say for example for spi0 in the example above, we expose two different groups of pins for the same function, but with different named in the mapping as described under -"Advanced mapping" above. So we have two mappings named "spi0-pos-A" and -"spi0-pos-B". +"Advanced mapping" above. So that for an SPI device, we have two states named +"pos-A" and "pos-B". This snippet first muxes the function in the pins defined by group A, enables it, disables and releases it, and muxes it in on the pins defined by group B: @@ -1020,23 +1045,36 @@ it, disables and releases it, and muxes it in on the pins defined by group B: foo_switch() { struct pinctrl *p; + struct pinctrl_state *s1, *s2; + + /* Setup */ + p = pinctrl_get(&device); + if (IS_ERR(p)) + ... + + s1 = pinctrl_lookup_state(foo->p, "pos-A"); + if (IS_ERR(s1)) + ... + + s2 = pinctrl_lookup_state(foo->p, "pos-B"); + if (IS_ERR(s2)) + ... /* Enable on position A */ - p = pinctrl_get(&device, "spi0-pos-A"); - if IS_ERR(p) - return PTR_ERR(p); - pinctrl_enable(p); + ret = pinctrl_select_state(s1); + if (ret < 0) + ... - /* This releases the pins again */ - pinctrl_disable(p); - pinctrl_put(p); + ... /* Enable on position B */ - p = pinctrl_get(&device, "spi0-pos-B"); - if IS_ERR(p) - return PTR_ERR(p); - pinctrl_enable(p); + ret = pinctrl_select_state(s2); + if (ret < 0) + ... + ... + + pinctrl_put(p); } The above has to be done from process context. -- cgit v1.1 From 1e2082b520721734c358f776d34a069867214c8e Mon Sep 17 00:00:00 2001 From: Stephen Warren Date: Fri, 2 Mar 2012 13:05:48 -0700 Subject: pinctrl: enhance mapping table to support pin config operations The pinctrl mapping table can now contain entries to: * Set the mux function of a pin group * Apply a set of pin config options to a pin or a group This allows pinctrl_select_state() to apply pin configs settings as well as mux settings. v3: Fix find_pinctrl() to iterate over the correct list. s/_MUX_CONFIGS_/_CONFIGS_/ in mapping table macros. Fix documentation to use correct mapping table macro. v2: Added numerous extra PIN_MAP_*() special-case macros. Fixed kerneldoc typo. Delete pinctrl_get_pin_id() and replace it with pin_get_from_name(). Various minor fixes. Updates due to rebase. Signed-off-by: Stephen Warren Acked-by: Dong Aisheng Signed-off-by: Linus Walleij --- Documentation/pinctrl.txt | 76 +++++++++++++++++++++++++++++++++++++++-------- 1 file changed, 64 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/pinctrl.txt b/Documentation/pinctrl.txt index 23426c7..d97bccf 100644 --- a/Documentation/pinctrl.txt +++ b/Documentation/pinctrl.txt @@ -206,14 +206,21 @@ using a certain resistor value - pull up and pull down - so that the pin has a stable value when nothing is driving the rail it is connected to, or when it's unconnected. -For example, a platform may do this: +Pin configuration can be programmed either using the explicit APIs described +immediately below, or by adding configuration entries into the mapping table; +see section "Board/machine configuration" below. + +For example, a platform may do the following to pull up a pin to VDD: #include ret = pin_config_set("foo-dev", "FOO_GPIO_PIN", PLATFORM_X_PULL_UP); -To pull up a pin to VDD. The pin configuration driver implements callbacks for -changing pin configuration in the pin controller ops like this: +The format and meaning of the configuration parameter, PLATFORM_X_PULL_UP +above, is entirely defined by the pin controller driver. + +The pin configuration driver implements callbacks for changing pin +configuration in the pin controller ops like this: #include #include @@ -765,7 +772,7 @@ obtain the function "gpioN" where "N" is the global GPIO pin number if no special GPIO-handler is registered. -Pinmux board/machine configuration +Board/machine configuration ================================== Boards and machines define how a certain complete running system is put @@ -773,9 +780,9 @@ together, including how GPIOs and devices are muxed, how regulators are constrained and how the clock tree looks. Of course pinmux settings are also part of this. -A pinmux config for a machine looks pretty much like a simple regulator -configuration, so for the example array above we want to enable i2c and -spi on the second function mapping: +A pin controller configuration for a machine looks pretty much like a simple +regulator configuration, so for the example array above we want to enable i2c +and spi on the second function mapping: #include @@ -783,20 +790,23 @@ static const struct pinctrl_map __initdata mapping[] = { { .dev_name = "foo-spi.0", .name = PINCTRL_STATE_DEFAULT, + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", - .function = "spi0", + .data.mux.function = "spi0", }, { .dev_name = "foo-i2c.0", .name = PINCTRL_STATE_DEFAULT, + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", - .function = "i2c0", + .data.mux.function = "i2c0", }, { .dev_name = "foo-mmc.0", .name = PINCTRL_STATE_DEFAULT, + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", - .function = "mmc0", + .data.mux.function = "mmc0", }, }; @@ -817,7 +827,40 @@ it even more compact which assumes you want to use pinctrl-foo and position 0 for mapping, for example: static struct pinctrl_map __initdata mapping[] = { - PIN_MAP(PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", "foo-i2c.0"), + PIN_MAP_MUX_GROUP("foo-i2c.o", PINCTRL_STATE_DEFAULT, "pinctrl-foo", NULL, "i2c0"), +}; + +The mapping table may also contain pin configuration entries. It's common for +each pin/group to have a number of configuration entries that affect it, so +the table entries for configuration reference an array of config parameters +and values. An example using the convenience macros is shown below: + +static unsigned long i2c_grp_configs[] = { + FOO_PIN_DRIVEN, + FOO_PIN_PULLUP, +}; + +static unsigned long i2c_pin_configs[] = { + FOO_OPEN_COLLECTOR, + FOO_SLEW_RATE_SLOW, +}; + +static struct pinctrl_map __initdata mapping[] = { + PIN_MAP_MUX_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", "i2c0"), + PIN_MAP_MUX_CONFIGS_GROUP("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0", i2c_grp_configs), + PIN_MAP_MUX_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0scl", i2c_pin_configs), + PIN_MAP_MUX_CONFIGS_PIN("foo-i2c.0", PINCTRL_STATE_DEFAULT, "pinctrl-foo", "i2c0sda", i2c_pin_configs), +}; + +Finally, some devices expect the mapping table to contain certain specific +named states. When running on hardware that doesn't need any pin controller +configuration, the mapping table must still contain those named states, in +order to explicitly indicate that the states were provided and intended to +be empty. Table entry macro PIN_MAP_DUMMY_STATE serves the purpose of defining +a named state without causing any pin controller to be programmed: + +static struct pinctrl_map __initdata mapping[] = { + PIN_MAP_DUMMY_STATE("foo-i2c.0", PINCTRL_STATE_DEFAULT), }; @@ -831,6 +874,7 @@ As it is possible to map a function to different groups of pins an optional { .dev_name = "foo-spi.0", .name = "spi0-pos-A", + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", .function = "spi0", .group = "spi0_0_grp", @@ -838,6 +882,7 @@ As it is possible to map a function to different groups of pins an optional { .dev_name = "foo-spi.0", .name = "spi0-pos-B", + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", .function = "spi0", .group = "spi0_1_grp", @@ -857,6 +902,7 @@ case), we define a mapping like this: { .dev_name = "foo-mmc.0", .name = "2bit" + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", .group = "mmc0_1_grp", @@ -864,6 +910,7 @@ case), we define a mapping like this: { .dev_name = "foo-mmc.0", .name = "4bit" + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", .group = "mmc0_1_grp", @@ -871,6 +918,7 @@ case), we define a mapping like this: { .dev_name = "foo-mmc.0", .name = "4bit" + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", .group = "mmc0_2_grp", @@ -878,6 +926,7 @@ case), we define a mapping like this: { .dev_name = "foo-mmc.0", .name = "8bit" + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", .group = "mmc0_1_grp", @@ -885,6 +934,7 @@ case), we define a mapping like this: { .dev_name = "foo-mmc.0", .name = "8bit" + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", .group = "mmc0_2_grp", @@ -892,6 +942,7 @@ case), we define a mapping like this: { .dev_name = "foo-mmc.0", .name = "8bit" + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", .function = "mmc0", .group = "mmc0_3_grp", @@ -1014,6 +1065,7 @@ to the pin controller device name, and the state name is PINCTRL_STATE_DEFAULT. { .dev_name = "pinctrl-foo", .name = PINCTRL_STATE_DEFAULT, + .type = PIN_MAP_TYPE_MUX_GROUP, .ctrl_dev_name = "pinctrl-foo", .function = "power_func", }, @@ -1022,7 +1074,7 @@ Since it may be common to request the core to hog a few always-applicable mux settings on the primary pin controller, there is a convenience macro for this: -PIN_MAP_SYS_HOG("pinctrl-foo", "power_func") +PIN_MAP_MUX_GROUP_HOG_DEFAULT("pinctrl-foo", NULL /* group */, "power_func") This gives the exact same result as the above construction. -- cgit v1.1 From 9d5ef2663fe220a88412a7190942b7d933da0333 Mon Sep 17 00:00:00 2001 From: Richard Zhao Date: Mon, 5 Mar 2012 22:31:04 +0800 Subject: ASoC: fsl: add dt support for imx-audmux It adds device tree probe support for imx-audmux driver. Signed-off-by: Richard Zhao Signed-off-by: Shawn Guo Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/sound/imx-audmux.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 Documentation/devicetree/bindings/sound/imx-audmux.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/sound/imx-audmux.txt b/Documentation/devicetree/bindings/sound/imx-audmux.txt new file mode 100644 index 0000000..215aa98 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/imx-audmux.txt @@ -0,0 +1,13 @@ +Freescale Digital Audio Mux (AUDMUX) device + +Required properties: +- compatible : "fsl,imx21-audmux" for AUDMUX version firstly used on i.MX21, + or "fsl,imx31-audmux" for the version firstly used on i.MX31. +- reg : Should contain AUDMUX registers location and length + +Example: + +audmux@021d8000 { + compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux"; + reg = <0x021d8000 0x4000>; +}; -- cgit v1.1 From 40e47125e6c5110383b0176d7b9d530f2936b1ae Mon Sep 17 00:00:00 2001 From: Masanari Iida Date: Sun, 4 Mar 2012 23:16:11 +0900 Subject: Documentation: Fix multiple typo in Documentation Signed-off-by: Masanari Iida Acked-by: Randy Dunlap Signed-off-by: Jiri Kosina --- Documentation/ABI/obsolete/sysfs-class-rfkill | 2 +- Documentation/ABI/stable/sysfs-module | 2 +- Documentation/DocBook/libata.tmpl | 4 ++-- Documentation/DocBook/media/v4l/compat.xml | 4 ++-- Documentation/arm/kernel_user_helpers.txt | 2 +- Documentation/cgroups/blkio-controller.txt | 18 +++++++++--------- Documentation/device-mapper/dm-raid.txt | 2 +- Documentation/device-mapper/persistent-data.txt | 2 +- Documentation/devicetree/bindings/arm/omap/omap.txt | 2 +- Documentation/devicetree/bindings/arm/sirf.txt | 2 +- Documentation/devicetree/booting-without-of.txt | 2 +- Documentation/dmaengine.txt | 2 +- Documentation/fb/matroxfb.txt | 8 ++++---- Documentation/filesystems/ext4.txt | 4 ++-- Documentation/filesystems/gfs2-uevents.txt | 2 +- .../filesystems/pohmelfs/network_protocol.txt | 2 +- Documentation/filesystems/vfs.txt | 2 +- Documentation/hwmon/adm1275 | 2 +- Documentation/hwmon/max16064 | 4 ++-- Documentation/hwmon/max34440 | 4 ++-- Documentation/hwmon/max8688 | 4 ++-- Documentation/hwmon/ucd9000 | 6 +++--- Documentation/hwmon/ucd9200 | 10 +++++----- Documentation/hwmon/zl6100 | 4 ++-- Documentation/i2o/ioctl | 12 ++++++------ Documentation/ide/ChangeLog.ide-cd.1994-2004 | 2 +- Documentation/input/alps.txt | 4 ++-- Documentation/input/joystick.txt | 2 +- Documentation/ioctl/hdio.txt | 4 ++-- Documentation/kbuild/kconfig-language.txt | 2 +- Documentation/networking/fore200e.txt | 2 +- Documentation/scsi/ChangeLog.lpfc | 2 +- Documentation/scsi/ChangeLog.megaraid_sas | 2 +- Documentation/scsi/tmscsim.txt | 2 +- Documentation/security/Smack.txt | 2 +- Documentation/security/keys-trusted-encrypted.txt | 2 +- Documentation/security/keys.txt | 2 +- Documentation/sound/alsa/ALSA-Configuration.txt | 2 +- Documentation/video4linux/uvcvideo.txt | 2 +- Documentation/virtual/kvm/mmu.txt | 4 ++-- Documentation/virtual/virtio-spec.txt | 8 ++++---- Documentation/vm/unevictable-lru.txt | 2 +- 42 files changed, 77 insertions(+), 77 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ABI/obsolete/sysfs-class-rfkill b/Documentation/ABI/obsolete/sysfs-class-rfkill index 4201d5b..ff60ad9 100644 --- a/Documentation/ABI/obsolete/sysfs-class-rfkill +++ b/Documentation/ABI/obsolete/sysfs-class-rfkill @@ -7,7 +7,7 @@ Date: 09-Jul-2007 KernelVersion v2.6.22 Contact: linux-wireless@vger.kernel.org Description: Current state of the transmitter. - This file is deprecated and sheduled to be removed in 2014, + This file is deprecated and scheduled to be removed in 2014, because its not possible to express the 'soft and hard block' state of the rfkill driver. Values: A numeric value. diff --git a/Documentation/ABI/stable/sysfs-module b/Documentation/ABI/stable/sysfs-module index 75be431..a0dd21c 100644 --- a/Documentation/ABI/stable/sysfs-module +++ b/Documentation/ABI/stable/sysfs-module @@ -6,7 +6,7 @@ Description: The name of the module that is in the kernel. This module name will show up either if the module is built directly into the kernel, or if it is loaded as a - dyanmic module. + dynamic module. /sys/module/MODULENAME/parameters This directory contains individual files that are each diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index 880c956..31df1aa 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -945,7 +945,7 @@ and other resources, etc. - !BSY && ERR after CDB tranfer starts but before the + !BSY && ERR after CDB transfer starts but before the last byte of CDB is transferred. ATA/ATAPI standard states that "The device shall not terminate the PACKET command with an error before the last byte of the command packet has @@ -1050,7 +1050,7 @@ and other resources, etc. to complete a command. Combined with the fact that MWDMA and PIO transfer errors aren't allowed to use ICRC bit up to ATA/ATAPI-7, it seems to imply that ABRT bit alone could - indicate tranfer errors. + indicate transfer errors. However, ATA/ATAPI-8 draft revision 1f removes the part diff --git a/Documentation/DocBook/media/v4l/compat.xml b/Documentation/DocBook/media/v4l/compat.xml index c736380..a2485b3 100644 --- a/Documentation/DocBook/media/v4l/compat.xml +++ b/Documentation/DocBook/media/v4l/compat.xml @@ -444,7 +444,7 @@ linkend="pixfmt-rgb">V4L2_PIX_FMT_BGR24V4L2_PIX_FMT_BGR32 Presumably all V4L RGB formats are -little-endian, although some drivers might interpret them according to machine endianess. V4L2 defines little-endian, big-endian and red/blue +little-endian, although some drivers might interpret them according to machine endianness. V4L2 defines little-endian, big-endian and red/blue swapped variants. For details see . @@ -823,7 +823,7 @@ standard); 35468950 Hz PAL and SECAM (625-line standards) sample_format V4L2_PIX_FMT_GREY. The last four bytes (a -machine endianess integer) contain a frame counter. +machine endianness integer) contain a frame counter. start[] diff --git a/Documentation/arm/kernel_user_helpers.txt b/Documentation/arm/kernel_user_helpers.txt index a17df9f..5673594 100644 --- a/Documentation/arm/kernel_user_helpers.txt +++ b/Documentation/arm/kernel_user_helpers.txt @@ -25,7 +25,7 @@ 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 +usage 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. diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index 84f0a15..b4b1fb3 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ b/Documentation/cgroups/blkio-controller.txt @@ -94,11 +94,11 @@ Throttling/Upper Limit policy Hierarchical Cgroups ==================== -- Currently none of the IO control policy supports hierarhical groups. But - cgroup interface does allow creation of hierarhical cgroups and internally +- Currently none of the IO control policy supports hierarchical groups. But + cgroup interface does allow creation of hierarchical cgroups and internally IO policies treat them as flat hierarchy. - So this patch will allow creation of cgroup hierarhcy but at the backend + So this patch will allow creation of cgroup hierarchcy but at the backend everything will be treated as flat. So if somebody created a hierarchy like as follows. @@ -266,7 +266,7 @@ Proportional weight policy files - blkio.idle_time - Debugging aid only enabled if CONFIG_DEBUG_BLK_CGROUP=y. This is the amount of time spent by the IO scheduler idling for a - given cgroup in anticipation of a better request than the exising ones + given cgroup in anticipation of a better request than the existing ones from other queues/cgroups. This is in nanoseconds. If this is read when the cgroup is in an idling state, the stat will only report the idle_time accumulated till the last idle period and will not include @@ -283,34 +283,34 @@ Throttling/Upper limit policy files ----------------------------------- - blkio.throttle.read_bps_device - Specifies upper limit on READ rate from the device. IO rate is - specified in bytes per second. Rules are per deivce. Following is + specified in bytes per second. Rules are per device. Following is the format. echo ": " > /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 + specified in bytes per second. Rules are per device. Following is the format. echo ": " > /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 + specified in IO per second. Rules are per device. Following is the format. echo ": " > /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 + specified in io per second. Rules are per device. Following is the format. echo ": " > /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. + subjected to both the constraints. - blkio.throttle.io_serviced - Number of IOs (bio) completed to/from the disk by the group (as diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt index 2a8c113..946c733 100644 --- a/Documentation/device-mapper/dm-raid.txt +++ b/Documentation/device-mapper/dm-raid.txt @@ -28,7 +28,7 @@ The target is named "raid" and it accepts the following parameters: raid6_nc RAID6 N continue - rotating parity N (right-to-left) with data continuation - Refererence: Chapter 4 of + Reference: Chapter 4 of http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf <#raid_params>: The number of parameters that follow. diff --git a/Documentation/device-mapper/persistent-data.txt b/Documentation/device-mapper/persistent-data.txt index 0e5df9b..a333bcb 100644 --- a/Documentation/device-mapper/persistent-data.txt +++ b/Documentation/device-mapper/persistent-data.txt @@ -3,7 +3,7 @@ Introduction The more-sophisticated device-mapper targets require complex metadata that is managed in kernel. In late 2010 we were seeing that various -different targets were rolling their own data strutures, for example: +different targets were rolling their own data structures, for example: - Mikulas Patocka's multisnap implementation - Heinz Mauelshagen's thin provisioning target diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index dbdab40..edc618a 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -5,7 +5,7 @@ IPs present in the SoC. On top of that an omap_device is created to extend the platform_device capabilities and to allow binding with one or several hwmods. The hwmods will contain all the information to build the device: -adresse range, irq lines, dma lines, interconnect, PRCM register, +address range, irq lines, dma lines, interconnect, PRCM register, clock domain, input clocks. For the moment just point to the existing hwmod, the next step will be to move data from hwmod to device-tree representation. diff --git a/Documentation/devicetree/bindings/arm/sirf.txt b/Documentation/devicetree/bindings/arm/sirf.txt index 6b07f65..1881e1c 100644 --- a/Documentation/devicetree/bindings/arm/sirf.txt +++ b/Documentation/devicetree/bindings/arm/sirf.txt @@ -1,3 +1,3 @@ -prima2 "cb" evalutation board +prima2 "cb" evaluation board Required root node properties: - compatible = "sirf,prima2-cb", "sirf,prima2"; diff --git a/Documentation/devicetree/booting-without-of.txt b/Documentation/devicetree/booting-without-of.txt index 7c1329d..da0bfeb 100644 --- a/Documentation/devicetree/booting-without-of.txt +++ b/Documentation/devicetree/booting-without-of.txt @@ -169,7 +169,7 @@ it with special cases. b) Entry with a flattened device-tree block. Firmware loads the physical address of the flattened device tree block (dtb) into r2, - r1 is not used, but it is considered good practise to use a valid + r1 is not used, but it is considered good practice to use a valid machine number as described in Documentation/arm/Booting. r0 : 0 diff --git a/Documentation/dmaengine.txt b/Documentation/dmaengine.txt index bbe6cb3..879b6e3 100644 --- a/Documentation/dmaengine.txt +++ b/Documentation/dmaengine.txt @@ -63,7 +63,7 @@ The slave DMA usage consists of following steps: struct dma_slave_config *config) Please see the dma_slave_config structure definition in dmaengine.h - for a detailed explaination of the struct members. Please note + for a detailed explanation of the struct members. Please note that the 'direction' member will be going away as it duplicates the direction given in the prepare call. diff --git a/Documentation/fb/matroxfb.txt b/Documentation/fb/matroxfb.txt index e5ce8a1..b95f5bb 100644 --- a/Documentation/fb/matroxfb.txt +++ b/Documentation/fb/matroxfb.txt @@ -177,8 +177,8 @@ sgram - tells to driver that you have Gxx0 with SGRAM memory. It has no effect without `init'. sdram - tells to driver that you have Gxx0 with SDRAM memory. It is a default. -inv24 - change timings parameters for 24bpp modes on Millenium and - Millenium II. Specify this if you see strange color shadows around +inv24 - change timings parameters for 24bpp modes on Millennium and + Millennium II. Specify this if you see strange color shadows around characters. noinv24 - use standard timings. It is the default. inverse - invert colors on screen (for LCD displays) @@ -204,9 +204,9 @@ grayscale - enable grayscale summing. It works in PSEUDOCOLOR modes (text, can paint colors. nograyscale - disable grayscale summing. It is default. cross4MB - enables that pixel line can cross 4MB boundary. It is default for - non-Millenium. + non-Millennium. nocross4MB - pixel line must not cross 4MB boundary. It is default for - Millenium I or II, because of these devices have hardware + Millennium I or II, because of these devices have hardware limitations which do not allow this. But this option is incompatible with some (if not all yet released) versions of XF86_FBDev. diff --git a/Documentation/filesystems/ext4.txt b/Documentation/filesystems/ext4.txt index 10ec4639..8c10bf3 100644 --- a/Documentation/filesystems/ext4.txt +++ b/Documentation/filesystems/ext4.txt @@ -308,7 +308,7 @@ min_batch_time=usec This parameter sets the commit time (as fast disks, at the cost of increasing latency. journal_ioprio=prio The I/O priority (from 0 to 7, where 0 is the - highest priorty) which should be used for I/O + highest priority) which should be used for I/O operations submitted by kjournald2 during a commit operation. This defaults to 3, which is a slightly higher priority than the default I/O @@ -343,7 +343,7 @@ noinit_itable Do not initialize any uninitialized inode table init_itable=n The lazy itable init code will wait n times the number of milliseconds it took to zero out the previous block group's inode table. This - minimizes the impact on the systme performance + minimizes the impact on the system performance while file system's inode table is being initialized. discard Controls whether ext4 should issue discard/TRIM diff --git a/Documentation/filesystems/gfs2-uevents.txt b/Documentation/filesystems/gfs2-uevents.txt index d818896..19a19eb 100644 --- a/Documentation/filesystems/gfs2-uevents.txt +++ b/Documentation/filesystems/gfs2-uevents.txt @@ -62,7 +62,7 @@ be fixed. The REMOVE uevent is generated at the end of an unsuccessful mount or at the end of a umount of the filesystem. All REMOVE uevents will -have been preceded by at least an ADD uevent for the same fileystem, +have been preceded by at least an ADD uevent for the same filesystem, and unlike the other uevents is generated automatically by the kernel's kobject subsystem. diff --git a/Documentation/filesystems/pohmelfs/network_protocol.txt b/Documentation/filesystems/pohmelfs/network_protocol.txt index 65e03dd..c680b4b 100644 --- a/Documentation/filesystems/pohmelfs/network_protocol.txt +++ b/Documentation/filesystems/pohmelfs/network_protocol.txt @@ -20,7 +20,7 @@ Commands can be embedded into transaction command (which in turn has own command so one can extend protocol as needed without breaking backward compatibility as long as old commands are supported. All string lengths include tail 0 byte. -All commands are transferred over the network in big-endian. CPU endianess is used at the end peers. +All commands are transferred over the network in big-endian. CPU endianness is used at the end peers. @cmd - command number, which specifies command to be processed. Following commands are used currently: diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 3d9393b..e916e3d 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -993,7 +993,7 @@ struct dentry_operations { If the 'rcu_walk' parameter is true, then the caller is doing a pathwalk in RCU-walk mode. Sleeping is not permitted in this mode, - and the caller can be asked to leave it and call again by returing + and the caller can be asked to leave it and call again by returning -ECHILD. This function is only used if DCACHE_MANAGE_TRANSIT is set on the diff --git a/Documentation/hwmon/adm1275 b/Documentation/hwmon/adm1275 index ab70d96..e5f982c 100644 --- a/Documentation/hwmon/adm1275 +++ b/Documentation/hwmon/adm1275 @@ -53,7 +53,7 @@ attributes are write-only, all other attributes are read-only. in1_label "vin1" or "vout1" depending on chip variant and configuration. in1_input Measured voltage. -in1_min Minumum Voltage. +in1_min Minimum Voltage. in1_max Maximum voltage. in1_min_alarm Voltage low alarm. in1_max_alarm Voltage high alarm. diff --git a/Documentation/hwmon/max16064 b/Documentation/hwmon/max16064 index f6e8bcb..f8b4780 100644 --- a/Documentation/hwmon/max16064 +++ b/Documentation/hwmon/max16064 @@ -42,9 +42,9 @@ attributes are read-only. in[1-4]_label "vout[1-4]" in[1-4]_input Measured voltage. From READ_VOUT register. -in[1-4]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register. +in[1-4]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register. in[1-4]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register. -in[1-4]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register. +in[1-4]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register. in[1-4]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register. in[1-4]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status. in[1-4]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status. diff --git a/Documentation/hwmon/max34440 b/Documentation/hwmon/max34440 index 8ab5153..1974391 100644 --- a/Documentation/hwmon/max34440 +++ b/Documentation/hwmon/max34440 @@ -48,9 +48,9 @@ attributes are read-only. in[1-6]_label "vout[1-6]". in[1-6]_input Measured voltage. From READ_VOUT register. -in[1-6]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register. +in[1-6]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register. in[1-6]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register. -in[1-6]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register. +in[1-6]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register. in[1-6]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register. in[1-6]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status. in[1-6]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status. diff --git a/Documentation/hwmon/max8688 b/Documentation/hwmon/max8688 index 71ed10a..fe84987 100644 --- a/Documentation/hwmon/max8688 +++ b/Documentation/hwmon/max8688 @@ -42,9 +42,9 @@ attributes are read-only. in1_label "vout1" in1_input Measured voltage. From READ_VOUT register. -in1_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register. +in1_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register. in1_max Maximum voltage. From VOUT_OV_WARN_LIMIT register. -in1_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register. +in1_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register. in1_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register. in1_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status. in1_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status. diff --git a/Documentation/hwmon/ucd9000 b/Documentation/hwmon/ucd9000 index 40ca6db..0df5f27 100644 --- a/Documentation/hwmon/ucd9000 +++ b/Documentation/hwmon/ucd9000 @@ -70,9 +70,9 @@ attributes are read-only. in[1-12]_label "vout[1-12]". in[1-12]_input Measured voltage. From READ_VOUT register. -in[1-12]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register. +in[1-12]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register. in[1-12]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register. -in[1-12]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register. +in[1-12]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register. in[1-12]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register. in[1-12]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status. in[1-12]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status. @@ -82,7 +82,7 @@ in[1-12]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status. curr[1-12]_label "iout[1-12]". curr[1-12]_input Measured current. From READ_IOUT register. curr[1-12]_max Maximum current. From IOUT_OC_WARN_LIMIT register. -curr[1-12]_lcrit Critical minumum output current. From IOUT_UC_FAULT_LIMIT +curr[1-12]_lcrit Critical minimum output current. From IOUT_UC_FAULT_LIMIT register. curr[1-12]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register. curr[1-12]_max_alarm Current high alarm. From IOUT_OC_WARNING status. diff --git a/Documentation/hwmon/ucd9200 b/Documentation/hwmon/ucd9200 index 3c58607..fd7d07b 100644 --- a/Documentation/hwmon/ucd9200 +++ b/Documentation/hwmon/ucd9200 @@ -54,9 +54,9 @@ attributes are read-only. in1_label "vin". in1_input Measured voltage. From READ_VIN register. -in1_min Minumum Voltage. From VIN_UV_WARN_LIMIT register. +in1_min Minimum Voltage. From VIN_UV_WARN_LIMIT register. in1_max Maximum voltage. From VIN_OV_WARN_LIMIT register. -in1_lcrit Critical minumum Voltage. VIN_UV_FAULT_LIMIT register. +in1_lcrit Critical minimum Voltage. VIN_UV_FAULT_LIMIT register. in1_crit Critical maximum voltage. From VIN_OV_FAULT_LIMIT register. in1_min_alarm Voltage low alarm. From VIN_UV_WARNING status. in1_max_alarm Voltage high alarm. From VIN_OV_WARNING status. @@ -65,9 +65,9 @@ in1_crit_alarm Voltage critical high alarm. From VIN_OV_FAULT status. in[2-5]_label "vout[1-4]". in[2-5]_input Measured voltage. From READ_VOUT register. -in[2-5]_min Minumum Voltage. From VOUT_UV_WARN_LIMIT register. +in[2-5]_min Minimum Voltage. From VOUT_UV_WARN_LIMIT register. in[2-5]_max Maximum voltage. From VOUT_OV_WARN_LIMIT register. -in[2-5]_lcrit Critical minumum Voltage. VOUT_UV_FAULT_LIMIT register. +in[2-5]_lcrit Critical minimum Voltage. VOUT_UV_FAULT_LIMIT register. in[2-5]_crit Critical maximum voltage. From VOUT_OV_FAULT_LIMIT register. in[2-5]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status. in[2-5]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status. @@ -80,7 +80,7 @@ curr1_input Measured current. From READ_IIN register. curr[2-5]_label "iout[1-4]". curr[2-5]_input Measured current. From READ_IOUT register. curr[2-5]_max Maximum current. From IOUT_OC_WARN_LIMIT register. -curr[2-5]_lcrit Critical minumum output current. From IOUT_UC_FAULT_LIMIT +curr[2-5]_lcrit Critical minimum output current. From IOUT_UC_FAULT_LIMIT register. curr[2-5]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register. curr[2-5]_max_alarm Current high alarm. From IOUT_OC_WARNING status. diff --git a/Documentation/hwmon/zl6100 b/Documentation/hwmon/zl6100 index 51f76a1..5865a24 100644 --- a/Documentation/hwmon/zl6100 +++ b/Documentation/hwmon/zl6100 @@ -108,7 +108,7 @@ in1_label "vin" in1_input Measured input voltage. in1_min Minimum input voltage. in1_max Maximum input voltage. -in1_lcrit Critical minumum input voltage. +in1_lcrit Critical minimum input voltage. in1_crit Critical maximum input voltage. in1_min_alarm Input voltage low alarm. in1_max_alarm Input voltage high alarm. @@ -117,7 +117,7 @@ in1_crit_alarm Input voltage critical high alarm. in2_label "vout1" in2_input Measured output voltage. -in2_lcrit Critical minumum output Voltage. +in2_lcrit Critical minimum output Voltage. in2_crit Critical maximum output voltage. in2_lcrit_alarm Critical output voltage critical low alarm. in2_crit_alarm Critical output voltage critical high alarm. diff --git a/Documentation/i2o/ioctl b/Documentation/i2o/ioctl index 22ca53a..27c3c54 100644 --- a/Documentation/i2o/ioctl +++ b/Documentation/i2o/ioctl @@ -138,7 +138,7 @@ VI. Setting Parameters The return value is the size in bytes of the data written into ops->resbuf if no errors occur. If an error occurs, -1 is returned - and errno is set appropriatly: + and errno is set appropriately: EFAULT Invalid user space pointer was passed ENXIO Invalid IOP number @@ -222,7 +222,7 @@ VIII. Downloading Software RETURNS This function returns 0 no errors occur. If an error occurs, -1 - is returned and errno is set appropriatly: + is returned and errno is set appropriately: EFAULT Invalid user space pointer was passed ENXIO Invalid IOP number @@ -264,7 +264,7 @@ IX. Uploading Software RETURNS This function returns 0 if no errors occur. If an error occurs, -1 - is returned and errno is set appropriatly: + is returned and errno is set appropriately: EFAULT Invalid user space pointer was passed ENXIO Invalid IOP number @@ -301,7 +301,7 @@ X. Removing Software RETURNS This function returns 0 if no errors occur. If an error occurs, -1 - is returned and errno is set appropriatly: + is returned and errno is set appropriately: EFAULT Invalid user space pointer was passed ENXIO Invalid IOP number @@ -325,7 +325,7 @@ X. Validating Configuration RETURNS This function returns 0 if no erro occur. If an error occurs, -1 is - returned and errno is set appropriatly: + returned and errno is set appropriately: ETIMEDOUT Timeout waiting for reply message ENXIO Invalid IOP number @@ -360,7 +360,7 @@ XI. Configuration Dialog RETURNS This function returns 0 if no error occur. If an error occurs, -1 - is returned and errno is set appropriatly: + is returned and errno is set appropriately: EFAULT Invalid user space pointer was passed ENXIO Invalid IOP number diff --git a/Documentation/ide/ChangeLog.ide-cd.1994-2004 b/Documentation/ide/ChangeLog.ide-cd.1994-2004 index 190d17b..4cc3ad9 100644 --- a/Documentation/ide/ChangeLog.ide-cd.1994-2004 +++ b/Documentation/ide/ChangeLog.ide-cd.1994-2004 @@ -175,7 +175,7 @@ * since the .pdf version doesn't seem to work... * -- Updated the TODO list to something more current. * - * 4.15 Aug 25, 1998 -- Updated ide-cd.h to respect mechine endianess, + * 4.15 Aug 25, 1998 -- Updated ide-cd.h to respect machine endianness, * patch thanks to "Eddie C. Dost" * * 4.50 Oct 19, 1998 -- New maintainers! diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt index f274c28..9c407f0 100644 --- a/Documentation/input/alps.txt +++ b/Documentation/input/alps.txt @@ -131,8 +131,8 @@ number of contacts (f1 and f0 in the table below). byte 5: 0 1 ? ? ? ? f1 f0 This packet only appears after a position packet with the mt bit set, and -ususally only appears when there are two or more contacts (although -ocassionally it's seen with only a single contact). +usually only appears when there are two or more contacts (although +occassionally it's seen with only a single contact). The final v3 packet type is the trackstick packet. diff --git a/Documentation/input/joystick.txt b/Documentation/input/joystick.txt index 8007b7c..304262b 100644 --- a/Documentation/input/joystick.txt +++ b/Documentation/input/joystick.txt @@ -330,7 +330,7 @@ the USB documentation for how to setup an USB mouse. The TM DirectConnect (BSP) protocol is supported by the tmdc.c module. This includes, but is not limited to: -* ThrustMaster Millenium 3D Inceptor +* ThrustMaster Millennium 3D Interceptor * ThrustMaster 3D Rage Pad * ThrustMaster Fusion Digital Game Pad diff --git a/Documentation/ioctl/hdio.txt b/Documentation/ioctl/hdio.txt index 91a6ecb..18eb98c 100644 --- a/Documentation/ioctl/hdio.txt +++ b/Documentation/ioctl/hdio.txt @@ -596,7 +596,7 @@ HDIO_DRIVE_TASKFILE execute raw taskfile if CHS/LBA28 The association between in_flags.all and each enable - bitfield flips depending on endianess; fortunately, TASKFILE + bitfield flips depending on endianness; fortunately, TASKFILE only uses inflags.b.data bit and ignores all other bits. The end result is that, on any endian machines, it has no effect other than modifying in_flags on completion. @@ -720,7 +720,7 @@ HDIO_DRIVE_TASKFILE execute raw taskfile [6] Do not access {in|out}_flags->all except for resetting all the bits. Always access individual bit fields. ->all - value will flip depending on endianess. For the same + value will flip depending on endianness. For the same reason, do not use IDE_{TASKFILE|HOB}_STD_{OUT|IN}_FLAGS constants defined in hdreg.h. diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index 44e2649..a686f9c 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -117,7 +117,7 @@ applicable everywhere (see syntax). This attribute is only applicable to menu blocks, if the condition is false, the menu block is not displayed to the user (the symbols contained there can still be selected by other symbols, though). It is - similar to a conditional "prompt" attribude for individual menu + similar to a conditional "prompt" attribute for individual menu entries. Default value of "visible" is true. - numerical ranges: "range" ["if" ] diff --git a/Documentation/networking/fore200e.txt b/Documentation/networking/fore200e.txt index 6e0d2a9..f648eb2 100644 --- a/Documentation/networking/fore200e.txt +++ b/Documentation/networking/fore200e.txt @@ -44,7 +44,7 @@ the 'software updates' pages. The firmware binaries are part of the various ForeThought software distributions. Notice that different versions of the PCA-200E firmware exist, depending -on the endianess of the host architecture. The driver is shipped with +on the endianness of the host architecture. The driver is shipped with both little and big endian PCA firmware images. Name and location of the new firmware images can be set at kernel diff --git a/Documentation/scsi/ChangeLog.lpfc b/Documentation/scsi/ChangeLog.lpfc index c56ec99..2f6d595 100644 --- a/Documentation/scsi/ChangeLog.lpfc +++ b/Documentation/scsi/ChangeLog.lpfc @@ -1718,7 +1718,7 @@ Changes from 20040319 to 20040326 * lpfc_els_timeout_handler() now uses system timer. * Further cleanup of #ifdef powerpc * lpfc_scsi_timeout_handler() now uses system timer. - * Replace common driver's own defines for endianess w/ Linux's + * Replace common driver's own defines for endianness w/ Linux's __BIG_ENDIAN etc. * Added #ifdef IPFC for all IPFC specific code. * lpfc_disc_retry_rptlun() now uses system timer. diff --git a/Documentation/scsi/ChangeLog.megaraid_sas b/Documentation/scsi/ChangeLog.megaraid_sas index 57566ba..83f8ea8 100644 --- a/Documentation/scsi/ChangeLog.megaraid_sas +++ b/Documentation/scsi/ChangeLog.megaraid_sas @@ -510,7 +510,7 @@ i. Support for 1078 type (ppc IOP) controller, device id : 0x60 added. 3 Older Version : 00.00.02.02 i. Register 16 byte CDB capability with scsi midlayer - "Ths patch properly registers the 16 byte command length capability of the + "This patch properly registers the 16 byte command length capability of the megaraid_sas controlled hardware with the scsi midlayer. All megaraid_sas hardware supports 16 byte CDB's." diff --git a/Documentation/scsi/tmscsim.txt b/Documentation/scsi/tmscsim.txt index 61c0531..3303d21 100644 --- a/Documentation/scsi/tmscsim.txt +++ b/Documentation/scsi/tmscsim.txt @@ -102,7 +102,7 @@ So take at least the following measures: ftp://student.physik.uni-dortmund.de/pub/linux/kernel/bootdisk.gz One more warning: I used to overclock my PCI bus to 41.67 MHz. My Tekram -DC390F (Sym53c875) accepted this as well as my Millenium. But the Am53C974 +DC390F (Sym53c875) accepted this as well as my Millennium. But the Am53C974 produced errors and started to corrupt my disks. So don't do that! A 37.50 MHz PCI bus works for me, though, but I don't recommend using higher clocks than the 33.33 MHz being in the PCI spec. diff --git a/Documentation/security/Smack.txt b/Documentation/security/Smack.txt index e9dab41..d2f72ae 100644 --- a/Documentation/security/Smack.txt +++ b/Documentation/security/Smack.txt @@ -536,6 +536,6 @@ writing a single character to the /smack/logging file : 3 : log denied & accepted Events are logged as 'key=value' pairs, for each event you at least will get -the subjet, the object, the rights requested, the action, the kernel function +the subject, the object, the rights requested, the action, the kernel function that triggered the event, plus other pairs depending on the type of event audited. diff --git a/Documentation/security/keys-trusted-encrypted.txt b/Documentation/security/keys-trusted-encrypted.txt index c9e4855..e105ae9 100644 --- a/Documentation/security/keys-trusted-encrypted.txt +++ b/Documentation/security/keys-trusted-encrypted.txt @@ -1,7 +1,7 @@ Trusted and Encrypted Keys Trusted and Encrypted Keys are two new key types added to the existing kernel -key ring service. Both of these new types are variable length symmetic keys, +key ring service. Both of these new types are variable length symmetric keys, and in both cases all keys are created in the kernel, and user space sees, stores, and loads only encrypted blobs. Trusted Keys require the availability of a Trusted Platform Module (TPM) chip for greater security, while Encrypted diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt index 4d75931..fcbe7a7 100644 --- a/Documentation/security/keys.txt +++ b/Documentation/security/keys.txt @@ -668,7 +668,7 @@ The keyctl syscall functions are: If the kernel calls back to userspace to complete the instantiation of a key, userspace should use this call mark the key as negative before the - invoked process returns if it is unable to fulfil the request. + invoked process returns if it is unable to fulfill the request. The process must have write access on the key to be able to instantiate it, and the key must be uninstantiated. diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index 936699e..12e3a0f 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -1588,7 +1588,7 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Module supports autoprobe a chip. - Note: the driver may have problems regarding endianess. + Note: the driver may have problems regarding endianness. The power-management is supported. diff --git a/Documentation/video4linux/uvcvideo.txt b/Documentation/video4linux/uvcvideo.txt index 848d620..35ce19c 100644 --- a/Documentation/video4linux/uvcvideo.txt +++ b/Documentation/video4linux/uvcvideo.txt @@ -116,7 +116,7 @@ Description: A UVC control can be mapped to several V4L2 controls. For instance, a UVC pan/tilt control could be mapped to separate pan and tilt V4L2 controls. The UVC control is divided into non overlapping fields using - the 'size' and 'offset' fields and are then independantly mapped to + the 'size' and 'offset' fields and are then independently mapped to V4L2 control. For signed integer V4L2 controls the data_type field should be set to diff --git a/Documentation/virtual/kvm/mmu.txt b/Documentation/virtual/kvm/mmu.txt index 5dc972c..fa5f1db 100644 --- a/Documentation/virtual/kvm/mmu.txt +++ b/Documentation/virtual/kvm/mmu.txt @@ -347,7 +347,7 @@ To instantiate a large spte, four constraints must be satisfied: - the spte must point to a large host page - the guest pte must be a large pte of at least equivalent size (if tdp is - enabled, there is no guest pte and this condition is satisified) + enabled, there is no guest pte and this condition is satisfied) - if the spte will be writeable, the large page frame may not overlap any write-protected pages - the guest page must be wholly contained by a single memory slot @@ -356,7 +356,7 @@ To check the last two conditions, the mmu maintains a ->write_count set of arrays for each memory slot and large page size. Every write protected page causes its write_count to be incremented, thus preventing instantiation of a large spte. The frames at the end of an unaligned memory slot have -artificically inflated ->write_counts so they can never be instantiated. +artificially inflated ->write_counts so they can never be instantiated. Further reading =============== diff --git a/Documentation/virtual/virtio-spec.txt b/Documentation/virtual/virtio-spec.txt index a350ae1..da09473 100644 --- a/Documentation/virtual/virtio-spec.txt +++ b/Documentation/virtual/virtio-spec.txt @@ -1403,7 +1403,7 @@ segmentation, if both guests are amenable. Packets are transmitted by placing them in the transmitq, and buffers for incoming packets are placed in the receiveq. In each -case, the packet itself is preceeded by a header: +case, the packet itself is preceded by a header: struct virtio_net_hdr { @@ -1642,7 +1642,7 @@ struct virtio_net_ctrl_mac { The device can filter incoming packets by any number of destination MAC addresses.[footnote: -Since there are no guarentees, it can use a hash filter +Since there are no guarantees, it can use a hash filter orsilently switch to allmulti or promiscuous mode if it is given too many addresses. ] This table is set using the class VIRTIO_NET_CTRL_MAC and the @@ -1805,7 +1805,7 @@ the FLUSH and FLUSH_OUT types are equivalent, the device does not distinguish between them ]). If the device has VIRTIO_BLK_F_BARRIER feature the high bit (VIRTIO_BLK_T_BARRIER) indicates that this request acts as a -barrier and that all preceeding requests must be complete before +barrier and that all preceding requests must be complete before this one, and all following requests must not be started until this is complete. Note that a barrier does not flush caches in the underlying backend device in host, and thus does not serve as @@ -2118,7 +2118,7 @@ This is historical, and independent of the guest page size Otherwise, the guest may begin to re-use pages previously given to the balloon before the device has acknowledged their - withdrawl. [footnote: + withdrawal. [footnote: In this case, deflation advice is merely a courtesy ] diff --git a/Documentation/vm/unevictable-lru.txt b/Documentation/vm/unevictable-lru.txt index 609d1a3..fa206cc 100644 --- a/Documentation/vm/unevictable-lru.txt +++ b/Documentation/vm/unevictable-lru.txt @@ -619,7 +619,7 @@ all PTEs from the page. For this purpose, the unevictable/mlock infrastructure introduced a variant of try_to_unmap() called try_to_munlock(). try_to_munlock() calls the same functions as try_to_unmap() for anonymous and -mapped file pages with an additional argument specifing unlock versus unmap +mapped file pages with an additional argument specifying unlock versus unmap processing. Again, these functions walk the respective reverse maps looking for VM_LOCKED VMAs. When such a VMA is found for anonymous pages and file pages mapped in linear VMAs, as in the try_to_unmap() case, the functions -- cgit v1.1 From 979b907fa55be8cdbbf455b9204b7e4602f303e6 Mon Sep 17 00:00:00 2001 From: Zhiwu Song Date: Wed, 8 Feb 2012 23:28:35 +0800 Subject: i2c: add CSR SiRFprimaII on-chip I2C controllers driver MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit SiRFprimaII is the latest generation application processor from CSR’s multi-function SoC product family. The SoC support codes are in arch/arm/mach-prima2 from Linux mainline 3.0. There are two I2C controllers on primaII, features include: * Two I2C controller modules are on chip * RISC I/O bus read write register * Up to 16 bytes data buffer for issuing commands and writing data at the same time * Up to 16 commands, and receiving read data 16 bytes at a time * Error INT report (ACK check) * No-ACK bus protocols (SCCB bus protocols) Signed-off-by: Zhiwu Song Signed-off-by: Xiangzhen Ye Signed-off-by: Yuping Luo Signed-off-by: Barry Song Signed-off-by: Wolfram Sang --- Documentation/devicetree/bindings/i2c/sirf-i2c.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/i2c/sirf-i2c.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/i2c/sirf-i2c.txt b/Documentation/devicetree/bindings/i2c/sirf-i2c.txt new file mode 100644 index 0000000..7baf9e1 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/sirf-i2c.txt @@ -0,0 +1,19 @@ +I2C for SiRFprimaII platforms + +Required properties : +- compatible : Must be "sirf,prima2-i2c" +- reg: physical base address of the controller and length of memory mapped + region. +- interrupts: interrupt number to the cpu. + +Optional properties: +- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz. + The absence of the propoerty indicates the default frequency 100 kHz. + +Examples : + +i2c0: i2c@b00e0000 { + compatible = "sirf,prima2-i2c"; + reg = <0xb00e0000 0x10000>; + interrupts = <24>; +}; -- cgit v1.1 From ffbbdd21329f3e15eeca6df2d4bc11c04d9d91c0 Mon Sep 17 00:00:00 2001 From: Linus Walleij Date: Wed, 22 Feb 2012 10:05:38 +0100 Subject: spi: create a message queueing infrastructure This rips the message queue in the PL022 driver out and pushes it into (optional) common infrastructure. Drivers that want to use the message pumping thread will need to define the new per-messags transfer methods and leave the deprecated transfer() method as NULL. Most of the design is described in the documentation changes that are included in this patch. Since there is a queue that need to be stopped when the system is suspending/resuming, two new calls are implemented for the device drivers to call in their suspend()/resume() functions: spi_master_suspend() and spi_master_resume(). ChangeLog v1->v2: - Remove Kconfig entry and do not make the queue support optional at all, instead be more agressive and have it as part of the compulsory infrastructure. - If the .transfer() method is implemented, delete print a small deprecation notice and do not start the transfer pump. - Fix a bitrotted comment. ChangeLog v2->v3: - Fix up a problematic sequence courtesy of Chris Blair. - Stop rather than destroy the queue on suspend() courtesy of Chris Blair. Signed-off-by: Chris Blair Signed-off-by: Linus Walleij Tested-by: Mark Brown Reviewed-by: Mark Brown Signed-off-by: Grant Likely --- Documentation/spi/spi-summary | 58 ++++++++++++++++++++++++++++++++++--------- 1 file changed, 46 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 4884cb3..7312ec1 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary @@ -1,7 +1,7 @@ Overview of Linux kernel SPI support ==================================== -21-May-2007 +02-Feb-2012 What is SPI? ------------ @@ -483,9 +483,9 @@ also initialize its own internal state. (See below about bus numbering and those methods.) After you initialize the spi_master, then use spi_register_master() to -publish it to the rest of the system. At that time, device nodes for -the controller and any predeclared spi devices will be made available, -and the driver model core will take care of binding them to drivers. +publish it to the rest of the system. At that time, device nodes for the +controller and any predeclared spi devices will be made available, and +the driver model core will take care of binding them to drivers. If you need to remove your SPI controller driver, spi_unregister_master() will reverse the effect of spi_register_master(). @@ -521,21 +521,53 @@ SPI MASTER METHODS ** When you code setup(), ASSUME that the controller ** is actively processing transfers for another device. - master->transfer(struct spi_device *spi, struct spi_message *message) - This must not sleep. Its responsibility is arrange that the - transfer happens and its complete() callback is issued. The two - will normally happen later, after other transfers complete, and - if the controller is idle it will need to be kickstarted. - master->cleanup(struct spi_device *spi) Your controller driver may use spi_device.controller_state to hold state it dynamically associates with that device. If you do that, be sure to provide the cleanup() method to free that state. + master->prepare_transfer_hardware(struct spi_master *master) + This will be called by the queue mechanism to signal to the driver + that a message is coming in soon, so the subsystem requests the + driver to prepare the transfer hardware by issuing this call. + This may sleep. + + master->unprepare_transfer_hardware(struct spi_master *master) + This will be called by the queue mechanism to signal to the driver + that there are no more messages pending in the queue and it may + relax the hardware (e.g. by power management calls). This may sleep. + + master->transfer_one_message(struct spi_master *master, + struct spi_message *mesg) + The subsystem calls the driver to transfer a single message while + queuing transfers that arrive in the meantime. When the driver is + finished with this message, it must call + spi_finalize_current_message() so the subsystem can issue the next + transfer. This may sleep. + + DEPRECATED METHODS + + master->transfer(struct spi_device *spi, struct spi_message *message) + This must not sleep. Its responsibility is arrange that the + transfer happens and its complete() callback is issued. The two + will normally happen later, after other transfers complete, and + if the controller is idle it will need to be kickstarted. This + method is not used on queued controllers and must be NULL if + transfer_one_message() and (un)prepare_transfer_hardware() are + implemented. + SPI MESSAGE QUEUE -The bulk of the driver will be managing the I/O queue fed by transfer(). +If you are happy with the standard queueing mechanism provided by the +SPI subsystem, just implement the queued methods specified above. Using +the message queue has the upside of centralizing a lot of code and +providing pure process-context execution of methods. The message queue +can also be elevated to realtime priority on high-priority SPI traffic. + +Unless the queueing mechanism in the SPI subsystem is selected, the bulk +of the driver will be managing the I/O queue fed by the now deprecated +function transfer(). That queue could be purely conceptual. For example, a driver used only for low-frequency sensor access might be fine using synchronous PIO. @@ -561,4 +593,6 @@ Stephen Street Mark Underwood Andrew Victor Vitaly Wool - +Grant Likely +Mark Brown +Linus Walleij -- cgit v1.1 From dd32f98120e7a763b125a3d5f60799a97b0a2b51 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jean-Fran=C3=A7ois=20Moine?= Date: Mon, 27 Feb 2012 04:58:59 -0300 Subject: [media] gspca - pac7302: Add new webcam 06f8:301b MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Jean-François Moine Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/gspca.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/gspca.txt b/Documentation/video4linux/gspca.txt index f2060f0d..e6c2842 100644 --- a/Documentation/video4linux/gspca.txt +++ b/Documentation/video4linux/gspca.txt @@ -217,6 +217,7 @@ ov534_9 06f8:3003 Hercules Dualpix HD Weblog sonixj 06f8:3004 Hercules Classic Silver sonixj 06f8:3008 Hercules Deluxe Optical Glass pac7302 06f8:3009 Hercules Classic Link +pac7302 06f8:301b Hercules Link nw80x 0728:d001 AVerMedia Camguard spca508 0733:0110 ViewQuest VQ110 spca501 0733:0401 Intel Create and Share -- cgit v1.1 From 25fa207157102162b1a6abba339dc5fe03f6adc5 Mon Sep 17 00:00:00 2001 From: Kyle Strickland Date: Sat, 18 Feb 2012 02:24:53 -0300 Subject: [media] Add support for KWorld PC150-U ATSC hybrid tuner card [mchehab@redhat.com: CodingStyle fixes] Signed-off-by: Kyle Strickland Signed-off-by: Mauro Carvalho Chehab --- Documentation/dvb/cards.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/dvb/cards.txt b/Documentation/dvb/cards.txt index cc09187..97709e9 100644 --- a/Documentation/dvb/cards.txt +++ b/Documentation/dvb/cards.txt @@ -119,4 +119,5 @@ o Cards based on the Phillips saa7134 PCI bridge: - Compro Videomate DVB-T300 - Compro Videomate DVB-T200 - AVerMedia AVerTVHD MCE A180 + - KWorld PC150-U ATSC Hybrid -- cgit v1.1 From 99025937bcd2291e6e50b4e54fe1f6d48d4c2b7c Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Thu, 8 Mar 2012 11:01:36 -0300 Subject: [media] Documentation: Update some card lists Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.cx23885 | 1 + Documentation/video4linux/CARDLIST.cx88 | 4 +++- Documentation/video4linux/CARDLIST.em28xx | 7 ++++--- Documentation/video4linux/CARDLIST.saa7134 | 1 + Documentation/video4linux/CARDLIST.tuner | 3 ++- 5 files changed, 11 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.cx23885 b/Documentation/video4linux/CARDLIST.cx23885 index 23584d0..f316d18 100644 --- a/Documentation/video4linux/CARDLIST.cx23885 +++ b/Documentation/video4linux/CARDLIST.cx23885 @@ -32,3 +32,4 @@ 31 -> Leadtek Winfast PxDVR3200 H XC4000 [107d:6f39] 32 -> MPX-885 33 -> Mygica X8507 [14f1:8502] + 34 -> TerraTec Cinergy T PCIe Dual [153b:117e] diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 index eee18e6..fa4b3f9 100644 --- a/Documentation/video4linux/CARDLIST.cx88 +++ b/Documentation/video4linux/CARDLIST.cx88 @@ -59,7 +59,7 @@ 58 -> Pinnacle PCTV HD 800i [11bd:0051] 59 -> DViCO FusionHDTV 5 PCI nano [18ac:d530] 60 -> Pinnacle Hybrid PCTV [12ab:1788] - 61 -> Leadtek TV2000 XP Global [107d:6f18,107d:6618] + 61 -> Leadtek TV2000 XP Global [107d:6f18,107d:6618,107d:6619] 62 -> PowerColor RA330 [14f1:ea3d] 63 -> Geniatech X8000-MT DVBT [14f1:8852] 64 -> DViCO FusionHDTV DVB-T PRO [18ac:db30] @@ -87,3 +87,5 @@ 86 -> TeVii S464 DVB-S/S2 [d464:9022] 87 -> Leadtek WinFast DTV2000 H PLUS [107d:6f42] 88 -> Leadtek WinFast DTV1800 H (XC4000) [107d:6f38] + 89 -> Leadtek TV2000 XP Global (SC4100) [107d:6f36] + 90 -> Leadtek TV2000 XP Global (XC4100) [107d:6f43] diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index e7be3ac..6f69b05 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -7,7 +7,7 @@ 6 -> Terratec Cinergy 200 USB (em2800) 7 -> Leadtek Winfast USB II (em2800) [0413:6023] 8 -> Kworld USB2800 (em2800) - 9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker (em2820/em2840) [1b80:e302,1b80:e304,2304:0207,2304:021a] + 9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker (em2820/em2840) [1b80:e302,1b80:e304,2304:0207,2304:021a,093b:a003] 10 -> Hauppauge WinTV HVR 900 (em2880) [2040:6500] 11 -> Terratec Hybrid XS (em2880) 12 -> Kworld PVR TV 2800 RF (em2820/em2840) @@ -61,7 +61,7 @@ 61 -> Pixelview PlayTV Box 4 USB 2.0 (em2820/em2840) 62 -> Gadmei TVR200 (em2820/em2840) 63 -> Kaiomy TVnPC U2 (em2860) [eb1a:e303] - 64 -> Easy Cap Capture DC-60 (em2860) + 64 -> Easy Cap Capture DC-60 (em2860) [1b80:e309] 65 -> IO-DATA GV-MVP/SZ (em2820/em2840) [04bb:0515] 66 -> Empire dual TV (em2880) 67 -> Terratec Grabby (em2860) [0ccd:0096,0ccd:10AF] @@ -76,7 +76,8 @@ 76 -> KWorld PlusTV 340U or UB435-Q (ATSC) (em2870) [1b80:a340] 77 -> EM2874 Leadership ISDBT (em2874) 78 -> PCTV nanoStick T2 290e (em28174) - 79 -> Terratec Cinergy H5 (em2884) [0ccd:10a2,0ccd:10ad] + 79 -> Terratec Cinergy H5 (em2884) [0ccd:008e,0ccd:00ac,0ccd:10a2,0ccd:10ad] 80 -> PCTV DVB-S2 Stick (460e) (em28174) 81 -> Hauppauge WinTV HVR 930C (em2884) [2040:1605] 82 -> Terratec Cinergy HTC Stick (em2884) [0ccd:00b2] + 83 -> Honestech Vidbox NW03 (em2860) [eb1a:5006] diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index e7ef38a..34f3b33 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -187,3 +187,4 @@ 186 -> Beholder BeholdTV 501 [5ace:5010] 187 -> Beholder BeholdTV 503 FM [5ace:5030] 188 -> Sensoray 811/911 [6000:0811,6000:0911] +189 -> Kworld PC150-U [17de:a134] diff --git a/Documentation/video4linux/CARDLIST.tuner b/Documentation/video4linux/CARDLIST.tuner index 6323b7a..c83f6e4 100644 --- a/Documentation/video4linux/CARDLIST.tuner +++ b/Documentation/video4linux/CARDLIST.tuner @@ -78,10 +78,11 @@ tuner=77 - TCL tuner MF02GIP-5N-E tuner=78 - Philips FMD1216MEX MK3 Hybrid Tuner tuner=79 - Philips PAL/SECAM multi (FM1216 MK5) tuner=80 - Philips FQ1216LME MK3 PAL/SECAM w/active loopthrough -tuner=81 - Xceive 4000 tuner tuner=81 - Partsnic (Daewoo) PTI-5NF05 tuner=82 - Philips CU1216L tuner=83 - NXP TDA18271 tuner=84 - Sony BTF-Pxn01Z tuner=85 - Philips FQ1236 MK5 tuner=86 - Tena TNF5337 MFD +tuner=87 - Xceive 4000 tuner +tuner=88 - Xceive 5000C tuner -- cgit v1.1 From 1b1301e67bbcad0649a8b3c6a944d2b2acddc411 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Fri, 24 Feb 2012 08:15:39 -0300 Subject: [media] Fix small DocBook typo Here is a small patch which fixes a DocBook mistake in the decoder_cmd documentation. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml index 466fe27..74b87f6 100644 --- a/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml +++ b/Documentation/DocBook/media/v4l/vidioc-decoder-cmd.xml @@ -118,7 +118,7 @@ this command, drivers and applications must set this field to zero. - __u32 + __s32 speed Playback speed and direction. The playback speed is defined as speed/1000 of the normal speed. So 1000 is normal playback. -- cgit v1.1 From 2098e95ce9bb039ff2e7bf836df358d18a176139 Mon Sep 17 00:00:00 2001 From: Rajendra Nayak Date: Tue, 28 Feb 2012 15:09:11 +0530 Subject: regulator: twl: adapt twl-regulator driver to dt Modify the twl regulator driver to extract the regulator_init_data from device tree when passed, instead of getting it through platform_data structures (on non-DT builds) Also add documentation for TWL regulator specific bindings. Signed-off-by: Rajendra Nayak Signed-off-by: Mark Brown --- .../bindings/regulator/twl-regulator.txt | 66 ++++++++++++++++++++++ 1 file changed, 66 insertions(+) create mode 100644 Documentation/devicetree/bindings/regulator/twl-regulator.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt b/Documentation/devicetree/bindings/regulator/twl-regulator.txt new file mode 100644 index 0000000..ba9d2cc --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt @@ -0,0 +1,66 @@ +TWL family of regulators + +Required properties: +For twl6030 regulators/LDOs +- compatible: + - "ti,twl6030-vaux1" for VAUX1 LDO + - "ti,twl6030-vaux2" for VAUX2 LDO + - "ti,twl6030-vaux3" for VAUX3 LDO + - "ti,twl6030-vmmc" for VMMC LDO + - "ti,twl6030-vpp" for VPP LDO + - "ti,twl6030-vusim" for VUSIM LDO + - "ti,twl6030-vana" for VANA LDO + - "ti,twl6030-vcxio" for VCXIO LDO + - "ti,twl6030-vdac" for VDAC LDO + - "ti,twl6030-vusb" for VUSB LDO + - "ti,twl6030-clk32kg" for CLK32KG RESOURCE + - "ti,twl6030-vdd1" for VDD1 SMPS + - "ti,twl6030-vdd2" for VDD2 SMPS + - "ti,twl6030-vdd3" for VDD3 SMPS +For twl6025 regulators/LDOs +- compatible: + - "ti,twl6025-ldo1" for LDO1 LDO + - "ti,twl6025-ldo2" for LDO2 LDO + - "ti,twl6025-ldo3" for LDO3 LDO + - "ti,twl6025-ldo4" for LDO4 LDO + - "ti,twl6025-ldo5" for LDO5 LDO + - "ti,twl6025-ldo6" for LDO6 LDO + - "ti,twl6025-ldo7" for LDO7 LDO + - "ti,twl6025-ldoln" for LDOLN LDO + - "ti,twl6025-ldousb" for LDOUSB LDO + - "ti,twl6025-smps3" for SMPS3 SMPS + - "ti,twl6025-smps4" for SMPS4 SMPS + - "ti,twl6025-vio" for VIO SMPS +For twl4030 regulators/LDOs +- compatible: + - "ti,twl4030-vaux1" for VAUX1 LDO + - "ti,twl4030-vaux2" for VAUX2 LDO + - "ti,twl5030-vaux2" for VAUX2 LDO + - "ti,twl4030-vaux3" for VAUX3 LDO + - "ti,twl4030-vaux4" for VAUX4 LDO + - "ti,twl4030-vmmc1" for VMMC1 LDO + - "ti,twl4030-vmmc2" for VMMC2 LDO + - "ti,twl4030-vpll1" for VPLL1 LDO + - "ti,twl4030-vpll2" for VPLL2 LDO + - "ti,twl4030-vsim" for VSIM LDO + - "ti,twl4030-vdac" for VDAC LDO + - "ti,twl4030-vintana2" for VINTANA2 LDO + - "ti,twl4030-vio" for VIO LDO + - "ti,twl4030-vdd1" for VDD1 SMPS + - "ti,twl4030-vdd2" for VDD2 SMPS + - "ti,twl4030-vintana1" for VINTANA1 LDO + - "ti,twl4030-vintdig" for VINTDIG LDO + - "ti,twl4030-vusb1v5" for VUSB1V5 LDO + - "ti,twl4030-vusb1v8" for VUSB1V8 LDO + - "ti,twl4030-vusb3v1" for VUSB3V1 LDO + +Optional properties: +- Any optional property defined in bindings/regulator/regulator.txt + +Example: + + xyz: regulator@0 { + compatible = "ti,twl6030-vaux1"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <3000000>; + }; -- cgit v1.1 From e9d47fa4ebb9382bc3282fc13ad28a4e2a1a089e Mon Sep 17 00:00:00 2001 From: Peter Ujfalusi Date: Tue, 28 Feb 2012 15:09:12 +0530 Subject: regulator: twl-regulator: Add fixed LDO for V1V8, V2V1 supply V1V8 supply most common use is to provide VIO for the system. V2V1 supply is used on SDP4430/PandaBoards to provide 2.1V to twl6040, and also as an input to VCXIO_IN, VDAC_IN of twl6030. Also update the bindings documentation with the new compatible property for these additional LDOs. Signed-off-by: Peter Ujfalusi Signed-off-by: Rajendra Nayak Signed-off-by: Mark Brown --- Documentation/devicetree/bindings/regulator/twl-regulator.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/regulator/twl-regulator.txt b/Documentation/devicetree/bindings/regulator/twl-regulator.txt index ba9d2cc..0c3395d 100644 --- a/Documentation/devicetree/bindings/regulator/twl-regulator.txt +++ b/Documentation/devicetree/bindings/regulator/twl-regulator.txt @@ -13,6 +13,8 @@ For twl6030 regulators/LDOs - "ti,twl6030-vcxio" for VCXIO LDO - "ti,twl6030-vdac" for VDAC LDO - "ti,twl6030-vusb" for VUSB LDO + - "ti,twl6030-v1v8" for V1V8 LDO + - "ti,twl6030-v2v1" for V2V1 LDO - "ti,twl6030-clk32kg" for CLK32KG RESOURCE - "ti,twl6030-vdd1" for VDD1 SMPS - "ti,twl6030-vdd2" for VDD2 SMPS -- cgit v1.1 From 3cd7920a2be893ed0ba58baaed8fc2930e822fc7 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Fri, 9 Mar 2012 17:25:33 +0100 Subject: mac80211: add auth/assoc/deauth flow diagram I've been working on some documentation, so let's add this diagram to the kernel tree where at least it has a chance of being maintained :-) Signed-off-by: Johannes Berg Signed-off-by: John W. Linville --- .../networking/mac80211-auth-assoc-deauth.txt | 99 ++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 Documentation/networking/mac80211-auth-assoc-deauth.txt (limited to 'Documentation') diff --git a/Documentation/networking/mac80211-auth-assoc-deauth.txt b/Documentation/networking/mac80211-auth-assoc-deauth.txt new file mode 100644 index 0000000..721773d --- /dev/null +++ b/Documentation/networking/mac80211-auth-assoc-deauth.txt @@ -0,0 +1,99 @@ +# +# This outlines the Linux authentication/association and +# deauthentication/disassociation flows. +# +# This can be converted into a diagram using the service +# at http://www.websequencediagrams.com/ +# + +participant userspace +participant mac80211 +participant driver + +alt authentication needed (not FT) +userspace->mac80211: authenticate + +alt authenticated/authenticating already +mac80211->driver: sta_state(AP, not-exist) +mac80211->driver: bss_info_changed(clear BSSID) +else associated +note over mac80211,driver +like deauth/disassoc, without sending the +BA session stop & deauth/disassoc frames +end note +end + +mac80211->driver: config(channel, non-HT) +mac80211->driver: bss_info_changed(set BSSID, basic rate bitmap) +mac80211->driver: sta_state(AP, exists) + +alt no probe request data known +mac80211->driver: TX directed probe request +driver->mac80211: RX probe response +end + +mac80211->driver: TX auth frame +driver->mac80211: RX auth frame + +alt WEP shared key auth +mac80211->driver: TX auth frame +driver->mac80211: RX auth frame +end + +mac80211->driver: sta_state(AP, authenticated) +mac80211->userspace: RX auth frame + +end + +userspace->mac80211: associate +alt authenticated or associated +note over mac80211,driver: cleanup like for authenticate +end + +alt not previously authenticated (FT) +mac80211->driver: config(channel, non-HT) +mac80211->driver: bss_info_changed(set BSSID, basic rate bitmap) +mac80211->driver: sta_state(AP, exists) +mac80211->driver: sta_state(AP, authenticated) +end +mac80211->driver: TX assoc +driver->mac80211: RX assoc response +note over mac80211: init rate control +mac80211->driver: sta_state(AP, associated) + +alt not using WPA +mac80211->driver: sta_state(AP, authorized) +end + +mac80211->driver: set up QoS parameters + +alt is HT channel +mac80211->driver: config(channel, HT params) +end + +mac80211->driver: bss_info_changed(QoS, HT, associated with AID) +mac80211->userspace: associated + +note left of userspace: associated now + +alt using WPA +note over userspace +do 4-way-handshake +(data frames) +end note +userspace->mac80211: authorized +mac80211->driver: sta_state(AP, authorized) +end + +userspace->mac80211: deauthenticate/disassociate +mac80211->driver: stop BA sessions +mac80211->driver: TX deauth/disassoc +mac80211->driver: flush frames +mac80211->driver: sta_state(AP,associated) +mac80211->driver: sta_state(AP,authenticated) +mac80211->driver: sta_state(AP,exist) +mac80211->driver: sta_state(AP,not-exist) +mac80211->driver: turn off powersave +mac80211->driver: bss_info_changed(clear BSSID, not associated, no QoS, ...) +mac80211->driver: config(non-HT channel type) +mac80211->userspace: disconnected -- cgit v1.1 From 6d430c2566467aaa6f39cbf7d0f6da5090db7007 Mon Sep 17 00:00:00 2001 From: Yegor Yefremov Date: Tue, 13 Mar 2012 10:57:51 +0100 Subject: Documentation: make exists consistent Signed-off-by: Yegor Yefremov Signed-off-by: John W. Linville --- Documentation/networking/mac80211-auth-assoc-deauth.txt | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/networking/mac80211-auth-assoc-deauth.txt b/Documentation/networking/mac80211-auth-assoc-deauth.txt index 721773d..e0a2aa58 100644 --- a/Documentation/networking/mac80211-auth-assoc-deauth.txt +++ b/Documentation/networking/mac80211-auth-assoc-deauth.txt @@ -14,7 +14,7 @@ alt authentication needed (not FT) userspace->mac80211: authenticate alt authenticated/authenticating already -mac80211->driver: sta_state(AP, not-exist) +mac80211->driver: sta_state(AP, not-exists) mac80211->driver: bss_info_changed(clear BSSID) else associated note over mac80211,driver @@ -91,8 +91,8 @@ mac80211->driver: TX deauth/disassoc mac80211->driver: flush frames mac80211->driver: sta_state(AP,associated) mac80211->driver: sta_state(AP,authenticated) -mac80211->driver: sta_state(AP,exist) -mac80211->driver: sta_state(AP,not-exist) +mac80211->driver: sta_state(AP,exists) +mac80211->driver: sta_state(AP,not-exists) mac80211->driver: turn off powersave mac80211->driver: bss_info_changed(clear BSSID, not associated, no QoS, ...) mac80211->driver: config(non-HT channel type) -- cgit v1.1 From 286431048b99705b555b6040da72bb2964386cea Mon Sep 17 00:00:00 2001 From: Roland Stigge Date: Mon, 12 Mar 2012 22:54:50 +0100 Subject: USB: ohci-nxp: Rename symbols from pnx4008 to nxp Since this driver is compatible with several NXP devices, the driver was renamed accordingly. This patch also changes the respective symbol names. Signed-off-by: Roland Stigge Acked-by: Arnd Bergmann Signed-off-by: Greg Kroah-Hartman --- Documentation/i2c/instantiating-devices | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/i2c/instantiating-devices b/Documentation/i2c/instantiating-devices index 9edb75d..abf6361 100644 --- a/Documentation/i2c/instantiating-devices +++ b/Documentation/i2c/instantiating-devices @@ -87,11 +87,11 @@ it may have different addresses from one board to the next (manufacturer changing its design without notice). In this case, you can call i2c_new_probed_device() instead of i2c_new_device(). -Example (from the pnx4008 OHCI driver): +Example (from the nxp OHCI driver): static const unsigned short normal_i2c[] = { 0x2c, 0x2d, I2C_CLIENT_END }; -static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev) +static int __devinit usb_hcd_nxp_probe(struct platform_device *pdev) { (...) struct i2c_adapter *i2c_adap; @@ -100,7 +100,7 @@ static int __devinit usb_hcd_pnx4008_probe(struct platform_device *pdev) (...) i2c_adap = i2c_get_adapter(2); memset(&i2c_info, 0, sizeof(struct i2c_board_info)); - strlcpy(i2c_info.type, "isp1301_pnx", I2C_NAME_SIZE); + strlcpy(i2c_info.type, "isp1301_nxp", I2C_NAME_SIZE); isp1301_i2c_client = i2c_new_probed_device(i2c_adap, &i2c_info, normal_i2c, NULL); i2c_put_adapter(i2c_adap); -- cgit v1.1 From 85dc0b8a4019e38ad4fd0c008f89a5c241805ac2 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Tue, 13 Mar 2012 01:01:39 +0100 Subject: PM / QoS: Make it possible to expose PM QoS latency constraints A runtime suspend of a device (e.g. an MMC controller) belonging to a power domain or, in a more complicated scenario, a runtime suspend of another device in the same power domain, may cause power to be removed from the entire domain. In that case, the amount of time necessary to runtime-resume the given device (e.g. the MMC controller) is often substantially greater than the time needed to run its driver's runtime resume callback. That may hurt performance in some situations, because user data may need to wait for the device to become operational, so we should make it possible to prevent that from happening. For this reason, introduce a new sysfs attribute for devices, power/pm_qos_resume_latency_us, allowing user space to specify the upper bound of the time necessary to bring the (runtime-suspended) device up after the resume of it has been requested. However, make that attribute appear only for the devices whose drivers declare support for it by calling the (new) dev_pm_qos_expose_latency_limit() helper function with the appropriate initial value of the attribute. Signed-off-by: Rafael J. Wysocki Reviewed-by: Kevin Hilman Reviewed-by: Mark Brown Acked-by: Linus Walleij --- Documentation/ABI/testing/sysfs-devices-power | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'Documentation') diff --git a/Documentation/ABI/testing/sysfs-devices-power b/Documentation/ABI/testing/sysfs-devices-power index 8ffbc25..840f7d6 100644 --- a/Documentation/ABI/testing/sysfs-devices-power +++ b/Documentation/ABI/testing/sysfs-devices-power @@ -165,3 +165,21 @@ Description: Not all drivers support this attribute. If it isn't supported, attempts to read or write it will yield I/O errors. + +What: /sys/devices/.../power/pm_qos_latency_us +Date: March 2012 +Contact: Rafael J. Wysocki +Description: + The /sys/devices/.../power/pm_qos_resume_latency_us attribute + contains the PM QoS resume latency limit for the given device, + which is the maximum allowed time it can take to resume the + device, after it has been suspended at run time, from a resume + request to the moment the device will be ready to process I/O, + in microseconds. If it is equal to 0, however, this means that + the PM QoS resume latency may be arbitrary. + + Not all drivers support this attribute. If it isn't supported, + it is not present. + + This attribute has no effect on system-wide suspend/resume and + hibernation. -- cgit v1.1 From 2cd36877ad1c61429e00c099b6903ebcd936ca00 Mon Sep 17 00:00:00 2001 From: Olof Johansson Date: Tue, 13 Mar 2012 21:35:51 -0700 Subject: Input: of_keymap - add device tree bindings for simple key matrices This adds a simple device tree binding for simple key matrix data and a helper to fill in the platform data. Signed-off-by: Olof Johansson Acked-by: Stephen Warren Signed-off-by: Dmitry Torokhov --- .../devicetree/bindings/input/matrix-keymap.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 Documentation/devicetree/bindings/input/matrix-keymap.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/matrix-keymap.txt b/Documentation/devicetree/bindings/input/matrix-keymap.txt new file mode 100644 index 0000000..3cd8b98 --- /dev/null +++ b/Documentation/devicetree/bindings/input/matrix-keymap.txt @@ -0,0 +1,19 @@ +A simple common binding for matrix-connected key boards. Currently targeted at +defining the keys in the scope of linux key codes since that is a stable and +standardized interface at this time. + +Required properties: +- linux,keymap: an array of packed 1-cell entries containing the equivalent + of row, column and linux key-code. The 32-bit big endian cell is packed + as: + row << 24 | column << 16 | key-code + +Optional properties: +Some users of this binding might choose to specify secondary keymaps for +cases where there is a modifier key such as a Fn key. Proposed names +for said properties are "linux,fn-keymap" or with another descriptive +word for the modifier other from "Fn". + +Example: + linux,keymap = < 0x00030012 + 0x0102003a >; -- cgit v1.1 From 145e97348a3066cf71038d02392aa8063550de6f Mon Sep 17 00:00:00 2001 From: Olof Johansson Date: Tue, 13 Mar 2012 21:36:29 -0700 Subject: Input: tegra-kbc - revise device tree support This is an incremental patch updating to the revised bindings for matrix keyboards. This includes an optional "linux,fn-keymap" binding that is not yet implemented, that will be used to specify the Fn-key modifier layout if needed. Signed-off-by: Olof Johansson Acked-by: Grant Likely Acked-by: Stephen Warren Signed-off-by: Dmitry Torokhov --- Documentation/devicetree/bindings/input/tegra-kbc.txt | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/input/tegra-kbc.txt b/Documentation/devicetree/bindings/input/tegra-kbc.txt index 5ecfa99..72683be 100644 --- a/Documentation/devicetree/bindings/input/tegra-kbc.txt +++ b/Documentation/devicetree/bindings/input/tegra-kbc.txt @@ -3,16 +3,21 @@ Required properties: - compatible: "nvidia,tegra20-kbc" -Optional properties: -- debounce-delay: delay in milliseconds per row scan for debouncing -- repeat-delay: delay in milliseconds before repeat starts -- ghost-filter: enable ghost filtering for this device -- wakeup-source: configure keyboard as a wakeup source for suspend/resume +Optional properties, in addition to those specified by the shared +matrix-keyboard bindings: + +- linux,fn-keymap: a second keymap, same specification as the + matrix-keyboard-controller spec but to be used when the KEY_FN modifier + key is pressed. +- nvidia,debounce-delay-ms: delay in milliseconds per row scan for debouncing +- nvidia,repeat-delay-ms: delay in milliseconds before repeat starts +- nvidia,ghost-filter: enable ghost filtering for this device +- nvidia,wakeup-source: configure keyboard as a wakeup source for suspend/resume Example: keyboard: keyboard { compatible = "nvidia,tegra20-kbc"; reg = <0x7000e200 0x100>; - ghost-filter; + nvidia,ghost-filter; }; -- cgit v1.1 From 7396bd9fa1f291423b6e9a262662a447cc3deb86 Mon Sep 17 00:00:00 2001 From: Sebastian Andrzej Siewior Date: Thu, 15 Mar 2012 21:59:36 +0100 Subject: usb/ub: deprecate & schedule for removal the "Low Performance USB Block" driver Deprecate this driver. All devices which can be handled by this driver can also be handled by the usb-storage driver. Acked-By: Pete Zaitcev Cc: Jens Axboe Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Greg Kroah-Hartman --- Documentation/feature-removal-schedule.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index a0ffac0..d5dc80f 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -524,3 +524,14 @@ Files: arch/arm/mach-at91/at91cap9.c Why: The code is not actively maintained and platforms are now hard to find. Who: Nicolas Ferre Jean-Christophe PLAGNIOL-VILLARD + +---------------------------- + +What: Low Performance USB Block driver ("CONFIG_BLK_DEV_UB") +When: 3.6 +Why: This driver provides support for USB storage devices like "USB + sticks". As of now, it is deactivated in Debian, Fedora and + Ubuntu. All current users can switch over to usb-storage + (CONFIG_USB_STORAGE) which only drawback is the additional SCSI + stack. +Who: Sebastian Andrzej Siewior -- cgit v1.1 From da3b6c0534c76bc08ce5524342586138687fd106 Mon Sep 17 00:00:00 2001 From: Diana CRACIUN Date: Wed, 1 Feb 2012 17:50:34 +0200 Subject: powerpc/fsl: Added aliased MSIIR register address to MSI node in dts The MSIIR register for each MSI bank is aliased to a different address. The MSI node reg property was updated to contain this address: e.g. reg = <0x41600 0x200 0x44140 4>; The first region contains the address and length of the MSI register set and the second region contains the address of the aliased MSIIR register at 0x44140. Signed-off-by: Diana CRACIUN Signed-off-by: Kumar Gala --- Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt index 5d586e1..5693877 100644 --- a/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt +++ b/Documentation/devicetree/bindings/powerpc/fsl/msi-pic.txt @@ -6,8 +6,10 @@ Required properties: etc.) and the second is "fsl,mpic-msi" or "fsl,ipic-msi" depending on the parent type. -- reg : should contain the address and the length of the shared message - interrupt register set. +- reg : It may contain one or two regions. The first region should contain + the address and the length of the shared message interrupt register set. + The second region should contain the address of aliased MSIIR register for + platforms that have such an alias. - msi-available-ranges: use style section to define which msi interrupt can be used in the 256 msi interrupts. This property is -- cgit v1.1 From e96dde2b5edbc0d385ccced05fb5db68c070b0d4 Mon Sep 17 00:00:00 2001 From: Jia Hongtao Date: Thu, 1 Mar 2012 17:32:34 +0800 Subject: powerpc: document the FSL MPIC message register binding This binding documents how the message register blocks found in some FSL MPIC implementations shall be represented in a device tree. Signed-off-by: Meador Inge Signed-off-by: Jia Hongtao Signed-off-by: Kumar Gala --- .../devicetree/bindings/powerpc/fsl/mpic-msgr.txt | 63 ++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt new file mode 100644 index 0000000..bc8ded6 --- /dev/null +++ b/Documentation/devicetree/bindings/powerpc/fsl/mpic-msgr.txt @@ -0,0 +1,63 @@ +* FSL MPIC Message Registers + +This binding specifies what properties must be available in the device tree +representation of the message register blocks found in some FSL MPIC +implementations. + +Required properties: + + - compatible: Specifies the compatibility list for the message register + block. The type shall be and the value shall be of the form + "fsl,mpic-v-msgr", where is the version number of + the MPIC containing the message registers. + + - reg: Specifies the base physical address(s) and size(s) of the + message register block's addressable register space. The type shall be + . + + - interrupts: Specifies a list of interrupt-specifiers which are available + for receiving interrupts. Interrupt-specifier consists of two cells: first + cell is interrupt-number and second cell is level-sense. The type shall be + . + +Optional properties: + + - mpic-msgr-receive-mask: Specifies what registers in the containing block + are allowed to receive interrupts. The value is a bit mask where a set + bit at bit 'n' indicates that message register 'n' can receive interrupts. + Note that "bit 'n'" is numbered from LSB for PPC hardware. The type shall + be . If not present, then all of the message registers in the block + are available. + +Aliases: + + An alias should be created for every message register block. They are not + required, though. However, a particular implementation of this binding + may require aliases to be present. Aliases are of the form + 'mpic-msgr-block', where is an integer specifying the block's number. + Numbers shall start at 0. + +Example: + + aliases { + mpic-msgr-block0 = &mpic_msgr_block0; + mpic-msgr-block1 = &mpic_msgr_block1; + }; + + mpic_msgr_block0: mpic-msgr-block@41400 { + compatible = "fsl,mpic-v3.1-msgr"; + reg = <0x41400 0x200>; + // Message registers 0 and 2 in this block can receive interrupts on + // sources 0xb0 and 0xb2, respectively. + interrupts = <0xb0 2 0xb2 2>; + mpic-msgr-receive-mask = <0x5>; + }; + + mpic_msgr_block1: mpic-msgr-block@42400 { + compatible = "fsl,mpic-v3.1-msgr"; + reg = <0x42400 0x200>; + // Message registers 0 and 2 in this block can receive interrupts on + // sources 0xb4 and 0xb6, respectively. + interrupts = <0xb4 2 0xb6 2>; + mpic-msgr-receive-mask = <0x5>; + }; -- cgit v1.1 From 6a228452d11eaf1f1577261540ec0903a2af7f61 Mon Sep 17 00:00:00 2001 From: Stefan Roese Date: Tue, 13 Mar 2012 04:56:37 +0000 Subject: stmmac: Add device-tree support This patch adds support to configure the STMMAC ethernet driver via device-tree instead of platform_data. Currently, only the properties needed on SPEAr600 are provided. All other properties should be added once needed on other platforms. Signed-off-by: Stefan Roese Cc: Giuseppe Cavallaro Signed-off-by: David S. Miller --- Documentation/devicetree/bindings/net/stmmac.txt | 28 ++++++++++++++++++++++++ 1 file changed, 28 insertions(+) create mode 100644 Documentation/devicetree/bindings/net/stmmac.txt (limited to 'Documentation') diff --git a/Documentation/devicetree/bindings/net/stmmac.txt b/Documentation/devicetree/bindings/net/stmmac.txt new file mode 100644 index 0000000..1f62623 --- /dev/null +++ b/Documentation/devicetree/bindings/net/stmmac.txt @@ -0,0 +1,28 @@ +* STMicroelectronics 10/100/1000 Ethernet driver (GMAC) + +Required properties: +- compatible: Should be "st,spear600-gmac" +- reg: Address and length of the register set for the device +- interrupt-parent: Should be the phandle for the interrupt controller + that services interrupts for this device +- interrupts: Should contain the STMMAC interrupts +- interrupt-names: Should contain the interrupt names "macirq" + "eth_wake_irq" if this interrupt is supported in the "interrupts" + property +- phy-mode: String, operation mode of the PHY interface. + Supported values are: "mii", "rmii", "gmii", "rgmii". + +Optional properties: +- mac-address: 6 bytes, mac address + +Examples: + + gmac0: ethernet@e0800000 { + compatible = "st,spear600-gmac"; + reg = <0xe0800000 0x8000>; + interrupt-parent = <&vic1>; + interrupts = <24 23>; + interrupt-names = "macirq", "eth_wake_irq"; + mac-address = [000000000000]; /* Filled in by U-Boot */ + phy-mode = "gmii"; + }; -- cgit v1.1 From 976af684bb7d2eb9e7dae7ae31d43843f0aa580b Mon Sep 17 00:00:00 2001 From: Andrea Gelmini Date: Sat, 17 Mar 2012 01:33:23 +0100 Subject: Documentation/powerpc/mpc52xx.txt: Checkpatch cleanup Fix all trailing whitespace errors reported by checkpatch. Signed-off-by: Andrea Gelmini Signed-off-by: Anatolij Gustschin --- Documentation/powerpc/mpc52xx.txt | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/powerpc/mpc52xx.txt b/Documentation/powerpc/mpc52xx.txt index 10dd4ab..0d540a3 100644 --- a/Documentation/powerpc/mpc52xx.txt +++ b/Documentation/powerpc/mpc52xx.txt @@ -2,7 +2,7 @@ Linux 2.6.x on MPC52xx family ----------------------------- For the latest info, go to http://www.246tNt.com/mpc52xx/ - + To compile/use : - U-Boot: @@ -10,23 +10,23 @@ To compile/use : if you wish to ). # make lite5200_defconfig # make uImage - + then, on U-boot: => tftpboot 200000 uImage => tftpboot 400000 pRamdisk => bootm 200000 400000 - + - DBug: # dn -i zImage.initrd.lite5200 - + Some remarks : - The port is named mpc52xxx, and config options are PPC_MPC52xx. The MGT5100 -- cgit v1.1 From 9908ad4cd4bc3e6620e1819e7f9b43f109650e1b Mon Sep 17 00:00:00 2001 From: Jean Delvare Date: Tue, 31 Jan 2012 09:27:11 -0500 Subject: hwmon: (lm80) Add detection of NatSemi/TI LM96080 Add detection of the National Semiconductor (now Texas Instruments) LM96080. It is functionally compatible with the LM80 but detection is completely different. Signed-off-by: Jean Delvare Cc: Guenter Roeck Cc: Frans Meulenbroeks Signed-off-by: Guenter Roeck --- Documentation/hwmon/lm80 | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm80 b/Documentation/hwmon/lm80 index cb5b407..a60b43e 100644 --- a/Documentation/hwmon/lm80 +++ b/Documentation/hwmon/lm80 @@ -7,6 +7,11 @@ Supported chips: Addresses scanned: I2C 0x28 - 0x2f Datasheet: Publicly available at the National Semiconductor website http://www.national.com/ + * National Semiconductor LM96080 + Prefix: 'lm96080' + Addresses scanned: I2C 0x28 - 0x2f + Datasheet: Publicly available at the National Semiconductor website + http://www.national.com/ Authors: Frodo Looijaard , @@ -17,7 +22,9 @@ Description This driver implements support for the National Semiconductor LM80. It is described as a 'Serial Interface ACPI-Compatible Microprocessor -System Hardware Monitor'. +System Hardware Monitor'. The LM96080 is a more recent incarnation, +it is pin and register compatible, with a few additional features not +yet supported by the driver. The LM80 implements one temperature sensor, two fan rotation speed sensors, seven voltage sensors, alarms, and some miscellaneous stuff. -- cgit v1.1 From 56aad5d143cbce620c079e1acf761b71f59758a0 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Fri, 24 Feb 2012 08:13:31 -0800 Subject: hwmon: (max34440) Add support for 'lowest' output voltage attribute MAX34440 and compatibles support reporting the lowest measured output voltage. Add support for it. Signed-off-by: Guenter Roeck Acked-by: Jean Delvare --- Documentation/hwmon/max34440 | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/max34440 b/Documentation/hwmon/max34440 index 8ab5153..36b335c 100644 --- a/Documentation/hwmon/max34440 +++ b/Documentation/hwmon/max34440 @@ -56,6 +56,7 @@ in[1-6]_min_alarm Voltage low alarm. From VOLTAGE_UV_WARNING status. in[1-6]_max_alarm Voltage high alarm. From VOLTAGE_OV_WARNING status. in[1-6]_lcrit_alarm Voltage critical low alarm. From VOLTAGE_UV_FAULT status. in[1-6]_crit_alarm Voltage critical high alarm. From VOLTAGE_OV_FAULT status. +in[1-6]_lowest Historical minimum voltage. in[1-6]_highest Historical maximum voltage. in[1-6]_reset_history Write any value to reset history. -- cgit v1.1 From c5f35c9d8285f4a065cb0fc2c57f7526e646b30f Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Tue, 28 Feb 2012 10:24:54 -0800 Subject: hwmon: (pmbus) Add support for TI TPS40400 and TPS40422 TPS40400 and TPS40422 are supported by the generic PMBus driver. Add device IDs and data sheet references. Signed-off-by: Guenter Roeck --- Documentation/hwmon/pmbus | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus index d28b591..c2b157b 100644 --- a/Documentation/hwmon/pmbus +++ b/Documentation/hwmon/pmbus @@ -22,6 +22,12 @@ Supported chips: http://www.lineagepower.com/oem/pdf/PDT006A0X.pdf http://www.lineagepower.com/oem/pdf/PDT012A0X.pdf http://www.lineagepower.com/oem/pdf/UDT020A0X.pdf + * Texas Instruments TPS40400, TPS40422 + Prefixes: 'tps40400', 'tps40422' + Addresses scanned: - + Datasheets: + http://www.ti.com/lit/gpn/tps40400 + http://www.ti.com/lit/gpn/tps40422 * Generic PMBus devices Prefix: 'pmbus' Addresses scanned: - -- cgit v1.1 From 216334094a875ed350079fb0b1b057ca17eb8b8e Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Tue, 28 Feb 2012 11:00:54 -0800 Subject: hwmon: (pmbus) Add support for Lineage Power MDT040 MDT040 is supported by the generic PMBus driver. Add device ID and reference to datasheet. Also mention Lineage Power device support in Kconfig. Signed-off-by: Guenter Roeck --- Documentation/hwmon/pmbus | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/pmbus b/Documentation/hwmon/pmbus index c2b157b..f90f999 100644 --- a/Documentation/hwmon/pmbus +++ b/Documentation/hwmon/pmbus @@ -15,13 +15,14 @@ Supported chips: http://www.onsemi.com/pub_link/Collateral/NCP4200-D.PDF http://www.onsemi.com/pub_link/Collateral/JUNE%202009-%20REV.%200.PDF * Lineage Power - Prefixes: 'pdt003', 'pdt006', 'pdt012', 'udt020' + Prefixes: 'mdt040', 'pdt003', 'pdt006', 'pdt012', 'udt020' Addresses scanned: - Datasheets: http://www.lineagepower.com/oem/pdf/PDT003A0X.pdf http://www.lineagepower.com/oem/pdf/PDT006A0X.pdf http://www.lineagepower.com/oem/pdf/PDT012A0X.pdf http://www.lineagepower.com/oem/pdf/UDT020A0X.pdf + http://www.lineagepower.com/oem/pdf/MDT040A0X.pdf * Texas Instruments TPS40400, TPS40422 Prefixes: 'tps40400', 'tps40422' Addresses scanned: - -- cgit v1.1 From 590defe59ef9596dcd892d2d8395d730c510323d Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Fri, 24 Feb 2012 03:40:22 -0800 Subject: hwmon: (max34440) Add support for MAX34446 Signed-off-by: Guenter Roeck --- Documentation/hwmon/max34440 | 29 +++++++++++++++++++++++++++-- 1 file changed, 27 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/max34440 b/Documentation/hwmon/max34440 index 36b335c..bbdf9bf 100644 --- a/Documentation/hwmon/max34440 +++ b/Documentation/hwmon/max34440 @@ -11,6 +11,11 @@ Supported chips: Prefixes: 'max34441' Addresses scanned: - Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34441.pdf + * Maxim MAX34446 + PMBus Power-Supply Data Logger + Prefixes: 'max34446' + Addresses scanned: - + Datasheet: http://datasheets.maxim-ic.com/en/ds/MAX34446.pdf Author: Guenter Roeck @@ -19,8 +24,8 @@ Description ----------- This driver supports hardware montoring for Maxim MAX34440 PMBus 6-Channel -Power-Supply Manager and MAX34441 PMBus 5-Channel Power-Supply Manager -and Intelligent Fan Controller. +Power-Supply Manager, MAX34441 PMBus 5-Channel Power-Supply Manager +and Intelligent Fan Controller, and MAX34446 PMBus Power-Supply Data Logger. The driver is a client driver to the core PMBus driver. Please see Documentation/hwmon/pmbus for details on PMBus client drivers. @@ -33,6 +38,13 @@ This driver does not auto-detect devices. You will have to instantiate the devices explicitly. Please see Documentation/i2c/instantiating-devices for details. +For MAX34446, the value of the currX_crit attribute determines if current or +voltage measurement is enabled for a given channel. Voltage measurement is +enabled if currX_crit is set to 0; current measurement is enabled if the +attribute is set to a positive value. Power measurement is only enabled if +channel 1 (3) is configured for voltage measurement, and channel 2 (4) is +configured for current measurement. + Platform data support --------------------- @@ -60,16 +72,27 @@ in[1-6]_lowest Historical minimum voltage. in[1-6]_highest Historical maximum voltage. in[1-6]_reset_history Write any value to reset history. + MAX34446 only supports in[1-4]. + curr[1-6]_label "iout[1-6]". curr[1-6]_input Measured current. From READ_IOUT register. curr[1-6]_max Maximum current. From IOUT_OC_WARN_LIMIT register. curr[1-6]_crit Critical maximum current. From IOUT_OC_FAULT_LIMIT register. curr[1-6]_max_alarm Current high alarm. From IOUT_OC_WARNING status. curr[1-6]_crit_alarm Current critical high alarm. From IOUT_OC_FAULT status. +curr[1-4]_average Historical average current (MAX34446 only). curr[1-6]_highest Historical maximum current. curr[1-6]_reset_history Write any value to reset history. in6 and curr6 attributes only exist for MAX34440. + MAX34446 only supports curr[1-4]. + +power[1,3]_label "pout[1,3]" +power[1,3]_input Measured power. +power[1,3]_average Historical average power. +power[1,3]_highest Historical maximum power. + + Power attributes only exist for MAX34446. temp[1-8]_input Measured temperatures. From READ_TEMPERATURE_1 register. temp1 is the chip's internal temperature. temp2..temp5 @@ -80,7 +103,9 @@ temp[1-8]_max Maximum temperature. From OT_WARN_LIMIT register. temp[1-8]_crit Critical high temperature. From OT_FAULT_LIMIT register. temp[1-8]_max_alarm Temperature high alarm. temp[1-8]_crit_alarm Temperature critical high alarm. +temp[1-8]_average Historical average temperature (MAX34446 only). temp[1-8]_highest Historical maximum temperature. temp[1-8]_reset_history Write any value to reset history. temp7 and temp8 attributes only exist for MAX34440. + MAX34446 only supports temp[1-3]. -- cgit v1.1 From 927112696654f4c96a85aa8a494866cbc6ccfbe6 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Fri, 24 Feb 2012 03:40:53 -0800 Subject: hwmon: (adm1275) Add support for ADM1075 Signed-off-by: Guenter Roeck --- Documentation/hwmon/adm1275 | 30 +++++++++++++++++++++++------- 1 file changed, 23 insertions(+), 7 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/adm1275 b/Documentation/hwmon/adm1275 index ab70d96..535ad23 100644 --- a/Documentation/hwmon/adm1275 +++ b/Documentation/hwmon/adm1275 @@ -2,6 +2,10 @@ Kernel driver adm1275 ===================== Supported chips: + * Analog Devices ADM1075 + Prefix: 'adm1075' + Addresses scanned: - + Datasheet: www.analog.com/static/imported-files/data_sheets/ADM1075.pdf * Analog Devices ADM1275 Prefix: 'adm1275' Addresses scanned: - @@ -17,13 +21,13 @@ Author: Guenter Roeck Description ----------- -This driver supports hardware montoring for Analog Devices ADM1275 and ADM1276 -Hot-Swap Controller and Digital Power Monitor. +This driver supports hardware montoring for Analog Devices ADM1075, ADM1275, +and ADM1276 Hot-Swap Controller and Digital Power Monitor. -ADM1275 and ADM1276 are hot-swap controllers that allow a circuit board to be -removed from or inserted into a live backplane. They also feature current and -voltage readback via an integrated 12-bit analog-to-digital converter (ADC), -accessed using a PMBus interface. +ADM1075, ADM1275, and ADM1276 are hot-swap controllers that allow a circuit +board to be removed from or inserted into a live backplane. They also feature +current and voltage readback via an integrated 12-bit analog-to-digital +converter (ADC), accessed using a PMBus interface. The driver is a client driver to the core PMBus driver. Please see Documentation/hwmon/pmbus for details on PMBus client drivers. @@ -36,6 +40,10 @@ This driver does not auto-detect devices. You will have to instantiate the devices explicitly. Please see Documentation/i2c/instantiating-devices for details. +The ADM1075, unlike many other PMBus devices, does not support internal voltage +or current scaling. Reported voltages, currents, and power are raw measurements, +and will typically have to be scaled. + Platform data support --------------------- @@ -51,7 +59,8 @@ The following attributes are supported. Limits are read-write, history reset attributes are write-only, all other attributes are read-only. in1_label "vin1" or "vout1" depending on chip variant and - configuration. + configuration. On ADM1075, vout1 reports the voltage on + the VAUX pin. in1_input Measured voltage. in1_min Minumum Voltage. in1_max Maximum voltage. @@ -74,3 +83,10 @@ curr1_crit Critical maximum current. Depending on the chip curr1_crit_alarm Critical current high alarm. curr1_highest Historical maximum current. curr1_reset_history Write any value to reset history. + +power1_label "pin1" +power1_input Input power. +power1_reset_history Write any value to reset history. + + Power attributes are supported on ADM1075 and ADM1276 + only. -- cgit v1.1 From 3360a106f8b4f87d3f3b0f1fd06c0c66fe45a87b Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Tue, 28 Feb 2012 13:18:47 -0800 Subject: hwmon: (zl6100) Add support for ZL9101M and ZL9117M ZL9101M and ZL9117M are compatible to ZL6100. Add support to the zl6100 driver. Signed-off-by: Guenter Roeck Acked-by: Jean Delvare --- Documentation/hwmon/zl6100 | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/zl6100 b/Documentation/hwmon/zl6100 index a4e8d90..2028c0a 100644 --- a/Documentation/hwmon/zl6100 +++ b/Documentation/hwmon/zl6100 @@ -34,6 +34,14 @@ Supported chips: Prefix: 'zl6105' Addresses scanned: - Datasheet: http://www.intersil.com/data/fn/fn6906.pdf + * Intersil / Zilker Labs ZL9101M + Prefix: 'zl9101' + Addresses scanned: - + Datasheet: http://www.intersil.com/data/fn/fn7669.pdf + * Intersil / Zilker Labs ZL9117M + Prefix: 'zl9117' + Addresses scanned: - + Datasheet: http://www.intersil.com/data/fn/fn7914.pdf * Ericsson BMR450, BMR451 Prefix: 'bmr450', 'bmr451' Addresses scanned: - -- cgit v1.1 From 86dda176344314526c7b65f1adce937b09d04f6d Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Thu, 8 Mar 2012 08:20:24 -0800 Subject: hwmon: (jc42) Remove unnecessary device IDs We don't really use or need separate device IDs for the various JC42.4 compliant chips, so remove them and just stick with jc42. Also update a datasheet references for SE98A, STTS424, and STTS424E02. Signed-off-by: Guenter Roeck Acked-by: Jean Delvare --- Documentation/hwmon/jc42 | 39 +++++++++------------------------------ 1 file changed, 9 insertions(+), 30 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/jc42 b/Documentation/hwmon/jc42 index 52729a7..66ecb9f 100644 --- a/Documentation/hwmon/jc42 +++ b/Documentation/hwmon/jc42 @@ -3,71 +3,50 @@ Kernel driver jc42 Supported chips: * Analog Devices ADT7408 - Prefix: 'adt7408' - Addresses scanned: I2C 0x18 - 0x1f Datasheets: http://www.analog.com/static/imported-files/data_sheets/ADT7408.pdf * Atmel AT30TS00 - Prefix: 'at30ts00' - Addresses scanned: I2C 0x18 - 0x1f Datasheets: http://www.atmel.com/Images/doc8585.pdf * IDT TSE2002B3, TSE2002GB2, TS3000B3, TS3000GB2 - Prefix: 'tse2002', 'ts3000' - Addresses scanned: I2C 0x18 - 0x1f Datasheets: http://www.idt.com/sites/default/files/documents/IDT_TSE2002B3C_DST_20100512_120303152056.pdf http://www.idt.com/sites/default/files/documents/IDT_TSE2002GB2A1_DST_20111107_120303145914.pdf http://www.idt.com/sites/default/files/documents/IDT_TS3000B3A_DST_20101129_120303152013.pdf http://www.idt.com/sites/default/files/documents/IDT_TS3000GB2A1_DST_20111104_120303151012.pdf * Maxim MAX6604 - Prefix: 'max6604' - Addresses scanned: I2C 0x18 - 0x1f Datasheets: http://datasheets.maxim-ic.com/en/ds/MAX6604.pdf * Microchip MCP9804, MCP9805, MCP98242, MCP98243, MCP9843 - Prefixes: 'mcp9804', 'mcp9805', 'mcp98242', 'mcp98243', 'mcp9843' - Addresses scanned: I2C 0x18 - 0x1f Datasheets: http://ww1.microchip.com/downloads/en/DeviceDoc/22203C.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/21977b.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/21996a.pdf http://ww1.microchip.com/downloads/en/DeviceDoc/22153c.pdf - * NXP Semiconductors SE97, SE97B - Prefix: 'se97' - Addresses scanned: I2C 0x18 - 0x1f + * NXP Semiconductors SE97, SE97B, SE98, SE98A Datasheets: http://www.nxp.com/documents/data_sheet/SE97.pdf http://www.nxp.com/documents/data_sheet/SE97B.pdf - * NXP Semiconductors SE98 - Prefix: 'se98' - Addresses scanned: I2C 0x18 - 0x1f - Datasheets: http://www.nxp.com/documents/data_sheet/SE98.pdf + http://www.nxp.com/documents/data_sheet/SE98A.pdf * ON Semiconductor CAT34TS02, CAT6095 - Prefix: 'cat34ts02', 'cat6095' - Addresses scanned: I2C 0x18 - 0x1f Datasheet: http://www.onsemi.com/pub_link/Collateral/CAT34TS02-D.PDF http://www.onsemi.com/pub/Collateral/CAT6095-D.PDF - * ST Microelectronics STTS424, STTS424E02 - Prefix: 'stts424' - Addresses scanned: I2C 0x18 - 0x1f - Datasheets: - http://www.st.com/stonline/products/literature/ds/13447/stts424.pdf - http://www.st.com/stonline/products/literature/ds/13448/stts424e02.pdf - * ST Microelectronics STTS2002, STTS3000 - Prefix: 'stts2002', 'stts3000' - Addresses scanned: I2C 0x18 - 0x1f + * ST Microelectronics STTS424, STTS424E02, STTS2002, STTS3000 Datasheets: + http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157556.pdf + http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00157558.pdf http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATASHEET/CD00225278.pdf http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/DATA_BRIEF/CD00270920.pdf * JEDEC JC 42.4 compliant temperature sensor chips - Prefix: 'jc42' - Addresses scanned: I2C 0x18 - 0x1f Datasheet: http://www.jedec.org/sites/default/files/docs/4_01_04R19.pdf + Common for all chips: + Prefix: 'jc42' + Addresses scanned: I2C 0x18 - 0x1f + Author: Guenter Roeck -- cgit v1.1 From 5e8e19bf6c3c9d8ecf74e2a7fdae99a76949bdf6 Mon Sep 17 00:00:00 2001 From: Borislav Petkov Date: Wed, 21 Sep 2011 14:10:43 +0200 Subject: EDAC: Correct scrub rate API The original scrub rate API definition states that if scrub rate accessors are not implemented, a negative value (-1) should be written to the sysfs file (/sys/devices/system/edac/mc/mc/sdram_scrub_rate, where N is the memory controller number on the system). This is counter-intuitive and awkward at the very least because, when setting the scrub rate, userspace has to write to sysfs and then read it back to check error status of the operation. As Tony notes, best it would be to not have the sdram_scrub_rate in sysfs if scrub rate support is not implemented. It is too late about that and a bunch of drivers on a bunch of arches would need to be changed and tested which is not a trivial task ATM. Instead, settle for the next best thing of returning -ENODEV when implementation is missing and -EINVAL when there was an error encountered while setting the scrub rate. Reported-by: Han Pingtian Cc: Tony Luck Link: http://lkml.kernel.org/r/20110916105856.GA13253@hpt.nay.redhat.com Signed-off-by: Borislav Petkov --- Documentation/edac.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/edac.txt b/Documentation/edac.txt index 249822c..fdcc49f 100644 --- a/Documentation/edac.txt +++ b/Documentation/edac.txt @@ -334,8 +334,8 @@ Sdram memory scrubbing rate: Reading the file will return the actual scrubbing rate employed. - If configuration fails or memory scrubbing is not implemented, the value - of the attribute file will be -1. + If configuration fails or memory scrubbing is not implemented, accessing + that attribute will fail. -- cgit v1.1 From 9d1721733038bda56c38e1e0807885a85f08d7a7 Mon Sep 17 00:00:00 2001 From: Hans Verkuil Date: Mon, 27 Feb 2012 05:36:38 -0300 Subject: [media] V4L2 Spec: return -EINVAL on unsupported wrap_around value This is a small extension to the S_HW_FREQ_SEEK ioctl: if the wrap_around value is not support by the hardware, then -EINVAL is returned. Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml index e013da8..18b1a82 100644 --- a/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml +++ b/Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml @@ -96,8 +96,8 @@ field and the &v4l2-tuner; index field. __u32 reserved[7] - Reserved for future extensions. Drivers and - applications must set the array to zero. + Reserved for future extensions. Applications + must set the array to zero. @@ -112,7 +112,7 @@ field and the &v4l2-tuner; index field. EINVAL The tuner index is out of -bounds or the value in the type field is +bounds, the wrap_around value is not supported or the value in the type field is wrong. -- cgit v1.1 From aa2e682a48ab96c27772c523a20e03850819afa1 Mon Sep 17 00:00:00 2001 From: Malcolm Priestley Date: Wed, 7 Mar 2012 18:17:59 -0300 Subject: [media] lmedm04 RS2000 Firmware details Signed-off-by: Malcolm Priestley Signed-off-by: Mauro Carvalho Chehab --- Documentation/dvb/lmedm04.txt | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'Documentation') diff --git a/Documentation/dvb/lmedm04.txt b/Documentation/dvb/lmedm04.txt index 10b5f04..f4b720a 100644 --- a/Documentation/dvb/lmedm04.txt +++ b/Documentation/dvb/lmedm04.txt @@ -66,5 +66,16 @@ dd if=US290D.sys ibs=1 skip=36856 count=3976 of=dvb-usb-lme2510-s0194.fw For LME2510C dd if=US290D.sys ibs=1 skip=33152 count=3697 of=dvb-usb-lme2510c-s0194.fw +--------------------------------------------------------------------- + +The m88rs2000 tuner driver can be found in windows/system32/drivers + +US2B0D.sys (dated 29 Jun 2010) + +dd if=US2B0D.sys ibs=1 skip=34432 count=3871 of=dvb-usb-lme2510c-rs2000.fw + +We need to modify id of rs2000 firmware or it will warm boot id 3344:1120. + +echo -ne \\xF0\\x22 | dd conv=notrunc bs=1 count=2 seek=266 of=dvb-usb-lme2510c-rs2000.fw Copy the firmware file(s) to /lib/firmware -- cgit v1.1 From 9080d5d3fa9888facd6898c6705b1a6713882955 Mon Sep 17 00:00:00 2001 From: Sylwester Nawrocki Date: Fri, 9 Mar 2012 06:46:28 -0300 Subject: [media] V4L: Improve the selection API documentation Make the VIDIOC_G/S_SELECTION ioctls documentation more consistent with the rest of media Docbook, use capital letters where necessary and correct few minor errors. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park Signed-off-by: Mauro Carvalho Chehab --- Documentation/DocBook/media/v4l/selection-api.xml | 8 +- .../DocBook/media/v4l/vidioc-g-selection.xml | 106 +++++++++++---------- 2 files changed, 61 insertions(+), 53 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/media/v4l/selection-api.xml b/Documentation/DocBook/media/v4l/selection-api.xml index 2f0bdb4..b299e47 100644 --- a/Documentation/DocBook/media/v4l/selection-api.xml +++ b/Documentation/DocBook/media/v4l/selection-api.xml @@ -52,6 +52,10 @@ cropping and composing rectangles have the same size. + +For complete list of the available selection targets see table +
@@ -186,7 +190,7 @@ V4L2_SEL_TGT_COMPOSE_ACTIVE target.
- Scaling control. + Scaling control An application can detect if scaling is performed by comparing the width and the height of rectangles obtained using V4L2_SEL_TGT_CROP_ACTIVE @@ -200,7 +204,7 @@ the scaling ratios using these values.
- Comparison with old cropping API. + Comparison with old cropping API The selection API was introduced to cope with deficiencies of previous API , that was designed to control simple capture diff --git a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml index a9d36e0..bb04eff 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-selection.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-selection.xml @@ -58,43 +58,43 @@ The ioctls are used to query and configure selection rectangles. - To query the cropping (composing) rectangle set -&v4l2-selection;::type to the respective buffer type. Do not -use multiplanar buffers. Use V4L2_BUF_TYPE_VIDEO_CAPTURE + To query the cropping (composing) rectangle set &v4l2-selection; + type field to the respective buffer type. +Do not use multiplanar buffers. Use V4L2_BUF_TYPE_VIDEO_CAPTURE instead of V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE . Use V4L2_BUF_TYPE_VIDEO_OUTPUT instead of V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE . The next step is -setting &v4l2-selection;::target to value - V4L2_SEL_TGT_CROP_ACTIVE ( +setting the value of &v4l2-selection; target field +to V4L2_SEL_TGT_CROP_ACTIVE ( V4L2_SEL_TGT_COMPOSE_ACTIVE ). Please refer to table or for additional -targets. Fields &v4l2-selection;::flags and - &v4l2-selection;::reserved are ignored and they -must be filled with zeros. The driver fills the rest of the structure or +targets. The flags and reserved + fields of &v4l2-selection; are ignored and they must be filled +with zeros. The driver fills the rest of the structure or returns &EINVAL; if incorrect buffer type or target was used. If cropping (composing) is not supported then the active rectangle is not mutable and it is -always equal to the bounds rectangle. Finally, structure -&v4l2-selection;::r is filled with the current cropping +always equal to the bounds rectangle. Finally, the &v4l2-rect; +r rectangle is filled with the current cropping (composing) coordinates. The coordinates are expressed in driver-dependent units. The only exception are rectangles for images in raw formats, whose coordinates are always expressed in pixels. - To change the cropping (composing) rectangle set -&v4l2-selection;::type to the respective buffer type. Do not + To change the cropping (composing) rectangle set the &v4l2-selection; +type field to the respective buffer type. Do not use multiplanar buffers. Use V4L2_BUF_TYPE_VIDEO_CAPTURE instead of V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE . Use V4L2_BUF_TYPE_VIDEO_OUTPUT instead of V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE . The next step is -setting &v4l2-selection;::target to value - V4L2_SEL_TGT_CROP_ACTIVE ( +setting the value of &v4l2-selection; target to +V4L2_SEL_TGT_CROP_ACTIVE ( V4L2_SEL_TGT_COMPOSE_ACTIVE ). Please refer to table or for additional -targets. Set desired active area into the field -&v4l2-selection;::r . Field -&v4l2-selection;::reserved is ignored and must be filled with -zeros. The driver may adjust the rectangle coordinates. An application may -introduce constraints to control rounding behaviour. Set the field - &v4l2-selection;::flags to one of values: +targets. The &v4l2-rect; r rectangle need to be +set to the desired active area. Field &v4l2-selection; reserved + is ignored and must be filled with zeros. The driver may adjust +coordinates of the requested rectangle. An application may +introduce constraints to control rounding behaviour. The &v4l2-selection; +flags field must be set to one of the following: @@ -129,7 +129,7 @@ and vertical offset and sizes are chosen according to following priority: - Satisfy constraints from &v4l2-selection;::flags. + Satisfy constraints from &v4l2-selection; flags. Adjust width, height, left, and top to hardware limits and alignments. @@ -145,7 +145,7 @@ and vertical offset and sizes are chosen according to following priority: -On success the field &v4l2-selection;::r contains +On success the &v4l2-rect; r field contains the adjusted rectangle. When the parameters are unsuitable the application may modify the cropping (composing) or image parameters and repeat the cycle until satisfactory parameters have been negotiated. If constraints flags have to be @@ -162,38 +162,38 @@ exist no rectangle that satisfies the constraints. V4L2_SEL_TGT_CROP_ACTIVE - 0 - area that is currently cropped by hardware + 0x0000 + The area that is currently cropped by hardware. V4L2_SEL_TGT_CROP_DEFAULT - 1 - suggested cropping rectangle that covers the "whole picture" + 0x0001 + Suggested cropping rectangle that covers the "whole picture". V4L2_SEL_TGT_CROP_BOUNDS - 2 - limits for the cropping rectangle + 0x0002 + Limits for the cropping rectangle. V4L2_SEL_TGT_COMPOSE_ACTIVE - 256 - area to which data are composed by hardware + 0x0100 + The area to which data is composed by hardware. V4L2_SEL_TGT_COMPOSE_DEFAULT - 257 - suggested composing rectangle that covers the "whole picture" + 0x0101 + Suggested composing rectangle that covers the "whole picture". V4L2_SEL_TGT_COMPOSE_BOUNDS - 258 - limits for the composing rectangle + 0x0102 + Limits for the composing rectangle. V4L2_SEL_TGT_COMPOSE_PADDED - 259 - the active area and all padding pixels that are inserted or modified by the hardware + 0x0103 + The active area and all padding pixels that are inserted or modified by hardware. @@ -209,12 +209,14 @@ exist no rectangle that satisfies the constraints. V4L2_SEL_FLAG_GE 0x00000001 - indicate that adjusted rectangle must contain a rectangle from &v4l2-selection;::r + Indicates that the adjusted rectangle must contain the original + &v4l2-selection; r rectangle. V4L2_SEL_FLAG_LE 0x00000002 - indicate that adjusted rectangle must be inside a rectangle from &v4l2-selection;::r + Indicates that the adjusted rectangle must be inside the original + &v4l2-rect; r rectangle. @@ -245,27 +247,29 @@ exist no rectangle that satisfies the constraints. __u32 type - Type of the buffer (from &v4l2-buf-type;) + Type of the buffer (from &v4l2-buf-type;). __u32 target - used to select between cropping and composing rectangles + Used to select between cropping + and composing rectangles. __u32 flags - control over coordinates adjustments, refer to selection flags + Flags controlling the selection rectangle adjustments, refer to + selection flags. &v4l2-rect; r - selection rectangle + The selection rectangle. __u32 reserved[9] - Reserved fields for future use + Reserved fields for future use. @@ -278,24 +282,24 @@ exist no rectangle that satisfies the constraints. EINVAL - The buffer &v4l2-selection;::type -or &v4l2-selection;::target is not supported, or -the &v4l2-selection;::flags are invalid. + Given buffer type type or +the selection target target is not supported, +or the flags argument is not valid. ERANGE - it is not possible to adjust a rectangle -&v4l2-selection;::r that satisfies all contraints from - &v4l2-selection;::flags . + It is not possible to adjust &v4l2-rect; +r rectangle to satisfy all contraints given in the +flags argument. EBUSY - it is not possible to apply change of selection rectangle at the moment. -Usually because streaming is in progress. + It is not possible to apply change of the selection rectangle +at the moment. Usually because streaming is in progress. -- cgit v1.1 From f92c97c8bd77992ff8bd6ef29a23dc82dca799cb Mon Sep 17 00:00:00 2001 From: Mauro Carvalho Chehab Date: Mon, 19 Mar 2012 23:12:02 -0300 Subject: [media] update CARDLIST.em28xx Add the new DRX-K based devices there. Signed-off-by: Mauro Carvalho Chehab --- Documentation/video4linux/CARDLIST.em28xx | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/video4linux/CARDLIST.em28xx b/Documentation/video4linux/CARDLIST.em28xx index 6f69b05..d99262d 100644 --- a/Documentation/video4linux/CARDLIST.em28xx +++ b/Documentation/video4linux/CARDLIST.em28xx @@ -81,3 +81,6 @@ 81 -> Hauppauge WinTV HVR 930C (em2884) [2040:1605] 82 -> Terratec Cinergy HTC Stick (em2884) [0ccd:00b2] 83 -> Honestech Vidbox NW03 (em2860) [eb1a:5006] + 84 -> MaxMedia UB425-TC (em2874) [1b80:e425] + 85 -> PCTV QuatroStick (510e) (em2884) [2304:0242] + 86 -> PCTV QuatroStick nano (520e) (em2884) [2013:0251] -- cgit v1.1 From da0df92b57311aa1b26a2a90599ed16e1e968b90 Mon Sep 17 00:00:00 2001 From: Carsten Emde Date: Sun, 18 Mar 2012 22:37:33 +0100 Subject: drm: allow loading an EDID as firmware to override broken monitor Broken monitors and/or broken graphic boards may send erroneous or no EDID data. This also applies to broken KVM devices that are unable to correctly forward the EDID data of the connected monitor but invent their own fantasy data. This patch allows to specify an EDID data set to be used instead of probing the monitor for it. It contains built-in data sets of frequently used screen resolutions. In addition, a particular EDID data set may be provided in the /lib/firmware directory and loaded via the firmware interface. The name is passed to the kernel as module parameter of the drm_kms_helper module either when loaded options drm_kms_helper edid_firmware=edid/1280x1024.bin or as kernel commandline parameter drm_kms_helper.edid_firmware=edid/1280x1024.bin It is also possible to restrict the usage of a specified EDID data set to a particular connector. This is done by prepending the name of the connector to the name of the EDID data set using the syntax edid_firmware=[:] such as, for example, edid_firmware=DVI-I-1:edid/1920x1080.bin in which case no other connector will be affected. The built-in data sets are Resolution Name -------------------------------- 1024x768 edid/1024x768.bin 1280x1024 edid/1280x1024.bin 1680x1050 edid/1680x1050.bin 1920x1080 edid/1920x1080.bin They are ignored, if a file with the same name is available in the /lib/firmware directory. The built-in EDID data sets are based on standard timings that may not apply to a particular monitor and even crash it. Ideally, EDID data of the connected monitor should be used. They may be obtained through the drm/cardX/cardX-/edid entry in the /sys/devices PCI directory of a correctly working graphics adapter. It is even possible to specify the name of an EDID data set on-the-fly via the /sys/module interface, e.g. echo edid/myedid.bin >/sys/module/drm_kms_helper/parameters/edid_firmware The new screen mode is considered when the related kernel function is called for the first time after the change. Such calls are made when the X server is started or when the display settings dialog is opened in an already running X server. Signed-off-by: Carsten Emde Signed-off-by: Dave Airlie --- Documentation/EDID/1024x768.S | 44 ++++++ Documentation/EDID/1280x1024.S | 44 ++++++ Documentation/EDID/1680x1050.S | 44 ++++++ Documentation/EDID/1920x1080.S | 44 ++++++ Documentation/EDID/HOWTO.txt | 39 ++++++ Documentation/EDID/Makefile | 26 ++++ Documentation/EDID/edid.S | 261 ++++++++++++++++++++++++++++++++++++ Documentation/EDID/hex | 1 + Documentation/kernel-parameters.txt | 15 +++ 9 files changed, 518 insertions(+) create mode 100644 Documentation/EDID/1024x768.S create mode 100644 Documentation/EDID/1280x1024.S create mode 100644 Documentation/EDID/1680x1050.S create mode 100644 Documentation/EDID/1920x1080.S create mode 100644 Documentation/EDID/HOWTO.txt create mode 100644 Documentation/EDID/Makefile create mode 100644 Documentation/EDID/edid.S create mode 100644 Documentation/EDID/hex (limited to 'Documentation') diff --git a/Documentation/EDID/1024x768.S b/Documentation/EDID/1024x768.S new file mode 100644 index 0000000..4b486fe --- /dev/null +++ b/Documentation/EDID/1024x768.S @@ -0,0 +1,44 @@ +/* + 1024x768.S: EDID data set for standard 1024x768 60 Hz monitor + + Copyright (C) 2011 Carsten Emde + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version 2 + of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +*/ + +/* EDID */ +#define VERSION 1 +#define REVISION 3 + +/* Display */ +#define CLOCK 65000 /* kHz */ +#define XPIX 1024 +#define YPIX 768 +#define XY_RATIO XY_RATIO_4_3 +#define XBLANK 320 +#define YBLANK 38 +#define XOFFSET 8 +#define XPULSE 144 +#define YOFFSET (63+3) +#define YPULSE (63+6) +#define DPI 72 +#define VFREQ 60 /* Hz */ +#define TIMING_NAME "Linux XGA" +#define ESTABLISHED_TIMINGS_BITS 0x08 /* Bit 3 -> 1024x768 @60 Hz */ +#define HSYNC_POL 0 +#define VSYNC_POL 0 +#define CRC 0x55 + +#include "edid.S" diff --git a/Documentation/EDID/1280x1024.S b/Documentation/EDID/1280x1024.S new file mode 100644 index 0000000..a2799fe --- /dev/null +++ b/Documentation/EDID/1280x1024.S @@ -0,0 +1,44 @@ +/* + 1280x1024.S: EDID data set for standard 1280x1024 60 Hz monitor + + Copyright (C) 2011 Carsten Emde + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version 2 + of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +*/ + +/* EDID */ +#define VERSION 1 +#define REVISION 3 + +/* Display */ +#define CLOCK 108000 /* kHz */ +#define XPIX 1280 +#define YPIX 1024 +#define XY_RATIO XY_RATIO_5_4 +#define XBLANK 408 +#define YBLANK 42 +#define XOFFSET 48 +#define XPULSE 112 +#define YOFFSET (63+1) +#define YPULSE (63+3) +#define DPI 72 +#define VFREQ 60 /* Hz */ +#define TIMING_NAME "Linux SXGA" +#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +#define HSYNC_POL 1 +#define VSYNC_POL 1 +#define CRC 0xa0 + +#include "edid.S" diff --git a/Documentation/EDID/1680x1050.S b/Documentation/EDID/1680x1050.S new file mode 100644 index 0000000..96f67ca --- /dev/null +++ b/Documentation/EDID/1680x1050.S @@ -0,0 +1,44 @@ +/* + 1680x1050.S: EDID data set for standard 1680x1050 60 Hz monitor + + Copyright (C) 2012 Carsten Emde + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version 2 + of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +*/ + +/* EDID */ +#define VERSION 1 +#define REVISION 3 + +/* Display */ +#define CLOCK 146250 /* kHz */ +#define XPIX 1680 +#define YPIX 1050 +#define XY_RATIO XY_RATIO_16_10 +#define XBLANK 560 +#define YBLANK 39 +#define XOFFSET 104 +#define XPULSE 176 +#define YOFFSET (63+3) +#define YPULSE (63+6) +#define DPI 96 +#define VFREQ 60 /* Hz */ +#define TIMING_NAME "Linux WSXGA" +#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +#define HSYNC_POL 1 +#define VSYNC_POL 1 +#define CRC 0x26 + +#include "edid.S" diff --git a/Documentation/EDID/1920x1080.S b/Documentation/EDID/1920x1080.S new file mode 100644 index 0000000..36ed5d5 --- /dev/null +++ b/Documentation/EDID/1920x1080.S @@ -0,0 +1,44 @@ +/* + 1920x1080.S: EDID data set for standard 1920x1080 60 Hz monitor + + Copyright (C) 2012 Carsten Emde + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version 2 + of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +*/ + +/* EDID */ +#define VERSION 1 +#define REVISION 3 + +/* Display */ +#define CLOCK 148500 /* kHz */ +#define XPIX 1920 +#define YPIX 1080 +#define XY_RATIO XY_RATIO_16_9 +#define XBLANK 280 +#define YBLANK 45 +#define XOFFSET 88 +#define XPULSE 44 +#define YOFFSET (63+4) +#define YPULSE (63+5) +#define DPI 96 +#define VFREQ 60 /* Hz */ +#define TIMING_NAME "Linux FHD" +#define ESTABLISHED_TIMINGS_BITS 0x00 /* none */ +#define HSYNC_POL 1 +#define VSYNC_POL 1 +#define CRC 0x05 + +#include "edid.S" diff --git a/Documentation/EDID/HOWTO.txt b/Documentation/EDID/HOWTO.txt new file mode 100644 index 0000000..75a9f2a --- /dev/null +++ b/Documentation/EDID/HOWTO.txt @@ -0,0 +1,39 @@ +In the good old days when graphics parameters were configured explicitly +in a file called xorg.conf, even broken hardware could be managed. + +Today, with the advent of Kernel Mode Setting, a graphics board is +either correctly working because all components follow the standards - +or the computer is unusable, because the screen remains dark after +booting or it displays the wrong area. Cases when this happens are: +- The graphics board does not recognize the monitor. +- The graphics board is unable to detect any EDID data. +- The graphics board incorrectly forwards EDID data to the driver. +- The monitor sends no or bogus EDID data. +- A KVM sends its own EDID data instead of querying the connected monitor. +Adding the kernel parameter "nomodeset" helps in most cases, but causes +restrictions later on. + +As a remedy for such situations, the kernel configuration item +CONFIG_DRM_LOAD_EDID_FIRMWARE was introduced. It allows to provide an +individually prepared or corrected EDID data set in the /lib/firmware +directory from where it is loaded via the firmware interface. The code +(see drivers/gpu/drm/drm_edid_load.c) contains built-in data sets for +commonly used screen resolutions (1024x768, 1280x1024, 1680x1050, +1920x1080) as binary blobs, but the kernel source tree does not contain +code to create these data. In order to elucidate the origin of the +built-in binary EDID blobs and to facilitate the creation of individual +data for a specific misbehaving monitor, commented sources and a +Makefile environment are given here. + +To create binary EDID and C source code files from the existing data +material, simply type "make". + +If you want to create your own EDID file, copy the file 1024x768.S and +replace the settings with your own data. The CRC value in the last line + #define CRC 0x55 +is a bit tricky. After a first version of the binary data set is +created, it must be be checked with the "edid-decode" utility which will +most probably complain about a wrong CRC. Fortunately, the utility also +displays the correct CRC which must then be inserted into the source +file. After the make procedure is repeated, the EDID data set is ready +to be used. diff --git a/Documentation/EDID/Makefile b/Documentation/EDID/Makefile new file mode 100644 index 0000000..17763ca --- /dev/null +++ b/Documentation/EDID/Makefile @@ -0,0 +1,26 @@ + +SOURCES := $(wildcard [0-9]*x[0-9]*.S) + +BIN := $(patsubst %.S, %.bin, $(SOURCES)) + +IHEX := $(patsubst %.S, %.bin.ihex, $(SOURCES)) + +CODE := $(patsubst %.S, %.c, $(SOURCES)) + +all: $(BIN) $(IHEX) $(CODE) + +clean: + @rm -f *.o *.bin.ihex *.bin *.c + +%.o: %.S + @cc -c $^ + +%.bin: %.o + @objcopy -Obinary $^ $@ + +%.bin.ihex: %.o + @objcopy -Oihex $^ $@ + @dos2unix $@ 2>/dev/null + +%.c: %.bin + @echo "{" >$@; hexdump -f hex $^ >>$@; echo "};" >>$@ diff --git a/Documentation/EDID/edid.S b/Documentation/EDID/edid.S new file mode 100644 index 0000000..ea97ae2 --- /dev/null +++ b/Documentation/EDID/edid.S @@ -0,0 +1,261 @@ +/* + edid.S: EDID data template + + Copyright (C) 2012 Carsten Emde + + This program is free software; you can redistribute it and/or + modify it under the terms of the GNU General Public License + as published by the Free Software Foundation; either version 2 + of the License, or (at your option) any later version. + + This program is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this program; if not, write to the Free Software + Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. +*/ + + +/* Manufacturer */ +#define MFG_LNX1 'L' +#define MFG_LNX2 'N' +#define MFG_LNX3 'X' +#define SERIAL 0 +#define YEAR 2012 +#define WEEK 5 + +/* EDID 1.3 standard definitions */ +#define XY_RATIO_16_10 0b00 +#define XY_RATIO_4_3 0b01 +#define XY_RATIO_5_4 0b10 +#define XY_RATIO_16_9 0b11 + +#define mfgname2id(v1,v2,v3) \ + ((((v1-'@')&0x1f)<<10)+(((v2-'@')&0x1f)<<5)+((v3-'@')&0x1f)) +#define swap16(v1) ((v1>>8)+((v1&0xff)<<8)) +#define msbs2(v1,v2) ((((v1>>8)&0x0f)<<4)+((v2>>8)&0x0f)) +#define msbs4(v1,v2,v3,v4) \ + (((v1&0x03)>>2)+((v2&0x03)>>4)+((v3&0x03)>>6)+((v4&0x03)>>8)) +#define pixdpi2mm(pix,dpi) ((pix*25)/dpi) +#define xsize pixdpi2mm(XPIX,DPI) +#define ysize pixdpi2mm(YPIX,DPI) + + .data + +/* Fixed header pattern */ +header: .byte 0x00,0xff,0xff,0xff,0xff,0xff,0xff,0x00 + +mfg_id: .word swap16(mfgname2id(MFG_LNX1, MFG_LNX2, MFG_LNX3)) + +prod_code: .word 0 + +/* Serial number. 32 bits, little endian. */ +serial_number: .long SERIAL + +/* Week of manufacture */ +week: .byte WEEK + +/* Year of manufacture, less 1990. (1990-2245) + If week=255, it is the model year instead */ +year: .byte YEAR-1990 + +version: .byte VERSION /* EDID version, usually 1 (for 1.3) */ +revision: .byte REVISION /* EDID revision, usually 3 (for 1.3) */ + +/* If Bit 7=1 Digital input. If set, the following bit definitions apply: + Bits 6-1 Reserved, must be 0 + Bit 0 Signal is compatible with VESA DFP 1.x TMDS CRGB, + 1 pixel per clock, up to 8 bits per color, MSB aligned, + If Bit 7=0 Analog input. If clear, the following bit definitions apply: + Bits 6-5 Video white and sync levels, relative to blank + 00=+0.7/-0.3 V; 01=+0.714/-0.286 V; + 10=+1.0/-0.4 V; 11=+0.7/0 V + Bit 4 Blank-to-black setup (pedestal) expected + Bit 3 Separate sync supported + Bit 2 Composite sync (on HSync) supported + Bit 1 Sync on green supported + Bit 0 VSync pulse must be serrated when somposite or + sync-on-green is used. */ +video_parms: .byte 0x6d + +/* Maximum horizontal image size, in centimetres + (max 292 cm/115 in at 16:9 aspect ratio) */ +max_hor_size: .byte xsize/10 + +/* Maximum vertical image size, in centimetres. + If either byte is 0, undefined (e.g. projector) */ +max_vert_size: .byte ysize/10 + +/* Display gamma, minus 1, times 100 (range 1.00-3.5 */ +gamma: .byte 120 + +/* Bit 7 DPMS standby supported + Bit 6 DPMS suspend supported + Bit 5 DPMS active-off supported + Bits 4-3 Display type: 00=monochrome; 01=RGB colour; + 10=non-RGB multicolour; 11=undefined + Bit 2 Standard sRGB colour space. Bytes 25-34 must contain + sRGB standard values. + Bit 1 Preferred timing mode specified in descriptor block 1. + Bit 0 GTF supported with default parameter values. */ +dsp_features: .byte 0xea + +/* Chromaticity coordinates. */ +/* Red and green least-significant bits + Bits 7-6 Red x value least-significant 2 bits + Bits 5-4 Red y value least-significant 2 bits + Bits 3-2 Green x value lst-significant 2 bits + Bits 1-0 Green y value least-significant 2 bits */ +red_green_lsb: .byte 0x5e + +/* Blue and white least-significant 2 bits */ +blue_white_lsb: .byte 0xc0 + +/* Red x value most significant 8 bits. + 0-255 encodes 0-0.996 (255/256); 0-0.999 (1023/1024) with lsbits */ +red_x_msb: .byte 0xa4 + +/* Red y value most significant 8 bits */ +red_y_msb: .byte 0x59 + +/* Green x and y value most significant 8 bits */ +green_x_y_msb: .byte 0x4a,0x98 + +/* Blue x and y value most significant 8 bits */ +blue_x_y_msb: .byte 0x25,0x20 + +/* Default white point x and y value most significant 8 bits */ +white_x_y_msb: .byte 0x50,0x54 + +/* Established timings */ +/* Bit 7 720x400 @ 70 Hz + Bit 6 720x400 @ 88 Hz + Bit 5 640x480 @ 60 Hz + Bit 4 640x480 @ 67 Hz + Bit 3 640x480 @ 72 Hz + Bit 2 640x480 @ 75 Hz + Bit 1 800x600 @ 56 Hz + Bit 0 800x600 @ 60 Hz */ +estbl_timing1: .byte 0x00 + +/* Bit 7 800x600 @ 72 Hz + Bit 6 800x600 @ 75 Hz + Bit 5 832x624 @ 75 Hz + Bit 4 1024x768 @ 87 Hz, interlaced (1024x768) + Bit 3 1024x768 @ 60 Hz + Bit 2 1024x768 @ 72 Hz + Bit 1 1024x768 @ 75 Hz + Bit 0 1280x1024 @ 75 Hz */ +estbl_timing2: .byte ESTABLISHED_TIMINGS_BITS + +/* Bit 7 1152x870 @ 75 Hz (Apple Macintosh II) + Bits 6-0 Other manufacturer-specific display mod */ +estbl_timing3: .byte 0x00 + +/* Standard timing */ +/* X resolution, less 31, divided by 8 (256-2288 pixels) */ +std_xres: .byte (XPIX/8)-31 +/* Y resolution, X:Y pixel ratio + Bits 7-6 X:Y pixel ratio: 00=16:10; 01=4:3; 10=5:4; 11=16:9. + Bits 5-0 Vertical frequency, less 60 (60-123 Hz) */ +std_vres: .byte (XY_RATIO<<6)+VFREQ-60 + .fill 7,2,0x0101 /* Unused */ + +descriptor1: +/* Pixel clock in 10 kHz units. (0.-655.35 MHz, little-endian) */ +clock: .word CLOCK/10 + +/* Horizontal active pixels 8 lsbits (0-4095) */ +x_act_lsb: .byte XPIX&0xff +/* Horizontal blanking pixels 8 lsbits (0-4095) + End of active to start of next active. */ +x_blk_lsb: .byte XBLANK&0xff +/* Bits 7-4 Horizontal active pixels 4 msbits + Bits 3-0 Horizontal blanking pixels 4 msbits */ +x_msbs: .byte msbs2(XPIX,XBLANK) + +/* Vertical active lines 8 lsbits (0-4095) */ +y_act_lsb: .byte YPIX&0xff +/* Vertical blanking lines 8 lsbits (0-4095) */ +y_blk_lsb: .byte YBLANK&0xff +/* Bits 7-4 Vertical active lines 4 msbits + Bits 3-0 Vertical blanking lines 4 msbits */ +y_msbs: .byte msbs2(YPIX,YBLANK) + +/* Horizontal sync offset pixels 8 lsbits (0-1023) From blanking start */ +x_snc_off_lsb: .byte XOFFSET&0xff +/* Horizontal sync pulse width pixels 8 lsbits (0-1023) */ +x_snc_pls_lsb: .byte XPULSE&0xff +/* Bits 7-4 Vertical sync offset lines 4 lsbits -63) + Bits 3-0 Vertical sync pulse width lines 4 lsbits -63) */ +y_snc_lsb: .byte ((YOFFSET-63)<<4)+(YPULSE-63) +/* Bits 7-6 Horizontal sync offset pixels 2 msbits + Bits 5-4 Horizontal sync pulse width pixels 2 msbits + Bits 3-2 Vertical sync offset lines 2 msbits + Bits 1-0 Vertical sync pulse width lines 2 msbits */ +xy_snc_msbs: .byte msbs4(XOFFSET,XPULSE,YOFFSET,YPULSE) + +/* Horizontal display size, mm, 8 lsbits (0-4095 mm, 161 in) */ +x_dsp_size: .byte xsize&0xff + +/* Vertical display size, mm, 8 lsbits (0-4095 mm, 161 in) */ +y_dsp_size: .byte ysize&0xff + +/* Bits 7-4 Horizontal display size, mm, 4 msbits + Bits 3-0 Vertical display size, mm, 4 msbits */ +dsp_size_mbsb: .byte msbs2(xsize,ysize) + +/* Horizontal border pixels (each side; total is twice this) */ +x_border: .byte 0 +/* Vertical border lines (each side; total is twice this) */ +y_border: .byte 0 + +/* Bit 7 Interlaced + Bits 6-5 Stereo mode: 00=No stereo; other values depend on bit 0: + Bit 0=0: 01=Field sequential, sync=1 during right; 10=similar, + sync=1 during left; 11=4-way interleaved stereo + Bit 0=1 2-way interleaved stereo: 01=Right image on even lines; + 10=Left image on even lines; 11=side-by-side + Bits 4-3 Sync type: 00=Analog composite; 01=Bipolar analog composite; + 10=Digital composite (on HSync); 11=Digital separate + Bit 2 If digital separate: Vertical sync polarity (1=positive) + Other types: VSync serrated (HSync during VSync) + Bit 1 If analog sync: Sync on all 3 RGB lines (else green only) + Digital: HSync polarity (1=positive) + Bit 0 2-way line-interleaved stereo, if bits 4-3 are not 00. */ +features: .byte 0x18+(VSYNC_POL<<2)+(HSYNC_POL<<1) + +descriptor2: .byte 0,0 /* Not a detailed timing descriptor */ + .byte 0 /* Must be zero */ + .byte 0xff /* Descriptor is monitor serial number (text) */ + .byte 0 /* Must be zero */ +start1: .ascii "Linux #0" +end1: .byte 0x0a /* End marker */ + .fill 12-(end1-start1), 1, 0x20 /* Padded spaces */ +descriptor3: .byte 0,0 /* Not a detailed timing descriptor */ + .byte 0 /* Must be zero */ + .byte 0xfd /* Descriptor is monitor range limits */ + .byte 0 /* Must be zero */ +start2: .byte VFREQ-1 /* Minimum vertical field rate (1-255 Hz) */ + .byte VFREQ+1 /* Maximum vertical field rate (1-255 Hz) */ + .byte (CLOCK/(XPIX+XBLANK))-1 /* Minimum horizontal line rate + (1-255 kHz) */ + .byte (CLOCK/(XPIX+XBLANK))+1 /* Maximum horizontal line rate + (1-255 kHz) */ + .byte (CLOCK/10000)+1 /* Maximum pixel clock rate, rounded up + to 10 MHz multiple (10-2550 MHz) */ + .byte 0 /* No extended timing information type */ +end2: .byte 0x0a /* End marker */ + .fill 12-(end2-start2), 1, 0x20 /* Padded spaces */ +descriptor4: .byte 0,0 /* Not a detailed timing descriptor */ + .byte 0 /* Must be zero */ + .byte 0xfc /* Descriptor is text */ + .byte 0 /* Must be zero */ +start3: .ascii TIMING_NAME +end3: .byte 0x0a /* End marker */ + .fill 12-(end3-start3), 1, 0x20 /* Padded spaces */ +extensions: .byte 0 /* Number of extensions to follow */ +checksum: .byte CRC /* Sum of all bytes must be 0 */ diff --git a/Documentation/EDID/hex b/Documentation/EDID/hex new file mode 100644 index 0000000..8873ebb --- /dev/null +++ b/Documentation/EDID/hex @@ -0,0 +1 @@ +"\t" 8/1 "0x%02x, " "\n" diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index d99fd9c..7f084b7 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -713,6 +713,21 @@ bytes respectively. Such letter suffixes can also be entirely omitted. The filter can be disabled or changed to another driver later using sysfs. + drm_kms_helper.edid_firmware=[:] + Broken monitors, graphic adapters and KVMs may + send no or incorrect EDID data sets. This parameter + allows to specify an EDID data set in the + /lib/firmware directory that is used instead. + Generic built-in EDID data sets are used, if one of + edid/1024x768.bin, edid/1280x1024.bin, + edid/1680x1050.bin, or edid/1920x1080.bin is given + and no file with the same name exists. Details and + instructions how to build your own EDID data are + available in Documentation/EDID/HOWTO.txt. An EDID + data set will only be used for a particular connector, + if its name and a colon are prepended to the EDID + name. + dscc4.setup= [NET] earlycon= [KNL] Output early console device and options. -- cgit v1.1 From 312869ec935ab3bb67b7ba641a7d11230555aff5 Mon Sep 17 00:00:00 2001 From: Hans de Goede Date: Sun, 18 Mar 2012 13:05:08 +0100 Subject: hwmon: (sch56xx) Add support for the integrated watchdog (v2) Add support for the watchdog integrated into the SMSC SCH5627 and SCH5636 superio-s. Since the watchdog is part of the hwmon logical device and thus shares ioports with it, the watchdog driver is integrated into the existing hwmon drivers for these. Note that this version of the watchdog support for sch56xx superio-s implements the watchdog chardev interface itself, rather then relying on the recently added watchdog core / watchdog_dev. This is done because currently some needed functionality is missing from watchdog_dev, as soon as this functionality is added (which is being discussed on the linux-watchdog mailinglist), I'll convert this driver over to using watchdog_dev. Signed-off-by: Hans de Goede [guenter.roeck@ericsson.com: Added missing linux/slab.h include] Signed-off-by: Guenter Roeck --- Documentation/hwmon/sch5627 | 5 +++++ Documentation/hwmon/sch5636 | 3 +++ 2 files changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/sch5627 b/Documentation/hwmon/sch5627 index 446a054..0551d26 100644 --- a/Documentation/hwmon/sch5627 +++ b/Documentation/hwmon/sch5627 @@ -16,6 +16,11 @@ Description SMSC SCH5627 Super I/O chips include complete hardware monitoring capabilities. They can monitor up to 5 voltages, 4 fans and 8 temperatures. +The SMSC SCH5627 hardware monitoring part also contains an integrated +watchdog. In order for this watchdog to function some motherboard specific +initialization most be done by the BIOS, so if the watchdog is not enabled +by the BIOS the sch5627 driver will not register a watchdog device. + The hardware monitoring part of the SMSC SCH5627 is accessed by talking through an embedded microcontroller. An application note describing the protocol for communicating with the microcontroller is available upon diff --git a/Documentation/hwmon/sch5636 b/Documentation/hwmon/sch5636 index f83bd1c..7b0a01d 100644 --- a/Documentation/hwmon/sch5636 +++ b/Documentation/hwmon/sch5636 @@ -26,6 +26,9 @@ 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. +The Fujitsu Theseus hwmon solution also contains an integrated watchdog. +This watchdog is fully supported by the sch5636 driver. + 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. -- cgit v1.1 From 317b6e128247f75976b0fc2b9fd8d2c20ef13b3a Mon Sep 17 00:00:00 2001 From: Cong Wang Date: Sat, 26 Nov 2011 11:12:30 +0800 Subject: feature-removal-schedule.txt: schedule the deprecated form of kmap_atomic() for removal Signed-off-by: Cong Wang --- Documentation/feature-removal-schedule.txt | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index a0ffac0..7465332 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -524,3 +524,11 @@ Files: arch/arm/mach-at91/at91cap9.c Why: The code is not actively maintained and platforms are now hard to find. Who: Nicolas Ferre Jean-Christophe PLAGNIOL-VILLARD + +---------------------------- + +What: kmap_atomic(page, km_type) +When: 3.5 +Why: The old kmap_atomic() with two arguments is deprecated, we only + keep it for backward compatibility for few cycles and then drop it. +Who: Cong Wang -- cgit v1.1 From 32991ab305ace7017c62f8eecbe5eb36dc32e13b Mon Sep 17 00:00:00 2001 From: Al Viro Date: Sun, 12 Feb 2012 22:15:47 -0500 Subject: vfs: d_alloc_root() gone all callers converted to d_make_root() by now Signed-off-by: Al Viro --- Documentation/filesystems/porting | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/porting b/Documentation/filesystems/porting index b4a3d76..74acd96 100644 --- a/Documentation/filesystems/porting +++ b/Documentation/filesystems/porting @@ -429,3 +429,9 @@ 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. + +-- +[mandatory] + d_alloc_root() is gone, along with a lot of bugs caused by code +misusing it. Replacement: d_make_root(inode). The difference is, +d_make_root() drops the reference to inode if dentry allocation fails. -- cgit v1.1 From 5d026c7242201e7c9d0e12fcb2bcaffead9d59fd Mon Sep 17 00:00:00 2001 From: Kai Bankett Date: Fri, 17 Feb 2012 05:59:20 +0100 Subject: fs: initial qnx6fs addition Adds support for qnx6fs readonly support to the linux kernel. * Mount option The option mmi_fs can be used to mount Harman Becker/Audi MMI 3G HDD qnx6fs filesystems. * Documentation A high level filesystem stucture description can be found in the Documentation/filesystems directory. (qnx6.txt) * Additional features - Active (stable) superblock selection - Superblock checksum check (enforced) - Supports mount of qnx6 filesystems with to host different endianess - Automatic endianess detection - Longfilename support (with non-enfocing crc check) - All blocksizes (512, 1024, 2048 and 4096 supported) Signed-off-by: Kai Bankett Signed-off-by: Al Viro --- Documentation/filesystems/qnx6.txt | 174 +++++++++++++++++++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 Documentation/filesystems/qnx6.txt (limited to 'Documentation') diff --git a/Documentation/filesystems/qnx6.txt b/Documentation/filesystems/qnx6.txt new file mode 100644 index 0000000..050223e --- /dev/null +++ b/Documentation/filesystems/qnx6.txt @@ -0,0 +1,174 @@ +The QNX6 Filesystem +=================== + +The qnx6fs is used by newer QNX operating system versions. (e.g. Neutrino) +It got introduced in QNX 6.4.0 and is used default since 6.4.1. + +Option +====== + +mmi_fs Mount filesystem as used for example by Audi MMI 3G system + +Specification +============= + +qnx6fs shares many properties with traditional Unix filesystems. It has the +concepts of blocks, inodes and directories. +On QNX it is possible to create little endian and big endian qnx6 filesystems. +This feature makes it possible to create and use a different endianness fs +for the target (QNX is used on quite a range of embedded systems) plattform +running on a different endianess. +The Linux driver handles endianness transparently. (LE and BE) + +Blocks +------ + +The space in the device or file is split up into blocks. These are a fixed +size of 512, 1024, 2048 or 4096, which is decided when the filesystem is +created. +Blockpointers are 32bit, so the maximum space that can be adressed is +2^32 * 4096 bytes or 16TB + +The superblocks +--------------- + +The superblock contains all global information about the filesystem. +Each qnx6fs got two superblocks, each one having a 64bit serial number. +That serial number is used to identify the "active" superblock. +In write mode with reach new snapshot (after each synchronous write), the +serial of the new master superblock is increased (old superblock serial + 1) + +So basically the snapshot functionality is realized by an atomic final +update of the serial number. Before updating that serial, all modifications +are done by copying all modified blocks during that specific write request +(or period) and building up a new (stable) filesystem structure under the +inactive superblock. + +Each superblock holds a set of root inodes for the different filesystem +parts. (Inode, Bitmap and Longfilenames) +Each of these root nodes holds information like total size of the stored +data and the adressing levels in that specific tree. +If the level value is 0, up to 16 direct blocks can be adressed by each +node. +Level 1 adds an additional indirect adressing level where each indirect +adressing block holds up to blocksize / 4 bytes pointers to data blocks. +Level 2 adds an additional indirect adressig block level (so, already up +to 16 * 256 * 256 = 1048576 blocks that can be adressed by such a tree)a + +Unused block pointers are always set to ~0 - regardless of root node, +indirect adressing blocks or inodes. +Data leaves are always on the lowest level. So no data is stored on upper +tree levels. + +The first Superblock is located at 0x2000. (0x2000 is the bootblock size) +The Audi MMI 3G first superblock directly starts at byte 0. +Second superblock position can either be calculated from the superblock +information (total number of filesystem blocks) or by taking the highest +device address, zeroing the last 3 bytes and then substracting 0x1000 from +that address. + +0x1000 is the size reserved for each superblock - regardless of the +blocksize of the filesystem. + +Inodes +------ + +Each object in the filesystem is represented by an inode. (index node) +The inode structure contains pointers to the filesystem blocks which contain +the data held in the object and all of the metadata about an object except +its longname. (filenames longer than 27 characters) +The metadata about an object includes the permissions, owner, group, flags, +size, number of blocks used, access time, change time and modification time. + +Object mode field is POSIX format. (which makes things easier) + +There are also pointers to the first 16 blocks, if the object data can be +adressed with 16 direct blocks. +For more than 16 blocks an indirect adressing in form of another tree is +used. (scheme is the same as the one used for the superblock root nodes) + +The filesize is stored 64bit. Inode counting starts with 1. (whilst long +filename inodes start with 0) + +Directories +----------- + +A directory is a filesystem object and has an inode just like a file. +It is a specially formatted file containing records which associate each +name with an inode number. +'.' inode number points to the directory inode +'..' inode number points to the parent directory inode +Eeach filename record additionally got a filename length field. + +One special case are long filenames or subdirectory names. +These got set a filename length field of 0xff in the corresponding directory +record plus the longfile inode number also stored in that record. +With that longfilename inode number, the longfilename tree can be walked +starting with the superblock longfilename root node pointers. + +Special files +------------- + +Symbolic links are also filesystem objects with inodes. They got a specific +bit in the inode mode field identifying them as symbolic link. +The directory entry file inode pointer points to the target file inode. + +Hard links got an inode, a directory entry, but a specific mode bit set, +no block pointers and the directory file record pointing to the target file +inode. + +Character and block special devices do not exist in QNX as those files +are handled by the QNX kernel/drivers and created in /dev independant of the +underlaying filesystem. + +Long filenames +-------------- + +Long filenames are stored in a seperate adressing tree. The staring point +is the longfilename root node in the active superblock. +Each data block (tree leaves) holds one long filename. That filename is +limited to 510 bytes. The first two starting bytes are used as length field +for the actual filename. +If that structure shall fit for all allowed blocksizes, it is clear why there +is a limit of 510 bytes for the actual filename stored. + +Bitmap +------ + +The qnx6fs filesystem allocation bitmap is stored in a tree under bitmap +root node in the superblock and each bit in the bitmap represents one +filesystem block. +The first block is block 0, which starts 0x1000 after superblock start. +So for a normal qnx6fs 0x3000 (bootblock + superblock) is the physical +address at which block 0 is located. + +Bits at the end of the last bitmap block are set to 1, if the device is +smaller than addressing space in the bitmap. + +Bitmap system area +------------------ + +The bitmap itself is devided into three parts. +First the system area, that is split into two halfs. +Then userspace. + +The requirement for a static, fixed preallocated system area comes from how +qnx6fs deals with writes. +Each superblock got it's own half of the system area. So superblock #1 +always uses blocks from the lower half whilst superblock #2 just writes to +blocks represented by the upper half bitmap system area bits. + +Bitmap blocks, Inode blocks and indirect addressing blocks for those two +tree structures are treated as system blocks. + +The rational behind that is that a write request can work on a new snapshot +(system area of the inactive - resp. lower serial numbered superblock) while +at the same time there is still a complete stable filesystem structer in the +other half of the system area. + +When finished with writing (a sync write is completed, the maximum sync leap +time or a filesystem sync is requested), serial of the previously inactive +superblock atomically is increased and the fs switches over to that - then +stable declared - superblock. + +For all data outside the system area, blocks are just copied while writing. -- cgit v1.1 From a051f71ce97c53cde3ac64de64eb02d658d9308e Mon Sep 17 00:00:00 2001 From: Matthew Garrett Date: Mon, 6 Feb 2012 15:14:40 -0500 Subject: hfsplus: add an ioctl to bless files Making an hfsplus partition bootable requires the ability to "bless" a file by putting its inode number in the volume header. Doing this from userspace on a mounted filesystem is impractical since the kernel will write back the original values on unmount. Add an ioctl to allow userspace to update the volume header information based on the target file. Signed-off-by: Matthew Garrett Signed-off-by: Christoph Hellwig Signed-off-by: Al Viro --- Documentation/ioctl/ioctl-number.txt | 1 + 1 file changed, 1 insertion(+) (limited to 'Documentation') diff --git a/Documentation/ioctl/ioctl-number.txt b/Documentation/ioctl/ioctl-number.txt index 4840334..37a4248 100644 --- a/Documentation/ioctl/ioctl-number.txt +++ b/Documentation/ioctl/ioctl-number.txt @@ -218,6 +218,7 @@ Code Seq#(hex) Include File Comments 'h' 00-7F conflict! Charon filesystem 'h' 00-1F linux/hpet.h conflict! +'h' 80-8F fs/hfsplus/ioctl.c 'i' 00-3F linux/i2o-dev.h conflict! 'i' 0B-1F linux/ipmi.h conflict! 'i' 80-8F linux/i8k.h -- cgit v1.1 From 88187398cc5fa6650f38b9dcd5464667f468888f Mon Sep 17 00:00:00 2001 From: Al Viro Date: Tue, 20 Mar 2012 06:00:24 -0400 Subject: debugfs-related mode_t whack-a-mole all of those should be umode_t... Signed-off-by: Al Viro --- Documentation/filesystems/debugfs.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/debugfs.txt b/Documentation/filesystems/debugfs.txt index 6872c91..41865d6 100644 --- a/Documentation/filesystems/debugfs.txt +++ b/Documentation/filesystems/debugfs.txt @@ -133,7 +133,7 @@ file. void __iomem *base; }; - struct dentry *debugfs_create_regset32(const char *name, mode_t mode, + struct dentry *debugfs_create_regset32(const char *name, umode_t mode, struct dentry *parent, struct debugfs_regset32 *regset); -- cgit v1.1 From 18d98f6c04991dd3c12acf6f39cea40e9510640a Mon Sep 17 00:00:00 2001 From: Sachin Bhamare Date: Mon, 19 Mar 2012 20:47:58 -0700 Subject: pnfs-obj: autologin: Add support for protocol autologin The pnfs-objects protocol mandates that we autologin into devices not present in the system, according to information specified in the get_device_info returned from the server. The Protocol specifies two login hints. 1. An IP address:port combination 2. A string URI which is constructed as a URL with a protocol prefix followed by :// and a string as address. For each protocol prefix the string-address format might be different. We only support the second option. The first option is just redundant to the second one. NOTE: The Kernel part of autologin does not parse the URI string. It just channels it to a user-mode script. So any new login protocols should only update the user-mode script which is a part of the nfs-utils package, but the Kernel need not change. We implement the autologin by using the call_usermodehelper() API. (Thanks to Steve Dickson for pointing it out) So there is no running daemon needed, and/or special setup. We Add the osd_login_prog Kernel module parameters which defaults to: /sbin/osd_login Kernel try's to upcall the program specified in osd_login_prog. If the file is not found or the execution fails Kernel will disable any farther upcalls, by zeroing out osd_login_prog, Until Admin re-enables it by setting the osd_login_prog parameter to a proper program. Also add text about the osd_login program command line API to: Documentation/filesystems/nfs/pnfs.txt and documentation of the new osd_login_prog module parameter to: Documentation/kernel-parameters.txt TODO: Add timeout option in the case osd_login program gets stuck Signed-off-by: Sachin Bhamare Signed-off-by: Boaz Harrosh Signed-off-by: Trond Myklebust --- Documentation/filesystems/nfs/pnfs.txt | 54 ++++++++++++++++++++++++++++++++++ Documentation/kernel-parameters.txt | 6 ++++ 2 files changed, 60 insertions(+) (limited to 'Documentation') diff --git a/Documentation/filesystems/nfs/pnfs.txt b/Documentation/filesystems/nfs/pnfs.txt index 983e14a..c7919c6 100644 --- a/Documentation/filesystems/nfs/pnfs.txt +++ b/Documentation/filesystems/nfs/pnfs.txt @@ -53,3 +53,57 @@ lseg maintains an extra reference corresponding to the NFS_LSEG_VALID bit which holds it in the pnfs_layout_hdr's list. When the final lseg is removed from the pnfs_layout_hdr's list, the NFS_LAYOUT_DESTROYED bit is set, preventing any new lsegs from being added. + +layout drivers +-------------- + +PNFS utilizes what is called layout drivers. The STD defines 3 basic +layout types: "files" "objects" and "blocks". For each of these types +there is a layout-driver with a common function-vectors table which +are called by the nfs-client pnfs-core to implement the different layout +types. + +Files-layout-driver code is in: fs/nfs/nfs4filelayout.c && nfs4filelayoutdev.c +Objects-layout-deriver code is in: fs/nfs/objlayout/.. directory +Blocks-layout-deriver code is in: fs/nfs/blocklayout/.. directory + +objects-layout setup +-------------------- + +As part of the full STD implementation the objlayoutdriver.ko needs, at times, +to automatically login to yet undiscovered iscsi/osd devices. For this the +driver makes up-calles to a user-mode script called *osd_login* + +The path_name of the script to use is by default: + /sbin/osd_login. +This name can be overridden by the Kernel module parameter: + objlayoutdriver.osd_login_prog + +If Kernel does not find the osd_login_prog path it will zero it out +and will not attempt farther logins. An admin can then write new value +to the objlayoutdriver.osd_login_prog Kernel parameter to re-enable it. + +The /sbin/osd_login is part of the nfs-utils package, and should usually +be installed on distributions that support this Kernel version. + +The API to the login script is as follows: + Usage: $0 -u -o -s + Options: + -u target uri e.g. iscsi://: + (allways exists) + (More protocols can be defined in the future. + The client does not interpret this string it is + passed unchanged as recieved from the Server) + -o osdname of the requested target OSD + (Might be empty) + (A string which denotes the OSD name, there is a + limit of 64 chars on this string) + -s systemid of the requested target OSD + (Might be empty) + (This string, if not empty is always an hex + representation of the 20 bytes osd_system_id) + +blocks-layout setup +------------------- + +TODO: Document the setup needs of the blocks layout driver diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 7bae0fd..0d79a88f 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1687,6 +1687,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted. information. + objlayoutdriver.osd_login_prog= + [NFS] [OBJLAYOUT] sets the pathname to the program which + is used to automatically discover and login into new + osd-targets. Please see: + Documentation/filesystems/pnfs.txt for more explanations + nmi_debug= [KNL,AVR32,SH] Specify one or more actions to take when a NMI is triggered. Format: [state][,regs][,debounce][,die] -- cgit v1.1 From 807f0ccfe15551afd514c062585045c88ca62037 Mon Sep 17 00:00:00 2001 From: Naoya Horiguchi Date: Wed, 21 Mar 2012 16:33:58 -0700 Subject: pagemap: document KPF_THP and make page-types aware of it page-types, which is a common user of pagemap, gets aware of thp with this patch. This helps system admins and kernel hackers know about how thp works. Here is a sample output of page-types over a thp: $ page-types -p --raw --list voffset offset len flags ... 7f9d40200 3f8400 1 ___U_lA____Ma_bH______t____________ 7f9d40201 3f8401 1ff ________________T_____t____________ flags page-count MB symbolic-flags long-symbolic-flags 0x0000000000410000 511 1 ________________T_____t____________ compound_tail,thp 0x000000000040d868 1 0 ___U_lA____Ma_bH______t____________ uptodate,lru,active,mmap,anonymous,swapbacked,compound_head,thp Signed-off-by: Naoya Horiguchi Acked-by: Wu Fengguang Reviewed-by: KAMEZAWA Hiroyuki Acked-by: KOSAKI Motohiro Cc: David Rientjes Cc: Andi Kleen Cc: Andrea Arcangeli Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/vm/page-types.c | 2 ++ Documentation/vm/pagemap.txt | 4 ++++ 2 files changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/vm/page-types.c b/Documentation/vm/page-types.c index 7445caa..0b13f02 100644 --- a/Documentation/vm/page-types.c +++ b/Documentation/vm/page-types.c @@ -98,6 +98,7 @@ #define KPF_HWPOISON 19 #define KPF_NOPAGE 20 #define KPF_KSM 21 +#define KPF_THP 22 /* [32-] kernel hacking assistances */ #define KPF_RESERVED 32 @@ -147,6 +148,7 @@ static const char *page_flag_names[] = { [KPF_HWPOISON] = "X:hwpoison", [KPF_NOPAGE] = "n:nopage", [KPF_KSM] = "x:ksm", + [KPF_THP] = "t:thp", [KPF_RESERVED] = "r:reserved", [KPF_MLOCKED] = "m:mlocked", diff --git a/Documentation/vm/pagemap.txt b/Documentation/vm/pagemap.txt index df09b96..4600cbe 100644 --- a/Documentation/vm/pagemap.txt +++ b/Documentation/vm/pagemap.txt @@ -60,6 +60,7 @@ There are three components to pagemap: 19. HWPOISON 20. NOPAGE 21. KSM + 22. THP Short descriptions to the page flags: @@ -97,6 +98,9 @@ Short descriptions to the page flags: 21. KSM identical memory pages dynamically shared between one or more processes +22. THP + contiguous pages which construct transparent hugepages + [IO related page flags] 1. ERROR IO error occurred 3. UPTODATE page has up-to-date data -- cgit v1.1 From fcf4d8212a8f38334679e82ff14532b908b4b451 Mon Sep 17 00:00:00 2001 From: Jiri Kosina Date: Wed, 21 Mar 2012 16:34:02 -0700 Subject: thp: documentation: 'transparent_hugepage=' can also be specified on cmdline The behavior of THP can either be toggled through sysfs in runtime or using a kernel cmdline parameter 'transparent_hugepage='. Document the latter in kernel-parameters.txt Signed-off-by: Jiri Kosina Cc: Andrea Arcangeli Cc: Mel Gorman Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 7 +++++++ 1 file changed, 7 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 8cadb75..7986d79 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -2635,6 +2635,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted. to facilitate early boot debugging. See also Documentation/trace/events.txt + transparent_hugepage= + [KNL] + Format: [always|madvise|never] + Can be used to control the default behavior of the system + with respect to transparent hugepages. + See Documentation/vm/transhuge.txt for more details. + tsc= Disable clocksource stability checks for TSC. Format: [x86] reliable: mark tsc clocksource as reliable, this -- cgit v1.1 From b76437579d1344b612cf1851ae610c636cec7db0 Mon Sep 17 00:00:00 2001 From: Siddhesh Poyarekar Date: Wed, 21 Mar 2012 16:34:04 -0700 Subject: procfs: mark thread stack correctly in proc//maps Stack for a new thread is mapped by userspace code and passed via sys_clone. This memory is currently seen as anonymous in /proc//maps, which makes it difficult to ascertain which mappings are being used for thread stacks. This patch uses the individual task stack pointers to determine which vmas are actually thread stacks. For a multithreaded program like the following: #include void *thread_main(void *foo) { while(1); } int main() { pthread_t t; pthread_create(&t, NULL, thread_main, NULL); pthread_join(t, NULL); } proc/PID/maps looks like the following: 00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out 00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out 019ef000-01a10000 rw-p 00000000 00:00 0 [heap] 7f8a44491000-7f8a44492000 ---p 00000000 00:00 0 7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0 7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0 7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so 7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0 7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0 7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so 7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so 7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0 7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack] 7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Here, one could guess that 7f8a44492000-7f8a44c92000 is a stack since the earlier vma that has no permissions (7f8a44e3d000-7f8a4503d000) but that is not always a reliable way to find out which vma is a thread stack. Also, /proc/PID/maps and /proc/PID/task/TID/maps has the same content. With this patch in place, /proc/PID/task/TID/maps are treated as 'maps as the task would see it' and hence, only the vma that that task uses as stack is marked as [stack]. All other 'stack' vmas are marked as anonymous memory. /proc/PID/maps acts as a thread group level view, where all thread stack vmas are marked as [stack:TID] where TID is the process ID of the task that uses that vma as stack, while the process stack is marked as [stack]. So /proc/PID/maps will look like this: 00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out 00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out 019ef000-01a10000 rw-p 00000000 00:00 0 [heap] 7f8a44491000-7f8a44492000 ---p 00000000 00:00 0 7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack:1442] 7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0 7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0 7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so 7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0 7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0 7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so 7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so 7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0 7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack] 7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] Thus marking all vmas that are used as stacks by the threads in the thread group along with the process stack. The task level maps will however like this: 00400000-00401000 r-xp 00000000 fd:0a 3671804 /home/siddhesh/a.out 00600000-00601000 rw-p 00000000 fd:0a 3671804 /home/siddhesh/a.out 019ef000-01a10000 rw-p 00000000 00:00 0 [heap] 7f8a44491000-7f8a44492000 ---p 00000000 00:00 0 7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack] 7f8a44c92000-7f8a44e3d000 r-xp 00000000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a44e3d000-7f8a4503d000 ---p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a4503d000-7f8a45041000 r--p 001ab000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a45041000-7f8a45043000 rw-p 001af000 fd:00 2097482 /lib64/libc-2.14.90.so 7f8a45043000-7f8a45048000 rw-p 00000000 00:00 0 7f8a45048000-7f8a4505f000 r-xp 00000000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a4505f000-7f8a4525e000 ---p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a4525e000-7f8a4525f000 r--p 00016000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a4525f000-7f8a45260000 rw-p 00017000 fd:00 2099938 /lib64/libpthread-2.14.90.so 7f8a45260000-7f8a45264000 rw-p 00000000 00:00 0 7f8a45264000-7f8a45286000 r-xp 00000000 fd:00 2097348 /lib64/ld-2.14.90.so 7f8a45457000-7f8a4545a000 rw-p 00000000 00:00 0 7f8a45484000-7f8a45485000 rw-p 00000000 00:00 0 7f8a45485000-7f8a45486000 r--p 00021000 fd:00 2097348 /lib64/ld-2.14.90.so 7f8a45486000-7f8a45487000 rw-p 00022000 fd:00 2097348 /lib64/ld-2.14.90.so 7f8a45487000-7f8a45488000 rw-p 00000000 00:00 0 7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 7fff627ff000-7fff62800000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] where only the vma that is being used as a stack by *that* task is marked as [stack]. Analogous changes have been made to /proc/PID/smaps, /proc/PID/numa_maps, /proc/PID/task/TID/smaps and /proc/PID/task/TID/numa_maps. Relevant snippets from smaps and numa_maps: [siddhesh@localhost ~ ]$ pgrep a.out 1441 [siddhesh@localhost ~ ]$ cat /proc/1441/smaps | grep "\[stack" 7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack:1442] 7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack] [siddhesh@localhost ~ ]$ cat /proc/1441/task/1442/smaps | grep "\[stack" 7f8a44492000-7f8a44c92000 rw-p 00000000 00:00 0 [stack] [siddhesh@localhost ~ ]$ cat /proc/1441/task/1441/smaps | grep "\[stack" 7fff6273b000-7fff6275c000 rw-p 00000000 00:00 0 [stack] [siddhesh@localhost ~ ]$ cat /proc/1441/numa_maps | grep "stack" 7f8a44492000 default stack:1442 anon=2 dirty=2 N0=2 7fff6273a000 default stack anon=3 dirty=3 N0=3 [siddhesh@localhost ~ ]$ cat /proc/1441/task/1442/numa_maps | grep "stack" 7f8a44492000 default stack anon=2 dirty=2 N0=2 [siddhesh@localhost ~ ]$ cat /proc/1441/task/1441/numa_maps | grep "stack" 7fff6273a000 default stack anon=3 dirty=3 N0=3 [akpm@linux-foundation.org: checkpatch fixes] [akpm@linux-foundation.org: fix build] Signed-off-by: Siddhesh Poyarekar Cc: KOSAKI Motohiro Cc: Alexander Viro Cc: Jamie Lokier Cc: Mike Frysinger Cc: Alexey Dobriyan Cc: Matt Mackall Cc: Oleg Nesterov Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/filesystems/proc.txt | 32 ++++++++++++++++++++++++++++++-- 1 file changed, 30 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index a76a26a..b7413cb 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -290,7 +290,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7) rsslim current limit in bytes on the rss start_code address above which program text can run end_code address below which program text can run - start_stack address of the start of the stack + start_stack address of the start of the main process stack esp current value of ESP eip current value of EIP pending bitmap of pending signals @@ -325,7 +325,7 @@ address perms offset dev inode pathname a7cb1000-a7cb2000 ---p 00000000 00:00 0 a7cb2000-a7eb2000 rw-p 00000000 00:00 0 a7eb2000-a7eb3000 ---p 00000000 00:00 0 -a7eb3000-a7ed5000 rw-p 00000000 00:00 0 +a7eb3000-a7ed5000 rw-p 00000000 00:00 0 [stack:1001] a7ed5000-a8008000 r-xp 00000000 03:00 4222 /lib/libc.so.6 a8008000-a800a000 r--p 00133000 03:00 4222 /lib/libc.so.6 a800a000-a800b000 rw-p 00135000 03:00 4222 /lib/libc.so.6 @@ -357,11 +357,39 @@ is not associated with a file: [heap] = the heap of the program [stack] = the stack of the main process + [stack:1001] = the stack of the thread with tid 1001 [vdso] = the "virtual dynamic shared object", the kernel system call handler or if empty, the mapping is anonymous. +The /proc/PID/task/TID/maps is a view of the virtual memory from the viewpoint +of the individual tasks of a process. In this file you will see a mapping marked +as [stack] if that task sees it as a stack. This is a key difference from the +content of /proc/PID/maps, where you will see all mappings that are being used +as stack by all of those tasks. Hence, for the example above, the task-level +map, i.e. /proc/PID/task/TID/maps for thread 1001 will look like this: + +08048000-08049000 r-xp 00000000 03:00 8312 /opt/test +08049000-0804a000 rw-p 00001000 03:00 8312 /opt/test +0804a000-0806b000 rw-p 00000000 00:00 0 [heap] +a7cb1000-a7cb2000 ---p 00000000 00:00 0 +a7cb2000-a7eb2000 rw-p 00000000 00:00 0 +a7eb2000-a7eb3000 ---p 00000000 00:00 0 +a7eb3000-a7ed5000 rw-p 00000000 00:00 0 [stack] +a7ed5000-a8008000 r-xp 00000000 03:00 4222 /lib/libc.so.6 +a8008000-a800a000 r--p 00133000 03:00 4222 /lib/libc.so.6 +a800a000-a800b000 rw-p 00135000 03:00 4222 /lib/libc.so.6 +a800b000-a800e000 rw-p 00000000 00:00 0 +a800e000-a8022000 r-xp 00000000 03:00 14462 /lib/libpthread.so.0 +a8022000-a8023000 r--p 00013000 03:00 14462 /lib/libpthread.so.0 +a8023000-a8024000 rw-p 00014000 03:00 14462 /lib/libpthread.so.0 +a8024000-a8027000 rw-p 00000000 00:00 0 +a8027000-a8043000 r-xp 00000000 03:00 8317 /lib/ld-linux.so.2 +a8043000-a8044000 r--p 0001b000 03:00 8317 /lib/ld-linux.so.2 +a8044000-a8045000 rw-p 0001c000 03:00 8317 /lib/ld-linux.so.2 +aff35000-aff4a000 rw-p 00000000 00:00 0 +ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso] The /proc/PID/smaps is an extension based on maps, showing the memory consumption for each of the process's mappings. For each of mappings there -- cgit v1.1 From bec4d62ead8096e433d624d9339893f50badd992 Mon Sep 17 00:00:00 2001 From: Jason Wessel Date: Mon, 19 Mar 2012 19:35:55 -0500 Subject: kgdb,debug_core: add the ability to control the reboot notifier Sometimes it is desirable to stop the kernel debugger before allowing a system to reboot either with kdb or kgdb. This patch adds the ability to turn the reboot notifier on and off or enter the debugger and stop kernel execution before rebooting. It is possible to change the setting after booting the kernel with the following: echo 1 > /sys/module/debug_core/parameters/kgdbreboot It is also possible to change this setting using kdb / kgdb to manipulate the variable directly. Using KDB: mm kgdbreboot 1 Using gdb: set kgdbreboot=1 Reported-by: Jan Kiszka Signed-off-by: Jason Wessel --- Documentation/DocBook/kgdb.tmpl | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) (limited to 'Documentation') diff --git a/Documentation/DocBook/kgdb.tmpl b/Documentation/DocBook/kgdb.tmpl index d71b57f..4ee4ba3 100644 --- a/Documentation/DocBook/kgdb.tmpl +++ b/Documentation/DocBook/kgdb.tmpl @@ -362,6 +362,23 @@ + + Run time parameter: kgdbreboot + The kgdbreboot feature allows you to change how the debugger + deals with the reboot notification. You have 3 choices for the + behavior. The default behavior is always set to 0. + + echo -1 > /sys/module/debug_core/parameters/kgdbreboot + Ignore the reboot notification entirely. + + echo 0 > /sys/module/debug_core/parameters/kgdbreboot + Send the detach message to any attached debugger client. + + echo 1 > /sys/module/debug_core/parameters/kgdbreboot + Enter the debugger on reboot notify. + + + Using kdb -- cgit v1.1 From b86c4782ab501e3b69e5e0b32050455f95caa681 Mon Sep 17 00:00:00 2001 From: Sebastian Andrzej Siewior Date: Wed, 21 Mar 2012 22:25:48 +0100 Subject: Documentation/kernel-parameters: remove inttest parameter According to grep I see no users: | #git grep inttest | Documentation/kernel-parameters.txt: inttest= [IA-64] The parameters itself has no description what it supposed to do. According to the history tree, it was introduced in "[PATCH] Updated Documentation/kernel-parameters.txt" ("10414c6ddb"). By that time that parameter had an user. It was removed later by "[PATCH] ia64: SGI SN update" ("c6bacd5010ec") by Jesse Barnes himself. Cc: Fenghua Yu Cc: Randy Dunlap Signed-off-by: Sebastian Andrzej Siewior Signed-off-by: Tony Luck --- Documentation/kernel-parameters.txt | 2 -- 1 file changed, 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 033d4e6..710cde9 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1071,8 +1071,6 @@ bytes respectively. Such letter suffixes can also be entirely omitted. no_x2apic_optout BIOS x2APIC opt-out request will be ignored - inttest= [IA-64] - iomem= Disable strict checking of access to MMIO memory strict regions from userspace. relaxed -- cgit v1.1 From ae544f64cc7b0850471f62e6808068ef77b90763 Mon Sep 17 00:00:00 2001 From: Guenter Roeck Date: Fri, 23 Mar 2012 10:02:18 +0100 Subject: hwmon: (lm90) Add support for GMT G781 GMT G781 is a ADM1032-compatible temperature sensor chip. Add support to the LM90 driver. Cc: Mike Gorchak Signed-off-by: Guenter Roeck Signed-off-by: Jean Delvare --- Documentation/hwmon/lm90 | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/hwmon/lm90 b/Documentation/hwmon/lm90 index 9cd14cfe..b466974 100644 --- a/Documentation/hwmon/lm90 +++ b/Documentation/hwmon/lm90 @@ -118,6 +118,10 @@ Supported chips: Addresses scanned: I2C 0x48 through 0x4F Datasheet: Publicly available at NXP website http://ics.nxp.com/products/interface/datasheet/sa56004x.pdf + * GMT G781 + Prefix: 'g781' + Addresses scanned: I2C 0x4c, 0x4d + Datasheet: Not publicly available from GMT Author: Jean Delvare -- cgit v1.1 From 0c2732152a5813a870d0b96f0844f4dfe1436519 Mon Sep 17 00:00:00 2001 From: Uwe Kleine-Koenig Date: Fri, 23 Mar 2012 10:02:19 +0100 Subject: hwmon: (mc13783-adc) Add support for the MC13892 PMIC Based on a patch by David Jander that mostly did s/mc13783/mc13xxx/ . Additionally use dev_get_drvdata instead of to_platform_device + platform_get_drvdata in mc13783_adc_read (spotted by Jean Delvare). Cc: David Jander Signed-off-by: Uwe Kleine-Koenig Signed-off-by: Jean Delvare --- Documentation/hwmon/mc13783-adc | 50 ++++++++++++++++++++++++++++++----------- 1 file changed, 37 insertions(+), 13 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hwmon/mc13783-adc b/Documentation/hwmon/mc13783-adc index 044531a..d0e7b3f 100644 --- a/Documentation/hwmon/mc13783-adc +++ b/Documentation/hwmon/mc13783-adc @@ -3,8 +3,11 @@ Kernel driver mc13783-adc Supported chips: * Freescale Atlas MC13783 - Prefix: 'mc13783_adc' + Prefix: 'mc13783' Datasheet: http://www.freescale.com/files/rf_if/doc/data_sheet/MC13783.pdf?fsrch=1 + * Freescale Atlas MC13892 + Prefix: 'mc13892' + Datasheet: http://cache.freescale.com/files/analog/doc/data_sheet/MC13892.pdf?fsrch=1&sr=1 Authors: Sascha Hauer @@ -13,20 +16,21 @@ Authors: Description ----------- -The Freescale MC13783 is a Power Management and Audio Circuit. Among -other things it contains a 10-bit A/D converter. The converter has 16 -channels which can be used in different modes. -The A/D converter has a resolution of 2.25mV. Channels 0-4 have -a dedicated meaning with chip internal scaling applied. Channels 5-7 -can be used as general purpose inputs or alternatively in a dedicated -mode. Channels 12-15 are occupied by the touchscreen if it's active. +The Freescale MC13783 and MC13892 are Power Management and Audio Circuits. +Among other things they contain a 10-bit A/D converter. The converter has 16 +(MC13783) resp. 12 (MC13892) channels which can be used in different modes. The +A/D converter has a resolution of 2.25mV. -Currently the driver only supports channels 2 and 5-15 with no alternative -modes for channels 5-7. +Some channels can be used as General Purpose inputs or in a dedicated mode with +a chip internal scaling applied . -See this table for the meaning of the different channels and their chip -internal scaling: +Currently the driver only supports the Application Supply channel (BP / BPSNS), +the General Purpose inputs and touchscreen. +See the following tables for the meaning of the different channels and their +chip internal scaling: + +MC13783: Channel Signal Input Range Scaling ------------------------------------------------------------------------------- 0 Battery Voltage (BATT) 2.50 - 4.65V -2.40V @@ -34,7 +38,7 @@ Channel Signal Input Range Scaling 2 Application Supply (BP) 2.50 - 4.65V -2.40V 3 Charger Voltage (CHRGRAW) 0 - 10V / /5 0 - 20V /10 -4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25V - 0.25V x4 +4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25 - 0.25V x4 5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.30V No 6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.30V / No / 1.50 - 3.50V -1.20V @@ -48,3 +52,23 @@ Channel Signal Input Range Scaling 13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.30V No 14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.30V No 15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.30V No + +MC13892: +Channel Signal Input Range Scaling +------------------------------------------------------------------------------- +0 Battery Voltage (BATT) 0 - 4.8V /2 +1 Battery Current (BATT - BATTISNSCC) -60 - 60 mV x20 +2 Application Supply (BPSNS) 0 - 4.8V /2 +3 Charger Voltage (CHRGRAW) 0 - 12V / /5 + 0 - 20V /10 +4 Charger Current (CHRGISNS-BPSNS) / -0.3 - 0.3V / x4 / + Touchscreen X-plate 1 0 - 2.4V No +5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.4V No +6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.4V / No + Backup Voltage (LICELL) 0 - 3.6V x2/3 +7 General Purpose ADIN7 / UID / Die Temperature 0 - 2.4V / No / + 0 - 4.8V /2 +12 General Purpose TSX1 / Touchscreen X-plate 1 0 - 2.4V No +13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.4V No +14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.4V No +15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.4V No -- cgit v1.1 From 5510e62a66bad22b104d5d854445523d7f5754f7 Mon Sep 17 00:00:00 2001 From: Xie Xiaobo Date: Fri, 23 Mar 2012 10:02:20 +0100 Subject: hwmon: Add MCP3021 ADC driver Add I2C driver for MCP3021 that is an ADC chip from Microchip. The MCP3021 is a successive approximation A/D converter (ADC) with 10-bit resolution. The driver export the value of Vin to sysfs, the voltage unit is mV. Through the sysfs interface, lm-sensors tool can also display Vin voltage. Signed-off-by: Mingkai Hu Signed-off-by: Xie Xiaobo Signed-off-by: Jean Delvare --- Documentation/hwmon/mcp3021 | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) create mode 100644 Documentation/hwmon/mcp3021 (limited to 'Documentation') diff --git a/Documentation/hwmon/mcp3021 b/Documentation/hwmon/mcp3021 new file mode 100644 index 0000000..325fd87 --- /dev/null +++ b/Documentation/hwmon/mcp3021 @@ -0,0 +1,22 @@ +Kernel driver MCP3021 +====================== + +Supported chips: + * Microchip Technology MCP3021 + Prefix: 'mcp3021' + Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/21805a.pdf + +Author: Mingkai Hu + +Description +----------- + +This driver implements support for the Microchip Technology MCP3021 chip. + +The Microchip Technology Inc. MCP3021 is a successive approximation A/D +converter (ADC) with 10-bit resolution. +This device provides one single-ended input with very low power consumption. +Communication to the MCP3021 is performed using a 2-wire I2C compatible +interface. Standard (100 kHz) and Fast (400 kHz) I2C modes are available. +The default I2C device address is 0x4d (contact the Microchip factory for +additional address options). -- cgit v1.1 From 7be865ab8634d4ec2a6bdb9459b268cd60e832af Mon Sep 17 00:00:00 2001 From: "Kim, Milo" Date: Fri, 23 Mar 2012 15:02:01 -0700 Subject: backlight: new backlight driver for LP855x devices THis driver supports TI LP8550/LP8551/LP8552/LP8553/LP8556 backlight devices. The brightness can be controlled by the I2C or PWM input. The lp855x driver provides both modes. For the PWM control, pwm-specific functions can be defined in the platform data. And some information can be read via the sysfs(lp855x device attributes). For details, please refer to Documentation/backlight/lp855x-driver.txt. [axel.lin@gmail.com: add missing mutex_unlock in lp855x_read_byte() error path] [axel.lin@gmail.com: check platform data in lp855x_probe()] [axel.lin@gmail.com: small cleanups] [dan.carpenter@oracle.com: silence a compiler warning] [axel.lin@gmail.com: use id->driver_data to differentiate lp855x chips] [akpm@linux-foundation.org: simplify boolean return expression] Signed-off-by: Milo(Woogyom) Kim Signed-off-by: Axel Lin Signed-off-by: Dan Carpenter Cc: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/backlight/lp855x-driver.txt | 78 +++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) create mode 100644 Documentation/backlight/lp855x-driver.txt (limited to 'Documentation') diff --git a/Documentation/backlight/lp855x-driver.txt b/Documentation/backlight/lp855x-driver.txt new file mode 100644 index 0000000..f5e4caa --- /dev/null +++ b/Documentation/backlight/lp855x-driver.txt @@ -0,0 +1,78 @@ +Kernel driver lp855x +==================== + +Backlight driver for LP855x ICs + +Supported chips: + Texas Instruments LP8550, LP8551, LP8552, LP8553 and LP8556 + +Author: Milo(Woogyom) Kim + +Description +----------- + +* Brightness control + +Brightness can be controlled by the pwm input or the i2c command. +The lp855x driver supports both cases. + +* Device attributes + +1) bl_ctl_mode +Backlight control mode. +Value : pwm based or register based + +2) chip_id +The lp855x chip id. +Value : lp8550/lp8551/lp8552/lp8553/lp8556 + +Platform data for lp855x +------------------------ + +For supporting platform specific data, the lp855x platform data can be used. + +* name : Backlight driver name. If it is not defined, default name is set. +* mode : Brightness control mode. PWM or register based. +* device_control : Value of DEVICE CONTROL register. +* initial_brightness : Initial value of backlight brightness. +* pwm_data : Platform specific pwm generation functions. + Only valid when brightness is pwm input mode. + Functions should be implemented by PWM driver. + - pwm_set_intensity() : set duty of PWM + - pwm_get_intensity() : get current duty of PWM +* load_new_rom_data : + 0 : use default configuration data + 1 : update values of eeprom or eprom registers on loading driver +* size_program : Total size of lp855x_rom_data. +* rom_data : List of new eeprom/eprom registers. + +example 1) lp8552 platform data : i2c register mode with new eeprom data + +#define EEPROM_A5_ADDR 0xA5 +#define EEPROM_A5_VAL 0x4f /* EN_VSYNC=0 */ + +static struct lp855x_rom_data lp8552_eeprom_arr[] = { + {EEPROM_A5_ADDR, EEPROM_A5_VAL}, +}; + +static struct lp855x_platform_data lp8552_pdata = { + .name = "lcd-bl", + .mode = REGISTER_BASED, + .device_control = I2C_CONFIG(LP8552), + .initial_brightness = INITIAL_BRT, + .load_new_rom_data = 1, + .size_program = ARRAY_SIZE(lp8552_eeprom_arr), + .rom_data = lp8552_eeprom_arr, +}; + +example 2) lp8556 platform data : pwm input mode with default rom data + +static struct lp855x_platform_data lp8556_pdata = { + .mode = PWM_BASED, + .device_control = PWM_CONFIG(LP8556), + .initial_brightness = INITIAL_BRT, + .pwm_data = { + .pwm_set_intensity = platform_pwm_set_intensity, + .pwm_get_intensity = platform_pwm_get_intensity, + }, +}; -- cgit v1.1 From 5ae4e8a77dc82afcfe8460168ec0b94f4b79a54a Mon Sep 17 00:00:00 2001 From: "Kim, Milo" Date: Fri, 23 Mar 2012 15:02:08 -0700 Subject: drivers/leds/leds-lp5521.c: add 'name' in the lp5521_led_config The name of each led channel can be configurable. For the compatibility, the name is set to default value(xx:channelN) when 'name' is not defined. Signed-off-by: Milo(Woogyom) Kim Acked-by: Linus Walleij Cc: Arun MURTHY Cc: Srinidhi Kasagar Cc: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/leds/leds-lp5521.txt | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'Documentation') diff --git a/Documentation/leds/leds-lp5521.txt b/Documentation/leds/leds-lp5521.txt index c4d8d15..f48ab75 100644 --- a/Documentation/leds/leds-lp5521.txt +++ b/Documentation/leds/leds-lp5521.txt @@ -43,17 +43,23 @@ Format: 10x mA i.e 10 means 1.0 mA example platform data: Note: chan_nr can have values between 0 and 2. +The name of each channel can be configurable. +If the name field is not defined, the default name will be set to 'xxxx:channelN' +(XXXX : pdata->label or i2c client name, N : channel number) static struct lp5521_led_config lp5521_led_config[] = { { + .name = "red", .chan_nr = 0, .led_current = 50, .max_current = 130, }, { + .name = "green", .chan_nr = 1, .led_current = 0, .max_current = 130, }, { + .name = "blue", .chan_nr = 2, .led_current = 0, .max_current = 130, -- cgit v1.1 From 3b49aacd0e56d5bf1b511f6554f17cd65eb8da64 Mon Sep 17 00:00:00 2001 From: "Kim, Milo" Date: Fri, 23 Mar 2012 15:02:08 -0700 Subject: drivers/leds/leds-lp5521.c: add 'update_config' in the lp5521_platform_data The value of CONFIG register(Addr 08h) is configurable. For supporting this feature, update_config is added in the platform data. If 'update_config' is not defined, the default value is 'LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT'. To define CONFIG register in the platform data, the bit definitions were mo= ved to the header file. Documentation updated : description about 'update_config' and example. Signed-off-by: Milo(Woogyom) Kim Acked-by: Linus Walleij Cc: Arun MURTHY Cc: Srinidhi Kasagar Cc: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/leds/leds-lp5521.txt | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) (limited to 'Documentation') diff --git a/Documentation/leds/leds-lp5521.txt b/Documentation/leds/leds-lp5521.txt index f48ab75..e3c66c6 100644 --- a/Documentation/leds/leds-lp5521.txt +++ b/Documentation/leds/leds-lp5521.txt @@ -92,3 +92,22 @@ static struct lp5521_platform_data lp5521_platform_data = { If the current is set to 0 in the platform data, that channel is disabled and it is not visible in the sysfs. + +The 'update_config' : CONFIG register (ADDR 08h) +This value is platform-specific data. +If update_config is not defined, the CONFIG register is set with +'LP5521_PWRSAVE_EN | LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT'. +(Enable auto-powersave, set charge pump to auto, red to battery) + +example of update_config : + +#define LP5521_CONFIGS (LP5521_PWM_HF | LP5521_PWRSAVE_EN | \ + LP5521_CP_MODE_AUTO | LP5521_R_TO_BATT | \ + LP5521_CLK_INT) + +static struct lp5521_platform_data lp5521_pdata = { + .led_config = lp5521_led_config, + .num_channels = ARRAY_SIZE(lp5521_led_config), + .clock_mode = LP5521_CLOCK_INT, + .update_config = LP5521_CONFIGS, +}; -- cgit v1.1 From 011af7bc7cd188a0310e2d26cdc2cc5d90148b0c Mon Sep 17 00:00:00 2001 From: "Kim, Milo" Date: Fri, 23 Mar 2012 15:02:09 -0700 Subject: drivers/leds/leds-lp5521.c: support led pattern data The lp5521 has autonomous operation mode without external control. Using lp5521_platform_data, various led patterns can be configurable. For supporting this feature, new functions and device attribute are added. Structure of lp5521_led_pattern: 3 channels are supported - red, green and blue. Pattern(s) of each channel and numbers of pattern(s) are defined in the pla= tform data. Pattern data are hexa codes which include pattern commands such like set pwm, wait, ramp up/down, branch and so on. Pattern mode functions: * lp5521_clear_program_memory Before running new led pattern, program memory should be cleared. * lp5521_write_program_memory Pattern data updated in the program memory via the i2c. * lp5521_get_pattern Get pattern from predefined in the platform data. * lp5521_run_led_pattern Stop current pattern or run new pattern. Transition time is required between different operation mode. Device attribute - 'led_pattern': To load specific led pattern, new device attribute is added. When the lp5521 driver is unloaded, stop current led pattern mode. Documentation updated : description about how to define the led patterns and example. [akpm@linux-foundation.org: checkpatch fixes] Signed-off-by: Milo(Woogyom) Kim Acked-by: Linus Walleij Cc: Arun MURTHY Cc: Srinidhi Kasagar Cc: Richard Purdie Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/leds/leds-lp5521.txt | 38 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 38 insertions(+) (limited to 'Documentation') diff --git a/Documentation/leds/leds-lp5521.txt b/Documentation/leds/leds-lp5521.txt index e3c66c6..0e542ab 100644 --- a/Documentation/leds/leds-lp5521.txt +++ b/Documentation/leds/leds-lp5521.txt @@ -111,3 +111,41 @@ static struct lp5521_platform_data lp5521_pdata = { .clock_mode = LP5521_CLOCK_INT, .update_config = LP5521_CONFIGS, }; + +LED patterns : LP5521 has autonomous operation without external control. +Pattern data can be defined in the platform data. + +example of led pattern data : + +/* RGB(50,5,0) 500ms on, 500ms off, infinite loop */ +static u8 pattern_red[] = { + 0x40, 0x32, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00, + }; + +static u8 pattern_green[] = { + 0x40, 0x05, 0x60, 0x00, 0x40, 0x00, 0x60, 0x00, + }; + +static struct lp5521_led_pattern board_led_patterns[] = { + { + .r = pattern_red, + .g = pattern_green, + .size_r = ARRAY_SIZE(pattern_red), + .size_g = ARRAY_SIZE(pattern_green), + }, +}; + +static struct lp5521_platform_data lp5521_platform_data = { + .led_config = lp5521_led_config, + .num_channels = ARRAY_SIZE(lp5521_led_config), + .clock_mode = LP5521_CLOCK_EXT, + .patterns = board_led_patterns, + .num_patterns = ARRAY_SIZE(board_led_patterns), +}; + +Then predefined led pattern(s) can be executed via the sysfs. +To start the pattern #1, +# echo 1 > /sys/bus/i2c/devices/xxxx/led_pattern +(xxxx : i2c bus & slave address) +To end the pattern, +# echo 0 > /sys/bus/i2c/devices/xxxx/led_pattern -- cgit v1.1 From fbedceb10066430b925cf43fbf926e8abb9e2359 Mon Sep 17 00:00:00 2001 From: Bob Pearson Date: Fri, 23 Mar 2012 15:02:22 -0700 Subject: crc32: move long comment about crc32 fundamentals to Documentation/ Move a long comment from lib/crc32.c to Documentation/crc32.txt where it will more likely get read. Edited the resulting document to add an explanation of the slicing-by-n algorithm. [djwong@us.ibm.com: minor changelog tweaks] [akpm@linux-foundation.org: fix typo, per George] Signed-off-by: George Spelvin Signed-off-by: Bob Pearson Signed-off-by: Darrick J. Wong Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/00-INDEX | 2 + Documentation/crc32.txt | 182 ++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 184 insertions(+) create mode 100644 Documentation/crc32.txt (limited to 'Documentation') diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index a1a6432..2214f12 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -104,6 +104,8 @@ cpuidle/ - info on CPU_IDLE, CPU idle state management subsystem. cputopology.txt - documentation on how CPU topology info is exported via sysfs. +crc32.txt + - brief tutorial on CRC computation cris/ - directory with info about Linux on CRIS architecture. crypto/ diff --git a/Documentation/crc32.txt b/Documentation/crc32.txt new file mode 100644 index 0000000..a08a7dd --- /dev/null +++ b/Documentation/crc32.txt @@ -0,0 +1,182 @@ +A brief CRC tutorial. + +A CRC is a long-division remainder. You add the CRC to the message, +and the whole thing (message+CRC) is a multiple of the given +CRC polynomial. To check the CRC, you can either check that the +CRC matches the recomputed value, *or* you can check that the +remainder computed on the message+CRC is 0. This latter approach +is used by a lot of hardware implementations, and is why so many +protocols put the end-of-frame flag after the CRC. + +It's actually the same long division you learned in school, except that +- We're working in binary, so the digits are only 0 and 1, and +- When dividing polynomials, there are no carries. Rather than add and + subtract, we just xor. Thus, we tend to get a bit sloppy about + the difference between adding and subtracting. + +Like all division, the remainder is always smaller than the divisor. +To produce a 32-bit CRC, the divisor is actually a 33-bit CRC polynomial. +Since it's 33 bits long, bit 32 is always going to be set, so usually the +CRC is written in hex with the most significant bit omitted. (If you're +familiar with the IEEE 754 floating-point format, it's the same idea.) + +Note that a CRC is computed over a string of *bits*, so you have +to decide on the endianness of the bits within each byte. To get +the best error-detecting properties, this should correspond to the +order they're actually sent. For example, standard RS-232 serial is +little-endian; the most significant bit (sometimes used for parity) +is sent last. And when appending a CRC word to a message, you should +do it in the right order, matching the endianness. + +Just like with ordinary division, you proceed one digit (bit) at a time. +Each step of the division you take one more digit (bit) of the dividend +and append it to the current remainder. Then you figure out the +appropriate multiple of the divisor to subtract to being the remainder +back into range. In binary, this is easy - it has to be either 0 or 1, +and to make the XOR cancel, it's just a copy of bit 32 of the remainder. + +When computing a CRC, we don't care about the quotient, so we can +throw the quotient bit away, but subtract the appropriate multiple of +the polynomial from the remainder and we're back to where we started, +ready to process the next bit. + +A big-endian CRC written this way would be coded like: +for (i = 0; i < input_bits; i++) { + multiple = remainder & 0x80000000 ? CRCPOLY : 0; + remainder = (remainder << 1 | next_input_bit()) ^ multiple; +} + +Notice how, to get at bit 32 of the shifted remainder, we look +at bit 31 of the remainder *before* shifting it. + +But also notice how the next_input_bit() bits we're shifting into +the remainder don't actually affect any decision-making until +32 bits later. Thus, the first 32 cycles of this are pretty boring. +Also, to add the CRC to a message, we need a 32-bit-long hole for it at +the end, so we have to add 32 extra cycles shifting in zeros at the +end of every message, + +These details lead to a standard trick: rearrange merging in the +next_input_bit() until the moment it's needed. Then the first 32 cycles +can be precomputed, and merging in the final 32 zero bits to make room +for the CRC can be skipped entirely. This changes the code to: + +for (i = 0; i < input_bits; i++) { + remainder ^= next_input_bit() << 31; + multiple = (remainder & 0x80000000) ? CRCPOLY : 0; + remainder = (remainder << 1) ^ multiple; +} + +With this optimization, the little-endian code is particularly simple: +for (i = 0; i < input_bits; i++) { + remainder ^= next_input_bit(); + multiple = (remainder & 1) ? CRCPOLY : 0; + remainder = (remainder >> 1) ^ multiple; +} + +The most significant coefficient of the remainder polynomial is stored +in the least significant bit of the binary "remainder" variable. +The other details of endianness have been hidden in CRCPOLY (which must +be bit-reversed) and next_input_bit(). + +As long as next_input_bit is returning the bits in a sensible order, we don't +*have* to wait until the last possible moment to merge in additional bits. +We can do it 8 bits at a time rather than 1 bit at a time: +for (i = 0; i < input_bytes; i++) { + remainder ^= next_input_byte() << 24; + for (j = 0; j < 8; j++) { + multiple = (remainder & 0x80000000) ? CRCPOLY : 0; + remainder = (remainder << 1) ^ multiple; + } +} + +Or in little-endian: +for (i = 0; i < input_bytes; i++) { + remainder ^= next_input_byte(); + for (j = 0; j < 8; j++) { + multiple = (remainder & 1) ? CRCPOLY : 0; + remainder = (remainder >> 1) ^ multiple; + } +} + +If the input is a multiple of 32 bits, you can even XOR in a 32-bit +word at a time and increase the inner loop count to 32. + +You can also mix and match the two loop styles, for example doing the +bulk of a message byte-at-a-time and adding bit-at-a-time processing +for any fractional bytes at the end. + +To reduce the number of conditional branches, software commonly uses +the byte-at-a-time table method, popularized by Dilip V. Sarwate, +"Computation of Cyclic Redundancy Checks via Table Look-Up", Comm. ACM +v.31 no.8 (August 1998) p. 1008-1013. + +Here, rather than just shifting one bit of the remainder to decide +in the correct multiple to subtract, we can shift a byte at a time. +This produces a 40-bit (rather than a 33-bit) intermediate remainder, +and the correct multiple of the polynomial to subtract is found using +a 256-entry lookup table indexed by the high 8 bits. + +(The table entries are simply the CRC-32 of the given one-byte messages.) + +When space is more constrained, smaller tables can be used, e.g. two +4-bit shifts followed by a lookup in a 16-entry table. + +It is not practical to process much more than 8 bits at a time using this +technique, because tables larger than 256 entries use too much memory and, +more importantly, too much of the L1 cache. + +To get higher software performance, a "slicing" technique can be used. +See "High Octane CRC Generation with the Intel Slicing-by-8 Algorithm", +ftp://download.intel.com/technology/comms/perfnet/download/slicing-by-8.pdf + +This does not change the number of table lookups, but does increase +the parallelism. With the classic Sarwate algorithm, each table lookup +must be completed before the index of the next can be computed. + +A "slicing by 2" technique would shift the remainder 16 bits at a time, +producing a 48-bit intermediate remainder. Rather than doing a single +lookup in a 65536-entry table, the two high bytes are looked up in +two different 256-entry tables. Each contains the remainder required +to cancel out the corresponding byte. The tables are different because the +polynomials to cancel are different. One has non-zero coefficients from +x^32 to x^39, while the other goes from x^40 to x^47. + +Since modern processors can handle many parallel memory operations, this +takes barely longer than a single table look-up and thus performs almost +twice as fast as the basic Sarwate algorithm. + +This can be extended to "slicing by 4" using 4 256-entry tables. +Each step, 32 bits of data is fetched, XORed with the CRC, and the result +broken into bytes and looked up in the tables. Because the 32-bit shift +leaves the low-order bits of the intermediate remainder zero, the +final CRC is simply the XOR of the 4 table look-ups. + +But this still enforces sequential execution: a second group of table +look-ups cannot begin until the previous groups 4 table look-ups have all +been completed. Thus, the processor's load/store unit is sometimes idle. + +To make maximum use of the processor, "slicing by 8" performs 8 look-ups +in parallel. Each step, the 32-bit CRC is shifted 64 bits and XORed +with 64 bits of input data. What is important to note is that 4 of +those 8 bytes are simply copies of the input data; they do not depend +on the previous CRC at all. Thus, those 4 table look-ups may commence +immediately, without waiting for the previous loop iteration. + +By always having 4 loads in flight, a modern superscalar processor can +be kept busy and make full use of its L1 cache. + +Two more details about CRC implementation in the real world: + +Normally, appending zero bits to a message which is already a multiple +of a polynomial produces a larger multiple of that polynomial. Thus, +a basic CRC will not detect appended zero bits (or bytes). To enable +a CRC to detect this condition, it's common to invert the CRC before +appending it. This makes the remainder of the message+crc come out not +as zero, but some fixed non-zero value. (The CRC of the inversion +pattern, 0xffffffff.) + +The same problem applies to zero bits prepended to the message, and a +similar solution is used. Instead of starting the CRC computation with +a remainder of 0, an initial remainder of all ones is used. As long as +you start the same way on decoding, it doesn't make a difference. -- cgit v1.1