Loading Documentation/DocBook/uio-howto.tmpl +3 −3 Original line number Original line Diff line number Diff line Loading @@ -16,7 +16,7 @@ </orgname> </orgname> <address> <address> <email>hjk@linutronix.de</email> <email>hjk@hansjkoch.de</email> </address> </address> </affiliation> </affiliation> </author> </author> Loading Loading @@ -114,7 +114,7 @@ GPL version 2. <para>If you know of any translations for this document, or you are <para>If you know of any translations for this document, or you are interested in translating it, please email me interested in translating it, please email me <email>hjk@linutronix.de</email>. <email>hjk@hansjkoch.de</email>. </para> </para> </sect1> </sect1> Loading Loading @@ -171,7 +171,7 @@ interested in translating it, please email me <title>Feedback</title> <title>Feedback</title> <para>Find something wrong with this document? (Or perhaps something <para>Find something wrong with this document? (Or perhaps something right?) I would love to hear from you. Please email me at right?) I would love to hear from you. Please email me at <email>hjk@linutronix.de</email>.</para> <email>hjk@hansjkoch.de</email>.</para> </sect1> </sect1> </chapter> </chapter> Loading Documentation/arm/OMAP/DSS +4 −3 Original line number Original line Diff line number Diff line Loading @@ -255,9 +255,10 @@ framebuffer parameters. Kernel boot arguments Kernel boot arguments --------------------- --------------------- vram=<size> vram=<size>[,<physaddr>] - Amount of total VRAM to preallocate. For example, "10M". omapfb - Amount of total VRAM to preallocate and optionally a physical start allocates memory for framebuffers from VRAM. memory address. For example, "10M". omapfb allocates memory for framebuffers from VRAM. omapfb.mode=<display>:<mode>[,...] omapfb.mode=<display>:<mode>[,...] - Default video mode for specified displays. For example, - Default video mode for specified displays. For example, Loading Documentation/development-process/2.Process +23 −10 Original line number Original line Diff line number Diff line Loading @@ -154,7 +154,7 @@ The stages that a patch goes through are, generally: inclusion, it should be accepted by a relevant subsystem maintainer - inclusion, it should be accepted by a relevant subsystem maintainer - though this acceptance is not a guarantee that the patch will make it 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 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 process works, this step leads to more extensive review of the patch and the discovery of any problems resulting from the integration of this the discovery of any problems resulting from the integration of this patch with work being done by others. patch with work being done by others. Loading Loading @@ -236,7 +236,7 @@ finding the right maintainer. Sending patches directly to Linus is not normally the right way to go. 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, 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 but it also raises an interesting question: what if somebody wants to look Loading @@ -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 the interesting subsystem trees, but that would be a big and error-prone job. 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 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 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 started). The -mm tree integrates patches from a long list of subsystem Loading @@ -275,7 +275,7 @@ directory at: Use of the MMOTM tree is likely to be a frustrating experience, though; Use of the MMOTM tree is likely to be a frustrating experience, though; there is a definite chance that it will not even compile. 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 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. 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 Linux-next trees are announced on the linux-kernel and linux-next mailing Loading Loading @@ -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 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. 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 2.4.1: STAGING TREES the drivers/staging/ directory and many sub-directories for drivers or filesystems that are on their way to being added to the kernel tree The kernel source tree now contains the drivers/staging/ directory, where proper, but they remain in drivers/staging/ while they still need more many sub-directories for drivers or filesystems that are on their way to work. 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 2.5: TOOLS Loading Documentation/feature-removal-schedule.txt +10 −0 Original line number Original line Diff line number Diff line Loading @@ -554,3 +554,13 @@ Why: This is a legacy interface which have been replaced by a more Who: NeilBrown <neilb@suse.de> Who: NeilBrown <neilb@suse.de> ---------------------------- ---------------------------- What: i2c_adapter.id When: June 2011 Why: This field is deprecated. I2C device drivers shouldn't change their behavior based on the underlying I2C adapter. Instead, the I2C adapter driver should instantiate the I2C devices and provide the needed platform-specific information. Who: Jean Delvare <khali@linux-fr.org> ---------------------------- Documentation/filesystems/configfs/configfs_example_explicit.c +1 −1 Original line number Original line Diff line number Diff line Loading @@ -89,7 +89,7 @@ static ssize_t childless_storeme_write(struct childless *childless, char *p = (char *) page; char *p = (char *) page; tmp = simple_strtoul(p, &p, 10); tmp = simple_strtoul(p, &p, 10); if (!p || (*p && (*p != '\n'))) if ((*p != '\0') && (*p != '\n')) return -EINVAL; return -EINVAL; if (tmp > INT_MAX) if (tmp > INT_MAX) Loading Loading
Documentation/DocBook/uio-howto.tmpl +3 −3 Original line number Original line Diff line number Diff line Loading @@ -16,7 +16,7 @@ </orgname> </orgname> <address> <address> <email>hjk@linutronix.de</email> <email>hjk@hansjkoch.de</email> </address> </address> </affiliation> </affiliation> </author> </author> Loading Loading @@ -114,7 +114,7 @@ GPL version 2. <para>If you know of any translations for this document, or you are <para>If you know of any translations for this document, or you are interested in translating it, please email me interested in translating it, please email me <email>hjk@linutronix.de</email>. <email>hjk@hansjkoch.de</email>. </para> </para> </sect1> </sect1> Loading Loading @@ -171,7 +171,7 @@ interested in translating it, please email me <title>Feedback</title> <title>Feedback</title> <para>Find something wrong with this document? (Or perhaps something <para>Find something wrong with this document? (Or perhaps something right?) I would love to hear from you. Please email me at right?) I would love to hear from you. Please email me at <email>hjk@linutronix.de</email>.</para> <email>hjk@hansjkoch.de</email>.</para> </sect1> </sect1> </chapter> </chapter> Loading
Documentation/arm/OMAP/DSS +4 −3 Original line number Original line Diff line number Diff line Loading @@ -255,9 +255,10 @@ framebuffer parameters. Kernel boot arguments Kernel boot arguments --------------------- --------------------- vram=<size> vram=<size>[,<physaddr>] - Amount of total VRAM to preallocate. For example, "10M". omapfb - Amount of total VRAM to preallocate and optionally a physical start allocates memory for framebuffers from VRAM. memory address. For example, "10M". omapfb allocates memory for framebuffers from VRAM. omapfb.mode=<display>:<mode>[,...] omapfb.mode=<display>:<mode>[,...] - Default video mode for specified displays. For example, - Default video mode for specified displays. For example, Loading
Documentation/development-process/2.Process +23 −10 Original line number Original line Diff line number Diff line Loading @@ -154,7 +154,7 @@ The stages that a patch goes through are, generally: inclusion, it should be accepted by a relevant subsystem maintainer - inclusion, it should be accepted by a relevant subsystem maintainer - though this acceptance is not a guarantee that the patch will make it 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 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 process works, this step leads to more extensive review of the patch and the discovery of any problems resulting from the integration of this the discovery of any problems resulting from the integration of this patch with work being done by others. patch with work being done by others. Loading Loading @@ -236,7 +236,7 @@ finding the right maintainer. Sending patches directly to Linus is not normally the right way to go. 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, 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 but it also raises an interesting question: what if somebody wants to look Loading @@ -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 the interesting subsystem trees, but that would be a big and error-prone job. 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 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 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 started). The -mm tree integrates patches from a long list of subsystem Loading @@ -275,7 +275,7 @@ directory at: Use of the MMOTM tree is likely to be a frustrating experience, though; Use of the MMOTM tree is likely to be a frustrating experience, though; there is a definite chance that it will not even compile. 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 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. 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 Linux-next trees are announced on the linux-kernel and linux-next mailing Loading Loading @@ -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 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. 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 2.4.1: STAGING TREES the drivers/staging/ directory and many sub-directories for drivers or filesystems that are on their way to being added to the kernel tree The kernel source tree now contains the drivers/staging/ directory, where proper, but they remain in drivers/staging/ while they still need more many sub-directories for drivers or filesystems that are on their way to work. 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 2.5: TOOLS Loading
Documentation/feature-removal-schedule.txt +10 −0 Original line number Original line Diff line number Diff line Loading @@ -554,3 +554,13 @@ Why: This is a legacy interface which have been replaced by a more Who: NeilBrown <neilb@suse.de> Who: NeilBrown <neilb@suse.de> ---------------------------- ---------------------------- What: i2c_adapter.id When: June 2011 Why: This field is deprecated. I2C device drivers shouldn't change their behavior based on the underlying I2C adapter. Instead, the I2C adapter driver should instantiate the I2C devices and provide the needed platform-specific information. Who: Jean Delvare <khali@linux-fr.org> ----------------------------
Documentation/filesystems/configfs/configfs_example_explicit.c +1 −1 Original line number Original line Diff line number Diff line Loading @@ -89,7 +89,7 @@ static ssize_t childless_storeme_write(struct childless *childless, char *p = (char *) page; char *p = (char *) page; tmp = simple_strtoul(p, &p, 10); tmp = simple_strtoul(p, &p, 10); if (!p || (*p && (*p != '\n'))) if ((*p != '\0') && (*p != '\n')) return -EINVAL; return -EINVAL; if (tmp > INT_MAX) if (tmp > INT_MAX) Loading
