Message-Id: <20230425110158.9755-1-fantonifabio@tiscali.it>
Date:   Tue, 25 Apr 2023 13:01:58 +0200
From:   Fabio Fantoni <fantonifabio@...cali.it>
To:     corbet@....net
Cc:     federico.vaga@...a.pv.it, linux-doc@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Fabio Fantoni <fantonifabio@...cali.it>
Subject: [PATCH] doc:it_IT: fix some typos

Fix of some typos spotted reading documentation in italian and latest
changes for 6.4

Signed-off-by: Fabio Fantoni <fantonifabio@...cali.it>
---
 Documentation/translations/it_IT/kernel-hacking/locking.rst | 2 +-
 Documentation/translations/it_IT/process/deprecated.rst     | 2 +-
 .../translations/it_IT/process/submitting-patches.rst       | 6 +++---
 3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/Documentation/translations/it_IT/kernel-hacking/locking.rst
index a9e781d2e323..4c21cf60f775 100644
--- a/Documentation/translations/it_IT/kernel-hacking/locking.rst
+++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst
@@ -1030,7 +1030,7 @@ alle corse critiche, dovreste usare timer_delete_sync()
 (``include/linux/timer.h``) per gestire questo caso.
 
 Prima di rilasciare un temporizzatore dovreste chiamare la funzione
-timer_shutdown() o timer_shutdown_sync() di modo che non venga più ricarmato.
+timer_shutdown() o timer_shutdown_sync() di modo che non venga più riarmato.
 Ogni successivo tentativo di riarmare il temporizzatore verrà silenziosamente
 ignorato.
 
diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Documentation/translations/it_IT/process/deprecated.rst
index 57b501f0dfa4..ba0ed7dc154c 100644
--- a/Documentation/translations/it_IT/process/deprecated.rst
+++ b/Documentation/translations/it_IT/process/deprecated.rst
@@ -386,7 +386,7 @@ combinazione con struct_size() e flex_array_size()::
 Ci sono due casi speciali dove è necessario usare la macro DECLARE_FLEX_ARRAY()
 (da notare che la stessa macro è chiamata __DECLARE_FLEX_ARRAY() nei file di
 intestazione UAPI). Uno è quando l'array flessibile è l'unico elemento di una
-struttura, e l'altro è quando è parti un unione. Per motivi non tecnici, entrambi
+struttura, e l'altro quando è parte di un unione. Per motivi non tecnici, entrambi
 i casi d'uso non sono permessi dalla specifica C99. Per esempio, per
 convertire il seguente codice::
 
diff --git a/Documentation/translations/it_IT/process/submitting-patches.rst b/Documentation/translations/it_IT/process/submitting-patches.rst
index 447b18792e61..f91c8092844f 100644
--- a/Documentation/translations/it_IT/process/submitting-patches.rst
+++ b/Documentation/translations/it_IT/process/submitting-patches.rst
@@ -532,7 +532,7 @@ manutentori che qualche verifica è stata fatta, fornisce un mezzo per trovare
 persone che possano verificare il codice in futuro, e garantisce che queste
 stesse persone ricevano credito per il loro lavoro.
 
-Reviewd-by:, invece, indica che la patch è stata revisionata ed è stata
+Reviewed-by:, invece, indica che la patch è stata revisionata ed è stata
 considerata accettabile in accordo con la dichiarazione dei revisori:
 
 Dichiarazione di svista dei revisori
@@ -563,13 +563,13 @@ una modifica che si ritiene appropriata e senza alcun problema tecnico
 importante.  Qualsiasi revisore interessato (quelli che lo hanno fatto)
 possono offrire il proprio Reviewed-by per la patch.  Questa etichetta serve
 a dare credito ai revisori e a informare i manutentori sul livello di revisione
-che è stato fatto sulla patch.  L'etichetta Reviewd-by, quando fornita da
+che è stato fatto sulla patch.  L'etichetta Reviewed-by, quando fornita da
 revisori conosciuti per la loro conoscenza sulla materia in oggetto e per la
 loro serietà nella revisione, accrescerà le probabilità che la vostra patch
 venga integrate nel kernel.
 
 Quando si riceve una email sulla lista di discussione da un tester o
-un revisore, le etichette Tested-by o Reviewd-by devono essere
+un revisore, le etichette Tested-by o Reviewed-by devono essere
 aggiunte dall'autore quando invierà nuovamente la patch. Tuttavia, se
 la patch è cambiata in modo significativo, queste etichette potrebbero
 non avere più senso e quindi andrebbero rimosse. Solitamente si tiene traccia
-- 
2.25.1

Powered by blists - more mailing lists