[PATCH v4 4/4] usb: doc: add document for USB3 debug port usage

[Lu Baolu]

Add Documentation/usb/usb3-debug-port.rst. This document includes
the user guide for USB3 debug port.

Cc: linux-doc@vger.kernel.org
Signed-off-by: Lu Baolu 
---
 Documentation/usb/usb3-debug-port.rst | 95 +++
 1 file changed, 95 insertions(+)
 create mode 100644 Documentation/usb/usb3-debug-port.rst

diff --git a/Documentation/usb/usb3-debug-port.rst 
b/Documentation/usb/usb3-debug-port.rst
new file mode 100644
index 000..70eabe4
--- /dev/null
+++ b/Documentation/usb/usb3-debug-port.rst
@@ -0,0 +1,95 @@
+===
+USB3 debug port
+===
+
+:Author: Lu Baolu 
+:Date: October 2016
+
+GENERAL
+===
+
+This is a HOWTO for using USB3 debug port on x86 systems.
+
+Before using any kernel debugging functionalities based on USB3
+debug port, you need to check 1) whether debug port is supported
+by the xHCI host, 2) which port is used for debugging purpose
+(normally the first USB3 root port). You must have a USB 3.0
+super-speed A-to-A debugging cable to connect the debug target
+with a debug host. In this document, a debug target stands for
+the system under debugging; while, a debug host stands for a
+stand-alone system that is able to talk to the debugging target
+through the USB3 debug port.
+
+EARLY PRINTK
+
+
+On debug target system, you need to customize a debugging kernel
+with CONFIG_EARLY_PRINTK_XDBC enabled. And add below kernel boot
+parameter::
+
+   "earlyprintk=xdbc"
+
+If there are multiple xHCI controllers in the system, you can
+append a host contoller index to this kernel parameter. This
+index is started from 0.
+
+If you are going to leverage the keep option defined by the
+early printk framework to keep the boot console alive after
+early boot, you'd better add below kernel boot parameter::
+
+   "usbcore.autosuspend=-1"
+
+On debug host side, you don't need to customize the kernel, but
+you need to disable usb subsystem runtime power management by
+adding below kernel boot parameter::
+
+   "usbcore.autosuspend=-1"
+
+Before starting the debug target, you should connect the debug
+port on debug target with a root port or port of any external hub
+on the debug host. The cable used to connect these two ports
+should be a USB 3.0 super-speed A-to-A debugging cable.
+
+During early boot of debug target, DbC (the debug engine for USB3
+debug port) hardware gets initialized. Debug host should be able
+to enumerate the debug target as a debug device. Debug host will
+then bind the debug device with the usb_debug driver module and
+create the /dev/ttyUSB0 device.
+
+If device enumeration goes smoothly, you should be able to see
+below kernel messages on debug host::
+
+   # tail -f /var/log/kern.log
+   [ 1815.983374] usb 4-3: new SuperSpeed USB device number 4 using 
xhci_hcd
+   [ 1815.999595] usb 4-3: LPM exit latency is zeroed, disabling LPM.
+   [ 1815.999899] usb 4-3: New USB device found, idVendor=1d6b, 
idProduct=0004
+   [ 1815.02] usb 4-3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
+   [ 1815.03] usb 4-3: Product: Remote GDB
+   [ 1815.04] usb 4-3: Manufacturer: Linux
+   [ 1815.05] usb 4-3: SerialNumber: 0001
+   [ 1816.000240] usb_debug 4-3:1.0: xhci_dbc converter detected
+   [ 1816.000360] usb 4-3: xhci_dbc converter now attached to ttyUSB0
+
+You can run below bash scripts on debug host to read the kernel
+log sent from debug target.
+
+.. code-block:: sh
+
+   = start of bash scripts =
+   #!/bin/bash
+
+   while true ; do
+   while [ ! -d /sys/class/tty/ttyUSB0 ] ; do
+   :
+   done
+   cat /dev/ttyUSB0 >> xdbc.log
+   done
+   = end of bash scripts ===
+
+You should be able to see the early boot message in xdbc.log.
+
+If it doesn't work, please ask it on the 
+mailing list. Below USB hosts have been verified to work::
+
+   Intel Corporation Sunrise Point-H USB 3.0 xHCI Controller
+   Intel Corporation Wildcat Point-LP USB xHCI Controller
-- 
2.1.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: make pdfdocs fails with v4.9-rc3

[Mauro Carvalho Chehab]

Em Mon, 31 Oct 2016 16:41:48 -0600
Mauro Carvalho Chehab  escreveu:

> Em Mon, 31 Oct 2016 16:40:02 -0600
> Mauro Carvalho Chehab  escreveu:
> 
> > Em Mon, 31 Oct 2016 15:04:42 -0700
> > Jim Davis  escreveu:
> > 
> > > On Mon, Oct 31, 2016 at 1:58 PM, Mauro Carvalho Chehab
> > >  wrote:
> > > > Em Mon, 31 Oct 2016 14:17:59 -0600
> > > > Mauro Carvalho Chehab  escreveu:
> > > >  
> > > >> Em Mon, 31 Oct 2016 13:15:24 -0600
> > > >> Jonathan Corbet  escreveu:
> > > >>  
> > > >> > On Mon, 31 Oct 2016 11:51:20 -0700
> > > >> > Jim Davis  wrote:
> > > >> >  
> > > >> > > Running make pdfdocs on a Ubuntu 16.04 system fails with
> > > >> > >
> > > >> > > Makefile:58: recipe for target 'media.pdf' failed
> > > >> > > make[2]: *** [media.pdf] Error 1
> > > >> > > Documentation/Makefile.sphinx:79: recipe for target 'pdfdocs' 
> > > >> > > failed
> > > >> > > make[1]: *** [pdfdocs] Error 2
> > > >> > > Makefile:1442: recipe for target 'pdfdocs' failed
> > > >> > > make: *** [pdfdocs] Error 2
> > > >> > >
> > > >> > > It's not clear from the voluminous (>5MB) output from make pdfdocs
> > > >> > > exactly which stage is failing, and there are some pdf files 
> > > >> > > produced
> > > >> > > in output/latex.  
> > > >> >
> > > >> > Hmm, so it does.  It comes down to this:
> > > >> >
> > > >> > ! LaTeX Error: \DUrole undefined.
> > > >> >
> > > >> > See the LaTeX manual or LaTeX Companion for explanation.
> > > >> > Type  H   for immediate help.
> > > >> >  ...
> > > >> >
> > > >> > l.195 \renewcommand*{\DUrole}
> > > >> >  [2]{ #2 }
> > > >> >
> > > >> > Where the offending command is in Documentation/media/index.rst.  
> > > >> > Mauro,
> > > >> > got an idea for what's going on there?  
> > > >>
> > > >> Sphinx is really a poor solution when it comes to PDF output. In this
> > > >> specific case, this is meant to fix a problem with cross-references.
> > > >>
> > > >> What happens is that Sphinx 1.4.6 (and later?) define reference names 
> > > >> without
> > > >> being properly escaped. So, for some references, it causes the PDF 
> > > >> output
> > > >> to crash. That happens at one of the DVB header files, if I remember 
> > > >> well.
> > > >>
> > > >> This commit restores the sphinx 1.2.x behavior:
> > > >>
> > > >> commit e61a39baf74dddb6cd236147bd19b55c10188d78
> > > >> Author: Mauro Carvalho Chehab 
> > > >> Date:   Sun Aug 21 15:14:57 2016 -0300
> > > >>
> > > >> [media] index.rst: Fix LaTeX error in interactive mode on Sphinx 
> > > >> 1.4.x
> > > >>
> > > >> The Sphinx 1.4.x definition for \DUrole is:
> > > >>
> > > >> \providecommand*{\DUrole}[2]{%
> > > >>   \ifcsname DUrole#1\endcsname%
> > > >> \csname DUrole#1\endcsname{#2}%
> > > >>   \else% backwards compatibility: try \docutilsrole#1{#2}
> > > >> \ifcsname docutilsrole#1\endcsname%
> > > >>   \csname docutilsrole#1\endcsname{#2}%
> > > >> \else%
> > > >>   #2%
> > > >> \fi%
> > > >>   \fi%
> > > >> }
> > > >>
> > > >> This is broken when it is used inside a \begin{alltt} block.
> > > >> So, replace it by just "#2", as this won't cause troubles, and
> > > >> it is one of the fallback methods for it.
> > > >>
> > > >> Signed-off-by: Mauro Carvalho Chehab 
> > > >>
> > > >> At the time I tested, it worked fine, but maybe it is redefining the
> > > >> \DUrole too late.
> > > >>
> > > >> Maybe we could move it to LaTeX preamble instead. Please check if this
> > > >> untested patch fixes the issue.  
> > > >
> > > > Yes, this seems to be the case. The patch below should fix it.
> > > >
> > > > [PATCH] docs-rst: fix PDF build errors
> > > >
> > > > PDF build on Kernel 4.9-rc? returns an error. This is
> > > > because we're re-defining a command too late. Move
> > > > such redefinition to LaTeX preamble.
> > > >
> > > > Tested by building the documentation on interactive mode:
> > > > make PDFLATEX=xelatex -C Documentation/output/./latex
> > > >
> > > > Fixes: e61a39baf74d ("[media] index.rst: Fix LaTeX error in interactive 
> > > > mode on Sphinx 1.4.x")
> > > >
> > > > Signed-off-by: Mauro Carvalho Chehab 
> > > >
> > > > diff --git a/Documentation/conf.py b/Documentation/conf.py
> > > > index d9bad21dd427..d9ebfeb431a9 100644
> > > > --- a/Documentation/conf.py
> > > > +++ b/Documentation/conf.py
> > > > @@ -329,6 +329,9 @@ latex_elements = {
> > > > % To allow adjusting table sizes
> > > > \\usepackage{adjustbox}
> > > >
> > > > +   % Fix reference escape troubles with Sphinx 1.4.x
> > > > +   \\renewcommand*{\\DUrole}[2]{ #2 }
> > > > +
> > > >   '''
> > > >  }
> > > >
> > > > diff --git a/Documentation/media/index.rst 
> > > > b/Documentation/media/index.rst
> > 

Re: make pdfdocs fails with v4.9-rc3

[Mauro Carvalho Chehab]

Em Mon, 31 Oct 2016 16:40:02 -0600
Mauro Carvalho Chehab  escreveu:

> Em Mon, 31 Oct 2016 15:04:42 -0700
> Jim Davis  escreveu:
> 
> > On Mon, Oct 31, 2016 at 1:58 PM, Mauro Carvalho Chehab
> >  wrote:
> > > Em Mon, 31 Oct 2016 14:17:59 -0600
> > > Mauro Carvalho Chehab  escreveu:
> > >  
> > >> Em Mon, 31 Oct 2016 13:15:24 -0600
> > >> Jonathan Corbet  escreveu:
> > >>  
> > >> > On Mon, 31 Oct 2016 11:51:20 -0700
> > >> > Jim Davis  wrote:
> > >> >  
> > >> > > Running make pdfdocs on a Ubuntu 16.04 system fails with
> > >> > >
> > >> > > Makefile:58: recipe for target 'media.pdf' failed
> > >> > > make[2]: *** [media.pdf] Error 1
> > >> > > Documentation/Makefile.sphinx:79: recipe for target 'pdfdocs' failed
> > >> > > make[1]: *** [pdfdocs] Error 2
> > >> > > Makefile:1442: recipe for target 'pdfdocs' failed
> > >> > > make: *** [pdfdocs] Error 2
> > >> > >
> > >> > > It's not clear from the voluminous (>5MB) output from make pdfdocs
> > >> > > exactly which stage is failing, and there are some pdf files produced
> > >> > > in output/latex.  
> > >> >
> > >> > Hmm, so it does.  It comes down to this:
> > >> >
> > >> > ! LaTeX Error: \DUrole undefined.
> > >> >
> > >> > See the LaTeX manual or LaTeX Companion for explanation.
> > >> > Type  H   for immediate help.
> > >> >  ...
> > >> >
> > >> > l.195 \renewcommand*{\DUrole}
> > >> >  [2]{ #2 }
> > >> >
> > >> > Where the offending command is in Documentation/media/index.rst.  
> > >> > Mauro,
> > >> > got an idea for what's going on there?  
> > >>
> > >> Sphinx is really a poor solution when it comes to PDF output. In this
> > >> specific case, this is meant to fix a problem with cross-references.
> > >>
> > >> What happens is that Sphinx 1.4.6 (and later?) define reference names 
> > >> without
> > >> being properly escaped. So, for some references, it causes the PDF output
> > >> to crash. That happens at one of the DVB header files, if I remember 
> > >> well.
> > >>
> > >> This commit restores the sphinx 1.2.x behavior:
> > >>
> > >> commit e61a39baf74dddb6cd236147bd19b55c10188d78
> > >> Author: Mauro Carvalho Chehab 
> > >> Date:   Sun Aug 21 15:14:57 2016 -0300
> > >>
> > >> [media] index.rst: Fix LaTeX error in interactive mode on Sphinx 
> > >> 1.4.x
> > >>
> > >> The Sphinx 1.4.x definition for \DUrole is:
> > >>
> > >> \providecommand*{\DUrole}[2]{%
> > >>   \ifcsname DUrole#1\endcsname%
> > >> \csname DUrole#1\endcsname{#2}%
> > >>   \else% backwards compatibility: try \docutilsrole#1{#2}
> > >> \ifcsname docutilsrole#1\endcsname%
> > >>   \csname docutilsrole#1\endcsname{#2}%
> > >> \else%
> > >>   #2%
> > >> \fi%
> > >>   \fi%
> > >> }
> > >>
> > >> This is broken when it is used inside a \begin{alltt} block.
> > >> So, replace it by just "#2", as this won't cause troubles, and
> > >> it is one of the fallback methods for it.
> > >>
> > >> Signed-off-by: Mauro Carvalho Chehab 
> > >>
> > >> At the time I tested, it worked fine, but maybe it is redefining the
> > >> \DUrole too late.
> > >>
> > >> Maybe we could move it to LaTeX preamble instead. Please check if this
> > >> untested patch fixes the issue.  
> > >
> > > Yes, this seems to be the case. The patch below should fix it.
> > >
> > > [PATCH] docs-rst: fix PDF build errors
> > >
> > > PDF build on Kernel 4.9-rc? returns an error. This is
> > > because we're re-defining a command too late. Move
> > > such redefinition to LaTeX preamble.
> > >
> > > Tested by building the documentation on interactive mode:
> > > make PDFLATEX=xelatex -C Documentation/output/./latex
> > >
> > > Fixes: e61a39baf74d ("[media] index.rst: Fix LaTeX error in interactive 
> > > mode on Sphinx 1.4.x")
> > >
> > > Signed-off-by: Mauro Carvalho Chehab 
> > >
> > > diff --git a/Documentation/conf.py b/Documentation/conf.py
> > > index d9bad21dd427..d9ebfeb431a9 100644
> > > --- a/Documentation/conf.py
> > > +++ b/Documentation/conf.py
> > > @@ -329,6 +329,9 @@ latex_elements = {
> > > % To allow adjusting table sizes
> > > \\usepackage{adjustbox}
> > >
> > > +   % Fix reference escape troubles with Sphinx 1.4.x
> > > +   \\renewcommand*{\\DUrole}[2]{ #2 }
> > > +
> > >   '''
> > >  }
> > >
> > > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> > > index e347a3e7bdef..7f8f0af620ce 100644
> > > --- a/Documentation/media/index.rst
> > > +++ b/Documentation/media/index.rst
> > > @@ -1,11 +1,6 @@
> > >  Linux Media Subsystem Documentation
> > >  ===
> > >
> > > -.. Sphinx 1.4.x has a definition for DUrole that doesn't work on alltt 
> > > blocks
> > > -.. raw:: latex
> > > -
> > > -   

Re: make pdfdocs fails with v4.9-rc3

[Mauro Carvalho Chehab]

Em Mon, 31 Oct 2016 15:04:42 -0700
Jim Davis  escreveu:

> On Mon, Oct 31, 2016 at 1:58 PM, Mauro Carvalho Chehab
>  wrote:
> > Em Mon, 31 Oct 2016 14:17:59 -0600
> > Mauro Carvalho Chehab  escreveu:
> >  
> >> Em Mon, 31 Oct 2016 13:15:24 -0600
> >> Jonathan Corbet  escreveu:
> >>  
> >> > On Mon, 31 Oct 2016 11:51:20 -0700
> >> > Jim Davis  wrote:
> >> >  
> >> > > Running make pdfdocs on a Ubuntu 16.04 system fails with
> >> > >
> >> > > Makefile:58: recipe for target 'media.pdf' failed
> >> > > make[2]: *** [media.pdf] Error 1
> >> > > Documentation/Makefile.sphinx:79: recipe for target 'pdfdocs' failed
> >> > > make[1]: *** [pdfdocs] Error 2
> >> > > Makefile:1442: recipe for target 'pdfdocs' failed
> >> > > make: *** [pdfdocs] Error 2
> >> > >
> >> > > It's not clear from the voluminous (>5MB) output from make pdfdocs
> >> > > exactly which stage is failing, and there are some pdf files produced
> >> > > in output/latex.  
> >> >
> >> > Hmm, so it does.  It comes down to this:
> >> >
> >> > ! LaTeX Error: \DUrole undefined.
> >> >
> >> > See the LaTeX manual or LaTeX Companion for explanation.
> >> > Type  H   for immediate help.
> >> >  ...
> >> >
> >> > l.195 \renewcommand*{\DUrole}
> >> >  [2]{ #2 }
> >> >
> >> > Where the offending command is in Documentation/media/index.rst.  Mauro,
> >> > got an idea for what's going on there?  
> >>
> >> Sphinx is really a poor solution when it comes to PDF output. In this
> >> specific case, this is meant to fix a problem with cross-references.
> >>
> >> What happens is that Sphinx 1.4.6 (and later?) define reference names 
> >> without
> >> being properly escaped. So, for some references, it causes the PDF output
> >> to crash. That happens at one of the DVB header files, if I remember well.
> >>
> >> This commit restores the sphinx 1.2.x behavior:
> >>
> >> commit e61a39baf74dddb6cd236147bd19b55c10188d78
> >> Author: Mauro Carvalho Chehab 
> >> Date:   Sun Aug 21 15:14:57 2016 -0300
> >>
> >> [media] index.rst: Fix LaTeX error in interactive mode on Sphinx 1.4.x
> >>
> >> The Sphinx 1.4.x definition for \DUrole is:
> >>
> >> \providecommand*{\DUrole}[2]{%
> >>   \ifcsname DUrole#1\endcsname%
> >> \csname DUrole#1\endcsname{#2}%
> >>   \else% backwards compatibility: try \docutilsrole#1{#2}
> >> \ifcsname docutilsrole#1\endcsname%
> >>   \csname docutilsrole#1\endcsname{#2}%
> >> \else%
> >>   #2%
> >> \fi%
> >>   \fi%
> >> }
> >>
> >> This is broken when it is used inside a \begin{alltt} block.
> >> So, replace it by just "#2", as this won't cause troubles, and
> >> it is one of the fallback methods for it.
> >>
> >> Signed-off-by: Mauro Carvalho Chehab 
> >>
> >> At the time I tested, it worked fine, but maybe it is redefining the
> >> \DUrole too late.
> >>
> >> Maybe we could move it to LaTeX preamble instead. Please check if this
> >> untested patch fixes the issue.  
> >
> > Yes, this seems to be the case. The patch below should fix it.
> >
> > [PATCH] docs-rst: fix PDF build errors
> >
> > PDF build on Kernel 4.9-rc? returns an error. This is
> > because we're re-defining a command too late. Move
> > such redefinition to LaTeX preamble.
> >
> > Tested by building the documentation on interactive mode:
> > make PDFLATEX=xelatex -C Documentation/output/./latex
> >
> > Fixes: e61a39baf74d ("[media] index.rst: Fix LaTeX error in interactive 
> > mode on Sphinx 1.4.x")
> >
> > Signed-off-by: Mauro Carvalho Chehab 
> >
> > diff --git a/Documentation/conf.py b/Documentation/conf.py
> > index d9bad21dd427..d9ebfeb431a9 100644
> > --- a/Documentation/conf.py
> > +++ b/Documentation/conf.py
> > @@ -329,6 +329,9 @@ latex_elements = {
> > % To allow adjusting table sizes
> > \\usepackage{adjustbox}
> >
> > +   % Fix reference escape troubles with Sphinx 1.4.x
> > +   \\renewcommand*{\\DUrole}[2]{ #2 }
> > +
> >   '''
> >  }
> >
> > diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> > index e347a3e7bdef..7f8f0af620ce 100644
> > --- a/Documentation/media/index.rst
> > +++ b/Documentation/media/index.rst
> > @@ -1,11 +1,6 @@
> >  Linux Media Subsystem Documentation
> >  ===
> >
> > -.. Sphinx 1.4.x has a definition for DUrole that doesn't work on alltt 
> > blocks
> > -.. raw:: latex
> > -
> > -   \renewcommand*{\DUrole}[2]{ #2 }
> > -
> >  Contents:
> >
> >  .. toctree::
> >
> >
> >
> >
> > Cheers,
> > Mauro  
> 
> After applying the patch I'm seeing a similar error message
> 
> [...]
> Running Sphinx v1.3.1
> [...]

Ah! you're running version 1.3.1...

We should likely add some logic at conf.py to only enable this on
Sphinx 1.4.x...

Cheers,
Mauro
--
To 

Re: make pdfdocs fails with v4.9-rc3

[Jim Davis]

On Mon, Oct 31, 2016 at 1:58 PM, Mauro Carvalho Chehab
 wrote:
> Em Mon, 31 Oct 2016 14:17:59 -0600
> Mauro Carvalho Chehab  escreveu:
>
>> Em Mon, 31 Oct 2016 13:15:24 -0600
>> Jonathan Corbet  escreveu:
>>
>> > On Mon, 31 Oct 2016 11:51:20 -0700
>> > Jim Davis  wrote:
>> >
>> > > Running make pdfdocs on a Ubuntu 16.04 system fails with
>> > >
>> > > Makefile:58: recipe for target 'media.pdf' failed
>> > > make[2]: *** [media.pdf] Error 1
>> > > Documentation/Makefile.sphinx:79: recipe for target 'pdfdocs' failed
>> > > make[1]: *** [pdfdocs] Error 2
>> > > Makefile:1442: recipe for target 'pdfdocs' failed
>> > > make: *** [pdfdocs] Error 2
>> > >
>> > > It's not clear from the voluminous (>5MB) output from make pdfdocs
>> > > exactly which stage is failing, and there are some pdf files produced
>> > > in output/latex.
>> >
>> > Hmm, so it does.  It comes down to this:
>> >
>> > ! LaTeX Error: \DUrole undefined.
>> >
>> > See the LaTeX manual or LaTeX Companion for explanation.
>> > Type  H   for immediate help.
>> >  ...
>> >
>> > l.195 \renewcommand*{\DUrole}
>> >  [2]{ #2 }
>> >
>> > Where the offending command is in Documentation/media/index.rst.  Mauro,
>> > got an idea for what's going on there?
>>
>> Sphinx is really a poor solution when it comes to PDF output. In this
>> specific case, this is meant to fix a problem with cross-references.
>>
>> What happens is that Sphinx 1.4.6 (and later?) define reference names without
>> being properly escaped. So, for some references, it causes the PDF output
>> to crash. That happens at one of the DVB header files, if I remember well.
>>
>> This commit restores the sphinx 1.2.x behavior:
>>
>> commit e61a39baf74dddb6cd236147bd19b55c10188d78
>> Author: Mauro Carvalho Chehab 
>> Date:   Sun Aug 21 15:14:57 2016 -0300
>>
>> [media] index.rst: Fix LaTeX error in interactive mode on Sphinx 1.4.x
>>
>> The Sphinx 1.4.x definition for \DUrole is:
>>
>> \providecommand*{\DUrole}[2]{%
>>   \ifcsname DUrole#1\endcsname%
>> \csname DUrole#1\endcsname{#2}%
>>   \else% backwards compatibility: try \docutilsrole#1{#2}
>> \ifcsname docutilsrole#1\endcsname%
>>   \csname docutilsrole#1\endcsname{#2}%
>> \else%
>>   #2%
>> \fi%
>>   \fi%
>> }
>>
>> This is broken when it is used inside a \begin{alltt} block.
>> So, replace it by just "#2", as this won't cause troubles, and
>> it is one of the fallback methods for it.
>>
>> Signed-off-by: Mauro Carvalho Chehab 
>>
>> At the time I tested, it worked fine, but maybe it is redefining the
>> \DUrole too late.
>>
>> Maybe we could move it to LaTeX preamble instead. Please check if this
>> untested patch fixes the issue.
>
> Yes, this seems to be the case. The patch below should fix it.
>
> [PATCH] docs-rst: fix PDF build errors
>
> PDF build on Kernel 4.9-rc? returns an error. This is
> because we're re-defining a command too late. Move
> such redefinition to LaTeX preamble.
>
> Tested by building the documentation on interactive mode:
> make PDFLATEX=xelatex -C Documentation/output/./latex
>
> Fixes: e61a39baf74d ("[media] index.rst: Fix LaTeX error in interactive mode 
> on Sphinx 1.4.x")
>
> Signed-off-by: Mauro Carvalho Chehab 
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index d9bad21dd427..d9ebfeb431a9 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -329,6 +329,9 @@ latex_elements = {
> % To allow adjusting table sizes
> \\usepackage{adjustbox}
>
> +   % Fix reference escape troubles with Sphinx 1.4.x
> +   \\renewcommand*{\\DUrole}[2]{ #2 }
> +
>   '''
>  }
>
> diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
> index e347a3e7bdef..7f8f0af620ce 100644
> --- a/Documentation/media/index.rst
> +++ b/Documentation/media/index.rst
> @@ -1,11 +1,6 @@
>  Linux Media Subsystem Documentation
>  ===
>
> -.. Sphinx 1.4.x has a definition for DUrole that doesn't work on alltt blocks
> -.. raw:: latex
> -
> -   \renewcommand*{\DUrole}[2]{ #2 }
> -
>  Contents:
>
>  .. toctree::
>
>
>
>
> Cheers,
> Mauro

After applying the patch I'm seeing a similar error message

[...]
Running Sphinx v1.3.1
[...]

! LaTeX Error: \DUrole undefined.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...

l.79 ^^I\renewcommand*{\DUrole}
   [2]{ #2 }

but in a different place

Makefile:58: recipe for target 'development-process.pdf' failed
make[2]: *** [development-process.pdf] Error 1
Documentation/Makefile.sphinx:79: recipe for target 'pdfdocs' failed

It was failing with the media.pdf target before.

And there was a development-process.pdf file created; it doesn't 

Re: make pdfdocs fails with v4.9-rc3

[Mauro Carvalho Chehab]

Em Mon, 31 Oct 2016 14:17:59 -0600
Mauro Carvalho Chehab  escreveu:

> Em Mon, 31 Oct 2016 13:15:24 -0600
> Jonathan Corbet  escreveu:
> 
> > On Mon, 31 Oct 2016 11:51:20 -0700
> > Jim Davis  wrote:
> >   
> > > Running make pdfdocs on a Ubuntu 16.04 system fails with
> > > 
> > > Makefile:58: recipe for target 'media.pdf' failed
> > > make[2]: *** [media.pdf] Error 1
> > > Documentation/Makefile.sphinx:79: recipe for target 'pdfdocs' failed
> > > make[1]: *** [pdfdocs] Error 2
> > > Makefile:1442: recipe for target 'pdfdocs' failed
> > > make: *** [pdfdocs] Error 2
> > > 
> > > It's not clear from the voluminous (>5MB) output from make pdfdocs
> > > exactly which stage is failing, and there are some pdf files produced
> > > in output/latex.
> > 
> > Hmm, so it does.  It comes down to this:
> > 
> > ! LaTeX Error: \DUrole undefined.
> > 
> > See the LaTeX manual or LaTeX Companion for explanation.
> > Type  H   for immediate help.
> >  ...  
> >   
> > l.195 \renewcommand*{\DUrole}
> >  [2]{ #2 }
> > 
> > Where the offending command is in Documentation/media/index.rst.  Mauro,
> > got an idea for what's going on there?  
> 
> Sphinx is really a poor solution when it comes to PDF output. In this
> specific case, this is meant to fix a problem with cross-references.
> 
> What happens is that Sphinx 1.4.6 (and later?) define reference names without
> being properly escaped. So, for some references, it causes the PDF output
> to crash. That happens at one of the DVB header files, if I remember well.
> 
> This commit restores the sphinx 1.2.x behavior:
> 
> commit e61a39baf74dddb6cd236147bd19b55c10188d78
> Author: Mauro Carvalho Chehab 
> Date:   Sun Aug 21 15:14:57 2016 -0300
> 
> [media] index.rst: Fix LaTeX error in interactive mode on Sphinx 1.4.x
> 
> The Sphinx 1.4.x definition for \DUrole is:
> 
> \providecommand*{\DUrole}[2]{%
>   \ifcsname DUrole#1\endcsname%
> \csname DUrole#1\endcsname{#2}%
>   \else% backwards compatibility: try \docutilsrole#1{#2}
> \ifcsname docutilsrole#1\endcsname%
>   \csname docutilsrole#1\endcsname{#2}%
> \else%
>   #2%
> \fi%
>   \fi%
> }
> 
> This is broken when it is used inside a \begin{alltt} block.
> So, replace it by just "#2", as this won't cause troubles, and
> it is one of the fallback methods for it.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> 
> At the time I tested, it worked fine, but maybe it is redefining the
> \DUrole too late.
> 
> Maybe we could move it to LaTeX preamble instead. Please check if this
> untested patch fixes the issue.

Yes, this seems to be the case. The patch below should fix it.

[PATCH] docs-rst: fix PDF build errors

PDF build on Kernel 4.9-rc? returns an error. This is
because we're re-defining a command too late. Move
such redefinition to LaTeX preamble.

Tested by building the documentation on interactive mode:
make PDFLATEX=xelatex -C Documentation/output/./latex

Fixes: e61a39baf74d ("[media] index.rst: Fix LaTeX error in interactive mode on 
Sphinx 1.4.x")

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/Documentation/conf.py b/Documentation/conf.py
index d9bad21dd427..d9ebfeb431a9 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -329,6 +329,9 @@ latex_elements = {
% To allow adjusting table sizes
\\usepackage{adjustbox}
 
+   % Fix reference escape troubles with Sphinx 1.4.x
+   \\renewcommand*{\\DUrole}[2]{ #2 }
+
  '''
 }
 
diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
index e347a3e7bdef..7f8f0af620ce 100644
--- a/Documentation/media/index.rst
+++ b/Documentation/media/index.rst
@@ -1,11 +1,6 @@
 Linux Media Subsystem Documentation
 ===
 
-.. Sphinx 1.4.x has a definition for DUrole that doesn't work on alltt blocks
-.. raw:: latex
-
-   \renewcommand*{\DUrole}[2]{ #2 }
-
 Contents:
 
 .. toctree::




Cheers,
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

Re: make cleandocs missing files with v4.9-rc3

[Jani Nikula]

On Mon, 31 Oct 2016, Jim Davis  wrote:
> On my Ubuntu 16.04 system, make htmldocs works just fine (hurrah!) but
> make cleandocs misses a fair number of files:
>
>   HTMLDocumentation/DocBook/index.html
> jim@krebstar:~/linux-rc$ make cleandocs
> jim@krebstar:~/linux-rc$ git status
> HEAD detached at v4.9-rc3
> nothing to commit, working directory clean
> jim@krebstar:~/linux-rc$ git clean -fdx
> Removing Documentation/DocBook/.alsa-driver-api.xml.cmd
> Removing Documentation/DocBook/.crypto-API.xml.cmd
> Removing Documentation/DocBook/.debugobjects.xml.cmd
> Removing Documentation/DocBook/.deviceiobook.xml.cmd
> Removing Documentation/DocBook/.filesystems.xml.cmd
> Removing Documentation/DocBook/.gadget.xml.cmd
> Removing Documentation/DocBook/.genericirq.xml.cmd
> Removing Documentation/DocBook/.iio.xml.cmd
> Removing Documentation/DocBook/.kernel-api.xml.cmd
> Removing Documentation/DocBook/.kernel-hacking.xml.cmd
> Removing Documentation/DocBook/.kernel-locking.xml.cmd
> Removing Documentation/DocBook/.kgdb.xml.cmd
> Removing Documentation/DocBook/.libata.xml.cmd
> Removing Documentation/DocBook/.librs.xml.cmd
> Removing Documentation/DocBook/.lsm.xml.cmd
> Removing Documentation/DocBook/.mtdnand.xml.cmd
> Removing Documentation/DocBook/.networking.xml.cmd
> Removing Documentation/DocBook/.rapidio.xml.cmd
> Removing Documentation/DocBook/.regulator.xml.cmd
> Removing Documentation/DocBook/.s390-drivers.xml.cmd
> Removing Documentation/DocBook/.scsi.xml.cmd
> Removing Documentation/DocBook/.sh.xml.cmd
> Removing Documentation/DocBook/.tracepoint.xml.cmd
> Removing Documentation/DocBook/.uio-howto.xml.cmd
> Removing Documentation/DocBook/.usb.xml.cmd
> Removing Documentation/DocBook/.w1.xml.cmd
> Removing Documentation/DocBook/.writing-an-alsa-driver.xml.cmd
> Removing Documentation/DocBook/.writing_musb_glue_layer.xml.cmd
> Removing Documentation/DocBook/.writing_usb_driver.xml.cmd
> Removing Documentation/DocBook/.z8530book.xml.cmd
> Removing Documentation/sphinx/cdomain.pyc
> Removing Documentation/sphinx/kernel-doc.pyc
> Removing Documentation/sphinx/kernel_include.pyc
> Removing Documentation/sphinx/load_config.pyc
> Removing Documentation/sphinx/rstFlatTable.pyc

This patch [1] should fix the pyc stuff. I suspect the rest have been
broken forever; will be fixed when the DocBook toolchain gets nuked. ;)

BR,
Jani.


[1] 
http://lkml.kernel.org/r/1477945781-8354-1-git-send-email-jani.nik...@intel.com


> Removing scripts/.check-lc_ctype.cmd
> Removing scripts/.docproc.cmd
> Removing scripts/basic/.fixdep.cmd
> Removing scripts/basic/fixdep
> Removing scripts/check-lc_ctype
> Removing scripts/docproc

-- 
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

[PATCH v2 06/12] ko_KR/HOWTO: Add cross-references to other documents

[SeongJae Park]

This commit applies commit 609d99a3b72e ("Documentation/HOWTO: add
cross-references to other documents") to Korean translation.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 19 +--
 1 file changed, 9 insertions(+), 10 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index c2a3f1719753..7f0b4e66e6c2 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -104,18 +104,17 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 빌드하기 위해 필요한 것을 설명한다. 커널에 입문하는 사람들은 여기서
 시작해야 한다.
 
-  Documentation/process/changes.rst
+  :ref:`Documentation/process/changes.rst `
 이 파일은 커널을 성공적으로 빌드하고 실행시키기 위해 필요한 다양한
 소프트웨어 패키지들의 최소 버젼을 나열한다.
 
-  Documentation/process/coding-style.rst
+  :ref:`Documentation/process/coding-style.rst `
 이 문서는 리눅스 커널 코딩 스타일과 그렇게 한 몇몇 이유를 설명한다.
 모든 새로운 코드는 이 문서에 가이드라인들을 따라야 한다. 대부분의
 메인테이너들은 이 규칙을 따르는 패치들만을 받아들일 것이고 많은 사람들이
 그 패치가 올바른 스타일일 경우만 코드를 검토할 것이다.
 
-  Documentation/process/submitting-patches.rst
-  Documentation/process/submitting-drivers.rst
+  :ref:`Documentation/process/submitting-patches.rst ` 와 
:ref:`Documentation/process/submitting-drivers.rst `
 이 파일들은 성공적으로 패치를 만들고 보내는 법을 다음의 내용들로
 굉장히 상세히 설명하고 있다(그러나 다음으로 한정되진 않는다).
 
@@ -138,7 +137,7 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 
 http://linux.yyz.us/patch-format.html
 
-   Documentation/process/stable-api-nonsense.rst
+   :ref:`Documentation/process/stable-api-nonsense.rst `
 이 문서는 의도적으로 커널이 불변하는 API를 갖지 않도록 결정한
 이유를 설명하며 다음과 같은 것들을 포함한다.
 
@@ -150,12 +149,12 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 리눅스로 전향하는 사람들에게는 매우 중요하다.
 
 
-  Documentation/admin-guide/security-bugs.rst
+  :ref:`Documentation/admin-guide/security-bugs.rst `
 여러분들이 리눅스 커널의 보안 문제를 발견했다고 생각한다면 이 문서에
 나온 단계에 따라서 커널 개발자들에게 알리고 그 문제를 해결할 수 있도록
 도와 달라.
 
-  Documentation/process/management-style.rst
+  :ref:`Documentation/process/management-style.rst `
 이 문서는 리눅스 커널 메인테이너들이 그들의 방법론에 녹아 있는
 정신을 어떻게 공유하고 운영하는지를 설명한다. 이것은 커널 개발에 입문하는
 모든 사람들(또는 커널 개발에 작은 호기심이라도 있는 사람들)이
@@ -163,17 +162,17 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 독특한 행동에 관하여 흔히 있는 오해들과 혼란들을 해소하고 있기
 때문이다.
 
-  Documentation/process/stable-kernel-rules.rst
+  :ref:`Documentation/process/stable_kernel_rules.rst `
 이 문서는 안정적인 커널 배포가 이루어지는 규칙을 설명하고 있으며
 여러분들이 이러한 배포들 중 하나에 변경을 하길 원한다면
 무엇을 해야 하는지를 설명한다.
 
-  Documentation/process/kernel-docs.rst
+  :ref:`Documentation/process/kernel-docs.rst `
 커널 개발에 관계된 외부 문서의 리스트이다. 커널 내의 포함된 문서들
 중에 여러분이 찾고 싶은 문서를 발견하지 못할 경우 이 리스트를
 살펴보라.
 
-  Documentation/process/applying-patches.rst
+  :ref:`Documentation/process/applying-patches.rst `
 패치가 무엇이며 그것을 커널의 다른 개발 브랜치들에 어떻게
 적용하는지에 관하여 자세히 설명하고 있는 좋은 입문서이다.
 
-- 
2.10.0

--
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] Documentation/sphinx: prevent generation of .pyc files in the source tree

[Jani Nikula]

Use PYTHONDONTWRITEBYTECODE=1 to prevent python from creating .pyc files
in the source tree. Python 3.2 has a __pycache__ scheme [1], but before
that the only alternative seems to be to copy the source files to the
build tree to ensure the .pyc files are created there too. Just prevent
.pyc file generation for simplicity.

Considering the small amount of python code to compile (assuming sphinx
itself has .pyc around), the impact on build is neglible.

[1] 
http://stackoverflow.com/questions/3522079/changing-the-directory-where-pyc-files-are-created

References: 
http://lkml.kernel.org/r/camuhmdvxqph7-9xj+ye_pgoa+-fe0969cskoehyh3uubycr...@mail.gmail.com
Reported-by: Geert Uytterhoeven 
Signed-off-by: Jani Nikula 
---
 Documentation/Makefile.sphinx | 1 +
 1 file changed, 1 insertion(+)

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 \
-- 
2.1.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 v2 00/12] Fix and update HOWTO Korean translation

[SeongJae Park]

This patchset applies ReST conversion effort for HOWTO document to its Korean
translation.  It also contains fixup of trivial nitpicks in the document and
the translation.

Changes from v1:
- Rebased on next-20161028
  The base version contains commit 186128f75392 ("docs-rst: add documents to
  development-process")

SeongJae Park (12):
  Documentation/process/howto: Mark subsection in suggested format
  ko_KR/HOWTO: Fix a typo: s/Linux Torvalds/Linus Torvalds
  ko_KR/HOWTO: Fix subtitles style
  ko_KR/HOWTO: Update obsolete link to bugzilla faq
  ko_KR/HOWTO: Convert to ReST notation
  ko_KR/HOWTO: Add cross-references to other documents
  ko_KR/HOWTO: Update information about generating documentation
  ko_KR/HOWTO: Improve some markups to make it visually better
  ko_KR/HOWTO: Adjust external link references
  ko_KR/HOWTO: Clean up bare :: lines
  ko_KR/HOWTO: Add whitespace between URL and text
  ko_KR/HOWTO: Mark subsection in suggested format

 Documentation/ko_KR/HOWTO   | 162 ++--
 Documentation/process/howto.rst |  15 ++--
 2 files changed, 117 insertions(+), 60 deletions(-)

-- 
2.10.0

--
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 v2 01/12] Documentation/process/howto: Mark subsection in suggested format

[SeongJae Park]

`Specific guidelines for the kernel documentation` section of
`kernel-documentation.rst` suggests to use ``~`` for subsection but
subsections in HOWTO is not marked in the format.  This commit marks
them in the format.

Signed-off-by: SeongJae Park 
---
 Documentation/process/howto.rst | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 3f66a1980726..449ca1f199f4 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -254,7 +254,8 @@ branches.  These different branches are:
   - the 4.x -next kernel tree for integration tests
 
 4.x kernel tree
--
+~~~
+
 4.x kernels are maintained by Linus Torvalds, and can be found on
 https://kernel.org in the pub/linux/kernel/v4.x/ directory.  Its development
 process is as follows:
@@ -289,7 +290,8 @@ mailing list about kernel releases:
preconceived timeline."*
 
 4.x.y -stable kernel tree
--
+~
+
 Kernels with 3-part versions are -stable kernels. They contain
 relatively small and critical fixes for security problems or significant
 regressions discovered in a given 4.x kernel.
@@ -312,7 +314,8 @@ documents what kinds of changes are acceptable for the 
-stable tree, and
 how the release process works.
 
 4.x -git patches
-
+
+
 These are daily snapshots of Linus' kernel tree which are managed in a
 git repository (hence the name.) These patches are usually released
 daily and represent the current state of Linus' tree.  They are more
@@ -320,7 +323,8 @@ experimental than -rc kernels since they are generated 
automatically
 without even a cursory glance to see if they are sane.
 
 Subsystem Specific kernel trees and patches

+~~~
+
 The maintainers of the various kernel subsystems --- and also many
 kernel subsystem developers --- expose their current state of
 development in source repositories.  That way, others can see what is
@@ -344,7 +348,8 @@ accepted, or rejected.  Most of these patchwork sites are 
listed at
 https://patchwork.kernel.org/.
 
 4.x -next kernel tree for integration tests

+~~~
+
 Before updates from subsystem trees are merged into the mainline 4.x
 tree, they need to be integration-tested.  For this purpose, a special
 testing repository exists into which virtually all subsystem trees are
-- 
2.10.0

--
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 v2 07/12] ko_KR/HOWTO: Update information about generating documentation

[SeongJae Park]

This commit applies commit 43fb67a5258c ("Documentation/HOWTO: update
information about generating documentation") to Korean translation.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 30 ++
 1 file changed, 22 insertions(+), 8 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 7f0b4e66e6c2..918be41b75de 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -176,21 +176,35 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 패치가 무엇이며 그것을 커널의 다른 개발 브랜치들에 어떻게
 적용하는지에 관하여 자세히 설명하고 있는 좋은 입문서이다.
 
-커널은 소스 코드 그 자체에서 자동적으로 만들어질 수 있는 많은 문서들을
-가지고 있다. 이것은 커널 내의 API에 대한 모든 설명, 그리고 락킹을
-올바르게 처리하는 법에 관한 규칙을 포함하고 있다. 이 문서는
-Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, HTML,
-그리고 man 페이지들로 다음과 같이 실행하여 만들어 진다.
+커널은 소스 코드 그 자체에서 또는 이것과 같은 ReStructuredText 마크업 (ReST) 을
+통해 자동적으로 만들어질 수 있는 많은 문서들을 가지고 있다. 이것은 커널 내의
+API에 대한 모든 설명, 그리고 락킹을 올바르게 처리하는 법에 관한 규칙을 포함하고
+있다.
+
+모든 그런 문서들은 커널 소스 디렉토리에서 다음 커맨드를 실행하는 것을 통해 PDF
+나 HTML 의 형태로 만들어질 수 있다.
 
 ::
 
  make pdfdocs
- make psdocs
  make htmldocs
- make mandocs
 
-각각의 명령을 메인 커널 소스 디렉토리로부터 실행한다.
+ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된다.  해당
+문서들은 다음의 커맨드를 사용하면 LaTeX 이나 ePub 로도 만들어질 수 있다:
+
+::
+
+ make latexdocs
+ make epubdocs
+
+현재, ReST 로의 변환이 진행중인, DocBook 으로 쓰인 문서들이 존재한다. 그런
+문서들은 Documentation/DocBook/ 디렉토리 안에 생성될 것이고 다음 커맨드를 통해
+Postscript 나 man page 로도 만들어질 수 있다:
+
+::
 
+ make psdocs
+ make mandocs
 
 커널 개발자가 되는 것
 -
-- 
2.10.0

--
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 v2 11/12] ko_KR/HOWTO: Add whitespace between URL and text

[SeongJae Park]

Because few sentences has no whitespace between URL and text, few
document viewers fail to properly parse the URL from it.  This commit
adds whitespace between them to fix the problem.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 2a91ebd8391f..9aea302ed8c3 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -260,7 +260,7 @@ Postscript 나 man page 로도 만들어질 수 있다::
 
 4.x 커널 트리
 -
-4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org의
+4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org 의
 pub/linux/kernel/v4.x/ 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
 
   - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
@@ -377,8 +377,8 @@ https://bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그
 점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은
 다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다.
 
-이미 보고된 버그 리포트들을 가지고 작업하기 위해서 https://bugzilla.kernel.org를
-참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면
+이미 보고된 버그 리포트들을 가지고 작업하기 위해서 https://bugzilla.kernel.org
+를 참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면
 bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다)
 bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다)
 에 등록하면 된다.
-- 
2.10.0

--
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 v2 05/12] ko_KR/HOWTO: Convert to ReST notation

[SeongJae Park]

This commit applies commit 022e04d6f555 ("Documentation/HOWTO: convert
to ReST notation") to Korean translation and fix a trivial ReST build
failure problem.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 55 ---
 1 file changed, 52 insertions(+), 3 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index f3348ef68bbd..c2a3f1719753 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -9,17 +9,20 @@ read for non English (read: korean) speakers and is not 
intended as
 a fork. So if you have any comments or updates for this file please
 try to update the original English file first.
 
-==
+--
+
 이 문서는
 Documentation/process/howto.rst
 의 한글 번역입니다.
 
 역자： 김민찬 
 감수： 이제이미 
-==
+
+--
+
 
 어떻게 리눅스 커널 개발을 하는가
--
+
 
 이 문서는 커널 개발에 있어 가장 중요한 문서이다. 이 문서는
 리눅스 커널 개발자가 되는 법과 리눅스 커널 개발 커뮤니티와 일하는
@@ -46,6 +49,7 @@ Documentation/process/howto.rst
 어셈블리(특정 아키텍쳐)는 잘 알아야 할 필요는 없다.
 다음의 참고서적들은 기본에 충실한 C 교육이나 수년간의 경험에 견주지는
 못하지만 적어도 참고 용도로는 좋을 것이다
+
  - "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]
@@ -79,6 +83,7 @@ Documentation/process/howto.rst
 그들의 말에 의지해서는 안된다.
 
 GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
+
 http://www.gnu.org/licenses/gpl-faq.html
 
 
@@ -93,6 +98,7 @@ GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
 mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 
 다음은 커널 소스 트리에 있는 읽어야 할 파일들의 리스트이다.
+
   README
 이 파일은 리눅스 커널에 관하여 간단한 배경 설명과 커널을 설정하고
 빌드하기 위해 필요한 것을 설명한다. 커널에 입문하는 사람들은 여기서
@@ -112,26 +118,34 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
   Documentation/process/submitting-drivers.rst
 이 파일들은 성공적으로 패치를 만들고 보내는 법을 다음의 내용들로
 굉장히 상세히 설명하고 있다(그러나 다음으로 한정되진 않는다).
+
- Email 내용들
- Email 양식
- 그것을 누구에게 보낼지
+
 이러한 규칙들을 따르는 것이 성공(역자주: 패치가 받아들여 지는 것)을
 보장하진 않는다(왜냐하면 모든 패치들은 내용과 스타일에 관하여
 면밀히 검토되기 때문이다). 그러나 규칙을 따르지 않는다면 거의
 성공하지도 못할 것이다.
 
 올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다.
+
 "The Perfect Patch"
+
 http://www.ozlabs.org/~akpm/stuff/tpp.txt
+
 "Linux kernel patch submission format"
+
 http://linux.yyz.us/patch-format.html
 
Documentation/process/stable-api-nonsense.rst
 이 문서는 의도적으로 커널이 불변하는 API를 갖지 않도록 결정한
 이유를 설명하며 다음과 같은 것들을 포함한다.
+
- 서브시스템 shim-layer(호환성을 위해?)
- 운영체제들간의 드라이버 이식성
- 커널 소스 트리내에 빠른 변화를 늦추는 것(또는 빠른 변화를 막는 것)
+
 이 문서는 리눅스 개발 철학을 이해하는데 필수적이며 다른 운영체제에서
 리눅스로 전향하는 사람들에게는 매우 중요하다.
 
@@ -168,10 +182,14 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 올바르게 처리하는 법에 관한 규칙을 포함하고 있다. 이 문서는
 Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, HTML,
 그리고 man 페이지들로 다음과 같이 실행하여 만들어 진다.
+
+::
+
  make pdfdocs
  make psdocs
  make htmldocs
  make mandocs
+
 각각의 명령을 메인 커널 소스 디렉토리로부터 실행한다.
 
 
@@ -180,7 +198,9 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 
 여러분이 리눅스 커널 개발에 관하여 아무것도 모른다면 Linux KernelNewbies
 프로젝트를 봐야 한다.
+
 http://kernelnewbies.org
+
 그곳은 거의 모든 종류의 기본적인 커널 개발 질문들(질문하기 전에 먼저
 아카이브를 찾아봐라. 과거에 이미 답변되었을 수도 있다)을 할 수 있는 도움이
 될만한 메일링 리스트가 있다. 또한 실시간으로 질문 할 수 있는 IRC 채널도
@@ -192,7 +212,9 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 
 여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수
 있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라.
+
http://kernelnewbies.org/KernelJanitors
+
 그곳은 시작하기에 훌륭한 장소이다. 그곳은 리눅스 커널 소스 트리내에
 간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이
 프로젝트를 대표하는 개발자들과 일하면서 자신의 패치를 리눅스 커널 트리에
@@ -204,6 +226,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 올바른 포맷으로 포장하는데 도움이 필요하다면 그러한 문제를 돕기 위해
 만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며
 다음에서 참조할 수 있다.
+
  http://selenic.com/mailman/listinfo/kernel-mentors
 
 리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게
@@ -213,6 +236,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 것은 Linux Cross-Reference project이며 그것은 자기 참조 방식이며
 소스코드를 인덱스된 웹 페이지들의 형태로 보여준다. 최신의 멋진 커널
 코드 저장소는 다음을 통하여 참조할 수 있다.
+
   http://lxr.free-electrons.com/
 
 
@@ -222,6 +246,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 리눅스 커널 개발 프로세스는 현재 몇몇 다른 메인 커널 "브랜치들"과
 서브시스템에 특화된 커널 브랜치들로 구성된다. 몇몇 다른 메인
 브랜치들은 다음과 같다.
+
   - main 4.x 커널 트리
   - 4.x.y - 안정된 커널 트리
   - 4.x -git 커널 패치들
@@ -232,6 +257,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 -
 4.x 커널들은 Linus Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v4.x/
 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
+
   - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
 메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
 몇 주 동안 -next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데
@@ -255,6 +281,9 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
 
 커널 

[PATCH v2 12/12] ko_KR/HOWTO: Mark subsection in suggested format

[SeongJae Park]

`Specific guidelines for the kernel documentation` section of
`kernel-documentation.rst` suggests to use ``~`` for subsection but
subsections in HOWTO is not marked in the format.  This commit marks
them in the format.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 9aea302ed8c3..3b0c15b277e0 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -259,7 +259,8 @@ Postscript 나 man page 로도 만들어질 수 있다::
   - 4.x - 통합 테스트를 위한 next 커널 트리
 
 4.x 커널 트리
--
+~
+
 4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org 의
 pub/linux/kernel/v4.x/ 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
 
@@ -292,7 +293,8 @@ Andrew Morton의 글이 있다.
  배포되는 것은 아니기 때문이다."*
 
 4.x.y - 안정 커널 트리
---
+~~
+
 3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 4.x
 커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을
 포함한다.
@@ -311,14 +313,16 @@ Andrew Morton의 글이 있다.
 진행되는지를 설명한다.
 
 4.x -git 패치들

+~~~
+
 git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의
 커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며
 Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도
 살펴보지 않고 자동적으로 생성된 것이므로 -rc 커널들 보다도 더 실험적이다.
 
 서브시스템 커널 트리들과 패치들

+~~~
+
 다양한 커널 서브시스템의 메인테이너들 --- 그리고 많은 커널 서브시스템 개발자들
 --- 은 그들의 현재 개발 상태를 소스 저장소로 노출한다. 이를 통해 다른 사람들도
 커널의 다른 영역에 어떤 변화가 이루어지고 있는지 알 수 있다. 급속히 개발이
-- 
2.10.0

--
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 v2 10/12] ko_KR/HOWTO: Clean up bare :: lines

[SeongJae Park]

This commit applies commit 1b49ecf2f3be ("docs: Clean up bare :: lines")
to Korean translation.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 8f3a1a68758d..2a91ebd8391f 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -180,26 +180,20 @@ API에 대한 모든 설명, 그리고 락킹을 올바르게 처리하는 법
 있다.
 
 모든 그런 문서들은 커널 소스 디렉토리에서 다음 커맨드를 실행하는 것을 통해 PDF
-나 HTML 의 형태로 만들어질 수 있다.
-
-::
+나 HTML 의 형태로 만들어질 수 있다::
 
  make pdfdocs
  make htmldocs
 
 ReST 마크업을 사용하는 문서들은 Documentation/output 에 생성된다.  해당
-문서들은 다음의 커맨드를 사용하면 LaTeX 이나 ePub 로도 만들어질 수 있다:
-
-::
+문서들은 다음의 커맨드를 사용하면 LaTeX 이나 ePub 로도 만들어질 수 있다::
 
  make latexdocs
  make epubdocs
 
 현재, ReST 로의 변환이 진행중인, DocBook 으로 쓰인 문서들이 존재한다. 그런
 문서들은 Documentation/DocBook/ 디렉토리 안에 생성될 것이고 다음 커맨드를 통해
-Postscript 나 man page 로도 만들어질 수 있다:
-
-::
+Postscript 나 man page 로도 만들어질 수 있다::
 
  make psdocs
  make mandocs
-- 
2.10.0

--
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 v2 09/12] ko_KR/HOWTO: Adjust external link references

[SeongJae Park]

This commit appplies commit f1eebe92c265 ("Documentation/HOWTO: adjust
external link references") to Korean translation.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 39 ++-
 1 file changed, 18 insertions(+), 21 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 4df8ef3d0ffe..8f3a1a68758d 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -84,7 +84,7 @@ Documentation/process/howto.rst
 
 GPL에 관한 잦은 질문들과 답변들은 다음을 참조하라.
 
-http://www.gnu.org/licenses/gpl-faq.html
+https://www.gnu.org/licenses/gpl-faq.html
 
 
 문서
@@ -130,11 +130,9 @@ mtk.manpa...@gmail.com의 메인테이너에게 보낼 것을 권장한다.
 올바른 패치들을 만드는 법에 관한 훌륭한 다른 문서들이 있다.
 
 "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/process/stable-api-nonsense.rst `
@@ -212,7 +210,7 @@ Postscript 나 man page 로도 만들어질 수 있다:
 여러분이 리눅스 커널 개발에 관하여 아무것도 모른다면 Linux KernelNewbies
 프로젝트를 봐야 한다.
 
-http://kernelnewbies.org
+https://kernelnewbies.org
 
 그곳은 거의 모든 종류의 기본적인 커널 개발 질문들(질문하기 전에 먼저
 아카이브를 찾아봐라. 과거에 이미 답변되었을 수도 있다)을 할 수 있는 도움이
@@ -226,7 +224,7 @@ Postscript 나 man page 로도 만들어질 수 있다:
 여러분이 어디서 시작해야 할진 모르지만 커널 개발 커뮤니티에 참여할 수
 있는 일들을 찾길 원한다면 리눅스 커널 Janitor 프로젝트를 살펴봐라.
 
-   http://kernelnewbies.org/KernelJanitors
+   https://kernelnewbies.org/KernelJanitors
 
 그곳은 시작하기에 훌륭한 장소이다. 그곳은 리눅스 커널 소스 트리내에
 간단히 정리되고 수정될 수 있는 문제들에 관하여 설명한다. 여러분은 이
@@ -240,7 +238,7 @@ Postscript 나 man page 로도 만들어질 수 있다:
 만들어진 kernel-mentors 프로젝트가 있다. 그곳은 메일링 리스트이며
 다음에서 참조할 수 있다.
 
- http://selenic.com/mailman/listinfo/kernel-mentors
+ https://selenic.com/mailman/listinfo/kernel-mentors
 
 리눅스 커널 코드에 실제 변경을 하기 전에 반드시 그 코드가 어떻게
 동작하는지 이해하고 있어야 한다. 코드를 분석하기 위하여 특정한 툴의
@@ -268,14 +266,14 @@ Postscript 나 man page 로도 만들어질 수 있다:
 
 4.x 커널 트리
 -
-4.x 커널들은 Linus Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v4.x/
-디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
+4.x 커널들은 Linus Torvalds가 관리하며 https://kernel.org의
+pub/linux/kernel/v4.x/ 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
 
   - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
 메인테이너들은 큰 diff들을 Linus에게 제출할 수 있다. 대개 이 패치들은
 몇 주 동안 -next 커널내에 이미 있었던 것들이다. 큰 변경들을 제출하는 데
 선호되는 방법은  git(커널의 소스 관리 툴, 더 많은 정보들은
-http://git-scm.com/ 에서 참조할 수 있다)를 사용하는 것이지만 순수한
+https://git-scm.com/ 에서 참조할 수 있다)를 사용하는 것이지만 순수한
 패치파일의 형식으로 보내는 것도 무관하다.
   - 2주 후에 -rc1 커널이 배포되며 지금부터는 전체 커널의 안정성에 영향을
 미칠수 있는 새로운 기능들을 포함하지 않는 패치들만이 추가될 수 있다.
@@ -337,14 +335,14 @@ Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인
 
 대부분의 이러한 저장소는 git 트리지만, git이 아닌 SCM으로 관리되거나, quilt
 시리즈로 제공되는 패치들도 존재한다. 이러한 서브시스템 저장소들은 MAINTAINERS
-파일에 나열되어 있다. 대부분은 http://git.kernel.org 에서 볼 수 있다.
+파일에 나열되어 있다. 대부분은 https://git.kernel.org 에서 볼 수 있다.
 
 제안된 패치는 서브시스템 트리에 커밋되기 전에 메일링 리스트를 통해
 리뷰된다(아래의 관련 섹션을 참고하기 바란다). 일부 커널 서브시스템의 경우, 이
 리뷰 프로세스는 patchwork라는 도구를 통해 추적된다. patchwork은 등록된 패치와
 패치에 대한 코멘트, 패치의 버전을 볼 수 있는 웹 인터페이스를 제공하고,
 메인테이너는 패치를 리뷰 중, 리뷰 통과, 또는 반려됨으로 표시할 수 있다.
-대부분의 이러한 patchwork 사이트는 http://patchwork.kernel.org/ 또는
+대부분의 이러한 patchwork 사이트는 https://patchwork.kernel.org/ 또는
 http://patchwork.ozlabs.org/ 에 나열되어 있다.
 
 4.x - 통합 테스트를 위한 next 커널 트리
@@ -353,7 +351,7 @@ http://patchwork.ozlabs.org/ 에 나열되어 있다.
 테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의
 매일 받아가는 특수한 테스트 저장소가 존재한다:
 
-   http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
+   https://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git
 
 이런 식으로, -next 커널을 통해 다음 머지 기간에 메인라인 커널에 어떤 변경이
 가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 -next 커널에서 테스트를
@@ -363,11 +361,11 @@ http://patchwork.ozlabs.org/ 에 나열되어 있다.
 버그 보고
 -
 
-bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 곳이다.
-사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 권장한다.
-kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
+https://bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는
+곳이다. 사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을
+권장한다.  kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
 
-http://bugzilla.kernel.org/page.cgi?id=faq.html
+https://bugzilla.kernel.org/page.cgi?id=faq.html
 
 메인 커널 소스 디렉토리에 있는 admin-guide/reporting-bugs.rst 파일은 커널 버그라고 생각되는
 것을 보고하는 방법에 관한 좋은 템플릿이며 문제를 추적하기 위해서 커널
@@ -385,13 +383,14 @@ kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
 점수를 얻을 수 있는 가장 좋은 방법중의 하나이다. 왜냐하면 많은 사람들은
 다른 사람들의 버그들을 수정하기 위하여 시간을 낭비하지 않기 때문이다.
 
-이미 보고된 버그 리포트들을 가지고 작업하기 위해서 http://bugzilla.kernel.org를
+이미 보고된 버그 리포트들을 가지고 작업하기 위해서 https://bugzilla.kernel.org를
 참조하라. 여러분이 앞으로 생겨날 버그 리포트들의 조언자가 되길 원한다면
 bugme-new 메일링 리스트나(새로운 버그 리포트들만이 이곳에서 메일로 전해진다)
 bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메일로 전해진다)
 에 등록하면 된다.
 
   https://lists.linux-foundation.org/mailman/listinfo/bugme-new
+
   https://lists.linux-foundation.org/mailman/listinfo/bugme-janitors
 
 
@@ -615,8 +614,6 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
 http://www.ozlabs.org/~akpm/stuff/tpp.txt
 

[PATCH v2 08/12] ko_KR/HOWTO: Improve some markups to make it visually better

[SeongJae Park]

This commit applies commit 34fed7e7e0e5 ("Documentation/HOWTO: improve
some markups to make it visually better") to Korean translation.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 918be41b75de..4df8ef3d0ffe 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -295,11 +295,9 @@ Postscript 나 man page 로도 만들어질 수 있다:
 커널 배포에 있어서 언급할만한 가치가 있는 리눅스 커널 메일링 리스트의
 Andrew Morton의 글이 있다.
 
-::
-
-"커널이 언제 배포될지는 아무도 모른다. 왜냐하면 배포는 알려진
+*"커널이 언제 배포될지는 아무도 모른다. 왜냐하면 배포는 알려진
  버그의 상황에 따라 배포되는 것이지 미리정해 놓은 시간에 따라
- 배포되는 것은 아니기 때문이다."
+ 배포되는 것은 아니기 때문이다."*
 
 4.x.y - 안정 커널 트리
 --
@@ -569,16 +567,14 @@ Pat이라는 이름을 가진 여자가 있을 수도 있는 것이다. 리눅
 
 여기에 커널 개발자 Al Viro의 이야기가 있다.
 
-::
-
-"학생의 수학 숙제를 채점하는 선생님을 생각해보라. 선생님은 학생들이
+*"학생의 수학 숙제를 채점하는 선생님을 생각해보라. 선생님은 학생들이
 답을 얻을때까지 겪은 시행착오를 보길 원하지 않는다. 선생님들은
 간결하고 가장 뛰어난 답을 보길 원한다. 훌륭한 학생은 이것을 알고
-마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다.
+마지막으로 답을 얻기 전 중간 과정들을 제출하진 않는다.*
 
-커널 개발도 마찬가지이다. 메인테이너들과 검토하는 사람들은 문제를
+*커널 개발도 마찬가지이다. 메인테이너들과 검토하는 사람들은 문제를
 풀어나가는 과정속에 숨겨진 과정을 보길 원하진 않는다. 그들은
-간결하고 멋진 답을 보길 원한다."
+간결하고 멋진 답을 보길 원한다."*
 
 커뮤니티와 협력하며 뛰어난 답을 찾는 것과 여러분들의 끝마치지 못한 작업들
 사이에 균형을 유지해야 하는 것은 어려울지도 모른다. 그러므로 프로세스의
-- 
2.10.0

--
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 v2 03/12] ko_KR/HOWTO: Fix subtitles style

[SeongJae Park]

This commit fixes subtitles style.  It aligns them with their header,
adjust blank lines between them properly.

Signed-off-by: SeongJae Park 
---
 Documentation/ko_KR/HOWTO | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/Documentation/ko_KR/HOWTO b/Documentation/ko_KR/HOWTO
index 4f5778dfeed2..1a5d7a8d66be 100644
--- a/Documentation/ko_KR/HOWTO
+++ b/Documentation/ko_KR/HOWTO
@@ -229,8 +229,7 @@ Documentation/DocBook/ 디렉토리 내에서 만들어지며 PDF, Postscript, H
   - 4.x - 통합 테스트를 위한 next 커널 트리
 
 4.x 커널 트리

-
+-
 4.x 커널들은 Linus Torvalds가 관리하며 kernel.org의 pub/linux/kernel/v4.x/
 디렉토리에서 참조될 수 있다.개발 프로세스는 다음과 같다.
   - 새로운 커널이 배포되자마자 2주의 시간이 주어진다. 이 기간동은
@@ -261,8 +260,7 @@ Andrew Morton의 글이 있다.
  배포되는 것은 아니기 때문이다."
 
 4.x.y - 안정 커널 트리
-
-
+--
 3 자리 숫자로 이루어진 버젼의 커널들은 -stable 커널들이다. 그것들은 4.x
 커널에서 발견된 큰 회귀들이나 보안 문제들 중 비교적 작고 중요한 수정들을
 포함한다.
@@ -280,9 +278,8 @@ Andrew Morton의 글이 있다.
 종류의 변경들이 -stable 트리로 들어왔는지와 배포 프로세스가 어떻게
 진행되는지를 설명한다.
 
-
 4.x -git 패치들
---
+---
 git 저장소(그러므로 -git이라는 이름이 붙음)에는 날마다 관리되는 Linus의
 커널 트리의 snapshot 들이 있다. 이 패치들은 일반적으로 날마다 배포되며
 Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인지 조금도
@@ -311,7 +308,7 @@ Linus의 트리의 현재 상태를 나타낸다. 이 패치들은 정상적인
 http://patchwork.ozlabs.org/ 에 나열되어 있다.
 
 4.x - 통합 테스트를 위한 next 커널 트리
--
+---
 서브시스템 트리들의 변경사항들은 mainline 4.x 트리로 들어오기 전에 통합
 테스트를 거쳐야 한다. 이런 목적으로, 모든 서브시스템 트리의 변경사항을 거의
 매일 받아가는 특수한 테스트 저장소가 존재한다:
@@ -321,8 +318,10 @@ http://patchwork.ozlabs.org/ 에 나열되어 있다.
 가해질 것인지 간략히 알 수 있다. 모험심 강한 테스터라면 -next 커널에서 테스트를
 수행하는 것도 좋을 것이다.
 
+
 버그 보고
 -
+
 bugzilla.kernel.org는 리눅스 커널 개발자들이 커널의 버그를 추적하는 곳이다.
 사용자들은 발견한 모든 버그들을 보고하기 위하여 이 툴을 사용할 것을 권장한다.
 kernel bugzilla를 사용하는 자세한 방법은 다음을 참조하라.
@@ -405,7 +404,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
 
 
 커뮤니티와 협력하는 법
-
+--
 
 커널 커뮤니티의 목적은 가능한한 가장 좋은 커널을 제공하는 것이다. 여러분이
 받아들여질 패치를 제출하게 되면 그 패치의 기술적인 이점으로 검토될 것이다.
@@ -443,7 +442,7 @@ bugme-janitor 메일링 리스트(bugzilla에 모든 변화들이 여기서 메
 
 
 커널 커뮤니티와 기업 조직간의 차이점
--
+
 커널 커뮤니티는 가장 전통적인 회사의 개발 환경과는 다르다. 여기에 여러분들의
 문제를 피하기 위한 목록이 있다.
   여러분들이 제안한 변경들에 관하여 말할 때 좋은 것들 :
-- 
2.10.0

--
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: make pdfdocs fails with v4.9-rc3

[Mauro Carvalho Chehab]

Em Mon, 31 Oct 2016 13:15:24 -0600
Jonathan Corbet  escreveu:

> On Mon, 31 Oct 2016 11:51:20 -0700
> Jim Davis  wrote:
> 
> > Running make pdfdocs on a Ubuntu 16.04 system fails with
> > 
> > Makefile:58: recipe for target 'media.pdf' failed
> > make[2]: *** [media.pdf] Error 1
> > Documentation/Makefile.sphinx:79: recipe for target 'pdfdocs' failed
> > make[1]: *** [pdfdocs] Error 2
> > Makefile:1442: recipe for target 'pdfdocs' failed
> > make: *** [pdfdocs] Error 2
> > 
> > It's not clear from the voluminous (>5MB) output from make pdfdocs
> > exactly which stage is failing, and there are some pdf files produced
> > in output/latex.  
> 
> Hmm, so it does.  It comes down to this:
> 
> ! LaTeX Error: \DUrole undefined.
> 
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H   for immediate help.
>  ...  
>   
> l.195 \renewcommand*{\DUrole}
>  [2]{ #2 }
> 
> Where the offending command is in Documentation/media/index.rst.  Mauro,
> got an idea for what's going on there?

Sphinx is really a poor solution when it comes to PDF output. In this
specific case, this is meant to fix a problem with cross-references.

What happens is that Sphinx 1.4.6 (and later?) define reference names without
being properly escaped. So, for some references, it causes the PDF output
to crash. That happens at one of the DVB header files, if I remember well.

This commit restores the sphinx 1.2.x behavior:

commit e61a39baf74dddb6cd236147bd19b55c10188d78
Author: Mauro Carvalho Chehab 
Date:   Sun Aug 21 15:14:57 2016 -0300

[media] index.rst: Fix LaTeX error in interactive mode on Sphinx 1.4.x

The Sphinx 1.4.x definition for \DUrole is:

\providecommand*{\DUrole}[2]{%
  \ifcsname DUrole#1\endcsname%
\csname DUrole#1\endcsname{#2}%
  \else% backwards compatibility: try \docutilsrole#1{#2}
\ifcsname docutilsrole#1\endcsname%
  \csname docutilsrole#1\endcsname{#2}%
\else%
  #2%
\fi%
  \fi%
}

This is broken when it is used inside a \begin{alltt} block.
So, replace it by just "#2", as this won't cause troubles, and
it is one of the fallback methods for it.

Signed-off-by: Mauro Carvalho Chehab 

At the time I tested, it worked fine, but maybe it is redefining the
\DUrole too late.

Maybe we could move it to LaTeX preamble instead. Please check if this
untested patch fixes the issue.

diff --git a/Documentation/conf.py b/Documentation/conf.py
index d9bad21dd427..ae7450c0a6e0 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -329,6 +329,9 @@ latex_elements = {
% To allow adjusting table sizes
\\usepackage{adjustbox}
 
+   % Fix reference escape troubles with Sphinx 1.4.x
+   \renewcommand*{\DUrole}[2]{ #2 }
+
  '''
 }
 
diff --git a/Documentation/media/index.rst b/Documentation/media/index.rst
index e347a3e7bdef..7f8f0af620ce 100644
--- a/Documentation/media/index.rst
+++ b/Documentation/media/index.rst
@@ -1,11 +1,6 @@
 Linux Media Subsystem Documentation
 ===
 
-.. Sphinx 1.4.x has a definition for DUrole that doesn't work on alltt blocks
-.. raw:: latex
-
-   \renewcommand*{\DUrole}[2]{ #2 }
-
 Contents:
 
 .. toctree::



Cheers,
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

make cleandocs missing files with v4.9-rc3

[Jim Davis]

On my Ubuntu 16.04 system, make htmldocs works just fine (hurrah!) but
make cleandocs misses a fair number of files:

  HTMLDocumentation/DocBook/index.html
jim@krebstar:~/linux-rc$ make cleandocs
jim@krebstar:~/linux-rc$ git status
HEAD detached at v4.9-rc3
nothing to commit, working directory clean
jim@krebstar:~/linux-rc$ git clean -fdx
Removing Documentation/DocBook/.alsa-driver-api.xml.cmd
Removing Documentation/DocBook/.crypto-API.xml.cmd
Removing Documentation/DocBook/.debugobjects.xml.cmd
Removing Documentation/DocBook/.deviceiobook.xml.cmd
Removing Documentation/DocBook/.filesystems.xml.cmd
Removing Documentation/DocBook/.gadget.xml.cmd
Removing Documentation/DocBook/.genericirq.xml.cmd
Removing Documentation/DocBook/.iio.xml.cmd
Removing Documentation/DocBook/.kernel-api.xml.cmd
Removing Documentation/DocBook/.kernel-hacking.xml.cmd
Removing Documentation/DocBook/.kernel-locking.xml.cmd
Removing Documentation/DocBook/.kgdb.xml.cmd
Removing Documentation/DocBook/.libata.xml.cmd
Removing Documentation/DocBook/.librs.xml.cmd
Removing Documentation/DocBook/.lsm.xml.cmd
Removing Documentation/DocBook/.mtdnand.xml.cmd
Removing Documentation/DocBook/.networking.xml.cmd
Removing Documentation/DocBook/.rapidio.xml.cmd
Removing Documentation/DocBook/.regulator.xml.cmd
Removing Documentation/DocBook/.s390-drivers.xml.cmd
Removing Documentation/DocBook/.scsi.xml.cmd
Removing Documentation/DocBook/.sh.xml.cmd
Removing Documentation/DocBook/.tracepoint.xml.cmd
Removing Documentation/DocBook/.uio-howto.xml.cmd
Removing Documentation/DocBook/.usb.xml.cmd
Removing Documentation/DocBook/.w1.xml.cmd
Removing Documentation/DocBook/.writing-an-alsa-driver.xml.cmd
Removing Documentation/DocBook/.writing_musb_glue_layer.xml.cmd
Removing Documentation/DocBook/.writing_usb_driver.xml.cmd
Removing Documentation/DocBook/.z8530book.xml.cmd
Removing Documentation/sphinx/cdomain.pyc
Removing Documentation/sphinx/kernel-doc.pyc
Removing Documentation/sphinx/kernel_include.pyc
Removing Documentation/sphinx/load_config.pyc
Removing Documentation/sphinx/rstFlatTable.pyc
Removing scripts/.check-lc_ctype.cmd
Removing scripts/.docproc.cmd
Removing scripts/basic/.fixdep.cmd
Removing scripts/basic/fixdep
Removing scripts/check-lc_ctype
Removing scripts/docproc


-- 
Jim
--
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

make psdocs fails with v4.9-rc3

[Jim Davis]

Running make psdocs on a Ubuntu 16.04 system fails with

Documentation/DocBook/Makefile:142: recipe for target
'Documentation/DocBook/kernel-hacking.ps' failed
make[1]: *** [Documentation/DocBook/kernel-hacking.ps] Error 9
Makefile:1442: recipe for target 'psdocs' failed
make: *** [psdocs] Error 2

possibly due to

[15.0.21]
! Undefined control sequence.
\Hy@wrapper@babel ...set@display@protect \edef \x
  {#2}\@onelevel@sanitize \x...
l.8111 \endHeadPar{}
\endSeq{}\Node%
! Argument of \HyWrap@hyper@anchorstart has an extra }.

\par
l.8111 \endHeadPar{}
\endSeq{}\Node%
Runaway argument?

Though I wonder how many people still build the psdocs version...


-- 
Jim
--
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: make pdfdocs fails with v4.9-rc3

[Jonathan Corbet]

On Mon, 31 Oct 2016 11:51:20 -0700
Jim Davis  wrote:

> Running make pdfdocs on a Ubuntu 16.04 system fails with
> 
> Makefile:58: recipe for target 'media.pdf' failed
> make[2]: *** [media.pdf] Error 1
> Documentation/Makefile.sphinx:79: recipe for target 'pdfdocs' failed
> make[1]: *** [pdfdocs] Error 2
> Makefile:1442: recipe for target 'pdfdocs' failed
> make: *** [pdfdocs] Error 2
> 
> It's not clear from the voluminous (>5MB) output from make pdfdocs
> exactly which stage is failing, and there are some pdf files produced
> in output/latex.

Hmm, so it does.  It comes down to this:

! LaTeX Error: \DUrole undefined.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H   for immediate help.
 ...  
  
l.195 \renewcommand*{\DUrole}
 [2]{ #2 }

Where the offending command is in Documentation/media/index.rst.  Mauro,
got an idea for what's going on there?

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

make pdfdocs fails with v4.9-rc3

[Jim Davis]

Running make pdfdocs on a Ubuntu 16.04 system fails with

Makefile:58: recipe for target 'media.pdf' failed
make[2]: *** [media.pdf] Error 1
Documentation/Makefile.sphinx:79: recipe for target 'pdfdocs' failed
make[1]: *** [pdfdocs] Error 2
Makefile:1442: recipe for target 'pdfdocs' failed
make: *** [pdfdocs] Error 2

It's not clear from the voluminous (>5MB) output from make pdfdocs
exactly which stage is failing, and there are some pdf files produced
in output/latex.

This is with sphinx, rst2pdf, and texlive installed from the Ubuntu
repositories.

-- 
Jim
--
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/2] swiotlb: Add swiotlb=nobounce debug option

[Geert Uytterhoeven]

Hi Robin,

On Mon, Oct 31, 2016 at 6:41 PM, Robin Murphy  wrote:
> On 31/10/16 15:45, Geert Uytterhoeven wrote:
>> On architectures like arm64, swiotlb is tied intimately to the core
>> architecture DMA support. In addition, ZONE_DMA cannot be disabled.
>
> To be fair, that only takes a single-character change in
> arch/arm64/Kconfig - in fact, I'm amused to see my stupid patch to fix
> the build if you do just that (86a5906e4d1d) has just had its birthday ;)

Unfortunately it's not that simple. Using a small patch (based on Mark Salter's
"arm64: make CONFIG_ZONE_DMA user settable"), it appears to work. However:
  - With CONFIG_ZONE_DMA=n and memory present over 4G, swiotlb_init() is
not called.
This will lead to a NULL pointer dereference later, when
dma_map_single() calls into an unitialized SWIOTLB subsystem through
swiotlb_tbl_map_single().
  - With CONFIG_ZONE_DMA=n and no memory present over 4G, swiotlb_init()
is also not called, but RAVB works fine.
Disabling CONFIG_SWIOTLB is non-trivial, as the arm64 DMA core always
uses swiotlb_dma_ops, and its operations depend a lot on SWIOTLB
helpers.

So that's why I went for this option.

>> To aid debugging and catch devices not supporting DMA to memory outside
>> the 32-bit address space, add a kernel command line option
>> "swiotlb=nobounce", which disables the use of bounce buffers.
>> If specified, trying to map memory that cannot be used with DMA will
>> fail, and a warning will be printed (rate-limited).
>
> This rationale seems questionable - how useful is non-deterministic
> behaviour for debugging really? What you end up with is DMA sometimes
> working or sometimes not depending on whether allocations happen to
> naturally fall below 4GB or not. In my experience, that in itself can be
> a pain in the arse to debug.

It immediately triggered for me, though:

rcar-dmac e730.dma-controller: Cannot do DMA to address
0x00067a9b7000
ravb e680.ethernet: Cannot do DMA to address 0x00067aa07780

> Most of the things you might then do to make things more deterministic
> again (like making the default DMA mask tiny or hacking out all the
> system's 32-bit addressable RAM) are also generally sufficient to make
> DMA fail earlier and make this option moot anyway. What's the specific
> use case motivating this?

My use case is finding which drivers and DMA engines do not support 64-bit
memory. There's more info in my series "[PATCH/RFC 0/5] arm64: r8a7796: 64-bit
Memory and Ethernet Prototype"
(https://www.mail-archive.com/linux-renesas-soc@vger.kernel.org/msg08393.html)

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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/2] swiotlb: Add swiotlb=nobounce debug option

[Konrad Rzeszutek Wilk]

On Mon, Oct 31, 2016 at 04:45:04PM +0100, Geert Uytterhoeven wrote:
> On architectures like arm64, swiotlb is tied intimately to the core
> architecture DMA support. In addition, ZONE_DMA cannot be disabled.
> 
> To aid debugging and catch devices not supporting DMA to memory outside
> the 32-bit address space, add a kernel command line option
> "swiotlb=nobounce", which disables the use of bounce buffers.
> If specified, trying to map memory that cannot be used with DMA will
> fail, and a warning will be printed (rate-limited).

I would make the 'swiotlb_force' an enum. And then instead of this
being 'nobounce' just do the inverse of 'force', that is the
'noforce' would trigger this no bounce effect.

So:

enum {
NORMAL, /* Default - depending on the hardware DMA mask and 
such. */
FORCE,  /* swiotlb=force */
NO_FORCE,   /* swiotlb=noforce */
}
> 
> Note that io_tlb_nslabs is set to 1, which is the minimal supported
> value.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/kernel-parameters.txt |  3 ++-
>  lib/swiotlb.c   | 19 +--
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 37babf91f2cb6de2..38556cdceabaf087 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -3998,10 +3998,11 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   it if 0 is given (See 
> Documentation/cgroup-v1/memory.txt)
>  
>   swiotlb=[ARM,IA-64,PPC,MIPS,X86]
> - Format: {  | force }
> + Format: {  | force | nobounce }
>-- Number of I/O TLB slabs
>   force -- force using of bounce buffers even if they
>wouldn't be automatically used by the kernel
> + nobounce -- Never use bounce buffers (for debugging)
>  
>   switches=   [HW,M68k]
>  
> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> index 6ce764410ae475cc..4550e6b516c2a4c0 100644
> --- a/lib/swiotlb.c
> +++ b/lib/swiotlb.c
> @@ -54,6 +54,7 @@
>  #define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
>  
>  int swiotlb_force;
> +static int swiotlb_nobounce;
>  
>  /*
>   * Used to do a quick range check in swiotlb_tbl_unmap_single and
> @@ -106,8 +107,12 @@
>   }
>   if (*str == ',')
>   ++str;
> - if (!strcmp(str, "force"))
> + if (!strcmp(str, "force")) {
>   swiotlb_force = 1;
> + } else if (!strcmp(str, "nobounce")) {
> + swiotlb_nobounce = 1;
> + io_tlb_nslabs = 1;
> + }
>  
>   return 0;
>  }
> @@ -541,8 +546,15 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
>  map_single(struct device *hwdev, phys_addr_t phys, size_t size,
>  enum dma_data_direction dir)
>  {
> - dma_addr_t start_dma_addr = phys_to_dma(hwdev, io_tlb_start);
> + dma_addr_t start_dma_addr;
> +
> + if (swiotlb_nobounce) {
> + dev_warn_ratelimited(hwdev, "Cannot do DMA to address %pa\n",
> +  );
> + return SWIOTLB_MAP_ERROR;
> + }
>  
> + start_dma_addr = phys_to_dma(hwdev, io_tlb_start);
>   return swiotlb_tbl_map_single(hwdev, start_dma_addr, phys, size, dir);
>  }
>  
> @@ -707,6 +719,9 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
> phys_addr_t tlb_addr,
>  swiotlb_full(struct device *dev, size_t size, enum dma_data_direction dir,
>int do_panic)
>  {
> + if (swiotlb_nobounce)
> + return;
> +
>   /*
>* Ran out of IOMMU space for this operation. This is very bad.
>* Unfortunately the drivers cannot handle this operation properly.
> -- 
> 1.9.1
> 
--
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/2] swiotlb: Add swiotlb=nobounce debug option

[Robin Murphy]

Hi Geert,

On 31/10/16 15:45, Geert Uytterhoeven wrote:
> On architectures like arm64, swiotlb is tied intimately to the core
> architecture DMA support. In addition, ZONE_DMA cannot be disabled.

To be fair, that only takes a single-character change in
arch/arm64/Kconfig - in fact, I'm amused to see my stupid patch to fix
the build if you do just that (86a5906e4d1d) has just had its birthday ;)

> To aid debugging and catch devices not supporting DMA to memory outside
> the 32-bit address space, add a kernel command line option
> "swiotlb=nobounce", which disables the use of bounce buffers.
> If specified, trying to map memory that cannot be used with DMA will
> fail, and a warning will be printed (rate-limited).

This rationale seems questionable - how useful is non-deterministic
behaviour for debugging really? What you end up with is DMA sometimes
working or sometimes not depending on whether allocations happen to
naturally fall below 4GB or not. In my experience, that in itself can be
a pain in the arse to debug.

Most of the things you might then do to make things more deterministic
again (like making the default DMA mask tiny or hacking out all the
system's 32-bit addressable RAM) are also generally sufficient to make
DMA fail earlier and make this option moot anyway. What's the specific
use case motivating this?

Robin.

> Note that io_tlb_nslabs is set to 1, which is the minimal supported
> value.
> 
> Signed-off-by: Geert Uytterhoeven 
> ---
>  Documentation/kernel-parameters.txt |  3 ++-
>  lib/swiotlb.c   | 19 +--
>  2 files changed, 19 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/kernel-parameters.txt 
> b/Documentation/kernel-parameters.txt
> index 37babf91f2cb6de2..38556cdceabaf087 100644
> --- a/Documentation/kernel-parameters.txt
> +++ b/Documentation/kernel-parameters.txt
> @@ -3998,10 +3998,11 @@ bytes respectively. Such letter suffixes can also be 
> entirely omitted.
>   it if 0 is given (See 
> Documentation/cgroup-v1/memory.txt)
>  
>   swiotlb=[ARM,IA-64,PPC,MIPS,X86]
> - Format: {  | force }
> + Format: {  | force | nobounce }
>-- Number of I/O TLB slabs
>   force -- force using of bounce buffers even if they
>wouldn't be automatically used by the kernel
> + nobounce -- Never use bounce buffers (for debugging)
>  
>   switches=   [HW,M68k]
>  
> diff --git a/lib/swiotlb.c b/lib/swiotlb.c
> index 6ce764410ae475cc..4550e6b516c2a4c0 100644
> --- a/lib/swiotlb.c
> +++ b/lib/swiotlb.c
> @@ -54,6 +54,7 @@
>  #define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
>  
>  int swiotlb_force;
> +static int swiotlb_nobounce;
>  
>  /*
>   * Used to do a quick range check in swiotlb_tbl_unmap_single and
> @@ -106,8 +107,12 @@
>   }
>   if (*str == ',')
>   ++str;
> - if (!strcmp(str, "force"))
> + if (!strcmp(str, "force")) {
>   swiotlb_force = 1;
> + } else if (!strcmp(str, "nobounce")) {
> + swiotlb_nobounce = 1;
> + io_tlb_nslabs = 1;
> + }
>  
>   return 0;
>  }
> @@ -541,8 +546,15 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
>  map_single(struct device *hwdev, phys_addr_t phys, size_t size,
>  enum dma_data_direction dir)
>  {
> - dma_addr_t start_dma_addr = phys_to_dma(hwdev, io_tlb_start);
> + dma_addr_t start_dma_addr;
> +
> + if (swiotlb_nobounce) {
> + dev_warn_ratelimited(hwdev, "Cannot do DMA to address %pa\n",
> +  );
> + return SWIOTLB_MAP_ERROR;
> + }
>  
> + start_dma_addr = phys_to_dma(hwdev, io_tlb_start);
>   return swiotlb_tbl_map_single(hwdev, start_dma_addr, phys, size, dir);
>  }
>  
> @@ -707,6 +719,9 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
> phys_addr_t tlb_addr,
>  swiotlb_full(struct device *dev, size_t size, enum dma_data_direction dir,
>int do_panic)
>  {
> + if (swiotlb_nobounce)
> + return;
> +
>   /*
>* Ran out of IOMMU space for this operation. This is very bad.
>* Unfortunately the drivers cannot handle this operation properly.
> 

--
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/2] swiotlb: Rate-limit printing when running out of SW-IOMMU space

[Sergei Shtylyov]

On 10/31/2016 06:45 PM, Geert Uytterhoeven wrote:


If the system runs out of SW-IOMMU space, changes are high successive


   s/changes/chances/?


requests will fail, too, flooding the kernel log.  This is true
especially for streaming DMA, which is typically used repeatedly outside
the driver's initialization routine.  Add rate-limiting to fix this.

While at it, get rid of the open-coded dev_name() handling by using the
appropriate dev_err_*() variant.

Signed-off-by: Geert Uytterhoeven 

[...]

MBR, Sergei

--
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/2] swiotlb: Rate-limit printing and 64-bit memory debugging

[Geert Uytterhoeven]

Hi Konrad, Jon,

This patch series contains two improvements for the SWIOTLB subsystem.

The first patch adds rate-limiting to an error message, to avoid
flooding the kernel log.
The second patch adds a kernel command line option to aid debugging when
developing support for DMA to memory outside the 32-bit address space.

Thanks for your comments!

Geert Uytterhoeven (2):
  swiotlb: Rate-limit printing when running out of SW-IOMMU space
  swiotlb: Add swiotlb=nobounce debug option

 Documentation/kernel-parameters.txt |  3 ++-
 lib/swiotlb.c   | 23 +++
 2 files changed, 21 insertions(+), 5 deletions(-)

-- 
1.9.1

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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 2/2] swiotlb: Add swiotlb=nobounce debug option

[Geert Uytterhoeven]

On architectures like arm64, swiotlb is tied intimately to the core
architecture DMA support. In addition, ZONE_DMA cannot be disabled.

To aid debugging and catch devices not supporting DMA to memory outside
the 32-bit address space, add a kernel command line option
"swiotlb=nobounce", which disables the use of bounce buffers.
If specified, trying to map memory that cannot be used with DMA will
fail, and a warning will be printed (rate-limited).

Note that io_tlb_nslabs is set to 1, which is the minimal supported
value.

Signed-off-by: Geert Uytterhoeven 
---
 Documentation/kernel-parameters.txt |  3 ++-
 lib/swiotlb.c   | 19 +--
 2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 37babf91f2cb6de2..38556cdceabaf087 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3998,10 +3998,11 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
it if 0 is given (See 
Documentation/cgroup-v1/memory.txt)
 
swiotlb=[ARM,IA-64,PPC,MIPS,X86]
-   Format: {  | force }
+   Format: {  | force | nobounce }
 -- Number of I/O TLB slabs
force -- force using of bounce buffers even if they
 wouldn't be automatically used by the kernel
+   nobounce -- Never use bounce buffers (for debugging)
 
switches=   [HW,M68k]
 
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 6ce764410ae475cc..4550e6b516c2a4c0 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -54,6 +54,7 @@
 #define IO_TLB_MIN_SLABS ((1<<20) >> IO_TLB_SHIFT)
 
 int swiotlb_force;
+static int swiotlb_nobounce;
 
 /*
  * Used to do a quick range check in swiotlb_tbl_unmap_single and
@@ -106,8 +107,12 @@
}
if (*str == ',')
++str;
-   if (!strcmp(str, "force"))
+   if (!strcmp(str, "force")) {
swiotlb_force = 1;
+   } else if (!strcmp(str, "nobounce")) {
+   swiotlb_nobounce = 1;
+   io_tlb_nslabs = 1;
+   }
 
return 0;
 }
@@ -541,8 +546,15 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
 map_single(struct device *hwdev, phys_addr_t phys, size_t size,
   enum dma_data_direction dir)
 {
-   dma_addr_t start_dma_addr = phys_to_dma(hwdev, io_tlb_start);
+   dma_addr_t start_dma_addr;
+
+   if (swiotlb_nobounce) {
+   dev_warn_ratelimited(hwdev, "Cannot do DMA to address %pa\n",
+);
+   return SWIOTLB_MAP_ERROR;
+   }
 
+   start_dma_addr = phys_to_dma(hwdev, io_tlb_start);
return swiotlb_tbl_map_single(hwdev, start_dma_addr, phys, size, dir);
 }
 
@@ -707,6 +719,9 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
phys_addr_t tlb_addr,
 swiotlb_full(struct device *dev, size_t size, enum dma_data_direction dir,
 int do_panic)
 {
+   if (swiotlb_nobounce)
+   return;
+
/*
 * Ran out of IOMMU space for this operation. This is very bad.
 * Unfortunately the drivers cannot handle this operation properly.
-- 
1.9.1

--
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 1/2] swiotlb: Rate-limit printing when running out of SW-IOMMU space

[Geert Uytterhoeven]

If the system runs out of SW-IOMMU space, changes are high successive
requests will fail, too, flooding the kernel log.  This is true
especially for streaming DMA, which is typically used repeatedly outside
the driver's initialization routine.  Add rate-limiting to fix this.

While at it, get rid of the open-coded dev_name() handling by using the
appropriate dev_err_*() variant.

Signed-off-by: Geert Uytterhoeven 
---
 lib/swiotlb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 22e13a0e19d76a2b..6ce764410ae475cc 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -714,8 +714,8 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
phys_addr_t tlb_addr,
 * When the mapping is small enough return a static buffer to limit
 * the damage, or panic when the transfer is too big.
 */
-   printk(KERN_ERR "DMA: Out of SW-IOMMU space for %zu bytes at "
-  "device %s\n", size, dev ? dev_name(dev) : "?");
+   dev_err_ratelimited(dev, "DMA: Out of SW-IOMMU space for %zu bytes\n",
+   size);
 
if (size <= io_tlb_overflow || !do_panic)
return;
-- 
1.9.1

--
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: Was: Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

[Markus Heiser]

Am 28.10.2016 um 14:37 schrieb Mauro Carvalho Chehab :

> On a separate matter: any news with regards to the man pages
> Sphinx extension?

I have one extension active in my POC:

  https://h2626237.stratoserver.net/kernel/

follow the "man" links. There you will also find my efforts
in pdf and the "HTML rendered kernel-doc comments" from
source tree.

sorry, media not yet ;-)

FYI: I rent this server this weekend / no yet certified and the
domain might change next time / I will inform you.

-- 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 0/3] Add the Documentation/ABI to the admin-guide

[Mauro Carvalho Chehab]

Em Mon, 31 Oct 2016 10:24:36 +0200
Jani Nikula  escreveu:

> On Fri, 28 Oct 2016, Mauro Carvalho Chehab  wrote:
> > This patch series fix a few issues on some ABI files that violate what's
> > written at Documentation/ABI/README, and add a parser, using
> > kernel-cmd, to produce an ABI book. A parsed version of it can be found at:
> >
> > https://mchehab.fedorapeople.org/kernel_docs/admin-guide/abi.html  
> 
> So here's a constructive counter proposal:
> 
> How about using the perl script you wrote to convert the ABI
> documentation into reStructuredText format, committing the changes, and
> maintaining ABI documentation in reStructuredText going forward?

> This would keep the Sphinx build simple and allow richer ABI
> documentation than the preformatted text blocks in above URL. I think
> this would be a worthy improvement in the documentation. The format of
> the ABI documentation is not ABI... we have no obligation to keep it in
> some old ad hoc text format.
> 
> Perhaps there's value in having a "database" format. But using rst does
> not preclude us from formatting the documentation in a way that's also
> parseable using a script. For example, use uniform header styles, use
> definition lists with fixed terms, etc.

Greg is the ABI maintainer, so he has the final word.

IMHO, keeping ABI as a database is better, as we can display only
the stuff we want. Right now, we're omitting several things, like
the ABI maintainer, the Kernel where it entering, etc, as such kind
of info is only relevant for someone touching the ABI, and not for
a system admin.

By having it as a database, it is easy to filter out undesired
stuff and sort the ABI whatever we like. Also, by having it defined
as lots of small per-subsystem files, it is easy to maintain, as
the risk of conflicts on merges is small.

That not talking about the practical aspects of such huge change.
It will be as hard as changing from kernel-doc markup to something
else: it will be really hard to merge such huge patchset, touching on
all subsystems.

Cheers,
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

Re: [PATCH 0/3] Add the Documentation/ABI to the admin-guide

[Jani Nikula]

On Fri, 28 Oct 2016, Mauro Carvalho Chehab  wrote:
> This patch series fix a few issues on some ABI files that violate what's
> written at Documentation/ABI/README, and add a parser, using
> kernel-cmd, to produce an ABI book. A parsed version of it can be found at:
>
>   https://mchehab.fedorapeople.org/kernel_docs/admin-guide/abi.html

So here's a constructive counter proposal:

How about using the perl script you wrote to convert the ABI
documentation into reStructuredText format, committing the changes, and
maintaining ABI documentation in reStructuredText going forward?

This would keep the Sphinx build simple and allow richer ABI
documentation than the preformatted text blocks in above URL. I think
this would be a worthy improvement in the documentation. The format of
the ABI documentation is not ABI... we have no obligation to keep it in
some old ad hoc text format.

Perhaps there's value in having a "database" format. But using rst does
not preclude us from formatting the documentation in a way that's also
parseable using a script. For example, use uniform header styles, use
definition lists with fixed terms, etc.

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 2/3] hwmon: (mcp3021) add devicetree bindings documentation

[Rob Herring]

On Fri, Oct 28, 2016 at 12:33:44AM +0200, Clemens Gruber wrote:
> Document the devicetree bindings for the Microchip MCP3021/3221.
> 
> Signed-off-by: Clemens Gruber 
> ---
>  Documentation/devicetree/bindings/hwmon/mcp3021.txt | 21 
> +
>  1 file changed, 21 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/hwmon/mcp3021.txt

Acked-by: Rob Herring 
--
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