Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

[Julia Lawall]

On Mon, 19 Sep 2016, Joe Perches wrote:

> On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote:
> > IMO what we need is to go through all rules in CodingStyle and if for
> > some rule there is no overwhelming majority in the core kernel, well,
> > the list has grown way too large and could use massive trimming.
>
> I'm in complete agreement.
>
> I also think that checkpatch's ERROR/WARNING/CHECK message naming is
> far too severe and injunctive and could use a renaming to something
> more silly, bug related and less commanding like FLEAS/GNATS/NITS.

I think it is better to be clear.  CHECK was never really clear to me,
especially if you see it in isolation, on a file that doesn't also have
ERROR or WARNING.  NITS is a common word in this context, but not FLEAS
and GNATS, as far as I know.

There could also be a severity level: high medium and low.

julia

>
> --
> To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [linux-next] Fix double word "the the" in Doc/filesystems

[Masanari Iida]

This patch fix typos "the the" found in Documentation/filesystems.

Signed-off-by: Masanari Iida 
---
 Documentation/filesystems/autofs4-mount-control.txt | 10 +-
 Documentation/filesystems/directory-locking |  2 +-
 Documentation/filesystems/overlayfs.txt |  2 +-
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/Documentation/filesystems/autofs4-mount-control.txt 
b/Documentation/filesystems/autofs4-mount-control.txt
index 50a3e01a36f8..572f7e6612a6 100644
--- a/Documentation/filesystems/autofs4-mount-control.txt
+++ b/Documentation/filesystems/autofs4-mount-control.txt
@@ -386,8 +386,8 @@ variation uses the path and optionally in.type field of 
struct args_ismountpoint
 set to an autofs mount type. The call returns 1 if this is a mount point
 and sets out.devid field to the device number of the mount and out.magic
 field to the relevant super block magic number (described below) or 0 if
-it isn't a mountpoint. In both cases the the device number (as returned
-by new_encode_dev()) is returned in out.devid field.
+it isn't a mountpoint. In both cases the device number (as returned by
+new_encode_dev()) is returned in out.devid field.
 
 If supplied with a file descriptor we're looking for a specific mount,
 not necessarily at the top of the mounted stack. In this case the path
@@ -400,7 +400,7 @@ is one or 0 if it isn't a mountpoint.
 If a path is supplied (and the ioctlfd field is set to -1) then the path
 is looked up and is checked to see if it is the root of a mount. If a
 type is also given we are looking for a particular autofs mount and if
-a match isn't found a fail is returned. If the the located path is the
-root of a mount 1 is returned along with the super magic of the mount
-or 0 otherwise.
+a match isn't found a fail is returned. If the located path is the root
+of a mount 1 is returned along with the super magic of the mount or 0
+otherwise.
 
diff --git a/Documentation/filesystems/directory-locking 
b/Documentation/filesystems/directory-locking
index 4e32cb961e5b..fe38d83bc3de 100644
--- a/Documentation/filesystems/directory-locking
+++ b/Documentation/filesystems/directory-locking
@@ -23,7 +23,7 @@ RENAME_EXCHANGE in flags argument) lock both.  In any case,
 if the target already exists, lock it.  If the source is a non-directory,
 lock it.  If we need to lock both, lock them in inode pointer order.
 Then call the method.  All locks are exclusive.
-NB: we might get away with locking the the source (and target in exchange
+NB: we might get away with locking the source (and target in exchange
 case) shared.
 
 5) link creation.  Locking rules:
diff --git a/Documentation/filesystems/overlayfs.txt 
b/Documentation/filesystems/overlayfs.txt
index 4de8475e3a04..820203d87f63 100644
--- a/Documentation/filesystems/overlayfs.txt
+++ b/Documentation/filesystems/overlayfs.txt
@@ -163,7 +163,7 @@ rename or unlink will of course be noticed and handled).
 Multiple lower layers
 -
 
-Multiple lower layers can now be given using the the colon (":") as a
+Multiple lower layers can now be given using the colon (":") as a
 separator character between the directory names.  For example:
 
   mount -t overlay overlay -olowerdir=/lower1:/lower2:/lower3 /merged
-- 
2.10.0.177.ge510a86

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

[Joe Perches]

On Tue, 2016-09-20 at 01:11 +0100, Al Viro wrote:
> IMO what we need is to go through all rules in CodingStyle and if for
> some rule there is no overwhelming majority in the core kernel, well,
> the list has grown way too large and could use massive trimming.

I'm in complete agreement.

I also think that checkpatch's ERROR/WARNING/CHECK message naming is
far too severe and injunctive and could use a renaming to something
more silly, bug related and less commanding like FLEAS/GNATS/NITS.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/4] Update kernel-docs.rst

[Mauro Carvalho Chehab]

Em Tue, 20 Sep 2016 02:40:21 +0200
Richard Sailer  escreveu:

> I think kernel-docs.rst should be kept. (Or at least another/updated
> file fullfilling this purpose should exist) Therefore I put 
> some effort into updating it.
> 
> This patch relies on Mauros: 
>[Patch v2 ...] Create a book for Kernel development
> 
> 
> Summary
> ---
> This patch: 
> 
>  * Removes all the dead links according to Jon and Mauro in 
>https://lkml.kernel.org/r/20160916182849.2a7101ea () vento ! lan
> 
>  * Removes some very old articles covering linux 2.0 or 2.2 
>(I could have been cleaning up much more aggressive, but 
> I wanted to be carefull for the first patch. I can send a 
> further patch deleting several more IMHO outdated entries 
> if this is appreciated/wanted.)
> 
>  * Adds 4 recent books/articles, which are helpfull IMHO
> 
>  * Fixes some minor layouting and indentation issues

Thanks for the patch!

Some suggestions for future work:

1) It could be useful to also take a look on the docs pointed 
as "The latest version of this document":
http://www.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html

(I would actually remove it - or keep the above URL as a reference
at the end - as clearly the Kernel version diverged from the one
on that site)

2) It would also make sense to order the entries by publication
date, placing the newer ones before the old ones.

3) I would add some newer books too. The advantage of a book is that
the main development topics are all listed altogether. I have those 
books on my bookshelf, and found them useful to me by the time I
bought them (several years ago):


https://www.amazon.com/Embedded-Linux-Primer-Practical-Real-World/dp/0137017839/ref=pd_sim_14_8?ie=UTF8=1=HQ6TJW1RKA4YSH2PH9T9
(2011)

https://www.amazon.com/Essential-Device-Drivers-Sreekrishnan-Venkateswaran/dp/0132396556/ref=pd_sim_14_10?ie=UTF8=1=TWWS52NANC39MB11A6EC
(2008)

They're now a bit old, but still newer than the ones listed on
kernel-docs.rst (except or the Robert Love's book's reference,
with was updated to point to the newest version).

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] Update kernel-docs.rst

[Richard Sailer]

I think kernel-docs.rst should be kept. (Or at least another/updated
file fullfilling this purpose should exist) Therefore I put 
some effort into updating it.

This patch relies on Mauros: 
   [Patch v2 ...] Create a book for Kernel development


Summary
---
This patch: 

 * Removes all the dead links according to Jon and Mauro in 
   https://lkml.kernel.org/r/20160916182849.2a7101ea () vento ! lan

 * Removes some very old articles covering linux 2.0 or 2.2 
   (I could have been cleaning up much more aggressive, but 
I wanted to be carefull for the first patch. I can send a 
further patch deleting several more IMHO outdated entries 
if this is appreciated/wanted.)

 * Adds 4 recent books/articles, which are helpfull IMHO

 * Fixes some minor layouting and indentation issues


kernel-docs.rst: Remove offline or outdated entries
kernel-docs.rst: Improve layouting of book list
kernel-docs.rst: Add 4 paper/book references
kernel-docs.rst: Consistent indenting: 4 spaces
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/4] kernel-docs.rst: Add 4 paper/book references

[Richard Sailer]

Background/Reasoning:

Books:
--
 * Linux Kernel Networking by Rami Rosen
   While some parts are quite short and could be
   more carefully explained it's still a good recomendation
   for understanding linux kernel networking, (IMHO)

* Linux Treiber entwickeln:
  It sure is a drawback that this is a german book.
  But it's quite recent, well structured and there are also
  other non-english (spanish) books/papers in this list.

Papers:
---

  * On Submitting kernel Patches
Contains 2 case studies of bigger patch sets and how (or how not)
they were merged. I found it helpful

  * Tracing the Way of Data in a TCP Connection through the Linux Kernel
Since this was written by me this inclusion may be a bit biased :p
Neitherless I think this gives a good introduction on
understanding/exploring linux internals using ftrace and an overview
of Linux TCP internals.

Signed-off-by: Richard Sailer 
---
 Documentation/development-process/kernel-docs.rst | 45 +++
 1 file changed, 45 insertions(+)

diff --git a/Documentation/development-process/kernel-docs.rst 
b/Documentation/development-process/kernel-docs.rst
index 6f7d7de..177f7dc 100644
--- a/Documentation/development-process/kernel-docs.rst
+++ b/Documentation/development-process/kernel-docs.rst
@@ -156,6 +156,33 @@ ON-LINE DOCS
  device driver. It describes the code for module initialization and
  cleanup, as well as the open() and close() system calls*.
 
+ * Title: **On submitting kernel Patches**
+
+   :Author: Andi Kleen
+   :URL: http://halobates.de/on-submitting-kernel-patches.pdf
+   :Keywords: patches, review process, types of submissions, basic rules, 
case studies
+   :Description: This paper gives several experience values on what types 
of patches
+ there are and how likley they get merged.
+   :Abstract:
+ [...]. This paper examines some common problems for
+  submitting larger changes and some strategies to avoid problems.
+
+ * Title: **Tracing the Way of Data in a TCP Connection through the Linux 
Kernel**
+   :Author: Richard Sailer
+   :URL: https://archive.org/details/linux_kernel_data_flow_short_paper
+   :Keywords: Linux Kernel Networking, TCP, tracing, ftrace
+   :Description: A seminar paper explaining ftrace and how to use it for
+ understanding linux kernel internals,
+ illustrated at tracing the way of a TCP packet through the kernel.
+   :Abstract: *This short paper outlines the usage of ftrace a tracing 
framework
+ as a tool to understand a running Linux system.
+ Having obtained a trace-log a kernel hacker can read and understand
+ source code more determined and with context.
+ In a detailed example this approach is demonstrated in tracing
+ and the way of data in a TCP Connection through the kernel.
+ Finally this trace-log is used as base for more a exact conceptual
+ exploration and description of the Linux TCP/IP implementation.*
+
  * Title: **The Devil's in the Details**
 
:Author: Georg v. Zezschwitz and Alessandro Rubini.
@@ -547,6 +574,24 @@ BOOKS: (Not on-line)
:Pages: 440
:ISBN: 978-0672329463
 
+ * Title: **Linux Kernel Networking: Implementation and Theory**
+
+   :Author: Rami Rosen
+   :Publisher: Apress
+   :Date: December 22, 2013
+   :Pages: 648
+   :ISBN: 978-1430261964
+
+ * Title: **Linux Treiber entwickeln**
+
+   :Author: Jürgen Quade, Eva-Katharina Kunst
+   :Publisher: dpunkt.verlag
+   :Date: Oct 2015 (4th edition)
+   :Pages: 688
+   :ISBN: 978-3-86490-288-8
+   :Note: German. The third edition from 2011 is
+  much cheaper and still quite up-to-date.
+
 MISCELLANEOUS
 -
 
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/3] mm, proc: Implement /proc//totmaps

[Robert Foss]

On 2016-09-19 03:32 PM, Michal Hocko wrote:

On Mon 19-09-16 11:16:31, Robert Foss wrote:

On 2016-09-14 05:12 AM, Michal Hocko wrote:

On Tue 13-09-16 13:27:39, Sonny Rao wrote:

[...]

Given that smaps
doesn't provide this in a straightforward way, what do you think is
the right way to provide this information?


I would be tempted to sneak it into /proc//statm because that looks
like a proper place but getting this information is not for free
performance wise so I am not really sure something that relies on this
file would see unexpected stalls. Maybe this could be worked around by
some caching... I would suggest to check who is actually using this file
(top/ps etc...)


What would this caching look like? Can any information be re-used between
vma walks?


yes basically return the same value if called within HZ or something
similar. But that assumes that statm latency really matters and it is
called often enough.


Any single application querying more often than HZ, would presumably do 
so for accuracy reasons.
However for multiple applications that combined query more often than 
HZ, this would most definitely be halpful in terms of performance.


@Sonny, does chromiumos fall into the first or second category?
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: "CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

[Al Viro]

On Mon, Sep 19, 2016 at 01:53:37PM +0200, Ilya Dryomov wrote:
> > I did consider the reason to be good enough to warrant a "change",
> > actually. Or more exactly from "one space is allowed" to "one space is
> > recommended." Which is quite different from changing all the code
> > actively. I can understand how you don't like it, but again, this
> > "inconsistency" has been accepted for almost a decade now, so I find it
> > strange to see so much resistance when someone finally tries to sort it
> > out.
> 
> Yeah, I guess that's where our disagreement lies - the "so that `diff
> -p` does not confuse labels with functions" in the age of git, hg and
> others, all of which can be customized to your heart's content is not
> a good enough reason to go from "allowed" to "advised".

On the top of CodingStyle we have
"This is a short document describing the preferred coding style for the
linux kernel."

Let's make it s/describing/& (as in "descriptive, not prescriptive")/.
The lack of consensus (in the core kernel areas) is _not_ an invitation
to pick a rule out of one's arse/nose/armpit/textbook/whatnot and stick
it as The One True Style, and references to uniformity are worthless
in such case.

In particular, "whitespace before labels" kind of patches anywhere in
VFS will be simply rejected.

IMO what we need is to go through all rules in CodingStyle and if for
some rule there is no overwhelming majority in the core kernel, well,
the list has grown way too large and could use massive trimming.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/3] mm, proc: Implement /proc//totmaps

[Sonny Rao]

On Mon, Sep 19, 2016 at 12:56 PM, Jann Horn  wrote:
> On Mon, Sep 19, 2016 at 09:51:13PM +0200, Michal Hocko wrote:
>> [not sure why the CC list was trimmed - do no do that please unless you
>>  have a strong reason for that - if this was not intentional please
>>  restpre it]
>
> Ah, sorry, pressed the wrong key.
>
>
>> On Mon 19-09-16 21:40:01, Jann Horn wrote:
>> > On Mon, Sep 19, 2016 at 09:32:38PM +0200, Michal Hocko wrote:
>> > > On Mon 19-09-16 11:16:31, Robert Foss wrote:
>> > > > On 2016-09-14 05:12 AM, Michal Hocko wrote:
>> > > > > On Tue 13-09-16 13:27:39, Sonny Rao wrote:
>> > > [...]
>> > > > > > Given that smaps
>> > > > > > doesn't provide this in a straightforward way, what do you think is
>> > > > > > the right way to provide this information?
>> > > > >
>> > > > > I would be tempted to sneak it into /proc//statm because that 
>> > > > > looks
>> > > > > like a proper place but getting this information is not for free
>> > > > > performance wise so I am not really sure something that relies on 
>> > > > > this
>> > > > > file would see unexpected stalls. Maybe this could be worked around 
>> > > > > by
>> > > > > some caching... I would suggest to check who is actually using this 
>> > > > > file
>> > > > > (top/ps etc...)
>> > > >
>> > > > What would this caching look like? Can any information be re-used 
>> > > > between
>> > > > vma walks?
>> > >
>> > > yes basically return the same value if called within HZ or something
>> > > similar. But that assumes that statm latency really matters and it is
>> > > called often enough.
>> >
>> > That sounds horrible. If some application decides that they want to check
>> > statm directly after some action or so (like after program startup), this 
>> > is
>> > going to give them a very bad time. That probably doesn't happen
>> > often - but still.
>> >
>> > I can already imagine some developer going "yeah, that usleep()... that's
>> > because the kernel API returns stale information for a couple milliseconds
>> > after we do something *shrug*".
>> >
>> > What are you trying to optimize for? Ten users on the same machine, each of
>> > which is running "top" because it looks so great?
>>
>> Please try to read what I wrote again. I didn't say this would be
>> needed. The idea was that _if_ /proc//statm is used very _often_
>> than some caching might help to reduce the overhead. Especially when you
>> consider that the information is not precise anyway. It can change
>> anytime while you are doing the address space walk.

Just thinking out loud here -- I haven't looked closely at the code so
please bear with me :-)

Instead of checking when the last read was and returning old data,
what about a scheme where we still have a timestamp for last stat read
on and any changes to that address space invalidate the timestamp.

The invalidation could be racy because we're not too concerned about
immediate accuracy -- so just a write.   The main issue I could see
which this is that it could cause the cacheline holding this timestamp
to bounce around a lot?  Maybe there's an existing solution in the
page table locking that could be leveraged here to at least maintain
whatever scalability enhancements are present for this type of
situation where there are many updates happening in parallel.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/3] mm, proc: Implement /proc//totmaps

[Jann Horn]

On Mon, Sep 19, 2016 at 09:51:13PM +0200, Michal Hocko wrote:
> [not sure why the CC list was trimmed - do no do that please unless you
>  have a strong reason for that - if this was not intentional please
>  restpre it]

Ah, sorry, pressed the wrong key.


> On Mon 19-09-16 21:40:01, Jann Horn wrote:
> > On Mon, Sep 19, 2016 at 09:32:38PM +0200, Michal Hocko wrote:
> > > On Mon 19-09-16 11:16:31, Robert Foss wrote:
> > > > On 2016-09-14 05:12 AM, Michal Hocko wrote:
> > > > > On Tue 13-09-16 13:27:39, Sonny Rao wrote:
> > > [...]
> > > > > > Given that smaps
> > > > > > doesn't provide this in a straightforward way, what do you think is
> > > > > > the right way to provide this information?
> > > > > 
> > > > > I would be tempted to sneak it into /proc//statm because that 
> > > > > looks
> > > > > like a proper place but getting this information is not for free
> > > > > performance wise so I am not really sure something that relies on this
> > > > > file would see unexpected stalls. Maybe this could be worked around by
> > > > > some caching... I would suggest to check who is actually using this 
> > > > > file
> > > > > (top/ps etc...)
> > > > 
> > > > What would this caching look like? Can any information be re-used 
> > > > between
> > > > vma walks?
> > > 
> > > yes basically return the same value if called within HZ or something
> > > similar. But that assumes that statm latency really matters and it is
> > > called often enough.
> > 
> > That sounds horrible. If some application decides that they want to check
> > statm directly after some action or so (like after program startup), this is
> > going to give them a very bad time. That probably doesn't happen
> > often - but still.
> > 
> > I can already imagine some developer going "yeah, that usleep()... that's
> > because the kernel API returns stale information for a couple milliseconds
> > after we do something *shrug*".
> > 
> > What are you trying to optimize for? Ten users on the same machine, each of
> > which is running "top" because it looks so great?
> 
> Please try to read what I wrote again. I didn't say this would be
> needed. The idea was that _if_ /proc//statm is used very _often_
> than some caching might help to reduce the overhead. Especially when you
> consider that the information is not precise anyway. It can change
> anytime while you are doing the address space walk.


signature.asc
Description: Digital signature

Re: samples: move auxdisplay example code from Documentation

[SF Markus Elfring]

> Documentation/auxdisplay/cfag12864b needs to be updated to reflect the new
> home for the program (which probably does belong in samples/).
> 
> I wonder if these programs need MAINTAINERS entries too?

Do you find any more update suggestions interesting around this software module?
https://patchwork.kernel.org/project/LKML/list/?q=cfag12864b

Regards,
Markus
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/3] mm, proc: Implement /proc//totmaps

[Michal Hocko]

On Mon 19-09-16 11:16:31, Robert Foss wrote:
> On 2016-09-14 05:12 AM, Michal Hocko wrote:
> > On Tue 13-09-16 13:27:39, Sonny Rao wrote:
[...]
> > > Given that smaps
> > > doesn't provide this in a straightforward way, what do you think is
> > > the right way to provide this information?
> > 
> > I would be tempted to sneak it into /proc//statm because that looks
> > like a proper place but getting this information is not for free
> > performance wise so I am not really sure something that relies on this
> > file would see unexpected stalls. Maybe this could be worked around by
> > some caching... I would suggest to check who is actually using this file
> > (top/ps etc...)
> 
> What would this caching look like? Can any information be re-used between
> vma walks?

yes basically return the same value if called within HZ or something
similar. But that assumes that statm latency really matters and it is
called often enough.

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[git:media_tree/master] MAINTAINERS: update documentation for media subsystem

[Mauro Carvalho Chehab]

This is an automatic generated email to let you know that the following patch 
were queued:

Subject: MAINTAINERS: update documentation for media subsystem
Author:  Mauro Carvalho Chehab 
Date:Mon Sep 12 12:48:54 2016 -0300

With ReST conversion, the media subsystem documentation is now
located on different directories.

Update them.

Suggested-by: Joe Perches 
Cc: LKML 
Cc: linux-doc 
Cc: Jonathan Corbet 
Signed-off-by: Mauro Carvalho Chehab 

 MAINTAINERS | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

---

diff --git a/MAINTAINERS b/MAINTAINERS
index 22feb294de5d..de23660823b8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2755,7 +2755,7 @@ L:linux-me...@vger.kernel.org
 W: https://linuxtv.org
 T: git git://linuxtv.org/media_tree.git
 S: Odd fixes
-F: Documentation/video4linux/bttv/
+F: Documentation/media/v4l-drivers/bttv*
 F: drivers/media/pci/bt8xx/bttv*
 
 BUSLOGIC SCSI DRIVER
@@ -2800,7 +2800,7 @@ M:Jonathan Corbet 
 L: linux-me...@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
 S: Maintained
-F: Documentation/video4linux/cafe_ccic
+F: Documentation/media/v4l-drivers/cafe_ccic*
 F: drivers/media/platform/marvell-ccic/
 
 CAIF NETWORK LAYER
@@ -2894,7 +2894,7 @@ T:git git://linuxtv.org/media_tree.git
 W: http://linuxtv.org
 S: Supported
 F: Documentation/cec.txt
-F: Documentation/DocBook/media/v4l/cec*
+F: Documentation/media/uapi/cec
 F: drivers/staging/media/cec/
 F: drivers/media/cec-edid.c
 F: drivers/media/rc/keymaps/rc-cec.c
@@ -3380,7 +3380,7 @@ T:git git://linuxtv.org/media_tree.git
 W: https://linuxtv.org
 W: http://www.ivtvdriver.org/index.php/Cx18
 S: Maintained
-F: Documentation/video4linux/cx18.txt
+F: Documentation/media/v4l-drivers/cx18*
 F: drivers/media/pci/cx18/
 F: include/uapi/linux/ivtv*
 
@@ -3409,7 +3409,7 @@ L:linux-me...@vger.kernel.org
 W: https://linuxtv.org
 T: git git://linuxtv.org/media_tree.git
 S: Odd fixes
-F: Documentation/video4linux/cx88/
+F: Documentation/media/v4l-drivers/cx88*
 F: drivers/media/pci/cx88/
 
 CXD2820R MEDIA DRIVER
@@ -3882,7 +3882,7 @@ X:Documentation/devicetree/
 X: Documentation/acpi
 X: Documentation/power
 X: Documentation/spi
-X: Documentation/DocBook/media
+X: Documentation/media
 T: git git://git.lwn.net/linux.git docs-next
 
 DOUBLETALK DRIVER
@@ -4577,6 +4577,7 @@ W:https://linuxtv.org
 T: git git://linuxtv.org/media_tree.git
 S: Maintained
 F: drivers/media/usb/em28xx/
+F: Documentation/media/v4l-drivers/em28xx*
 
 EMBEDDED LINUX
 M: Paul Gortmaker 
@@ -6503,7 +6504,7 @@ L:linux-me...@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
 W: http://www.ivtvdriver.org
 S: Maintained
-F: Documentation/video4linux/*.ivtv
+F: Documentation/media/v4l-drivers/ivtv*
 F: drivers/media/pci/ivtv/
 F: include/uapi/linux/ivtv*
 
@@ -7583,9 +7584,7 @@ W:https://linuxtv.org
 Q: http://patchwork.kernel.org/project/linux-media/list/
 T: git git://linuxtv.org/media_tree.git
 S: Maintained
-F: Documentation/dvb/
-F: Documentation/video4linux/
-F: Documentation/DocBook/media/
+F: Documentation/media/
 F: drivers/media/
 F: drivers/staging/media/
 F: include/linux/platform_data/media/
@@ -7854,7 +7853,7 @@ F:kernel/module.c
 MOTION EYE VAIO PICTUREBOOK CAMERA DRIVER
 W: http://popies.net/meye/
 S: Orphan
-F: Documentation/video4linux/meye.txt
+F: Documentation/media/v4l-drivers/meye*
 F: drivers/media/pci/meye/
 F: include/uapi/linux/meye.h
 
@@ -9498,7 +9497,7 @@ L:linux-me...@vger.kernel.org
 W: http://www.isely.net/pvrusb2/
 T: git git://linuxtv.org/media_tree.git
 S: Maintained
-F: Documentation/video4linux/README.pvrusb2
+F: Documentation/media/v4l-drivers/pvrusb2*
 F: drivers/media/usb/pvrusb2/
 
 PWC WEBCAM DRIVER
@@ -10152,7 +10151,7 @@ L:  linux-me...@vger.kernel.org
 W: https://linuxtv.org
 T: git git://linuxtv.org/media_tree.git
 S: Odd fixes
-F: Documentation/video4linux/*.saa7134
+F: Documentation/media/v4l-drivers/saa7134*
 F: drivers/media/pci/saa7134/
 
 SAA7146 VIDEO4LINUX-2 DRIVER
@@ -11853,6 +11852,7 @@ W:  https://linuxtv.org
 T: git git://linuxtv.org/media_tree.git
 S: Odd fixes
 F: drivers/media/usb/tm6000/
+F: Documentation/media/v4l-drivers/tm6000*
 
 TW5864 VIDEO4LINUX DRIVER
 M: Bluecherry Maintainers 
@@ -12357,7 +12357,7 @@ L:  linux-me...@vger.kernel.org
 T: git git://linuxtv.org/media_tree.git
 W: 

Re: [PATCH] [media] videodev2.h.rst.exceptions: fix warnings

[Hans Verkuil]

On 09/19/2016 07:32 PM, Mauro Carvalho Chehab wrote:
> Changeset ab6343956f9c ("[media] V4L2: Add documentation for SDI timings
> and related flags") added documentation for new V4L2 defines, but
> it forgot to update videodev2.h.rst.exceptions to point to where
> the documentation for those new values will be inside the book,
> causing those warnings:
> 
> Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
> v4l2-dv-bt-std-sdi (if the link has no caption the label must precede a 
> section header)
> Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
> v4l2-dv-fl-first-field-extra-line (if the link has no caption the label must 
> precede a section header)
> Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
> v4l2-in-st-no-v-lock (if the link has no caption the label must precede a 
> section header)
> Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
> v4l2-in-st-no-std-lock (if the link has no caption the label must precede a 
> section header)
> 
> Fixes: ab6343956f9c ("[media] V4L2: Add documentation for SDI timings and 
> related flags")
> 
> Cc: Charles-Antoine Couret 
> Cc: Hans Verkuil 
> Signed-off-by: Mauro Carvalho Chehab 

Acked-by: Hans Verkuil 

I *know* I made the same change, but it looks like I may have forgotten to push 
to
my git branch :-(

Anyway, this is obviously correct.

Regards,

Hans

> ---
>  Documentation/media/videodev2.h.rst.exceptions | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/Documentation/media/videodev2.h.rst.exceptions 
> b/Documentation/media/videodev2.h.rst.exceptions
> index 3828a2983acb..1d3f27d922b2 100644
> --- a/Documentation/media/videodev2.h.rst.exceptions
> +++ b/Documentation/media/videodev2.h.rst.exceptions
> @@ -268,12 +268,14 @@ replace define V4L2_DV_BT_STD_CEA861 dv-bt-standards
>  replace define V4L2_DV_BT_STD_DMT dv-bt-standards
>  replace define V4L2_DV_BT_STD_CVT dv-bt-standards
>  replace define V4L2_DV_BT_STD_GTF dv-bt-standards
> +replace define V4L2_DV_BT_STD_SDI dv-bt-standards
>  
>  replace define V4L2_DV_FL_REDUCED_BLANKING dv-bt-standards
>  replace define V4L2_DV_FL_CAN_REDUCE_FPS dv-bt-standards
>  replace define V4L2_DV_FL_REDUCED_FPS dv-bt-standards
>  replace define V4L2_DV_FL_HALF_LINE dv-bt-standards
>  replace define V4L2_DV_FL_IS_CE_VIDEO dv-bt-standards
> +replace define V4L2_DV_FL_FIRST_FIELD_EXTRA_LINE dv-bt-standards
>  
>  replace define V4L2_DV_BT_656_1120 dv-timing-types
>  
> @@ -301,6 +303,8 @@ replace define V4L2_IN_ST_NO_CARRIER input-status
>  replace define V4L2_IN_ST_MACROVISION input-status
>  replace define V4L2_IN_ST_NO_ACCESS input-status
>  replace define V4L2_IN_ST_VTR input-status
> +replace define V4L2_IN_ST_NO_V_LOCK input-status
> +replace define V4L2_IN_ST_NO_STD_LOCK input-status
>  
>  replace define V4L2_IN_CAP_DV_TIMINGS input-capabilities
>  replace define V4L2_IN_CAP_STD input-capabilities
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] videodev2.h.rst.exceptions: fix warnings

[Mauro Carvalho Chehab]

Changeset ab6343956f9c ("[media] V4L2: Add documentation for SDI timings
and related flags") added documentation for new V4L2 defines, but
it forgot to update videodev2.h.rst.exceptions to point to where
the documentation for those new values will be inside the book,
causing those warnings:

Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
v4l2-dv-bt-std-sdi (if the link has no caption the label must precede a section 
header)
Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
v4l2-dv-fl-first-field-extra-line (if the link has no caption the label must 
precede a section header)
Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
v4l2-in-st-no-v-lock (if the link has no caption the label must precede a 
section header)
Documentation/output/videodev2.h.rst:6: WARNING: undefined label: 
v4l2-in-st-no-std-lock (if the link has no caption the label must precede a 
section header)

Fixes: ab6343956f9c ("[media] V4L2: Add documentation for SDI timings and 
related flags")

Cc: Charles-Antoine Couret 
Cc: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/media/videodev2.h.rst.exceptions | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/media/videodev2.h.rst.exceptions 
b/Documentation/media/videodev2.h.rst.exceptions
index 3828a2983acb..1d3f27d922b2 100644
--- a/Documentation/media/videodev2.h.rst.exceptions
+++ b/Documentation/media/videodev2.h.rst.exceptions
@@ -268,12 +268,14 @@ replace define V4L2_DV_BT_STD_CEA861 dv-bt-standards
 replace define V4L2_DV_BT_STD_DMT dv-bt-standards
 replace define V4L2_DV_BT_STD_CVT dv-bt-standards
 replace define V4L2_DV_BT_STD_GTF dv-bt-standards
+replace define V4L2_DV_BT_STD_SDI dv-bt-standards
 
 replace define V4L2_DV_FL_REDUCED_BLANKING dv-bt-standards
 replace define V4L2_DV_FL_CAN_REDUCE_FPS dv-bt-standards
 replace define V4L2_DV_FL_REDUCED_FPS dv-bt-standards
 replace define V4L2_DV_FL_HALF_LINE dv-bt-standards
 replace define V4L2_DV_FL_IS_CE_VIDEO dv-bt-standards
+replace define V4L2_DV_FL_FIRST_FIELD_EXTRA_LINE dv-bt-standards
 
 replace define V4L2_DV_BT_656_1120 dv-timing-types
 
@@ -301,6 +303,8 @@ replace define V4L2_IN_ST_NO_CARRIER input-status
 replace define V4L2_IN_ST_MACROVISION input-status
 replace define V4L2_IN_ST_NO_ACCESS input-status
 replace define V4L2_IN_ST_VTR input-status
+replace define V4L2_IN_ST_NO_V_LOCK input-status
+replace define V4L2_IN_ST_NO_STD_LOCK input-status
 
 replace define V4L2_IN_CAP_DV_TIMINGS input-capabilities
 replace define V4L2_IN_CAP_STD input-capabilities
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/8] samples: move pcmcia example code from Documentation

[Jonathan Corbet]

On Mon, 19 Sep 2016 08:47:37 -0600
Shuah Khan  wrote:

> Move pcmcia examples to samples and remove it from Documentation
> Makefile. Create a new Makefile to build pcmcia. It can be built
> from top level directory or from pcmcia directory:

Does PCMCIA still exist/work?  I guess it probably must somewhere.  This
one might better qualify as a "tool."
Documentation/pcmcia/devicetable.txt needs an update, as does MAINTAINERS.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 5/8] samples: move misc-devices/mei example code from Documentation

[Jonathan Corbet]

On Mon, 19 Sep 2016 08:47:36 -0600
Shuah Khan  wrote:

> Move misc-devices/mei examples to samples/mei and remove it from
> Documentation Makefile. Delete misc-devices/Makefile.
> 
> Create a new Makefile to build samples/mei. It can be built from top
> level directory or from mei directory:

This one still has a fair amount of code hiding in the .txt files, but
that's a separate job.

Acked-by: Jonathan Corbet 

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/8] samples: move mic/mpssd example code from Documentation

[Jonathan Corbet]

On Mon, 19 Sep 2016 08:47:35 -0600
Shuah Khan  wrote:

> Move mic/mpssd examples to samples and remove it from Documentation
> Makefile. Create a new Makefile to build mic/mpssd. It can be built
> from top level directory or from mic/mpssd directory:
> 
> Run make -C samples/mic/mpssd or cd samples/mic/mpssd; make

This one seems good as-is

Acked-by: Jonathan Corbet 

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 3/8] samples: move laptops example code from Documentation

[Jonathan Corbet]

On Mon, 19 Sep 2016 08:47:34 -0600
Shuah Khan  wrote:

> Move laptops examples to samples and remove it from Documentation
> Makefile. Create a new Makefile to build laptops. It can be built
> from top level directory or from laptops directory:

This one might be better called a "tool" rather than a "sample" - assuming
it actually still works, of course.  It hasn't seen a real update in the
Git era, which is a bit disconcerting.  Is it possible that this is dead
code that we might want to just get rid of?

If it stays, Documentation/laptops/laptop-mode.txt needs an update.

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/8] samples: move auxdisplay example code from Documentation

[Jonathan Corbet]

On Mon, 19 Sep 2016 08:47:33 -0600
Shuah Khan  wrote:

> Move auxdisplay examples to samples and remove it from Documentation
> Makefile. Create a new Makefile to build auxdisplay. It can be built
> from top level directory or from auxdisplay directory:

Documentation/auxdisplay/cfag12864b needs to be updated to reflect the new
home for the program (which probably does belong in samples/).

I wonder if these programs need MAINTAINERS entries too?

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/8] samples: move accounting example code from Documentation

[Jonathan Corbet]

On Mon, 19 Sep 2016 08:47:32 -0600
Shuah Khan  wrote:

> Move accounting examples to samples and remove it from Documentation
> Makefile. Create a new Makefile to build accounting. It can be built
> from top level directory or from accounting directory:

So I like the basic idea of these patches; it's the direction we've been
trying to push things for a little bit.  I have a couple of specific
comments for this one that may well apply to the others as well.

1) Is samples the right destination for these utilities?  Some of them
   might well be better placed under tools/ instead.  I'm not sure we've
   ever formally stated the purpose of those two subtrees; I see samples/
   as demonstrations of how to use something, while tools/ are utilities
   you might actually want to use for some purpose.  Something like
   getdelays might well fall into the latter group.  But maybe others
   disagree?

2) Tools like getdelays are referenced in the documents that have been
   left behind; see accounting/delay-accounting.txt, for example.  Those
   documents should be updated so that readers know where to find the
   referenced programs, wherever they end up.  Converting them to Sphinx
   while you're at it is an extra-credit exercise :)

Thanks,

jon
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/8] Move runnable examples code from Documentation to samples

[Jani Nikula]

On Mon, 19 Sep 2016, Shuah Khan  wrote:
> Move runnable examples code from Documentation to samples. I moved
> just the example code, and left documentation files as is.

FWIW I like this.

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/3] doc-rst:c-domain: fix some issues in the c-domain

[Mauro Carvalho Chehab]

Em Mon, 19 Sep 2016 13:36:55 +0200
Markus Heiser  escreveu:

> Hi Mauro, 
> 
> sorry for my late reply (so much work to do) ..
> 
> Am 09.09.2016 um 14:25 schrieb Markus Heiser :
> 
> >> Using either this approach or my kernel-doc patch, I'm now getting
> >> only two warnings:
> >> 
> >> 1) at media-entity.h, even without nitpick mode:
> >> 
> >> ./include/media/media-entity.h:1053: warning: No description found for 
> >> parameter '...'  
> 
> FYI: This message comes from the kernel-doc parser.
> 
> >> This is caused by this kernel-doc tag and the corresponding macro:
> >> 
> >>/**
> >> * media_entity_call - Calls a struct media_entity_operations operation 
> >> on
> >> *  an entity
> >> *
> >> * @entity: entity where the @operation will be called
> >> * @operation: type of the operation. Should be the name of a member of
> >> *  struct _entity_operations.
> >> *
> >> * This helper function will check if @operation is not %NULL. On such 
> >> case,
> >> * it will issue a call to @operation\(@entity, @args\).
> >> */
> >> 
> >>#define media_entity_call(entity, operation, args...)   
> >> \
> >>(((entity)->ops && (entity)->ops->operation) ?  
> >> \
> >> (entity)->ops->operation((entity) , ##args) : -ENOIOCTLCMD)
> >> 
> >> 
> >> Basically, the Sphinx C domain seems to be expecting a description for
> >> "...". I didn't find any way to get rid of that.  
> 
> This is a bug in the kernel-doc parser.   The parser generates:
> 
>   .. c:function:: media_entity_call ( entity,  operation,  ...)
> 
> correct is:
> 
>   .. c:function::  media_entity_call( entity,  operation,  args...)
> 
> So both, the message and the wrong parse result comes from kernel-doc.

Ok, I'll try to address it by fixing kernel-doc script.

> 
> >> 
> >> 2) a nitpick warning at v4l2-mem2mem.h:
> >> 
> >> ./include/media/v4l2-mem2mem.h:339: WARNING: c:type reference target not 
> >> found: queue_init  
> 
> FYI: this message comes from sphinx c-domain.
> 
> >>/**
> >> * v4l2_m2m_ctx_init() - allocate and initialize a m2m context
> >> *
> >> * @m2m_dev: opaque pointer to the internal data to handle M2M context
> >> * @drv_priv: driver's instance private data
> >> * @queue_init: a callback for queue type-specific initialization 
> >> function
> >> *  to be used for initializing videobuf_queues
> >> *
> >> * Usually called from driver's ``open()`` function.
> >> */
> >>struct v4l2_m2m_ctx *v4l2_m2m_ctx_init(struct v4l2_m2m_dev *m2m_dev,
> >>void *drv_priv,
> >>int (*queue_init)(void *priv, struct vb2_queue *src_vq, 
> >> struct vb2_queue *dst_vq));
> >> 
> >> I checked the output of kernel-doc, and it looked ok. Yet, it expects
> >> "queue_init" to be defined somehow. I suspect that this is an error at
> >> Sphinx C domain parser.  
> 
> Hmm, as far as I see, the output is not correct ... The output of
> functions with a function pointer argument are missing the 
> leading parenthesis in the function definition:
> 
>   .. c:function:: struct v4l2_m2m_ctx * v4l2_m2m_ctx_init (struct 
> v4l2_m2m_dev * m2m_dev, void * drv_priv, int (*queue_init) (void *priv, 
> struct vb2_queue *src_vq, struct vb2_queue *dst_vq)
> 
> The missing parenthesis cause the error message. 


Ah, OK! I'll kernel-doc and see what's happening here.

> 
> The output of the parameter description is:
> 
>   ``int (*)(void *priv, struct vb2_queue *src_vq, struct vb2_queue *dst_vq) 
> queue_init``
> a callback for queue type-specific initialization function
> to be used for initializing videobuf_queues
> 
> Correct (and IMO better to read) is:
> 
>   .. c:function:: struct v4l2_m2m_ctx *v4l2_m2m_ctx_init(struct v4l2_m2m_dev 
> *m2m_dev, void *drv_priv, int (*queue_init)(void *priv, struct vb2_queue 
> *src_vq, struct vb2_queue *dst_vq))
> 
> and the parameter description should be something like ...
> 
>:param int (\*queue_init)(void \*priv, struct vb2_queue \*src_vq, struct 
> vb2_queue \*dst_vq):
> a callback for queue type-specific initialization function
> to be used for initializing videobuf_queues

I guess the better would be to strip the parameter type and output
it as:
queue_init
a callback for queue type-specific initialization function
to be used for initializing videobuf_queues

As I pointed before, the point is that such argument can easily have
more than 80 columns, with would cause troubles with LaTeX output,
as LaTeX doesn't break long verbatim text on multiple lines.

I submitted one patch fixing it. Not sure if it got merged by Jon
or not.

> 
> I tested this with my linuxdoc tools (parser) with I get no
> error messages from the sphinx c-domain.
> 
> BTW: 
> 
> The parser of my linuxdoc project is more strict and spit out some 
> 

[PATCH 1/8] samples: move accounting example code from Documentation

[Shuah Khan]

Move accounting examples to samples and remove it from Documentation
Makefile. Create a new Makefile to build accounting. It can be built
from top level directory or from accounting directory:

Run make -C samples/accounting or cd samples/accounting; make

Signed-off-by: Shuah Khan 
---
 Documentation/Makefile   |   2 +-
 Documentation/accounting/.gitignore  |   1 -
 Documentation/accounting/Makefile|   7 -
 Documentation/accounting/getdelays.c | 550 ---
 samples/accounting/.gitignore|   1 +
 samples/accounting/Makefile  |   9 +
 samples/accounting/getdelays.c   | 550 +++
 7 files changed, 561 insertions(+), 559 deletions(-)
 delete mode 100644 Documentation/accounting/.gitignore
 delete mode 100644 Documentation/accounting/Makefile
 delete mode 100644 Documentation/accounting/getdelays.c
 create mode 100644 samples/accounting/.gitignore
 create mode 100644 samples/accounting/Makefile
 create mode 100644 samples/accounting/getdelays.c

diff --git a/Documentation/Makefile b/Documentation/Makefile
index f530c29..58c6629 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,2 +1,2 @@
-subdir-y := accounting auxdisplay blackfin \
+subdir-y := auxdisplay blackfin \
laptops mic misc-devices pcmcia timers watchdog
diff --git a/Documentation/accounting/.gitignore 
b/Documentation/accounting/.gitignore
deleted file mode 100644
index 8648520..000
--- a/Documentation/accounting/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-getdelays
diff --git a/Documentation/accounting/Makefile 
b/Documentation/accounting/Makefile
deleted file mode 100644
index 7e232cb..000
--- a/Documentation/accounting/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# List of programs to build
-hostprogs-y := getdelays
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
-
-HOSTCFLAGS_getdelays.o += -I$(objtree)/usr/include
diff --git a/Documentation/accounting/getdelays.c 
b/Documentation/accounting/getdelays.c
deleted file mode 100644
index b5ca536..000
--- a/Documentation/accounting/getdelays.c
+++ /dev/null
@@ -1,550 +0,0 @@
-/* getdelays.c
- *
- * Utility to get per-pid and per-tgid delay accounting statistics
- * Also illustrates usage of the taskstats interface
- *
- * Copyright (C) Shailabh Nagar, IBM Corp. 2005
- * Copyright (C) Balbir Singh, IBM Corp. 2006
- * Copyright (c) Jay Lan, SGI. 2006
- *
- * Compile with
- * gcc -I/usr/src/linux/include getdelays.c -o getdelays
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-
-/*
- * Generic macros for dealing with netlink sockets. Might be duplicated
- * elsewhere. It is recommended that commercial grade applications use
- * libnl or libnetlink and use the interfaces provided by the library
- */
-#define GENLMSG_DATA(glh)  ((void *)(NLMSG_DATA(glh) + GENL_HDRLEN))
-#define GENLMSG_PAYLOAD(glh)   (NLMSG_PAYLOAD(glh, 0) - GENL_HDRLEN)
-#define NLA_DATA(na)   ((void *)((char*)(na) + NLA_HDRLEN))
-#define NLA_PAYLOAD(len)   (len - NLA_HDRLEN)
-
-#define err(code, fmt, arg...) \
-   do {\
-   fprintf(stderr, fmt, ##arg);\
-   exit(code); \
-   } while (0)
-
-int done;
-int rcvbufsz;
-char name[100];
-int dbg;
-int print_delays;
-int print_io_accounting;
-int print_task_context_switch_counts;
-
-#define PRINTF(fmt, arg...) {  \
-   if (dbg) {  \
-   printf(fmt, ##arg); \
-   }   \
-   }
-
-/* Maximum size of response requested or message sent */
-#define MAX_MSG_SIZE   1024
-/* Maximum number of cpus expected to be specified in a cpumask */
-#define MAX_CPUS   32
-
-struct msgtemplate {
-   struct nlmsghdr n;
-   struct genlmsghdr g;
-   char buf[MAX_MSG_SIZE];
-};
-
-char cpumask[100+6*MAX_CPUS];
-
-static void usage(void)
-{
-   fprintf(stderr, "getdelays [-dilv] [-w logfile] [-r bufsize] "
-   "[-m cpumask] [-t tgid] [-p pid]\n");
-   fprintf(stderr, "  -d: print delayacct stats\n");
-   fprintf(stderr, "  -i: print IO accounting (works only with -p)\n");
-   fprintf(stderr, "  -l: listen forever\n");
-   fprintf(stderr, "  -v: debug on\n");
-   fprintf(stderr, "  -C: container path\n");
-}
-
-/*
- * Create a raw netlink socket and bind
- */
-static int create_nl_socket(int protocol)
-{
-   int fd;
-   struct sockaddr_nl local;
-
-   fd = socket(AF_NETLINK, SOCK_RAW, protocol);
-   if (fd < 0)
-   return -1;
-
-   if (rcvbufsz)
-   if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF,
-   , sizeof(rcvbufsz)) < 0) {
-   

[PATCH 6/8] samples: move pcmcia example code from Documentation

[Shuah Khan]

Move pcmcia examples to samples and remove it from Documentation
Makefile. Create a new Makefile to build pcmcia. It can be built
from top level directory or from pcmcia directory:

Run make -C samples/pcmcia or cd samples/pcmcia; make

Signed-off-by: Shuah Khan 
---
 Documentation/Makefile   |  2 +-
 Documentation/pcmcia/.gitignore  |  1 -
 Documentation/pcmcia/Makefile|  7 ---
 Documentation/pcmcia/crc32hash.c | 32 
 samples/pcmcia/.gitignore|  1 +
 samples/pcmcia/Makefile  |  9 +
 samples/pcmcia/crc32hash.c   | 32 
 7 files changed, 43 insertions(+), 41 deletions(-)
 delete mode 100644 Documentation/pcmcia/.gitignore
 delete mode 100644 Documentation/pcmcia/Makefile
 delete mode 100644 Documentation/pcmcia/crc32hash.c
 create mode 100644 samples/pcmcia/.gitignore
 create mode 100644 samples/pcmcia/Makefile
 create mode 100644 samples/pcmcia/crc32hash.c

diff --git a/Documentation/Makefile b/Documentation/Makefile
index ac7d68f..bd5f115 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1 +1 @@
-subdir-y := blackfin pcmcia timers watchdog
+subdir-y := blackfin timers watchdog
diff --git a/Documentation/pcmcia/.gitignore b/Documentation/pcmcia/.gitignore
deleted file mode 100644
index 53d0813..000
--- a/Documentation/pcmcia/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-crc32hash
diff --git a/Documentation/pcmcia/Makefile b/Documentation/pcmcia/Makefile
deleted file mode 100644
index 47a8fa1..000
--- a/Documentation/pcmcia/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# List of programs to build
-hostprogs-y := crc32hash
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
-
-HOSTCFLAGS_crc32hash.o += -I$(objtree)/usr/include
diff --git a/Documentation/pcmcia/crc32hash.c b/Documentation/pcmcia/crc32hash.c
deleted file mode 100644
index 44f8bee..000
--- a/Documentation/pcmcia/crc32hash.c
+++ /dev/null
@@ -1,32 +0,0 @@
-/* crc32hash.c - derived from linux/lib/crc32.c, GNU GPL v2 */
-/* Usage example:
-$ ./crc32hash "Dual Speed"
-*/
-
-#include 
-#include 
-#include 
-#include 
-
-static unsigned int crc32(unsigned char const *p, unsigned int len)
-{
-   int i;
-   unsigned int crc = 0;
-   while (len--) {
-   crc ^= *p++;
-   for (i = 0; i < 8; i++)
-   crc = (crc >> 1) ^ ((crc & 1) ? 0xedb88320 : 0);
-   }
-   return crc;
-}
-
-int main(int argc, char **argv) {
-   unsigned int result;
-   if (argc != 2) {
-   printf("no string passed as argument\n");
-   return -1;
-   }
-   result = crc32((unsigned char const *)argv[1], strlen(argv[1]));
-   printf("0x%x\n", result);
-   return 0;
-}
diff --git a/samples/pcmcia/.gitignore b/samples/pcmcia/.gitignore
new file mode 100644
index 000..53d0813
--- /dev/null
+++ b/samples/pcmcia/.gitignore
@@ -0,0 +1 @@
+crc32hash
diff --git a/samples/pcmcia/Makefile b/samples/pcmcia/Makefile
new file mode 100644
index 000..81a7498
--- /dev/null
+++ b/samples/pcmcia/Makefile
@@ -0,0 +1,9 @@
+CC := $(CROSS_COMPILE)gcc
+CFLAGS := -I../../usr/include
+
+PROGS := crc32hash
+
+all: $(PROGS)
+
+clean:
+   rm -fr $(PROGS)
diff --git a/samples/pcmcia/crc32hash.c b/samples/pcmcia/crc32hash.c
new file mode 100644
index 000..44f8bee
--- /dev/null
+++ b/samples/pcmcia/crc32hash.c
@@ -0,0 +1,32 @@
+/* crc32hash.c - derived from linux/lib/crc32.c, GNU GPL v2 */
+/* Usage example:
+$ ./crc32hash "Dual Speed"
+*/
+
+#include 
+#include 
+#include 
+#include 
+
+static unsigned int crc32(unsigned char const *p, unsigned int len)
+{
+   int i;
+   unsigned int crc = 0;
+   while (len--) {
+   crc ^= *p++;
+   for (i = 0; i < 8; i++)
+   crc = (crc >> 1) ^ ((crc & 1) ? 0xedb88320 : 0);
+   }
+   return crc;
+}
+
+int main(int argc, char **argv) {
+   unsigned int result;
+   if (argc != 2) {
+   printf("no string passed as argument\n");
+   return -1;
+   }
+   result = crc32((unsigned char const *)argv[1], strlen(argv[1]));
+   printf("0x%x\n", result);
+   return 0;
+}
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/8] samples: move laptops example code from Documentation

[Shuah Khan]

Move laptops examples to samples and remove it from Documentation
Makefile. Create a new Makefile to build laptops. It can be built
from top level directory or from laptops directory:

Run make -C samples/laptops or cd samples/laptops; make

Signed-off-by: Shuah Khan 
---
 Documentation/Makefile   |   2 +-
 Documentation/laptops/.gitignore |   1 -
 Documentation/laptops/Makefile   |   5 --
 Documentation/laptops/dslm.c | 166 ---
 samples/laptops/.gitignore   |   1 +
 samples/laptops/Makefile |   9 +++
 samples/laptops/dslm.c   | 166 +++
 7 files changed, 177 insertions(+), 173 deletions(-)
 delete mode 100644 Documentation/laptops/.gitignore
 delete mode 100644 Documentation/laptops/Makefile
 delete mode 100644 Documentation/laptops/dslm.c
 create mode 100644 samples/laptops/.gitignore
 create mode 100644 samples/laptops/Makefile
 create mode 100644 samples/laptops/dslm.c

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 60ec0dc..539120b 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1 +1 @@
-subdir-y := blackfin laptops mic misc-devices pcmcia timers watchdog
+subdir-y := blackfin mic misc-devices pcmcia timers watchdog
diff --git a/Documentation/laptops/.gitignore b/Documentation/laptops/.gitignore
deleted file mode 100644
index 9fc984e..000
--- a/Documentation/laptops/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-dslm
diff --git a/Documentation/laptops/Makefile b/Documentation/laptops/Makefile
deleted file mode 100644
index 0abe44f..000
--- a/Documentation/laptops/Makefile
+++ /dev/null
@@ -1,5 +0,0 @@
-# List of programs to build
-hostprogs-y := dslm
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
diff --git a/Documentation/laptops/dslm.c b/Documentation/laptops/dslm.c
deleted file mode 100644
index d5dd2d4..000
--- a/Documentation/laptops/dslm.c
+++ /dev/null
@@ -1,166 +0,0 @@
-/*
- * dslm.c
- * Simple Disk Sleep Monitor
- *  by Bartek Kania
- * Licensed under the GPL
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#ifdef DEBUG
-#define D(x) x
-#else
-#define D(x)
-#endif
-
-int endit = 0;
-
-/* Check if the disk is in powersave-mode
- * Most of the code is stolen from hdparm.
- * 1 = active, 0 = standby/sleep, -1 = unknown */
-static int check_powermode(int fd)
-{
-unsigned char args[4] = {WIN_CHECKPOWERMODE1,0,0,0};
-int state;
-
-if (ioctl(fd, HDIO_DRIVE_CMD, )
-   && (args[0] = WIN_CHECKPOWERMODE2) /* try again with 0x98 */
-   && ioctl(fd, HDIO_DRIVE_CMD, )) {
-   if (errno != EIO || args[0] != 0 || args[1] != 0) {
-   state = -1; /* "unknown"; */
-   } else
-   state = 0; /* "sleeping"; */
-} else {
-   state = (args[2] == 255) ? 1 : 0;
-}
-D(printf(" drive state is:  %d\n", state));
-
-return state;
-}
-
-static char *state_name(int i)
-{
-if (i == -1) return "unknown";
-if (i == 0) return "sleeping";
-if (i == 1) return "active";
-
-return "internal error";
-}
-
-static char *myctime(time_t time)
-{
-char *ts = ctime();
-ts[strlen(ts) - 1] = 0;
-
-return ts;
-}
-
-static void measure(int fd)
-{
-time_t start_time;
-int last_state;
-time_t last_time;
-int curr_state;
-time_t curr_time = 0;
-time_t time_diff;
-time_t active_time = 0;
-time_t sleep_time = 0;
-time_t unknown_time = 0;
-time_t total_time = 0;
-int changes = 0;
-float tmp;
-
-printf("Starting measurements\n");
-
-last_state = check_powermode(fd);
-start_time = last_time = time(0);
-printf("  System is in state %s\n\n", state_name(last_state));
-
-while(!endit) {
-   sleep(1);
-   curr_state = check_powermode(fd);
-
-   if (curr_state != last_state || endit) {
-   changes++;
-   curr_time = time(0);
-   time_diff = curr_time - last_time;
-
-   if (last_state == 1) active_time += time_diff;
-   else if (last_state == 0) sleep_time += time_diff;
-   else unknown_time += time_diff;
-
-   last_state = curr_state;
-   last_time = curr_time;
-
-   printf("%s: State-change to %s\n", myctime(curr_time),
-  state_name(curr_state));
-   }
-}
-changes--; /* Compensate for SIGINT */
-
-total_time = time(0) - start_time;
-printf("\nTotal running time:  %lus\n", curr_time - start_time);
-printf(" State changed %d times\n", changes);
-
-tmp = (float)sleep_time / (float)total_time * 100;
-printf(" Time in sleep state:   %lus (%.2f%%)\n", sleep_time, tmp);
-tmp = (float)active_time / (float)total_time * 100;
-printf(" Time in active state:  %lus (%.2f%%)\n", active_time, tmp);
-tmp = (float)unknown_time / (float)total_time * 100;
-printf(" Time in unknown state: %lus (%.2f%%)\n", 

[PATCH 5/8] samples: move misc-devices/mei example code from Documentation

[Shuah Khan]

Move misc-devices/mei examples to samples/mei and remove it from
Documentation Makefile. Delete misc-devices/Makefile.

Create a new Makefile to build samples/mei. It can be built from top
level directory or from mei directory:

Run make -C samples/mei or cd samples/mei; make

Signed-off-by: Shuah Khan 
---
 Documentation/Makefile   |   2 +-
 Documentation/misc-devices/Makefile  |   1 -
 Documentation/misc-devices/mei/.gitignore|   1 -
 Documentation/misc-devices/mei/Makefile  |   5 -
 Documentation/misc-devices/mei/TODO  |   2 -
 Documentation/misc-devices/mei/mei-amt-version.c | 479 ---
 samples/mei/.gitignore   |   1 +
 samples/mei/Makefile |   9 +
 samples/mei/TODO |   2 +
 samples/mei/mei-amt-version.c| 479 +++
 10 files changed, 492 insertions(+), 489 deletions(-)
 delete mode 100644 Documentation/misc-devices/Makefile
 delete mode 100644 Documentation/misc-devices/mei/.gitignore
 delete mode 100644 Documentation/misc-devices/mei/Makefile
 delete mode 100644 Documentation/misc-devices/mei/TODO
 delete mode 100644 Documentation/misc-devices/mei/mei-amt-version.c
 create mode 100644 samples/mei/.gitignore
 create mode 100644 samples/mei/Makefile
 create mode 100644 samples/mei/TODO
 create mode 100644 samples/mei/mei-amt-version.c

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 90271bc..ac7d68f 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1 +1 @@
-subdir-y := blackfin misc-devices pcmcia timers watchdog
+subdir-y := blackfin pcmcia timers watchdog
diff --git a/Documentation/misc-devices/Makefile 
b/Documentation/misc-devices/Makefile
deleted file mode 100644
index e2b7aa4..000
--- a/Documentation/misc-devices/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-subdir-y := mei
diff --git a/Documentation/misc-devices/mei/.gitignore 
b/Documentation/misc-devices/mei/.gitignore
deleted file mode 100644
index f356b81..000
--- a/Documentation/misc-devices/mei/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-mei-amt-version
diff --git a/Documentation/misc-devices/mei/Makefile 
b/Documentation/misc-devices/mei/Makefile
deleted file mode 100644
index d758047..000
--- a/Documentation/misc-devices/mei/Makefile
+++ /dev/null
@@ -1,5 +0,0 @@
-# List of programs to build
-hostprogs-y := mei-amt-version
-HOSTCFLAGS_mei-amt-version.o += -I$(objtree)/usr/include
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
diff --git a/Documentation/misc-devices/mei/TODO 
b/Documentation/misc-devices/mei/TODO
deleted file mode 100644
index 6b3625d..000
--- a/Documentation/misc-devices/mei/TODO
+++ /dev/null
@@ -1,2 +0,0 @@
-TODO:
-   - Cleanup and split the timer function
diff --git a/Documentation/misc-devices/mei/mei-amt-version.c 
b/Documentation/misc-devices/mei/mei-amt-version.c
deleted file mode 100644
index 57d0d87..000
--- a/Documentation/misc-devices/mei/mei-amt-version.c
+++ /dev/null
@@ -1,479 +0,0 @@
-/**
- * Intel Management Engine Interface (Intel MEI) Linux driver
- * Intel MEI Interface Header
- *
- * This file is provided under a dual BSD/GPLv2 license.  When using or
- * redistributing this file, you may do so under either license.
- *
- * GPL LICENSE SUMMARY
- *
- * Copyright(c) 2012 Intel Corporation. All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of version 2 of the GNU General Public License as
- * published by the Free Software Foundation.
- *
- * 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 Street, Fifth Floor, Boston, MA 02110,
- * USA
- *
- * The full GNU General Public License is included in this distribution
- * in the file called LICENSE.GPL.
- *
- * Contact Information:
- * Intel Corporation.
- * linux-...@linux.intel.com
- * http://www.intel.com
- *
- * BSD LICENSE
- *
- * Copyright(c) 2003 - 2012 Intel Corporation. All rights reserved.
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions
- * are met:
- *
- *  * Redistributions of source code must retain the above copyright
- *notice, this list of conditions and the following disclaimer.
- *  * Redistributions in binary form must reproduce the above copyright
- *notice, this list of conditions and the 

[PATCH 8/8] samples: move watchdog example code from Documentation

[Shuah Khan]

Move watchdog examples to samples and remove it from Documentation
Makefile. Create a new Makefile to build watchdog. It can be built
from top level directory or from watchdog directory:

Run make -C samples/watchdog or cd samples/watchdog; make

Signed-off-by: Shuah Khan 
---
 Documentation/Makefile   |  2 +-
 Documentation/watchdog/Makefile  |  1 -
 Documentation/watchdog/src/.gitignore|  1 -
 Documentation/watchdog/src/Makefile  |  5 -
 Documentation/watchdog/src/watchdog-simple.c | 24 
 samples/watchdog/.gitignore  |  1 +
 samples/watchdog/Makefile|  8 
 samples/watchdog/watchdog-simple.c   | 24 
 8 files changed, 34 insertions(+), 32 deletions(-)
 delete mode 100644 Documentation/watchdog/Makefile
 delete mode 100644 Documentation/watchdog/src/.gitignore
 delete mode 100644 Documentation/watchdog/src/Makefile
 delete mode 100644 Documentation/watchdog/src/watchdog-simple.c
 create mode 100644 samples/watchdog/.gitignore
 create mode 100644 samples/watchdog/Makefile
 create mode 100644 samples/watchdog/watchdog-simple.c

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 9c3fe11..8435965 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1 +1 @@
-subdir-y := blackfin watchdog
+subdir-y := blackfin
diff --git a/Documentation/watchdog/Makefile b/Documentation/watchdog/Makefile
deleted file mode 100644
index 6018f45..000
--- a/Documentation/watchdog/Makefile
+++ /dev/null
@@ -1 +0,0 @@
-subdir-y := src
diff --git a/Documentation/watchdog/src/.gitignore 
b/Documentation/watchdog/src/.gitignore
deleted file mode 100644
index ff0ebb5..000
--- a/Documentation/watchdog/src/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-watchdog-simple
diff --git a/Documentation/watchdog/src/Makefile 
b/Documentation/watchdog/src/Makefile
deleted file mode 100644
index 47be791..000
--- a/Documentation/watchdog/src/Makefile
+++ /dev/null
@@ -1,5 +0,0 @@
-# List of programs to build
-hostprogs-y := watchdog-simple
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
diff --git a/Documentation/watchdog/src/watchdog-simple.c 
b/Documentation/watchdog/src/watchdog-simple.c
deleted file mode 100644
index ba45803..000
--- a/Documentation/watchdog/src/watchdog-simple.c
+++ /dev/null
@@ -1,24 +0,0 @@
-#include 
-#include 
-#include 
-#include 
-
-int main(void)
-{
-   int fd = open("/dev/watchdog", O_WRONLY);
-   int ret = 0;
-   if (fd == -1) {
-   perror("watchdog");
-   exit(EXIT_FAILURE);
-   }
-   while (1) {
-   ret = write(fd, "\0", 1);
-   if (ret != 1) {
-   ret = -1;
-   break;
-   }
-   sleep(10);
-   }
-   close(fd);
-   return ret;
-}
diff --git a/samples/watchdog/.gitignore b/samples/watchdog/.gitignore
new file mode 100644
index 000..ff0ebb5
--- /dev/null
+++ b/samples/watchdog/.gitignore
@@ -0,0 +1 @@
+watchdog-simple
diff --git a/samples/watchdog/Makefile b/samples/watchdog/Makefile
new file mode 100644
index 000..9b53d89
--- /dev/null
+++ b/samples/watchdog/Makefile
@@ -0,0 +1,8 @@
+CC := $(CROSS_COMPILE)gcc
+PROGS := watchdog-simple
+
+all: $(PROGS)
+
+clean:
+   rm -fr $(PROGS)
+
diff --git a/samples/watchdog/watchdog-simple.c 
b/samples/watchdog/watchdog-simple.c
new file mode 100644
index 000..ba45803
--- /dev/null
+++ b/samples/watchdog/watchdog-simple.c
@@ -0,0 +1,24 @@
+#include 
+#include 
+#include 
+#include 
+
+int main(void)
+{
+   int fd = open("/dev/watchdog", O_WRONLY);
+   int ret = 0;
+   if (fd == -1) {
+   perror("watchdog");
+   exit(EXIT_FAILURE);
+   }
+   while (1) {
+   ret = write(fd, "\0", 1);
+   if (ret != 1) {
+   ret = -1;
+   break;
+   }
+   sleep(10);
+   }
+   close(fd);
+   return ret;
+}
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/8] samples: move timers example code from Documentation

[Shuah Khan]

Move timers examples to samples and remove it from Documentation
Makefile. Create a new Makefile to build timers. It can be built
from top level directory or from timers directory:

Run make -C samples/timers or cd samples/timers; make

Signed-off-by: Shuah Khan 
---
 Documentation/Makefile  |   2 +-
 Documentation/timers/.gitignore |   1 -
 Documentation/timers/Makefile   |   5 -
 Documentation/timers/hpet_example.c | 294 
 samples/timers/.gitignore   |   1 +
 samples/timers/Makefile |  15 ++
 samples/timers/hpet_example.c   | 294 
 7 files changed, 311 insertions(+), 301 deletions(-)
 delete mode 100644 Documentation/timers/.gitignore
 delete mode 100644 Documentation/timers/Makefile
 delete mode 100644 Documentation/timers/hpet_example.c
 create mode 100644 samples/timers/.gitignore
 create mode 100644 samples/timers/Makefile
 create mode 100644 samples/timers/hpet_example.c

diff --git a/Documentation/Makefile b/Documentation/Makefile
index bd5f115..9c3fe11 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1 +1 @@
-subdir-y := blackfin timers watchdog
+subdir-y := blackfin watchdog
diff --git a/Documentation/timers/.gitignore b/Documentation/timers/.gitignore
deleted file mode 100644
index c5c45d7..000
--- a/Documentation/timers/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-hpet_example
diff --git a/Documentation/timers/Makefile b/Documentation/timers/Makefile
deleted file mode 100644
index 6c09ee6..000
--- a/Documentation/timers/Makefile
+++ /dev/null
@@ -1,5 +0,0 @@
-# List of programs to build
-hostprogs-$(CONFIG_X86) := hpet_example
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
diff --git a/Documentation/timers/hpet_example.c 
b/Documentation/timers/hpet_example.c
deleted file mode 100644
index 3ab4993..000
--- a/Documentation/timers/hpet_example.c
+++ /dev/null
@@ -1,294 +0,0 @@
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-
-extern void hpet_open_close(int, const char **);
-extern void hpet_info(int, const char **);
-extern void hpet_poll(int, const char **);
-extern void hpet_fasync(int, const char **);
-extern void hpet_read(int, const char **);
-
-#include 
-#include 
-
-struct hpet_command {
-   char*command;
-   void(*func)(int argc, const char ** argv);
-} hpet_command[] = {
-   {
-   "open-close",
-   hpet_open_close
-   },
-   {
-   "info",
-   hpet_info
-   },
-   {
-   "poll",
-   hpet_poll
-   },
-   {
-   "fasync",
-   hpet_fasync
-   },
-};
-
-int
-main(int argc, const char ** argv)
-{
-   unsigned inti;
-
-   argc--;
-   argv++;
-
-   if (!argc) {
-   fprintf(stderr, "-hpet: requires command\n");
-   return -1;
-   }
-
-
-   for (i = 0; i < (sizeof (hpet_command) / sizeof (hpet_command[0])); i++)
-   if (!strcmp(argv[0], hpet_command[i].command)) {
-   argc--;
-   argv++;
-   fprintf(stderr, "-hpet: executing %s\n",
-   hpet_command[i].command);
-   hpet_command[i].func(argc, argv);
-   return 0;
-   }
-
-   fprintf(stderr, "do_hpet: command %s not implemented\n", argv[0]);
-
-   return -1;
-}
-
-void
-hpet_open_close(int argc, const char **argv)
-{
-   int fd;
-
-   if (argc != 1) {
-   fprintf(stderr, "hpet_open_close: device-name\n");
-   return;
-   }
-
-   fd = open(argv[0], O_RDONLY);
-   if (fd < 0)
-   fprintf(stderr, "hpet_open_close: open failed\n");
-   else
-   close(fd);
-
-   return;
-}
-
-void
-hpet_info(int argc, const char **argv)
-{
-   struct hpet_infoinfo;
-   int fd;
-
-   if (argc != 1) {
-   fprintf(stderr, "hpet_info: device-name\n");
-   return;
-   }
-
-   fd = open(argv[0], O_RDONLY);
-   if (fd < 0) {
-   fprintf(stderr, "hpet_info: open of %s failed\n", argv[0]);
-   return;
-   }
-
-   if (ioctl(fd, HPET_INFO, ) < 0) {
-   fprintf(stderr, "hpet_info: failed to get info\n");
-   goto out;
-   }
-
-   fprintf(stderr, "hpet_info: hi_irqfreq 0x%lx hi_flags 0x%lx ",
-   info.hi_ireqfreq, info.hi_flags);
-   fprintf(stderr, "hi_hpet %d hi_timer %d\n",
-   info.hi_hpet, info.hi_timer);
-
-out:
-   close(fd);
-   return;
-}
-
-void
-hpet_poll(int argc, const char **argv)
-{
-   unsigned long   freq;
-   int   

[PATCH 2/8] samples: move auxdisplay example code from Documentation

[Shuah Khan]

Move auxdisplay examples to samples and remove it from Documentation
Makefile. Create a new Makefile to build auxdisplay. It can be built
from top level directory or from auxdisplay directory:

Run make -C samples/auxdisplay or cd samples/auxdisplay; make

Signed-off-by: Shuah Khan 
---
 Documentation/Makefile|   3 +-
 Documentation/auxdisplay/.gitignore   |   1 -
 Documentation/auxdisplay/Makefile |   7 -
 Documentation/auxdisplay/cfag12864b-example.c | 281 --
 samples/auxdisplay/.gitignore |   1 +
 samples/auxdisplay/Makefile   |   9 +
 samples/auxdisplay/cfag12864b-example.c   | 281 ++
 7 files changed, 292 insertions(+), 291 deletions(-)
 delete mode 100644 Documentation/auxdisplay/.gitignore
 delete mode 100644 Documentation/auxdisplay/Makefile
 delete mode 100644 Documentation/auxdisplay/cfag12864b-example.c
 create mode 100644 samples/auxdisplay/.gitignore
 create mode 100644 samples/auxdisplay/Makefile
 create mode 100644 samples/auxdisplay/cfag12864b-example.c

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 58c6629..60ec0dc 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1,2 +1 @@
-subdir-y := auxdisplay blackfin \
-   laptops mic misc-devices pcmcia timers watchdog
+subdir-y := blackfin laptops mic misc-devices pcmcia timers watchdog
diff --git a/Documentation/auxdisplay/.gitignore 
b/Documentation/auxdisplay/.gitignore
deleted file mode 100644
index 7af2228..000
--- a/Documentation/auxdisplay/.gitignore
+++ /dev/null
@@ -1 +0,0 @@
-cfag12864b-example
diff --git a/Documentation/auxdisplay/Makefile 
b/Documentation/auxdisplay/Makefile
deleted file mode 100644
index ada4dac..000
--- a/Documentation/auxdisplay/Makefile
+++ /dev/null
@@ -1,7 +0,0 @@
-# List of programs to build
-hostprogs-y := cfag12864b-example
-
-# Tell kbuild to always build the programs
-always := $(hostprogs-y)
-
-HOSTCFLAGS_cfag12864b-example.o += -I$(objtree)/usr/include
diff --git a/Documentation/auxdisplay/cfag12864b-example.c 
b/Documentation/auxdisplay/cfag12864b-example.c
deleted file mode 100644
index e7823ff..000
--- a/Documentation/auxdisplay/cfag12864b-example.c
+++ /dev/null
@@ -1,281 +0,0 @@
-/*
- *Filename: cfag12864b-example.c
- * Version: 0.1.0
- * Description: cfag12864b LCD userspace example program
- * License: GPLv2
- *
- *  Author: Copyright (C) Miguel Ojeda Sandonis
- *Date: 2006-10-31
- *
- *  This program is free software; you can redistribute it and/or modify
- *  it under the terms of the GNU General Public License version 2 as
- *  published by the Free Software Foundation.
- *
- *  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., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
- *
- */
-
-/*
- * 
- * start of cfag12864b code
- * 
- */
-
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#define CFAG12864B_WIDTH   (128)
-#define CFAG12864B_HEIGHT  (64)
-#define CFAG12864B_SIZE(128 * 64 / 8)
-#define CFAG12864B_BPB (8)
-#define CFAG12864B_ADDRESS(x, y)   ((y) * CFAG12864B_WIDTH / \
-   CFAG12864B_BPB + (x) / CFAG12864B_BPB)
-#define CFAG12864B_BIT(n)  (((unsigned char) 1) << (n))
-
-#undef CFAG12864B_DOCHECK
-#ifdef CFAG12864B_DOCHECK
-   #define CFAG12864B_CHECK(x, y)  ((x) < CFAG12864B_WIDTH && \
-   (y) < CFAG12864B_HEIGHT)
-#else
-   #define CFAG12864B_CHECK(x, y)  (1)
-#endif
-
-int cfag12864b_fd;
-unsigned char * cfag12864b_mem;
-unsigned char cfag12864b_buffer[CFAG12864B_SIZE];
-
-/*
- * init a cfag12864b framebuffer device
- *
- * No error:   return = 0
- * Unable to open: return = -1
- * Unable to mmap: return = -2
- */
-static int cfag12864b_init(char *path)
-{
-   cfag12864b_fd = open(path, O_RDWR);
-   if (cfag12864b_fd == -1)
-   return -1;
-
-   cfag12864b_mem = mmap(0, CFAG12864B_SIZE, PROT_READ | PROT_WRITE,
-   MAP_SHARED, cfag12864b_fd, 0);
-   if (cfag12864b_mem == MAP_FAILED) {
-   close(cfag12864b_fd);
-   return -2;
-   }
-
-   return 0;
-}
-
-/*
- * exit a cfag12864b framebuffer device
- */
-static void cfag12864b_exit(void)
-{
-   munmap(cfag12864b_mem, CFAG12864B_SIZE);
-   close(cfag12864b_fd);
-}
-
-/*
- * set (x, y) pixel
- */
-static void 

[PATCH 0/8] Move runnable examples code from Documentation to samples

[Shuah Khan]

Move runnable examples code from Documentation to samples. I moved
just the example code, and left documentation files as is.

blackfin gptimers example code needs a bit of special handling since
it is a module. I will address it in a separate patch. 00-Index files
need to be updated due to this move which will be done another patch.

Shuah Khan (8):
  samples: move accounting example code from Documentation
  samples: move auxdisplay example code from Documentation
  samples: move laptops example code from Documentation
  samples: move mic/mpssd example code from Documentation
  samples: move misc-devices/mei example code from Documentation
  samples: move pcmcia example code from Documentation
  samples: move timers example code from Documentation
  samples: move watchdog example code from Documentation

 Documentation/Makefile   |3 +-
 Documentation/accounting/.gitignore  |1 -
 Documentation/accounting/Makefile|7 -
 Documentation/accounting/getdelays.c |  550 ---
 Documentation/auxdisplay/.gitignore  |1 -
 Documentation/auxdisplay/Makefile|7 -
 Documentation/auxdisplay/cfag12864b-example.c|  281 
 Documentation/laptops/.gitignore |1 -
 Documentation/laptops/Makefile   |5 -
 Documentation/laptops/dslm.c |  166 --
 Documentation/mic/Makefile   |1 -
 Documentation/mic/mpssd/.gitignore   |1 -
 Documentation/mic/mpssd/Makefile |   21 -
 Documentation/mic/mpssd/micctrl  |  173 --
 Documentation/mic/mpssd/mpss |  200 ---
 Documentation/mic/mpssd/mpssd.c  | 1826 --
 Documentation/mic/mpssd/mpssd.h  |  103 --
 Documentation/mic/mpssd/sysfs.c  |  102 --
 Documentation/misc-devices/Makefile  |1 -
 Documentation/misc-devices/mei/.gitignore|1 -
 Documentation/misc-devices/mei/Makefile  |5 -
 Documentation/misc-devices/mei/TODO  |2 -
 Documentation/misc-devices/mei/mei-amt-version.c |  479 --
 Documentation/pcmcia/.gitignore  |1 -
 Documentation/pcmcia/Makefile|7 -
 Documentation/pcmcia/crc32hash.c |   32 -
 Documentation/timers/.gitignore  |1 -
 Documentation/timers/Makefile|5 -
 Documentation/timers/hpet_example.c  |  294 
 Documentation/watchdog/Makefile  |1 -
 Documentation/watchdog/src/.gitignore|1 -
 Documentation/watchdog/src/Makefile  |5 -
 Documentation/watchdog/src/watchdog-simple.c |   24 -
 samples/accounting/.gitignore|1 +
 samples/accounting/Makefile  |9 +
 samples/accounting/getdelays.c   |  550 +++
 samples/auxdisplay/.gitignore|1 +
 samples/auxdisplay/Makefile  |9 +
 samples/auxdisplay/cfag12864b-example.c  |  281 
 samples/laptops/.gitignore   |1 +
 samples/laptops/Makefile |9 +
 samples/laptops/dslm.c   |  166 ++
 samples/mei/.gitignore   |1 +
 samples/mei/Makefile |9 +
 samples/mei/TODO |2 +
 samples/mei/mei-amt-version.c|  479 ++
 samples/mic/mpssd/.gitignore |1 +
 samples/mic/mpssd/Makefile   |   27 +
 samples/mic/mpssd/micctrl|  173 ++
 samples/mic/mpssd/mpss   |  200 +++
 samples/mic/mpssd/mpssd.c| 1826 ++
 samples/mic/mpssd/mpssd.h|  103 ++
 samples/mic/mpssd/sysfs.c|  102 ++
 samples/pcmcia/.gitignore|1 +
 samples/pcmcia/Makefile  |9 +
 samples/pcmcia/crc32hash.c   |   32 +
 samples/timers/.gitignore|1 +
 samples/timers/Makefile  |   15 +
 samples/timers/hpet_example.c|  294 
 samples/watchdog/.gitignore  |1 +
 samples/watchdog/Makefile|8 +
 samples/watchdog/watchdog-simple.c   |   24 +
 62 files changed, 4336 insertions(+), 4307 deletions(-)
 delete mode 100644 Documentation/accounting/.gitignore
 delete mode 100644 Documentation/accounting/Makefile
 delete mode 100644 Documentation/accounting/getdelays.c
 delete mode 100644 Documentation/auxdisplay/.gitignore
 delete mode 100644 Documentation/auxdisplay/Makefile
 delete mode 100644 Documentation/auxdisplay/cfag12864b-example.c
 delete mode 100644 

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

[Dalessandro, Dennis]

On Wed, 2016-09-14 at 12:36 +0530, Parav Pandit wrote:
> Hi Dennis,
> 
> Do you know how would HFI1 driver would work along with rdma cgroup?

Keep in mind HFI1 driver has two "modes" of operation. We support
verbs, and would surely fall in line with whatever cgroups do for IB
core. For our psm interface, not sure how cgroups would come into play.
Psm is designed to expose the hw to user and avoid the kernel when
possible adding more kernel control is sort of contrary to that.

Now that being said, Christoph recently made mention of maybe having a
drivers/psm [1]. I really haven't had a chance to think about the
implications of that, but maybe it's worth considering, after all we
have two implementations, qib and hfi1. So anyway I'm not sure we need
to be too concerned about cgroups right now as far as psm side of
things goes.

Depending how things shake out for the uAPI rewrite, or verbs 2.0 or
whatever we are calling it today things may change.

[1] http://marc.info/?l=linux-rdma=147401714313831=2

-Denny

> Hi Matan, Leon, Jason,
> Apart from HFI1, is there any other concern?
> Or Patch is good to go?
> 
> 4.8 dates are close by (2 weeks) and there are two git trees involved
> (that might cause merge error to Linus) so if there are no issues, I
> would like to make request to Doug to consider it for 4.8 early on.
> 
> Parav
> 
> On Mon, Sep 12, 2016 at 10:37 AM, Leon Romanovsky 
> wrote:
> > On Sun, Sep 11, 2016 at 11:52:35AM -0600, Jason Gunthorpe wrote:
> > > On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig
> > > wrote:
> > > > > > > I've posted some initial work toward a) a while ago, and
> > > > > > > once we
> > > > > 
> > > > > Did it get merged? Do you have a pointer?
> > > > 
> > > > http://www.spinics.net/lists/linux-rdma/msg31958.html
> > > 
> > > Right, I remember that. Certainly the right direction
> > > 
> > > > > However, everything under verbs is not straightforward. The
> > > > > files in
> > > > > userspace are not copies...
> > > > > 
> > > > > user:
> > > > > 
> > > > > struct ibv_query_device {
> > > > >    __u32 command;
> > > > >    __u16 in_words;
> > > > >    __u16 out_words;
> > > > >    __u64 response;
> > > > >    __u64 driver_data[0];
> > > > > };
> > > > > 
> > > > > kernel:
> > > > > 
> > > > > struct ib_uverbs_query_device {
> > > > > __u64 response;
> > > > > __u64 driver_data[0];
> > > > > };
> > > > 
> > > > We'll obviously need different strutures for the libibvers API
> > > > and the kernel interface in this case, and we'll need to figure
> > > > out
> > > > how to properly translate them.  I think a cast, plus compile
> > > > time
> > > > type checking ala BUILD_BUG_ON is the way to go.
> > > 
> > > I'm not sure I follow, which would I cast?
> > > 
> > > BUILD_BUG_ON(sizeof(ibv_query_device) ==
> > > sizeof(ib_uverbs_cmd_hdr) +
> > >  sizeof(ib_uverbs_query_device))
> > > 
> > > ?
> > > 
> > > > > I'm thinking the best way forward might be to use a script
> > > > > and
> > > > > transform userspace into:
> > > > > 
> > > > > struct ibv_query_device {
> > > > >   struct ib_uverbs_cmd_hdr hdr;
> > > > >   struct ib_uverbs_query_device cmd;
> > > > > };
> > > > 
> > > > That would break the users of the interface.
> > > 
> > > Sorry, I mean doing this inside rdma-plumbing. Since the change
> > > is ABI
> > > identical the modified libibverbs would still be binary
> > > compatible
> > > with all providers but not source compatible. Since all kernel
> > > supported providers are in rdma-plumbing we can add the '.cmd.'
> > > at the
> > > same time.
> > > 
> > > The kernel uapi header would stay the same.
> > > 
> > > > However automatically generating the user ABI from the kernel
> > > > one
> > > > might still be a good idea in the long run.
> > > 
> > > My preference would be to try and use the kernel headers
> > > directly.
> > 
> > I thought the same, especially after realizing that they are almost
> > copy/paste from the vendor *-abi.h files.
> > 
> > > 
> > > Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

"CodingStyle: Clarify and complete chapter 7" in docs-next (was Re: [PATCH 03/47] block-rbd: Adjust the position of a jump label in rbd_header_from_disk())

[Ilya Dryomov]

On Mon, Sep 19, 2016 at 11:37 AM, Jean Delvare  wrote:
> Hi Ilya,
>
> Sorry for the late answer.
>
> On Tue, 13 Sep 2016 20:31:57 +0200, Ilya Dryomov wrote:
>> Sorry, navigating lkml.org archive is a pain, and I was expecting to
>> see patch.  Your points
>>
>> "The acceptance of an optional single space before labels dates back to
>> at least June 2007, as supported by the very first incarnation of
>> checkpatch.pl. So nothing really new here, except for a preference
>> (my preference, admittedly, but I'm know I'm not alone) being expressed
>> in the coding style document."
>>
>> "Recommendations are not meant to document what people are currently
>> doing but what we think they should be doing."
>>
>> are valid, but note that there is a world of difference between an
>> acceptance and a preference.  The *only* point of whitespace guidelines
>> is to keep the code base consistent.
>
> Consistency is half of the reason, the other half is readability. This
> is why the CodingStyle document has a number of rationales explained.
> This is also why we put whitespace in the first place, while the C
> language doesn't require any ;-)
>
> The sense of my proposal was to address a readability (or usability)
> issue.
>
>> You don't go changing whitespace
>> preferences in such a huge project, not unless you have a *very* good
>> rationale and existing code base is swayed (which it isn't, given the
>> 9/10 ratio).
>
> I did consider the reason to be good enough to warrant a "change",
> actually. Or more exactly from "one space is allowed" to "one space is
> recommended." Which is quite different from changing all the code
> actively. I can understand how you don't like it, but again, this
> "inconsistency" has been accepted for almost a decade now, so I find it
> strange to see so much resistance when someone finally tries to sort it
> out.

Yeah, I guess that's where our disagreement lies - the "so that `diff
-p` does not confuse labels with functions" in the age of git, hg and
others, all of which can be customized to your heart's content is not
a good enough reason to go from "allowed" to "advised".

>
>> >> If I wanted to clarify the
>> >> situation, I'd have gone with "one space indented labels are also
>> >> acceptable" or so.  The example you've re-indented dates back to 2.6.4
>> >> times...
>> >
>> > I can't see how this is relevant.
>>
>> That was a 12 year old example, codifying an existing style used in
>> ~90% cases, serving as a guideline for new contributors.
>
> OK, I get your point now. But the CodingStyle document isn't carved
> into stone. I see 43 changes to that file in recent history (since
> April 2005), some of which are actual changes or clarifications of our
> coding style. This very section of the document was updated in December
> 2014, so not so long ago.
>
> In the end I suppose it boils down to how problematic you consider the
> current situation to be. Apparently you and several other maintainers
> think it's just fine, while me (and a few others apparently) think it
> is not.
>
>> >> git diff also works on regular files, BTW.
>> >
>> > I have no idea what you mean here, sorry.
>>
>> Oh, just that it works outside of git repos too, so you aren't stuck
>> with diffutils if you want to diff two random .c files.
>
> Oh, I had never thought of that. Thanks for the hint :-)
>
>> > (...)
>> > http://marc.info/?l=linux-kernel=147325166209844=2
>> >
>> > It uses the git diff xfuncname feature you mentioned above. To be
>> > honest I'm surprised it isn't the git default, it seems odd to have so
>> > many diff drivers included in git and not enable them on obvious file
>> > extensions. Oh well.
>>
>> This came up before: http://www.spinics.net/lists/git/msg164216.html,
>> Linus didn't like it.  I suggest you add him to the CC on this patch to
>> see if he changed his mind.
>
> Thanks for the pointer. It is interesting to see many people had been
> bothered by the same problem for many years and even proposed solution
> for it. But also sad to see that nothing happened :-(
>
> Well Linus suggested to improve the default, he was not opposed to the
> change per se I think. But it was 5 years ago and nothing happened
> since then, so I'd rather go with what is available today. Which means
> either one space before labels, or drivers in .gitattributes. Choose
> your poison ;-)

Jon, ping?  My points upthread aside, both CodingStyle and
.gitattributes patches seem to be queued...

Thanks,

Ilya
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 2/3] powerpc/mm: allow memory hotplug into a memoryless node

[Balbir Singh]

On 15/09/16 06:06, Reza Arbab wrote:
> Remove the check which prevents us from hotplugging into an empty node.
> 
> This limitation has been questioned before [1], and judging by the
> response, there doesn't seem to be a reason we can't remove it. No issues
> have been found in light testing.
> 
> [1] 
> http://lkml.kernel.org/r/cagzkibrmksa1yyhbf5hwgxubcjse5smksmy4tpanerme2ug...@mail.gmail.com
> 
> http://lkml.kernel.org/r/20160511215051.gf22...@arbab-laptop.austin.ibm.com
> 
> Signed-off-by: Reza Arbab 
> Acked-by: Balbir Singh 
> Cc: Nathan Fontenot 
> Cc: Bharata B Rao 
> ---
>  arch/powerpc/mm/numa.c | 13 +
>  1 file changed, 1 insertion(+), 12 deletions(-)
> 

I presume you've tested with CONFIG_NODES_SHIFT of 8 (255 nodes?)

Balbir Singh.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 13/29] Documentation/CodingStyle: use the .. note:: markup where needed

[Mauro Carvalho Chehab]

There are two places there where there are notes that should
be highlighted. So, use the ReST note markup for such texts.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/CodingStyle | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 0024c36b8046..7e30da38bb3a 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -333,9 +333,11 @@ useful only for:
  Example: ``pte_t`` etc. opaque objects that you can only access using
  the proper accessor functions.
 
- NOTE! Opaqueness and ``accessor functions`` are not good in themselves.
- The reason we have them for things like pte_t etc. is that there
- really is absolutely **zero** portably accessible information there.
+ .. note::
+
+   Opaqueness and ``accessor functions`` are not good in themselves.
+   The reason we have them for things like pte_t etc. is that there
+   really is absolutely **zero** portably accessible information there.
 
  (b) Clear integer types, where the abstraction **helps** avoid confusion
  whether it is ``int`` or ``long``.
@@ -343,8 +345,10 @@ useful only for:
  u8/u16/u32 are perfectly fine typedefs, although they fit into
  category (d) better than here.
 
- NOTE! Again - there needs to be a **reason** for this. If something is
- ``unsigned long``, then there's no reason to do
+ .. note::
+
+   Again - there needs to be a **reason** for this. If something is
+   ``unsigned long``, then there's no reason to do
 
typedef unsigned long myflags_t;
 
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 19/29] Documentation/SubmittingPatches: convert it to ReST markup

[Mauro Carvalho Chehab]

- Change the sections to use ReST markup;
- Add cross-references where needed;
- convert aspas to verbatim text;
- use code block tags;
- make Sphinx happy.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/SubmittingPatches | 207 
 1 file changed, 105 insertions(+), 102 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 8c79f1d53731..04a4284d8ee4 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -1,9 +1,6 @@
 
-   How to Get Your Change Into the Linux Kernel
-   or
-   Care And Operation Of Your Linus Torvalds
-
-
+How to Get Your Change Into the Linux Kernel or Care And Operation Of Your 
Linus Torvalds
+=
 
 For a person or company who wishes to submit a change to the Linux
 kernel, the process can sometimes be daunting if you're not familiar
@@ -24,9 +21,8 @@ of the mechanical work done for you, though you'll still need 
to prepare
 and document a sensible set of patches.  In general, use of git will make
 your life as a kernel developer easier.
 
-
-SECTION 1 - CREATING AND SENDING YOUR CHANGE
-
+Creating and Sending your Change
+
 
 
 0) Obtain a current source tree
@@ -34,35 +30,35 @@ SECTION 1 - CREATING AND SENDING YOUR CHANGE
 
 If you do not have a repository with the current kernel source handy, use
 git to obtain one.  You'll want to start with the mainline repository,
-which can be grabbed with:
+which can be grabbed with::
 
-  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
+  git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
 
 Note, however, that you may not want to develop against the mainline tree
 directly.  Most subsystem maintainers run their own trees and want to see
-patches prepared against those trees.  See the "T:" entry for the subsystem
+patches prepared against those trees.  See the **T:** entry for the subsystem
 in the MAINTAINERS file to find that tree, or simply ask the maintainer if
 the tree is not listed there.
 
 It is still possible to download kernel releases via tarballs (as described
 in the next section), but that is the hard way to do kernel development.
 
-1) "diff -up"
-
+1) ``diff -up``
+---
 
-If you must generate your patches by hand, use "diff -up" or "diff -uprN"
+If you must generate your patches by hand, use ``diff -up`` or ``diff -uprN``
 to create patches.  Git generates patches in this form by default; if
 you're using git, you can skip this section entirely.
 
 All changes to the Linux kernel occur in the form of patches, as
 generated by diff(1).  When creating your patch, make sure to create it
-in "unified diff" format, as supplied by the '-u' argument to diff(1).
-Also, please use the '-p' argument which shows which C function each
+in "unified diff" format, as supplied by the ``-u`` argument to diff(1).
+Also, please use the ``-p`` argument which shows which C function each
 change is in - that makes the resultant diff a lot easier to read.
 Patches should be based in the root kernel source directory,
 not in any lower subdirectory.
 
-To create a patch for a single file, it is often sufficient to do:
+To create a patch for a single file, it is often sufficient to do::
 
SRCTREE= linux
MYFILE=  drivers/net/mydriver.c
@@ -75,7 +71,7 @@ To create a patch for a single file, it is often sufficient 
to do:
 
 To create a patch for multiple files, you should unpack a "vanilla",
 or unmodified kernel source tree, and generate a diff against your
-own source tree.  For example:
+own source tree.  For example::
 
MYSRC= /devel/linux
 
@@ -84,7 +80,7 @@ own source tree.  For example:
diff -uprN -X linux-3.19-vanilla/Documentation/dontdiff \
linux-3.19-vanilla $MYSRC > /tmp/patch
 
-"dontdiff" is a list of files which are generated by the kernel during
+``dontdiff`` is a list of files which are generated by the kernel during
 the build process, and should be ignored in any diff(1)-generated
 patch.
 
@@ -93,18 +89,18 @@ belong in a patch submission.  Make sure to review your 
patch -after-
 generating it with diff(1), to ensure accuracy.
 
 If your changes produce a lot of deltas, you need to split them into
-individual patches which modify things in logical stages; see section
-#3.  This will facilitate review by other kernel developers,
+individual patches which modify things in logical stages; see
+:ref:`split_changes`.  This will facilitate review by other kernel developers,
 very important if you want your patch accepted.
 
-If you're using git, "git rebase -i" can help you with this process.  If
+If you're using git, ``git rebase -i`` can help you 

[PATCH v4 22/29] Documentation/HOWTO: add cross-references to other documents

[Mauro Carvalho Chehab]

Add cross references for the documents mentioned at HOWTO and
are under the Documentation/ directory, using the ReST notation.

It should be noticed that HOWTO also mentions the /README file.
We opted to not touch it, for now, as making it build on
Sphinx would require it to be moved to a Documentation/foo
directory.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/Changes |  2 ++
 Documentation/CodingStyle |  2 ++
 Documentation/HOWTO   | 18 +-
 Documentation/ManagementStyle |  2 ++
 Documentation/SecurityBugs|  2 ++
 Documentation/SubmittingDrivers   |  2 ++
 Documentation/SubmittingPatches   |  1 +
 Documentation/applying-patches.txt|  1 +
 Documentation/kernel-docs.txt |  2 ++
 Documentation/stable_api_nonsense.txt |  2 ++
 Documentation/stable_kernel_rules.txt |  2 ++
 11 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/Documentation/Changes b/Documentation/Changes
index 93c8e1c15844..754cd50c1bc6 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -1,3 +1,5 @@
+.. _changes:
+
 Minimal requerements to compile the Kernel
 ++
 
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 7e30da38bb3a..852253c932fe 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -1,3 +1,5 @@
+.. _codingstyle:
+
 Linux kernel coding style
 =
 
diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 5a85e3a8112b..31c8df5d20c7 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -90,19 +90,19 @@ required reading:
 what is necessary to do to configure and build the kernel.  People
 who are new to the kernel should start here.
 
-  Documentation/Changes
+  :ref:`Documentation/Changes `
 This file gives a list of the minimum levels of various software
 packages that are necessary to build and run the kernel
 successfully.
 
-  Documentation/CodingStyle
+  :ref:`Documentation/CodingStyle `
 This describes the Linux kernel coding style, and some of the
 rationale behind it. All new code is expected to follow the
 guidelines in this document. Most maintainers will only accept
 patches if these rules are followed, and many people will only
 review code if it is in the proper style.
 
-  Documentation/SubmittingPatches and Documentation/SubmittingDrivers
+  :ref:`Documentation/SubmittingPatches ` and 
:ref:`Documentation/SubmittingDrivers `
 These files describe in explicit detail how to successfully create
 and send a patch, including (but not limited to):
 
@@ -124,7 +124,7 @@ required reading:
 
http://linux.yyz.us/patch-format.html
 
-  Documentation/stable_api_nonsense.txt
+  :ref:`Documentation/stable_api_nonsense.txt `
 This file describes the rationale behind the conscious decision to
 not have a stable API within the kernel, including things like:
 
@@ -137,29 +137,29 @@ required reading:
 philosophy and is very important for people moving to Linux from
 development on other Operating Systems.
 
-  Documentation/SecurityBugs
+  :ref:`Documentation/SecurityBugs `
 If you feel you have found a security problem in the Linux kernel,
 please follow the steps in this document to help notify the kernel
 developers, and help solve the issue.
 
-  Documentation/ManagementStyle
+  :ref:`Documentation/ManagementStyle `
 This document describes how Linux kernel maintainers operate and the
 shared ethos behind their methodologies.  This is important reading
 for anyone new to kernel development (or anyone simply curious about
 it), as it resolves a lot of common misconceptions and confusion
 about the unique behavior of kernel maintainers.
 
-  Documentation/stable_kernel_rules.txt
+  :ref:`Documentation/stable_kernel_rules.txt `
 This file describes the rules on how the stable kernel releases
 happen, and what to do if you want to get a change into one of these
 releases.
 
-  Documentation/kernel-docs.txt
+  :ref:`Documentation/kernel-docs.txt `
 A list of external documentation that pertains to kernel
 development.  Please consult this list if you do not find what you
 are looking for within the in-kernel documentation.
 
-  Documentation/applying-patches.txt
+  :ref:`Documentation/applying-patches.txt `
 A good introduction describing exactly what a patch is and how to
 apply it to the different development branches of the kernel.
 
diff --git a/Documentation/ManagementStyle b/Documentation/ManagementStyle
index 1471df6015a2..dea2e66c9a10 100644
--- a/Documentation/ManagementStyle
+++ b/Documentation/ManagementStyle
@@ -1,3 +1,5 @@
+.. _managementstyle:
+
 Linux kernel management style
 =
 
diff --git a/Documentation/SecurityBugs b/Documentation/SecurityBugs
index 

[PATCH v4 26/29] Documentation/SubmitChecklist: update kernel-doc task

[Mauro Carvalho Chehab]

Task 11 (kernel-doc) still mentions usage of make manpages, but
this won't work if the API is documented via Sphinx. So, update
it to use either htmldocs or pdfdocs, with are the documentation
targets that work for all.

While here, add ReST reference to the kernel documentation book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/SubmitChecklist  | 7 ---
 Documentation/kernel-documentation.rst | 2 ++
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist
index 2b7e32dfe00d..bb114c8a781c 100644
--- a/Documentation/SubmitChecklist
+++ b/Documentation/SubmitChecklist
@@ -47,9 +47,10 @@ kernel patches.
 but any one function that uses more than 512 bytes on the stack is a
 candidate for change.
 
-11: Include kernel-doc to document global kernel APIs.  (Not required for
-static functions, but OK there also.) Use 'make htmldocs' or 'make
-mandocs' to check the kernel-doc and fix any issues.
+11: Include :ref:`kernel-doc ` to document global  kernel APIs.
+(Not required for static functions, but OK there also.) Use
+``make htmldocs`` or ``make pdfdocs`` to check the
+:ref:`kernel-doc ` and fix any issues.
 
 12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
 CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
diff --git a/Documentation/kernel-documentation.rst 
b/Documentation/kernel-documentation.rst
index a0dcae15639b..10cc7ddb6235 100644
--- a/Documentation/kernel-documentation.rst
+++ b/Documentation/kernel-documentation.rst
@@ -294,6 +294,8 @@ The kernel-doc extension is included in the kernel source 
tree, at
 ``scripts/kernel-doc`` script to extract the documentation comments from the
 source.
 
+.. _kernel_doc:
+
 Writing kernel-doc comments
 ===
 
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 23/29] Documentation/HOWTO: update information about generating documentation

[Mauro Carvalho Chehab]

The description there are pre-Sphinx. Update it to cover the
new way.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/HOWTO | 28 ++--
 1 file changed, 22 insertions(+), 6 deletions(-)

diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 31c8df5d20c7..f297d5512885 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -164,21 +164,37 @@ required reading:
 apply it to the different development branches of the kernel.
 
 The kernel also has a large number of documents that can be
-automatically generated from the source code itself.  This includes a
+automatically generated from the source code itself or from
+ReStructuredText markups (ReST), like this one. This includes a
 full description of the in-kernel API, and rules on how to handle
-locking properly.  The documents will be created in the
-Documentation/DocBook/ directory and can be generated as PDF,
-Postscript, HTML, and man pages by running:
+locking properly.
+
+All such documents can be generated as PDF or HTML by running:
 
 ::
 
make pdfdocs
-   make psdocs
make htmldocs
-   make mandocs
 
 respectively from the main kernel source directory.
 
+The documents that uses ReST markup will be generated at Documentation/output.
+They can also be generated on LaTeX and ePub formats with:
+
+::
+
+   make latexdocs
+   make epubdocs
+
+Currently, there are some documents written on DocBook that are in
+the process of conversion to ReST. Such documents will be created in the
+Documentation/DocBook/ directory and can be generated also as
+Postscript or man pages by running:
+
+::
+
+   make psdocs
+   make mandocs
 
 Becoming A Kernel Developer
 ---
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 28/29] Documentation/email-clients.txt: convert it to ReST markup

[Mauro Carvalho Chehab]

As this file is mentioned at the development-process/ book,
let's convert it to ReST markup.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/SubmittingPatches |   2 +-
 Documentation/development-process/5.Posting.rst |   2 +-
 Documentation/email-clients.txt | 214 ++--
 Documentation/ja_JP/SubmittingPatches   |   2 +-
 Documentation/zh_CN/email-clients.txt   |   4 +-
 5 files changed, 127 insertions(+), 97 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 9c3dfa7babf3..801f5cd5103b 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -358,7 +358,7 @@ decreasing the likelihood of your MIME-attached change 
being accepted.
 Exception:  If your mailer is mangling patches then someone may ask
 you to re-send them using MIME.
 
-See Documentation/email-clients.txt for hints about configuring
+See Documentation/development-process/email-clients.rst for hints about 
configuring
 your e-mail client so that it sends your patches untouched.
 
 7) E-mail size
diff --git a/Documentation/development-process/5.Posting.rst 
b/Documentation/development-process/5.Posting.rst
index b511ddf7e82a..945d40200538 100644
--- a/Documentation/development-process/5.Posting.rst
+++ b/Documentation/development-process/5.Posting.rst
@@ -248,7 +248,7 @@ take care of:
be examined in any detail.  If there is any doubt at all, mail the patch
to yourself and convince yourself that it shows up intact.
 
-   Documentation/email-clients.txt has some helpful hints on making
+   Documentation/development-process/email-clients.rst has some helpful hints 
on making
specific mail clients work for sending patches.
 
  - Are you sure your patch is free of silly mistakes?  You should always
diff --git a/Documentation/email-clients.txt b/Documentation/email-clients.txt
index 2d485dea8cec..0deb240bee56 100644
--- a/Documentation/email-clients.txt
+++ b/Documentation/email-clients.txt
@@ -1,23 +1,25 @@
 Email clients info for Linux
-==
+
 
 Git
---
-These days most developers use `git send-email` instead of regular
+---
+
+These days most developers use ``git send-email`` instead of regular
 email clients.  The man page for this is quite good.  On the receiving
-end, maintainers use `git am` to apply the patches.
+end, maintainers use ``git am`` to apply the patches.
 
-If you are new to git then send your first patch to yourself.  Save it
-as raw text including all the headers.  Run `git am raw_email.txt` and
-then review the changelog with `git log`.  When that works then send
+If you are new to ``git`` then send your first patch to yourself.  Save it
+as raw text including all the headers.  Run ``git am raw_email.txt`` and
+then review the changelog with ``git log``.  When that works then send
 the patch to the appropriate mailing list(s).
 
 General Preferences
---
+---
+
 Patches for the Linux kernel are submitted via email, preferably as
 inline text in the body of the email.  Some maintainers accept
 attachments, but then the attachments should have content-type
-"text/plain".  However, attachments are generally frowned upon because
+``text/plain``.  However, attachments are generally frowned upon because
 it makes quoting portions of the patch more difficult in the patch
 review process.
 
@@ -25,7 +27,7 @@ Email clients that are used for Linux kernel patches should 
send the
 patch text untouched.  For example, they should not modify or delete tabs
 or spaces, even at the beginning or end of lines.
 
-Don't send patches with "format=flowed".  This can cause unexpected
+Don't send patches with ``format=flowed``.  This can cause unexpected
 and unwanted line breaks.
 
 Don't let your email client do automatic word wrapping for you.
@@ -54,57 +56,63 @@ mailing lists.
 
 
 Some email client (MUA) hints
---
+-
+
 Here are some specific MUA configuration hints for editing and sending
 patches for the Linux kernel.  These are not meant to be complete
 software package configuration summaries.
 
+
 Legend:
-TUI = text-based user interface
-GUI = graphical user interface
 
-~~
+- TUI = text-based user interface
+- GUI = graphical user interface
+
 Alpine (TUI)
+
 
 Config options:
-In the "Sending Preferences" section:
 
-- "Do Not Send Flowed Text" must be enabled
-- "Strip Whitespace Before Sending" must be disabled
+In the :menuselection:`Sending Preferences` section:
+
+- :menuselection:`Do Not Send Flowed Text` must be ``enabled``
+- :menuselection:`Strip 

