Merge branch 'docs-mw' into docs-nextdocs-next

20 files changed, 319 insertions, 28 deletions

diff --git a/Documentation/admin-guide/bug-hunting.rst b/Documentation/admin-guide/bug-hunting.rst
index 3901b43c96df..642bf8474726 100644
--- a/Documentation/admin-guide/bug-hunting.rst
+++ b/Documentation/admin-guide/bug-hunting.rst
@@ -63,8 +63,8 @@ Documentation/admin-guide/tainted-kernels.rst, "being loaded" is
 annotated with "+", and "being unloaded" is annotated with "-".
 
 
-Where is the Oops message is located?
--------------------------------------
+Where is the Oops message located?
+----------------------------------
 
 Normally the Oops text is read from the kernel buffers by klogd and
 handed to ``syslogd`` which writes it to a syslog file, typically
diff --git a/Documentation/admin-guide/quickly-build-trimmed-linux.rst b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
index cb178e0a6208..3432dc8e1a85 100644
--- a/Documentation/admin-guide/quickly-build-trimmed-linux.rst
+++ b/Documentation/admin-guide/quickly-build-trimmed-linux.rst
@@ -217,7 +217,7 @@ again.
 
    There is a catch: 'localmodconfig' is likely to disable kernel features you
    did not use since you booted your Linux -- like drivers for currently
-   disconnected peripherals or a virtualization software not haven't used yet.
+   disconnected peripherals or virtualization software not currently in use.
    You can reduce or nearly eliminate that risk with tricks the reference
    section outlines; but when building a kernel just for quick testing purposes
    it is often negligible if such features are missing. But you should keep that
diff --git a/Documentation/arch/arc/arc.rst b/Documentation/arch/arc/arc.rst
index 6c4d978f3f4e..5923dee37a98 100644
--- a/Documentation/arch/arc/arc.rst
+++ b/Documentation/arch/arc/arc.rst
@@ -36,7 +36,7 @@ Important note on ARC processors configurability
 
 ARC processors are highly configurable and several configurable options
 are supported in Linux. Some options are transparent to software
-(i.e cache geometries, some can be detected at runtime and configured
+(e.g., cache geometries), some can be detected at runtime and configured
 and used accordingly, while some need to be explicitly selected or configured
 in the kernel's configuration utility (AKA "make menuconfig").
 
diff --git a/Documentation/arch/arm/samsung/clksrc-change-registers.awk b/Documentation/arch/arm/samsung/clksrc-change-registers.awk
index 7be1b8aa7cd9..48464397088c 100755
--- a/Documentation/arch/arm/samsung/clksrc-change-registers.awk
+++ b/Documentation/arch/arm/samsung/clksrc-change-registers.awk
@@ -163,4 +163,4 @@ BEGIN {
     }
 }
 
-// && ! /clksrc_clk.*=.*{/ { print $0 }
+// && ! /clksrc_clk.*=.*{/ { print $0 }}
diff --git a/Documentation/arch/arm/vlocks.rst b/Documentation/arch/arm/vlocks.rst
index 737aa8661a21..b0ac33263086 100644
--- a/Documentation/arch/arm/vlocks.rst
+++ b/Documentation/arch/arm/vlocks.rst
@@ -102,10 +102,10 @@ Features and limitations
 	if (I_won) {
 		/* we won the town election, let's go for the state */
 		my_state = states[(this_cpu >> 8) & 0xf];
-		I_won = vlock_lock(my_state, this_cpu & 0xf));
+		I_won = vlock_lock(my_state, this_cpu & 0xf);
 		if (I_won) {
 			/* and so on */
-			I_won = vlock_lock(the_whole_country, this_cpu & 0xf];
+			I_won = vlock_lock(the_whole_country, this_cpu & 0xf);
 			if (I_won) {
 				/* ... */
 			}
diff --git a/Documentation/arch/arm64/memory-tagging-extension.rst b/Documentation/arch/arm64/memory-tagging-extension.rst
index 679725030731..e6fe428f0e2a 100644
--- a/Documentation/arch/arm64/memory-tagging-extension.rst
+++ b/Documentation/arch/arm64/memory-tagging-extension.rst
@@ -222,7 +222,7 @@ programs should not retry in case of a non-zero system call return.
 address ABI control and MTE configuration of a process as per the
 ``prctl()`` options described in
 Documentation/arch/arm64/tagged-address-abi.rst and above. The corresponding
-``regset`` is 1 element of 8 bytes (``sizeof(long))``).
+``regset`` is 1 element of 8 bytes (``sizeof(long)``).
 
 Core dump support
 -----------------
