Re: [RESEND PATCH v2 4/4] usb: doc: add document for USB3 debug port usage

[Lu Baolu]

Hi Jani,

On 10/19/2016 03:48 PM, Jani Nikula wrote:
> On Wed, 19 Oct 2016, Lu Baolu  wrote:
>> Add Documentation/usb/usb3-debug-port.txt. This document includes
>> the user guide for USB3 debug port.
> If you're adding completely new files, please at least consider writing
> them in reStructuredText, so we can easily bolt them to the Sphinx
> build. Just a few tweaks would be required, comments inline below.

Thanks for your comments. I will refactor my document according
to your comments.

By the way, are there any tools that I can use to check the document
format?

Best regards,
Lu Baolu

>
> BR,
> Jani.
>
>> Cc: linux-doc@vger.kernel.org
>> Signed-off-by: Lu Baolu 
>> ---
>>  Documentation/usb/usb3-debug-port.txt | 87 
>> +++
>>  1 file changed, 87 insertions(+)
>>  create mode 100644 Documentation/usb/usb3-debug-port.txt
>>
>> diff --git a/Documentation/usb/usb3-debug-port.txt 
>> b/Documentation/usb/usb3-debug-port.txt
>> new file mode 100644
>> index 000..df5ce27
>> --- /dev/null
>> +++ b/Documentation/usb/usb3-debug-port.txt
>> @@ -0,0 +1,87 @@
>> +  USB3 debug port
> Make that a title with
>
> ===
> USB3 debug port
> ===
>
>> +
>> + Lu Baolu 
> :Author: Lu Baolu 
>
> Although git blame will give a more accurate idea after the file's been
> edited by others.
>
>> +
>> +  Last-updated: October 2016
> :Date: October 2016
>
> Again, this is what git does.
>
>> +
>> +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.
> Add :: at the end of previous line to make the below indented block
> preformatted text. Ditto for the others.
>
>> +
>> +"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.
> Again, add :: and indent the below lines by some spaces.
>
>> +
>> +# 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.
> Same here. Alternatively, if you do
>
> .. code-block:: sh
>
> and indent the block, you'll get syntax highlighting in the output.
>
>> +
>> += start of bash scripts =
>> +#!/bin/bash
>> +
>> +while true ; do
>> +while [ ! -d /sys/class/tty/ttyUSB0 ] ; do
>> + 

Re: The downside of math::

[Mauro Carvalho Chehab]

Em Wed, 19 Oct 2016 22:26:18 -0200
Mauro Carvalho Chehab  escreveu:

> Hi Jon,
> 
> Em Wed, 19 Oct 2016 17:02:46 -0600
> Jonathan Corbet  escreveu:
> 
> > Hey, Mauro,
> > 
> > So I was a little surprised to find that the htmldocs build now breaks on
> > one of my machines due to a lack of LaTeX.

Btw, I was also surprised when I discovered such dependency myself... I
even commented about that at the media mailing list, as I didn't
understood why make htmldocs were not working on my server:

https://www.mail-archive.com/search?l=linux-me...@vger.kernel.org=subject:%22Re%5C%3A+%5C%5BPATCH+0%5C%2F9%5C%5D+Prepare+Sphinx+to+build+media+PDF+books%22=newest=1

Regrds,
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: The downside of math::

[Mauro Carvalho Chehab]

Hi Jon,

Em Wed, 19 Oct 2016 17:02:46 -0600
Jonathan Corbet  escreveu:

> Hey, Mauro,
> 
> So I was a little surprised to find that the htmldocs build now breaks on
> one of my machines due to a lack of LaTeX.  A bit of digging turned up
> the culprit: commit b7ff94df5628 (pixfmt-007.rst: use Sphinx math::
> expressions).  The math:: directive uses LaTeX to process the math markup. 
> 
> What this means is that said commit has made LaTeX a dependency for the
> htmldocs build.  I'm not convinced that this is a good idea; that's a
> massive dependency to add for web builds that, ostensibly, should not
> need it.  Certainly we shouldn't add it without discussion...:)
> 
> So I'll ask: how important to you is the math extension, and is there any
> way we could get you your fancy math in a way that doesn't force
> everybody to install the whole LaTeX package set?

As you know, image handling comes with complex expressions ;) We have lots
of expressions at the media documentation, but right now, the complex ones
that require ReST math:: directive are related to colorspace conversions:

https://linuxtv.org/downloads/v4l-dvb-apis-new/uapi/v4l/pixfmt-007.html

On DocBook, we used to represent the same expressions using several
tricks, like superscript and used some UTF-8 math symbols. As
expected, they didn't look nice there:

https://linuxtv.org/downloads/v4l-dvb-apis/ch02s06.html

The initial conversion of those math expressions from DocBook make
them look even worse. It also broke PDF generation, because LaTeX
fonts were not compatible with UTF-8 math symbols (such issue was
latter solved with xelatex - for some other remaining UTF-8 symbols).

That's said, we're currently discussing APIs for codecs on media.
Eventually, their documentation could come with a way more complex
expressions than what we have so far.

So, I really prefer not removing math support.

>From what's written at Sphinx documentation:
http://www.sphinx-doc.org/en/stable/ext/math.html

It sounded to me that only sphinx.ext.imgmath extension is capable of
providing math on all outputs, by generating an image like this one,
using LaTeX:

https://linuxtv.org/downloads/v4l-dvb-apis-new/_images/math/ae0a381368b3837b88b1308aaccedcd9a438757a.png

There are two alternative math extensions that handle math::, but both
seem to be specific for HTML, as they use JavaScript. Also, Sphinx
require using either one of the extension, so we cannot enable both,
one for PDF and the other one for HTML.

Perhaps there are some extensions that would allow using something else,
like this one:
https://bitbucket.org/coh/sphinx-contrib-mathml/overview

But I haven't test. So, I'm not sure:
- if it would work;
- if it would be portable to both HTML and PDF outputs;
- if it won't require an even weirder toolbox.

Thanks,
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 v2 3/3] Documentation/workqueue.txt: convert to ReST markup

[Tejun Heo]

On Wed, Oct 19, 2016 at 08:38:39PM +0200, Silvio Fricke wrote:
> This patch add a "misc" documentation section and add the workqueue
> documentation to this section.
> 
> Signed-off-by: Silvio Fricke 

Looks good to me.  How should these patches be routed?  Should I take
2 and 3 through wq/for-4.10?

Thanks.

-- 
tejun
--
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 2/3] workqueue: kerneldocify workqueue_attrs

[Silvio Fricke]

Only formating changes.

Signed-off-by: Silvio Fricke 
---
 include/linux/workqueue.h | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/include/linux/workqueue.h b/include/linux/workqueue.h
index fc6e221..afc1d46 100644
--- a/include/linux/workqueue.h
+++ b/include/linux/workqueue.h
@@ -119,18 +119,30 @@ struct delayed_work {
int cpu;
 };
 
-/*
- * A struct for workqueue attributes.  This can be used to change
- * attributes of an unbound workqueue.
+/**
+ * struct workqueue_attrs - A struct for workqueue attributes.
  *
- * Unlike other fields, ->no_numa isn't a property of a worker_pool.  It
- * only modifies how apply_workqueue_attrs() select pools and thus doesn't
- * participate in pool hash calculations or equality comparisons.
+ * This can be used to change attributes of an unbound workqueue.
  */
 struct workqueue_attrs {
-   int nice;   /* nice level */
-   cpumask_var_t   cpumask;/* allowed CPUs */
-   boolno_numa;/* disable NUMA affinity */
+   /**
+* @nice: nice level
+*/
+   int nice;
+
+   /**
+* @cpumask: allowed CPUs
+*/
+   cpumask_var_t cpumask;
+
+   /**
+* @no_numa: disable NUMA affinity
+*
+* Unlike other fields, ``no_numa`` isn't a property of a worker_pool. 
It
+* only modifies how :c:func:`apply_workqueue_attrs` select pools and 
thus
+* doesn't participate in pool hash calculations or equality 
comparisons.
+*/
+   bool no_numa;
 };
 
 static inline struct delayed_work *to_delayed_work(struct work_struct *work)
-- 
git-series 0.8.10
--
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 0/3] workqueue documentation reformatted

[Silvio Fricke]

Hi,

Thanks Jani for reviewing of my first attempt.

v1 -> v2:
* s/kernel-doc: $type_param takes care that this parameter is used for
  formatting too.
* i/l/workqueue.h: inlining of documentation for workqueue_attrs struct members
* D/workqueue.rst: Every author get a own :AUTHOR:-label
* D/index.rst: add misc section and add link to workqueue documentation

Best regards
Silvio

Silvio Fricke (3):
  kernel-doc: better parsing of named variable arguments
  workqueue: kerneldocify workqueue_attrs
  Documentation/workqueue.txt: convert to ReST markup

 Documentation/index.rst  |   1 +-
 Documentation/misc/conf.py   |   5 +-
 Documentation/misc/index.rst |  17 ++-
 Documentation/workqueue.rst  | 394 -
 Documentation/workqueue.txt  | 388 +---
 MAINTAINERS  |   2 +-
 include/linux/workqueue.h|  34 ++-
 scripts/kernel-doc   |   8 +-
 8 files changed, 447 insertions(+), 402 deletions(-)
 create mode 100644 Documentation/misc/conf.py
 create mode 100644 Documentation/misc/index.rst
 create mode 100644 Documentation/workqueue.rst
 delete mode 100644 Documentation/workqueue.txt

base-commit: 893e2c5c9fedeccf89653b0ad17df69e88dbd707
-- 
git-series 0.8.10
--
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 1/3] kernel-doc: better parsing of named variable arguments

[Silvio Fricke]

Without this patch we get warnings for named variable arguments.

warning: No description found for parameter '...'
warning: Excess function parameter 'args' description in 
'alloc_ordered_workqueue'

Signed-off-by: Silvio Fricke 
---
 scripts/kernel-doc | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 93721f3..e10378f 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -204,6 +204,7 @@ EOF
 
 ## init lots of data
 
+
 my $errors = 0;
 my $warnings = 0;
 my $anon_struct_union = 0;
@@ -211,7 +212,7 @@ my $anon_struct_union = 0;
 # match expressions used to find embedded type information
 my $type_constant = '\%([-_\w]+)';
 my $type_func = '(\w+)\(\)';