[PATCH v4 24/29] Documentation/HOWTO: improve some markups to make it visually better

[Mauro Carvalho Chehab]

Do a series of minor improvements at the ReST output format:

- Instead of using the quote blocks (::) for quotes, use
italics. That looks nicer on epub (and html) output, as
no scroll bar will be added. Also, it will adjust line
breaks on the text automatically.

- Add a missing reference to SubmittingPatches.rst and use
**foo** instead of _foo_.

- use bold for "The Perfect Patch" by removing a newline.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/HOWTO | 36 
 1 file changed, 16 insertions(+), 20 deletions(-)

diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index f297d5512885..784724aa4f34 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -292,11 +292,9 @@ process is as follows:
 It is worth mentioning what Andrew Morton wrote on the linux-kernel
 mailing list about kernel releases:
 
-::
-
-   "Nobody knows when a kernel will be released, because it's
+   *"Nobody knows when a kernel will be released, because it's
released according to perceived bug status, not according to a
-   preconceived timeline."
+   preconceived timeline."*
 
 4.x.y -stable kernel tree
 -
@@ -449,13 +447,14 @@ add your statements between the individual quoted 
sections instead of
 writing at the top of the mail.
 
 If you add patches to your mail, make sure they are plain readable text
-as stated in Documentation/SubmittingPatches. Kernel developers don't
-want to deal with attachments or compressed patches; they may want
-to comment on individual lines of your patch, which works only that way.
-Make sure you use a mail program that does not mangle spaces and tab
-characters. A good first test is to send the mail to yourself and try
-to apply your own patch by yourself. If that doesn't work, get your
-mail program fixed or change it until it works.
+as stated in Documentation/SubmittingPatches.
+Kernel developers don't want to deal with
+attachments or compressed patches; they may want to comment on
+individual lines of your patch, which works only that way. Make sure you
+use a mail program that does not mangle spaces and tab characters. A
+good first test is to send the mail to yourself and try to apply your
+own patch by yourself. If that doesn't work, get your mail program fixed
+or change it until it works.
 
 Above all, please remember to show respect to other subscribers.
 