diff --git a/Documentation/arch/powerpc/vas-api.rst b/Documentation/arch/powerpc/vas-api.rst
index a9625a2fa0c6..1d0d055356e3 100644
--- a/Documentation/arch/powerpc/vas-api.rst
+++ b/Documentation/arch/powerpc/vas-api.rst
@@ -293,7 +293,7 @@ Simple example
 				//Format CRB request with compression or
 				//uncompression
 				// Refer tests for vas_copy/vas_paste
-				vas_copy((&crb, 0, 1);
+				vas_copy(&crb, 0, 1);
 				vas_paste(addr, 0, 1);
 				// Poll on csb.flags with timeout
 				// csb address is listed in CRB
diff --git a/Documentation/arch/sparc/oradax/dax-hv-api.txt b/Documentation/arch/sparc/oradax/dax-hv-api.txt
index ef1a4c2bf08b..49be62a9ce86 100644
--- a/Documentation/arch/sparc/oradax/dax-hv-api.txt
+++ b/Documentation/arch/sparc/oradax/dax-hv-api.txt
@@ -457,7 +457,7 @@ bits set, and terminate at a CCB that has the Conditional bit set, but not the P
 Offset   Size   Field Description
                 Bits         Field Description
                 [15:14]      Secondary Input Element Size (see Section 36.2.1.1.4,
-                             “Secondary Input Element Size”
+                             “Secondary Input Element Size”)
                 [13:10]      Output Format (see Section 36.2.1.1.6, “Output Format”)
                 [9]          Padding Direction selector: A value of 1 causes padding bytes
                              to be added to the left side of output elements. A value of 0
@@ -656,7 +656,7 @@ Offset         Size            Field Description
                                [18:16]      Secondary Input Starting Offset (see Section 36.2.1.1.5, “Input
                                             Element Offsets”)
                                [15:14]      Secondary Input Element Size (see Section 36.2.1.1.4,
-                                            “Secondary Input Element Size”
+                                            “Secondary Input Element Size”)
                                [13:10]      Output Format (see Section 36.2.1.1.6, “Output Format”)
                                [9:5]        Operand size for first scan criteria value. In a scan value
                                             operation, this is one of two potential exact match values.
@@ -793,13 +793,13 @@ Offset   Size   Field Description
                 [18:16]      Secondary Input Starting Offset (see Section 36.2.1.1.5, “Input
                              Element Offsets”)
                 [15:14]      Secondary Input Element Size (see Section 36.2.1.1.4,
-                             “Secondary Input Element Size”
+                             “Secondary Input Element Size”)
                 [13:10]      Output Format (see Section 36.2.1.1.6, “Output Format”)
                 [9]          Reserved
                 [8:0]        Test value used for comparison against the most significant bits
                              in the input values, when using 2 or 3 byte input elements.
-8        8      Completion (same fields as Section 36.2.1.2, “Extract command”
-16       8      Primary Input (same fields as Section 36.2.1.2, “Extract command”
+8        8      Completion (same fields as Section 36.2.1.2, “Extract command”)
+16       8      Primary Input (same fields as Section 36.2.1.2, “Extract command”)
 24       8      Data Access Control (same fields as Section 36.2.1.2, “Extract command”,
                 except Primary Input Length Format may not use the 0x0 value)
 32       8      Secondary Input, if used by Primary Input Format. Same fields as Primary
@@ -880,7 +880,7 @@ Offset   Size   Field Description
                                        [18:16]     Secondary Input Starting Offset (see Section 36.2.1.1.5, “Input
                                                    Element Offsets”)
                                        [15:14]     Secondary Input Element Size (see Section 36.2.1.1.4,
-                                                   “Secondary Input Element Size”
+                                                   “Secondary Input Element Size”)
 
 
                                                       524
@@ -895,8 +895,8 @@ Offset   Size   Field Description
                                                     causes padding bytes to be added to the right side of output
                                                     elements.
                                        [8:0]        Reserved
-        8              8               Completion (same fields as Section 36.2.1.2, “Extract command”
-        16             8               Primary Input (same fields as Section 36.2.1.2, “Extract command”
+        8              8               Completion (same fields as Section 36.2.1.2, “Extract command”)
+        16             8               Primary Input (same fields as Section 36.2.1.2, “Extract command”)
         24             8               Data Access Control (same fields as Section 36.2.1.2, “Extract command”)
         32             8               Secondary Bit Vector Input. Same fields as Primary Input.
         40             8               Reserved
@@ -949,7 +949,7 @@ Offset   Size   Field Description
                                    [31]        If set, this CCB functions as a Sync command. If clear, this
                                                CCB functions as a No-op command.
                                    [30:0]      Reserved
-       8             8             Completion (same fields as Section 36.2.1.2, “Extract command”
+       8             8             Completion (same fields as Section 36.2.1.2, “Extract command”)
        16            46            Reserved
 
 36.2.2. CCB Completion Area
diff --git a/Documentation/arch/sparc/oradax/oracle-dax.rst b/Documentation/arch/sparc/oradax/oracle-dax.rst
index d1e14d572918..a5d53f240dc8 100644
--- a/Documentation/arch/sparc/oradax/oracle-dax.rst
+++ b/Documentation/arch/sparc/oradax/oracle-dax.rst
@@ -438,7 +438,7 @@ that in user land::
 The output bitmap is ready for consumption immediately after the
 completion status indicates success.
 
-Excer[t from UltraSPARC Virtual Machine Specification
+Excerpt from UltraSPARC Virtual Machine Specification
 =====================================================
 
  .. include:: dax-hv-api.txt
diff --git a/Documentation/arch/x86/x86_64/fsgs.rst b/Documentation/arch/x86/x86_64/fsgs.rst
index 6bda4d16d3f7..f8d483a7fb06 100644
--- a/Documentation/arch/x86/x86_64/fsgs.rst
+++ b/Documentation/arch/x86/x86_64/fsgs.rst
@@ -182,8 +182,8 @@ address spaces via an attribute based mechanism in Clang 2.6 and newer
 versions:
 
  ==================================== =====================================
-  __attribute__((address_space(256))  Variable is addressed relative to GS
-  __attribute__((address_space(257))  Variable is addressed relative to FS
+  __attribute__(address_space(256))   Variable is addressed relative to GS
+  __attribute__(address_space(257))   Variable is addressed relative to FS
  ==================================== =====================================
 
 FS/GS based addressing with inline assembly
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
index ac75b7ecac47..03de71f654c7 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -388,7 +388,7 @@ allocations. For example, these open coded assignments::
 	ptr = kmalloc_array(count, sizeof(*ptr), gfp);
 	ptr = kcalloc(count, sizeof(*ptr), gfp);
 	ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
-	ptr = kmalloc(sizeof(struct foo, gfp);
+	ptr = kmalloc(sizeof(struct foo), gfp);
 
 become, respectively::
 
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
index a3a90a7d4c68..fa91dfc53783 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -60,7 +60,7 @@ All typical platform related patches should be sent via SoC submaintainers
 shared defconfigs. Note that scripts/get_maintainer.pl might not provide
 correct addresses for the shared defconfig, so ignore its output and manually
 create CC-list based on MAINTAINERS file or use something like
-``scripts/get_maintainer.pl -f drivers/soc/FOO/``).
+``scripts/get_maintainer.pl -f drivers/soc/FOO/``.
 
 Submitting Patches to the Main SoC Maintainers
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/Documentation/translations/it_IT/process/submit-checklist.rst b/Documentation/translations/it_IT/process/submit-checklist.rst
index 5bf1b4adebc1..c58d773fd297 100644
--- a/Documentation/translations/it_IT/process/submit-checklist.rst
+++ b/Documentation/translations/it_IT/process/submit-checklist.rst
@@ -122,7 +122,7 @@ Verificate il vostro codice
 
 1) La patch è stata verificata con le seguenti opzioni abilitate
    contemporaneamente: ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
-   ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
+   ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
    ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
    ``CONFIG_PROVE_RCU`` e ``CONFIG_DEBUG_OBJECTS_RCU_HEAD``.
 
diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst
index 165cb3ed94ec..d31d469909e4 100644
--- a/Documentation/translations/ja_JP/process/submitting-patches.rst
+++ b/Documentation/translations/ja_JP/process/submitting-patches.rst
@@ -355,3 +355,50 @@ cover letter または個々のパッチに ``patch changelog`` を追加し、�
 
 メールクライアントとメーリングリストでの作法についての推奨事項は、
 Documentation/process/email-clients.rst を参照してください。
+
+メール議論では不要な引用を削った interleaved replies を使う
+------------------------------------------------------------
+
+Linux カーネル開発の議論では、top-posting は強く非推奨とされています。
+Interleaved replies、または ``inline`` replies を使うと、会話の流れを
+ずっと追いやすくなります。詳細は次を参照してください:
+https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
+
+メーリングリストでは、よく次のように引用されます::
+
+  A: http://en.wikipedia.org/wiki/Top_post
+  Q: Where do I find info about this thing called top-posting?
+  A: Because it messes up the order in which people normally read text.
+  Q: Why is top-posting such a bad thing?
+  A: Top-posting.
+  Q: What is the most annoying thing in e-mail?
+
+同様に、返信に関係のない不要な引用はすべて削ってください。
+そうすることで、返答を見つけやすくなり、時間と容量を節約できます。
+詳細は次を参照してください: http://daringfireball.net/2007/07/on_top ::
+
+  A: No.
+  Q: Should I include quotations after my reply?
+
+
+落胆しない、そして急がない
+--------------------------
+
+変更を投稿した後は、辛抱強く待ってください。レビューアは忙しい人たちであり、
+あなたのパッチをすぐに見られるとは限りません。
+
+かつては、パッチが何のコメントもなく虚空へ消えていくこともありましたが、
+現在の開発プロセスはそれよりも円滑に機能しています。数週間以内、
+通常は 2〜3 週間以内にコメントを受け取るはずです。そうならない場合は、
+パッチを正しい場所へ送ったか確認してください。再投稿したりレビューアに
+ping したりする前に、少なくとも 1 週間は待ってください。merge window の
+ような忙しい時期には、さらに長く待つ方がよい場合もあります。
+
+数週間後に、subject line に "RESEND" を追加して、パッチまたは
+パッチシリーズを再送しても構いません::
+
+   [PATCH Vx RESEND] sub/sys: Condensed patch summary
+
+パッチまたはパッチシリーズの修正版を投稿する場合は、"RESEND" を
+追加しないでください。"RESEND" は、前回の投稿から一切変更していない
+パッチまたはパッチシリーズを再送する場合にのみ使います。
diff --git a/Documentation/translations/pt_BR/process/3.Early-stage.rst b/Documentation/translations/pt_BR/process/3.Early-stage.rst
new file mode 100644
index 000000000000..74e741766b46
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/3.Early-stage.rst
@@ -0,0 +1,233 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Planejamento em estágio inicial
+===============================
+
+Ao contemplar um projeto de desenvolvimento do kernel Linux, pode ser tentador
+dar um salto direto e começar a codificar. No entanto, como ocorre com qualquer
+projeto significativo, grande parte da base para o sucesso é melhor estabelecida
+antes que a primeira linha de código seja escrita. Um tempo gasto no planejamento
+e na comunicação iniciais pode economizar muito mais tempo mais adiante.
+
+
+Especificando o problema
+------------------------
+
+Como qualquer projeto de engenharia, um aprimoramento bem-sucedido do kernel
+começa com uma descrição clara do problema a ser resolvido. Em alguns casos,
+esta etapa é fácil: quando um driver é necessário para um componente de
+hardware específico, por exemplo. Em outros, no entanto, é tentador confundir o
+problema real com a solução proposta, e isso pode levar a dificuldades.
+
+Considere um exemplo: alguns anos atrás, desenvolvedores que trabalhavam com o
+áudio do Linux buscavam uma maneira de executar aplicativos sem interrupções
+(*dropouts*) ou outros artefatos causados por latência excessiva no sistema. A
+solução a que chegaram foi um módulo do kernel destinado a se conectar à
+estrutura do Linux Security Module (LSM); esse módulo poderia ser configurado
+para dar a aplicativos específicos acesso ao escalonador de tempo real. Esse
+módulo foi implementado e enviado para a lista de discussão linux-kernel, onde
+imediatamente encontrou problemas.
+
+Para os desenvolvedores de áudio, esse módulo de segurança era suficiente para
+resolver o problema imediato deles. Para a comunidade mais ampla do kernel, no
+entanto, ele foi visto como um uso indevido da estrutura LSM (que não tem a
+intenção de conceder privilégios a processos que eles de outra forma não
+teriam) e um risco para a estabilidade do sistema. As soluções preferidas da
+comunidade envolviam o acesso ao escalonamento de tempo real via mecanismo
+rlimit a curto prazo, e o trabalho contínuo de redução de latência a longo prazo.
+
+A comunidade de áudio, no entanto, não conseguia enxergar além da solução
+específica que havia implementado; eles não estavam dispostos a aceitar
+alternativas. O desacordo resultante deixou esses desenvolvedores sentindo-se
+desiludidos com todo o processo de desenvolvimento do kernel; um deles voltou
+para uma lista de áudio e postou isto:
+
+  "Existe um bom número de desenvolvedores muito bons no kernel Linux, mas eles
+  tendem a ser abafados por uma grande multidão de tolos arrogantes. Tentar
+  comunicar os requisitos dos usuários a essas pessoas é uma perda de tempo.
+  Eles são 'inteligentes' demais para ouvir os meros mortais."
+
+(https://lwn.net/Articles/131776/).
+
+A realidade da situação era diferente; os desenvolvedores do kernel estavam muito
+mais preocupados com a estabilidade do sistema, com a manutenção a longo prazo e
+em encontrar a solução correta para o problema do que com um módulo específico.
+A moral da história é focar no problema — e não em uma solução específica — e
+discuti-lo com a comunidade de desenvolvimento antes de investir na criação de
+um conjunto de códigos.
+
+Portanto, ao contemplar um projeto de desenvolvimento do kernel, deve-se
+obter respostas para um pequeno conjunto de perguntas:
+
+ - Qual é, exatamente, o problema que precisa ser resolvido?
+
+ - Quem são os usuários afetados por esse problema? Quais casos de uso a
+   solução deve abranger?
+
+ - De que forma o kernel deixa a desejar em resolver esse problema atualmente?
+
+Só então faz sentido começar a considerar possíveis soluções.
+
+
+Discussão inicial
+-----------------
+
+Ao planejar um projeto de desenvolvimento do kernel, faz todo o sentido realizar
+discussões com a comunidade antes de iniciar a implementação. A comunicação
+inicial pode economizar tempo e problemas de várias maneiras:number of ways:
+
+ - Pode muito bem ser que o problema já seja tratado pelo kernel de maneiras
+   que você não compreendeu. O kernel Linux é grande e possui uma série de
+   recursos e capacidades que não são imediatamente óbvios. Nem todas as
+   capacidades do kernel são documentadas tão bem quanto se gostaria, e é fácil
+   deixar passar algumas coisas. Este autor já viu a postagem de um driver
+   completo que duplicava um driver existente do qual o novo autor não tinha
+   conhecimento. Códigos que reinventam as rodas existentes não são apenas um
+   desperdício; eles também não serão aceitos no kernel principal (*mainline*).
+
+ - Pode haver elementos na solução proposta que não serão aceitáveis para a
+   integração no kernel principal . É melhor descobrir problemas
+   como este antes de escrever o código.
+
+ - É inteiramente possível que outros desenvolvedores já tenham pensado sobre
+   o problema; eles podem ter ideias para uma solução melhor e podem estar
+   dispostos a ajudar na criação dessa solução.
+
+Anos de experiência com a comunidade de desenvolvimento do kernel ensinaram uma
+lição clara: códigos do kernel que são projetados e desenvolvidos a portas
+fechadas invariavelmente apresentam problemas que só são revelados quando o
+código é lançado na comunidade. Às vezes, esses problemas são graves, exigindo
+meses ou anos de esforço antes que o código possa ser adequado aos padrões da
+comunidade do kernel. Alguns exemplos incluem:
+
+ - A pilha de rede Devicescape foi projetada e implementada para sistemas
+   monoprocessados. Ela não pôde ser integrada ao kernel principal (*mainline*)
+   até que fosse adaptada para sistemas multiprocessados. Ajustar retroativamente
+   mecanismos de travamento (*locking*) e afins em um código é uma tarefa difícil;
+   como resultado, a integração desse código (hoje chamado mac80211) foi atrasada
+   por mais de um ano.
+
+ - O sistema de arquivos Reiser4 incluía uma série de capacidades que, na
+   opinião dos desenvolvedores principais do kernel, deveriam ter sido
+   implementadas na camada de sistema de arquivos virtual (*Virtual Filesystem*
+   ou VFS). Ele também incluía recursos que não podiam ser facilmente
+   implementados sem expor o sistema a travamentos mútuos (*deadlocks*) causados
+   pelo usuário. A revelação tardia desses problemas — e a recusa em corrigir
+   alguns deles — fez com que o Reiser4 permanecesse fora do kernel principal
+   (*mainline*).
+
+ - O módulo de segurança AppArmor fazia uso de estruturas de dados internas
+   do sistema de arquivos virtual de maneiras que eram
+   consideradas inseguras e não confiáveis. Essa preocupação (entre outras)
+   manteve o AppArmor fora do kernel principal (*mainline*) por anos.
+
+In each of these cases, a great deal of pain and extra work could have been
+avoided with some early discussion with the kernel developers.
+
+
+Como encontrar os mantenedores?
+-------------------------------
+
+Quando os desenvolvedores decidem tornar seus planos públicos, a próxima
+pergunta será: por onde começamos? A resposta é encontrar a(s) lista(s) de
+discussão correta(s) e o mantenedor adequado. Para listas de discussão, a
+melhor abordagem é procurar no arquivo MAINTAINERS por um local relevante para
+postar. Se houver uma lista de subsistema adequada, postar nela costuma ser
+preferível a postar na linux-kernel; é mais provável que você alcance
+desenvolvedores com experiência no subsistema relevante e o ambiente pode ser
+mais acolhedor.
+
+Encontrar os mantenedores pode ser um pouco mais difícil. Novamente, o arquivo
+MAINTAINERS é o lugar para começar. No entanto, esse arquivo tende a não estar
+sempre atualizado, e nem todos os subsistemas estão representados ali. A
+pessoa listada no arquivo MAINTAINERS pode, na verdade, não ser quem está
+atuando nessa função atualmente. Portanto, quando houver dúvidas sobre quem
+contactar, um truque útil é usar o git (e o "git log" em particular) para ver
+quem está ativo no momento dentro do subsistema de interesse. Observe quem
+está escrevendo os patches e quem, se houver alguém, está anexando linhas
+"Signed-off-by" a esses patches. Essas são as pessoas que estarão em melhor
+posição para ajudar com um novo projeto de desenvolvimento.
+
+A tarefa de encontrar o mantenedor correto às vezes é desafiadora o suficiente
+para que os desenvolvedores do kernel tenham adicionado um script para facilitar
+o processo:
+
+::
+
+	.../scripts/get_maintainer.pl
+
+Este script retornará o(s) mantenedor(es) atual(is) para um determinado arquivo
+ou diretório quando fornecida a opção "-f". Se receber um patch na linha de
+comando, ele listará os mantenedores que provavelmente devem receber cópias do
+patch. Esta é a maneira preferencial (ao contrário da opção "-f") de obter a
+lista de pessoas para incluir em cópia (Cc) nos seus patches. Há uma série de
+opções que regulam o quão profundamente o get_maintainer.pl buscará por
+mantenedores; por favor, tenha cuidado ao usar as opções mais agressivas, pois
+você pode acabar incluindo desenvolvedores que não têm interesse real no código
+que você está modificando.
+
+Se tudo mais falhar, falar com Andrew Morton pode ser uma maneira eficaz de
+rastrear um mantenedor para um trecho específico de código.
+
+
+Quando postar?
+--------------
+
+Se possível, postar seus planos durante os estágios iniciais só pode
+ser útil. Descreva o problema que está sendo resolvido e quaisquer
+planos que tenham sido feitos sobre como a implementação será feita.
+Qualquer informação que você possa fornecer pode ajudar a comunidade de
+desenvolvimento a dar contribuições úteis sobre o projeto.
+
+Uma coisa desanimadora que pode acontecer neste estágio não é uma
+reação hostil, mas, em vez disso, pouca ou nenhuma reação. A triste
+verdade sobre o assunto é que (1) os desenvolvedores do kernel tendem a
+estar ocupados, (2) não há escassez de pessoas com planos grandiosos e
+pouco código (ou mesmo perspectiva de código) para apoiá-los, e (3)
+ninguém é obrigado a revisar ou comentar sobre ideias postadas por
+outros. Além disso, designs de alto nível frequentemente escondem
+problemas que só são revelados quando alguém realmente tenta
+implementar esses designs; por essa razão, os desenvolvedores do kernel
+preferem ver o código.
+
+Se uma postagem de pedido de comentários (RFC) render poucos
+comentários, não presuma que isso significa que não há interesse no
+projeto. Infelizmente, você também não pode presumir que não há
+problemas com sua ideia. A melhor coisa a fazer nesta situação é
+prosseguir, mantendo a comunidade informada à medida que avança.
+
+
+Obter a aprovação oficial
+-------------------------
+
+Se o seu trabalho estiver sendo realizado em um ambiente corporativo  como é o
+caso da maior parte do trabalho no kernel do Linux —, você deve, obviamente, ter
+a permissão de gerentes devidamente autorizados antes de poder publicar os
+planos ou o código da sua empresa em uma lista de discussão pública.
+A publicação de código que não tenha sido liberado para lançamento sob uma
+licença compatível com a GPL pode ser especialmente problemática; quanto mais
+cedo a gerência e a equipe jurídica de uma empresa puderem entrar em acordo
+sobre a publicação de um projeto de desenvolvimento do kernel, melhor será para
+todos os envolvidos.
+
+Alguns leitores podem estar pensando, neste ponto, que o seu trabalho no kernel
+se destina a dar suporte a um produto que ainda não tem uma existência oficialmente
+reconhecida. Revelar os planos de seu empregador em uma lista de discussão pública
+pode não ser uma opção viável. Em casos como esse, vale a pena considerar se o
+segredo é realmente necessário; muitas vezes não há uma real necessidade de manter
+os planos de desenvolvimento a portas fechadas.
+
+Dito isso, também existem casos em que uma empresa legitimamente não pode
+revelar seus planos logo no início do processo de desenvolvimento. Empresas com
+desenvolvedores de kernel experientes podem optar por prosseguir de maneira isolada
+(em "malha aberta"), partindo do pressuposto de que serão capazes de evitar problemas
+graves de integração mais tarde. Para empresas que não possuem esse tipo de expertise
+interna, a melhor opção costuma ser a contratação de um desenvolvedor externo para
+revisar os planos sob um acordo de confidencialidade (NDA). A Linux Foundation opera
+um programa de NDA projetado para ajudar nesse tipo de situação; mais informações
+podem ser encontradas em:
+
+    https://www.linuxfoundation.org/nda/
+
+Esse tipo de revisão costuma ser suficiente para evitar problemas graves mais
+tarde, sem a necessidade de uma divulgação pública do projeto.
diff --git a/Documentation/translations/pt_BR/process/development-process.rst b/Documentation/translations/pt_BR/process/development-process.rst
index 737fdcdffd4a..599c34c859be 100644
--- a/Documentation/translations/pt_BR/process/development-process.rst
+++ b/Documentation/translations/pt_BR/process/development-process.rst
@@ -19,3 +19,4 @@ conhecimento profundo de programação de kernel para ser compreendida.
 
    1.Intro
    2.Process
+   3.Early-stage
diff --git a/Documentation/translations/pt_BR/process/maintainer-soc.rst b/Documentation/translations/pt_BR/process/maintainer-soc.rst
index 5a3ae213ef67..eb8040a62109 100644
--- a/Documentation/translations/pt_BR/process/maintainer-soc.rst
+++ b/Documentation/translations/pt_BR/process/maintainer-soc.rst
@@ -8,7 +8,7 @@ Visão Geral
 -----------
 
 O subsistema SoC é um local de agregação para códigos específicos de SoC
-System on Chip). Os principais componentes do subsistema são:
+(System on Chip). Os principais componentes do subsistema são:
 
 * Devicetrees (DTS) para ARM de 32 e 64 bits e RISC-V.
 * Arquivos de placa (board files) ARM de 32 bits (arch/arm/mach*).
@@ -220,3 +220,13 @@ A linha de assunto de um pull request deve começar com "[GIT PULL]" e ser feita
 usando uma tag assinada, em vez de um branch. Esta tag deve conter uma breve
 descrição resumindo as alterações no pull request. Para mais detalhes sobre o
 envio de pull requests, consulte ``Documentation/maintainer/pull-requests.rst``.
+
+Propósito dos Defconfigs
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Defconfigs são usados principalmente pelos desenvolvedores do kernel, porque as
+distribuições têm suas próprias configurações. Uma mudança que adiciona novas
+opções CONFIG a um defconfig deve explicar por que os desenvolvedores do kernel
+em geral gostariam de tal opção, por exemplo, fornecendo o nome de uma máquina/placa
+suportada usando essa nova opção. Isso implica que habilitar opções em defconfig
+para máquinas não upstream não deve ser aceito.
diff --git a/Documentation/translations/sp_SP/process/submit-checklist.rst b/Documentation/translations/sp_SP/process/submit-checklist.rst
index e7107cc97001..aedf55eb3b80 100644
--- a/Documentation/translations/sp_SP/process/submit-checklist.rst
+++ b/Documentation/translations/sp_SP/process/submit-checklist.rst
@@ -76,7 +76,7 @@ y en otros lugares con respecto al envío de parches del kernel de Linux.
     cualquier problema.
 
 12) Ha sido probado con ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
-    ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
+    ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
     ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``
     ``CONFIG_PROVE_RCU`` y ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` todos
     habilitados simultáneamente.
diff --git a/Documentation/translations/zh_CN/process/submit-checklist.rst b/Documentation/translations/zh_CN/process/submit-checklist.rst
index 0e524f1c1af5..18411b426122 100644
--- a/Documentation/translations/zh_CN/process/submit-checklist.rst
+++ b/Documentation/translations/zh_CN/process/submit-checklist.rst
@@ -65,7 +65,7 @@ Linux内核补丁提交检查单
     :ref:`kernel-doc <kernel_doc_zh>` 并修复任何问题。
 
 12) 通过以下选项同时启用的测试： ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
-    ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
+    ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
     ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
     ``CONFIG_PROVE_RCU`` 和 ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` 。
 
diff --git a/Documentation/translations/zh_TW/process/submit-checklist.rst b/Documentation/translations/zh_TW/process/submit-checklist.rst
index a0cb91a6945f..06aa635a659c 100644
--- a/Documentation/translations/zh_TW/process/submit-checklist.rst
+++ b/Documentation/translations/zh_TW/process/submit-checklist.rst
@@ -68,7 +68,7 @@ Linux內核補丁提交檢查單
     :ref:`kernel-doc <kernel_doc_zh>` 並修復任何問題。
 
 12) 通過以下選項同時啓用的測試： ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
-    ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
+    ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
     ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
     ``CONFIG_PROVE_RCU`` 和 ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` 。