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

Pull documentation updates from Jonathan Corbet:
 "Nothing hugely exciting happening in the documentation tree this time
  around, mostly more of the usual:

   - More Spanish, Italian, and Chinese translations

   - A new script, scripts/checktransupdate.py, can be used to see which
     commits have touched an (English) document since a given
     translation was last updated.

   - A couple of "best practices" suggestions (on Link: tags and
     off-list discussions) that were not entirely at consensus level,
     but I concluded they were close enough to accept.

   - Some nice cleanups removing documentation for kernel parameters
     that have not been recognized for ... a long time.

  ...along with the usual updates, typo fixes, and such"

* tag 'docs-6.11' of git://git.lwn.net/linux: (57 commits)
  Documentation: Document user_events ioctl code
  docs/pinctrl: fix typo in mapping example
  docs: maintainer: discourage taking conversations off-list
  docs: driver-model: platform: update the definition of platform_driver
  docs/sp_SP: Add translation for scheduler/sched-design-CFS.rst
  writing_musb_glue_layer.rst: Fix broken URL
  zh_CN/admin-guide: one typo fix
  docs/zh_CN/virt: Update the translation of guest-halt-polling.rst
  Documentation: add reference from dynamic debug to loglevel kernel params
  Documentation: best practices for using Link trailers
  Documentation: fix links to mailing list services
  Documentation: exception-tables.rst: Fix the wrong steps referenced
  docs/zh_CN: add process/researcher-guidelines Chinese translation
  Documentation/tools/rv: fix document header
  docs/sp_SP: Add translation of process/maintainer-kvm-x86.rst
  docs/admin-guide/mm: correct typo 'quired' to 'queried'
  Add libps2 to the input section of driver-api
  Docs/mm/index: move allocation profiling document to unsorted documents chapter
  Docs/mm/index: rename 'Legacy Documentation' to 'Unsorted Documentation'
  Docs/mm/index: Remove 'Memory Management Guide' chapter marker
  ...

37 files changed, 1582 insertions, 194 deletions

diff --git a/Documentation/translations/it_IT/riscv/patch-acceptance.rst b/Documentation/translations/it_IT/arch/riscv/patch-acceptance.rst
index 2d7afb1f6959..e0ad63643f1b 100644
--- a/Documentation/translations/it_IT/riscv/patch-acceptance.rst
+++ b/Documentation/translations/it_IT/arch/riscv/patch-acceptance.rst
@@ -1,6 +1,6 @@
-.. include:: ../disclaimer-ita.rst
+.. include:: ../../disclaimer-ita.rst
 
-:Original: :doc:`../../../arch/riscv/patch-acceptance`
+:Original: :doc:`../../../../arch/riscv/patch-acceptance`
 :Translator: Federico Vaga <federico.vaga@vaga.pv.it>
 
 arch/riscv linee guida alla manutenzione per gli sviluppatori
@@ -22,6 +22,26 @@ sperimentale.  Desideriamo estendere questi stessi principi al codice
 relativo all'architettura RISC-V che verrà accettato per l'inclusione
 nel kernel.
 
+Patchwork
+---------
+
+RISC-V ha un'istanza di patchwork dov'è possibile controllare lo stato delle patch:
+
+  https://patchwork.kernel.org/project/linux-riscv/list/
+
+Se la vostra patch non appare nella vista predefinita, i manutentori di RISC-V
+hanno probabilmente richiesto delle modifiche o si aspettano che venga applicata
+a un altro albero.
+
+Il processo automatico viene eseguito su questa istanza di patchwork, costruendo
+e collaudando le patch man mano che arrivano. Il processo applica le patch al
+riferimento HEAD corrente dei rami `for-next` e `fixes` dei sorgenti RISC-V,
+questo a seconda che la patch sia stata o meno individuata come correzione. In
+caso contrario, utilizzerà il ramo `master` di RISC-V. L'esatto commit a cui è
+stata applicata una serie di patch sarà annotato su patchwork. È improbabile che
+vengano applicate Le patch che non passano i controlli, nella maggior parte dei
+casi dovranno essere ripresentate.
+
 In aggiunta alla lista delle verifiche da fare prima di inviare una patch
 -------------------------------------------------------------------------
 
diff --git a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
index 74057d203539..aa0e31d353d6 100644
--- a/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
+++ b/Documentation/translations/it_IT/doc-guide/kernel-doc.rst
@@ -370,6 +370,50 @@ Anche i tipi di dato per prototipi di funzione possono essere documentati::
    */
    typedef void (*type_name)(struct v4l2_ctrl *arg1, void *arg2);
 
+Documentazione di macro simili a oggetti
+----------------------------------------
+
+Le macro simili a oggetti si distinguono dalle macro simili a funzione. Esse si
+distinguono in base al fatto che il nome della macro simile a funzione sia
+immediatamente seguito da una parentesi sinistra ('(') mentre in quelle simili a
+oggetti no.
+
+Le macro simili a funzioni sono gestite come funzioni da ``scripts/kernel-doc``.
+Possono avere un elenco di parametri. Le macro simili a oggetti non hanno un
+elenco di parametri.
+
+Il formato generale di un commento kernel-doc per una macro simile a oggetti è::
+
+  /**
+   * define object_name - Brief description.
+   *
+   * Description of the object.
+   */
+
+Esempio::
+
+  /**
+   * define MAX_ERRNO - maximum errno value that is supported
+   *
+   * Kernel pointers have redundant information, so we can use a
+   * scheme where we can return either an error code or a normal
+   * pointer with the same return value.
+   */
+  #define MAX_ERRNO	4095
+
+Esempio::
+
+  /**
+   * define DRM_GEM_VRAM_PLANE_HELPER_FUNCS - \
+   *	Initializes struct drm_plane_helper_funcs for VRAM handling
+   *
+   * This macro initializes struct drm_plane_helper_funcs to use the
+   * respective helper functions.
+   */
+  #define DRM_GEM_VRAM_PLANE_HELPER_FUNCS \
+	.prepare_fb = drm_gem_vram_plane_helper_prepare_fb, \
+	.cleanup_fb = drm_gem_vram_plane_helper_cleanup_fb
+
 Marcatori e riferimenti
 -----------------------
 
diff --git a/Documentation/translations/it_IT/doc-guide/parse-headers.rst b/Documentation/translations/it_IT/doc-guide/parse-headers.rst
index c7076a21667a..026a23e49767 100644
--- a/Documentation/translations/it_IT/doc-guide/parse-headers.rst
+++ b/Documentation/translations/it_IT/doc-guide/parse-headers.rst
@@ -63,7 +63,7 @@ DESCRIZIONE
 ***********
 
 Converte un file d'intestazione o un file sorgente C (C_FILE) in un testo
-ReStructuredText incluso mediante il blocco ..parsed-literal
+reStructuredText incluso mediante il blocco ..parsed-literal
 con riferimenti alla documentazione che descrive l'API. Opzionalmente,
 il programma accetta anche un altro file (EXCEPTIONS_FILE) che
 descrive quali elementi debbano essere ignorati o il cui riferimento
diff --git a/Documentation/translations/it_IT/process/5.Posting.rst b/Documentation/translations/it_IT/process/5.Posting.rst
index a7e2a3238415..a61d9e6f7433 100644
--- a/Documentation/translations/it_IT/process/5.Posting.rst
+++ b/Documentation/translations/it_IT/process/5.Posting.rst
@@ -223,8 +223,9 @@ Un'etichetta ci può dire quale commit ha introdotto il problema che viene corre
        Fixes: 1f2e3d4c5b6a ("The first line of the commit specified by the first 12 characters of its SHA-1 ID")
 
 Un'altra etichetta viene usata per fornire collegamenti a pagine web contenenti
-maggiori informazioni, per esempio un rapporto circa il baco risolto dalla
-patch, oppure un documento con le specifiche implementate dalla patch::
+maggiori informazioni, per esempio una discussione avvenuta precedentemente
+circa il baco risolto dalla patch, oppure un documento con le specifiche
+implementate dalla patch::
 
        Link: https://example.com/somewhere.html  optional-other-stuff
 
@@ -233,7 +234,19 @@ alla più recente discussione pubblica. A volte questo è fatto automaticamente
 alcuni strumenti come b4 or un *hook* git come quello descritto qui
 'Documentation/translations/it_IT/maintainer/configure-git.rst'
 
-Un terzo tipo di etichetta viene usato per indicare chi ha contribuito allo
+
+Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch,
+allora usate l'etichetta "Closes:"::
+
+       Closes: https://example.com/issues/1234  optional-other-stuff
+
+Alcune piattaforme di tracciamento di bachi hanno la capacità di chiudere
+automaticamente il problema se l'etichetta è presente nel messaggio. Alcuni
+automatismi che monitorano la liste di discussione possono anche tracciare
+queste etichette e intraprendere azioni. Piattaforme private e URL invalidi sono
+proibiti.
+
+Un altro tipo di etichetta viene usato per indicare chi ha contribuito allo
 sviluppo della patch. Tutte queste etichette seguono il formato::
 
 	tag: Full Name <email address>  optional-other-stuff
@@ -267,7 +280,13 @@ Le etichette in uso più comuni sono:
  - Reported-by: menziona l'utente che ha riportato il problema corretto da
    questa patch; quest'etichetta viene usata per dare credito alle persone che
    hanno verificato il codice e ci hanno fatto sapere quando le cose non
-   funzionavano correttamente. Se esiste un rapporto disponibile sul web, allora
+   funzionavano correttamente. Questa etichetta dovrebbe essere seguita da
+   quella Closes: con un indirizzo al rapporto, a meno che questo non sia
+   disponibile sul web. L'etichetta Link: può essere usata in alternativa a
+   Closes: se la patch corregge solo in parte il problema riportato nel
+   rapporto.
+
+   Se esiste un rapporto disponibile sul web, allora
    L'etichetta dovrebbe essere seguita da un collegamento al suddetto rapporto.
 
  - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto
diff --git a/Documentation/translations/it_IT/process/6.Followthrough.rst b/Documentation/translations/it_IT/process/6.Followthrough.rst
index df7d5fb28832..685eee5690f3 100644
--- a/Documentation/translations/it_IT/process/6.Followthrough.rst
+++ b/Documentation/translations/it_IT/process/6.Followthrough.rst
@@ -60,6 +60,13 @@ resa molto più facile se tenete presente alcuni dettagli:
    stanno lavorando per la creazione del miglior kernel possibile; non
    stanno cercando di creare un disagio ad aziende concorrenti.
 
+  - Preparatevi a richieste apparentemente sciocche di modifiche allo stile di
+    codifica e a richieste di trasferire parte del vostro codice in parti
+    condivise del kernel. Uno dei compiti dei manutentori è quello di mantenere
+    lo aspetto del codice. A volte questo significa che l'ingegnoso stratagemma
+    nel vostro driver per aggirare un problema deve diventare una caratteristica
+    generalizzata del kernel pronta per essere riutilizzata.
+
 Quello che si sta cercando di dire è che, quando i revisori vi inviano degli
 appunti dovete fare attenzione alle osservazioni tecniche che vi stanno
 facendo.  Non lasciate che il loro modo di esprimersi o il vostro orgoglio
diff --git a/Documentation/translations/it_IT/process/7.AdvancedTopics.rst b/Documentation/translations/it_IT/process/7.AdvancedTopics.rst
index a83fcfe18024..b3d8b62f3b57 100644
--- a/Documentation/translations/it_IT/process/7.AdvancedTopics.rst
+++ b/Documentation/translations/it_IT/process/7.AdvancedTopics.rst
@@ -200,7 +200,7 @@ all'ABI dello spazio utente, eccetera.  Qualunque tipo di revisione è ben
 accetta e di valore, se porta ad avere un codice migliore nel kernel.
 
 Non esistono requisiti particolarmente stringenti per l'uso di etichette come
-``Reviewd-by``. Tuttavia, perché la revisione sia efficace ci si aspetta un
+``Reviewed-by``. Tuttavia, perché la revisione sia efficace ci si aspetta un
 qualche tipo di messaggio che dica "ho verificato A, B e C nel codice che è
 appena stato inviato e mi sembra tutto in ordine". Inoltre, questo permette ai
 manutentori di prendere conoscenza circa una revisione avvenuta per davvero.
diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documentation/translations/it_IT/process/changes.rst
index ade695a7de19..0bcf8423cc80 100644
--- a/Documentation/translations/it_IT/process/changes.rst
+++ b/Documentation/translations/it_IT/process/changes.rst
@@ -33,8 +33,8 @@ PC Card, per esempio, probabilmente non dovreste preoccuparvi di pcmciautils.
         Programma       Versione minima       Comando per verificare la versione
 ====================== =================  ========================================
 GNU C                  5.1                gcc --version
-Clang/LLVM (optional)  11.0.0             clang --version
-Rust (opzionale)       1.74.1             rustc --version
+Clang/LLVM (optional)  13.0.0             clang --version
+Rust (opzionale)       1.76.0             rustc --version
 bindgen (opzionale)    0.65.1             bindgen --version
 GNU make               3.81               make --version
 bash                   4.2                bash --version
diff --git a/Documentation/translations/it_IT/process/clang-format.rst b/Documentation/translations/it_IT/process/clang-format.rst
index 29f83c198025..6fab07772da0 100644
--- a/Documentation/translations/it_IT/process/clang-format.rst
+++ b/Documentation/translations/it_IT/process/clang-format.rst
@@ -1,6 +1,6 @@
 .. include:: ../disclaimer-ita.rst
 
-:Original: :ref:`Documentation/process/clang-format.rst <clangformat>`
+:Original: :ref:`Documentation/dev-tools/clang-format.rst <clangformat>`
 :Translator: Federico Vaga <federico.vaga@vaga.pv.it>
 
 .. _it_clangformat:
diff --git a/Documentation/translations/it_IT/process/index.rst b/Documentation/translations/it_IT/process/index.rst
index 73c643dcc541..c24500f74660 100644
--- a/Documentation/translations/it_IT/process/index.rst
+++ b/Documentation/translations/it_IT/process/index.rst
@@ -107,7 +107,7 @@ perché non si è trovato un posto migliore.
 
    magic-number
    clang-format
-   ../riscv/patch-acceptance
+   ../arch/riscv/patch-acceptance
 
 .. only::  subproject and html
 
diff --git a/Documentation/translations/it_IT/process/magic-number.rst b/Documentation/translations/it_IT/process/magic-number.rst
index ae92ab633c16..cd8f23571835 100644
--- a/Documentation/translations/it_IT/process/magic-number.rst
+++ b/Documentation/translations/it_IT/process/magic-number.rst
@@ -1,6 +1,6 @@
 .. include:: ../disclaimer-ita.rst
 
-:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>`
+:Original: :ref:`Documentation/staging/magic-number.rst <magicnumbers>`
 :Translator: Federico Vaga <federico.vaga@vaga.pv.it>
 
 .. _it_magicnumbers:
diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.rst b/Documentation/translations/it_IT/process/stable-kernel-rules.rst
index a2577a806a18..b1592f10f7a7 100644
--- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst
+++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst
@@ -11,32 +11,31 @@ Tutto quello che volevate sapere sui rilasci -stable di Linux
 Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
 "-stable":
 
- - Ovviamente dev'essere corretta e verificata.
- - Non dev'essere più grande di 100 righe, incluso il contesto.
- - Deve correggere una cosa sola.
- - Deve correggere un baco vero che sta disturbando gli utenti (non cose del
-   tipo "Questo potrebbe essere un problema ...").
- - Deve correggere un problema di compilazione (ma non per cose già segnate
-   con CONFIG_BROKEN), un kernel oops, un blocco, una corruzione di dati,
-   un vero problema di sicurezza, o problemi del tipo "oh, questo non va bene".
-   In pratica, qualcosa di critico.
- - Problemi importanti riportati dagli utenti di una distribuzione potrebbero
-   essere considerati se correggono importanti problemi di prestazioni o di
-   interattività.  Dato che questi problemi non sono così ovvi e la loro
-   correzione ha un'alta probabilità d'introdurre una regressione, dovrebbero
-   essere sottomessi solo dal manutentore della distribuzione includendo un
-   link, se esiste, ad un rapporto su bugzilla, e informazioni aggiuntive
-   sull'impatto che ha sugli utenti.
- - Non deve correggere problemi relativi a una "teorica sezione critica",
-   a meno che non venga fornita anche una spiegazione su come questa si
-   possa verificare.
- - Non deve includere alcuna correzione "banale" (correzioni grammaticali,
-   pulizia dagli spazi bianchi, eccetera).
- - Deve rispettare le regole scritte in
-   :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
- - Questa patch o una equivalente deve esistere già nei sorgenti principali di
-   Linux
-
+- Questa patch o una equivalente deve esistere già nei sorgenti principali di
+  Linux (upstream)
+- Ovviamente dev'essere corretta e verificata.
+- Non dev'essere più grande di 100 righe, incluso il contesto.
+- Deve rispettare le regole scritte in
+  :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
+- Deve correggere un vero baco che causi problemi agli utenti oppure aggiunge
+  un nuovo identificatore di dispositivo. Maggiori dettagli per il primo caso:
+
+  - Corregge un problema come un oops, un blocco, una corruzione di dati, un
+    vero problema di sicurezza, una stranezza hardware, un problema di
+    compilazione (ma non per cose già segnate con CONFIG_BROKEN), o problemi
+    del tipo "oh, questo non va bene".
+  - Problemi importanti riportati dagli utenti di una distribuzione potrebbero
+    essere considerati se correggono importanti problemi di prestazioni o di
+    interattività. Dato che questi problemi non sono così ovvi e la loro
+    correzione ha un'alta probabilità d'introdurre una regressione,
+    dovrebbero essere sottomessi solo dal manutentore della distribuzione
+    includendo un link, se esiste, ad un rapporto su bugzilla, e informazioni
+    aggiuntive sull'impatto che ha sugli utenti.
+  - Non si accettano cose del tipo "Questo potrebbe essere un problema ..."
+    come una teorica sezione critica, senza aver fornito anche una spiegazione
+    su come il baco possa essere sfruttato.
+  - Non deve includere alcuna correzione "banale" (correzioni grammaticali,
+    pulizia dagli spazi bianchi, eccetera).
 
 Procedura per sottomettere patch per i sorgenti -stable
 -------------------------------------------------------
@@ -46,177 +45,204 @@ Procedura per sottomettere patch per i sorgenti -stable
   di revisione -stable, ma dovrebbe seguire le procedure descritte in
   :ref:`Documentation/translations/it_IT/process/security-bugs.rst <it_securitybugs>`.
 
-Per tutte le altre sottomissioni, scegliere una delle seguenti procedure
-------------------------------------------------------------------------
+Ci sono tre opzioni per inviare una modifica per i sorgenti -stable:
+
+1. Aggiungi un'etichetta 'stable' alla descrizione della patch al momento della
+   sottomissione per l'inclusione nei sorgenti principali.
+2. Chiedere alla squadra "stable" di prendere una patch già applicata sui
+   sorgenti principali
+3. Sottomettere una patch alla squadra "stable" equivalente ad una modifica già
+   fatta sui sorgenti principali.
+
+Le seguenti sezioni descrivono con maggiori dettagli ognuna di queste opzioni
+
+L':ref:`it_option_1` è **fortemente** raccomandata; è il modo più facile e
+usato. L':ref:`it_option_2` si usa quando al momento della sottomissione non si
+era pensato di riportare la modifica su versioni precedenti.
+L':ref:`it_option_3` è un'alternativa ai due metodi precedenti quando la patch
+nei sorgenti principali ha bisogno di aggiustamenti per essere applicata su
+versioni precedenti (per esempio a causa di cambiamenti dell'API).
+
+Quando si utilizza l'opzione 2 o 3 è possibile chiedere che la modifica sia
+inclusa in specifiche versioni stabili. In tal caso, assicurarsi che la correzione
+o una equivalente sia applicabile, o già presente in tutti i sorgenti
+stabili più recenti ancora supportati. Questo ha lo scopo di prevenire
+regressioni che gli utenti potrebbero incontrare in seguito durante
+l'aggiornamento, se ad esempio una correzione per 5.19-rc1 venisse
+riportata a 5.10.y, ma non a 5.15.y.
 
 .. _it_option_1:
 
 Opzione 1
 *********
 
-Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili,
-aggiungete l'etichetta
+Aggiungete la seguente etichetta nell'area delle firme per far sì che una patch
+che state inviando per l'inclusione nei sorgenti principali venga presa
+automaticamente anche per quelli stabili::
 
-.. code-block:: none
+  Cc: stable@vger.kernel.org
 
-     Cc: stable@vger.kernel.org
+Invece, usate ``Cc: stable@vger.kernel.org`` quando state inviando correzioni
+per vulnerabilità non ancora di pubblico dominio: questo riduce il rischio di
+esporre accidentalmente al pubblico la correzione quando si usa 'git
+send-email', perché i messaggi inviati a quell'indirizzo non vengono inviati da
+nessuna parte.
 
-nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrà
-applicata anche sui sorgenti stabili senza che l'autore o il manutentore
-del sottosistema debba fare qualcosa.
+Una volta che la patch è stata inclusa, verrà applicata anche sui sorgenti
+stabili senza che l'autore o il manutentore del sottosistema debba fare
+qualcosa.
 
-.. _it_option_2:
+Per lasciare una nota per la squadra "stable", usate commenti in linea in stile
+shell (leggere oltre per maggiori dettagli).
 
-Opzione 2
-*********
+* Specificate i prerequisiti per le patch aggiuntive::
 
-Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a
-stable@vger.kernel.org includendo: il titolo della patch, l'identificativo
-del commit, il perché pensate che debba essere applicata, e in quale versione
-del kernel la vorreste vedere.
+    Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
+    Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
+    Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
+    Cc: <stable@vger.kernel.org> # 3.3.x
+    Signed-off-by: Ingo Molnar <mingo@elte.hu>
 
-.. _it_option_3:
+  La sequenza di etichette ha il seguente significato::
 
-Opzione 3
-*********
+     git cherry-pick a1f84a3
+     git cherry-pick 1b9508f
+     git cherry-pick fd21073
+     git cherry-pick <this commit>
 
-Inviata la patch, dopo aver verificato che rispetta le regole descritte in
-precedenza, a stable@vger.kernel.org.  Dovete annotare nel changelog
-l'identificativo del commit nei sorgenti principali, così come la versione
-del kernel nel quale vorreste vedere la patch.
+  Notate che per una serie di patch non dovere elencare come necessarie tutte
+  le patch della serie stessa. Per esempio se avete la seguente serie::
 
-L':ref:`it_option_1` è fortemente raccomandata; è il modo più facile e usato.
-L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento
-dell'inclusione dei sorgenti principali, si ritiene che non debbano essere
-incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero
-fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è
-particolarmente utile se una patch dev'essere riportata su una versione
-precedente (per esempio la patch richiede modifiche a causa di cambiamenti di
-API).
+     patch1
+     patch2
 
-Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei
-sorgenti principali (per esempio perché è stato necessario un lavoro di
-adattamento) allora dev'essere ben documentata e giustificata nella descrizione
-della patch.
+  dove patch2 dipende da patch1, non dovete elencare patch1 come requisito per
+  patch2 se avete già menzionato patch1 per l'inclusione in "stable"
 
-L'identificativo del commit nei sorgenti principali dev'essere indicato sopra
-al messaggio della patch, così:
+* Evidenziate le patch che hanno dei requisiti circa la versione del kernel::
 
-.. code-block:: none
+    Cc: <stable@vger.kernel.org> # 3.3.x
 
-    commit <sha1> upstream.
+  L'etichetta ha il seguente significato::
 
-o in alternativa:
+     git cherry-pick <this commit>
 
-.. code-block:: none
+  per ogni sorgente "-stable" che inizia con la versione indicata.
 
-    [ Upstream commit <sha1>  ]
+  Notate che queste etichette non sono necessarie se la squadre "stable" può
+  dedurre la versione dalle etichette Fixes:
 
-In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero
-dipendere da altre che devo essere incluse. Questa situazione può essere
-indicata nel seguente modo nell'area dedicata alle firme:
+* Ritardare l'inclusione di patch::
+    Cc: <stable@vger.kernel.org> # after -rc3
 
-.. code-block:: none
+* Evidenziare problemi noti::
 
-     Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
-     Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
-     Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
-     Cc: <stable@vger.kernel.org> # 3.3.x
-     Signed-off-by: Ingo Molnar <mingo@elte.hu>
+     Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3
 
-La sequenza di etichette ha il seguente significato:
+Esiste un'ulteriore variante per l'etichetta "stable" che permette di comunicare
+allo strumento di *backporting* di ignorare un cambiamento::
 
-.. code-block:: none
+     Cc: <stable+noautosel@kernel.org> # reason goes here, and must be present
 
-     git cherry-pick a1f84a3
-     git cherry-pick 1b9508f
-     git cherry-pick fd21073
-     git cherry-pick <this commit>
 
-Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del
-kernel. Questo può essere indicato usando il seguente formato nell'area
-dedicata alle firme:
+.. _it_option_2:
 
-.. code-block:: none
+Opzione 2
+*********
 
-     Cc: <stable@vger.kernel.org> # 3.3.x
+Se la patch è già stata inclusa nei sorgenti Linux, inviate una mail a
+stable@vger.kernel.org includendo: il titolo della patch, l'identificativo
+del commit, il perché pensate che debba essere applicata, e in quali versioni
+del kernel la vorreste vedere.
 
-L'etichetta ha il seguente significato:
+.. _it_option_3:
 
-.. code-block:: none
+Opzione 3
+*********
 
-     git cherry-pick <this commit>
+Dopo aver verificato che rispetta le regole descritte in precedenza, inviata la
+patch a stable@vger.kernel.org facendo anche menzione delle versioni nella quale
+si vorrebbe applicarla. Nel farlo, dovete annotare nel changelog
+l'identificativo del commit nei sorgenti principali, così come la versione del
+kernel nel quale vorreste vedere la patch.::
 
-per ogni sorgente "-stable" che inizia con la versione indicata.
+    commit <sha1> upstream.
 
-Dopo la sottomissione:
+o in alternativa::
 
- - Il mittente riceverà un ACK quando la patch è stata accettata e messa in
-   coda, oppure un NAK se la patch è stata rigettata.  A seconda degli impegni
-   degli sviluppatori, questa risposta potrebbe richiedere alcuni giorni.
- - Se accettata, la patch verrà aggiunta alla coda -stable per essere
-   revisionata dal altri sviluppatori e dal principale manutentore del
-   sottosistema.
+    [ Upstream commit <sha1>  ]
 
+Se la patch inviata devia rispetto all'originale presente nei sorgenti
+principali (per esempio per adattarsi ad un cambiamento di API), allora questo
+dev'essere giustificato e dettagliato in modo chiaro nella descrizione.
+
+Dopo la sottomissione
+---------------------
+
+Il mittente riceverà un ACK quando la patch è stata accettata e messa in coda,
+oppure un NAK se la patch è stata rigettata. La risposta potrebbe richiedere
+alcuni giorni in funzione dei piani dei membri della squadra "stable",
+
+Se accettata, la patch verrà aggiunta alla coda -stable per essere revisionata
+dal altri sviluppatori e dal principale manutentore del sottosistema.
 
 Ciclo di una revisione
 ----------------------
 
- - Quando i manutentori -stable decidono di fare un ciclo di revisione, le
-   patch vengono mandate al comitato per la revisione, ai manutentori soggetti
-   alle modifiche delle patch (a meno che il mittente non sia anche il
-   manutentore di quell'area del kernel) e in CC: alla lista di discussione
-   linux-kernel.
- - La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK
-   alle patch.
- - Se una patch viene rigettata da un membro della commissione, o un membro
-   della lista linux-kernel obietta la bontà della patch, sollevando problemi
-   che i manutentori ed i membri non avevano compreso, allora la patch verrà
-   rimossa dalla coda.
- - Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di
-   un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e
-   dai testatori.
- - Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi
-   importanti, alcune patch potrebbero essere modificate o essere scartate,
-   oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate
-   nuove -rc e così via finché non si ritiene che non vi siano più problemi.
- - Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email
-   con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al
-   commit rilascio.
- - Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le
-   patch che erano in coda e sono state verificate.
- - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente
-   dalla squadra per la sicurezza del kernel, e non passerà per il normale
-   ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli
-   su questa procedura.
+- Quando i manutentori -stable decidono di fare un ciclo di revisione, le
+  patch vengono mandate al comitato per la revisione, ai manutentori soggetti
+  alle modifiche delle patch (a meno che il mittente non sia anche il
+  manutentore di quell'area del kernel) e in CC: alla lista di discussione
+  linux-kernel.
+- La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK
+  alle patch.
+- Se una patch viene rigettata da un membro della commissione, o un membro
+  della lista linux-kernel obietta la bontà della patch, sollevando problemi
+  che i manutentori ed i membri non avevano compreso, allora la patch verrà
+  rimossa dalla coda.
+- Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di
+  un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e
+  dai testatori.
+- Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi
+  importanti, alcune patch potrebbero essere modificate o essere scartate,
+  oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate
+  nuove -rc e così via finché non si ritiene che non vi siano più problemi.
+- Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email
+  con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al
+  commit rilascio.
+- Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le
+  patch che erano in coda e sono state verificate.
+- Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente
+  dalla squadra per la sicurezza del kernel, e non passerà per il normale
+  ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli
+  su questa procedura.
 
 Sorgenti
 --------
 
- - La coda delle patch, sia quelle già applicate che in fase di revisione,
-   possono essere trovate al seguente indirizzo:
+- La coda delle patch, sia quelle già applicate che in fase di revisione,
+  possono essere trovate al seguente indirizzo:
 
-	https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
+    https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git
 
- - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere
-   trovato in rami distinti per versione al seguente indirizzo:
+- Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere
+  trovato in rami distinti per versione al seguente indirizzo:
 
-	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
+    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
 
- - I rilasci candidati di tutti i kernel stabili possono essere trovati al
-   seguente indirizzo:
+- I rilasci candidati di tutti i kernel stabili possono essere trovati al
+  seguente indirizzo:
 
     https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/
 
-
-   .. warning::
-     I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e
-     subirà frequenti modifiche, dunque verrà anche trapiantato spesso.
-     Dovrebbe essere usato solo allo scopo di verifica (per esempio in un
-     sistema di CI)
+  .. warning::
+    I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e
+    subirà frequenti modifiche, dunque verrà anche trapiantato spesso.
+    Dovrebbe essere usato solo allo scopo di verifica (per esempio in un
+    sistema di CI)
 
 Comitato per la revisione
 -------------------------
 
- - Questo comitato è fatto di sviluppatori del kernel che si sono offerti
-   volontari per questo lavoro, e pochi altri che non sono proprio volontari.
+- Questo comitato è fatto di sviluppatori del kernel che si sono offerti
+  volontari per questo lavoro, e pochi altri che non sono proprio volontari.
diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst
index 4c6a276bdc08..a7252e73937a 100644
--- a/Documentation/translations/it_IT/process/submitting-patches.rst
+++ b/Documentation/translations/it_IT/process/submitting-patches.rst
@@ -106,9 +106,29 @@ do frotz" piuttosto che "[This patch] makes xyzzy do frotz" or "[I] changed
 xyzzy to do frotz", come se steste dando ordini al codice di cambiare il suo
 comportamento.
 
+Se volete far riferimento a uno specifico commit, non usate solo
+l'identificativo SHA-1.  Per cortesia, aggiungete anche la breve riga
+riassuntiva del commit per rendere la chiaro ai revisori l'oggetto.
+Per esempio::
+
+	Commit e21d2170f36602ae2708 ("video: remove unnecessary
+	platform_set_drvdata()") removed the unnecessary
+	platform_set_drvdata(), but left the variable "dev" unused,
+	delete it.
+
+Dovreste anche assicurarvi di usare almeno i primi 12 caratteri
+dell'identificativo SHA-1.  Il repositorio del kernel ha *molti* oggetti e
+questo rende possibile la collisione fra due identificativi con pochi
+caratteri.  Tenete ben presente che anche se oggi non ci sono collisioni con il
+vostro identificativo a 6 caratteri, potrebbero essercene fra 5 anni da oggi.
+
 Se ci sono delle discussioni, o altre informazioni d'interesse, che fanno
 riferimento alla patch, allora aggiungete l'etichetta 'Link:' per farvi
-riferimento. Per esempio, se la vostra patch corregge un baco potete aggiungere
+riferimento. Se la patch è il risultato di una discussione avvenuta
+precedentemente o di un documento sul presente sul web, allora fatevi
+riferimento.
+
+Per esempio, se la vostra patch corregge un baco potete aggiungere
 quest'etichetta per fare riferimento ad un rapporto su una lista di discussione
 o un *bug tracker*. Un altro esempio; potete usare quest'etichetta per far
 riferimento ad una discussione precedentemente avvenuta su una lista di
@@ -129,21 +149,16 @@ Tuttavia, provate comunque a dare una spiegazione comprensibile anche senza
 accedere alle fonti esterne. Inoltre, riassumente i punti più salienti che hanno
 condotto all'invio della patch.
 
-Se volete far riferimento a uno specifico commit, non usate solo
-l'identificativo SHA-1.  Per cortesia, aggiungete anche la breve riga
-riassuntiva del commit per rendere la chiaro ai revisori l'oggetto.
-Per esempio::
+Se il collegamento indirizza verso un rapporto su un baco risolto dalla patch,
+allora usate l'etichetta "Closes:"::
 
-	Commit e21d2170f36602ae2708 ("video: remove unnecessary
-	platform_set_drvdata()") removed the unnecessary
-	platform_set_drvdata(), but left the variable "dev" unused,
-	delete it.
+       Closes: https://example.com/issues/1234  optional-other-stuff
 
-Dovreste anche assicurarvi di usare almeno i primi 12 caratteri
-dell'identificativo SHA-1.  Il repositorio del kernel ha *molti* oggetti e
-questo rende possibile la collisione fra due identificativi con pochi
-caratteri.  Tenete ben presente che anche se oggi non ci sono collisioni con il
-vostro identificativo a 6 caratteri, potrebbero essercene fra 5 anni da oggi.
+Alcune piattaforme di tracciamento di bachi hanno la capacità di chiudere
+automaticamente il problema se l'etichetta è presente nel messaggio. Alcuni
+automatismi che monitorano la liste di discussione possono anche tracciare
+queste etichette e intraprendere azioni. Piattaforme private e URL invalidi sono
+proibiti.
 
 Se la vostra patch corregge un baco in un commit specifico, per esempio avete
 trovato un problema usando ``git bisect``, per favore usate l'etichetta
@@ -237,13 +252,19 @@ nella vostra patch.
 5) Selezionate i destinatari della vostra patch
 -----------------------------------------------
 
-Dovreste sempre inviare una copia della patch ai manutentori dei sottosistemi
-interessati dalle modifiche; date un'occhiata al file MAINTAINERS e alla storia
-delle revisioni per scoprire chi si occupa del codice. Lo script
-scripts/get_maintainer.pl può esservi d'aiuto (passategli il percorso alle
-vostre patch). Se non riuscite a trovare un manutentore per il sottosistema su
-cui state lavorando, allora Andrew Morton (akpm@linux-foundation.org) sarà la
-vostra ultima possibilità.
+Dovreste sempre inviare una copia della patch ai manutentori e alle liste di
+discussione dei sottosistemi interessati dalle modifiche; date un'occhiata al
+file MAINTAINERS e alla storia delle revisioni per scoprire chi si occupa del
+codice. Lo script scripts/get_maintainer.pl può esservi d'aiuto (passategli il
+percorso alle vostre patch). Se non riuscite a trovare un manutentore per il
+sottosistema su cui state lavorando, allora Andrew Morton
+(akpm@linux-foundation.org) sarà la vostra ultima possibilità.
+
+La lista linux-kernel@vger.kernel.org dovrebbe essere usata per l'invio di tutte
+le patch, ma il volume ha raggiunto un livello tale d'aver spinto alcuni
+sviluppatori a non seguirla più. Dunque, per favore, evitate di inviare messaggi
+scorrelati al tema della lista o a persone che non dovrebbero essere
+interessate all'argomento.
 
 Normalmente, dovreste anche scegliere una lista di discussione a cui inviare la
 vostra serie di patch. La lista di discussione linux-kernel@vger.kernel.org
@@ -343,7 +364,8 @@ questo caso, rispondete con educazione e concentratevi sul problema che hanno
 evidenziato. Quando inviate una versione successiva ricordatevi di aggiungere un
 ``patch changelog`` alla email di intestazione o ad ogni singola patch spiegando
 le differenze rispetto a sottomissioni precedenti (vedere
-:ref:`it_the_canonical_patch_format`).
+:ref:`it_the_canonical_patch_format`). Aggiungete a CC tutte le persone che
+vi hanno fornito dei commenti per notificarle di eventuali nuove versioni.
 
 Leggete Documentation/translations/it_IT/process/email-clients.rst per
 le raccomandazioni sui programmi di posta elettronica e l'etichetta da usare
@@ -385,10 +407,10 @@ Dopo che avete inviato le vostre modifiche, siate pazienti e aspettate.
 I revisori sono persone occupate e potrebbero non ricevere la vostra patch
 immediatamente.
 
-Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento,
-ma ora il processo di sviluppo funziona meglio.  Dovreste ricevere commenti
-in una settimana o poco più; se questo non dovesse accadere, assicuratevi di
-aver inviato le patch correttamente.  Aspettate almeno una settimana prima di
+Un tempo, le patch erano solite scomparire nel vuoto senza alcun commento, ma
+ora il processo di sviluppo funziona meglio. Dovreste ricevere commenti in poche
+settimane (tipicamente 2 o 3); se questo non dovesse accadere, assicuratevi di
+aver inviato le patch correttamente. Aspettate almeno una settimana prima di
 rinviare le modifiche o sollecitare i revisori - probabilmente anche di più
 durante la finestra d'integrazione.
 
@@ -552,6 +574,10 @@ e si spera che questo possa ispirarli ad aiutarci nuovamente in futuro.
 Rammentate che se il baco è stato riportato in privato, dovrete chiedere il
 permesso prima di poter utilizzare l'etichetta Reported-by. Questa etichetta va
 usata per i bachi, dunque non usatela per richieste di nuove funzionalità.
+Questa etichetta dovrebbe essere seguita da quella Closes: con un indirizzo al
+rapporto, a meno che questo non sia disponibile sul web. L'etichetta Link: può
+essere usata in alternativa a Closes: se la patch corregge solo in parte il
+problema riportato nel rapporto.
 
 L'etichetta Tested-by: indica che la patch è stata verificata con successo
 (su un qualche sistema) dalla persona citata.  Questa etichetta informa i
@@ -808,6 +834,63 @@ giungla di riferimenti all'interno dei programmi di posta.  Se un collegamento
 ad una versione precedente di una serie di patch (per esempio, potete usarlo
 per l'email introduttiva alla serie).
 
+Fornire informazioni circa i sorgenti
+-------------------------------------
+
+Quando gli altri sviluppatori ricevono le vostre patch e iniziano il processo di
+revisione, è assolutamente necessario che sappiano qual è il commit/ramo di base
+su cui si base il vostro lavoro: considerate l'enorme quantità di sorgenti dei
+manutentori presenti al giorno d'oggi. Si noti ancora una volta la voce **T:**
+nel file MAINTAINERS spiegato sopra.
+
+Questo è ancora più importante per i processi automatizzati di CI che tentano di
+eseguire una serie di test per stabilire la qualità del codice prima che il
+manutentore inizi la revisione.
+
+Se si usa ``git format-patch`` per generare le patch, si possono includere
+automaticamente le informazioni sull'albero di base nell'invio usando il flag
+``--base``. Il modo più semplice e comodo di usare questa opzione è con i rami
+topici::
+
+    $ git checkout -t -b my-topical-branch master
+    Branch 'my-topical-branch' set up to track local branch 'master'.
+    Switched to a new branch 'my-topical-branch'
+
+    [perform your edits and commits]
+
+    $ git format-patch --base=auto --cover-letter -o outgoing/ master
+    outgoing/0000-cover-letter.patch
+    outgoing/0001-First-Commit.patch
+    outgoing/...
+
+Aprendo ``outgoing/0000-cover-letter.patch`` per la modifica, si noterà
+che ha ``base-commit:`` in fondo, questo fornisce al revisore e agli
+strumenti CI informazioni sufficienti per eseguire correttamente ``git am``
+senza preoccuparsi dei conflitti::
+
+    $ git checkout -b patch-review [base-commit-id]
+    Switched to a new branch 'patch-review'
+    $ git am patches.mbox
+    Applying: First Commit
+    Applying: ...
+
+Consultate ``man git-format-patch`` per maggiori informazioni circa questa
+opzione.
+
+.. note::
+
+   L'opzione ``--base`` fu introdotta con git versione 2.9.0
+
+Se non si usa git per produrre le patch, si può comunque includere
+``base-commit`` per indicare l'hash del commit dei sorgenti su cui si basa il
+lavoro. Dovreste aggiungerlo nella lettera di accompagnamento o nella prima
+patch della serie e dovrebbe essere collocato sotto la riga ``---`` o in fondo a
+tutti gli altri contenuti, subito prima della vostra firma e-mail.
+
+Assicuratevi che il commit si basi su sorgenti ufficiali del
+manutentore/mainline e non su sorgenti interni, accessibile solo a voi,
+altrimenti sarebbe inutile.
+
 Riferimenti
 -----------
 
diff --git a/Documentation/translations/sp_SP/index.rst b/Documentation/translations/sp_SP/index.rst
index 274ef4ad96b9..aae7018b0d1a 100644
--- a/Documentation/translations/sp_SP/index.rst
+++ b/Documentation/translations/sp_SP/index.rst
@@ -78,3 +78,4 @@ Traducciones al español
 
    process/index
    wrappers/memory-barriers
+   scheduler/index
diff --git a/Documentation/translations/sp_SP/process/coding-style.rst b/Documentation/translations/sp_SP/process/coding-style.rst
index b5a84df44cea..025223be9706 100644
--- a/Documentation/translations/sp_SP/process/coding-style.rst
+++ b/Documentation/translations/sp_SP/process/coding-style.rst
@@ -754,7 +754,7 @@ código automáticamente, y revisar archivos completos para detectar errores
 de estilo del código, errores tipográficos y posibles mejoras. También es
 útil para ordenar ``#includes``, para alinear variables/macros, para
 redistribuir texto y otras tareas similares. Vea el archivo
-:ref:`Documentation/process/clang-format.rst <clangformat>` para más
+:ref:`Documentation/dev-tools/clang-format.rst <clangformat>` para más
 detalles.
 
 10) Archivos de configuración de Kconfig
diff --git a/Documentation/translations/sp_SP/process/index.rst b/Documentation/translations/sp_SP/process/index.rst
index 4892159310ff..adb2cc845928 100644
--- a/Documentation/translations/sp_SP/process/index.rst
+++ b/Documentation/translations/sp_SP/process/index.rst
@@ -29,3 +29,4 @@
    submit-checklist
    howto
    development-process
+   maintainer-kvm-x86
diff --git a/Documentation/translations/sp_SP/process/magic-number.rst b/Documentation/translations/sp_SP/process/magic-number.rst
index 32a99aac2f6c..beb4b4c1de11 100644
--- a/Documentation/translations/sp_SP/process/magic-number.rst
+++ b/Documentation/translations/sp_SP/process/magic-number.rst
@@ -1,6 +1,6 @@
 .. include:: ../disclaimer-sp.rst
 
-:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>`
+:Original: :ref:`Documentation/staging/magic-number.rst <magicnumbers>`
 :Translator: Carlos Bilbao <carlos.bilbao.osdev@gmail.com>
 
 .. _sp_magicnumbers:
diff --git a/Documentation/translations/sp_SP/process/maintainer-kvm-x86.rst b/Documentation/translations/sp_SP/process/maintainer-kvm-x86.rst
new file mode 100644
index 000000000000..053b6a06db01
--- /dev/null
+++ b/Documentation/translations/sp_SP/process/maintainer-kvm-x86.rst
@@ -0,0 +1,465 @@
+.. include:: ../disclaimer-sp.rst
+
+:Original: Documentation/process/maintainer-kvm-x86.rst
+:Translator: Juan Embid <jembid@ucm.es>
+
+KVM x86
+=======
+
+Prólogo
+--------
+KVM se esfuerza por ser una comunidad acogedora; las contribuciones de los
+recién llegados son valoradas e incentivadas. Por favor, no se desanime ni
+se sienta intimidado por la extensión de este documento y las numerosas
+normas/directrices que contiene. Todos cometemos errores y todos hemos sido
+principiantes en algún momento. Mientras haga un esfuerzo honesto por
+seguir las directrices de KVM x86, sea receptivo a los comentarios, y
+aprenda de los errores que cometa, será recibido con los brazos abiertos,
+no con antorchas y horcas.
+
+TL;DR
+-----
+Las pruebas son obligatorias. Sea coherente con los estilos y patrones
+establecidos.
+
+Árboles
+-------
+KVM x86 se encuentra actualmente en un período de transición de ser parte
+del árbol principal de KVM, a ser "sólo otra rama de KVM". Como tal, KVM
+x86 está dividido entre el árbol principal de KVM,
+``git.kernel.org/pub/scm/virt/kvm/kvm.git``, y un árbol específico de KVM
+x86, ``github.com/kvm-x86/linux.git``.
+
+Por lo general, las correcciones para el ciclo en curso se aplican
+directamente al árbol principal de KVM, mientras que todo el desarrollo
+para el siguiente ciclo se dirige a través del árbol de KVM x86. En el
+improbable caso de que una corrección para el ciclo actual se dirija a
+través del árbol KVM x86, se aplicará a la rama ``fixes`` antes de llegar
+al árbol KVM principal.
+
+Tenga en cuenta que se espera que este periodo de transición dure bastante
+tiempo, es decir, que será el statu quo en un futuro previsible.
+
+Ramas
+~~~~~
+El árbol de KVM x86 está organizado en múltiples ramas por temas. El
+propósito de utilizar ramas temáticas más específicas es facilitar el
+control de un área de desarrollo, y para limitar los daños colaterales de
+errores humanos y/o commits con errores, por ejemplo, borrar el commit HEAD
+de una rama temática no tiene impacto en los hashes SHA1 de otros commit
+en en camino, y tener que rechazar una solicitud de pull debido a errores
+retrasa sólo esa rama temática.
+
+Todas las ramas temáticas, excepto ``next`` y ``fixes``, se agrupan en
+``next`` a través de un Cthulhu merge en función de las necesidades, es
+decir, cuando se actualiza una rama temática. Como resultado, los push
+forzados a ``next`` son comunes.
+
+Ciclo de Vida
+~~~~~~~~~~~~~
+Las correcciones dirigidas a la versión actual, también conocida como
+mainline, suelen aplicarse directamente al árbol principal de KVM, es
+decir, no pasan por el árbol x86 de KVM.
+
+Los cambios dirigidos a la siguiente versión se dirigen a través del árbol
+KVM x86. Se envían pull requests (de KVM x86 a KVM main) para cada rama
+temática de KVM x86, normalmente la semana antes de que Linus abra la
+ventana de fusión, por ejemplo, la semana siguiente a rc7 para las
+versiones "normales". Si todo va bien, las ramas temáticas son subidas en
+el pull request principal de KVM enviado durante la ventana de fusión de
+Linus.
+
+El árbol de KVM x86 no tiene su propia ventana de fusión oficial, pero hay
+un cierre suave alrededor de rc5 para nuevas características, y un cierre
+suave alrededor de rc6 para correcciones (para la próxima versión; fíjese
+más arriba para las correcciones dirigidas a la versión actual).
+
+Cronología
+~~~~~~~~~~
+Normalmente, los envíos se revisan y aplican en orden FIFO, con cierto
+margen de maniobra en función del tamaño de la serie, los parches que están
+"calientes en caché", etc. Correcciones, especialmente para la versión
+actual y/o árboles estables, consiguen saltar la cola. Los parches que se
+lleven a través de un árbol que no sea KVM (la mayoría de las veces a
+través del árbol de consejos) y/o que tengan otros acks/revisiones también
+saltan la cola hasta cierto punto.
+
+Tenga en cuenta que la mayor parte de la revisión se realiza entre rc1 y
+rc6, más o menos. El periodo entre la rc6 y la siguiente rc1 se utiliza
+para ponerse al día en otras tareas, es decir, la falta de envíos durante
+este periodo no es inusual.
+
+Los pings para obtener una actualización del estado son bienvenidos, pero
+tenga en cuenta el calendario del ciclo de publicación actual y tenga
+expectativas realistas. Si está haciendo ping para la aceptación, es decir,
+no sólo para obtener comentarios o una actualización, por favor haga todo
+lo posible, dentro de lo razonable, para asegurarse de que sus parches
+están listos para ser fusionados. Los pings sobre series que rompen la
+compilación o fallan en las pruebas provocan el descontento de los
+mantenedores.
+
+Desarrollo
+-----------
+
+Árbol base/Rama
+~~~~~~~~~~~~~~~
+Las correcciones dirigidas a la versión actual, también conocida como
+mainline, deben basarse en
+``git://git.kernel.org/pub/scm/virt/kvm/kvm.git master``. Tenga en cuenta
+que las correcciones no garantizan automáticamente la inclusión en la
+versión actual. No hay una regla única, pero normalmente sólo las
+correcciones de errores urgentes, críticos y/o introducidos en la versión
+actual deberían incluirse en la versión actual.
+
+Todo lo demás debería basarse en ``kvm-x86/next``, es decir, no hay
+necesidad de seleccionar una rama temática específica como base. Si hay
+conflictos y/o dependencias entre ramas, es trabajo del mantenedor
+resolverlos.
+
+La única excepción al uso de ``kvm-x86/next`` como base es si un
+parche/serie es una serie multi-arquitectura, es decir, tiene
+modificaciones no triviales en el código común de KVM y/o tiene cambios más
+que superficiales en el código de otras arquitecturas. Los parches/series
+multi-arquitectura deberían basarse en un punto común y estable en la
+historia de KVM, por ejemplo, la versión candidata en la que se basa
+``kvm-x86 next``. Si no está seguro de si un parche/serie es realmente
+multiarquitectura, sea precavido y trátelo como multiarquitectura, es
+decir, utilice una base común.
+
+Estilo del codigo
+~~~~~~~~~~~~~~~~~~~~~~
+Cuando se trata de estilo, nomenclatura, patrones, etc., la coherencia es
+la prioridad número uno en KVM x86. Si todo lo demás falla, haga coincidir
+lo que ya existe.
+
+Con algunas advertencias que se enumeran a continuación, siga las
+recomendaciones de los responsables del árbol de consejos
+:ref:`maintainer-tip-coding-style`, ya que los parches/series a menudo
+tocan tanto archivos x86 KVM como no KVM, es decir, llaman la atención de
+los mantenedores de KVM *y* del árbol de consejos.
+
+El uso del abeto inverso, también conocido como árbol de Navidad inverso o
+árbol XMAS inverso, para las declaraciones de variables no es estrictamente
+necesario, aunque es preferible.
+
+Excepto para unos pocos apuntes especiales, no utilice comentarios
+kernel-doc para las funciones. La gran mayoría de las funciones "públicas"
+de KVM no son realmente públicas, ya que están destinadas únicamente al
+consumo interno de KVM (hay planes para privatizar las cabeceras y
+exportaciones de KVM para reforzar esto).
+
+Comentarios
+~~~~~~~~~~~
+Escriba los comentarios en modo imperativo y evite los pronombres. Utilice
+los comentarios para ofrecer una visión general de alto nivel del código
+y/o para explicar por qué el código hace lo que hace. No reitere lo que el
+código hace literalmente; deje que el código hable por sí mismo. Si el
+propio código es inescrutable, los comentarios no servirán de nada.
+
+Referencias SDM y APM
+~~~~~~~~~~~~~~~~~~~~~~
+Gran parte de la base de código de KVM está directamente vinculada al
+comportamiento de la arquitectura definido en El Manual de Desarrollo de
+Software (SDM) de Intel y el Manual del Programador de Arquitectura (APM)
+de AMD. El uso de "SDM de Intel" y "APM de AMD", o incluso sólo "SDM" o
+"APM", sin contexto adicional es correcto.
+
+No haga referencia a secciones específicas, tablas, figuras, etc. por su
+número, especialmente en los comentarios. En su lugar, si es necesario
+(véase más abajo), copie y pegue el fragmento correspondiente y haga
+referencia a las secciones/tablas/figuras por su nombre. Los diseños del
+SDM y el APM cambian constantemente, por lo que los números/etiquetas no
+son estables.
+
+En general, no haga referencia explícita ni copie-pegue del SDM o APM en
+los comentarios. Con pocas excepciones, KVM *debe* respetar el
+comportamiento de la arquitectura, por lo que está implícito que el
+comportamiento de KVM está emulando el comportamiento de SDM y/o APM. Tenga
+en cuenta que hacer referencia al SDM/APM en los registros de cambios para
+justificar el cambio y proporcionar contexto es perfectamente correcto y
+recomendable.
+
+Shortlog
+~~~~~~~~
+El formato de prefijo más recomendable es ``KVM: <topic>:``, donde
+``<topic>`` es uno de los siguientes::
+
+- x86
+- x86/mmu
+- x86/pmu
+- x86/xen
+- autocomprobaciones
+- SVM
+- nSVM
+- VMX
+- nVMX
+
+**¡NO use x86/kvm!** ``x86/kvm`` se usa exclusivamente para cambios de
+Linux virtualizado por KVM, es decir, para arch/x86/kernel/kvm.c. No use
+nombres de archivos o archivos completos como prefijo de asunto/shortlog.
+
+Tenga en cuenta que esto no coincide con las ramas temáticas (las ramas
+temáticas se preocupan mucho más por los conflictos de código).
+
+Todos los nombres distinguen entre mayúsculas y minúsculas. ``KVM: x86:``
+es correcto, ``kvm: vmx:`` no lo es.
+
+Escriba en mayúsculas la primera palabra de la descripción condensada del
+parche, pero omita la puntuación final. Por ejemplo::
+
+	KVM: x86: Corregir una desviación de puntero nulo en function_xyz()
+
+no::
+
+	kvm: x86: corregir una desviación de puntero nulo en function_xyz.
+
+Si un parche afecta a varios temas, recorra el árbol conceptual hasta
+encontrar el primer padre común (que suele ser simplemente ``x86``). En
+caso de duda, ``git log path/to/file`` debería proporcionar una pista
+razonable.
+
+De vez en cuando surgen nuevos temas, pero le rogamos que inicie un debate
+en la lista si desea proponer la introducción de un nuevo tema, es decir,
+no se ande con rodeos.
+
+Consulte :ref:`the_canonical_patch_format` para obtener más información,
+con una enmienda: no trate el límite de 70-75 caracteres como un límite
+absoluto y duro. En su lugar, utilice 75 caracteres como límite firme, pero
+no duro, y 80 caracteres como límite duro. Es decir, deje que el registro
+corto sobrepase en algunos caracteres el límite estándar si tiene una buena
+razón para hacerlo.
+
+Registro de cambios
+~~~~~~~~~~~~~~~~~~~
+Y lo que es más importante, escriba los registros de cambios en modo
+imperativo y evite los pronombres.
+
+Consulte :ref:`describe_changes` para obtener más información, con una
+recomendación: comience con un breve resumen de los cambios reales y
+continúe con el contexto y los antecedentes. Nota. Este orden entra en
+conflicto directo con el enfoque preferido del árbol de sugerencias. Por
+favor, siga el estilo preferido del árbol de sugerencias cuando envíe
+parches. que se dirigen principalmente a código arch/x86 que _NO_ es código
+KVM.
+
+KVM x86 prefiere indicar lo que hace un parche antes de entrar en detalles
+por varias razones. En primer lugar, el código que realmente se está
+cambiando es posiblemente la información más importante, por lo que esa
+información debe ser fácil de encontrar. Changelogs que entierran el "qué
+está cambiando realmente" en una sola línea después de 3+ párrafos de fondo
+hacen muy difícil encontrar esa información.
+
+Para la revisión inicial, se podría argumentar que "lo que está roto" es
+más importante, pero para hojear los registros y la arqueología git, los
+detalles escabrosos importan cada vez menos. Por ejemplo, al hacer una
+serie de "git blame", los detalles de cada cambio a lo largo del camino son
+inútiles, los detalles sólo importan para el culpable. Proporcionar el "qué
+ha cambiado" facilita determinar rápidamente si una confirmación puede ser
+de interés o no.
+
+Otra ventaja de decir primero "qué cambia" es que casi siempre es posible
+decir "qué cambia" en una sola frase. A la inversa, todo menos los errores
+más simples requieren varias frases o párrafos para describir el problema.
+Si tanto "qué está cambiando" como "cuál es el fallo" son muy breves, el
+orden no importa. Pero si uno es más corto (casi siempre el "qué está
+cambiando"), entonces cubrir el más corto primero es ventajoso porque es
+menos inconveniente para los lectores/revisores que tienen una preferencia
+estricta de orden. Por ejemplo, tener que saltarse una frase para llegar al
+contexto es menos doloroso que tener que saltarse tres párrafos para llegar
+a "lo que cambia".
+
+Arreglos
+~~~~~~~~
+Si un cambio corrige un error de KVM/kernel, añada una etiqueta Fixes:
+incluso si el cambio no necesita ser retroportado a kernels estables, e
+incluso si el cambio corrige un error en una versión anterior.
+
+Por el contrario, si es necesario hacer una corrección, etiquete
+explícitamente el parche con "Cc: stable@vger.kernel" (aunque no es
+necesario que el correo electrónico incluya Cc: stable); KVM x86 opta por
+excluirse del backporting Correcciones: por defecto. Algunos parches
+seleccionados automáticamente se retroportan, pero requieren la aprobación
+explícita de los mantenedores (busque MANUALSEL).
+
+Referencias a Funciones
+~~~~~~~~~~~~~~~~~~~~~~~
+Cuando se mencione una función en un comentario, registro de cambios o
+registro abreviado (o en cualquier otro lugar), utilice el formato
+``nombre_de_la_función()``. Los paréntesis proporcionan contexto y
+desambiguan la referencia.
+
+Pruebas
+~~~~~~~
+Como mínimo, *todos* los parches de una serie deben construirse limpiamente
+para KVM_INTEL=m KVM_AMD=m, y KVM_WERROR=y. Construir todas las
+combinaciones posibles de Kconfigs no es factible, pero cuantas más mejor.
+KVM_SMM, KVM_XEN, PROVE_LOCKING, y X86_64 son particularmente interesantes.
+
+También es obligatorio ejecutar las autopruebas y las pruebas unitarias de
+KVM (y, como es obvio, las pruebas deben pasar). La única excepción es para
+los cambios que tienen una probabilidad insignificante de afectar al
+comportamiento en tiempo de ejecución, por ejemplo, parches que sólo
+modificar los comentarios. Siempre que sea posible y pertinente, se
+recomienda encarecidamente realizar pruebas tanto en Intel como en AMD. Se
+recomienda arrancar una máquina virtual real, pero no es obligatorio.
+
+Para cambios que afecten al código de paginación en la sombra de KVM, es
+obligatorio ejecutar con TDP (EPT/NPT) deshabilitado. Para cambios que
+afecten al código MMU común de KVM, se recomienda encarecidamente ejecutar
+con TDP deshabilitado. Para todos los demás cambios, si el código que se
+está modificando depende de y/o interactúa con un parámetro del módulo, es
+obligatorio realizar pruebas con la configuración correspondiente.
+
+Tenga en cuenta que las autopruebas de KVM y las pruebas de unidad de KVM
+tienen fallos conocidos. Si sospecha que un fallo no se debe a sus cambios,
+verifique que el *exactamente el mismo* fallo se produce con y sin sus
+cambios.
+
+Los cambios que afecten a la documentación de texto reestructurado, es
+decir, a los archivos .rst, deben generar htmldocs de forma limpia, es
+decir, sin advertencias ni errores.
+
+Si no puede probar completamente un cambio, por ejemplo, por falta de
+hardware, indique claramente qué nivel de pruebas ha podido realizar, por
+ejemplo, en la carta de presentación.
+
+Novedades
+~~~~~~~~~
+Con una excepción, las nuevas características *deben* venir con cobertura
+de pruebas. Las pruebas específicas de KVM no son estrictamente necesarias,
+por ejemplo, si la cobertura se proporciona mediante la ejecución de una
+prueba de VM huésped suficientemente habilitada, o ejecutando una
+autoprueba de kernel relacionada en una VM, pero en todos los casos se
+prefieren las pruebas KVM dedicadas. Los casos de prueba negativos en
+particular son obligatorios para la habilitación de nuevas características
+de hardware, ya que los flujos de errores y excepciones rara vez se
+ejercitan simplemente ejecutando una VM.
+
+La única excepción a esta regla es si KVM está simplemente anunciando
+soporte para un a través de KVM_GET_SUPPORTED_CPUID, es decir, para
+instrucciones/funciones que KVM no puede impedir que utilice una VM y
+para las que no existe una verdadera habilitación.
+
+Tenga en cuenta que "nuevas características" no significa sólo "nuevas
+características de hardware". Las nuevas funcionalidades que no puedan ser
+validadas usando las pruebas existentes de KVM y/o las pruebas unitarias de
+KVM deben venir con pruebas.
+
+Es más que bienvenido el envío de nuevos desarrollos de características sin
+pruebas para obtener un feedback temprano, pero tales envíos deben ser
+etiquetados como RFC, y la carta de presentación debe indicar claramente
+qué tipo de feedback se solicita/espera. No abuse del proceso de RFC; las
+RFC no suelen recibir una revisión en profundidad.
+
+Corrección de Errores
+~~~~~~~~~~~~~~~~~~~~~
+Salvo en el caso de fallos "obvios" detectados por inspección, las
+correcciones deben ir acompañadas de un reproductor del fallo corregido. En
+muchos casos, el reproductor está implícito, por ejemplo, para errores de
+compilación y fallos de prueba, pero debe quedar claro para lectores qué es
+lo que no funciona y cómo verificar la solución. Se concede cierto margen a
+los errores detectados mediante cargas de trabajo/pruebas no públicas, pero
+se recomienda encarecidamente que se faciliten pruebas de regresión para
+dichos errores.
+
+En general, las pruebas de regresión son preferibles para cualquier fallo
+que no sea trivial de encontrar. Por ejemplo, incluso si el error fue
+encontrado originalmente por un fuzzer como syzkaller, una prueba de
+regresión dirigida puede estar justificada si el error requiere golpear una
+condición de carrera de tipo uno en un millón.
+
+Recuerde que los fallos de KVM rara vez son urgentes *y* no triviales de
+reproducir. Pregúntate si un fallo es realmente el fin del mundo antes de
+publicar una corrección sin un reproductor.
+
+Publicación
+-----------
+
+Enlaces
+~~~~~~~
+No haga referencia explícita a informes de errores, versiones anteriores de
+un parche/serie, etc. mediante cabeceras ``In-Reply-To:``. Usar
+``In-Reply-To:`` se convierte en un lío para grandes series y/o cuando el
+número de versiones es alto, y ``In-Reply-To:`` es inútil para cualquiera
+que no tenga el mensaje original, por ejemplo, si alguien no recibió un Cc
+en el informe de error o si la lista de destinatarios cambia entre
+versiones.
+
+Para enlazar con un informe de error, una versión anterior o cualquier cosa
+de interés, utiliza enlaces lore. Para hacer referencia a versiones
+anteriores, en general no incluya un Enlace: en el registro de cambios, ya
+que no hay necesidad de registrar la historia en git, es decir, ponga el
+enlace en la carta de presentación o en la sección que git ignora.
+Proporcione un Enlace: formal para los informes de errores y/o discusiones
+que condujeron al parche. El contexto de por qué se hizo un cambio es muy
+valioso para futuros lectores.
+
+Basado en Git
+~~~~~~~~~~~~~
+Si utilizas la versión 2.9.0 o posterior de git (Googlers, ¡os incluimos a
+todos!), utilice ``git format-patch`` con el indicador ``--base`` para
+incluir automáticamente la información del árbol base en los parches
+generados.
+
+Tenga en cuenta que ``--base=auto`` funciona como se espera si y sólo si el
+upstream de una rama se establece en la rama temática base, por ejemplo,
+hará lo incorrecto si su upstream se establece en su repositorio personal
+con fines de copia de seguridad. Una solución "automática" alternativa es
+derivar los nombres de tus ramas de desarrollo basándose en su KVM x86, e
+introdúzcalo en ``--base``. Por ejemplo, ``x86/pmu/mi_nombre_de_rama``, y
+luego escribir un pequeño wrapper para extraer ``pmu`` del nombre de la
+rama actual para obtener ``--base=x/pmu``, donde ``x`` es el nombre que su
+repositorio utiliza para rastrear el remoto KVM x86.
+
+Tests de Co-Publicación
+~~~~~~~~~~~~~~~~~~~~~~~
+Las autopruebas de KVM asociadas a cambios de KVM, por ejemplo, pruebas de
+regresión para correcciones de errores, deben publicarse junto con los
+cambios de KVM como una única serie. Se aplicarán las reglas estándar del
+núcleo para la bisección, es decir, los cambios de KVM que provoquen fallos
+en las pruebas se ordenarán después de las actualizaciones de las
+autopruebas, y viceversa. Las pruebas que fallan debido a errores de KVM
+deben ordenarse después de las correcciones de KVM.
+
+KVM-unit-tests debería *siempre* publicarse por separado. Las herramientas,
+por ejemplo b4 am, no saben que KVM-unit-tests es un repositorio separado y
+se confunden cuando los parches de una serie se aplican en diferentes
+árboles. Para vincular los parches de KVM-unit-tests a Parches KVM, primero
+publique los cambios KVM y luego proporcione un enlace lore Link: al
+parche/serie KVM en el parche(s) KVM-unit-tests.
+
+Notificaciones
+~~~~~~~~~~~~~~
+Cuando se acepte oficialmente un parche/serie, se enviará un correo
+electrónico de notificación en respuesta a la publicación original (carta
+de presentación para series de varios parches). La notificación incluirá el
+árbol y la rama temática, junto con los SHA1 de los commits de los parches
+aplicados.
+
+Si se aplica un subconjunto de parches, se indicará claramente en la
+notificación. A menos que se indique lo contrario, se sobreentiende que
+todos los parches del Las series que no han sido aceptadas necesitan más
+trabajo y deben presentarse en una nueva versión.
+
+Si por alguna razón se retira un parche después de haber sido aceptado
+oficialmente, se enviará una respuesta al correo electrónico de
+notificación explicando por qué se ha retirado el parche, así como los
+pasos siguientes.
+
+Estabilidad SHA1
+~~~~~~~~~~~~~~~~
+Los SHA1 no son 100% estables hasta que llegan al árbol de Linus. Un SHA1
+es *normalmente* estable una vez que se ha enviado una notificación, pero
+ocurren cosas. En la mayoría de los casos, se proporcionará una
+actualización del correo electrónico de notificación si se aplica un SHA1
+del parche. Sin embargo, en algunos escenarios, por ejemplo, si todas las
+ramas de KVM x86 necesitan ser rebasadas, no se darán notificaciones
+individuales.
+
+Vulnerabilidades
+~~~~~~~~~~~~~~~~
+Los fallos que pueden ser explotados por la VM (el "guest") para atacar al
+host (kernel o espacio de usuario), o que pueden ser explotados por una VM
+anidada a *su* host (L2 atacando a L1), son de particular interés para KVM.
+Por favor, siga el protocolo para :ref:`securitybugs` si sospecha que un
+fallo puede provocar una filtración de datos, etc.
diff --git a/Documentation/translations/sp_SP/scheduler/index.rst b/Documentation/translations/sp_SP/scheduler/index.rst
new file mode 100644
index 000000000000..768488d6f001
--- /dev/null
+++ b/Documentation/translations/sp_SP/scheduler/index.rst
@@ -0,0 +1,8 @@
+.. include:: ../disclaimer-sp.rst
+
+.. _sp_scheduler_index:
+
+.. toctree::
+    :maxdepth: 1
+
+    sched-design-CFS
diff --git a/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
new file mode 100644
index 000000000000..90a153cad4e8
--- /dev/null
+++ b/Documentation/translations/sp_SP/scheduler/sched-design-CFS.rst
@@ -0,0 +1,277 @@
+.. include:: ../disclaimer-sp.rst
+
+:Original: :ref:`Documentation/scheduler/sched-design-CFS.rst <sched_design_CFS>`
+:Translator: Sergio González Collado <sergio.collado@gmail.com>
+
+.. _sp_sched_desing_CFS:
+
+====================
+Gestor de tareas CFS
+====================
+
+1.  VISIÓN GENERAL
+==================
+
+CFS viene de las siglas en inglés de "Gestor de tareas totalmente justo"
+("Completely Fair Scheduler"), y es el nuevo gestor de tareas de escritorio
+implementado por Ingo Molnar e integrado en Linux 2.6.23. Es el sustituto de
+el previo gestor de tareas SCHED_OTHER.
+
+Nota: El planificador EEVDF fue incorporado más recientemente al kernel.
+
+El 80% del diseño de CFS puede ser resumido en una única frase: CFS
+básicamente modela una "CPU ideal, precisa y multi-tarea" sobre hardware
+real.
+
+"una CPU multitarea ideal" es una CPU (inexistente :-)) que tiene un 100%
+de potencia y que puede ejecutar cualquier tarea exactamente a la misma
+velocidad, en paralelo, y cada una a 1/n velocidad. Por ejemplo, si hay dos
+tareas ejecutándose, entonces cada una usa un 50% de la potencia --- es decir,
+como si se ejecutaran en paralelo.
+
+En hardware real, se puede ejecutar una única tarea a la vez, así que
+se ha usado el concepto de "tiempo de ejecución virtual". El tiempo
+de ejecución virtual de una tarea específica cuando la siguiente porción
+de ejecución podría empezar en la CPU ideal multi-tarea descrita anteriormente.
+En la práctica, el tiempo de ejecución virtual de una tarea es el
+tiempo de ejecución real normalizado con respecto al número total de
+tareas ejecutándose.
+
+
+2.  UNOS CUANTOS DETALLES DE IMPLEMENTACIÓN
+===========================================
+
+En CFS, el tiempo de ejecución virtual se expresa y se monitoriza por
+cada tarea, en su valor de p->se.vruntime (en unidades de nanosegundos).
+De este modo, es posible temporizar con precisión y medir el "tiempo
+de CPU esperado" que una tarea debería tener.
+
+Un pequeño detalle: en hardware "ideal", en cualquier momento todas las
+tareas pueden tener el mismo valor de p->se.vruntime --- i.e., tareas
+se podrían ejecutar simultáneamente y ninguna tarea podría escaparse del
+"balance" de la partición "ideal" del tiempo compartido de la CPU.
+
+La lógica de elección del tareas de CFS se basa en el valor de p->se.vruntime
+y por tanto es muy sencilla: siempre intenta ejecutar la tarea con el valor
+p->se.vruntime más pequeño (i.e., la tarea que se ha ejecutado menos hasta el
+momento). CFS siempre intenta dividir el espacio de tiempo entre tareas
+en ejecución tan próximo a la "ejecución multitarea ideal del hardware" como
+sea posible.
+
+El resto del diseño de CFS simplemente se escapa de este simple concepto,
+con unos cuantos añadidos como los niveles "nice" ("nice" significa "amable"
+en inglés), multi-tarea y varias variantes del algoritmo para identificar
+tareas "durmiendo".
+
+
+3.  EL ÁRBOL ROJO-NEGRO
+=======================
+
+El diseño de CFS es bastante radical: no utiliza las antiguas estructuras
+de datos para las colas de ejecución (en inglés "runqueues"), pero usa una
+estructura de árbol rojo-negro (en inglés "red-black tree") ordenado cronológicamente
+para construir un línea de ejecución en el futuro, y por eso no tiene ningún
+artificio de "cambio de tareas" (algo que previamente era usado por el gestor
+anterior y RSDL/SD).
+
+CFS también mantiene el valor de rq->cfs.min_vruntime, el cual crece
+monotónicamente siguiendo el valor más pequeño de vruntime de entre todas
+las tareas en la cola de ejecución. La cantidad total de trabajo realizado
+por el sistema es monitorizado usado min_vruntime; este valor es usado
+para situar las nuevas tareas en la parte izquierda del árbol tanto
+como sea posible.
+
+El valor total de tareas ejecutándose en la cola de ejecución es
+contabilizado mediante el valor rq->cfs.load, el cual es la suma de los
+de esas tareas que están en la cola de ejecución.
+
+CFS mantiene un árbol rojo-negro cronológicamente ordenado, donde todas las
+tareas que pueden ser ejecutadas están ordenadas por su valor de
+p->se.vruntime. CFS selecciona la tarea más hacia la izquierda de este
+árbol y la mantiene. Según el sistema continúa, las tareas ejecutadas
+se ponen en este árbol más y más hacia la derecha --- lentamente pero
+de forma continuada dando una oportunidad a cada tarea de ser la que
+está "la más hacia la izquierda" y por tanto obtener la CPU una cantidad
+determinista de tiempo.
+
+Resumiendo, CFS funciona así: ejecuta una tarea un tiempo, y cuando la
+tarea se gestiona (o sucede un tic del gestor de tareas) se considera
+que el tiempo de uso de la CPU se ha completado, y se añade a
+p->se.vruntime. Una vez p->se.vruntime ha aumentado lo suficiente como
+para que otra tarea sea "la tarea más hacia la izquierda" del árbol
+rojo-negro ordenado cronológicamente esta mantienen (más una cierta pequeña
+cantidad de distancia relativa a la tarea más hacia la izquierda para
+que no se sobre-reserven tareas y perjudique a la cache), entonces la
+nueva tarea "que está a la izquierda del todo", es la que se elige
+para que se ejecute, y la tarea en ejecución es interrumpida.
+
+4.  ALGUNAS CARACTERÍSTICAS DE CFS
+==================================
+
+CFS usa una granularidad de nanosegundos y no depende de ningún
+jiffie o detalles como HZ. De este modo, el gestor de tareas CFS no tiene
+noción de "ventanas de tiempo" de la forma en que tenía el gestor de
+tareas previo, y tampoco tiene heurísticos. Únicamente hay un parámetro
+central ajustable (se ha de cambiar en CONFIG_SCHED_DEBUG):
+
+   /sys/kernel/debug/sched/base_slice_ns
+
+El cual puede ser usado para afinar desde el gestor de tareas del "escritorio"
+(i.e., bajas latencias) hacia cargas de "servidor" (i.e., bueno con
+procesamientos). Su valor por defecto es adecuado para tareas de escritorio.
+SCHED_BATCH también es gestionado por el gestor de tareas CFS.
+
+Debido a su diseño, el gestor de tareas CFS no es proclive a ninguno de los
+ataques que existen a día de hoy contra los heurísticos del gestor de tareas:
+fiftyp.c, thud.c, chew.c, ring-test.c, massive_intr.c todos trabajan
+correctamente y no tienen impacto en la interacción y se comportan de la forma
+esperada.
+
+El gestor de tareas CFS tiene una gestión mucho más firme de los niveles
+"nice" y SCHED_BATCH que los previos gestores de tareas: ambos tipos de
+tareas están aisladas de forma más eficiente.
+
+El balanceo de tareas SMP ha sido rehecho/mejorado: el avance por las
+colas de ejecución de tareas ha desaparecido del código de balanceo de
+carga, y ahora se usan iteradores en la gestión de módulos. El balanceo
+del código ha sido simplificado como resultado esto.
+
+5.  Políticas de gestión de tareas
+==================================
+
+CFS implementa tres políticas de gestión de tareas:
+
+  - SCHED_NORMAL (tradicionalmente llamada SCHED_OTHER): Gestión de
+    tareas que se usan para tareas normales.
+
+  - SCHED_BATCH: No interrumpe tareas tan a menudo como las tareas
+    normales harían, por eso permite a las tareas ejecutarse durante
+    ventanas de tiempo mayores y hace un uso más efectivo de las
+    caches pero al coste de la interactividad. Esto es adecuado
+    para trabajos de procesado de datos.
+
+  - SCHED_IDLE: Esta política es más débil incluso que nice 19, pero
+    no es un gestor "idle" para evitar caer en el problema de la
+    inversión de prioridades que causaría un bloqueo de la máquina
+    (deadlock).
+
+SCHED_FIFO/_RR se implementan en sched/rt.c y son específicos de
+POSIX.
+
+El comando chrt de util-linux-ng 2.13.1.1. puede asignar cualquiera de
+estas políticas excepto SCHED_IDLE.
+
+
+6.  CLASES DE GESTIÓN
+=====================
+
+El nuevo gestor de tareas CFS ha sido diseñado de tal modo para incluir
+"clases de gestión", una jerarquía ampliable de módulos que pueden tener
+distintas políticas de gestión de tareas. Estos módulos encapsulan los
+detalles de las politicas de gestión y son manejadas por el núcleo del
+gestor de tareas sin que este tenga que presuponer mucho sobre estas clases.
+
+sched/fair.c implementa el gestor de tareas CFS descrito antes.
+
+sched/rt.c implementa la semántica de SCHED_FIFO y SCHED_RR, de una forma
+más sencilla que el gestor de tareas anterior. Usa 100 colas de ejecución
+(por todos los 100 niveles de prioridad RT, en vez de las 140 que necesitaba
+el gestor de tareas anterior) y no necesita las listas de expiración.
+
+Las clases de gestión de tareas son implementadas por medio de la estructura
+sched_class, la cual tiene llamadas a las funciones que deben de llamarse
+cuando quiera que ocurra un evento interesante.
+
+Esta es la lista parcial de llamadas:
+
+ - enqueue_task(...)
+
+   Llamada cuando una tarea entra en el estado de lista para ejecución.
+   Pone la entidad a ser gestionada (la tarea) en el árbol rojo-negro
+   e incrementa la variable nr_running.
+
+ - dequeue_task(...)
+
+   Cuando una tarea deja de ser ejecutable, esta función se llama para
+   mantener a la entidad gestionada fuera del árbol rojo-negor. Esto
+   decrementa la variable nr_running.
+
+ - yield_task(...)
+
+   Esta función es básicamente desencolar, seguido por encolar, a menos que
+   sysctl compat_yield esté activado; en ese caso, sitúa la entidad a gestionar
+   en la parte más hacia la derecha del árbol rojo-negro.
+
+ - check_preempt_curr(...)
+
+   Esta función comprueba si una tarea que ha entrado en el estado de
+   poder ser ejecutada, podría reemplazar a la tarea que actualmente
+   se esté ejecutando.
+
+ - pick_next_task(...)
+
+   Esta función elige la tarea más apropiada para ser ejecutada a continuación.
+
+ - set_curr_task(...)
+
+   Esta función se llama cuando una tarea cambia su clase de gestión o
+   cambia su grupo de tareas.
+
+ - task_tick(...)
+
+   Esta función es llamada la mayoría de las veces desde la función de tiempo
+   tick; esto puede llevar a un cambio de procesos. Esto dirige el reemplazo
+   de las tareas.
+
+
+7.  EXTENSIONES DE GRUPOS PARA CFS
+==================================
+
+Normalmente, el gestor de tareas gestiona tareas individuales e intenta
+proporcionar una cantidad justa de CPU a cada tarea. Algunas veces, puede
+ser deseable agrupar las tareas y proporcionarles una cantidad justa
+de tiempo de CPU a cada una de las tareas de ese grupo. Por ejemplo,
+podría ser deseable que primero se proporcione una cantidad justa de
+tiempo de CPU a cada usuario del sistema y después a cada tarea
+que pertenezca a un usuario.
+
+CONFIG_CGROUP_SCHED destaca en conseguir exactamente eso. Permite a las
+tareas ser agrupadas y divide el tiempo de CPU de forma just entre esos
+grupos.
+
+CONFIG_RT_GROUP_SCHED permite agrupar tareas de tiempo real (i.e.,
+SCHED_FIFO y SCHED_RR).
+
+CONFIG_FAIR_GROUP_SCHED permite agrupar tareas de CFS (i.e., SCHED_NORMAL y
+SCHED_BATCH).
+
+Estas opciones necesitan CONFIG_CGROUPS para ser definidas, y permitir
+al administrador crear grupos arbitrarios de tareas, usando el pseudo
+sistema de archivos "cgroup". Vease la documentación para más información
+sobre este sistema de archivos: Documentation/admin-guide/cgroup-v1/cgroups.rst
+
+Cuando CONFIG_FAIR_GROUP_SCHED es definido, un archivo
+"cpu.shares" es creado por cada grupo creado usado en el pseudo
+sistema de archivos. Véanse por ejemplo los pasos a continuación
+para crear grupos de tareas y modificar cuanto comparten de la CPU
+usando el pseudo sistema de archivos "cgroup" ::
+
+	# mount -t tmpfs cgroup_root /sys/fs/cgroup
+	# mkdir /sys/fs/cgroup/cpu
+	# mount -t cgroup -ocpu none /sys/fs/cgroup/cpu
+	# cd /sys/fs/cgroup/cpu
+
+	# mkdir multimedia	# crear un grupo de tareas "multimedia"
+	# mkdir browser 	# crear un grupo de tareas "browser"
+
+	# #Configurar el grupo multimedia para tener el doble de tiempo de CPU
+	# #que el grupo browser
+
+	# echo 2048 > multimedia/cpu.shares
+	# echo 1024 > browser/cpu.shares
+
+	# firefox &	# Lanzar firefox y moverlo al grupo "browser"
+	# echo <firefox_pid> > browser/tasks
+
+	# #Lanzar gmplayer (o su programa favorito de reproducción de películas)
+	# echo <movie_player_pid> > multimedia/tasks
diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst
index ac2960da33e6..0db80ab830a0 100644
--- a/Documentation/translations/zh_CN/admin-guide/index.rst
+++ b/Documentation/translations/zh_CN/admin-guide/index.rst
@@ -68,6 +68,7 @@ Todolist:
    cpu-load
    cputopology
    lockup-watchdogs
+   numastat
    unicode
    sysrq
    mm/index
@@ -109,7 +110,6 @@ Todolist:
 *   module-signing
 *   mono
 *   namespaces/index
-*   numastat
 *   parport
 *   perf-security
 *   pm/index
diff --git a/Documentation/translations/zh_CN/admin-guide/numastat.rst b/Documentation/translations/zh_CN/admin-guide/numastat.rst
new file mode 100644
index 000000000000..4d9817b91870
--- /dev/null
+++ b/Documentation/translations/zh_CN/admin-guide/numastat.rst
@@ -0,0 +1,48 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../disclaimer-zh_CN.rst
+
+:Original: Documentation/admin-guide/numastat.rst
+:Translator: Tao Zou <wodemia@linux.alibaba.com>
+
+
+=======================
+Numa策略命中/未命中统计
+=======================
+
+/sys/devices/system/node/node*/numastat
+
+所有数据的单位都是页面。巨页有独立的计数器。
+
+numa_hit、numa_miss和numa_foreign计数器反映了进程是否能够在他们偏好的节点上分配内存。
+如果进程成功在偏好的节点上分配内存则在偏好的节点上增加numa_hit计数，否则在偏好的节点上增
+加numa_foreign计数同时在实际内存分配的节点上增加numa_miss计数。
+
+通常，偏好的节点是进程运行所在的CPU的本地节点，但是一些限制可以改变这一行为，比如内存策略，
+因此同样有两个基于CPU本地节点的计数器。local_node和numa_hit类似，当在CPU所在的节点上分
+配内存时增加local_node计数，other_node和numa_miss类似，当在CPU所在节点之外的其他节点
+上成功分配内存时增加other_node计数。需要注意，没有和numa_foreign对应的计数器。
+
+更多细节内容:
+
+=============== ============================================================
+numa_hit        一个进程想要从本节点分配内存并且成功。
+
+numa_miss       一个进程想要从其他节点分配内存但是最终在本节点完成内存分配。
+
+numa_foreign    一个进程想要在本节点分配内存但是最终在其他节点完成内存分配。
+
+local_node      一个进程运行在本节点的CPU上并且从本节点上获得了内存。
+
+other_node      一个进程运行在其他节点的CPU上但是在本节点上获得了内存。
+
+interleave_hit  内存交叉分配策略下想要从本节点分配内存并且成功。
+=============== ============================================================
+
+你可以使用numactl软件包（http://oss.sgi.com/projects/libnuma/）中的numastat工具
+来辅助阅读。需要注意，numastat工具目前只在有少量CPU的机器上运行良好。
+
+需要注意，在包含无内存节点（一个节点有CPUs但是没有内存）的系统中numa_hit、numa_miss和
+numa_foreign统计数据会被严重曲解。在当前的内核实现中，如果一个进程偏好一个无内存节点（即
+进程正在该节点的一个本地CPU上运行），实际上会从距离最近的有内存节点中挑选一个作为偏好节点。
+结果会导致相应的内存分配不会增加无内存节点上的numa_foreign计数器，并且会扭曲最近节点上的
+numa_hit、numa_miss和numa_foreign统计数据。
diff --git a/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst b/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst
index 17b5ce85a90c..3c133a918f30 100644
--- a/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst
+++ b/Documentation/translations/zh_CN/dev-tools/gdb-kernel-debugging.rst
@@ -34,6 +34,10 @@ Kgdb内核调试器、QEMU等虚拟机管理程序或基于JTAG的硬件接口�
   但这通常仅在不依赖内核模块时才有效。有关此模式的更多详细信息，请参阅QEMU文档。
   在这种情况下，如果架构支持KASLR，应该在禁用CONFIG_RANDOMIZE_BASE的情况下构建内核。
 