@@ -496,8 +495,8 @@ Remember, being wrong is acceptable as long as you are 
willing to work
 toward a solution that is right.
 
 It is normal that the answers to your first patch might simply be a list
-of a dozen things you should correct.  This does _not_ imply that your
-patch will not be accepted, and it is _not_ meant against you
+of a dozen things you should correct.  This does **not** imply that your
+patch will not be accepted, and it is **not** meant against you
 personally.  Simply correct all issues raised against your patch and
 resend it.
 
@@ -582,19 +581,17 @@ The reasons for breaking things up are the following:
 
 Here is an analogy from kernel developer Al Viro:
 
-::
-
-   "Think of a teacher grading homework from a math student.  The
+   *"Think of a teacher grading homework from a math student.  The
teacher does not want to see the student's trials and errors
before they came up with the solution. They want to see the
cleanest, most elegant answer.  A good student knows this, and
would never submit her intermediate work before the final
-   solution.
+   solution.*
 
-   The same is true of kernel development. The maintainers and
+   *The same is true of kernel development. The maintainers and
reviewers do not want to see the thought process behind the
solution to the problem one is solving. They want to see a
-   simple and elegant solution."
+   simple and elegant solution."*
 
 It may be challenging to keep the balance between presenting an elegant
 solution and working together with the community and discussing your
