* 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] 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 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] 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] 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
* [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 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
* 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 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] 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: [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 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: [PATCH v2 1/6] io_uring/zcrx: add ctx pointer to zcrx
From: Vishwanath Seshagiri @ 2026-05-19 15:19 UTC (permalink / raw)
To: Clément Léger
Cc: io-uring, Pavel Begunkov, Jens Axboe, linux-doc, linux-kernel,
linux-kselftest, netdev, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan
In-Reply-To: <20260518153532.2835502-2-cleger@meta.com>
On Mon, May 18, 2026 at 8:36 AM Clément Léger <cleger@meta.com> wrote:
>
> From: Pavel Begunkov <asml.silence@gmail.com>
>
> zcrx will need to have a pointer to an owning ctx to communicate
> different events. Reference the ctx while it's attached to zcrx, and
> rely on zcrx termination to drop the ctx to avoid circular ref deps.
>
> Co-developed-by: Vishwanath Seshagiri <vishs@meta.com>
> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Vishwanath Seshagiri <vishs@meta.com>
> ---
> io_uring/zcrx.c | 39 +++++++++++++++++++++++++++++++--------
> io_uring/zcrx.h | 3 +++
> 2 files changed, 34 insertions(+), 8 deletions(-)
>
> diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c
> index 3f9632e7790a..34faf90423f4 100644
> --- a/io_uring/zcrx.c
> +++ b/io_uring/zcrx.c
> @@ -44,6 +44,17 @@ static inline struct io_zcrx_area *io_zcrx_iov_to_area(const struct net_iov *nio
> return container_of(owner, struct io_zcrx_area, nia);
> }
>
> +static bool zcrx_set_ring_ctx(struct io_zcrx_ifq *zcrx,
> + struct io_ring_ctx *ctx)
> +{
> + guard(spinlock_bh)(&zcrx->ctx_lock);
> + if (zcrx->master_ctx)
> + return false;
> + percpu_ref_get(&ctx->refs);
> + zcrx->master_ctx = ctx;
> + return true;
> +}
> +
> static inline struct page *io_zcrx_iov_page(const struct net_iov *niov)
> {
> struct io_zcrx_area *area = io_zcrx_iov_to_area(niov);
> @@ -531,6 +542,7 @@ static struct io_zcrx_ifq *io_zcrx_ifq_alloc(struct io_ring_ctx *ctx)
> return NULL;
>
> ifq->if_rxq = -1;
> + spin_lock_init(&ifq->ctx_lock);
> spin_lock_init(&ifq->rq.lock);
> mutex_init(&ifq->pp_lock);
> refcount_set(&ifq->refs, 1);
> @@ -580,6 +592,8 @@ static void io_zcrx_ifq_free(struct io_zcrx_ifq *ifq)
> return;
> if (WARN_ON_ONCE(ifq->netdev != NULL))
> return;
> + if (WARN_ON_ONCE(ifq->master_ctx))
> + return;
>
> if (ifq->area)
> io_zcrx_free_area(ifq, ifq->area);
> @@ -656,17 +670,24 @@ static void io_zcrx_scrub(struct io_zcrx_ifq *ifq)
> }
> }
>
> -static void zcrx_unregister_user(struct io_zcrx_ifq *ifq)
> +static void zcrx_unregister_user(struct io_zcrx_ifq *ifq, struct io_ring_ctx *ctx)
> {
> + scoped_guard(spinlock_bh, &ifq->ctx_lock) {
> + if (ctx && ifq->master_ctx == ctx) {
> + ifq->master_ctx = NULL;
> + percpu_ref_put(&ctx->refs);
> + }
> + }
> +
> if (refcount_dec_and_test(&ifq->user_refs)) {
> io_close_queue(ifq);
> io_zcrx_scrub(ifq);
> }
> }
>
> -static void zcrx_unregister(struct io_zcrx_ifq *ifq)
> +static void zcrx_unregister(struct io_zcrx_ifq *ifq, struct io_ring_ctx *ctx)
> {
> - zcrx_unregister_user(ifq);
> + zcrx_unregister_user(ifq, ctx);
> io_put_zcrx_ifq(ifq);
> }
>
> @@ -686,7 +707,7 @@ static int zcrx_box_release(struct inode *inode, struct file *file)
>
> if (WARN_ON_ONCE(!ifq))
> return -EFAULT;
> - zcrx_unregister(ifq);
> + zcrx_unregister(ifq, NULL);
> return 0;
> }
>
> @@ -711,7 +732,7 @@ static int zcrx_export(struct io_ring_ctx *ctx, struct io_zcrx_ifq *ifq,
> file = anon_inode_create_getfile("[zcrx]", &zcrx_box_fops,
> ifq, O_CLOEXEC, NULL);
> if (IS_ERR(file)) {
> - zcrx_unregister(ifq);
> + zcrx_unregister(ifq, NULL);
> return PTR_ERR(file);
> }
>
> @@ -787,7 +808,7 @@ static int import_zcrx(struct io_ring_ctx *ctx,
> scoped_guard(mutex, &ctx->mmap_lock)
> xa_erase(&ctx->zcrx_ctxs, id);
> err:
> - zcrx_unregister(ifq);
> + zcrx_unregister(ifq, ctx);
> return ret;
> }
>
> @@ -932,12 +953,14 @@ int io_register_zcrx(struct io_ring_ctx *ctx,
> ret = -EFAULT;
> goto err;
> }
> +
> + zcrx_set_ring_ctx(ifq, ctx);
> return 0;
> err:
> scoped_guard(mutex, &ctx->mmap_lock)
> xa_erase(&ctx->zcrx_ctxs, id);
> ifq_free:
> - zcrx_unregister(ifq);
> + zcrx_unregister(ifq, ctx);
> return ret;
> }
>
> @@ -967,7 +990,7 @@ void io_terminate_zcrx(struct io_ring_ctx *ctx)
> break;
> set_zcrx_entry_mark(ctx, id);
> id++;
> - zcrx_unregister_user(ifq);
> + zcrx_unregister_user(ifq, ctx);
> }
> }
>
> diff --git a/io_uring/zcrx.h b/io_uring/zcrx.h
> index 9e1a6a1b11e8..6b565d0bf6da 100644
> --- a/io_uring/zcrx.h
> +++ b/io_uring/zcrx.h
> @@ -73,6 +73,9 @@ struct io_zcrx_ifq {
> */
> struct mutex pp_lock;
> struct io_mapped_region rq_region;
> +
> + spinlock_t ctx_lock;
> + struct io_ring_ctx *master_ctx;
> };
>
> #if defined(CONFIG_IO_URING_ZCRX)
> --
> 2.53.0-Meta
>
^ permalink raw reply
* Re: [PATCH v2 2/6] io_uring/zcrx: notify user when out of buffers
From: Vishwanath Seshagiri @ 2026-05-19 15:21 UTC (permalink / raw)
To: Clément Léger
Cc: io-uring, Pavel Begunkov, Jens Axboe, linux-doc, linux-kernel,
linux-kselftest, netdev, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Vishwanath Seshagiri
In-Reply-To: <20260518153532.2835502-3-cleger@meta.com>
On Mon, May 18, 2026 at 8:36 AM Clément Léger <cleger@meta.com> wrote:
>
> From: Pavel Begunkov <asml.silence@gmail.com>
>
> There are currently no easy ways for the user to know if zcrx is out of
> buffers and page pool fails to allocate. Add uapi for zcrx to communicate
> it back.
>
> It's implemented as a separate CQE, which for now is posted to the creator
> ctx. To use it, on registration the user space needs to pass an instance
> of struct zcrx_notification_desc, which tells the kernel the user_data
> for resulting CQEs and which event types are expected / allowed.
>
> When an allowed event happens, zcrx will post a CQE containing the
> specified user_data, and lower bits of cqe->res will be set to the event
> mask. Before the kernel could post another notification of the given
> type, the user needs to acknowledge that it processed the previous one
> by issuing IORING_REGISTER_ZCRX_CTRL with ZCRX_CTRL_ARM_NOTIFICATION.
>
> The only notification type the patch implements is
> ZCRX_NOTIF_NO_BUFFERS, but we'll need more of them in the future.
>
> Co-developed-by: Vishwanath Seshagiri <vishs@meta.com>
> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com>
Signed-off-by: Vishwanath Seshagiri <vishs@meta.com>
> ---
> include/uapi/linux/io_uring/zcrx.h | 24 ++++++++-
> io_uring/io_uring.c | 2 +-
> io_uring/io_uring.h | 1 +
> io_uring/zcrx.c | 86 +++++++++++++++++++++++++++++-
> io_uring/zcrx.h | 7 ++-
> 5 files changed, 115 insertions(+), 5 deletions(-)
>
> diff --git a/include/uapi/linux/io_uring/zcrx.h b/include/uapi/linux/io_uring/zcrx.h
> index 5ce02c7a6096..67185566ad3c 100644
> --- a/include/uapi/linux/io_uring/zcrx.h
> +++ b/include/uapi/linux/io_uring/zcrx.h
> @@ -65,6 +65,20 @@ enum zcrx_features {
> * value in struct io_uring_zcrx_ifq_reg::rx_buf_len.
> */
> ZCRX_FEATURE_RX_PAGE_SIZE = 1 << 0,
> + ZCRX_FEATURE_NOTIFICATION = 1 << 1,
> +};
> +
> +enum zcrx_notification_type {
> + ZCRX_NOTIF_NO_BUFFERS,
> +
> + __ZCRX_NOTIF_TYPE_LAST,
> +};
> +
> +struct zcrx_notification_desc {
> + __u64 user_data;
> + __u32 type_mask;
> + __u32 __resv1;
> + __u64 __resv2[10];
> };
>
> /*
> @@ -82,12 +96,14 @@ struct io_uring_zcrx_ifq_reg {
> struct io_uring_zcrx_offsets offsets;
> __u32 zcrx_id;
> __u32 rx_buf_len;
> - __u64 __resv[3];
> + __u64 notif_desc; /* see struct zcrx_notification_desc */
> + __u64 __resv[2];
> };
>
> enum zcrx_ctrl_op {
> ZCRX_CTRL_FLUSH_RQ,
> ZCRX_CTRL_EXPORT,
> + ZCRX_CTRL_ARM_NOTIFICATION,
>
> __ZCRX_CTRL_LAST,
> };
> @@ -101,6 +117,11 @@ struct zcrx_ctrl_export {
> __u32 __resv1[11];
> };
>
> +struct zcrx_ctrl_arm_notif {
> + __u32 notif_type;
> + __u32 __resv[11];
> +};
> +
> struct zcrx_ctrl {
> __u32 zcrx_id;
> __u32 op; /* see enum zcrx_ctrl_op */
> @@ -109,6 +130,7 @@ struct zcrx_ctrl {
> union {
> struct zcrx_ctrl_export zc_export;
> struct zcrx_ctrl_flush_rq zc_flush;
> + struct zcrx_ctrl_arm_notif zc_arm_notif;
> };
> };
>
> diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
> index 2ebb0ba37c4f..c5972274cce1 100644
> --- a/io_uring/io_uring.c
> +++ b/io_uring/io_uring.c
> @@ -160,7 +160,7 @@ static void io_poison_cached_req(struct io_kiocb *req)
> req->apoll = IO_URING_PTR_POISON;
> }
>
> -static void io_poison_req(struct io_kiocb *req)
> +void io_poison_req(struct io_kiocb *req)
> {
> io_poison_cached_req(req);
> req->async_data = IO_URING_PTR_POISON;
> diff --git a/io_uring/io_uring.h b/io_uring/io_uring.h
> index e612a66ee80e..de0a3bed58d1 100644
> --- a/io_uring/io_uring.h
> +++ b/io_uring/io_uring.h
> @@ -213,6 +213,7 @@ bool __io_alloc_req_refill(struct io_ring_ctx *ctx);
>
> void io_activate_pollwq(struct io_ring_ctx *ctx);
> void io_restriction_clone(struct io_restriction *dst, struct io_restriction *src);
> +void io_poison_req(struct io_kiocb *req);
>
> static inline void io_lockdep_assert_cq_locked(struct io_ring_ctx *ctx)
> {
> diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c
> index 34faf90423f4..463fbaead35b 100644
> --- a/io_uring/zcrx.c
> +++ b/io_uring/zcrx.c
> @@ -768,6 +768,8 @@ static int import_zcrx(struct io_ring_ctx *ctx,
> return -EINVAL;
> if (reg->if_rxq || reg->rq_entries || reg->area_ptr || reg->region_ptr)
> return -EINVAL;
> + if (reg->notif_desc)
> + return -EINVAL;
> if (reg->flags & ~ZCRX_REG_IMPORT)
> return -EINVAL;
>
> @@ -856,6 +858,7 @@ static int zcrx_register_netdev(struct io_zcrx_ifq *ifq,
> int io_register_zcrx(struct io_ring_ctx *ctx,
> struct io_uring_zcrx_ifq_reg __user *arg)
> {
> + struct zcrx_notification_desc notif;
> struct io_uring_zcrx_area_reg area;
> struct io_uring_zcrx_ifq_reg reg;
> struct io_uring_region_desc rd;
> @@ -899,10 +902,22 @@ int io_register_zcrx(struct io_ring_ctx *ctx,
> if (copy_from_user(&area, u64_to_user_ptr(reg.area_ptr), sizeof(area)))
> return -EFAULT;
>
> + memset(¬if, 0, sizeof(notif));
> + if (reg.notif_desc && copy_from_user(¬if, u64_to_user_ptr(reg.notif_desc),
> + sizeof(notif)))
> + return -EFAULT;
> + if (notif.type_mask & ~ZCRX_NOTIF_TYPE_MASK)
> + return -EINVAL;
> + if (notif.__resv1 || !mem_is_zero(¬if.__resv2, sizeof(notif.__resv2)))
> + return -EINVAL;
> +
> ifq = io_zcrx_ifq_alloc(ctx);
> if (!ifq)
> return -ENOMEM;
>
> + ifq->notif_data = notif.user_data;
> + ifq->allowed_notif_mask = notif.type_mask;
> +
> if (ctx->user) {
> get_uid(ctx->user);
> ifq->user = ctx->user;
> @@ -954,7 +969,8 @@ int io_register_zcrx(struct io_ring_ctx *ctx,
> goto err;
> }
>
> - zcrx_set_ring_ctx(ifq, ctx);
> + if (notif.type_mask)
> + zcrx_set_ring_ctx(ifq, ctx);
> return 0;
> err:
> scoped_guard(mutex, &ctx->mmap_lock)
> @@ -1127,6 +1143,48 @@ static unsigned io_zcrx_refill_slow(struct page_pool *pp, struct io_zcrx_ifq *if
> return allocated;
> }
>
> +static void zcrx_notif_tw(struct io_tw_req tw_req, io_tw_token_t tw)
> +{
> + struct io_kiocb *req = tw_req.req;
> + struct io_ring_ctx *ctx = req->ctx;
> +
> + io_post_aux_cqe(ctx, req->cqe.user_data, req->cqe.res, 0);
> + percpu_ref_put(&ctx->refs);
> + io_poison_req(req);
> + kmem_cache_free(req_cachep, req);
> +}
> +
> +static void zcrx_send_notif(struct io_zcrx_ifq *ifq, unsigned type)
> +{
> + gfp_t gfp = GFP_ATOMIC | __GFP_NOWARN | __GFP_ZERO;
> + u32 type_mask = 1 << type;
> + struct io_kiocb *req;
> +
> + if (!(type_mask & ifq->allowed_notif_mask))
> + return;
> +
> + guard(spinlock_bh)(&ifq->ctx_lock);
> + if (!ifq->master_ctx)
> + return;
> + if (type_mask & ifq->fired_notifs)
> + return;
> +
> + req = kmem_cache_alloc(req_cachep, gfp);
> + if (unlikely(!req))
> + return;
> +
> + ifq->fired_notifs |= type_mask;
> +
> + req->opcode = IORING_OP_NOP;
> + req->cqe.user_data = ifq->notif_data;
> + req->cqe.res = type;
> + req->ctx = ifq->master_ctx;
> + percpu_ref_get(&req->ctx->refs);
> + req->tctx = NULL;
> + req->io_task_work.func = zcrx_notif_tw;
> + io_req_task_work_add(req);
> +}
> +
> static netmem_ref io_pp_zc_alloc_netmems(struct page_pool *pp, gfp_t gfp)
> {
> struct io_zcrx_ifq *ifq = io_pp_to_ifq(pp);
> @@ -1143,8 +1201,10 @@ static netmem_ref io_pp_zc_alloc_netmems(struct page_pool *pp, gfp_t gfp)
> goto out_return;
>
> allocated = io_zcrx_refill_slow(pp, ifq, netmems, to_alloc);
> - if (!allocated)
> + if (!allocated) {
> + zcrx_send_notif(ifq, ZCRX_NOTIF_NO_BUFFERS);
> return 0;
> + }
> out_return:
> zcrx_sync_for_device(pp, ifq, netmems, allocated);
> allocated--;
> @@ -1293,12 +1353,32 @@ static int zcrx_flush_rq(struct io_ring_ctx *ctx, struct io_zcrx_ifq *zcrx,
> return 0;
> }
>
> +static int zcrx_arm_notif(struct io_ring_ctx *ctx, struct io_zcrx_ifq *zcrx,
> + struct zcrx_ctrl *ctrl)
> +{
> + const struct zcrx_ctrl_arm_notif *an = &ctrl->zc_arm_notif;
> + unsigned type_mask;
> +
> + if (an->notif_type >= __ZCRX_NOTIF_TYPE_LAST)
> + return -EINVAL;
> + if (!mem_is_zero(&an->__resv, sizeof(an->__resv)))
> + return -EINVAL;
> +
> + guard(spinlock_bh)(&zcrx->ctx_lock);
> + type_mask = 1U << an->notif_type;
> + if (type_mask & ~zcrx->fired_notifs)
> + return -EINVAL;
> + zcrx->fired_notifs &= ~type_mask;
> + return 0;
> +}
> +
> int io_zcrx_ctrl(struct io_ring_ctx *ctx, void __user *arg, unsigned nr_args)
> {
> struct zcrx_ctrl ctrl;
> struct io_zcrx_ifq *zcrx;
>
> BUILD_BUG_ON(sizeof(ctrl.zc_export) != sizeof(ctrl.zc_flush));
> + BUILD_BUG_ON(sizeof(ctrl.zc_export) != sizeof(ctrl.zc_arm_notif));
>
> if (nr_args)
> return -EINVAL;
> @@ -1316,6 +1396,8 @@ int io_zcrx_ctrl(struct io_ring_ctx *ctx, void __user *arg, unsigned nr_args)
> return zcrx_flush_rq(ctx, zcrx, &ctrl);
> case ZCRX_CTRL_EXPORT:
> return zcrx_export(ctx, zcrx, &ctrl, arg);
> + case ZCRX_CTRL_ARM_NOTIFICATION:
> + return zcrx_arm_notif(ctx, zcrx, &ctrl);
> }
>
> return -EOPNOTSUPP;
> diff --git a/io_uring/zcrx.h b/io_uring/zcrx.h
> index 6b565d0bf6da..cca10d0d02ac 100644
> --- a/io_uring/zcrx.h
> +++ b/io_uring/zcrx.h
> @@ -9,7 +9,9 @@
> #include <net/net_trackers.h>
>
> #define ZCRX_SUPPORTED_REG_FLAGS (ZCRX_REG_IMPORT | ZCRX_REG_NODEV)
> -#define ZCRX_FEATURES (ZCRX_FEATURE_RX_PAGE_SIZE)
> +#define ZCRX_FEATURES (ZCRX_FEATURE_RX_PAGE_SIZE |\
> + ZCRX_FEATURE_NOTIFICATION)
> +#define ZCRX_NOTIF_TYPE_MASK (1U << ZCRX_NOTIF_NO_BUFFERS)
>
> struct io_zcrx_mem {
> unsigned long size;
> @@ -76,6 +78,9 @@ struct io_zcrx_ifq {
>
> spinlock_t ctx_lock;
> struct io_ring_ctx *master_ctx;
> + u32 allowed_notif_mask;
> + u32 fired_notifs;
> + u64 notif_data;
> };
>
> #if defined(CONFIG_IO_URING_ZCRX)
> --
> 2.53.0-Meta
>
^ permalink raw reply
* Re: [PATCH v2 0/2] arm64: Implement support for 2025 dpISA extensions
From: Will Deacon @ 2026-05-19 15:22 UTC (permalink / raw)
To: Catalin Marinas, Jonathan Corbet, Shuah Khan, Mark Brown
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-kernel,
linux-doc, linux-kselftest
In-Reply-To: <20260518-arm64-dpisa-2025-v2-0-b3367b73bd00@kernel.org>
On Mon, 18 May 2026 16:07:28 +0100, Mark Brown wrote:
> The 2025 dpISA extensions introduce a number of architecture features
> all of which are fairly straightforward from a kernel point of view
> since they only introduce new instructions, not any architecture state.
>
>
Applied selftest update to arm64 (for-next/selftests), thanks!
[2/2] kselftest/arm64: Add 2025 dpISA coverage to hwcaps
https://git.kernel.org/arm64/c/7da70f41da81
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2] arm64: errata: Reformat table for IDs
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: catalin.marinas, Robin Murphy
Cc: kernel-team, Will Deacon, linux-arm-kernel, linux-doc
In-Reply-To: <0d4c8f3968e5c5c0a6f3dc295c3e9f696b9006f4.1777657487.git.robin.murphy@arm.com>
On Fri, 01 May 2026 18:52:28 +0100, Robin Murphy wrote:
> We have some inconsistency where multiple errata for the same component
> share the same Kconfig workaround; some are one ID per line, some are
> smooshed together, and some are entirely separate entries. Standardise
> on the single entry, one ID per line format so that things render nice
> and consistently in the HTML docs, and it's simple and clear to add new
> IDs to existing workarounds without churning the table too much.
>
> [...]
I think I intended to send this upstream at -rc1, but it didn't happen.
However, we don't (yet) seem to have any new workarounds in linux-next
so I'll take it on its own branch for 7.2.
Applied to arm64 (for-next/errata), thanks!
[1/1] arm64: errata: Reformat table for IDs
https://git.kernel.org/arm64/c/ede94377d855
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v3 0/5] Support the FEAT_HDBSS introduced in Armv9.5
From: Will Deacon @ 2026-05-19 15:23 UTC (permalink / raw)
To: maz, oupton, catalin.marinas, corbet, pbonzini, Tian Zheng
Cc: kernel-team, Will Deacon, yuzenghui, wangzhou1, liuyonglong,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose, leo.bras,
Jonathan Cameron
In-Reply-To: <20260225040421.2683931-1-zhengtian10@huawei.com>
On Wed, 25 Feb 2026 12:04:16 +0800, Tian Zheng wrote:
> This series of patches add support to the Hardware Dirty state tracking
> Structure(HDBSS) feature, which is introduced by the ARM architecture
> in the DDI0601(ID121123) version.
>
> The HDBSS feature is an extension to the architecture that enhances
> tracking translation table descriptors' dirty state, identified as
> FEAT_HDBSS. This feature utilizes hardware assistance to achieve dirty
> page tracking, aiming to significantly reduce the overhead of scanning
> for dirty pages.
>
> [...]
Applied sysreg definitions to arm64 (for-next/sysregs), thanks!
[1/5] arm64/sysreg: Add HDBSS related register information
https://git.kernel.org/arm64/c/72f7be0c2e30
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH v2 1/2] arm64/cpufeature: Define hwcaps for 2025 dpISA features
From: Will Deacon @ 2026-05-19 15:24 UTC (permalink / raw)
To: Mark Brown
Cc: Catalin Marinas, Jonathan Corbet, Shuah Khan, linux-arm-kernel,
linux-kernel, linux-doc, linux-kselftest
In-Reply-To: <20260518-arm64-dpisa-2025-v2-1-b3367b73bd00@kernel.org>
On Mon, May 18, 2026 at 04:07:29PM +0100, Mark Brown wrote:
> The features added by the 2025 dpISA are all straightforward instruction
> only features so there is no state to manage, we can just expose hwcaps to
> let userspace know they are available.
>
> F16MM is slightly odd in that the feature is FEAT_F16MM but it is discovered
> via ID_AA64FPFR0_EL1.F16MM2. We follow the feature name.
>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> Documentation/arch/arm64/elf_hwcaps.rst | 24 ++++++++++++++++++++++++
> arch/arm64/include/uapi/asm/hwcap.h | 8 ++++++++
> arch/arm64/kernel/cpufeature.c | 11 +++++++++++
> arch/arm64/kernel/cpuinfo.c | 8 ++++++++
> 4 files changed, 51 insertions(+)
>
> diff --git a/Documentation/arch/arm64/elf_hwcaps.rst b/Documentation/arch/arm64/elf_hwcaps.rst
> index 97315ae6c0da..07ff9ea1d605 100644
> --- a/Documentation/arch/arm64/elf_hwcaps.rst
> +++ b/Documentation/arch/arm64/elf_hwcaps.rst
> @@ -451,6 +451,30 @@ HWCAP3_LS64
> of CPU. User should only use ld64b/st64b on supported target (device)
> memory location, otherwise fallback to the non-atomic alternatives.
>
> +HWCAP3_SVE_B16MM
> + Functionality implied by ID_AA64ZFR0_EL1.B16B16 == 0b0011
> +
> +HWCAP3_SVE2P3
> + Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0100
> +
> +HWCAP3_SME_LUT6
> + Functionality implied by ID_AA64SMFR0_EL1.LUT6 == 0b1
> +
> +HWCAP3_SME2P3
> + Functionality implied by ID_AA64SMFR0_EL1.SMEver == 0b0100
> +
> +HWCAP3_F16MM
> + Functionality implied by ID_AA64FPFR0_EL1.F16MM2 == 0b1
> +
> +HWCAP3_F16F32DOT
> + Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0010
> +
> +HWCAP3_F16F32MM
> + Functionality implied by ID_AA64ISAR0_EL1.FHM == 0b0011
> +
> +HWCAP3_SVE_LUT6
> + Functionality implied by ID_AA64ISAR2_EL1.LUT == 0b0010 and
> + ID_AA64PFR0_EL1.SVE == 0b0001.
I've queued this, but I'm curious why you've called out the
'ID_AA64PFR0_EL1.SVE == 0b0001' part here and not for any of the other
SVE caps you're adding? It's also formatted inconsistently from
pre-existing entries (such as HWCAP2_SVE_B16B16) which put the
ID_AA64PFR0_EL1.SVE part of the antecedent first.
Will
^ permalink raw reply
* Re: [PATCH v3 2/3] hwmon: raspberrypi: Add voltage input support
From: Florian Fainelli @ 2026-05-19 15:28 UTC (permalink / raw)
To: Shubham Chakraborty, Guenter Roeck, Jonathan Corbet
Cc: Shuah Khan, Broadcom internal kernel review list, Ray Jui,
Scott Branden, linux-hwmon, linux-doc, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260517080445.103962-3-chakrabortyshubham66@gmail.com>
On 5/17/26 01:04, Shubham Chakraborty wrote:
> Extend the raspberrypi-hwmon driver to expose firmware-provided
> voltage measurements through the hwmon subsystem.
>
> The driver now exports the following voltage inputs:
>
> - in0_input (core)
> - in1_input (sdram_c)
> - in2_input (sdram_i)
> - in3_input (sdram_p)
>
> Voltage values returned by firmware are converted from microvolts
> to millivolts as expected by the hwmon subsystem.
>
> Update the documentation related to it.
>
> The existing undervoltage sticky alarm handling is preserved and
> associated with the first voltage channel.
>
> Tested in -
> - Raspberry Pi 3b+ (Linux raspberrypi 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT
> Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux)
>
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v3 1/3] soc: bcm2835: raspberrypi-firmware: Add voltage domain IDs
From: Florian Fainelli @ 2026-05-19 15:29 UTC (permalink / raw)
To: Shubham Chakraborty, Guenter Roeck, Jonathan Corbet
Cc: Shuah Khan, Broadcom internal kernel review list, Ray Jui,
Scott Branden, linux-hwmon, linux-doc, linux-rpi-kernel,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260517080445.103962-2-chakrabortyshubham66@gmail.com>
On 5/17/26 01:04, Shubham Chakraborty wrote:
> Add Raspberry Pi firmware voltage domain identifiers for the mailbox
> property interface.
>
> Also add the voltage request structure used with
> RPI_FIRMWARE_GET_VOLTAGE so firmware clients can share the common API
> definition from the firmware header.
>
> Signed-off-by: Shubham Chakraborty <chakrabortyshubham66@gmail.com>
Acked-by: Florian Fainelli <florian.fainelli@broadcom.com>
--
Florian
^ permalink raw reply
* Re: [PATCH v3 0/5] Support the FEAT_HDBSS introduced in Armv9.5
From: Leonardo Bras @ 2026-05-19 15:35 UTC (permalink / raw)
To: Will Deacon
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
Tian Zheng, kernel-team, yuzenghui, wangzhou1, liuyonglong,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose, Jonathan Cameron
In-Reply-To: <177918656142.736362.17906576792384645789.b4-ty@kernel.org>
On Tue, May 19, 2026 at 04:23:12PM +0100, Will Deacon wrote:
> On Wed, 25 Feb 2026 12:04:16 +0800, Tian Zheng wrote:
> > This series of patches add support to the Hardware Dirty state tracking
> > Structure(HDBSS) feature, which is introduced by the ARM architecture
> > in the DDI0601(ID121123) version.
> >
> > The HDBSS feature is an extension to the architecture that enhances
> > tracking translation table descriptors' dirty state, identified as
> > FEAT_HDBSS. This feature utilizes hardware assistance to achieve dirty
> > page tracking, aiming to significantly reduce the overhead of scanning
> > for dirty pages.
> >
> > [...]
>
> Applied sysreg definitions to arm64 (for-next/sysregs), thanks!
>
> [1/5] arm64/sysreg: Add HDBSS related register information
> https://git.kernel.org/arm64/c/72f7be0c2e30
>
Thanks!
Leo
> Cheers,
> --
> Will
>
> https://fixes.arm64.dev
> https://next.arm64.dev
> https://will.arm64.dev
^ permalink raw reply
* Re: [PATCH 00/12] misc/syncobj: add /dev/syncobj device
From: Xaver Hugl @ 2026-05-19 15:31 UTC (permalink / raw)
To: Christian König
Cc: Julian Orth, 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: <5ee6d5af-ac48-41d7-a19f-e08a3c5b7d19@amd.com>
Am Di., 19. Mai 2026 um 15:29 Uhr schrieb Christian König
<christian.koenig@amd.com>:
> > 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.
FWIW udmabuf is also under /dev directly, but I don't think any
compositor developer would complain about a different path.
What are the rules for that? Could this simply be put in /dev/dri/syncobj?
The part where we get this independent of attached hardware is quite
important for us though, since we can't just ignore explicit sync once
the device we previously imported the syncobj into is disconnected.
Buffers can be from any device or allocated in system memory and
access should be synchronized properly in all cases.
How exactly it's made available isn't all that critical.
> > 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.
Could you expand on why it's needed? For compositors, the handle is
just an intermediary thing when translating between file descriptors.
FTR for me at least, this part would be merely nice to have, since it
slightly reduces the amount of ioctls a compositor needs to call, but
it's not important.
> >> 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.
That simply makes vgem unsuitable for solving the problems we face in
compositors.
- Xaver
^ permalink raw reply
* [PATCH v3 0/2] iio: dac: Add support for AD5529R DAC
From: Janani Sunil @ 2026-05-19 15:42 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan
Cc: linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
Janani Sunil
This patch series adds support for Analog Devices AD5529R, a 16 channel
16 and 12 bit voltage Digital-to-Analog Converter (DAC) with integrated
precision reference. The AD5529R operates from both unipolar and
bipolar supplies. The device communicates via SPI interface.
**Device Overview:**
The AD5529R features 16 independent DAC channels, with 16 or 12 bit
resolution, allowing independently programmable output ranges. The
internal 4.096V precision reference sets the accuracy of the output
voltage.
**Features Implemented:**
- Automatic detection of 12/16 bit variant with product ID read.
- Reset support via GPIO.
- Dual regmap configuration to handle 8 and 16 bit registers.
**Patch Summary:**
1. **dt-bindings**: Binding documentation with channel configuration.
2. **driver**: Implement IIO DAC Driver with regmap support.
**Testing:**
The driver was compiled and tested on the EVAL-AD5529R-ARDZ using a
coraZ7 with a mainline v7.0 kernel.
**Driver Rationale:**
AD5529R introduces:
1. A unique register layout
2. Mixed 8-bit and 16-bit register accesses
3. Product ID based generic identification
4. Hardware specific features like function generators, multi-die
hotpath registers etc.
The device warrants its own drivers due to these fundamental
architectural differences, that would require substantial changes to
existing drivers without providing reusable benefits. The standalone
driver also allows future extensions for related devices in the same
family.
Signed-off-by: Janani Sunil <janani.sunil@analog.com>
---
Changes in v3:
- Split into adi,ad5529r-16 and adi,ad5529r-12 device tree compatibles
- Add DT-based output range configuration via adi,output-range-microvolt
- Expand DT binding: vref-supply, clear/tg GPIOs, interrupts, muxout
- Correct power supply voltage specifications as per datasheet
- Reduce SPI frequency limit to 25MHz as per datasheet specs
- Switch to autoincrement addressing mode, remove +1 register offsets
- Use DT match data instead of device ID detection for fallback support
- Implement dynamic scale/offset calculation per configured channel range
- Added explicit val_format_endian and reg_stride for 16-bit regmap bus
- Code cleanup: alphabetical includes, ARRAY_SIZE(), unused defines
- Minor: .sign→.format field, simplify read/write order, optional hvss-supply
- Remove redundant driver documentation ad5529r.rst
- Link to v2: https://lore.kernel.org/r/20260508-ad5529r-driver-v2-0-e315441685d7@analog.com
Changes in v2:
- Fix IIO scale to use millivolts per ABI requirement
- Fix documentation voltage calculations (2.5V not 2.048V)
- Fix bipolar ranges in documentation (±5V, ±10V, ±15V, ±20V)
- Fix alphabetical ordering in documentation index
- Add missing newline to documentation file
- Fix scale units description (millivolts not microvolts)
- Include a section for driver rationale in the cover letter
- Reword contents in cover letter 12/16 bit generic->variant
- Add dependency array for spi-cpha and spi-cpol properties
- Link to v1: https://lore.kernel.org/r/20260507-ad5529r-driver-v1-0-b4460f3cb44f@analog.com
---
Janani Sunil (2):
dt-bindings: iio: dac: Add AD5529R
iio: dac: Add AD5529R DAC driver support
.../devicetree/bindings/iio/dac/adi,ad5529r.yaml | 217 +++++++++
MAINTAINERS | 8 +
drivers/iio/dac/Kconfig | 17 +
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/ad5529r.c | 527 +++++++++++++++++++++
5 files changed, 770 insertions(+)
---
base-commit: 93df88612859e8e19dec93c69d563b4b73e9bd4b
change-id: 20260507-ad5529r-driver-866bbdd864de
Best regards,
--
Janani Sunil <janani.sunil@analog.com>
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: iio: dac: Add AD5529R
From: Janani Sunil @ 2026-05-19 15:42 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan
Cc: linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
Janani Sunil
In-Reply-To: <20260519-ad5529r-driver-v3-0-267c0731aa68@analog.com>
Devicetree bindings for AD5529R 16 channel 12/16 bit high voltage,
buffered voltage output digital-to-analog converter (DAC) with an
integrated precision reference.
Signed-off-by: Janani Sunil <janani.sunil@analog.com>
---
.../devicetree/bindings/iio/dac/adi,ad5529r.yaml | 217 +++++++++++++++++++++
MAINTAINERS | 7 +
2 files changed, 224 insertions(+)
diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
new file mode 100644
index 000000000000..eb66f6ca063d
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
@@ -0,0 +1,217 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/iio/dac/adi,ad5529r.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices AD5529R 16-Channel 12/16-bit High Voltage DAC
+
+maintainers:
+ - Janani Sunil <janani.sunil@analog.com>
+
+description: |
+ The AD5529R is a 16-channel, 12-bit or 16-bit, high voltage, buffered voltage output
+ digital-to-analog converter (DAC) with an integrated precision reference.
+ The device operates from unipolar and bipolar supplies. It is guaranteed
+ monotonic and has built-in rail-to-rail output buffers that can source or
+ sink up to 25mA.
+
+ Specifications:
+ * 16 independent 12-bit or 16-bit DAC channels
+ * Independently programmable output ranges: 0V to 5V, 0V to 10V, 0V to 20V,
+ 0V to 40V, ±5V, ±10V, ±15V, and ±20V
+ * The device supports SPI communication with Mode 0 and Mode 3.
+ * 4.096V precision reference, 12ppm/°C maximum
+ * Built-in function generation: Toggle, Sinusoidal Dither, and Ramp waveforms
+ * Multiplexer for output voltage, load current sense and die temperature
+
+ Datasheet: https://www.analog.com/media/en/technical-documentation/data-sheets/ad5529r.pdf
+
+properties:
+ compatible:
+ enum:
+ - adi,ad5529r-16 # 16-bit variant
+ - adi,ad5529r-12 # 12-bit variant
+
+ reg:
+ maxItems: 1
+
+ spi-max-frequency:
+ maximum: 25000000
+ description:
+ Maximum SPI frequency. The device supports SPI Mode 0 and Mode 3.
+ Read operations are limited to 25MHz maximum.
+
+ reset-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the RESET pin. Active low. When asserted low,
+ performs a power-on reset and initializes the device to its default state.
+
+ clear-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the CLEAR pin. Active low. When asserted low,
+ clears all DAC data registers without affecting configuration settings.
+
+ interrupts:
+ maxItems: 1
+ description:
+ Interrupt connected to the ALARM pin. Active low interrupt output
+ for overtemperature conditions, SPI CRC errors, and function completion.
+
+ tg0-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the TG0 toggle pin. Pulsing this pin allows all
+ selected DACs to be updated synchronously for coordinated output changes.
+
+ tg1-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the TG1 toggle pin. Pulsing this pin allows all
+ selected DACs to be updated synchronously for coordinated output changes.
+
+ tg2-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the TG2 toggle pin. Pulsing this pin allows all
+ selected DACs to be updated synchronously for coordinated output changes.
+
+ tg3-gpios:
+ maxItems: 1
+ description:
+ GPIO connected to the TG3 toggle pin. Pulsing this pin allows all
+ selected DACs to be updated synchronously for coordinated output changes.
+
+ io-channels:
+ maxItems: 1
+ description:
+ ADC channel connected to the MUXOUT pin for monitoring output voltage,
+ load current sense, and die temperature.
+
+ io-channel-names:
+ const: muxout
+
+ vdd-supply:
+ description: Digital power supply (1.08V to 1.98V)
+
+ avdd-supply:
+ description: Analog power supply (4.75V to 5.25V)
+
+ hvdd-supply:
+ description:
+ High voltage positive supply (7V to 45V). Supply voltage should be chosen
+ based on configured output ranges (see datasheet Table 9).
+
+ hvss-supply:
+ description:
+ High voltage negative supply (-22.5V to 0V). Required only when using bipolar
+ output ranges (±5V, ±10V, ±15V, ±20V). Supply voltage should be
+ chosen based on configured output ranges (see datasheet Table 9).
+
+ vref-supply:
+ description:
+ External voltage reference supply (4.056V to 4.136V, typically 4.096V).
+ When specified, the device uses external reference mode and the VREF pin becomes an
+ input. The device uses the internal 4.096V precision reference otherwise.
+
+ "#address-cells":
+ const: 1
+
+ "#size-cells":
+ const: 0
+
+patternProperties:
+ "^channel@([0-9]|1[0-5])$":
+ type: object
+ description: Child nodes for individual channel configuration
+
+ properties:
+ reg:
+ description: Channel number.
+ minimum: 0
+ maximum: 15
+
+ adi,output-range-microvolt:
+ description: |
+ Output voltage range for this channel as [min, max] in microvolts.
+ If not specified, defaults to 0V to 5V range.
+ oneOf:
+ - items:
+ - const: 0
+ - enum: [5000000, 10000000, 20000000, 40000000]
+ - items:
+ - const: -5000000
+ - const: 5000000
+ - items:
+ - const: -10000000
+ - const: 10000000
+ - items:
+ - const: -15000000
+ - const: 15000000
+ - items:
+ - const: -20000000
+ - const: 20000000
+
+ required:
+ - reg
+
+ additionalProperties: false
+
+required:
+ - compatible
+ - reg
+ - vdd-supply
+ - avdd-supply
+ - hvdd-supply
+
+dependencies:
+ spi-cpha: [ spi-cpol ]
+ spi-cpol: [ spi-cpha ]
+
+allOf:
+ - $ref: /schemas/spi/spi-peripheral-props.yaml#
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/gpio/gpio.h>
+
+ spi {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ dac@0 {
+ compatible = "adi,ad5529r-16";
+ reg = <0>;
+ spi-max-frequency = <25000000>;
+
+ vdd-supply = <&vdd_regulator>;
+ avdd-supply = <&avdd_regulator>;
+ hvdd-supply = <&hvdd_regulator>;
+ hvss-supply = <&hvss_regulator>;
+
+ reset-gpios = <&gpio0 87 GPIO_ACTIVE_LOW>;
+
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ channel@0 {
+ reg = <0>;
+ adi,output-range-microvolt = <0 5000000>;
+ };
+
+ channel@1 {
+ reg = <1>;
+ adi,output-range-microvolt = <(-10000000) 10000000>;
+ };
+
+ channel@2 {
+ reg = <2>;
+ adi,output-range-microvolt = <0 40000000>;
+ };
+ };
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index d6c3c7d22403..320e84765ce6 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1507,6 +1507,13 @@ W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/adc/adi,ad4851.yaml
F: drivers/iio/adc/ad4851.c
+ANALOG DEVICES INC AD5529R DRIVER
+M: Janani Sunil <janani.sunil@analog.com>
+L: linux-iio@vger.kernel.org
+S: Supported
+W: https://ez.analog.com/linux-software-drivers
+F: Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
+
ANALOG DEVICES INC AD5706R DRIVER
M: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
L: linux-iio@vger.kernel.org
--
2.43.0
^ permalink raw reply related
* [PATCH v3 2/2] iio: dac: Add AD5529R DAC driver support
From: Janani Sunil @ 2026-05-19 15:42 UTC (permalink / raw)
To: Lars-Peter Clausen, Michael Hennerich, Jonathan Cameron,
David Lechner, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Philipp Zabel, Jonathan Corbet,
Shuah Khan
Cc: linux-iio, devicetree, linux-kernel, linux-doc, Janani Sunil,
Janani Sunil
In-Reply-To: <20260519-ad5529r-driver-v3-0-267c0731aa68@analog.com>
Add support for AD5529R 16-channel, 12/16 bit Digital to Analog Converter
Signed-off-by: Janani Sunil <janani.sunil@analog.com>
---
MAINTAINERS | 1 +
drivers/iio/dac/Kconfig | 17 ++
drivers/iio/dac/Makefile | 1 +
drivers/iio/dac/ad5529r.c | 527 ++++++++++++++++++++++++++++++++++++++++++++++
4 files changed, 546 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 320e84765ce6..143714e27d51 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1513,6 +1513,7 @@ L: linux-iio@vger.kernel.org
S: Supported
W: https://ez.analog.com/linux-software-drivers
F: Documentation/devicetree/bindings/iio/dac/adi,ad5529r.yaml
+F: drivers/iio/dac/ad5529r.c
ANALOG DEVICES INC AD5706R DRIVER
M: Alexis Czezar Torreno <alexisczezar.torreno@analog.com>
diff --git a/drivers/iio/dac/Kconfig b/drivers/iio/dac/Kconfig
index 657c68e75542..bb1d59889a2a 100644
--- a/drivers/iio/dac/Kconfig
+++ b/drivers/iio/dac/Kconfig
@@ -134,6 +134,23 @@ config AD5449
To compile this driver as a module, choose M here: the
module will be called ad5449.
+config AD5529R
+ tristate "Analog Devices AD5529R High Voltage DAC driver"
+ depends on SPI_MASTER
+ select REGMAP_SPI
+ help
+ Say yes here to build support for Analog Devices AD5529R
+ 16-Channel, 12-Bit/16-Bit, 40V High Voltage Precision Digital to Analog
+ Converter.
+
+ The device features multiple output voltage ranges from -20V to +20V,
+ built-in 4.096V voltage reference, and digital functions including
+ toggle, dither, and ramp modes. Supports both 12-bit and 16-bit
+ resolution variants.
+
+ To compile this driver as a module, choose M here: the
+ module will be called ad5529r.
+
config AD5592R_BASE
tristate
diff --git a/drivers/iio/dac/Makefile b/drivers/iio/dac/Makefile
index 003431798498..f35e060b3643 100644
--- a/drivers/iio/dac/Makefile
+++ b/drivers/iio/dac/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_AD5446) += ad5446.o
obj-$(CONFIG_AD5446_SPI) += ad5446-spi.o
obj-$(CONFIG_AD5446_I2C) += ad5446-i2c.o
obj-$(CONFIG_AD5449) += ad5449.o
+obj-$(CONFIG_AD5529R) += ad5529r.o
obj-$(CONFIG_AD5592R_BASE) += ad5592r-base.o
obj-$(CONFIG_AD5592R) += ad5592r.o
obj-$(CONFIG_AD5593R) += ad5593r.o
diff --git a/drivers/iio/dac/ad5529r.c b/drivers/iio/dac/ad5529r.c
new file mode 100644
index 000000000000..9bb63030db95
--- /dev/null
+++ b/drivers/iio/dac/ad5529r.c
@@ -0,0 +1,527 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * AD5529R Digital-to-Analog Converter Driver
+ * 16-Channel, 12/16-Bit, 40V High Voltage Precision DAC
+ *
+ * Copyright 2026 Analog Devices Inc.
+ * Author: Janani Sunil <janani.sunil@analog.com>
+ */
+
+#include <linux/array_size.h>
+#include <linux/bits.h>
+#include <linux/delay.h>
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/errno.h>
+#include <linux/iio/iio.h>
+#include <linux/mod_devicetable.h>
+#include <linux/module.h>
+#include <linux/property.h>
+#include <linux/regmap.h>
+#include <linux/regulator/consumer.h>
+#include <linux/reset.h>
+#include <linux/spi/spi.h>
+
+#define AD5529R_REG_INTERFACE_CONFIG_A 0x00
+#define AD5529R_REG_DEVICE_CONFIG 0x02
+#define AD5529R_REG_CHIP_GRADE 0x06
+#define AD5529R_REG_SCRATCH_PAD 0x0A
+#define AD5529R_REG_SPI_REVISION 0x0B
+#define AD5529R_REG_VENDOR_H 0x0D
+#define AD5529R_REG_STREAM_MODE 0x0E
+#define AD5529R_REG_INTERFACE_STATUS_A 0x11
+#define AD5529R_REG_MULTI_DAC_CH_SEL 0x14
+#define AD5529R_REG_OUT_RANGE_BASE 0x3C
+#define AD5529R_REG_OUT_RANGE(ch) (AD5529R_REG_OUT_RANGE_BASE + (ch) * 2)
+#define AD5529R_REG_DAC_INPUT_A_BASE 0x148
+#define AD5529R_REG_DAC_INPUT_A(ch) (AD5529R_REG_DAC_INPUT_A_BASE + (ch) * 2)
+#define AD5529R_REG_DAC_DATA_READBACK_BASE 0x16A
+#define AD5529R_REG_TSENS_ALERT_FLAG 0x18C
+#define AD5529R_REG_TSENS_SHTD_FLAG 0x18E
+#define AD5529R_REG_FUNC_BUSY 0x1A0
+#define AD5529R_REG_REF_SEL 0x1A2
+#define AD5529R_REG_INIT_CRC_ERR_STAT 0x1A4
+#define AD5529R_REG_MULTI_DAC_HOTPATH_SW_LDAC 0x1A8
+
+#define AD5529R_INTERFACE_CONFIG_A_SW_RESET (BIT(7) | BIT(0))
+#define AD5529R_INTERFACE_CONFIG_A_ADDR_ASCENSION BIT(5)
+#define AD5529R_INTERFACE_CONFIG_A_SDO_ENABLE BIT(4)
+#define AD5529R_REF_SEL_MASK BIT(0)
+#define AD5529R_MAX_REGISTER 0x232
+#define AD5529R_8BIT_REG_MAX 0x13
+#define AD5529R_SPI_READ_FLAG 0x80
+
+struct ad5529r_model_data {
+ const char *model_name;
+ unsigned int resolution;
+ const struct iio_chan_spec *channels;
+ unsigned int num_channels;
+};
+
+#define AD5529R_DAC_CHANNEL(chan, bits) { \
+ .type = IIO_VOLTAGE, \
+ .indexed = 1, \
+ .output = 1, \
+ .channel = (chan), \
+ .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | \
+ BIT(IIO_CHAN_INFO_SCALE) | \
+ BIT(IIO_CHAN_INFO_OFFSET), \
+ .scan_type = { \
+ .format = 'u', \
+ .realbits = (bits), \
+ .storagebits = 16, \
+ }, \
+}
+
+static const char * const ad5529r_supply_names[] = {
+ "vdd",
+ "avdd",
+ "hvdd",
+};
+
+static const struct iio_chan_spec ad5529r_channels_16bit[] = {
+ AD5529R_DAC_CHANNEL(0, 16),
+ AD5529R_DAC_CHANNEL(1, 16),
+ AD5529R_DAC_CHANNEL(2, 16),
+ AD5529R_DAC_CHANNEL(3, 16),
+ AD5529R_DAC_CHANNEL(4, 16),
+ AD5529R_DAC_CHANNEL(5, 16),
+ AD5529R_DAC_CHANNEL(6, 16),
+ AD5529R_DAC_CHANNEL(7, 16),
+ AD5529R_DAC_CHANNEL(8, 16),
+ AD5529R_DAC_CHANNEL(9, 16),
+ AD5529R_DAC_CHANNEL(10, 16),
+ AD5529R_DAC_CHANNEL(11, 16),
+ AD5529R_DAC_CHANNEL(12, 16),
+ AD5529R_DAC_CHANNEL(13, 16),
+ AD5529R_DAC_CHANNEL(14, 16),
+ AD5529R_DAC_CHANNEL(15, 16),
+};
+
+static const struct iio_chan_spec ad5529r_channels_12bit[] = {
+ AD5529R_DAC_CHANNEL(0, 12),
+ AD5529R_DAC_CHANNEL(1, 12),
+ AD5529R_DAC_CHANNEL(2, 12),
+ AD5529R_DAC_CHANNEL(3, 12),
+ AD5529R_DAC_CHANNEL(4, 12),
+ AD5529R_DAC_CHANNEL(5, 12),
+ AD5529R_DAC_CHANNEL(6, 12),
+ AD5529R_DAC_CHANNEL(7, 12),
+ AD5529R_DAC_CHANNEL(8, 12),
+ AD5529R_DAC_CHANNEL(9, 12),
+ AD5529R_DAC_CHANNEL(10, 12),
+ AD5529R_DAC_CHANNEL(11, 12),
+ AD5529R_DAC_CHANNEL(12, 12),
+ AD5529R_DAC_CHANNEL(13, 12),
+ AD5529R_DAC_CHANNEL(14, 12),
+ AD5529R_DAC_CHANNEL(15, 12),
+};
+
+static const struct ad5529r_model_data ad5529r_16bit_model_data = {
+ .model_name = "ad5529r-16",
+ .resolution = 16,
+ .channels = ad5529r_channels_16bit,
+ .num_channels = ARRAY_SIZE(ad5529r_channels_16bit),
+};
+
+static const struct ad5529r_model_data ad5529r_12bit_model_data = {
+ .model_name = "ad5529r-12",
+ .resolution = 12,
+ .channels = ad5529r_channels_12bit,
+ .num_channels = ARRAY_SIZE(ad5529r_channels_12bit),
+};
+
+enum ad5529r_output_range {
+ AD5529R_RANGE_0V_5V,
+ AD5529R_RANGE_0V_10V,
+ AD5529R_RANGE_0V_20V,
+ AD5529R_RANGE_0V_40V,
+ AD5529R_RANGE_NEG5V_5V,
+ AD5529R_RANGE_NEG10V_10V,
+ AD5529R_RANGE_NEG15V_15V,
+ AD5529R_RANGE_NEG20V_20V,
+};
+
+static const s32 ad5529r_output_ranges_mv[8][2] = {
+ [AD5529R_RANGE_0V_5V] = { 0, 5000 },
+ [AD5529R_RANGE_0V_10V] = { 0, 10000 },
+ [AD5529R_RANGE_0V_20V] = { 0, 20000 },
+ [AD5529R_RANGE_0V_40V] = { 0, 40000 },
+ [AD5529R_RANGE_NEG5V_5V] = { -5000, 5000 },
+ [AD5529R_RANGE_NEG10V_10V] = { -10000, 10000 },
+ [AD5529R_RANGE_NEG15V_15V] = { -15000, 15000 },
+ [AD5529R_RANGE_NEG20V_20V] = { -20000, 20000 },
+};
+
+struct ad5529r_state {
+ struct spi_device *spi;
+ const struct ad5529r_model_data *model_data;
+ struct regmap *regmap_8bit;
+ struct regmap *regmap_16bit;
+ struct regulator *vref_regulator;
+ enum ad5529r_output_range output_range_idx[16];
+};
+
+static const struct regmap_range ad5529r_8bit_readable_ranges[] = {
+ regmap_reg_range(AD5529R_REG_INTERFACE_CONFIG_A, AD5529R_REG_CHIP_GRADE),
+ regmap_reg_range(AD5529R_REG_SCRATCH_PAD, AD5529R_REG_VENDOR_H),
+ regmap_reg_range(AD5529R_REG_STREAM_MODE, AD5529R_REG_INTERFACE_STATUS_A),
+};
+
+static const struct regmap_range ad5529r_16bit_readable_ranges[] = {
+ regmap_reg_range(AD5529R_REG_MULTI_DAC_CH_SEL, AD5529R_REG_INIT_CRC_ERR_STAT),
+ regmap_reg_range(AD5529R_REG_MULTI_DAC_HOTPATH_SW_LDAC, AD5529R_MAX_REGISTER),
+};
+
+static const struct regmap_access_table ad5529r_8bit_readable_table = {
+ .yes_ranges = ad5529r_8bit_readable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(ad5529r_8bit_readable_ranges),
+};
+
+static const struct regmap_access_table ad5529r_16bit_readable_table = {
+ .yes_ranges = ad5529r_16bit_readable_ranges,
+ .n_yes_ranges = ARRAY_SIZE(ad5529r_16bit_readable_ranges),
+};
+
+static const struct regmap_range ad5529r_8bit_read_only_ranges[] = {
+ regmap_reg_range(AD5529R_REG_DEVICE_CONFIG, AD5529R_REG_CHIP_GRADE),
+ regmap_reg_range(AD5529R_REG_SPI_REVISION, AD5529R_REG_VENDOR_H),
+};
+
+static const struct regmap_range ad5529r_16bit_read_only_ranges[] = {
+ regmap_reg_range(AD5529R_REG_DAC_DATA_READBACK_BASE,
+ (AD5529R_REG_DAC_DATA_READBACK_BASE + 15 * 2)),
+ regmap_reg_range(AD5529R_REG_TSENS_ALERT_FLAG, AD5529R_REG_TSENS_SHTD_FLAG),
+ regmap_reg_range(AD5529R_REG_FUNC_BUSY, AD5529R_REG_FUNC_BUSY),
+ regmap_reg_range(AD5529R_REG_INIT_CRC_ERR_STAT, AD5529R_REG_INIT_CRC_ERR_STAT),
+};
+
+static const struct regmap_access_table ad5529r_8bit_writeable_table = {
+ .no_ranges = ad5529r_8bit_read_only_ranges,
+ .n_no_ranges = ARRAY_SIZE(ad5529r_8bit_read_only_ranges),
+};
+
+static const struct regmap_access_table ad5529r_16bit_writeable_table = {
+ .no_ranges = ad5529r_16bit_read_only_ranges,
+ .n_no_ranges = ARRAY_SIZE(ad5529r_16bit_read_only_ranges),
+};
+
+static const struct regmap_config ad5529r_regmap_8bit_config = {
+ .name = "ad5529r-8bit",
+ .reg_bits = 16,
+ .val_bits = 8,
+ .max_register = AD5529R_8BIT_REG_MAX,
+ .read_flag_mask = AD5529R_SPI_READ_FLAG,
+ .rd_table = &ad5529r_8bit_readable_table,
+ .wr_table = &ad5529r_8bit_writeable_table,
+};
+
+static const struct regmap_config ad5529r_regmap_16bit_config = {
+ .name = "ad5529r-16bit",
+ .reg_bits = 16,
+ .val_bits = 16,
+ .max_register = AD5529R_MAX_REGISTER,
+ .read_flag_mask = AD5529R_SPI_READ_FLAG,
+ .val_format_endian = REGMAP_ENDIAN_LITTLE,
+ .rd_table = &ad5529r_16bit_readable_table,
+ .wr_table = &ad5529r_16bit_writeable_table,
+ .reg_stride = 2,
+};
+
+static struct regmap *ad5529r_get_regmap(struct ad5529r_state *st,
+ unsigned int reg)
+{
+ if (reg <= AD5529R_8BIT_REG_MAX)
+ return st->regmap_8bit;
+
+ return st->regmap_16bit;
+}
+
+static int ad5529r_reset(struct ad5529r_state *st)
+{
+ struct reset_control *rst;
+ int ret;
+
+ rst = devm_reset_control_get_optional_exclusive(&st->spi->dev, NULL);
+ if (IS_ERR(rst))
+ return PTR_ERR(rst);
+
+ if (rst) {
+ ret = reset_control_deassert(rst);
+ if (ret)
+ return ret;
+ } else {
+ ret = regmap_write(st->regmap_8bit, AD5529R_REG_INTERFACE_CONFIG_A,
+ AD5529R_INTERFACE_CONFIG_A_SW_RESET);
+ if (ret)
+ return ret;
+ }
+
+ fsleep(10000);
+
+ return regmap_write(st->regmap_8bit, AD5529R_REG_INTERFACE_CONFIG_A,
+ AD5529R_INTERFACE_CONFIG_A_SDO_ENABLE |
+ AD5529R_INTERFACE_CONFIG_A_ADDR_ASCENSION);
+}
+
+static int ad5529r_read_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int *val, int *val2, long mask)
+{
+ struct ad5529r_state *st = iio_priv(indio_dev);
+ unsigned int reg_addr, reg_val_h;
+ int ret, range_idx, span_mv;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ reg_addr = AD5529R_REG_DAC_INPUT_A(chan->channel);
+ ret = regmap_read(st->regmap_16bit, reg_addr, ®_val_h);
+ if (ret)
+ return ret;
+
+ *val = reg_val_h;
+
+ return IIO_VAL_INT;
+ case IIO_CHAN_INFO_SCALE:
+ range_idx = st->output_range_idx[chan->channel];
+
+ span_mv = ad5529r_output_ranges_mv[range_idx][1] -
+ ad5529r_output_ranges_mv[range_idx][0];
+ *val = span_mv;
+ *val2 = st->model_data->resolution;
+
+ return IIO_VAL_FRACTIONAL_LOG2;
+ case IIO_CHAN_INFO_OFFSET:
+ range_idx = st->output_range_idx[chan->channel];
+
+ if (ad5529r_output_ranges_mv[range_idx][0] < 0)
+ *val = -(1 << (st->model_data->resolution - 1));
+ else
+ *val = 0;
+
+ return IIO_VAL_INT;
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ad5529r_write_raw(struct iio_dev *indio_dev,
+ struct iio_chan_spec const *chan,
+ int val, int val2, long mask)
+{
+ struct ad5529r_state *st = iio_priv(indio_dev);
+ unsigned int reg_addr;
+
+ switch (mask) {
+ case IIO_CHAN_INFO_RAW:
+ if (val < 0 || val > GENMASK(st->model_data->resolution - 1, 0))
+ return -EINVAL;
+
+ reg_addr = AD5529R_REG_DAC_INPUT_A(chan->channel);
+
+ return regmap_write(st->regmap_16bit, reg_addr, val);
+ default:
+ return -EINVAL;
+ }
+}
+
+static int ad5529r_find_output_range(const s32 *vals)
+{
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(ad5529r_output_ranges_mv); i++) {
+ if (vals[0] == ad5529r_output_ranges_mv[i][0] * 1000 &&
+ vals[1] == ad5529r_output_ranges_mv[i][1] * 1000)
+ return i;
+ }
+
+ return -EINVAL;
+}
+
+static int ad5529r_parse_channel_ranges(struct device *dev,
+ struct ad5529r_state *st)
+{
+ int ret, ch, range_idx;
+ s32 vals[2];
+
+ device_for_each_child_node_scoped(dev, child) {
+ range_idx = AD5529R_RANGE_0V_5V;
+
+ ret = fwnode_property_read_u32(child, "reg", &ch);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Missing reg property in channel node\n");
+
+ if (ch >= 16)
+ return dev_err_probe(dev, -EINVAL,
+ "Invalid channel number: %d\n", ch);
+
+ if (!fwnode_property_read_u32_array(child,
+ "adi,output-range-microvolt",
+ vals, 2)) {
+ range_idx = ad5529r_find_output_range(vals);
+ if (range_idx < 0)
+ return dev_err_probe(dev, range_idx,
+ "Invalid range [%d %d] for ch %d\n",
+ vals[0], vals[1], ch);
+ }
+
+ st->output_range_idx[ch] = range_idx;
+ ret = regmap_write(st->regmap_16bit,
+ AD5529R_REG_OUT_RANGE(ch), range_idx);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to configure range for ch %d\n",
+ ch);
+ }
+
+ return 0;
+}
+
+static int ad5529r_debugfs_reg_read(struct ad5529r_state *st, unsigned int reg,
+ unsigned int *val)
+{
+ return regmap_read(ad5529r_get_regmap(st, reg), reg, val);
+}
+
+static int ad5529r_debugfs_reg_write(struct ad5529r_state *st, unsigned int reg,
+ unsigned int val)
+{
+ return regmap_write(ad5529r_get_regmap(st, reg), reg, val);
+}
+
+static int ad5529r_reg_access(struct iio_dev *indio_dev,
+ unsigned int reg,
+ unsigned int writeval,
+ unsigned int *readval)
+{
+ struct ad5529r_state *st = iio_priv(indio_dev);
+
+ if (readval)
+ return ad5529r_debugfs_reg_read(st, reg, readval);
+
+ return ad5529r_debugfs_reg_write(st, reg, writeval);
+}
+
+static void ad5529r_disable_regulator(void *regulator)
+{
+ regulator_disable(regulator);
+}
+
+static const struct iio_info ad5529r_info = {
+ .read_raw = ad5529r_read_raw,
+ .write_raw = ad5529r_write_raw,
+ .debugfs_reg_access = ad5529r_reg_access,
+};
+
+static int ad5529r_probe(struct spi_device *spi)
+{
+ struct device *dev = &spi->dev;
+ struct iio_dev *indio_dev;
+ struct ad5529r_state *st;
+ int ret;
+
+ indio_dev = devm_iio_device_alloc(dev, sizeof(*st));
+ if (!indio_dev)
+ return -ENOMEM;
+
+ st = iio_priv(indio_dev);
+
+ st->spi = spi;
+
+ st->model_data = spi_get_device_match_data(spi);
+ if (!st->model_data)
+ return dev_err_probe(dev, -EINVAL, "Failed to identify device variant\n");
+
+ ret = devm_regulator_bulk_get_enable(dev, ARRAY_SIZE(ad5529r_supply_names),
+ ad5529r_supply_names);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to get and enable regulators\n");
+
+ ret = devm_regulator_get_enable_optional(dev, "hvss");
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to get and enable hvss regulator\n");
+
+ st->vref_regulator = devm_regulator_get_optional(dev, "vref");
+ if (IS_ERR(st->vref_regulator)) {
+ if (PTR_ERR(st->vref_regulator) != -ENODEV)
+ return dev_err_probe(dev, PTR_ERR(st->vref_regulator),
+ "Failed to get vref regulator\n");
+ st->vref_regulator = NULL;
+ }
+
+ if (st->vref_regulator) {
+ ret = regulator_enable(st->vref_regulator);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to enable vref regulator\n");
+
+ ret = devm_add_action_or_reset(dev, ad5529r_disable_regulator,
+ st->vref_regulator);
+ if (ret)
+ return dev_err_probe(dev, ret,
+ "Failed to add vref regulator cleanup\n");
+ }
+
+ st->regmap_8bit = devm_regmap_init_spi(spi, &ad5529r_regmap_8bit_config);
+ if (IS_ERR(st->regmap_8bit))
+ return dev_err_probe(dev, PTR_ERR(st->regmap_8bit),
+ "Failed to initialize 8-bit regmap\n");
+
+ st->regmap_16bit = devm_regmap_init_spi(spi, &ad5529r_regmap_16bit_config);
+ if (IS_ERR(st->regmap_16bit))
+ return dev_err_probe(dev, PTR_ERR(st->regmap_16bit),
+ "Failed to initialize 16-bit regmap\n");
+
+ ret = ad5529r_reset(st);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to reset device\n");
+
+ ret = regmap_update_bits(st->regmap_16bit, AD5529R_REG_REF_SEL,
+ AD5529R_REF_SEL_MASK,
+ st->vref_regulator ? 0 : AD5529R_REF_SEL_MASK);
+ if (ret)
+ return dev_err_probe(dev, ret, "Failed to configure reference\n");
+
+ ret = ad5529r_parse_channel_ranges(dev, st);
+ if (ret)
+ return ret;
+
+ indio_dev->name = st->model_data->model_name;
+ indio_dev->info = &ad5529r_info;
+ indio_dev->modes = INDIO_DIRECT_MODE;
+ indio_dev->channels = st->model_data->channels;
+ indio_dev->num_channels = st->model_data->num_channels;
+
+ return devm_iio_device_register(dev, indio_dev);
+}
+
+static const struct of_device_id ad5529r_of_match[] = {
+ { .compatible = "adi,ad5529r-16", .data = &ad5529r_16bit_model_data },
+ { .compatible = "adi,ad5529r-12", .data = &ad5529r_12bit_model_data },
+ { }
+};
+MODULE_DEVICE_TABLE(of, ad5529r_of_match);
+
+static const struct spi_device_id ad5529r_id[] = {
+ { "ad5529r-16", .driver_data = (kernel_ulong_t)&ad5529r_16bit_model_data },
+ { "ad5529r-12", .driver_data = (kernel_ulong_t)&ad5529r_12bit_model_data },
+ { }
+};
+MODULE_DEVICE_TABLE(spi, ad5529r_id);
+
+static struct spi_driver ad5529r_driver = {
+ .driver = {
+ .name = "ad5529r",
+ .of_match_table = ad5529r_of_match,
+ },
+ .probe = ad5529r_probe,
+ .id_table = ad5529r_id,
+};
+module_spi_driver(ad5529r_driver);
+
+MODULE_AUTHOR("Janani Sunil <janani.sunil@analog.com>");
+MODULE_DESCRIPTION("Analog Devices AD5529R 12/16-bit DAC driver");
+MODULE_LICENSE("GPL");
--
2.43.0
^ 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