-my $type_param = '\@(\w+)';
+my $type_param = '\@(\w+(\.\.\.)?)';
 my $type_fp_param = '\@(\w+)\(\)';  # Special RST handling for func ptr params
 my $type_struct = '\&((struct\s*)*[_\w]+)';
 my $type_struct_xml = '\\((struct\s*)*[_\w]+)';
@@ -2353,7 +2354,10 @@ sub push_parameter($$$) {
 
if ($type eq "" && $param =~ /\.\.\.$/)
{
-   $param = "...";
+   if (!$param =~ /\w\.\.\.$/) {
+ # handles unnamed variable parameters
+ $param = "...";
+   }
if (!defined $parameterdescs{$param} || $parameterdescs{$param} eq 
"") {
$parameterdescs{$param} = "variable arguments";
}
-- 
git-series 0.8.10
--
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: [RESEND PATCH v2 4/4] usb: doc: add document for USB3 debug port usage

[Jani Nikula]

On Wed, 19 Oct 2016, Lu Baolu  wrote:
> Add Documentation/usb/usb3-debug-port.txt. This document includes
> the user guide for USB3 debug port.

If you're adding completely new files, please at least consider writing
them in reStructuredText, so we can easily bolt them to the Sphinx
build. Just a few tweaks would be required, comments inline below.

BR,
Jani.

>
> Cc: linux-doc@vger.kernel.org
> Signed-off-by: Lu Baolu 
> ---
>  Documentation/usb/usb3-debug-port.txt | 87 
> +++
>  1 file changed, 87 insertions(+)
>  create mode 100644 Documentation/usb/usb3-debug-port.txt
>
> diff --git a/Documentation/usb/usb3-debug-port.txt 
> b/Documentation/usb/usb3-debug-port.txt
> new file mode 100644
> index 000..df5ce27
> --- /dev/null
> +++ b/Documentation/usb/usb3-debug-port.txt
> @@ -0,0 +1,87 @@
> +  USB3 debug port

Make that a title with

===
USB3 debug port
===

> +
> + Lu Baolu 

:Author: Lu Baolu 

Although git blame will give a more accurate idea after the file's been
edited by others.

> +
> +  Last-updated: October 2016

:Date: October 2016

Again, this is what git does.

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

Add :: at the end of previous line to make the below indented block
preformatted text. Ditto for the others.

> +
> +"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.

Again, add :: and indent the below lines by some spaces.

> +
> +# 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.

Same here. Alternatively, if you do

.. code-block:: sh

and indent the block, you'll get syntax highlighting in the output.

> +
> += 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.

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

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

[Peter Zijlstra]

On Tue, Oct 18, 2016 at 05:15:01PM -0400, Daniel Micay wrote:
> It's also worth noting that fine-grained control via a scoped mechanism
> would likely only be used to implement *more restrictions* on Android,
> not to make the feature less aggressive.

> It's desirable for perf events to be disabled by default for non-root
> across the board on Android.

Right, but this is Android. The knob seems to now also live in Debian
(and derived) distros. And there it is utter crap.

It completely defeats having perf for a fairly large segment of
corporate developers who do not get to have root on their own machines
(which is stupid policy but whatever).

It similarly defeats development of self profiling JITs and whatnot.

A capability would allow people to run perf (or another sanctioned
binary), even though in general they cannot do sys_perf_event_open().
--
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 00/32] Create an User's manual and improve development-process book

[Mauro Carvalho Chehab]

Em Tue, 18 Oct 2016 17:25:42 -0600
Jonathan Corbet  escreveu:

> On Tue, 18 Oct 2016 08:20:18 -0200
> Mauro Carvalho Chehab  wrote:
> 
> > > While at it, how about unifying some of the FilenamesInCamelCase,
> > > filenames-with-hyphens, and filenames_with_underscores too...? To at
> > > least move things towards just one of them within one directory.
> > 
> > Sure, let's do it. I would just keep README as README.rst , as people
> > are more used to see readme files on upercases.
> > 
> > For the rest, what's your preference?
> > 
> > - FooBar.rst
> > - foo_bar.rst
> > - foo-bar.rst
> > 
> > My personal preference is for "foo-bar".  
> 
> I guess that would be mine too.  CamelCase is not generally all that
> popular in kernel space.  On one hand, I worry about further renaming
> files that we're already moving; on the other, if we're going to do it, I
> guess this would be the time, when people will have to look for them
> anyway...

It was also somewhat painful to do the renames, but IMHO, it is for
a greater good. Anyway, the version 2 of this series, submitted
yesterday, is doing the renames to foo-bar.rst. I merged all renames
on a single patch, per book. So, if we still need to change something,
there will be no need on touching on the ReST conversion patches.

There were a few issues that I noticed on the version 2, but I
wait for a couple of days before sending the final version, in order
to give people more time to review.

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

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

[Peter Zijlstra]

On Wed, Oct 19, 2016 at 07:26:02AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Oct 19, 2016 at 12:01:26PM +0200, Peter Zijlstra escreveu:
> > On Tue, Oct 18, 2016 at 05:15:01PM -0400, Daniel Micay wrote:
> > > It's also worth noting that fine-grained control via a scoped mechanism
> > > would likely only be used to implement *more restrictions* on Android,
> > > not to make the feature less aggressive.
>  
> > > It's desirable for perf events to be disabled by default for non-root
> > > across the board on Android.
>  
> > Right, but this is Android. The knob seems to now also live in Debian
> > (and derived) distros. And there it is utter crap.
>  
> > It completely defeats having perf for a fairly large segment of
> > corporate developers who do not get to have root on their own machines
> > (which is stupid policy but whatever).
>  
> > It similarly defeats development of self profiling JITs and whatnot.
>  
> > A capability would allow people to run perf (or another sanctioned
> > binary), even though in general they cannot do sys_perf_event_open().
> 
> But self profiling JITs would be useful for non-developers, on Android
> (anywhere, really), and for that it would require being able to at
> least, well, self profile, using sys_perf_event_open() by a normal
> process, limited to profiling itself, no?
> 
> This not being possible, self profiling will use some other means, its
> like sys_perf_event_open() never existed for them.

Right, so with capabilities, we could grant the binary the capability to
use sys_perf_event_open().

That would still leave developers of said JIT in a tight spot, because
there'd be no way to set the capability on their freshly compiled
binary.

They'd have to be granted the capability to the user, using pam_cap.
Which would involve corp. IT doing something sensible, ergo, this'll
never happen :-(.


--
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 v20 10/10] fpga-manager: Add Socfpga Arria10 support

[atull]

On Tue, 18 Oct 2016, Moritz Fischer wrote:

> On Mon, Oct 17, 2016 at 11:09:41AM -0500, Alan Tull wrote:
> > Add low level driver to support reprogramming FPGAs for Altera
> > SoCFPGA Arria10.
> > 
> > Signed-off-by: Alan Tull 
> 
> Reviewed-by: Moritz Fischer 

> > +
> > +MODULE_AUTHOR("Alan Tull ");
> > +MODULE_DESCRIPTION("SoCFPGA Arria10 FPGA Manager");
> > +MODULE_LICENSE("GPL v2");
> > -- 
> > 2.10.1
> > 
> 
> Looking good,
> 
> Moritz
> 

Hi Moritz,

Thanks!

Alan
--
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: sequence diagrams in rst documentation

[Johannes Berg]

On Tue, 2016-10-18 at 17:52 -0600, Jonathan Corbet wrote:

> In summary, I think we can consider taking on a module if it's what
> we need to do the docs right.  And if somebody agrees to maintain it!
> :)

