* Re: [PATCH v2] coccinelle: update Coccinelle URL
From: Jonathan Corbet @ 2026-03-22 20:53 UTC (permalink / raw)
To: Julia Lawall
Cc: Shuah Khan, workflows, cocci, Nicolas Palix, Hu Haowen, Alex Shi,
Yanteng Si, Dongliang Mu, linux-doc, linux-kernel, Federico Vaga,
Carlos Bilbao, Avadhut Naik, LIU Haoyang
In-Reply-To: <20260310121431.362091-1-Julia.Lawall@inria.fr>
Julia Lawall <Julia.Lawall@inria.fr> writes:
> The LIP6 URL no longer functions.
>
> Signed-off-by: Julia Lawall <Julia.Lawall@inria.fr>
>
> ---
>
> v2: corrected the character encoding, no other changes
>
> Documentation/dev-tools/coccinelle.rst | 2 +-
> Documentation/translations/it_IT/process/4.Coding.rst | 3 ++-
> Documentation/translations/sp_SP/process/4.Coding.rst | 3 ++-
> Documentation/translations/zh_CN/process/4.Coding.rst | 2 +-
> Documentation/translations/zh_TW/process/4.Coding.rst | 2 +-
> 5 files changed, 7 insertions(+), 5 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v3] docs: path-lookup: fix unrenamed WALK_GET
From: Jonathan Corbet @ 2026-03-22 20:54 UTC (permalink / raw)
To: Daniel Tang, linux-doc, linux-kernel, Fox Chen
Cc: NeilBrown, vegard.nossum, viro, rdunlap, grandmaster
In-Reply-To: <13011949.O9o76ZdvQC@daniel-desktop3>
Daniel Tang <danielzgtg.opensource@gmail.com> writes:
> The symbol WALK_GET does not appears in the codebase as of
> 0031c06807cfa8aa. It was renamed as of 8f64fb1ccef33107. A previous
> documentation update, de9414adafe4, renamed one occurrence in
> path-lookup.rst, but forgot to change another occurrence later in the
> file.
>
> Fixes: de9414adafe4 ("docs: path-lookup: update WALK_GET, WALK_PUT desc")
> Signed-off-by: Daniel Tang <danielzgtg.opensource@gmail.com>
> ---
> Documentation/filesystems/path-lookup.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst
> index 9ced1135608e..6957c70f18db 100644
> --- a/Documentation/filesystems/path-lookup.rst
> +++ b/Documentation/filesystems/path-lookup.rst
> @@ -1364,7 +1364,7 @@ it sets ``LOOKUP_AUTOMOUNT``, as does "``quotactl()``" and the handling of
> symlinks. Some system calls set or clear it implicitly, while
> others have API flags such as ``AT_SYMLINK_FOLLOW`` and
> ``UMOUNT_NOFOLLOW`` to control it. Its effect is similar to
> -``WALK_GET`` that we already met, but it is used in a different way.
> +``WALK_TRAILING`` that we already met, but it is used in a different way.
>
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] tools/docs/checktransupdate.py: fix missing prefix in f-string
From: Jonathan Corbet @ 2026-03-22 20:55 UTC (permalink / raw)
To: LIU Haoyang, Mauro Carvalho Chehab, Shuah Khan, Dongliang Mu,
Yanteng Si
Cc: LIU Haoyang, linux-doc, linux-kernel
In-Reply-To: <20260308104135.9037-1-tttturtleruss@gmail.com>
LIU Haoyang <tttturtleruss@gmail.com> writes:
> Add a f prefix to f-string in checktransupdate.py.
>
> Fixes: 63e96ce050e5 ("scripts: fix all issues reported by pylint")
> Signed-off-by: LIU Haoyang <tttturtleruss@gmail.com>
> ---
> tools/docs/checktransupdate.py | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/docs/checktransupdate.py b/tools/docs/checktransupdate.py
> index e894652369a5..bf735562aeeb 100755
> --- a/tools/docs/checktransupdate.py
> +++ b/tools/docs/checktransupdate.py
> @@ -131,7 +131,7 @@ def check_per_file(file_path):
> opath = get_origin_path(file_path)
>
> if not os.path.isfile(opath):
> - logging.error("Cannot find the origin path for {file_path}")
> + logging.error(f"Cannot find the origin path for {file_path}")
> return
Applied, thanks.
jon
^ permalink raw reply
* Re: Invalid link generation for equations
From: Jonathan Corbet @ 2026-03-22 21:05 UTC (permalink / raw)
To: Kevin Brodsky, linux-doc; +Cc: Shuah Khan
In-Reply-To: <9b320e77-9acf-4f0d-8c52-6e1fc3a8cf53@arm.com>
Kevin Brodsky <kevin.brodsky@arm.com> writes:
> Hi,
>
> I have noticed that links to equation images are not generated correctly
> on docs.kernel.org. For instance, Documentation/mm/memory-model.rst has:
>
> .. math::
>
> NR\_MEM\_SECTIONS = 2 ^ {(MAX\_PHYSMEM\_BITS - SECTION\_SIZE\_BITS)}
>
> The generated HTML [1] shows the source code instead of the rendered
> equation because the link to the image [2] is broken. [3] does however
> exist. The issue seems to be that the link is relative to the root, even
> though we are in a subfolder (mm/ here).
>
> Given my non-existent knowledge of Sphinx I have no idea what the fix
> might be, but I thought I'd report this at least :)
>
> - Kevin
>
> [1] https://docs.kernel.org/mm/memory-model.html#sparsemem
> [2]
> https://docs.kernel.org/mm/_images/math/d99368220bfdedf1a888b1c09eb7236a8c87d079.png
> [3]
> https://docs.kernel.org/_images/math/d99368220bfdedf1a888b1c09eb7236a8c87d079.png
Thanks for the report.
We have all that elaborate machinery for generating fancy formatted
math, it would be best if it works properly. I am curious, though, if
it's truly broken universally and, if so, how long that has been the
case. If it's been that way for some time, one might legitimately
wonder why nobody has noticed thus far.
Anyway, will try to look into it soon.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v3 00/22] kernel-doc: use a C lexical tokenizer for transforms
From: Jonathan Corbet @ 2026-03-22 21:08 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Kees Cook, Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab, linux-doc, linux-hardening, linux-kernel,
Gustavo A. R. Silva, Aleksandr Loktionov, Randy Dunlap,
Shuah Khan, Vincent Mailhol
In-Reply-To: <cover.1773770483.git.mchehab+huawei@kernel.org>
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> Hi Jon,
>
> It follows v3 of the series. I basically addressed there the
> points you mentioned. Besides that, I did a fix at CMatch
> group(0) logic, and opted to create a special token for ";",
> as it simplifies the code a little bit and will likely help to
> simplify future changes.
OK, I have gone ahead and applied this series...it doesn't seem to
explode for me, anyway :) Let's hope for the best...
Thanks,
jon
^ permalink raw reply
* Re: [PATCH 00/14] More kernel-doc patches
From: Jonathan Corbet @ 2026-03-22 21:25 UTC (permalink / raw)
To: Mauro Carvalho Chehab, Mauro Carvalho Chehab
Cc: Mauro Carvalho Chehab, linux-doc, linux-kernel,
Aleksandr Loktionov, Randy Dunlap, Shuah Khan, Sasha Levin
In-Reply-To: <cover.1773823995.git.mchehab+huawei@kernel.org>
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> writes:
> Hi Jon,
>
> This series comes after:
> https://lore.kernel.org/linux-doc/cover.1773770483.git.mchehab+huawei@kernel.org/
>
> It basically contains patches I submitted before on a 40+ patch series,
> but were less relevant, plus a couple of other minor fixes:
>
> - patch 1 improves one of the CTokenizer unit test, fixing some
> potential issues on it;
> - patches 2 and 3 contain some improvement/fixes for Sphinx
> Python autodoc extension. They basically document c_lex.py;
>
> - The remaining patches:
> - create a new class for kernel-doc config;
> - fix some internal representations of KdocItem;
> - add unit tests for KernelDoc() parser class;
> - add support to output KdocItem in YAML, which is a
> machine-readable output for all documented kAPI.
>
> None of the patches should affect man or html output.
OK, I applied this set too.
Thanks,
jon
^ permalink raw reply
* Re: [PATCH v2] docs: use logo.svg as favicon
From: Jonathan Corbet @ 2026-03-22 21:31 UTC (permalink / raw)
To: Rito Rhymes, linux-doc; +Cc: Shuah Khan, linux-kernel, Rito Rhymes
In-Reply-To: <20260321125532.9568-1-rito@ritovision.com>
Rito Rhymes <rito@ritovision.com> writes:
> Use the existing documentation logo as the HTML favicon.
>
> This makes generated documentation pages use a matching browser tab
> icon without introducing a separate favicon asset.
>
> Signed-off-by: Rito Rhymes <rito@ritovision.com>
> ---
> v2: add commit message body and missing Signed-off-by
>
> Documentation/conf.py | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index 679861503..9b822ab47 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -455,6 +455,7 @@ if html_theme == "alabaster":
> # The name of an image file (relative to this directory) to place at the top
> # of the sidebar.
> html_logo = "images/logo.svg"
> +html_favicon = "images/logo.svg"
>
This seems straightforward enough; applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v13 1/1] rust: interop: Add list module for C linked list interface
From: Alejandra González @ 2026-03-23 0:07 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Joel Fernandes, Alice Ryhl, linux-kernel, Miguel Ojeda,
Boqun Feng, Gary Guo, Björn Roy Baron, Benno Lossin,
Andreas Hindborg, Trevor Gross, Alex Gaynor, Danilo Krummrich,
Dave Airlie, David Airlie, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Simona Vetter, Daniel Almeida, Koen Koning,
Nikola Djukic, Alexandre Courbot, Philipp Stanner, Elle Rhumsaa,
Jonathan Corbet, Alex Deucher, Christian König, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Huang Rui,
Matthew Auld, Matthew Brost, Lucas De Marchi,
Thomas Hellström, Helge Deller, John Hubbard,
Alistair Popple, Timur Tabi, Edwin Peer, Andrea Righi,
Andy Ritger, Zhi Wang, Balbir Singh, alexeyi, Eliot Courtney,
dri-devel, rust-for-linux, linux-doc, amd-gfx, intel-gfx,
intel-xe, linux-fbdev
In-Reply-To: <CANiq72nZKx7pw_rZK2mHHvR=TaeGvMRvg5GTHOd58X17oyxieg@mail.gmail.com>
On Wed, Mar 18, 2026 at 7:57 PM Miguel Ojeda
<miguel.ojeda.sandonis@gmail.com> wrote:
>
> On Wed, Mar 18, 2026 at 7:31 PM Joel Fernandes <joelagnelf@nvidia.com> wrote:
> >
> > Anyway, the fix is simple, just need to do // SAFETY*: as Miguel suggests
> > here, instead of // SAFETY:
> > https://lore.kernel.org/all/CANiq72kEnDyUpnWMZmheJytjioeiJUK_C-yQJk77dPid89LExw@mail.gmail.com/
>
> So, to clarify, I suggested it as a temporary thing we could do if we
> want to use that "fake `unsafe` block in macro matcher" pattern more
> and more.
>
> i.e. if we plan to use the pattern more, then I am happy to ask
> upstream if it would make sense for Clippy to recognize it (or perhaps
> it is just a false negative instead of a false positive, given
> `impl_device_context_deref`), so that we don't need a hacked safety
> tag (Cc'ing Alejandra).
The team is a bit hesitant on adding comment-specific syntax apart
from the widely used (and already on clippy) `// SAFETY` comments.
I'm pushing for some more comments specific to the Rust4Linux project,
because we already tailor some lints for specific projects (such as the
Safety Critical Rust Consortium), but adding more than new types of
comments is a bit much.
On this specific lint emission, I'll see if I can get it fixed,
because it's a false
positive.
Cheers,
Alejandra.
^ permalink raw reply
* Re: [PATCH 0/5] docs: watchdog: general cleaning and corrections
From: Randy Dunlap @ 2026-03-23 0:54 UTC (permalink / raw)
To: Jonathan Corbet, linux-kernel
Cc: Shuah Khan, Wim Van Sebroeck, Guenter Roeck, linux-watchdog,
linux-doc
In-Reply-To: <875x7cddye.fsf@trenco.lwn.net>
On 3/3/26 9:23 AM, Jonathan Corbet wrote:
> Randy Dunlap <rdunlap@infradead.org> writes:
>
>> Fix some obvious issues in the watchdog documentation files.
>> I didn't try to fix every little niggling mistake.
>>
>> [PATCH 1/5] docs: watchdog: mlx-wdt: small fixes
>> [PATCH 2/5] docs: watchdog: pcwd: fix typo and driver info.
>> [PATCH 3/5] docs: watchdog-api: general cleaning
>> [PATCH 4/5] docs: watchdog-kernel-api: general cleanups
>> [PATCH 5/5] docs: watchdog-parameters: add missing watchdog_core parameters
>>
>> Documentation/watchdog/mlx-wdt.rst | 4 -
>> Documentation/watchdog/pcwd-watchdog.rst | 19 +++++--
>> Documentation/watchdog/watchdog-api.rst | 38 +++++++--------
>> Documentation/watchdog/watchdog-kernel-api.rst | 20 +++++--
>> Documentation/watchdog/watchdog-parameters.rst | 11 +++-
>> 5 files changed, 58 insertions(+), 34 deletions(-)
>
> Wim, do you want to pick these up, or should I take them through the
> docs tree?
Wim, are you active? Can you reply and/or merge these?
thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH v2 09/10] gpu: nova-core: remove `io::` qualifier to register macro invocations
From: Eliot Courtney @ 2026-03-23 1:40 UTC (permalink / raw)
To: Alexandre Courbot, Danilo Krummrich, Alice Ryhl, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross
Cc: John Hubbard, Alistair Popple, Joel Fernandes, Timur Tabi,
Zhi Wang, Eliot Courtney, dri-devel, linux-kernel, linux-riscv,
linux-doc, rust-for-linux
In-Reply-To: <20260320-b4-nova-register-v2-9-88fcf103e8d4@nvidia.com>
On Fri Mar 20, 2026 at 9:19 PM JST, Alexandre Courbot wrote:
> The kernel's `register` macro would clash with nova-core's own version
> if it was imported directly, so it was accessed through its `io` module
> during the conversion phase.
>
> Now that nova-core's `register` macro doesn't exist anymore, we can
> import and use it directly without risk of name collision.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
^ permalink raw reply
* Re: [PATCH v2 01/10] gpu: nova-core: convert PMC registers to kernel register macro
From: Eliot Courtney @ 2026-03-23 1:41 UTC (permalink / raw)
To: Alexandre Courbot, Danilo Krummrich, Alice Ryhl, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg,
Trevor Gross
Cc: John Hubbard, Alistair Popple, Joel Fernandes, Timur Tabi,
Zhi Wang, Eliot Courtney, dri-devel, linux-kernel, linux-riscv,
linux-doc, rust-for-linux
In-Reply-To: <20260320-b4-nova-register-v2-1-88fcf103e8d4@nvidia.com>
On Fri Mar 20, 2026 at 9:19 PM JST, Alexandre Courbot wrote:
> Convert all PMC registers to use the kernel's register macro and update
> the code accordingly.
>
> nova-core's registers have some constant properties (like a 32-bit size
> and a crate visibility), so introduce the `nv_reg` macro to shorten
> their declaration.
>
> Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
Modulo updating the commit message,
Reviewed-by: Eliot Courtney <ecourtney@nvidia.com>
^ permalink raw reply
* Re: [PATCH v8 0/5] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-03-23 1:44 UTC (permalink / raw)
To: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, akpm, bhe, vgoyal, dyoung,
rdunlap, pmladek, dapeng1.mi, kees, paulmck, lirongqing, fvdl,
rppt, ardb, leitao, sourabhjain, jbohac, cfsworks, osandov,
tangyouling, ritesh.list, hbathini, eajames, songshuaishuai,
kevin.brodsky, samuel.holland, vishal.moola, junhui.liu, coxu,
liaoyuanhong, fuqiang.wang, brgerst, x86, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv,
devicetree, kexec
In-Reply-To: <20260302035315.3892241-1-ruanjinjie@huawei.com>
If there are no other review comments, I'd like to ask if this is ready
to be merged.
On 2026/3/2 11:53, Jinjie Ruan wrote:
> The crash memory allocation, and the exclude of crashk_res, crashk_low_res
> and crashk_cma memory are almost identical across different architectures,
> This patch set handle them in crash core in a general way, which eliminate
> a lot of duplication code.
>
> And add support for crashkernel CMA reservation for arm64 and riscv.
>
> Rebased on v7.0-rc1.
>
> Basic second kernel boot test were performed on QEMU platforms for x86,
> ARM64, and RISC-V architectures with the following parameters:
>
> "cma=256M crashkernel=256M crashkernel=64M,cma"
>
> Changes in v8:
> - Fix the build issues reported by kernel test robot and Sourabh.
> - Link to v7: https://lore.kernel.org/all/20260226130437.1867658-1-ruanjinjie@huawei.com/
>
> Changes in v7:
> - Correct the inclusion of CMA-reserved ranges for kdump kernel in of/kexec
> for arm64 and riscv.
> - Add Acked-by.
> - Link to v6: https://lore.kernel.org/all/20260224085342.387996-1-ruanjinjie@huawei.com/
>
> Changes in v6:
> - Update the crash core exclude code as Mike suggested.
> - Rebased on v7.0-rc1.
> - Add acked-by.
> - Link to v5: https://lore.kernel.org/all/20260212101001.343158-1-ruanjinjie@huawei.com/
>
> Changes in v5:
> - Fix the kernel test robot build warnings.
> - Sort crash memory ranges before preparing elfcorehdr for powerpc
> - Link to v4: https://lore.kernel.org/all/20260209095931.2813152-1-ruanjinjie@huawei.com/
>
> Changes in v4:
> - Move the size calculation (and the realloc if needed) into the
> generic crash.
> - Link to v3: https://lore.kernel.org/all/20260204093728.1447527-1-ruanjinjie@huawei.com/
>
> Jinjie Ruan (4):
> crash: Exclude crash kernel memory in crash core
> crash: Use crash_exclude_core_ranges() on powerpc
> arm64: kexec: Add support for crashkernel CMA reservation
> riscv: kexec: Add support for crashkernel CMA reservation
>
> Sourabh Jain (1):
> powerpc/crash: sort crash memory ranges before preparing elfcorehdr
>
> .../admin-guide/kernel-parameters.txt | 16 +--
> arch/arm64/kernel/machine_kexec_file.c | 39 +++----
> arch/arm64/mm/init.c | 5 +-
> arch/loongarch/kernel/machine_kexec_file.c | 39 +++----
> arch/powerpc/include/asm/kexec_ranges.h | 1 -
> arch/powerpc/kexec/crash.c | 5 +-
> arch/powerpc/kexec/ranges.c | 101 +-----------------
> arch/riscv/kernel/machine_kexec_file.c | 38 +++----
> arch/riscv/mm/init.c | 5 +-
> arch/x86/kernel/crash.c | 89 +++------------
> drivers/of/fdt.c | 9 +-
> drivers/of/kexec.c | 9 ++
> include/linux/crash_core.h | 9 ++
> kernel/crash_core.c | 89 ++++++++++++++-
> 14 files changed, 178 insertions(+), 276 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v8 0/5] arm64/riscv: Add support for crashkernel CMA reservation
From: Andrew Morton @ 2026-03-23 1:58 UTC (permalink / raw)
To: Jinjie Ruan
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, bhe, vgoyal, dyoung, rdunlap,
pmladek, dapeng1.mi, kees, paulmck, lirongqing, fvdl, rppt, ardb,
leitao, sourabhjain, jbohac, cfsworks, osandov, tangyouling,
ritesh.list, hbathini, eajames, songshuaishuai, kevin.brodsky,
samuel.holland, vishal.moola, junhui.liu, coxu, liaoyuanhong,
fuqiang.wang, brgerst, x86, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv,
devicetree, kexec
In-Reply-To: <ce99a024-f910-cd83-c60a-28e60db318d3@huawei.com>
On Mon, 23 Mar 2026 09:44:21 +0800 Jinjie Ruan <ruanjinjie@huawei.com> wrote:
> If there are no other review comments, I'd like to ask if this is ready
> to be merged.
This patchset predates the introduction of the Sashiko AI review, and
that thing is proving very good at finding issues.
So can you please update the changelog footers for thus-far-received
acks/reviews and then resend?
Thanks.
^ permalink raw reply
* Re: [PATCH v8 0/5] arm64/riscv: Add support for crashkernel CMA reservation
From: Jinjie Ruan @ 2026-03-23 2:15 UTC (permalink / raw)
To: Andrew Morton
Cc: corbet, skhan, catalin.marinas, will, chenhuacai, kernel, maddy,
mpe, npiggin, chleroy, pjw, palmer, aou, alex, tglx, mingo, bp,
dave.hansen, hpa, robh, saravanak, bhe, vgoyal, dyoung, rdunlap,
pmladek, dapeng1.mi, kees, paulmck, lirongqing, fvdl, rppt, ardb,
leitao, sourabhjain, jbohac, cfsworks, osandov, tangyouling,
ritesh.list, hbathini, eajames, songshuaishuai, kevin.brodsky,
samuel.holland, vishal.moola, junhui.liu, coxu, liaoyuanhong,
fuqiang.wang, brgerst, x86, linux-doc, linux-kernel,
linux-arm-kernel, loongarch, linuxppc-dev, linux-riscv,
devicetree, kexec
In-Reply-To: <20260322185853.e8e43c346ed98a0ef0544948@linux-foundation.org>
On 2026/3/23 9:58, Andrew Morton wrote:
> On Mon, 23 Mar 2026 09:44:21 +0800 Jinjie Ruan <ruanjinjie@huawei.com> wrote:
>
>> If there are no other review comments, I'd like to ask if this is ready
>> to be merged.
>
> This patchset predates the introduction of the Sashiko AI review, and
> that thing is proving very good at finding issues.
That would be good to use this tool to find the low-level issues.
>
> So can you please update the changelog footers for thus-far-received
> acks/reviews and then resend?
Sure.
>
> Thanks.
>
>
>
^ permalink raw reply
* [PATCH v3 0/2] hwmon/pmbus: isl68137: Add RAA228942/RAA228943 support
From: Dawei Liu @ 2026-03-23 3:20 UTC (permalink / raw)
To: linux
Cc: linux-hwmon, linux-kernel, linux-doc, devicetree,
linux-renesas-soc, robh, krzk+dt, conor+dt, corbet, skhan,
geert+renesas, magnus.damm, grant.peltier.jg, linda.xin.jg,
Dawei Liu
Add support for Renesas RAA228942 and RAA228943 digital
dual-output 16-phase PWM controllers.
Changes in v3:
- Update commit message to clarify hardware differences
(suggested by Krzysztof Kozlowski)
- Drop enum cleanup patch as it has been merged
Changes in v2:
- Remove entire unused enum chips
(suggested by Guenter Roeck)
- Improve commit message to clarify hardware difference
- Split enum chips cleanup into separate patch
Dawei Liu (2):
hwmon: (pmbus/isl68137) Add support for Renesas RAA228942 and
RAA228943
dt-bindings: hwmon: isl68137: Add compatible strings for RAA228942 and
RAA228943
.../bindings/hwmon/pmbus/isil,isl68137.yaml | 2 ++
Documentation/hwmon/isl68137.rst | 20 +++++++++++++++++++
drivers/hwmon/pmbus/isl68137.c | 4 ++++
3 files changed, 26 insertions(+)
--
2.34.1
^ permalink raw reply
* [PATCH 1/2] hwmon: (pmbus/isl68137) Add support for Renesas RAA228942 and RAA228943
From: Dawei Liu @ 2026-03-23 3:20 UTC (permalink / raw)
To: linux
Cc: linux-hwmon, linux-kernel, linux-doc, devicetree,
linux-renesas-soc, robh, krzk+dt, conor+dt, corbet, skhan,
geert+renesas, magnus.damm, grant.peltier.jg, linda.xin.jg,
Dawei Liu
In-Reply-To: <20260323032057.953-1-dawei.liu.jy@renesas.com>
RAA228942 and RAA228943 are Renesas digital dual-output
16-phase (X+Y <= 16) PWM controllers with 2-rail non-TC
driver configuration. They have different hardware
interfaces and feature sets compared to existing
family members.
Signed-off-by: Dawei Liu <dawei.liu.jy@renesas.com>
---
Documentation/hwmon/isl68137.rst | 20 ++++++++++++++++++++
drivers/hwmon/pmbus/isl68137.c | 4 ++++
2 files changed, 24 insertions(+)
diff --git a/Documentation/hwmon/isl68137.rst b/Documentation/hwmon/isl68137.rst
index e77f582c2..0ce20d091 100644
--- a/Documentation/hwmon/isl68137.rst
+++ b/Documentation/hwmon/isl68137.rst
@@ -394,6 +394,26 @@ Supported chips:
Provided by Renesas upon request and NDA
+ * Renesas RAA228942
+
+ Prefix: 'raa228942'
+
+ Addresses scanned: -
+
+ Datasheet:
+
+ Provided by Renesas upon request and NDA
+
+ * Renesas RAA228943
+
+ Prefix: 'raa228943'
+
+ Addresses scanned: -
+
+ Datasheet:
+
+ Provided by Renesas upon request and NDA
+
* Renesas RAA229001
Prefix: 'raa229001'
diff --git a/drivers/hwmon/pmbus/isl68137.c b/drivers/hwmon/pmbus/isl68137.c
index 3346afdf3..e9bb24a2a 100644
--- a/drivers/hwmon/pmbus/isl68137.c
+++ b/drivers/hwmon/pmbus/isl68137.c
@@ -432,6 +432,8 @@ static const struct i2c_device_id raa_dmpvr_id[] = {
{"raa228228", raa_dmpvr2_2rail_nontc},
{"raa228244", raa_dmpvr2_2rail_nontc},
{"raa228246", raa_dmpvr2_2rail_nontc},
+ {"raa228942", raa_dmpvr2_2rail_nontc},
+ {"raa228943", raa_dmpvr2_2rail_nontc},
{"raa229001", raa_dmpvr2_2rail},
{"raa229004", raa_dmpvr2_2rail},
{"raa229141", raa_dmpvr2_2rail_pmbus},
@@ -483,6 +485,8 @@ static const struct of_device_id isl68137_of_match[] = {
{ .compatible = "renesas,raa228228", .data = (void *)raa_dmpvr2_2rail_nontc },
{ .compatible = "renesas,raa228244", .data = (void *)raa_dmpvr2_2rail_nontc },
{ .compatible = "renesas,raa228246", .data = (void *)raa_dmpvr2_2rail_nontc },
+ { .compatible = "renesas,raa228942", .data = (void *)raa_dmpvr2_2rail_nontc },
+ { .compatible = "renesas,raa228943", .data = (void *)raa_dmpvr2_2rail_nontc },
{ .compatible = "renesas,raa229001", .data = (void *)raa_dmpvr2_2rail },
{ .compatible = "renesas,raa229004", .data = (void *)raa_dmpvr2_2rail },
{ .compatible = "renesas,raa229621", .data = (void *)raa_dmpvr2_2rail },
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] dt-bindings: hwmon: isl68137: Add compatible strings for RAA228942 and RAA228943
From: Dawei Liu @ 2026-03-23 3:20 UTC (permalink / raw)
To: linux
Cc: linux-hwmon, linux-kernel, linux-doc, devicetree,
linux-renesas-soc, robh, krzk+dt, conor+dt, corbet, skhan,
geert+renesas, magnus.damm, grant.peltier.jg, linda.xin.jg,
Dawei Liu
In-Reply-To: <20260323032057.953-1-dawei.liu.jy@renesas.com>
RAA228942 and RAA228943 are Renesas digital dual-output
16-phase (X+Y <= 16) PWM controllers with 2-rail non-TC
driver configuration. They have different hardware
interfaces and feature sets compared to existing
family members.
Signed-off-by: Dawei Liu <dawei.liu.jy@renesas.com>
---
.../devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml
index ae23a0537..53d07c0ce 100644
--- a/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml
+++ b/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml
@@ -56,6 +56,8 @@ properties:
- renesas,raa228228
- renesas,raa228244
- renesas,raa228246
+ - renesas,raa228942
+ - renesas,raa228943
- renesas,raa229001
- renesas,raa229004
- renesas,raa229621
--
2.34.1
^ permalink raw reply related
* RE: [PATCH v4 18/21] drivers: hv: vmbus: replace deprecated mmap hook with mmap_prepare
From: Michael Kelley @ 2026-03-23 4:16 UTC (permalink / raw)
To: Long Li, Lorenzo Stoakes (Oracle), Andrew Morton
Cc: Jonathan Corbet, Clemens Ladisch, Arnd Bergmann,
Greg Kroah-Hartman, K . Y . Srinivasan, Haiyang Zhang, Wei Liu,
Dexuan Cui, 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, Vlastimil Babka, Mike Rapoport,
Suren Baghdasaryan, Michal Hocko, Jann Horn, Pedro Falcato,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-hyperv@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-mtd@lists.infradead.org, linux-staging@lists.linux.dev,
linux-scsi@vger.kernel.org, target-devel@vger.kernel.org,
linux-afs@lists.infradead.org, linux-fsdevel@vger.kernel.org,
linux-mm@kvack.org, Ryan Roberts
In-Reply-To: <05467cb62267d750e5c770147517d4df0246cda6.1774045440.git.ljs@kernel.org>
From: Lorenzo Stoakes (Oracle) <ljs@kernel.org> Sent: Friday, March 20, 2026 3:40 PM
>
> The f_op->mmap interface is deprecated, so update the vmbus driver to use
> its successor, mmap_prepare.
>
> This updates all callbacks which referenced the function pointer
> hv_mmap_ring_buffer to instead reference hv_mmap_prepare_ring_buffer,
> utilising the newly introduced compat_set_desc_from_vma() and
> __compat_vma_mmap() to be able to implement this change.
>
> The UIO HV generic driver is the only user of hv_create_ring_sysfs(),
> which is the only function which references
> vmbus_channel->mmap_prepare_ring_buffer which, in turn, is the only
> external interface to hv_mmap_prepare_ring_buffer.
>
> This patch therefore updates this caller to use mmap_prepare instead,
> which also previously used vm_iomap_memory(), so this change replaces it
> with its mmap_prepare equivalent, mmap_action_simple_ioremap().
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
> ---
> drivers/hv/hyperv_vmbus.h | 4 ++--
> drivers/hv/vmbus_drv.c | 31 +++++++++++++++++++------------
> drivers/uio/uio_hv_generic.c | 11 ++++++-----
> include/linux/hyperv.h | 4 ++--
> 4 files changed, 29 insertions(+), 21 deletions(-)
>
There are two mmap() code paths in the Hyper-V UIO code. One path is
to mmap() the file descriptor for /dev/uio<n>, and the other is to mmap()
the "ring" entry under /sys/devices/vmbus/devices/<uuid>. The former is
done by uio_mmap(), and the latter by hv_uio_ring_mmap_prepare().
I tested both these paths using a combination of two methods in a
x86/x64 VM on Hyper-V:
1) Using the fcopy daemon, which maps the ring buffer for the primary
channel and sends/receives messages with the Hyper-V host. This
method tests only the 1st path because the fcopy daemon doesn't create
any subchannels that would use the "ring" entry.
2) Using a custom-built test program. This program doesn't communicate
with the Hyper-V host, but allows mostly verifying both code paths for the
primary channel. As a sanity check, it verifies that the two mmaps are
mapping the same memory, as expected.
As such,
Reviewed-by: Michael Kelley <mhklinux@outlook.com>
Tested-by: Michael Kelley <mhklinux@outlook.com>
The most robust test would be to run DPDK networking against
UIO, as it would communicate with the Hyper-V host and use
multiple subchannels that resulting in mmap'ing the "ring"
entry under /sys.
@Long Li -- I'll leave it to your discretion as to whether you want
to test DPDK against these mmap() changes.
I've noted one minor issue below.
[snip]
--- a/include/linux/hyperv.h
+++ b/include/linux/hyperv.h
@@ -1015,8 +1015,8 @@ struct vmbus_channel {
/* The max size of a packet on this channel */
u32 max_pkt_size;
- /* function to mmap ring buffer memory to the channel's sysfs ring attribute */
- int (*mmap_ring_buffer)(struct vmbus_channel *channel, struct vm_area_struct *vma);
+ /* function to mmap_prepare ring buffer memory to the channel's sysfs ring attribute */
Changing the comment from "mmap ring buffer" to "mmap_prepare ring buffer"
produces awkward wording since "mmap" is used here as a verb. It might be better
to just leave the comment unchanged.
Michael
+ int (*mmap_prepare_ring_buffer)(struct vmbus_channel *channel, struct vm_area_desc *desc);
/* boolean to control visibility of sysfs for ring buffer */
bool ring_sysfs_visible;
^ permalink raw reply
* RE: [PATCH v2 3/3] dt-bindings: hwmon: isl68137: Add compatible strings for RAA228942 and RAA228943
From: Dawei Liu @ 2026-03-23 4:22 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux@roeck-us.net, linux-hwmon@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
robh@kernel.org, krzk+dt@kernel.org, conor+dt@kernel.org,
corbet@lwn.net, skhan@linuxfoundation.org,
geert+renesas@glider.be, magnus.damm, Grant Peltier, Linda Xin,
tabreztalks@gmail.com
In-Reply-To: <177412601062.18368.450072825684601974.b4-reply@b4>
> If they are compatible, maybe finally this binding should switch to representing this with fallback?
These chips have different hardware interfaces and
feature sets compared to existing family members,
requiring separate compatible strings for correct
hardware identification.
I have sent v3 with an updated commit message to
better reflect this.
Best regards,
Dawei Liu
^ permalink raw reply
* Re: [PATCH v6 01/40] arm_mpam: Ensure in_reset_state is false after applying configuration
From: Gavin Shan @ 2026-03-23 4:37 UTC (permalink / raw)
To: Ben Horgan
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: <20260313144617.3420416-2-ben.horgan@arm.com>
On 3/14/26 12:45 AM, Ben Horgan wrote:
> From: Zeng Heng <zengheng4@huawei.com>
>
> The per-RIS flag, in_reset_state, indicates whether or not the MSC
> registers are in reset state, and allows avoiding resetting when they are
> already in reset state. However, when mpam_apply_config() updates the
> configuration it doesn't update the in_reset_state flag and so even after
> the configuration update in_reset_state can be true and mpam_reset_ris()
> will skip the actual register restoration on subsequent resets.
>
> Once resctrl has a MPAM backend it will use resctrl_arch_reset_all_ctrls()
> to reset the MSC configuration on unmount and, if the in_reset_state flag
> is bogusly true, fail to reset the MSC configuration. The resulting
> non-reset MSC configuration can lead to persistent performance restrictions
> even after resctrl is unmounted.
>
> Fix by clearing in_reset_state to false immediately after successful
> configuration application, ensuring that the next reset operation
> properly restores MSC register defaults.
>
> Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")
> Signed-off-by: Zeng Heng <zengheng4@huawei.com>
> Acked-by: Ben Horgan <ben.horgan@arm.com>
> [Horgan: rewrite commit message to not be specific to resctrl unmount]
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> Subject was originally:
> arm_mpam: Fix MPAM reset on resctrl unmount by clearing in_reset_state
> ---
> drivers/resctrl/mpam_devices.c | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* Re: [PATCH v6 00/40] arm_mpam: Add KVM/arm64 and resctrl glue code
From: Gavin Shan @ 2026-03-23 4:41 UTC (permalink / raw)
To: Ben Horgan
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: <20260313144617.3420416-1-ben.horgan@arm.com>
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,
Gavin
^ permalink raw reply
* Re: [PATCH v6 02/40] arm_mpam: Reset when feature configuration bit unset
From: Gavin Shan @ 2026-03-23 4:44 UTC (permalink / raw)
To: Ben Horgan
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: <20260313144617.3420416-3-ben.horgan@arm.com>
On 3/14/26 12:45 AM, Ben Horgan wrote:
> To indicate that the configuration, of the controls used by resctrl, in a
> RIS need resetting to driver defaults the reset flags in mpam_config are
> set. However, these flags are only ever set temporarily at RIS scope in
> mpam_reset_ris() and hence mpam_cpu_online() will never reset these
> controls to default. As the hardware reset is unknown this leads to unknown
> configuration when the control values haven't been configured away from the
> defaults.
>
> Use the policy that an unset feature configuration bit means reset. In this
> way the mpam_config in the component can encode that it should be in reset
> state and mpam_reprogram_msc() will reset controls as needed.
>
> Fixes: 09b89d2a72f3 ("arm_mpam: Allow configuration to be applied and restored during cpu online")
> Signed-off-by: Ben Horgan <ben.horgan@arm.com>
> ---
> This goes back to the initial feature configuration policy that James
> used in the MPAM base driver rfc but I unfortunately
> suggested him to change it.
> ---
> drivers/resctrl/mpam_devices.c | 40 ++++++++++------------------------
> 1 file changed, 12 insertions(+), 28 deletions(-)
>
Reviewed-by: Gavin Shan <gshan@redhat.com>
^ permalink raw reply
* [PATCH v3 0/2] hwmon: Add support for MPS mp2985
From: wenswang @ 2026-03-23 6:19 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, linux, skhan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Wensheng Wang
From: Wensheng Wang <wenswang@yeah.net>
Add mp2985 driver in hwmon and add dt-bindings for it.
V2 -> V3:
1. The shifted mantissa be clamped to the range [-1024, 1023]
before being masked in mp2985_linear_exp_transfer() function.
2. The PMBUS_VOUT_OV_FAULT_LIMIT and PMBUS_VOUT_UV_FAULT_LIMIT
value are clamped to 0xFFF before being written to the mp2985.
3. Fix the vout scale issue for vout linear11 mode.
v1 -> v2:
1. add Krzysztof's Acked-by
2. remove duplicate entry in mp2985.rst
3. clamp vout value to 32767
4. simplify the code for obtaining PMBUS_VOUT_MODE bit value
5. add comment for explaining MP2985 supported vout mode
6. switch back to previous page after obtaining vid scale to avoid
confusing the PMBus core
Wensheng Wang (2):
dt-bindings: hwmon: Add MPS mp2985
hwmon: add MP2985 driver
.../devicetree/bindings/trivial-devices.yaml | 2 +
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/mp2985.rst | 147 +++++++
MAINTAINERS | 7 +
drivers/hwmon/pmbus/Kconfig | 9 +
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/mp2985.c | 379 ++++++++++++++++++
7 files changed, 546 insertions(+)
create mode 100644 Documentation/hwmon/mp2985.rst
create mode 100644 drivers/hwmon/pmbus/mp2985.c
--
2.25.1
^ permalink raw reply
* [PATCH v3 1/2] dt-bindings: hwmon: Add MPS mp2985
From: wenswang @ 2026-03-23 6:21 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, linux, skhan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Wensheng Wang,
Krzysztof Kozlowski
In-Reply-To: <20260323061901.827025-1-wenswang@yeah.net>
From: Wensheng Wang <wenswang@yeah.net>
Add support for MPS mp2985 controller.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Wensheng Wang <wenswang@yeah.net>
---
v1 -> v2:
1. add Krzysztof's Acked-by
Documentation/devicetree/bindings/trivial-devices.yaml | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml
index a482aeadcd44..d61482269352 100644
--- a/Documentation/devicetree/bindings/trivial-devices.yaml
+++ b/Documentation/devicetree/bindings/trivial-devices.yaml
@@ -325,6 +325,8 @@ properties:
- mps,mp29612
# Monolithic Power Systems Inc. multi-phase controller mp29816
- mps,mp29816
+ # Monolithic Power Systems Inc. multi-phase controller mp2985
+ - mps,mp2985
# Monolithic Power Systems Inc. multi-phase controller mp2993
- mps,mp2993
# Monolithic Power Systems Inc. hot-swap protection device
--
2.25.1
^ permalink raw reply related
* [PATCH v3 2/2] hwmon: add MP2985 driver
From: wenswang @ 2026-03-23 6:21 UTC (permalink / raw)
To: robh, krzk+dt, conor+dt, linux, skhan
Cc: devicetree, linux-kernel, linux-hwmon, linux-doc, Wensheng Wang
In-Reply-To: <20260323062104.827263-1-wenswang@yeah.net>
From: Wensheng Wang <wenswang@yeah.net>
Add support for MPS mp2985 controller. This driver exposes
telemetry and limit value readings and writtings.
Signed-off-by: Wensheng Wang <wenswang@yeah.net>
---
V2 -> V3:
1. The shifted mantissa be clamped to the range [-1024, 1023]
before being masked in mp2985_linear_exp_transfer() function.
2. The PMBUS_VOUT_OV_FAULT_LIMIT and PMBUS_VOUT_UV_FAULT_LIMIT
value are clamped to 0xFFF before being written to the mp2985.
3. Fix the vout scale issue for vout linear11 mode.
v1 -> v2:
1. remove duplicate entry in mp2985.rst
2. clamp vout value to 32767
3. simplify the code for obtaining PMBUS_VOUT_MODE bit value
4. add comment for explaining MP2985 supported vout mode
5. switch back to previous page after obtaining vid scale to avoid
confusing the PMBus core
Documentation/hwmon/index.rst | 1 +
Documentation/hwmon/mp2985.rst | 147 +++++++++++++
MAINTAINERS | 7 +
drivers/hwmon/pmbus/Kconfig | 9 +
drivers/hwmon/pmbus/Makefile | 1 +
drivers/hwmon/pmbus/mp2985.c | 379 +++++++++++++++++++++++++++++++++
6 files changed, 544 insertions(+)
create mode 100644 Documentation/hwmon/mp2985.rst
create mode 100644 drivers/hwmon/pmbus/mp2985.c
diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst
index b2ca8513cfcd..1b7007f41b39 100644
--- a/Documentation/hwmon/index.rst
+++ b/Documentation/hwmon/index.rst
@@ -183,6 +183,7 @@ Hardware Monitoring Kernel Drivers
mp2925
mp29502
mp2975
+ mp2985
mp2993
mp5023
mp5920
diff --git a/Documentation/hwmon/mp2985.rst b/Documentation/hwmon/mp2985.rst
new file mode 100644
index 000000000000..87a39c8a300c
--- /dev/null
+++ b/Documentation/hwmon/mp2985.rst
@@ -0,0 +1,147 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+Kernel driver mp2985
+====================
+
+Supported chips:
+
+ * MPS mp2985
+
+ Prefix: 'mp2985'
+
+Author:
+
+ Wensheng Wang <wenswang@yeah.net>
+
+Description
+-----------
+
+This driver implements support for Monolithic Power Systems, Inc. (MPS)
+MP2985 Dual Loop Digital Multi-phase Controller.
+
+Device compliant with:
+
+- PMBus rev 1.3 interface.
+
+The driver exports the following attributes via the 'sysfs' files
+for input voltage:
+
+**in1_input**
+
+**in1_label**
+
+**in1_crit**
+
+**in1_crit_alarm**
+
+**in1_lcrit**
+
+**in1_lcrit_alarm**
+
+**in1_max**
+
+**in1_max_alarm**
+
+**in1_min**
+
+**in1_min_alarm**
+
+The driver provides the following attributes for output voltage:
+
+**in2_input**
+
+**in2_label**
+
+**in2_crit**
+
+**in2_crit_alarm**
+
+**in2_lcrit**
+
+**in2_lcrit_alarm**
+
+**in3_input**
+
+**in3_label**
+
+**in3_crit**
+
+**in3_crit_alarm**
+
+**in3_lcrit**
+
+**in3_lcrit_alarm**
+
+The driver provides the following attributes for input current:
+
+**curr1_input**
+
+**curr1_label**
+
+The driver provides the following attributes for output current:
+
+**curr2_input**
+
+**curr2_label**
+
+**curr2_crit**
+
+**curr2_crit_alarm**
+
+**curr2_max**
+
+**curr2_max_alarm**
+
+**curr3_input**
+
+**curr3_label**
+
+**curr3_crit**
+
+**curr3_crit_alarm**
+
+**curr3_max**
+
+**curr3_max_alarm**
+
+The driver provides the following attributes for input power:
+
+**power1_input**
+
+**power1_label**
+
+**power2_input**
+
+**power2_label**
+
+The driver provides the following attributes for output power:
+
+**power3_input**
+
+**power3_label**
+
+**power4_input**
+
+**power4_label**
+
+The driver provides the following attributes for temperature:
+
+**temp1_input**
+
+**temp1_crit**
+
+**temp1_crit_alarm**
+
+**temp1_max**
+
+**temp1_max_alarm**
+
+**temp2_input**
+
+**temp2_crit**
+
+**temp2_crit_alarm**
+
+**temp2_max**
+
+**temp2_max_alarm**
diff --git a/MAINTAINERS b/MAINTAINERS
index 7d10988cbc62..24da1f3540ed 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -17922,6 +17922,13 @@ S: Maintained
F: Documentation/hwmon/mp29502.rst
F: drivers/hwmon/pmbus/mp29502.c
+MPS MP2985 DRIVER
+M: Wensheng Wang <wenswang@yeah.net>
+L: linux-hwmon@vger.kernel.org
+S: Maintained
+F: Documentation/hwmon/mp2985.rst
+F: drivers/hwmon/pmbus/mp2985.c
+
MPS MP2993 DRIVER
M: Noah Wang <noahwang.wang@outlook.com>
L: linux-hwmon@vger.kernel.org
diff --git a/drivers/hwmon/pmbus/Kconfig b/drivers/hwmon/pmbus/Kconfig
index fc1273abe357..83fe5866c083 100644
--- a/drivers/hwmon/pmbus/Kconfig
+++ b/drivers/hwmon/pmbus/Kconfig
@@ -447,6 +447,15 @@ config SENSORS_MP2975
This driver can also be built as a module. If so, the module will
be called mp2975.
+config SENSORS_MP2985
+ tristate "MPS MP2985"
+ help
+ If you say yes here you get hardware monitoring support for MPS
+ MP2985 Dual Loop Digital Multi-Phase Controller.
+
+ This driver can also be built as a module. If so, the module will
+ be called mp2985.
+
config SENSORS_MP2993
tristate "MPS MP2993"
help
diff --git a/drivers/hwmon/pmbus/Makefile b/drivers/hwmon/pmbus/Makefile
index d6c86924f887..24505bbee2b0 100644
--- a/drivers/hwmon/pmbus/Makefile
+++ b/drivers/hwmon/pmbus/Makefile
@@ -45,6 +45,7 @@ obj-$(CONFIG_SENSORS_MP2891) += mp2891.o
obj-$(CONFIG_SENSORS_MP2925) += mp2925.o
obj-$(CONFIG_SENSORS_MP29502) += mp29502.o
obj-$(CONFIG_SENSORS_MP2975) += mp2975.o
+obj-$(CONFIG_SENSORS_MP2985) += mp2985.o
obj-$(CONFIG_SENSORS_MP2993) += mp2993.o
obj-$(CONFIG_SENSORS_MP5023) += mp5023.o
obj-$(CONFIG_SENSORS_MP5920) += mp5920.o
diff --git a/drivers/hwmon/pmbus/mp2985.c b/drivers/hwmon/pmbus/mp2985.c
new file mode 100644
index 000000000000..c9731e89c31a
--- /dev/null
+++ b/drivers/hwmon/pmbus/mp2985.c
@@ -0,0 +1,379 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * Hardware monitoring driver for MPS Multi-phase Digital VR Controllers(MP2985)
+ *
+ * Copyright (C) 2026 MPS
+ */
+
+#include <linux/bitfield.h>
+#include <linux/i2c.h>
+#include <linux/module.h>
+#include <linux/of_device.h>
+#include "pmbus.h"
+
+/*
+ * Vender specific register READ_PIN_EST(0x93), READ_IIN_EST(0x8E),
+ * MFR_VR_MULTI_CONFIG_R1(0x0D) and MFR_VR_MULTI_CONFIG_R2(0x1D).
+ * The READ_PIN_EST is used to read pin telemetry, the READ_IIN_EST
+ * is used to read iin telemetry and the MFR_VR_MULTI_CONFIG_R1,
+ * MFR_VR_MULTI_CONFIG_R2 are used to obtain vid scale.
+ */
+#define READ_PIN_EST 0x93
+#define READ_IIN_EST 0x8E
+#define MFR_VR_MULTI_CONFIG_R1 0x0D
+#define MFR_VR_MULTI_CONFIG_R2 0x1D
+
+#define MP2985_VOUT_DIV 64
+#define MP2985_VOUT_OVUV_UINT 125
+#define MP2985_VOUT_OVUV_DIV 64
+
+#define MP2985_PAGE_NUM 2
+
+#define MP2985_RAIL1_FUNC (PMBUS_HAVE_VIN | PMBUS_HAVE_PIN | \
+ PMBUS_HAVE_VOUT | PMBUS_HAVE_IOUT | \
+ PMBUS_HAVE_POUT | PMBUS_HAVE_TEMP | \
+ PMBUS_HAVE_STATUS_VOUT | \
+ PMBUS_HAVE_STATUS_IOUT | \
+ PMBUS_HAVE_STATUS_TEMP | \
+ PMBUS_HAVE_STATUS_INPUT)
+
+#define MP2985_RAIL2_FUNC (PMBUS_HAVE_PIN | PMBUS_HAVE_VOUT | \
+ PMBUS_HAVE_IOUT | PMBUS_HAVE_POUT | \
+ PMBUS_HAVE_TEMP | PMBUS_HAVE_IIN | \
+ PMBUS_HAVE_STATUS_VOUT | \
+ PMBUS_HAVE_STATUS_IOUT | \
+ PMBUS_HAVE_STATUS_TEMP | \
+ PMBUS_HAVE_STATUS_INPUT)
+
+struct mp2985_data {
+ struct pmbus_driver_info info;
+ int vout_scale[MP2985_PAGE_NUM];
+ int vid_offset[MP2985_PAGE_NUM];
+};
+
+#define to_mp2985_data(x) container_of(x, struct mp2985_data, info)
+
+static u16 mp2985_linear_exp_transfer(u16 word, u16 expect_exponent)
+{
+ s16 exponent, mantissa, target_exponent;
+
+ exponent = ((s16)word) >> 11;
+ mantissa = ((s16)((word & 0x7ff) << 5)) >> 5;
+ target_exponent = (s16)((expect_exponent & 0x1f) << 11) >> 11;
+
+ if (exponent > target_exponent)
+ mantissa = mantissa << (exponent - target_exponent);
+ else
+ mantissa = mantissa >> (target_exponent - exponent);
+
+ mantissa = clamp_t(s16, mantissa, -1024, 1023);
+
+ return (mantissa & 0x7ff) | ((expect_exponent << 11) & 0xf800);
+}
+
+static int mp2985_read_byte_data(struct i2c_client *client, int page, int reg)
+{
+ int ret;
+
+ switch (reg) {
+ case PMBUS_VOUT_MODE:
+ /*
+ * The MP2985 does not follow standard PMBus protocol completely,
+ * and the calculation of vout in this driver is based on direct
+ * format. As a result, the format of vout is enforced to direct.
+ */
+ ret = PB_VOUT_MODE_DIRECT;
+ break;
+ default:
+ ret = -ENODATA;
+ break;
+ }
+
+ return ret;
+}
+
+static int mp2985_read_word_data(struct i2c_client *client, int page, int phase,
+ int reg)
+{
+ const struct pmbus_driver_info *info = pmbus_get_driver_info(client);
+ struct mp2985_data *data = to_mp2985_data(info);
+ int ret;
+
+ switch (reg) {
+ case PMBUS_READ_VOUT:
+ ret = pmbus_read_word_data(client, page, phase, reg);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * The MP2985 supports three vout mode, direct, linear11 and vid mode.
+ * In vid mode, the MP2985 vout telemetry has 49 vid step offset, but
+ * PMBUS_VOUT_OV_FAULT_LIMIT and PMBUS_VOUT_UV_FAULT_LIMIT do not take
+ * this into consideration, their resolution are 1.953125mV/LSB, as a
+ * result, format[PSC_VOLTAGE_OUT] can not be set to vid mode directly.
+ * Adding extra vid_offset variable for vout telemetry.
+ */
+ ret = clamp_val(DIV_ROUND_CLOSEST(((ret & GENMASK(11, 0)) +
+ data->vid_offset[page]) *
+ data->vout_scale[page], MP2985_VOUT_DIV),
+ 0, 0x7FFF);
+ break;
+ case PMBUS_READ_IIN:
+ /*
+ * The MP2985 has standard PMBUS_READ_IIN register(0x89), but this is
+ * not used to read the input current of per rail. The input current
+ * is read through the vender redefined register READ_IIN_EST(0x8E).
+ */
+ ret = pmbus_read_word_data(client, page, phase, READ_IIN_EST);
+ break;
+ case PMBUS_READ_PIN:
+ /*
+ * The MP2985 has standard PMBUS_READ_PIN register(0x97), but this
+ * is not used to read the input power of per rail. The input power
+ * of per rail is read through the vender redefined register
+ * READ_PIN_EST(0x93).
+ */
+ ret = pmbus_read_word_data(client, page, phase, READ_PIN_EST);
+ break;
+ case PMBUS_VOUT_OV_FAULT_LIMIT:
+ case PMBUS_VOUT_UV_FAULT_LIMIT:
+ ret = pmbus_read_word_data(client, page, phase, reg);
+ if (ret < 0)
+ return ret;
+
+ ret = DIV_ROUND_CLOSEST((ret & GENMASK(11, 0)) * MP2985_VOUT_OVUV_UINT,
+ MP2985_VOUT_OVUV_DIV);
+ break;
+ case PMBUS_STATUS_WORD:
+ case PMBUS_READ_VIN:
+ case PMBUS_READ_IOUT:
+ case PMBUS_READ_POUT:
+ case PMBUS_READ_TEMPERATURE_1:
+ case PMBUS_VIN_OV_FAULT_LIMIT:
+ case PMBUS_VIN_OV_WARN_LIMIT:
+ case PMBUS_VIN_UV_WARN_LIMIT:
+ case PMBUS_VIN_UV_FAULT_LIMIT:
+ case PMBUS_IOUT_OC_FAULT_LIMIT:
+ case PMBUS_IOUT_OC_WARN_LIMIT:
+ case PMBUS_OT_FAULT_LIMIT:
+ case PMBUS_OT_WARN_LIMIT:
+ ret = -ENODATA;
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
+static int mp2985_write_word_data(struct i2c_client *client, int page, int reg,
+ u16 word)
+{
+ int ret;
+
+ switch (reg) {
+ case PMBUS_VIN_OV_FAULT_LIMIT:
+ case PMBUS_VIN_OV_WARN_LIMIT:
+ case PMBUS_VIN_UV_WARN_LIMIT:
+ case PMBUS_VIN_UV_FAULT_LIMIT:
+ /*
+ * The PMBUS_VIN_OV_FAULT_LIMIT, PMBUS_VIN_OV_WARN_LIMIT,
+ * PMBUS_VIN_UV_WARN_LIMIT and PMBUS_VIN_UV_FAULT_LIMIT
+ * of MP2985 is linear11 format, and the exponent is a
+ * constant value(5'b11101)， so the exponent of word
+ * parameter should be converted to 5'b11101(0x1D).
+ */
+ ret = pmbus_write_word_data(client, page, reg,
+ mp2985_linear_exp_transfer(word, 0x1D));
+ break;
+ case PMBUS_VOUT_OV_FAULT_LIMIT:
+ case PMBUS_VOUT_UV_FAULT_LIMIT:
+ /*
+ * The bit0-bit11 is the limit value, and bit12-bit15
+ * should not be changed.
+ */
+ ret = pmbus_read_word_data(client, page, 0xff, reg);
+ if (ret < 0)
+ return ret;
+
+ ret = pmbus_write_word_data(client, page, reg,
+ (ret & ~GENMASK(11, 0)) |
+ clamp_val(DIV_ROUND_CLOSEST(word * MP2985_VOUT_OVUV_DIV,
+ MP2985_VOUT_OVUV_UINT), 0, 0xFFF));
+ break;
+ case PMBUS_OT_FAULT_LIMIT:
+ case PMBUS_OT_WARN_LIMIT:
+ /*
+ * The PMBUS_OT_FAULT_LIMIT and PMBUS_OT_WARN_LIMIT of
+ * MP2985 is linear11 format, and the exponent is a
+ * constant value(5'b00000), so the exponent of word
+ * parameter should be converted to 5'b00000.
+ */
+ ret = pmbus_write_word_data(client, page, reg,
+ mp2985_linear_exp_transfer(word, 0x00));
+ break;
+ case PMBUS_IOUT_OC_FAULT_LIMIT:
+ case PMBUS_IOUT_OC_WARN_LIMIT:
+ /*
+ * The PMBUS_IOUT_OC_FAULT_LIMIT and PMBUS_IOUT_OC_WARN_LIMIT
+ * of MP2985 is linear11 format, and the exponent can not be
+ * changed.
+ */
+ ret = pmbus_read_word_data(client, page, 0xff, reg);
+ if (ret < 0)
+ return ret;
+
+ ret = pmbus_write_word_data(client, page, reg,
+ mp2985_linear_exp_transfer(word,
+ FIELD_GET(GENMASK(15, 11),
+ ret)));
+ break;
+ default:
+ ret = -EINVAL;
+ break;
+ }
+
+ return ret;
+}
+
+static int
+mp2985_identify_vout_scale(struct i2c_client *client, struct pmbus_driver_info *info,
+ int page)
+{
+ struct mp2985_data *data = to_mp2985_data(info);
+ int ret;
+
+ ret = i2c_smbus_write_byte_data(client, PMBUS_PAGE, page);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_read_byte_data(client, PMBUS_VOUT_MODE);
+ if (ret < 0)
+ return ret;
+
+ /*
+ * The MP2985 supports three vout mode. If PMBUS_VOUT_MODE
+ * bit5 is 1, it is vid mode. If PMBUS PMBUS_VOUT_MODE bit4
+ * is 1, it is linear11 mode, the vout scale is 1.953125mv/LSB.
+ * If PMBUS PMBUS_VOUT_MODE bit6 is 1, it is direct mode, the
+ * vout scale is 1mv/LSB. In vid mode, the MP2985 vout telemetry
+ * has 49 vid step offset.
+ */
+ if (FIELD_GET(BIT(5), ret)) {
+ ret = i2c_smbus_write_byte_data(client, PMBUS_PAGE, 2);
+ if (ret < 0)
+ return ret;
+
+ ret = i2c_smbus_read_word_data(client, page == 0 ?
+ MFR_VR_MULTI_CONFIG_R1 :
+ MFR_VR_MULTI_CONFIG_R2);
+ if (ret < 0)
+ return ret;
+
+ if (page == 0) {
+ if (FIELD_GET(BIT(4), ret))
+ data->vout_scale[page] = 320;
+ else
+ data->vout_scale[page] = 640;
+ } else {
+ if (FIELD_GET(BIT(3), ret))
+ data->vout_scale[page] = 320;
+ else
+ data->vout_scale[page] = 640;
+ }
+
+ data->vid_offset[page] = 49;
+
+ /*
+ * For vid mode, the MP2985 should be changed to page 2
+ * to obtain vout scale value, this may confuse the PMBus
+ * core. To avoid this, switch back to the previous page
+ * again.
+ */
+ ret = i2c_smbus_write_byte_data(client, PMBUS_PAGE, page);
+ if (ret < 0)
+ return ret;
+ } else if (FIELD_GET(BIT(4), ret)) {
+ data->vout_scale[page] = 125;
+ data->vid_offset[page] = 0;
+ } else {
+ data->vout_scale[page] = 64;
+ data->vid_offset[page] = 0;
+ }
+
+ return 0;
+}
+
+static int mp2985_identify(struct i2c_client *client, struct pmbus_driver_info *info)
+{
+ int ret;
+
+ ret = mp2985_identify_vout_scale(client, info, 0);
+ if (ret < 0)
+ return ret;
+
+ return mp2985_identify_vout_scale(client, info, 1);
+}
+
+static struct pmbus_driver_info mp2985_info = {
+ .pages = MP2985_PAGE_NUM,
+ .format[PSC_VOLTAGE_IN] = linear,
+ .format[PSC_CURRENT_IN] = linear,
+ .format[PSC_CURRENT_OUT] = linear,
+ .format[PSC_POWER] = linear,
+ .format[PSC_TEMPERATURE] = linear,
+ .format[PSC_VOLTAGE_OUT] = direct,
+
+ .m[PSC_VOLTAGE_OUT] = 1,
+ .R[PSC_VOLTAGE_OUT] = 3,
+ .b[PSC_VOLTAGE_OUT] = 0,
+
+ .func[0] = MP2985_RAIL1_FUNC,
+ .func[1] = MP2985_RAIL2_FUNC,
+ .read_word_data = mp2985_read_word_data,
+ .read_byte_data = mp2985_read_byte_data,
+ .write_word_data = mp2985_write_word_data,
+ .identify = mp2985_identify,
+};
+
+static int mp2985_probe(struct i2c_client *client)
+{
+ struct mp2985_data *data;
+
+ data = devm_kzalloc(&client->dev, sizeof(struct mp2985_data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ memcpy(&data->info, &mp2985_info, sizeof(mp2985_info));
+
+ return pmbus_do_probe(client, &data->info);
+}
+
+static const struct i2c_device_id mp2985_id[] = {
+ {"mp2985", 0},
+ {}
+};
+MODULE_DEVICE_TABLE(i2c, mp2985_id);
+
+static const struct of_device_id __maybe_unused mp2985_of_match[] = {
+ {.compatible = "mps,mp2985"},
+ {}
+};
+MODULE_DEVICE_TABLE(of, mp2985_of_match);
+
+static struct i2c_driver mp2985_driver = {
+ .driver = {
+ .name = "mp2985",
+ .of_match_table = mp2985_of_match,
+ },
+ .probe = mp2985_probe,
+ .id_table = mp2985_id,
+};
+
+module_i2c_driver(mp2985_driver);
+
+MODULE_AUTHOR("Wensheng Wang <wenswang@yeah.net>");
+MODULE_DESCRIPTION("PMBus driver for MPS MP2985 device");
+MODULE_LICENSE("GPL");
+MODULE_IMPORT_NS("PMBUS");
--
2.25.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox