* Re: [PATCH v3 4/5] watchdog: Separate kind of documentation
From: Guenter Roeck @ 2026-05-05 13:11 UTC (permalink / raw)
To: Philipp Hahn
Cc: Wim Van Sebroeck, Philipp Hahn, linux-watchdog, linux-doc,
linux-kernel
In-Reply-To: <7d1b722205bab83603832e66750f7b5f1f73eaa5.1777972790.git.phahn-oss@avm.de>
On Tue, May 05, 2026 at 11:26:15AM +0200, Philipp Hahn wrote:
> From: Philipp Hahn <phahn-oss@avm.de>
>
> Currently there are several (sub-)documents for "Generic kernel
> infrastructure API" and several "driver specific" documents. Put each
> one into its own sub-section.
>
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Applied to my watchdog-next branch
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 8/9] docs: maintainers_include: don't ignore invalid profile entries
From: Mauro Carvalho Chehab @ 2026-05-05 13:09 UTC (permalink / raw)
To: Gary Guo
Cc: Miguel Ojeda, Jonathan Corbet, Linux Doc Mailing List,
Mauro Carvalho Chehab, linux-kernel, rust-for-linux,
Björn Roy Baron, Alice Ryhl, Andreas Hindborg, Benno Lossin,
Boqun Feng, Danilo Krummrich, Miguel Ojeda, Shuah Khan,
Trevor Gross
In-Reply-To: <DIAP83C37D9N.1US9NOU3ME7YI@garyguo.net>
On Tue, 05 May 2026 12:16:03 +0100
"Gary Guo" <gary@garyguo.net> wrote:
> On Tue May 5, 2026 at 6:45 AM BST, Mauro Carvalho Chehab wrote:
> > On Tue, 5 May 2026 02:20:45 +0200
> > Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
> >
> >> On Tue, May 5, 2026 at 2:08 AM Mauro Carvalho Chehab
> >> <mchehab+huawei@kernel.org> wrote:
> >> >
> >> > Also, with time, maintainers may change their employers while still
> >> > keeping their maintainership status.
> >> >
> >> > So, I'd say that whatever is there at the "P" entry, or where it is
> >> > located (either on a ReST file at the Kernel or on some external URL),
> >> > it should reflect the model that a maintainer or subsystem community
> >> > that actively participate at the Kernel development agrees with.
> >> > This should be vendor-agnostic.
> >>
> >> I am not sure what you mean. By "vendored" I don't mean
> >> companies/employers, I mean that the file comes from an upstream
> >> repository:
> >>
> >> https://github.com/Rust-for-Linux/pin-init/blob/main/CONTRIBUTING.md
> >>
> >> Nevertheless, it is true that this really is a special case, in that
> >> the upstream project decided to provide something that could then be
> >> fit into the `P:` field.
> >>
> >> One could say "let's ask them to do rst upstream", but to be honest,
> >> it is simpler to just put a hyperlink to GitHub's rendered file.
> >> Markdown is anyway a better fit for their file.
> >
> > Ok. Then it P entry could be:
> >
> > P: https://github.com/Rust-for-Linux/pin-init/blob/main/CONTRIBUTING.md
>
> If you send a patch I can queue it up for 7.2. Or would you want this to be
> taken via docs tree instead?
It doesn't matter much but placing it at the documentation series
will keep this change together with the other patches, so I guess
it would be a little better.
I'll be sending the new patch series soon with this change there
as well.
--
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v3 2/5] watchdog: Move `struct` before name
From: Guenter Roeck @ 2026-05-05 13:09 UTC (permalink / raw)
To: Philipp Hahn
Cc: Wim Van Sebroeck, Philipp Hahn, linux-watchdog, linux-doc,
linux-kernel
In-Reply-To: <e66ec58f3b8252b3676cc9fe68818af95123210c.1777972790.git.phahn-oss@avm.de>
On Tue, May 05, 2026 at 11:26:13AM +0200, Philipp Hahn wrote:
> From: Philipp Hahn <phahn-oss@avm.de>
>
> Write `struct ` before the structure name as Sphinx otherwise uses the
> following word after it. See
> https://docs.kernel.org/watchdog/watchdog-api.html#environmental-monitoring
>
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Applied to my watchdog-next branch.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH v3 1/5] watchdog: Change suffix .txt to .rst in references
From: Guenter Roeck @ 2026-05-05 13:08 UTC (permalink / raw)
To: Philipp Hahn
Cc: Wim Van Sebroeck, Philipp Hahn, linux-watchdog, linux-doc,
linux-kernel
In-Reply-To: <bb1aa3129d5e52bc4c8e1ec3340b88f80f726fef.1777972790.git.phahn-oss@avm.de>
On Tue, May 05, 2026 at 11:26:12AM +0200, Philipp Hahn wrote:
> From: Philipp Hahn <phahn-oss@avm.de>
>
> Fix link to documentation, which has already been converted to reST.
> Also remove apostrophes which are no longer needed.
>
> Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
Applied to my watchdog-next branch.
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH 9/9] docs: maintainers: add a filtering javascript
From: Mauro Carvalho Chehab @ 2026-05-05 13:00 UTC (permalink / raw)
To: Randy Dunlap
Cc: Jonathan Corbet, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, rust-for-linux, Shuah Khan
In-Reply-To: <afcc4dc7-14c8-4a10-aea4-69ae7ed3f37f@infradead.org>
On Mon, 4 May 2026 14:12:50 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> On 5/4/26 8:51 AM, Mauro Carvalho Chehab wrote:
> > The maintainers table is big. Add a javascript to allow filtering
> > it. Such script is only added at the page which contains the
> > maintainers-include tag.
> >
> > I opted to keep the search case-sensitive, as, this way,
> > upper case searches at subsystem.
> >
> > Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
> > ---
> > Documentation/sphinx/maintainers_include.py | 77 +++++++++++++++++++--
> > 1 file changed, 71 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/sphinx/maintainers_include.py b/Documentation/sphinx/maintainers_include.py
> > index bbdadf2aa4f3..f85298627da2 100755
> > --- a/Documentation/sphinx/maintainers_include.py
> > +++ b/Documentation/sphinx/maintainers_include.py
>
> > + function addInput() {
> > + const table = document.getElementById("maintainers-table");
> > + if (!table) return;
> > + let input = document.getElementById("filter-table");
> > + if (!input) {
> > + const filt_div = document.createElement('div');
> > + filt_div.innerHTML = `
> > + <p>Filter:
> > + <input type="search" id="filter-table" placeholder="subsystem or property (case-sensitive)" />
>
> The "placeholder" string does not fit inside the prompt/entry block so it is
> truncated with no way to tell what the missing part is AFAICT.
> Maybe include that after "Filter:"? E.g.,
>
> <p>Filter: (subsystem or property, case-sensitive)
>
> > + </p>
> > + `;
Makes sense. Changed the logic to:
filt_div.innerHTML = `
<p>Filter:
<input type="search" id="filter-table" placeholder="search string"/>
subsystem or property (case-sensitive)
</p>
`;
--
Thanks,
Mauro
^ permalink raw reply
* Re: Regression due to /sys/kernel/dmabuf/buffers removal
From: Julian Orth @ 2026-05-05 12:59 UTC (permalink / raw)
To: Christian König
Cc: T.J. Mercier, corbet, dri-devel, linaro-mm-sig, linux-doc,
linux-kernel, linux-media, Sumit Semwal
In-Reply-To: <cf945dda-f526-4544-bc43-22f70acb28f5@amd.com>
On Tue, May 5, 2026 at 2:41 PM Christian König <christian.koenig@amd.com> wrote:
>
> Hi Julian,
>
> On 5/5/26 14:25, Julian Orth wrote:
> > In ab4c3dcf9a71582503b4fb25aeab884c696cab25 ("dma-buf: Remove DMA-BUF
> > sysfs stats") the /sys/kernel/dmabuf/buffer directory was removed.
> >
> > I've been using this interface, specifically the exporter_name file,
> > to detect dmabufs created via udmabuf. Such dmabufs show "udmabuf" in
> > exporter_name. I've been doing this for two reasons: 1) to detect that
> > mmap on such buffers will be fast and 2) to detect that GPU access to
> > such buffers will be slow.
>
> Crap, I really hoped that Android was the only user of that sysfs interface since that approach turned out to be quite broken.
>
> It's number one rule on Linux that we don't break userspace. So I hope that you don't insist on bringing that interface back, but if you do I will just revert the removal until we found a better solution.
Bringing it back shouldn't be necessary.
>
> > With the removal of that file, that detection mechanism no longer works.
> >
> > I'm not particularly fond of that mechanism but it was the only one
> > providing that functionality that I could find at the time. If there
> > is another one, ideally an ioctl on the dmabuf, please let me know.
>
> The virtual fdinfo file you can find under /proc/$pid/fdinfo/$fd also contains the exporter name for the DMA-buf.
>
> You can find the full documentation here: https://docs.kernel.org/filesystems/proc.html#dma-buffer-files
>
> Is that sufficient?
I think that is sufficient. I probably didn't use fdinfo initially
because 1) it's a lot more work to parse and 2) I wasn't sure if it
was intended to be machine-readable or if there could sometimes be
newlines in the values and such.
>
> Additional to that the debugfs for DMA-buf also contains that information and I'm open to the suggestion with the IOCTL.
My application runs as a regular user so it cannot access /sys/kernel/debug.
Having an IOCTL would be ideal if it is not too much work. I'll fall
back to fdinfo for now.
Thanks, Julian
>
> Regards,
> Christian.
>
> >
> > Shipping an entire BPF compiler in my application, which the original
> > patch suggests as the replacement, is not an option when the removed
> > alternative was simply reading a file.
> >
> > Thanks, Julian
>
^ permalink raw reply
* Re: [PATCH v9 1/9] revocable: Revocable resource management
From: Bartosz Golaszewski @ 2026-05-05 12:55 UTC (permalink / raw)
To: Tzung-Bi Shih
Cc: Benson Leung, linux-kernel, chrome-platform, driver-core,
linux-doc, linux-gpio, Rafael J. Wysocki, Danilo Krummrich,
Jonathan Corbet, Shuah Khan, Laurent Pinchart, Wolfram Sang,
Jason Gunthorpe, Johan Hovold, Paul E . McKenney, Dan Williams,
Arnd Bergmann, Greg Kroah-Hartman, Bartosz Golaszewski,
Linus Walleij
In-Reply-To: <20260427135841.96266-2-tzungbi@kernel.org>
On Mon, 27 Apr 2026 15:58:33 +0200, Tzung-Bi Shih <tzungbi@kernel.org> said:
> The "revocable" mechanism is a synchronization primitive designed to
> manage safe access to resources that can be asynchronously removed or
> invalidated. Its primary purpose is to prevent Use-After-Free (UAF)
> errors when interacting with resources whose lifetimes are not
> guaranteed to outlast their consumers.
>
> This is particularly useful in systems where resources can disappear
> unexpectedly, such as those provided by hot-pluggable devices like
> USB. When a consumer holds a reference to such a resource, the
> underlying device might be removed, causing the resource's memory to
> be freed. Subsequent access attempts by the consumer would then lead
> to UAF errors.
>
> Revocable addresses this by providing a form of "weak reference" and
> a controlled access method. It allows a resource consumer to safely
> attempt to access the resource. The mechanism guarantees that any
> access granted is valid for the duration of its use. If the resource
> has already been revoked (i.e., freed), the access attempt will fail
> safely, typically by returning NULL, instead of causing a crash.
>
> It uses a provider/consumer model built on Sleepable RCU (SRCU) to
> guarantee safe memory access:
>
> - A resource provider, such as a driver for a hot-pluggable device,
> allocates a struct revocable and initializes it with a pointer
> to the resource.
>
> - A resource consumer that wants to access the resource allocates a
> struct revocable_consumer containing a reference to the provider.
>
> - To access the resource, the consumer uses revocable_try_access().
> This function enters an SRCU read-side critical section and returns
> the pointer to the resource. If the provider has already freed the
> resource, it returns NULL. After use, the consumer calls
> revocable_withdraw_access() to exit the SRCU critical section. There
> are some macro level helpers for doing that.
>
> The API provides the following contract:
>
> - revocable_try_access() can be safely called from both process and
> atomic contexts.
> - It is permitted to sleep within the critical section established
> between revocable_try_access() and revocable_withdraw_access().
> - revocable_try_access() and the matching revocable_withdraw_access()
> must occur in the same context. For example, it is illegal to
> invoke revocable_withdraw_access() in an irq handler if the matching
> revocable_try_access() was invoked in process context.
>
> - When the provider needs to remove the resource, it calls
> revocable_revoke(). This function sets the internal resource
> pointer to NULL and then calls synchronize_srcu() to wait for all
> current readers to finish before the resource can be completely torn
> down.
>
> Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
> ---
...
> diff --git a/include/linux/revocable.h b/include/linux/revocable.h
> new file mode 100644
> index 000000000000..2bcf23f01ace
> --- /dev/null
> +++ b/include/linux/revocable.h
> @@ -0,0 +1,214 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright 2026 Google LLC
> + */
> +
> +#ifndef __LINUX_REVOCABLE_H
> +#define __LINUX_REVOCABLE_H
> +
> +#include <linux/cleanup.h>
> +#include <linux/compiler.h>
I don't think you need this header.
> +#include <linux/kref.h>
> +#include <linux/srcu.h>
> +
> +/**
> + * enum revocable_alloc_type - The allocation method for a revocable provider.
> + * @REVOCABLE_DYNAMIC: The struct revocable was dynamically allocated using
> + * revocable_alloc() and its lifetime is managed by
> + * reference counting.
> + * @REVOCABLE_EMBEDDED: The struct revocable is embedded within another
> + * structure. Its lifetime is tied to the parent
> + * structure and is not reference counted.
> + */
> +enum revocable_alloc_type {
> + REVOCABLE_DYNAMIC,
> + REVOCABLE_EMBEDDED,
> +};
Maybe we don't need this public enum at all, we could just use a different
release callback for kref_put() depending on how the revocable was allocated?
The enum is not used elsewhere so it doesn't make sense to document it as if it
was part of the revocable API.
> +
> +/**
> + * struct revocable - A handle for resource provider.
> + * @srcu: The SRCU to protect the resource.
> + * @res: The pointer of resource. It can point to anything.
> + * @kref: The refcount for this handle.
> + * @alloc_type: The memory allocation type.
> + */
> +struct revocable {
> + struct srcu_struct srcu;
> + void __rcu *res;
> + struct kref kref;
> + enum revocable_alloc_type alloc_type;
This could be replaced with the pointer to the release callback, assigned
by revocable_alloc()/revocable_init() respectively.
> +};
> +
> +/**
> + * struct revocable_consumer - A handle for resource consumer.
> + * @rev: The pointer of resource provider.
> + * @idx: The index for the SRCU critical section.
Should any of these be accessed directly by the user? Maybe document them
as __private?
> + */
> +struct revocable_consumer {
> + struct revocable *rev;
> + int idx;
> +};
I'd rename it to struct revocable_handle which indicates better what it is:
it's a handle *owned* by the consumer.
> +
> +void revocable_get(struct revocable *rev);
> +void revocable_put(struct revocable *rev);
> +
> +struct revocable *revocable_alloc(void *res);
> +void revocable_revoke(struct revocable *rev);
> +int revocable_embed_init(struct revocable *rev, void *res);
> +void revocable_embed_destroy(struct revocable *rev);
> +
> +void revocable_init(struct revocable *rev, struct revocable_consumer *rc);
> +void revocable_deinit(struct revocable_consumer *rc);
If we hid the release logic, we could drop revocable_embed_destroy() and use
the same refcounting functions for both variants. I'd suggest the following:
For refcounting (same for both variants):
void revocable_get(struct revocable *rev);
void revocable_put(struct revocable *rev);
For dynamic variant:
struct revocable *revocable_alloc(void *res);
For embedded:
int revocable_init(struct revocable *rev, void *res);
For handles:
void revocable_handle_init(struct revocable *rev, struct
revocable_consumer *rc);
void revocable_handle_deinit(struct revocable_consumer *rc);
Does it make sense?
Other (try_access_*, etc.) helpers look good. And the API in general looks
pretty good to me too.
Bart
^ permalink raw reply
* Re: [PATCH 0/9] Improve process/maintainers output
From: Mauro Carvalho Chehab @ 2026-05-05 12:50 UTC (permalink / raw)
To: Randy Dunlap
Cc: Jonathan Corbet, Mauro Carvalho Chehab, Miguel Ojeda, linux-doc,
linux-kernel, rust-for-linux, Björn Roy Baron, Alice Ryhl,
Andreas Hindborg, Andrew Morton, Benno Lossin, Boqun Feng,
Danilo Krummrich, Gary Guo, Joe Perches, Matteo Croce, Shuah Khan,
Trevor Gross
In-Reply-To: <d303200a-9fc7-4ea6-89ec-90c2a159bfe2@infradead.org>
On Mon, 4 May 2026 14:13:01 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> On 5/4/26 8:51 AM, Mauro Carvalho Chehab wrote:
> > Hi Jon,
> >
> > As promised, this series improve the output at process/maintainers:
> > instead of a pure enriched text, the maintainer's file content is
> > now converted with a table, and has gained a javascript to allow
> > filtering entries.
> >
> > The initial patches change the logic to split parsing from
> > output generation. Now, everything is stored into a dict at
> > the parsing phase. This way, it is easier to adjust the
> > directive handler for it to produce a more structured document.
> >
> > Right now, the entries are sorted alphabetically, per subsystem's
> > name.
>
> How is subsystem determined? Just by the heading?
> The MAINTAINERS file doesn't stay sorted so the output isn't sorted
> unless I am just missing something basic.
>
> See e.g.:
> DRM TTM SUBSYSTEM
> GPU BUDDY ALLOCATOR
> DRM AUTOMATED TESTING
It was preserving the same order as found at MAINTAINERS file,
where the order is wrong. I added a sort function there (I guess I
had it before internally on my branches some rebases).
--
Thanks,
Mauro
^ permalink raw reply
* Re: Regression due to /sys/kernel/dmabuf/buffers removal
From: Christian König @ 2026-05-05 12:41 UTC (permalink / raw)
To: Julian Orth, T.J. Mercier
Cc: corbet, dri-devel, linaro-mm-sig, linux-doc, linux-kernel,
linux-media, Sumit Semwal
In-Reply-To: <CAHijbEXhuVRgkkPA2dAC=njGBU7vpAbxAbsSmxvvPznO-ckVRA@mail.gmail.com>
Hi Julian,
On 5/5/26 14:25, Julian Orth wrote:
> In ab4c3dcf9a71582503b4fb25aeab884c696cab25 ("dma-buf: Remove DMA-BUF
> sysfs stats") the /sys/kernel/dmabuf/buffer directory was removed.
>
> I've been using this interface, specifically the exporter_name file,
> to detect dmabufs created via udmabuf. Such dmabufs show "udmabuf" in
> exporter_name. I've been doing this for two reasons: 1) to detect that
> mmap on such buffers will be fast and 2) to detect that GPU access to
> such buffers will be slow.
Crap, I really hoped that Android was the only user of that sysfs interface since that approach turned out to be quite broken.
It's number one rule on Linux that we don't break userspace. So I hope that you don't insist on bringing that interface back, but if you do I will just revert the removal until we found a better solution.
> With the removal of that file, that detection mechanism no longer works.
>
> I'm not particularly fond of that mechanism but it was the only one
> providing that functionality that I could find at the time. If there
> is another one, ideally an ioctl on the dmabuf, please let me know.
The virtual fdinfo file you can find under /proc/$pid/fdinfo/$fd also contains the exporter name for the DMA-buf.
You can find the full documentation here: https://docs.kernel.org/filesystems/proc.html#dma-buffer-files
Is that sufficient?
Additional to that the debugfs for DMA-buf also contains that information and I'm open to the suggestion with the IOCTL.
Regards,
Christian.
>
> Shipping an entire BPF compiler in my application, which the original
> patch suggests as the replacement, is not an option when the removed
> alternative was simply reading a file.
>
> Thanks, Julian
^ permalink raw reply
* Re: [PATCH v2] cpufreq: CPPC: add autonomous mode boot parameter support
From: Sumit Gupta @ 2026-05-05 12:29 UTC (permalink / raw)
To: Jie Zhan, rafael, viresh.kumar, pierre.gondois, ionela.voinescu,
zhenglifeng1, corbet, skhan, rdunlap, mario.limonciello, linux-pm,
linux-doc, linux-kernel
Cc: linux-tegra, treding, jonathanh, vsethi, ksitaraman, sanjayc,
mochs, bbasu, sumitg
In-Reply-To: <a4ed690a-50d6-4bfe-8810-86a75d7b51e3@hisilicon.com>
Hi Jie,
On 27/04/26 13:54, Jie Zhan wrote:
> External email: Use caution opening links or attachments
>
>
> Hi Sumit,
>
> In general, I would expect this parameter only toggles on auto_sel by
> default. IIUC, other CPPC configurations (min/max/desired perf, EPP,
> enable) are optional and not closely related to this.
>
> Why including those stuff here?
>
>
> Please see other questions inline.
>
> Thanks!
> Jie
These together provide a known, predictable autonomous mode boot.
min/max/desired seeding ensures HW has a known starting bound (BIOS
may leave them unset).
EPP=PERFORMANCE_PREF is needed as BIOS defaults often bias toward
energy saving, and admins on many CPU systems shouldn't have to script
per CPU sysfs writes at every boot to undo that.
>
> On 4/25/2026 4:18 AM, Sumit Gupta wrote:
>> Add a kernel boot parameter 'cppc_cpufreq.auto_sel_mode' to enable
>> CPPC autonomous performance selection on all CPUs at system startup.
>> When autonomous mode is enabled, the hardware automatically adjusts
>> CPU performance based on workload demands using Energy Performance
>> Preference (EPP) hints.
>>
>> When auto_sel_mode=1:
>> - Configure all CPUs for autonomous operation on first init
>> - Set EPP to performance preference (0x0)
>> - Use HW min/max_perf when available; otherwise initialize from caps
>> - Clamp desired_perf to bounds before enabling autonomous mode
>> - Hardware controls frequency instead of the OS governor
>>
>> The boot parameter is applied only during first policy initialization.
>> Skip applying it on CPU hotplug to preserve runtime sysfs configuration.
>>
>> This patch depends on patch [2] ("cpufreq: Set policy->min and max
>> as real QoS constraints") so that the policy->min/max set in
>> cppc_cpufreq_cpu_init() are not overridden by cpufreq_set_policy()
>> during init.
>>
>> Reviewed-by: Randy Dunlap <rdunlap@infradead.org> (Documentation)
>> Signed-off-by: Sumit Gupta <sumitg@nvidia.com>
>> ---
>> v[1] -> v2:
>> - Call cppc_set_enable() unconditionally so CPPC is enabled for both
>> OS-driven and autonomous modes.
> Why adding this in v2?
> This looks like a separate issue since setting CPPC Enable reg doesn't seem
> to be related with autonomous control.
In v2, moved it out of the auto_sel specific check.
Agree that cppc_set_enable() is general CPPC enablement and can be split
into a separate patch in v3 if preferred.
>> - Init min/max from caps instead of cppc_cpufreq_update_perf_limits()
>> as policy->min/max aren't yet populated.
>>
>> [1] https://lore.kernel.org/lkml/20260317151053.2361475-1-sumitg@nvidia.com/
>> [2] https://lore.kernel.org/lkml/20260423084731.1090384-2-pierre.gondois@arm.com/
>> ---
>> .../admin-guide/kernel-parameters.txt | 13 +++
>> drivers/cpufreq/cppc_cpufreq.c | 89 +++++++++++++++++--
>> 2 files changed, 97 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
>> index 0a1abed1b93c..751817b0573a 100644
>> --- a/Documentation/admin-guide/kernel-parameters.txt
>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>> @@ -1067,6 +1067,19 @@ Kernel parameters
>> policy to use. This governor must be registered in the
>> kernel before the cpufreq driver probes.
>>
>> + cppc_cpufreq.auto_sel_mode=
>> + [CPU_FREQ] Enable ACPI CPPC autonomous performance
>> + selection. When enabled, hardware automatically adjusts
>> + CPU frequency on all CPUs based on workload demands.
>> + In Autonomous mode, Energy Performance Preference (EPP)
>> + hints guide hardware toward performance (0x0) or energy
>> + efficiency (0xff).
>> + Requires ACPI CPPC autonomous selection register support.
>> + Format: <bool>
>> + Default: 0 (disabled)
>> + 0: use cpufreq governors
>> + 1: enable if supported by hardware
>> +
>> cpu_init_udelay=N
>> [X86,EARLY] Delay for N microsec between assert and de-assert
>> of APIC INIT to start processors. This delay occurs
>> diff --git a/drivers/cpufreq/cppc_cpufreq.c b/drivers/cpufreq/cppc_cpufreq.c
>> index 02db03d03755..672fc3058190 100644
>> --- a/drivers/cpufreq/cppc_cpufreq.c
>> +++ b/drivers/cpufreq/cppc_cpufreq.c
>> @@ -28,6 +28,9 @@
>>
>> static struct cpufreq_driver cppc_cpufreq_driver;
>>
>> +/* Autonomous Selection boot parameter */
>> +static bool auto_sel_mode;
>> +
>> #ifdef CONFIG_ACPI_CPPC_CPUFREQ_FIE
>> static enum {
>> FIE_UNSET = -1,
>> @@ -656,6 +659,14 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
>> caps = &cpu_data->perf_caps;
>> policy->driver_data = cpu_data;
>>
>> + /*
>> + * Enable CPPC for both OS-driven and autonomous modes.
>> + * The Enable register is optional - some platforms may not support it
>> + */
>> + ret = cppc_set_enable(cpu, true);
>> + if (ret && ret != -EOPNOTSUPP)
>> + pr_warn("Failed to enable CPPC for CPU%d (%d)\n", cpu, ret);
>> +
>> min = cppc_perf_to_khz(caps, caps->lowest_nonlinear_perf);
>> max = cppc_perf_to_khz(caps, policy->boost_enabled ?
>> caps->highest_perf : caps->nominal_perf);
>> @@ -711,11 +722,71 @@ static int cppc_cpufreq_cpu_init(struct cpufreq_policy *policy)
>> policy->cur = cppc_perf_to_khz(caps, caps->highest_perf);
>> cpu_data->perf_ctrls.desired_perf = caps->highest_perf;
>>
>> - ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>> - if (ret) {
>> - pr_debug("Err setting perf value:%d on CPU:%d. ret:%d\n",
>> - caps->highest_perf, cpu, ret);
>> - goto out;
>> + /*
>> + * Enable autonomous mode on first init if boot param is set.
>> + * Check last_governor to detect first init and skip if auto_sel
>> + * is already enabled.
>> + */
>> + if (auto_sel_mode && policy->last_governor[0] == '\0' &&
>> + !cpu_data->perf_ctrls.auto_sel) {
>> + /* Init min/max_perf from caps if not already set by HW. */
>> + if (!cpu_data->perf_ctrls.min_perf)
>> + cpu_data->perf_ctrls.min_perf = caps->lowest_nonlinear_perf;
>> + if (!cpu_data->perf_ctrls.max_perf)
>> + cpu_data->perf_ctrls.max_perf = policy->boost_enabled ?
>> + caps->highest_perf : caps->nominal_perf;
> Is it automatically adjusted when switching boost on and off?
Yes. Here just setting the the initial value. Subsequent boost toggles
propagate via the existing QoS/CPUFREQ_NEED_UPDATE_LIMITS flow:
a FREQ_QOS_MAX update triggers .target (cppc_cpufreq_set_target)
-> cppc_set_perf, which sets the new max_perf to HW.
>> +
>> + cpu_data->perf_ctrls.desired_perf =
>> + clamp_t(u32, cpu_data->perf_ctrls.desired_perf,
>> + cpu_data->perf_ctrls.min_perf,
>> + cpu_data->perf_ctrls.max_perf);
> Why do we need to clamp desire_perf here?
You are right, the clamp isn't really needed.
With auto_sel, the desired_perf is an optional hint. EPP and the
platform drive actual selection within [min_perf, max_perf].
We can simply initialize desired_perf to max_perf as starting hint.
I will update it to below in v3:
cpu_data->perf_ctrls.desired_perf = cpu_data->perf_ctrls.max_perf;
>> +
>> + policy->cur = cppc_perf_to_khz(caps,
>> + cpu_data->perf_ctrls.desired_perf);
>> +
>> + /* EPP is optional - some platforms may not support it */
>> + ret = cppc_set_epp(cpu, CPPC_EPP_PERFORMANCE_PREF);
> Why setting this to PERFORMANCE by default?
> A platform can have its own default EPP value. This would override that.
The boot option targets performance oriented use cases on many CPU
systems, avoiding sysfs scripting across all CPUs on every boot.
The BIOS default EPP (often biased toward energy saving) would otherwise
steer HW away from that goal. Admins can still re-tune EPP at runtime via
the existing energy_performance_preference_val sysfs.
>> + if (ret && ret != -EOPNOTSUPP)
>> + pr_warn("Failed to set EPP for CPU%d (%d)\n", cpu, ret);
>> + else if (!ret)
>> + cpu_data->perf_ctrls.energy_perf = CPPC_EPP_PERFORMANCE_PREF;
>> +
>> + /* Program min/max/desired into CPPC regs before enabling auto_sel. */
>> + ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>> + if (ret) {
>> + pr_debug("Err setting perf for autonomous mode CPU:%d ret:%d\n",
>> + cpu, ret);
>> + goto out;
> Shouldn't this be pr_warn(), or even pr_err(), if it needs to bail out?
>
> However, IIUC setting min/max/desired perf is optional for auto_sel, so
> better to pr_info() and continue setting auto_sel?
Agree that we shouldn't fail the whole init here.
Even if cppc_set_perf fails, HW can still operate in autonomous mode.
Prefer pr_warn to pr_info as a non-zero cppc_set_perf return means a
real error, not a missing register, so it's worth flagging.
Will update in v3.
>> + }
>> +
>> + ret = cppc_set_auto_sel(cpu, true);
>> + if (ret && ret != -EOPNOTSUPP) {
>> + pr_warn("Failed autonomous config for CPU%d (%d)\n",
>> + cpu, ret);
>> + goto out;
> Bailing out here would end up without DVFS support.
> Can we fall back to the normal OS directed mode?
Good point.
The fallback is already wired up: when auto_sel stays false, the next
else branch takes the OS directed path. So I will just drop the goto out
and update the message in v3.
Thank you,
Sumit Gupta
>> + }
>> + if (!ret)
>> + cpu_data->perf_ctrls.auto_sel = true;
>> + }
>> +
>> + if (cpu_data->perf_ctrls.auto_sel) {
>> + /* Sync policy limits from HW when autonomous mode is active */
>> + policy->min = cppc_perf_to_khz(caps,
>> + cpu_data->perf_ctrls.min_perf ?:
>> + caps->lowest_nonlinear_perf);
>> + policy->max = cppc_perf_to_khz(caps,
>> + cpu_data->perf_ctrls.max_perf ?:
>> + (policy->boost_enabled ?
>> + caps->highest_perf :
>> + caps->nominal_perf));
>> + } else {
>> + /* Normal mode: governors control frequency */
>> + ret = cppc_set_perf(cpu, &cpu_data->perf_ctrls);
>> + if (ret) {
>> + pr_debug("Err setting perf value:%d on CPU:%d. ret:%d\n",
>> + caps->highest_perf, cpu, ret);
>> + goto out;
>> + }
>> }
>>
>> cppc_cpufreq_cpu_fie_init(policy);
>> @@ -1035,10 +1106,18 @@ static int __init cppc_cpufreq_init(void)
>>
>> static void __exit cppc_cpufreq_exit(void)
>> {
>> + unsigned int cpu;
>> +
>> + for_each_present_cpu(cpu)
>> + cppc_set_auto_sel(cpu, false);
>> +
>> cpufreq_unregister_driver(&cppc_cpufreq_driver);
>> cppc_freq_invariance_exit();
>> }
>>
>> +module_param(auto_sel_mode, bool, 0444);
>> +MODULE_PARM_DESC(auto_sel_mode, "Enable CPPC autonomous performance selection at boot");
>> +
>> module_exit(cppc_cpufreq_exit);
>> MODULE_AUTHOR("Ashwin Chaugule");
>> MODULE_DESCRIPTION("CPUFreq driver based on the ACPI CPPC v5.0+ spec");
^ permalink raw reply
* Regression due to /sys/kernel/dmabuf/buffers removal
From: Julian Orth @ 2026-05-05 12:25 UTC (permalink / raw)
To: T.J. Mercier
Cc: Christian König, corbet, dri-devel, linaro-mm-sig, linux-doc,
linux-kernel, linux-media, Sumit Semwal
In ab4c3dcf9a71582503b4fb25aeab884c696cab25 ("dma-buf: Remove DMA-BUF
sysfs stats") the /sys/kernel/dmabuf/buffer directory was removed.
I've been using this interface, specifically the exporter_name file,
to detect dmabufs created via udmabuf. Such dmabufs show "udmabuf" in
exporter_name. I've been doing this for two reasons: 1) to detect that
mmap on such buffers will be fast and 2) to detect that GPU access to
such buffers will be slow.
With the removal of that file, that detection mechanism no longer works.
I'm not particularly fond of that mechanism but it was the only one
providing that functionality that I could find at the time. If there
is another one, ideally an ioctl on the dmabuf, please let me know.
Shipping an entire BPF compiler in my application, which the original
patch suggests as the replacement, is not an option when the removed
alternative was simply reading a file.
Thanks, Julian
^ permalink raw reply
* Re: [PATCH v1 1/7] rust: sync: completion: add wait_for_completion_timeout()
From: Miguel Ojeda @ 2026-05-05 12:17 UTC (permalink / raw)
To: Joel Fernandes
Cc: linux-kernel, Danilo Krummrich, Alexandre Courbot, John Hubbard,
Alice Ryhl, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Miguel Ojeda, Boqun Feng,
Gary Guo, Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross, Jonathan Corbet, Shuah Khan, nova-gpu, dri-devel,
rust-for-linux, linux-doc
In-Reply-To: <20260501205825.73614-2-joelagnelf@nvidia.com>
On Fri, May 1, 2026 at 10:58 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
>
> + // SAFETY: `self.as_raw()` is a pointer to a valid `struct completion`.
This is fine since it follows the other ones in the file, but we
should say why this is the case (in another series, possibly a good
first issue), rather than just asserting it.
e.g. a type invariant?
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH net-next v3 1/2] dpll: add fractional frequency offset to pin-parent-device
From: Jiri Pirko @ 2026-05-05 11:31 UTC (permalink / raw)
To: Ivan Vecera
Cc: netdev, Andrew Lunn, Arkadiusz Kubalewski, David S. Miller,
Donald Hunter, Eric Dumazet, Jakub Kicinski, Jonathan Corbet,
Leon Romanovsky, Mark Bloch, Michal Schmidt, Paolo Abeni,
Pasi Vaananen, Petr Oros, Prathosh Satish, Saeed Mahameed,
Shuah Khan, Simon Horman, Tariq Toukan, Vadim Fedorenko,
linux-doc, linux-kernel, linux-rdma
In-Reply-To: <20260504155340.411063-2-ivecera@redhat.com>
Mon, May 04, 2026 at 05:53:39PM +0200, ivecera@redhat.com wrote:
>Add both fractional-frequency-offset (PPM) and
>fractional-frequency-offset-ppt (PPT) attributes to the
>pin-parent-device nested attribute set, alongside the existing
>top-level pin attributes. Both carry the same measurement at
>different precisions.
>
>Distinguish the two contexts in the ffo_get callback by passing
>dpll=NULL for the top-level call and a valid dpll pointer for the
>nested per-parent call. This allows drivers to report a different
>value per parent DPLL if needed. Update mlx5 and zl3073x drivers
>to return -ENODATA for the context they do not yet support.
>
>Add documentation for both FFO attributes to dpll.rst.
>
>Signed-off-by: Ivan Vecera <ivecera@redhat.com>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Beleswar Prasad Padhi @ 2026-05-05 11:16 UTC (permalink / raw)
To: tanmay.shah, Arnaud POULIQUEN, Mathieu Poirier
Cc: Shenwei Wang, Andrew Lunn, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Frank Li, Sascha Hauer, Shuah Khan,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski
In-Reply-To: <c6f68ab5-271a-41ed-b285-75b739f1edd6@amd.com>
Hi Tanmay,
On 05/05/26 00:49, Shah, Tanmay wrote:
> Hello all,
>
> I have started reviewing this work as well.
> Thanks Shenwei for this work.
>
> I have gone through only the current revision, and would like to provide
> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
> Also, have some bindings related question.
>
> Please see below:
>
> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>
>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>> Hello Arnaud,
>>>
>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>> Hello,
>>>>
>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>> Hi Mathieu,
>>>>>>
>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>> Andersson
>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>> linux-imx <linux-
>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>> rpmsg GPIO driver
>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>> Jonathan
>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>> __u8 status;
>>>>>>>>>>>>> __u8 value;
>>>>>>>>>>>>> };
>>>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>
>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>> message format.
>>>>>>>>>>>
>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>
>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>> requests and
>>>>>>>>> replies, and a second one for events.
>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>> channel, so a
>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>> of messages.
>>>>>>>>>>
>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>> an additional
>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>> field is added to
>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>
>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>> multiplexing
>>>>>>>>> capability by way of endpoints. There is no need for a port
>>>>>>>>> field. One endpoint,
>>>>>>>>> one GPIO controller.
>>>>>>>>>
>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>> endpoint maps to, either
>>>>>>>> by embedding the port information in the message (the current
>>>>>>>> way), or by sending it
>>>>>>>> separately.
>>>>>>>>
>>>>>>> An endpoint is created with every namespace request. There should be
>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>> unique
>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>> field to identify them.
>>>>>>
>>>>>> Right, but this can still be done by just having one namespace
>>>>>> request.
>>>>>> We can create new endpoints bound to an existing namespace/channel by
>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>> b73d-228295daaeec@ti.com/
>>>>>>
>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>> next week.
>>>>>
>>>>>> My mental model looks like this for the complete picture:
>>>>>>
>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>> a. ept1 -> gpio-controller@1
>>>>>> b. ept2 -> gpio-controller@2
>>>>>>
> If my understanding of what gpio-controller is right, than this won't
> work. We need one rpmsg channel per gpio-controller, and in most cases
> there will be only one GPIO-controller on the remote side.
Why so? In the current v13 version, the remote side already
handles 2 GPIO controllers.
> If there are
> multiple or multiple instances of same controller, than we need separate
> channel name for that controller just like we would have separate device
> on the Linux.
Why so? I think there is some confusion in the terminology:
GPIO controller = GPIO port (gpio@xyz) defined in the
Device tree = struct rpmsg_gpio_port in code
GPIO line = Individual lines within each GPIO port (max =
GPIOS_PER_PORT_DEFAULT) = struct rpmsg_gpio_line in code
>
>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>> beginning. I don't yet have a strong opinion on whether to use one
>>>>> namespace request per GPIO controller or a single request that spins
>>>>> off multiple endpoints. I'll have to look at your link and reflect on
>>>>> that. Regardless of how we proceed on that front, multiplexing needs
>>>>> to happen at the endpoint level rather than the packet level. This is
>>>>> the only way this work can move forward.
>>>>>
>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>> created with every namespace request.”
>>>>
>>>> If the endpoint is created only on the Linux side, how do we match
>>>> the Linux endpoint address with the local port field on the remote side?
>>>
>>> Simply by sending a message to the remote containing the newly created
>>> endpoint and the port idx. Note that is this done just one time, after
>>> this
>>> Linux need not have the port field in the message everytime its sending
>>> a message.
>>>
>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>> the DT. This would:
>>>
>>> You will face the same problem in this case also that you asked above:
>>> "how do we match the Linux endpoint address with the local port field
>>> on the remote side?"
>> Sorry I probably introduced confusion here
>> my sentence should be;
>> With a multi-namespace approach, the namespace could be rpmsg-io-[port],
>> where [port] corresponds to the GPIO controller port in the DT.
>>
>>
>> For instance:
>>
>> rpmsg {
>> rpmsg-io {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> gpio@25 {
>> compatible = "rpmsg-gpio";
>> reg = <25>;
>> gpio-controller;
>> #gpio-cells = <2>;
>> #interrupt-cells = <2>;
>> interrupt-controller;
>> };
>>
>> gpio@32 {
>> compatible = "rpmsg-gpio";
>> reg = <32>;
>> gpio-controller;
>> #gpio-cells = <2>;
>> #interrupt-cells = <2>;
>> interrupt-controller;
>> };
>> };
>> };
>>
>> rpmsg-io-25 would match with gpio@25
>> rpmsg-io-32 would match with gpio@32
>>
> The problem with this approach is, we will endup creating way too many
> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
> many GPIOs can be handled by remote from memory perspective. At
> somepoint we might just run-out of number ept & channels created by the
> remote. As of now, open-amp library supports 128 epts I think.
Arnaud was suggesting one channel per gpio controller,
not per line. We will not have 128 gpio controllers....
>
>>> Because the endpoint that is created on a namespace request is also
>>> dynamic in nature. How will the remote know which endpoint addr
>>> Linux allocated for a namespace that it announced?
>>>
>>> As an example/PoC, I created a firmware example which announces
>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>> the name service request from the same firmware:
>>>
>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel
>>> ti.ipc4.ping-pong addr 0xd
>>> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>> addr 0xe
>>> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>> formed from src = 0x400 to dst = 0xe
>>> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>> new channel: 0x401 -> 0xd!
>>>
>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>> Back to same problem. Simple solution is to reply to remote with the
>>> created ept addr and the index.
>> That why I would like to suggest to use the name service field to
>> identify the port/controller, instead of the endpoint address.
>>>
>>>> - match the RPMsg probe with the DT,
>>>
>>> We can probe from all controllers with a single name service
>>> announcement too.
>>>
>>>> - provide a simple mapping between the port and the endpoint on both
>>>> sides,
>>>
>>> We are trying to get rid of this mapping from Linux side to adapt
>>> the gpio-virtio design.
>>>
>>>> - allow multiple endpoints on the remote side,
>>>
>>> We can support this as well with single nameservice model.
>>> There is no limitation. Remote has to send a message with
>>> its newly created ept that's all.
>>>
>>>> - provide a simple discovery mechanism for remote capabilities.
>>>
>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>
>>> Feel free to let me know if you have concerns with any of the
>>> suggestions!
>> My only concern, whatever the solution, is that we find a smart
>> solution to associate the correct endpoint with the correct GPIO
>> port/controller defined in the DT.
>>
>> I may have misunderstood your solution. Could you please help me
>> understand your proposal by explaining how you would handle three
>> GPIO ports defined in the DT, considering that the endpoint
>> addresses on the Linux side can be random?
>> If I assume there is a unique endpoint on the remote side,
>> I do not understand how you can match, on the firmware side,
>> the Linux endpoint address to the GPIO port.
>>
>> Thanks and Regards,Arnaud
>>
>>> Thanks,
>>> Beleswar
>>>
>>>> Regards,
>>>> Arnaud
>>>>
>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>> a. ept1 -> i2c@1
>>>>>> b. ept2 -> i2c@2
>>>>>> c. ept3 -> i2c@3
>>>>>>
>>>>>> etc...
>>>>>>
> Just want to clear-up few terms before I jump to the solution:
>
> **RPMsg channel/device**:
> - These are devices announced by the remote processor, and created by
> linux. They are created at: /sys/bus/rpmsg/devices
> - The channel format: <name>.<src ept>.<dst ept>
>
> **RPMsg endpoint**:
> - Endpoint is differnt than channel. Single channel can have multiple
> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>
> To create endpoint device, we have rpmsg_create_ept API, which takes
> channel information as input, which has src-ept, dst-ept.
>
> Following is proposed solution:
>
> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
> pin/port).
One channel per pin was not suggested earlier...
> - In our case that would be, single rpmsg-io node. (That makes me
> question if bindings are correct or not).
>
> 2) Assign GPIO number as src ept.
>
> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
> endpoint.
>
> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
> add 1024 offset to the GPIO number:
>
> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>
> Now on the remote side, there is single channel and only single-endpoint
> is needed that is mapped to the rpmsg-io channel callback.
>
> That callback will receive all the payloads from the Linux, which will
> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
>
> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
> on platform specific logic.
>
> This doesn't need PORT information at all. Also it makes sure that
> remote is using only single-endpoint so not much memory is used.
>
> *Example*:
> If only rpmsg-gpio channel is created by the remote side, than following
> is the representation of the devices when GPIO 25, 26, 27 is assigned to
> the rpmsg-io controller:
>
> Linux Remote
>
> rpmsg-channel: rpmsg-gpio.0x400.0x400
>
> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
> |
> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
> |
> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-| 0x400 ept callback.
>
>
> *On remote side*:
>
> ept_0x400_callback(..., int src_ept, ...,)
> {
> int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
> // platform specific logic to convert gpio num to proper pin,
> // just like you would convert gpio num to pin on a linux gpio controller.
> }
>
> My question on the binding:
>
> Why each GPIO is represented with the separate node? I think rpmsg-gpio
> can be represented just any other GPIO controller? Please let me know if
> I am missing something.
These are separate GPIO controllers, not separate pins within
the same GPIO controller. Could you revisit your solution with
this update.
Thanks for your time,
Beleswar
^ permalink raw reply
* Re: [PATCH 8/9] docs: maintainers_include: don't ignore invalid profile entries
From: Gary Guo @ 2026-05-05 11:16 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Miguel Ojeda
Cc: Jonathan Corbet, Linux Doc Mailing List, Mauro Carvalho Chehab,
linux-kernel, rust-for-linux, Björn Roy Baron, Alice Ryhl,
Andreas Hindborg, Benno Lossin, Boqun Feng, Danilo Krummrich,
Gary Guo, Miguel Ojeda, Shuah Khan, Trevor Gross
In-Reply-To: <20260505074534.5fefbed0@foz.lan>
On Tue May 5, 2026 at 6:45 AM BST, Mauro Carvalho Chehab wrote:
> On Tue, 5 May 2026 02:20:45 +0200
> Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> wrote:
>
>> On Tue, May 5, 2026 at 2:08 AM Mauro Carvalho Chehab
>> <mchehab+huawei@kernel.org> wrote:
>> >
>> > Also, with time, maintainers may change their employers while still
>> > keeping their maintainership status.
>> >
>> > So, I'd say that whatever is there at the "P" entry, or where it is
>> > located (either on a ReST file at the Kernel or on some external URL),
>> > it should reflect the model that a maintainer or subsystem community
>> > that actively participate at the Kernel development agrees with.
>> > This should be vendor-agnostic.
>>
>> I am not sure what you mean. By "vendored" I don't mean
>> companies/employers, I mean that the file comes from an upstream
>> repository:
>>
>> https://github.com/Rust-for-Linux/pin-init/blob/main/CONTRIBUTING.md
>>
>> Nevertheless, it is true that this really is a special case, in that
>> the upstream project decided to provide something that could then be
>> fit into the `P:` field.
>>
>> One could say "let's ask them to do rst upstream", but to be honest,
>> it is simpler to just put a hyperlink to GitHub's rendered file.
>> Markdown is anyway a better fit for their file.
>
> Ok. Then it P entry could be:
>
> P: https://github.com/Rust-for-Linux/pin-init/blob/main/CONTRIBUTING.md
If you send a patch I can queue it up for 7.2. Or would you want this to be
taken via docs tree instead?
Best,
Gary
^ permalink raw reply
* Re: [PATCH 6/6] KVM: PPC: Document KVM_PPC_GET_COMPAT_CAPS ioctl
From: Harsh Prateek Bora @ 2026-05-05 9:55 UTC (permalink / raw)
To: Amit Machhiwal, linuxppc-dev, Madhavan Srinivasan
Cc: Vaibhav Jain, Paolo Bonzini, Jonathan Corbet, Shuah Khan, kvm,
linux-kernel, linux-doc
In-Reply-To: <20260430054906.94431-7-amachhiw@linux.ibm.com>
On 30/04/26 11:19 am, Amit Machhiwal wrote:
> Add documentation for the KVM_PPC_GET_COMPAT_CAPS ioctl to the KVM API
> documentation.
>
> The ioctl exposes host processor compatibility modes supported for
> nested KVM guests on PowerPC systems.
>
> Signed-off-by: Amit Machhiwal <amachhiw@linux.ibm.com>
> ---
> Documentation/virt/kvm/api.rst | 35 ++++++++++++++++++++++++++++++++++
> 1 file changed, 35 insertions(+)
>
> diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst
> index 52bbbb553ce1..7a10c3c6cbf1 100644
> --- a/Documentation/virt/kvm/api.rst
> +++ b/Documentation/virt/kvm/api.rst
> @@ -6555,6 +6555,41 @@ KVM_S390_KEYOP_SSKE
>
> .. _kvm_run:
>
> +4.145 KVM_PPC_GET_COMPAT_CAPS
> +-----------------------------
> +:Capability: KVM_CAP_PPC_COMPAT_CAPS
> +:Architectures: powerpc
> +:Type: vm ioctl
> +:Parameters: struct kvm_ppc_compat_caps (out)
> +:Returns:
> + 0 on successful completion,
> + -EFAULT if ``struct kvm_ppc_compat_caps`` cannot be written
-EINVAL also needs to be documented?
> +
> +IBM POWER system server-based processors provide a compatibility mode feature
> +where an Nth generation processor can operate in modes consistent with earlier
> +generations such as (N-1) and (N-2).
> +
> +This ioctl provides userspace with information about the CPU compatibility modes
> +supported by the current host processor for booting the nested KVM guests on
> +PowerNV (KVM nested APIv1) and PowerVM (KVM nested APIv2) platforms.
> +
> +::
> +
> + struct kvm_ppc_compat_caps {
> + __u32 flags;
> + __u64 compat_capabilities; /* Capabilities supported by the host */
> + };
> +
> +The ``compat_capabilities`` bit field describes the processor compatibility
> +modes supported by the host. For example, the following bits indicate support
> +for specific processor modes.
> +
> +::
> +
> + bit 1: KVM guests can run in Power9 processor mode
> + bit 2: KVM guests can run in Power10 processor mode
> + bit 3: KVM guests can run in Power11 processor mode
May be use H_GUEST_CAP_POWER9 and friends ?
> +
> 5. The kvm_run structure
> ========================
>
^ permalink raw reply
* Re: [PATCH v7 6/6] ARM: zte: defconfig: Add a zx29 defconfig file
From: Linus Walleij @ 2026-05-05 9:54 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260429-send-v7-6-b432e00d2db8@gmail.com>
On Wed, Apr 29, 2026 at 9:14 PM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:
> This enables existing drivers for hardware that is present on this board
> even if it is not present in the DT yet.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
I'm in favor of this, mainly because multi_v7 is pretty useless
for this board, it is absolutely too big to boot on the machine,
the board is odd and need some ARM64 stuff.
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v7 5/6] ARM: dts: zte: Add D-Link DWR-932M support
From: Linus Walleij @ 2026-05-05 9:53 UTC (permalink / raw)
To: Stefan Dösinger
Cc: Jonathan Corbet, Shuah Khan, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Arnd Bergmann,
Krzysztof Kozlowski, Alexandre Belloni, Drew Fustini,
Greg Kroah-Hartman, Jiri Slaby, linux-doc, linux-kernel,
linux-arm-kernel, devicetree, soc, linux-serial
In-Reply-To: <20260429-send-v7-5-b432e00d2db8@gmail.com>
On Wed, Apr 29, 2026 at 9:14 PM Stefan Dösinger
<stefandoesinger@gmail.com> wrote:
> This adds base DT definition for zx297520v3 and one board that consumes it.
>
> The stock kernel does not use the armv7 timer, but it seems to work
> fine. The board has other board-specific timers that would need a driver
> and I see no reason to bother with them since the arm standard timer
> works.
>
> The caveat is the non-standard GIC setup needed to handle the timer's
> level-low PPI. This is the responsibility of the boot loader and
> documented in Documentation/arch/arm/zte/zx297520v3.rst.
>
> Signed-off-by: Stefan Dösinger <stefandoesinger@gmail.com>
Reviewed-by: Linus Walleij <linusw@kernel.org>
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
From: Herbert Xu @ 2026-05-05 9:31 UTC (permalink / raw)
To: Eric Biggers
Cc: linux-crypto, linux-doc, linux-api, linux-kernel, netdev,
Linus Torvalds
In-Reply-To: <20260430011544.31823-1-ebiggers@kernel.org>
On Wed, Apr 29, 2026 at 06:15:44PM -0700, Eric Biggers wrote:
> AF_ALG is almost completely unnecessary, and it exposes a massive attack
> surface that hasn't been standing up to modern vulnerability discovery
> tools. The latest one even has its own website, providing a small
> Python script that reliably roots most Linux distros: https://copy.fail/
>
> This isn't sustainable, especially as LLMs have accelerated the rate the
> vulnerabilities are coming in. The effort that is being put into this
> thing is vastly disproportional to the few programs that actually use
> it, and those programs would be better served by userspace code anyway.
>
> These issues have been noted in many mailing list discussions already.
> But until now they haven't been reflected in the documentation or
> kconfig menu itself, and the vulnerabilities are still coming in.
>
> Let's go ahead and document the deprecation.
>
> This isn't intended to change anything overnight. After all, most Linux
> distros won't be able to disable the kconfig options quite yet, mainly
> because of iwd. But this should create a bit more impetus for these
> userspace programs to be fixed, and the documentation update should also
> help prevent more users from appearing.
>
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>
> This patch is targeting crypto/master
>
> Documentation/crypto/userspace-if.rst | 82 ++++++++++++++++++++-------
> crypto/Kconfig | 69 ++++++++++++++++------
> 2 files changed, 113 insertions(+), 38 deletions(-)
Patch applied. Thanks.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Arnaud POULIQUEN @ 2026-05-05 9:28 UTC (permalink / raw)
To: tanmay.shah, Beleswar Prasad Padhi, Mathieu Poirier
Cc: Shenwei Wang, Andrew Lunn, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Frank Li, Sascha Hauer, Shuah Khan,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski
In-Reply-To: <c6f68ab5-271a-41ed-b285-75b739f1edd6@amd.com>
Hi Tanmay,
On 5/4/26 21:19, Shah, Tanmay wrote:
>
> Hello all,
>
> I have started reviewing this work as well.
> Thanks Shenwei for this work.
>
> I have gone through only the current revision, and would like to provide
> idea on how to achieve GPIO number multiplexing with the RPMsg protocol.
> Also, have some bindings related question.
>
> Please see below:
>
> On 4/30/2026 11:40 AM, Arnaud POULIQUEN wrote:
>>
>>
>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>> Hello Arnaud,
>>>
>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>> Hello,
>>>>
>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>
>>>>>> Hi Mathieu,
>>>>>>
>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Mathieu Poirier <mathieu.poirier@linaro.org>
>>>>>>>>> Sent: Wednesday, April 29, 2026 10:42 AM
>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>> Cc: Andrew Lunn <andrew@lunn.ch>; Padhi, Beleswar <b-
>>>>>>>>> padhi@ti.com>; Linus
>>>>>>>>> Walleij <linusw@kernel.org>; Bartosz Golaszewski
>>>>>>>>> <brgl@kernel.org>; Jonathan
>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>;
>>>>>>>>> Krzysztof Kozlowski
>>>>>>>>> <krzk+dt@kernel.org>; Conor Dooley <conor+dt@kernel.org>; Bjorn
>>>>>>>>> Andersson
>>>>>>>>> <andersson@kernel.org>; Frank Li <frank.li@nxp.com>; Sascha Hauer
>>>>>>>>> <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>> <skhan@linuxfoundation.org>; linux-
>>>>>>>>> gpio@vger.kernel.org; linux-doc@vger.kernel.org; linux-
>>>>>>>>> kernel@vger.kernel.org;
>>>>>>>>> Pengutronix Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>> devicetree@vger.kernel.org; linux-remoteproc@vger.kernel.org;
>>>>>>>>> imx@lists.linux.dev; linux-arm-kernel@lists.infradead.org; dl-
>>>>>>>>> linux-imx <linux-
>>>>>>>>> imx@nxp.com>; Bartosz Golaszewski <brgl@bgdev.pl>
>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic
>>>>>>>>> rpmsg GPIO driver
>>>>>>>>> On Tue, Apr 28, 2026 at 03:24:59PM +0000, Shenwei Wang wrote:
>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Andrew Lunn <andrew@lunn.ch>
>>>>>>>>>>> Sent: Monday, April 27, 2026 3:49 PM
>>>>>>>>>>> To: Shenwei Wang <shenwei.wang@nxp.com>
>>>>>>>>>>> Cc: Padhi, Beleswar <b-padhi@ti.com>; Linus Walleij
>>>>>>>>>>> <linusw@kernel.org>; Bartosz Golaszewski <brgl@kernel.org>;
>>>>>>>>>>> Jonathan
>>>>>>>>>>> Corbet <corbet@lwn.net>; Rob Herring <robh@kernel.org>; Krzysztof
>>>>>>>>>>> Kozlowski <krzk+dt@kernel.org>; Conor Dooley
>>>>>>>>>>> <conor+dt@kernel.org>;
>>>>>>>>>>> Bjorn Andersson <andersson@kernel.org>; Mathieu Poirier
>>>>>>>>>>> <mathieu.poirier@linaro.org>; Frank Li <frank.li@nxp.com>; Sascha
>>>>>>>>>>> Hauer <s.hauer@pengutronix.de>; Shuah Khan
>>>>>>>>>>> <skhan@linuxfoundation.org>; linux-gpio@vger.kernel.org; linux-
>>>>>>>>>>> doc@vger.kernel.org; linux-kernel@vger.kernel.org; Pengutronix
>>>>>>>>>>> Kernel Team <kernel@pengutronix.de>; Fabio Estevam
>>>>>>>>>>> <festevam@gmail.com>; Peng Fan <peng.fan@nxp.com>;
>>>>>>>>>>> devicetree@vger.kernel.org; linux- remoteproc@vger.kernel.org;
>>>>>>>>>>> imx@lists.linux.dev; linux-arm- kernel@lists.infradead.org;
>>>>>>>>>>> dl-linux-imx <linux-imx@nxp.com>; Bartosz Golaszewski
>>>>>>>>>>> <brgl@bgdev.pl>
>>>>>>>>>>> Subject: [EXT] Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg
>>>>>>>>>>> GPIO driver
>>>>>>>>>>>>> struct virtio_gpio_response {
>>>>>>>>>>>>> __u8 status;
>>>>>>>>>>>>> __u8 value;
>>>>>>>>>>>>> };
>>>>>>>>>>>> It is the same message format. Please see the message definition
>>>>>>>>>>> (GET_DIRECTION) below:
>>>>>>>>>>>
>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>>> + |0x00 |0x01 |0x02 |0x03 |0x04 |0x05|
>>>>>>>>>>>> + | 1 | 2 |port |line | err | dir|
>>>>>>>>>>>> + +-----+-----+-----+-----+-----+----+
>>>>>>>>>>> Sorry, but i don't see how two u8 vs six u8 are the same
>>>>>>>>>>> message format.
>>>>>>>>>>>
>>>>>>>>>> Some changes to the message format are necessary.
>>>>>>>>>>
>>>>>>>>>> Virtio uses two communication channels (virtqueues): one for
>>>>>>>>>> requests and
>>>>>>>>> replies, and a second one for events.
>>>>>>>>>> In contrast, rpmsg provides only a single communication
>>>>>>>>>> channel, so a
>>>>>>>>>> type field is required to distinguish between different kinds
>>>>>>>>>> of messages.
>>>>>>>>>>
>>>>>>>>>> Since rpmsg replies and events share the same message format,
>>>>>>>>>> an additional
>>>>>>>>> line is introduced to handle both cases.
>>>>>>>>>> Finally, rpmsg supports multiple GPIO controllers, so a port
>>>>>>>>>> field is added to
>>>>>>>>> uniquely identify the target controller.
>>>>>>>>>
>>>>>>>>> I have commented on this before - RPMSG is already providing
>>>>>>>>> multiplexing
>>>>>>>>> capability by way of endpoints. There is no need for a port
>>>>>>>>> field. One endpoint,
>>>>>>>>> one GPIO controller.
>>>>>>>>>
>>>>>>>> You still need a way to let the remote side know which port the
>>>>>>>> endpoint maps to, either
>>>>>>>> by embedding the port information in the message (the current
>>>>>>>> way), or by sending it
>>>>>>>> separately.
>>>>>>>>
>>>>>>> An endpoint is created with every namespace request. There should be
>>>>>>> one namespace request for every GPIO controller, which yields a
>>>>>>> unique
>>>>>>> endpoint for each controller and eliminates the need for an extra
>>>>>>> field to identify them.
>>>>>>
>>>>>>
>>>>>> Right, but this can still be done by just having one namespace
>>>>>> request.
>>>>>> We can create new endpoints bound to an existing namespace/channel by
>>>>>> invoking rpmsg_create_ept(). This is what I suggested here too:
>>>>>> https://lore.kernel.org/all/29485742-6e49-482e-
>>>>>> b73d-228295daaeec@ti.com/
>>>>>>
>>>>>
>>>>> I will look at your suggestion (i.e link above) later this week or
>>>>> next week.
>>>>>
>>>>>> My mental model looks like this for the complete picture:
>>>>>>
>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>> a. ept1 -> gpio-controller@1
>>>>>> b. ept2 -> gpio-controller@2
>>>>>>
>
> If my understanding of what gpio-controller is right, than this won't
> work. We need one rpmsg channel per gpio-controller, and in most cases
> there will be only one GPIO-controller on the remote side. If there are
> multiple or multiple instances of same controller, than we need separate
> channel name for that controller just like we would have separate device
> on the Linux.
As done in ehe rpmsg_tty driver it could be instantiated several times with
the same channel/service name. This would imply a specific rpmsg to retreive
the gpio controller index from the remote side.
>
>>>>>
>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>> beginning. I don't yet have a strong opinion on whether to use one
>>>>> namespace request per GPIO controller or a single request that spins
>>>>> off multiple endpoints. I'll have to look at your link and reflect on
>>>>> that. Regardless of how we proceed on that front, multiplexing needs
>>>>> to happen at the endpoint level rather than the packet level. This is
>>>>> the only way this work can move forward.
>>>>>
>>>>
>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is
>>>> created with every namespace request.”
>>>>
>>>> If the endpoint is created only on the Linux side, how do we match
>>>> the Linux endpoint address with the local port field on the remote side?
>>>
>>>
>>> Simply by sending a message to the remote containing the newly created
>>> endpoint and the port idx. Note that is this done just one time, after
>>> this
>>> Linux need not have the port field in the message everytime its sending
>>> a message.
>>>
>>>>
>>>> With a multi-namespace approach, the namespace could be rpmsg-io-
>>>> [addr], where [addr] corresponds to the GPIO controller address in
>>>> the DT. This would:
>>>
>>>
>>> You will face the same problem in this case also that you asked above:
>>> "how do we match the Linux endpoint address with the local port field
>>> on the remote side?"
>>
>> Sorry I probably introduced confusion here
>> my sentence should be;
>> With a multi-namespace approach, the namespace could be rpmsg-io-[port],
>> where [port] corresponds to the GPIO controller port in the DT.
>>
>>
>> For instance:
>>
>> rpmsg {
>> rpmsg-io {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> gpio@25 {
>> compatible = "rpmsg-gpio";
>> reg = <25>;
>> gpio-controller;
>> #gpio-cells = <2>;
>> #interrupt-cells = <2>;
>> interrupt-controller;
>> };
>>
>> gpio@32 {
>> compatible = "rpmsg-gpio";
>> reg = <32>;
>> gpio-controller;
>> #gpio-cells = <2>;
>> #interrupt-cells = <2>;
>> interrupt-controller;
>> };
>> };
>> };
>>
>> rpmsg-io-25 would match with gpio@25
>> rpmsg-io-32 would match with gpio@32
>>
>
> The problem with this approach is, we will endup creating way too many
> RPMsg devices/channels. i.e. one channel per one GPIO. That limits how
> many GPIOs can be handled by remote from memory perspective. At
> somepoint we might just run-out of number ept & channels created by the
> remote. As of now, open-amp library supports 128 epts I think.
Right, I proposed a solution in my previous answer to Beleswar who has
the same concern.
>
>>
>>>
>>> Because the endpoint that is created on a namespace request is also
>>> dynamic in nature. How will the remote know which endpoint addr
>>> Linux allocated for a namespace that it announced?
>>>
>>> As an example/PoC, I created a firmware example which announces
>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>> the name service request from the same firmware:
>>>
>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel
>>> ti.ipc4.ping-pong addr 0xd
>>> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev
>>> addr 0xe
>>> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel
>>> formed from src = 0x400 to dst = 0xe
>>> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13:
>>> new channel: 0x401 -> 0xd!
>>>
>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>> Back to same problem. Simple solution is to reply to remote with the
>>> created ept addr and the index.
>>
>> That why I would like to suggest to use the name service field to
>> identify the port/controller, instead of the endpoint address.
>>>
>>>>
>>>> - match the RPMsg probe with the DT,
>>>
>>>
>>> We can probe from all controllers with a single name service
>>> announcement too.
>>>
>>>> - provide a simple mapping between the port and the endpoint on both
>>>> sides,
>>>
>>>
>>> We are trying to get rid of this mapping from Linux side to adapt
>>> the gpio-virtio design.
>>>
>>>> - allow multiple endpoints on the remote side,
>>>
>>>
>>> We can support this as well with single nameservice model.
>>> There is no limitation. Remote has to send a message with
>>> its newly created ept that's all.
>>>
>>>> - provide a simple discovery mechanism for remote capabilities.
>>>
>>>
>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>
>>> Feel free to let me know if you have concerns with any of the
>>> suggestions!
>>
>> My only concern, whatever the solution, is that we find a smart
>> solution to associate the correct endpoint with the correct GPIO
>> port/controller defined in the DT.
>>
>> I may have misunderstood your solution. Could you please help me
>> understand your proposal by explaining how you would handle three
>> GPIO ports defined in the DT, considering that the endpoint
>> addresses on the Linux side can be random?
>> If I assume there is a unique endpoint on the remote side,
>> I do not understand how you can match, on the firmware side,
>> the Linux endpoint address to the GPIO port.
>>
>> Thanks and Regards,Arnaud
>>
>>>
>>> Thanks,
>>> Beleswar
>>>
>>>>
>>>> Regards,
>>>> Arnaud
>>>>
>>>>>> 2. namespace/channel#2 = rpmsg-i2c
>>>>>> a. ept1 -> i2c@1
>>>>>> b. ept2 -> i2c@2
>>>>>> c. ept3 -> i2c@3
>>>>>>
>>>>>> etc...
>>>>>>
>
> Just want to clear-up few terms before I jump to the solution:
>
> **RPMsg channel/device**:
> - These are devices announced by the remote processor, and created by
> linux. They are created at: /sys/bus/rpmsg/devices
> - The channel format: <name>.<src ept>.<dst ept>
>
> **RPMsg endpoint**:
> - Endpoint is differnt than channel. Single channel can have multiple
> endpoints, and represented in the linux with: /dev/rpmsg? devices.
>
> To create endpoint device, we have rpmsg_create_ept API, which takes
> channel information as input, which has src-ept, dst-ept.
>
> Following is proposed solution:
>
> 1) Assign RPMsg channel/device per rpmsg-gpio controller (Not per GPIO
> pin/port).
> - In our case that would be, single rpmsg-io node. (That makes me
> question if bindings are correct or not).
>
> 2) Assign GPIO number as src ept.
>
> i.e. *rpmsg-io.<GPIO number>.<dst ept>*. Do not randomly assign src
> endpoint.
>
> Now, RPMSG channel by spec reserves first 1024 endpoints [1], so we can
> add 1024 offset to the GPIO number:
>
> so, when calling rpmsg_create_ept() API, we assing src_endpoint as:
> (GPIO_NUMBER + RPMSG_RESERVED_ADDRESSES)
>
> Now on the remote side, there is single channel and only single-endpoint
> is needed that is mapped to the rpmsg-io channel callback.
>
> That callback will receive all the payloads from the Linux, which will
> have src-ept i.e. (RPMSG_RESERVED_ADDRESSES + GPIO_NUMBER).
Interesting approach. I also tried to find a similar solution.
The question here is: how can we guarantee continuous addresses? Given
the static and dynamic allocation of endpoint addresses that are
implemented, my conclusion was that it is not reliable enough.
but perhaps I missed something...
>
> It can retrieve GPIO_NUMBER easily, and convert to appropriate pin based
> on platform specific logic.
>
> This doesn't need PORT information at all. Also it makes sure that
> remote is using only single-endpoint so not much memory is used.
>
> *Example*:
> If only rpmsg-gpio channel is created by the remote side, than following
> is the representation of the devices when GPIO 25, 26, 27 is assigned to
> the rpmsg-io controller:
>
> Linux Remote
>
> rpmsg-channel: rpmsg-gpio.0x400.0x400
>
> /dev/rpmsg0 - GPIO25 ept (rpmsg-gpio.0x419.0x400)-|
> |
> /dev/rpmsg1 - GPIO26 ept (rpmsg-gpio.0x41a.0x400)-|-> rpmsg-gpio.*.0x400
> |
> /dev/rpmsg2 - GPIO27 ept (rpmsg-gpio.0x41b.0x400)-| 0x400 ept callback.
>
>
> *On remote side*:
>
> ept_0x400_callback(..., int src_ept, ...,)
> {
> int gpio_num = src_ept - RPMSG_RESERVED_ADDRESSES;
> // platform specific logic to convert gpio num to proper pin,
> // just like you would convert gpio num to pin on a linux gpio controller.
> }
>
> My question on the binding:
>
> Why each GPIO is represented with the separate node? I think rpmsg-gpio
> can be represented just any other GPIO controller? Please let me know if
> I am missing something. So rpmsg channel/rpmsg device is not created per
> GPIO, but per controller. GPIO number multiplexing should be done with
> rpmsg src ept, that removes the need of having each GPIO as a separate node.
>
>
> rpmsg_gpio: rpmsg-gpio@0 {
> compatible = "rpmsg-gpio";
> reg = <0>;
> gpio-controller;
> #gpio-cells = <2>;
> #interrupt-cells = <2>;
> interrupt-controller;
> };
>
> Then in DT, use like regular GPIO, but with the rpmsg-gpio controller:
>
> rpmsg-gpios = <&rpmsg_gpio (GPIO NUM) (flags)>;
>
> If the intent to create separate gpio nodes was only for the channel
> creation, then it's not really needed.
>
> [1]
> https://github.com/torvalds/linux/blob/6d35786de28116ecf78797a62b84e6bf3c45aa5a/drivers/rpmsg/virtio_rpmsg_bus.c#L136
>
It is already the case. bindings declare GPIO controllers, not directly
GPIOs in:
[PATCH v13 2/4] dt-bindings: remoteproc: imx_rproc: Add "rpmsg" subnode
support
The discussion is around having an unique RPmsg endpoint for all
GPIO controller or one RPmsg endpoint per GPIO controller.
Or did I misunderstand your questions?
Thanks,
Arnaud
>>>>>> This way device groups are isolated with each channel/namespace, and
>>>>>> instances within each device groups are also respected with specific
>>>>>> endpoints.
>>>>>>
>>>>>> Thanks,
>>>>>> Beleswar
>>>>>>
>>>>>
>>>>
>>
>>
>
^ permalink raw reply
* [PATCH v3 1/5] watchdog: Change suffix .txt to .rst in references
From: Philipp Hahn @ 2026-05-05 9:26 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck
Cc: Philipp Hahn, linux-watchdog, linux-doc, linux-kernel
In-Reply-To: <cover.1777972790.git.phahn-oss@avm.de>
From: Philipp Hahn <phahn-oss@avm.de>
Fix link to documentation, which has already been converted to reST.
Also remove apostrophes which are no longer needed.
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
---
Documentation/watchdog/convert_drivers_to_kernel_api.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/watchdog/convert_drivers_to_kernel_api.rst b/Documentation/watchdog/convert_drivers_to_kernel_api.rst
index e83609a5d0071..9eddb962f8e4c 100644
--- a/Documentation/watchdog/convert_drivers_to_kernel_api.rst
+++ b/Documentation/watchdog/convert_drivers_to_kernel_api.rst
@@ -114,7 +114,7 @@ Add the watchdog operations
---------------------------
All possible callbacks are defined in 'struct watchdog_ops'. You can find it
-explained in 'watchdog-kernel-api.txt' in this directory. start() and
+explained in watchdog-kernel-api.rst in this directory. start() and
owner must be set, the rest are optional. You will easily find corresponding
functions in the old driver. Note that you will now get a pointer to the
watchdog_device as a parameter to these functions, so you probably have to
@@ -153,7 +153,7 @@ Add the watchdog device
Now we need to create a 'struct watchdog_device' and populate it with the
necessary information for the framework. The struct is also explained in detail
-in 'watchdog-kernel-api.txt' in this directory. We pass it the mandatory
+in watchdog-kernel-api.rst in this directory. We pass it the mandatory
watchdog_info struct and the newly created watchdog_ops. Often, old drivers
have their own record-keeping for things like bootstatus and timeout using
static variables. Those have to be converted to use the members in
--
2.43.0
^ permalink raw reply related
* [PATCH v3 2/5] watchdog: Move `struct` before name
From: Philipp Hahn @ 2026-05-05 9:26 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck
Cc: Philipp Hahn, linux-watchdog, linux-doc, linux-kernel
In-Reply-To: <cover.1777972790.git.phahn-oss@avm.de>
From: Philipp Hahn <phahn-oss@avm.de>
Write `struct ` before the structure name as Sphinx otherwise uses the
following word after it. See
https://docs.kernel.org/watchdog/watchdog-api.html#environmental-monitoring
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
---
.../convert_drivers_to_kernel_api.rst | 24 +++++++++----------
Documentation/watchdog/watchdog-api.rst | 2 +-
.../watchdog/watchdog-kernel-api.rst | 2 +-
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/Documentation/watchdog/convert_drivers_to_kernel_api.rst b/Documentation/watchdog/convert_drivers_to_kernel_api.rst
index 9eddb962f8e4c..004fe6ef76e94 100644
--- a/Documentation/watchdog/convert_drivers_to_kernel_api.rst
+++ b/Documentation/watchdog/convert_drivers_to_kernel_api.rst
@@ -11,12 +11,12 @@ This document shall guide you for this task. The necessary steps are described
as well as things to look out for.
-Remove the file_operations struct
+Remove the struct file_operations
---------------------------------
Old drivers define their own file_operations for actions like open(), write(),
etc... These are now handled by the framework and just call the driver when
-needed. So, in general, the 'file_operations' struct and assorted functions can
+needed. So, in general, the struct file_operations and assorted functions can
go. Only very few driver-specific details have to be moved to other functions.
Here is a overview of the functions and probably needed actions:
@@ -36,7 +36,7 @@ Here is a overview of the functions and probably needed actions:
from the driver:
WDIOC_GETSUPPORT:
- Returns the mandatory watchdog_info struct from the driver
+ Returns the mandatory struct watchdog_info from the driver
WDIOC_GETSTATUS:
Needs the status-callback defined, otherwise returns 0
@@ -88,8 +88,8 @@ refactoring. The rest can go.
Remove the miscdevice
---------------------
-Since the file_operations are gone now, you can also remove the 'struct
-miscdevice'. The framework will create it on watchdog_dev_register() called by
+Since the file_operations are gone now, you can also remove the struct
+miscdevice. The framework will create it on watchdog_dev_register() called by
watchdog_register_device()::
-static struct miscdevice s3c2410wdt_miscdev = {
@@ -113,10 +113,10 @@ them. Includes can be removed, too. For example::
Add the watchdog operations
---------------------------
-All possible callbacks are defined in 'struct watchdog_ops'. You can find it
+All possible callbacks are defined in struct watchdog_ops. You can find it
explained in watchdog-kernel-api.rst in this directory. start() and
owner must be set, the rest are optional. You will easily find corresponding
-functions in the old driver. Note that you will now get a pointer to the
+functions in the old driver. Note that you will now get a pointer to the struct
watchdog_device as a parameter to these functions, so you probably have to
change the function header. Other changes are most likely not needed, because
here simply happens the direct hardware access. If you have device-specific
@@ -151,12 +151,12 @@ A typical function-header change looks like::
Add the watchdog device
-----------------------
-Now we need to create a 'struct watchdog_device' and populate it with the
-necessary information for the framework. The struct is also explained in detail
+Now we need to create a struct watchdog_device and populate it with the
+necessary information for the framework. The structure is also explained in detail
in watchdog-kernel-api.rst in this directory. We pass it the mandatory
-watchdog_info struct and the newly created watchdog_ops. Often, old drivers
+struct watchdog_info and the newly created struct watchdog_ops. Often, old drivers
have their own record-keeping for things like bootstatus and timeout using
-static variables. Those have to be converted to use the members in
+static variables. Those have to be converted to use the members in struct
watchdog_device. Note that the timeout values are unsigned int. Some drivers
use signed int, so this has to be converted, too.
@@ -174,7 +174,7 @@ Handle the 'nowayout' feature
A few drivers use nowayout statically, i.e. there is no module parameter for it
and only CONFIG_WATCHDOG_NOWAYOUT determines if the feature is going to be
used. This needs to be converted by initializing the status variable of the
-watchdog_device like this::
+struct watchdog_device like this::
.status = WATCHDOG_NOWAYOUT_INIT_STATUS,
diff --git a/Documentation/watchdog/watchdog-api.rst b/Documentation/watchdog/watchdog-api.rst
index 78e228c272cf8..2c138eaa43397 100644
--- a/Documentation/watchdog/watchdog-api.rst
+++ b/Documentation/watchdog/watchdog-api.rst
@@ -158,7 +158,7 @@ available to ask what the device can do::
struct watchdog_info ident;
ioctl(fd, WDIOC_GETSUPPORT, &ident);
-the fields returned in the ident struct are:
+the fields returned in the struct watchdog_info are:
================ =============================================
identity a string identifying the watchdog driver
diff --git a/Documentation/watchdog/watchdog-kernel-api.rst b/Documentation/watchdog/watchdog-kernel-api.rst
index 5649c54cf6fbe..e2c1386c95509 100644
--- a/Documentation/watchdog/watchdog-kernel-api.rst
+++ b/Documentation/watchdog/watchdog-kernel-api.rst
@@ -257,7 +257,7 @@ bit-operations. The status bits that are defined are:
To set the WDOG_NO_WAY_OUT status bit (before registering your watchdog
timer device) you can either:
- * set it statically in your watchdog_device struct with
+ * set it statically in your struct watchdog_device with
.status = WATCHDOG_NOWAYOUT_INIT_STATUS,
--
2.43.0
^ permalink raw reply related
* [PATCH v3 4/5] watchdog: Separate kind of documentation
From: Philipp Hahn @ 2026-05-05 9:26 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck
Cc: Philipp Hahn, linux-watchdog, linux-doc, linux-kernel
In-Reply-To: <cover.1777972790.git.phahn-oss@avm.de>
From: Philipp Hahn <phahn-oss@avm.de>
Currently there are several (sub-)documents for "Generic kernel
infrastructure API" and several "driver specific" documents. Put each
one into its own sub-section.
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
---
Documentation/watchdog/index.rst | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/Documentation/watchdog/index.rst b/Documentation/watchdog/index.rst
index 1cea24681e6bd..293ed05ba6b87 100644
--- a/Documentation/watchdog/index.rst
+++ b/Documentation/watchdog/index.rst
@@ -4,15 +4,25 @@
Watchdog Support
================
+Kernel infrastructure
+=====================
+
.. toctree::
:maxdepth: 1
- hpwdt
- mlx-wdt
- pcwd-watchdog
watchdog-api
watchdog-kernel-api
- watchdog-parameters
watchdog-pm
- wdt
convert_drivers_to_kernel_api
+
+Driver specific
+===============
+
+.. toctree::
+ :maxdepth: 1
+
+ watchdog-parameters
+ hpwdt
+ wdt
+ mlx-wdt
+ pcwd-watchdog
--
2.43.0
^ permalink raw reply related
* [PATCH v3 0/5] Cleanup Linux Watchdog documentation
From: Philipp Hahn @ 2026-05-05 9:26 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck
Cc: Philipp Hahn, linux-watchdog, linux-doc, linux-kernel
From: Philipp Hahn <phahn-oss@avm.de>
Hello,
while reading the documentation on the Linux kernel watchdog
subsystem[1] I noticed some strange looking formatting: `struct`s are
detected automatically by Sphinx and the word **after** it is considered
the name of the structure, but the watchdog documentation puts the name
**before** the word `struct`; this leads to the wrong word being
emphasized.
Also reorganize the index page to better separate the documentation on
generic infrastructure from specific drivers – which are mostly obsolete
and relevant for historic documentation only.
Please apply; thank you for all your work.
Philipp
[1]: https://docs.kernel.org/watchdog/convert_drivers_to_kernel_api.html
---
Philipp Hahn (5):
watchdog: Change suffix .txt to .rst in references
watchdog: Move `struct` before name
watchdog: Replace intermixed tab/space indent
watchdog: Separate kind of documentation
watchdog: Prefix WDT with ICS for clarity
v2 -> v1
- Rename wdt.rst to ics-wdt.rst
- Expand abbreviation "ICS" in more places
- Fix wrong reference to samples/watchdog/watchdog-simple.c
v1 -> v2
- Drop invalid SPDX change to Documentation/watchdog/index.rst
- Add SPDX to Documentation/watchdog/wdt.rst
.../convert_drivers_to_kernel_api.rst | 28 +++++++++----------
.../watchdog/{wdt.rst => ics-wdt.rst} | 8 ++++--
Documentation/watchdog/index.rst | 20 +++++++++----
Documentation/watchdog/watchdog-api.rst | 4 +--
.../watchdog/watchdog-kernel-api.rst | 2 +-
drivers/watchdog/Kconfig | 10 ++++---
drivers/watchdog/smsc37b787_wdt.c | 2 +-
7 files changed, 44 insertions(+), 30 deletions(-)
rename Documentation/watchdog/{wdt.rst => ics-wdt.rst} (91%)
--
2.43.0
^ permalink raw reply
* [PATCH v3 5/5] watchdog: Prefix WDT with ICS for clarity
From: Philipp Hahn @ 2026-05-05 9:26 UTC (permalink / raw)
To: Wim Van Sebroeck, Guenter Roeck
Cc: Philipp Hahn, linux-watchdog, linux-doc, linux-kernel
In-Reply-To: <cover.1777972790.git.phahn-oss@avm.de>
From: Philipp Hahn <phahn-oss@avm.de>
`wdt.rst` is only about the Watchdog from "Industrial Computer Source"
(ICS). Change the title and rename the file to better express this.
Add missing SPDX license identifier `GPL-2.0-or-later` same as code to
silence `checkpatch`.
Fix wrong link to sample driver in drivers/watchdog/smsc37b787_wdt.c.
Signed-off-by: Philipp Hahn <phahn-oss@avm.de>
---
Documentation/watchdog/{wdt.rst => ics-wdt.rst} | 8 +++++---
Documentation/watchdog/index.rst | 2 +-
drivers/watchdog/Kconfig | 10 ++++++----
drivers/watchdog/smsc37b787_wdt.c | 2 +-
4 files changed, 13 insertions(+), 9 deletions(-)
rename Documentation/watchdog/{wdt.rst => ics-wdt.rst} (91%)
diff --git a/Documentation/watchdog/wdt.rst b/Documentation/watchdog/ics-wdt.rst
similarity index 91%
rename from Documentation/watchdog/wdt.rst
rename to Documentation/watchdog/ics-wdt.rst
index d97b0361535b0..b0dc29e56358d 100644
--- a/Documentation/watchdog/wdt.rst
+++ b/Documentation/watchdog/ics-wdt.rst
@@ -1,6 +1,8 @@
-============================================================
-WDT Watchdog Timer Interfaces For The Linux Operating System
-============================================================
+.. SPDX-License-Identifier: GPL-2.0-or-later
+
+==========================================
+Industrial Computer Source Watchdog Driver
+==========================================
Last Reviewed: 10/05/2007
diff --git a/Documentation/watchdog/index.rst b/Documentation/watchdog/index.rst
index 293ed05ba6b87..dbc702b31a43e 100644
--- a/Documentation/watchdog/index.rst
+++ b/Documentation/watchdog/index.rst
@@ -23,6 +23,6 @@ Driver specific
watchdog-parameters
hpwdt
- wdt
+ ics-wdt
mlx-wdt
pcwd-watchdog
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index dc78729ba2a5d..43c2ee69caada 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -2270,10 +2270,11 @@ config MIXCOMWD
Most people will say N.
config WDT
- tristate "WDT Watchdog timer"
+ tristate "ICS WDT500P/501P Watchdog timer"
depends on ISA
help
- If you have a WDT500P or WDT501P watchdog board, say Y here,
+ If you have an Industrial Computer Source (ICS) WDT500P or WDT501P
+ watchdog board, say Y here,
otherwise N. It is not possible to probe for this board, which means
that you have to inform the kernel about the IO port and IRQ that
is needed (you can do this via the io and irq parameters)
@@ -2304,10 +2305,11 @@ config PCIPCWATCHDOG
Most people will say N.
config WDTPCI
- tristate "PCI-WDT500/501 Watchdog timer"
+ tristate "ICS PCI-WDT500/501 Watchdog timer"
depends on PCI && HAS_IOPORT
help
- If you have a PCI-WDT500/501 watchdog board, say Y here, otherwise N.
+ If you have an Industrial Computer Source (ICS) PCI-WDT500/501 watchdog
+ board, say Y here, otherwise N.
If you have a PCI-WDT501 watchdog board then you can enable the
temperature sensor by setting the type parameter to 501.
diff --git a/drivers/watchdog/smsc37b787_wdt.c b/drivers/watchdog/smsc37b787_wdt.c
index 3011e1af00f98..9f2c2ab4e2f15 100644
--- a/drivers/watchdog/smsc37b787_wdt.c
+++ b/drivers/watchdog/smsc37b787_wdt.c
@@ -36,7 +36,7 @@
* mknod /dev/watchdog c 10 130
*
* For an example userspace keep-alive daemon, see:
- * Documentation/watchdog/wdt.rst
+ * samples/watchdog/watchdog-simple.c
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
--
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