[PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

[Markus Heiser]

From: Markus Heiser 

Hi Jon, Mauro, and Jani,

with this series a reST-directive kernel-cmd is introduced. The kernel-cmd
directive includes contend from the stdout of a command-line (@mchehab asked
for).

Including content from a command's stdout is a more general solution for other
workarounds like the "kernel_include + parseheaders" solution. This series also
migrates the kernel-include uses to kernel-cmd directives and drops the Makefile
in the media sub-folder. With the last patch, the (no longer needed)
kernel-include directive is removed.

-- Markus --

Markus Heiser (4):
  doc-rst: reST-directive kernel-cmd / include contentent from scripts
  doc-rst: customize RTD theme; literal-block
  doc-rst: migrated media build kernel-cmd directive
  doc-rst: remove the kernel-include directive

 Documentation/Makefile.sphinx  |   4 +-
 Documentation/conf.py  |   2 +-
 Documentation/media/Makefile   |  61 ---
 Documentation/media/audio.h.rst.exceptions |  20 -
 Documentation/media/ca.h.rst.exceptions|  24 -
 Documentation/media/cec.h.rst.exceptions   | 492 ---
 Documentation/media/dmx.h.rst.exceptions   |  63 ---
 Documentation/media/frontend.h.rst.exceptions  |  47 --
 Documentation/media/lirc.h.rst.exceptions  |  43 --
 Documentation/media/media.h.rst.exceptions |  30 --
 Documentation/media/net.h.rst.exceptions   |  11 -
 Documentation/media/uapi/cec/cec-header.rst|   3 +-
 Documentation/media/uapi/cec/cec.h.exceptions  | 492 +++
 Documentation/media/uapi/dvb/audio.h.exceptions|  20 +
 Documentation/media/uapi/dvb/audio_h.rst   |   2 +-
 Documentation/media/uapi/dvb/ca.h.exceptions   |  24 +
 Documentation/media/uapi/dvb/ca_h.rst  |   2 +-
 Documentation/media/uapi/dvb/dmx.h.exceptions  |  63 +++
 Documentation/media/uapi/dvb/dmx_h.rst |   2 +-
 Documentation/media/uapi/dvb/frontend.h.exceptions |  47 ++
 Documentation/media/uapi/dvb/frontend_h.rst|   2 +-
 Documentation/media/uapi/dvb/net.h.exceptions  |  11 +
 Documentation/media/uapi/dvb/net_h.rst |   2 +-
 Documentation/media/uapi/dvb/video.h.exceptions|  40 ++
 Documentation/media/uapi/dvb/video_h.rst   |   2 +-
 Documentation/media/uapi/mediactl/media-header.rst |   3 +-
 .../media/uapi/mediactl/media.h.exceptions |  30 ++
 Documentation/media/uapi/rc/lirc-header.rst|   2 +-
 Documentation/media/uapi/rc/lirc.h.exceptions  |  43 ++
 Documentation/media/uapi/v4l/videodev.rst  |   2 +-
 .../media/uapi/v4l/videodev2.h.exceptions  | 535 +
 Documentation/media/video.h.rst.exceptions |  40 --
 Documentation/media/videodev2.h.rst.exceptions | 535 -
 Documentation/sphinx-static/theme_overrides.css|   7 +
 Documentation/sphinx/kernel_cmd.py | 206 
 Documentation/sphinx/kernel_include.py | 190 
 Documentation/sphinx/parse-headers.pl  |  17 +-
 37 files changed, 1538 insertions(+), 1581 deletions(-)
 delete mode 100644 Documentation/media/Makefile
 delete mode 100644 Documentation/media/audio.h.rst.exceptions
 delete mode 100644 Documentation/media/ca.h.rst.exceptions
 delete mode 100644 Documentation/media/cec.h.rst.exceptions
 delete mode 100644 Documentation/media/dmx.h.rst.exceptions
 delete mode 100644 Documentation/media/frontend.h.rst.exceptions
 delete mode 100644 Documentation/media/lirc.h.rst.exceptions
 delete mode 100644 Documentation/media/media.h.rst.exceptions
 delete mode 100644 Documentation/media/net.h.rst.exceptions
 create mode 100644 Documentation/media/uapi/cec/cec.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/audio.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/ca.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/dmx.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/frontend.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/net.h.exceptions
 create mode 100644 Documentation/media/uapi/dvb/video.h.exceptions
 create mode 100644 Documentation/media/uapi/mediactl/media.h.exceptions
 create mode 100644 Documentation/media/uapi/rc/lirc.h.exceptions
 create mode 100644 Documentation/media/uapi/v4l/videodev2.h.exceptions
 delete mode 100644 Documentation/media/video.h.rst.exceptions
 delete mode 100644 Documentation/media/videodev2.h.rst.exceptions
 create mode 100644 Documentation/sphinx/kernel_cmd.py
 delete mode 100755 Documentation/sphinx/kernel_include.py

-- 
2.7.4

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

[PATCH 2/4] doc-rst: customize RTD theme; literal-block

[Markus Heiser]

From: Markus Heiser 

From: Markus Heiser 

Format the literal-block like other code-block elements, with 12px and a
line-high of 1.5.

Signed-off-by: Markus Heiser 
---
 Documentation/sphinx-static/theme_overrides.css | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/sphinx-static/theme_overrides.css 
b/Documentation/sphinx-static/theme_overrides.css
index 8c00f84..47026e4 100644
--- a/Documentation/sphinx-static/theme_overrides.css
+++ b/Documentation/sphinx-static/theme_overrides.css
@@ -69,4 +69,11 @@
 .rst-content tt.literal,.rst-content tt.literal,.rst-content code.literal {
 color: inherit;
 }
+
+/* literal blocks (e.g. parsed-literal directive) */
+
+pre.literal-block {
+font-size: 12px;
+line-height: 1.5;
+}
 }
-- 
2.7.4

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

[PATCH 4/4] doc-rst: remove the kernel-include directive

[Markus Heiser]

From: Markus Heiser 

From: Markus Heiser 

The kernel-include directive is no longer needed, so lets remove this
out-of-favor solution.

BTW: fixed a C&P typo in the Documentation/Makefile

Signed-off-by: Markus Heiser 
---
 Documentation/Makefile.sphinx  |   2 +-
 Documentation/conf.py  |   2 +-
 Documentation/sphinx/kernel_include.py | 190 -
 3 files changed, 2 insertions(+), 192 deletions(-)
 delete mode 100755 Documentation/sphinx/kernel_include.py

diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
index 2e033e4..36b8c41 100644
--- a/Documentation/Makefile.sphinx
+++ b/Documentation/Makefile.sphinx
@@ -51,7 +51,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1))
 # $5 reST source folder relative to $(srctree)/$(src),
 #e.g. "media" for the linux-tv book-set at ./Documentation/media
 
-quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4);
+quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
   cmd_sphinx = \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
$(srctree)/$(src)/$5/$(SPHINX_CONF)) \
$(SPHINXBUILD) \
diff --git a/Documentation/conf.py b/Documentation/conf.py
index 64231e1..a165b53 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', 
'kernel_cmd']
+extensions = ['kernel-doc', 'rstFlatTable', 'cdomain', 'kernel_cmd']
 
 # The name of the math extension changed on Sphinx 1.4
 if minor > 3:
diff --git a/Documentation/sphinx/kernel_include.py 
b/Documentation/sphinx/kernel_include.py
deleted file mode 100755
index f523aa6..000
--- a/Documentation/sphinx/kernel_include.py
+++ /dev/null
@@ -1,190 +0,0 @@
-#!/usr/bin/env python3
-# -*- coding: utf-8; mode: python -*-
-# pylint: disable=R0903, C0330, R0914, R0912, E0401
-
-u"""
-kernel-include
-~~
-
-Implementation of the ``kernel-include`` reST-directive.
-
-:copyright:  Copyright (C) 2016  Markus Heiser
-:license:GPL Version 2, June 1991 see linux/COPYING for details.
-
-The ``kernel-include`` reST-directive is a replacement for the ``include``
-directive. The ``kernel-include`` directive expand environment variables in
-the path name and allows to include files from arbitrary locations.
-
-.. hint::
-
-  Including files from arbitrary locations (e.g. from ``/etc``) is a
-  security risk for builders. This is why the ``include`` directive from
-  docutils *prohibit* pathnames pointing to locations *above* the 
filesystem
-  tree where the reST document with the include directive is placed.
-
-Substrings of the form $name or ${name} are replaced by the value of
-environment variable name. Malformed variable names and references to
-non-existing variables are left unchanged.
-"""
-
-# 
==
-# imports
-# 
==
-
-import os.path
-
-from docutils import io, nodes, statemachine
-from docutils.utils.error_reporting import SafeString, ErrorString
-from docutils.parsers.rst import directives
-from docutils.parsers.rst.directives.body import CodeBlock, NumberLines
-from docutils.parsers.rst.directives.misc import Include
-
-__version__  = '1.0'
-
-# 
==
-def setup(app):
-# 
==
-
-app.add_directive("kernel-include", KernelInclude)
-return dict(
-version = __version__,
-parallel_read_safe = True,
-parallel_write_safe = True
-)
-
-# 
==
-class KernelInclude(Include):
-# 
==
-
-u"""KernelInclude (``kernel-include``) directive"""
-
-def run(self):
-path = os.path.realpath(
-os.path.expandvars(self.arguments[0]))
-
-# to get a bit security back, prohibit /etc:
-if path.startswith(os.sep + "etc"):
-raise self.severe(
-'Problems with "%s" directive, prohibited path: %s'
-% (self.name, path))
-
-self.arguments[0] = path
-
-#return super(KernelInclude, self).run() # won't work, see HINTs in 
_run()
-return self._run()
-
-def _run(self):
-"""Include a file as part of the content of this reST file."""
-
-# HINT: I had to copy&paste the whole Include.run method. I'am not 
happy
-# with this, but due to security reasons, the Include.run method does
-

[PATCH 1/4] doc-rst: reST-directive kernel-cmd / include contentent from scripts

[Markus Heiser]

From: Markus Heiser 

From: Markus Heiser 

The ``kernel-cmd`` directive includes contend from the stdout of a
command-line. With the ``kernel-cmd`` directive we can include the
output of any (Perl or whatever) script. This is a more general solution
for other workarounds like the "kernel_include + parseheaders" solution.

Overview of directive's argument and options.

.. code-block:: rst

.. kernel-cmd:: 
:depends: 
:code-block: 
:debug:

The argument  is required, it is a command line to be
executed. The stdout stream of the command is captured and is inserted as
reST content. The command line is executed in a system shell where the PATH
environment is extended with the paths ::

PATH=$(srctree)/scripts:$(srctree)/Documentation/sphinx:...

A very simple example, which includes the output as ``code-block``::

  .. kernel-cmd:: ls -la $srctree
:code-block: sh

The ``code-block`` is optional, leaving it will include the output as
pure (hopefully well) formated reST.

.. warning::

   The kernel-cmd directive **executes** commands, whatever poses a risk
   (shell injection) in itself!

   The command might depend on local installations, don't use commands which
   are not available in some OS (be clear about the dependencies).

Signed-off-by: Markus Heiser 
---
 Documentation/conf.py  |   2 +-
 Documentation/sphinx/kernel_cmd.py | 206 +
 2 files changed, 207 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/sphinx/kernel_cmd.py

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 0cc8765..64231e1 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 = ['kernel-doc', 'rstFlatTable', 'kernel_include', 'cdomain', 
'kernel_cmd']
 
 # The name of the math extension changed on Sphinx 1.4
 if minor > 3:
diff --git a/Documentation/sphinx/kernel_cmd.py 
b/Documentation/sphinx/kernel_cmd.py
new file mode 100644
index 000..ddb2a27
--- /dev/null
+++ b/Documentation/sphinx/kernel_cmd.py
@@ -0,0 +1,206 @@
+# -*- coding: utf-8; mode: python -*-
+u"""
+kernel-cmd
+~~
+
+Implementation of the ``kernel-cmd`` reST-directive.
+
+:copyright:  Copyright (C) 2016  Markus Heiser
+:license:GPL Version 2, June 1991 see Linux/COPYING for details.
+
+The ``kernel-cmd`` (:py:class:`KernelCmd`) directive includes contend
+from the stdout of a comand-line.
+
+Overview of directive's argument and options.
+
+.. code-block:: rst
+
+.. kernel-cmd:: 
+:depends: 
+:code-block: 
+:debug:
+
+The argument  is required, it is a command line to be
+executed. The stdout stream of the command is captured and is inserted as
+reST content. The command line is executed in a system shell where the PATH
+environment is extended with the paths ::
+
+PATH=$(srctree)/scripts:$(srctree)/Documentation/sphinx:...
+
+``depends ``
+
+  If the stdout of the command line depends on files, you can add them as
+  dependency, which means: if one of the listed files is changed, the
+  sphinx-build (environment) is newly build.
+
+``code-block ``
+
+  If the called script outputs a code-block, use the ``code-block`` option
+  with an *language* as argument.  The valid values for the highlighting
+  language are:
+
+  * none (no highlighting)
+  * guess (let Pygments guess the lexer based on contents, only works
+with certain well-recognizable languages)
+  * rest
+  * c
+  * and any other lexer alias that `Pygments
+`_ supports.
+
+``debug``
+  Inserts a code-block with the *raw* reST. Sometimes it is helpful to see
+  what reST is generated.
+
+.. warning::
+
+   The kernel-cmd directive **executes** commands, whatever poses a risk
+   (shell injection) in itself!
+
+   The command might depend on local installations, don't use commands 
which
+   are not available in some OS (be clear about the dependencies).
+
+"""
+
+import sys
+import os
+from os import path
+import subprocess
+
+from sphinx.ext.autodoc import AutodocReporter
+
+from docutils import nodes
+from docutils.parsers.rst import Directive, directives
+from docutils.statemachine import ViewList
+from docutils.utils.error_reporting import ErrorString
+
+
+__version__  = '1.0'
+
+# We can't assume that six is installed
+PY3 = sys.version_info[0] == 3
+PY2 = sys.version_info[0] == 2
+if PY3:
+# pylint: disable=C0103, W0622
+unicode = str
+basestring  = str
+
+def setup(app):
+
+app.add_directive("kernel-cmd", KernelCmd)
+re