:)

I think for the ones that we carry, they're probably specific?

> I've heard others say they would like better diagramming support.  Do
> you think that, maybe, something like aafigure would do the trick?
> 
>   https://pythonhosted.org/sphinxcontrib-aafig/
> 
> I've not actually played with it at all, but I like the idea that
> we'd have readable diagrams in the source docs as well...

Well, maybe. I agree having it readable in the source docs as well is
nice, but for sequence diagrams in particular, I don't think

    +---+ +---+
| Hello +>+ aafigure! |
+---+ +---+

really beats

   Hello -> aafigure!

by much. You could do some alignment even with the latter version, and
the above isn't even really a sequence diagram anyway :)

Some of the sequence diagrams may also be automatically generated from
runtime behaviour observation (e.g. tracing, we've actually done that),
and outputting the types of ascii boxes is much more difficult there.

For other types of diagrams this may be nice though.

Anyway, I guess we'll cross that bridge when we get to it. I'd like to
have these types of documentation, perhaps with a script to auto-
generate from tracing - such as script and visual display can even
serve as a debugging aid :)

johannes
--
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: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

[Daniel Micay]

On Wed, 2016-10-19 at 07:26 -0300, Arnaldo Carvalho de Melo wrote:
> 
> But self profiling JITs would be useful for non-developers, on Android
> (anywhere, really), and for that it would require being able to at
> least, well, self profile, using sys_perf_event_open() by a normal
> process, limited to profiling itself, no?
> 
> This not being possible, self profiling will use some other means, its
> like sys_perf_event_open() never existed for them.
> 
> - Arnaldo

It would defeat the purpose of the security feature if it was exposed to
apps on Android. There are other ways for Chromium (including WebView)
and the ART JIT to profile. AFAIK, they've never actually considered
using perf for their JIT profiling. It wasn't something that anyone
cared about when this was implemented.

Chromium would *certainly* never use perf for this. They use a much
tighter sandbox than the Android app sandbox. It doesn't have system
calls like open(), let alone perf events. Their seccomp-bpf usage is to
reduce kernel attack surface, since it has proven to be the easiest way
out of a sandbox. They don't even allow futex() without filtering based 
on the parameters anymore. That proved to be a major
issue.

The only case where untrusted apps declaring the privileges they need
actually works out is when the privileges are high-level controls over
access to a user's personal information. That way, they can be exposed
to the user with the ability to reject access when it's first needed or
toggle it off later. The strength of the app sandbox isn't something
that end users can be responsible for. Permissions also don't work if
apps bypass them with local privilege escalation vulnerabilities.

Even for the base system, no perf access is better than having it used
anywhere. The difference is only that the base system can actually be
trusted to declare what it needs, but those components can be exploited
so it's still best if they are trusted as little as possible at runtime.

I could see Android completely removing unprivileged access down the
road too, not as a form of access control (apps already run as unique
uid/gid pairs, etc.) but to remove a non-trivial form of kernel attack
surface. The perf API isn't being singled out here. It just happened to
be the first case where a kernel API was restricted to developer usage
on Android. Should expect more of this.