@@ -632,7 +629,6 @@ For more details on what this should all look like, please 
see the
 ChangeLog section of the document:
 
   "The Perfect Patch"
-
   http://www.ozlabs.org/~akpm/stuff/tpp.txt
 
 
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 12/29] Documentation/CodingStyle: replace underline markups

[Mauro Carvalho Chehab]

Sphinx doesn't accept underline markups by purpose.
While there are ways to support underline via CSS, this won't
be portable with non-html outputs.

As we want CodingStyle to do emphasis, replace _foo_ by **foo**,
using bold emphasis.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/CodingStyle | 32 
 1 file changed, 16 insertions(+), 16 deletions(-)

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index c25528d76af1..0024c36b8046 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -2,7 +2,7 @@ Linux kernel coding style
 =
 
 This is a short document describing the preferred coding style for the
-linux kernel.  Coding style is very personal, and I won't _force_ my
+linux kernel.  Coding style is very personal, and I won't **force** my
 views on anybody, but this is what goes for anything that I have to be
 able to maintain, and I'd prefer it for most other things too.  Please
 at least consider the points made here.
@@ -136,10 +136,10 @@ opening brace at the beginning of the next line, thus:
 
 Heretic people all over the world have claimed that this inconsistency
 is ...  well ...  inconsistent, but all right-thinking people know that
