Merge tag 'docs-4.11-fixes' of git://git.lwn.net/linux

Pull documentation fixes from Jonathan Corbet:
 "A few fixes for the docs tree, including one for a 4.11 build
  regression"

* tag 'docs-4.11-fixes' of git://git.lwn.net/linux:
  Documentation/sphinx: fix primary_domain configuration
  docs: Fix htmldocs build failure
  doc/ko_KR/memory-barriers: Update control-dependencies section
  pcieaer doc: update the link
  Documentation: Update path to sysrq.txt

8 files changed, 47 insertions, 41 deletions

diff --git a/Documentation/DocBook/Makefile b/Documentation/DocBook/Makefile
index 60a17b7da834..164c1c76971f 100644
--- a/Documentation/DocBook/Makefile
+++ b/Documentation/DocBook/Makefile
@@ -7,12 +7,12 @@
 # list of DOCBOOKS.
 
 DOCBOOKS := z8530book.xml  \
-            kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
+            kernel-hacking.xml kernel-locking.xml \
             writing_usb_driver.xml networking.xml \
             kernel-api.xml filesystems.xml lsm.xml kgdb.xml \
             gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \
             genericirq.xml s390-drivers.xml scsi.xml \
-            sh.xml regulator.xml w1.xml \
+            sh.xml w1.xml \
             writing_musb_glue_layer.xml
 
 ifeq ($(DOCBOOKS),)
diff --git a/Documentation/PCI/pcieaer-howto.txt b/Documentation/PCI/pcieaer-howto.txt
index ea8cafba255c..acd0dddd6bb8 100644
--- a/Documentation/PCI/pcieaer-howto.txt
+++ b/Documentation/PCI/pcieaer-howto.txt
@@ -256,7 +256,7 @@ After reboot with new kernel or insert the module, a device file named
 
 Then, you need a user space tool named aer-inject, which can be gotten
 from:
-    http://www.kernel.org/pub/linux/utils/pci/aer-inject/
+    https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
 
 More information about aer-inject can be found in the document comes
 with its source code.
diff --git a/Documentation/conf.py b/Documentation/conf.py
index f6823cf01275..7fadb3b83293 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -135,7 +135,7 @@ pygments_style = 'sphinx'
 # If true, `todo` and `todoList` produce output, else they produce nothing.
 todo_include_todos = False
 
-primary_domain = 'C'
+primary_domain = 'c'
 highlight_language = 'none'
 
 # -- Options for HTML output ----------------------------------------------
diff --git a/Documentation/media/v4l-drivers/bttv.rst b/Documentation/media/v4l-drivers/bttv.rst
index bc63b12efafd..195ccaac2816 100644
--- a/Documentation/media/v4l-drivers/bttv.rst
+++ b/Documentation/media/v4l-drivers/bttv.rst
@@ -312,7 +312,7 @@ information out of a register+stack dump printed by the kernel on
 protection faults (so-called "kernel oops").
 
 If you run into some kind of deadlock, you can try to dump a call trace
-for each process using sysrq-t (see Documentation/sysrq.txt).
+for each process using sysrq-t (see Documentation/admin-guide/sysrq.rst).
 This way it is possible to figure where *exactly* some process in "D"
 state is stuck.
 
