From 43e60861fe9d39740cf5b355f58fecedf0d8e9ba Mon Sep 17 00:00:00 2001 From: Mark Brown Date: Thu, 11 Nov 2010 01:51:26 +0100 Subject: PM / OPP: Hide OPP configuration when SoCs do not provide an implementation Since the OPP API is only useful with an appropraite SoC-specific implementation there is no point in offering the ability to enable the API on general systems. Provide an ARCH_HAS OPP Kconfig symbol which masks out the option unless selected by an implementation. Signed-off-by: Mark Brown Acked-by: Nishanth Menon Acked-by: Kevin Hilman Signed-off-by: Rafael J. Wysocki --- Documentation/power/opp.txt | 3 +++ 1 file changed, 3 insertions(+) (limited to 'Documentation') diff --git a/Documentation/power/opp.txt b/Documentation/power/opp.txt index 44d87ad3cea..cd445582d1f 100644 --- a/Documentation/power/opp.txt +++ b/Documentation/power/opp.txt @@ -37,6 +37,9 @@ Typical usage of the OPP library is as follows: SoC framework -> modifies on required cases certain OPPs -> OPP layer -> queries to search/retrieve information -> +Architectures that provide a SoC framework for OPP should select ARCH_HAS_OPP +to make the OPP layer available. + OPP layer expects each domain to be represented by a unique device pointer. SoC framework registers a set of initial OPPs per device with the OPP layer. This list is expected to be an optimally small number typically around 5 per device. -- cgit v1.2.2 From 09c9feb94672bdb3ca6d424a292ffc26eff8ca0b Mon Sep 17 00:00:00 2001 From: Dan Carpenter Date: Thu, 18 Nov 2010 12:27:32 -0800 Subject: Documentation: make configfs example code simpler, clearer If "p" is NULL then it will cause an oops when we pass it to simple_strtoul(). In this case "p" can not be NULL so I removed the check. I also changed the check a little to make it more explicit that we are testing whether p points to the NUL char. Signed-off-by: Dan Carpenter Acked-by: Joel Becker Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/filesystems/configfs/configfs_example_explicit.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/filesystems/configfs/configfs_example_explicit.c b/Documentation/filesystems/configfs/configfs_example_explicit.c index d428cc9f07f..fd53869f563 100644 --- a/Documentation/filesystems/configfs/configfs_example_explicit.c +++ b/Documentation/filesystems/configfs/configfs_example_explicit.c @@ -89,7 +89,7 @@ static ssize_t childless_storeme_write(struct childless *childless, char *p = (char *) page; tmp = simple_strtoul(p, &p, 10); - if (!p || (*p && (*p != '\n'))) + if ((*p != '\0') && (*p != '\n')) return -EINVAL; if (tmp > INT_MAX) -- cgit v1.2.2 From ebde7b062cd9e2ea968c93f23f73dd28c0a192d1 Mon Sep 17 00:00:00 2001 From: Bernhard Walle Date: Thu, 18 Nov 2010 12:27:33 -0800 Subject: Documentation/gpio.txt: explain poll/select usage Add a bit more information how to use poll(2) on GPIO value files correctly. For me it was not clear that I need to poll(2) for POLLPRI|POLLERR or select(2) for exceptfds. Signed-off-by: Bernhard Walle Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/gpio.txt | 10 ++++++++++ 1 file changed, 10 insertions(+) (limited to 'Documentation') diff --git a/Documentation/gpio.txt b/Documentation/gpio.txt index 9633da01ff4..792faa3c06c 100644 --- a/Documentation/gpio.txt +++ b/Documentation/gpio.txt @@ -617,6 +617,16 @@ and have the following read/write attributes: is configured as an output, this value may be written; any nonzero value is treated as high. + If the pin can be configured as interrupt-generating interrupt + and if it has been configured to generate interrupts (see the + description of "edge"), you can poll(2) on that file and + poll(2) will return whenever the interrupt was triggered. If + you use poll(2), set the events POLLPRI and POLLERR. If you + use select(2), set the file descriptor in exceptfds. After + poll(2) returns, either lseek(2) to the beginning of the sysfs + file and read the new value or close the file and re-open it + to read the value. + "edge" ... reads as either "none", "rising", "falling", or "both". Write these strings to select the signal edge(s) that will make poll(2) on the "value" file return. -- cgit v1.2.2 From f99e0e98f95bbe8833bd96c314b71ef859851bc5 Mon Sep 17 00:00:00 2001 From: "Hans J. Koch" Date: Thu, 18 Nov 2010 12:27:34 -0800 Subject: Documentation: change email address for Hans Koch My old mail address doesn't exist anymore. This changes all occurrences to my new address. Signed-off-by: Hans J. Koch Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/DocBook/uio-howto.tmpl | 6 +++--- Documentation/hwmon/lm93 | 2 +- Documentation/hwmon/max6650 | 2 +- 3 files changed, 5 insertions(+), 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/DocBook/uio-howto.tmpl b/Documentation/DocBook/uio-howto.tmpl index 4d4ce0e61e4..b4665b9c40b 100644 --- a/Documentation/DocBook/uio-howto.tmpl +++ b/Documentation/DocBook/uio-howto.tmpl @@ -16,7 +16,7 @@
- hjk@linutronix.de + hjk@hansjkoch.de
@@ -114,7 +114,7 @@ GPL version 2. If you know of any translations for this document, or you are interested in translating it, please email me -hjk@linutronix.de. +hjk@hansjkoch.de. @@ -171,7 +171,7 @@ interested in translating it, please email me Feedback Find something wrong with this document? (Or perhaps something right?) I would love to hear from you. Please email me at - hjk@linutronix.de. + hjk@hansjkoch.de. diff --git a/Documentation/hwmon/lm93 b/Documentation/hwmon/lm93 index ac711f357fa..7a10616d0b4 100644 --- a/Documentation/hwmon/lm93 +++ b/Documentation/hwmon/lm93 @@ -11,7 +11,7 @@ Authors: Mark M. Hoffman Ported to 2.6 by Eric J. Bowersox Adapted to 2.6.20 by Carsten Emde - Modified for mainline integration by Hans J. Koch + Modified for mainline integration by Hans J. Koch Module Parameters ----------------- diff --git a/Documentation/hwmon/max6650 b/Documentation/hwmon/max6650 index 8be7beb9e3e..c565650fcfc 100644 --- a/Documentation/hwmon/max6650 +++ b/Documentation/hwmon/max6650 @@ -8,7 +8,7 @@ Supported chips: Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6650-MAX6651.pdf Authors: - Hans J. Koch + Hans J. Koch John Morris Claus Gindhart -- cgit v1.2.2 From e4fabad30eaba5bb78cd8d47885f1b705a0918a0 Mon Sep 17 00:00:00 2001 From: Andres Salomon Date: Thu, 18 Nov 2010 12:27:35 -0800 Subject: Documentation/development-process: use -next trees instead of staging This is confusing, as we have "staging" trees for drivers/staging. Call them -next trees. Signed-off-by: Andres Salomon Acked-by: Greg Kroah-Hartman Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/development-process/2.Process | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process index 97726eba610..ae8127c1a78 100644 --- a/Documentation/development-process/2.Process +++ b/Documentation/development-process/2.Process @@ -154,7 +154,7 @@ The stages that a patch goes through are, generally: inclusion, it should be accepted by a relevant subsystem maintainer - though this acceptance is not a guarantee that the patch will make it all the way to the mainline. The patch will show up in the maintainer's - subsystem tree and into the staging trees (described below). When the + subsystem tree and into the -next trees (described below). When the process works, this step leads to more extensive review of the patch and the discovery of any problems resulting from the integration of this patch with work being done by others. @@ -236,7 +236,7 @@ finding the right maintainer. Sending patches directly to Linus is not normally the right way to go. -2.4: STAGING TREES +2.4: NEXT TREES The chain of subsystem trees guides the flow of patches into the kernel, but it also raises an interesting question: what if somebody wants to look @@ -250,7 +250,7 @@ changes land in the mainline kernel. One could pull changes from all of the interesting subsystem trees, but that would be a big and error-prone job. -The answer comes in the form of staging trees, where subsystem trees are +The answer comes in the form of -next trees, where subsystem trees are collected for testing and review. The older of these trees, maintained by Andrew Morton, is called "-mm" (for memory management, which is how it got started). The -mm tree integrates patches from a long list of subsystem @@ -275,7 +275,7 @@ directory at: Use of the MMOTM tree is likely to be a frustrating experience, though; there is a definite chance that it will not even compile. -The other staging tree, started more recently, is linux-next, maintained by +The other -next tree, started more recently, is linux-next, maintained by Stephen Rothwell. The linux-next tree is, by design, a snapshot of what the mainline is expected to look like after the next merge window closes. Linux-next trees are announced on the linux-kernel and linux-next mailing -- cgit v1.2.2 From f830673f6aa28741ff6993deade587c8550c1dd3 Mon Sep 17 00:00:00 2001 From: Andres Salomon Date: Thu, 18 Nov 2010 12:27:36 -0800 Subject: Documentation/development-process: more staging info Document things that I would've liked to have known when submitting a driver to gregkh for staging. Signed-off-by: Andres Salomon Acked-by: Greg Kroah-Hartman Signed-off-by: Randy Dunlap Signed-off-by: Linus Torvalds --- Documentation/development-process/2.Process | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-) (limited to 'Documentation') diff --git a/Documentation/development-process/2.Process b/Documentation/development-process/2.Process index ae8127c1a78..911a4518634 100644 --- a/Documentation/development-process/2.Process +++ b/Documentation/development-process/2.Process @@ -303,12 +303,25 @@ volatility of linux-next tends to make it a difficult development target. See http://lwn.net/Articles/289013/ for more information on this topic, and stay tuned; much is still in flux where linux-next is involved. -Besides the mmotm and linux-next trees, the kernel source tree now contains -the drivers/staging/ directory and many sub-directories for drivers or -filesystems that are on their way to being added to the kernel tree -proper, but they remain in drivers/staging/ while they still need more -work. - +2.4.1: STAGING TREES + +The kernel source tree now contains the drivers/staging/ directory, where +many sub-directories for drivers or filesystems that are on their way to +being added to the kernel tree live. They remain in drivers/staging while +they still need more work; once complete, they can be moved into the +kernel proper. This is a way to keep track of drivers that aren't +up to Linux kernel coding or quality standards, but people may want to use +them and track development. + +Greg Kroah-Hartman currently (as of 2.6.36) maintains the staging tree. +Drivers that still need work are sent to him, with each driver having +its own subdirectory in drivers/staging/. Along with the driver source +files, a TODO file should be present in the directory as well. The TODO +file lists the pending work that the driver needs for acceptance into +the kernel proper, as well as a list of people that should be Cc'd for any +patches to the driver. Staging drivers that don't currently build should +have their config entries depend upon CONFIG_BROKEN. Once they can +be successfully built without outside patches, CONFIG_BROKEN can be removed. 2.5: TOOLS -- cgit v1.2.2