+- 构建gdb脚本（适用于内核v5.1版本及以上）
+
+    make scripts_gdb
+
 - 启用QEMU/KVM的gdb stub，可以通过如下方式实现
 
     - 在VM启动时，通过在QEMU命令行中添加“-s”参数
diff --git a/Documentation/translations/zh_CN/dev-tools/index.rst b/Documentation/translations/zh_CN/dev-tools/index.rst
index fa900f5beb68..c540e4a7d5db 100644
--- a/Documentation/translations/zh_CN/dev-tools/index.rst
+++ b/Documentation/translations/zh_CN/dev-tools/index.rst
@@ -20,18 +20,22 @@ Documentation/translations/zh_CN/dev-tools/testing-overview.rst
 
    testing-overview
    sparse
+   kcov
    gcov
    kasan
-   kcov
    ubsan
    kmemleak
    gdb-kernel-debugging
 
 Todolist:
 
+ - checkpatch
  - coccinelle
+ - kmsan
  - kcsan
  - kfence
  - kgdb
  - kselftest
  - kunit/index
+ - ktap
+ - checkuapi
diff --git a/Documentation/translations/zh_CN/dev-tools/kasan.rst b/Documentation/translations/zh_CN/dev-tools/kasan.rst
index 2b1e8f74904b..4491ad2830ed 100644
--- a/Documentation/translations/zh_CN/dev-tools/kasan.rst
+++ b/Documentation/translations/zh_CN/dev-tools/kasan.rst
@@ -235,6 +235,24 @@ slab对象的描述以及关于访问的内存页的信息。
 通用KASAN还报告两个辅助调用堆栈跟踪。这些堆栈跟踪指向代码中与对象交互但不直接
 出现在错误访问堆栈跟踪中的位置。目前，这包括 call_rcu() 和排队的工作队列。
 