[PATCH] Documentation/trace/uprobetracer.txt: fix incorrect examples

[Marcin Nowakowski]

Current uprobetracer examples don't work as they use an incorrect syntax
- if no event name is specified then 'p/r' must not be followed by a
  colon
- if no event name is specified then the default event name will have a
  'p_' prefix, so use that in the '-' example as well

Signed-off-by: Marcin Nowakowski 
---
 Documentation/trace/uprobetracer.txt | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/trace/uprobetracer.txt 
b/Documentation/trace/uprobetracer.txt
index 72d1cd4..41f83b2 100644
--- a/Documentation/trace/uprobetracer.txt
+++ b/Documentation/trace/uprobetracer.txt
@@ -73,15 +73,15 @@ Usage examples
  * Add a probe as a new uprobe event, write a new definition to uprobe_events
 as below: (sets a uprobe at an offset of 0x4245c0 in the executable /bin/bash)
 
-echo 'p: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
+echo 'p /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
 
  * Add a probe as a new uretprobe event:
 
-echo 'r: /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
+echo 'r /bin/bash:0x4245c0' > /sys/kernel/debug/tracing/uprobe_events
 
  * Unset registered event:
 
-echo '-:bash_0x4245c0' >> /sys/kernel/debug/tracing/uprobe_events
+echo '-:p_bash_0x4245c0' >> /sys/kernel/debug/tracing/uprobe_events
 
  * Print out the events that are registered:
 
-- 
2.7.4

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

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

[Jani Nikula]

On Thu, 06 Oct 2016, Markus Heiser  wrote:
> with this series a reST-directive kernel-cmd is introduced. The kernel-cmd
> directive includes contend from the stdout of a command-line (@mchehab asked
> for).

I like the fact that this removes Documentation/media/Makefile, and
cleans up the Sphinx build rule in Documentation/Makefile.sphinx. Does
this also make the documentation buildable with sphinx-build directly,
without the kernel build system? If so, great.

However, I would have much preferred the approach I proposed months ago,
having the extension itself do specifically what parse-headers.pl does
now. While it may seem generic on the surface, I don't think it's a
clean or a secure approach to allow running of arbitrary scripts from
PATH while building documentation. It's certainly not an approach that
should be encouraged.

In part, the reason the DocBook build became so unwieldy was the
proliferation of arbitrary scripts and tools required to make it
happen. I think it would be really sad to let this happen to the Sphinx
build. I am *already* sad about how parse-headers.pl was bolted on to
the build.

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

[PATCH v9 2/4] drm: Add API for capturing frame CRCs

[Tomeu Vizoso]

Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:

dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data

Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
by calling drm_crtc_add_crc_entry.

v2:
- Lots of good fixes suggested by Thierry.
- Added documentation.
- Changed the debugfs layout.
- Moved to allocate the entries circular queue once when frame
  generation gets enabled for the first time.
v3:
- Use the control file just to select the source, and start and stop
  capture when the data file is opened and closed, respectively.
- Make variable the number of CRC values per entry, per source.
- Allocate entries queue each time we start capturing as now there
  isn't a fixed number of CRC values per entry.
- Store the frame counter in the data file as a 8-digit hex number.
- For sources that cannot provide useful frame numbers, place
   in the frame field.

v4:
- Build only if CONFIG_DEBUG_FS is enabled.
- Use memdup_user_nul.
- Consolidate calculation of the size of an entry in a helper.
- Add 0x prefix to hex numbers in the data file.
- Remove unnecessary snprintf and strlen usage in read callback.

v5:
- Made the crcs array in drm_crtc_crc_entry fixed-size
- Lots of other smaller improvements suggested by Emil Velikov

v7:
- Move definition of drm_debugfs_crtc_crc_add to drm_internal.h

v8:
- Call debugfs_remove_recursive when we fail to create the minor
  device

v9:
- Register the debugfs directory for a crtc from
  drm_crtc_register_all()

Signed-off-by: Tomeu Vizoso 
---

 Documentation/gpu/drm-uapi.rst|   6 +
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_crtc.c|  34 +++-
 drivers/gpu/drm/drm_debugfs.c |  34 +++-
 drivers/gpu/drm/drm_debugfs_crc.c | 351 ++
 drivers/gpu/drm/drm_internal.h|  16 ++
 include/drm/drm_crtc.h|  41 +
 include/drm/drm_debugfs_crc.h |  73 
 8 files changed, 555 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 1ba301cebe16..de3ac9f90f8f 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -216,3 +216,9 @@ interfaces. Especially since all hardware-acceleration 
interfaces to
 userspace are driver specific for efficiency and other reasons these
 interfaces can be rather substantial. Hence every driver has its own
 chapter.
+
+Testing and validation
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
+   :doc: CRC ABI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 25c720454017..74579d2e796e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
drm_scatter.o drm_pci.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
-   drm_info.o drm_debugfs.o drm_encoder_slave.o \
+   drm_info.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
@@ -23,6 +23,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
+drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2d7bedf28647..151ff9805de1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -126,6 +126,10 @@ static int drm_crtc_register_all(struct drm_device *dev)
ret = crtc->funcs->late_register(crtc);
if (ret)
return ret;
+
+   ret = drm_debugfs_crtc_add(crtc);
+   if (ret)
+   return ret;
}
 
return 0;
@@ -136,11 +140,31 @@ static void drm_crtc_unregister_all(struct drm_device 
*dev)
struct drm_crtc *crtc;
 
drm_for_each_crtc(crtc, dev) {
+   drm_debugfs_crtc_remove(crtc);
if (crtc->funcs->early_unregister)
crtc->funcs->early_unregister(crtc);
}
 }
 
+static int drm_crtc_crc_init(struct drm_crtc *crtc)
+{
+#ifde

[PATCH v9 0/4] New debugfs API for capturing CRC of frames

[Tomeu Vizoso]

Hi,

this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.

The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.

Other drivers for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.

In this v9, there are build fixes for !CONFIG_DEBUG_FS and a fix so we don't
break probing of drivers that still use the .load callback (tested on
Tegra124).

Thanks,

Tomeu


Tomeu Vizoso (4):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API
  drm/i915: Put "cooked" vlank counters in frame CRC lines

 Documentation/gpu/drm-uapi.rst|6 +
 drivers/gpu/drm/Makefile  |3 +-
 drivers/gpu/drm/drm_crtc.c|   34 +-
 drivers/gpu/drm/drm_debugfs.c |   34 +-
 drivers/gpu/drm/drm_debugfs_crc.c |  351 
 drivers/gpu/drm/drm_internal.h|   16 +
 drivers/gpu/drm/i915/Makefile |2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  886 +---
 drivers/gpu/drm/i915/i915_drv.h   |1 +
 drivers/gpu/drm/i915/i915_irq.c   |   83 ++-
 drivers/gpu/drm/i915/intel_display.c  |1 +
 drivers/gpu/drm/i915/intel_drv.h  |   13 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 1013 +
 include/drm/drm_crtc.h|   41 ++
 include/drm/drm_debugfs_crc.h |   73 +++
 15 files changed, 1645 insertions(+), 912 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

-- 
2.7.4

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

Re: [PATCH v9 2/4] drm: Add API for capturing frame CRCs

[Emil Velikov]

On 6 October 2016 at 09:56, Tomeu Vizoso  wrote:
> Adds files and directories to debugfs for controlling and reading frame
> CRCs, per CRTC:
>
> dri/0/crtc-0/crc
> dri/0/crtc-0/crc/control
> dri/0/crtc-0/crc/data
>
> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
> start and stop generating frame CRCs and can add entries to the output
> by calling drm_crtc_add_crc_entry.
>
> v2:
> - Lots of good fixes suggested by Thierry.
> - Added documentation.
> - Changed the debugfs layout.
> - Moved to allocate the entries circular queue once when frame
>   generation gets enabled for the first time.
> v3:
> - Use the control file just to select the source, and start and stop
>   capture when the data file is opened and closed, respectively.
> - Make variable the number of CRC values per entry, per source.
> - Allocate entries queue each time we start capturing as now there
>   isn't a fixed number of CRC values per entry.
> - Store the frame counter in the data file as a 8-digit hex number.
> - For sources that cannot provide useful frame numbers, place
>    in the frame field.
>
> v4:
> - Build only if CONFIG_DEBUG_FS is enabled.
> - Use memdup_user_nul.
> - Consolidate calculation of the size of an entry in a helper.
> - Add 0x prefix to hex numbers in the data file.
> - Remove unnecessary snprintf and strlen usage in read callback.
>
> v5:
> - Made the crcs array in drm_crtc_crc_entry fixed-size
> - Lots of other smaller improvements suggested by Emil Velikov
>
> v7:
> - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h
>
> v8:
> - Call debugfs_remove_recursive when we fail to create the minor
>   device
>
> v9:
> - Register the debugfs directory for a crtc from
>   drm_crtc_register_all()
>
> Signed-off-by: Tomeu Vizoso 
> ---
>
>  Documentation/gpu/drm-uapi.rst|   6 +
>  drivers/gpu/drm/Makefile  |   3 +-
>  drivers/gpu/drm/drm_crtc.c|  34 +++-
>  drivers/gpu/drm/drm_debugfs.c |  34 +++-
>  drivers/gpu/drm/drm_debugfs_crc.c | 351 
> ++
>  drivers/gpu/drm/drm_internal.h|  16 ++
>  include/drm/drm_crtc.h|  41 +
>  include/drm/drm_debugfs_crc.h |  73 
>  8 files changed, 555 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
>  create mode 100644 include/drm/drm_debugfs_crc.h
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 1ba301cebe16..de3ac9f90f8f 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -216,3 +216,9 @@ interfaces. Especially since all hardware-acceleration 
> interfaces to
>  userspace are driver specific for efficiency and other reasons these
>  interfaces can be rather substantial. Hence every driver has its own
>  chapter.
> +
> +Testing and validation
> +==
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
> +   :doc: CRC ABI
> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> index 25c720454017..74579d2e796e 100644
> --- a/drivers/gpu/drm/Makefile
> +++ b/drivers/gpu/drm/Makefile
> @@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
> drm_scatter.o drm_pci.o \
> drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
> drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
> -   drm_info.o drm_debugfs.o drm_encoder_slave.o \
> +   drm_info.o drm_encoder_slave.o \
> drm_trace_points.o drm_global.o drm_prime.o \
> drm_rect.o drm_vma_manager.o drm_flip_work.o \
> drm_modeset_lock.o drm_atomic.o drm_bridge.o \
> @@ -23,6 +23,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>  drm-$(CONFIG_OF) += drm_of.o
>  drm-$(CONFIG_AGP) += drm_agpsupport.o
> +drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>
>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> index 2d7bedf28647..151ff9805de1 100644
> --- a/drivers/gpu/drm/drm_crtc.c
> +++ b/drivers/gpu/drm/drm_crtc.c
> @@ -40,7 +40,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>
>  #include "drm_crtc_internal.h"
>  #include "drm_internal.h"
> @@ -126,6 +126,10 @@ static int drm_crtc_register_all(struct drm_device *dev)
> ret = crtc->funcs->late_register(crtc);
> if (ret)
Here we want to teardown the already created debugfs entries.

> return ret;
> +
> +   ret = drm_debugfs_crtc_add(crtc);
> +   if (ret)
> +   return ret;
IIRC v8 made sure we don't error out if adding debugfs entries fails.
Pretty su

Re: [PATCH v9 2/4] drm: Add API for capturing frame CRCs

[Tomeu Vizoso]

On 10/06/2016 01:13 PM, Emil Velikov wrote:
> On 6 October 2016 at 09:56, Tomeu Vizoso  wrote:
>> Adds files and directories to debugfs for controlling and reading frame
>> CRCs, per CRTC:
>>
>> dri/0/crtc-0/crc
>> dri/0/crtc-0/crc/control
>> dri/0/crtc-0/crc/data
>>
>> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
>> start and stop generating frame CRCs and can add entries to the output
>> by calling drm_crtc_add_crc_entry.
>>
>> v2:
>> - Lots of good fixes suggested by Thierry.
>> - Added documentation.
>> - Changed the debugfs layout.
>> - Moved to allocate the entries circular queue once when frame
>>   generation gets enabled for the first time.
>> v3:
>> - Use the control file just to select the source, and start and stop
>>   capture when the data file is opened and closed, respectively.
>> - Make variable the number of CRC values per entry, per source.
>> - Allocate entries queue each time we start capturing as now there
>>   isn't a fixed number of CRC values per entry.
>> - Store the frame counter in the data file as a 8-digit hex number.
>> - For sources that cannot provide useful frame numbers, place
>>    in the frame field.
>>
>> v4:
>> - Build only if CONFIG_DEBUG_FS is enabled.
>> - Use memdup_user_nul.
>> - Consolidate calculation of the size of an entry in a helper.
>> - Add 0x prefix to hex numbers in the data file.
>> - Remove unnecessary snprintf and strlen usage in read callback.
>>
>> v5:
>> - Made the crcs array in drm_crtc_crc_entry fixed-size
>> - Lots of other smaller improvements suggested by Emil Velikov
>>
>> v7:
>> - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h
>>
>> v8:
>> - Call debugfs_remove_recursive when we fail to create the minor
>>   device
>>
>> v9:
>> - Register the debugfs directory for a crtc from
>>   drm_crtc_register_all()
>>
>> Signed-off-by: Tomeu Vizoso 
>> ---
>>
>>  Documentation/gpu/drm-uapi.rst|   6 +
>>  drivers/gpu/drm/Makefile  |   3 +-
>>  drivers/gpu/drm/drm_crtc.c|  34 +++-
>>  drivers/gpu/drm/drm_debugfs.c |  34 +++-
>>  drivers/gpu/drm/drm_debugfs_crc.c | 351 
>> ++
>>  drivers/gpu/drm/drm_internal.h|  16 ++
>>  include/drm/drm_crtc.h|  41 +
>>  include/drm/drm_debugfs_crc.h |  73 
>>  8 files changed, 555 insertions(+), 3 deletions(-)
>>  create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
>>  create mode 100644 include/drm/drm_debugfs_crc.h
>>
>> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
>> index 1ba301cebe16..de3ac9f90f8f 100644
>> --- a/Documentation/gpu/drm-uapi.rst
>> +++ b/Documentation/gpu/drm-uapi.rst
>> @@ -216,3 +216,9 @@ interfaces. Especially since all hardware-acceleration 
>> interfaces to
>>  userspace are driver specific for efficiency and other reasons these
>>  interfaces can be rather substantial. Hence every driver has its own
>>  chapter.
>> +
>> +Testing and validation
>> +==
>> +
>> +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
>> +   :doc: CRC ABI
>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>> index 25c720454017..74579d2e796e 100644
>> --- a/drivers/gpu/drm/Makefile
>> +++ b/drivers/gpu/drm/Makefile
>> @@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
>> drm_scatter.o drm_pci.o \
>> drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
>> drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
>> -   drm_info.o drm_debugfs.o drm_encoder_slave.o \
>> +   drm_info.o drm_encoder_slave.o \
>> drm_trace_points.o drm_global.o drm_prime.o \
>> drm_rect.o drm_vma_manager.o drm_flip_work.o \
>> drm_modeset_lock.o drm_atomic.o drm_bridge.o \
>> @@ -23,6 +23,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
>>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>>  drm-$(CONFIG_OF) += drm_of.o
>>  drm-$(CONFIG_AGP) += drm_agpsupport.o
>> +drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>>
>>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
>> drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o 
>> \
>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>> index 2d7bedf28647..151ff9805de1 100644
>> --- a/drivers/gpu/drm/drm_crtc.c
>> +++ b/drivers/gpu/drm/drm_crtc.c
>> @@ -40,7 +40,7 @@
>>  #include 
>>  #include 
>>  #include 
>> -#include 
>> +#include 
>>
>>  #include "drm_crtc_internal.h"
>>  #include "drm_internal.h"
>> @@ -126,6 +126,10 @@ static int drm_crtc_register_all(struct drm_device *dev)
>> ret = crtc->funcs->late_register(crtc);
>> if (ret)
> Here we want to teardown the already created debugfs entries.

Yeah, I was a bit puzzled by the existing behaviour of
drm_modeset_re

Re: [PATCH 3/4] doc-rst: migrated media build kernel-cmd directive

[Mauro Carvalho Chehab]

Em Thu,  6 Oct 2016 09:20:19 +0200
Markus Heiser  escreveu:

> From: Markus Heiser 
> 
> From: Markus Heiser 
> 
> Remove the media-Makefile and migrate the ``.. kernel-include::``
> directive to the new ``.. kernel-cmd::`` directive.
> 
> To avoid breaking bisect, this patch includes the required changes to
> the implementation (script ``parse-headers.pl``) and the content (*.rst
> files).

It is a way easier to review this patch if you do a diff with the
-M option, as below.

---

doc-rst: migrated media build kernel-cmd directive

From: Markus Heiser 

Remove the media-Makefile and migrate the ``.. kernel-include::``
directive to the new ``.. kernel-cmd::`` directive.

To avoid breaking bisect, this patch includes the required changes to
the implementation (script ``parse-headers.pl``) and the content (*.rst
files).

Signed-off-by: Markus Heiser 

 Documentation/Makefile.sphinx  |  2 +-
 Documentation/media/Makefile   | 61 --
 Documentation/media/uapi/cec/cec-header.rst|  3 +-
 .../cec/cec.h.exceptions}  |  0
 .../dvb/audio.h.exceptions}|  0
 Documentation/media/uapi/dvb/audio_h.rst   |  2 +-
 .../dvb/ca.h.exceptions}   |  0
 Documentation/media/uapi/dvb/ca_h.rst  |  2 +-
 .../dvb/dmx.h.exceptions}  |  0
 Documentation/media/uapi/dvb/dmx_h.rst |  2 +-
 .../dvb/frontend.h.exceptions} |  0
 Documentation/media/uapi/dvb/frontend_h.rst|  2 +-
 .../dvb/net.h.exceptions}  |  0
 Documentation/media/uapi/dvb/net_h.rst |  2 +-
 .../dvb/video.h.exceptions}|  0
 Documentation/media/uapi/dvb/video_h.rst   |  2 +-
 Documentation/media/uapi/mediactl/media-header.rst |  3 +-
 .../mediactl/media.h.exceptions}   |  0
 Documentation/media/uapi/rc/lirc-header.rst|  2 +-
 .../rc/lirc.h.exceptions}  |  0
 Documentation/media/uapi/v4l/videodev.rst  |  2 +-
 .../v4l/videodev2.h.exceptions}|  0
 Documentation/sphinx/parse-headers.pl  | 17 +++---
 23 files changed, 18 insertions(+), 84 deletions(-)