-(a) K are _right_ and (b) K are right.  Besides, functions are
+(a) K are **right** and (b) K are right.  Besides, functions are
 special anyway (you can't nest them in C).
 
-Note that the closing brace is empty on a line of its own, _except_ in
+Note that the closing brace is empty on a line of its own, **except** in
 the cases where it is followed by a continuation of the same statement,
 ie a ``while`` in a do-statement or an ``else`` in an if-statement, like
 this:
@@ -283,10 +283,10 @@ HOWEVER, while mixed-case names are frowned upon, 
descriptive names for
 global variables are a must.  To call a global function ``foo`` is a
 shooting offense.
 
-GLOBAL variables (to be used only if you _really_ need them) need to
+GLOBAL variables (to be used only if you **really** need them) need to
 have descriptive names, as do global functions.  If you have a function
 that counts the number of active users, you should call that
-``count_active_users()`` or similar, you should _not_ call it ``cntusr()``.
+``count_active_users()`` or similar, you should **not** call it ``cntusr()``.
 
 Encoding the type of a function into the name (so-called Hungarian
 notation) is brain damaged - the compiler knows the types anyway and can
@@ -308,7 +308,7 @@ See chapter 6 (Functions).
 ---
 
 Please don't use things like ``vps_t``.
-It's a _mistake_ to use typedef for structures and pointers. When you see a
+It's a **mistake** to use typedef for structures and pointers. When you see a
 
 .. code-block:: c
 
@@ -327,7 +327,7 @@ you can actually tell what ``a`` is.
 Lots of people think that typedefs ``help readability``. Not so. They are
 useful only for:
 
- (a) totally opaque objects (where the typedef is actively used to _hide_
+ (a) totally opaque objects (where the typedef is actively used to **hide**
  what the object is).
 
  Example: ``pte_t`` etc. opaque objects that you can only access using
@@ -335,15 +335,15 @@ useful only for:
 
  NOTE! Opaqueness and ``accessor functions`` are not good in themselves.
  The reason we have them for things like pte_t etc. is that there
- really is absolutely _zero_ portably accessible information there.
+ really is absolutely **zero** portably accessible information there.
 
- (b) Clear integer types, where the abstraction _helps_ avoid confusion
+ (b) Clear integer types, where the abstraction **helps** avoid confusion
  whether it is ``int`` or ``long``.
 
  u8/u16/u32 are perfectly fine typedefs, although they fit into
  category (d) better than here.
 
- NOTE! Again - there needs to be a _reason_ for this. If something is
+ NOTE! Again - there needs to be a **reason** for this. If something is
  ``unsigned long``, then there's no reason to do
 
typedef unsigned long myflags_t;
@@ -352,7 +352,7 @@ useful only for:
  might be an ``unsigned int`` and under other configurations might be
  ``unsigned long``, then by all means go ahead and use a typedef.
 
- (c) when you use sparse to literally create a _new_ type for
+ (c) when you use sparse to literally create a **new** type for
  type-checking.
 
  (d) New types which are identical to standard C99 types, in certain
@@ -381,7 +381,7 @@ Maybe there are other cases too, but the rule should 
basically be to NEVER
 EVER use a typedef unless you can clearly match one of those rules.
 
 In general, a pointer, or a struct that has elements that can reasonably
-be directly accessed should _never_ be a typedef.
+be directly accessed should **never** be a typedef.
 
 
 6) Functions
@@ -509,7 +509,7 @@ Ideally you should simulate errors to test all exit paths.
 
 Comments are good, but there is also a 

[PATCH v4 07/29] Documentation/applying-patches.txt: Update the information there

[Mauro Carvalho Chehab]

This document is old: it is from Kernel v2.6.12 days.
Update it to the current status, and add a reference for the
linux-next tree.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/applying-patches.txt | 255 -
 1 file changed, 110 insertions(+), 145 deletions(-)

diff --git a/Documentation/applying-patches.txt 
b/Documentation/applying-patches.txt
index 573eb3bee19e..0e873dbf5566 100644
--- a/Documentation/applying-patches.txt
+++ b/Documentation/applying-patches.txt
@@ -6,7 +6,7 @@ Original by:
Jesper Juhl, August 2005
 
 Last update:
-   2006-01-05
+   2016-09-14
 
 
 A frequently asked question on the Linux Kernel Mailing List is how to apply
@@ -90,23 +90,23 @@ this:
 
patch -p1 -i path/to/patch-x.y.z
 
-If your patch file is compressed with gzip or bzip2 and you don't want to
+If your patch file is compressed with gzip or xz and you don't want to
 uncompress it before applying it, then you can feed it to patch like this
 instead:
 
 ::
 
-   zcat path/to/patch-x.y.z.gz | patch -p1
-   bzcat path/to/patch-x.y.z.bz2 | patch -p1
+   xzcat path/to/patch-x.y.z.xz | patch -p1
+   bzcat path/to/patch-x.y.z.gz | patch -p1
 
 If you wish to uncompress the patch file by hand first before applying it
 (what I assume you've done in the examples below), then you simply run
-gunzip or bunzip2 on the file -- like this:
+gunzip or xz on the file -- like this:
 
 ::
 
gunzip patch-x.y.z.gz
-   bunzip2 patch-x.y.z.bz2
+   xz -d patch-x.y.z.xz
 
 Which will leave you with a plain text patch-x.y.z file that you can feed to
 patch via stdin or the ``-i`` argument, as you prefer.
@@ -226,16 +226,16 @@ You can use the ``interdiff`` program 
(http://cyberelk.net/tim/patchutils/) to
 generate a patch representing the differences between two patches and then
 apply the result.
 
-This will let you move from something like 2.6.12.2 to 2.6.12.3 in a single
+This will let you move from something like 4.7.2 to 4.7.3 in a single
 step. The -z flag to interdiff will even let you feed it patches in gzip or
 bzip2 compressed form directly without the use of zcat or bzcat or manual
 decompression.
 
-Here's how you'd go from 2.6.12.2 to 2.6.12.3 in a single step:
+Here's how you'd go from 4.7.2 to 4.7.3 in a single step:
 
 ::
 
-   interdiff -z ../patch-2.6.12.2.bz2 ../patch-2.6.12.3.gz | patch -p1
+   interdiff -z ../patch-4.7.2.gz ../patch-4.7.3.gz | patch -p1
 
 Although interdiff may save you a step or two you are generally advised to
 do the additional steps since interdiff can get things wrong in some cases.
@@ -257,21 +257,13 @@ The patches are available at http://kernel.org/
 Most recent patches are linked from the front page, but they also have
 specific homes.
 
-The 2.6.x.y (-stable) and 2.6.x patches live at
+The 4.x.y (-stable) and 4.x patches live at
 
-   ftp://ftp.kernel.org/pub/linux/kernel/v2.6/
+   ftp://ftp.kernel.org/pub/linux/kernel/v4.x/
 
 The -rc patches live at
 
-   ftp://ftp.kernel.org/pub/linux/kernel/v2.6/testing/
-
-The -git patches live at
-
-   ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/
-
-The -mm kernels live at
-
-   ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/
+   ftp://ftp.kernel.org/pub/linux/kernel/v4.x/testing/
 
 In place of ``ftp.kernel.org`` you can use ``ftp.cc.kernel.org``, where cc is a
 country code. This way you'll be downloading from a mirror site that's most
@@ -280,53 +272,55 @@ less bandwidth used globally and less load on the main 
kernel.org servers --
 these are good things, so do use mirrors when possible.
 
 
-The 2.6.x kernels
-=
+The 4.x kernels
+===
 
 These are the base stable releases released by Linus. The highest numbered
 release is the most recent.
 
 If regressions or other serious flaws are found, then a -stable fix patch
-will be released (see below) on top of this base. Once a new 2.6.x base
+will be released (see below) on top of this base. Once a new 4.x base
 kernel is released, a patch is made available that is a delta between the
-previous 2.6.x kernel and the new one.
+previous 4.x kernel and the new one.
 
-To apply a patch moving from 2.6.11 to 2.6.12, you'd do the following (note
-that such patches do **NOT** apply on top of 2.6.x.y kernels but on top of the
-base 2.6.x kernel -- if you need to move from 2.6.x.y to 2.6.x+1 you need to
-first revert the 2.6.x.y patch).
+To apply a patch moving from 4.6 to 4.7, you'd do the following (note
+that such patches do **NOT** apply on top of 4.x.y kernels but on top of the
+base 4.x kernel -- if you need to move from 4.x.y to 4.x+1 you need to
+first revert the 4.x.y patch).
 
 Here are some examples:
 
 ::
 
-   # moving from 2.6.11 to 2.6.12
-   $ cd ~/linux-2.6.11 # change to kernel source dir
-   $ patch -p1 < ../patch-2.6.12   # apply the 2.6.12 patch
+   

[PATCH v4 02/29] doc: development-process: convert it to ReST markup

[Mauro Carvalho Chehab]

This document is on good shape for ReST: all it was needed was
to fix the section markups, add a toctree, convert the tables
and add a few code/quote blocks.

While not strictly required, I opted to use lowercase for
the titles, just like the other books that were converted
to Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/development-process/1.Intro  | 68 ++
 Documentation/development-process/2.Process| 41 +
 Documentation/development-process/3.Early-stage| 22 +--
 Documentation/development-process/4.Coding | 46 ++-
 Documentation/development-process/5.Posting| 26 +++--
 Documentation/development-process/6.Followthrough  | 14 +++--
 Documentation/development-process/7.AdvancedTopics | 13 -
 Documentation/development-process/8.Conclusion |  8 ++-
 .../development-process/development-process.rst| 27 +
 9 files changed, 179 insertions(+), 86 deletions(-)
 create mode 100644 Documentation/development-process/development-process.rst

diff --git a/Documentation/development-process/1.Intro 
b/Documentation/development-process/1.Intro
index 9b614480aa84..22642b3fe903 100644
--- a/Documentation/development-process/1.Intro
+++ b/Documentation/development-process/1.Intro
@@ -1,16 +1,8 @@
-1: A GUIDE TO THE KERNEL DEVELOPMENT PROCESS
+Introdution
+===
 
-The purpose of this document is to help developers (and their managers)
-work with the development community with a minimum of frustration.  It is
-an attempt to document how this community works in a way which is
-accessible to those who are not intimately familiar with Linux kernel
-development (or, indeed, free software development in general).  While
-there is some technical material here, this is very much a process-oriented
-discussion which does not require a deep knowledge of kernel programming to
-understand.
-
-
-1.1: EXECUTIVE SUMMARY
+Executive summary
+-
 
 The rest of this section covers the scope of the kernel development process
 and the kinds of frustrations that developers and their employers can
@@ -20,41 +12,41 @@ availability to users, community support in many forms, and 
the ability to
 influence the direction of kernel development.  Code contributed to the
 Linux kernel must be made available under a GPL-compatible license.
 
-Section 2 introduces the development process, the kernel release cycle, and
-the mechanics of the merge window.  The various phases in the patch
-development, review, and merging cycle are covered.  There is some
+:ref:`development_process` introduces the development process, the kernel
+release cycle, and the mechanics of the merge window.  The various phases in
+the patch development, review, and merging cycle are covered.  There is some
 discussion of tools and mailing lists.  Developers wanting to get started
 with kernel development are encouraged to track down and fix bugs as an
 initial exercise.
 
-Section 3 covers early-stage project planning, with an emphasis on
-involving the development community as soon as possible.
+:ref:`development_early_stage` covers early-stage project planning, with an
+emphasis on involving the development community as soon as possible.
 
-Section 4 is about the coding process; several pitfalls which have been
-encountered by other developers are discussed.  Some requirements for
+:ref:`development_coding` is about the coding process; several pitfalls which
+have been encountered by other developers are discussed.  Some requirements for
 patches are covered, and there is an introduction to some of the tools
 which can help to ensure that kernel patches are correct.
 
-Section 5 talks about the process of posting patches for review.  To be
-taken seriously by the development community, patches must be properly
-formatted and described, and they must be sent to the right place.
+:ref:`development_posting` talks about the process of posting patches for
+review. To be taken seriously by the development community, patches must be
+properly formatted and described, and they must be sent to the right place.
 Following the advice in this section should help to ensure the best
 possible reception for your work.
 
-Section 6 covers what happens after posting patches; the job is far from
-done at that point.  Working with reviewers is a crucial part of the
-development process; this section offers a number of tips on how to avoid
-problems at this important stage.  Developers are cautioned against
+:ref:`development_followthrough` covers what happens after posting patches; the
+job is far from done at that point.  Working with reviewers is a crucial part
+of the development process; this section offers a number of tips on how to
+avoid problems at this important stage.  Developers are cautioned against
 assuming that the job is done when a patch is merged into the mainline.
 
-Section 7 introduces a couple of "advanced" 

[PATCH v4 25/29] Documentation/HOWTO: adjust external link references

[Mauro Carvalho Chehab]

- A few link references were missing http://
- Several sites are now redirecting to https protocol. On such
  cases, just use the https URL.

NOTE: all URLs were checked and they're pointing to the right places.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/HOWTO | 37 +
 1 file changed, 17 insertions(+), 20 deletions(-)

diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 784724aa4f34..adde88a6d9c4 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -66,7 +66,7 @@ their statements on legal matters.
 
 For common questions and answers about the GPL, please see:
 
-   http://www.gnu.org/licenses/gpl-faq.html
+   https://www.gnu.org/licenses/gpl-faq.html
 
 
 Documentation
@@ -117,11 +117,9 @@ required reading:
 Other excellent descriptions of how to create patches properly are:
 
"The Perfect Patch"
-
-   http://www.ozlabs.org/~akpm/stuff/tpp.txt
+   https://www.ozlabs.org/~akpm/stuff/tpp.txt
 
"Linux kernel patch submission format"
-
http://linux.yyz.us/patch-format.html
 
   :ref:`Documentation/stable_api_nonsense.txt `
@@ -202,7 +200,7 @@ Becoming A Kernel Developer
 If you do not know anything about Linux kernel development, you should
 look at the Linux KernelNewbies project:
 
-   http://kernelnewbies.org
+   https://kernelnewbies.org
 
 It consists of a helpful mailing list where you can ask almost any type
 of basic kernel development question (make sure to search the archives
@@ -220,7 +218,7 @@ If you do not know where you want to start, but you want to 
look for
 some task to start doing to join into the kernel development community,
 go to the Linux Kernel Janitor's project:
 
-   http://kernelnewbies.org/KernelJanitors
+   https://kernelnewbies.org/KernelJanitors
 
 It is a great place to start.  It describes a list of relatively simple
 problems that need to be cleaned up and fixed within the Linux kernel
@@ -234,7 +232,7 @@ tree, but need some help getting it in the proper form, the
 kernel-mentors project was created to help you out with this.  It is a
 mailing list, and can be found at:
 
-   http://selenic.com/mailman/listinfo/kernel-mentors
+   https://selenic.com/mailman/listinfo/kernel-mentors
 
 Before making any actual modifications to the Linux kernel code, it is
 imperative to understand how the code in question works.  For this
@@ -264,7 +262,7 @@ branches.  These different branches are:
 4.x kernel tree
 -
 4.x kernels are maintained by Linus Torvalds, and can be found on
-kernel.org in the pub/linux/kernel/v4.x/ directory.  Its development
+https://kernel.org in the pub/linux/kernel/v4.x/ directory.  Its development
 process is as follows:
 
   - As soon as a new kernel is released a two weeks window is open,
@@ -272,7 +270,7 @@ process is as follows:
 Linus, usually the patches that have already been included in the
 -next kernel for a few weeks.  The preferred way to submit big changes
 is using git (the kernel's source management tool, more information
-can be found at http://git-scm.com/) but plain patches are also just
+can be found at https://git-scm.com/) but plain patches are also just
 fine.
   - After two weeks a -rc1 kernel is released it is now possible to push
 only patches that do not include new features that could affect the
@@ -340,7 +338,7 @@ submission and other already ongoing work are avoided.
 Most of these repositories are git trees, but there are also other SCMs
 in use, or patch queues being published as quilt series.  Addresses of
 these subsystem repositories are listed in the MAINTAINERS file.  Many
-of them can be browsed at http://git.kernel.org/.
+of them can be browsed at https://git.kernel.org/.
 
 Before a proposed patch is committed to such a subsystem tree, it is
 subject to review which primarily happens on mailing lists (see the
@@ -349,7 +347,7 @@ process is tracked with the tool patchwork.  Patchwork 
offers a web
 interface which shows patch postings, any comments on a patch or
 revisions to it, and maintainers can mark patches as under review,
 accepted, or rejected.  Most of these patchwork sites are listed at
-http://patchwork.kernel.org/.
+https://patchwork.kernel.org/.
 
 4.x -next kernel tree for integration tests
 ---
@@ -358,7 +356,7 @@ tree, they need to be integration-tested.  For this 
purpose, a special
 testing repository exists into which virtually all subsystem trees are
 pulled on an almost daily basis:
 
-   http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
+   https://git.kernel.org/?p=linux/kernel/git/next/linux-next.git
 
 This way, the -next kernel gives a summary outlook onto what will be
 expected to go into the mainline kernel at the next merge period.
@@ -368,11 +366,11 @@ Adventurous testers are very welcome to runtime-test the 

[PATCH v4 27/29] Documentation/SubmitChecklist: convert it to ReST markup

[Mauro Carvalho Chehab]

- use ``foo`` to markup inline literal stuff, effectively making it
  to be presented as a monospaced font when parsed by Sphinx;

- the markup below the title should have the same length as the
  title;

- Fix the list markups, from "1:" to "1)";

- Split item 2 into a separate list for the build options, in order
  to be presented as a list on Sphinx;

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/SubmitChecklist | 116 ++
 1 file changed, 62 insertions(+), 54 deletions(-)

diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist
index bb114c8a781c..22a370ff34e5 100644
--- a/Documentation/SubmitChecklist
+++ b/Documentation/SubmitChecklist
@@ -1,110 +1,118 @@
 Linux Kernel patch submission checklist
-~~
+~~~
 
 Here are some basic things that developers should do if they want to see their
 kernel patch submissions accepted more quickly.
 
 These are all above and beyond the documentation that is provided in
-Documentation/SubmittingPatches and elsewhere regarding submitting Linux
-kernel patches.
+Documentation/SubmittingPatches
+and elsewhere regarding submitting Linux kernel patches.
 
 
-1: If you use a facility then #include the file that defines/declares
+1) If you use a facility then #include the file that defines/declares
that facility.  Don't depend on other header files pulling in ones
that you use.
 
-2: Builds cleanly with applicable or modified CONFIG options =y, =m, and
-   =n.  No gcc warnings/errors, no linker warnings/errors.
+2) Builds cleanly:
 
-2b: Passes allnoconfig, allmodconfig
+  a) with applicable or modified ``CONFIG`` options ``=y``, ``=m``, and
+ ``=n``.  No ``gcc`` warnings/errors, no linker warnings/errors.
 
-2c: Builds successfully when using O=builddir
+  b) Passes ``allnoconfig``, ``allmodconfig``
 
-3: Builds on multiple CPU architectures by using local cross-compile tools
+  c) Builds successfully when using ``O=builddir``
+
+3) Builds on multiple CPU architectures by using local cross-compile tools
or some other build farm.
 
-4: ppc64 is a good architecture for cross-compilation checking because it
-   tends to use `unsigned long' for 64-bit quantities.
+4) ppc64 is a good architecture for cross-compilation checking because it
+   tends to use ``unsigned long`` for 64-bit quantities.
 
 5: Check your patch for general style as detailed in
-   Documentation/CodingStyle.  Check for trivial violations with the
-   patch style checker prior to submission (scripts/checkpatch.pl).
+   Documentation/CodingStyle.
+   Check for trivial violations with the patch style checker prior to
+   submission (``scripts/checkpatch.pl``).
You should be able to justify all violations that remain in
your patch.
 
-6: Any new or modified CONFIG options don't muck up the config menu.
+6) Any new or modified ``CONFIG`` options don't muck up the config menu.
 
-7: All new Kconfig options have help text.
+7) All new ``Kconfig`` options have help text.
 
-8: Has been carefully reviewed with respect to relevant Kconfig
+8) Has been carefully reviewed with respect to relevant ``Kconfig``
combinations.  This is very hard to get right with testing -- brainpower
pays off here.
 
-9: Check cleanly with sparse.
+9) Check cleanly with sparse.
 
-10: Use 'make checkstack' and 'make namespacecheck' and fix any problems
-that they find.  Note: checkstack does not point out problems explicitly,
-but any one function that uses more than 512 bytes on the stack is a
-candidate for change.
+10) Use ``make checkstack`` and ``make namespacecheck`` and fix any problems
+that they find.
+
+.. note::
+
+   ``checkstack`` does not point out problems explicitly,
+   but any one function that uses more than 512 bytes on the stack is a
+   candidate for change.
 
 11: Include :ref:`kernel-doc ` to document global  kernel APIs.
 (Not required for static functions, but OK there also.) Use
 ``make htmldocs`` or ``make pdfdocs`` to check the
 :ref:`kernel-doc ` and fix any issues.
 
-12: Has been tested with CONFIG_PREEMPT, CONFIG_DEBUG_PREEMPT,
-CONFIG_DEBUG_SLAB, CONFIG_DEBUG_PAGEALLOC, CONFIG_DEBUG_MUTEXES,
-CONFIG_DEBUG_SPINLOCK, CONFIG_DEBUG_ATOMIC_SLEEP, CONFIG_PROVE_RCU
-and CONFIG_DEBUG_OBJECTS_RCU_HEAD all simultaneously enabled.
+12) Has been tested with ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
+``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, 
``CONFIG_DEBUG_MUTEXES``,
+``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
+``CONFIG_PROVE_RCU`` and ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` all
+simultaneously enabled.
 
-13: Has been build- and runtime tested with and without CONFIG_SMP and
-CONFIG_PREEMPT.
+13) Has been build- and runtime tested with and without ``CONFIG_SMP`` and
+``CONFIG_PREEMPT.``
 
-14: If the patch 

[PATCH v4 10/29] Documentation/CodingStyle: Convert to ReST markup

[Mauro Carvalho Chehab]

- Fix all chapter identation;
- add c blocks where needed;

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/CodingStyle | 257 --
 1 file changed, 180 insertions(+), 77 deletions(-)

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index 0f1dbd87eb48..f103de7e2028 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -1,5 +1,5 @@
-
-   Linux kernel coding style
+Linux kernel coding style
+=
 
 This is a short document describing the preferred coding style for the
 linux kernel.  Coding style is very personal, and I won't _force_ my
@@ -13,7 +13,8 @@ and NOT read it.  Burn them, it's a great symbolic gesture.
 Anyway, here goes:
 
 
-   Chapter 1: Indentation
+1) Indentation
+--
 
 Tabs are 8 characters, and thus indentations are also 8 characters.
 There are heretic movements that try to make indentations 4 (or even 2!)
@@ -39,6 +40,8 @@ The preferred way to ease multiple indentation levels in a 
switch statement is
 to align the "switch" and its subordinate "case" labels in the same column
 instead of "double-indenting" the "case" labels.  E.g.:
 
+.. code-block:: c
+
switch (suffix) {
case 'G':
case 'g':
@@ -59,6 +62,8 @@ instead of "double-indenting" the "case" labels.  E.g.:
 Don't put multiple statements on a single line unless you have
 something to hide:
 
+.. code-block:: c
+
if (condition) do_this;
  do_something_everytime;
 
@@ -71,7 +76,8 @@ used for indentation, and the above example is deliberately 
broken.
 Get a decent editor and don't leave whitespace at the end of lines.
 
 
-   Chapter 2: Breaking long lines and strings
+2) Breaking long lines and strings
+--
 
 Coding style is all about readability and maintainability using commonly
 available tools.
@@ -87,7 +93,8 @@ with a long argument list. However, never break user-visible 
strings such as
 printk messages, because that breaks the ability to grep for them.
 
 
-   Chapter 3: Placing Braces and Spaces
+3) Placing Braces and Spaces
+
 
 The other issue that always comes up in C styling is the placement of
 braces.  Unlike the indent size, there are few technical reasons to
@@ -95,6 +102,8 @@ choose one placement strategy over the other, but the 
preferred way, as
 shown to us by the prophets Kernighan and Ritchie, is to put the opening
 brace last on the line, and put the closing brace first, thusly:
 
+.. code-block:: c
+
if (x is true) {
we do y
}
@@ -102,6 +111,8 @@ brace last on the line, and put the closing brace first, 
thusly:
 This applies to all non-function statement blocks (if, switch, for,
 while, do).  E.g.:
 
+.. code-block:: c
+
switch (action) {
case KOBJ_ADD:
return "add";
@@ -116,6 +127,8 @@ while, do).  E.g.:
 However, there is one special case, namely functions: they have the
 opening brace at the beginning of the next line, thus:
 
+.. code-block:: c
+
int function(int x)
{
body of function
@@ -131,12 +144,16 @@ the cases where it is followed by a continuation of the 
same statement,
 ie a "while" in a do-statement or an "else" in an if-statement, like
 this:
 
+.. code-block:: c
+
do {
body of do-loop
} while (condition);
 
 and
 
+.. code-block:: c
+
if (x == y) {
..
} else if (x > y) {
@@ -155,11 +172,15 @@ comments on.
 
 Do not unnecessarily use braces where a single statement will do.
 
+.. code-block:: c
+
if (condition)
action();
 
 and
 
+.. code-block:: none
+
if (condition)
do_this();
else
@@ -168,6 +189,8 @@ and
 This does not apply if only one branch of a conditional statement is a single
 statement; in the latter case use braces in both branches:
 
+.. code-block:: c
+
if (condition) {
do_this();
do_that();
@@ -175,50 +198,60 @@ statement; in the latter case use braces in both branches:
otherwise();
}
 
-   3.1:  Spaces
+3.1) Spaces
+***
 
 Linux kernel style for use of spaces depends (mostly) on
 function-versus-keyword usage.  Use a space after (most) keywords.  The
 notable exceptions are sizeof, typeof, alignof, and __attribute__, which look
 somewhat like functions (and are usually used with parentheses in Linux,
-although they are not required in the language, as in: "sizeof info" after
-"struct fileinfo info;" is declared).
+although they are not required in the language, as in: ``sizeof info`` after
+``struct fileinfo info;`` is declared).
 
-So use a space after these keywords:
+So use a space after these keywords::
 
if, switch, case, for, do, while
 
 but not with sizeof, typeof, alignof, or 

[PATCH v4 14/29] Documentation/ManagementStyle: convert it to ReST markup

[Mauro Carvalho Chehab]

- Convert document name to ReST;
- Convert footnotes;
- Convert sections to ReST format;
- Don't use _foo_, as Sphinx doesn't support underline. Instead,
  use bold;
- While here, remove whitespaces at the end of lines.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/ManagementStyle | 154 ++
 1 file changed, 82 insertions(+), 72 deletions(-)

diff --git a/Documentation/ManagementStyle b/Documentation/ManagementStyle
index a211ee8d8b44..1471df6015a2 100644
--- a/Documentation/ManagementStyle
+++ b/Documentation/ManagementStyle
@@ -1,10 +1,10 @@
-
-Linux kernel management style
+Linux kernel management style
+=
 
 This is a short document describing the preferred (or made up, depending
 on who you ask) management style for the linux kernel.  It's meant to
 mirror the CodingStyle document to some degree, and mainly written to
-avoid answering (*) the same (or similar) questions over and over again. 
+avoid answering [#f1]_  the same (or similar) questions over and over again.
 
 Management style is very personal and much harder to quantify than
 simple coding style rules, so this document may or may not have anything
@@ -14,50 +14,52 @@ might not actually be true. You'll have to decide for 
yourself.
 Btw, when talking about "kernel manager", it's all about the technical
 lead persons, not the people who do traditional management inside
 companies.  If you sign purchase orders or you have any clue about the
-budget of your group, you're almost certainly not a kernel manager. 
-These suggestions may or may not apply to you. 
+budget of your group, you're almost certainly not a kernel manager.
+These suggestions may or may not apply to you.
 
 First off, I'd suggest buying "Seven Habits of Highly Effective
-People", and NOT read it.  Burn it, it's a great symbolic gesture. 
+People", and NOT read it.  Burn it, it's a great symbolic gesture.
 
-(*) This document does so not so much by answering the question, but by
-making it painfully obvious to the questioner that we don't have a clue
-to what the answer is. 
+.. [#f1] This document does so not so much by answering the question, but by
+  making it painfully obvious to the questioner that we don't have a clue
+  to what the answer is.
 
 Anyway, here goes:
 
+.. _decisions:
 
-   Chapter 1: Decisions
+1) Decisions
+
 
 Everybody thinks managers make decisions, and that decision-making is
 important.  The bigger and more painful the decision, the bigger the
 manager must be to make it.  That's very deep and obvious, but it's not
-actually true. 
+actually true.
 
-The name of the game is to _avoid_ having to make a decision.  In
+The name of the game is to **avoid** having to make a decision.  In
 particular, if somebody tells you "choose (a) or (b), we really need you
 to decide on this", you're in trouble as a manager.  The people you
 manage had better know the details better than you, so if they come to
 you for a technical decision, you're screwed.  You're clearly not
-competent to make that decision for them. 
+competent to make that decision for them.
 
 (Corollary:if the people you manage don't know the details better than
-you, you're also screwed, although for a totally different reason. 
-Namely that you are in the wrong job, and that _they_ should be managing
-your brilliance instead). 
+you, you're also screwed, although for a totally different reason.
+Namely that you are in the wrong job, and that **they** should be managing
+your brilliance instead).
 
-So the name of the game is to _avoid_ decisions, at least the big and
+So the name of the game is to **avoid** decisions, at least the big and
 painful ones.  Making small and non-consequential decisions is fine, and
 makes you look like you know what you're doing, so what a kernel manager
 needs to do is to turn the big and painful ones into small things where
-nobody really cares. 
+nobody really cares.
 
 It helps to realize that the key difference between a big decision and a
 small one is whether you can fix your decision afterwards.  Any decision
 can be made small by just always making sure that if you were wrong (and
-you _will_ be wrong), you can always undo the damage later by
+you **will** be wrong), you can always undo the damage later by
 backtracking.  Suddenly, you get to be doubly managerial for making
-_two_ inconsequential decisions - the wrong one _and_ the right one. 
+**two** inconsequential decisions - the wrong one **and** the right one.
 
 And people will even see that as true leadership (*cough* bullshit
 *cough*).
@@ -65,10 +67,10 @@ And people will even see that as true leadership (*cough* 
bullshit
 Thus the key to avoiding big decisions becomes to just avoiding to do
 things that can't be undone.  Don't get ushered into a corner from which
 you cannot escape.  A cornered rat may be dangerous - a cornered manager
-is just 

[PATCH v4 15/29] Documentation/SecurityBugs: convert it to ReST markup

[Mauro Carvalho Chehab]

Add a name for the document and convert the sections to
ReST markups.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/SecurityBugs | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/SecurityBugs b/Documentation/SecurityBugs
index a660d494c8ed..10a1f79376a2 100644
--- a/Documentation/SecurityBugs
+++ b/Documentation/SecurityBugs
@@ -1,9 +1,13 @@
+Security bugs
+=
+
 Linux kernel developers take security very seriously.  As such, we'd
 like to know when a security bug is found so that it can be fixed and
 disclosed as quickly as possible.  Please report security bugs to the
 Linux kernel security team.
 
 1) Contact
+--
 
 The Linux kernel security team can be contacted by email at
 .  This is a private list of security officers
@@ -18,6 +22,7 @@ Any exploit code is very helpful and will not be released 
without
 consent from the reporter unless it has already been made public.
 
 2) Disclosure
+-
 
 The goal of the Linux kernel security team is to work with the
 bug submitter to bug resolution as well as disclosure.  We prefer
@@ -33,6 +38,7 @@ to a few weeks.  As a basic default policy, we expect report 
date to
 disclosure date to be on the order of 7 days.
 
 3) Non-disclosure agreements
+
 
 The Linux kernel security team is not a formal body and therefore unable
 to enter any non-disclosure agreements.
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 11/29] Documentation/CodingStyle: use the proper tag for verbatim font

[Mauro Carvalho Chehab]

On Sphinx/ReST notation, ``foo`` means that foo will be will be
marked as inline literal, effectively making it to be presented
as a monospaced font.

As we want this document to be parsed by Sphinx, instead of using
"foo", use ``foo`` for the names that are literal, because it is an
usual typographic convention to use monospaced fonts for functions
and language commands on documents, and we're following such
convention on the other ReST books.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/CodingStyle | 98 +++
 1 file changed, 49 insertions(+), 49 deletions(-)

diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index f103de7e2028..c25528d76af1 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -37,8 +37,8 @@ benefit of warning you when you're nesting your functions too 
deep.
 Heed that warning.
 
 The preferred way to ease multiple indentation levels in a switch statement is
-to align the "switch" and its subordinate "case" labels in the same column
-instead of "double-indenting" the "case" labels.  E.g.:
+to align the ``switch`` and its subordinate ``case`` labels in the same column
+instead of ``double-indenting`` the ``case`` labels.  E.g.:
 
 .. code-block:: c
 