+CONFIG_KASAN_EXTRA_INFO
+~~~~~~~~~~~~~~~~~~~~~~~
+
+启用 CONFIG_KASAN_EXTRA_INFO 选项允许 KASAN 记录和报告更多信息。目前支持的
+额外信息包括分配和释放时的 CPU 编号和时间戳。更多的信息可以帮助找到内核错误的原因，
+并将错误与其他系统事件关联起来，但代价是用额外的内存来记录更多信息（有关更多
+开销的细节，请参见 CONFIG_KASAN_EXTRA_INFO 选项的帮助文本）。
+
+以下为 CONFIG_KASAN_EXTRA_INFO 开启后的报告（仅显示不同部分）::
+
+    ==================================================================
+    ...
+    Allocated by task 134 on cpu 5 at 229.133855s:
+    ...
+    Freed by task 136 on cpu 3 at 230.199335s:
+    ...
+    ==================================================================
+
 实施细则
 --------
 
diff --git a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
index c91f9b60f9f1..286ed6b01f65 100644
--- a/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
+++ b/Documentation/translations/zh_CN/dev-tools/testing-overview.rst
@@ -99,6 +99,8 @@ Documentation/dev-tools/kcov.rst 是能够构建在内核之中，用于在每�
   参阅 Documentation/dev-tools/kfence.rst
 * lockdep是一个锁定正确性检测器。参阅
   Documentation/locking/lockdep-design.rst
