* Re: [PATCH v2] Fail the build on RUST=y and RUST_IS_AVAILABLE=n
From: Andreas Hindborg @ 2026-05-28 11:54 UTC (permalink / raw)
To: Sasha Finkelstein, Alice Ryhl, Benno Lossin, Björn Roy Baron,
Boqun Feng, Danilo Krummrich, Gary Guo, Jonathan Corbet,
Miguel Ojeda, Shuah Khan, Trevor Gross
Cc: Neal Gompa, linux-doc, linux-kernel, rust-for-linux,
Sasha Finkelstein
In-Reply-To: <20260521-evolve-to-crab-v2-1-c18e0e98fc54@chaosmail.tech>
"Sasha Finkelstein" <k@chaosmail.tech> writes:
> The current approach of silently disabling all rust drivers if the
> toolchain is missing results in users that try to compile their own
> kernels getting a "successful" build and then being confused about where
> did their drivers go. In comparison, missing openssl results in a build
> failure, not a disappearance of everything that depends on it.
>
> This also means that allyesconfig will depend on rust, but since the
> rust experiment concluded with "rust is here to stay", i believe that
> allyesconfig should be building rust drivers too.
>
> Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
This is long overdue.
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Best regards,
Andreas Hindborg
^ permalink raw reply
* Re: [PATCH v2] Fail the build on RUST=y and RUST_IS_AVAILABLE=n
From: Gary Guo @ 2026-05-28 12:35 UTC (permalink / raw)
To: Sasha Finkelstein, Alice Ryhl, Andreas Hindborg, Benno Lossin,
Björn Roy Baron, Boqun Feng, Danilo Krummrich, Gary Guo,
Jonathan Corbet, Miguel Ojeda, Shuah Khan, Trevor Gross
Cc: Neal Gompa, linux-doc, linux-kernel, rust-for-linux
In-Reply-To: <20260521-evolve-to-crab-v2-1-c18e0e98fc54@chaosmail.tech>
On Thu May 21, 2026 at 9:30 AM BST, Sasha Finkelstein wrote:
> The current approach of silently disabling all rust drivers if the
> toolchain is missing results in users that try to compile their own
> kernels getting a "successful" build and then being confused about where
> did their drivers go. In comparison, missing openssl results in a build
> failure, not a disappearance of everything that depends on it.
>
> This also means that allyesconfig will depend on rust, but since the
> rust experiment concluded with "rust is here to stay", i believe that
> allyesconfig should be building rust drivers too.
>
> Signed-off-by: Sasha Finkelstein <k@chaosmail.tech>
Reviewed-by: Gary Guo <gary@garyguo.net>
> ---
> Changes in v2:
> - No longer a RFC, let's make it happen.
> - Update the docs.
> - Link to v1: https://patch.msgid.link/20260510-evolve-to-crab-v1-1-208df84e67be@chaosmail.tech
> ---
> Documentation/rust/quick-start.rst | 6 +++---
> init/Kconfig | 1 -
> 2 files changed, 3 insertions(+), 4 deletions(-)
^ permalink raw reply
* RE: [PATCH net-next v2 10/10] net: ethernet: adi: Add a driver for the ADIN1140 MACPHY
From: Regus, Ciprian @ 2026-05-28 12:43 UTC (permalink / raw)
To: Andrew Lunn
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <0aaa9a58-fac1-4de7-90f0-443db37228c8@lunn.ch>
> > +static netdev_tx_t adin1140_start_xmit(struct sk_buff *skb,
> > + struct net_device *netdev)
> > +{
> > + struct adin1140_priv *priv = netdev_priv(netdev);
> > +
> > + /* Pad frames to minimum Ethernet frame size (60 bytes without
> FCS).
> > + * The MAC will append the FCS, but we need to ensure the frame is
> > + * at least ETH_ZLEN bytes.
> > + */
> > + if (skb_put_padto(skb, ETH_ZLEN))
> > + return NETDEV_TX_OK;
>
> Does the standard say anything about this? It seems like something
> which could be moved into the core.
The comment is a mistake on my part, as it doesn't clearly describe why we
have to pad the skb. It's a case of a MAC device which doesn't pad a frame to
a minimum size when the host wants to transmit less than 64 bytes. I'll update
it in v3 to say:
/* The MAC doesn't automatically pad the frame to a 64 byte minimum size in
* case the host sent a shorter skb, so we have to do it in the driver. The FCS
* will be added by the MAC.
*/
As for what the OA TC6 standard says, this is the relevant section
(7.3 - Data Transaction Protocol for Ethernet Frames)
"Ethernet frames are typically transferred from the SPI host to the MAC-PHY without
any padding or frame check sequence (FCS). The MAC will automatically pad the Ethernet
frame to the minimum frame size of 64 bytes and append a computed FCS. However, the
Ethernet specification allows for the SPI host to optionally perform the frame padding and
FCS computation prior to transfer to the MAC-PHY. Similarly, the MAC-PHY will typically
strip the FCS from received Ethernet frames prior to transfer to the SPI host. However,
the Ethernet specification allows the option for the Ethernet frame to be transferred to the
MAC client with the FCS.
The IEEE Ethernet standard [2] defines the behavior of the MAC and therefore is beyond
the scope of this specification. As a result, support for allowing the SPI host to perform frame
padding and FCS computation, or passing the FCS to the SPI host is optional. When supported,
the method for configuring the MAC-PHY to enable these modes of frame transfer is
implementation specific."
As I understand, from the TC6 standard point of view, the padding and FCS offload is optional.
So, I think this shouldn't go into the core.
>
> Andrew
^ permalink raw reply
* Re: [RFC PATCH v1 00/13] exec: add spawn templates for repeated executable startup
From: Mateusz Guzik @ 2026-05-28 12:55 UTC (permalink / raw)
To: Li Chen
Cc: Christian Brauner, Kees Cook, Alexander Viro, linux-fsdevel,
linux-api, linux-kernel, linux-mm, linux-arch, linux-doc,
linux-kselftest, x86, Arnd Bergmann, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Jan Kara, Jonathan Corbet, Shuah Khan
In-Reply-To: <20260528095235.2491226-1-me@linux.beauty>
On Thu, May 28, 2026 at 05:52:21PM +0800, Li Chen wrote:
> This RFC adds spawn_template, a userspace-controlled exec acceleration
> mechanism for runtimes that repeatedly start the same executable with
> different argv, envp, and per-spawn file descriptor setup.
>
> The main target is agent runtimes. Modern coding agents repeatedly start
> short-lived helper tools such as rg, git, sed, awk, python, node, and
> shell wrappers while they inspect and edit a workspace. Those runtimes
> already know which tools are hot, and they are also the right place to
> decide policy. The kernel does not choose names such as rg, git, or sed.
> Userspace opts in by creating a template fd for one executable, then uses
> that fd for later spawns. Launchers, shells, and build systems have a
> similar repeated-startup shape and could use the same primitive, but the
> agent runtime case is the main motivation for this RFC.
>
[..]
> A typical agent runtime would keep one template per hot executable and
> still build argv, envp, cwd, and pipe wiring for each tool call:
>
> rg_tmpl = spawn_template_create("/usr/bin/rg");
>
> for each search request:
> out_r, out_w = pipe_cloexec();
> err_r, err_w = pipe_cloexec();
> actions = [
> FCHDIR(worktree_fd),
> DUP2(out_w, STDOUT_FILENO),
> DUP2(err_w, STDERR_FILENO),
> ];
> child = spawn_template_spawn(rg_tmpl, rg_argv, envp, actions);
> close(out_w);
> close(err_w);
> read out_r and err_r;
> waitid(P_PIDFD, child.pidfd, ...);
>
>
[..]
> The cached state is intentionally small. The template fd keeps the opened
> main executable file, an optional absolute path string, the creator
> credential pointer, and the deny-write state. The executable identity key
> records device, inode, size, mode, owner, ctime, and mtime, and is
> rechecked before cached metadata is used. The ELF cache keeps only the
> main executable's ELF header, program header table, and program header
> count.
>
> cached in this RFC not cached in this RFC
> ------------------ ----------------------
> opened main executable PT_INTERP metadata
> executable identity key shared-library graph
> main ELF header VMA layout metadata
> main ELF program headers cross-process metadata sharing
> creator cred pointer
> deny-write state
>
> This RFC does not cache ELF interpreter metadata, shared-library
> dependency state, or derived mapping-layout state. Shared-library
> resolution is dynamic linker policy and depends on LD_LIBRARY_PATH,
> RPATH, RUNPATH, /etc/ld.so.cache, mount namespaces, and secure-exec
> state. It also does not share cached executable metadata between template
> fds created by different processes. Each template owns its small cached
> metadata object in this RFC.
>
> Performance
> ===========
>
[..]
> Workload Calls subprocess spawn_template time_s Delta
> (workers) calls calls/s calls/s seconds
> 1x16 6144 411.04 420.32 14.95/14.62 +2.26%
> 2x8 6144 666.78 690.08 9.21/8.90 +3.49%
> 4x4 6144 955.61 1003.25 6.43/6.12 +4.99%
> 8x2 6144 1048.25 1069.18 5.86/5.75 +2.00%
>
This problem is dear to my heart and I have been pondering it on and off
for some time now. The entire fork + exec idiom is terrible and needs to
be retired.
Is this vibe-coded? I asked claude for in-kernel posix_spawn for kicks
some time ago and it generated remarkably similar code. But that's a
tangent.
I'm rather confused by the angle in the patchset. Most of this shaves
off a tiny amount of work, while retaining the primary avoidable reason
for bad performance: the very fact that fork is part of the picture,
especially the part mucking with mm. Creating a pristine process is the
way to go.
Additionally there is a known problem where transiently copied file
descriptors on fork + exec cause a headache in multithreaded programs
doing something like this in parallel. I only did cursory reading, it
seems your patchset keeps the same problem in place.
There are numerous impactful ways to speed up execs both in terms of
single-threaded cost and their multicore scalability, most of which
would be immediately usable by all programs without an opt-in. imo these
needs to be exhausted before something like a "template" can be
considered.
Per the above, the primary win would stem from *NOT* messing with mm.
As in, whatever the interface, it needs to create an "empty" target
process (for lack of a better term).
In terms of userspace-visible APIs, a clean solution escapes me.
Some time ago I proposed returning a handle which is populated over time
by the parnet-to-be. One of the problems with it I failed to consider at
the time is NUMA locality -- what if the process to be created is going
to run on another domain? For example, opening and installing a file for
its later use will result in avoidable loss of locality for some of the
in-kernel data. That's on top of the fd vs fork problem.
From perf standpoint, the final goal of whatever mechanism should be a
state where the target process avoided copying any state it did not need
to and which allocated any memory it needed from local NUMA node
(whatever it may happen to be). Of course if no affinity is assigned it
may happen to move again and lose such locality, nothing can be done
about that. But pretend the process is to run in a specific node the
parent is NOT running in.
So I think the pragmatic way forward is to implement something close to
posix_spawn in the kernel. It may make sense for the thing to take the
PATH argument for repeated exec attempts. I understand this is of no use
in your particular case, but it very much IS of use for most of the
real-world. The initial implementation might even start with doing vfork
just to get it off the ground.
The next step would be to extend the interface with means to AVOID
copying any file descriptors. There could be a dedicated file action
which tells the kernel to avoid such copies or something like a
close_range file action (or close_from) -- with a range like <0, INT_MAX>
you know no fds are copied.
For the NUMA angle to be sorted out, any file action which opens a file
or dups from the parent needs to execute in the child. And frankly
something would be needed to ask the scheduler where does it think the
child is going to run, so that the task_struct itself can also be
allocated with the right backing.
I have not looked into what's needed to create a new process and NOT
mess with mm, but I don't think there are unsolvable problems there, at
worst some churn.
There are of course other parameters which need to be sorted out, that's
covered by the posix_spawn thing.
This e-mail is long enough, so I'm not going to go into issues
concerning exec itself right now.
tl;dr I would suggest redoing the patchset as posix_spawn and then doing
the actual optimization of not cloning mm itself.
^ permalink raw reply
* Re: [PATCH v2] docs: pt_BR: update maintainer-handbooks
From: Daniel Pereira @ 2026-05-28 12:57 UTC (permalink / raw)
To: Amanda Corrêa; +Cc: linux-doc
In-Reply-To: <20260528041958.57231-1-amandacorreasilvax@gmail.com>
On Thu, May 28, 2026 at 1:20 AM Amanda Corrêa
<amandacorreasilvax@gmail.com> wrote:
>
> Update the content of the maintainer-handbooks documentation
> to Brazilian Portuguese.
>
> v2: Update maintainer-handbooks documentation based on the actual latest version of the English
> documentation. Prior version was based on an older version of the English documentation, which caused
> some inconsistencies between the two versions.
> This update ensures that the Brazilian Portuguese documentation is in sync with the latest English
> version, providing accurate and up-to-date information.
>
> Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com>
> ---
> .../pt_BR/process/maintainer-handbooks.rst | 19 +++++++++++--------
> 1 file changed, 11 insertions(+), 8 deletions(-)
Hi Amanda,
I believe this is your first contribution.
I noticed that the titles for v1 and v2 of this patch were different.
When sending subsequent versions, please maintain the exact same
subject line, only updating the version tag (e.g., from [PATCH v1] to
[PATCH v2]). This helps significantly with identification.
Regarding the content, the Portuguese grammar is correct, and the
change makes sense.
Thanks,
Acked-by: Daniel Pereira
^ permalink raw reply
* Re: 答复: 答复: [外部邮件] Re: [PATCH] mm/mempool: use static key for boot-time debug enablement
From: Usama Arif @ 2026-05-28 12:59 UTC (permalink / raw)
To: Li,Rongqing(ACG CCN)
Cc: Jonathan Corbet, Shuah Khan, Vlastimil Babka, Harry Yoo,
Andrew Morton, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
In-Reply-To: <b9d53cb0be024778b09e1bb1ef7d0211@baidu.com>
On 28/05/2026 11:50, Li,Rongqing(ACG CCN) wrote:
>
>
>>
>> On 28/05/2026 04:00, Li,Rongqing(ACG CCN) wrote:
>>>>> From: Li RongQing <lirongqing@baidu.com>
>>>>>
>>>>> Replace the #ifdef CONFIG_SLUB_DEBUG_ON conditional compilation with
>>>>> a static key (mempool_debug_enabled). This allows enabling mempool
>>>>> debugging at boot time via:
>>>>>
>>>>> mempool_debug
>>>>>
>>>>> Instead of requiring CONFIG_SLUB_DEBUG_ON at compile time. Benefits:
>>>>>
>>>>> - Debugging can be enabled without rebuilding the kernel
>>>>> - Uses standard kernel static_key mechanism with minimal overhead
>>>>>
>>>>> Suggested-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
>>>>> Signed-off-by: Li RongQing <lirongqing@baidu.com>
>>>>> Cc: Vlastimil Babka <vbabka@kernel.org>
>>>>> Cc: Harry Yoo <harry@kernel.org>
>>>>> Cc: Andrew Morton <akpm@linux-foundation.org>
>>>>> Cc: Hao Li <hao.li@linux.dev>
>>>>> Cc: Christoph Lameter <cl@gentwo.org>
>>>>> Cc: David Rientjes <rientjes@google.com>
>>>>> Cc: Roman Gushchin <roman.gushchin@linux.dev>
>>>>> ---
>>>>> Documentation/admin-guide/kernel-parameters.txt | 5 ++++
>>>>> mm/mempool.c | 32
>>>> ++++++++++++++++++-------
>>>>> 2 files changed, 28 insertions(+), 9 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/admin-guide/kernel-parameters.txt
>>>>> b/Documentation/admin-guide/kernel-parameters.txt
>>>>> index 35ed9dc..5a070e6 100644
>>>>> --- a/Documentation/admin-guide/kernel-parameters.txt
>>>>> +++ b/Documentation/admin-guide/kernel-parameters.txt
>>>>> @@ -3998,6 +3998,11 @@ Kernel parameters
>>>>> Note that even when enabled, there are a few cases where
>>>>> the feature is not effective.
>>>>>
>>>>> + mempool_debug [MM]
>>>>> + Enable mempool debugging. This enables element
>>>>> + poison checking when freeing elements back to the
>>>>> + pool. Useful for debugging mempool corruption.
>>>>> +
>>>>> memtest= [KNL,X86,ARM,M68K,PPC,RISCV,EARLY] Enable
>> memtest
>>>>> Format: <integer>
>>>>> default : 0 <disable>
>>>>> diff --git a/mm/mempool.c b/mm/mempool.c index db23e0e..4f429a1
>>>> 100644
>>>>> --- a/mm/mempool.c
>>>>> +++ b/mm/mempool.c
>>>>> @@ -16,11 +16,28 @@
>>>>> #include <linux/export.h>
>>>>> #include <linux/mempool.h>
>>>>> #include <linux/writeback.h>
>>>>> +#include <linux/static_key.h>
>>>>> +#include <linux/init.h>
>>>>> #include "slab.h"
>>>>>
>>>>> static DECLARE_FAULT_ATTR(fail_mempool_alloc);
>>>>> static DECLARE_FAULT_ATTR(fail_mempool_alloc_bulk);
>>>>>
>>>>> +/*
>>>>> + * Debugging support for mempool using static key.
>>>>> + *
>>>>> + * This allows enabling mempool debug at boot time via:
>>>>> + * mempool_debug
>>>>> + */
>>>>> +static DEFINE_STATIC_KEY_FALSE(mempool_debug_enabled);
>>>>> +
>>>>> +static int __init mempool_debug_setup(char *str) {
>>>>> + static_branch_enable(&mempool_debug_enabled);
>>>>> + return 0;
>>>>> +}
>>>>> +early_param("mempool_debug", mempool_debug_setup);
>>>>> +
>>>>
>>>> Can static_branch_enable() in mempool_debug_setup() run before
>>>> jump_label_init() has set static_key_initialized?
>>>>
>>>> Looking at start_kernel() in init/main.c:
>>>>
>>>> setup_arch(&command_line);
>>>> mm_core_init_early();
>>>> /* Static keys and static calls are needed by LSMs */
>>>> jump_label_init();
>>>> ...
>>>> /* parameters may set static keys */
>>>> parse_early_param();
>>>>
>>>> This will trigger the warning in include/linux/jump_label.h has:
>>>>
>>>> #define STATIC_KEY_CHECK_USE(key) WARN(!static_key_initialized, \
>>>> "%s(): static key '%pS' used before call to jump_label_init()", \
>>>> __func__, (key))
>>>>
>>>>
>>>> mm/dmapool.c registers an equivalent debug toggle via __setup()
>>>> rather than
>>>> early_param():
>>>>
>>>> static int __init dmapool_debug_setup(char *str)
>>>> {
>>>> static_branch_enable(&dmapool_debug_enabled);
>>>> return 1;
>>>> }
>>>> __setup("dmapool_debug", dmapool_debug_setup);
>>>>
>>>> I think you can reuse that.
>>>
>>> Thanks for your review!
>>>
>>> While this boot-time ordering used to be a generic issue, it seems
>>> many architectures have already aligned or fixed this internally. For
>>> instance,
>>>
>>> commit ca829e05d3d4 ("powerpc/64: Init jump labels before
>>> parse_early_param()") and commit 6070970db9fe ("m68k: Initialize jump
>>> labels early during setup_arch()") explicitly relocated jump_label_init() before
>> the early parameter parsing.
>>>
>>
>> I think 32 bit ARM doesnt?
>
> You are right, 32-bit ARM doesn't.
>
> However, the correct architectural approach should be fixing the boot sequence
> inside arch/arm/ to match arm64 , powerpc and m68k, rather than compromising core MM
> code with temporary boilerplate variables.
>
> I prefer to keep the mempool implementation clean. If ARM32 triggers the
> warning, the proper remedy is a follow-up patch to align its setup_arch()
> ordering.
>
> What do you think?
>
I think it would be a prerequisite rather than a follow up patch inorder to not
break 32 bit arm. I will let ARM and slab maintainers decide on this.
^ permalink raw reply
* Re: [PATCH] docs: zh_TW: process: localize terminologies and improve fluency in 8.Conclusion
From: Jonathan Corbet @ 2026-05-28 13:19 UTC (permalink / raw)
To: CHEN-YOU-0331, Hu Haowen
Cc: Shuah Khan, linux-doc, linux-kernel, CHEN-YOU-0331, alexs
In-Reply-To: <20260528041330.23247-1-chenyou910331@gmail.com>
CHEN-YOU-0331 <chenyou910331@gmail.com> writes:
> Translate PRC tech terms into Taiwanese tech terms (e.g.,
> 內核 -> 核心, 代碼 -> 程式碼, 軟件 -> 軟體) to improve
> readability for local developers. Also, rephrase several
> awkward sentences to make the document more fluent.
>
> Signed-off-by: CHEN-YOU-0331 <chenyou910331@gmail.com>
> ---
> .../zh_TW/process/8.Conclusion.rst | 45 +++++++++----------
> 1 file changed, 22 insertions(+), 23 deletions(-)
I, of course, am in no position to judge these changes, and I worry
about getting into some sort of turf war over differences in
terminology. Alex, are you able to give me a recommendation on this
change?
Meanwhile, the signoff should have your proper name, please.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2 1/2] ALSA: usb-audio: Add QUIRK_FLAG_MIXER_GET_CUR_BROKEN
From: Rong Zhang @ 2026-05-28 13:23 UTC (permalink / raw)
To: Takashi Iwai
Cc: Jaroslav Kysela, Takashi Iwai, Jonathan Corbet, Shuah Khan,
linux-sound, linux-doc, linux-kernel
In-Reply-To: <877boougfq.wl-tiwai@suse.de>
Hi Takashi,
Thanks for your review.
On Thu, 2026-05-28 at 09:44 +0200, Takashi Iwai wrote:
> On Wed, 27 May 2026 20:56:27 +0200,
> Rong Zhang wrote:
> >
> > @@ -1258,6 +1261,16 @@ static int check_sticky_volume_control(struct usb_mixer_elem_info *cval,
> > return 0;
> > }
> >
> > + if (cval->head.mixer->chip->quirk_flags & QUIRK_FLAG_MIXER_GET_CUR_BROKEN) {
> > + usb_audio_warn(cval->head.mixer->chip,
> > + "%d:%d: broken mixer GET_CUR (%d/%d/%d => %d)\n",
> > + cval->head.id, mixer_ctrl_intf(cval->head.mixer),
> > + cval->min, cval->max, cval->res, saved);
> > +
>
> IMO, it's better to be usb_audio_info(). Otherwise it leads to an
> unnecessary caution. Basically the behavior is expected, so there is
> nothing to worry about that.
Hmm, makes sense.
With your suggestion, I also just realized that it makes no sense to
restore a garbage volume using snd_usb_set_cur_mix_value(..., saved)
when GET_CUR is broken. It would be probably better to rely on
init_cur_mix_raw() to initialize the mixer to cval->min instead, just
like what it does for mixers that return errors for GET_CUR.
Hence, I will turn it into a usb_audio_info(), clear cval->cached and
goto no_checks, so that init_cur_mix_raw() will initialize it properly.
The usb_audio_warn() in init_cur_mix_raw() will need to be gated by
cval->get_cur_broken in this case too.
Thanks for your suggestion,
Rong
>
>
> thanks,
>
> Takashi
^ permalink raw reply
* [PATCH] docs: mm: clarify that user_reserve_kbytes has no effect when overcommit_memory is set to 0 or 1
From: Brian Masney @ 2026-05-28 13:45 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Andrew Morton
Cc: linux-mm, linux-doc, linux-kernel, Matthew Storr, Brian Masney
Looking at __vm_enough_memory() in mm/util.c, user_reserve_kbytes has no
effect when overcommit_memory is set to 0 or 1. The documentation for
overcommit_memory already references user_reserve_kbytes when the flag
is set to 2.
Let's go ahead and add a clarification to user_reserve_kbytes in vm.rst
that it has no effect when overcommit_memory is set to 0 or 1.
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
Documentation/admin-guide/sysctl/vm.rst | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
index 97e12359775c..b9b0c218bfb4 100644
--- a/Documentation/admin-guide/sysctl/vm.rst
+++ b/Documentation/admin-guide/sysctl/vm.rst
@@ -1034,6 +1034,8 @@ min(3% of current process size, user_reserve_kbytes) of free memory.
This is intended to prevent a user from starting a single memory hogging
process, such that they cannot recover (kill the hog).
+This setting has no effect when overcommit_memory is set to 0 or 1.
+
user_reserve_kbytes defaults to min(3% of the current process size, 128MB).
If this is reduced to zero, then the user will be allowed to allocate
---
base-commit: e7d700e14934e68f86338c5610cf2ae76798b663
change-id: 20260528-mm-clarify-docs-76ab8f82826d
Best regards,
--
Brian Masney <bmasney@redhat.com>
^ permalink raw reply related
* Re: [PATCH -next] mtd: spi-nor: testing locking, fix new doc build warnings
From: Pratyush Yadav @ 2026-05-28 13:53 UTC (permalink / raw)
To: Randy Dunlap
Cc: linux-doc, Jonathan Corbet, Shuah Khan, Pratyush Yadav,
Michael Walle, Takahiro Kuwano, linux-mtd, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra
In-Reply-To: <20260526172341.773398-1-rdunlap@infradead.org>
On Tue, May 26 2026, Randy Dunlap wrote:
> Add a blank line to prevent documentation build warnings:
>
> Documentation/driver-api/mtd/spi-nor.rst:215: ERROR: Unexpected indentation. [docutils]
> Documentation/driver-api/mtd/spi-nor.rst:216: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> # for spi-nor/next
Folded into "mtd: spi-nor: Add steps for testing locking support".
Thanks!
--
Regards,
Pratyush Yadav
^ permalink raw reply
* Re: [PATCH] docs: mm: clarify that user_reserve_kbytes has no effect when overcommit_memory is set to 0 or 1
From: Brian Masney @ 2026-05-28 14:02 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Andrew Morton, David Hildenbrand,
Lorenzo Stoakes, Liam R. Howlett, Vlastimil Babka
Cc: linux-mm, linux-doc, linux-kernel, Matthew Storr
In-Reply-To: <20260528-mm-clarify-docs-v1-1-aa88e83b4bfd@redhat.com>
On Thu, May 28, 2026 at 09:45:10AM -0400, Brian Masney wrote:
> Looking at __vm_enough_memory() in mm/util.c, user_reserve_kbytes has no
> effect when overcommit_memory is set to 0 or 1. The documentation for
> overcommit_memory already references user_reserve_kbytes when the flag
> is set to 2.
>
> Let's go ahead and add a clarification to user_reserve_kbytes in vm.rst
> that it has no effect when overcommit_memory is set to 0 or 1.
>
> Signed-off-by: Brian Masney <bmasney@redhat.com>
> ---
> Documentation/admin-guide/sysctl/vm.rst | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
> index 97e12359775c..b9b0c218bfb4 100644
> --- a/Documentation/admin-guide/sysctl/vm.rst
> +++ b/Documentation/admin-guide/sysctl/vm.rst
> @@ -1034,6 +1034,8 @@ min(3% of current process size, user_reserve_kbytes) of free memory.
> This is intended to prevent a user from starting a single memory hogging
> process, such that they cannot recover (kill the hog).
>
> +This setting has no effect when overcommit_memory is set to 0 or 1.
> +
> user_reserve_kbytes defaults to min(3% of the current process size, 128MB).
>
> If this is reduced to zero, then the user will be allowed to allocate
>
> ---
> base-commit: e7d700e14934e68f86338c5610cf2ae76798b663
> change-id: 20260528-mm-clarify-docs-76ab8f82826d
+ Other MM maintainers / reviewers. Sorry for not including on the
initial patch posting. I initially missed the separate MM Core subsystem
in the MAINTAINERS file.
Brian
^ permalink raw reply
* Re: [PATCH net-next v2 10/10] net: ethernet: adi: Add a driver for the ADIN1140 MACPHY
From: Andrew Lunn @ 2026-05-28 14:05 UTC (permalink / raw)
To: Regus, Ciprian
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Heiner Kallweit, Russell King, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org
In-Reply-To: <72c3a9a8040e4b8990f217d4072872de@analog.com>
> > Does the standard say anything about this? It seems like something
> > which could be moved into the core.
>
> The comment is a mistake on my part, as it doesn't clearly describe why we
> have to pad the skb. It's a case of a MAC device which doesn't pad a frame to
> a minimum size when the host wants to transmit less than 64 bytes. I'll update
> it in v3 to say:
>
> /* The MAC doesn't automatically pad the frame to a 64 byte minimum size in
> * case the host sent a shorter skb, so we have to do it in the driver. The FCS
> * will be added by the MAC.
> */
Just an FYI: the 64 bytes includes the FCS. So if the MAC is adding
the FCS, you should pad to 60, not 64.
> As for what the OA TC6 standard says, this is the relevant section
> (7.3 - Data Transaction Protocol for Ethernet Frames)
>
> "Ethernet frames are typically transferred from the SPI host to the MAC-PHY without
> any padding or frame check sequence (FCS). The MAC will automatically pad the Ethernet
> frame to the minimum frame size of 64 bytes and append a computed FCS. However, the
> Ethernet specification allows for the SPI host to optionally perform the frame padding and
> FCS computation prior to transfer to the MAC-PHY. Similarly, the MAC-PHY will typically
> strip the FCS from received Ethernet frames prior to transfer to the SPI host. However,
> the Ethernet specification allows the option for the Ethernet frame to be transferred to the
> MAC client with the FCS.
>
> The IEEE Ethernet standard [2] defines the behavior of the MAC and therefore is beyond
> the scope of this specification. As a result, support for allowing the SPI host to perform frame
> padding and FCS computation, or passing the FCS to the SPI host is optional. When supported,
> the method for configuring the MAC-PHY to enable these modes of frame transfer is
> implementation specific."
>
> As I understand, from the TC6 standard point of view, the padding and FCS offload is optional.
> So, I think this shouldn't go into the core.
Thanks for the quotes from the standard. I personally think this was a
bad decision by the authors of the standard, leaving it ambiguous.
In the end, putting it in the driver seems like a good first
approach. Maybe as we get more devices following the standard, we see
it is common to need padding, and we move it into the core controlled
by a quirk. But that can come later.
Andrew
^ permalink raw reply
* Re: [RFC PATCH v3 1/3] scripts: add kconfirm
From: Gary Guo @ 2026-05-28 14:30 UTC (permalink / raw)
To: Demi Marie Obenour, Miguel Ojeda
Cc: Julian Braha, nathan, nsc, jani.nikula, akpm, gary, ljs, arnd,
gregkh, masahiroy, ojeda, corbet, qingfang.deng, yann.prono, ej,
linux-kernel, rust-for-linux, linux-doc, linux-kbuild
In-Reply-To: <f77a4858-2bcf-4bfb-95e0-24a5d91e0862@gmail.com>
On Sun May 17, 2026 at 9:25 PM BST, Demi Marie Obenour wrote:
> On 5/17/26 05:58, Miguel Ojeda wrote:
>> On Sun, May 17, 2026 at 8:10 AM Demi Marie Obenour
>> <demiobenour@gmail.com> wrote:
>>>
>>> I think it is simpler to just inline all of this code into its
>>> single call-site. The safety of the code is obvious in context,
>>> and you can avoid checking for impossible errors. For instance,
>>> since all of the options have required arguments, it really is safe
>>> to dereference optarg without any null check.
>>
>> If we are going to have unsafe code, then let's please build safe
>> abstractions wherever possible, just like we do elsewhere. We should
>> also write `// SAFETY` comments and enable the lints that catch that
>> etc., just like elsewhere too.
>>
>> (This is not to say we should use `getopt` instead of something like
>> `clap` -- as soon as we start using `cargo vendor`, then it makes
>> sense to at least consider having a set of vetted, well-known crates
>> to write Rust tools in-tree, as I mentioned in v1.)
>
> I was hoping for Linux to avoid the Rust trend of downloading tons
> of third-party crates, with all the supply-chain risks that entails.
> Hence the idea of using getopt and system C libraries.
Well, there're quite a few libraries which are "third-party" but they're
blessed and used by the Rust compiler itself (and often maintained by the same
group of people behind the Rust project).
https://github.com/rust-lang/rust/blob/main/Cargo.lock
For example, I would trust `clap` to be used, and I think it's a huge
developer-experience improvement compared to getopt.
I think it's not really reasonable to avoid all dependencies, after all, C tools
also require a few dependencies, it's just that they're sourced from distro and
not crates.io.
I think the only issue is that unlike C libraries, there's no unified ways for
distros to ship these libraries (and some distros don't ship individual Rust
crates as libraries at all). It used to be the case that you can enable the
`rustc_private` feature and just link against whatever the version that the Rust
compiler depends on, but rustc stopped you from doing that a while ago because
they don't want people to depend on rustc's private dependencies.
If the concern is with supply chain security, there're mechanisms like cargo-vet
https://github.com/mozilla/cargo-vet which can be used to ensure dependencies to
be audited. That plus the hash locking should be sufficient.
Best,
Gary
^ permalink raw reply
* Re: [PATCH] docs/zh_CN: update admin-guide/index.rst translation
From: Dongliang Mu @ 2026-05-28 14:46 UTC (permalink / raw)
To: Yan Zhu, corbet, alexs, si.yanteng, kees
Cc: skhan, tony.luck, gpiccoli, frederic, jani.nikula, longman,
mchehab+huawei, linux-doc, linux-kernel
In-Reply-To: <tencent_7ADF2D1EBD8EAD2028BC93BA7858EA655D0A@qq.com>
On 5/10/26 2:48 PM, Yan Zhu wrote:
> update Documentation/admin-guide/index.rst Chinese translation
>
> Update the translation through commit f0efd29aa60c
> ("doc: Add CPU Isolation documentation")
>
> Signed-off-by: Yan Zhu <zhuyan2015@qq.com>
> ---
> .../translations/zh_CN/admin-guide/index.rst | 209 +++++++++++++-----
> 1 file changed, 159 insertions(+), 50 deletions(-)
>
> diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst
> index 15d9ab5993a7..575449b91916 100644
> --- a/Documentation/translations/zh_CN/admin-guide/index.rst
> +++ b/Documentation/translations/zh_CN/admin-guide/index.rst
> @@ -1,7 +1,13 @@
> +.. SPDX-License-Identifier: GPL-2.0
> .. include:: ../disclaimer-zh_CN.rst
>
> -:Original: :doc:`../../../admin-guide/index`
> -:Translator: Alex Shi <alex.shi@linux.alibaba.com>
> +:Original: Documentation/admin-guide/index.rst
> +
> +:翻译:
> +
> + 时奎亮 Alex Shi <alex.shi@linux.alibaba.com>
> +
> + 朱岩 Yan Zhu <zhuyan2015@qq.com>
>
>
> Linux 内核用户和管理员指南
> @@ -11,7 +17,11 @@ Linux 内核用户和管理员指南
> 整体的顺序或组织 - 这些材料不是一个单一的，连贯的文件！幸运的话，情况会随着
> 时间的推移而迅速改善。
>
> -这个初始部分包含总体信息，包括描述内核的README， 关于内核参数的文档等。
> +
> +内核管理通用指南
> +----------------
> +
> +本节包含总体信息，包括描述内核整体的 README 文件、内核参数文档等。
>
> .. toctree::
> :maxdepth: 1
> @@ -20,17 +30,55 @@ Linux 内核用户和管理员指南
>
> Todolist:
>
> -* kernel-parameters
> * devices
> +* features
> +
> +内核管理接口的重要组成部分是 /proc 和 sysfs 虚拟文件系统；这些文档描述了如何
> +与之交互。
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + cputopology
> +
> +
> +Todolist:
Add a blank line here.
> +* sysfs-rules
> * sysctl/index
> +* abi
> +
> +安全相关文档：
> +
> +.. toctree::
> + :maxdepth: 1
>
> -本节介绍CPU漏洞及其缓解措施。
>
> Todolist:
>
> * hw-vuln/index
> +* LSM/index
> +* perf-security
> +
> +
> +内核启动
> +--------
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + bootconfig
> +
> +Todolist:
> +
> +* kernel-parameters
> +* efi-stub
> +* initrd
> +
> +
> +追踪和识别问题
> +--------------
>
> -下面的一组文档，针对的是试图跟踪问题和bug的用户。
> +以下是一组面向试图追踪特定问题和 bug 的用户的文档。
>
> .. toctree::
> :maxdepth: 1
> @@ -39,94 +87,155 @@ Todolist:
> reporting-regressions
> bug-hunting
> bug-bisect
> - tainted-kernels
> init
> + clearing-warn-once
> + lockup-watchdogs
> + sysrq
>
> Todolist:
>
> +* quickly-build-trimmed-linux
> +* verify-bugs-and-bisect-regressions
> +* tainted-kernels
> * ramoops
> * dynamic-debug-howto
> * kdump/index
> * perf/index
> +* pstore-blk
> +* kernel-per-CPU-kthreads
> +* RAS/index
> +
> +
> +核心内核子系统
> +--------------
> +
> +这些文档描述了核心内核管理接口，这些接口几乎在任何系统上都值得关注。
> +
> +.. toctree::
> + :maxdepth: 1
> +
> + cpu-load
> + mm/index
> + module-signing
> + numastat
>
> -这是应用程序开发人员感兴趣的章节的开始。可以在这里找到涵盖内核ABI各个
> -方面的文档。
>
> Todolist:
>
> -* sysfs-rules
> +* cgroup-v2
> +* cgroup-v1/index
> +* namespaces/index
> +* pm/index
> +* syscall-user-dispatch
>
> -本手册的其余部分包括各种指南，介绍如何根据您的喜好配置内核的特定行为。
>
> +对非原生二进制格式的支持。请注意，其中一些文档相当古老。
I think you can emphasize 古老 with bold in RST, which can match the
English documentation.
> +
> +.. toctree::
> + :maxdepth: 1
> +
> +
> +Todolist:
> +
> +* binfmt-misc
> +* java
> +* mono
> +
> +
> +块设备和文件系统管理
> +--------------------
>
> .. toctree::
> :maxdepth: 1
>
> - bootconfig
> - clearing-warn-once
> - cpu-load
> - cputopology
> - lockup-watchdogs
> - numastat
> - unicode
> - sysrq
> - mm/index
>
> Todolist:
>
> -* acpi/index
> -* aoe/index
> -* auxdisplay/index
> * bcache
> * binderfs
> -* binfmt-misc
> * blockdev/index
> -* braille-console
> -* btmrvl
> -* cgroup-v1/index
> -* cgroup-v2
> * cifs/index
> -* dell_rbu
> * device-mapper/index
> -* edid
> -* efi-stub
> * ext4
> +* filesystem-monitoring
> * nfs/index
> -* gpio/index
> -* highuid
> -* hw_random
> -* initrd
> * iostats
> -* java
> * jfs
> -* kernel-per-CPU-kthreads
> +* md
> +* ufs
> +* xfs
> +
> +
> +专用设备指南
> +------------
> +
> +如何在 Linux 系统中配置硬件。
> +
> +.. toctree::
> + :maxdepth: 1
> +
> +
Remove one blank line. Only keep one blank line here.
> +Todolist:
> +
> +* acpi/index
> +* aoe/index
> +* auxdisplay/index
> +* braille-console
> +* btmrvl
> +* dell_rbu
> +* edid
> +* gpio/index
> +* hw_random
> * laptops/index
> * lcd-panel-cgram
> -* ldm
> -* LSM/index
> -* md
> * media/index
> -* module-signing
> -* mono
> -* namespaces/index
> +* nvme-multipath
> * parport
> -* perf-security
> -* pm/index
> * pnp
> * rapidio
> -* ras
> * rtc
> * serial-console
> * svga
> +* thermal/index
> * thunderbolt
> -* ufs
> * vga-softcursor
> * video-output
> -* xfs
> +
> +
> +工作负载分析
> +------------
> +
> +这是一个章节的开始，其中包含对从事 Linux 内核安全关键性分析的应用程序开发人员
> +和系统集成商感兴趣的信息。这里可以找到支持分析内核与应用程序交互以及关键内核
> +子系统预期的文档。
> +
> +.. toctree::
> + :maxdepth: 1
> +
> +
Remove one blank line. Only keep one blank line here.
> +Todolist:
> +
> +* workload-tracing
> +
> +
> +其他内容
> +--------
> +
> +一些难以分类且通常已过时的文档。
> +
> +.. toctree::
> + :maxdepth: 1
> +
> +
> +Todolist:
> +
> +* highuid
> +* ldm
> +* unicode
>
> .. only:: subproject and html
>
> - Indices
> - =======
> + 索引
> + ====
>
> * :ref:`genindex`
^ permalink raw reply
* Re: [PATCH v2] docs: pt_BR: update maintainer-handbooks
From: Jonathan Corbet @ 2026-05-28 14:47 UTC (permalink / raw)
To: Daniel Pereira, Amanda Corrêa; +Cc: linux-doc
In-Reply-To: <CAMAsx6fWkQi1BHRPypDQeXL7LsDftfm5SFsgf1-pSUMQAdo8YA@mail.gmail.com>
Daniel Pereira <danielmaraboo@gmail.com> writes:
> On Thu, May 28, 2026 at 1:20 AM Amanda Corrêa
> <amandacorreasilvax@gmail.com> wrote:
>>
>> Update the content of the maintainer-handbooks documentation
>> to Brazilian Portuguese.
>>
>> v2: Update maintainer-handbooks documentation based on the actual latest version of the English
>> documentation. Prior version was based on an older version of the English documentation, which caused
>> some inconsistencies between the two versions.
>> This update ensures that the Brazilian Portuguese documentation is in sync with the latest English
>> version, providing accurate and up-to-date information.
>>
>> Signed-off-by: Amanda Corrêa <amandacorreasilvax@gmail.com>
>> ---
>> .../pt_BR/process/maintainer-handbooks.rst | 19 +++++++++++--------
>> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> Hi Amanda,
>
> I believe this is your first contribution.
>
> I noticed that the titles for v1 and v2 of this patch were different.
> When sending subsequent versions, please maintain the exact same
> subject line, only updating the version tag (e.g., from [PATCH v1] to
> [PATCH v2]). This helps significantly with identification.
>
> Regarding the content, the Portuguese grammar is correct, and the
> change makes sense.
Is that an Acked-by?
Thanks,
jon
^ permalink raw reply
* RE: [PATCH net-next v2 01/10] dt-bindings: net: Add ADIN1140
From: Regus, Ciprian @ 2026-05-28 16:46 UTC (permalink / raw)
To: Conor Dooley
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Andrew Lunn, Heiner Kallweit, Russell King,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <20260527-nearness-antacid-9f94a3f43abc@spud>
> > +title: ADI ADIN1140 10BASE-T1S MAC-PHY
> > +
> > +maintainers:
> > + - Ciprian Regus <ciprian.regus@analog.com>
> > +
> > +description: |
> > + The ADIN1140 (also called AD3306) is a low power single port
>
> Can you explain what is going on here please?
> Is "adin1140" (which I can find no information easily online for) the
> exact same device as the ad3306 (which has an entry on your site)?
The adin1140 is an upcoming version of ad3306 that lacks some
(stress test) qualifications, but otherwise they are the exact same die.
>
> > + 10BASE-T1S MAC-PHY. It integrates an Ethernet PHY with a MAC
> > + and all the associated analog circuitry.
> > + The device tries to implement the Open Alliance TC6 10BASE-T1x MAC-
> PHY
> > + Serial Interface specification and is compliant with the
> > + IEEE 802.3cg-2019 Ethernet standard for 10 Mbps single pair
> > + Ethernet (SPE). The device has a 4-wire SPI interface for
> > + communication between the MAC and host processor.
> > +
> > +allOf:
> > + - $ref: /schemas/net/ethernet-controller.yaml#
> > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > +
> > +properties:
> > + compatible:
> > + enum:
> > + - adi,ad3306
> > + - adi,adin1140
>
> Because if they are really two names for the same part, this compatible
> setup makes no sense, as it means they have a different programming
> models.
Since they have the same programming model, should I just keep the adi,adin1140
entry?
>
> Thanks,
> Conor.
>
^ permalink raw reply
* Re: [PATCH 1/3] net: Remove support for AIO on sockets
From: Jens Axboe @ 2026-05-28 16:56 UTC (permalink / raw)
To: Christoph Hellwig
Cc: demiobenour, Herbert Xu, David S. Miller, Eric Dumazet,
Kuniyuki Iwashima, Paolo Abeni, Willem de Bruijn, Jakub Kicinski,
Simon Horman, Peter Zijlstra, Ingo Molnar,
Arnaldo Carvalho de Melo, Namhyung Kim, Mark Rutland,
Alexander Shishkin, Jiri Olsa, Ian Rogers, Adrian Hunter,
James Clark, Jonathan Corbet, Shuah Khan, Eric Biggers,
Ard Biesheuvel, linux-crypto, linux-kernel, io-uring, netdev,
linux-perf-users, linux-doc, Toke Høiland-Jørgensen,
linux-api, David Howells
In-Reply-To: <ahanjVfIDlCmeCUE@infradead.org>
On 5/27/26 2:13 AM, Christoph Hellwig wrote:
> On Tue, May 26, 2026 at 09:58:27AM -0600, Jens Axboe wrote:
>>> The current TCP zerocopy implementation provides completion notification
>>> through the socket error code, which is freaking weird and doesn't
>>> integrate well with either io_uring or in-kernel callers.
>>
>> We already have that via io_uring
>
> Where? And how do make that available to in-kernel users like
> storage protocols and network file system, which really suffer from
> the current MSG_SPLICE_PAGES semantics.
For zero copy, on both the receive and send side. Since we have a proper
notification channel, that's what we use rather than the hack that is
the error queue.
>> , and without needing msg_kiocb or the
>
> What do you think is the downside of using a kiocb here like for
> everything else with async notifications?
Where would the notifications go? You'd end up inventing something new
to propagate them to userspace then. The io_uring side does not rely on
using msg_kiocb, and iirc that part was only ever used for the crypto
stuff and largely broken. Which is why I do agree with just yanking it
out.
--
Jens Axboe
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwmon: pmbus: Add Analog Devices MAX20860A
From: Pradhan, Sanman @ 2026-05-28 17:06 UTC (permalink / raw)
To: conor@kernel.org
Cc: linux-hwmon@vger.kernel.org, linux@roeck-us.net, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, corbet@lwn.net,
skhan@linuxfoundation.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Sanman Pradhan
In-Reply-To: <20260527-exuberant-broadband-052c3526847f@spud>
From: Sanman Pradhan <psanman@juniper.net>
Thanks Conor for the review. Will fix in v2, will add an allOf reference
to regulator.yaml and switch to unevaluatedProperties: false, will follow
the same pattern as adi,max20830.yaml, if that's ok.
Regards,
Sanman Pradhan
^ permalink raw reply
* Re: [PATCH mm-unstable v18 11/14] mm/khugepaged: Introduce mTHP collapse support
From: Nico Pache @ 2026-05-28 17:11 UTC (permalink / raw)
To: Wei Yang
Cc: Andrew Morton, linux-doc, linux-kernel, linux-mm,
linux-trace-kernel, aarcange, anshuman.khandual, apopple, baohua,
baolin.wang, byungchul, catalin.marinas, cl, corbet, dave.hansen,
david, dev.jain, gourry, hannes, hughd, jack, jackmanb, jannh,
jglisse, joshua.hahnjy, kas, lance.yang, liam, ljs,
mathieu.desnoyers, matthew.brost, mhiramat, mhocko, peterx,
pfalcato, rakie.kim, raquini, rdunlap, rientjes, rostedt, rppt,
ryan.roberts, shivankg, sunnanyong, surenb, thomas.hellstrom,
tiwai, usamaarif642, vbabka, vishal.moola, wangkefeng.wang, will,
willy, yang, ying.huang, ziy, zokeefe
In-Reply-To: <20260528084211.wsdrvbvxvkddokb5@master>
On Thu, May 28, 2026 at 2:42 AM Wei Yang <richard.weiyang@gmail.com> wrote:
>
> On Tue, May 26, 2026 at 06:07:38AM -0600, Nico Pache wrote:
> >On Tue, May 26, 2026 at 12:57 AM Wei Yang <richard.weiyang@gmail.com> wrote:
> >>
> >> On Mon, May 25, 2026 at 12:10:41PM -0700, Andrew Morton wrote:
> >> >On Mon, 25 May 2026 08:15:53 -0600 Nico Pache <npache@redhat.com> wrote:
> >> >
> >> >> Can you please append the following fixup that reverts one of the
> >> >> changes requested in V17. The issue with the change is described
> >> >> below.
> >> >
> >> >OK. fyi, what I received was badly mangled: wordwrapping, tabs messed
> >> >up, etc.
> >> >
> >> >Here's my reconstruction:
> >> >
> >>
> >> Hi, Nico
> >>
> >> I tried to reply your mail, but found it has some encoding problem, so reply
> >> here.
> >
> >Yeah sorry I didnt properly configure my email client after getting a
> >new laptop.
> >
> >>
> >> >
> >> >Author: Nico Pache <npache@redhat.com>
> >> >Subject: fix potential use-after-free of vma in mthp_collapse()
> >> >Date: Mon May 25 07:38:59 2026 -0600
> >> >
> >> >Between V17 and v18, one reviewer (Wei) brought up that we are not doing
> >> >the uffd-armed check until deep in the collapse operation. While not
> >> >functionally incorrect, it can lead to unnecessary work.
> >>
> >> So we decide to tolerate the behavioral change?
> >
> >Yes, I believe it is ok for now. Either way we needed to remove the
> >potential UAF. It only affects the behavior if mTHP is enabled, so the
> >legacy behavior is kept. And the uffd case is limited.
> >
> >My future work involves further optimizing and cleaning up khugepaged.
> >I'll make this part of the goal too. My first thought is to do the
> >revalidation at every order (between the locks dropping); but that
> >essentially pays the same penalty... I can't think of a clean solution
> >at the moment.
>
> One way come into my mind is add a @was_uffd_armed field in collapse_control
> and updates it in hugepage_vma_revalidate() when latest vma is retrieved.
>
> Still not elegant enough.
So our issue is that userfaultfd_armed is at the VMA granularity.
Ideally we want PMD/PTE granularity, but we only have that for wp. I'm
just still investigating all the nuances of uffd and its interactions
with khugepaged (something I've been meaning to understand more of
anyway). But from what i understand so far we actually can use the
bitmap and the was_uffd_armed to optimize this further. It solves the
issue and has a rather small race window, which can just be handled by
the revalidation later on, probably eliminating most of the potential
cases.
IIUC, filling a region with previously empty/zero pages is only an
issue for MODE_MISSING and MODE_WP with WP_UNPOPULATED set as well. I
have a work in progress commit to improve all this uffd handling.
I think what i have is a good middle ground. It improves the current
functionality and closes this gap we have with the new mthp_collapse--
best of both worlds. If the race window is hit, we will pay the
penalty, but that should be greatly reduced. I will send out an RFC
for this targeting mm-new once I have everything verified and cleaned
up :)
Cheers,
-- Nico
>
> >
> >Does that sound ok?
> >
>
> Not sure. I can't imagine the impact it would have.
>
> >Cheers,
> >-- Nico
>
>
> --
> Wei Yang
> Help you, Help me
>
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwmon: pmbus: Add Analog Devices MAX20860A
From: Conor Dooley @ 2026-05-28 17:16 UTC (permalink / raw)
To: Pradhan, Sanman
Cc: linux-hwmon@vger.kernel.org, linux@roeck-us.net, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, corbet@lwn.net,
skhan@linuxfoundation.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Sanman Pradhan
In-Reply-To: <20260528170618.85027-1-sanman.pradhan@hpe.com>
[-- Attachment #1: Type: text/plain, Size: 501 bytes --]
On Thu, May 28, 2026 at 05:06:30PM +0000, Pradhan, Sanman wrote:
> From: Sanman Pradhan <psanman@juniper.net>
>
> Thanks Conor for the review. Will fix in v2, will add an allOf reference
> to regulator.yaml and switch to unevaluatedProperties: false, will follow
> the same pattern as adi,max20830.yaml, if that's ok.
Okay. Please don't remove quoted text when you reply, so that I don't
have to look on lore.kernel.org to figure out what it is that I am
commenting on.
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v2 01/10] dt-bindings: net: Add ADIN1140
From: Conor Dooley @ 2026-05-28 17:18 UTC (permalink / raw)
To: Regus, Ciprian
Cc: Parthiban Veerasooran, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, Andrew Lunn, Heiner Kallweit, Russell King,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <925d1903a01a44d8ac61b1302a820e6a@analog.com>
[-- Attachment #1: Type: text/plain, Size: 2000 bytes --]
On Thu, May 28, 2026 at 04:46:54PM +0000, Regus, Ciprian wrote:
> > > +title: ADI ADIN1140 10BASE-T1S MAC-PHY
> > > +
> > > +maintainers:
> > > + - Ciprian Regus <ciprian.regus@analog.com>
> > > +
> > > +description: |
> > > + The ADIN1140 (also called AD3306) is a low power single port
> >
> > Can you explain what is going on here please?
> > Is "adin1140" (which I can find no information easily online for) the
> > exact same device as the ad3306 (which has an entry on your site)?
>
> The adin1140 is an upcoming version of ad3306 that lacks some
> (stress test) qualifications, but otherwise they are the exact same die.
>
> >
> > > + 10BASE-T1S MAC-PHY. It integrates an Ethernet PHY with a MAC
> > > + and all the associated analog circuitry.
> > > + The device tries to implement the Open Alliance TC6 10BASE-T1x MAC-
> > PHY
> > > + Serial Interface specification and is compliant with the
> > > + IEEE 802.3cg-2019 Ethernet standard for 10 Mbps single pair
> > > + Ethernet (SPE). The device has a 4-wire SPI interface for
> > > + communication between the MAC and host processor.
> > > +
> > > +allOf:
> > > + - $ref: /schemas/net/ethernet-controller.yaml#
> > > + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> > > +
> > > +properties:
> > > + compatible:
> > > + enum:
> > > + - adi,ad3306
> > > + - adi,adin1140
> >
> > Because if they are really two names for the same part, this compatible
> > setup makes no sense, as it means they have a different programming
> > models.
>
> Since they have the same programming model, should I just keep the adi,adin1140
> entry?
If the ad3306 was the existing device, probably it should be the
compatible you keep, if you remove any.
Otherwise, just permit ad3306 as a fallback for adin1140:
compatible:
oneOf:
- items:
- const: adi,adin1140
- const: adi,ad3306
- const: adi,ad3306
>
> >
> > Thanks,
> > Conor.
> >
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2] docs: pt_BR: update maintainer-handbooks
From: Daniel Pereira @ 2026-05-28 17:22 UTC (permalink / raw)
To: Jonathan Corbet; +Cc: Amanda Corrêa, linux-doc
In-Reply-To: <874ijrlhf4.fsf@trenco.lwn.net>
On Thu, May 28, 2026 at 11:47 AM Jonathan Corbet <corbet@lwn.net> wrote:
>
>
> Is that an Acked-by?
>
> Thanks,
>
> jon
Hi Jon,
Yes, that is an Acked-by.
The preceding text was just a note to Amanda regarding maintaining a
consistent subject line for her future contributions, but the patch
itself is fine.
Thanks,
Daniel
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwmon: pmbus: Add Analog Devices MAX20860A
From: Pradhan, Sanman @ 2026-05-28 17:29 UTC (permalink / raw)
To: conor@kernel.org
Cc: linux-hwmon@vger.kernel.org, linux@roeck-us.net, robh@kernel.org,
krzk+dt@kernel.org, conor+dt@kernel.org, corbet@lwn.net,
skhan@linuxfoundation.org, devicetree@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Sanman Pradhan
In-Reply-To: <20260528-resupply-sympathy-f590eb8616ce@spud>
From: Sanman Pradhan <psanman@juniper.net>
On Thu, May 28, 2026 at 18:16:25 +0100, Conor Dooley wrote:
> On Thu, May 28, 2026 at 05:06:30PM +0000, Pradhan, Sanman wrote:
> > From: Sanman Pradhan <psanman@juniper.net>
> >
> > Thanks Conor for the review. Will fix in v2, will add an allOf reference
> > to regulator.yaml and switch to unevaluatedProperties: false, will follow
> > the same pattern as adi,max20830.yaml, if that's ok.
>
> Okay. Please don't remove quoted text when you reply, so that I don't
> have to look on lore.kernel.org to figure out what it is that I am
> commenting on.
Apologies for stripping the quoted context, will make sure to
preserve it going forward.
Thank you.
Regards,
Sanman Pradhan
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: hwmon: pmbus: Add Analog Devices MAX20860A
From: Pradhan, Sanman @ 2026-05-28 17:34 UTC (permalink / raw)
To: linux-hwmon@vger.kernel.org
Cc: linux@roeck-us.net, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Syed, Arif, Sanman Pradhan
In-Reply-To: <20260528173424.87503-1-sanman.pradhan@hpe.com>
From: Sanman Pradhan <psanman@juniper.net>
Add devicetree binding documentation for the Analog Devices MAX20860A
step-down DC-DC switching regulator with PMBus interface.
Both "adi,max20860a" and "maxim,max20860a" compatible strings are
supported. The MAX20860A was originally manufactured by Maxim Integrated,
now part of Analog Devices.
Signed-off-by: Sanman Pradhan <psanman@juniper.net>
---
v2:
- Added allOf regulator.yaml reference and unevaluatedProperties
- Added "maxim,max20860a" as alternative compatible
.../bindings/hwmon/pmbus/adi,max20860a.yaml | 47 ++++++++++++++++++++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml
new file mode 100644
index 000000000000..f7eeb30f11b3
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/hwmon/pmbus/adi,max20860a.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Analog Devices MAX20860A Step-Down Converter
+
+maintainers:
+ - Sanman Pradhan <psanman@juniper.net>
+
+description: |
+ The MAX20860A is a fully integrated step-down DC-DC switching regulator
+ with PMBus interface for monitoring input/output voltage, output current
+ and temperature.
+
+ Datasheet: https://www.analog.com/en/products/max20860a.html
+
+allOf:
+ - $ref: /schemas/regulator/regulator.yaml#
+
+properties:
+ compatible:
+ enum:
+ - adi,max20860a
+ - maxim,max20860a
+
+ reg:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ i2c {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ regulator@40 {
+ compatible = "adi,max20860a";
+ reg = <0x40>;
+ };
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH v2 2/2] hwmon: (pmbus/max20860a) Add driver for Analog Devices MAX20860A
From: Pradhan, Sanman @ 2026-05-28 17:34 UTC (permalink / raw)
To: linux-hwmon@vger.kernel.org
Cc: linux@roeck-us.net, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org, corbet@lwn.net, skhan@linuxfoundation.org,
devicetree@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Syed, Arif, Sanman Pradhan
In-Reply-To: <20260528173424.87503-1-sanman.pradhan@hpe.com>
From: Syed Arif <arif.syed@hpe.com>
Add a PMBus driver for the Analog Devices MAX20860A step-down DC-DC
switching regulator. The MAX20860A provides monitoring of input/output
voltage, output current, and temperature via the PMBus interface using
linear data format.
Both "adi,max20860a" and "maxim,max20860a" compatible strings are
supported for devicetree matching.
Signed-off-by: Syed Arif <arif.syed@hpe.com>
Signed-off-by: Sanman Pradhan <psanman@juniper.net>
---
v2:
- Added "maxim,max20860a" to of_device_id table
- Removed WRITE_PROTECT write from probe
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/max20860a.rst | 57 ++++++++++++++++++++++++++++++
MAINTAINERS | 8 +++++
drivers/hwmon/pmbus/Kconfig | 9 +++++
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/max20860a.c | 58 +++++++++++++++++++++++++++++++
6 files changed, 134 insertions(+)
create mode 100644 Documentation/hwmon/max20860a.rst
create mode 100644 drivers/hwmon/pmbus/max20860a.c
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index e880c6ca84f0..ffaacda416e7 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -163,6 +163,7 @@ Hardware Monitoring Kernel Drivers
max20730
max20751
max20830
+ max20860a
max31722
max31730
max31760
diff --git a/Documentation/hwmon/max20860a.rst b/Documentation/hwmon/max20860a.rst
new file mode 100644
index 000000000000..ea6d2228fafc
--- /dev/null
+++ b/Documentation/hwmon/max20860a.rst
@@ -0,0 +1,57 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver max20860a
+=======================
+
+Supported chips:
+
+ * Analog Devices MAX20860A
+
+ Prefix: 'max20860a'
+
+ Addresses scanned: -
+
+ Datasheet: https://www.analog.com/en/products/max20860a.html
+
+Author:
+
+ - Syed Arif <arif.syed@hpe.com>
+ - Sanman Pradhan <psanman@juniper.net>
+
+
+Description
+-----------
+
+This driver supports hardware monitoring for Analog Devices MAX20860A
+Step-Down Switching Regulator with PMBus Interface.
+
+The MAX20860A is a fully integrated step-down DC-DC switching regulator.
+Through the PMBus interface, the device can monitor input/output voltages,
+output current and temperature.
+
+The driver is a client driver to the core PMBus driver. Please see
+Documentation/hwmon/pmbus.rst for details on PMBus client drivers.
+
+Usage Notes
+-----------
+
+This driver does not auto-detect devices. You will have to instantiate
+the devices explicitly.
+
+Sysfs entries
+-------------
+
+================= ========================================
+in1_label "vin"
+in1_input Measured input voltage
+in1_alarm Input voltage alarm
+in2_label "vout1"
+in2_input Measured output voltage
+in2_alarm Output voltage alarm
+curr1_label "iout1"
+curr1_input Measured output current
+curr1_alarm Output current alarm
+temp1_input Measured temperature
+temp1_alarm Chip temperature alarm
+temp2_input Measured temperature (secondary)
+================= ========================================
diff --git a/MAINTAINERS b/MAINTAINERS
index b71acb130395..1d9651947ee3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15688,6 +15688,14 @@ F: Documentation/devicetree/bindings/hwmon/pmbus/adi,max20830.yaml
F: Documentation/hwmon/max20830.rst
F: drivers/hwmon/pmbus/max20830.c
+MAX20860A HARDWARE MONITOR DRIVER
+M: Sanman Pradhan <psanman@juniper.net>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/devicetree/bindings/hwmon/pmbus/adi,max20860a.yaml
+F: Documentation/hwmon/max20860a.rst
+F: drivers/hwmon/pmbus/max20860a.c
+
MAX2175 SDR TUNER DRIVER
M: Ramesh Shanmugasundaram <rashanmu@gmail.com>
L: linux-media@vger.kernel.org
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index 64f38654f4e7..5825dda75f2c 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -402,6 +402,15 @@ config SENSORS_MAX20830
This driver can also be built as a module. If so, the module will
be called max20830.
+config SENSORS_MAX20860A
+ tristate "Analog Devices MAX20860A"
+ help
+ If you say yes here you get hardware monitoring support for Analog
+ Devices MAX20860A step-down converter.
+
+ This driver can also be built as a module. If so, the module will
+ be called max20860a.
+
config SENSORS_MAX31785
tristate "Maxim MAX31785 and compatibles"
help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index 1f2c73b71953..ffc05f493213 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_SENSORS_MAX17616) += max17616.o
obj-$(CONFIG_SENSORS_MAX20730) += max20730.o
obj-$(CONFIG_SENSORS_MAX20751) += max20751.o
obj-$(CONFIG_SENSORS_MAX20830) += max20830.o
+obj-$(CONFIG_SENSORS_MAX20860A) += max20860a.o
obj-$(CONFIG_SENSORS_MAX31785) += max31785.o
obj-$(CONFIG_SENSORS_MAX34440) += max34440.o
obj-$(CONFIG_SENSORS_MAX8688) += max8688.o
diff --git a/drivers/hwmon/pmbus/max20860a.c b/drivers/hwmon/pmbus/max20860a.c
new file mode 100644
index 000000000000..5274147ad3d0
--- /dev/null
+++ b/drivers/hwmon/pmbus/max20860a.c
@@ -0,0 +1,58 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Hardware monitoring driver for Analog Devices MAX20860A
+ *
+ * SPDX-FileCopyrightText: Copyright Hewlett Packard Enterprise Development LP
+ */
+
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include "pmbus.h"
+
+static struct pmbus_driver_info max20860a_info = {
+ .pages = 1,
+ .format[PSC_VOLTAGE_IN] = linear,
+ .format[PSC_VOLTAGE_OUT] = linear,
+ .format[PSC_CURRENT_OUT] = linear,
+ .format[PSC_TEMPERATURE] = linear,
+ .func[0] = PMBUS_HAVE_VIN | PMBUS_HAVE_VOUT |
+ PMBUS_HAVE_STATUS_VOUT |
+ PMBUS_HAVE_IOUT | PMBUS_HAVE_STATUS_IOUT |
+ PMBUS_HAVE_TEMP | PMBUS_HAVE_TEMP2 |
+ PMBUS_HAVE_STATUS_TEMP | PMBUS_HAVE_STATUS_INPUT,
+};
+
+static int max20860a_probe(struct i2c_client *client)
+{
+ return pmbus_do_probe(client, &max20860a_info);
+}
+
+static const struct i2c_device_id max20860a_id[] = {
+ {"max20860a"},
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, max20860a_id);
+
+static const struct of_device_id max20860a_of_match[] = {
+ { .compatible = "adi,max20860a" },
+ { .compatible = "maxim,max20860a" },
+ {}
+};
+MODULE_DEVICE_TABLE(of, max20860a_of_match);
+
+static struct i2c_driver max20860a_driver = {
+ .driver = {
+ .name = "max20860a",
+ .of_match_table = max20860a_of_match,
+ },
+ .probe = max20860a_probe,
+ .id_table = max20860a_id,
+};
+
+module_i2c_driver(max20860a_driver);
+
+MODULE_AUTHOR("Syed Arif <arif.syed@hpe.com>");
+MODULE_AUTHOR("Sanman Pradhan <psanman@juniper.net>");
+MODULE_DESCRIPTION("PMBus driver for Analog Devices MAX20860A");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("PMBUS");
--
2.34.1
^ 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