@@ -141,7 +141,7 @@ special anyway (you can't nest them in C).
 
 Note that the closing brace is empty on a line of its own, _except_ in
 the cases where it is followed by a continuation of the same statement,
-ie a "while" in a do-statement or an "else" in an if-statement, like
+ie a ``while`` in a do-statement or an ``else`` in an if-statement, like
 this:
 
 .. code-block:: c
@@ -228,7 +228,7 @@ Do not add spaces around (inside) parenthesized 
expressions.  This example is
s = sizeof( struct file );
 
 When declaring pointer data or a function that returns a pointer type, the
-preferred use of '\*' is adjacent to the data name or function name and not
+preferred use of ``*`` is adjacent to the data name or function name and not
 adjacent to the type name.  Examples:
 
 .. code-block:: c
@@ -255,10 +255,10 @@ no space after the prefix increment & decrement unary 
operators::
 
++  --
 
-and no space around the '.' and "->" structure member operators.
+and no space around the ``.`` and ``->`` structure member operators.
 
 Do not leave trailing whitespace at the ends of lines.  Some editors with
-"smart" indentation will insert whitespace at the beginning of new lines as
+``smart`` indentation will insert whitespace at the beginning of new lines as
 appropriate, so you can start typing the next line of code right away.
 However, some such editors do not remove the whitespace if you end up not
 putting a line of code there, such as if you leave a blank line.  As a result,
@@ -276,17 +276,17 @@ context lines.
 C is a Spartan language, and so should your naming be.  Unlike Modula-2
 and Pascal programmers, C programmers do not use cute names like
 ThisVariableIsATemporaryCounter.  A C programmer would call that
-variable "tmp", which is much easier to write, and not the least more
+variable ``tmp``, which is much easier to write, and not the least more
 difficult to understand.
 
 HOWEVER, while mixed-case names are frowned upon, descriptive names for
-global variables are a must.  To call a global function "foo" is a
+global variables are a must.  To call a global function ``foo`` is a
 shooting offense.
 
 GLOBAL variables (to be used only if you _really_ need them) need to
 have descriptive names, as do global functions.  If you have a function
 that counts the number of active users, you should call that
-"count_active_users()" or similar, you should _not_ call it "cntusr()".
+``count_active_users()`` or similar, you should _not_ call it ``cntusr()``.
 
 Encoding the type of a function into the name (so-called Hungarian
 notation) is brain damaged - the compiler knows the types anyway and can
@@ -294,9 +294,9 @@ check those, and it only confuses the programmer.  No 
wonder MicroSoft
 makes buggy programs.
 
 LOCAL variable names should be short, and to the point.  If you have
-some random integer loop counter, it should probably be called "i".
-Calling it "loop_counter" is non-productive, if there is no chance of it
-being mis-understood.  Similarly, "tmp" can be just about any type of
+some random integer loop counter, it should probably be called ``i``.
+Calling it ``loop_counter`` is non-productive, if there is no chance of it
+being mis-understood.  Similarly, ``tmp`` can be just about any type of
 variable that is used to hold a temporary value.
 
 If you are afraid to mix up your local variable names, you have another
@@ -307,7 +307,7 @@ See chapter 6 (Functions).
 5) Typedefs
 ---
 
-Please don't use things like "vps_t".
+Please don't use things like ``vps_t``.
 It's a _mistake_ to use typedef for structures and pointers. When you see a
 
 .. code-block:: c
@@ -322,35 +322,35 @@ In contrast, 

[PATCH v4 17/29] Documentation/stable_kernel_rules.txt: convert it to ReST markup

[Mauro Carvalho Chehab]

- use ReST markups for section headers;
- add cross-references to the options;
- mark code blocks;
- a few minor changes to make Sphinx happy.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/stable_kernel_rules.txt | 101 +++---
 1 file changed, 68 insertions(+), 33 deletions(-)

diff --git a/Documentation/stable_kernel_rules.txt 
b/Documentation/stable_kernel_rules.txt
index ffd4575ec9f2..387d8a44eda2 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -1,4 +1,5 @@
-Everything you ever wanted to know about Linux -stable releases.
+Everything you ever wanted to know about Linux -stable releases
+===
 
 Rules on what kind of patches are accepted, and which ones are not, into the
 "-stable" tree:
@@ -27,7 +28,8 @@ Rules on what kind of patches are accepted, and which ones 
are not, into the
  - It or an equivalent fix must already exist in Linus' tree (upstream).
 
 
-Procedure for submitting patches to the -stable tree:
+Procedure for submitting patches to the -stable tree
+
 
  - If the patch covers files in net/ or drivers/net please follow netdev stable
submission guidelines as described in
@@ -35,56 +37,78 @@ Procedure for submitting patches to the -stable tree:
  - Security patches should not be handled (solely) by the -stable review
process but should follow the procedures in Documentation/SecurityBugs.
 
-For all other submissions, choose one of the following procedures:
+For all other submissions, choose one of the following procedures
+-
 
-   --- Option 1 ---
+.. _option_1:
+
+Option 1
+
+
+To have the patch automatically included in the stable tree, add the tag
+
+.. code-block:: none
 
-   To have the patch automatically included in the stable tree, add the tag
  Cc: sta...@vger.kernel.org
-   in the sign-off area. Once the patch is merged it will be applied to
-   the stable tree without anything else needing to be done by the author
-   or subsystem maintainer.
 
-   --- Option 2 ---
+in the sign-off area. Once the patch is merged it will be applied to
+the stable tree without anything else needing to be done by the author
+or subsystem maintainer.
 
-   After the patch has been merged to Linus' tree, send an email to
-   sta...@vger.kernel.org containing the subject of the patch, the commit ID,
-   why you think it should be applied, and what kernel version you wish it to
-   be applied to.
+.. _option_2:
 
-   --- Option 3 ---
+Option 2
+
 
-   Send the patch, after verifying that it follows the above rules, to
-   sta...@vger.kernel.org.  You must note the upstream commit ID in the
-   changelog of your submission, as well as the kernel version you wish
-   it to be applied to.
+After the patch has been merged to Linus' tree, send an email to
+sta...@vger.kernel.org containing the subject of the patch, the commit ID,
+why you think it should be applied, and what kernel version you wish it to
+be applied to.
 
-Option 1 is *strongly* preferred, is the easiest and most common.  Options 2 
and
-3 are more useful if the patch isn't deemed worthy at the time it is applied to
-a public git tree (for instance, because it deserves more regression testing
-first).  Option 3 is especially useful if the patch needs some special handling
-to apply to an older kernel (e.g., if API's have changed in the meantime).
+.. _option_3:
 
-Note that for Option 3, if the patch deviates from the original upstream patch
-(for example because it had to be backported) this must be very clearly
-documented and justified in the patch description.
+Option 3
+
+
+Send the patch, after verifying that it follows the above rules, to
+sta...@vger.kernel.org.  You must note the upstream commit ID in the
+changelog of your submission, as well as the kernel version you wish
+it to be applied to.
+
+:ref:`option_1` is **strongly** preferred, is the easiest and most common.
+:ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed
+worthy at the time it is applied to a public git tree (for instance, because
+it deserves more regression testing first).  :ref:`option_3` is especially
+useful if the patch needs some special handling to apply to an older kernel
+(e.g., if API's have changed in the meantime).
+
+Note that for :ref:`option_3`, if the patch deviates from the original
+upstream patch (for example because it had to be backported) this must be very
+clearly documented and justified in the patch description.
 
 The upstream commit ID must be specified with a separate line above the commit
 text, like this:
 
+.. code-block:: none
+
 commit  upstream.
 
 Additionally, some patches submitted via Option 1 may have additional patch
 prerequisites which can be cherry-picked. This can be 

[PATCH v4 16/29] Documentation/stable_api_nonsense.txt: convert it to ReST markup

[Mauro Carvalho Chehab]

Add markups for it to be properly parsed by Sphinx.

As people browsing this document may not notice that the source
file title is "stable_api_nonsense", I opted to use bold to
the rationale for this document. I also found it better to
add a note when it says that the nonsense applies only to the
kABI/kAPI, and not to uAPI.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/stable_api_nonsense.txt | 35 ---
 1 file changed, 24 insertions(+), 11 deletions(-)

diff --git a/Documentation/stable_api_nonsense.txt 
b/Documentation/stable_api_nonsense.txt
index db3be892afb2..9187b4ef4bac 100644
--- a/Documentation/stable_api_nonsense.txt
+++ b/Documentation/stable_api_nonsense.txt
@@ -1,17 +1,24 @@
 The Linux Kernel Driver Interface
+==
+
 (all of your questions answered and then some)
 
 Greg Kroah-Hartman 
 
-This is being written to try to explain why Linux does not have a binary
-kernel interface, nor does it have a stable kernel interface.  Please
-realize that this article describes the _in kernel_ interfaces, not the
-kernel to userspace interfaces.  The kernel to userspace interface is
-the one that application programs use, the syscall interface.  That
-interface is _very_ stable over time, and will not break.  I have old
-programs that were built on a pre 0.9something kernel that still work
-just fine on the latest 2.6 kernel release.  That interface is the one
-that users and application programmers can count on being stable.
+This is being written to try to explain why Linux **does not have a binary
+kernel interface, nor does it have a stable kernel interface**.
+
+.. note::
+
+  Please realize that this article describes the **in kernel** interfaces, not
+  the kernel to userspace interfaces.
+
+  The kernel to userspace interface is the one that application programs use,
+  the syscall interface.  That interface is **very** stable over time, and
+  will not break.  I have old programs that were built on a pre 0.9something
+  kernel that still work just fine on the latest 2.6 kernel release.
+  That interface is the one that users and application programmers can count
+  on being stable.
 
 
 Executive Summary
@@ -33,7 +40,7 @@ to worry about the in-kernel interfaces changing.  For the 
majority of
 the world, they neither see this interface, nor do they care about it at
 all.
 
-First off, I'm not going to address _any_ legal issues about closed
+First off, I'm not going to address **any** legal issues about closed
 source, hidden source, binary blobs, source wrappers, or any other term
 that describes kernel drivers that do not have their source code
 released under the GPL.  Please consult a lawyer if you have any legal
@@ -51,19 +58,23 @@ Binary Kernel Interface
 Assuming that we had a stable kernel source interface for the kernel, a
 binary interface would naturally happen too, right?  Wrong.  Please
 consider the following facts about the Linux kernel:
+
   - Depending on the version of the C compiler you use, different kernel
 data structures will contain different alignment of structures, and
 possibly include different functions in different ways (putting
 functions inline or not.)  The individual function organization
 isn't that important, but the different data structure padding is
 very important.
+
   - Depending on what kernel build options you select, a wide range of
 different things can be assumed by the kernel:
+
   - different structures can contain different fields
   - Some functions may not be implemented at all, (i.e. some locks
compile away to nothing for non-SMP builds.)
   - Memory within the kernel can be aligned in different ways,
depending on the build options.
+
   - Linux runs on a wide range of different processor architectures.
 There is no way that binary drivers from one architecture will run
 on another architecture properly.
@@ -105,6 +116,7 @@ As a specific examples of this, the in-kernel USB 
interfaces have
 undergone at least three different reworks over the lifetime of this
 subsystem.  These reworks were done to address a number of different
 issues:
+
   - A change from a synchronous model of data streams to an asynchronous
 one.  This reduced the complexity of a number of drivers and
 increased the throughput of all USB drivers such that we are now
@@ -166,6 +178,7 @@ very little effort on your part.
 
 The very good side effects of having your driver in the main kernel tree
 are:
+
   - The quality of the driver will rise as the maintenance costs (to the
 original developer) will decrease.
   - Other developers will add features to your driver.
@@ -175,7 +188,7 @@ are:
 changes require it.
   - The driver automatically gets shipped in all Linux distributions
 without having to ask the distros to add it.
-
+
 As Linux supports a larger number of different 

[PATCH v4 18/29] Documentation/SubmittingDrivers: convert it to ReST markup

[Mauro Carvalho Chehab]

- Change the document title markup to make it on a higher level;
- Add blank lines as needed, to improve the output;
- use italics for the country-code at kernel.org ftp URL.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/SubmittingDrivers | 45 -
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers
index 31d372609ac0..a2f30a9e28d1 100644
--- a/Documentation/SubmittingDrivers
+++ b/Documentation/SubmittingDrivers
@@ -1,5 +1,5 @@
 Submitting Drivers For The Linux Kernel

+===
 
 This document is intended to explain how to submit device drivers to the
 various kernel trees. Note that if you are interested in video card drivers
@@ -46,34 +46,39 @@ Linux 2.6:
 What Criteria Determine Acceptance
 --
 
-Licensing: The code must be released to us under the
+Licensing:
+   The code must be released to us under the
GNU General Public License. We don't insist on any kind
of exclusive GPL licensing, and if you wish the driver
to be useful to other communities such as BSD you may well
wish to release under multiple licenses.
See accepted licenses at include/linux/module.h
 
-Copyright: The copyright owner must agree to use of GPL.
+Copyright:
+   The copyright owner must agree to use of GPL.
It's best if the submitter and copyright owner
are the same person/entity. If not, the name of
the person/entity authorizing use of GPL should be
listed in case it's necessary to verify the will of
the copyright owner.
 
-Interfaces:If your driver uses existing interfaces and behaves like
+Interfaces:
+   If your driver uses existing interfaces and behaves like
other drivers in the same class it will be much more likely
to be accepted than if it invents gratuitous new ones.
If you need to implement a common API over Linux and NT
drivers do it in userspace.
 
-Code:  Please use the Linux style of code formatting as documented
+Code:
+   Please use the Linux style of code formatting as documented
in Documentation/CodingStyle. If you have sections of code
that need to be in other formats, for example because they
are shared with a windows driver kit and you want to
maintain them just once separate them out nicely and note
this fact.
 
-Portability:   Pointers are not always 32bits, not all computers are little
+Portability:
+   Pointers are not always 32bits, not all computers are little
endian, people do not all have floating point and you
shouldn't use inline x86 assembler in your driver without
careful thought. Pure x86 drivers generally are not popular.
@@ -81,12 +86,14 @@ Portability:Pointers are not always 32bits, not all 
computers are little
but it is easy to make sure the code can easily be made
portable.
 
-Clarity:   It helps if anyone can see how to fix the driver. It helps
+Clarity:
+   It helps if anyone can see how to fix the driver. It helps
you because you get patches not bug reports. If you submit a
driver that intentionally obfuscates how the hardware works
it will go in the bitbucket.
 
-PM support:Since Linux is used on many portable and desktop systems, your
+PM support:
+   Since Linux is used on many portable and desktop systems, your
driver is likely to be used on such a system and therefore it
should support basic power management by implementing, if
necessary, the .suspend and .resume methods used during the
@@ -101,7 +108,8 @@ PM support: Since Linux is used on many portable and 
desktop systems, your
complete overview of the power management issues related to
drivers see Documentation/power/devices.txt .
 
-Control:   In general if there is active maintenance of a driver by
+Control:
+   In general if there is active maintenance of a driver by
the author then patches will be redirected to them unless
they are totally obvious and without need of checking.
If you want to be the contact and update point for the
@@ -111,13 +119,15 @@ Control:  In general if there is active maintenance of a 
driver by
 What Criteria Do Not Determine Acceptance
 -
 
-Vendor:Being the hardware vendor and maintaining the driver is

[PATCH v4 09/29] Documentation/Changes: add minimal requirements for documentation build

[Mauro Carvalho Chehab]

As discussed at linux-doc ML, the best is to keep all documents
backward compatible with Sphinx version 1.2, as it is the latest
version found on some distros like Debian.

All books currently support it.

Please notice that, while it mentions the eventual need of
XeLaTex and texlive to build pdf files, this is not a minimal
requirement, as one could just be interested on building html
documents. Also, identifying the minimal requirements for
texlive packages is not trivial, as each distribution seems to
use different criteria on grouping LaTex functionalities.

While here, update the current kernel version to 4.x.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/Changes | 36 +++-
 1 file changed, 35 insertions(+), 1 deletion(-)

diff --git a/Documentation/Changes b/Documentation/Changes
index a9f365d864c7..93c8e1c15844 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -5,7 +5,7 @@ Intro
 =
 
 This document is designed to provide a list of the minimum levels of
-software necessary to run the 3.0 kernels.
+software necessary to run the 4.x kernels.
 
 This document is originally based on my "Changes" file for 2.0.x kernels
 and therefore owes credit to the same people as that file (Jared Mauch,
@@ -51,8 +51,10 @@ mcelog 0.6  mcelog --version
 iptables   1.4.2iptables -V
 openssl & libcrypto1.0.0openssl version
 bc 1.06.95  bc --version
+Sphinx\ [#f1]_1.2  sphinx-build --version
 == ===  

 
+.. [#f1] Sphinx is needed only to build the Kernel documentation
 
 Kernel compilation
 **
@@ -307,6 +309,30 @@ On x86 kernels the mcelog utility is needed to process and 
log machine check
 events when ``CONFIG_X86_MCE`` is enabled. Machine check events are errors
 reported by the CPU. Processing them is strongly encouraged.
 
+Kernel documentation
+
+
+Sphinx
+--
+
+The ReST markups currently used by the Documentation/ files are meant to be
+built with ``Sphinx`` version 1.2 or upper. If you're desiring to build
+PDF outputs, it is recommended to use version 1.4.6.
+
+.. note::
+
+  Please notice that, for PDF and LaTeX output, you'll also need ``XeLaTeX``
+  version 3.14159265. Depending on the distribution, you may also need
+  to install a series of ``texlive`` packages that provide the minimal
+  set of functionalities required for ``XeLaTex`` to work.
+
+Other tools
+---
+
+In order to produce documentation from DocBook, you'll also need ``xmlto``.
+Please notice, however, that we're currently migrating all documents to use
+``Sphinx``.
+
 Getting updated software
 
 
@@ -453,3 +479,11 @@ NFS-Utils
 -
 
 - 
+
+Kernel documentation
+
+
+Sphinx
+--
+
+- 
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 04/29] docs-rst: create a book for the development process

[Mauro Carvalho Chehab]

Now that the files at Documentation/development-process/
were converted to ReST, make create a book at Sphinx.

As we'll have other books related to the development process,
we'll add it as a sub-book.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/conf.py   |  2 ++
 Documentation/development-process/conf.py   | 10 ++
 Documentation/development-process/index.rst |  9 +
 Documentation/index.rst |  1 +
 4 files changed, 22 insertions(+)
 create mode 100644 Documentation/development-process/conf.py
 create mode 100644 Documentation/development-process/index.rst

diff --git a/Documentation/conf.py b/Documentation/conf.py
index c25e95d46272..bf6f310e5170 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -338,6 +338,8 @@ latex_elements = {
 latex_documents = [
 ('kernel-documentation', 'kernel-documentation.tex', 'The Linux Kernel 
Documentation',
  'The kernel development community', 'manual'),
+('development-process/index', 'development-process.tex', 'Linux Kernel 
Development Documentation',
+ 'The kernel development community', 'manual'),
 ('gpu/index', 'gpu.tex', 'Linux GPU Driver Developer\'s Guide',
  'The kernel development community', 'manual'),
 ('media/index', 'media.tex', 'Linux Media Subsystem Documentation',
diff --git a/Documentation/development-process/conf.py 
b/Documentation/development-process/conf.py
new file mode 100644
index ..4b4a12dace02
--- /dev/null
+++ b/Documentation/development-process/conf.py
@@ -0,0 +1,10 @@
+# -*- coding: utf-8; mode: python -*-
+
+project = 'Linux Kernel Development Documentation'
+
+tags.add("subproject")
+
+latex_documents = [
+('index', 'development-process.tex', 'Linux Kernel Development 
Documentation',
+ 'The kernel development community', 'manual'),
+]
diff --git a/Documentation/development-process/index.rst 
b/Documentation/development-process/index.rst
new file mode 100644
index ..c37475d91090
--- /dev/null
+++ b/Documentation/development-process/index.rst
@@ -0,0 +1,9 @@
+Linux Kernel Development Documentation
+==
+
+Contents:
+
+.. toctree::
+   :maxdepth: 2
+
+   development-process
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 05eded59820e..c6cf3971788d 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -12,6 +12,7 @@ Contents:
:maxdepth: 2
 
kernel-documentation
+   development-process/index
dev-tools/tools
media/index
gpu/index
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 06/29] Documentation/applying-patches.txt: convert it to ReST markup

[Mauro Carvalho Chehab]

- use the correct markup to identify each section;

- Add some blank lines for Sphinx to properly interpret
  the markups;

- Remove a blank space on some paragraphs;

- Fix the verbatim and bold markups;

- Cleanup the remaining errors to make Sphinx happy.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/applying-patches.txt | 311 ++---
 1 file changed, 189 insertions(+), 122 deletions(-)

diff --git a/Documentation/applying-patches.txt 
b/Documentation/applying-patches.txt
index 77df55b0225a..573eb3bee19e 100644
--- a/Documentation/applying-patches.txt
+++ b/Documentation/applying-patches.txt
@@ -1,9 +1,12 @@
 
-   Applying Patches To The Linux Kernel
-   
+Applying Patches To The Linux Kernel
+
 
-   Original by: Jesper Juhl, August 2005
-   Last update: 2006-01-05
+Original by:
+   Jesper Juhl, August 2005
+
+Last update:
+   2006-01-05
 
 
 A frequently asked question on the Linux Kernel Mailing List is how to apply
@@ -17,10 +20,12 @@ their specific patches) is also provided.
 
 
 What is a patch?

- A patch is a small text document containing a delta of changes between two
-different versions of a source tree. Patches are created with the `diff'
+
+
+A patch is a small text document containing a delta of changes between two
+different versions of a source tree. Patches are created with the ``diff``
 program.
+
 To correctly apply a patch you need to know what base it was generated from
 and what new version the patch will change the source tree into. These
 should both be present in the patch file metadata or be possible to deduce
@@ -28,8 +33,9 @@ from the filename.
 
 
 How do I apply or revert a patch?

- You apply a patch with the `patch' program. The patch program reads a diff
+=
+
+You apply a patch with the ``patch`` program. The patch program reads a diff
 (or patch) file and makes the changes to the source tree described in it.
 
 Patches for the Linux kernel are generated relative to the parent directory
@@ -38,26 +44,39 @@ holding the kernel source dir.
 This means that paths to files inside the patch file contain the name of the
 kernel source directories it was generated against (or some other directory
 names like "a/" and "b/").
+
 Since this is unlikely to match the name of the kernel source dir on your
 local machine (but is often useful info to see what version an otherwise
 unlabeled patch was generated against) you should change into your kernel
 source directory and then strip the first element of the path from filenames
-in the patch file when applying it (the -p1 argument to `patch' does this).
+in the patch file when applying it (the ``-p1`` argument to ``patch`` does
+this).
 
 To revert a previously applied patch, use the -R argument to patch.
 So, if you applied a patch like this:
+
+::
+
patch -p1 < ../patch-x.y.z
 
 You can revert (undo) it like this:
+
+::
+
patch -R -p1 < ../patch-x.y.z
 
 
-How do I feed a patch/diff file to `patch'?

- This (as usual with Linux and other UNIX like operating systems) can be
+How do I feed a patch/diff file to ``patch``?
+=
+
+This (as usual with Linux and other UNIX like operating systems) can be
 done in several different ways.
+
 In all the examples below I feed the file (in uncompressed form) to patch
 via stdin using the following syntax:
+
+::
+
patch -p1 < path/to/patch-x.y.z
 
 If you just want to be able to follow the examples below and don't want to
@@ -66,34 +85,45 @@ section here.
 
 Patch can also get the name of the file to use via the -i argument, like
 this:
+
+::
+
patch -p1 -i path/to/patch-x.y.z
 
 If your patch file is compressed with gzip or bzip2 and you don't want to
 uncompress it before applying it, then you can feed it to patch like this
 instead:
+
+::
+
zcat path/to/patch-x.y.z.gz | patch -p1
bzcat path/to/patch-x.y.z.bz2 | patch -p1
 
 If you wish to uncompress the patch file by hand first before applying it
 (what I assume you've done in the examples below), then you simply run
 gunzip or bunzip2 on the file -- like this:
+
+::
+
gunzip patch-x.y.z.gz
bunzip2 patch-x.y.z.bz2
 
 Which will leave you with a plain text patch-x.y.z file that you can feed to
-patch via stdin or the -i argument, as you prefer.
+patch via stdin or the ``-i`` argument, as you prefer.
 
-A few other nice arguments for patch are -s which causes patch to be silent
+A few other nice arguments for patch are ``-s`` which causes patch to be silent
 except for errors which is nice to prevent errors from scrolling out of the
-screen too fast, and --dry-run which causes patch to just print a listing of
-what would happen, but doesn't actually make any changes. Finally --verbose
+screen too fast, and ``--dry-run`` 

[PATCH v4 05/29] Documentation/HOWTO: convert to ReST notation

[Mauro Carvalho Chehab]

This document is almost compliant with ReST notation, but some
small adjustments are needed to make it parse properly by
Sphinx (mostly, add blank lines where needed).

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/HOWTO | 53 +
 1 file changed, 49 insertions(+), 4 deletions(-)

diff --git a/Documentation/HOWTO b/Documentation/HOWTO
index 1f345da28ec5..5a85e3a8112b 100644
--- a/Documentation/HOWTO
+++ b/Documentation/HOWTO
@@ -1,5 +1,5 @@
 HOWTO do Linux kernel development
--
+=
 
 This is the be-all, end-all document on this topic.  It contains
 instructions on how to become a Linux kernel developer and how to learn
@@ -28,6 +28,7 @@ kernel development.  Assembly (any architecture) is not 
required unless
 you plan to do low-level development for that architecture.  Though they
 are not a good substitute for a solid C education and/or years of
 experience, the following books are good for, if anything, reference:
+
  - "The C Programming Language" by Kernighan and Ritchie [Prentice Hall]
  - "Practical C Programming" by Steve Oualline [O'Reilly]
  - "C:  A Reference Manual" by Harbison and Steele [Prentice Hall]
@@ -64,6 +65,7 @@ people on the mailing lists are not lawyers, and you should 
not rely on
 their statements on legal matters.
 
 For common questions and answers about the GPL, please see:
+
http://www.gnu.org/licenses/gpl-faq.html
 
 
@@ -82,6 +84,7 @@ linux-...@vger.kernel.org.
 
 Here is a list of files that are in the kernel source tree that are
 required reading:
+
   README
 This file gives a short background on the Linux kernel and describes
 what is necessary to do to configure and build the kernel.  People
@@ -99,30 +102,37 @@ required reading:
 patches if these rules are followed, and many people will only
 review code if it is in the proper style.
 
-  Documentation/SubmittingPatches
-  Documentation/SubmittingDrivers
+  Documentation/SubmittingPatches and Documentation/SubmittingDrivers
 These files describe in explicit detail how to successfully create
 and send a patch, including (but not limited to):
+
- Email contents
- Email format
- Who to send it to
+
 Following these rules will not guarantee success (as all patches are
 subject to scrutiny for content and style), but not following them
 will almost always prevent it.
 
 Other excellent descriptions of how to create patches properly are:
+
"The Perfect Patch"
+
http://www.ozlabs.org/~akpm/stuff/tpp.txt
+
"Linux kernel patch submission format"
+
http://linux.yyz.us/patch-format.html
 
   Documentation/stable_api_nonsense.txt
 This file describes the rationale behind the conscious decision to
 not have a stable API within the kernel, including things like:
+
   - Subsystem shim-layers (for compatibility?)
   - Driver portability between Operating Systems.
   - Mitigating rapid change within the kernel source tree (or
preventing rapid change)
+
 This document is crucial for understanding the Linux development
 philosophy and is very important for people moving to Linux from
 development on other Operating Systems.
@@ -159,10 +169,14 @@ full description of the in-kernel API, and rules on how 
to handle
 locking properly.  The documents will be created in the
 Documentation/DocBook/ directory and can be generated as PDF,
 Postscript, HTML, and man pages by running:
+
+::
+
make pdfdocs
make psdocs
make htmldocs
make mandocs
+
 respectively from the main kernel source directory.
 
 
@@ -171,7 +185,9 @@ Becoming A Kernel Developer
 
 If you do not know anything about Linux kernel development, you should
 look at the Linux KernelNewbies project:
+
http://kernelnewbies.org
+
 It consists of a helpful mailing list where you can ask almost any type
 of basic kernel development question (make sure to search the archives
 first, before asking something that has already been answered in the
@@ -187,7 +203,9 @@ apply a patch.
 If you do not know where you want to start, but you want to look for
 some task to start doing to join into the kernel development community,
 go to the Linux Kernel Janitor's project:
+
http://kernelnewbies.org/KernelJanitors
+
 It is a great place to start.  It describes a list of relatively simple
 problems that need to be cleaned up and fixed within the Linux kernel
 source tree.  Working with the developers in charge of this project, you
@@ -199,6 +217,7 @@ If you already have a chunk of code that you want to put 
into the kernel
 tree, but need some help getting it in the proper form, the
 kernel-mentors project was created to help you out with this.  It is a
 mailing list, and can be found at:
+
http://selenic.com/mailman/listinfo/kernel-mentors
 
 

[PATCH v4 00/29] Create a book for Kernel development

[Mauro Carvalho Chehab]

That's the 4th version of this series. It also contains a second patch series
with more ReST conversions and documentation improvements.
This patchset merges the content of a second patch series:

[PATCH 00/17] Improve documentation for the development-process

I opted to keep the patch changing the  kernel-docs.txt changes
(patch 21/29). The patch is already written and another patch
(patch 22/29)  depends on it, because there are references to
this file at Documentation/HOWTO.

It shouldn't be hard  to get rid of it, but I'm not sure if worths
the effort. As I commented, people might find useful to update
it to point to more modern documents. If people won't do it,
it can still be removed from the Kernel a the next Kernel version.

Yet, if you prefer, feel free to drop patch 21/29 and replace
by a patch removing kernel-docs.txt, adding my ack.

I also folded all renaming stuff to a single patch (29/29).

Jon,

   Please don't merge patch 29/29 as-is, as it requires more discussion.

I opted to not rename development-process there, nor to split it into
per-subsystem changes, as we need to first agree about the approach to
be taken. I opted to keep this at the series to allow people to test the
book generation, on both pdf and html formats.

IMHO, patches 1 to 28 should be OK to merge, as they don't do any
renames. We need to discuss more about patch 29, until we solve
this question:
"Should we rename those well-known documents?"

If the answer is "no":

  - should we use symlinks instead?
  - can't Sphinx be tricked to build them with their existing names?

If the answer is "yes":

  - shoud we create files to replace CheckPatch/SubmitPatches/SubmitDrivers
that would point to the newer location?

Also, as you pointed, some of those files (like SecurityBugs) may fit better
on a "users manual" book.

For such book, we'll likely want to group most of the information at
the /README file, and add other stuff there too, like:

Documentation/kernel-parameters.txt
(perhaps splitting its content per-subystem?)

Also, as SecurityBooks is mentioned at HOWTO, if we put it on a separate
book, we'll need to enable interSphinx extension, in order to generate
cross-references between different documents. This is needed for the PDF
output.

Also, "development-process" is a very big name for a dir. We should likely
shorten it to just "process" or "devel". (and "Documentation/" is another
big name too). Those two big names makes several cross-references to
be bigger than the 80-cols limit, like:

:ref:`Documentation/development-process/SubmittingDrivers.rst 
`

--

There are several documents related to Kernel development, where the
HOWTO works like an index to several such documents. There are also
a series of files describing the development process.

This patch series:

1) converts the Documentation/development-process/ to ReST
   and creates a Sphinx book, prepared to support sub-books;

2) Converts several files under Documentation to ReST markup;

3) Move the converted files to development-process/ directory, adding
   a .rst extension to them, adjusting cross-references and adding them
   to the development-process book.

NOTE: HOWTO also mentions the /README document on it. While IMHO it
makes sense to convert it to ReST, moving it out of the main directory
didn't sound a good idea. So, I'm leaving this one untouched.

PS.: I decided to do such conversion because I received yet  another
email from one developer wanted to submit drivers, but not being
aware of the right proceures. As usual, I pointed him to the Kernel
sources, but there are a way too much documentation there with a mix of
procedures and API docs inside.

It would be a way easier to point to a single URL where the submission
procedures would be altoghether. Hopefully, this will have a lot of time
in the future. My evil plan is to put this doc somewhere at LinuxTV and
have a standard e-mail prepared for such next requests :-D

The produced output, in HTML, is at:
https://mchehab.fedorapeople.org/development-process/

The LaTeX version at:

https://mchehab.fedorapeople.org/development-process/latex/development-process.tex

And the PDF version at:

https://mchehab.fedorapeople.org/development-process/latex/development-process.pdf


--

Version 4 changes:

- Keep chapter numeration on the Documentation/* files (CodingStyle
  & friends);
- Use :: on the same line, to improve document reading in plain text;
- Added the contents of a separate patch series:

[PATCH 00/17] Improve documentation for the development-process

  Several patches from such series were folded on the ReST conversion
  patches.

  Ok, this makes this one big, but it helped to keep some sanity, as
  all renames could be folded into a single patch at the end of this
  series.

Version 3 changes:

- Almost all changes here are just a patch set reordering to do first the 
  ReST conversion and then renames. 

[PATCH v4 08/29] Documentation/Changes: convert it to ReST markup

[Mauro Carvalho Chehab]

- Fix chapter identation inconsistencies;
- Convert table to ReST format;
- use the right tag for bullets;
- Fix bold emphasis;
- mark blocks with :: tags;
- use verbatim font for files;
- make Sphinx happy

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/Changes | 224 ++
 1 file changed, 134 insertions(+), 90 deletions(-)

diff --git a/Documentation/Changes b/Documentation/Changes
index ec97b77c8b00..a9f365d864c7 100644
--- a/Documentation/Changes
+++ b/Documentation/Changes
@@ -1,3 +1,6 @@
+Minimal requerements to compile the Kernel
+++
+
 Intro
 =
 
@@ -10,9 +13,9 @@ Axel Boldt, Alessandro Sigala, and countless other users all 
over the
 'net).
 
 Current Minimal Requirements
-
+
 
-Upgrade to at *least* these software revisions before thinking you've
+Upgrade to at **least** these software revisions before thinking you've
 encountered a bug!  If you're unsure what version you're currently
 running, the suggested command should tell you.
 
@@ -21,34 +24,38 @@ running a Linux kernel.  Also, not all tools are necessary 
on all
 systems; obviously, if you don't have any ISDN hardware, for example,
 you probably needn't concern yourself with isdn4k-utils.
 
-o  GNU C  3.2 # gcc --version
-o  GNU make   3.80# make --version
-o  binutils   2.12# ld -v
-o  util-linux 2.10o   # fdformat --version
-o  module-init-tools  0.9.10  # depmod -V
-o  e2fsprogs  1.41.4  # e2fsck -V
-o  jfsutils   1.1.3   # fsck.jfs -V
-o  reiserfsprogs  3.6.3   # reiserfsck -V
-o  xfsprogs   2.6.0   # xfs_db -V
-o  squashfs-tools 4.0 # mksquashfs -version
-o  btrfs-progs0.18# btrfsck
-o  pcmciautils004 # pccardctl -V
-o  quota-tools3.09# quota -V
-o  PPP2.4.0   # pppd --version
-o  isdn4k-utils   3.1pre1 # isdnctrl 2>&1|grep version
-o  nfs-utils  1.0.5   # showmount --version
-o  procps 3.2.0   # ps --version
-o  oprofile   0.9 # oprofiled --version
-o  udev   081 # udevd --version
-o  grub   0.93# grub --version || 
grub-install --version
-o  mcelog 0.6 # mcelog --version
-o  iptables   1.4.2   # iptables -V
-o  openssl & libcrypto1.0.0   # openssl version
-o  bc 1.06.95 # bc --version
+== ===  

+ProgramMinimal version   Command to check the version
+== ===  

+GNU C  3.2  gcc --version
+GNU make   3.80 make --version
+binutils   2.12 ld -v
+util-linux 2.10ofdformat --version
+module-init-tools  0.9.10   depmod -V
+e2fsprogs  1.41.4   e2fsck -V
+jfsutils   1.1.3fsck.jfs -V
+reiserfsprogs  3.6.3reiserfsck -V
+xfsprogs   2.6.0xfs_db -V
+squashfs-tools 4.0  mksquashfs -version
+btrfs-progs0.18 btrfsck
+pcmciautils004  pccardctl -V
+quota-tools3.09 quota -V
+PPP2.4.0pppd --version
+isdn4k-utils   3.1pre1  isdnctrl 2>&1|grep version
+nfs-utils  1.0.5showmount --version
+procps 3.2.0ps --version
+oprofile   0.9  oprofiled --version
+udev   081  udevd --version
+grub   0.93 grub --version || grub-install 
--version
+mcelog 0.6  mcelog --version
+iptables   1.4.2iptables -V
+openssl & libcrypto1.0.0openssl version
+bc 1.06.95  bc --version
+== ===  

 
 
 Kernel compilation
-==
+**
 
 GCC
 ---
@@ -64,16 +71,16 @@ You will need GNU make 3.80 or later to build the kernel.
 Binutils
 
 
-Linux on IA-32 has recently switched from using as86 to using gas for
-assembling the 16-bit boot code, removing the need for as86 to compile

[PATCH v4 01/29] doc-rst: add CSS styles for :kbd: and :menuselection:

[Mauro Carvalho Chehab]

As we're about to use those two markups, add them to the
theme style overrride.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/sphinx-static/theme_overrides.css | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/sphinx-static/theme_overrides.css 
b/Documentation/sphinx-static/theme_overrides.css
index e88461c4c1e6..d5764a4de5a2 100644
--- a/Documentation/sphinx-static/theme_overrides.css
+++ b/Documentation/sphinx-static/theme_overrides.css
@@ -42,6 +42,20 @@
 caption a.headerlink { opacity: 0; }
 caption a.headerlink:hover { opacity: 1; }
 
+/* Menu selection and keystrokes */
+
+span.menuselection {
+   color: blue;
+   font-family: "Courier New", Courier, monospace
+}
+
+code.kbd, code.kbd span {
+   color: white;
+   background-color: darkblue;
+   font-weight: bold;
+   font-family: "Courier New", Courier, monospace
+}
+
 /* inline literal: drop the borderbox, padding and red color */
 
 code, .rst-content tt, .rst-content code {
@@ -55,5 +69,4 @@
 .rst-content tt.literal,.rst-content tt.literal,.rst-content code.literal {
 color: inherit;
 }
-
 }
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 1/3] drivers/of: recognize status property of dt memory nodes

[Balbir Singh]

On 15/09/16 06:06, Reza Arbab wrote:
> Respect the standard dt "status" property when scanning memory nodes in
> early_init_dt_scan_memory(), so that if the property is present and not
> "okay", no memory will be added.
> 
> The use case at hand is accelerator or device memory, which may be
> unusable until post-boot initialization of the memory link. Such a node
> can be described in the dt as any other, given its status is "disabled".
> Per the device tree specification,
> 
> "disabled"
>   Indicates that the device is not presently operational, but it
>   might become operational in the future (for example, something
>   is not plugged in, or switched off).
> 
> Once such memory is made operational, it can then be hotplugged.
> 
> Signed-off-by: Reza Arbab 

Makes sense, so basically a /memory@  with missing status or status = "okay"
are added, others are skipped. No memblocks corresponding to those nodes
are created either.

Balbir Singh
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: pyc files in source dir with O=

[Jani Nikula]

On Sun, 18 Sep 2016, Markus Heiser  wrote:
> Am 07.09.2016 um 15:28 schrieb Jani Nikula :
>
>> On Wed, 07 Sep 2016, Geert Uytterhoeven  wrote:
>>> When running "make htmldocs O=/path/to/somewhere", *.pyc files end up
>>> in the source tree instead of in the build tree:
>>> 
>>>$ git ls-files -o
>>>Documentation/sphinx/kernel-doc.pyc
>>>Documentation/sphinx/kernel_include.pyc
>>>Documentation/sphinx/rstFlatTable.pyc
>>>$
>>> 
>>> This is with v4.8-rc5.
>>> 
>>> With next-20160907, two more files appear:
>>> 
>>>Documentation/sphinx/cdomain.pyc
>>>Documentation/sphinx/load_config.pyc
>> 
>> This should help
>> 
>> diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
>> index 92deea30b183..a4cba2d1aaf1 100644
>> --- a/Documentation/Makefile.sphinx
>> +++ b/Documentation/Makefile.sphinx
>> @@ -53,6 +53,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1))
>> 
>> quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4);
>>   cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) 
>> $(build)=Documentation/media all;\
>> +PYTHONDONTWRITEBYTECODE=1 \
>>  BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
>> $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
>>  $(SPHINXBUILD) \
>>  -b $2 \
>> 
>> 
>> Side note, I'm really sad the Sphinx build has grown so ugly and
>> complicated now. :(
>
> Hi Jani, I feel guilty about this ... 
>
> the "sub-folder" build functionality brought some complexity to
> the cmd_sphinx. In the hope, that it helps a bit, I added a small
> comment on top ...

No amount of documentation will bring back the ability to build the
documentation with pure Sphinx.

BR,
Jani.


>
> # $2 sphinx builder e.g. "html"
> # $3 name of the build subfolder / e.g. "media", used as:
> #* dest folder relative to $(BUILDDIR) and
> #* cache folder relative to $(BUILDDIR)/.doctrees
> # $4 dest subfolder e.g. "man" for man pages at media/man
> # $5 reST source folder relative to $(srctree)/$(src),
> #e.g. "media" for the linux-tv book-set at ./Documentation/media
>
> quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4);
>   cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) 
> $(build)=Documentation/media all;\
>   BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
> $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
>   $(SPHINXBUILD) \
>   -b $2 \
>   -c $(abspath $(srctree)/$(src)) \
>   -d $(abspath $(BUILDDIR)/.doctrees/$3) \
>   -D version=$(KERNELVERSION) -D release=$(KERNELRELEASE) \
>   $(ALLSPHINXOPTS) \
>   $(abspath $(srctree)/$(src)/$5) \
>   $(abspath $(BUILDDIR)/$3/$4);
>
> But you are right, it is very compact / complicated.
>
> --Markus--
>
>> 
>> BR,
>> Jani.
>> 
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 3/3] mm: enable CONFIG_MOVABLE_NODE on powerpc