If you want perf exposed, make it secure. Stop writing kernel code in a
memory unsafe language and start using isolation. Not going to happen in
all likelihood, so kernel code will be increasingly walled off instead
since it's the biggest liability on the system. Fixing bugs on a case by
case basis doesn't work for systems that need even basic security.

signature.asc
Description: This is a digitally signed message part

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

[Daniel Micay]

On Wed, 2016-10-19 at 10:41 +0100, Mark Rutland wrote:
> On Mon, Oct 17, 2016 at 10:54:33AM -0400, Daniel Micay wrote:
> > On Mon, 2016-10-17 at 14:44 +0100, Mark Rutland wrote:
> > > It's also my understanding that for Android, perf_event_paranoid
> > > is
> > > lowered when the user enables developer mode (rather than only
> > > when an
> > > external debugger is attached); is that correct?
> > 
> > It's exposed as a "system property" marked as writable by the shell
> > user, so the Android Debug Bridge shell can lower it. The debugging
> > tools learned how to toggle it off automatically when they're used.
> > It
> > intentionally isn't a persist. prefixed property so the setting also
> > goes away on reboot.
> > 
> > ADB (incl. the shell user) isn't available until developer mode is
> > enabled + ADB is toggled on in the developer settings, and then it
> > still
> > requires whitelisting keys.
> 
> Ah; so I'd misunderstood somewhat.
> 
> I was under the (clearly mistaken) impression that this was lowered
> when
> developer mode was enabled, rather than only when it was both enabled
> and ADB was connected, for example.
> 
> Thanks for clearing that up!

ADB provides a shell as the 'shell' user, and that user has the ability
to toggle the sysctl. So profiling tools were able to be taught to do
that automatically. It's the only way that the 'shell' user is actually
exposed. For example, a terminal app just runs in the untrusted_app
SELinux domain as a unique unprivileged uid/gid pair, not as the much
more privileged ADB 'shell' domain.

So it doesn't actually get toggled off you use ADB to do something else.

ADB itself is pretty much comparable to SSH, but over USB (i.e. key-
based way of getting a shell).

The 'shell' user has tools like 'run-as' to be able to run things as
various apps (if they are marked debuggable), so in theory it could be
finer-grained and act only there, for the app being debugged. It would
be really hard to cover all use cases and maybe things other than apps
though (although in an Android 'user' build, the base system itself
isn't very debuggable, you really need 'userdebug' or 'eng' which isn't
what ships on end user devices).

signature.asc
Description: This is a digitally signed message part

Re: sequence diagrams in rst documentation

[Jani Nikula]

On Wed, 19 Oct 2016, Markus Heiser  wrote:
> Am 18.10.2016 um 16:52 schrieb Jani Nikula :
>
>>> *Only* adding the PNG would be awful, I'd have to keep track of the
>>> corresponding source elsewhere, and perhaps couldn't even GPL it
>>> because then I couldn't distribute the PNG without corresponding
>>> source...
>>> 
>>> Adding the source text would really be the only practical choice, but
>>> doing so makes it easy to mismatch things, and also very easy to use
>>> proprietary services for it that may go away at any time, etc.
>> 
>> Agreed. And there are other problems with attaching binaries (although
>> I'd say we should fix them too) [1].
>> 
>> [1] http://lkml.kernel.org/r/02a78907-933d-3f61-572e-28154b16b...@redhat.com
>
> Hmm, I was not briefed that binaries are problematic. I have seen
> GIFs e.g. [2] and PDFs with a long history (when I worked with the media
> documentation), so I thought binaries are OK.
>
> Can you give me some more hints to understand in what ways they are
> problematic?  / sorry if my question seems dump /

You can download incremental patches from https://www.kernel.org/ for
kernel updates. Seems so 90s, but people apparently still do this. I
don't think the traditional diff/patch tools play ball with
binaries. The least that could be done is to generate the patches using
git diff --binary to include the git binary diff format. I don't see how
that would be worse than having just "Binary files foo and bar differ"
in the diff.

Personally I don't really mind including binaries if they are the
*source* format. If they're generated from something else, that
something else should be tracked in git instead.

And Someone(tm) should fix the tooling to handle binaries...

BR,
Jani.


>
> [2] 
> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/Documentation/DocBook/v4l/fieldseq_tb.gif?h=v3.0
>
> -- Markus --

-- 
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: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

[Arnaldo Carvalho de Melo]

Em Wed, Oct 19, 2016 at 12:01:26PM +0200, Peter Zijlstra escreveu:
> On Tue, Oct 18, 2016 at 05:15:01PM -0400, Daniel Micay wrote:
> > It's also worth noting that fine-grained control via a scoped mechanism
> > would likely only be used to implement *more restrictions* on Android,
> > not to make the feature less aggressive.
 
> > It's desirable for perf events to be disabled by default for non-root
> > across the board on Android.
 
> Right, but this is Android. The knob seems to now also live in Debian
> (and derived) distros. And there it is utter crap.
 
> It completely defeats having perf for a fairly large segment of
> corporate developers who do not get to have root on their own machines
> (which is stupid policy but whatever).
 
> It similarly defeats development of self profiling JITs and whatnot.
 
> A capability would allow people to run perf (or another sanctioned
> binary), even though in general they cannot do sys_perf_event_open().

But self profiling JITs would be useful for non-developers, on Android
(anywhere, really), and for that it would require being able to at
least, well, self profile, using sys_perf_event_open() by a normal
process, limited to profiling itself, no?

This not being possible, self profiling will use some other means, its
like sys_perf_event_open() never existed for them.

- Arnaldo
--
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] hwmon: (mcp3021) rework for DT support