+* 运行时确认（Runtime Verification）支持检查给定子系统的特定行为。参阅
+  Documentation/trace/rv/runtime-verification.rst。
 * 除此以外，在内核中还有一些其它的调试工具，大多数能在
   lib/Kconfig.debug 中找到。
 
diff --git a/Documentation/translations/zh_CN/driver-api/index.rst b/Documentation/translations/zh_CN/driver-api/index.rst
index 92ff1b7fc3d3..4050a2fb51c6 100644
--- a/Documentation/translations/zh_CN/driver-api/index.rst
+++ b/Documentation/translations/zh_CN/driver-api/index.rst
@@ -23,6 +23,7 @@ Linux驱动实现者的API指南
 
    gpio/index
    io_ordering
+   phy/index
 
 Todolist:
 
@@ -103,7 +104,6 @@ Todolist:
 *   parport-lowlevel
 *   pps
 *   ptp
-*   phy/index
 *   pwm
 *   pldmfw/index
 *   rfkill
diff --git a/Documentation/translations/zh_CN/driver-api/phy/index.rst b/Documentation/translations/zh_CN/driver-api/phy/index.rst
new file mode 100644
index 000000000000..2cdce17b74a9
--- /dev/null
+++ b/Documentation/translations/zh_CN/driver-api/phy/index.rst
@@ -0,0 +1,20 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+============
+PHY 通用框架
+============
+
+.. toctree::
+
+   phy
+
+Todolist:
+
+*   samsung-usb2
+
+.. only::  subproject and html
+
+   Indices
+   =======
+
+   * :ref:`genindex`
diff --git a/Documentation/translations/zh_CN/driver-api/phy/phy.rst b/Documentation/translations/zh_CN/driver-api/phy/phy.rst
new file mode 100644
index 000000000000..0d7489081b90
--- /dev/null
+++ b/Documentation/translations/zh_CN/driver-api/phy/phy.rst
@@ -0,0 +1,212 @@
+.. SPDX-License-Identifier: GPL-2.0
+.. include:: ../../disclaimer-zh_CN.rst
+
+:Original: Documentation/driver-api/phy/phy.rst
+
+:翻译:
+
+ 司延腾 Yanteng Si <siyanteng@loongson.cn>
+
+=========
+PHY子系统
+=========
+
+:作者: Kishon Vijay Abraham I <kishon@ti.com>
+
+本文档解释了 PHY 的通用框架和提供的API，以及使用方法。
+
+简介
+====
+
+*PHY* 是物理层的缩写，它被用来把设备连接到一个物理媒介，例如USB控制器
+有一个提供序列化、反序列化、编码、解码和负责获取所需的数据传输速率的 PHY。
+注意，有些USB控制器内嵌了 PHY 的功能，其它的则使用了一个外置的PHY，此外
+使用 PHY 的设备还有无线网、以太网、SATA等（控制器）。
+
+创建这个框架的目的是将遍布 Linux 内核的 PHY 驱动程序融入到 drivers/phy，
+以增加代码的可复用性，进而提高代码的可维护性。
+
+该框架仅适用于使用外部 PHY（PHY 功能未嵌入控制器内）的设备。
+
+注册/注销PHY provider
+=====================
+
+PHY provider是指实现一个或多个 PHY 实例的实体。对于 PHY provider 仅
+实现单个 PHY 实例的简单情况，框架在 of_phy_simple_xlate 中提供其自己
+的 of_xlate 实现。如果 PHY provider 实现多个实例，则应提供其自己的
+of_xlate 实现。of_xlate 仅用于 dt 启动情况。
+
+::
+
+	#define of_phy_provider_register(dev, xlate)    \
+		__of_phy_provider_register((dev), NULL, THIS_MODULE, (xlate))
+
+	#define devm_of_phy_provider_register(dev, xlate)       \
+		__devm_of_phy_provider_register((dev), NULL, THIS_MODULE,
+						(xlate))
+
+of_phy_provider_register 和 devm_of_phy_provider_register 宏
+可用于注册 phy_provider，它以 device 和 of_xlate 作为参数。对于 dt
+启动情况，所有 PHY provider 都应使用上述两个宏之一来注册 PHY provider。
+
+与 PHY provider 关联的设备树节点通常包含一组子节点，每个子节点代表一个
+PHY。某些绑定可能会为了上下文和可扩展性将子节点嵌套在特别的层级中，在这种
+情况下，可以使用低级别的 of_phy_provider_register_full() 和
+devm_of_phy_provider_register_full() 宏来覆盖包含子节点的节点。
+
+::
+
+	#define of_phy_provider_register_full(dev, children, xlate) \
+		__of_phy_provider_register(dev, children, THIS_MODULE, xlate)
+
+	#define devm_of_phy_provider_register_full(dev, children, xlate) \
+		__devm_of_phy_provider_register_full(dev, children,
+						     THIS_MODULE, xlate)
+
+	void devm_of_phy_provider_unregister(struct device *dev,
+		struct phy_provider *phy_provider);
+	void of_phy_provider_unregister(struct phy_provider *phy_provider);
+
+devm_of_phy_provider_unregister 和 of_phy_provider_unregister
+可以被用来注销PHY.
+
+创建PHY
+=======
+
+PHY 驱动程序应创建 PHY，以便其他外围（芯片）控制器能够使用它。PHY 框架
+提供了 2 个 API 来创建 PHY。
+
+::
+
+	struct phy *phy_create(struct device *dev, struct device_node *node,
+			       const struct phy_ops *ops);
+	struct phy *devm_phy_create(struct device *dev,
+				    struct device_node *node,
+				    const struct phy_ops *ops);
+
+PHY 驱动程序可以使用上述两个 API 之一，通过传递设备指针和 phy_ops
+来创建 PHY。
+
+phy_ops 是一组用于执行 PHY 操作（例如 init、exit、power_on 和
+power_off）的函数指针。
+
+在 phy_ops 中，PHY provider驱动程序在创建 PHY 后使用 phy_set_drvdata()
+设置私有数据，使用 phy_get_drvdata() 获取私有数据。
+
+获取对 PHY 的引用
+=================
+
+控制器必须先获取对 PHY 的引用，然后才能使用 PHY。此框架提供以下 API
+来获取对 PHY 的引用。
+
+::
+
+	struct phy *phy_get(struct device *dev, const char *string);
+	struct phy *devm_phy_get(struct device *dev, const char *string);
+	struct phy *devm_phy_optional_get(struct device *dev,
+					  const char *string);
+	struct phy *devm_of_phy_get(struct device *dev, struct device_node *np,
+				    const char *con_id);
+	struct phy *devm_of_phy_optional_get(struct device *dev,
+					     struct device_node *np,
+					     const char *con_id);
+	struct phy *devm_of_phy_get_by_index(struct device *dev,
+					     struct device_node *np,
+					     int index);
+
+phy_get、devm_phy_get 和 devm_phy_optional_get 可用于在 dt
+启动的情况下获取 PHY，字符串参数应包含 dt 数据中给出的 phy 名称，在
+非 dt 启动的情况下，它应包含 PHY 的标签。两个 devm_phy_get 在成功
+获取 PHY 后使用 devres 将设备与 PHY 关联。在驱动程序分离时，将在
+devres 数据上调用 release 函数并释放 devres 数据。当 phy 是可选
+的时，应使用 _optional_get 变体。这些函数永远不会返回 -ENODEV，而
+是在找不到 phy 时返回 NULL。一些通用驱动程序（例如 ehci）可能使用
+多个 phy。在这种情况下，devm_of_phy_get 或 devm_of_phy_get_by_index
+用于根据名称或索引获取 phy 引用。
+
+需要注意的是，NULL 是有效的 phy 引用。NULL phy 上的所有 phy 使用
+者调用都将成为 NOP。也就是说释放调用，当应用于 NULL phy 时，release
+调用、phy_init()/phy_exit() 调用、phy_power_on()/phy_power_off()
+调用都是 NOP。NULL phy 在处理可选的 phy 设备中很有用。
+
+API的调用顺序
+=============
+
+通常，调用顺序应该是::
+
+    [devm_][of_]phy_get()
+    phy_init()
+    phy_power_on()
+    [phy_set_mode[_ext]()]
+    ...
+    phy_power_off()
+    phy_exit()
+    [[of_]phy_put()]
+
+一些PHY驱动可能没有实现 :c:func:`phy_init` 或 :c:func:`phy_power_on`,
+但是控制器应该总是调用这些函数以兼容其它PHY，有些PHY可能要求
+:c:func:`phy_set_mode <phy_set_mode_ext>` 而其他 PHY 可能使用
+默认模式（通常通过设备树或其他固件配置）。出于兼容性考虑，如果您知道将
+使用哪种模式，则应始终调用此函数。通常，应在 :c:func:`phy_power_on`
+之后调用此函数，尽管某些 PHY 驱动程序可能随时允许调用它。
+
+释放对 PHY 的引用
+=================
+
+当控制器不再需要 PHY 时，它必须使用上一节中提到的 API 释放对已获得
+的 PHY 的引用。PHY 框架提供了 2 个 API 来释放对 PHY 的引用。
+
+::
+
+	void phy_put(struct phy *phy);
+	void devm_phy_put(struct device *dev, struct phy *phy);
+
+这两个 API 都用于释放对 PHY 的引用，并且 devm_phy_put 会销毁与此
+PHY 关联的设备资源。
+
+销毁 PHY
+========
+
+当创建 PHY 的驱动程序被卸载时，它应该使用以下 2 个 API 之一销毁其创
+建的 PHY::
+
+	void phy_destroy(struct phy *phy);
+	void devm_phy_destroy(struct device *dev, struct phy *phy);
+
+这两个 API 都会销毁 PHY，并且 devm_phy_destroy 会销毁与此 PHY 关
+联的 devres。
+
+PM Runtime
+==========
+
+这个子系统启用了pm runtime。 所以，在创建PHY 时，将调用此子系统创建的
+phy 设备的 pm_runtime_enable 函数，在销毁 PHY 时，将调用
+pm_runtime_disable。请注意，此子系统创建的 phy 设备将是调用 phy_create
+（PHY provider 设备）的设备的子设备。
+
+因此，由于父子关系，此子系统创建的 phy_device 的 pm_runtime_get_sync
+调用 PHY provider 设备的 pm_runtime_get_sync。还应注意，
+phy_power_on 和 phy_power_off 分别执行 phy_pm_runtime_get_sync 和
+phy_pm_runtime_put。有导出的 API，如 phy_pm_runtime_get、
+phy_pm_runtime_get_sync、phy_pm_runtime_put、phy_pm_runtime_put_sync、
+phy_pm_runtime_allow 和 phy_pm_runtime_forbid，用于执行 PM 操作。
+
+PHY映射
+=======
+
+为了在没有 DeviceTree 帮助的情况下获取对 PHY 的引用，框架提供了可与
+clkdev 进行比较的查找，允许将 clk 结构体绑定到设备。当 struct phy 的
+句柄已存在时，可以在运行时进行查找。
+
+该框架提供以下 API 用于注册和注销查找::
+
+	int phy_create_lookup(struct phy *phy, const char *con_id,
+			      const char *dev_id);
+	void phy_remove_lookup(struct phy *phy, const char *con_id,
+			       const char *dev_id);
+
+DeviceTree绑定
+==============
+
+PHY dt 绑定的文档可以在以下位置找到 @
+Documentation/devicetree/bindings/phy/phy-bindings.txt
diff --git a/Documentation/translations/zh_CN/process/4.Coding.rst b/Documentation/translations/zh_CN/process/4.Coding.rst
index 7cac9424f5d5..4cc35d410dbc 100644
--- a/Documentation/translations/zh_CN/process/4.Coding.rst
+++ b/Documentation/translations/zh_CN/process/4.Coding.rst
@@ -54,7 +54,7 @@
 注意您还可以使用 ``clang-format`` 工具来帮助您处理这些规则，快速自动重新格式
 化部分代码，和审阅完整的文件以发现代码样式错误、拼写错误和可能的改进。它还
 可以方便地排序 ``#includes`` 、对齐变量/宏、重排文本和其他类似任务。有关详细
