docs: pt_BR: Translate submit-checklist to Portuguese

Translate the submit-checklist document from Documentation/process/
to Portuguese (pt_BR) to make the kernel contribution guidelines
more accessible to Portuguese-speaking developers.

Also, add the newly translated file to the main index in the pt_BR
translation directory to ensure it compiles and links correctly
within the Sphinx build.

Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Message-ID: <20260716021013.48025-2-danielmaraboo@gmail.com>

2 files changed, 146 insertions, 0 deletions

diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index 6a72da08d343..40ebf23d774d 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -84,3 +84,4 @@ kernel e sobre como ver seu trabalho integrado.
    Processo do subsistema KVM x86 <process/maintainer-kvm-x86>
    Adicionando uma nova chamada de Sistema <process/adding-syscalls>
    Declaração sobre Drivers do Kernel <process/kernel-driver-statement>
+   Lista de verificação para submissão de patches do kernel Linux <process/submit-checklist>
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..003fc956832d
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/submit-checklist.rst
@@ -0,0 +1,145 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+==============================================================
+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 de kernel aceitas mais rapidamente.
+
+Estas diretrizes vão além da documentação fornecida em
+:ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
+e em outros locais sobre o envio de patches para o kernel Linux.
+
+Revise seu código
+=================
+
+1) Se você usar um recurso, faça o #include do arquivo que define/declara
+   esse recurso. Não dependa de outros arquivos de cabeçalho que incluam
+   os que você usa de forma indireta.
+
+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 estão fazendo e o porquê.
+
+Revise as alterações do Kconfig
+===============================
+
+1) Quaisquer novas ou modificadas opções de ``CONFIG`` não bagunçam o
+   menu de configuração e têm 'desativado' (off) como 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 de ``Kconfig`` possuem texto de ajuda.
+
+3) Foram cuidadosamente revisadas com relação às combinações relevantes de
+   ``Kconfig``. Isso é muito difícil de acertar apenas com testes --- exige
+   capacidade de raciocínio.
+   pays off here.
+
+Forneça documentação
+====================
+
+1) Inclua :ref:`kernel-doc <kernel_doc>` para documentar as 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 sob
+   ``Documentation/``.
+
+3) Todos os novos parâmetros de inicialização (boot) 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 com o espaço de usuário (userspace) devem ser
+   documentadas em ``Documentation/ABI/``. Consulte
+   ``Documentation/admin-guide/abi.rst`` (ou ``Documentation/ABI/README``)
+   para obter mais informações. Patches que alteram interfaces de espaço
+   de usuário devem incluir em cópia (CC) linux-api@vger.kernel.org.
+
+6) Se quaisquer ioctls forem adicionados pelo patch, atualize também
+   ``Documentation/userspace-api/ioctl/ioctl-number.rst``.
+
+Verifique seu código com ferramentas
+====================================
+
+1) Verifique se há violações triviais com o verificador de estilo de patch
+   antes do envio (``scripts/checkpatch.pl``). Você deve ser capaz de
+   justificar todas as violações que permanecerem no seu patch.
+
+2) Faça uma verificação limpa com o sparse.
+
+3) Use ``make checkstack`` e corrija quaisquer problemas encontrados por ele.
+   Observe que o ``checkstack`` não aponta problemas explicitamente, mas
+   qualquer função individual que utilize mais de 512 bytes na pilha é uma
+   candidata a alteração.
+
+Compile seu código
+==================
+
+1) Compila de forma limpa:
+
+  a) com as opções de ``CONFIG`` aplicáveis ou modificadas definidas como
+     ``=y``, ``=m`` e ``=n``. Sem avisos/erros do ``gcc``, sem avisos/erros do
+     vinculador (linker).
+
+  b) Passa em ``allnoconfig``, ``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 (cross-compile) ou alguma outra fazenda de compilação
+   (build farm).
+   Observe que testar em arquiteturas de diferentes tamanhos de palavra
+   (32 e 64 bits) e diferentes endianness (big- e little-endian) é eficaz
+   para capturar vários problemas de portabilidade decorrentes de falsas
+   suposições sobre o intervalo de quantidade representável, alinhamento
+   de dados ou endianness, entre outros.
+
+3) O novo código 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 seu código-fonte modificado depender ou usar quaisquer APIs ou
+   recursos do kernel relacionados aos seguintes símbolos do ``Kconfig``,
+   teste múltiplas compilações com os símbolos relacionados do ``Kconfig``
+   desativados e/ou definidos como ``=m`` (se essa opção estiver disponível)
+   [não todos ao mesmo tempo, apenas combinações variadas/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 habilitados simultaneamente.
+
+2) Foi testado em tempo de compilação e de execução com e sem ``CONFIG_SMP``
+   e ``CONFIG_PREEMPT``.
+
+3) Todos os caminhos de código foram executados com todos os recursos de
+   lockdep ativados.
+
+4) Foi verificado com a injeção de falhas de pelo menos slab e alocação de
+   páginas. Consulte ``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 do linux-next para garantir que ele ainda
+   funcione com todos os outros patches enfileirados e com várias alterações
+   na VM, VFS e outros subsistemas.