* Re: [PATCH v2 3/9] kernel/api: add debugfs interface for kernel API specifications
From: Greg Kroah-Hartman @ 2026-03-24 11:45 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E . McKenney, Jonathan Corbet, Dmitry Vyukov, Randy Dunlap,
Cyril Hrubis, Kees Cook, Jake Edge, David Laight, Askar Safin,
Gabriele Paoloni, Mauro Carvalho Chehab, Christian Brauner,
Alexander Viro, Andrew Morton, Masahiro Yamada, Shuah Khan,
Ingo Molnar, Arnd Bergmann
In-Reply-To: <acJ2gnnA9MP1wO_Z@laps>
On Tue, Mar 24, 2026 at 07:33:22AM -0400, Sasha Levin wrote:
> On Tue, Mar 24, 2026 at 09:20:01AM +0100, Greg Kroah-Hartman wrote:
> > On Mon, Mar 23, 2026 at 07:58:50PM -0400, Sasha Levin wrote:
> > > > But this only works if the kabi stuff is built into the kernel image,
> > > > right? This doesn't work if any of these abi sections are in a module
> > > > or am I missing that logic here?
> > >
> > > That is correct, for now.
> > >
> > > I'm only trying to tackle syscalls to begin with, and since no syscalls live in
> > > modules, we have no need for module support.
> >
> > We used to support syscalls in modules, but thankfully that is now gone.
> > But, how will this work for stuff like usbfs ioctls? That is a module,
> > and our uapi is, by far, in drivers through ioctl "hell" and that would
> > be great to be able to document through all of this. Will that just not
> > be in the debugfs api?
>
> It will. I see it working just like how BTF or trace events do it now.
>
> When a module loads, find_module_sections() extracts the .kapi_specs section
> pointer and element count into new struct module fields. The COMING notifier
> then iterates those specs, registers each via the existing kapi_register_spec()
> dynamic registration path, and creates per-spec debugfs files under the
> existing /sys/kernel/debug/kapi/specs/ directory. The kapi_list_show() function
> is extended to also walk the dynamic_api_specs list (currently it only iterates
> the static __start_kapi_specs..__stop_kapi_specs range). On GOING, all specs
> owned by that module are removed from the list and their debugfs entries
> cleaned up via debugfs_remove().
Sounds good, I was worried about that static range and how that would be
"extended" or not.
greg k-h
^ permalink raw reply
* Re: [PATCH v8 2/6] iio: Replace 'sign' field with union in struct iio_scan_type
From: Francesco Lavra @ 2026-03-24 11:42 UTC (permalink / raw)
To: Andy Shevchenko
Cc: David Lechner, Jonathan Corbet, Shuah Khan, Jonathan Cameron,
Nuno Sá, Andy Shevchenko, linux-doc, linux-kernel, linux-iio
In-Reply-To: <acJv1RNLugS0aat9@ashevche-desk.local>
On Tue, 2026-03-24 at 13:04 +0200, Andy Shevchenko wrote:
> On Mon, Mar 23, 2026 at 06:37:38PM +0100, Francesco Lavra wrote:
> > On Mon, 2026-03-23 at 18:49 +0200, Andy Shevchenko wrote:
> > > On Mon, Mar 23, 2026 at 05:04:10PM +0100, Francesco Lavra wrote:
> > > > On Sat, 2026-03-21 at 12:22 -0500, David Lechner wrote:
> > > > > On 3/17/26 10:04 AM, Francesco Lavra wrote:
>
> ...
>
> > > > > > + * @IIO_SCAN_FORMAT_SIGNED_INT: Signed integer (two's
> > > > > > complement).
> > > > > > + * @IIO_SCAN_FORMAT_UNSIGNED_INT: Unsigned integer.
> > >
> > > > > We could make this proper kernel doc format with one comment per
> > > > > macro.
> > > >
> > > > Actually, a set of related #defines can be documented with a single
> > > > comment. I see a few examples doing that in
> > > > include/linux/gfp_types.h
> > > > and
> > > > include/linux/fpga/fpga-mgr.h
> > > >
> > > > > > +#define IIO_SCAN_FORMAT_SIGNED_INT 's'
> > > > > > +#define IIO_SCAN_FORMAT_UNSIGNED_INT 'u'
> > >
> > > ...or use enum
> > >
> > > /**
> > > * ...kernel-doc for enum...
> > > */
> > > enum {
> > > IIO_SCAN_FORMAT_SIGNED_INT = 's',
> > > IIO_SCAN_FORMAT_UNSIGNED_INT = 'u',
> > > };
> >
> > There is no standard kernel-doc format for anonymous enums.
>
> What do you mean? We have such in kernel, for example,
> drivers/pinctrl/intel/pinctrl-intel.c.
The kernel-doc guidelines at Documentation/doc-guide/kernel-doc.rst, in the
section that describe structure, union, and enumeration documentation,
include the name of the struct in the example, so I thought they wouldn't
apply to anonymous types. But now I see that anonymous enum comments are
processed just fine by the kernel-doc tool.
Anyway, in v9 I switched to one comment per macro, as suggested by David.
^ permalink raw reply
* Re: [PATCH 0/2] kallsyms: show typed function parameters in oops/WARN dumps
From: Sasha Levin @ 2026-03-24 11:39 UTC (permalink / raw)
To: Jiri Olsa
Cc: Andrew Morton, Masahiro Yamada, Nathan Chancellor, Nicolas Schier,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Petr Mladek,
Alexei Starovoitov, Jonathan Corbet, David Gow, Kees Cook,
Greg KH, Luis Chamberlain, Steven Rostedt, Helge Deller,
Randy Dunlap, Geert Uytterhoeven, Juergen Gross, James Bottomley,
Alexey Dobriyan, Vlastimil Babka, Laurent Pinchart, Petr Pavlu,
x86, linux-kernel, linux-kbuild, linux-doc, linux-modules, bpf
In-Reply-To: <acJR51EAjn-7EOPm@krava>
On Tue, Mar 24, 2026 at 09:57:11AM +0100, Jiri Olsa wrote:
>On Mon, Mar 23, 2026 at 12:48:55PM -0400, Sasha Levin wrote:
>> Building on the lineinfo series, this adds typed function parameter
>
>hi,
>could you please specify the exact tree/commit and point to the
>series this patchset is based on?
Yup, sorry, I should have noted that. This series is based on Andrew Morton's
mm-nonmm-unstable branch (git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
mm-nonmm-unstable) since he took the base lineinfo patches and these build on
code adjacent to it.
There's no direct dependency between the two, but they touch the same parts of
the code.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 2/3] docs: hwmon: Update TMP108 documentation for NXP P3T1084UK support
From: Guenter Roeck @ 2026-03-24 11:39 UTC (permalink / raw)
To: Anshika Gupta, corbet, skhan, linux-hwmon, linux-doc,
linux-kernel, robh, krzk+dt, conor+dt, devicetree
Cc: lakshaypiplani77
In-Reply-To: <20260323162252.15508-2-guptaanshika.ag@gmail.com>
On 3/23/26 09:22, Anshika Gupta wrote:
> Add references to the NXP P3T1084UK temperature sensor in the TMP108
> hardware monitoring documentation. The P3T1084UK is compatible with
> the TMP108 register interface and protocol, and the hwmon driver now
> supports it. Update the .rst document accordingly to reflect the new
> compatible device and its expected behavior.
>
> Signed-off-by: Lakshay Piplani <lakshaypiplani77@gmail.com>
> Signed-off-by: Anshika Gupta <guptaanshika.ag@gmail.com>
> ---
> Documentation/hwmon/tmp108.rst | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/hwmon/tmp108.rst b/Documentation/hwmon/tmp108.rst
> index c218ea333dd6..cda280032710 100644
> --- a/Documentation/hwmon/tmp108.rst
> +++ b/Documentation/hwmon/tmp108.rst
> @@ -11,6 +11,13 @@ Supported chips:
>
> Datasheet: https://www.nxp.com/docs/en/data-sheet/P3T1035XUK_P3T2030XUK.pdf
>
> + * NXP P3T1084
Sashiko:
This isn't a bug, but the new bullet point uses a single leading space,
whereas the surrounding list items use two leading spaces. This inconsistent
indentation might cause parsing issues when generating the reStructuredText
documentation.
> +
> + Prefix: 'p3t1045'
> +
P3T1084 or p3t1045 ?
> + Addresses scanned: none
> +
> + Datasheet: https://www.nxp.com/docs/en/data-sheet/P3T1084UK.pdf
>
> * NXP P3T1085
>
Guenter
^ permalink raw reply
* Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc
From: Guenter Roeck @ 2026-03-24 11:33 UTC (permalink / raw)
To: Gupta, Akshay, linux-kernel@vger.kernel.org
Cc: corbet@lwn.net, skhan@linuxfoundation.org, arnd@arndb.de,
gregkh@linuxfoundation.org, L k, Prathima,
Chatradhi, Naveen Krishna, Umarji, Anand,
linux-doc@vger.kernel.org, linux-hwmon@vger.kernel.org,
kunyi@google.com
In-Reply-To: <d0ed96aa-529d-42fb-a680-917c325998ee@amd.com>
On 3/24/26 03:36, Gupta, Akshay wrote:
>
> On 3/23/2026 7:45 PM, Guenter Roeck wrote:
>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>
>>
>> On 3/23/26 04:08, Akshay Gupta wrote:
>>> From: Prathima <Prathima.Lk@amd.com>
>>>
>>> Move SBTSI core functionality out of the hwmon-only path and into
>>> drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
>>>
>>> This split prepares the driver for additional interfaces while keeping
>>> hwmon support as an optional layer on top of common SBTSI core logic.
>>>
>> This moves the driver out of hwmon space into misc/amd-sbi which,
>> in my opinion, is completely unnecessary to accomplish the stated goals.
>>
>> I assume this is to be able to make changes which do not follow
>> the hwmon ABI and/or to bypass hwmon subsystem review, similar
>> to what has been done by others.
>>
>> Obviously, I think this is a bad idea. I won't give it a NACK,
>> but I won't approve (nor review) it either.
>>
>> Guenter
>
> Hi Guenter,
>
> Thank you for your quick response.
>
> At present, TSI supports a range of functionalities that cannot be exposed through hwmon. Additionally, a new protocol leveraging the TSI endpoint in hardware has been introduced, which, to our understanding, cannot be accommodated within the hwmon subsystem.
>
> Since we already support the RMI interface via misc/amd-sbi, we believe this remains the appropriate place to continue AMD's out-of-band support.
>
> I will update the commit message and cover letter to clearly articulate the rationale behind this change.
>
> Thank you
>
That is neither a reason or an argument for moving _hwmon_ part of the code
out of the hwmon subsystem.
FWIW, your patch series removes a lot of error handling code. Sashiko has
a field day with it.
Guenter
^ permalink raw reply
* Re: [PATCH v2 3/9] kernel/api: add debugfs interface for kernel API specifications
From: Sasha Levin @ 2026-03-24 11:33 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E . McKenney, Jonathan Corbet, Dmitry Vyukov, Randy Dunlap,
Cyril Hrubis, Kees Cook, Jake Edge, David Laight, Askar Safin,
Gabriele Paoloni, Mauro Carvalho Chehab, Christian Brauner,
Alexander Viro, Andrew Morton, Masahiro Yamada, Shuah Khan,
Ingo Molnar, Arnd Bergmann
In-Reply-To: <2026032411-paramount-lapdog-41e6@gregkh>
On Tue, Mar 24, 2026 at 09:20:01AM +0100, Greg Kroah-Hartman wrote:
>On Mon, Mar 23, 2026 at 07:58:50PM -0400, Sasha Levin wrote:
>> > But this only works if the kabi stuff is built into the kernel image,
>> > right? This doesn't work if any of these abi sections are in a module
>> > or am I missing that logic here?
>>
>> That is correct, for now.
>>
>> I'm only trying to tackle syscalls to begin with, and since no syscalls live in
>> modules, we have no need for module support.
>
>We used to support syscalls in modules, but thankfully that is now gone.
>But, how will this work for stuff like usbfs ioctls? That is a module,
>and our uapi is, by far, in drivers through ioctl "hell" and that would
>be great to be able to document through all of this. Will that just not
>be in the debugfs api?
It will. I see it working just like how BTF or trace events do it now.
When a module loads, find_module_sections() extracts the .kapi_specs section
pointer and element count into new struct module fields. The COMING notifier
then iterates those specs, registers each via the existing kapi_register_spec()
dynamic registration path, and creates per-spec debugfs files under the
existing /sys/kernel/debug/kapi/specs/ directory. The kapi_list_show() function
is extended to also walk the dynamic_api_specs list (currently it only iterates
the static __start_kapi_specs..__stop_kapi_specs range). On GOING, all specs
owned by that module are removed from the list and their debugfs entries
cleaned up via debugfs_remove().
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] Documentation: PCI: Document decoding of TLP Header in AER messages
From: Ilpo Järvinen @ 2026-03-24 11:18 UTC (permalink / raw)
To: mx2pg
Cc: Bjorn Helgaas, Lukas Wunner, Jonathan Corbet, linux-pci,
linux-doc, Mika Westerberg, Kai-Heng Feng
In-Reply-To: <jlpBGxAZL6_8dQI417NowB0RVfrnwcnuaNvBlTN035buqP4dRBJaaX3fwqtYxZu2evmcNCAJVzj2suZKDA5iriUSrpj_ziWQVWxZS3nEkEg=@pm.me>
[-- Attachment #1: Type: text/plain, Size: 7508 bytes --]
On Tue, 24 Mar 2026, mx2pg@pm.me wrote:
> One thing worth calling out: starting with PCIe 6.0, Flit Mode is
> mandatory at 64.0 GT/s and supported at all PCIe link speeds, so a
> Flit-capable PCIe 6.x link may operate below 64.0 GT/s and still be
> in Flit Mode. The raw TLP Header bytes do not encode the framing —
> the same four bytes decode to entirely different packet types in
> non-Flit vs Flit framing. The negotiated mode can be read from the
> Flit Mode Status bit in Link Status 2, or via lspci -vv on a recent
> pciutils build.
There's one caveat in using Link Status 2 Flit Mode Status bit, it can
only be used as the indicator when the Link is Up, which may come into
picture in troubleshooting scenarios.
The kernel code tries to hide that by indicating the Flit mode explicitly
in the log message it prints out.
Sadly, TLP Logging on DPC side was botched in the PCIe spec so it doesn't
indicate the Flit/non-Flit mode information explicitly (in contrast to AER
that has a flag that tells in which mode the TLP Log was captured). To
workaround that limitation, kernel has to save of the Link Status 2
contents and hope the information is not stale when DPC has brought the
Link Down (it seems relatively likely to remain valid but it's still
fundamentally racy way to get the Flit/non-Flit information).
--
i.
> tlp-tool defaults to non-Flit, which is correct for the vast majority
> of hardware deployed today. That will change: as PCIe 6.x adoption
> grows, a significant share of TLP debugging will involve Flit Mode
> links, and this is already a concern among switch and device vendors
> working through the transition. Users on Flit Mode links must pass
> --flit:
>
> # non-Flit link (default, most common today)
> curl -L https://git.kernel.org/linus/2ca1c94ce0b6 | rtlp-tool --aer
>
> # Flit Mode link
> curl -L https://git.kernel.org/linus/2ca1c94ce0b6 | rtlp-tool --aer --flit
>
> It may be worth a one-liner in the Documentation patch:
>
> For PCIe 6.x links with Flit Mode negotiated (check Flit Mode Status
> in Link Status 2, or lspci -vv), pass --flit to rtlp-tool.
>
> Maciej
>
>
>
> On Monday, March 23rd, 2026 at 9:50 AM, Bjorn Helgaas <helgaas@kernel.org> wrote:
>
> > On Mon, Mar 23, 2026 at 07:52:39AM +0100, Lukas Wunner wrote:
> > > The prefix/header of the TLP that caused an error is recorded by the Root
> > > Complex and emitted to the kernel log in raw hex format. Document the
> > > existence and usage of tlp-tool, which allows decoding the TLP Header
> > > into human-readable form.
> > >
> > > The TLP Header hints at the root cause of an error, yet is often ignored
> > > because of its seeming opaqueness. Instead, PCIe errors are frequently
> > > worked around by a change in the kernel without fully understanding the
> > > actual source of the problem. With more documentation on available tools
> > > we'll hopefully come up with better solutions.
> > >
> > > There are also wireshark dissectors for TLPs, but it seems they expect a
> > > complete TLP, not just the header, and they cannot grok the hex format
> > > emitted by the kernel directly. tlp-tool appears to be the most cut and
> > > dried solution out there.
> > >
> > > Signed-off-by: Lukas Wunner <lukas@wunner.de>
> > > Cc: Maciej Grochowski <mx2pg@pm.me>
> >
> > Applied to pci/for-linus for v7.0, thanks!
> >
> > I tweaked the commit log to note that the Header Log is in the AER
> > Capability, which may be in any PCIe function.
> >
> > > ---
> > > We could also go one step further and point users to this tool
> > > in a printk_once() message when the first error occurs.
> > > For now, just amending the documentation is probably sufficient.
> > >
> > > Documentation/PCI/pcieaer-howto.rst | 10 ++++++++++
> > > 1 file changed, 10 insertions(+)
> > >
> > > diff --git a/Documentation/PCI/pcieaer-howto.rst b/Documentation/PCI/pcieaer-howto.rst
> > > index 3210c47..90fdfdd 100644
> > > --- a/Documentation/PCI/pcieaer-howto.rst
> > > +++ b/Documentation/PCI/pcieaer-howto.rst
> > > @@ -85,6 +85,16 @@ In the example, 'Requester ID' means the ID of the device that sent
> > > the error message to the Root Port. Please refer to PCIe specs for other
> > > fields.
> > >
> > > +The 'TLP Header' is the prefix/header of the TLP that caused the error
> > > +in raw hex format. To decode the TLP Header into human-readable form
> > > +one may use tlp-tool:
> > > +
> > > +https://github.com/mmpg-x86/tlp-tool
> > > +
> > > +Example usage::
> > > +
> > > + curl -L https://git.kernel.org/linus/2ca1c94ce0b6 | rtlp-tool --aer
> > > +
> > > AER Ratelimits
> > > --------------
> > >
> > > --
> > > 2.51.0
> > >
> >
>
^ permalink raw reply
* Re: [PATCH v8 2/6] iio: Replace 'sign' field with union in struct iio_scan_type
From: Andy Shevchenko @ 2026-03-24 11:04 UTC (permalink / raw)
To: Francesco Lavra
Cc: David Lechner, Jonathan Corbet, Shuah Khan, Jonathan Cameron,
Nuno Sá, Andy Shevchenko, linux-doc, linux-kernel, linux-iio
In-Reply-To: <5c780b1be8a64f7862a421db5a1f5be861cb197c.camel@baylibre.com>
On Mon, Mar 23, 2026 at 06:37:38PM +0100, Francesco Lavra wrote:
> On Mon, 2026-03-23 at 18:49 +0200, Andy Shevchenko wrote:
> > On Mon, Mar 23, 2026 at 05:04:10PM +0100, Francesco Lavra wrote:
> > > On Sat, 2026-03-21 at 12:22 -0500, David Lechner wrote:
> > > > On 3/17/26 10:04 AM, Francesco Lavra wrote:
...
> > > > > + * @IIO_SCAN_FORMAT_SIGNED_INT: Signed integer (two's complement).
> > > > > + * @IIO_SCAN_FORMAT_UNSIGNED_INT: Unsigned integer.
> >
> > > > We could make this proper kernel doc format with one comment per
> > > > macro.
> > >
> > > Actually, a set of related #defines can be documented with a single
> > > comment. I see a few examples doing that in include/linux/gfp_types.h
> > > and
> > > include/linux/fpga/fpga-mgr.h
> > >
> > > > > +#define IIO_SCAN_FORMAT_SIGNED_INT 's'
> > > > > +#define IIO_SCAN_FORMAT_UNSIGNED_INT 'u'
> >
> > ...or use enum
> >
> > /**
> > * ...kernel-doc for enum...
> > */
> > enum {
> > IIO_SCAN_FORMAT_SIGNED_INT = 's',
> > IIO_SCAN_FORMAT_UNSIGNED_INT = 'u',
> > };
>
> There is no standard kernel-doc format for anonymous enums.
What do you mean? We have such in kernel, for example,
drivers/pinctrl/intel/pinctrl-intel.c.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH v4 04/21] mm: avoid deadlock when holding rmap on mmap_prepare error
From: Vlastimil Babka (SUSE) @ 2026-03-24 10:55 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <d44248be9da68258b07c2c59d4e73485ee0ca943.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Commit ac0a3fc9c07d ("mm: add ability to take further action in
> vm_area_desc") added the ability for drivers to instruct mm to take actions
> after the .mmap_prepare callback is complete.
>
> To make life simpler and safer, this is done before the VMA/mmap write lock
> is dropped but when the VMA is completely established.
>
> So on error, we simply munmap() the VMA.
>
> As part of this implementation, unfortunately a horrible hack had to be
> implemented to support some questionable behaviour hugetlb relies upon -
> that is that the file rmap lock is held until the operation is complete.
>
> The implementation, for convenience, did this in mmap_action_finish() so
> both the VMA and mmap_prepare compatibility layer paths would have this
> correctly handled.
>
> However, it turns out there is a mistake here - the rmap lock cannot be
> held on munmap, as free_pgtables() -> unlink_file_vma_batch_add() ->
> unlink_file_vma_batch_process() takes the file rmap lock.
>
> We therefore currently have a deadlock issue that might arise.
>
> Resolve this by leaving it to callers to handle the unmap.
>
> The compatibility layer does not support this rmap behaviour, so we simply
> have it unmap on error after calling mmap_action_complete().
>
> In the VMA implementation, we only perform the unmap after the rmap lock is
> dropped.
>
> This resolves the issue by ensuring the rmap lock is always dropped when
> the unmap occurs.
>
> Fixes: ac0a3fc9c07d ("mm: add ability to take further action in vm_area_desc")
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 01/21] mm: various small mmap_prepare cleanups
From: Vlastimil Babka (SUSE) @ 2026-03-24 10:46 UTC (permalink / raw)
To: Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, Long Li, Alexander Shishkin, Maxime Coquelin,
Alexandre Torgue, Miquel Raynal, Richard Weinberger,
Vignesh Raghavendra, Bodo Stroesser, Martin K . Petersen,
David Howells, Marc Dionne, Alexander Viro, Christian Brauner,
Jan Kara, David Hildenbrand, Liam R . Howlett, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel, linux-doc, linux-hyperv, linux-stm32,
linux-arm-kernel, linux-mtd, linux-staging, linux-scsi,
target-devel, linux-afs, linux-fsdevel, linux-mm, Ryan Roberts
In-Reply-To: <99f408e4694f44ab12bdc55fe0bd9685d3bd1117.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> Rather than passing arbitrary fields, pass a vm_area_desc pointer to mmap
> prepare functions to mmap prepare, and an action and vma pointer to mmap
> complete in order to put all the action-specific logic in the function
> actually doing the work.
>
> Additionally, allow mmap prepare functions to return an error so we can
> error out as soon as possible if there is something logically incorrect in
> the input.
>
> Update remap_pfn_range_prepare() to properly check the input range for the
> CoW case.
>
> Also remove io_remap_pfn_range_complete(), as we can simply set up the
> fields correctly in io_remap_pfn_range_prepare() and use
> remap_pfn_range_complete() for this.
>
> While we're here, make remap_pfn_range_prepare_vma() a little neater, and
> pass mmap_action directly to call_action_complete().
>
> Then, update compat_vma_mmap() to perform its logic directly, as
> __compat_vma_map() is not used by anything so we don't need to export it.
>
> Also update compat_vma_mmap() to use vfs_mmap_prepare() rather than
> calling the mmap_prepare op directly.
>
> Finally, update the VMA userland tests to reflect the changes.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v1 1/6] hwmon/misc: amd-sbi: Move core SBTSI support from hwmon to misc
From: Gupta, Akshay @ 2026-03-24 10:36 UTC (permalink / raw)
To: Guenter Roeck, linux-kernel@vger.kernel.org
Cc: corbet@lwn.net, skhan@linuxfoundation.org, arnd@arndb.de,
gregkh@linuxfoundation.org, L k, Prathima,
Chatradhi, Naveen Krishna, Umarji, Anand,
linux-doc@vger.kernel.org, linux-hwmon@vger.kernel.org,
kunyi@google.com
In-Reply-To: <86ec222b-d252-4586-a1cc-2a7a5674e1b4@roeck-us.net>
On 3/23/2026 7:45 PM, Guenter Roeck wrote:
> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>
>
> On 3/23/26 04:08, Akshay Gupta wrote:
>> From: Prathima <Prathima.Lk@amd.com>
>>
>> Move SBTSI core functionality out of the hwmon-only path and into
>> drivers/misc/amd-sbi so it can be reused by non-hwmon consumers.
>>
>> This split prepares the driver for additional interfaces while keeping
>> hwmon support as an optional layer on top of common SBTSI core logic.
>>
> This moves the driver out of hwmon space into misc/amd-sbi which,
> in my opinion, is completely unnecessary to accomplish the stated goals.
>
> I assume this is to be able to make changes which do not follow
> the hwmon ABI and/or to bypass hwmon subsystem review, similar
> to what has been done by others.
>
> Obviously, I think this is a bad idea. I won't give it a NACK,
> but I won't approve (nor review) it either.
>
> Guenter
Hi Guenter,
Thank you for your quick response.
At present, TSI supports a range of functionalities that cannot be
exposed through hwmon. Additionally, a new protocol leveraging the TSI
endpoint in hardware has been introduced, which, to our understanding,
cannot be accommodated within the hwmon subsystem.
Since we already support the RMI interface via misc/amd-sbi, we believe
this remains the appropriate place to continue AMD's out-of-band support.
I will update the commit message and cover letter to clearly articulate
the rationale behind this change.
Thank you
^ permalink raw reply
* Re: [PATCH] Documentation: PCI: Document decoding of TLP Header in AER messages
From: Lukas Wunner @ 2026-03-24 10:22 UTC (permalink / raw)
To: Maciej Grochowski
Cc: Bjorn Helgaas, Jonathan Corbet, linux-pci, linux-doc,
Mika Westerberg, Ilpo Jarvinen, Kai-Heng Feng
In-Reply-To: <acJi32zgSVvDPVyK@wunner.de>
On Tue, Mar 24, 2026 at 11:09:35AM +0100, Lukas Wunner wrote:
> Ilpo (who is cc'ed) amended the kernel last year with commit
> 7e077e6707b3 ("PCI/ERR: Handle TLP Log in Flit mode") to suffix
> the hexdump with " (Flit)" in Flit Mode:
>
> https://git.kernel.org/linus/7e077e6707b3
Sorry, I should have mentioned that this commit first appeared in
v6.15, so auto-detection of Flit mode logs in user space tools
should be possible from that kernel version onward.
> As an aside: Prior to that, commit f68ea779d98a ("PCI: Add
> pcie_print_tlp_log() to print TLP Header and Prefix Log")
> changed the log message to prefix each dword with "0x".
> But I tested it and it seems that tlp-tool groks both the
> old and the new format without any code change:
>
> https://git.kernel.org/linus/f68ea779d98a
This landed in v6.14.
Thanks,
Lukas
^ permalink raw reply
* Re: [PATCH v6 00/40] arm_mpam: Add KVM/arm64 and resctrl glue code
From: Ben Horgan @ 2026-03-24 10:09 UTC (permalink / raw)
To: Gavin Shan
Cc: amitsinght, baisheng.gao, baolin.wang, carl, dave.martin, david,
dfustini, fenghuay, james.morse, jonathan.cameron, kobak,
lcherian, linux-arm-kernel, linux-kernel, peternewman,
punit.agrawal, quic_jiles, reinette.chatre, rohit.mathew, scott,
sdonthineni, tan.shaopeng, xhao, catalin.marinas, will, corbet,
maz, oupton, joey.gouly, suzuki.poulose, kvmarm, zengheng4,
linux-doc
In-Reply-To: <71f9ac1e-9f5a-4f12-807b-bbe0803f99e7@redhat.com>
Hi Gavin,
On 3/23/26 04:41, Gavin Shan wrote:
> * # Be careful, this email looks suspicious; * Out of Character: The sender is exhibiting a significant deviation from
> their usual behavior, this may indicate that their account has been compromised. Be extra cautious before opening links
> or attachments. *
> On 3/14/26 12:45 AM, Ben Horgan wrote:
>> This version of the mpam missing pieces series sees a couple of things
>> dropped or hidden. Memory bandwith utilization with free-running counters
>> is dropped in preference of just always using 'mbm_event' mode (ABMC
>> emulation) which simplifies the code and allows for, in the future,
>> filtering by read/write traffic. So, for the interim, there is no memory
>> bandwidth utilization support. CDP is hidden behind config expert as
>> remount of resctrl fs could potentially lead to out of range PARTIDs being
>> used and the fix requires a change in fs/resctrl. The setting of MPAM2_EL2
>> (for pkvm/nvhe) is dropped as too expensive a write for not much value.
>>
>> There are a couple of 'fixes' at the start of the series which address
>> problems in the base driver but are only user visible due to this series.
>>
>> Changelogs in patches
>>
>> Thanks for all the reviewing and testing so far. Just a bit more to get this
>> over the line.
>>
>> There is a small build conflict with the MPAM abmc precursors series [1], which
>> alters some of the resctrl arch hooks. I will shortly be posting a respin
>> of that too.
>>
>> [1] https://lore.kernel.org/lkml/20260225201905.3568624-1-ben.horgan@arm.com/
>>
>> From James' cover letter:
>>
>> This is the missing piece to make MPAM usable resctrl in user-space. This has
>> shed its debugfs code and the read/write 'event configuration' for the monitors
>> to make the series smaller.
>>
>> This adds the arch code and KVM support first. I anticipate the whole thing
>> going via arm64, but if goes via tip instead, the an immutable branch with those
>> patches should be easy to do.
>>
>> Generally the resctrl glue code works by picking what MPAM features it can expose
>> from the MPAM drive, then configuring the structs that back the resctrl helpers.
>> If your platform is sufficiently Xeon shaped, you should be able to get L2/L3 CPOR
>> bitmaps exposed via resctrl. CSU counters work if they are on/after the L3. MBWU
>> counters are considerably more hairy, and depend on hueristics around the topology,
>> and a bunch of stuff trying to emulate ABMC.
>> If it didn't pick what you wanted it to, please share the debug messages produced
>> when enabling dynamic debug and booting with:
>> | dyndbg="file mpam_resctrl.c +pl"
>>
>> I've not found a platform that can test all the behaviours around the monitors,
>> so this is where I'd expect the most bugs.
>>
>> The MPAM spec that describes all the system and MMIO registers can be found here:
>> https://developer.arm.com/documentation/ddi0598/db/?lang=en
>> (Ignored the 'RETIRED' warning - that is just arm moving the documentation around.
>> This document has the best overview)
>>
>>
>> Based on v7.0-rc3
>>
>> The series can be retrieved from:
>> https://gitlab.arm.com/linux-arm/linux-bh.git mpam_resctrl_glue_v6
>>
>
> [...]
>
> Retested this series on NVidia's grace-hopper machine where L3 cache partitioning
> and MBW (soft) limiting worked as expected. Besides, The L3 cache monitor counters
> are increased as more cache usage is observed.
>
> Tested-by: Gavin Shan <gshan@redhat.com>
Thanks for testing and all the reviews.
Ben
>
> Thanks,
> Gavin
>
>
^ permalink raw reply
* Re: [PATCH 2/2] Documentation: document panic_on_unrecoverable_memory_failure sysctl
From: Breno Leitao @ 2026-03-24 10:09 UTC (permalink / raw)
To: Randy Dunlap
Cc: Miaohe Lin, Naoya Horiguchi, Andrew Morton, Jonathan Corbet,
Shuah Khan, linux-mm, linux-kernel, linux-doc, kernel-team
In-Reply-To: <e046d0a8-b10b-405f-b3dd-94b7f4450313@infradead.org>
Hello Randy,
On Mon, Mar 23, 2026 at 09:51:55AM -0700, Randy Dunlap wrote:
> On 3/23/26 8:29 AM, Breno Leitao wrote:
> > Document the new vm.panic_on_unrecoverable_memory_failure sysctl in the
> > admin guide, following the same format as panic_on_unrecovered_nmi.
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > ---
> > Documentation/admin-guide/sysctl/vm.rst | 27 +++++++++++++++++++++++++++
> > 1 file changed, 27 insertions(+)
> >
> > diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst
> > index 97e12359775c9..3310fb8272fb9 100644
> > --- a/Documentation/admin-guide/sysctl/vm.rst
> > +++ b/Documentation/admin-guide/sysctl/vm.rst
>
>
> > +
> > += ===================================================================
> > +0 Try to continue operation (default).
> > +1 Panic immediately. If the ``panic`` sysctl is also non-zero then the
> > + machine will be rebooted.
> > += ===================================================================
>
> The table begin and end lines must be at least as long as the text (may be
> longer). Please extend the =========== lines by a few characters.
The HTML renders correctly in Sphinx (likely due to automatic column
expansion), but I agree the raw table format should be properly
structured.
I'll send v2 with this corrected.
Thanks for the review,
--breno
^ permalink raw reply
* Re: [PATCH] Documentation: PCI: Document decoding of TLP Header in AER messages
From: Lukas Wunner @ 2026-03-24 10:09 UTC (permalink / raw)
To: Maciej Grochowski
Cc: Bjorn Helgaas, Jonathan Corbet, linux-pci, linux-doc,
Mika Westerberg, Ilpo Jarvinen, Kai-Heng Feng
In-Reply-To: <jlpBGxAZL6_8dQI417NowB0RVfrnwcnuaNvBlTN035buqP4dRBJaaX3fwqtYxZu2evmcNCAJVzj2suZKDA5iriUSrpj_ziWQVWxZS3nEkEg=@pm.me>
On Tue, Mar 24, 2026 at 05:53:30AM +0000, mx2pg@pm.me wrote:
> One thing worth calling out: starting with PCIe 6.0, Flit Mode is
> mandatory at 64.0 GT/s and supported at all PCIe link speeds, so a
> Flit-capable PCIe 6.x link may operate below 64.0 GT/s and still be
> in Flit Mode. The raw TLP Header bytes do not encode the framing —
> the same four bytes decode to entirely different packet types in
> non-Flit vs Flit framing. The negotiated mode can be read from the
> Flit Mode Status bit in Link Status 2, or via lspci -vv on a recent
> pciutils build.
Thanks Maciej for chiming in.
Ilpo (who is cc'ed) amended the kernel last year with commit
7e077e6707b3 ("PCI/ERR: Handle TLP Log in Flit mode") to suffix
the hexdump with " (Flit)" in Flit Mode:
https://git.kernel.org/linus/7e077e6707b3
Any chance you could amend tlp-tool to auto-detect Flit Mode
if the suffix is present?
As an aside: Prior to that, commit f68ea779d98a ("PCI: Add
pcie_print_tlp_log() to print TLP Header and Prefix Log")
changed the log message to prefix each dword with "0x".
But I tested it and it seems that tlp-tool groks both the
old and the new format without any code change:
https://git.kernel.org/linus/f68ea779d98a
But we need to be careful going forward not to break user space
tooling that might rely on the syntax.
Thanks,
Lukas
^ permalink raw reply
* Re: [RFC net-next 15/15] Documentation: networking: add ipxlat translator guide
From: Ralf Lici @ 2026-03-24 9:55 UTC (permalink / raw)
To: Jonathan Corbet, netdev
Cc: Daniel Gröber, Antonio Quartulli, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Shuah Khan, linux-doc, linux-kernel
In-Reply-To: <87se9vh3ls.fsf@trenco.lwn.net>
On 3/19/26 23:11, Jonathan Corbet wrote:
> Ralf Lici <ralf@mandelbit.com> writes:
>
>> From: Daniel Gröber <dxld@darkboxed.org>
>>
>> Add user and reviewer documentation for the ipxlat virtual netdevice in
>> Documentation/networking/ipxlat.rst.
>>
>> The document describes the datapath model, stateless IPv4/IPv6 address
>> translation rules, ICMP handling, control-plane configuration, and test
>> topology assumptions. It also records the intended runtime configuration
>> contract and current behavior limits so deployment expectations are
>> clear.
>>
>> Signed-off-by: Daniel Gröber <dxld@darkboxed.org>
>> Signed-off-by: Ralf Lici <ralf@mandelbit.com>
>> ---
>> Documentation/networking/ipxlat.rst | 190 ++++++++++++++++++++++++++++
>> 1 file changed, 190 insertions(+)
>> create mode 100644 Documentation/networking/ipxlat.rst
>
> You need to add this new file to Documentation/networking/index.rst or
> it won't be included in the build (and you'll get a warning).
>
> Thanks,
>
> jon
Hi Jon,
Thanks for the heads-up.
I’ve fixed this for the next revision. While rechecking with 'make
SPHINXDIRS=networking htmldocs', I also found and fixed a couple of
'ipxlat.rst' issues reported by Sphinx.
Thanks,
--
Ralf Lici
Mandelbit Srl
^ permalink raw reply
* Re: [PATCH v2 3/9] kernel/api: add debugfs interface for kernel API specifications
From: Mauro Carvalho Chehab @ 2026-03-24 9:49 UTC (permalink / raw)
To: Sasha Levin, Greg Kroah-Hartman
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E . McKenney, Jonathan Corbet, Dmitry Vyukov, Randy Dunlap,
Cyril Hrubis, Kees Cook, Jake Edge, David Laight, Askar Safin,
Gabriele Paoloni, Mauro Carvalho Chehab, Christian Brauner,
Alexander Viro, Andrew Morton, Masahiro Yamada, Shuah Khan,
Ingo Molnar, Arnd Bergmann
In-Reply-To: <acHTupVGxJR3gmFT@laps>
Hi Sasha,
On Mon, 23 Mar 2026 19:58:50 -0400
Sasha Levin <sashal@kernel.org> wrote:
> On Mon, Mar 23, 2026 at 02:52:58PM +0100, Greg Kroah-Hartman wrote:
> >On Sun, Mar 22, 2026 at 08:10:17AM -0400, Sasha Levin wrote:
> >> Add a debugfs interface to expose kernel API specifications at runtime.
> >> This allows tools and users to query the complete API specifications
> >> through the debugfs filesystem.
> >>
> >> The interface provides:
> >> - /sys/kernel/debug/kapi/list - lists all available API specifications
> >> - /sys/kernel/debug/kapi/specs/<name> - detailed info for each API
> >>
> >> Each specification file includes:
> >> - Function name, version, and descriptions
> >> - Execution context requirements and flags
> >> - Parameter details with types, flags, and constraints
> >> - Return value specifications and success conditions
> >> - Error codes with descriptions and conditions
> >> - Locking requirements and constraints
> >> - Signal handling specifications
> >> - Examples, notes, and deprecation status
> >>
> >> This enables runtime introspection of kernel APIs for documentation
> >> tools, static analyzers, and debugging purposes.
> >>
> >> Signed-off-by: Sasha Levin <sashal@kernel.org>
> >
> >Debugfs logic looks sane, nice.
>
> Thanks!
>
> >But this only works if the kabi stuff is built into the kernel image,
> >right? This doesn't work if any of these abi sections are in a module
> >or am I missing that logic here?
>
> That is correct, for now.
>
> I'm only trying to tackle syscalls to begin with, and since no syscalls live in
> modules, we have no need for module support.
Have you seen tools/docs/get_abi.py?
It handles debugfs/sysfs descriptions from Documentation/ABI/.
Its "rest" command converts ABI specs from it into RST.
The "undefined" command does realtime introspection for sysfs ABI,
checking if they're documented.
Perhaps you should consider integrating it on your new tool.
--
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH v4] landlock: Expand restrict flags example for ABI version 8
From: Günther Noack @ 2026-03-24 9:48 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Panagiotis "Ivory" Vasilopoulos, Jonathan Corbet,
Shuah Khan, linux-security-module, linux-doc, linux-kernel,
Dan Cojocaru
In-Reply-To: <20260323.sheiHaR5uRoo@digikod.net>
Hello!
On Mon, Mar 23, 2026 at 07:56:21PM +0100, Mickaël Salaün wrote:
> Thanks! I pushed your patch in next with a minor fix.
>
> Günther, does it look good to you?
>
> On Wed, Mar 04, 2026 at 07:13:04PM +0100, Panagiotis "Ivory" Vasilopoulos wrote:
> > Add LANDLOCK_RESTRICT_SELF_TSYNC to the backwards compatibility example
> > for restrict flags. This introduces completeness, similar to that of
> > the ruleset attributes example. However, as the new example can impact
> > enforcement in certain cases, an appropriate warning is also included.
> >
> > Additionally, I modified the two comments of the example to make them
> > more consistent with the ruleset attributes example's.
> >
> > Signed-off-by: Panagiotis 'Ivory' Vasilopoulos <git@n0toose.net>
> > Co-developed-by: Dan Cojocaru <dan@dcdev.ro>
> > Signed-off-by: Dan Cojocaru <dan@dcdev.ro>
> > ---
> > Changes in v4:
> > - Make warning somewhat more terse, merge comments.
> > - Remove some sensationalization. ("Don't copy-paste this just yet!")
> > - Apply Günther's suggestion (v3 "recycled" some phrases, was long)
> > - ... but also retain some of the wording on ABI differences
> > - Provide a brief overview that contextualizes the example further:
> > - Clarify the difference behind ABI < 8 & ABI v8, to avoid
> > misunderstandings on which option is the default.
> > - Make "linear reading" easier.
> > - Based on Mickaël's feedback: Avoid cans of worms w.r.t. use cases
> > - Link to v3: https://lore.kernel.org/r/20260228-landlock-docs-add-tsync-example-v3-1-140ab50f0524@n0toose.net
> >
> > Changes in v3:
> > - Add __attribute__((fallthrough)) like in earlier example.
> > - Improve comment for LANDLOCK_RESTRICT_SELF_TSYNC (ABI < 8) example.
> > - Add relevant warning for ABI < 8 example based on Günther's feedback.
> > - Link to v2: https://lore.kernel.org/r/20260221-landlock-docs-add-tsync-example-v2-1-60990986bba5@n0toose.net
> >
> > Changes in v2:
> > - Fix formatting error.
> > - Link to v1: https://lore.kernel.org/r/20260221-landlock-docs-add-tsync-example-v1-1-f89383809eb4@n0toose.net
> > ---
> > Documentation/userspace-api/landlock.rst | 22 ++++++++++++++++++----
> > 1 file changed, 18 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/userspace-api/landlock.rst b/Documentation/userspace-api/landlock.rst
> > index 13134bccdd39d78ddce3daf454f32dda162ce91b..64c7138a788d74f99da0a71428da392b3d873bf8 100644
> > --- a/Documentation/userspace-api/landlock.rst
> > +++ b/Documentation/userspace-api/landlock.rst
> > @@ -196,13 +196,27 @@ similar backwards compatibility check is needed for the restrict flags
> > (see sys_landlock_restrict_self() documentation for available flags):
> >
> > .. code-block:: c
> > -
> > - __u32 restrict_flags = LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON;
> > - if (abi < 7) {
> > - /* Clear logging flags unsupported before ABI 7. */
> > + __u32 restrict_flags =
> > + LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON |
> > + LANDLOCK_RESTRICT_SELF_TSYNC;
> > + switch (abi) {
> > + case 1 ... 6:
> > + /* Clear logging flags unsupported for ABI < 7 */
> > restrict_flags &= ~(LANDLOCK_RESTRICT_SELF_LOG_SAME_EXEC_OFF |
> > LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON |
> > LANDLOCK_RESTRICT_SELF_LOG_SUBDOMAINS_OFF);
> > + __attribute__((fallthrough));
> > + case 7:
> > + /*
> > + * Removes multithreaded enforcement flag unsupported for ABI < 8
> > + *
> > + * WARNING: Without this flag, calling landlock_restrict_self(2) is
> > + * only equivalent if the calling process is single-threaded. Below
> > + * ABI v8 (and as of ABI v8, when not using this flag), a Landlock
> > + * policy would only be enforced for the calling thread and its
> > + * children (and not for all threads, including parents and siblings).
> > + */
> > + restrict_flags &= ~LANDLOCK_RESTRICT_SELF_TSYNC;
> > }
> >
> > The next step is to restrict the current thread from gaining more privileges
> >
> > ---
> > base-commit: ceb977bfe9e8715e6cd3a4785c7aab8ea5cd2b77
> > change-id: 20260221-landlock-docs-add-tsync-example-e8fd5c64a366
> >
> > Best regards,
> > --
> > Panagiotis "Ivory" Vasilopoulos <git@n0toose.net>
> >
> >
Apologies for the delay, this must have slipped through the cracks.
Thanks for bringing it up again. Yes, this looks good.
Signed-off-by: Günther Noack <gnoack@google.com>
—Günther
^ permalink raw reply
* Re: [PATCH 0/2] kallsyms: show typed function parameters in oops/WARN dumps
From: Jiri Olsa @ 2026-03-24 8:57 UTC (permalink / raw)
To: Sasha Levin
Cc: Andrew Morton, Masahiro Yamada, Nathan Chancellor, Nicolas Schier,
Thomas Gleixner, Ingo Molnar, Borislav Petkov, Dave Hansen,
H. Peter Anvin, Peter Zijlstra, Josh Poimboeuf, Petr Mladek,
Alexei Starovoitov, Jonathan Corbet, David Gow, Kees Cook,
Greg KH, Luis Chamberlain, Steven Rostedt, Helge Deller,
Randy Dunlap, Geert Uytterhoeven, Juergen Gross, James Bottomley,
Alexey Dobriyan, Vlastimil Babka, Laurent Pinchart, Petr Pavlu,
x86, linux-kernel, linux-kbuild, linux-doc, linux-modules, bpf
In-Reply-To: <20260323164858.1939248-1-sashal@kernel.org>
On Mon, Mar 23, 2026 at 12:48:55PM -0400, Sasha Levin wrote:
> Building on the lineinfo series, this adds typed function parameter
hi,
could you please specify the exact tree/commit and point to the
series this patchset is based on?
thanks,
jirka
> display to oops and WARN dumps. A build-time tool extracts parameter
> names and types from DWARF, and the kernel maps pt_regs to the calling
> convention at crash time. When BTF is available, struct pointer
> parameters are dereferenced and their members displayed.
>
> Example output from a WARN in a function receiving struct new_utsname *
> (kernel version info) and struct file * parameters:
>
> ------------[ cut here ]------------
> WARNING: drivers/tty/sysrq.c:1209 at demo_crash+0xf/0x20 (drivers/tty/sysrq.c:1209)
> CPU: 2 UID: 0 PID: 323 Comm: bash
> RIP: 0010:demo_crash+0xf/0x20 (drivers/tty/sysrq.c:1209)
> ...
> RDI: ffffffffb8ca8d00
> RSI: ffffa0a3c250acc0
> ...
> Function parameters (paraminfo_demo_crash):
> uts (struct new_utsname *) = 0xffffffffb8ca8d00
> .sysname = "Linux" .nodename = "localhost"
> .release = "7.0.0-rc2-00006-g3190..." .version = "#45 SMP PRE"
> file (struct file * ) = 0xffffa0a3c250acc0
> .f_mode = (fmode_t)67993630 .f_op = (struct file_operations *)0xffffffffb7237620
> .f_flags = (unsigned int)32769 .f_cred = (struct cred *)0xffffa0a3c2e06a80
> .dentry = (struct dentry *)0xffffa0a3c0978cc0
> .prev_pos = (loff_t)-1
> Call Trace:
> <TASK>
> write_sysrq_trigger+0x96/0xb0 (drivers/tty/sysrq.c:1222)
> proc_reg_write+0x54/0xa0 (fs/proc/inode.c:330)
> vfs_write+0xc9/0x480 (fs/read_write.c:686)
> ksys_write+0x6e/0xe0 (fs/read_write.c:738)
> do_syscall_64+0xe2/0x570 (arch/x86/entry/syscall_64.c:62)
> entry_SYSCALL_64_after_hwframe+0x77/0x7f (arch/x86/entry/entry_64.S:121)
>
> Patch 1 adds the core paraminfo infrastructure (DWARF extraction,
> kernel-side lookup, register-to-parameter mapping, ~1-2 MB overhead).
> Patch 2 adds optional BTF-based struct rendering, gated behind
> CONFIG_KALLSYMS_PARAMINFO_BTF.
>
> Sasha Levin (2):
> kallsyms: show function parameter info in oops/WARN dumps
> kallsyms: add BTF-based deep parameter rendering in oops dumps
>
> .../admin-guide/kallsyms-lineinfo.rst | 31 +
> arch/x86/kernel/dumpstack.c | 6 +-
> include/linux/kallsyms.h | 9 +
> init/Kconfig | 40 ++
> kernel/Makefile | 1 +
> kernel/kallsyms.c | 182 ++++++
> kernel/kallsyms_internal.h | 6 +
> kernel/kallsyms_paraminfo_btf.c | 199 ++++++
> lib/Kconfig.debug | 11 +
> lib/tests/Makefile | 3 +
> lib/tests/paraminfo_kunit.c | 249 ++++++++
> scripts/Makefile | 3 +
> scripts/empty_paraminfo.S | 18 +
> scripts/gen_paraminfo.c | 597 ++++++++++++++++++
> scripts/link-vmlinux.sh | 44 +-
> 15 files changed, 1393 insertions(+), 6 deletions(-)
> create mode 100644 kernel/kallsyms_paraminfo_btf.c
> create mode 100644 lib/tests/paraminfo_kunit.c
> create mode 100644 scripts/empty_paraminfo.S
> create mode 100644 scripts/gen_paraminfo.c
>
> --
> 2.51.0
>
>
^ permalink raw reply
* [PATCH v9 4/6] iio: ABI: Add support for floating-point numbers in buffer scan elements
From: Francesco Lavra @ 2026-03-24 8:47 UTC (permalink / raw)
To: Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Jonathan Corbet, Shuah Khan, linux-iio, linux-kernel, linux-doc
In-Reply-To: <20260324084655.653781-1-flavra@baylibre.com>
In the data storage description of a scan element, the first character
after the colon can have the values 's' and 'u' to specify signed and
unsigned integers, respectively.
Add 'f' as an allowed value to specify floating-point numbers formatted
according to the IEEE 754 standard.
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
---
Documentation/ABI/testing/sysfs-bus-iio | 33 +++++++++++++-----------
Documentation/driver-api/iio/buffers.rst | 3 ++-
Documentation/iio/iio_devbuf.rst | 3 ++-
include/linux/iio/iio.h | 7 +++++
4 files changed, 29 insertions(+), 17 deletions(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio
index 5f87dcee78f7..bd6c3305dd2b 100644
--- a/Documentation/ABI/testing/sysfs-bus-iio
+++ b/Documentation/ABI/testing/sysfs-bus-iio
@@ -1510,21 +1510,24 @@ Contact: linux-iio@vger.kernel.org
Description:
Description of the scan element data storage within the buffer
and hence the form in which it is read from user-space.
- Form is [be|le]:[s|u]bits/storagebits[>>shift].
- be or le specifies big or little endian. s or u specifies if
- signed (2's complement) or unsigned. bits is the number of bits
- of data and storagebits is the space (after padding) that it
- occupies in the buffer. shift if specified, is the shift that
- needs to be applied prior to masking out unused bits. Some
- devices put their data in the middle of the transferred elements
- with additional information on both sides. Note that some
- devices will have additional information in the unused bits
- so to get a clean value, the bits value must be used to mask
- the buffer output value appropriately. The storagebits value
- also specifies the data alignment. So s48/64>>2 will be a
- signed 48 bit integer stored in a 64 bit location aligned to
- a 64 bit boundary. To obtain the clean value, shift right 2
- and apply a mask to zero the top 16 bits of the result.
+ Form is [be|le]:[f|s|u]bits/storagebits[>>shift].
+ be or le specifies big or little endian. f means floating-point
+ (IEEE 754 binary format), s means signed (2's complement), u means
+ unsigned. bits is the number of bits of data and storagebits is the
+ space (after padding) that it occupies in the buffer; when using a
+ floating-point format, bits must be one of the width values defined
+ in the IEEE 754 standard for binary interchange formats (e.g. 16
+ indicates the binary16 format for half-precision numbers). shift,
+ if specified, is the shift that needs to be applied prior to
+ masking out unused bits. Some devices put their data in the middle
+ of the transferred elements with additional information on both
+ sides. Note that some devices will have additional information in
+ the unused bits, so to get a clean value the bits value must be
+ used to mask the buffer output value appropriately. The storagebits
+ value also specifies the data alignment. So s48/64>>2 will be a
+ signed 48 bit integer stored in a 64 bit location aligned to a 64
+ bit boundary. To obtain the clean value, shift right 2 and apply a
+ mask to zero the top 16 bits of the result.
For other storage combinations this attribute will be extended
appropriately.
diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst
index e16abaf826fe..8779022e3da5 100644
--- a/Documentation/driver-api/iio/buffers.rst
+++ b/Documentation/driver-api/iio/buffers.rst
@@ -37,9 +37,10 @@ directory contains attributes of the following form:
* :file:`index`, the scan_index of the channel.
* :file:`type`, description of the scan element data storage within the buffer
and hence the form in which it is read from user space.
- Format is [be|le]:[s|u]bits/storagebits[Xrepeat][>>shift] .
+ Format is [be|le]:[f|s|u]bits/storagebits[Xrepeat][>>shift] .
* *be* or *le*, specifies big or little endian.
+ * *f*, specifies if floating-point.
* *s* or *u*, specifies if signed (2's complement) or unsigned.
* *bits*, is the number of valid data bits.
* *storagebits*, is the number of bits (after padding) that it occupies in the
diff --git a/Documentation/iio/iio_devbuf.rst b/Documentation/iio/iio_devbuf.rst
index dca1f0200b0d..e91730fa3cea 100644
--- a/Documentation/iio/iio_devbuf.rst
+++ b/Documentation/iio/iio_devbuf.rst
@@ -83,9 +83,10 @@ and the relevant _type attributes to establish the data storage format.
Read-only attribute containing the description of the scan element data storage
within the buffer and hence the form in which it is read from userspace. Format
-is [be|le]:[s|u]bits/storagebits[Xrepeat][>>shift], where:
+is [be|le]:[f|s|u]bits/storagebits[Xrepeat][>>shift], where:
- **be** or **le** specifies big or little-endian.
+- **f** specifies if floating-point.
- **s** or **u** specifies if signed (2's complement) or unsigned.
- **bits** is the number of valid data bits.
- **storagebits** is the number of bits (after padding) that it occupies in the
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index 745290bd9af4..97ac4961585f 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -190,6 +190,13 @@ struct iio_event_spec {
*/
#define IIO_SCAN_FORMAT_UNSIGNED_INT 'u'
+/**
+ * define IIO_SCAN_FORMAT_FLOAT - floating-point data format
+ *
+ * &iio_scan_type.format value for IEEE 754 floating-point numbers.
+ */
+#define IIO_SCAN_FORMAT_FLOAT 'f'
+
/**
* struct iio_scan_type - specification for channel data format in buffer
* @sign: Deprecated, use @format instead.
--
2.39.5
^ permalink raw reply related
* [PATCH v9 2/6] iio: Replace 'sign' field with union in struct iio_scan_type
From: Francesco Lavra @ 2026-03-24 8:47 UTC (permalink / raw)
To: Jonathan Corbet, Shuah Khan, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, linux-doc, linux-kernel, linux-iio
In-Reply-To: <20260324084655.653781-1-flavra@baylibre.com>
This field is used to differentiate between signed and unsigned integers.
A following commit will extend its use in order to add support for non-
integer scan elements; therefore, replace it with a union that contains a
more generic 'format' field. This union will be dropped when all drivers
are changed to use the format field.
Opportunistically replace character literals with symbolic constants that
represent the set of allowed values for the format field.
Signed-off-by: Francesco Lavra <flavra@baylibre.com>
---
Documentation/driver-api/iio/buffers.rst | 4 ++--
include/linux/iio/iio.h | 23 +++++++++++++++++++++--
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/Documentation/driver-api/iio/buffers.rst b/Documentation/driver-api/iio/buffers.rst
index 63f364e862d1..e16abaf826fe 100644
--- a/Documentation/driver-api/iio/buffers.rst
+++ b/Documentation/driver-api/iio/buffers.rst
@@ -78,7 +78,7 @@ fields in iio_chan_spec definition::
/* other members */
int scan_index
struct {
- char sign;
+ char format;
u8 realbits;
u8 storagebits;
u8 shift;
@@ -98,7 +98,7 @@ following channel definition::
/* other stuff here */
.scan_index = 0,
.scan_type = {
- .sign = 's',
+ .format = IIO_SCAN_FORMAT_SIGNED_INT,
.realbits = 12,
.storagebits = 16,
.shift = 4,
diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
index a9ecff191bd9..745290bd9af4 100644
--- a/include/linux/iio/iio.h
+++ b/include/linux/iio/iio.h
@@ -176,9 +176,25 @@ struct iio_event_spec {
unsigned long mask_shared_by_all;
};
+/**
+ * define IIO_SCAN_FORMAT_SIGNED_INT - signed integer data format
+ *
+ * &iio_scan_type.format value for signed integers (two's complement).
+ */
+#define IIO_SCAN_FORMAT_SIGNED_INT 's'
+
+/**
+ * define IIO_SCAN_FORMAT_UNSIGNED_INT - unsigned integer data format
+ *
+ * &iio_scan_type.format value for unsigned integers.
+ */
+#define IIO_SCAN_FORMAT_UNSIGNED_INT 'u'
+
/**
* struct iio_scan_type - specification for channel data format in buffer
- * @sign: 's' or 'u' to specify signed or unsigned
+ * @sign: Deprecated, use @format instead.
+ * @format: Data format, can have any of the IIO_SCAN_FORMAT_*
+ * values.
* @realbits: Number of valid bits of data
* @storagebits: Realbits + padding
* @shift: Shift right by this before masking out realbits.
@@ -189,7 +205,10 @@ struct iio_event_spec {
* @endianness: little or big endian
*/
struct iio_scan_type {
- char sign;
+ union {
+ char sign;
+ char format;
+ };
u8 realbits;
u8 storagebits;
u8 shift;
--
2.39.5
^ permalink raw reply related
* Re: [PATCH v2 3/9] kernel/api: add debugfs interface for kernel API specifications
From: Greg Kroah-Hartman @ 2026-03-24 8:20 UTC (permalink / raw)
To: Sasha Levin
Cc: linux-api, linux-kernel, linux-doc, linux-fsdevel, linux-kbuild,
linux-kselftest, workflows, tools, x86, Thomas Gleixner,
Paul E . McKenney, Jonathan Corbet, Dmitry Vyukov, Randy Dunlap,
Cyril Hrubis, Kees Cook, Jake Edge, David Laight, Askar Safin,
Gabriele Paoloni, Mauro Carvalho Chehab, Christian Brauner,
Alexander Viro, Andrew Morton, Masahiro Yamada, Shuah Khan,
Ingo Molnar, Arnd Bergmann
In-Reply-To: <acHTupVGxJR3gmFT@laps>
On Mon, Mar 23, 2026 at 07:58:50PM -0400, Sasha Levin wrote:
> > But this only works if the kabi stuff is built into the kernel image,
> > right? This doesn't work if any of these abi sections are in a module
> > or am I missing that logic here?
>
> That is correct, for now.
>
> I'm only trying to tackle syscalls to begin with, and since no syscalls live in
> modules, we have no need for module support.
We used to support syscalls in modules, but thankfully that is now gone.
But, how will this work for stuff like usbfs ioctls? That is a module,
and our uapi is, by far, in drivers through ioctl "hell" and that would
be great to be able to document through all of this. Will that just not
be in the debugfs api?
thanks,
greg k-h
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v6 14/14] ixd: add devlink support
From: Loktionov, Aleksandr @ 2026-03-24 7:59 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Singhai, Anjali,
Michal Swiatkowski, Zaremba, Larysa, Fijalkowski, Maciej,
Tantilov, Emil S, Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260323174052.5355-15-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Monday, March 23, 2026 6:41 PM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Singhai, Anjali
> <anjali.singhai@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-next v6 14/14] ixd: add devlink
> support
>
> From: Amritha Nambiar <amritha.nambiar@intel.com>
>
> Enable initial support for the devlink interface with the ixd driver.
> The ixd hardware is a single function PCIe device. So, the PCIe
> adapter gets its own devlink instance to manage device-wide resources
> or configuration.
>
> $ devlink dev show
> pci/0000:83:00.6
>
> $ devlink dev info pci/0000:83:00.6
> pci/0000:83:00.6:
> driver ixd
> serial_number 00-a0-c9-ff-ff-23-45-67
> versions:
> fixed:
> device.type MEV
> running:
> virtchnl 2.0
>
> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
> Reviewed-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Tested-by: Bharath R <Bharath.r@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> Documentation/networking/devlink/index.rst | 1 +
> Documentation/networking/devlink/ixd.rst | 30 ++++++
> drivers/net/ethernet/intel/ixd/Kconfig | 1 +
> drivers/net/ethernet/intel/ixd/Makefile | 1 +
> drivers/net/ethernet/intel/ixd/ixd_devlink.c | 97
> ++++++++++++++++++++ drivers/net/ethernet/intel/ixd/ixd_devlink.h |
> 44 +++++++++
> drivers/net/ethernet/intel/ixd/ixd_main.c | 16 +++-
> 7 files changed, 187 insertions(+), 3 deletions(-) create mode
> 100644 Documentation/networking/devlink/ixd.rst
> create mode 100644 drivers/net/ethernet/intel/ixd/ixd_devlink.c
> create mode 100644 drivers/net/ethernet/intel/ixd/ixd_devlink.h
>
> diff --git a/Documentation/networking/devlink/index.rst
> b/Documentation/networking/devlink/index.rst
> index f7ba7dcf477d..f0c077843fa7 100644
> --- a/Documentation/networking/devlink/index.rst
> +++ b/Documentation/networking/devlink/index.rst
> @@ -88,6 +88,7 @@ parameters, info versions, and other features it
> supports.
> ionic
> iosm
> ixgbe
...
> }
>
> static const struct pci_device_id ixd_pci_tbl[] = {
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v6 13/14] ixd: add the core initialization
From: Loktionov, Aleksandr @ 2026-03-24 7:59 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Singhai, Anjali,
Michal Swiatkowski, Zaremba, Larysa, Fijalkowski, Maciej,
Tantilov, Emil S, Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260323174052.5355-14-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Monday, March 23, 2026 6:41 PM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Singhai, Anjali
> <anjali.singhai@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-next v6 13/14] ixd: add the core
> initialization
>
> As the mailbox is setup, initialize the core. This makes use of the
> send and receive mailbox message framework for virtchnl communication
> between the driver and device Control Plane (CP).
>
> To start with, driver confirms the virtchnl version with the CP. Once
> that is done, it requests and gets the required capabilities and
> resources needed such as max vectors, queues, vports etc.
>
> Use a unified way of handling the virtchnl messages, where a single
> function handles all related memory management and the caller only
> provides the callbacks to fill the send buffer and to handle the
> response.
>
> Place generic control queue message handling separately to facilitate
> the addition of protocols other than virtchannel in the future.
>
> Co-developed-by: Amritha Nambiar <amritha.nambiar@intel.com>
> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Tested-by: Bharath R <Bharath.r@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> drivers/net/ethernet/intel/ixd/Makefile | 2 +
> drivers/net/ethernet/intel/ixd/ixd.h | 10 +
> drivers/net/ethernet/intel/ixd/ixd_ctlq.c | 149 +++++++++++++++
> drivers/net/ethernet/intel/ixd/ixd_ctlq.h | 33 ++++
> drivers/net/ethernet/intel/ixd/ixd_lib.c | 25 ++-
> drivers/net/ethernet/intel/ixd/ixd_main.c | 3 +
> drivers/net/ethernet/intel/ixd/ixd_virtchnl.c | 178
> ++++++++++++++++++ drivers/net/ethernet/intel/ixd/ixd_virtchnl.h |
> 12 ++
> 8 files changed, 411 insertions(+), 1 deletion(-) create mode 100644
> drivers/net/ethernet/intel/ixd/ixd_ctlq.c
> create mode 100644 drivers/net/ethernet/intel/ixd/ixd_ctlq.h
> create mode 100644 drivers/net/ethernet/intel/ixd/ixd_virtchnl.c
> create mode 100644 drivers/net/ethernet/intel/ixd/ixd_virtchnl.h
>
> diff --git a/drivers/net/ethernet/intel/ixd/Makefile
> b/drivers/net/ethernet/intel/ixd/Makefile
> index 164b2c86952f..90abf231fb16 100644
> --- a/drivers/net/ethernet/intel/ixd/Makefile
> +++ b/drivers/net/ethernet/intel/ixd/Makefile
> @@ -6,5 +6,7 @@
> obj-$(CONFIG_IXD) += ixd.o
>
> ixd-y := ixd_main.o
> +ixd-y += ixd_ctlq.o
> ixd-y += ixd_dev.o
> ixd-y += ixd_lib.o
> +ixd-y += ixd_virtchnl.o
> diff --git a/drivers/net/ethernet/intel/ixd/ixd.h
> b/drivers/net/ethernet/intel/ixd/ixd.h
> index 99c44f2aa659..98d1f22534b5 100644
> --- a/drivers/net/ethernet/intel/ixd/ixd.h
> +++ b/drivers/net/ethernet/intel/ixd/ixd.h
> @@ -10,19 +10,29 @@
> * struct ixd_adapter - Data structure representing a CPF
> * @cp_ctx: Control plane communication context
> * @init_task: Delayed initialization after reset
...
> +#endif /* _IXD_VIRTCHNL_H_ */
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v6 11/14] ixd: add basic driver framework for Intel(R) Control Plane Function
From: Loktionov, Aleksandr @ 2026-03-24 7:58 UTC (permalink / raw)
To: Zaremba, Larysa, intel-wired-lan@lists.osuosl.org,
Nguyen, Anthony L
Cc: Lobakin, Aleksander, Samudrala, Sridhar, Singhai, Anjali,
Michal Swiatkowski, Zaremba, Larysa, Fijalkowski, Maciej,
Tantilov, Emil S, Chittim, Madhu, Hay, Joshua A, Keller, Jacob E,
Shanmugam, Jayaprakash, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Richard Cochran, Kitszel, Przemyslaw, Andrew Lunn,
netdev@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260323174052.5355-12-larysa.zaremba@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Larysa Zaremba
> Sent: Monday, March 23, 2026 6:41 PM
> To: intel-wired-lan@lists.osuosl.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>
> Cc: Lobakin, Aleksander <aleksander.lobakin@intel.com>; Samudrala,
> Sridhar <sridhar.samudrala@intel.com>; Singhai, Anjali
> <anjali.singhai@intel.com>; Michal Swiatkowski
> <michal.swiatkowski@linux.intel.com>; Zaremba, Larysa
> <larysa.zaremba@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>; Tantilov, Emil S
> <emil.s.tantilov@intel.com>; Chittim, Madhu <madhu.chittim@intel.com>;
> Hay, Joshua A <joshua.a.hay@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Shanmugam, Jayaprakash
> <jayaprakash.shanmugam@intel.com>; Jiri Pirko <jiri@resnulli.us>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Simon Horman <horms@kernel.org>; Jonathan Corbet
> <corbet@lwn.net>; Richard Cochran <richardcochran@gmail.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; netdev@vger.kernel.org; linux-
> doc@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH iwl-next v6 11/14] ixd: add basic
> driver framework for Intel(R) Control Plane Function
>
> Add module register and probe functionality. Add the required support
> to register IXD PCI driver, as well as probe and remove call backs.
> Enable the PCI device and request the kernel to reserve the memory
> resources that will be used by the driver. Finally map the BAR0
> address space.
>
> For now, use devm_alloc() to allocate adapter, as it requires the
> least amount of code. In a later commit, it will be replaced with a
> devlink alternative.
>
> Co-developed-by: Amritha Nambiar <amritha.nambiar@intel.com>
> Signed-off-by: Amritha Nambiar <amritha.nambiar@intel.com>
> Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> Signed-off-by: Larysa Zaremba <larysa.zaremba@intel.com>
> Tested-by: Bharath R <Bharath.r@intel.com>
> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
> ---
> .../device_drivers/ethernet/index.rst | 1 +
> .../device_drivers/ethernet/intel/ixd.rst | 39 ++++++
> drivers/net/ethernet/intel/Kconfig | 2 +
> drivers/net/ethernet/intel/Makefile | 1 +
> drivers/net/ethernet/intel/ixd/Kconfig | 13 ++
> drivers/net/ethernet/intel/ixd/Makefile | 8 ++
> drivers/net/ethernet/intel/ixd/ixd.h | 28 +++++
> drivers/net/ethernet/intel/ixd/ixd_lan_regs.h | 28 +++++
> drivers/net/ethernet/intel/ixd/ixd_main.c | 112
> ++++++++++++++++++
> 9 files changed, 232 insertions(+)
> create mode 100644
> Documentation/networking/device_drivers/ethernet/intel/ixd.rst
> create mode 100644 drivers/net/ethernet/intel/ixd/Kconfig
> create mode 100644 drivers/net/ethernet/intel/ixd/Makefile
> create mode 100644 drivers/net/ethernet/intel/ixd/ixd.h
> create mode 100644 drivers/net/ethernet/intel/ixd/ixd_lan_regs.h
> create mode 100644 drivers/net/ethernet/intel/ixd/ixd_main.c
>
> diff --git
> a/Documentation/networking/device_drivers/ethernet/index.rst
> b/Documentation/networking/device_drivers/ethernet/index.rst
> index 5f3f06111911..5b6846f387f8 100644
> --- a/Documentation/networking/device_drivers/ethernet/index.rst
> +++ b/Documentation/networking/device_drivers/ethernet/index.rst
> @@ -38,6 +38,7 @@ Contents:
> intel/igbvf
> intel/ixgbe
> intel/ixgbevf
> + intel/ixd
> intel/i40e
> intel/iavf
> intel/ice
> diff --git
> a/Documentation/networking/device_drivers/ethernet/intel/ixd.rst
> b/Documentation/networking/device_drivers/ethernet/intel/ixd.rst
> new file mode 100644
> index 000000000000..1387626e5d20
> --- /dev/null
> +++ b/Documentation/networking/device_drivers/ethernet/intel/ixd.rst
> @@ -0,0 +1,39 @@
...
> +module_pci_driver(ixd_driver);
> --
> 2.47.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ 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