[Clemens Gruber]

Support setting the reference voltage from the device tree.
Rework of driver structure, put chip specific data in a separate
structure and assign it depending on device id from platform data or
DT match.
Extend the device documentation and also change S_IRUGO to the better
readable 0444, which fixes a checkpatch warning.

Signed-off-by: Clemens Gruber 
---
 Documentation/hwmon/mcp3021 |   5 ++
 drivers/hwmon/mcp3021.c | 143 +++-
 2 files changed, 107 insertions(+), 41 deletions(-)

diff --git a/Documentation/hwmon/mcp3021 b/Documentation/hwmon/mcp3021
index 74a6b72..55792c3 100644
--- a/Documentation/hwmon/mcp3021
+++ b/Documentation/hwmon/mcp3021
@@ -12,6 +12,7 @@ Supported chips:
 Authors:
Mingkai Hu
Sven Schuchmann 
+   Clemens Gruber 
 
 Description
 ---
@@ -27,3 +28,7 @@ Communication to the MCP3021/MCP3221  is performed using a 
2-wire I2C
 compatible interface. Standard (100 kHz) and Fast (400 kHz) I2C modes are
 available. The default I2C device address is 0x4d (contact the Microchip
 factory for additional address options).
+
+The reference-voltage used in the conversion can be set via platform data or
+device tree. Please refer to Documentation/devicetree/bindings/i2c/mcp3021.txt
+for information about the bindings if the device tree is used.
diff --git a/drivers/hwmon/mcp3021.c b/drivers/hwmon/mcp3021.c
index 972444a..89b26fb 100644
--- a/drivers/hwmon/mcp3021.c
+++ b/drivers/hwmon/mcp3021.c
@@ -4,6 +4,7 @@
  * Copyright (C) 2008-2009, 2012 Freescale Semiconductor, Inc.
  * Author: Mingkai Hu 
  * Reworked by Sven Schuchmann 
+ * Copyright (C) 2016 Clemens Gruber 
  *
  * This driver export the value of analog input voltage to sysfs, the
  * voltage unit is mV. Through the sysfs interface, lm-sensors tool
@@ -22,37 +23,56 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
-/* Vdd info */
+/* Vdd / reference voltage */
 #define MCP3021_VDD_MAX5500
 #define MCP3021_VDD_MIN2700
-#define MCP3021_VDD_REF3300
-
-/* output format */
-#define MCP3021_SAR_SHIFT  2
-#define MCP3021_SAR_MASK   0x3ff
-#define MCP3021_OUTPUT_RES 10  /* 10-bit resolution */
-
-#define MCP3221_SAR_SHIFT  0
-#define MCP3221_SAR_MASK   0xfff
-#define MCP3221_OUTPUT_RES 12  /* 12-bit resolution */
+#define MCP3021_VDD_DEFAULT3300
 
 enum chips {
mcp3021,
mcp3221
 };
 
+struct mcp3021_chip_info {
+   u16 sar_shift;
+   u16 sar_mask;
+   u8 output_res;
+};
+
 /*
  * Client data (each client gets its own)
  */
 struct mcp3021_data {
struct device *hwmon_dev;
-   u32 vdd;/* device power supply */
-   u16 sar_shift;
-   u16 sar_mask;
-   u8 output_res;
+   const struct mcp3021_chip_info *chip_info;
+   u32 vdd; /* device power supply and reference voltage */
 };
 
+static const struct mcp3021_chip_info mcp3021_chip_info_tbl[] = {
+   [mcp3021] = {
+   .sar_shift = 2,
+   .sar_mask = 0x3ff,
+   .output_res = 10,   /* 10-bit resolution */
+   },
+   [mcp3221] = {
+   .sar_shift = 0,
+   .sar_mask = 0xfff,
+   .output_res = 12,   /* 12-bit resolution */
+   },
+};
+
+#ifdef CONFIG_OF
+static const struct of_device_id of_mcp3021_match[] = {
+   { .compatible = "microchip,mcp3021", .data = (void *)mcp3021 },
+   { .compatible = "microchip,mcp3221", .data = (void *)mcp3221 },
+   { }
+};
+MODULE_DEVICE_TABLE(of, of_mcp3021_match);
+#endif
+
 static int mcp3021_read16(struct i2c_client *client)
 {
struct mcp3021_data *data = i2c_get_clientdata(client);
@@ -73,14 +93,15 @@ static int mcp3021_read16(struct i2c_client *client)
 * The ten-bit output code is composed of the lower 4-bit of the
 * first byte and the upper 6-bit of the second byte.
 */
-   reg = (reg >> data->sar_shift) & data->sar_mask;
+   reg = (reg >> data->chip_info->sar_shift) & data->chip_info->sar_mask;
 
return reg;
 }
 
 static inline u16 volts_from_reg(struct mcp3021_data *data, u16 val)
 {
-   return DIV_ROUND_CLOSEST(data->vdd * val, 1 << data->output_res);
+   return DIV_ROUND_CLOSEST(data->vdd * val,
+1 << data->chip_info->output_res);
 }
 
 static ssize_t show_in_input(struct device *dev, struct device_attribute *attr,
@@ -99,46 +120,83 @@ static ssize_t show_in_input(struct device *dev, struct 
device_attribute *attr,
return sprintf(buf, "%d\n", in_input);
 }
 
-static DEVICE_ATTR(in0_input, S_IRUGO, show_in_input, NULL);
+static DEVICE_ATTR(in0_input, 0444, show_in_input, NULL);
 
-static int mcp3021_probe(struct i2c_client *client,
+#ifdef CONFIG_OF
+static int 

Re: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

[Mark Rutland]

On Mon, Oct 17, 2016 at 10:54:33AM -0400, Daniel Micay wrote:
> On Mon, 2016-10-17 at 14:44 +0100, Mark Rutland wrote:
> > It's also my understanding that for Android, perf_event_paranoid is
> > lowered when the user enables developer mode (rather than only when an
> > external debugger is attached); is that correct?
> 
> It's exposed as a "system property" marked as writable by the shell
> user, so the Android Debug Bridge shell can lower it. The debugging
> tools learned how to toggle it off automatically when they're used. It
> intentionally isn't a persist. prefixed property so the setting also
> goes away on reboot.
> 
> ADB (incl. the shell user) isn't available until developer mode is
> enabled + ADB is toggled on in the developer settings, and then it still
> requires whitelisting keys.

Ah; so I'd misunderstood somewhat.

I was under the (clearly mistaken) impression that this was lowered when
developer mode was enabled, rather than only when it was both enabled
and ADB was connected, for example.

Thanks for clearing that up!

Thanks,
Mark.
--
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: sequence diagrams in rst documentation

[Markus Heiser]

Am 18.10.2016 um 16:52 schrieb Jani Nikula :

>> *Only* adding the PNG would be awful, I'd have to keep track of the
>> corresponding source elsewhere, and perhaps couldn't even GPL it
>> because then I couldn't distribute the PNG without corresponding
>> source...
>> 
>> Adding the source text would really be the only practical choice, but
>> doing so makes it easy to mismatch things, and also very easy to use
>> proprietary services for it that may go away at any time, etc.
> 
> Agreed. And there are other problems with attaching binaries (although
> I'd say we should fix them too) [1].
> 
> [1] http://lkml.kernel.org/r/02a78907-933d-3f61-572e-28154b16b...@redhat.com

Hmm, I was not briefed that binaries are problematic. I have seen
GIFs e.g. [2] and PDFs with a long history (when I worked with the media
documentation), so I thought binaries are OK.

Can you give me some more hints to understand in what ways they are
problematic?  / sorry if my question seems dump /

[2] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/Documentation/DocBook/v4l/fieldseq_tb.gif?h=v3.0

-- 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: [kernel-hardening] [PATCH 1/2] security, perf: allow further restriction of perf_event_open

[Mark Rutland]

On Tue, Oct 18, 2016 at 05:15:01PM -0400, Daniel Micay wrote:
> It's also worth noting that fine-grained control via a scoped
> mechanism would likely only be used to implement *more restrictions*
> on Android, not to make the feature less aggressive. It's desirable
> for perf events to be disabled by default for non-root across the
> board on Android.  The part that's imperfect is that when a developer
> uses a profiling tool, unprivileged usage is automatically enabled
> across the board until reboot. Ideally, it would be enabled only for
> the scope where it's needed. 

Sure; understood.

> It would be very tricky to implement though, especially without adding
> friction, and it would only have value for protecting devices being
> used for development. It really doesn't seem to be worth the trouble,
> especially since it doesn't persist on reboot. It's only a temporary
> security hole and only for developer devices.

I can see that for Android this isn't much of a win. It is beneficial
elsewhere, and covers a larger set of use-cases.

If perf were a filesystem object, we'd only allow access by a given
'perf' group, and that would be sufficient to avoid most of that
friction (IIUC). I wonder what we can do that's similar.

Thanks,
Mark.
--
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] Documentation/sphinx: rename kernel-doc.py to kerneldoc.py

[Markus Heiser]

Am 19.10.2016 um 12:44 schrieb Jani Nikula :

> Python module names should not have hyphens per [PEP 8]. Drop the hyphen
> from kernel-doc.py. The extension directive remains unchanged.
> 
> [PEP 8] https://www.python.org/dev/peps/pep-0008/#package-and-module-names
> 
> Reported-by: Markus Heiser 
> Signed-off-by: Jani Nikula 

Wow! .. you are fast ;-) / Thanks!

--M--

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

miss some documentation on https://www.kernel.org/doc/

[Markus Heiser]

Hi kernel.org maintainers,

sorry for my silly question: I miss the documentation of the
reST (sphinx) content [1] on https://www.kernel.org/doc/ Since
the DocBook files migrated to reST (sphinx) increase
the "htmldocs" at [3] are decreasing.

I suppose you build HTML of the DocBook content of [3] with:

 make htmldocs

If you do so, you will find the HTML rendered sphinx content in
Documentation/output (O=dir).

If you only want to build the Sphinx content, set DOCBOOKS empty:

 make DOCBOOKS= htmldocs

There is also a small intro [2]. If you need help/infos, don't
hesitate and contact me and/or Linux Doc Mailing List
.

It would be great to see HTML build of the sphinx content at [3].

Thanks and BR

 -- Markus --

[1] https://lwn.net/Articles/692705/
[2] 
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/kernel-documentation.rst
[3] https://www.kernel.org/doc/htmldocs/

--
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 16/37] Documentation/module-signing.txt: convert to ReST markup