-信息，请参阅文档 :ref:`Documentation/process/clang-format.rst <clangformat>`
+信息，请参阅文档 :ref:`Documentation/dev-tools/clang-format.rst <clangformat>`
 
 抽象层
 ******
diff --git a/Documentation/translations/zh_CN/process/coding-style.rst b/Documentation/translations/zh_CN/process/coding-style.rst
index 3bc2810b151d..10b9cb4f6a65 100644
--- a/Documentation/translations/zh_CN/process/coding-style.rst
+++ b/Documentation/translations/zh_CN/process/coding-style.rst
@@ -654,7 +654,7 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 scripts/kernel-doc 。
 请注意，您还可以使用 ``clang-format`` 工具帮助您处理这些规则，快速自动重新格
 式化部分代码，并审阅整个文件以发现代码风格错误、打字错误和可能的改进。它还可
 以方便地排序 ``#include`` ，对齐变量/宏，重排文本和其他类似任务。
-详见 Documentation/process/clang-format.rst 。
+详见 Documentation/dev-tools/clang-format.rst 。
 
 
 10) Kconfig 配置文件
diff --git a/Documentation/translations/zh_CN/process/index.rst b/Documentation/translations/zh_CN/process/index.rst
index 5c6c8ccdd50d..5a5cd7c01c62 100644
--- a/Documentation/translations/zh_CN/process/index.rst
+++ b/Documentation/translations/zh_CN/process/index.rst
@@ -64,6 +64,7 @@ TODOLIST:
    management-style
    stable-kernel-rules
    submit-checklist
+   researcher-guidelines
 
 TODOLIST:
 
@@ -71,7 +72,6 @@ TODOLIST:
 * kernel-docs
 * deprecated
 * maintainers
-* researcher-guidelines
 * contribution-maturity-model
 
 
diff --git a/Documentation/translations/zh_CN/process/magic-number.rst b/Documentation/translations/zh_CN/process/magic-number.rst
index 4e4aeaca796c..4ebc84cc0c54 100644
--- a/Documentation/translations/zh_CN/process/magic-number.rst
+++ b/Documentation/translations/zh_CN/process/magic-number.rst
@@ -1,6 +1,6 @@
 .. include:: ../disclaimer-zh_CN.rst
 
-:Original: Documentation/process/magic-number.rst
+:Original: Documentation/staging/magic-number.rst
 
 :翻译:
 
diff --git a/Documentation/translations/zh_CN/process/researcher-guidelines.rst b/Documentation/translations/zh_CN/process/researcher-guidelines.rst
new file mode 100644
index 000000000000..1f2da68fc4e8
--- /dev/null
+++ b/Documentation/translations/zh_CN/process/researcher-guidelines.rst
@@ -0,0 +1,129 @@
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+.. include:: ../disclaimer-zh_CN.rst
+
+.. _cn_researcherguidelines:
+
+:Original: Documentation/process/researcher-guidelines.rst
+
+:译者:
+ - 慕冬亮 Dongliang Mu <dzm91@hust.edu.cn>
+
+研究人员指南
++++++++++++++++++++++
+
+Linux 内核社区欢迎对 Linux 内核及其开发过程中涉及的活动与任何其他副产品
+进行透明的研究。Linux 从这种研究中受益匪浅，其多方面均由某种形式的研究所推动。
+
+社区非常感谢研究人员在公开研究结果之前能分享初步发现，特别是涉及安全的研究。
+早期参与有助于提高研究质量并使 Linux 受益。无论如何，推荐研究人员与社区分享
+已发表研究的开放访问副本。
+
+本文旨在澄清研究开展过程中 Linux 内核社区认可与不认可的一些做法。至少，这类
+研究及相关活动应遵循标准的研究伦理规则。有关研究伦理、技术伦理以及开发者社区
+研究的更多背景信息，请查阅：
+
+* `研究伦理史 <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_
+* `IEEE 伦理 <https://www.ieee.org/about/ethics/index.html>`_
+* `开发者和研究人员对开源项目实验伦理的看法 <https://arxiv.org/pdf/2112.13217.pdf>`_
+
+Linux 内核社区期望与项目互动的每个人都是真诚地为了使 Linux 变得更好。
+对 Linux 内核社区产生的任何公开可用的成果（包括但不限于源代码）的研究
+是受欢迎的，对开发者的研究如若要开展，则必须要明确说明，获得（开发者）同意。
+
+完全基于公开可用资源（包括公共邮件列表的帖子和公开代码库的提交）的被动研究
+显然是允许的。不过，和任何研究一样，仍需遵循标准伦理。
+
+然而，针对开发者行为的主动研究必须在获得相关开发者的明确同意和完全披露的情况下进行。
+未经同意，不得与开发者互动或对其进行实验；这也是标准的研究伦理。
+
+调查
+=======
+
+研究通常采用调查问卷的形式发送给维护者或贡献者。然而，内核社区通常从这些调查问卷中获益
+甚少。内核开发过程之所以有效，是因为每个开发者都从中受益，即使与目标不同的人一起工作。
+而回应调查则是对繁忙开发者的单向需求，对他们自己或整个内核社区没有相应的好处。因此，
+这种研究方法不被鼓励。
+
+内核社区成员已经收到过多的电子邮件，可能会将调查请求视为对他们时间的又一要求。发送
+此类请求会剥夺社区宝贵的贡献者时间，且不太可能产生有统计意义的回应。
+
+作为替代，研究人员应考虑参加开发者活动，举办研讨会来介绍研究项目及其对参与者的益处，
+并直接与社区互动。该方式获得的信息将比电子邮件调查问卷丰富得多，且社区也能从中学习
+到您的见解。
+
+补丁
+=======
+
+澄清：向开发者发送补丁**是**与他们互动，但他们已经同意接收**善意贡献**。故意发送有缺陷/
+有漏洞的补丁或在讨论中提供误导信息是不被同意的。这种交流会对开发者造成损害
+（例如，消耗时间、精力和士气），并通过破坏整个开发者社区对贡献者（及其所在组织）
+的信任而损害项目，削弱为贡献者提供建设性反馈的努力，并使最终用户面临软件缺陷的风险。
+
+研究人员参与 Linux 本身的开发与其他人一样受到欢迎和鼓励。研究 Linux 代码是常见
+做法，尤其是在开发或运行可产生可操作结果的分析工具时。
+
+在与开发者社区互动时，发送补丁历来是产生影响的最佳方式。Linux 已经有很多已知的
+漏洞 -- 更有帮助的是经过审核的修复。在贡献之前，请仔细阅读相关文档：
+
+* Documentation/process/development-process.rst
+* Documentation/process/submitting-patches.rst
+* Documentation/admin-guide/reporting-issues.rst
+* Documentation/process/security-bugs.rst
+
+然后发送补丁（包括所有如下详细信息的提交日志）并跟进其他开发者的任何反馈。
+
+当发送因研究而产生的补丁时，提交日志应至少包含以下详细信息，以便开发者有适当的上下文
+来理解贡献。回答：
+
+* 找到了什么具体问题？
+* 在运行系统上如何触发这个问题？
+* 遇到这个问题对系统会有什么影响？
+* 如何发现这个问题？具体包括任何测试、静态或动态分析程序及其他用于执行工作的工具或方法的详细信息。
+* 在哪个版本的 Linux 上发现了这个问题？强烈推荐使用最新的发布版本或最近的 linux-next 分支（参见 Documentation/process/howto.rst）。
+* 进行了哪些更改来修复这个问题，为什么认为这些更改是正确的？
+* 如何进行构建测试和运行时测试？
+* 此更改修复了哪个先前的提交？这应该在 "Fixes:" 标签中，如文档所述。
+* 还有谁审查了这个补丁？这应该在适当的 "Reviewed-by:" 标签中注明；见下文。
+
+例如::
+
+  From: Author <author@email>
+  Subject: [PATCH] drivers/foo_bar: Add missing kfree()
+
+  The error path in foo_bar driver does not correctly free the allocated
+  struct foo_bar_info. This can happen if the attached foo_bar device
+  rejects the initialization packets sent during foo_bar_probe(). This
+  would result in a 64 byte slab memory leak once per device attach,
+  wasting memory resources over time.
+
+  This flaw was found using an experimental static analysis tool we are
+  developing, LeakMagic[1], which reported the following warning when
+  analyzing the v5.15 kernel release:
+
+   path/to/foo_bar.c:187: missing kfree() call?
+
+  Add the missing kfree() to the error path. No other references to
+  this memory exist outside the probe function, so this is the only
+  place it can be freed.
+
+  x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC
+  11.2 show no new warnings, and LeakMagic no longer warns about this
+  code path. As we don't have a FooBar device to test with, no runtime
+  testing was able to be performed.
+
+  [1] https://url/to/leakmagic/details
+
+  Reported-by: Researcher <researcher@email>
+  Fixes: aaaabbbbccccdddd ("Introduce support for FooBar")
+  Signed-off-by: Author <author@email>
+  Reviewed-by: Reviewer <reviewer@email>
+
+如果您是第一次参与贡献，建议在补丁在发布到公共列表前请其他人私下进行审核。（如果明确
+告诉您补丁需要更仔细的内部审查，则这是必需的。）这些人预计会在最终的补丁中包含他们的
+"Reviewed-by" 标签。找到熟悉 Linux 贡献的其他开发者，特别是您自己组织内的开发者，
+并在将补丁发送到公共邮件列表前请他们帮助审核，往往会显著提高补丁的质量，从而减少
+其他开发者的负担。
+
+如果你找不到人内部审核补丁且需要帮助找到这样的人，或者如果您对本文档和开发者社区的期望
+有任何其他问题，请联系技术咨询委员会私有邮件列表：<tech-board@groups.linuxfoundation.org>。
diff --git a/Documentation/translations/zh_CN/virt/guest-halt-polling.rst b/Documentation/translations/zh_CN/virt/guest-halt-polling.rst
index b798d1cf0b48..463d1d829062 100644
--- a/Documentation/translations/zh_CN/virt/guest-halt-polling.rst
+++ b/Documentation/translations/zh_CN/virt/guest-halt-polling.rst
@@ -76,7 +76,7 @@ guest_halt_poll_ns将保持高位）。
 
 默认值: Y
 
-模块参数可以从Debugfs文件中设置，在::
+模块参数可以从sysfs文件中设置，在::
 
 	/sys/module/haltpoll/parameters/
 
diff --git a/Documentation/translations/zh_TW/process/4.Coding.rst b/Documentation/translations/zh_TW/process/4.Coding.rst
index bdd2abe4daf4..e90a6b51fb98 100644
--- a/Documentation/translations/zh_TW/process/4.Coding.rst
+++ b/Documentation/translations/zh_TW/process/4.Coding.rst
@@ -57,7 +57,7 @@
 注意您還可以使用 ``clang-format`` 工具來幫助您處理這些規則，快速自動重新格式
 化部分代碼，和審閱完整的文件以發現代碼樣式錯誤、拼寫錯誤和可能的改進。它還
 可以方便地排序 ``#includes`` 、對齊變量/宏、重排文本和其他類似任務。有關詳細
-信息，請參閱文檔 :ref:`Documentation/process/clang-format.rst <clangformat>`
+信息，請參閱文檔 :ref:`Documentation/dev-tools/clang-format.rst <clangformat>`
 
 抽象層
 ******
diff --git a/Documentation/translations/zh_TW/process/coding-style.rst b/Documentation/translations/zh_TW/process/coding-style.rst
index c7ac504f6f40..311c6f6bad0b 100644
--- a/Documentation/translations/zh_TW/process/coding-style.rst
+++ b/Documentation/translations/zh_TW/process/coding-style.rst
@@ -657,7 +657,7 @@ Documentation/translations/zh_CN/doc-guide/index.rst 和 scripts/kernel-doc 。
 請注意，您還可以使用 ``clang-format`` 工具幫助您處理這些規則，快速自動重新格
 式化部分代碼，並審閱整個文件以發現代碼風格錯誤、打字錯誤和可能的改進。它還可
 以方便地排序 ``#include`` ，對齊變量/宏，重排文本和其他類似任務。
-詳見 Documentation/process/clang-format.rst 。
+詳見 Documentation/dev-tools/clang-format.rst 。
 
 
 10) Kconfig 配置文件
diff --git a/Documentation/translations/zh_TW/process/magic-number.rst b/Documentation/translations/zh_TW/process/magic-number.rst
index 199cd5d63973..5582df6d7ca7 100644
--- a/Documentation/translations/zh_TW/process/magic-number.rst
+++ b/Documentation/translations/zh_TW/process/magic-number.rst
@@ -4,7 +4,7 @@
 
 .. include:: ../disclaimer-zh_TW.rst
 
-:Original: :ref:`Documentation/process/magic-number.rst <magicnumbers>`
+:Original: :ref:`Documentation/staging/magic-number.rst <magicnumbers>`
 
 如果想評論或更新本文的內容，請直接發信到LKML。如果你使用英文交流有困難的話，也可
 以向中文版維護者求助。如果本翻譯更新不及時或者翻譯存在問題，請聯繫中文版維護者::