* Re: [PATCH v4 1/2] usb: xhci-pci: add AMD Promontory 21 PCI glue
From: Jihong Min @ 2026-05-08 17:39 UTC (permalink / raw)
To: Mario Limonciello, Jihong Min, Greg Kroah-Hartman, Mathias Nyman
Cc: Guenter Roeck, Jonathan Corbet, Shuah Khan, Basavaraj Natikar,
linux-usb, linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <ad41d70b-e9c0-446e-8bd0-4528de75b592@amd.com>
> This define should be in a common header used by xhci-pci.c and
> xhci-pci-prom21.c both.
Agreed. I moved PCI_DEVICE_ID_AMD_PROM21_XHCI to xhci-pci.h so both
xhci-pci.c and xhci-pci-prom21.c use the same definition.
Sincerely,
Jihong Min
^ permalink raw reply
* Re: [PATCH v4 2/2] hwmon: add AMD Promontory 21 xHCI temperature sensor support
From: Jihong Min @ 2026-05-08 17:40 UTC (permalink / raw)
To: Mario Limonciello, Jihong Min, Greg Kroah-Hartman, Mathias Nyman
Cc: Guenter Roeck, Jonathan Corbet, Shuah Khan, Basavaraj Natikar,
linux-usb, linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <f682afbb-e816-44e6-9b18-fc7e2335706e@amd.com>
> Rather than using pm_ref as an output variable to indicate whether you
> took a ref - how about you instead always take a ref on success and
> return an error on fail? This would feel more logical to me.
Agreed. I changed the PM helper so success always means that a usage
reference
is held, and the caller now unconditionally drops it with
pm_runtime_put_noidle()
after the register access.
For the runtime PM disabled case, pm_runtime_get_if_active() returns
-EINVAL.
In that case the helper now allows the read if the device is not marked
suspended, and uses pm_runtime_get_noresume() so the same success/put
contract
is preserved without changing the runtime PM state.
> guard(mutex) perhaps?
The private mutex is gone. Guenter pointed out that the hwmon core already
serializes the callbacks, so I removed the extra lock instead of
converting it.
> You only care about the first byte, right? Just use readb() and make
> data a u8.
Done. The data register read now uses readb(), and the local data
variable is
u8.
> I personally don't really like changing the pointer when there is
> potentially an error case with it for -ENODATA.
Done. The raw output pointer is only written after validating the read
value.
> Does 0xff actually happen with your runtime PM handling? Between my
> suggestion above to use readb() this can turn into:
>
> if (!data)
> return -ENODDATA;
> *raw = data;
>
> return 0;
Done. I removed the 0xff invalid check. Suspended devices are rejected
before
the MMIO access, so the read path now only treats zero as invalid and
assigns
*raw after that check.
Sincerely,
Jihong Min
^ permalink raw reply
* Re: [PATCH RFC v4 10/44] KVM: guest_memfd: Add support for KVM_SET_MEMORY_ATTRIBUTES2
From: Sean Christopherson @ 2026-05-08 17:40 UTC (permalink / raw)
To: Michael Roth
Cc: Ackerley Tng, aik, andrew.jones, binbin.wu, brauner, chao.p.peng,
david, ira.weiny, jmattson, jthoughton, oupton, pankaj.gupta,
qperret, rick.p.edgecombe, rientjes, shivankg, steven.price,
tabba, willy, wyihan, yan.y.zhao, forkloop, pratyush,
suzuki.poulose, aneesh.kumar, Paolo Bonzini, Thomas Gleixner,
Ingo Molnar, Borislav Petkov, Dave Hansen, x86, H. Peter Anvin,
Steven Rostedt, Masami Hiramatsu, Mathieu Desnoyers,
Jonathan Corbet, Shuah Khan, Shuah Khan, Vishal Annapurve,
Andrew Morton, Chris Li, Kairui Song, Kemeng Shi, Nhat Pham,
Baoquan He, Barry Song, Axel Rasmussen, Yuanchu Xie, Wei Xu,
Jason Gunthorpe, Vlastimil Babka, kvm, linux-kernel,
linux-trace-kernel, linux-doc, linux-kselftest, linux-mm
In-Reply-To: <foi2zvv5qrfdcspnx4fstrvzl74m6xp6zrsw5omlbprxh4jrhx@vxnwk7fr46gu>
On Wed, Apr 29, 2026, Michael Roth wrote:
> On Fri, Apr 24, 2026 at 12:08:45PM -0700, Ackerley Tng wrote:
> > Michael Roth <michael.roth@amd.com> writes:
> >
> > Thank you for your patches!
> >
> > >
> > > [...snip...]
> > >
> > >>
> > >> I also did some minor updates (prefixed with a "[squash]" tag) to advertise
> > >> the KVM_SET_MEMORY_ATTRIBUTES2_PRESERVED flag so it can be used by
> > >
> > > Though I'm not sure how we deal with it if SNP/TDX at some point become
> > > capable of using the PRESERVED flag *after* populate... but maybe that's
> > > too unlikely to worry about? If we wanted to address it though, we could
> > > have both PRESERVED and PRESERVED_BEFORE_LAUNCH so they can be
> > > enumerated separately from the start.
> > >
> >
> > Not sure how likely it is, but if SNP and TDX can honor PRESERVE
> > semantics after populate, I think we could implement support under a new
> > flag like CIPHER.
>
> That works, but it still makes things *slightly* awkward due to special-casing
> the PRESERVE semantics for 1 guest type vs. another.
Summarizing this week's PUCK call[*]:
Scrap PRESERVE and ZERO, and simply rely on vendor specific semantics.
My desire to enforce PRESERVE and ZERO semantics and avoid relying on vendor specific
behavior (i.e. on trusted firmware semantics) is a pipe dream. Unless KVM does
a truly insane amount of per-gfn tracking, KVM can't know the state of memory for
a given page, and so can't guarantee PRESERVE or ZERO will be honored.
If userspace requests PRESERVE, just because it's _possible_ to preserve contents
(e.g. during the pre-boot phase on TDX), doesn't mean the contents are _guaranteed_
to be preserved. If userspace doesn't actually ADD the memory to the guest's
initial image, then the contents won't be preserved. Ditto for SNP.
To guarantee PRESERVE, KVM would need to track per-gfn information to know if the
memory was actually preserved. And enforcing PRESERVE would be all kinds of crazy;
KVM would have to kill the VM or something? And that would still require userspace
to be aware of vendor specific details.
The same holds true for ZERO. On a private=>shared conversion, KVM can't guarantee
the memory is zeroed by trusted firmware unless KVM tracks, per-gfn, whether or
not the memory was actually fully assigned to the guest. E.g. if userspace does
shared=>private and then private=>shared(ZERO), without the memory being faulted
into the guest, then the TDX-Module won't have "seen" the page and so wont' have
zeroed it on the private=>shared conversion.
And trying to special case SNP's "validated CPUID" behavior, where memory can be
preserved on private=>shared after a failed shared=>private, would also require
tracking that the page was never actually converted to private.
Note, regarding ZERO, someone (Mike? Ackerley?) pointed out that userspace typically
doesn't rely on the kernel to zero memory, and so supporting ZERO for private=>shared
isn't really all that valuable in the first place.
[*] https://drive.google.com/file/d/1w0ifzh5PmNViJ1SKru9jK9x52MybXSNa/view?usp=drive_link
^ permalink raw reply
* Re: [PATCH 2/5] docs: fix repeated word 'that' across documentation
From: Randy Dunlap @ 2026-05-08 17:40 UTC (permalink / raw)
To: Shuah Khan, Adrien Reynard, Paul E. McKenney, Frederic Weisbecker,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Jonathan Corbet, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, David Howells,
Paulo Alcantara, Masami Hiramatsu,
open list:READ-COPY UPDATE (RCU), open list:DOCUMENTATION,
open list, open list:DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS,
open list:FILESYSTEMS [NETFS LIBRARY],
open list:FILESYSTEMS [NETFS LIBRARY], open list:TRACING
In-Reply-To: <1501caea-8cff-4968-aca6-e8d4b20e0e80@linuxfoundation.org>
On 5/8/26 10:15 AM, Shuah Khan wrote:
> On 5/8/26 10:37, Adrien Reynard wrote:
>
> Missing commit log in all your patches - I don't patch 1/5 in
> my Inbox.
>
>> Signed-off-by: Adrien Reynard <reynard.adrien.08@gmail.com>
>> ---
>> Documentation/RCU/rcu.rst | 2 +-
>> Documentation/driver-api/driver-model/overview.rst | 2 +-
>> Documentation/filesystems/netfs_library.rst | 2 +-
>> Documentation/trace/histogram-design.rst | 2 +-
>> Documentation/trace/histogram.rst | 2 +-
>> 5 files changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/Documentation/RCU/rcu.rst b/Documentation/RCU/rcu.rst
>> index bf6617b330a7..320ad3292b75 100644
>> --- a/Documentation/RCU/rcu.rst
>> +++ b/Documentation/RCU/rcu.rst
>> @@ -32,7 +32,7 @@ Frequently Asked Questions
>> Just as with spinlocks, RCU readers are not permitted to
>> block, switch to user-mode execution, or enter the idle loop.
>> Therefore, as soon as a CPU is seen passing through any of these
>> - three states, we know that that CPU has exited any previous RCU
>> + three states, we know that CPU has exited any previous RCU
>
> The original intent might have been to say, "that cpu", so adding
> the missing comma after the first "that" or change "that" to "the"
> would make sense.
Not a comma, please.
I don't see a problem with "that that," but "that the" could also be OK.
>
>
>> read-side critical sections. So, if we remove an item from a
>> linked list, and then wait until all CPUs have switched context,
>> executed in user mode, or executed in the idle loop, we can
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 1/2] usb: xhci-pci: add AMD Promontory 21 PCI glue
From: Mario Limonciello @ 2026-05-08 17:42 UTC (permalink / raw)
To: Jihong Min, Jihong Min, Greg Kroah-Hartman, Mathias Nyman
Cc: Guenter Roeck, Jonathan Corbet, Shuah Khan, Basavaraj Natikar,
linux-usb, linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <0d518d40-e239-4d93-8e71-0d2e140f00ca@icloud.com>
On 5/8/26 12:39, Jihong Min wrote:
> > This define should be in a common header used by xhci-pci.c and
> > xhci-pci-prom21.c both.
>
> Agreed. I moved PCI_DEVICE_ID_AMD_PROM21_XHCI to xhci-pci.h so both
> xhci-pci.c and xhci-pci-prom21.c use the same definition.
>
> Sincerely,
> Jihong Min
>
Something else I was thinking about while reviewing this series.
Promontory 21 is only on AMD platforms and AMD platforms are only x86.
I think the Kconfig should be conditional on AMD CPU support being
enabled and X86 architecture so that we don't bloat other architectures
with dead code that will never run.
^ permalink raw reply
* Re: [PATCH 4/5] docs: fix repeated prepositions across documentation
From: Randy Dunlap @ 2026-05-08 17:44 UTC (permalink / raw)
To: Shuah Khan, Adrien Reynard, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino,
Jonathan Corbet, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Richard Weinberger, Anton Ivanov,
Johannes Berg, open list:KASAN, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list,
open list:NETWORKING [GENERAL], open list:USER-MODE LINUX (UML)
In-Reply-To: <2b771350-0562-4cb1-b9b3-cc3ce59b1a63@linuxfoundation.org>
On 5/8/26 10:23 AM, Shuah Khan wrote:
> On 5/8/26 10:38, Adrien Reynard wrote:
>
> Missing commit log
>
>> Signed-off-by: Adrien Reynard <reynard.adrien.08@gmail.com>
>> ---
>> Documentation/dev-tools/kasan.rst | 2 +-
>> Documentation/networking/switchdev.rst | 2 +-
>> Documentation/virt/uml/user_mode_linux_howto_v2.rst | 2 +-
>> 3 files changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
>> index 4968b2aa60c8..3a8bd40ad905 100644
>> --- a/Documentation/dev-tools/kasan.rst
>> +++ b/Documentation/dev-tools/kasan.rst
>> @@ -392,7 +392,7 @@ reserved to tag freed memory regions.
>> If the hardware does not support MTE (pre ARMv8.5), Hardware Tag-Based KASAN
>> will not be enabled. In this case, all KASAN boot parameters are ignored.
>> -Note that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
>> +Note that enabling CONFIG_KASAN_HW_TAGS always results in-kernel TBI being
>
> This is correct the way it is - no need to change this. "results in in-kernel"
ack.
>> enabled. Even when ``kasan.mode=off`` is provided or when the hardware does not
>> support MTE (but supports TBI).
>> diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst
>> index 2966b7122f05..948bce44ca9b 100644
>> --- a/Documentation/networking/switchdev.rst
>> +++ b/Documentation/networking/switchdev.rst
>> @@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
>> monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
>> bond will see its upper master change. If that bond is moved into a bridge,
>> the bond's upper master will change. And so on. The driver will track such
>> -movements to know what position a port is in in the overall topology by
>> +movements to know what position a port is in the overall topology by
>
> This looks fine.
Change not needed.
>> registering for netdevice events and acting on NETDEV_CHANGEUPPER.
>> L2 Forwarding Offload
>> diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
>> index c37e8e594d12..7b08738c30aa 100644
>> --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst
>> +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
>> @@ -1092,7 +1092,7 @@ be formatted as plain text.
>> Developing always goes hand in hand with debugging. First of all,
>> you can always run UML under gdb and there will be a whole section
>> -later on on how to do that. That, however, is not the only way to
>> +later on how to do that. That, however, is not the only way to
>
> This change is not needed. If at all add a comma after "later" to make
> a distinction between the use two back to back "on"s
>
> "later on,"
We disagree. :)
This change LGTM.
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 1/2] usb: xhci-pci: add AMD Promontory 21 PCI glue
From: Jihong Min @ 2026-05-08 17:48 UTC (permalink / raw)
To: Mario Limonciello, Jihong Min, Greg Kroah-Hartman, Mathias Nyman
Cc: Guenter Roeck, Jonathan Corbet, Shuah Khan, Basavaraj Natikar,
linux-usb, linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <966c9e07-10e6-4abe-9cb5-77b974f31302@amd.com>
> Something else I was thinking about while reviewing this series.
>
> Promontory 21 is only on AMD platforms and AMD platforms are only x86.
> I think the Kconfig should be conditional on AMD CPU support being
> enabled and X86 architecture so that we don't bloat other
> architectures with dead code that will never run.
Agreed. PROM21 is AMD x86 platform-specific, so I will add X86 and
CPU_SUP_AMD dependencies to USB_XHCI_PCI_PROM21 for v5.
Sincerely,
Jihong Min
^ permalink raw reply
* Re: [PATCH 2/5] docs: fix repeated word 'that' across documentation
From: Paul E. McKenney @ 2026-05-08 17:52 UTC (permalink / raw)
To: Randy Dunlap
Cc: Shuah Khan, Adrien Reynard, Frederic Weisbecker, Neeraj Upadhyay,
Joel Fernandes, Josh Triplett, Boqun Feng, Uladzislau Rezki,
Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Zqiang,
Jonathan Corbet, Greg Kroah-Hartman, Rafael J. Wysocki,
Danilo Krummrich, David Howells, Paulo Alcantara,
Masami Hiramatsu, open list:READ-COPY UPDATE (RCU),
open list:DOCUMENTATION, open list,
open list:DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS,
open list:FILESYSTEMS [NETFS LIBRARY],
open list:FILESYSTEMS [NETFS LIBRARY], open list:TRACING
In-Reply-To: <5f68ac30-21ac-494b-a140-2307e236f0a2@infradead.org>
On Fri, May 08, 2026 at 10:40:49AM -0700, Randy Dunlap wrote:
>
>
> On 5/8/26 10:15 AM, Shuah Khan wrote:
> > On 5/8/26 10:37, Adrien Reynard wrote:
> >
> > Missing commit log in all your patches - I don't patch 1/5 in
> > my Inbox.
> >
> >> Signed-off-by: Adrien Reynard <reynard.adrien.08@gmail.com>
> >> ---
> >> Documentation/RCU/rcu.rst | 2 +-
> >> Documentation/driver-api/driver-model/overview.rst | 2 +-
> >> Documentation/filesystems/netfs_library.rst | 2 +-
> >> Documentation/trace/histogram-design.rst | 2 +-
> >> Documentation/trace/histogram.rst | 2 +-
> >> 5 files changed, 5 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/Documentation/RCU/rcu.rst b/Documentation/RCU/rcu.rst
> >> index bf6617b330a7..320ad3292b75 100644
> >> --- a/Documentation/RCU/rcu.rst
> >> +++ b/Documentation/RCU/rcu.rst
> >> @@ -32,7 +32,7 @@ Frequently Asked Questions
> >> Just as with spinlocks, RCU readers are not permitted to
> >> block, switch to user-mode execution, or enter the idle loop.
> >> Therefore, as soon as a CPU is seen passing through any of these
> >> - three states, we know that that CPU has exited any previous RCU
> >> + three states, we know that CPU has exited any previous RCU
> >
> > The original intent might have been to say, "that cpu", so adding
> > the missing comma after the first "that" or change "that" to "the"
> > would make sense.
>
> Not a comma, please.
> I don't see a problem with "that that," but "that the" could also be OK.
This CPU was already mentioned. So if for whatever reason we cannnot
stomach "that that", then "that this" would be better than "that the".
I suppose that false positives from simple grammar checkers might be
sufficient reason, but in this brave new world of LLMs, shouldn't we
be hoping for better? ;-)
Thanx, Paul
> >> read-side critical sections. So, if we remove an item from a
> >> linked list, and then wait until all CPUs have switched context,
> >> executed in user mode, or executed in the idle loop, we can
>
>
> --
> ~Randy
>
^ permalink raw reply
* Re: [RFC net-next 0/4] devlink: Add boot-time defaults
From: Mark Bloch @ 2026-05-08 17:59 UTC (permalink / raw)
To: Jiri Pirko
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller, Jonathan Corbet, Shuah Khan, Simon Horman,
Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Andrew Morton,
Borislav Petkov (AMD), Randy Dunlap, Dave Hansen,
Christian Brauner, Petr Mladek, Peter Zijlstra (Intel),
Thomas Gleixner, Pawan Gupta, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, Li RongQing, Paul E. McKenney, linux-doc,
linux-kernel, netdev, linux-rdma
In-Reply-To: <afxvzOjqw-vxUAED@FV6GYCPJ69>
On 07/05/2026 14:03, Jiri Pirko wrote:
> Wed, May 06, 2026 at 07:35:10PM +0200, mbloch@nvidia.com wrote:
>>
>>
>> On 06/05/2026 18:22, Jiri Pirko wrote:
>>> Wed, May 06, 2026 at 02:37:35PM +0200, mbloch@nvidia.com wrote:
>>>> This series adds a devlink= kernel command line parameter for applying
>>>> selected devlink settings during device initialization.
>>>>
>>>> Following a discussion with Jakub[1], I am sending this RFC to get the
>>>> conversation moving. I started from Jakub's example/request and extended
>>>> it to cover requirements from production systems and configurations that
>>>> customers use.
>>>>
>>>> One important caveat is that the parsing logic in this RFC was written
>>>> with AI assistance. I am also not sure whether the resulting syntax and
>>>> parser are too complex for a kernel command line interface. This is part
>>>> of why I am sending it as an RFC: to understand what direction and level
>>>> of complexity would be acceptable to people.
>>>>
>>>> The implementation is intended to support the following properties:
>>>>
>>>> - A system may have multiple devlink devices that usually need the same
>>>> configuration. For a configuration such as eswitch mode switchdev, a
>>>> user should be able to specify multiple devices to which that
>>>> configuration applies.
>>>>
>>>> - There may be ordering dependencies between options. For example, in
>>>> mlx5, flow_steering_mode should be set before moving to switchdev.
>>>> With this in mind, defaults are applied per device in the left-to-right
>>>> order in which they appear on the command line.
>>>>
>>>> The intent is to let deployments set devlink defaults before normal
>>>> userspace orchestration runs, while still using devlink concepts and
>>>
>>> "defaults before normal userspace orchestrarion". I read it as config
>>> before config, which eventually could be skipped.
>>>
>>>
>>>> driver callbacks rather than adding driver-specific module parameters.
>>>> A default is scoped to one or more devlink handles, for example:
>>>>
>>>> devlink=[pci/0000:08:00.0]:esw:mode:switchdev
>>>> devlink=[pci/0000:08:00.0]:param:flow_steering_mode:smfs
>>>> devlink=[pci/0000:08:00.0,pci/0000:08:00.1]:param:flow_steering_mode:hmfs,[pci/0000:08:00.0,pci/0000:08:00.1]:esw:mode:switchdev
>>>
>>> I don't like this. What you do, you are basically introducing user
>>> configuration tool on kernel cmdline.
>>>
>>> The same you would achieve with a proper userspace tool/daemon.
>>> I did try to come up with it and push it here:
>>> https://github.com/systemd/systemd/pull/37393
>>> That didn't get merged for unknown reason, but the idea is sound. You
>>> provide configuration files for devlink object and systemd-devlinkd
>>> will apply when they appear. Wouldn't this help your case?
>>
>> I agree that systemd-devlinkd is the right shape for normal
>> devlink configuration, and it could probably replace the udev/devlink
>> plumbing we use today.
>>
>> The case I am trying to cover is earlier than that.
>>
>> On BlueField/ECPF/DPU systems, the host PF driver cannot always finish
>> probing independently of the ECPF side. When the ECPF is the eswitch
>> manager, the host PF is kept in initializing state until the ECPF eswitch
>> side is set up and mlx5 enables the external host PF HCA. That happens as
>> part of moving the ECPF to switchdev.
>>
>> Today userspace observes the ECPF instance and then switches the
>> mode through devlink, usually via udev or similar plumbing. That still
>> leaves a window where the ECPF has probed, userspace has not applied the
>> mode yet, and the host PF is waiting. With many ECPFs this becomes visible
>> in host PF probe/boot time. A daemon reacting to the devlink object
>> appearing can make the userspace side cleaner, but it still runs after the
>> device has appeared and after userspace scheduling/uevent handling.
>>
>> Long term, for these DPU deployments, we would like mlx5 to initialize
>> directly in switchdev. I am hesitant to make that unconditional because it
>> changes existing behavior and there is no early opt-out before probe. The
>> cmdline parameter was meant as an explicit opt-in middle step: ask the
>> driver to apply the same devlink operation during init, before this path
>> depends on userspace.
>>
>> We previously tried to address this with an mlx5 module parameter. By
>> design, that was too coarse: it applied to all mlx5 devices handled by the
>> module. That makes it usable only for narrow DPU-only configurations. The
>> devlink-handle based cmdline syntax was intended to keep the opt-in scoped
>> to the specific devices that need this early switchdev transition.
>
> The switchdev mode was introduced at roughly the time CX4 was out. What
> stopped us from making it default for CX4+ ?
>
> Introducing this horrible plumbing only bacause we were not able to
> change the default sounds so absurd.
>
> Can we write the default mode as a bit in ASIC NV memory perhaps? Simple
> devlink cmode permanent param to write it, the driver can read this bit
> during init to decide the init flow path?
I don't think switchdev by default should mean CX4+ in general. If we get
there, I would expect it to be limited to the DPU/BlueField/ECPF case, where
the host PF probe path can depend on the ECPF reaching switchdev. Changing the
default for regular host NIC deployments feels like a much larger compatibility
change.
For the ASIC/NV bit: maybe technically possible, but it feels like the wrong
layer. This is boot/deployment policy, not a persistent hardware property, and
storing it in NV memory would make the state persist across kernels/hosts in a
surprising way.
I do agree the RFC probably went too far by making a generic devlink cmdline
configuration language. Maybe the smaller thing to discuss is only:
devlink=[pci/...]:esw:mode:{legacy|switchdev|switchdev_inactive}
No runtime params, no ordering between different operations, just early eswitch
mode for explicitly selected handles.
@Jakub, I know you wanted something more generic/extensible, but maybe the
generic case belongs in the devlinkd/systemd direction Jiri pointed at, while
the kernel cmdline handles only this early boot eswitch mode case.
Mark
^ permalink raw reply
* Re: [v6 00/10] Reintroduce Hornet LSM
From: Blaise Boscaccy @ 2026-05-08 18:03 UTC (permalink / raw)
To: Paul Moore
Cc: Jonathan Corbet, James Morris, Serge E. Hallyn,
Mickaël Salaün, Günther Noack,
Dr. David Alan Gilbert, Andrew Morton, James.Bottomley, dhowells,
Fan Wu, Ryan Foster, Randy Dunlap, linux-security-module,
linux-doc, linux-kernel, bpf, Song Liu
In-Reply-To: <CAHC9VhScmOoCtoFtccJ6x_cTdwvKCBfUyg=1p-kuAGmo=FdgwA@mail.gmail.com>
Paul Moore <paul@paul-moore.com> writes:
> On Wed, Apr 29, 2026 at 3:14 PM Blaise Boscaccy
> <bboscaccy@linux.microsoft.com> wrote:
>>
>> This patch series introduces the next iteration of the Hornet LSM.
>> Hornet’s goal is to provide a secure and extensible in-kernel
>> signature verification mechanism for eBPF programs.
>
> I see that Fan identified a few issues that need resolution, but I
> just wanted to make sure you've read the expectations for a new LSM.
> To be clear, I think you've ticked all the boxes, and there is a
> MAINTAINERS entry with your name attached, but I just wanted to make
> sure you're okay with maintaining Hornet. I like Hornet, I think it's
> a nice and fairly clever solution, but the last thing I need is a new
> LSM to maintain :)
>
Yes, I'm good with maintaining Hornet. Thanks Paul
-blaise
> https://github.com/LinuxSecurityModule/kernel#new-lsms
>
> --
> paul-moore.com
^ permalink raw reply
* Re: [PATCH v9 00/22] Enable FRED with KVM VMX
From: Maciej Wieczor-Retman @ 2026-05-08 18:06 UTC (permalink / raw)
To: David Woodhouse
Cc: Andrew Cooper, Xin Li, linux-kernel, kvm, linux-doc,
Saenz Julienne, Nicolas, pbonzini, seanjc, corbet, tglx, mingo,
bp, dave.hansen, x86, hpa, luto, peterz, chao.gao, hch,
sohil.mehta
In-Reply-To: <9de74d88b3c1a2693a4758c023e97826d561c133.camel@infradead.org>
On 2026-05-08 at 15:46:41 +0100, David Woodhouse wrote:
>On Fri, 2026-05-08 at 16:25 +0200, Maciej Wieczor-Retman wrote:
>>
>> Just tested it and now it works fine :)
>
>Great, thanks. Including the __attribute__((used)) part?
Yeah, I didn't have to modify anything aside from commenting out the ICEBP part
for the test to pass.
>> (aside from the ICEBP thing of course but that's on the kernel side)
>
>Well yes, that was kind of the point in generating the selftest.
>
>I don't have access to hardware right now, but I can do test driven
>development by proxy... :)
Anytime :b
--
Kind regards
Maciej Wieczór-Retman
^ permalink raw reply
* Re: [RFC net-next 0/4] devlink: Add boot-time defaults
From: Jiri Pirko @ 2026-05-08 18:07 UTC (permalink / raw)
To: Mark Bloch
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Andrew Lunn,
David S. Miller, Jonathan Corbet, Shuah Khan, Simon Horman,
Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Andrew Morton,
Borislav Petkov (AMD), Randy Dunlap, Dave Hansen,
Christian Brauner, Petr Mladek, Peter Zijlstra (Intel),
Thomas Gleixner, Pawan Gupta, Dapeng Mi, Kees Cook, Marco Elver,
Eric Biggers, Li RongQing, Paul E. McKenney, linux-doc,
linux-kernel, netdev, linux-rdma
In-Reply-To: <b6a9b568-dd09-4414-be57-6b9cd282a43c@nvidia.com>
Fri, May 08, 2026 at 07:59:04PM +0200, mbloch@nvidia.com wrote:
>
>
>On 07/05/2026 14:03, Jiri Pirko wrote:
>> Wed, May 06, 2026 at 07:35:10PM +0200, mbloch@nvidia.com wrote:
>>>
>>>
>>> On 06/05/2026 18:22, Jiri Pirko wrote:
>>>> Wed, May 06, 2026 at 02:37:35PM +0200, mbloch@nvidia.com wrote:
>>>>> This series adds a devlink= kernel command line parameter for applying
>>>>> selected devlink settings during device initialization.
>>>>>
>>>>> Following a discussion with Jakub[1], I am sending this RFC to get the
>>>>> conversation moving. I started from Jakub's example/request and extended
>>>>> it to cover requirements from production systems and configurations that
>>>>> customers use.
>>>>>
>>>>> One important caveat is that the parsing logic in this RFC was written
>>>>> with AI assistance. I am also not sure whether the resulting syntax and
>>>>> parser are too complex for a kernel command line interface. This is part
>>>>> of why I am sending it as an RFC: to understand what direction and level
>>>>> of complexity would be acceptable to people.
>>>>>
>>>>> The implementation is intended to support the following properties:
>>>>>
>>>>> - A system may have multiple devlink devices that usually need the same
>>>>> configuration. For a configuration such as eswitch mode switchdev, a
>>>>> user should be able to specify multiple devices to which that
>>>>> configuration applies.
>>>>>
>>>>> - There may be ordering dependencies between options. For example, in
>>>>> mlx5, flow_steering_mode should be set before moving to switchdev.
>>>>> With this in mind, defaults are applied per device in the left-to-right
>>>>> order in which they appear on the command line.
>>>>>
>>>>> The intent is to let deployments set devlink defaults before normal
>>>>> userspace orchestration runs, while still using devlink concepts and
>>>>
>>>> "defaults before normal userspace orchestrarion". I read it as config
>>>> before config, which eventually could be skipped.
>>>>
>>>>
>>>>> driver callbacks rather than adding driver-specific module parameters.
>>>>> A default is scoped to one or more devlink handles, for example:
>>>>>
>>>>> devlink=[pci/0000:08:00.0]:esw:mode:switchdev
>>>>> devlink=[pci/0000:08:00.0]:param:flow_steering_mode:smfs
>>>>> devlink=[pci/0000:08:00.0,pci/0000:08:00.1]:param:flow_steering_mode:hmfs,[pci/0000:08:00.0,pci/0000:08:00.1]:esw:mode:switchdev
>>>>
>>>> I don't like this. What you do, you are basically introducing user
>>>> configuration tool on kernel cmdline.
>>>>
>>>> The same you would achieve with a proper userspace tool/daemon.
>>>> I did try to come up with it and push it here:
>>>> https://github.com/systemd/systemd/pull/37393
>>>> That didn't get merged for unknown reason, but the idea is sound. You
>>>> provide configuration files for devlink object and systemd-devlinkd
>>>> will apply when they appear. Wouldn't this help your case?
>>>
>>> I agree that systemd-devlinkd is the right shape for normal
>>> devlink configuration, and it could probably replace the udev/devlink
>>> plumbing we use today.
>>>
>>> The case I am trying to cover is earlier than that.
>>>
>>> On BlueField/ECPF/DPU systems, the host PF driver cannot always finish
>>> probing independently of the ECPF side. When the ECPF is the eswitch
>>> manager, the host PF is kept in initializing state until the ECPF eswitch
>>> side is set up and mlx5 enables the external host PF HCA. That happens as
>>> part of moving the ECPF to switchdev.
>>>
>>> Today userspace observes the ECPF instance and then switches the
>>> mode through devlink, usually via udev or similar plumbing. That still
>>> leaves a window where the ECPF has probed, userspace has not applied the
>>> mode yet, and the host PF is waiting. With many ECPFs this becomes visible
>>> in host PF probe/boot time. A daemon reacting to the devlink object
>>> appearing can make the userspace side cleaner, but it still runs after the
>>> device has appeared and after userspace scheduling/uevent handling.
>>>
>>> Long term, for these DPU deployments, we would like mlx5 to initialize
>>> directly in switchdev. I am hesitant to make that unconditional because it
>>> changes existing behavior and there is no early opt-out before probe. The
>>> cmdline parameter was meant as an explicit opt-in middle step: ask the
>>> driver to apply the same devlink operation during init, before this path
>>> depends on userspace.
>>>
>>> We previously tried to address this with an mlx5 module parameter. By
>>> design, that was too coarse: it applied to all mlx5 devices handled by the
>>> module. That makes it usable only for narrow DPU-only configurations. The
>>> devlink-handle based cmdline syntax was intended to keep the opt-in scoped
>>> to the specific devices that need this early switchdev transition.
>>
>> The switchdev mode was introduced at roughly the time CX4 was out. What
>> stopped us from making it default for CX4+ ?
>>
>> Introducing this horrible plumbing only bacause we were not able to
>> change the default sounds so absurd.
>>
>> Can we write the default mode as a bit in ASIC NV memory perhaps? Simple
>> devlink cmode permanent param to write it, the driver can read this bit
>> during init to decide the init flow path?
>
>I don't think switchdev by default should mean CX4+ in general. If we get
>there, I would expect it to be limited to the DPU/BlueField/ECPF case, where
>the host PF probe path can depend on the ECPF reaching switchdev. Changing the
>default for regular host NIC deployments feels like a much larger compatibility
>change.
We can't travel throught time, but if from CX5 onwards the default would
be switchdev, nobody would feel broken in terms of compatibility. That
is my point. Having "legacy" as default is simply wrong for never NIC
generations. That is why it is called "legacy" and it should have been
rotten through and out since CX4 times.
>
>For the ASIC/NV bit: maybe technically possible, but it feels like the wrong
>layer. This is boot/deployment policy, not a persistent hardware property, and
>storing it in NV memory would make the state persist across kernels/hosts in a
>surprising way.
Well, as any other nv config, it persists across kernels/hosts. Think
about it as "unbreak-my-not-legacy-device" bit.
>
>I do agree the RFC probably went too far by making a generic devlink cmdline
>configuration language. Maybe the smaller thing to discuss is only:
>
>devlink=[pci/...]:esw:mode:{legacy|switchdev|switchdev_inactive}
>
>No runtime params, no ordering between different operations, just early eswitch
>mode for explicitly selected handles.
FWIW, I'm still against this.
>
>@Jakub, I know you wanted something more generic/extensible, but maybe the
>generic case belongs in the devlinkd/systemd direction Jiri pointed at, while
>the kernel cmdline handles only this early boot eswitch mode case.
>
>Mark
^ permalink raw reply
* Re: [PATCH v4 1/2] usb: xhci-pci: add AMD Promontory 21 PCI glue
From: Jihong Min @ 2026-05-08 18:11 UTC (permalink / raw)
To: Mario Limonciello, Jihong Min, Greg Kroah-Hartman, Mathias Nyman
Cc: Guenter Roeck, Jonathan Corbet, Shuah Khan, Basavaraj Natikar,
linux-usb, linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <b8372128-c922-4b62-91c5-46f848180bc5@icloud.com>
>> Something else I was thinking about while reviewing this series.
>>
>> Promontory 21 is only on AMD platforms and AMD platforms are only
>> x86. I think the Kconfig should be conditional on AMD CPU support
>> being enabled and X86 architecture so that we don't bloat other
>> architectures with dead code that will never run.
One related Kconfig question: would it be acceptable to make
USB_XHCI_PCI_PROM21 default y with the X86 && CPU_SUP_AMD dependency?
This would only default-enable the PROM21 xHCI PCI glue. The hwmon driver
would still be controlled separately by SENSORS_PROM21_XHCI and would remain
opt-in, so the undocumented temperature register polling would not be
enabled
by default.
The concern is that, without default y, distribution configs may miss the
PROM21 PCI glue and then SENSORS_PROM21_XHCI can not bind even if the hwmon
driver itself is enabled or available as a module.
Would you prefer this, or should USB_XHCI_PCI_PROM21 remain explicitly
enabled
by distributions?
Sincerely,
Jihong Min
^ permalink raw reply
* Re: [PATCH v4 1/2] usb: xhci-pci: add AMD Promontory 21 PCI glue
From: Guenter Roeck @ 2026-05-08 18:15 UTC (permalink / raw)
To: Jihong Min, Mario Limonciello, Jihong Min, Greg Kroah-Hartman,
Mathias Nyman
Cc: Jonathan Corbet, Shuah Khan, Basavaraj Natikar, linux-usb,
linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <2657e1b7-126d-4c4b-8027-012a6d3ffee3@icloud.com>
On 5/8/26 11:11, Jihong Min wrote:
>>> Something else I was thinking about while reviewing this series.
>>>
>>> Promontory 21 is only on AMD platforms and AMD platforms are only x86. I think the Kconfig should be conditional on AMD CPU support being enabled and X86 architecture so that we don't bloat other architectures with dead code that will never run.
> One related Kconfig question: would it be acceptable to make
> USB_XHCI_PCI_PROM21 default y with the X86 && CPU_SUP_AMD dependency?
>
> This would only default-enable the PROM21 xHCI PCI glue. The hwmon driver
> would still be controlled separately by SENSORS_PROM21_XHCI and would remain
> opt-in, so the undocumented temperature register polling would not be enabled
> by default.
>
> The concern is that, without default y, distribution configs may miss the
> PROM21 PCI glue and then SENSORS_PROM21_XHCI can not bind even if the hwmon
> driver itself is enabled or available as a module.
>
> Would you prefer this, or should USB_XHCI_PCI_PROM21 remain explicitly enabled
> by distributions?
>
How about "default USB_XHCI_PCI" ?
Guenter
^ permalink raw reply
* Re: [PATCH 1/3] Documentation/gpu: add dedicated documentation for Intel display
From: Randy Dunlap @ 2026-05-08 18:22 UTC (permalink / raw)
To: Jani Nikula, intel-gfx, intel-xe, dri-devel, linux-doc
Cc: rodrigo.vivi, Matthew Brost, Thomas Hellström,
joonas.lahtinen, tursulin
In-Reply-To: <21bfa7777eb0926eadd309d4c6f5c9cf48405cf0.1778235406.git.jani.nikula@intel.com>
On 5/8/26 3:20 AM, Jani Nikula wrote:
> diff --git a/Documentation/gpu/intel-display/index.rst b/Documentation/gpu/intel-display/index.rst
> new file mode 100644
> index 000000000000..8d40363b8f90
> --- /dev/null
> +++ b/Documentation/gpu/intel-display/index.rst
> @@ -0,0 +1,40 @@
> +.. SPDX-License-Identifier: MIT
> +.. Copyright © 2026 Intel Corporation
> +
> +.. _drm/intel-display:
> +
> +====================
> +Intel Display Driver
> +====================
> +
> +The Intel display driver provides the display, or :ref:`drm-kms`, support for
> +both the :ref:`drm/xe <drm/xe>` and :ref:`drm/i915 <drm/i915>` Intel GPU
> +drivers.
> +
> +The source code currently resides under ``drivers/gpu/drm/i915/display`` due to
> +historical reasons, and it's compiled separately into both drm/xe and drm/i915
> +kernel modules.
> +
> +The drm/xe and drm/i915 drivers are the "core" or "parent" drivers for display,
> +as they initialize and own the drm device, and pass that on to the display
> +driver. The display driver isn't an independent driver in that sense.
> +
> +.. toctree::
> + :maxdepth: 1
> + :caption: Detailed display topics
> +
> + async-flip
> + audio
> + cdclk
> + dmc
> + dpio
> + dpll
> + drrs
> + dsb
> + fbc
> + fifo-underrun
> + frontbuffer
> + hotplug
> + plane
> + psr
> + vbt
Is this in almost-alphabetical order or just random? :)
Tested-by: Randy Dunlap <rdunlap@infradead.org>
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/3] Documentation/gpu: use === for Intel display section heading underlines
From: Randy Dunlap @ 2026-05-08 18:22 UTC (permalink / raw)
To: Jani Nikula, intel-gfx, intel-xe, dri-devel, linux-doc
Cc: rodrigo.vivi, Matthew Brost, Thomas Hellström,
joonas.lahtinen, tursulin
In-Reply-To: <f49968792220ca3ff24efde813550850340d092e.1778235406.git.jani.nikula@intel.com>
On 5/8/26 3:20 AM, Jani Nikula wrote:
> Prefer to use === instead of --- for top level section heading
> underlines to allow using the latter for sub-headings later.
>
> While at it, fix the underline lenghts where needed.
lengths
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/5] docs: fix repeated word 'that' across documentation
From: David Laight @ 2026-05-08 18:26 UTC (permalink / raw)
To: Shuah Khan
Cc: Adrien Reynard, Paul E. McKenney, Frederic Weisbecker,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Jonathan Corbet, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, David Howells,
Paulo Alcantara, Masami Hiramatsu,
open list:READ-COPY UPDATE (RCU), open list:DOCUMENTATION,
open list, open list:DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS,
open list:FILESYSTEMS [NETFS LIBRARY],
open list:FILESYSTEMS [NETFS LIBRARY], open list:TRACING
In-Reply-To: <1501caea-8cff-4968-aca6-e8d4b20e0e80@linuxfoundation.org>
On Fri, 8 May 2026 11:15:28 -0600
Shuah Khan <skhan@linuxfoundation.org> wrote:
> On 5/8/26 10:37, Adrien Reynard wrote:
>
> Missing commit log in all your patches - I don't patch 1/5 in
> my Inbox.
>
> > Signed-off-by: Adrien Reynard <reynard.adrien.08@gmail.com>
> > ---
> > Documentation/RCU/rcu.rst | 2 +-
> > Documentation/driver-api/driver-model/overview.rst | 2 +-
> > Documentation/filesystems/netfs_library.rst | 2 +-
> > Documentation/trace/histogram-design.rst | 2 +-
> > Documentation/trace/histogram.rst | 2 +-
> > 5 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/RCU/rcu.rst b/Documentation/RCU/rcu.rst
> > index bf6617b330a7..320ad3292b75 100644
> > --- a/Documentation/RCU/rcu.rst
> > +++ b/Documentation/RCU/rcu.rst
> > @@ -32,7 +32,7 @@ Frequently Asked Questions
> > Just as with spinlocks, RCU readers are not permitted to
> > block, switch to user-mode execution, or enter the idle loop.
> > Therefore, as soon as a CPU is seen passing through any of these
> > - three states, we know that that CPU has exited any previous RCU
> > + three states, we know that CPU has exited any previous RCU
>
> The original intent might have been to say, "that cpu", so adding
> the missing comma after the first "that" or change "that" to "the"
> would make sense.
...
I don't think adding a comma would be correct.
The clause splits as 'we know that' 'that CPU' and the repeated 'that'
is absolutely correct.
Maybe 'that CPU' could be replaced by 'it'; but it can be difficult to
work out what back references like 'it' refer to.
You can re-order it, as (say):
Therefore we know that as soon as a CPU is seen passing through any of these
three states it has exited any previous RCU read-side critical sections.
But just because some grammar book says you shouldn't have repeated words
doesn't mean there aren't exceptions.
The sign writer was doing a new sign for the 'Pig and Whistle'.
Unfortunately the gaps between Pig and and and and and Whistle
ended up visibly different.
-- David
^ permalink raw reply
* Re: [PATCH 4/5] docs: fix repeated prepositions across documentation
From: David Laight @ 2026-05-08 18:28 UTC (permalink / raw)
To: Adrien Reynard
Cc: Andrey Ryabinin, Alexander Potapenko, Andrey Konovalov,
Dmitry Vyukov, Vincenzo Frascino, Jonathan Corbet, Shuah Khan,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Richard Weinberger, Anton Ivanov, Johannes Berg,
open list:KASAN, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list,
open list:NETWORKING [GENERAL], open list:USER-MODE LINUX (UML)
In-Reply-To: <20260508163804.16267-1-reynard.adrien.08@gmail.com>
On Fri, 8 May 2026 18:38:03 +0200
Adrien Reynard <reynard.adrien.08@gmail.com> wrote:
Nope, all these are correct as is.
I'm not looking at any more.
> Signed-off-by: Adrien Reynard <reynard.adrien.08@gmail.com>
> ---
> Documentation/dev-tools/kasan.rst | 2 +-
> Documentation/networking/switchdev.rst | 2 +-
> Documentation/virt/uml/user_mode_linux_howto_v2.rst | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
> index 4968b2aa60c8..3a8bd40ad905 100644
> --- a/Documentation/dev-tools/kasan.rst
> +++ b/Documentation/dev-tools/kasan.rst
> @@ -392,7 +392,7 @@ reserved to tag freed memory regions.
> If the hardware does not support MTE (pre ARMv8.5), Hardware Tag-Based KASAN
> will not be enabled. In this case, all KASAN boot parameters are ignored.
>
> -Note that enabling CONFIG_KASAN_HW_TAGS always results in in-kernel TBI being
> +Note that enabling CONFIG_KASAN_HW_TAGS always results in-kernel TBI being
> enabled. Even when ``kasan.mode=off`` is provided or when the hardware does not
> support MTE (but supports TBI).
>
> diff --git a/Documentation/networking/switchdev.rst b/Documentation/networking/switchdev.rst
> index 2966b7122f05..948bce44ca9b 100644
> --- a/Documentation/networking/switchdev.rst
> +++ b/Documentation/networking/switchdev.rst
> @@ -162,7 +162,7 @@ The switchdev driver can know a particular port's position in the topology by
> monitoring NETDEV_CHANGEUPPER notifications. For example, a port moved into a
> bond will see its upper master change. If that bond is moved into a bridge,
> the bond's upper master will change. And so on. The driver will track such
> -movements to know what position a port is in in the overall topology by
> +movements to know what position a port is in the overall topology by
> registering for netdevice events and acting on NETDEV_CHANGEUPPER.
>
> L2 Forwarding Offload
> diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
> index c37e8e594d12..7b08738c30aa 100644
> --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst
> +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst
> @@ -1092,7 +1092,7 @@ be formatted as plain text.
>
> Developing always goes hand in hand with debugging. First of all,
> you can always run UML under gdb and there will be a whole section
> -later on on how to do that. That, however, is not the only way to
> +later on how to do that. That, however, is not the only way to
> debug a Linux kernel. Quite often adding tracing statements and/or
> using UML specific approaches such as ptracing the UML kernel process
> are significantly more informative.
^ permalink raw reply
* Re: [PATCH 3/3] Documentation/gpu/rfc: fix toctree
From: Randy Dunlap @ 2026-05-08 18:36 UTC (permalink / raw)
To: Jani Nikula, dri-devel, linux-doc
In-Reply-To: <c9678a78749a71cf86941f37116232dbc7c23b5f.1778238671.git.jani.nikula@intel.com>
On 5/8/26 4:12 AM, Jani Nikula wrote:
> Just one toctree is enough. The .rst suffixes are superfluous in the
> toctree. Fix indent. Add missing newline at the end of the file.
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Documentation/gpu/rfc/index.rst | 26 ++++++--------------------
> 1 file changed, 6 insertions(+), 20 deletions(-)
>
> diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst
> index ef19b0ba2a3e..26a7ebe6fb44 100644
> --- a/Documentation/gpu/rfc/index.rst
> +++ b/Documentation/gpu/rfc/index.rst
> @@ -18,23 +18,9 @@ host such documentation:
>
> .. toctree::
>
> - gpusvm.rst
> -
> -.. toctree::
> -
> - i915_gem_lmem.rst
> -
> -.. toctree::
> -
> - i915_scheduler.rst
> -
> -.. toctree::
> -
> - i915_small_bar.rst
> -
> -.. toctree::
> -
> - i915_vm_bind.rst
> -
> -.. toctree::
> - color_pipeline.rst
> \ No newline at end of file
> + gpusvm
> + i915_gem_lmem
> + i915_scheduler
> + i915_small_bar
> + i915_vm_bind
> + color_pipeline
--
~Randy
^ permalink raw reply
* Re: [PATCH 2/3] Documentation/gpu: add some tables of contents to large documents
From: Randy Dunlap @ 2026-05-08 18:37 UTC (permalink / raw)
To: Jani Nikula, dri-devel, linux-doc
In-Reply-To: <e3f9357c0e8198cc48e69e2a3b8ca072c7ab92ca.1778238671.git.jani.nikula@intel.com>
On 5/8/26 4:12 AM, Jani Nikula wrote:
> Some of the GPU documentation pages are quite long, with various levels
> of details. Add document internal tables of contents to the larger
> documents to make them easier to navigate.
>
> The index.rst in the sub-directories have toctrees, which provide
> similar overviews.
>
> Fix one missing newline at the end of drm-uapi.rst while at it,
> primarily because rst should have it, and secondarily because my editor
> rst mode refuses to save the file without it.
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Documentation/gpu/driver-uapi.rst | 2 ++
> Documentation/gpu/drm-internals.rst | 2 ++
> Documentation/gpu/drm-kms-helpers.rst | 2 ++
> Documentation/gpu/drm-kms.rst | 2 ++
> Documentation/gpu/drm-mm.rst | 2 ++
> Documentation/gpu/drm-ras.rst | 2 ++
> Documentation/gpu/drm-uapi.rst | 4 +++-
> Documentation/gpu/drm-usage-stats.rst | 2 ++
> Documentation/gpu/introduction.rst | 2 ++
> 9 files changed, 19 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst
> index 1f15a8ca1265..627fc68c7a21 100644
> --- a/Documentation/gpu/driver-uapi.rst
> +++ b/Documentation/gpu/driver-uapi.rst
> @@ -2,6 +2,8 @@
> DRM Driver uAPI
> ===============
>
> +.. contents::
> +
> drm/i915 uAPI
> =============
>
> diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst
> index 94f93fd3b8a0..a3ce25a36f1d 100644
> --- a/Documentation/gpu/drm-internals.rst
> +++ b/Documentation/gpu/drm-internals.rst
> @@ -18,6 +18,8 @@ event handling, memory management, output management, framebuffer
> management, command submission & fencing, suspend/resume support, and
> DMA services.
>
> +.. contents::
> +
> Driver Initialization
> =====================
>
> diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst
> index b4a9e5ae81f6..80453dda33b8 100644
> --- a/Documentation/gpu/drm-kms-helpers.rst
> +++ b/Documentation/gpu/drm-kms-helpers.rst
> @@ -33,6 +33,8 @@ There are a few areas these helpers can grouped into:
> pipeline: Planes, handling rectangles for visibility checking and scissoring,
> flip queues and assorted bits.
>
> +.. contents::
> +
> Modeset Helper Reference for Common Vtables
> ===========================================
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index fbe0583eb84c..d22817fdf9aa 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -15,6 +15,8 @@ be setup by initializing the following fields.
> - struct drm_mode_config_funcs \*funcs;
> Mode setting functions.
>
> +.. contents::
> +
> Overview
> ========
>
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index 32fb506db05b..2dea94f77d52 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -25,6 +25,8 @@ share it. GEM has simpler initialization and execution requirements than
> TTM, but has no video RAM management capabilities and is thus limited to
> UMA devices.
>
> +.. contents::
> +
> The Translation Table Manager (TTM)
> ===================================
>
> diff --git a/Documentation/gpu/drm-ras.rst b/Documentation/gpu/drm-ras.rst
> index 4636e68f5678..83c21853b74b 100644
> --- a/Documentation/gpu/drm-ras.rst
> +++ b/Documentation/gpu/drm-ras.rst
> @@ -24,6 +24,8 @@ Key Goals:
> nodes for different IP blocks, sub-blocks, or other logical subdivisions
> as applicable.
>
> +.. contents::
> +
> Nodes
> =====
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 32206ce62931..2c2f939322fb 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -16,6 +16,8 @@ management, and output management.
> Cover generic ioctls and sysfs layout here. We only need high-level
> info, since man pages should cover the rest.
>
> +.. contents::
> +
> libdrm Device Lookup
> ====================
>
> @@ -765,4 +767,4 @@ Stable uAPI events
> From ``drivers/gpu/drm/scheduler/gpu_scheduler_trace.h``
>
> .. kernel-doc:: drivers/gpu/drm/scheduler/gpu_scheduler_trace.h
> - :doc: uAPI trace events
> \ No newline at end of file
> + :doc: uAPI trace events
> diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst
> index 24d3012ca7a6..70b7cfcc194f 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -16,6 +16,8 @@ output is split between common and driver specific parts. Having said that,
> wherever possible effort should still be made to standardise as much as
> possible.
>
> +.. contents::
> +
> File format specification
> =========================
>
> diff --git a/Documentation/gpu/introduction.rst b/Documentation/gpu/introduction.rst
> index d8f519693fc2..64074ac22d9b 100644
> --- a/Documentation/gpu/introduction.rst
> +++ b/Documentation/gpu/introduction.rst
> @@ -16,6 +16,8 @@ found in current kernels.
>
> [Insert diagram of typical DRM stack here]
>
> +.. contents::
> +
> Style Guidelines
> ================
>
--
~Randy
^ permalink raw reply
* Re: [PATCH 1/3] Documentation/gpu: limit main toctree depth to 2
From: Randy Dunlap @ 2026-05-08 18:37 UTC (permalink / raw)
To: Jani Nikula, dri-devel, linux-doc
In-Reply-To: <cddd2d11c104132801510e3ab4e4b9ef3ea9cb6d.1778238671.git.jani.nikula@intel.com>
On 5/8/26 4:12 AM, Jani Nikula wrote:
> The main GPU documentation toctree has no limit to the toctree depth,
> which means the main GPU index page recursively includes all the
> headings in all of GPU documentation in the single table of
> contents. This makes getting any kind of overview of the documentation
> really difficult.
>
> Limit the main toctree depth to 2 i.e. show at most two levels of
> headings.
>
> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Tested-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> Documentation/gpu/index.rst | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> index 5d708a106b3f..65bf3b26e4f4 100644
> --- a/Documentation/gpu/index.rst
> +++ b/Documentation/gpu/index.rst
> @@ -3,6 +3,7 @@ GPU Driver Developer's Guide
> ============================
>
> .. toctree::
> + :maxdepth: 2
>
> introduction
> drm-internals
--
~Randy
^ permalink raw reply
* Re: [PATCH v4 1/2] usb: xhci-pci: add AMD Promontory 21 PCI glue
From: Jihong Min @ 2026-05-08 18:39 UTC (permalink / raw)
To: Guenter Roeck, Mario Limonciello, Jihong Min, Greg Kroah-Hartman,
Mathias Nyman
Cc: Jonathan Corbet, Shuah Khan, Basavaraj Natikar, linux-usb,
linux-hwmon, linux-doc, linux-pci, linux-kernel
In-Reply-To: <053b019e-9c6a-4eb3-aa69-0c07cd6e7f12@roeck-us.net>
> How about "default USB_XHCI_PCI" ?
>
> Guenter
That makes sense. I changed USB_XHCI_PCI_PROM21 to use
default USB_XHCI_PCI
locally.
Sincerely,
Jihong Min
^ permalink raw reply
* Re: [PATCH v7 10/10] ipe: Add BPF program load policy enforcement via Hornet integration
From: Fan Wu @ 2026-05-08 18:40 UTC (permalink / raw)
To: Blaise Boscaccy
Cc: Jonathan Corbet, Paul Moore, James Morris, Serge E. Hallyn,
Mickaël Salaün, Günther Noack,
Dr. David Alan Gilbert, Andrew Morton, James.Bottomley, dhowells,
Fan Wu, Ryan Foster, Randy Dunlap, linux-security-module,
linux-doc, linux-kernel, bpf, Song Liu
In-Reply-To: <20260507191416.2984054-11-bboscaccy@linux.microsoft.com>
On Thu, May 7, 2026 at 12:15 PM Blaise Boscaccy
<bboscaccy@linux.microsoft.com> wrote:
>
> Add support for the bpf_prog_load_post_integrity LSM hook, enabling IPE
> to make policy decisions about BPF program loading based on integrity
> verdicts provided by the Hornet LSM.
>
> New policy operation:
> op=BPF_PROG_LOAD - Matches BPF program load events
>
> New policy properties:
> bpf_signature=NONE - No Verdict
> bpf_signature=OK - Program signature and map hashes verified
> bpf_signature=UNSIGNED - No signature provided
> bpf_signature=PARTIALSIG - Signature OK but no map hash data
> bpf_signature=UNKNOWNKEY - The keyring requested by the user is invalid
> bpf_signature=UNEXPECTED - An unexpected hash value was encountered
> bpf_signature=FAULT - System error during verification
> bpf_signature=BADSIG - Signature or map hash verification failed
> bpf_keyring=BUILTIN - Program was signed using a builtin keyring
> bpf_keyring=SECONDARY - Program was signed using the secondary keyring
> bpf_keyring=PLATFORM - Program was signed using the platform keyring
> bpf_kernel=TRUE - Program originated from kernelspace
> bpf_kernel=FALSE - Program originated from userspace
>
> These properties map directly to the lsm_integrity_verdict enum values
> provided by the Hornet LSM through security_bpf_prog_load_post_integrity.
>
> The feature is gated on CONFIG_IPE_PROP_BPF_SIGNATURE which depends on
> CONFIG_SECURITY_HORNET.
>
> Signed-off-by: Blaise Boscaccy <bboscaccy@linux.microsoft.com>
Acked-by: Fan Wu <wufan@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 00/10] platform/x86: msi-wmi-platform: Add fan curves/platform profile/tdp/battery limiting
From: Derek J. Clark @ 2026-05-08 18:41 UTC (permalink / raw)
To: lkml
Cc: W_Armin, corbet, hdegoede, ilpo.jarvinen, jdelvare, kuurtb,
linux-doc, linux-hwmon, linux-kernel, linux, platform-driver-x86
In-Reply-To: <20250511204427.327558-1-lkml@antheas.dev>
>This draft patch series brings into parity the msi-wmi-platform driver with
>the MSI Center M Windows application for the MSI Claw (all models).
>Unfortunately, MSI Center M and this interface do not have a discovery API,
>necessitating the introduction of a quirk system.
>
>While this patch series is fully functional and tested, there are still
>some issues that need to be addressed:
> - Armin notes we need to disable fan curve support by default and quirk
> it as well, as it is not supported on all models. However, the way
> PWM enable ops work, this makes it a bit difficult, so I would like
> some suggestions on how to rework this.
> - It turns out that to fully disable the fan curve, we have to restore
> the default fan values. This is also what is done on the OEM software.
> For this, the last patch in the series is used, which is a bit dirty.
>
>Sleep was tested with all values being preserved during S0iX (platform
>profile, fan curve, PL1/PL2), so we do not need suspend/resume hooks, at
>least for the Claw devices.
>
>For PL1/PL2, we use firmware-attributes. So for that I +cc Kurt since if
>his new high level interface is merged beforehand, we can use that instead.
>
Hi Antheas,
It seems this series is stalled for 3 days shy of a year now. I have an
interest in getting this across the finish line. Will you be continuing
development? If not, I will take what you've started here and finish out
the remaining nits, keeping your original attribution of course.
Cheers,
Derek
>Antheas Kapenekakis (8):
> platform/x86: msi-wmi-platform: Add unlocked msi_wmi_platform_query
> platform/x86: msi-wmi-platform: Add quirk system
> platform/x86: msi-wmi-platform: Add platform profile through shift
> mode
> platform/x86: msi-wmi-platform: Add PL1/PL2 support via firmware
> attributes
> platform/x86: msi-wmi-platform: Add charge_threshold support
> platform/x86: msi-wmi-platform: Drop excess fans in dual fan devices
> platform/x86: msi-wmi-platform: Update header text
> platform/x86: msi-wmi-platform: Restore fan curves on PWM disable and
> unload
>
>Armin Wolf (2):
> platform/x86: msi-wmi-platform: Use input buffer for returning result
> platform/x86: msi-wmi-platform: Add support for fan control
>
> .../wmi/devices/msi-wmi-platform.rst | 26 +
> drivers/platform/x86/Kconfig | 3 +
> drivers/platform/x86/msi-wmi-platform.c | 1181 ++++++++++++++++-
> 3 files changed, 1156 insertions(+), 54 deletions(-)
>
>
>base-commit: 62b1dcf2e7af3dc2879d1a39bf6823c99486a8c2
^ permalink raw reply
* Re: [PATCH 2/5] docs: fix repeated word 'that' across documentation
From: David Howells @ 2026-05-08 19:43 UTC (permalink / raw)
To: Adrien Reynard
Cc: Paul E. McKenney, Frederic Weisbecker, Neeraj Upadhyay,
Joel Fernandes, Josh Triplett, Boqun Feng, Uladzislau Rezki,
Steven Rostedt, Mathieu Desnoyers, Lai Jiangshan, Zqiang,
Jonathan Corbet, Shuah Khan, Greg Kroah-Hartman,
Rafael J. Wysocki, Danilo Krummrich, David Howells,
Paulo Alcantara, Masami Hiramatsu,
open list:READ-COPY UPDATE (RCU), open list:DOCUMENTATION,
open list, open list:DRIVER CORE, KOBJECTS, DEBUGFS AND SYSFS,
open list:FILESYSTEMS [NETFS LIBRARY],
open list:FILESYSTEMS [NETFS LIBRARY], open list:TRACING
In-Reply-To: <20260508163759.16231-1-reynard.adrien.08@gmail.com>
Adrien Reynard <reynard.adrien.08@gmail.com> wrote:
> - three states, we know that that CPU has exited any previous RCU
This is arguably correct. The two 'that' words are functionally different.
If you look at another language, say Hungarian, they are different words
(e.g. 'hogy' vs 'az').
David
^ permalink raw reply
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