diff --git a/Documentation/Makefile.sphinx b/Documentation/Makefile.sphinx
index 92deea30b183..2e033e4e0e60 100644
--- a/Documentation/Makefile.sphinx
+++ b/Documentation/Makefile.sphinx
@@ -52,7 +52,7 @@ loop_cmd = $(echo-cmd) $(cmd_$(1))
 #e.g. "media" for the linux-tv book-set at ./Documentation/media
 
 quiet_cmd_sphinx = SPHINX  $@ --> file://$(abspath $(BUILDDIR)/$3/$4);
-  cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) 
$(build)=Documentation/media all;\
+  cmd_sphinx = \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath 
$(srctree)/$(src)/$5/$(SPHINX_CONF)) \
$(SPHINXBUILD) \
-b $2 \
diff --git a/Documentation/media/Makefile b/Documentation/media/Makefile
deleted file mode 100644
index a7fb35291f6c..
--- a/Documentation/media/Makefile
+++ /dev/null
@@ -1,61 +0,0 @@
-# Generate the *.h.rst files from uAPI headers
-
-PARSER = $(srctree)/Documentation/sphinx/parse-headers.pl
-UAPI = $(srctree)/include/uapi/linux
-KAPI = $(srctree)/include/linux
-SRC_DIR=$(srctree)/Documentation/media
-
-FILES = audio.h.rst ca.h.rst dmx.h.rst frontend.h.rst net.h.rst video.h.rst \
- videodev2.h.rst media.h.rst cec.h.rst lirc.h.rst
-
-TARGETS := $(addprefix $(BUILDDIR)/, $(FILES))
-
-.PHONY: all
-all: $(BUILDDIR) ${TARGETS}
-
-$(BUILDDIR):
-   $(Q)mkdir -p $@
-
-# Rule to convert a .h file to inline RST documentation
-
-gen_rst = \
-   echo ${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions; \
-   ${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions
-
-quiet_gen_rst = echo '  PARSE   $(patsubst $(srctree)/%,%,$<)'; \
-   ${PARSER} $< $@ $(SRC_DIR)/$(notdir $@).exceptions
-
-silent_gen_rst = ${gen_rst}
-
-$(BUILDDIR)/audio.h.rst: ${UAPI}/dvb/audio.h ${PARSER} 
$(SRC_DIR)/audio.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/ca.h.rst: ${UAPI}/dvb/ca.h ${PARSER} $(SRC_DIR)/ca.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/dmx.h.rst: ${UAPI}/dvb/dmx.h ${PARSER} 
$(SRC_DIR)/dmx.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/frontend.h.rst: ${UAPI}/dvb/frontend.h ${PARSER} 
$(SRC_DIR)/frontend.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/net.h.rst: ${UAPI}/dvb/net.h ${PARSER} 
$(SRC_DIR)/net.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/video.h.rst: ${UAPI}/dvb/video.h ${PARSER} 
$(SRC_DIR)/video.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/videodev2.h.rst: ${UAPI}/videodev2.h ${PARSER} 
$(SRC_DIR)/videodev2.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/media.h.rst: ${UAPI}/media.h ${PARSER} 
$(SRC_DIR)/media.h.rst.exceptions
-   @$($(quiet)gen_rst)
-
-$(BUILDDIR)/cec.h.rst: ${KAPI}/cec.h ${PARSER} $(S

Re: [PATCH v9 2/4] drm: Add API for capturing frame CRCs

[Emil Velikov]

On 6 October 2016 at 12:33, Tomeu Vizoso  wrote:
> On 10/06/2016 01:13 PM, Emil Velikov wrote:
>> On 6 October 2016 at 09:56, Tomeu Vizoso  wrote:
>>> Adds files and directories to debugfs for controlling and reading frame
>>> CRCs, per CRTC:
>>>
>>> dri/0/crtc-0/crc
>>> dri/0/crtc-0/crc/control
>>> dri/0/crtc-0/crc/data
>>>
>>> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
>>> start and stop generating frame CRCs and can add entries to the output
>>> by calling drm_crtc_add_crc_entry.
>>>
>>> v2:
>>> - Lots of good fixes suggested by Thierry.
>>> - Added documentation.
>>> - Changed the debugfs layout.
>>> - Moved to allocate the entries circular queue once when frame
>>>   generation gets enabled for the first time.
>>> v3:
>>> - Use the control file just to select the source, and start and stop
>>>   capture when the data file is opened and closed, respectively.
>>> - Make variable the number of CRC values per entry, per source.
>>> - Allocate entries queue each time we start capturing as now there
>>>   isn't a fixed number of CRC values per entry.
>>> - Store the frame counter in the data file as a 8-digit hex number.
>>> - For sources that cannot provide useful frame numbers, place
>>>    in the frame field.
>>>
>>> v4:
>>> - Build only if CONFIG_DEBUG_FS is enabled.
>>> - Use memdup_user_nul.
>>> - Consolidate calculation of the size of an entry in a helper.
>>> - Add 0x prefix to hex numbers in the data file.
>>> - Remove unnecessary snprintf and strlen usage in read callback.
>>>
>>> v5:
>>> - Made the crcs array in drm_crtc_crc_entry fixed-size
>>> - Lots of other smaller improvements suggested by Emil Velikov
>>>
>>> v7:
>>> - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h
>>>
>>> v8:
>>> - Call debugfs_remove_recursive when we fail to create the minor
>>>   device
>>>
>>> v9:
>>> - Register the debugfs directory for a crtc from
>>>   drm_crtc_register_all()
>>>
>>> Signed-off-by: Tomeu Vizoso 
>>> ---
>>>
>>>  Documentation/gpu/drm-uapi.rst|   6 +
>>>  drivers/gpu/drm/Makefile  |   3 +-
>>>  drivers/gpu/drm/drm_crtc.c|  34 +++-
>>>  drivers/gpu/drm/drm_debugfs.c |  34 +++-
>>>  drivers/gpu/drm/drm_debugfs_crc.c | 351 
>>> ++
>>>  drivers/gpu/drm/drm_internal.h|  16 ++
>>>  include/drm/drm_crtc.h|  41 +
>>>  include/drm/drm_debugfs_crc.h |  73 
>>>  8 files changed, 555 insertions(+), 3 deletions(-)
>>>  create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
>>>  create mode 100644 include/drm/drm_debugfs_crc.h
>>>
>>> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
>>> index 1ba301cebe16..de3ac9f90f8f 100644
>>> --- a/Documentation/gpu/drm-uapi.rst
>>> +++ b/Documentation/gpu/drm-uapi.rst
>>> @@ -216,3 +216,9 @@ interfaces. Especially since all hardware-acceleration 
>>> interfaces to
>>>  userspace are driver specific for efficiency and other reasons these
>>>  interfaces can be rather substantial. Hence every driver has its own
>>>  chapter.
>>> +
>>> +Testing and validation
>>> +==
>>> +
>>> +.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
>>> +   :doc: CRC ABI
>>> diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
>>> index 25c720454017..74579d2e796e 100644
>>> --- a/drivers/gpu/drm/Makefile
>>> +++ b/drivers/gpu/drm/Makefile
>>> @@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
>>> drm_scatter.o drm_pci.o \
>>> drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
>>> drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
>>> -   drm_info.o drm_debugfs.o drm_encoder_slave.o \
>>> +   drm_info.o drm_encoder_slave.o \
>>> drm_trace_points.o drm_global.o drm_prime.o \
>>> drm_rect.o drm_vma_manager.o drm_flip_work.o \
>>> drm_modeset_lock.o drm_atomic.o drm_bridge.o \
>>> @@ -23,6 +23,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
>>>  drm-$(CONFIG_DRM_PANEL) += drm_panel.o
>>>  drm-$(CONFIG_OF) += drm_of.o
>>>  drm-$(CONFIG_AGP) += drm_agpsupport.o
>>> +drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
>>>
>>>  drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
>>> drm_plane_helper.o drm_dp_mst_topology.o 
>>> drm_atomic_helper.o \
>>> diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
>>> index 2d7bedf28647..151ff9805de1 100644
>>> --- a/drivers/gpu/drm/drm_crtc.c
>>> +++ b/drivers/gpu/drm/drm_crtc.c
>>> @@ -40,7 +40,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> -#include 
>>> +#include 
>>>
>>>  #include "drm_crtc_internal.h"
>>>  #include "drm_internal.h"
>>> @@ -126,6 +126,10 @@ static int drm_crtc_register_all(struct drm_device 
>>> *dev)
>>> ret = crtc->funcs->late_regi

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

[Parav Pandit]

Hi Christoph,

On Wed, Oct 5, 2016 at 12:07 PM, Christoph Hellwig  wrote:
> FYI, the patches look fine to me:
>
> Acked-by: Christoph Hellwig 
>
Thanks a lot for review.

Parav
--
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: [PATCHv12 0/3] rdmacg: IB/core: rdma controller support

[Parav Pandit]

Hi Leon,

On Wed, Oct 5, 2016 at 4:52 PM, Leon Romanovsky  wrote:
> On Wed, Aug 31, 2016 at 02:07:24PM +0530, Parav Pandit wrote:
>> rdmacg: IB/core: rdma controller support
>>
>> Patch is generated and tested against below Doug's linux-rdma
>> git tree.
>>
>> URL: git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
>> Branch: master
>>
>> Patchset is also compiled and tested against below Tejun's cgroup tree
>> using cgroup v2 mode.
>> URL: git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
>> Branch: master
>>
>> Overview:
>> Currently user space applications can easily take away all the rdma
>> device specific resources such as AH, CQ, QP, MR etc. Due to which other
>> applications in other cgroup or kernel space ULPs may not even get chance
>> to allocate any rdma resources. This results into service unavailibility.
>>
>> RDMA cgroup addresses this issue by allowing resource accounting,
>> limit enforcement on per cgroup, per rdma device basis.
>>
>> RDMA uverbs layer will enforce limits on well defined RDMA verb
>> resources without any HCA vendor device driver involvement.
>>
>> RDMA uverbs layer will not do limit enforcement of HCA hw vendor
>> specific resources. Instead rdma cgroup provides set of APIs
>> through which vendor specific drivers can do resource accounting
>> by making use of rdma cgroup.
>
> Hi Parav,
> I want to propose an extension to the RDMA cgroup which can be done as
> follow-up patches.
>

To bring logical end to this feature/patch discussion and to progress
towards merging it, Lets discuss this new feature in follow-on email
right after this email between these two mailing list and I will drop
linux kernel and docs mailing list.

> Let's add new global type, which will control whole HCA (for example in 
> percentages). It will
> allow natively define new objects without need to introduce them to the user.
>
> This HCA share will be overwritten by specific UVERBS types which you
> already defined.
>
> What do you think?
>
> Except this proposal,
> Reviewed-by: Leon Romanovsky 

Thanks a lot for review.

Parav
--
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] printk: introduce kptr_restrict level 3

[Roberts, William C]

> -Original Message-
> From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk]
> Sent: Wednesday, October 5, 2016 4:53 PM
> To: Roberts, William C 
> Cc: kernel-harden...@lists.openwall.com; cor...@lwn.net; linux-
> d...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
> 
> On Wed, Oct 05 2016, william.c.robe...@intel.com wrote:
> 
> > From: William Roberts 
> >
> > Some out-of-tree modules do not use %pK and just use %p, as it's the
> > common C paradigm for printing pointers. Because of this,
> > kptr_restrict has no affect on the output and thus, no way to contain
> > the kernel address leak.
> >
> > Introduce kptr_restrict level 3 that causes the kernel to treat %p as
> > if it was %pK and thus always prints zeros.
> >
> > Sample Output:
> > kptr_restrict == 2:
> > p: 604369f4
> > pK: 
> >
> > kptr_restrict == 3:
> > p: 
> > pK: 
> >
> > Signed-off-by: William Roberts 
> > ---
> >  Documentation/sysctl/kernel.txt |   3 ++
> >  kernel/sysctl.c |   3 +-
> >  lib/vsprintf.c  | 107 
> > 
> 
> That's a lot of changed lines. Why isn't this just

I moved the nested case into a static local function, I thought it was easier 
to read than the existing
nested switches. The other reason was so we didn't have kptr_restrict littering 
that code
and it was contained within the default and K values of the switch.

> 
> --- a/lib/vsprintf.c
> +++ b/lib/vsprintf.c
> @@ -1719,6 +1719,8 @@ char *pointer(const char *fmt, char *buf, char *end,
> void *ptr,
> case 'G':
> return flags_string(buf, end, ptr, fmt);
> }
> +   if (kptr_restrict == 3)
> +   ptr = NULL;
> spec.flags |= SMALL;
> if (spec.field_width == -1) {
> spec.field_width = default_width;
> 
> ?
--
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] printk: introduce kptr_restrict level 3

[Roberts, William C]

> -Original Message-
> From: keesc...@google.com [mailto:keesc...@google.com] On Behalf Of Kees
> Cook
> Sent: Wednesday, October 5, 2016 3:34 PM
> To: Roberts, William C 
> Cc: kernel-harden...@lists.openwall.com; Jonathan Corbet ;
> linux-doc@vger.kernel.org; LKML ; Nick
> Desaulniers ; Dave Weinstein 
> Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
> 
> On Wed, Oct 5, 2016 at 11:04 AM,   wrote:
> > From: William Roberts 
> >
> > Some out-of-tree modules do not use %pK and just use %p, as it's the
> > common C paradigm for printing pointers. Because of this,
> > kptr_restrict has no affect on the output and thus, no way to contain
> > the kernel address leak.
> 
> Solving this is certainly a good idea -- I'm all for finding a solid solution.
> 
> > Introduce kptr_restrict level 3 that causes the kernel to treat %p as
> > if it was %pK and thus always prints zeros.
> 
> I'm worried that this could break kernel internals where %p is being used and 
> not
> exposed to userspace. Maybe those situations don't exist...

Not saying they don't I didn't find any.

> 
> Regardless, I would rather do what Grsecurity has done in this area, and 
> whitelist
> known-safe values instead. For example, they have %pP for approved pointers,
> and %pX for approved
> dereference_function_descriptor() output. Everything else is censored if it 
> is a
> value in kernel memory and destined for a user-space memory
> buffer:
> 
> if ((unsigned long)ptr > TASK_SIZE && *fmt != 'P' && *fmt != 'X' && 
> *fmt !=
> 'K' && is_usercopy_object(buf)) {
> printk(KERN_ALERT "grsec: kernel infoleak detected!
> Please report this log to spen...@grsecurity.net.\n");
> dump_stack();
> ptr = NULL;
> }
> 
> The "is_usercopy_object()" test is something we can add, which is testing for 
> a
> new SLAB flag that is used to mark slab caches as either used by user-space or
> not, which is done also through whitelisting.
> (For more details on this, see:
> http://www.openwall.com/lists/kernel-hardening/2016/06/08/10)
> 
> Would you have time/interest to add the slab flags and is_usercopy_object()?
> The hardened usercopy part of the slab whitelisting can be separate, since it 
> likely
> needs a different usercopy interface to sanely integrate with upstream.

I could likely take this on. I would need to read up on the links and have a 
better concept
of what it is.

> 
> -Kees
> 
> --
> Kees Cook
> Nexus Security
N�r��yb�X��ǧv�^�)޺{.n�+{�v�"��^n�r���z���h�&���G���h�(�階�ݢj"���m��z�ޖ���f���h���~�m�

Re: [PATCH] printk: introduce kptr_restrict level 3

[Christoph Hellwig]

On Wed, Oct 05, 2016 at 02:04:46PM -0400, william.c.robe...@intel.com wrote:
> From: William Roberts 
> 
> Some out-of-tree modules do not use %pK and just use %p, as it's
> the common C paradigm for printing pointers. Because of this,
> kptr_restrict has no affect on the output and thus, no way to
> contain the kernel address leak.

So what?  We a) don't care about out of tree modules and b) you could
just triviall fix them up if you care.

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

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

[Mauro Carvalho Chehab]

Em Thu, 06 Oct 2016 11:42:14 +0300
Jani Nikula  escreveu:

> On Thu, 06 Oct 2016, Markus Heiser  wrote:
> > with this series a reST-directive kernel-cmd is introduced. The kernel-cmd
> > directive includes contend from the stdout of a command-line (@mchehab asked
> > for).  

Ok, I ran some tests here and it works as expected.

> I like the fact that this removes Documentation/media/Makefile, and
> cleans up the Sphinx build rule in Documentation/Makefile.sphinx.

Yeah, that sounds great.

> Does
> this also make the documentation buildable with sphinx-build directly,
> without the kernel build system? If so, great.

I guess it probably allows that, if you include the extension on
some other tree.

Just curious here: what use case do you see by building the Kernel
documentation without the Kernel tree?

> However, I would have much preferred the approach I proposed months ago,
> having the extension itself do specifically what parse-headers.pl does
> now. While it may seem generic on the surface, I don't think it's a
> clean or a secure approach to allow running of arbitrary scripts from
> PATH while building documentation. It's certainly not an approach that
> should be encouraged.

Sorry, but I disagree. The security threat of having a random command
doing something wrong is the same as we already have with the Kernel
Makefiles, as they can also run a random command. All it is needed
is to add this to a Makefile:

subdir-y += run_some_evil_cmd

If we accept the fact that we do need to run commands when running "make",
it doesn't really matter if such command is at a makefile, inside a 
perl/python script or called via some Sphinx directive. In all cases,
patches need to be reviewed by the community, to be sure that they won't
introduce any vulnerabilities.

Btw, with regards to security, a way bigger threat is if someone
introduces a vulnerable code inside the Kernel code, as this will
affect a lot more systems than a vulnerability at the documentation
build process.

Yet, if you think security is still a high risk, my suggestion
would be to restrict the kernel-cmd script to only run scripts
inside trusted places, like Documentation/sphinx.


-

The real issue here is that Sphinx itself doesn't provide what
it is needed to build the Kernel documentation. Some extra
scripts are required. Right now, we converted maybe 5% of the
documentation to ReST, and we're using running two perl scripts:
- kernel-doc
- parse-headers.pl

We also identified that, if we want to add the MAINTAINERS file to
some documentation (or a parsed version of it), we would need an extra
script to filter it[1].

I can think on other use cases to run such scripts[2].

What I'm saying is that, we can keep adding a Sphinx-specific
extension for every such needs, with will result in code duplication
and will make harder to maintain it, or we can use a generic
solution like this kernel-cmd extension.

IMO, a generic solution is a way better, as it sounds easier to
maintain.

Regards,
Mauro

[1] 
https://git.linuxtv.org/mchehab/experimental.git/commit/?h=lkml-books&id=c8b07684c0278d7f9d0e30f575eb4be3a2da4c3b

[2] There's another possible usecase, with I'm not convinced yet
whether should be addressed or not.

At the media subsystem, we use 8 out-of-tree scripts that update
the list of supported USB and PCI media boards, e. g. the files under:
Documentation/media/v4l-drivers/*cardlist.rst

Such scripts used to be part of the mercurial tree, before we moved the 
media development to git, like this one:
https://linuxtv.org/hg/v4l-dvb/file/3724e93f7af5/v4l/scripts/bttv.pl

Currently, I'm using a local fork of the old scripts, and, when I
notice a patch for a driver with a cardlist, if I remember, I run the
scripts to add to update the cardlists. While it could be kept
OOT forever, if moved it to the Kernel tree,  the documentation will 
always reflect the Kernel status, with is, IMHO, a good thing.
--
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] printk: introduce kptr_restrict level 3

[Roberts, William C]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Thursday, October 6, 2016 9:32 AM
> To: Roberts, William C 
> Cc: kernel-harden...@lists.openwall.com; cor...@lwn.net; linux-
> d...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
> 
> On Wed, Oct 05, 2016 at 02:04:46PM -0400, william.c.robe...@intel.com wrote:
> > From: William Roberts 
> >
> > Some out-of-tree modules do not use %pK and just use %p, as it's the
> > common C paradigm for printing pointers. Because of this,
> > kptr_restrict has no affect on the output and thus, no way to contain
> > the kernel address leak.
> 
> So what?  We a) don't care about out of tree modules and b) you could just 
> triviall
> fix them up if you care.

Out of tree modules still affect core kernel security. I would also bet money, 
that somewhere
In-tree someone has put a %p when they wanted a %pK. So this method is just 
quite error
prone. We currently have a blacklist approach versus whitelist.

> 
> No need to bloat the kernel with crap like this.

It's unconstructive comments like this that do the whole community harm. Notice 
how
responses from Kees Cook were aimed at finding a different solution to the 
problem and were
very constructive. As far as "bloating" goes, it really didn't change a whole 
lot, most of it was moved
lines, and adds maybe a few lines of code.

--
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] printk: introduce kptr_restrict level 3

[Christoph Hellwig]

On Thu, Oct 06, 2016 at 01:47:47PM +, Roberts, William C wrote:
> Out of tree modules still affect core kernel security.

So don't use them.

> I would also bet money, that somewhere
> In-tree someone has put a %p when they wanted a %pK.

So fix them.

> So this method is just quite error
> prone. We currently have a blacklist approach versus whitelist.

Or fix the entire thing, get rid of %pK and always protect %p if you
can show that it doesn't break anything.

But stop posting patches with bullshit arguments like out of tree
modules.
--
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] RE: [PATCH] printk: introduce kptr_restrict level 3

[Jann Horn]

On Thu, Oct 06, 2016 at 01:47:47PM +, Roberts, William C wrote:
> > -Original Message-
> > From: Christoph Hellwig [mailto:h...@infradead.org]
> > Sent: Thursday, October 6, 2016 9:32 AM
> > To: Roberts, William C 
> > Cc: kernel-harden...@lists.openwall.com; cor...@lwn.net; linux-
> > d...@vger.kernel.org; linux-ker...@vger.kernel.org
> > Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
> > 
> > On Wed, Oct 05, 2016 at 02:04:46PM -0400, william.c.robe...@intel.com wrote:
> > > From: William Roberts 
> > >
> > > Some out-of-tree modules do not use %pK and just use %p, as it's the
> > > common C paradigm for printing pointers. Because of this,
> > > kptr_restrict has no affect on the output and thus, no way to contain
> > > the kernel address leak.
> > 
> > So what?  We a) don't care about out of tree modules and b) you could just 
> > triviall
> > fix them up if you care.
> 
> Out of tree modules still affect core kernel security. I would also bet 
> money, that somewhere
> In-tree someone has put a %p when they wanted a %pK. So this method is just 
> quite error
> prone. We currently have a blacklist approach versus whitelist.

grep says you have a point:

$ grep -IR 'seq_printf.*%p[^FfSsBRrhbMmIiEUVKNadCDgG].*&'
drivers/dma/qcom/hidma_dbg.c:   seq_printf(s, "dev_trca=%p\n", 
&dmadev->dev_trca);
drivers/dma/qcom/hidma_dbg.c:   seq_printf(s, "dev_evca=%p\n", 
&dmadev->dev_evca);

$ grep -IR 'pr_info.*%p[^FfSsBRrhbMmIiEUVKNadCDgG].*&'
drivers/misc/lkdtm_heap.c:  pr_info("Allocated memory %p-%p\n", base, 
&base[offset * 2]);

$ grep -IR 'pr_err.*%p[^FfSsBRrhbMmIiEUVKNadCDgG].*&'
drivers/net/ethernet/qlogic/qlge/qlge_dbg.c:pr_err("rx_ring->cqicb = %p\n", 
&rx_ring->cqicb);

And these are just trivially greppable, low-hanging-fruit ones.
With somewhat broader greps, there seem to be lots more, but they'd
require manual review.

And in total, there are 13578 matches for %p[^FfSsBRrhbMmIiEUVKNadCDgG]
throughout the kernel. Reviewing all of those manually would suck.


signature.asc
Description: Digital signature

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

[Jani Nikula]

On Thu, 06 Oct 2016, Mauro Carvalho Chehab  wrote:
> Em Thu, 06 Oct 2016 11:42:14 +0300
> Jani Nikula  escreveu:
> Just curious here: what use case do you see by building the Kernel
> documentation without the Kernel tree?

Not without the kernel tree, but without the kernel build system. If
sphinx-build works directly, https://readthedocs.org/ just works when
you point it at a kernel git repo and the conf.py inside it.

It would be important to get Sphinx working over at
https://www.kernel.org/doc/htmldocs/ (which still looks kind of sad) but
in the mean time we could have had that at https://readthedocs.org/. If
it weren't for parse-headers.pl and the build hacks around it.

At least there's one at https://01.org/linuxgraphics/gfx-docs/drm/ now.

>> However, I would have much preferred the approach I proposed months ago,
>> having the extension itself do specifically what parse-headers.pl does
>> now. While it may seem generic on the surface, I don't think it's a
>> clean or a secure approach to allow running of arbitrary scripts from
>> PATH while building documentation. It's certainly not an approach that
>> should be encouraged.
>
> Sorry, but I disagree. The security threat of having a random command
> doing something wrong is the same as we already have with the Kernel
> Makefiles, as they can also run a random command. All it is needed
> is to add this to a Makefile:

My intention was to emphasize the importance of the clarity of the
documentation build, and not get hung up on the security aspect.

This is connected to the above: keeping documentation buildable with
sphinx-build directly will force you to avoid the Makefile hacks.

> IMO, a generic solution is a way better, as it sounds easier to
> maintain.

We've seen what happens when we make it easy to add random scripts to
build documentation. We've worked hard to get rid of that. In my books,
one of the bigger points in favor of Sphinx over AsciiDoc(tor) was
getting rid of all the hacks required in the build. Things that broke in
subtle ways.

I think having people write Sphinx extensions for the special needs have
a better chance of solving the problems in more generic ways than
writing scripts for each specific need. Ideally, we can push those
extensions to upstream Sphinx, but at least make them easily usable
across the kernel documentation.

Case in point, parse-headers.pl was added for a specific need of media
documentation, and for the life of me I can't figure out by reading the
script what good, if any, it would be for gpu documentation. I call
*that* unmaintainable.


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: [kernel-hardening] RE: [PATCH] printk: introduce kptr_restrict level 3

[Jann Horn]

On Thu, Oct 06, 2016 at 04:05:53PM +0200, Jann Horn wrote:
> On Thu, Oct 06, 2016 at 01:47:47PM +, Roberts, William C wrote:
> > > -Original Message-
> > > From: Christoph Hellwig [mailto:h...@infradead.org]
> > > Sent: Thursday, October 6, 2016 9:32 AM
> > > To: Roberts, William C 
> > > Cc: kernel-harden...@lists.openwall.com; cor...@lwn.net; linux-
> > > d...@vger.kernel.org; linux-ker...@vger.kernel.org
> > > Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
> > > 
> > > On Wed, Oct 05, 2016 at 02:04:46PM -0400, william.c.robe...@intel.com 
> > > wrote:
> > > > From: William Roberts 
> > > >
> > > > Some out-of-tree modules do not use %pK and just use %p, as it's the
> > > > common C paradigm for printing pointers. Because of this,
> > > > kptr_restrict has no affect on the output and thus, no way to contain
> > > > the kernel address leak.
> > > 
> > > So what?  We a) don't care about out of tree modules and b) you could 
> > > just triviall
> > > fix them up if you care.
> > 
> > Out of tree modules still affect core kernel security. I would also bet 
> > money, that somewhere
> > In-tree someone has put a %p when they wanted a %pK. So this method is just 
> > quite error
> > prone. We currently have a blacklist approach versus whitelist.
> 
> grep says you have a point:
> 
> $ grep -IR 'seq_printf.*%p[^FfSsBRrhbMmIiEUVKNadCDgG].*&'
> drivers/dma/qcom/hidma_dbg.c: seq_printf(s, "dev_trca=%p\n", 
> &dmadev->dev_trca);
> drivers/dma/qcom/hidma_dbg.c: seq_printf(s, "dev_evca=%p\n", 
> &dmadev->dev_evca);
> 
> $ grep -IR 'pr_info.*%p[^FfSsBRrhbMmIiEUVKNadCDgG].*&'
> drivers/misc/lkdtm_heap.c:pr_info("Allocated memory %p-%p\n", base, 
> &base[offset * 2]);
> 
> $ grep -IR 'pr_err.*%p[^FfSsBRrhbMmIiEUVKNadCDgG].*&'
> drivers/net/ethernet/qlogic/qlge/qlge_dbg.c:  pr_err("rx_ring->cqicb = %p\n", 
> &rx_ring->cqicb);
> 
> And these are just trivially greppable, low-hanging-fruit ones.
> With somewhat broader greps, there seem to be lots more, but they'd
> require manual review.

(Although, of course, most matches for seq_printf are in debugfs
files or stuff that's only enabled with some DEBUG config option
or so. But there are also e.g. pr_warn() users of %p that are not
in debug code.)


signature.asc
Description: Digital signature

RE: [PATCH] printk: introduce kptr_restrict level 3

[Roberts, William C]

> -Original Message-
> From: Christoph Hellwig [mailto:h...@infradead.org]
> Sent: Thursday, October 6, 2016 9:56 AM
> To: Roberts, William C 
> Cc: Christoph Hellwig ; kernel-
> harden...@lists.openwall.com; cor...@lwn.net; linux-doc@vger.kernel.org;
> linux-ker...@vger.kernel.org
> Subject: Re: [PATCH] printk: introduce kptr_restrict level 3
> 
> On Thu, Oct 06, 2016 at 01:47:47PM +, Roberts, William C wrote:
> > Out of tree modules still affect core kernel security.
> 
> So don't use them.
> 
> > I would also bet money, that somewhere In-tree someone has put a %p
> > when they wanted a %pK.
> 
> So fix them.

As Jann Horn points out, "And in total, there are 13578 matches for 
%p[^FfSsBRrhbMmIiEUVKNadCDgG] throughout the kernel. Reviewing all of those 
manually would suck."

> 
> > So this method is just quite error
> > prone. We currently have a blacklist approach versus whitelist.
> 
> Or fix the entire thing, get rid of %pK and always protect %p if you can show 
> that
> it doesn't break anything.
> 
> But stop posting patches with bullshit arguments like out of tree modules.

Ok perhaps the commit message sucks, and I should have included the large 
spread usages of %p throughout
the kernel, I assumed those would just be known, I shouldn't have made that 
assumption.

We should care about out-of-tree modules wrt security as they affect the 
security of the whole system, especially when the
modules are linking to core symbols like printing and string routines. There 
are tons of %p usages throughout the
kernel as noted above.

This is pretty low hanging fruit and we should fix this, as Kees points out.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v10 0/4] New debugfs API for capturing CRC of frames

[Tomeu Vizoso]

Hi,

this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.

The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.

Other drivers for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.

In this v10 debugfs creation failures don't abort CRTC registration, as
suggested by Emil Velikov.

Thanks,

Tomeu


Tomeu Vizoso (4):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API
  drm/i915: Put "cooked" vlank counters in frame CRC lines

 Documentation/gpu/drm-uapi.rst|6 +
 drivers/gpu/drm/Makefile  |3 +-
 drivers/gpu/drm/drm_crtc.c|   34 +-
 drivers/gpu/drm/drm_debugfs.c |   34 +-
 drivers/gpu/drm/drm_debugfs_crc.c |  351 
 drivers/gpu/drm/drm_internal.h|   16 +
 drivers/gpu/drm/i915/Makefile |2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  886 +---
 drivers/gpu/drm/i915/i915_drv.h   |1 +
 drivers/gpu/drm/i915/i915_irq.c   |   83 ++-
 drivers/gpu/drm/i915/intel_display.c  |1 +
 drivers/gpu/drm/i915/intel_drv.h  |   13 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 1013 +
 include/drm/drm_crtc.h|   41 ++
 include/drm/drm_debugfs_crc.h |   73 +++
 15 files changed, 1645 insertions(+), 912 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

-- 
2.7.4

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

[PATCH v10 2/4] drm: Add API for capturing frame CRCs

[Tomeu Vizoso]

Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:

dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data

Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
by calling drm_crtc_add_crc_entry.

v2:
- Lots of good fixes suggested by Thierry.
- Added documentation.
- Changed the debugfs layout.
- Moved to allocate the entries circular queue once when frame
  generation gets enabled for the first time.
v3:
- Use the control file just to select the source, and start and stop
  capture when the data file is opened and closed, respectively.
- Make variable the number of CRC values per entry, per source.
- Allocate entries queue each time we start capturing as now there
  isn't a fixed number of CRC values per entry.
- Store the frame counter in the data file as a 8-digit hex number.
- For sources that cannot provide useful frame numbers, place
   in the frame field.

v4:
- Build only if CONFIG_DEBUG_FS is enabled.
- Use memdup_user_nul.
- Consolidate calculation of the size of an entry in a helper.
- Add 0x prefix to hex numbers in the data file.
- Remove unnecessary snprintf and strlen usage in read callback.

v5:
- Made the crcs array in drm_crtc_crc_entry fixed-size
- Lots of other smaller improvements suggested by Emil Velikov

v7:
- Move definition of drm_debugfs_crtc_crc_add to drm_internal.h

v8:
- Call debugfs_remove_recursive when we fail to create the minor
  device

v9:
- Register the debugfs directory for a crtc from
  drm_crtc_register_all()

v10:
- Don't let debugfs failures interrupt CRTC registration (Emil
  Velikov)

Signed-off-by: Tomeu Vizoso 
---

 Documentation/gpu/drm-uapi.rst|   6 +
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_crtc.c|  34 +++-
 drivers/gpu/drm/drm_debugfs.c |  34 +++-
 drivers/gpu/drm/drm_debugfs_crc.c | 351 ++
 drivers/gpu/drm/drm_internal.h|  16 ++
 include/drm/drm_crtc.h|  41 +
 include/drm/drm_debugfs_crc.h |  73 
 8 files changed, 555 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 1ba301cebe16..de3ac9f90f8f 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -216,3 +216,9 @@ interfaces. Especially since all hardware-acceleration 
interfaces to
 userspace are driver specific for efficiency and other reasons these
 interfaces can be rather substantial. Hence every driver has its own
 chapter.
+
+Testing and validation
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
+   :doc: CRC ABI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 25c720454017..74579d2e796e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
drm_scatter.o drm_pci.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
-   drm_info.o drm_debugfs.o drm_encoder_slave.o \
+   drm_info.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
@@ -23,6 +23,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
+drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2d7bedf28647..b9891a724437 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -122,6 +122,10 @@ static int drm_crtc_register_all(struct drm_device *dev)
int ret = 0;
 
drm_for_each_crtc(crtc, dev) {
+   if (drm_debugfs_crtc_add(crtc)) {
+   DRM_ERROR("Failed to initialize debugfs entry for CRTC 
'%s'.\n",
+ crtc->name);
+
if (crtc->funcs->late_register)
ret = crtc->funcs->late_register(crtc);
if (ret)
@@ -138,9 +142,29 @@ static void drm_crtc_unregister_all(struct drm_device *dev)
drm_for_each_crtc(crtc, dev) {
if (crtc->funcs->early_unregister)

[PATCH v11 0/4] New debugfs API for capturing CRC of frames

[Tomeu Vizoso]

Hi,

this series basically takes the facility for continuously capturing CRCs
of frames from the i915 driver and into the DRM core.

The idea is that test suites such as IGT use this information to check
that frames that are exected to be identical, also have identical CRC
values.

Other drivers for hardware that can provide frame CRCs (including eDP
panels that support self-refresh) can easily implement the new callback
and provide userspace with the CRC values.

Sorry about that, but there was a dangling brace in v10 breaking the build so
here is this v11.

Thanks,

Tomeu


Tomeu Vizoso (4):
  drm/i915/debugfs: Move out pipe CRC code
  drm: Add API for capturing frame CRCs
  drm/i915: Use new CRC debugfs API
  drm/i915: Put "cooked" vlank counters in frame CRC lines

 Documentation/gpu/drm-uapi.rst|6 +
 drivers/gpu/drm/Makefile  |3 +-
 drivers/gpu/drm/drm_crtc.c|   34 +-
 drivers/gpu/drm/drm_debugfs.c |   34 +-
 drivers/gpu/drm/drm_debugfs_crc.c |  351 
 drivers/gpu/drm/drm_internal.h|   16 +
 drivers/gpu/drm/i915/Makefile |2 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |  886 +---
 drivers/gpu/drm/i915/i915_drv.h   |1 +
 drivers/gpu/drm/i915/i915_irq.c   |   83 ++-
 drivers/gpu/drm/i915/intel_display.c  |1 +
 drivers/gpu/drm/i915/intel_drv.h  |   13 +
 drivers/gpu/drm/i915/intel_pipe_crc.c | 1013 +
 include/drm/drm_crtc.h|   41 ++
 include/drm/drm_debugfs_crc.h |   73 +++
 15 files changed, 1645 insertions(+), 912 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 drivers/gpu/drm/i915/intel_pipe_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

-- 
2.7.4

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

[PATCH v11 2/4] drm: Add API for capturing frame CRCs

[Tomeu Vizoso]

Adds files and directories to debugfs for controlling and reading frame
CRCs, per CRTC:

dri/0/crtc-0/crc
dri/0/crtc-0/crc/control
dri/0/crtc-0/crc/data

Drivers can implement the set_crc_source callback() in drm_crtc_funcs to
start and stop generating frame CRCs and can add entries to the output
by calling drm_crtc_add_crc_entry.

v2:
- Lots of good fixes suggested by Thierry.
- Added documentation.
- Changed the debugfs layout.
- Moved to allocate the entries circular queue once when frame
  generation gets enabled for the first time.
v3:
- Use the control file just to select the source, and start and stop
  capture when the data file is opened and closed, respectively.
- Make variable the number of CRC values per entry, per source.
- Allocate entries queue each time we start capturing as now there
  isn't a fixed number of CRC values per entry.
- Store the frame counter in the data file as a 8-digit hex number.
- For sources that cannot provide useful frame numbers, place
   in the frame field.

v4:
- Build only if CONFIG_DEBUG_FS is enabled.
- Use memdup_user_nul.
- Consolidate calculation of the size of an entry in a helper.
- Add 0x prefix to hex numbers in the data file.
- Remove unnecessary snprintf and strlen usage in read callback.

v5:
- Made the crcs array in drm_crtc_crc_entry fixed-size
- Lots of other smaller improvements suggested by Emil Velikov

v7:
- Move definition of drm_debugfs_crtc_crc_add to drm_internal.h

v8:
- Call debugfs_remove_recursive when we fail to create the minor
  device

v9:
- Register the debugfs directory for a crtc from
  drm_crtc_register_all()

v10:
- Don't let debugfs failures interrupt CRTC registration (Emil
  Velikov)

v11:
- Remove extra brace that broke compilation. Sorry!

Signed-off-by: Tomeu Vizoso 
---

 Documentation/gpu/drm-uapi.rst|   6 +
 drivers/gpu/drm/Makefile  |   3 +-
 drivers/gpu/drm/drm_crtc.c|  34 +++-
 drivers/gpu/drm/drm_debugfs.c |  34 +++-
 drivers/gpu/drm/drm_debugfs_crc.c | 351 ++
 drivers/gpu/drm/drm_internal.h|  16 ++
 include/drm/drm_crtc.h|  41 +
 include/drm/drm_debugfs_crc.h |  73 
 8 files changed, 555 insertions(+), 3 deletions(-)
 create mode 100644 drivers/gpu/drm/drm_debugfs_crc.c
 create mode 100644 include/drm/drm_debugfs_crc.h

diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
index 1ba301cebe16..de3ac9f90f8f 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -216,3 +216,9 @@ interfaces. Especially since all hardware-acceleration 
interfaces to
 userspace are driver specific for efficiency and other reasons these
 interfaces can be rather substantial. Hence every driver has its own
 chapter.
+
+Testing and validation
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_debugfs_crc.c
+   :doc: CRC ABI
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 25c720454017..74579d2e796e 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -9,7 +9,7 @@ drm-y   :=  drm_auth.o drm_bufs.o drm_cache.o \
drm_scatter.o drm_pci.o \
drm_platform.o drm_sysfs.o drm_hashtab.o drm_mm.o \
drm_crtc.o drm_fourcc.o drm_modes.o drm_edid.o \
-   drm_info.o drm_debugfs.o drm_encoder_slave.o \
+   drm_info.o drm_encoder_slave.o \
drm_trace_points.o drm_global.o drm_prime.o \
drm_rect.o drm_vma_manager.o drm_flip_work.o \
drm_modeset_lock.o drm_atomic.o drm_bridge.o \
@@ -23,6 +23,7 @@ drm-$(CONFIG_PCI) += ati_pcigart.o
 drm-$(CONFIG_DRM_PANEL) += drm_panel.o
 drm-$(CONFIG_OF) += drm_of.o
 drm-$(CONFIG_AGP) += drm_agpsupport.o
+drm-$(CONFIG_DEBUG_FS) += drm_debugfs.o drm_debugfs_crc.o
 
 drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \
drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o \
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 2d7bedf28647..60403bf7a4ff 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -40,7 +40,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #include "drm_crtc_internal.h"
 #include "drm_internal.h"
@@ -122,6 +122,10 @@ static int drm_crtc_register_all(struct drm_device *dev)
int ret = 0;
 
drm_for_each_crtc(crtc, dev) {
+   if (drm_debugfs_crtc_add(crtc))
+   DRM_ERROR("Failed to initialize debugfs entry for CRTC 
'%s'.\n",
+ crtc->name);
+
if (crtc->funcs->late_register)
ret = crtc->funcs->late_register(crtc);
if (ret)
@@ -138,9 +142,29 @@ static void drm_crtc_unregister_all(struct drm_device *dev)
drm_for_each_crtc(crtc, dev) {
   

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

[Mauro Carvalho Chehab]

Em Thu, 06 Oct 2016 17:21:36 +0300
Jani Nikula  escreveu:

> On Thu, 06 Oct 2016, Mauro Carvalho Chehab  wrote:
> > Em Thu, 06 Oct 2016 11:42:14 +0300
> > Jani Nikula  escreveu:
> > Just curious here: what use case do you see by building the Kernel
> > documentation without the Kernel tree?  
> 
> Not without the kernel tree, but without the kernel build system. If
> sphinx-build works directly, https://readthedocs.org/ just works when
> you point it at a kernel git repo and the conf.py inside it.
> 
> It would be important to get Sphinx working over at
> https://www.kernel.org/doc/htmldocs/ (which still looks kind of sad) but
> in the mean time we could have had that at https://readthedocs.org/. If
> it weren't for parse-headers.pl and the build hacks around it.

I'm not sure how readthedocs.org work, but if it doesn't use the
extensions inside the git tree, it won't work anyway, and if it uses,
it will run the right scripts, including kernel-doc and parse-headers.pl,
if our tree would contain kernel-cmd or a parse-headers extension.

In the specific case of kernel.org, fixing it to produce all docs
is likely just a matter of installing Sphinx there and be sure that
the documentation will be generated at the right place, like at an
output dir inside https://www.kernel.org/doc/Documentation/. 

I guess we could talk to kernel.org maintainers asking them to do that
for us.

It probably makes sense to create a global index.html file that will
point to both html DocBook and Sphinx output dirs, while we there are
still some DocBook files somewhere - or to finish their conversion for
Kernel 4.10.

> At least there's one at https://01.org/linuxgraphics/gfx-docs/drm/ now.

Good! We can also host a complete Sphinx output at linuxtv.org if 
worth. I'll likely do it anyway, in order to point to the user and
development-process books once we merge those patches, in order to do
some cleanup at the linux media wiki pages there.

> >> However, I would have much preferred the approach I proposed months ago,
> >> having the extension itself do specifically what parse-headers.pl does
> >> now. While it may seem generic on the surface, I don't think it's a
> >> clean or a secure approach to allow running of arbitrary scripts from
> >> PATH while building documentation. It's certainly not an approach that
> >> should be encouraged.  
> >
> > Sorry, but I disagree. The security threat of having a random command
> > doing something wrong is the same as we already have with the Kernel
> > Makefiles, as they can also run a random command. All it is needed
> > is to add this to a Makefile:  
> 
> My intention was to emphasize the importance of the clarity of the
> documentation build, and not get hung up on the security aspect.
> 
> This is connected to the above: keeping documentation buildable with
> sphinx-build directly will force you to avoid the Makefile hacks.

A generic kernel-cmd extension will avoid Makefile hacks. It will
also prevent the addition of a new extension for every new script
we may need to run, in order to cover the Sphinx deficiencies.

> > IMO, a generic solution is a way better, as it sounds easier to
> > maintain.  
> 
> We've seen what happens when we make it easy to add random scripts to
> build documentation. We've worked hard to get rid of that. In my books,
> one of the bigger points in favor of Sphinx over AsciiDoc(tor) was
> getting rid of all the hacks required in the build. Things that broke in
> subtle ways.

I really can't see what scripts it get rids. with both Sphinx and
AsciiDoc(tor), the kernel-doc perl/python script is still needed.

On media books, as Sphinx is incapable of generate cross-references
from C code to the documentation, we needed to add the parse_headers.pl.

So, at the end of the day, we still need the same scripts as before.

If the choice was for Doxygen, then we would get rid of both scripts,
at the price of needing to write tables in HTML, and the need to convert
all kernel-doc markups to Doxygen syntax, with would be worse, IMHO.

> I think having people write Sphinx extensions for the special needs have
> a better chance of solving the problems in more generic ways than
> writing scripts for each specific need. Ideally, we can push those
> extensions to upstream Sphinx, but at least make them easily usable
> across the kernel documentation.

Well, writing a Sphinx extension would require a deep knowledge about
Sphinx internals and a python programmer. As I don't have any, nor
intend to invest some time to be expert on writing Sphinx extensions
any time soon, it means that for me a Sphinx extension is unmaintainable.

> Case in point, parse-headers.pl was added for a specific need of media
> documentation, and for the life of me I can't figure out by reading the
> script what good, if any, it would be for gpu documentation. I call
> *that* unmaintainable.

Actually, parse-headers.pl was added to do something that Doxygen does for
a long time: if you include a file exa

Re: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP

[Davidlohr Bueso]

On Thu, 18 Aug 2016, Waiman Long wrote:


Currently, when down_read() fails, the active read locking isn't undone
until the rwsem_down_read_failed() function grabs the wait_lock. If the
wait_lock is contended, it may takes a while to get the lock. During
that period, writer lock stealing will be disabled because of the
active read lock.

This patch will release the active read lock ASAP so that writer lock
stealing can happen sooner. The only downside is when the reader is
the first one in the wait queue as it has to issue another atomic
operation to update the count.

On a 4-socket Haswell machine running on a 4.7-rc1 tip-based kernel,
the fio test with multithreaded randrw and randwrite tests on the
same file on a XFS partition on top of a NVDIMM with DAX were run,
the aggregated bandwidths before and after the patch were as follows:

 Test  BW before patch BW after patch  % change
   --- --  
 randrw1210 MB/s  1352 MB/s  +12%
 randwrite 1622 MB/s  1710 MB/s  +5.4%


Yeah, this is really a bad workload to make decisions on locking
heuristics imo - if I'm thinking of the same workload. Mainly because
concurrent buffered io to the same file isn't very realistic and you
end up pathologically pounding on i_rwsem (which used to be until
recently i_mutex until Al's parallel lookup/readdir). Obviously write
lock stealing wins in this case.

Thanks,
Davidlohr
--
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: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

[Waiman Long]

On 10/06/2016 01:47 AM, Davidlohr Bueso wrote:

On Wed, 05 Oct 2016, Waiman Long wrote:


diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
index 05a3785..1e6823a 100644
--- a/kernel/locking/osq_lock.c
+++ b/kernel/locking/osq_lock.c
@@ -12,6 +12,23 @@
 */
static DEFINE_PER_CPU_SHARED_ALIGNED(struct optimistic_spin_node, 
osq_node);


+enum mbtype {
+acquire,
+release,
+relaxed,
+};


No, please.


+
+static __always_inline int
+_atomic_cmpxchg_(const enum mbtype barrier, atomic_t *v, int old, 
int new)

+{
+if (barrier == acquire)
+return atomic_cmpxchg_acquire(v, old, new);
+else if (barrier == release)
+return atomic_cmpxchg_release(v, old, new);
+else
+return atomic_cmpxchg_relaxed(v, old, new);
+}


Things like the above are icky. How about something like below? I'm not
crazy about it, but there are other similar macros, ie lockref. We still
provide the osq_lock/unlock to imply acquire/release and the new _relaxed
flavor, as I agree that should be the correct naming

While I have not touched osq_wait_next(), the following are impacted:

- node->locked is now completely without ordering for _relaxed() 
(currently

its under smp_load_acquire, which does not match and the race is harmless
to begin with as we just iterate again. For the acquire flavor, it is 
always

formed with ctr dep + smp_rmb().

- If osq_lock() fails we never guarantee any ordering.

What do you think?

Thanks,
Davidlohr


Yes, I am OK with your change. However, I need some additional changes 
in osq_wait_next() as well. Either it is changed to use the release 
variants of atomic_cmpxchg and xchg or using macro like what you did 
with osq_lock and osq_unlock. The release variant is needed in the 
osq_lock(). As osq_wait_next() is only invoked in the failure path of 
osq_lock(), the barrier type doesn't really matter.


Cheers,
Longman
--
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: [RFC PATCH-tip v4 01/10] locking/osq: Make lock/unlock proper acquire/release barrier

[Jason Low]

On Wed, Oct 5, 2016 at 10:47 PM, Davidlohr Bueso  wrote:
> On Wed, 05 Oct 2016, Waiman Long wrote:
>
>> diff --git a/kernel/locking/osq_lock.c b/kernel/locking/osq_lock.c
>> index 05a3785..1e6823a 100644
>> --- a/kernel/locking/osq_lock.c
>> +++ b/kernel/locking/osq_lock.c
>> @@ -12,6 +12,23 @@
>>  */
>> static DEFINE_PER_CPU_SHARED_ALIGNED(struct optimistic_spin_node,
>> osq_node);
>>
>> +enum mbtype {
>> +acquire,
>> +release,
>> +relaxed,
>> +};
>
>
> No, please.
>
>> +
>> +static __always_inline int
>> +_atomic_cmpxchg_(const enum mbtype barrier, atomic_t *v, int old, int
>> new)
>> +{
>> +if (barrier == acquire)
>> +return atomic_cmpxchg_acquire(v, old, new);
>> +else if (barrier == release)
>> +return atomic_cmpxchg_release(v, old, new);
>> +else
>> +return atomic_cmpxchg_relaxed(v, old, new);
>> +}
>
>
> Things like the above are icky. How about something like below? I'm not
> crazy about it, but there are other similar macros, ie lockref. We still
> provide the osq_lock/unlock to imply acquire/release and the new _relaxed
> flavor, as I agree that should be the correct naming
>
> While I have not touched osq_wait_next(), the following are impacted:
>
> - node->locked is now completely without ordering for _relaxed() (currently
> its under smp_load_acquire, which does not match and the race is harmless
> to begin with as we just iterate again. For the acquire flavor, it is always
> formed with ctr dep + smp_rmb().
>
> - If osq_lock() fails we never guarantee any ordering.
>
> What do you think?

I think that this method looks cleaner than the version with the
conditionals and enum.

My first preference though would be to document that the current code
doesn't provide the acquire semantics. The thinking is that if OSQ is
just used internally as a queuing mechanism and isn't used as a
traditional lock guarding critical sections, then it may just be
misleading and just adds more complexity.

If we do want a separate acquire and relaxed variants, then I think
David's version using macros is a bit more in line with other locking
code.

Jason
--
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] printk: introduce kptr_restrict level 3

[Kees Cook]

On Thu, Oct 6, 2016 at 6:56 AM, Christoph Hellwig  wrote:
> On Thu, Oct 06, 2016 at 01:47:47PM +, Roberts, William C wrote:
> > On Thu, Oct 6, 2016 at 6:31 AM, Christoph Hellwig  
> > wrote:
> > > So what?  We a) don't care about out of tree modules and b) you could 
> > > just triviall
> > > fix them up if you care.
> >
> > Out of tree modules still affect core kernel security.
>
> So don't use them.

I'm really interested in keeping these discussions productive.
Declaring that the upstream kernel community (your implied "we")
doesn't care about out-of-tree code is both false and short-sighted.
Huge numbers of people depend on Linux on their phones, their IoT
devices, cars, etc, and huge volumes of those (unfortunately) are
running out-of-tree code.

This isn't about supporting some special interface that a single third
party driver uses; this is about robust engineering and security
practices that benefits everything, even out-of-tree code.

>> I would also bet money, that somewhere
>> In-tree someone has put a %p when they wanted a %pK.
>
> So fix them.

%pK is an ugly situation that I'd like to fix correctly. It was
designed originally as a blacklisting method, when it should have been
designed as a whitelist (as William mentions). This is what will need
fixing (and is what I was suggesting in my original reply to the
patch).

All that said, "so fix them" sounds very much like "just fix the bugs"
which is another troublesome attitude to have for dealing with
potential security flaws. The kernel community already finds/fixes
obvious flaws; the efforts with changes like what William is proposing
are based around assuming (correctly, I can argue) that there are
already bugs present, and they will remain in the kernel for years to
come. Designing the kernel to safely deal with bugs being present is a
fundamental design principle for kernel security self-defense
technologies.

The challenge is not "fix them", the challenge is "design the kernel
to do the right thing even when the bugs are unfixed".

>> So this method is just quite error
>> prone. We currently have a blacklist approach versus whitelist.
>
> Or fix the entire thing, get rid of %pK and always protect %p if you
> can show that it doesn't break anything.
>
> But stop posting patches with bullshit arguments like out of tree
> modules.

As a _singlular_ argument, "it's for out-of-tree code" is weak. As an
_additional_ argument, it has value. Saying "this only helps
out-of-tree code" doesn't carry much weight. Saying "this helps kernel
security, even for out-of-tree code" is perfectly valid. And a wrinkle
in this is that some day, either that out-of-tree code, or brand new
code, will land in the kernel, and we don't want to continue to
require authors be aware of an opt-in security feature. The kernel
should protect itself (and all of itself, including out-of-tree or
future code) by default.

And based on my read of this thread, we all appear to be in violent
agreement. :) "always protect %p" is absolutely the goal, and we can
figure out the best way to get there.

-Kees

-- 
Kees Cook
Nexus Security
--
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] printk: introduce kptr_restrict level 3

[Joe Perches]

On Thu, 2016-10-06 at 14:00 -0700, Kees Cook wrote:

> And based on my read of this thread, we all appear to be in violent
> agreement. :) "always protect %p" is absolutely the goal, and we can
> figure out the best way to get there.

I proposed emitting pointers from the const and text sections by default
and using NULL for data pointers.

https://lkml.org/lkml/2016/8/5/380

--
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] printk: introduce kptr_restrict level 3

[Kees Cook]

On Thu, Oct 6, 2016 at 2:19 PM, Joe Perches  wrote:
> On Thu, 2016-10-06 at 14:00 -0700, Kees Cook wrote:
>
>> And based on my read of this thread, we all appear to be in violent
>> agreement. :) "always protect %p" is absolutely the goal, and we can
>> figure out the best way to get there.
>
> I proposed emitting pointers from the const and text sections by default
> and using NULL for data pointers.
>
> https://lkml.org/lkml/2016/8/5/380

Leaks of const and text (while not useful for write-attacks) can leak
KASLR offset (though yes, yes, there are many existing leaks -- but we
should avoid adding a new one regardless).

I think the logic of "is this destined for userspace" is likely the
cleanest approach. There still may be many things this breaks, though.
(I expect perf. Everything breaks perf. ;)

-Kees

-- 
Kees Cook
Nexus Security
--
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: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP

[Dave Chinner]

On Thu, Oct 06, 2016 at 11:17:18AM -0700, Davidlohr Bueso wrote:
> On Thu, 18 Aug 2016, Waiman Long wrote:
> 
> >Currently, when down_read() fails, the active read locking isn't undone
> >until the rwsem_down_read_failed() function grabs the wait_lock. If the
> >wait_lock is contended, it may takes a while to get the lock. During
> >that period, writer lock stealing will be disabled because of the
> >active read lock.
> >
> >This patch will release the active read lock ASAP so that writer lock
> >stealing can happen sooner. The only downside is when the reader is
> >the first one in the wait queue as it has to issue another atomic
> >operation to update the count.
> >
> >On a 4-socket Haswell machine running on a 4.7-rc1 tip-based kernel,
> >the fio test with multithreaded randrw and randwrite tests on the
> >same file on a XFS partition on top of a NVDIMM with DAX were run,
> >the aggregated bandwidths before and after the patch were as follows:
> >
> > Test  BW before patch BW after patch  % change
> >   --- --  
> > randrw1210 MB/s  1352 MB/s  +12%
> > randwrite 1622 MB/s  1710 MB/s  +5.4%
> 
> Yeah, this is really a bad workload to make decisions on locking
> heuristics imo - if I'm thinking of the same workload. Mainly because
> concurrent buffered io to the same file isn't very realistic and you
> end up pathologically pounding on i_rwsem (which used to be until
> recently i_mutex until Al's parallel lookup/readdir). Obviously write
> lock stealing wins in this case.

Except that it's DAX, and in 4.7-rc1 that used shared locking at the
XFS level and never took exclusive locks.

*However*, the DAX IO path locking in XFS  has changed in 4.9-rc1 to
match the buffered IO single writer POSIX semantics - the test is a
bad test based on the fact it exercised a path that is under heavy
development and so can't be used as a regression test across
multiple kernels.

If you want to stress concurrent access to a single file, please
use direct IO, not DAX or buffered IO.

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com
--
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: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP

[Davidlohr Bueso]

On Fri, 07 Oct 2016, Dave Chinner wrote:


Except that it's DAX


Duh, of course; silly me.

Thanks,
Davidlohr
--
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/2] Moving runnable code from Documentation (last 2 patches)

[Shuah Khan]

This patch series contains the last 2 patches to complete moving runnable
code from Documentation to selftests, samples, and tools.

The first patch moves blackfin gptimers-example to samples, removes
BUILD_DOCSRC and updates BUILD_DOCSRC dependencies.

The second one updates 00-INDEX files under Documentation to reflect the
move of runnable code from Documentation.

Patch 0001 Changes since v1:
- Fixed make htmldocs and make distclean failures. Documentation/Makefile
  is not deleted to avoid these failures. Makefile.sphinx could be renamed
  to be the Documentation Makefile in a future patch.
- Fixed samples/Kconfig error in v1 that preserved the 'CONFIG_'
  prefix (i.e., depends on CONFIG_BLACKFIN && CONFIG_BFIN_GPTIMERS...),
  rendering SAMPLE_BLACKFIN_GPTIMERS to be dead.
- Updated rivers/media/v4l2-core/Kconfig (VIDEO_PCI_SKELETON) dependency
  on BUILD_DOCSRC.
- Added Acks from Jon Corbet, Michal Marek, and reviewed by from Kees Cook
- Added Reported-by from Valentin Rothberg, and Paul Gortmaker.

Patch 0002 Changes since v1:
- Updated Documentation/timers/00-INDEX to remove hpet_example.c. I missed
  this change in v1.
- Added Acks from Jon Corbet, Michal Marek, and reviewed by from Kees Cook

Shuah Khan (2):
  samples: move blackfin gptimers-example from Documentation
  Doc: update 00-INDEX files to reflect the runnable code move

 Documentation/00-INDEX|  3 +-
 Documentation/Makefile|  2 +-
 Documentation/arm/00-INDEX|  2 -
 Documentation/blackfin/00-INDEX   |  4 --
 Documentation/blackfin/Makefile   |  5 --
 Documentation/blackfin/gptimers-example.c | 91 ---
 Documentation/filesystems/00-INDEX|  2 -
 Documentation/networking/00-INDEX |  2 -
 Documentation/spi/00-INDEX|  2 -
 Documentation/timers/00-INDEX |  4 --
 Makefile  |  3 -
 drivers/media/v4l2-core/Kconfig   |  2 +-
 lib/Kconfig.debug |  9 ---
 samples/Kconfig   |  6 ++
 samples/Makefile  |  2 +-
 samples/blackfin/Makefile |  1 +
 samples/blackfin/gptimers-example.c   | 91 +++
 17 files changed, 103 insertions(+), 128 deletions(-)
 delete mode 100644 Documentation/blackfin/Makefile
 delete mode 100644 Documentation/blackfin/gptimers-example.c
 create mode 100644 samples/blackfin/Makefile
 create mode 100644 samples/blackfin/gptimers-example.c

-- 
2.7.4

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

[PATCH v2 1/2] samples: move blackfin gptimers-example from Documentation

[Shuah Khan]

Move blackfin gptimers-example to samples and remove it from Documentation
Makefile. Update samples Kconfig and Makefile to build gptimers-example.

blackfin is the last CONFIG_BUILD_DOCSRC target in Documentation/Makefile.
Hence this patch also includes changes to remove CONFIG_BUILD_DOCSRC from
Makefile and lib/Kconfig.debug and updates VIDEO_PCI_SKELETON dependency
on BUILD_DOCSRC.

Documentation/Makefile is not deleted to avoid braking make htmldocs and
make distclean.

Acked-by: Michal Marek 
Acked-by: Jonathan Corbet 
Reviewed-by: Kees Cook 
Reported-by: Valentin Rothberg 
Reported-by: Paul Gortmaker 
Signed-off-by: Shuah Khan 
---
 Documentation/Makefile|  2 +-
 Documentation/blackfin/00-INDEX   |  4 --
 Documentation/blackfin/Makefile   |  5 --
 Documentation/blackfin/gptimers-example.c | 91 ---
 Makefile  |  3 -
 drivers/media/v4l2-core/Kconfig   |  2 +-
 lib/Kconfig.debug |  9 ---
 samples/Kconfig   |  6 ++
 samples/Makefile  |  2 +-
 samples/blackfin/Makefile |  1 +
 samples/blackfin/gptimers-example.c   | 91 +++
 11 files changed, 101 insertions(+), 115 deletions(-)
 delete mode 100644 Documentation/blackfin/Makefile
 delete mode 100644 Documentation/blackfin/gptimers-example.c
 create mode 100644 samples/blackfin/Makefile
 create mode 100644 samples/blackfin/gptimers-example.c