diff --git a/Documentation/s390/Debugging390.txt b/Documentation/s390/Debugging390.txt
index 3df8babcdc41..5ae7f868a007 100644
--- a/Documentation/s390/Debugging390.txt
+++ b/Documentation/s390/Debugging390.txt
@@ -2116,7 +2116,7 @@ The sysrq key reading is very picky ( I have to type the keys in an
 This is particularly useful for syncing disks unmounting & rebooting
 if the machine gets partially hung.
 
-Read Documentation/sysrq.txt for more info
+Read Documentation/admin-guide/sysrq.rst for more info
 
 References:
 ===========
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index a32b4b748644..bac23c198360 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -85,7 +85,7 @@ show up in /proc/sys/kernel:
 - softlockup_all_cpu_backtrace
 - soft_watchdog
 - stop-a                      [ SPARC only ]
-- sysrq                       ==> Documentation/sysrq.txt
+- sysrq                       ==> Documentation/admin-guide/sysrq.rst
 - sysctl_writes_strict
 - tainted
 - threads-max
diff --git a/Documentation/translations/ko_KR/memory-barriers.txt b/Documentation/translations/ko_KR/memory-barriers.txt
index a3228a676cc1..ce0b48d69eaa 100644
--- a/Documentation/translations/ko_KR/memory-barriers.txt
+++ b/Documentation/translations/ko_KR/memory-barriers.txt
@@ -662,6 +662,10 @@ include/linux/rcupdate.h 의 rcu_assign_pointer() 와 rcu_dereference() 를
 컨트롤 의존성
 -------------
 
+현재의 컴파일러들은 컨트롤 의존성을 이해하고 있지 않기 때문에 컨트롤 의존성은
+약간 다루기 어려울 수 있습니다.  이 섹션의 목적은 여러분이 컴파일러의 무시로
+인해 여러분의 코드가 망가지는 걸 막을 수 있도록 돕는겁니다.
+
 로드-로드 컨트롤 의존성은 데이터 의존성 배리어만으로는 정확히 동작할 수가
 없어서 읽기 메모리 배리어를 필요로 합니다.  아래의 코드를 봅시다:
 
@@ -689,20 +693,21 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
         q = READ_ONCE(a);
         if (q) {
-                WRITE_ONCE(b, p);
+                WRITE_ONCE(b, 1);
         }
 
 컨트롤 의존성은 보통 다른 타입의 배리어들과 짝을 맞춰 사용됩니다.  그렇다곤
-하나, READ_ONCE() 는 반드시 사용해야 함을 부디 명심하세요!  READ_ONCE() 가
-없다면, 컴파일러가 'a' 로부터의 로드를 'a' 로부터의 또다른 로드와, 'b' 로의
-스토어를 'b' 로의 또다른 스토어와 조합해 버려 매우 비직관적인 결과를 초래할 수
-있습니다.
+하나, READ_ONCE() 도 WRITE_ONCE() 도 선택사항이 아니라 필수사항임을 부디
+명심하세요!  READ_ONCE() 가 없다면, 컴파일러는 'a' 로부터의 로드를 'a' 로부터의
+또다른 로드와 조합할 수 있습니다.  WRITE_ONCE() 가 없다면, 컴파일러는 'b' 로의
+스토어를 'b' 로의 또라느 스토어들과 조합할 수 있습니다.  두 경우 모두 순서에
+있어 상당히 비직관적인 결과를 초래할 수 있습니다.
 
 이걸로 끝이 아닌게, 컴파일러가 변수 'a' 의 값이 항상 0이 아니라고 증명할 수
 있다면, 앞의 예에서 "if" 문을 없애서 다음과 같이 최적화 할 수도 있습니다:
 
         q = a;
-        b = p;  /* BUG: Compiler and CPU can both reorder!!! */
+        b = 1;  /* BUG: Compiler and CPU can both reorder!!! */
 
 그러니 READ_ONCE() 를 반드시 사용하세요.
 
@@ -712,11 +717,11 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
         q = READ_ONCE(a);
         if (q) {
                 barrier();
-                WRITE_ONCE(b, p);
+                WRITE_ONCE(b, 1);
                 do_something();
         } else {
                 barrier();
-                WRITE_ONCE(b, p);
+                WRITE_ONCE(b, 1);
                 do_something_else();
         }
 
@@ -725,12 +730,12 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
         q = READ_ONCE(a);
         barrier();
-        WRITE_ONCE(b, p);  /* BUG: No ordering vs. load from a!!! */
+        WRITE_ONCE(b, 1);  /* BUG: No ordering vs. load from a!!! */
         if (q) {
-                /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
+                /* WRITE_ONCE(b, 1); -- moved up, BUG!!! */
                 do_something();
         } else {
-                /* WRITE_ONCE(b, p); -- moved up, BUG!!! */
+                /* WRITE_ONCE(b, 1); -- moved up, BUG!!! */
                 do_something_else();
         }
 
@@ -742,10 +747,10 @@ CPU 는 b 로부터의 로드 오퍼레이션이 a 로부터의 로드 오퍼레
 
         q = READ_ONCE(a);