Merge branch 'docs-next' of git://git.lwn.net/linux

Pull documentation updates from Jonathan Corbet:
 "After a fair amount of churn in the last couple of cycles, docs are
  taking it easier this time around. Lots of fixes and some new
  documentation, but nothing all that radical. Perhaps the most
  interesting change for many is the scripts/sphinx-pre-install tool
  from Mauro; it will tell you exactly which packages you need to
  install to get a working docs toolchain on your system.

  There are two little patches reaching outside of Documentation/; both
  just tweak kerneldoc comments to eliminate warnings and fix some
  dangling doc pointers"

* 'docs-next' of git://git.lwn.net/linux: (52 commits)
  Documentation/sphinx: fix kernel-doc decode for non-utf-8 locale
  genalloc: Fix an incorrect kerneldoc comment
  doc: Add documentation for the genalloc subsystem
  assoc_array: fix path to assoc_array documentation
  kernel-doc parser mishandles declarations split into lines
  docs: ReSTify table of contents in core.rst
  docs: process: drop git snapshots from applying-patches.rst
  Documentation:input: fix typo
  swap: Remove obsolete sentence
  sphinx.rst: Allow Sphinx version 1.6 at the docs
  docs-rst: fix verbatim font size on tables
  Documentation: stable-kernel-rules: fix broken git urls
  rtmutex: update rt-mutex
  rtmutex: update rt-mutex-design
  docs: fix minimal sphinx version in conf.py
  docs: fix nested numbering in the TOC
  NVMEM documentation fix: A minor typo
  docs-rst: pdf: use same vertical margin on all Sphinx versions
  doc: Makefile: if sphinx is not found, run a check script
  docs: Fix paths in security/keys
  ...

3 files changed, 5 insertions, 15 deletions

diff --git a/Documentation/security/keys/core.rst b/Documentation/security/keys/core.rst
index 1648fa80b3bf..1266eeae45f6 100644
--- a/Documentation/security/keys/core.rst
+++ b/Documentation/security/keys/core.rst
@@ -16,17 +16,7 @@ The key service can be configured on by enabling:
 
 This document has the following sections:
 
-	- Key overview
-	- Key service overview
-	- Key access permissions
-	- SELinux support
-	- New procfs files
-	- Userspace system call interface
-	- Kernel services
-	- Notes on accessing payload contents
-	- Defining a key type
-	- Request-key callback service
-	- Garbage collection
+.. contents:: :local:
 
 
 Key Overview
@@ -443,7 +433,7 @@ The main syscalls are:
      /sbin/request-key will be invoked in an attempt to obtain a key. The
      callout_info string will be passed as an argument to the program.
 
-     See also Documentation/security/keys-request-key.txt.
+     See also Documentation/security/keys/request-key.rst.
 
 
 The keyctl syscall functions are:
@@ -973,7 +963,7 @@ payload contents" for more information.
     If successful, the key will have been attached to the default keyring for
     implicitly obtained request-key keys, as set by KEYCTL_SET_REQKEY_KEYRING.
 
-    See also Documentation/security/keys-request-key.txt.
+    See also Documentation/security/keys/request-key.rst.
 
 
  *  To search for a key, passing auxiliary data to the upcaller, call::
diff --git a/Documentation/security/keys/request-key.rst b/Documentation/security/keys/request-key.rst
index aba32784174c..b2d16abaa9e9 100644
--- a/Documentation/security/keys/request-key.rst
+++ b/Documentation/security/keys/request-key.rst
@@ -3,7 +3,7 @@ Key Request Service
 ===================
 
 The key request service is part of the key retention service (refer to
-Documentation/security/keys.txt).  This document explains more fully how
+Documentation/security/core.rst).  This document explains more fully how
 the requesting algorithm works.
 
 The process starts by either the kernel requesting a service by calling
diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst
index 7b503831bdea..3bb24e09a332 100644
--- a/Documentation/security/keys/trusted-encrypted.rst
+++ b/Documentation/security/keys/trusted-encrypted.rst
@@ -172,4 +172,4 @@ Other uses for trusted and encrypted keys, such as for disk and file encryption
 are anticipated.  In particular the new format 'ecryptfs' has been defined in
 in order to use encrypted keys to mount an eCryptfs filesystem.  More details
 about the usage can be found in the file
-``Documentation/security/keys-ecryptfs.txt``.
+``Documentation/security/keys/ecryptfs.rst``.