diff --git a/Documentation/Makefile b/Documentation/Makefile
index 8435965..c2a4691 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -1 +1 @@
-subdir-y := blackfin
+subdir-y :=
diff --git a/Documentation/blackfin/00-INDEX b/Documentation/blackfin/00-INDEX
index c54fcdd..265a1ef 100644
--- a/Documentation/blackfin/00-INDEX
+++ b/Documentation/blackfin/00-INDEX
@@ -1,10 +1,6 @@
 00-INDEX
- This file
-Makefile
-   - Makefile for gptimers example file.
 bfin-gpio-notes.txt
- Notes in developing/using bfin-gpio driver.
 bfin-spi-notes.txt
- Notes for using bfin spi bus driver.
-gptimers-example.c
-   - gptimers example
diff --git a/Documentation/blackfin/Makefile b/Documentation/blackfin/Makefile
deleted file mode 100644
index 6782c58..000
--- a/Documentation/blackfin/Makefile
+++ /dev/null
@@ -1,5 +0,0 @@
-ifneq ($(CONFIG_BLACKFIN),)
-ifneq ($(CONFIG_BFIN_GPTIMERS),)
-obj-m := gptimers-example.o
-endif
-endif
diff --git a/Documentation/blackfin/gptimers-example.c 
b/Documentation/blackfin/gptimers-example.c
deleted file mode 100644
index 283eba9..000
--- a/Documentation/blackfin/gptimers-example.c
+++ /dev/null
@@ -1,91 +0,0 @@
-/*
- * Simple gptimers example
- * 
http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:gptimers
- *
- * Copyright 2007-2009 Analog Devices Inc.
- *
- * Licensed under the GPL-2 or later.
- */
-
-#include 
-#include 
-
-#include 
-#include 
-
-/* ... random driver includes ... */
-
-#define DRIVER_NAME "gptimer_example"
-
-#ifdef IRQ_TIMER5
-#define SAMPLE_IRQ_TIMER IRQ_TIMER5
-#else
-#define SAMPLE_IRQ_TIMER IRQ_TIMER2
-#endif
-
-struct gptimer_data {
-   uint32_t period, width;
-};
-static struct gptimer_data data;
-
-/* ... random driver state ... */
-
-static irqreturn_t gptimer_example_irq(int irq, void *dev_id)
-{
-   struct gptimer_data *data = dev_id;
-
-   /* make sure it was our timer which caused the interrupt */
-   if (!get_gptimer_intr(TIMER5_id))
-   return IRQ_NONE;
-
-   /* read the width/period values that were captured for the waveform */
-   data->width = get_gptimer_pwidth(TIMER5_id);
-   data->period = get_gptimer_period(TIMER5_id);
-
-   /* acknowledge the interrupt */
-   clear_gptimer_intr(TIMER5_id);
-
-   /* tell the upper layers we took care of things */
-   return IRQ_HANDLED;
-}
-
-/* ... random driver code ... */
-
-static int __init gptimer_example_init(void)
-{
-   int ret;
-
-   /* grab the peripheral pins */
-   ret = peripheral_request(P_TMR5, DRIVER_NAME);
-   if (ret) {
-   printk(KERN_NOTICE DRIVER_NAME ": peripheral request failed\n");
-   return ret;
-   }
-
-   /* grab the IRQ for the timer */
-   ret = request_irq(SAMPLE_IRQ_TIMER, gptimer_example_irq,
-   IRQF_SHARED, DRIVER_NAME, &data);
-   if (ret) {
-   printk(KERN_NOTICE DRIVER_NAME ": IRQ request failed\n");
-   peripheral_free(P_TMR5);
-   return ret;
-   }
-
-   /* setup the timer and enable it */
-   set_gptimer_config(TIMER5_id,
-   WDTH_CAP | PULSE_HI | PERIOD_CNT | IRQ_ENA);
-   enable_gptimers(TIMER5bit);
-
-   return 0;
-}
-module_init(gptimer_example_init);
-
-static void __exit gptimer_example_exit(void)
-{
-   disable_gptimers(TIMER5bit);
-   free_irq(SAMPLE_IRQ_TIMER, &data);
-

[PATCH v2 2/2] Doc: update 00-INDEX files to reflect the runnable code move

[Shuah Khan]

Update 00-INDEX files with the current file list to reflect the runnable
code move.

Acked-by: Michal Marek 
Acked-by: Jonathan Corbet 
Reviewed-by: Kees Cook 
Signed-off-by: Shuah Khan 
---
 Documentation/00-INDEX | 3 ++-
 Documentation/arm/00-INDEX | 2 --
 Documentation/filesystems/00-INDEX | 2 --
 Documentation/networking/00-INDEX  | 2 --
 Documentation/spi/00-INDEX | 2 --
 Documentation/timers/00-INDEX  | 4 
 6 files changed, 2 insertions(+), 13 deletions(-)

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index cb9a6c6..3acc4f1 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -46,7 +46,8 @@ IRQ.txt
 Intel-IOMMU.txt
- basic info on the Intel IOMMU virtualization support.
 Makefile
-   - some files in Documentation dir are actually sample code to build
+   - This file does nothing. Removing it breaks make htmldocs and
+ make distclean.
 ManagementStyle
- how to (attempt to) manage kernel hackers.
 RCU/
diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX
index dea011c..b6e69fd 100644
--- a/Documentation/arm/00-INDEX
+++ b/Documentation/arm/00-INDEX
@@ -8,8 +8,6 @@ Interrupts
- ARM Interrupt subsystem documentation
 IXP4xx
- Intel IXP4xx Network processor.
-Makefile
-   - Build sourcefiles as part of the Documentation-build for arm
 Netwinder
- Netwinder specific documentation
 Porting
diff --git a/Documentation/filesystems/00-INDEX 
b/Documentation/filesystems/00-INDEX
index 9922939..f66e748 100644
--- a/Documentation/filesystems/00-INDEX
+++ b/Documentation/filesystems/00-INDEX
@@ -2,8 +2,6 @@
- this file (info on some of the filesystems supported by linux).
 Locking
- info on locking rules as they pertain to Linux VFS.
-Makefile
-   - Makefile for building the filsystems-part of DocBook.
 9p.txt
- 9p (v9fs) is an implementation of the Plan 9 remote fs protocol.
 adfs.txt
diff --git a/Documentation/networking/00-INDEX 
b/Documentation/networking/00-INDEX
index 415154a..98f3d4b 100644
--- a/Documentation/networking/00-INDEX
+++ b/Documentation/networking/00-INDEX
@@ -10,8 +10,6 @@ LICENSE.qlge
- GPLv2 for QLogic Linux qlge NIC Driver
 LICENSE.qlcnic
- GPLv2 for QLogic Linux qlcnic NIC Driver
-Makefile
-   - Makefile for docsrc.
 PLIP.txt
- PLIP: The Parallel Line Internet Protocol device driver
 README.ipw2100
diff --git a/Documentation/spi/00-INDEX b/Documentation/spi/00-INDEX
index 4644bf0..8e4bb17 100644
--- a/Documentation/spi/00-INDEX
+++ b/Documentation/spi/00-INDEX
@@ -1,7 +1,5 @@
 00-INDEX
- this file.
-Makefile
-   - Makefile for the example sourcefiles.
 butterfly
- AVR Butterfly SPI driver overview and pin configuration.
 ep93xx_spi
diff --git a/Documentation/timers/00-INDEX b/Documentation/timers/00-INDEX
index ee212a2..3be05fe 100644
--- a/Documentation/timers/00-INDEX
+++ b/Documentation/timers/00-INDEX
@@ -4,12 +4,8 @@ highres.txt
- High resolution timers and dynamic ticks design notes
 hpet.txt
- High Precision Event Timer Driver for Linux
-hpet_example.c
-   - sample hpet timer test program
 hrtimers.txt
- subsystem for high-resolution kernel timers
-Makefile
-   - Build and link hpet_example
 NO_HZ.txt
- Summary of the different methods for the scheduler clock-interrupts 
management.
 timekeeping.txt
-- 
2.7.4

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

[PATCHv2] hwmon: Add tc654 driver

[Chris Packham]

Add support for the tc654 and tc655 fan controllers from Microchip.

http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf

Signed-off-by: Chris Packham 
---

Changes in v2:
- Add Documentation/hwmon/tc654
- Incorporate most of the review comments from Guenter. Additional error
  handling is added. Unused/unnecessary code is removed. I decided not
  to go down the regmap path yet. I may circle back to it when I look at
  using regmap in the adm9240 driver.

 .../devicetree/bindings/i2c/trivial-devices.txt|   2 +
 Documentation/hwmon/tc654  |  26 ++
 drivers/hwmon/Kconfig  |  11 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/tc654.c  | 513 +
 5 files changed, 553 insertions(+)
 create mode 100644 Documentation/hwmon/tc654
 create mode 100644 drivers/hwmon/tc654.c

diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt 
b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
index 1416c6a0d2cd..833fb9f133d3 100644
--- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
+++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
@@ -122,6 +122,8 @@ microchip,mcp4662-502   Microchip 8-bit Dual I2C 
Digital Potentiometer with NV Mem
 microchip,mcp4662-103  Microchip 8-bit Dual I2C Digital Potentiometer with NV 
Memory (10k)
 microchip,mcp4662-503  Microchip 8-bit Dual I2C Digital Potentiometer with NV 
Memory (50k)
 microchip,mcp4662-104  Microchip 8-bit Dual I2C Digital Potentiometer with NV 
Memory (100k)
+microchip,tc654PWM Fan Speed Controller With Fan Fault 
Detection
+microchip,tc655PWM Fan Speed Controller With Fan Fault 
Detection
 national,lm63  Temperature sensor with integrated fan control
 national,lm75  I2C TEMP SENSOR
 national,lm80  Serial Interface ACPI-Compatible Microprocessor System 
Hardware Monitor
diff --git a/Documentation/hwmon/tc654 b/Documentation/hwmon/tc654
new file mode 100644
index ..93796c5c7e79
--- /dev/null
+++ b/Documentation/hwmon/tc654
@@ -0,0 +1,26 @@
+Kernel driver tc654
+===
+
+Supported chips:
+  * Microship TC654 and TC655
+Prefix: 'tc654'
+Datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20001734C.pdf
+
+Authors:
+Chris Packham 
+Masahiko Iwamoto 
+
+Description
+---
+This driver implements support for the Microchip TC654 and TC655.
+
+The TC654 used the 2-wire interface compatible with the SMBUS 2.0
+specification. The TC654 has two (2) inputs for measuring fan RPM and
+one (1) PWM output which can be used for fan control.
+
+Configuration Notes
+---
+Ordinarily the pwm1_mode ABI is used for controlling the pwm output
+mode.  However, for this chip the output is always pwm, and the
+pwm1_mode determines if the pwm output is controlled via the pwm1 value
+or via the Vin analog input.
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d2c75c..8681bc65cde5 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -907,6 +907,17 @@ config SENSORS_MCP3021
  This driver can also be built as a module.  If so, the module
  will be called mcp3021.
 
+config SENSORS_TC654
+   tristate "Microchip TC654/TC655 and compatibles"
+   depends on I2C
+   help
+ If you say yes here you get support for TC654 and TC655.
+ The TC654 and TC655 are PWM mode fan speed controllers with
+ FanSense technology for use with brushless DC fans.
+
+ This driver can also be built as a module.  If so, the module
+ will be called tc654.
+
 config SENSORS_MENF21BMC_HWMON
tristate "MEN 14F021P00 BMC Hardware Monitoring"
depends on MFD_MENF21BMC
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba17460..c651f0f1d047 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -122,6 +122,7 @@ obj-$(CONFIG_SENSORS_MAX6697)   += max6697.o
 obj-$(CONFIG_SENSORS_MAX31790) += max31790.o
 obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
 obj-$(CONFIG_SENSORS_MCP3021)  += mcp3021.o
+obj-$(CONFIG_SENSORS_TC654)+= tc654.o
 obj-$(CONFIG_SENSORS_MENF21BMC_HWMON) += menf21bmc_hwmon.o
 obj-$(CONFIG_SENSORS_NCT6683)  += nct6683.o
 obj-$(CONFIG_SENSORS_NCT6775)  += nct6775.o
diff --git a/drivers/hwmon/tc654.c b/drivers/hwmon/tc654.c
new file mode 100644
index ..cba31cbd3383
--- /dev/null
+++ b/drivers/hwmon/tc654.c
@@ -0,0 +1,513 @@
+/*
+ * tc654.c - Linux kernel modules for fan speed controller
+ *
+ * Copyright (C) 2016 Allied Telesis Labs NZ
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope th

Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts

[Jani Nikula]

On Thu, 06 Oct 2016, Mauro Carvalho Chehab  wrote:
> Em Thu, 06 Oct 2016 17:21:36 +0300
> Jani Nikula  escreveu:
>> We've seen what happens when we make it easy to add random scripts to
>> build documentation. We've worked hard to get rid of that. In my books,
>> one of the bigger points in favor of Sphinx over AsciiDoc(tor) was
>> getting rid of all the hacks required in the build. Things that broke in
>> subtle ways.
>
> I really can't see what scripts it get rids.

Really? You don't see why the DocBook build was so fragile and difficult
to maintain? That scares me a bit, because then you will not have
learned why we should at all costs avoid adding random scripts to
produce documentation.

The DocBook build was designed by Rube Goldberg, and this video
accurately illustrates how it works:
https://www.youtube.com/watch?v=qybUFnY7Y8w

I don't want the Sphinx build to end up like that.


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