[Mauro Carvalho Chehab]

Em Wed, 19 Oct 2016 06:58:12 +0200
Markus Heiser  escreveu:
 
> just a small suggestion of mine 
> 
> .. CONTENTS
> 
>   - Overview.
>   - Configuring module signing.
>   - Generating signing keys.
>   - Public keys in the kernel.
>   - Manually signing modules.
>   - Signed modules and stripping.
>   - Loading signed modules.
>   - Non-valid signatures and unsigned modules.
>   - Administering/protecting the private key.
> 
> should be enough.

True, but it sounds counter-intuitive to my C-language-training mind to 
see a multi-line comment block with no end tag, like the above.

For my mental parser, this is a way more obvious that the entire block
is commented:

.. CONTENTS
..
.. - Overview.
.. - Configuring module signing.

With resembles C99 comments, with '//'.

Thanks,
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 v2 16/37] Documentation/module-signing.txt: convert to ReST markup

[Markus Heiser]

Am 19.10.2016 um 11:33 schrieb Mauro Carvalho Chehab :

> Em Wed, 19 Oct 2016 06:58:12 +0200
> Markus Heiser  escreveu:
> 
>> just a small suggestion of mine 
>> 
>> .. CONTENTS
>> 
>>  - Overview.
>>  - Configuring module signing.
>>  - Generating signing keys.
>>  - Public keys in the kernel.
>>  - Manually signing modules.
>>  - Signed modules and stripping.
>>  - Loading signed modules.
>>  - Non-valid signatures and unsigned modules.
>>  - Administering/protecting the private key.
>> 
>> should be enough.
> 
> True, but it sounds counter-intuitive to my C-language-training mind to 
> see a multi-line comment block with no end tag, like the above.

Ah, OK .. I didn't know if you aware about comment blocks and I thought
about readability in pure ASCII. IMO Both is OK.

--M--

> For my mental parser, this is a way more obvious that the entire block
> is commented:
> 
>   .. CONTENTS
>   ..
>   .. - Overview.
>   .. - Configuring module signing.
> 
> With resembles C99 comments, with '//'.
> 
> Thanks,
> 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] Documentation/sphinx: rename kernel-doc.py to kerneldoc.py

[Jani Nikula]

Python module names should not have hyphens per [PEP 8]. Drop the hyphen
from kernel-doc.py. The extension directive remains unchanged.

[PEP 8] https://www.python.org/dev/peps/pep-0008/#package-and-module-names

Reported-by: Markus Heiser 
Signed-off-by: Jani Nikula 
---
 Documentation/conf.py| 2 +-
 Documentation/sphinx/{kernel-doc.py => kerneldoc.py} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename Documentation/sphinx/{kernel-doc.py => kerneldoc.py} (100%)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 0cc8765d3f98..bebab599a09b 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -34,7 +34,7 @@ from load_config import loadConfig
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain']
+extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain']
 
 # The name of the math extension changed on Sphinx 1.4
 if minor > 3:
diff --git a/Documentation/sphinx/kernel-doc.py 
b/Documentation/sphinx/kerneldoc.py
similarity index 100%
rename from Documentation/sphinx/kernel-doc.py
rename to Documentation/sphinx/kerneldoc.py
-- 
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: [PATCH] Documentation/RCU: Fix minor typo

[Paul E. McKenney]

On Tue, Oct 18, 2016 at 12:43:24AM -0700, Josh Triplett wrote:
> On Tue, Oct 18, 2016 at 12:54:03AM -0400, Pranith Kumar wrote:
> > deference should actually be dereference.
> > 
> > Signed-off-by: Pranith Kumar 
> 
> Good catch.
> 
> Reviewed-by: Josh Triplett 

Applied, thank you both!

Thanx, Paul

> >  Documentation/RCU/whatisRCU.txt | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/Documentation/RCU/whatisRCU.txt 
> > b/Documentation/RCU/whatisRCU.txt
> > index 2044227..5cbd8b2 100644
> > --- a/Documentation/RCU/whatisRCU.txt
> > +++ b/Documentation/RCU/whatisRCU.txt
> > @@ -237,7 +237,7 @@ rcu_dereference()
> >  
> > The reader uses rcu_dereference() to fetch an RCU-protected
> > pointer, which returns a value that may then be safely
> > -   dereferenced.  Note that rcu_deference() does not actually
> > +   dereferenced.  Note that rcu_dereference() does not actually
> > dereference the pointer, instead, it protects the pointer for
> > later dereferencing.  It also executes any needed memory-barrier
> > instructions for a given CPU architecture.  Currently, only Alpha
> > -- 
> > 2.10.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