[Aneesh Kumar K.V]

Reza Arbab  writes:

> Onlining memory into ZONE_MOVABLE requires CONFIG_MOVABLE_NODE. Enable
> the use of this config option on PPC64 platforms.
>
> Signed-off-by: Reza Arbab 
> ---
>  Documentation/kernel-parameters.txt | 2 +-
>  mm/Kconfig  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index a4f4d69..3d8460d 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -2344,7 +2344,7 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   that the amount of memory usable for all allocations
>   is not too small.
>  
> - movable_node[KNL,X86] Boot-time switch to enable the effects
> + movable_node[KNL,X86,PPC] Boot-time switch to enable the effects
>   of CONFIG_MOVABLE_NODE=y. See mm/Kconfig for details.
>  

Movable node also does.
memblock_set_bottom_up(true);
What is the impact of that. Do we need changes equivalent to that ? Also
where are we marking the nodes which can be hotplugged, ie where do we
do memblock_mark_hotplug() ?
   
>   MTD_Partition=  [MTD]
> diff --git a/mm/Kconfig b/mm/Kconfig
> index be0ee11..4b19cd3 100644
> --- a/mm/Kconfig
> +++ b/mm/Kconfig
> @@ -153,7 +153,7 @@ config MOVABLE_NODE
>   bool "Enable to assign a node which has only movable memory"
>   depends on HAVE_MEMBLOCK
>   depends on NO_BOOTMEM
> - depends on X86_64
> + depends on X86_64 || PPC64
>   depends on NUMA
>   default n
>   help

-aneesh

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 RESEND 2/3] Documentation: kdump: Remind user of nr_cpus

[Baoquan He]

From: Zhou Wenjian 

nr_cpus can help to save memory. So we should remind user of it.

Signed-off-by: Zhou Wenjian 
Acked-by: Baoquan He 
Acked-by: Xunlei Pang 
---
 Documentation/kdump/kdump.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index 88ff63d..f7ef340 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -393,6 +393,8 @@ Notes on loading the dump-capture kernel:
 * We generally don' have to bring up a SMP kernel just to capture the
   dump. Hence generally it is useful either to build a UP dump-capture
   kernel or specify maxcpus=1 option while loading dump-capture kernel.
+  Note, though maxcpus always works, you had better replace it with
+  nr_cpus to save memory if supported by the current ARCH, such as x86.
 
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 RESEND 1/3] docs: kernel-parameter : Improve the description of nr_cpus and maxcpus

[Baoquan He]

>From the old description people still can't get what's the exact
difference between nr_cpus and maxcpus. Especially in kdump kernel
nr_cpus is always suggested if it's implemented in ARCH. The reason
is nr_cpus is used to limit the max number of possible cpu in system,
the sum of already plugged cpus and hot plug cpus can't exceed its
value. However maxcpus is used to limit how many cpus are allowed to
be brought up during bootup.

Signed-off-by: Baoquan He 
---
 Documentation/kernel-parameters.txt | 20 +---
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index a4f4d69..98d6406 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2161,10 +2161,13 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
than or equal to this physical address is ignored.
 
maxcpus=[SMP] Maximum number of processors that an SMP kernel
-   should make use of.  maxcpus=n : n >= 0 limits the
-   kernel to using 'n' processors.  n=0 is a special case,
-   it is equivalent to "nosmp", which also disables
-   the IO APIC.
+   will bring up during bootup.  maxcpus=n : n >= 0 limits
+   the kernel to bring up 'n' processors. Surely after
+   bootup you can bring up the other plugged cpu by 
executing
+   "echo 1 > /sys/devices/system/cpu/cpuX/online". So 
maxcpus
+   only takes effect during system bootup.
+   While n=0 is a special case, it is equivalent to 
"nosmp",
+   which also disables the IO APIC.
 
max_loop=   [LOOP] The number of loop block devices that get
(loop.max_loop) unconditionally pre-created at init time. The default
@@ -2773,9 +2776,12 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
 
nr_cpus=[SMP] Maximum number of processors that an SMP kernel
could support.  nr_cpus=n : n >= 1 limits the kernel to
-   supporting 'n' processors. Later in runtime you can not
-   use hotplug cpu feature to put more cpu back to online.
-   just like you compile the kernel NR_CPUS=n
+   support 'n' processors. It could be larger than the
+   number of already plugged CPU during bootup, later in
+   runtime you can physically add extra cpu until it 
reaches
+   n. So during boot up some boot time memory for per-cpu
+   variables need be pre-allocated for later physical cpu
+   hot plugging.
 
nr_uarts=   [SERIAL] maximum number of UARTs to be registered.
 
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 RESEND 3/3] Documentation: kdump: Add description of enable multi-cpus support

[Baoquan He]

From: Zhou Wenjian 

Multi-cpu support is useful to improve the performance of kdump in
some cases. So add the description of enable multi-cpu support in
dump-capture kernel.

Signed-off-by: Zhou Wenjian 
Acked-by: Baoquan He 
Acked-by: Xunlei Pang 
---
 Documentation/kdump/kdump.txt | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
index f7ef340..b0eb27b 100644
--- a/Documentation/kdump/kdump.txt
+++ b/Documentation/kdump/kdump.txt
@@ -396,6 +396,13 @@ Notes on loading the dump-capture kernel:
   Note, though maxcpus always works, you had better replace it with
   nr_cpus to save memory if supported by the current ARCH, such as x86.
 
+* You should enable multi-cpu support in dump-capture kernel if you intend
+  to use multi-thread programs with it, such as parallel dump feature of
+  makedumpfile. Otherwise, the multi-thread program may have a great
+  performance degradation. To enable multi-cpu support, you should bring up an
+  SMP dump-capture kernel and specify maxcpus/nr_cpus, disable_cpu_apicid=[X]
+  options while loading it.
+
 * For s390x there are two kdump modes: If a ELF header is specified with
   the elfcorehdr= kernel parameter, it is used by the kdump kernel as it
   is done on all other architectures. If no elfcorehdr= kernel parameter is
-- 
2.5.5

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html