[PATCH] docs: pt_BR: process: Translate patch submission checklist

Translate Documentation/process/submit-checklist.rst into Brazilian Portuguese and link it from the pt_BR documentation index.

Signed-off-by: Fabio Pereira da Silva <[email protected]>
---
 Documentation/translations/pt_BR/index.rst    |   1 +
 .../pt_BR/process/submit-checklist.rst        | 141 ++++++++++++++++++
 2 files changed, 142 insertions(+)
 create mode 100644 Documentation/translations/pt_BR/process/submit-checklist.rst

diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index dcc238a5ecfe..c09afbe8e22c 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -72,6 +72,7 @@ kernel e sobre como ver seu trabalho integrado.
    Como começar <process/howto>
    Requisitos mínimos <process/changes>
    CVEs <process/cve>
+   Lista de verificação para patches <process/submit-checklist>
    Conclave (Continuidade do projeto) <process/conclave>
    Manuais dos mantenedores <process/maintainer-handbooks>
    Processo do subsistema de rede (netdev) <process/maintainer-netdev>
diff --git a/Documentation/translations/pt_BR/process/submit-checklist.rst b/Documentation/translations/pt_BR/process/submit-checklist.rst
new file mode 100644
index 000000000000..f53b76268641
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/submit-checklist.rst
@@ -0,0 +1,141 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+.. _pt_submitchecklist:
+
+=================================================================
+Lista de verificação para submissão de patches do kernel Linux
+=================================================================
+
+Aqui estão algumas coisas básicas que os desenvolvedores devem fazer se
+quiserem ver suas submissões de patches para o kernel aceitas mais rapidamente.
+
+Tudo isso vai além da documentação fornecida em
+:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+e em outros lugares sobre a submissão de patches para o kernel Linux.
+
+Revise seu código
+=================
+
+1) Se você usa uma funcionalidade, então inclua com #include o arquivo que
+   define/declara essa funcionalidade. Não dependa de outros arquivos de
+   cabeçalho para incluírem aqueles que você usa.
+
+2) Verifique o estilo geral do seu patch, conforme detalhado em
+   :ref:`Documentation/process/coding-style.rst <codingstyle>`.
+
+3) Todas as barreiras de memória {por exemplo, ``barrier()``, ``rmb()``,
+   ``wmb()``} precisam de um comentário no código-fonte que explique a lógica
+   do que elas estão fazendo e por quê.
+
+Revise alterações de Kconfig
+============================
+
+1) Quaisquer opções ``CONFIG`` novas ou modificadas não devem desorganizar o menu
+   de configuração e devem vir desativadas por padrão, a menos que atendam aos
+   critérios de exceção documentados em ``Documentation/kbuild/kconfig-language.rst``
+   Atributos de menu: valor padrão.
+
+2) Todas as novas opções ``Kconfig`` devem ter texto de ajuda.
+
+3) Deve ter sido revisado cuidadosamente em relação às combinações relevantes
+   de ``Kconfig``. É muito difícil acertar isso com testes; raciocínio
+   cuidadoso compensa aqui.
+
+Forneça documentação
+====================
+
+1) Inclua :ref:`kernel-doc <kernel_doc>` para documentar APIs globais do kernel.
+   (Não é obrigatório para funções estáticas, mas também é aceitável nelas.)
+
+2) Todas as novas entradas em ``/proc`` devem ser documentadas em
+   ``Documentation/``.
+
+3) Todos os novos parâmetros de inicialização do kernel devem ser documentados
+   em ``Documentation/admin-guide/kernel-parameters.rst``.
+
+4) Todos os novos parâmetros de módulo devem ser documentados com
+   ``MODULE_PARM_DESC()``.
+
+5) Todas as novas interfaces de espaço de usuário devem ser documentadas em
+   ``Documentation/ABI/``. Veja Documentation/admin-guide/abi.rst (ou
+   ``Documentation/ABI/README``) para mais informações.
+   Patches que alteram interfaces de espaço de usuário devem colocar
+   [email protected] em cópia (CC).
+
+6) Se algum ioctl for adicionado pelo patch, atualize também
+   ``Documentation/userspace-api/ioctl/ioctl-number.rst``.
+
+Verifique seu código com ferramentas
+====================================
+
+1) Verifique violações triviais com o verificador de estilo de patches antes
+   da submissão (``scripts/checkpatch.pl``). Você deve ser capaz de justificar
+   todas as violações que permanecerem no seu patch.
+
+2) Verifique limpo com sparse.
+
+3) Use ``make checkstack`` e corrija quaisquer problemas encontrados.
+   Observe que ``checkstack`` não aponta problemas explicitamente, mas qualquer
+   função que use mais de 512 bytes na pilha é candidata a alteração.
+
+Compile seu código
+==================
+
+1) Compila sem problemas:
+
+  a) com as opções ``CONFIG`` aplicáveis ou modificadas como ``=y``, ``=m`` e
+     ``=n``. Sem avisos/erros do ``gcc`` e sem avisos/erros do linker.
+
+  b) Passa em ``allnoconfig`` e ``allmodconfig``.
+
+  c) Compila com sucesso ao usar ``O=builddir``.
+
+  d) Quaisquer alterações em Documentation/ compilam com sucesso sem novos
+     avisos/erros. Use ``make htmldocs`` ou ``make pdfdocs`` para verificar a
+     compilação e corrigir quaisquer problemas.
+
+2) Compila em múltiplas arquiteturas de CPU usando ferramentas locais de
+   compilação cruzada ou alguma outra infraestrutura de build.
+   Observe que testar em arquiteturas com tamanhos de palavra diferentes
+   (32 e 64 bits) e endianidade diferente (big-endian e little-endian) é eficaz para
+   detectar vários problemas de portabilidade causados por falsas suposições
+   sobre intervalo de quantidades representáveis, alinhamento de dados ou
+   endianidade, entre outros.
+
+3) Código recém-adicionado foi compilado com ``gcc -W`` (use
+   ``make KCFLAGS=-W``). Isso gerará muito ruído, mas é bom para encontrar
+   bugs como "warning: comparison between signed and unsigned".
+
+4) Se o código-fonte modificado depende de ou usa qualquer API ou recurso do
+   kernel relacionado aos seguintes símbolos ``Kconfig``, então teste múltiplas
+   compilações com os símbolos ``Kconfig`` relacionados desativados e/ou como
+   ``=m`` (se essa opção estiver disponível) [não todos ao mesmo tempo, apenas
+   várias combinações aleatórias deles]:
+
+   ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``,
+   ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``,
+   ``CONFIG_NET``, ``CONFIG_INET=n`` (mas este último com ``CONFIG_NET=y``).
+
+Teste seu código
+================
+
+1) Foi testado com ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
+   ``CONFIG_SLUB_DEBUG``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
+   ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
+   ``CONFIG_PROVE_RCU`` e ``CONFIG_DEBUG_OBJECTS_RCU_HEAD`` todos ativados
+   simultaneamente.
+
+2) Foi testado em compilação e em tempo de execução com e sem ``CONFIG_SMP`` e
+   ``CONFIG_PREEMPT``.
+
+3) Todos os caminhos de código foram exercitados com todos os recursos do lockdep
+   ativados.
+
+4) Foi verificado com injeção de falhas pelo menos de slab e de alocação de
+   páginas. Veja ``Documentation/fault-injection/``. Se o novo código for
+   substancial, a adição de injeção de falhas específica do subsistema pode ser
+   apropriada.
+
+5) Testado com a tag mais recente da linux-next para garantir que ainda funciona
+   com todos os outros patches enfileirados e várias alterações na VM, VFS e em
+   outros subsistemas.
\ No newline at end of file
-- 
2.55.0.windows.2