* Re: [PATCH 2/6] mm/damon/sysfs: implement update_schemes_quota_goals command
From: SeongJae Park @ 2026-05-19 15:08 UTC (permalink / raw)
To: Maksym Shcherba
Cc: SeongJae Park, Maksym Shcherba, akpm, david, ljs, liam, vbabka,
rppt, surenb, mhocko, corbet, skhan, damon, linux-mm,
linux-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260519073352.16587-1-maksym.shcherba@lnu.edu.ua>
On Tue, 19 May 2026 10:33:52 +0300 Maksym Shcherba <mshcherba2000@gmail.com> wrote:
> On Mon, 18 May 2026 17:17:02 -0700 SeongJae Park <sj@kernel.org> wrote:
>
> > On Mon, 18 May 2026 22:09:28 +0300 Maksym Shcherba <mshcherba2000@gmail.com> wrote:
> >
> > > Add the logic to copy the current_value from the internal
> > > damos_quota_goal structure to the damos_sysfs_quota_goal sysfs structure.
> > > Introduce the DAMON_SYSFS_CMD_UPDATE_SCHEMES_QUOTA_GOALS command
> > > and integrate it with the sysfs interface via the 'state' file.
> >
> > Could you please further elaborate why you think this change is needed? What
> > is the expected use case and benefit?
> >
>
> Hi SJ,
>
> The documentation (`Documentation/admin-guide/mm/damon/usage.rst`)
> states that users can read the `current_value` file. However, the
> kernel currently never updates this value in sysfs, preventing users
> from reading the actual metrics.
>
> This patch series implements the missing logic to align the code
> with the documentation.
Thank you for clarifying, Maksym.
>
> If the design intent was to intentionally keep `current_value`
> internal and not expose it via sysfs, then the documentation is
> incorrect. Let me know if that's the case, and I will send a v2
> that drops the code changes and only fixes the documentation.
Yes, the documentation is incorrect. It was written in the way due to
following history. The DAMOS quota auto-tuning feature was initially developed
with oly 'user_input' target metric type. In the case, 'current_value' is set
by users. Hence reading the file was returning the last user-input value.
That is, as the documentation is also saying, it is returning the 'parameter'
(user input) value. It is not designed for exposing the internal state.
Later we extended the feature to let DAMOS self-fetch the current value. The
fact that the ``current_value`` is for reading and writing the parameter (user
input) value, and therefore reading it doesn't return the internal set value,
should be further clarified, but I forgot doing that.
So, yes, if the current behavior is not making problem, let's update the
documentation. I'll wait for your v2 :)
>
> (Apologies for missing the cover letter where this should have
> been explained, this is my first patch submission).
No worries, we continuously mistake and learn from each other in the
DAMON/mm/linux community! Welcome to the community, and I'm looking forward to
your v2!
Thanks,
SJ
[...]
^ permalink raw reply
* Re: [RFC PATCH 0/5] mm: support zswap-backed anonymous large folio swapin
From: Alexandre Ghiti @ 2026-05-19 14:49 UTC (permalink / raw)
To: Fujunjie
Cc: Andrew Morton, Chris Li, Kairui Song, Johannes Weiner, Nhat Pham,
Yosry Ahmed, linux-mm, linux-kernel, linux-doc, Jonathan Corbet,
David Hildenbrand, Ryan Roberts, Barry Song, Baolin Wang,
Chengming Zhou, Baoquan He, Lorenzo Stoakes
In-Reply-To: <tencent_BE4D8C052157D1B38BA2F9FCA287D4C8E606@qq.com>
Hi,
On Tue, May 12, 2026 at 9:46 AM Fujunjie <fujunjie1@qq.com> wrote:
>
> >
>
>
> On 5/12/2026 12:20 PM, Alexandre Ghiti wrote:
> > So I have been working on the exact same thing for some weeks now. My work is based on Usama's series [1].
> >
> > The problem with large folio swapin is that it can create swap thrashing: to swap in a large folio, swap out may be necessary, as reported in [2].
> >
> > I implemented quite a few throttling algorithms on top to try to avoid this issue and so far, I have had mixed/inconsistent results.
> >
> > How did you test this series? Did you encounter thrashing? Do you have performance numbers?
> >
> > Happy to talk more about this, thanks for your series!
> >
> > Alex
> >
> > [1] https://lore.kernel.org/all/20241018105026.2521366-1-usamaarif642@gmail.com/ <https://lore.kernel.org/all/20241018105026.2521366-1-usamaarif642@gmail.com/ >
> > [2] https://lore.kernel.org/all/SJ0PR11MB5678A864244B09FDE4D914EEC9402@SJ0PR11MB5678.namprd11.prod.outlook.com/ <https://lore.kernel.org/all/SJ0PR11MB5678A864244B09FDE4D914EEC9402@SJ0PR11MB5678.namprd11.prod.outlook.com/ >
>
> Thanks Alexandre.
>
> My RFC only had correctness testing so far. I tested the all-zswap path
> and fallback cases under QEMU, but I don't have bare-metal
> performance numbers yet.
>
> If you are already actively working on this, I don't want to duplicate the
> same effort. I will pause this RFC for now and wait for your series.
>
> After your series is posted, I will take another look and see if there is
> anything that still needs follow-up work.
>
> Thanks for letting me know.
Sorry for the late answer. I took a break because of the inconsistent
results that I had, perhaps a fresh look could help so no worries if
you give it a try on your end.
Happy to discuss further results if you continue.
Alex
>
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-19 14:13 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Marc Zyngier, Will Deacon, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <CABgObfbS-z3OphDna5W_JQPvw+OK=yXJurVMHp1ANZ5uGEgVhQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2526 bytes --]
On Tue, 2026-05-19 at 15:53 +0200, Paolo Bonzini wrote:
> On Tue, May 19, 2026 at 3:00 PM David Woodhouse <dwmw2@infradead.org> wrote:
> > Or some guest configurations which have only ever been tested under KVM
> > could have a bug where they *rely* on the registers not being writable,
> > and write values which are inconsistent with the rest of their
> > configuration. Which breaks the moment those registers become writable.
>
> Yeah, just having guests that worked by utter chance - but you still
> don't want to break them - is the case that is most likely. Crappy
> code that runs only under emulation/virtualization appears with
> probability 1 over time.
>
> Is this likely in this specific case---probably not, honestly.
> Christoffer's patch dates back to 2018 (commit d53c2c29ae0d); *back
> then* KVM/Arm was a lot less mature, and people developing for Arm on
> vanilla upstream kernels have moved on from Linux 4.19.
It's not really 2018 though. EC2 is still running kernels with that
older commit reverted because of the breaking change that it
introduced.
So the behaviour corresponding to GICD_IIDR.implementation_rev=1 is
still current for *millions* of guests.
I'm now finding that revert in our tree during a *later* kernel upgrade
and trying to eliminate it.
And sure, I have given the engineers responsible for that a very hard
stare and suggested that they should have fixed it 'properly' in the
first place with a patch like the one we're discussing right now.
And they're looking at this thread and saying "haha no, if fixing
things properly for Arm is this hard then we'll stick with the crappy
approach".
I do not want them to be right. I don't think any of us want that.
> I would still lean towards accepting the code considering the limited
> complexity of the addition (in fact I like it more now that it uses
> IIDR instead of v2_groups_user_writable, but that's taste).
I'm absolutely prepared to have a separate technical discussion about
the v2_groups_user_writable thing for GICv2, which is the second part
of that series.
It seems like the right thing to do, and as far as I can tell, this
code *never* worked with QEMU. But I'm not sure who even cares about
GICv2 any more. I couldn't find hardware and I had to test the whole
thing inside qemu-tcg.
But the 'IIDR defaults to 3 but the *behaviour* doesn't match until you
explicitly *set* it to 3' thing seemed so *egregiously* wrong to me,
that I fixed it anyway.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] Doc, scripts: facilitate phaseout of strlcat
From: Manuel Ebner @ 2026-05-19 14:10 UTC (permalink / raw)
To: Andy Shevchenko, Kees Cook, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
Geert Uytterhoeven, David Laight, Randy Dunlap, Jani Nikula,
Heiko Carstens, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list
In-Reply-To: <20260514160719.105084-3-manuelebner@mailbox.org>
Hello
i'll ditch this series - it's just not the time yet.
Manuel
On Thu, 2026-05-14 at 18:07 +0200, Manuel Ebner wrote:
> Thanks for all the feedback. I tried to incorporate it in this version.
>
> The goal of this series is to facilitate the transition away from strlcat()
>
> [v2]
> add recipants
> add remarks to strlcat definition in
> lib/string.c
> tools/include/nolibc/string.h
> -> [3/3]
>
^ permalink raw reply
* Re: [PATCH] liveupdate: document liveupdate=on
From: Pasha Tatashin @ 2026-05-19 14:03 UTC (permalink / raw)
To: Mike Rapoport, Luca Boccassi, Jonathan Corbet, Pratyush Yadav
Cc: linux-kernel, kexec, linux-doc
In-Reply-To: <20260519125714.2435640-1-pratyush@kernel.org>
On Tue, 19 May 2026 14:57:06 +0200, Pratyush Yadav wrote:
> While the liveupdate= parameter is documented in kernel-parameters.txt,
> it is not listed in LUO's user facing documentation. This can make it
> hard for users to figure out how to enable the subsystem, since enabling
> just the config isn't enough.
>
> Note the need for the kernel parameter in LUO core documentation, which
> gets exported to Documentation/core-api/liveupdate.rst.
>
> [...]
Applied, thanks!
[1/1] liveupdate: document liveupdate=on
commit: d65d7e28888a6f3a1999908cacadd99f4c14ddd9
Best regards,
--
Pasha Tatashin <pasha.tatashin@soleen.com>
^ permalink raw reply
* Re: [PATCH v3 3/4] docs: pt_BR: Translate process/kernel-docs.rst into Portuguese
From: Daniel Pereira @ 2026-05-19 14:03 UTC (permalink / raw)
To: linux-doc
In-Reply-To: <20260519140035.1031694-1-danielmaraboo@gmail.com>
On Tue, May 19, 2026 at 11:00 AM Daniel Pereira <danielmaraboo@gmail.com> wrote:
>
> Translate Documentation/process/kernel-docs.rst into Portuguese (pt_BR)
> and update the main index.
>
> The content was adapted following the RST formatting rules and the
> appropriate technical terminology for Brazilian Portuguese.
>
> Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
> ---
> Documentation/translations/pt_BR/index.rst | 1 +
> .../pt_BR/process/kernel-docs.rst | 373 ++++++++++++++++++
> 2 files changed, 374 insertions(+)
> create mode 100644 Documentation/translations/pt_BR/process/kernel-docs.rst
>
> diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
> index 77c1a1cdc..76936710b 100644
> --- a/Documentation/translations/pt_BR/index.rst
> +++ b/Documentation/translations/pt_BR/index.rst
> @@ -67,6 +67,7 @@ kernel e sobre como ver seu trabalho integrado.
> :maxdepth: 1
Hello everyone,
Please kindly disregard this patch. It was mistakenly generated as
piece 3/4 of a series, but it is actually a standalone patch.
I will resend it in the correct format shortly.
Best regards,
Daniel Pereira
^ permalink raw reply
* [PATCH v3 3/4] docs: pt_BR: Translate process/kernel-docs.rst into Portuguese
From: Daniel Pereira @ 2026-05-19 14:00 UTC (permalink / raw)
To: linux-doc; +Cc: corbet, Daniel Pereira
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 17550 bytes --]
Translate Documentation/process/kernel-docs.rst into Portuguese (pt_BR)
and update the main index.
The content was adapted following the RST formatting rules and the
appropriate technical terminology for Brazilian Portuguese.
Signed-off-by: Daniel Pereira <danielmaraboo@gmail.com>
---
Documentation/translations/pt_BR/index.rst | 1 +
.../pt_BR/process/kernel-docs.rst | 373 ++++++++++++++++++
2 files changed, 374 insertions(+)
create mode 100644 Documentation/translations/pt_BR/process/kernel-docs.rst
diff --git a/Documentation/translations/pt_BR/index.rst b/Documentation/translations/pt_BR/index.rst
index 77c1a1cdc..76936710b 100644
--- a/Documentation/translations/pt_BR/index.rst
+++ b/Documentation/translations/pt_BR/index.rst
@@ -67,6 +67,7 @@ kernel e sobre como ver seu trabalho integrado.
:maxdepth: 1
Introdução <process/1.Intro>
+ Index de documentos do Kernel <process/kernel-docs>
Regras de licenciamento <process/license-rules>
Como começar <process/howto>
Requisitos mínimos <process/changes>
diff --git a/Documentation/translations/pt_BR/process/kernel-docs.rst b/Documentation/translations/pt_BR/process/kernel-docs.rst
new file mode 100644
index 000000000..3c8d80ffa
--- /dev/null
+++ b/Documentation/translations/pt_BR/process/kernel-docs.rst
@@ -0,0 +1,373 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Índice de Documentação Adicional do Kernel
+==========================================
+
+A necessidade de um documento como este tornou-se evidente na lista de discussão
+linux-kernel, uma vez que as mesmas perguntas, solicitando referências de
+informações, apareciam repetidamente.
+
+Felizmente, à medida que cada vez mais pessoas chegam ao GNU/Linux, mais pessoas
+se interessam pelo Kernel. No entanto, ler o código-fonte nem sempre é o
+suficiente. É fácil entender o código, mas perder os conceitos, a filosofia
+e as decisões de design por trás dele.
+
+Infelizmente, não há muitos documentos disponíveis para iniciantes começarem.
+E, mesmo quando existem, não havia um local "bem conhecido" que os centralizasse.
+Estas linhas tentam suprir essa falta.
+
+POR FAVOR, se você conhece algum artigo não listado aqui ou se escrever um novo
+documento, inclua uma referência a ele aqui, seguindo o processo de envio de
+patches do kernel. Quaisquer correções, ideias ou comentários também são
+bem-vindos.
+
+Todos os documentos estão catalogados com os seguintes campos: o "Título" do
+documento, o(s) "Autor(es)", a "URL" onde podem ser encontrados, algumas
+"Palavras-chave" úteis para pesquisar tópicos específicos e uma breve
+"Descrição" do documento.
+
+.. note::
+
+ Os documentos em cada seção deste documento estão ordenados por sua data de
+ publicação, do mais recente para o mais antigo. O(s) mantenedor(es) deve(m)
+ remover periodicamente recursos à medida que se tornem obsoletos ou
+ desatualizados; com exceção de livros fundamentais.
+
+Documentação na árvore do Kernel
+--------------------------------
+
+Os manuais Sphinx devem ser compilados com ``make {htmldocs | pdfdocs | epubdocs}``.
+
+ * Nome: **linux/Documentation**
+
+ :Autor: Muitos.
+ :Localização: Documentation/
+ :Palavras-chave: arquivos de texto, Sphinx.
+ :Descrição: Documentação que acompanha o código-fonte do kernel,
+ dentro do diretório Documentation. Algumas páginas deste documento
+ (incluindo este próprio documento) foram movidas para lá e podem
+ estar mais atualizadas do que a versão web.
+
+Documentação on-line
+--------------------
+
+ * Título: **Linux Kernel Mailing List Glossary**
+
+ :Autor: diversos
+ :URL: https://kernelnewbies.org/KernelGlossary
+ :Data: versão contínua (rolling)
+ :Palavras-chave: glossário, termos, linux-kernel.
+ :Descrição: Da introdução: "Este glossário destina-se a ser uma breve
+ descrição de algumas das siglas e termos que você poderá ouvir durante
+ as discussões sobre o kernel Linux".
+
+ * Título: **The Linux Kernel Module Programming Guide**
+
+ :Autor: Peter Jay Salzman, Michael Burian, Ori Pomerantz, Bob Mottram,
+ Jim Huang.
+ :URL: https://sysprog21.github.io/lkmpg/
+ :Data: 2021
+ :Palavras-chave: módulos, livro GPL, /proc, ioctls, chamadas de sistema,
+ manipuladores de interrupção.
+ :Descrição: Um excelente livro sob licença GPL sobre o tópico de
+ programação de módulos. Repleto de exemplos. Atualmente, a nova versão
+ está sendo mantida ativamente em https://github.com/sysprog21/lkmpg.
+
+Livros Publicados
+-----------------
+
+ * Title: **The Linux Memory Manager**
+
+ :Autor: Lorenzo Stoakes
+ :Editora: No Starch Press
+ :Data: Fevereiro 2025
+ :Páginas: 1300
+ :ISBN: 978-1718504462
+ :Notas: Gerenciamento de memória. Rascunho completo disponível como acesso
+ antecipado para ré-venda, lançamento completo agendado para o
+ outono de 2025. Veja https://nostarch.com/linux-memory-manager
+ para mais informações.
+
+ * Title: **Practical Linux System Administration: A Guide to Installation, Configuration, and Management, 1st Edition**
+
+ :Autor: Kenneth Hess
+ :Editora: O'Reilly Media
+ :Data: Maio, 2023
+ :Páginas: 246
+ :ISBN: 978-1098109035
+ :Notas: Administração de sistemas
+
+ * Title: **Linux Kernel Debugging: Leverage proven tools and advanced techniques to effectively debug Linux kernels and kernel modules**
+
+ :Autor: Kaiwan N Billimoria
+ :Editora: Packt Publishing Ltd
+ :Data: Agosto, 2022
+ :Páginas: 638
+ :ISBN: 978-1801075039
+ :Notas: Livro sobre depuração (debugging)
+
+ * Title: **Linux Kernel Programming: A Comprehensive Guide to Kernel Internals, Writing Kernel Modules, and Kernel Synchronization**
+
+ :Autor: Kaiwan N Billimoria
+ :Editora: Packt Publishing Ltd
+ :Data: Março, 2021 (Segunda edição publicada em 2024)
+ :Páginas: 754
+ :ISBN: 978-1789953435 (O ISBN da segunda edição é 978-1803232225)
+
+ * Title: **Linux Kernel Programming Part 2 - Char Device Drivers and Kernel Synchronization: Create user-kernel interfaces, work with peripheral I/O, and handle hardware interrupts**
+
+ :Autor: Kaiwan N Billimoria
+ :Editora: Packt Publishing Ltd
+ :Data: Março, 2021
+ :Páginas: 452
+ :ISBN: 978-1801079518
+
+ * Title: **Linux System Programming: Talking Directly to the Kernel and C Library**
+
+ :Autor: Robert Love
+ :Editora: O'Reilly Media
+ :Data: Junho, 2013
+ :Páginas: 456
+ :ISBN: 978-1449339531
+ :Notas: Livro fundamental
+
+ * Título: **Linux Kernel Development, 3rd Edition**
+
+ :Autor: Robert Love
+ :Editora: Addison-Wesley
+ :Data: Julho de 2010
+ :Páginas: 440
+ :ISBN: 978-0672329463
+ :Notas: Livro fundamental
+
+ * Título: **Linux Device Drivers, 3rd Edition**
+
+ :Autores: Jonathan Corbet, Alessandro Rubini e Greg Kroah-Hartman
+ :Editora: O'Reilly & Associates
+ :Data: 2005
+ :Páginas: 636
+ :ISBN: 0-596-00590-3
+ :Notas: Livro fundamental. Mais informações em
+ http://www.oreilly.com/catalog/linuxdrive3/
+ Formato PDF, URL: https://lwn.net/Kernel/LDD3/
+
+ * Título: **The Design of the UNIX Operating System**
+
+ :Autor: Maurice J. Bach
+ :Editora: Prentice Hall
+ :Data: 1986
+ :Páginas: 471
+ :ISBN: 0-13-201757-1
+ :Notas: Livro fundamental
+
+Diversos
+--------
+
+ * Nome: **Cross-Referencing Linux**
+
+ :URL: https://elixir.bootlin.com/
+ :Palavras-chave: Navegação em código-fonte.
+ :Descrição: Outro navegador web para o código-fonte do kernel Linux.
+ Possui muitas referências cruzadas para variáveis e funções. Você pode
+ ver onde elas são definidas e onde são utilizadas.
+
+ * Nome: **Linux Weekly News**
+
+ :URL: https://lwn.net
+ :Palavras-chave: últimas notícias do kernel.
+ :Descrição: O título diz tudo. Há uma seção fixa sobre o kernel que
+ resume o trabalho dos desenvolvedores, correções de bugs, novos recursos
+ e versões produzidas durante a semana.
+
+ * Nome: **The home page of Linux-MM**
+
+ :Autor: A equipe Linux-MM.
+ :URL: https://linux-mm.org/
+ :Palavras-chave: gerenciamento de memória, Linux-MM, mm patches, TODO,
+ docs, mailing list.
+ :Descrição: Site dedicado ao desenvolvimento do Gerenciamento de Memória
+ do Linux. Patches relacionados à memória, HOWTOs, links, desenvolvedores
+ mm... Não perca se você estiver interessado no desenvolvimento do
+ gerenciamento de memória!
+
+ * Nome: **Kernel Newbies IRC Channel and Website**
+
+ :URL: https://www.kernelnewbies.org
+ :Palavras-chave: IRC, novatos, canal, tirar dúvidas.
+ :Descrição: #kernelnewbies em irc.oftc.net.
+ O canal #kernelnewbies é uma rede de IRC dedicada ao hacker de kernel
+ "novato" (newbie). O público consiste principalmente de pessoas que estão
+ aprendendo sobre o kernel, trabalhando em projetos do kernel ou hackers
+ profissionais que desejam ajudar pessoas menos experientes.
+ O #kernelnewbies está na rede de IRC OFTC.
+ Tente acessar irc.oftc.net como seu servidor e então digite /join #kernelnewbies.
+ O site kernelnewbies também hospeda artigos, documentos, FAQs...
+
+ * Nome: **linux-kernel mailing list archives and search engines**
+
+ :URL: https://subspace.kernel.org
+ :URL: https://lore.kernel.org
+ :Palavras-chave: linux-kernel, arquivos, busca.
+ :Descrição: Alguns dos arquivadores da lista de discussão linux-kernel.
+ Se você conhece algum outro (ou um melhor), por favor, me avise.
+
+ * Nome: **The Linux Foundation YouTube channel**
+
+ :URL: https://www.youtube.com/user/thelinuxfoundation
+ :Palavras-chave: linux, vídeos, linux-foundation, youtube.
+ :Descrição: A Linux Foundation faz o upload de gravações de vídeo de seus
+ eventos colaborativos, conferências de Linux (incluindo a LinuxCon) e
+ outras pesquisas originais e conteúdos relacionados ao Linux e ao
+ desenvolvimento de software.
+
+Rust
+----
+
+ * Título: **Rust for Linux**
+
+ :Autor: diversos
+ :URL: https://rust-for-linux.com/
+ :Data: versão contínua (rolling)
+ :Palavras-chave: glossário, termos, linux-kernel, rust.
+ :Descrição Do site: "Rust for Linux é o projeto que adiciona suporte à
+ linguagem Rust ao kernel Linux. Este site pretende ser um hub de links,
+ documentação e recursos relacionados ao projeto".
+
+ * Título: **Learn Rust the Dangerous Way**
+
+ :Autor: Cliff L. Biffle
+ :URL: https://cliffle.com/p/dangerust/
+ :Data: Acessado em 11 de setembro de 2024
+ :Palavras-chave: rust, blog.
+ :Descrição: Do site: "LRtDW é uma série de artigos que coloca os recursos
+ do Rust em contexto para programadores C de baixo nível que talvez não
+ tenham uma formação formal em Ciência da Computação, o tipo de pessoa
+ que trabalha com firmware, engines de jogos, kernels de SO e afins.
+ Basicamente, pessoas como eu.". O site ilustra conversões de linha por
+ linha de C para Rust.
+
+ * Título: **The Rust Book**
+
+ :Autor: Steve Klabnik e Carol Nichols, com contribuições da comunidade Rust
+ :URL: https://doc.rust-lang.org/book/
+ :Data: Acessado em 11 de setembro de 2024
+ :Palavras-chave: rust, livro.
+ :Descrição: Do site: "Este livro abraça totalmente o potencial do Rust para
+ capacitar seus usuários. É um texto amigável e acessível destinado a
+ ajudá-lo a elevar não apenas seu conhecimento de Rust, mas também seu
+ alcance e confiança como programador em geral. Então mergulhe de cabeça,
+ prepare-se para aprender e bem-vindo à comunidade Rust!".
+
+ * Título: **Rust for the Polyglot Programmer**
+
+ :Autor: Ian Jackson
+ :URL: https://www.chiark.greenend.org.uk/~ianmdlvl/rust-polyglot/index.html
+ :Data: Dezembro de 2022
+ :Palavras-chave: rust, blog, tooling.
+ :Descrição: Do site: "Existem muitos guias e introduções ao Rust. Este é
+ algo diferente: destina-se ao programador experiente que já conhece
+ muitas outras linguagens de programação. Tento ser abrangente o suficiente
+ para servir de ponto de partida para qualquer área do Rust, mas evito
+ entrar em detalhes excessivos, exceto onde as coisas não são como você
+ poderia esperar. Além disso, este guia não é inteiramente isento de
+ opiniões, incluindo recomendações de bibliotecas (crates), ferramentas, etc.".
+
+ * Título: **Fasterthanli.me**
+
+ :Autor: Amos Wenger
+ :URL: https://fasterthanli.me/
+ :Data: Acessado em 11 de setembro de 2024
+ :Palavras-chave: rust, blog, notícias.
+ :Descrição: Do site: "Eu crio artigos e vídeos sobre como os computadores
+ funcionam. Meu conteúdo é de formato longo, didático e exploratório
+ e frequentemente uma desculpa para ensinar Rust!".
+
+ * Título: **Comprehensive Rust**
+
+ :Autor: Equipe Android do Google
+ :URL: https://google.github.io/comprehensive-rust/
+ :Data: Acessado em 13 de setembro de 2024
+ :Palavras-chave: rust, blog.
+ :Descrição: Do site: "O curso cobre todo o espectro do Rust, desde a
+ sintaxe básica até tópicos avançados como genéricos e tratamento de erros".
+
+ * Título: **The Embedded Rust Book**
+
+ :Autor: Múltiplos colaboradores, principalmente Jorge Aparicio
+ :URL: https://docs.rust-embedded.org/book/
+ :Data: Acessado em 13 de setembro de 2024
+ :Palavras-chave: rust, blog.
+ :Descrição: Do site: "Um livro introdutório sobre o uso da linguagem de
+ programação Rust em sistemas embarcados 'Bare Metal', como microcontroladores".
+
+ * Título: **Experiment: Improving the Rust Book**
+
+ :Autor: Cognitive Engineering Lab na Brown University
+ :URL: https://rust-book.cs.brown.edu/
+ :Data: Acessado em 22 de setembro de 2024
+ :Palavras-chave: rust, blog.
+ :Descrição: Do site: "O objetivo deste experimento é avaliar e melhorar o
+ conteúdo do Rust Book para ajudar as pessoas a aprenderem Rust de forma
+ mais eficaz".
+
+ * Título: **New Rustacean** (podcast)
+
+ :Autor: Chris Krycho
+ :URL: https://newrustacean.com/
+ :Data: Acessado em 22 de setembro de 2024
+ :Palavras-chave: rust, podcast.
+ :Descrição: Do site: "Este é um podcast sobre aprender a linguagem de
+ programação Rust do zero! Além desta página inicial elegante, todo o
+ conteúdo do site é construído com as próprias ferramentas de documentação
+ do Rust".
+
+ * Título: **Opsem-team** (repositório)
+
+ :Autor: Equipe de semântica operacional (Operational semantics team)
+ :URL: https://github.com/rust-lang/opsem-team/tree/main
+ :Data: Acessado em 22 de setembro de 2024
+ :Palavras-chave: rust, repositório.
+ :Descrição: Do README: "A equipe opsem é a sucessora do grupo de trabalho
+ unsafe-code-guidelines e é responsável por responder a muitas das perguntas
+ difíceis sobre a semântica do Rust inseguro (unsafe Rust)".
+
+ * Título: **You Can't Spell Trust Without Rust**
+
+ :Autor: Alexis Beingessner
+ :URL: https://repository.library.carleton.ca/downloads/1j92g820w?locale=en
+ :Data: 2015
+ :Palavras-chave: rust, mestrado, tese.
+ :Descrição: Esta tese foca no sistema de propriedade (ownership) do Rust,
+ que garante a segurança de memória ao controlar a manipulação de dados e
+ o tempo de vida, enquanto também destaca suas limitações e o compara a
+ sistemas semelhantes no Cyclone e C++.
+
+ * Nome: **Apresentações de Rust no Linux Plumbers (LPC) 2024**
+
+ :Título: Rust microconference
+ :URL: https://lpc.events/event/18/sessions/186/#20240918
+ :Título: Rust for Linux
+ :URL: https://lpc.events/event/18/contributions/1912/
+ :Título: Journey of a C kernel engineer starting a Rust driver project
+ :URL: https://lpc.events/event/18/contributions/1911/
+ :Título: Crafting a Linux kernel scheduler that runs in user-space using Rust
+ :URL: https://lpc.events/event/18/contributions/1723/
+ :Título: openHCL: A Linux and Rust based paravisor
+ :URL: https://lpc.events/event/18/contributions/1956/
+ :Palavras-chave: rust, lpc, apresentações.
+ :Descrição: Uma série de palestras do LPC relacionadas ao Rust.
+
+ * Nome: **The Rustacean Station Podcast**
+
+ :URL: https://rustacean-station.org/
+ :Palavras-chave: rust, podcasts.
+ :Descrição: Um projeto comunitário para a criação de conteúdo em podcast
+ sobre a linguagem de programação Rust.
+
+-------
+
+Este documento foi originalmente baseado em:
+
+https://www.dit.upm.es/~jmseyas/linux/kernel/hackers-docs.html
+
+e escrito por Juan-Mariano de Goyeneche.
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: Paolo Bonzini @ 2026-05-19 13:53 UTC (permalink / raw)
To: David Woodhouse
Cc: Marc Zyngier, Will Deacon, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <593a782c50f3c8656e13b36dfb975a67d43a908e.camel@infradead.org>
On Tue, May 19, 2026 at 3:00 PM David Woodhouse <dwmw2@infradead.org> wrote:
> Or some guest configurations which have only ever been tested under KVM
> could have a bug where they *rely* on the registers not being writable,
> and write values which are inconsistent with the rest of their
> configuration. Which breaks the moment those registers become writable.
Yeah, just having guests that worked by utter chance - but you still
don't want to break them - is the case that is most likely. Crappy
code that runs only under emulation/virtualization appears with
probability 1 over time.
Is this likely in this specific case---probably not, honestly.
Christoffer's patch dates back to 2018 (commit d53c2c29ae0d); *back
then* KVM/Arm was a lot less mature, and people developing for Arm on
vanilla upstream kernels have moved on from Linux 4.19.
I would still lean towards accepting the code considering the limited
complexity of the addition (in fact I like it more now that it uses
IIDR instead of v2_groups_user_writable, but that's taste). However,
there's a huge difference between setting expectations based on 2018
vs 2026 maturity, and perhaps that's why Marc overall is inclined to
put this in the category of pointless bug for bug compatibility?
In any case, there's no arguing over this documentation patch, which
is already a good thing to know.
Thanks,
Paolo
> And those hypothetical cases *do* happen. All of the time. There's a
> massive zoo of guest operating systems; not just the major players like
> Linux, FreeBSD and Windows but a whole bunch of embedded home-grown and
> network appliance kernels.
>
> Nobody is claiming that we shouldn't fix any bug ever.
^ permalink raw reply
* Re: [PATCH] docs/filesystems/9p: fix broken external links
From: Aayush Patil @ 2026-05-19 13:53 UTC (permalink / raw)
To: Dominique Martinet
Cc: ericvh, lucho, linux_oss, corbet, skhan, v9fs, linux-doc,
linux-kernel
In-Reply-To: <CABc3pKGKCLydod2NOgETP-z0T5BHep8hyy7z2UF3o+DrWEh5yw@mail.gmail.com>
Hi Dominique,
Thanks for the review! Yes, the trailing S is a typo.
Regarding the replacement links, should I include them in v2 or leave
those entries removed since you're not sure if they're the same files?
Happy to go either way.
Aayush
On Tue, 19 May 2026 at 19:14, Aayush Patil <aayushpatilsch@gmail.com> wrote:
>
> Hi Dominique,
>
> Thanks for the review!
>
> Regarding the replacement links, should I include them in v2 or leave those entries removed since you're not sure if they're the same files? Happy to go either way.
>
> Aayush
>
>
> On Tue, 19 May 2026 at 17:56, Dominique Martinet <asmadeus@codewreck.org> wrote:
>>
>> Aayush Patil wrote on Sun, May 10, 2026 at 11:58:56PM +0530:
>> > The xcpu.org links for xcpu-talk, kvmfs, and cellfs-talk are dead
>> > with no archived snapshots available on the Wayback Machine, so
>> > remove them. The PROSE I/O link redirects to a dead server; replace
>> > it with an archived version from web.archive.org.S
>>
>> (I assume the final S is a typo here)
>>
>> Eric, it looks like you're the one who added these links, would you
>> happen to have a copy around if you care about keeping these?
>> Otherwise I'm not sure of the value of listing the papers without the
>> actual files available, but I don't mind either way.
>>
>> I agree dead links are of little value though so will pick this up if
>> there's no reply in a while
>>
>> >
>> > Signed-off-by: Aayush Patil <aayushpatilsch@gmail.com>
>> > ---
>> > Documentation/filesystems/9p.rst | 5 +----
>> > 1 file changed, 1 insertion(+), 4 deletions(-)
>> >
>> > diff --git a/Documentation/filesystems/9p.rst b/Documentation/filesystems/9p.rst
>> > index be3504ca034a..65809a1dad21 100644
>> > --- a/Documentation/filesystems/9p.rst
>> > +++ b/Documentation/filesystems/9p.rst
>> > @@ -23,13 +23,10 @@ the 9p client is available in the form of a USENIX paper:
>> > Other applications are described in the following papers:
>> >
>> > * XCPU & Clustering
>> > - http://xcpu.org/papers/xcpu-talk.pdf
>>
>> I found http://mirtchovski.postnix.pw/p9/xcpu-talk.pdf but I'm not sure
>> if it's the same file
>>
>> > * KVMFS: control file system for KVM
>> > - http://xcpu.org/papers/kvmfs.pdf
>>
>> Looks close but perhaps not the same as
>> https://www.kernel.org/doc/ols/2007/ols2007v2-pages-59-64.pdf ?
>>
>> > * CellFS: A New Programming Model for the Cell BE
>> > - http://xcpu.org/papers/cellfs-talk.pdf
>>
>> Couldn't find anything fo this one
>>
>> > * PROSE I/O: Using 9p to enable Application Partitions
>> > - http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
>> > + http://web.archive.org/web/20110101152020/http://plan9.escet.urjc.es/iwp9/cready/PROSE_iwp9_2006.pdf
>> > * VirtFS: A Virtualization Aware File System pass-through
>> > https://kernel.org/doc/ols/2010/ols2010-pages-109-120.pdf
>> >
>>
>> --
>> Dominique Martinet | Asmadeus
^ permalink raw reply
* Re: [PATCH v2 1/4] cpufreq: Extract cpufreq_policy_init_qos() function
From: Zhongqiu Han @ 2026-05-19 13:51 UTC (permalink / raw)
To: Pierre Gondois, linux-kernel
Cc: Jie Zhan, Lifeng Zheng, Ionela Voinescu, Sumit Gupta,
Rafael J. Wysocki, Viresh Kumar, Jonathan Corbet, Shuah Khan,
Huang Rui, Mario Limonciello, Perry Yuan, K Prateek Nayak,
Srinivas Pandruvada, Len Brown, Saravana Kannan, linux-pm,
linux-doc, zhongqiu.han
In-Reply-To: <20260511135538.522653-2-pierre.gondois@arm.com>
On 5/11/2026 9:55 PM, Pierre Gondois wrote:
> Extract the QoS related logic from cpufreq_policy_online()
> to make the function shorter/simpler.
>
> The logic is placed in cpufreq_policy_init_qos() and is
> now executed right after the following calls:
> - cpufreq_driver->init()
> - cpufreq_table_validate_and_sort()
>
> This helps preparing following patches that will,
> in cpufreq_policy_init_qos():
> - treat the policy->min/max values set by drivers as QoS requests.
> - set a default policy->min/max value to all policies.
>
> No functional change.
>
> Signed-off-by: Pierre Gondois <pierre.gondois@arm.com>
Looks good to me apart from a minor nit inline.
Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> ---
> drivers/cpufreq/cpufreq.c | 53 +++++++++++++++++++++++----------------
> 1 file changed, 32 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
> index 44eb1b7e7fc1b..034603c2af325 100644
> --- a/drivers/cpufreq/cpufreq.c
> +++ b/drivers/cpufreq/cpufreq.c
> @@ -1397,6 +1397,32 @@ static void cpufreq_policy_free(struct cpufreq_policy *policy)
> kfree(policy);
> }
>
> +static int cpufreq_policy_init_qos(struct cpufreq_policy *policy)
> +{
> + int ret;
> +
> + if (policy->boost_supported) {
> + ret = freq_qos_add_request(&policy->constraints,
> + &policy->boost_freq_req,
> + FREQ_QOS_MAX,
> + policy->cpuinfo.max_freq);
> + if (ret < 0)
> + return ret;
> + }
> +
> + ret = freq_qos_add_request(&policy->constraints, &policy->min_freq_req,
> + FREQ_QOS_MIN, FREQ_QOS_MIN_DEFAULT_VALUE);
> + if (ret < 0)
> + return ret;
> +
> + ret = freq_qos_add_request(&policy->constraints, &policy->max_freq_req,
> + FREQ_QOS_MAX, FREQ_QOS_MAX_DEFAULT_VALUE);
> + if (ret < 0)
> + return ret;
> +
> + return ret;
Just minor nit: cpufreq_policy_init_qos() could perhaps return 0 on
success.
In the original inline code we only checked 'ret < 0', so positive
return values were not intended to propagate as part of the API
contract. Returning 'ret' here may expose a positive success code (e.g.
1) and make the helper easier to misuse (e.g. 'if (ret)' checks).
Returning 0 would keep the semantics unambiguous.
Alternatively, if this behavior is intentional, it might be helpful to
document it with a kdoc comment (e.g. that the function may return 0 or
1 on success and callers should check 'ret < 0' for errors).
> +}
> +
> static int cpufreq_policy_online(struct cpufreq_policy *policy,
> unsigned int cpu, bool new_policy)
> {
> @@ -1442,6 +1468,12 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> if (ret)
> goto out_offline_policy;
>
> + if (new_policy) {
> + ret = cpufreq_policy_init_qos(policy);
> + if (ret < 0)
> + goto out_offline_policy;
> + }
> +
> /* related_cpus should at least include policy->cpus. */
> cpumask_copy(policy->related_cpus, policy->cpus);
> }
> @@ -1458,27 +1490,6 @@ static int cpufreq_policy_online(struct cpufreq_policy *policy,
> add_cpu_dev_symlink(policy, j, get_cpu_device(j));
> }
>
> - if (policy->boost_supported) {
> - ret = freq_qos_add_request(&policy->constraints,
> - &policy->boost_freq_req,
> - FREQ_QOS_MAX,
> - policy->cpuinfo.max_freq);
> - if (ret < 0)
> - goto out_destroy_policy;
> - }
> -
> - ret = freq_qos_add_request(&policy->constraints,
> - &policy->min_freq_req, FREQ_QOS_MIN,
> - FREQ_QOS_MIN_DEFAULT_VALUE);
> - if (ret < 0)
> - goto out_destroy_policy;
> -
> - ret = freq_qos_add_request(&policy->constraints,
> - &policy->max_freq_req, FREQ_QOS_MAX,
> - FREQ_QOS_MAX_DEFAULT_VALUE);
> - if (ret < 0)
> - goto out_destroy_policy;
> -
> blocking_notifier_call_chain(&cpufreq_policy_notifier_list,
> CPUFREQ_CREATE_POLICY, policy);
> }
--
Thx and BRs,
Zhongqiu Han
^ permalink raw reply
* Re: [PATCH] tpm: tpm_tis: Add optional delay after relinquish
From: Jim Broadus @ 2026-05-19 13:38 UTC (permalink / raw)
To: linux-integrity, linux-kernel, linux-doc; +Cc: peterhuewe, jarkko, jgg
In-Reply-To: <20260519060926.103727-1-jbroadus@gmail.com>
I realize the delay should be moved to __tpm_tis_relinquish_locality.
I'll change that in a v2 patch.
On Mon, May 18, 2026 at 11:09 PM Jim Broadus <jbroadus@gmail.com> wrote:
>
> Some TPMs fail to grant locality when requested immediately after being
> relinquished. In this case, the TPM_ACCESS_REQUEST_USE bit of the
> TPM_ACCESS register is cleared immediately without setting
> TPM_ACCESS_ACTIVE_LOCALITY.
>
> This issue can be seen at boot since tpm_chip_start, called right
> after locality is relinquished, fails. This causes the probe to fail:
>
> tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -1
>
> This occurs on some older Dell Latitudes and maybe others. To work
> around this, add a "settle" boolean param to tpm_tis. When this is
> enabled, a delay is added after locality is relinquished.
>
> Signed-off-by: Jim Broadus <jbroadus@gmail.com>
> ---
> Documentation/admin-guide/kernel-parameters.txt | 7 +++++++
> drivers/char/tpm/tpm_tis.c | 7 +++++++
> drivers/char/tpm/tpm_tis_core.c | 3 +++
> drivers/char/tpm/tpm_tis_core.h | 1 +
> 4 files changed, 18 insertions(+)
>
> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
> index 4d0f545fb3ec..5b7111033fbb 100644
> --- a/Documentation/admin-guide/kernel-parameters.txt
> +++ b/Documentation/admin-guide/kernel-parameters.txt
> @@ -7651,6 +7651,13 @@ Kernel parameters
> defined by Trusted Computing Group (TCG) see
> https://trustedcomputinggroup.org/resource/pc-client-platform-tpm-profile-ptp-specification/
>
> + tpm_tis.settle= [HW,TPM]
> + Format: <bool>
> + When enabled, this adds a delay after locality is
> + relinquished. Some TPMs will fail to grant locality if
> + requested immediately after being relinquished. This
> + causes the probe to fail.
> +
> tp_printk [FTRACE]
> Have the tracepoints sent to printk as well as the
> tracing ring buffer. This is useful for early boot up
> diff --git a/drivers/char/tpm/tpm_tis.c b/drivers/char/tpm/tpm_tis.c
> index 9aa230a63616..8ac0ea78570e 100644
> --- a/drivers/char/tpm/tpm_tis.c
> +++ b/drivers/char/tpm/tpm_tis.c
> @@ -101,6 +101,10 @@ module_param(force, bool, 0444);
> MODULE_PARM_DESC(force, "Force device probe rather than using ACPI entry");
> #endif
>
> +static bool settle;
> +module_param(settle, bool, 0444);
> +MODULE_PARM_DESC(settle, "Add settle time after relinquish");
> +
> #if defined(CONFIG_PNP) && defined(CONFIG_ACPI)
> static int has_hid(struct acpi_device *dev, const char *hid)
> {
> @@ -242,6 +246,9 @@ static int tpm_tis_init(struct device *dev, struct tpm_info *tpm_info)
> if (itpm || is_itpm(ACPI_COMPANION(dev)))
> set_bit(TPM_TIS_ITPM_WORKAROUND, &phy->priv.flags);
>
> + if (settle)
> + set_bit(TPM_TIS_SETTLE_AFTER_RELINQUISH, &phy->priv.flags);
> +
> return tpm_tis_core_init(dev, &phy->priv, irq, &tpm_tcg,
> ACPI_HANDLE(dev));
> }
> diff --git a/drivers/char/tpm/tpm_tis_core.c b/drivers/char/tpm/tpm_tis_core.c
> index 21d79ad3b164..68be26fa5817 100644
> --- a/drivers/char/tpm/tpm_tis_core.c
> +++ b/drivers/char/tpm/tpm_tis_core.c
> @@ -184,6 +184,9 @@ static int tpm_tis_relinquish_locality(struct tpm_chip *chip, int l)
> __tpm_tis_relinquish_locality(priv, l);
> mutex_unlock(&priv->locality_count_mutex);
>
> + if (test_bit(TPM_TIS_SETTLE_AFTER_RELINQUISH, &priv->flags))
> + tpm_msleep(TPM_TIMEOUT);
> +
> return 0;
> }
>
> diff --git a/drivers/char/tpm/tpm_tis_core.h b/drivers/char/tpm/tpm_tis_core.h
> index 6c3aa480396b..413cac5e0f31 100644
> --- a/drivers/char/tpm/tpm_tis_core.h
> +++ b/drivers/char/tpm/tpm_tis_core.h
> @@ -90,6 +90,7 @@ enum tpm_tis_flags {
> TPM_TIS_DEFAULT_CANCELLATION = 2,
> TPM_TIS_IRQ_TESTED = 3,
> TPM_TIS_STATUS_VALID_RETRY = 4,
> + TPM_TIS_SETTLE_AFTER_RELINQUISH = 5,
> };
>
> struct tpm_tis_data {
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v6 03/11] dt-bindings: mfd: add documentation for S2MU005 PMIC
From: Krzysztof Kozlowski @ 2026-05-19 13:31 UTC (permalink / raw)
To: Kaustabh Chakraborty, Conor Dooley
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <DIMN3D9E8YCT.3T2PGAYYB2IOO@disroot.org>
On 19/05/2026 14:07, Kaustabh Chakraborty wrote:
>>>>
>>>> I don't think the compatible should be here, but I also don't want to
>>>> stall that patchset. I understand that it is inconsistent review from my
>>>> side, because other similar patchsets receive comment to drop the
>>>> compatible. But I don't think we will be fair asking to drop the
>>>> compatible now, when we did not ask for that in the early versions at all.
>>>
>>>
>>> I think you misunderstood, we were talking about the ordering of the
>>> properties in the binding file being alphanumerical, rather than the
>>> more typical approach of approximately following the order of
>>> dts-coding-style.
>>
>>
>> Ah, then I misunderstood and, even though it is a nit, I do care because
>> old code is then used for new patches. Bindings follow DTS rules, thus
>> should be:
>> 1. compatible
>> 2. reg
>> 3. core properties
>> 4. vendor properties
>>
>> Kaustabh, can you change it please?
>
> Ack, will do that in v8 then.
>
> While at it, do you also want me to drop the multi-led compatible string?
> So it would be:
Yes
>
> multi-led:
> $ref: /schemas/leds/leds-class-multicolor.yaml#
with "unevaluatedProperties: false"
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
From: Christian König @ 2026-05-19 13:28 UTC (permalink / raw)
To: Julian Orth
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sumit Semwal, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, dri-devel, linux-kernel,
linux-media, linaro-mm-sig, linux-doc, wayland-devel,
Michel Dänzer
In-Reply-To: <CAHijbEWHp960qvZFoK7+9ppHAqkAR7=UQhtMUccqWzGd_pFPQA@mail.gmail.com>
On 5/19/26 15:19, Julian Orth wrote:
> On Tue, May 19, 2026 at 10:18 AM Christian König
> <christian.koenig@amd.com> wrote:
>>
>> On 5/18/26 14:58, Julian Orth wrote:
>>> On Mon, May 18, 2026 at 2:41 PM Christian König
>>> <christian.koenig@amd.com> wrote:
>> ...
>>>> It could be that we have eventfd integration for that as well now, but in that case you could give the compositor an eventfd instead of a drm_syncobj fd in the first place.
>>>
>>> Yes, all compositors use the DRM_IOCTL_SYNCOBJ_EVENTFD ioctl to wait
>>> async for the timeline point to materialize and/or be signaled. The
>>> wayland protocol was the motivation for that ioctl.
>>>
>>>>
>>>> So as far as I can see using drm_syncobj for software rendering really doesn't make sense, eventfd is a much better fit for that use case.
>>>
>>> Using eventfd has some disadvantages:
>>>
>>> - We've just added syncobj support to vulkan:
>>> https://github.com/KhronosGroup/Vulkan-Docs/issues/2473#issuecomment-4446117280.
>>> For eventfd we would not only have to add yet another extension, that
>>> would realistically only be exposed by llvmpipe, but also every
>>> compositor and every client would have to support both extensions.
>>> - Similarly, a new wayland protocol would need to be designed to
>>> support sync over eventfd.
>>> - Eventfd does not support timeline semantics. Meaning that you would
>>> have to send two eventfds over the wire for each commit, one for the
>>> acquire point and one for the release point. Whereas with syncobj you
>>> only need to send two integers per commit.
>>>
>>> I don't see the advantage when drm_syncobj already does everything we need.
>>>
>>> You seem to believe that compositors would not be ready for this and
>>> from that perspective I can understand your apprehension. But I can
>>> assure you that compositors are already fully set up to support all of
>>> the usecases I've described: The wayland protocol requires the
>>> compositor to support wait before signal.
>> Yeah that's much better than I thought it would be.
>>
>> And that eventfds don't support timeline points is indeed a pretty good argument.
>>
>> But I still don't see much justification for creating a /dev/syncobj device, this is clearly something DRM specific.
>
> The justification is given in the cover letter. To repeat them briefly:
>
> 1. This series makes the ability to manipulate syncobjs available
> independently of attached hardware.
> 2. It makes it available under a consistent path /dev/syncobj.
Exactly that is a big no-go. This has to be under /dev/dri.
> 3. It removes the need to translate between syncobjs fds and handles.
That's a pretty big no-go as well. The differentiation between FDs and handles is completely intentional.
>
>>
>> What about using VGEM for this?
>
> If the vgem render node were made available unconditionally under,
Software rendering is a complete corner case, I don't think that this will be enabled by default.
Regards,
Christian.
> say, /dev/vgem and DRIVER_SYNCOBJ_TIMELINE were added to the driver,
> then maybe that could solve points 1 and 2 above.
>
> But it would not solve point 3 and it sounds like a hack to me to have
> a render node available outside of /dev/dri.
>
>>
>> Regards,
>> Christian.
>>
>>>
>>>>
>>>> Regards,
>>>> Christian.
^ permalink raw reply
* Re: [PATCH] Documentation: KVM: Document guest-visible compatibility expectations
From: David Woodhouse @ 2026-05-19 13:24 UTC (permalink / raw)
To: Marc Zyngier, Paolo Bonzini
Cc: Will Deacon, Jonathan Corbet, Shuah Khan, kvm,
Linux Doc Mailing List, Kernel Mailing List, Linux,
Sean Christopherson, Jim Mattson, Oliver Upton, Joey Gouly,
Suzuki K Poulose, Zenghui Yu, Catalin Marinas,
Raghavendra Rao Ananta, Eric Auger, Kees Cook, Arnd Bergmann,
Nathan Chancellor, linux-arm-kernel, kvmarm, linux-kselftest
In-Reply-To: <86pl2rwoat.wl-maz@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]
On Tue, 2026-05-19 at 13:56 +0100, Marc Zyngier wrote:
> On Tue, 19 May 2026 13:38:57 +0100,
> Marc Zyngier <maz@kernel.org> wrote:
> >
> > As I said before, I'd be OK with something that would restore IIDR to
> > REV1. But not something that actively breaks the GIC emulation by
> > reintroducing a bug. That's, by construction, dead code that will only
> > bitrot, because there is no SW that can make use of this nonsense.
>
> I will also add that if we make it a policy to preserve buggy
> behaviours that the guest cannot be relying on, then I question
> whether we should be fixing anything at all.
I think we just have a different understanding of what it practically
means to have behaviour "that the guest cannot be relying on", as in
the examples I just described for the IIDR issue.
> For example, 6.19 fixed a totally buggy behaviour where a guest
> couldn't not have more than (on most HW) 4 interrupts in flight at any
> given time. This was obviously totally bogus, and this was fixed
> unconditionally, as legitimate guests could experience gold-platted
> lock-ups.
And marked with a Fixes: tag and backported to stable, one presumes?
I'm confused that you think this is relevant. Can you contrive a
situation where a guest actually relied on this bug and *survived*,
like the situations I just explained for the IIDR issue?
You can nit-pick my hypotheticals as unlikely — and they are. But if we
always just YOLO it and change guest-visible behaviour on the basis
that it's "unlikely" to break anyone, and there are many such changes
in a given kernel deployment (e.g. from v6.6 to v6.18), then the
cumulative probability of being bitten by one of those "unlikely"
problems approaches 1.
There's a reason we do a *huge* amount of testing of what the guest
sees as we move from one kernel to the next, and back again, and
endeavour to eliminate all those differences.
And once the new kernel *is* deployed and won't be rolled back, of
course, all new launches can get the newer behaviour (and the latest
version of PSCI, etc...)
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
From: Julian Orth @ 2026-05-19 13:19 UTC (permalink / raw)
To: Christian König
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sumit Semwal, Jonathan Corbet, Shuah Khan,
Arnd Bergmann, Greg Kroah-Hartman, dri-devel, linux-kernel,
linux-media, linaro-mm-sig, linux-doc, wayland-devel,
Michel Dänzer
In-Reply-To: <38551bfe-75e1-4978-b57d-adc43cebc85e@amd.com>
On Tue, May 19, 2026 at 10:18 AM Christian König
<christian.koenig@amd.com> wrote:
>
> On 5/18/26 14:58, Julian Orth wrote:
> > On Mon, May 18, 2026 at 2:41 PM Christian König
> > <christian.koenig@amd.com> wrote:
> ...
> >> It could be that we have eventfd integration for that as well now, but in that case you could give the compositor an eventfd instead of a drm_syncobj fd in the first place.
> >
> > Yes, all compositors use the DRM_IOCTL_SYNCOBJ_EVENTFD ioctl to wait
> > async for the timeline point to materialize and/or be signaled. The
> > wayland protocol was the motivation for that ioctl.
> >
> >>
> >> So as far as I can see using drm_syncobj for software rendering really doesn't make sense, eventfd is a much better fit for that use case.
> >
> > Using eventfd has some disadvantages:
> >
> > - We've just added syncobj support to vulkan:
> > https://github.com/KhronosGroup/Vulkan-Docs/issues/2473#issuecomment-4446117280.
> > For eventfd we would not only have to add yet another extension, that
> > would realistically only be exposed by llvmpipe, but also every
> > compositor and every client would have to support both extensions.
> > - Similarly, a new wayland protocol would need to be designed to
> > support sync over eventfd.
> > - Eventfd does not support timeline semantics. Meaning that you would
> > have to send two eventfds over the wire for each commit, one for the
> > acquire point and one for the release point. Whereas with syncobj you
> > only need to send two integers per commit.
> >
> > I don't see the advantage when drm_syncobj already does everything we need.
> >
> > You seem to believe that compositors would not be ready for this and
> > from that perspective I can understand your apprehension. But I can
> > assure you that compositors are already fully set up to support all of
> > the usecases I've described: The wayland protocol requires the
> > compositor to support wait before signal.
> Yeah that's much better than I thought it would be.
>
> And that eventfds don't support timeline points is indeed a pretty good argument.
>
> But I still don't see much justification for creating a /dev/syncobj device, this is clearly something DRM specific.
The justification is given in the cover letter. To repeat them briefly:
1. This series makes the ability to manipulate syncobjs available
independently of attached hardware.
2. It makes it available under a consistent path /dev/syncobj.
3. It removes the need to translate between syncobjs fds and handles.
>
> What about using VGEM for this?
If the vgem render node were made available unconditionally under,
say, /dev/vgem and DRIVER_SYNCOBJ_TIMELINE were added to the driver,
then maybe that could solve points 1 and 2 above.
But it would not solve point 3 and it sounds like a hack to me to have
a render node available outside of /dev/dri.
>
> Regards,
> Christian.
>
> >
> >>
> >> Regards,
> >> Christian.
^ permalink raw reply
* [PATCH v17 14/14] crypto: qce - Communicate the base physical address to the dmaengine
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
In order to communicate to the BAM DMA engine which address should be
used as a scratchpad for dummy writes related to BAM pipe locking,
fill out and attach the provided metadata struct to the descriptor.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/crypto/qce/dma.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
index b66e6386fccda20d9462e70e51b8b485be85dec8..97b0f02c2b4d212f9e9ad41bbcb3a33e0b64835a 100644
--- a/drivers/crypto/qce/dma.c
+++ b/drivers/crypto/qce/dma.c
@@ -11,6 +11,7 @@
#include "core.h"
#include "dma.h"
+#include "regs-v5.h"
#define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
#define QCE_BAM_CMD_SGL_SIZE 128
@@ -43,6 +44,10 @@ void qce_clear_bam_transaction(struct qce_device *qce)
int qce_submit_cmd_desc(struct qce_device *qce)
{
+ struct bam_desc_metadata meta = {
+ .scratchpad_addr = qce->base_phys + REG_VERSION,
+ .direction = DMA_MEM_TO_DEV,
+ };
struct qce_desc_info *qce_desc = qce->dma.bam_txn->desc;
struct qce_bam_transaction *bam_txn = qce->dma.bam_txn;
struct dma_async_tx_descriptor *dma_desc;
@@ -63,6 +68,10 @@ int qce_submit_cmd_desc(struct qce_device *qce)
goto err_unmap_sg;
}
+ ret = dmaengine_desc_attach_metadata(dma_desc, &meta, 0);
+ if (ret)
+ goto err_unmap_sg;
+
qce_desc->dma_desc = dma_desc;
cookie = dmaengine_submit(qce_desc->dma_desc);
--
2.47.3
^ permalink raw reply related
* [PATCH v17 13/14] crypto: qce - Add BAM DMA support for crypto register I/O
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Switch to using BAM DMA for register I/O in addition to passing data. To
that end: provide the necessary infrastructure in the driver, modify the
ordering of operations as required and replace all direct register writes
with wrappers queueing DMA command descriptors.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/crypto/qce/aead.c | 10 ++--
drivers/crypto/qce/common.c | 20 ++++---
drivers/crypto/qce/core.h | 4 ++
drivers/crypto/qce/dma.c | 123 ++++++++++++++++++++++++++++++++++++++++--
drivers/crypto/qce/dma.h | 5 ++
drivers/crypto/qce/sha.c | 10 ++--
drivers/crypto/qce/skcipher.c | 10 ++--
7 files changed, 152 insertions(+), 30 deletions(-)
diff --git a/drivers/crypto/qce/aead.c b/drivers/crypto/qce/aead.c
index 03b8042da9a1b4aebdc775ad8ab912abc7b2383d..e271ecbcbb4a33c405fbec85c458cf1daa7e2c55 100644
--- a/drivers/crypto/qce/aead.c
+++ b/drivers/crypto/qce/aead.c
@@ -463,17 +463,17 @@ qce_aead_async_req_handle(struct crypto_async_request *async_req)
src_nents = dst_nents - 1;
}
- ret = qce_dma_prep_sgs(&qce->dma, rctx->src_sg, src_nents, rctx->dst_sg, dst_nents,
- qce_aead_done, async_req);
+ ret = qce_start(async_req, tmpl->crypto_alg_type);
if (ret)
goto error_unmap_src;
- qce_dma_issue_pending(&qce->dma);
-
- ret = qce_start(async_req, tmpl->crypto_alg_type);
+ ret = qce_dma_prep_sgs(&qce->dma, rctx->src_sg, src_nents, rctx->dst_sg, dst_nents,
+ qce_aead_done, async_req);
if (ret)
goto error_terminate;
+ qce_dma_issue_pending(&qce->dma);
+
return 0;
error_terminate:
diff --git a/drivers/crypto/qce/common.c b/drivers/crypto/qce/common.c
index 54a78a57f63028f01870a3edeb8e390f523bb190..37bb6f03244d317a887aeb0aa10cefe327b4ce05 100644
--- a/drivers/crypto/qce/common.c
+++ b/drivers/crypto/qce/common.c
@@ -25,7 +25,7 @@ static inline u32 qce_read(struct qce_device *qce, u32 offset)
static inline void qce_write(struct qce_device *qce, u32 offset, u32 val)
{
- writel(val, qce->base + offset);
+ qce_write_dma(qce, offset, val);
}
static inline void qce_write_array(struct qce_device *qce, u32 offset,
@@ -82,6 +82,8 @@ static void qce_setup_config(struct qce_device *qce)
{
u32 config;
+ qce_clear_bam_transaction(qce);
+
/* get big endianness */
config = qce_config_reg(qce, 0);
@@ -90,12 +92,14 @@ static void qce_setup_config(struct qce_device *qce)
qce_write(qce, REG_CONFIG, config);
}
-static inline void qce_crypto_go(struct qce_device *qce, bool result_dump)
+static inline int qce_crypto_go(struct qce_device *qce, bool result_dump)
{
if (result_dump)
qce_write(qce, REG_GOPROC, BIT(GO_SHIFT) | BIT(RESULTS_DUMP_SHIFT));
else
qce_write(qce, REG_GOPROC, BIT(GO_SHIFT));
+
+ return qce_submit_cmd_desc(qce);
}
#if defined(CONFIG_CRYPTO_DEV_QCE_SHA) || defined(CONFIG_CRYPTO_DEV_QCE_AEAD)
@@ -223,9 +227,7 @@ static int qce_setup_regs_ahash(struct crypto_async_request *async_req)
config = qce_config_reg(qce, 1);
qce_write(qce, REG_CONFIG, config);
- qce_crypto_go(qce, true);
-
- return 0;
+ return qce_crypto_go(qce, true);
}
#endif
@@ -386,9 +388,7 @@ static int qce_setup_regs_skcipher(struct crypto_async_request *async_req)
config = qce_config_reg(qce, 1);
qce_write(qce, REG_CONFIG, config);
- qce_crypto_go(qce, true);
-
- return 0;
+ return qce_crypto_go(qce, true);
}
#endif
@@ -535,9 +535,7 @@ static int qce_setup_regs_aead(struct crypto_async_request *async_req)
qce_write(qce, REG_CONFIG, config);
/* Start the process */
- qce_crypto_go(qce, !IS_CCM(flags));
-
- return 0;
+ return qce_crypto_go(qce, !IS_CCM(flags));
}
#endif
diff --git a/drivers/crypto/qce/core.h b/drivers/crypto/qce/core.h
index a80e12eac6c87e5321cce16c56a4bf5003474ef0..d238097f834e4605f3825f23d0316d4196439116 100644
--- a/drivers/crypto/qce/core.h
+++ b/drivers/crypto/qce/core.h
@@ -30,6 +30,8 @@
* @base_dma: base DMA address
* @base_phys: base physical address
* @dma_size: size of memory mapped for DMA
+ * @read_buf: Buffer for DMA to write back to
+ * @read_buf_dma: Mapped address of the read buffer
* @async_req_enqueue: invoked by every algorithm to enqueue a request
* @async_req_done: invoked by every algorithm to finish its request
*/
@@ -49,6 +51,8 @@ struct qce_device {
dma_addr_t base_dma;
phys_addr_t base_phys;
size_t dma_size;
+ __le32 *read_buf;
+ dma_addr_t read_buf_dma;
int (*async_req_enqueue)(struct qce_device *qce,
struct crypto_async_request *req);
void (*async_req_done)(struct qce_device *qce, int ret);
diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
index 3db46fc0c419a0a387abce93649084fbf4b1f128..b66e6386fccda20d9462e70e51b8b485be85dec8 100644
--- a/drivers/crypto/qce/dma.c
+++ b/drivers/crypto/qce/dma.c
@@ -4,6 +4,8 @@
*/
#include <linux/device.h>
+#include <linux/dma/qcom_bam_dma.h>
+#include <linux/dma-mapping.h>
#include <linux/dmaengine.h>
#include <crypto/scatterwalk.h>
@@ -11,6 +13,99 @@
#include "dma.h"
#define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
+#define QCE_BAM_CMD_SGL_SIZE 128
+#define QCE_BAM_CMD_ELEMENT_SIZE 128
+#define QCE_MAX_REG_READ 8
+
+struct qce_desc_info {
+ struct dma_async_tx_descriptor *dma_desc;
+ enum dma_data_direction dir;
+};
+
+struct qce_bam_transaction {
+ struct bam_cmd_element bam_ce[QCE_BAM_CMD_ELEMENT_SIZE];
+ struct scatterlist wr_sgl[QCE_BAM_CMD_SGL_SIZE];
+ struct qce_desc_info *desc;
+ u32 bam_ce_idx;
+ u32 pre_bam_ce_idx;
+ u32 wr_sgl_cnt;
+};
+
+void qce_clear_bam_transaction(struct qce_device *qce)
+{
+ struct qce_bam_transaction *bam_txn = qce->dma.bam_txn;
+
+ bam_txn->bam_ce_idx = 0;
+ bam_txn->wr_sgl_cnt = 0;
+ bam_txn->bam_ce_idx = 0;
+ bam_txn->pre_bam_ce_idx = 0;
+}
+
+int qce_submit_cmd_desc(struct qce_device *qce)
+{
+ struct qce_desc_info *qce_desc = qce->dma.bam_txn->desc;
+ struct qce_bam_transaction *bam_txn = qce->dma.bam_txn;
+ struct dma_async_tx_descriptor *dma_desc;
+ struct dma_chan *chan = qce->dma.rxchan;
+ unsigned long attrs = DMA_PREP_CMD;
+ dma_cookie_t cookie;
+ unsigned int mapped;
+ int ret;
+
+ mapped = dma_map_sg(qce->dev, bam_txn->wr_sgl, bam_txn->wr_sgl_cnt, DMA_TO_DEVICE);
+ if (!mapped)
+ return -ENOMEM;
+
+ dma_desc = dmaengine_prep_slave_sg(chan, bam_txn->wr_sgl, bam_txn->wr_sgl_cnt,
+ DMA_MEM_TO_DEV, attrs);
+ if (!dma_desc) {
+ ret = -ENOMEM;
+ goto err_unmap_sg;
+ }
+
+ qce_desc->dma_desc = dma_desc;
+ cookie = dmaengine_submit(qce_desc->dma_desc);
+
+ ret = dma_submit_error(cookie);
+ if (ret)
+ goto err_unmap_sg;
+
+ return 0;
+
+err_unmap_sg:
+ dma_unmap_sg(qce->dev, bam_txn->wr_sgl, bam_txn->wr_sgl_cnt, DMA_TO_DEVICE);
+ return ret;
+}
+
+static void qce_prep_dma_cmd_desc(struct qce_device *qce, struct qce_dma_data *dma,
+ unsigned int addr, void *buf)
+{
+ struct qce_bam_transaction *bam_txn = dma->bam_txn;
+ struct bam_cmd_element *bam_ce_buf;
+ int bam_ce_size, cnt, idx;
+
+ idx = bam_txn->bam_ce_idx;
+ bam_ce_buf = &bam_txn->bam_ce[idx];
+ bam_prep_ce_le32(bam_ce_buf, addr, BAM_WRITE_COMMAND, *((__le32 *)buf));
+
+ bam_ce_buf = &bam_txn->bam_ce[bam_txn->pre_bam_ce_idx];
+ bam_txn->bam_ce_idx++;
+ bam_ce_size = (bam_txn->bam_ce_idx - bam_txn->pre_bam_ce_idx) * sizeof(*bam_ce_buf);
+
+ cnt = bam_txn->wr_sgl_cnt;
+
+ sg_set_buf(&bam_txn->wr_sgl[cnt], bam_ce_buf, bam_ce_size);
+
+ ++bam_txn->wr_sgl_cnt;
+ bam_txn->pre_bam_ce_idx = bam_txn->bam_ce_idx;
+}
+
+void qce_write_dma(struct qce_device *qce, unsigned int offset, u32 val)
+{
+ unsigned int reg_addr = ((unsigned int)(qce->base_phys) + offset);
+
+ qce_prep_dma_cmd_desc(qce, &qce->dma, reg_addr, &val);
+}
int devm_qce_dma_request(struct qce_device *qce)
{
@@ -31,6 +126,21 @@ int devm_qce_dma_request(struct qce_device *qce)
return dev_err_probe(dev, PTR_ERR(dma->rxchan),
"Failed to get RX DMA channel\n");
+ dma->bam_txn = devm_kzalloc(dev, sizeof(*dma->bam_txn), GFP_KERNEL);
+ if (!dma->bam_txn)
+ return -ENOMEM;
+
+ dma->bam_txn->desc = devm_kzalloc(dev, sizeof(*dma->bam_txn->desc), GFP_KERNEL);
+ if (!dma->bam_txn->desc)
+ return -ENOMEM;
+
+ sg_init_table(dma->bam_txn->wr_sgl, QCE_BAM_CMD_SGL_SIZE);
+
+ qce->read_buf = dmam_alloc_coherent(qce->dev, QCE_MAX_REG_READ * sizeof(*qce->read_buf),
+ &qce->read_buf_dma, GFP_KERNEL);
+ if (!qce->read_buf)
+ return -ENOMEM;
+
return 0;
}
@@ -90,28 +200,33 @@ int qce_dma_prep_sgs(struct qce_dma_data *dma, struct scatterlist *rx_sg,
{
struct dma_chan *rxchan = dma->rxchan;
struct dma_chan *txchan = dma->txchan;
- unsigned long flags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK;
+ unsigned long txflags = DMA_PREP_INTERRUPT | DMA_CTRL_ACK;
+ unsigned long rxflags = txflags | DMA_PREP_FENCE;
int ret;
- ret = qce_dma_prep_sg(rxchan, rx_sg, rx_nents, flags, DMA_MEM_TO_DEV,
+ ret = qce_dma_prep_sg(rxchan, rx_sg, rx_nents, rxflags, DMA_MEM_TO_DEV,
NULL, NULL);
if (ret)
return ret;
- return qce_dma_prep_sg(txchan, tx_sg, tx_nents, flags, DMA_DEV_TO_MEM,
+ return qce_dma_prep_sg(txchan, tx_sg, tx_nents, txflags, DMA_DEV_TO_MEM,
cb, cb_param);
}
void qce_dma_issue_pending(struct qce_dma_data *dma)
{
- dma_async_issue_pending(dma->rxchan);
dma_async_issue_pending(dma->txchan);
+ dma_async_issue_pending(dma->rxchan);
}
int qce_dma_terminate_all(struct qce_dma_data *dma)
{
+ struct qce_device *qce = container_of(dma, struct qce_device, dma);
+ struct qce_bam_transaction *bam_txn = dma->bam_txn;
int ret;
+ dma_unmap_sg(qce->dev, bam_txn->wr_sgl, bam_txn->wr_sgl_cnt, DMA_TO_DEVICE);
+
ret = dmaengine_terminate_all(dma->rxchan);
return ret ?: dmaengine_terminate_all(dma->txchan);
}
diff --git a/drivers/crypto/qce/dma.h b/drivers/crypto/qce/dma.h
index 483789d9fa98e79d1283de8297bf2fc2a773f3a7..f05dfa9e6b25bd60e32f45079a8bc7e6a4cf81f9 100644
--- a/drivers/crypto/qce/dma.h
+++ b/drivers/crypto/qce/dma.h
@@ -8,6 +8,7 @@
#include <linux/dmaengine.h>
+struct qce_bam_transaction;
struct qce_device;
/* maximum data transfer block size between BAM and CE */
@@ -32,6 +33,7 @@ struct qce_dma_data {
struct dma_chan *txchan;
struct dma_chan *rxchan;
struct qce_result_dump *result_buf;
+ struct qce_bam_transaction *bam_txn;
};
int devm_qce_dma_request(struct qce_device *qce);
@@ -43,5 +45,8 @@ int qce_dma_terminate_all(struct qce_dma_data *dma);
struct scatterlist *
qce_sgtable_add(struct sg_table *sgt, struct scatterlist *sg_add,
unsigned int max_len);
+void qce_write_dma(struct qce_device *qce, unsigned int offset, u32 val);
+int qce_submit_cmd_desc(struct qce_device *qce);
+void qce_clear_bam_transaction(struct qce_device *qce);
#endif /* _DMA_H_ */
diff --git a/drivers/crypto/qce/sha.c b/drivers/crypto/qce/sha.c
index a3a1a205aaf8559a04809936e2a3b7d564c16c53..5be82b345753f49202797852cec09dbc7f0a1e03 100644
--- a/drivers/crypto/qce/sha.c
+++ b/drivers/crypto/qce/sha.c
@@ -109,17 +109,17 @@ static int qce_ahash_async_req_handle(struct crypto_async_request *async_req)
goto error_unmap_src;
}
- ret = qce_dma_prep_sgs(&qce->dma, req->src, rctx->src_nents,
- &rctx->result_sg, 1, qce_ahash_done, async_req);
+ ret = qce_start(async_req, tmpl->crypto_alg_type);
if (ret)
goto error_unmap_dst;
- qce_dma_issue_pending(&qce->dma);
-
- ret = qce_start(async_req, tmpl->crypto_alg_type);
+ ret = qce_dma_prep_sgs(&qce->dma, req->src, rctx->src_nents,
+ &rctx->result_sg, 1, qce_ahash_done, async_req);
if (ret)
goto error_terminate;
+ qce_dma_issue_pending(&qce->dma);
+
return 0;
error_terminate:
diff --git a/drivers/crypto/qce/skcipher.c b/drivers/crypto/qce/skcipher.c
index 1fef315a7105c869e7fc6a60719087b721e78bb3..6535336a2c57c39db94999011890b8bdad5c58c2 100644
--- a/drivers/crypto/qce/skcipher.c
+++ b/drivers/crypto/qce/skcipher.c
@@ -142,18 +142,18 @@ qce_skcipher_async_req_handle(struct crypto_async_request *async_req)
src_nents = dst_nents - 1;
}
+ ret = qce_start(async_req, tmpl->crypto_alg_type);
+ if (ret)
+ goto error_unmap_src;
+
ret = qce_dma_prep_sgs(&qce->dma, rctx->src_sg, src_nents,
rctx->dst_sg, dst_nents,
qce_skcipher_done, async_req);
if (ret)
- goto error_unmap_src;
+ goto error_terminate;
qce_dma_issue_pending(&qce->dma);
- ret = qce_start(async_req, tmpl->crypto_alg_type);
- if (ret)
- goto error_terminate;
-
return 0;
error_terminate:
--
2.47.3
^ permalink raw reply related
* [PATCH v17 12/14] crypto: qce - Map crypto memory for DMA
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
As the first step in converting the driver to using DMA for register
I/O, let's map the crypto memory range.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/crypto/qce/core.c | 23 ++++++++++++++++++++++-
drivers/crypto/qce/core.h | 6 ++++++
2 files changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
index 90f44db6606173d8afbd295a6dadea177b7bcd11..92e551f4570c0c69cbbbb709a0752fbc16c307e5 100644
--- a/drivers/crypto/qce/core.c
+++ b/drivers/crypto/qce/core.c
@@ -192,10 +192,19 @@ static void qce_cancel_work(void *data)
cancel_work_sync(work);
}
+static void qce_crypto_unmap_dma(void *data)
+{
+ struct qce_device *qce = data;
+
+ dma_unmap_resource(qce->dev, qce->base_dma, qce->dma_size,
+ DMA_BIDIRECTIONAL, 0);
+}
+
static int qce_crypto_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct qce_device *qce;
+ struct resource *res;
int ret;
qce = devm_kzalloc(dev, sizeof(*qce), GFP_KERNEL);
@@ -205,7 +214,7 @@ static int qce_crypto_probe(struct platform_device *pdev)
qce->dev = dev;
platform_set_drvdata(pdev, qce);
- qce->base = devm_platform_ioremap_resource(pdev, 0);
+ qce->base = devm_platform_get_and_ioremap_resource(pdev, 0, &res);
if (IS_ERR(qce->base))
return PTR_ERR(qce->base);
@@ -256,6 +265,18 @@ static int qce_crypto_probe(struct platform_device *pdev)
qce->async_req_enqueue = qce_async_request_enqueue;
qce->async_req_done = qce_async_request_done;
+ qce->dma_size = resource_size(res);
+ qce->base_dma = dma_map_resource(dev, res->start, qce->dma_size,
+ DMA_BIDIRECTIONAL, 0);
+ qce->base_phys = res->start;
+ ret = dma_mapping_error(dev, qce->base_dma);
+ if (ret)
+ return ret;
+
+ ret = devm_add_action_or_reset(qce->dev, qce_crypto_unmap_dma, qce);
+ if (ret)
+ return ret;
+
return devm_qce_register_algs(qce);
}
diff --git a/drivers/crypto/qce/core.h b/drivers/crypto/qce/core.h
index f092ce2d3b04a936a37805c20ac5ba78d8fdd2df..a80e12eac6c87e5321cce16c56a4bf5003474ef0 100644
--- a/drivers/crypto/qce/core.h
+++ b/drivers/crypto/qce/core.h
@@ -27,6 +27,9 @@
* @dma: pointer to dma data
* @burst_size: the crypto burst size
* @pipe_pair_id: which pipe pair id the device using
+ * @base_dma: base DMA address
+ * @base_phys: base physical address
+ * @dma_size: size of memory mapped for DMA
* @async_req_enqueue: invoked by every algorithm to enqueue a request
* @async_req_done: invoked by every algorithm to finish its request
*/
@@ -43,6 +46,9 @@ struct qce_device {
struct qce_dma_data dma;
int burst_size;
unsigned int pipe_pair_id;
+ dma_addr_t base_dma;
+ phys_addr_t base_phys;
+ size_t dma_size;
int (*async_req_enqueue)(struct qce_device *qce,
struct crypto_async_request *req);
void (*async_req_done)(struct qce_device *qce, int ret);
--
2.47.3
^ permalink raw reply related
* [PATCH v17 11/14] crypto: qce - Use existing devres APIs in devm_qce_dma_request()
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski,
Konrad Dybcio
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Switch to devm_kmalloc() and devm_dma_alloc_chan() in
devm_qce_dma_request(). This allows us to drop two labels and shrink the
function.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/crypto/qce/dma.c | 41 ++++++++++-------------------------------
1 file changed, 10 insertions(+), 31 deletions(-)
diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
index c29b0abe9445381a019e0447d30acfd7319d5c1f..3db46fc0c419a0a387abce93649084fbf4b1f128 100644
--- a/drivers/crypto/qce/dma.c
+++ b/drivers/crypto/qce/dma.c
@@ -12,47 +12,26 @@
#define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
-static void qce_dma_release(void *data)
-{
- struct qce_dma_data *dma = data;
-
- dma_release_channel(dma->txchan);
- dma_release_channel(dma->rxchan);
- kfree(dma->result_buf);
-}
-
int devm_qce_dma_request(struct qce_device *qce)
{
struct qce_dma_data *dma = &qce->dma;
struct device *dev = qce->dev;
- int ret;
- dma->txchan = dma_request_chan(dev, "tx");
+ dma->result_buf = devm_kmalloc(dev, QCE_RESULT_BUF_SZ + QCE_IGNORE_BUF_SZ, GFP_KERNEL);
+ if (!dma->result_buf)
+ return -ENOMEM;
+
+ dma->txchan = devm_dma_request_chan(dev, "tx");
if (IS_ERR(dma->txchan))
return dev_err_probe(dev, PTR_ERR(dma->txchan),
"Failed to get TX DMA channel\n");
- dma->rxchan = dma_request_chan(dev, "rx");
- if (IS_ERR(dma->rxchan)) {
- ret = dev_err_probe(dev, PTR_ERR(dma->rxchan),
- "Failed to get RX DMA channel\n");
- goto error_rx;
- }
-
- dma->result_buf = kmalloc(QCE_RESULT_BUF_SZ + QCE_IGNORE_BUF_SZ,
- GFP_KERNEL);
- if (!dma->result_buf) {
- ret = -ENOMEM;
- goto error_nomem;
- }
-
- return devm_add_action_or_reset(dev, qce_dma_release, dma);
+ dma->rxchan = devm_dma_request_chan(dev, "rx");
+ if (IS_ERR(dma->rxchan))
+ return dev_err_probe(dev, PTR_ERR(dma->rxchan),
+ "Failed to get RX DMA channel\n");
-error_nomem:
- dma_release_channel(dma->rxchan);
-error_rx:
- dma_release_channel(dma->txchan);
- return ret;
+ return 0;
}
struct scatterlist *
--
2.47.3
^ permalink raw reply related
* [PATCH v17 10/14] crypto: qce - Simplify arguments of devm_qce_dma_request()
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
This function can extract all the information it needs from struct
qce_device alone so simplify its arguments. This is done in preparation
for adding support for register I/O over DMA which will require
accessing even more fields from struct qce_device.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/crypto/qce/core.c | 2 +-
drivers/crypto/qce/dma.c | 5 ++++-
drivers/crypto/qce/dma.h | 4 +++-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
index 5f724db7c65930991218557394d99574418fb68c..90f44db6606173d8afbd295a6dadea177b7bcd11 100644
--- a/drivers/crypto/qce/core.c
+++ b/drivers/crypto/qce/core.c
@@ -233,7 +233,7 @@ static int qce_crypto_probe(struct platform_device *pdev)
if (ret)
return ret;
- ret = devm_qce_dma_request(qce->dev, &qce->dma);
+ ret = devm_qce_dma_request(qce);
if (ret)
return ret;
diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
index 08bf3e8ec12433c1a8ee17003f3487e41b7329e4..c29b0abe9445381a019e0447d30acfd7319d5c1f 100644
--- a/drivers/crypto/qce/dma.c
+++ b/drivers/crypto/qce/dma.c
@@ -7,6 +7,7 @@
#include <linux/dmaengine.h>
#include <crypto/scatterwalk.h>
+#include "core.h"
#include "dma.h"
#define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
@@ -20,8 +21,10 @@ static void qce_dma_release(void *data)
kfree(dma->result_buf);
}
-int devm_qce_dma_request(struct device *dev, struct qce_dma_data *dma)
+int devm_qce_dma_request(struct qce_device *qce)
{
+ struct qce_dma_data *dma = &qce->dma;
+ struct device *dev = qce->dev;
int ret;
dma->txchan = dma_request_chan(dev, "tx");
diff --git a/drivers/crypto/qce/dma.h b/drivers/crypto/qce/dma.h
index fc337c435cd14917bdfb99febcf9119275afdeba..483789d9fa98e79d1283de8297bf2fc2a773f3a7 100644
--- a/drivers/crypto/qce/dma.h
+++ b/drivers/crypto/qce/dma.h
@@ -8,6 +8,8 @@
#include <linux/dmaengine.h>
+struct qce_device;
+
/* maximum data transfer block size between BAM and CE */
#define QCE_BAM_BURST_SIZE 64
@@ -32,7 +34,7 @@ struct qce_dma_data {
struct qce_result_dump *result_buf;
};
-int devm_qce_dma_request(struct device *dev, struct qce_dma_data *dma);
+int devm_qce_dma_request(struct qce_device *qce);
int qce_dma_prep_sgs(struct qce_dma_data *dma, struct scatterlist *sg_in,
int in_ents, struct scatterlist *sg_out, int out_ents,
dma_async_tx_callback cb, void *cb_param);
--
2.47.3
^ permalink raw reply related
* [PATCH v17 09/14] crypto: qce - Remove unused ignore_buf
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
It's unclear what the purpose of this field is. It has been here since
the initial commit but without any explanation. The driver works fine
without it. We still keep allocating more space in the result buffer, we
just don't need to store its address. While at it: move the
QCE_IGNORE_BUF_SZ definition into dma.c as it's not used outside of this
compilation unit.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/crypto/qce/dma.c | 4 ++--
drivers/crypto/qce/dma.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/crypto/qce/dma.c b/drivers/crypto/qce/dma.c
index 68cafd4741ad3d91906d39e817fc7873b028d498..08bf3e8ec12433c1a8ee17003f3487e41b7329e4 100644
--- a/drivers/crypto/qce/dma.c
+++ b/drivers/crypto/qce/dma.c
@@ -9,6 +9,8 @@
#include "dma.h"
+#define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
+
static void qce_dma_release(void *data)
{
struct qce_dma_data *dma = data;
@@ -41,8 +43,6 @@ int devm_qce_dma_request(struct device *dev, struct qce_dma_data *dma)
goto error_nomem;
}
- dma->ignore_buf = dma->result_buf + QCE_RESULT_BUF_SZ;
-
return devm_add_action_or_reset(dev, qce_dma_release, dma);
error_nomem:
diff --git a/drivers/crypto/qce/dma.h b/drivers/crypto/qce/dma.h
index 31629185000e12242fa07c2cc08b95fcbd5d4b8c..fc337c435cd14917bdfb99febcf9119275afdeba 100644
--- a/drivers/crypto/qce/dma.h
+++ b/drivers/crypto/qce/dma.h
@@ -23,7 +23,6 @@ struct qce_result_dump {
u32 status2;
};
-#define QCE_IGNORE_BUF_SZ (2 * QCE_BAM_BURST_SIZE)
#define QCE_RESULT_BUF_SZ \
ALIGN(sizeof(struct qce_result_dump), QCE_BAM_BURST_SIZE)
@@ -31,7 +30,6 @@ struct qce_dma_data {
struct dma_chan *txchan;
struct dma_chan *rxchan;
struct qce_result_dump *result_buf;
- void *ignore_buf;
};
int devm_qce_dma_request(struct device *dev, struct qce_dma_data *dma);
--
2.47.3
^ permalink raw reply related
* [PATCH v17 08/14] crypto: qce - Include algapi.h in the core.h header
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
The header defines a struct embedding struct crypto_queue whose size
needs to be known and which is defined in crypto/algapi.h. Move the
inclusion from core.c to core.h.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/crypto/qce/core.c | 1 -
drivers/crypto/qce/core.h | 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
index e82fc862c74b20c34ea5abd6c0b98b71089a3fee..5f724db7c65930991218557394d99574418fb68c 100644
--- a/drivers/crypto/qce/core.c
+++ b/drivers/crypto/qce/core.c
@@ -13,7 +13,6 @@
#include <linux/mod_devicetable.h>
#include <linux/platform_device.h>
#include <linux/types.h>
-#include <crypto/algapi.h>
#include <crypto/internal/hash.h>
#include "core.h"
diff --git a/drivers/crypto/qce/core.h b/drivers/crypto/qce/core.h
index eb6fa7a8b64a81daf9ad5304a3ae4e5e597a70b8..f092ce2d3b04a936a37805c20ac5ba78d8fdd2df 100644
--- a/drivers/crypto/qce/core.h
+++ b/drivers/crypto/qce/core.h
@@ -8,6 +8,7 @@
#include <linux/mutex.h>
#include <linux/workqueue.h>
+#include <crypto/algapi.h>
#include "dma.h"
--
2.47.3
^ permalink raw reply related
* [PATCH v17 07/14] crypto: qce - Cancel work on device detach
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
The workqueue is setup in probe() but never cancelled on error or in
remove(). Set up a devres action to clean it up.
Fixes: eb7986e5e14d ("crypto: qce - convert tasklet to workqueue")
Closes: https://sashiko.dev/#/patchset/20260427-qcom-qce-cmd-descr-v16-0-945fd1cafbbc%40oss.qualcomm.com?part=7
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/crypto/qce/core.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/crypto/qce/core.c b/drivers/crypto/qce/core.c
index b966f3365b7de8d2a8f6707397a34aa4facdc4ac..e82fc862c74b20c34ea5abd6c0b98b71089a3fee 100644
--- a/drivers/crypto/qce/core.c
+++ b/drivers/crypto/qce/core.c
@@ -186,6 +186,13 @@ static int qce_check_version(struct qce_device *qce)
return 0;
}
+static void qce_cancel_work(void *data)
+{
+ struct work_struct *work = data;
+
+ cancel_work_sync(work);
+}
+
static int qce_crypto_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
@@ -240,6 +247,11 @@ static int qce_crypto_probe(struct platform_device *pdev)
return ret;
INIT_WORK(&qce->done_work, qce_req_done_work);
+
+ ret = devm_add_action_or_reset(dev, qce_cancel_work, &qce->done_work);
+ if (ret)
+ return ret;
+
crypto_init_queue(&qce->queue, QCE_QUEUE_LENGTH);
qce->async_req_enqueue = qce_async_request_enqueue;
--
2.47.3
^ permalink raw reply related
* [PATCH v17 06/14] dmaengine: qcom: bam_dma: add support for BAM locking
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
Add support for BAM pipe locking. To that end: when starting DMA on an RX
channel - prepend the existing queue of issued descriptors with an
additional "dummy" command descriptor with the LOCK bit set. Once the
transaction is done (no more issued descriptors), issue one more dummy
descriptor with the UNLOCK bit.
We *must* wait until the transaction is signalled as done because we
must not perform any writes into config registers while the engine is
busy.
The dummy writes must be issued into a scratchpad register of the client
so provide a mechanism to communicate the right address via descriptor
metadata.
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/dma/qcom/bam_dma.c | 156 ++++++++++++++++++++++++++++++++++++++-
include/linux/dma/qcom_bam_dma.h | 14 ++++
2 files changed, 166 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 30318cf01ee20b7e64a988e8ce1ec04dab55e3c3..2c9f90313c313851f84ebea8d99e73b37829b297 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -28,11 +28,13 @@
#include <linux/clk.h>
#include <linux/device.h>
#include <linux/dma-mapping.h>
+#include <linux/dma/qcom_bam_dma.h>
#include <linux/dmaengine.h>
#include <linux/init.h>
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/kernel.h>
+#include <linux/lockdep.h>
#include <linux/module.h>
#include <linux/of_address.h>
#include <linux/of_dma.h>
@@ -60,6 +62,8 @@ struct bam_desc_hw {
#define DESC_FLAG_EOB BIT(13)
#define DESC_FLAG_NWD BIT(12)
#define DESC_FLAG_CMD BIT(11)
+#define DESC_FLAG_LOCK BIT(10)
+#define DESC_FLAG_UNLOCK BIT(9)
struct bam_async_desc {
struct virt_dma_desc vd;
@@ -72,6 +76,10 @@ struct bam_async_desc {
struct bam_desc_hw *curr_desc;
+ /* BAM locking infrastructure */
+ struct scatterlist lock_sg;
+ struct bam_cmd_element lock_ce;
+
/* list node for the desc in the bam_chan list of descriptors */
struct list_head desc_node;
enum dma_transfer_direction dir;
@@ -391,6 +399,10 @@ struct bam_chan {
struct list_head desc_list;
struct list_head node;
+
+ /* BAM locking infrastructure */
+ phys_addr_t scratchpad_addr;
+ enum dma_transfer_direction direction;
};
static inline struct bam_chan *to_bam_chan(struct dma_chan *common)
@@ -652,6 +664,35 @@ static int bam_slave_config(struct dma_chan *chan,
return 0;
}
+static int bam_metadata_attach(struct dma_async_tx_descriptor *desc, void *data, size_t len)
+{
+ struct bam_chan *bchan = to_bam_chan(desc->chan);
+ const struct bam_device_data *bdata = bchan->bdev->dev_data;
+ struct bam_desc_metadata *metadata = data;
+
+ if (!data)
+ return -EINVAL;
+
+ if (!bdata->pipe_lock_supported)
+ /*
+ * The client wants to use locking but this BAM version doesn't
+ * support it. Don't return an error here as this will stop the
+ * client from using DMA at all for no reason.
+ */
+ return 0;
+
+ guard(spinlock_irqsave)(&bchan->vc.lock);
+
+ bchan->scratchpad_addr = metadata->scratchpad_addr;
+ bchan->direction = metadata->direction;
+
+ return 0;
+}
+
+static const struct dma_descriptor_metadata_ops bam_metadata_ops = {
+ .attach = bam_metadata_attach,
+};
+
/**
* bam_prep_slave_sg - Prep slave sg transaction
*
@@ -668,6 +709,7 @@ static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
void *context)
{
struct bam_chan *bchan = to_bam_chan(chan);
+ struct dma_async_tx_descriptor *tx_desc;
struct bam_device *bdev = bchan->bdev;
struct bam_async_desc *async_desc;
struct scatterlist *sg;
@@ -723,7 +765,12 @@ static struct dma_async_tx_descriptor *bam_prep_slave_sg(struct dma_chan *chan,
} while (remainder > 0);
}
- return vchan_tx_prep(&bchan->vc, &async_desc->vd, flags);
+ tx_desc = vchan_tx_prep(&bchan->vc, &async_desc->vd, flags);
+ if (!tx_desc)
+ return NULL;
+
+ tx_desc->metadata_ops = &bam_metadata_ops;
+ return tx_desc;
}
/**
@@ -1012,13 +1059,106 @@ static void bam_apply_new_config(struct bam_chan *bchan,
bchan->reconfigure = 0;
}
+static struct bam_async_desc *
+bam_make_lock_desc(struct bam_chan *bchan, unsigned long flag)
+{
+ struct dma_chan *chan = &bchan->vc.chan;
+ struct bam_async_desc *async_desc;
+ struct bam_desc_hw *desc;
+ struct virt_dma_desc *vd;
+ struct virt_dma_chan *vc;
+ unsigned int mapped;
+ dma_cookie_t cookie;
+ int ret;
+
+ async_desc = kzalloc_flex(*async_desc, desc, 1, GFP_NOWAIT);
+ if (!async_desc) {
+ dev_err(bchan->bdev->dev, "failed to allocate the BAM lock descriptor\n");
+ return ERR_PTR(-ENOMEM);
+ }
+
+ sg_init_table(&async_desc->lock_sg, 1);
+
+ async_desc->num_desc = 1;
+ async_desc->curr_desc = async_desc->desc;
+ async_desc->dir = DMA_MEM_TO_DEV;
+
+ desc = async_desc->desc;
+
+ bam_prep_ce_le32(&async_desc->lock_ce, bchan->scratchpad_addr, BAM_WRITE_COMMAND, 0);
+ sg_set_buf(&async_desc->lock_sg, &async_desc->lock_ce, sizeof(async_desc->lock_ce));
+
+ mapped = dma_map_sg_attrs(chan->slave, &async_desc->lock_sg,
+ 1, DMA_TO_DEVICE, DMA_PREP_CMD);
+ if (!mapped) {
+ kfree(async_desc);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ desc->flags |= cpu_to_le16(DESC_FLAG_CMD | flag);
+ desc->addr = sg_dma_address(&async_desc->lock_sg);
+ desc->size = sizeof(struct bam_cmd_element);
+
+ vc = &bchan->vc;
+ vd = &async_desc->vd;
+
+ dma_async_tx_descriptor_init(&vd->tx, &vc->chan);
+ vd->tx.flags = DMA_PREP_CMD;
+ vd->tx.desc_free = vchan_tx_desc_free;
+ vd->tx_result.result = DMA_TRANS_NOERROR;
+ vd->tx_result.residue = 0;
+
+ cookie = dma_cookie_assign(&vd->tx);
+ ret = dma_submit_error(cookie);
+ if (ret) {
+ dma_unmap_sg(chan->slave, &async_desc->lock_sg, 1, DMA_TO_DEVICE);
+ kfree(async_desc);
+ return ERR_PTR(ret);
+ }
+
+ return async_desc;
+}
+
+static int bam_do_setup_pipe_lock(struct bam_chan *bchan, bool lock)
+{
+ struct bam_device *bdev = bchan->bdev;
+ const struct bam_device_data *bdata = bdev->dev_data;
+ struct bam_async_desc *lock_desc;
+ unsigned long flag;
+
+ lockdep_assert_held(&bchan->vc.lock);
+
+ if (!bdata->pipe_lock_supported || !bchan->scratchpad_addr ||
+ bchan->direction != DMA_MEM_TO_DEV)
+ return 0;
+
+ flag = lock ? DESC_FLAG_LOCK : DESC_FLAG_UNLOCK;
+
+ lock_desc = bam_make_lock_desc(bchan, flag);
+ if (IS_ERR(lock_desc))
+ return PTR_ERR(lock_desc);
+
+ if (lock)
+ list_add(&lock_desc->vd.node, &bchan->vc.desc_issued);
+ else
+ list_add_tail(&lock_desc->vd.node, &bchan->vc.desc_issued);
+
+ return 0;
+}
+
+static void bam_setup_pipe_lock(struct bam_chan *bchan)
+{
+ if (bam_do_setup_pipe_lock(bchan, true) || bam_do_setup_pipe_lock(bchan, false))
+ dev_err(bchan->vc.chan.slave, "Failed to setup BAM pipe lock descriptors");
+}
+
/**
* bam_start_dma - start next transaction
* @bchan: bam dma channel
*/
static void bam_start_dma(struct bam_chan *bchan)
{
- struct virt_dma_desc *vd = vchan_next_desc(&bchan->vc);
+ struct virt_dma_desc *vd;
struct bam_device *bdev = bchan->bdev;
struct bam_async_desc *async_desc = NULL;
struct bam_desc_hw *desc;
@@ -1030,6 +1170,9 @@ static void bam_start_dma(struct bam_chan *bchan)
lockdep_assert_held(&bchan->vc.lock);
+ bam_setup_pipe_lock(bchan);
+
+ vd = vchan_next_desc(&bchan->vc);
if (!vd)
return;
@@ -1157,8 +1300,12 @@ static void bam_issue_pending(struct dma_chan *chan)
*/
static void bam_dma_free_desc(struct virt_dma_desc *vd)
{
- struct bam_async_desc *async_desc = container_of(vd,
- struct bam_async_desc, vd);
+ struct bam_async_desc *async_desc = container_of(vd, struct bam_async_desc, vd);
+ struct bam_desc_hw *desc = async_desc->desc;
+ struct dma_chan *chan = vd->tx.chan;
+
+ if (le16_to_cpu(desc->flags) & (DESC_FLAG_LOCK | DESC_FLAG_UNLOCK))
+ dma_unmap_sg(chan->slave, &async_desc->lock_sg, 1, DMA_TO_DEVICE);
kfree(async_desc);
}
@@ -1349,6 +1496,7 @@ static int bam_dma_probe(struct platform_device *pdev)
bdev->common.device_terminate_all = bam_dma_terminate_all;
bdev->common.device_issue_pending = bam_issue_pending;
bdev->common.device_tx_status = bam_tx_status;
+ bdev->common.desc_metadata_modes = DESC_METADATA_CLIENT;
bdev->common.dev = bdev->dev;
ret = dma_async_device_register(&bdev->common);
diff --git a/include/linux/dma/qcom_bam_dma.h b/include/linux/dma/qcom_bam_dma.h
index 68fc0e643b1b97fe4520d5878daa322b81f4f559..a2594264b0f58c4b2b1c85e243cad0d5669c26dc 100644
--- a/include/linux/dma/qcom_bam_dma.h
+++ b/include/linux/dma/qcom_bam_dma.h
@@ -6,6 +6,8 @@
#ifndef _QCOM_BAM_DMA_H
#define _QCOM_BAM_DMA_H
+#include <linux/dmaengine.h>
+
#include <asm/byteorder.h>
/*
@@ -34,6 +36,18 @@ enum bam_command_type {
BAM_READ_COMMAND,
};
+/**
+ * struct bam_desc_metadata - DMA descriptor metadata specific to the BAM driver.
+ *
+ * @scratchpad_addr: Physical address to use for dummy write operations when
+ * queuing command descriptors with LOCK/UNLOCK bits set.
+ * @direction: Transfer direction of this channel.
+ */
+struct bam_desc_metadata {
+ phys_addr_t scratchpad_addr;
+ enum dma_transfer_direction direction;
+};
+
/*
* prep_bam_ce_le32 - Wrapper function to prepare a single BAM command
* element with the data already in le32 format.
--
2.47.3
^ permalink raw reply related
* [PATCH v17 05/14] dmaengine: qcom: bam_dma: Add pipe_lock_supported flag support
From: Bartosz Golaszewski @ 2026-05-19 13:17 UTC (permalink / raw)
To: Vinod Koul, Jonathan Corbet, Thara Gopinath, Herbert Xu,
David S. Miller, Udit Tiwari, Md Sadre Alam, Dmitry Baryshkov,
Manivannan Sadhasivam, Stephan Gerhold, Bjorn Andersson,
Peter Ujfalusi, Michal Simek, Frank Li, Andy Gross,
Neil Armstrong
Cc: dmaengine, linux-doc, linux-kernel, linux-arm-msm, linux-crypto,
linux-arm-kernel, brgl, Bartosz Golaszewski, Bartosz Golaszewski,
Dmitry Baryshkov
In-Reply-To: <20260519-qcom-qce-cmd-descr-v17-0-53a595414b79@oss.qualcomm.com>
From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Extend the device match data with a flag indicating whether the IP
supports the BAM lock/unlock feature. Set it to true on BAM IP versions
1.4.0 and above.
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Acked-by: Manivannan Sadhasivam <mani@kernel.org>
Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>
Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
---
drivers/dma/qcom/bam_dma.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/dma/qcom/bam_dma.c b/drivers/dma/qcom/bam_dma.c
index 7f3d1b6dd5d7660d2743dafcc43878e5f7952b8d..30318cf01ee20b7e64a988e8ce1ec04dab55e3c3 100644
--- a/drivers/dma/qcom/bam_dma.c
+++ b/drivers/dma/qcom/bam_dma.c
@@ -115,6 +115,7 @@ struct reg_offset_data {
struct bam_device_data {
const struct reg_offset_data *reg_info;
+ bool pipe_lock_supported;
};
static const struct reg_offset_data bam_v1_3_reg_info[] = {
@@ -181,6 +182,7 @@ static const struct reg_offset_data bam_v1_4_reg_info[] = {
static const struct bam_device_data bam_v1_4_data = {
.reg_info = bam_v1_4_reg_info,
+ .pipe_lock_supported = true,
};
static const struct reg_offset_data bam_v1_7_reg_info[] = {
@@ -214,6 +216,7 @@ static const struct reg_offset_data bam_v1_7_reg_info[] = {
static const struct bam_device_data bam_v1_7_data = {
.reg_info = bam_v1_7_reg_info,
+ .pipe_lock_supported = true,
};
/* BAM CTRL */
--
2.47.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox