* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Maxime Ripard @ 2026-03-25 13:44 UTC (permalink / raw)
To: Nicolas Frattaroli
Cc: Dave Stevenson, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <12425220.nUPlyArG6x@workhorse>
[-- Attachment #1: Type: text/plain, Size: 3249 bytes --]
On Wed, Mar 25, 2026 at 02:21:24PM +0100, Nicolas Frattaroli wrote:
> On Wednesday, 25 March 2026 14:05:25 Central European Standard Time Maxime Ripard wrote:
> > Hi Dave,
> >
> > On Wed, Mar 25, 2026 at 12:49:19PM +0000, Dave Stevenson wrote:
> > > > diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> > > > index af8b92d2d5b7..bd549f912b76 100644
> > > > --- a/include/drm/drm_connector.h
> > > > +++ b/include/drm/drm_connector.h
> > > > @@ -571,14 +571,102 @@ enum drm_colorspace {
> > > > * YCbCr 4:2:2 output format (ie. with horizontal subsampling)
> > > > * @DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > > > * YCbCr 4:2:0 output format (ie. with horizontal and vertical subsampling)
> > > > + * @DRM_OUTPUT_COLOR_FORMAT_COUNT:
> > > > + * Number of valid output color format values in this enum
> > > > */
> > > > enum drm_output_color_format {
> > > > DRM_OUTPUT_COLOR_FORMAT_RGB444 = 0,
> > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR444,
> > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR422,
> > > > DRM_OUTPUT_COLOR_FORMAT_YCBCR420,
> > > > + DRM_OUTPUT_COLOR_FORMAT_COUNT,
> > > > };
> > > >
> > > > +/**
> > > > + * enum drm_connector_color_format - Connector Color Format Request
> > > > + *
> > > > + * This enum, unlike &enum drm_output_color_format, is used to specify requests
> > > > + * for a specific color format on a connector through the DRM "color format"
> > > > + * property. The difference is that it has an "AUTO" value to specify that
> > > > + * no specific choice has been made.
> > > > + */
> > > > +enum drm_connector_color_format {
> > > > + /**
> > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > + * helpers should pick a suitable color format. All implementations of a
> > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > + * semantics.
> > > > + *
> > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > + * YCbCr 4:2:0.
> > >
> > > Is there a reason you propose dropping back to YCbCr 4:2:0 without
> > > trying YCbCr 4:2:2 first? Minimising the subsampling is surely
> > > beneficial, and vc4 for one can do 4:2:2 but not 4:2:0.
> >
> > The "auto" behaviour is strictly identical to the one we have right now,
> > and this one stems from i915. Back when all that logic was added, it was
> > decided to align every driver behavior on i915 because that's what most
> > compositors would expect.
>
> would it be okay to extend the behavior while we're at it? 4:2:2 does save
> bandwidth compared to RGB (unlike YCbCr 4:4:4). I do think 4:2:2 instead of
> 4:2:0 will provide benefits in some cases.
I don't really know, we would need to ask some Wayland/Weston devs as
well, but it sure is something worth discussing.
I wouldn't do it in this series but as a follow-up though.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v4 18/21] drivers: hv: vmbus: replace deprecated mmap hook with mmap_prepare
From: Vlastimil Babka (SUSE) @ 2026-03-25 13:57 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: <05467cb62267d750e5c770147517d4df0246cda6.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> 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>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 2/2] hwmon: (pmbus/isl68137) Add support for Renesas RAA228942 and RAA228943
From: Guenter Roeck @ 2026-03-25 14:12 UTC (permalink / raw)
To: Dawei Liu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Geert Uytterhoeven, Magnus Damm, Grant Peltier,
Linda Xin, Tabrez Ahmed, linux-hwmon, devicetree, linux-doc,
linux-renesas-soc, linux-kernel
In-Reply-To: <20260325041728.68-3-dawei.liu.jy@renesas.com>
On 3/24/26 21:17, Dawei Liu wrote:
> Add I2C device IDs for Renesas RAA228942 and RAA228943.
>
> At the Linux PMBus hwmon interface level currently supported by this
> driver, these devices are compatible with the existing 2-rail non-TC
> controllers, so devicetree will use fallback compatibles and no
> dedicated OF match entries are needed.
>
The AI still has a couple of concerns:
https://sashiko.dev/#/patchset/20260325090208.857-1-dawei.liu.jy%40renesas.com
As it turns out, the concern about i2c_match_id() vs. i2c_get_match_data()
has already been addressed in the hwmon-next branch.
Given that, I'll apply the series and address Krzysztof's feedback to the
first patch. No need to resend.
Thanks,
Guenter
> Signed-off-by: Dawei Liu <dawei.liu.jy@renesas.com>
> ---
> Documentation/hwmon/isl68137.rst | 20 ++++++++++++++++++++
> drivers/hwmon/pmbus/isl68137.c | 2 ++
> 2 files changed, 22 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..03c9adc0e 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},
^ permalink raw reply
* Re: [PATCH v4 19/21] uio: replace deprecated mmap hook with mmap_prepare in uio_info
From: Vlastimil Babka (SUSE) @ 2026-03-25 14:13 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: <157583e4477705b496896c7acd4ac88a937b8fa6.1774045440.git.ljs@kernel.org>
On 3/20/26 23:39, Lorenzo Stoakes (Oracle) wrote:
> The f_op->mmap interface is deprecated, so update uio_info to use its
> successor, mmap_prepare.
>
> Therefore, replace the uio_info->mmap hook with a new
> uio_info->mmap_prepare hook, and update its one user, target_core_user,
> to both specify this new mmap_prepare hook and also to use the new
> vm_ops->mapped() hook to continue to maintain a correct udev->kref
> refcount.
>
> Then update uio_mmap() to utilise the mmap_prepare compatibility layer to
> invoke this callback from the uio mmap invocation.
>
> Signed-off-by: Lorenzo Stoakes (Oracle) <ljs@kernel.org>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> drivers/target/target_core_user.c | 26 ++++++++++++++++++--------
> drivers/uio/uio.c | 10 ++++++++--
> include/linux/uio_driver.h | 4 ++--
> 3 files changed, 28 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/target/target_core_user.c b/drivers/target/target_core_user.c
> index af95531ddd35..edc2afd5f4ee 100644
> --- a/drivers/target/target_core_user.c
> +++ b/drivers/target/target_core_user.c
> @@ -1860,6 +1860,17 @@ static struct page *tcmu_try_get_data_page(struct tcmu_dev *udev, uint32_t dpi)
> return NULL;
> }
>
> +static int tcmu_vma_mapped(unsigned long start, unsigned long end, pgoff_t pgoff,
> + const struct file *file, void **vm_private_data)
> +{
> + struct tcmu_dev *udev = *vm_private_data;
> +
> + pr_debug("vma_mapped\n");
This looked like testing leftover at first, but it matches
tcmu_vma_open()/close() (in case anyone else wonders).
> +
> + kref_get(&udev->kref);
> + return 0;
> +}
> +
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: hwmon: isl68137: Add compatible strings for RAA228942 and RAA228943
From: Guenter Roeck @ 2026-03-25 14:14 UTC (permalink / raw)
To: Dawei Liu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Geert Uytterhoeven, Magnus Damm, Grant Peltier,
Linda Xin, Tabrez Ahmed, linux-hwmon, devicetree, linux-doc,
linux-renesas-soc, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260325090208.857-2-dawei.liu.jy@renesas.com>
On Wed, Mar 25, 2026 at 05:02:07PM +0800, Dawei Liu wrote:
> RAA228942 and RAA228943 are Renesas digital dual-output
> 16-phase (X+Y <= 16) PWM controllers with 2-rail non-TC
> driver configuration. At the PMBus hwmon interface level,
> they are compatible with existing 2-rail non-TC controllers
> and use renesas,raa228244 as fallback compatible
>
> Signed-off-by: Dawei Liu <dawei.liu.jy@renesas.com>
> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Applied.
Thanks,
Guenter
> ---
> .../bindings/hwmon/pmbus/isil,isl68137.yaml | 93 ++++++++++---------
> 1 file changed, 50 insertions(+), 43 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml
> index ae23a0537..8216cdf75 100644
> --- a/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml
> +++ b/Documentation/devicetree/bindings/hwmon/pmbus/isil,isl68137.yaml
> @@ -16,49 +16,56 @@ description: |
>
> properties:
> compatible:
> - enum:
> - - isil,isl68137
> - - renesas,isl68220
> - - renesas,isl68221
> - - renesas,isl68222
> - - renesas,isl68223
> - - renesas,isl68224
> - - renesas,isl68225
> - - renesas,isl68226
> - - renesas,isl68227
> - - renesas,isl68229
> - - renesas,isl68233
> - - renesas,isl68239
> - - renesas,isl69222
> - - renesas,isl69223
> - - renesas,isl69224
> - - renesas,isl69225
> - - renesas,isl69227
> - - renesas,isl69228
> - - renesas,isl69234
> - - renesas,isl69236
> - - renesas,isl69239
> - - renesas,isl69242
> - - renesas,isl69243
> - - renesas,isl69247
> - - renesas,isl69248
> - - renesas,isl69254
> - - renesas,isl69255
> - - renesas,isl69256
> - - renesas,isl69259
> - - isil,isl69260
> - - renesas,isl69268
> - - isil,isl69269
> - - renesas,isl69298
> - - renesas,raa228000
> - - renesas,raa228004
> - - renesas,raa228006
> - - renesas,raa228228
> - - renesas,raa228244
> - - renesas,raa228246
> - - renesas,raa229001
> - - renesas,raa229004
> - - renesas,raa229621
> + oneOf:
> + - enum:
> + - isil,isl68137
> + - renesas,isl68220
> + - renesas,isl68221
> + - renesas,isl68222
> + - renesas,isl68223
> + - renesas,isl68224
> + - renesas,isl68225
> + - renesas,isl68226
> + - renesas,isl68227
> + - renesas,isl68229
> + - renesas,isl68233
> + - renesas,isl68239
> + - renesas,isl69222
> + - renesas,isl69223
> + - renesas,isl69224
> + - renesas,isl69225
> + - renesas,isl69227
> + - renesas,isl69228
> + - renesas,isl69234
> + - renesas,isl69236
> + - renesas,isl69239
> + - renesas,isl69242
> + - renesas,isl69243
> + - renesas,isl69247
> + - renesas,isl69248
> + - renesas,isl69254
> + - renesas,isl69255
> + - renesas,isl69256
> + - renesas,isl69259
> + - isil,isl69260
> + - renesas,isl69268
> + - isil,isl69269
> + - renesas,isl69298
> + - renesas,raa228000
> + - renesas,raa228004
> + - renesas,raa228006
> + - renesas,raa228228
> + - renesas,raa228244
> + - renesas,raa228246
> + - renesas,raa229001
> + - renesas,raa229004
> + - renesas,raa229621
> +
> + - items:
> + - enum:
> + - renesas,raa228942
> + - renesas,raa228943
> + - const: renesas,raa228244
>
> reg:
> maxItems: 1
^ permalink raw reply
* Re: [PATCH v5 2/2] hwmon: (pmbus/isl68137) Add support for Renesas RAA228942 and RAA228943
From: Guenter Roeck @ 2026-03-25 14:20 UTC (permalink / raw)
To: Dawei Liu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Jonathan Corbet,
Shuah Khan, Geert Uytterhoeven, Magnus Damm, Grant Peltier,
Linda Xin, Tabrez Ahmed, linux-hwmon, devicetree, linux-doc,
linux-renesas-soc, linux-kernel
In-Reply-To: <20260325090208.857-3-dawei.liu.jy@renesas.com>
On Wed, Mar 25, 2026 at 05:02:08PM +0800, Dawei Liu wrote:
> Add I2C device IDs for Renesas RAA228942 and RAA228943.
>
> At the Linux PMBus hwmon interface level currently supported by this
> driver, these devices are compatible with the existing 2-rail non-TC
> controllers, so devicetree will use fallback compatibles and no
> dedicated OF match entries are needed.
>
> Signed-off-by: Dawei Liu <dawei.liu.jy@renesas.com>
Applied.
Sorry for the v4 noise. Upside of AI reviews is that it finds lots
of issues. Downside is that I now get flooded with lots of patch
revisions. Still, I very much appreciate and prefer to get both.
Thanks,
Guenter
> ---
> Documentation/hwmon/isl68137.rst | 20 ++++++++++++++++++++
> drivers/hwmon/pmbus/isl68137.c | 2 ++
> 2 files changed, 22 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..03c9adc0e 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},
^ permalink raw reply
* Re: [PATCH v2] bootconfig: Apply early options from embedded config
From: Masami Hiramatsu @ 2026-03-25 14:22 UTC (permalink / raw)
To: Breno Leitao
Cc: Jonathan Corbet, Shuah Khan, linux-kernel, linux-trace-kernel,
linux-doc, oss, paulmck, rostedt, kernel-team
In-Reply-To: <20260325-early_bootconfig-v2-1-6b05a36fbfb5@debian.org>
Hi Breno,
On Wed, 25 Mar 2026 03:05:38 -0700
Breno Leitao <leitao@debian.org> wrote:
> Bootconfig currently cannot be used to configure early kernel
> parameters. For example, the "mitigations=" parameter must be passed
> through traditional boot methods because bootconfig parsing happens
> after these early parameters need to be processed.
>
> This patch allows early options such as:
>
> kernel.mitigations = off
>
> to be placed in the embedded bootconfig and take effect, without
> requiring them to be on the kernel command line.
>
> Add bootconfig_apply_early_params() which walks all kernel.* keys in the
> parsed XBC tree and calls do_early_param() for each one. It is called
> from setup_boot_config() immediately after a successful xbc_init() on
> the embedded data, which happens before parse_early_param() runs in
> start_kernel().
>
> Early options in initrd bootconfig are still silently ignored, as the
> initrd is only available after the early param window has closed.
>
> Document this behaviour in both Kconfig and the admin guide.
AI review made some comments. Some of the review comments seem
reasonable.
https://sashiko.dev/#/patchset/20260325-early_bootconfig-v2-1-6b05a36fbfb5%40debian.org
[..]
>
> diff --git a/init/main.c b/init/main.c
> index 453ac9dff2da0..14a04c283fa48 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -416,9 +416,64 @@ static int __init warn_bootconfig(char *str)
> return 0;
> }
>
> +/*
> + * do_early_param() is defined later in this file but called from
> + * bootconfig_apply_early_params() below, so we need a forward declaration.
> + */
> +static int __init do_early_param(char *param, char *val,
> + const char *unused, void *arg);
> +
> +/*
> + * bootconfig_apply_early_params - dispatch kernel.* keys from the embedded
> + * bootconfig as early_param() calls.
> + *
> + * early_param() handlers must run before most of the kernel initialises
> + * (e.g. before the GIC driver reads irqchip.gicv3_pseudo_nmi). A bootconfig
> + * attached to the initrd arrives too late for this because the initrd is not
> + * mapped yet when early params are processed. The embedded bootconfig lives
> + * in the kernel image itself (.init.data), so it is always reachable.
> + *
> + * This function is called from setup_boot_config() which runs in
> + * start_kernel() before parse_early_param(), making the timing correct.
> + */
> +static void __init bootconfig_apply_early_params(void)
[sashiko comment]
| Does this run early enough for architectural parameters?
| While setup_boot_config() runs before parse_early_param() in start_kernel(),
| it runs after setup_arch(). setup_boot_config() relies on xbc_init() which
| uses the memblock allocator, requiring setup_arch() to have already
| initialized it.
| However, the kernel expects many early parameters (like mem=, earlycon,
| noapic, and iommu) to be parsed during setup_arch() via the architecture's
| call to parse_early_param(). Since setup_arch() completes before
| setup_boot_config() runs, will these architectural early parameters be
| silently ignored because the decisions they influence were already
| finalized?
This is the major reason that I did not support early parameter
in bootconfig. Some archs initialize kernel_cmdline in setup_arch()
and setup early parameters in it.
To fix this, we need to change setup_arch() for each architecture so
that it calls this bootconfig_apply_early_params().
> +{
> + static char val_buf[COMMAND_LINE_SIZE] __initdata;
[sashiko comment]
| Can using a single shared static buffer cause data corruption for handlers
| that save the argument pointer?
| Several early_param handlers assume the passed string pointer is persistent
| (like the boot_command_line) and retain it internally. For example,
| setup_earlycon() calls register_earlycon(), which sets
| early_console_dev.con->options = options, where options is a pointer
| directly into the passed buffer.
| Because val_buf is overwritten on every loop iteration, the stored pointer
| will point to the value of the last bootconfig key processed.
Ah, good catch. Since we don't have any standard way to handle the
parameters, some of them does not copy the value but try to keep
reference to the given string.
> + struct xbc_node *knode, *root;
> + const char *val;
> + ssize_t ret;
> +
> + root = xbc_find_node("kernel");
> + if (!root)
> + return;
> +
> + /*
> + * Keys that do not match any early_param() handler are silently
> + * ignored — do_early_param() always returns 0.
> + */
> + xbc_node_for_each_key_value(root, knode, val) {
[sashiko comment]
| Does this loop handle array values correctly?
| xbc_node_for_each_key_value() only assigns the first value of an array to
| the val pointer before advancing to the next key. It does not iterate over
| the child nodes of the array.
| If the bootconfig contains a multi-value key like
| kernel.console = "ttyS0", "tty0", will the subsequent values in the array
| be silently dropped instead of passed to the early_param handlers?
Also, good catch :) we need to use xbc_node_for_each_array_value()
for inner loop.
> + if (xbc_node_compose_key_after(root, knode, xbc_namebuf, XBC_KEYLEN_MAX) < 0)
> + continue;
> +
> + /*
> + * We need to copy const char *val to a char pointer,
> + * which is what do_early_param() need, given it might
> + * call strsep(), strtok() later.
> + */
> + ret = strscpy(val_buf, val, sizeof(val_buf));
> + if (ret < 0) {
> + pr_warn("ignoring bootconfig value '%s', too long\n",
> + xbc_namebuf);
> + continue;
> + }
> + do_early_param(xbc_namebuf, val_buf, NULL, NULL);
[sashiko comment]
| How does this handle valueless parameters (boolean flags)?
| When parsing the standard kernel command line, parse_args() passes a NULL
| value to the setup function for flags that lack an = sign (e.g., ro or
| earlycon).
| However, the bootconfig parser returns a zero-length string for valueless
| keys, which gets copied into val_buf as "" and passed to do_early_param().
| This semantic deviation breaks handlers that explicitly check if (!val).
| For instance, param_setup_earlycon() and parse_lapic() check for a NULL
| argument to enable features. Will passing "" instead of NULL prevent these
| handlers from working correctly?
See fs/proc/bootconfig.c. You can check whether the key has a value or
not by checking xbc_node_get_child(knode) != NULL.
Thank you,
> + }
> +}
> +
> static void __init setup_boot_config(void)
> {
> static char tmp_cmdline[COMMAND_LINE_SIZE] __initdata;
> + bool using_embedded = false;
> const char *msg, *data;
> int pos, ret;
> size_t size;
> @@ -427,8 +482,17 @@ static void __init setup_boot_config(void)
> /* Cut out the bootconfig data even if we have no bootconfig option */
> data = get_boot_config_from_initrd(&size);
> /* If there is no bootconfig in initrd, try embedded one. */
> - if (!data)
> + if (!data) {
> data = xbc_get_embedded_bootconfig(&size);
> + /*
> + * Record that we are using the embedded config so that
> + * bootconfig_apply_early_params() is called below.
> + * When CONFIG_BOOT_CONFIG_EMBED is not set,
> + * xbc_get_embedded_bootconfig() is a stub returning NULL, so
> + * data is always NULL here and using_embedded stays false.
> + */
> + using_embedded = data;
> + }
>
> strscpy(tmp_cmdline, boot_command_line, COMMAND_LINE_SIZE);
> err = parse_args("bootconfig", tmp_cmdline, NULL, 0, 0, 0, NULL,
> @@ -466,6 +530,8 @@ static void __init setup_boot_config(void)
> } else {
> xbc_get_info(&ret, NULL);
> pr_info("Load bootconfig: %ld bytes %d nodes\n", (long)size, ret);
> + if (using_embedded)
> + bootconfig_apply_early_params();
> /* keys starting with "kernel." are passed via cmdline */
> extra_command_line = xbc_make_cmdline("kernel");
> /* Also, "init." keys are init arguments */
>
> ---
> base-commit: 785f0eb2f85decbe7c1ef9ae922931f0194ffc2e
> change-id: 20260323-early_bootconfig-2efc4509af3d
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
^ permalink raw reply
* Re: [PATCH v4 00/10] gpu: nova-core: convert registers to use the kernel register macro
From: Danilo Krummrich @ 2026-03-25 14:46 UTC (permalink / raw)
To: Alexandre Courbot
Cc: 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, 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: <20260325-b4-nova-register-v4-0-bdf172f0f6ca@nvidia.com>
On 3/25/26 3:46 AM, Alexandre Courbot wrote:
> Alexandre Courbot (10):
> gpu: nova-core: introduce `bounded_enum` macro
> gpu: nova-core: convert PMC registers to kernel register macro
> gpu: nova-core: convert PBUS registers to kernel register macro
> gpu: nova-core: convert PFB registers to kernel register macro
> gpu: nova-core: convert GC6 registers to kernel register macro
> gpu: nova-core: convert FUSE registers to kernel register macro
> gpu: nova-core: convert PDISP registers to kernel register macro
> gpu: nova-core: convert falcon registers to kernel register macro
> gpu: nova-core: remove `io::` qualifier to register macro invocations
> Documentation: nova: remove register abstraction task
Acked-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 03/24] PCI: Require Live Update preserved devices are in singleton iommu_groups
From: Liu, Yi L @ 2026-03-25 14:51 UTC (permalink / raw)
To: David Matlack
Cc: Alex Williamson, Bjorn Helgaas, Adithya Jayachandran,
Graf, Alexander, Alex Mastro, Andrew Morton, Ankit Agrawal,
Arnd Bergmann, Askar Safin, Borislav Petkov, Chris Li, Dapeng Mi,
David Rientjes, Feng Tang, Jacob Pan, Jason Gunthorpe,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Kees Cook,
Tian, Kevin, kexec@lists.infradead.org, kvm@vger.kernel.org,
Leon Romanovsky, Leon Romanovsky, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, linux-pci@vger.kernel.org, Li RongQing,
Lukas Wunner, Elver Marco, Winiarski, Michal, Mike Rapoport,
Parav Pandit, Pasha Tatashin, Paul E. McKenney, Pawan Gupta,
Peter Zijlstra, Pranjal Shrivastava, Pratyush Yadav,
Raghavendra Rao Ananta, Randy Dunlap, Vivi, Rodrigo,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Vipin Sharma,
Kasireddy, Vivek, William Tu, Yanjun Zhu
On 3/25/26 02:00, David Matlack wrote:
> On 2026-03-24 09:07 PM, Yi Liu wrote:
>> On 3/24/26 07:57, David Matlack wrote:
>>> Require that Live Update preserved devices are in singleton iommu_groups
>>> during preservation (outgoing kernel) and retrieval (incoming kernel).
>>> PCI devices preserved across Live Update will be allowed to perform
>>> memory transactions throughout the Live Update. Thus IOMMU groups for
>>> preserved devices must remain fixed. Since all current use cases for
>>> Live Update are for PCI devices in singleton iommu_groups, require that
>>> as a starting point. This avoids the complexity of needing to enforce
>>> arbitrary iommu_group topologies while still allowing all current use
>>> cases.
>>> Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
>>> Signed-off-by: David Matlack <dmatlack@google.com>
>>> ---
>>> drivers/pci/liveupdate.c | 34 +++++++++++++++++++++++++++++++++-
>>> 1 file changed, 33 insertions(+), 1 deletion(-)
>>> diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
>>> index bec7b3500057..a3dbe06650ff 100644
>>> --- a/drivers/pci/liveupdate.c
>>> +++ b/drivers/pci/liveupdate.c
>>> @@ -75,6 +75,8 @@
>>> *
>>> * * The device must not be a Physical Function (PF).
>>> *
>>> + * * The device must be the only device in its IOMMU group.
>>> + *
>>> * Preservation Behavior
>>> * =====================
>>> *
>>> @@ -105,6 +107,7 @@
>>> #include <linux/bsearch.h>
>>> #include <linux/io.h>
>>> +#include <linux/iommu.h>
>>> #include <linux/kexec_handover.h>
>>> #include <linux/kho/abi/pci.h>
>>> #include <linux/liveupdate.h>
>>> @@ -222,6 +225,31 @@ static void pci_ser_delete(struct pci_ser *ser, struct pci_dev *dev)
>>> ser->nr_devices--;
>>> }
>>> +static int count_devices(struct device *dev, void *__nr_devices)
>>> +{
>>> + (*(int *)__nr_devices)++;
>>> + return 0;
>>> +}
>>> +
>> there was a related discussion on the singleton group check. have you
>> considered the device_group_immutable_singleton() in below link?
>> https://lore.kernel.org/linux-iommu/20220421052121.3464100-4-baolu.lu@linux.intel.com/
> Thanks for the link.
> Based on the discussion in the follow-up threads, I think the only check
> in that function that is needed on top of what is in this patch to
> ensure group immutability is this one:
> /*
> * The device could be considered to be fully isolated if
> * all devices on the path from the device to the host-PCI
> * bridge are protected from peer-to-peer DMA by ACS.
> */
> if (!pci_acs_path_enabled(pdev, NULL, REQ_ACS_FLAGS))
> return false;
> However, this would restrict Live Update support to only device
> topologies that have these flags enabled. I am not yet sure if this
> would be overly restrictive for the scenarios we care about supporting.
yes. It's a bit different from that thread in which not only require
singleton group but also need to be immutable.
> An alternative way to ensure immutability would be to block adding
> devices at probe time. i.e. Fail pci_device_group() if the device being
> added has liveupdate_incoming=True, or if the group already contains a
> device with liveupdate_{incoming,outgoing}=True. We would still need the
> check in pci_liveupdate_preserve() to pretect against setting
> liveupdate_outgoing=True on a device in a multi-device group.
this looks good to me. But you'll disallow hotplug-in during liveupdate.
not sure about if any decision w.r.t. hotplug. is it acceptable?
BTW. A question not specific to this patch. If failure happens after
executing kexec, is there any chance to fallback to the prior kernel?
Regards,
Yi Liu
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Maxime Ripard @ 2026-03-25 14:56 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acPA60Ci3n_t__xF@intel.com>
[-- Attachment #1: Type: text/plain, Size: 5249 bytes --]
On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > +enum drm_connector_color_format {
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > + * semantics.
> > > > > > + *
> > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > + * YCbCr 4:2:0.
> > > > > > + *
> > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > + * as has already been the case before the introduction of the "color
> > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > + * how HDMI does it).
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > + * not subsampled)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > + * with horizontal subsampling)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > +
> > > > > > + /**
> > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > + * with horizontal and vertical subsampling)
> > > > > > + */
> > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > >
> > > > > Seems like this should document what the quantization range
> > > > > should be for each format.
> > > > >
> > > >
> > > > I don't think so? If you want per-component bit depth values,
> > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > enum is more abstract than that, and is there to communicate
> > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > by other properties.
> > > >
> > > > If you mean the factor used for subsampling, then that'd only be
> > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > be added; no digital display protocol standard supports it to my
> > > > knowledge, and hopefully none ever will.
> > >
> > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > >
> > > The i915 behaviour is that YCbCr is always limited range,
> > > RGB can either be full or limited range depending on the
> > > "Broadcast RGB" property and other related factors.
> >
> > So far the HDMI state has both the format and quantization range as
> > different fields. I'm not sure we need to document the range in the
> > format field, maybe only mention it's not part of the format but has a
> > field of its own?
>
> I think we only have it for RGB (on some drivers only?). For YCbCr
> I think the assumption is limited range everywhere.
>
> But I'm not really concerned about documenting struct members.
> What I'm talking about is the *uapi* docs. Surely userspace
> will want to know what the new property actually does so the
> uapi needs to be documented properly. And down the line some
> new driver might also implement the wrong behaviour if there
> is no clear specification.
Ack
> So I'm thinking (or perhaps hoping) the rule might be something like:
> - YCbCr limited range
> - RGB full range if "Broadcast RGB" property is not present
Isn't it much more complicated than that for HDMI though? My
recollection was that any VIC but VIC1 would be limited range, and
anything else full range?
> - RGB full or limited range based on the "Broadcast RGB" property
> if it's present
>
> I think the "Broadcast RGB" property itself might also be lacking
> proper uapi docs, so that may need to be remedied as well.
I took care of documenting it when merging the HDMI helpers:
https://docs.kernel.org/gpu/drm-kms.html#hdmi-specific-connector-properties
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH v3 09/13] leds: flash: add support for Samsung S2M series PMIC flash LED device
From: Lee Jones @ 2026-03-25 14:58 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Pavel Machek, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
Krzysztof Kozlowski, André Draszik, Alexandre Belloni,
Jonathan Corbet, Shuah Khan, Nam Tran, linux-leds, devicetree,
linux-kernel, linux-pm, linux-samsung-soc, linux-rtc, linux-doc
In-Reply-To: <DH1XVOS6IIOE.HGIH6JQRHNAM@disroot.org>
On Sat, 14 Mar 2026, Kaustabh Chakraborty wrote:
> On 2026-03-10 11:38 +00:00, Lee Jones wrote:
> > On Wed, 25 Feb 2026, Kaustabh Chakraborty wrote:
> >
> >> Add support for flash LEDs found in certain Samsung S2M series PMICs.
> >> The device has two channels for LEDs, typically for the back and front
> >> cameras in mobile devices. Both channels can be independently
> >> controlled, and can be operated in torch or flash modes.
> >>
> >> The driver includes initial support for the S2MU005 PMIC flash LEDs.
> >>
> >> Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
> >> ---
> >> drivers/leds/flash/Kconfig | 12 +
> >> drivers/leds/flash/Makefile | 1 +
> >> drivers/leds/flash/leds-s2m-flash.c | 429 ++++++++++++++++++++++++++++++++++++
> >> 3 files changed, 442 insertions(+)
> >>
> >> diff --git a/drivers/leds/flash/Kconfig b/drivers/leds/flash/Kconfig
> >> index 5e08102a67841..be62e05277429 100644
> >> --- a/drivers/leds/flash/Kconfig
> >> +++ b/drivers/leds/flash/Kconfig
> >> @@ -114,6 +114,18 @@ config LEDS_RT8515
> >> To compile this driver as a module, choose M here: the module
> >> will be called leds-rt8515.
> >>
> >> +config LEDS_S2M_FLASH
> >> + tristate "Samsung S2M series PMICs flash/torch LED support"
> >> + depends on LEDS_CLASS
> >> + depends on MFD_SEC_CORE
> >> + depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
> >> + select REGMAP_IRQ
> >> + help
> >> + This option enables support for the flash/torch LEDs found in
> >> + certain Samsung S2M series PMICs, such as the S2MU005. It has
> >> + a LED channel dedicated for every physical LED. The LEDs can
> >> + be controlled in flash and torch modes.
> >> +
> >> config LEDS_SGM3140
> >> tristate "LED support for the SGM3140"
> >> depends on V4L2_FLASH_LED_CLASS || !V4L2_FLASH_LED_CLASS
> >> diff --git a/drivers/leds/flash/Makefile b/drivers/leds/flash/Makefile
> >> index 712fb737a428e..44e6c1b4beb37 100644
> >> --- a/drivers/leds/flash/Makefile
> >> +++ b/drivers/leds/flash/Makefile
> >> @@ -10,6 +10,7 @@ obj-$(CONFIG_LEDS_MAX77693) += leds-max77693.o
> >> obj-$(CONFIG_LEDS_QCOM_FLASH) += leds-qcom-flash.o
> >> obj-$(CONFIG_LEDS_RT4505) += leds-rt4505.o
> >> obj-$(CONFIG_LEDS_RT8515) += leds-rt8515.o
> >> +obj-$(CONFIG_LEDS_S2M_FLASH) += leds-s2m-flash.o
> >> obj-$(CONFIG_LEDS_SGM3140) += leds-sgm3140.o
> >> obj-$(CONFIG_LEDS_SY7802) += leds-sy7802.o
> >> obj-$(CONFIG_LEDS_TPS6131X) += leds-tps6131x.o
[...]
> >> +static int s2mu005_fled_torch_brightness_set(struct led_classdev *cdev,
> >> + enum led_brightness value)
> >> +{
> >> + struct s2m_fled *priv = to_led_priv(to_cdev_flash(cdev));
> >> + struct regmap *regmap = priv->regmap;
> >> + int ret;
> >> +
> >> + mutex_lock(&priv->lock);
> >> +
> >> + if (value == LED_OFF) {
> >
> > These defines are deprecated.
> >
> > From include/linux/leds.h:
> >
> > /* This is obsolete/useless. We now support variable maximum brightness. */
> > enum led_brightness {
> > LED_OFF = 0,
> > LED_ON = 1,
> > LED_HALF = 127,
> > LED_FULL = 255,
> > };
> >
>
> Let me know what am I supposed to use then. The
> brightness_set_blocking() function is defined as such:
>
> int (*brightness_set_blocking)(struct led_classdev *led_cdev,
> enum led_brightness brightness);
>
> Which has enum led_brightness as one of its params.
>
> Do I just ignore the 'obsolete' param for now and replace ` == LED_OFF`
> with a logical NOT?
I'm pretty sure most places just treat this as a u8 these days.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH net-next v3 03/13] net: introduce ndo_set_rx_mode_async and dev_rx_mode_work
From: Stanislav Fomichev @ 2026-03-25 15:06 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Stanislav Fomichev, netdev, davem, edumazet, pabeni, horms,
corbet, skhan, andrew+netdev, michael.chan, pavan.chebbi,
anthony.l.nguyen, przemyslaw.kitszel, saeedm, tariqt, mbloch,
alexanderduyck, kernel-team, johannes, sd, jianbol, dtatulea,
mohsin.bashr, jacob.e.keller, willemb, skhawaja, bestswngs,
aleksandr.loktionov, kees, linux-doc, linux-kernel,
intel-wired-lan, linux-rdma, linux-wireless, linux-kselftest,
leon
In-Reply-To: <20260324204440.1752423d@kernel.org>
On 03/24, Jakub Kicinski wrote:
> On Tue, 24 Mar 2026 15:49:27 -0700 Stanislav Fomichev wrote:
> > > > Not sure why cancel+release, maybe you're thinking about the unregister
> > > > path? This is rtnl_unlock -> netdev_run_todo -> __rtnl_unlock + some
> > > > extras.
> > > >
> > > > And the flush is here to plumb the addresses to the real devices
> > > > before we return to the callers. Mostly because of the following
> > > > things we have in the tests:
> > > >
> > > > # TEST: team cleanup mode lacp [FAIL]
> > > > # macvlan unicast address not found on a slave
> > > >
> > > > Can you explain a bit more on the suggestion?
> > >
> > > Oh, I thought it's here for unregister! Feels like it'd be cleaner to
> > > add the flush in dev_*c_add() and friends? How hard would it be to
> > > identify the callers in atomic context?
> >
> > Not sure we can do it in dev_xc_add because it runs under rtnl :-(
> > I currently do flush in netdev_run_todo because that's the place that
> > doesn't hold rtnl. Otherwise flush will get stuck because the work
> > handler grabs it...
>
> I was thinking of something a'la linkwatch. We can "steal" / "flush"
> the pending work inline. I guess linkwatch is a major source of races
> over the years...
>
> Does the macvlan + team problem still happens with the current
> implementation minus the flush? We are only flushing once so only
> pushing the addresses thru one layer of async callbacks.
Yes, it does happen consistently when I remove the flush. It also
happens with my internal v4, so I need to look again at what's going on.
Not sure whether it's my internal regression or I was just sloppy/lucky
(since you're correct in pointing out that we flush only once).
Before I went down the workqueue route, I had a simple
net_todo_list-like approach: `list_add_tail` on enqueue and
`while(!list_empty) run_work()` on rtnl_unlock. This had a nice properly of
tracking re-submissions (by checking whether the device's list_head is
linked into the list or not) and it was relatively easy to do the
recursive flush. Let me try get back to this approach and see whether
it solves the flush? Not sure what wq buys us at this point.
^ permalink raw reply
* Re: [PATCH V9 3/8] dax: add fsdev.c driver for fs-dax on character dax
From: Ira Weiny @ 2026-03-25 16:04 UTC (permalink / raw)
To: John Groves, Jonathan Cameron
Cc: John Groves, Miklos Szeredi, Dan Williams, Bernd Schubert,
Alison Schofield, John Groves, Jonathan Corbet, Shuah Khan,
Vishal Verma, Dave Jiang, Matthew Wilcox, Jan Kara,
Alexander Viro, David Hildenbrand, Christian Brauner,
Darrick J . Wong, Randy Dunlap, Jeff Layton, Amir Goldstein,
Stefan Hajnoczi, Joanne Koong, Josef Bacik, Bagas Sanjaya,
Chen Linxuan, James Morse, Fuad Tabba, Sean Christopherson,
Shivank Garg, Ackerley Tng, Gregory Price, Aravind Ramesh,
Ajay Joshi, venkataravis@micron.com, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev,
linux-cxl@vger.kernel.org, linux-fsdevel@vger.kernel.org
In-Reply-To: <acPX9T2ZF7xTCHtZ@groves.net>
John Groves wrote:
> On 26/03/24 02:39PM, Jonathan Cameron wrote:
> > On Tue, 24 Mar 2026 00:38:31 +0000
> > John Groves <john@jagalactic.com> wrote:
> >
> > > From: John Groves <john@groves.net>
> > >
> > > The new fsdev driver provides pages/folios initialized compatibly with
> > > fsdax - normal rather than devdax-style refcounting, and starting out
> > > with order-0 folios.
> > >
> > > When fsdev binds to a daxdev, it is usually (always?) switching from the
> > > devdax mode (device.c), which pre-initializes compound folios according
> > > to its alignment. Fsdev uses fsdev_clear_folio_state() to switch the
> > > folios into a fsdax-compatible state.
> > >
> > > A side effect of this is that raw mmap doesn't (can't?) work on an fsdev
> > > dax instance. Accordingly, The fsdev driver does not provide raw mmap -
> > > devices must be put in 'devdax' mode (drivers/dax/device.c) to get raw
> > > mmap capability.
> > >
> > > In this commit is just the framework, which remaps pages/folios compatibly
> > > with fsdax.
> > >
> > > Enabling dax changes:
> > >
> > > - bus.h: add DAXDRV_FSDEV_TYPE driver type
> > > - bus.c: allow DAXDRV_FSDEV_TYPE drivers to bind to daxdevs
> > > - dax.h: prototype inode_dax(), which fsdev needs
> > >
> > > Suggested-by: Dan Williams <dan.j.williams@intel.com>
> > > Suggested-by: Gregory Price <gourry@gourry.net>
> > > Signed-off-by: John Groves <john@groves.net>
> >
> > I was kind of thinking you'd go with a hidden KCONFIG option with default
> > magic to do the same build condition to you had in the Makefil, but one the
> > user can opt in or out for is also fine.
> >
> > Comments on that below. Meh, I think this is better anyway :)
> >
> > Reviewed-by: Jonathan Cameron <jonathan.cameron@huawei.com>
> >
> >
> >
> > > diff --git a/drivers/dax/Kconfig b/drivers/dax/Kconfig
> > > index d656e4c0eb84..7051b70980d5 100644
> > > --- a/drivers/dax/Kconfig
> > > +++ b/drivers/dax/Kconfig
> > > @@ -61,6 +61,17 @@ config DEV_DAX_HMEM_DEVICES
> > > depends on DEV_DAX_HMEM && DAX
> > > def_bool y
> > >
> > > +config DEV_DAX_FSDEV
> > > + tristate "FSDEV DAX: fs-dax compatible devdax driver"
> > > + depends on DEV_DAX && FS_DAX
> > > + help
> > > + Support fs-dax access to DAX devices via a character device
> > > + interface. Unlike device_dax (which pre-initializes compound folios
> > > + based on device alignment), this driver leaves folios at order-0 so
> > > + that fs-dax filesystems can manage folio order dynamically.
> > > +
> > > + Say M if unsure.
> > Fine like this, but if you wanted to hide it in interests of not
> > confusing users...
> >
> > config DEV_DAX_FSDEV
> > tristate
> > depends on DEV_DAX && FS_DAX
> > default DEV_DAX
>
> I like this better. I see no reason not to default to including fsdev.
> It does nothing other than frustrating famfs users if it's off - since
> building it still has no effect unless you put a daxdev in famfs mode.
>
> Ira, it's kinda in your hands at the moment. Do you feel like making this
> change?
I don't mind making this change. But we have to deal with the breakage to
current device dax users.
https://lore.kernel.org/all/69c36921255b6_e9d8d1009b@iweiny-mobl.notmuch/
What am I missing?
Ira
^ permalink raw reply
* [PATCH v18 0/2] ACPI: Add support for ACPI RAS2 feature table
From: shiju.jose @ 2026-03-25 16:57 UTC (permalink / raw)
To: rafael, bp, akpm, rppt, dferguson, linux-edac, linux-acpi,
linux-mm, linux-doc, tony.luck, lenb, leo.duran, Yazen.Ghannam,
mchehab
Cc: jonathan.cameron, linuxarm, rientjes, jiaqiyan, Jon.Grimm,
dave.hansen, naoya.horiguchi, james.morse, jthoughton,
somasundaram.a, erdemaktas, pgonda, duenwen, gthelen, wschwartz,
wbs, nifan.cxl, tanxiaofei, prime.zeng, roberto.sassu,
kangkang.shen, wanghuiqiang, shiju.jose
From: Shiju Jose <shiju.jose@huawei.com>
Add support for ACPI RAS2 feature table (RAS2) defined in the
ACPI 6.5 specification, section 5.2.21 and RAS2 HW based memory
scrubbing feature.
ACPI RAS2 patches were part of the EDAC series [1] and
this is the 38th version (20 + 18) of RAS2 patches sending
in last 3 years.
The code is based on linux.git v7.0-rc3 [2].
1. https://lore.kernel.org/linux-cxl/20250212143654.1893-1-shiju.jose@huawei.com/
2. https://github.com/torvalds/linux.git
Changes
=======
v17 -> v18:
1. Fixed few AI tool reported issues shared by Borislav. Thanks.
https://lore.kernel.org/all/20260312165247.GSabLvX5DjzhDtmyuh@fat_crate.local/
2. Re-add support for user setting scrub address range for Daniel's
reply in v16, which was removed in v13 because of request to simplify the code and
with the expectation that the firmware will do the full node demand scrubbing and
may enable these attributes later in the follow-up patches.
https://lore.kernel.org/all/df5fe0ed-3483-4ac5-8096-447e4e560816@os.amperecomputing.com/
v16 -> v17:
1. Merged all changes suggested by Borislav.
https://lore.kernel.org/all/20260126171552.GJaXehSJp33nFnpvVd@fat_crate.local/
2. Changes for Borislav's feedback "Add remove_aux_device() which unwinds everything
add_aux_device() does for all those devices".
v15 -> v16:
Attempt to modify throughout the code and logs for the below comments from Borislav.
Thanks for the comments.
https://lore.kernel.org/all/20251125073627.GLaSVce7hBqGH1a3ni@fat_crate.local/
https://lore.kernel.org/all/20251231131512.GBaVUh4NSWqvr2xhbM@fat_crate.local/
https://lore.kernel.org/all/20260119111701.GBaW4Sres045xnfkpz@fat_crate.local/
v14 -> v15:
1. Incorporated new changes suggested by Borislav on v13.
https://lore.kernel.org/all/20251231131512.GBaVUh4NSWqvr2xhbM@fat_crate.local/
2. Rebase to v6.19-rc5.
v13 -> v14:
1. Modifications for changes wanted by Borislav.
https://lore.kernel.org/all/20251125073627.GLaSVce7hBqGH1a3ni@fat_crate.local/
2. Changes for the comments from Randy Dunlap
https://lore.kernel.org/all/4807417b-a8f7-47a3-b38a-94ea7bdbf775@infradead.org/
https://lore.kernel.org/all/af7b6cdc-c0a7-4896-ba6b-6bb933898d37@infradead.org/
https://lore.kernel.org/all/26083ba9-1979-4d14-8465-3f54f2f96d23@infradead.org/
v12 -> v13:
1. Fixed some bugs reported and changes wanted by Borislav.
https://lore.kernel.org/all/20250910192707.GAaMHRCxWx37XitN3t@fat_crate.local/
2. Tried modifying the patch header as commented by Borislav.
3. Fixed a bug reported by Yazen.
https://lore.kernel.org/all/20250909162434.GB11602@yaz-khff2.amd.com/
4. Changed setting 'Requested Address Range' for GET_PATROL_PARAMETERS
command to meet the requirements from Daniel for Ampere Computing
platform.
https://lore.kernel.org/all/7a211c5c-174c-438b-9a98-fd47b057ea4a@os.amperecomputing.com/
5. In RAS2 driver, removed support for scrub control attributes 'addr' and
'size' for the time being with the expectation that a firmware will do
the full node demand scrubbing and may enable these attributes in the
future.
6. Add 'enable_demand' attribute to the EDAC scrub interface to start/stop
the demand scrub, which is used for the RAS2 demand scrub control.
v11 -> v12:
1. Modified logic for finding the lowest contiguous phy memory addr range for
NUMA domain using node_start_pfn() and node_spanned_pages() according to the
feedback from Mike Rapoport in v11.
https://lore.kernel.org/all/aKsIlFTkBsAF5sqD@kernel.org/
2. Rebase to 6.17-rc4.
v10 -> v11:
1. Simplified code by removing workarounds previously added to support
non-compliant case of single PCC channel shared across all proximity
domains (which is no longer required).
https://lore.kernel.org/all/f5b28977-0b80-4c39-929b-cf02ab1efb97@os.amperecomputing.com/
2. Fix for the comments from Borislav (Thanks).
https://lore.kernel.org/all/20250811152805.GQaJoMBecC4DSDtTAu@fat_crate.local/
3. Rebase to 6.17-rc1.
v9 -> v10:
1. Use pcc_chan->shmem instead of
acpi_os_ioremap(pcc_chan->shmem_base_addr,...) as it was
acpi_os_ioremap internally by the PCC driver to pcc_chan->shmem.
2. Changes required for the Ampere Computing system where uses a single
PCC channel for RAS2 memory features across all NUMA domains. Based on the
requirements from by Daniel on V9
https://lore.kernel.org/all/547ed8fb-d6b7-4b6b-a38b-bf13223971b1@os.amperecomputing.com/
and discussion with Jonathan.
2.1 Add node_to_range lookup facility to numa_memblks. This is to retrieve the lowest
physical continuous memory range of the memory associated with a NUMA domain.
2.2. Set requested addr range to the memory region's base addr and size
while send RAS2 cmd GET_PATROL_PARAMETER
in functions ras2_update_patrol_scrub_params_cache() &
ras2_get_patrol_scrub_running().
2.3. Split struct ras2_mem_ctx into struct ras2_mem_ctx_hdr and struct ras2_pxm_domain
to support cases, uses a single PCC channel for RAS2 scrubbers across all NUMA
domains and PCC channel per RAS2 scrub instance. Provided ACPI spec define single
memory scrub per NUMA domain.
2.4. EDAC feature sysfs folder for RAS2 changed from "acpi_ras_memX" to "acpi_ras_mem_idX"
because memory scrub instances across all NUMA domains would present under
"acpi_ras_mem_id0" when a system uses a single PCC channel for RAS2 scrubbers across
all NUMA domains etc.
2.5. Removed Acked-by: Rafael from patch [2], because of the several above changes from v9.
v8 -> v9:
1. Added following changes for feedback from Yazen.
1.1 In ras2_check_pcc_chan(..) function
- u32 variables moved to the same line.
- Updated error log for readw_relaxed_poll_timeout()
- Added error log for if (status & PCC_STATUS_ERROR), error condition.
- Removed an impossible condition check.
1.2. Added guard for ras2_pc_list_lock in ras2_get_pcc_subspace().
2. Rebased to linux.git v6.16-rc2 [2].
v7 -> v8:
1. Rebased to linux.git v6.16-rc1 [2].
v6 -> v7:
1. Fix for the issue reported by Daniel,
In ras2_check_pcc_chan(), add read, clear and check RAS2 set_cap_status outside
if (status & PCC_STATUS_ERROR) check.
https://lore.kernel.org/all/51bcb52c-4132-4daf-8903-29b121c485a1@os.amperecomputing.com/
v5 -> v6:
1. Fix for the issue reported by Daniel, in start scrubbing with correct addr and size
after firmware return INVALID DATA error for scrub request with invalid addr or size.
https://lore.kernel.org/all/8cdf7885-31b3-4308-8a7c-f4e427486429@os.amperecomputing.com/
v4 -> v5:
1. Fix for the build warnings reported by kernel test robot.
https://patchwork.kernel.org/project/linux-edac/patch/20250423163511.1412-3-shiju.jose@huawei.com/
2. Removed patch "ACPI: ACPI 6.5: RAS2: Rename RAS2 table structure and field names"
from the series as the patch was merged to linux-pm.git : branch linux-next
3. Rebased to ras.git: edac-for-next branch merged with linux-pm.git : linux-next branch.
v3 -> v4:
1. Changes for feedbacks from Yazen on v3.
https://lore.kernel.org/all/20250415210504.GA854098@yaz-khff2.amd.com/
v2 -> v3:
1. Rename RAS2 table structure and field names in
include/acpi/actbl2.h limited to only necessary
for RAS2 scrub feature.
2. Changes for feedbacks from Jonathan on v2.
3. Daniel reported a known behaviour: when readback 'size' attribute after
setting in, returns 0 before starting scrubbing via 'addr' attribute.
Changes added to fix this.
4. Daniel reported that firmware cannot update status of demand scrubbing
via the 'Actual Address Range (OUTPUT)', thus add workaround in the
kernel to update sysfs 'addr' attribute with the status of demand
scrubbing.
5. Optimized logic in ras2_check_pcc_chan() function
(patch - ACPI:RAS2: Add ACPI RAS2 driver).
6. Add PCC channel lock to struct ras2_pcc_subspace and change
lock in ras2_mem_ctx as a pointer to pcc channel lock to make sure
writing to PCC subspace shared memory is protected from race conditions.
v1 -> v2:
1. Changes for feedbacks from Borislav.
- Shorten ACPI RAS2 structures and variables names.
- Shorten some of the other variables in the RAS2 drivers.
- Fixed few CamelCases.
2. Changes for feedbacks from Yazen.
- Added newline after number of '}' and return statements.
- Changed return type for "ras2_add_aux_device() to 'int'.
- Deleted a duplication of acpi_get_table("RAS2",...) in the ras2_acpi_parse_table().
- Add "FW_WARN" to few error logs in the ras2_acpi_parse_table().
- Rename ras2_acpi_init() to acpi_ras2_init() and modified to call acpi_ras2_init()
function from the acpi_init().
- Moved scrub related variables from the struct ras2_mem_ctx from patch
"ACPI:RAS2: Add ACPI RAS2 driver" to "ras: mem: Add memory ACPI RAS2 driver".
Shiju Jose (2):
ACPI:RAS2: Add driver for the ACPI RAS2 feature table
ras: mem: Add ACPI RAS2 memory driver
Documentation/ABI/testing/sysfs-edac-scrub | 13 +-
Documentation/edac/scrub.rst | 70 +++
drivers/acpi/Kconfig | 11 +
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 3 +
drivers/acpi/ras2.c | 428 +++++++++++++++++
drivers/edac/scrub.c | 12 +
drivers/ras/Kconfig | 13 +
drivers/ras/Makefile | 1 +
drivers/ras/acpi_ras2.c | 504 +++++++++++++++++++++
include/acpi/ras2.h | 80 ++++
include/linux/edac.h | 4 +
12 files changed, 1135 insertions(+), 5 deletions(-)
create mode 100644 drivers/acpi/ras2.c
create mode 100644 drivers/ras/acpi_ras2.c
create mode 100644 include/acpi/ras2.h
--
2.43.0
^ permalink raw reply
* [PATCH v18 1/2] ACPI:RAS2: Add driver for the ACPI RAS2 feature table
From: shiju.jose @ 2026-03-25 16:57 UTC (permalink / raw)
To: rafael, bp, akpm, rppt, dferguson, linux-edac, linux-acpi,
linux-mm, linux-doc, tony.luck, lenb, leo.duran, Yazen.Ghannam,
mchehab
Cc: jonathan.cameron, linuxarm, rientjes, jiaqiyan, Jon.Grimm,
dave.hansen, naoya.horiguchi, james.morse, jthoughton,
somasundaram.a, erdemaktas, pgonda, duenwen, gthelen, wschwartz,
wbs, nifan.cxl, tanxiaofei, prime.zeng, roberto.sassu,
kangkang.shen, wanghuiqiang, shiju.jose
In-Reply-To: <20260325165714.294-1-shiju.jose@huawei.com>
From: Shiju Jose <shiju.jose@huawei.com>
ACPI 6.5 Specification, section 5.2.21, defined RAS2 feature table (RAS2).
Driver adds support for RAS2 feature table, which provides interfaces for
platform RAS features, e.g., for HW-based memory scrubbing, and logical to
PA translation service. RAS2 uses PCC channel subspace for communicating
with the ACPI compliant HW platform.
Co-developed-by: A Somasundaram <somasundaram.a@hpe.com>
Signed-off-by: A Somasundaram <somasundaram.a@hpe.com>
Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: Daniel Ferguson <danielf@os.amperecomputing.com>
Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
---
drivers/acpi/Kconfig | 11 ++
drivers/acpi/Makefile | 1 +
drivers/acpi/bus.c | 3 +
drivers/acpi/ras2.c | 428 ++++++++++++++++++++++++++++++++++++++++++
include/acpi/ras2.h | 57 ++++++
5 files changed, 500 insertions(+)
create mode 100644 drivers/acpi/ras2.c
create mode 100644 include/acpi/ras2.h
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index df0ff0764d0d..194da13c8b31 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -293,6 +293,17 @@ config ACPI_CPPC_LIB
If your platform does not support CPPC in firmware,
leave this option disabled.
+config ACPI_RAS2
+ bool "ACPI RAS2 driver"
+ select AUXILIARY_BUS
+ depends on MAILBOX
+ depends on PCC
+ help
+ Add support for the RAS2 feature table and provide interfaces for
+ platform RAS features, such as hardware-based memory scrubbing.
+
+ If unsure, select N.
+
config ACPI_PROCESSOR
tristate "Processor"
depends on X86 || ARM64 || LOONGARCH || RISCV
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index d1b0affb844f..abfec6745724 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -105,6 +105,7 @@ obj-$(CONFIG_ACPI_EC_DEBUGFS) += ec_sys.o
obj-$(CONFIG_ACPI_BGRT) += bgrt.o
obj-$(CONFIG_ACPI_CPPC_LIB) += cppc_acpi.o
obj-$(CONFIG_ACPI_SPCR_TABLE) += spcr.o
+obj-$(CONFIG_ACPI_RAS2) += ras2.o
obj-$(CONFIG_ACPI_DEBUGGER_USER) += acpi_dbg.o
obj-$(CONFIG_ACPI_PPTT) += pptt.o
obj-$(CONFIG_ACPI_PFRUT) += pfr_update.o pfr_telemetry.o
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index f6707325f582..77a848f0cfc1 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -31,6 +31,7 @@
#include <acpi/apei.h>
#include <linux/suspend.h>
#include <linux/prmt.h>
+#include <acpi/ras2.h>
#include "internal.h"
@@ -1531,6 +1532,8 @@ static int __init acpi_init(void)
acpi_debugger_init();
acpi_setup_sb_notify_handler();
acpi_viot_init();
+ acpi_ras2_init();
+
return 0;
}
diff --git a/drivers/acpi/ras2.c b/drivers/acpi/ras2.c
new file mode 100644
index 000000000000..36de200f0fc1
--- /dev/null
+++ b/drivers/acpi/ras2.c
@@ -0,0 +1,428 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * ACPI RAS2 feature table driver.
+ *
+ * Copyright (c) 2024-2026 HiSilicon Limited.
+ *
+ * Support for RAS2 table - ACPI 6.5 Specification, section 5.2.21, which
+ * provides interfaces for platform RAS features, e.g., for HW-based memory
+ * scrubbing, and logical to physical address translation service. RAS2 uses
+ * PCC channel subspace for communicating with the ACPI compliant HW platform.
+ */
+
+#undef pr_fmt
+#define pr_fmt(fmt) "ACPI RAS2: " fmt
+
+#include <linux/delay.h>
+#include <linux/export.h>
+#include <linux/iopoll.h>
+#include <linux/ktime.h>
+#include <acpi/pcc.h>
+#include <acpi/ras2.h>
+
+/**
+ * struct ras2_sspcc - Data structure for PCC communication
+ * @mbox_client: struct mbox_client object
+ * @pcc_chan: Pointer to struct pcc_mbox_chan
+ * @comm_addr: Pointer to RAS2 PCC shared memory region
+ * @pcc_lock: PCC lock to provide mutually exclusive access
+ * to PCC channel subspace
+ * @deadline_us: Poll PCC status register timeout in microsecs
+ * for PCC command completion
+ * @pcc_mpar: Maximum Periodic Access Rate (MPAR) for PCC channel
+ * @pcc_mrtt: Minimum Request Turnaround Time (MRTT) in microsecs
+ * OS must wait after completion of a PCC command before
+ * issuing next command
+ * @last_cmd_cmpl_time: Completion time of last PCC command
+ * @last_mpar_reset: Time of last MPAR count reset
+ * @mpar_count: MPAR count
+ * @pcc_id: Identifier of the RAS2 platform communication channel
+ * @last_cmd: Last PCC command
+ * @pcc_chnl_acq: Status of PCC channel acquired
+ */
+struct ras2_sspcc {
+ struct mbox_client mbox_client;
+ struct pcc_mbox_chan *pcc_chan;
+ struct acpi_ras2_shmem __iomem *comm_addr;
+ struct mutex pcc_lock;
+ unsigned int deadline_us;
+ unsigned int pcc_mpar;
+ unsigned int pcc_mrtt;
+ ktime_t last_cmd_cmpl_time;
+ ktime_t last_mpar_reset;
+ int mpar_count;
+ int pcc_id;
+ u16 last_cmd;
+ bool pcc_chnl_acq;
+};
+
+/*
+ * Arbitrary retries for PCC commands because the remote processor could be
+ * much slower to reply. Keep it high enough to cover emulators where the
+ * processors run painfully slow.
+ */
+#define PCC_NUM_RETRIES 600ULL
+#define PCC_MIN_POLL_USECS 3
+
+#define RAS2_MAX_NUM_PCC_DESCS 100
+#define RAS2_FEAT_TYPE_MEMORY 0x00
+
+static int check_pcc_chan(struct ras2_sspcc *sspcc)
+{
+ struct acpi_ras2_shmem __iomem *gen_comm_base = sspcc->comm_addr;
+ u32 cap_status;
+ u16 status;
+ int rc;
+
+ /*
+ * As per ACPI spec, the PCC space will be initialized by the
+ * platform and should have set the command completion bit when
+ * PCC can be used by OSPM.
+ *
+ * Poll PCC status register every PCC_MIN_POLL_USECS for maximum of
+ * PCC_NUM_RETRIES * PCC channel latency until PCC command complete
+ * bit is set.
+ */
+ rc = readw_relaxed_poll_timeout(&gen_comm_base->status, status,
+ status & PCC_STATUS_CMD_COMPLETE,
+ PCC_MIN_POLL_USECS, sspcc->deadline_us);
+ if (rc) {
+ pr_warn("PCC ID: 0x%x: PCC check channel timeout for last command: 0x%x rc=%d\n",
+ sspcc->pcc_id, sspcc->last_cmd, rc);
+
+ return rc;
+ }
+
+ if (status & PCC_STATUS_ERROR) {
+ pr_warn("PCC ID: 0x%x: Error in executing last command: 0x%x\n",
+ sspcc->pcc_id, sspcc->last_cmd);
+ status &= ~PCC_STATUS_ERROR;
+ writew_relaxed(status, &gen_comm_base->status);
+ return -EIO;
+ }
+
+ cap_status = readl_relaxed(&gen_comm_base->set_caps_status);
+ switch (cap_status) {
+ case ACPI_RAS2_NOT_VALID:
+ case ACPI_RAS2_NOT_SUPPORTED:
+ rc = -EPERM;
+ break;
+ case ACPI_RAS2_BUSY:
+ rc = -EBUSY;
+ break;
+ case ACPI_RAS2_FAILED:
+ case ACPI_RAS2_ABORTED:
+ case ACPI_RAS2_INVALID_DATA:
+ rc = -EINVAL;
+ break;
+ default:
+ rc = 0;
+ }
+
+ writew_relaxed(0x0, &gen_comm_base->set_caps_status);
+
+ return rc;
+}
+
+/**
+ * ras2_send_pcc_cmd() - Send RAS2 command via PCC channel
+ * @ras2_ctx: pointer to the RAS2 context structure
+ * @cmd: RAS2 command to send
+ *
+ * Returns: 0 on success, an error otherwise
+ */
+int ras2_send_pcc_cmd(struct ras2_mem_ctx *ras2_ctx, u16 cmd)
+{
+ struct acpi_ras2_shmem __iomem *gen_comm_base;
+ struct mbox_chan *pcc_channel;
+ struct ras2_sspcc *sspcc;
+ unsigned int time_delta;
+ int rc;
+
+ if (!ras2_ctx)
+ return -EINVAL;
+
+ sspcc = ras2_ctx->sspcc;
+ gen_comm_base = sspcc->comm_addr;
+
+ rc = check_pcc_chan(sspcc);
+ if (rc < 0)
+ return rc;
+
+ pcc_channel = sspcc->pcc_chan->mchan;
+
+ /*
+ * Handle the Minimum Request Turnaround Time (MRTT): the minimum
+ * amount of time that OSPM must wait after the completion of
+ * a command before issuing the next command, in microseconds.
+ */
+ if (sspcc->pcc_mrtt) {
+ time_delta = ktime_us_delta(ktime_get(), sspcc->last_cmd_cmpl_time);
+ if (sspcc->pcc_mrtt > time_delta)
+ udelay(sspcc->pcc_mrtt - time_delta);
+ }
+
+ /*
+ * Handle the non-zero Maximum Periodic Access Rate (MPAR): the
+ * maximum number of periodic requests that the subspace channel can
+ * support, reported in commands per minute. 0 indicates no
+ * limitation.
+ *
+ * This parameter should be ideally zero or large enough so that it
+ * can handle maximum number of requests that all the cores in the
+ * system can collectively generate. If it is not, follow the spec and
+ * just not send the request to the platform after hitting the MPAR
+ * limit in any 60s window.
+ */
+ if (sspcc->pcc_mpar) {
+ if (!sspcc->mpar_count) {
+ time_delta = ktime_ms_delta(ktime_get(), sspcc->last_mpar_reset);
+ if (time_delta < 60 * MSEC_PER_SEC) {
+ dev_dbg(ras2_ctx->dev,
+ "PCC command 0x%x not sent due to MPAR limit", cmd);
+ return -EIO;
+ }
+ sspcc->last_mpar_reset = ktime_get();
+ sspcc->mpar_count = sspcc->pcc_mpar;
+ }
+ sspcc->mpar_count--;
+ }
+
+ /* Write to the shared comm region */
+ writew_relaxed(cmd, &gen_comm_base->command);
+
+ /* Flip CMD COMPLETE bit */
+ writew_relaxed(0, &gen_comm_base->status);
+
+ /* Ring doorbell */
+ rc = mbox_send_message(pcc_channel, &cmd);
+ /*
+ * mbox_send_message() returns a non-negative integer for successful submission
+ * and a negative value on failure.
+ */
+ if (rc < 0) {
+ dev_warn(ras2_ctx->dev,
+ "Error sending PCC mbox message command: 0x%x, rc:%d\n", cmd, rc);
+ return rc;
+ } else {
+ rc = 0;
+ }
+
+ sspcc->last_cmd = cmd;
+
+ /*
+ * If Minimum Request Turnaround Time is non-zero, need to record the
+ * completion time of both READ and WRITE commands for proper handling
+ * of MRTT, so need to check for pcc_mrtt in addition to PCC_CMD_EXEC_RAS2.
+ */
+ if (cmd == PCC_CMD_EXEC_RAS2 || sspcc->pcc_mrtt) {
+ rc = check_pcc_chan(sspcc);
+ if (sspcc->pcc_mrtt)
+ sspcc->last_cmd_cmpl_time = ktime_get();
+ }
+
+ /*
+ * Both mbox_chan_txdone() and mbox_client_txdone() require the status
+ * of the last transmission as the second argument.
+ */
+ if (pcc_channel->mbox->txdone_irq)
+ mbox_chan_txdone(pcc_channel, rc);
+ else
+ mbox_client_txdone(pcc_channel, rc);
+
+ return rc;
+}
+EXPORT_SYMBOL_FOR_MODULES(ras2_send_pcc_cmd, "acpi_ras2");
+
+static int register_pcc_channel(struct ras2_mem_ctx *ras2_ctx, int pcc_id)
+{
+ struct pcc_mbox_chan *pcc_chan;
+ struct ras2_sspcc *sspcc;
+
+ if (pcc_id < 0)
+ return -EINVAL;
+
+ sspcc = kzalloc(sizeof(*sspcc), GFP_KERNEL);
+ if (!sspcc)
+ return -ENOMEM;
+
+ pcc_chan = pcc_mbox_request_channel(&sspcc->mbox_client, pcc_id);
+ if (IS_ERR(pcc_chan)) {
+ kfree(sspcc);
+ return PTR_ERR(pcc_chan);
+ }
+
+ sspcc->pcc_id = pcc_id;
+ sspcc->pcc_chan = pcc_chan;
+ sspcc->comm_addr = pcc_chan->shmem;
+ sspcc->deadline_us = PCC_NUM_RETRIES * pcc_chan->latency;
+ sspcc->pcc_mrtt = pcc_chan->min_turnaround_time;
+ sspcc->pcc_mpar = pcc_chan->max_access_rate;
+ sspcc->mbox_client.knows_txdone = true;
+
+ ras2_ctx->sspcc = sspcc;
+ ras2_ctx->comm_addr = sspcc->comm_addr;
+ ras2_ctx->dev = pcc_chan->mchan->mbox->dev;
+
+ mutex_init(&sspcc->pcc_lock);
+ ras2_ctx->pcc_lock = &sspcc->pcc_lock;
+
+ return 0;
+}
+
+static DEFINE_IDA(ras2_ida);
+static void ras2_release(struct device *device)
+{
+ struct auxiliary_device *auxdev = to_auxiliary_dev(device);
+ struct ras2_mem_ctx *ras2_ctx = container_of(auxdev, struct ras2_mem_ctx, adev);
+ struct ras2_sspcc *sspcc;
+
+ ida_free(&ras2_ida, auxdev->id);
+ sspcc = ras2_ctx->sspcc;
+ pcc_mbox_free_channel(sspcc->pcc_chan);
+ kfree(sspcc);
+ kfree(ras2_ctx);
+}
+
+static struct ras2_mem_ctx *add_aux_device(char *name, int channel, u32 pxm_inst)
+{
+ struct ras2_mem_ctx *ras2_ctx;
+ struct ras2_sspcc *sspcc;
+ u32 comp_nid;
+ int id, rc;
+
+ comp_nid = pxm_to_node(pxm_inst);
+ if (comp_nid == NUMA_NO_NODE) {
+ pr_debug("Invalid NUMA node, channel=%d pxm_inst=%d\n", channel, pxm_inst);
+ return ERR_PTR(-EINVAL);
+ }
+
+ ras2_ctx = kzalloc(sizeof(*ras2_ctx), GFP_KERNEL);
+ if (!ras2_ctx)
+ return ERR_PTR(-ENOMEM);
+
+ ras2_ctx->sys_comp_nid = comp_nid;
+
+ rc = register_pcc_channel(ras2_ctx, channel);
+ if (rc < 0) {
+ pr_debug("Failed to register PCC channel=%d pxm_inst=%d rc=%d\n", channel,
+ pxm_inst, rc);
+ goto ctx_free;
+ }
+
+ id = ida_alloc(&ras2_ida, GFP_KERNEL);
+ if (id < 0) {
+ rc = id;
+ goto pcc_free;
+ }
+
+ ras2_ctx->adev.id = id;
+ ras2_ctx->adev.name = name;
+ ras2_ctx->adev.dev.release = ras2_release;
+ ras2_ctx->adev.dev.parent = ras2_ctx->dev;
+
+ rc = auxiliary_device_init(&ras2_ctx->adev);
+ if (rc)
+ goto ida_free;
+
+ rc = auxiliary_device_add(&ras2_ctx->adev);
+ if (rc) {
+ auxiliary_device_uninit(&ras2_ctx->adev);
+ goto ida_free;
+ }
+
+ return ras2_ctx;
+
+ida_free:
+ ida_free(&ras2_ida, id);
+pcc_free:
+ sspcc = ras2_ctx->sspcc;
+ pcc_mbox_free_channel(sspcc->pcc_chan);
+ kfree(sspcc);
+ctx_free:
+ kfree(ras2_ctx);
+
+ return ERR_PTR(rc);
+}
+
+static void remove_aux_device(struct ras2_mem_ctx *ras2_ctx)
+{
+ if (!ras2_ctx)
+ return;
+
+ auxiliary_device_delete(&ras2_ctx->adev);
+ auxiliary_device_uninit(&ras2_ctx->adev);
+}
+
+static int parse_ras2_table(struct acpi_table_ras2 *ras2_tab)
+{
+ struct acpi_ras2_pcc_desc *pcc_desc_list;
+ struct ras2_mem_ctx **pctx_list;
+ struct ras2_mem_ctx *ras2_ctx;
+ u16 i;
+
+ if (ras2_tab->header.length < sizeof(*ras2_tab)) {
+ pr_warn(FW_WARN "ACPI RAS2 table present but broken (too short, size=%u)\n",
+ ras2_tab->header.length);
+ return -EINVAL;
+ }
+
+ if (!ras2_tab->num_pcc_descs || ras2_tab->num_pcc_descs > RAS2_MAX_NUM_PCC_DESCS) {
+ pr_warn(FW_WARN "No/Invalid number of PCC descs(%d) in ACPI RAS2 table\n",
+ ras2_tab->num_pcc_descs);
+ return -EINVAL;
+ }
+
+ pctx_list = kcalloc(ras2_tab->num_pcc_descs, sizeof(*pctx_list), GFP_KERNEL);
+ if (!pctx_list)
+ return -ENOMEM;
+
+ pcc_desc_list = (struct acpi_ras2_pcc_desc *)(ras2_tab + 1);
+ for (i = 0; i < ras2_tab->num_pcc_descs; i++, pcc_desc_list++) {
+ if (pcc_desc_list->feature_type != RAS2_FEAT_TYPE_MEMORY)
+ continue;
+
+ ras2_ctx = add_aux_device(RAS2_MEM_DEV_ID_NAME, pcc_desc_list->channel_id,
+ pcc_desc_list->instance);
+ if (IS_ERR(ras2_ctx)) {
+ pr_warn("Failed to add RAS2 auxiliary device rc=%ld\n", PTR_ERR(ras2_ctx));
+ for (; i > 0; i--) {
+ if (pctx_list[i - 1])
+ remove_aux_device(pctx_list[i - 1]);
+ }
+ kfree(pctx_list);
+ return PTR_ERR(ras2_ctx);
+ }
+ pctx_list[i] = ras2_ctx;
+ }
+ kfree(pctx_list);
+
+ return 0;
+}
+
+/**
+ * acpi_ras2_init - RAS2 driver initialization function.
+ *
+ * Extracts the ACPI RAS2 table and retrieves ID for the PCC channel subspace
+ * for communicating with the ACPI compliant HW platform. Driver adds an
+ * auxiliary device, which binds to the memory ACPI RAS2 driver, for each RAS2
+ * memory feature.
+ *
+ * Returns: none.
+ */
+void __init acpi_ras2_init(void)
+{
+ struct acpi_table_ras2 *ras2_tab;
+ acpi_status status;
+
+ status = acpi_get_table(ACPI_SIG_RAS2, 0, (struct acpi_table_header **)&ras2_tab);
+ if (ACPI_FAILURE(status)) {
+ pr_debug("Failed to get table, %s\n", acpi_format_exception(status));
+ return;
+ }
+
+ if (parse_ras2_table(ras2_tab))
+ pr_debug("Failed to parse RAS2 table\n");
+
+ acpi_put_table((struct acpi_table_header *)ras2_tab);
+}
diff --git a/include/acpi/ras2.h b/include/acpi/ras2.h
new file mode 100644
index 000000000000..f4574e8e0a12
--- /dev/null
+++ b/include/acpi/ras2.h
@@ -0,0 +1,57 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/*
+ * ACPI RAS2 (RAS Feature Table) methods.
+ *
+ * Copyright (c) 2024-2026 HiSilicon Limited
+ */
+
+#ifndef _ACPI_RAS2_H
+#define _ACPI_RAS2_H
+
+#include <linux/acpi.h>
+#include <linux/auxiliary_bus.h>
+#include <linux/mailbox_client.h>
+#include <linux/mutex.h>
+#include <linux/types.h>
+
+struct device;
+
+/*
+ * ACPI spec 6.5 Table 5.82: PCC command codes used by
+ * RAS2 platform communication channel.
+ */
+#define PCC_CMD_EXEC_RAS2 0x01
+
+#define RAS2_AUX_DEV_NAME "ras2"
+#define RAS2_MEM_DEV_ID_NAME "acpi_ras2_mem"
+
+/**
+ * struct ras2_mem_ctx - Context for RAS2 memory features
+ * @adev: Auxiliary device object
+ * @comm_addr: Pointer to RAS2 PCC shared memory region
+ * @dev: Pointer to device backing struct mbox_controller for PCC
+ * @sspcc: Pointer to local data structure for PCC communication
+ * @pcc_lock: Pointer to PCC lock to provide mutually exclusive access
+ * to PCC channel subspace
+ * @sys_comp_nid: Node ID of the system component that the RAS feature
+ * is associated with. See ACPI spec 6.5 Table 5.80: RAS2
+ * Platform Communication Channel Descriptor format,
+ * Field: Instance
+ */
+struct ras2_mem_ctx {
+ struct auxiliary_device adev;
+ struct acpi_ras2_shmem __iomem *comm_addr;
+ struct device *dev;
+ void *sspcc;
+ struct mutex *pcc_lock;
+ u32 sys_comp_nid;
+};
+
+#ifdef CONFIG_ACPI_RAS2
+void __init acpi_ras2_init(void);
+int ras2_send_pcc_cmd(struct ras2_mem_ctx *ras2_ctx, u16 cmd);
+#else
+static inline void acpi_ras2_init(void) { }
+#endif
+
+#endif /* _ACPI_RAS2_H */
--
2.43.0
^ permalink raw reply related
* [PATCH v18 2/2] ras: mem: Add ACPI RAS2 memory driver
From: shiju.jose @ 2026-03-25 16:57 UTC (permalink / raw)
To: rafael, bp, akpm, rppt, dferguson, linux-edac, linux-acpi,
linux-mm, linux-doc, tony.luck, lenb, leo.duran, Yazen.Ghannam,
mchehab
Cc: jonathan.cameron, linuxarm, rientjes, jiaqiyan, Jon.Grimm,
dave.hansen, naoya.horiguchi, james.morse, jthoughton,
somasundaram.a, erdemaktas, pgonda, duenwen, gthelen, wschwartz,
wbs, nifan.cxl, tanxiaofei, prime.zeng, roberto.sassu,
kangkang.shen, wanghuiqiang, shiju.jose
In-Reply-To: <20260325165714.294-1-shiju.jose@huawei.com>
From: Shiju Jose <shiju.jose@huawei.com>
ACPI 6.5 Specification, section 5.2.21, defined RAS2 feature table (RAS2).
Driver adds support for RAS2 feature table, which provides interfaces for
platform RAS features, e.g., for HW-based memory scrubbing, and logical to
PA translation service. RAS2 uses PCC channel subspace for communicating
with the ACPI compliant HW platform.
ACPI RAS2 auxiliary driver for the memory features binds to the auxiliary
device, which is added by the RAS2 table parser in the ACPI RAS2 driver.
Given the address range provided to the userspace may be the lowest scrub
address range in the presence of disjoint address ranges, skipping address
ranges that are from other NUMA nodes but happen to lie within this range.
Driver retrieves the PA range of the NUMA domain and use it as the
'Requested Address Range', when send RAS2 command GET_PATROL_PARAMETERS
to get parameters that apply to all addresses in the NUMA domain.
Device with ACPI RAS2 scrub feature registers with EDAC device driver,
which retrieves the scrub descriptor from EDAC scrub and exposes
the scrub control attributes for RAS2 scrub instance to userspace in
/sys/bus/edac/devices/acpi_ras_memX/scrub0/.
Add 'enable_demand' attribute to the EDAC scrub interface to start/stop
the demand scrub, which is used in the RAS2 demand scrub control.
When a demand scrub is started, any background scrub currently in progress
will be stopped and then automatically restarted at the beginning when the
demand scrub has completed.
Co-developed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Tested-by: Daniel Ferguson <danielf@os.amperecomputing.com>
Signed-off-by: Shiju Jose <shiju.jose@huawei.com>
---
Documentation/ABI/testing/sysfs-edac-scrub | 13 +-
Documentation/edac/scrub.rst | 70 +++
drivers/edac/scrub.c | 12 +
drivers/ras/Kconfig | 13 +
drivers/ras/Makefile | 1 +
drivers/ras/acpi_ras2.c | 504 +++++++++++++++++++++
include/acpi/ras2.h | 23 +
include/linux/edac.h | 4 +
8 files changed, 635 insertions(+), 5 deletions(-)
create mode 100644 drivers/ras/acpi_ras2.c
diff --git a/Documentation/ABI/testing/sysfs-edac-scrub b/Documentation/ABI/testing/sysfs-edac-scrub
index ab6014743da5..3f68f63556f4 100644
--- a/Documentation/ABI/testing/sysfs-edac-scrub
+++ b/Documentation/ABI/testing/sysfs-edac-scrub
@@ -20,11 +20,7 @@ KernelVersion: 6.15
Contact: linux-edac@vger.kernel.org
Description:
(RW) The base address of the memory region to be scrubbed
- for on-demand scrubbing. Setting address starts scrubbing.
- The size must be set before that.
-
- The readback addr value is non-zero if the requested
- on-demand scrubbing is in progress, zero otherwise.
+ for demand scrubbing.
What: /sys/bus/edac/devices/<dev-name>/scrubX/size
Date: March 2025
@@ -34,6 +30,13 @@ Description:
(RW) The size of the memory region to be scrubbed
(on-demand scrubbing).
+What: /sys/bus/edac/devices/<dev-name>/scrubX/enable_demand
+Date: Jan 2026
+KernelVersion: 6.19
+Contact: linux-edac@vger.kernel.org
+Description:
+ (RW) Start/Stop demand scrubbing if supported.
+
What: /sys/bus/edac/devices/<dev-name>/scrubX/enable_background
Date: March 2025
KernelVersion: 6.15
diff --git a/Documentation/edac/scrub.rst b/Documentation/edac/scrub.rst
index 2cfa74fa1ffd..562bfd6ff630 100644
--- a/Documentation/edac/scrub.rst
+++ b/Documentation/edac/scrub.rst
@@ -340,3 +340,73 @@ controller or platform when unexpectedly high error rates are detected.
Sysfs files for scrubbing are documented in
`Documentation/ABI/testing/sysfs-edac-ecs`
+
+3. ACPI RAS2 Hardware-based Memory Scrubbing
+
+3.1. Demand scrubbing for a specific memory region.
+
+3.1.1. Query the status of demand scrubbing
+
+# cat /sys/bus/edac/devices/acpi_ras_mem0/scrub0/enable_demand
+
+0
+
+3.1.2. Query what is device default/current scrub cycle setting.
+
+Applicable to both demand and background scrubbing. The unit of the
+scrub cycle is seconds.
+
+# cat /sys/bus/edac/devices/acpi_ras_mem0/scrub0/current_cycle_duration
+
+36000
+
+3.1.3. Query the range of device supported scrub cycle for a memory region.
+The unit of the scrub cycle range is seconds.
+
+# cat /sys/bus/edac/devices/acpi_ras_mem0/scrub0/min_cycle_duration
+
+3600
+
+# cat /sys/bus/edac/devices/acpi_ras_mem0/scrub0/max_cycle_duration
+
+86400
+
+3.1.4. Program scrubbing for the memory region in RAS2 device to repeat every
+43200 seconds (half a day).
+
+# echo 43200 > /sys/bus/edac/devices/acpi_ras_mem0/scrub0/current_cycle_duration
+
+3.1.5. Set address range.
+
+Set 'addr' of the memory region to scrub.
+
+# echo 0x80000000 > /sys/bus/edac/devices/acpi_ras_mem0/scrub0/addr
+
+Set 'size' of the memory region to scrub.
+
+# echo 0x200000 > /sys/bus/edac/devices/acpi_ras_mem0/scrub0/size
+
+3.1.6. Start 'demand scrubbing'.
+
+When a demand scrub is started, any background scrub currently in progress
+will be stopped and then automatically restarted at the beginning when the
+demand scrub has completed.
+
+# echo 1 > /sys/bus/edac/devices/acpi_ras_mem0/scrub0/enable_demand
+
+3.2. Background scrubbing the entire memory
+
+3.2.1. Query the status of background scrubbing.
+
+# cat /sys/bus/edac/devices/acpi_ras_mem0/scrub0/enable_background
+
+0
+
+3.2.2. Program background scrubbing for RAS2 device to repeat in every 21600
+seconds (quarter of a day).
+
+# echo 21600 > /sys/bus/edac/devices/acpi_ras_mem0/scrub0/current_cycle_duration
+
+3.2.3. Start 'background scrubbing'.
+
+# echo 1 > /sys/bus/edac/devices/acpi_ras_mem0/scrub0/enable_background
diff --git a/drivers/edac/scrub.c b/drivers/edac/scrub.c
index f9d02af2fc3a..f3b9a2f04950 100644
--- a/drivers/edac/scrub.c
+++ b/drivers/edac/scrub.c
@@ -14,6 +14,7 @@ enum edac_scrub_attributes {
SCRUB_ADDRESS,
SCRUB_SIZE,
SCRUB_ENABLE_BACKGROUND,
+ SCRUB_ENABLE_DEMAND,
SCRUB_MIN_CYCLE_DURATION,
SCRUB_MAX_CYCLE_DURATION,
SCRUB_CUR_CYCLE_DURATION,
@@ -55,6 +56,7 @@ static ssize_t attrib##_show(struct device *ras_feat_dev, \
EDAC_SCRUB_ATTR_SHOW(addr, read_addr, u64, "0x%llx\n")
EDAC_SCRUB_ATTR_SHOW(size, read_size, u64, "0x%llx\n")
EDAC_SCRUB_ATTR_SHOW(enable_background, get_enabled_bg, bool, "%u\n")
+EDAC_SCRUB_ATTR_SHOW(enable_demand, get_enabled_od, bool, "%u\n")
EDAC_SCRUB_ATTR_SHOW(min_cycle_duration, get_min_cycle, u32, "%u\n")
EDAC_SCRUB_ATTR_SHOW(max_cycle_duration, get_max_cycle, u32, "%u\n")
EDAC_SCRUB_ATTR_SHOW(current_cycle_duration, get_cycle_duration, u32, "%u\n")
@@ -84,6 +86,7 @@ static ssize_t attrib##_store(struct device *ras_feat_dev, \
EDAC_SCRUB_ATTR_STORE(addr, write_addr, u64, kstrtou64)
EDAC_SCRUB_ATTR_STORE(size, write_size, u64, kstrtou64)
EDAC_SCRUB_ATTR_STORE(enable_background, set_enabled_bg, unsigned long, kstrtoul)
+EDAC_SCRUB_ATTR_STORE(enable_demand, set_enabled_od, unsigned long, kstrtoul)
EDAC_SCRUB_ATTR_STORE(current_cycle_duration, set_cycle_duration, unsigned long, kstrtoul)
static umode_t scrub_attr_visible(struct kobject *kobj, struct attribute *a, int attr_id)
@@ -119,6 +122,14 @@ static umode_t scrub_attr_visible(struct kobject *kobj, struct attribute *a, int
return 0444;
}
break;
+ case SCRUB_ENABLE_DEMAND:
+ if (ops->get_enabled_od) {
+ if (ops->set_enabled_od)
+ return a->mode;
+ else
+ return 0444;
+ }
+ break;
case SCRUB_MIN_CYCLE_DURATION:
if (ops->get_min_cycle)
return a->mode;
@@ -164,6 +175,7 @@ static int scrub_create_desc(struct device *scrub_dev,
[SCRUB_ADDRESS] = EDAC_SCRUB_ATTR_RW(addr, instance),
[SCRUB_SIZE] = EDAC_SCRUB_ATTR_RW(size, instance),
[SCRUB_ENABLE_BACKGROUND] = EDAC_SCRUB_ATTR_RW(enable_background, instance),
+ [SCRUB_ENABLE_DEMAND] = EDAC_SCRUB_ATTR_RW(enable_demand, instance),
[SCRUB_MIN_CYCLE_DURATION] = EDAC_SCRUB_ATTR_RO(min_cycle_duration, instance),
[SCRUB_MAX_CYCLE_DURATION] = EDAC_SCRUB_ATTR_RO(max_cycle_duration, instance),
[SCRUB_CUR_CYCLE_DURATION] = EDAC_SCRUB_ATTR_RW(current_cycle_duration, instance)
diff --git a/drivers/ras/Kconfig b/drivers/ras/Kconfig
index fc4f4bb94a4c..a1e6aed8bcc8 100644
--- a/drivers/ras/Kconfig
+++ b/drivers/ras/Kconfig
@@ -46,4 +46,17 @@ config RAS_FMPM
Memory will be retired during boot time and run time depending on
platform-specific policies.
+config MEM_ACPI_RAS2
+ tristate "Memory ACPI RAS2 driver"
+ depends on ACPI_RAS2
+ depends on EDAC
+ depends on EDAC_SCRUB
+ select NUMA_KEEP_MEMINFO
+ help
+ The driver binds to the auxiliary device added by the ACPI RAS2
+ feature table parser. The driver uses a PCC channel subspace to
+ communicate with the ACPI-compliant platform and provides
+ control of the HW-based memory scrubber parameters to the user
+ through the EDAC scrub interface.
+
endif
diff --git a/drivers/ras/Makefile b/drivers/ras/Makefile
index 11f95d59d397..a0e6e903d6b0 100644
--- a/drivers/ras/Makefile
+++ b/drivers/ras/Makefile
@@ -2,6 +2,7 @@
obj-$(CONFIG_RAS) += ras.o
obj-$(CONFIG_DEBUG_FS) += debugfs.o
obj-$(CONFIG_RAS_CEC) += cec.o
+obj-$(CONFIG_MEM_ACPI_RAS2) += acpi_ras2.o
obj-$(CONFIG_RAS_FMPM) += amd/fmpm.o
obj-y += amd/atl/
diff --git a/drivers/ras/acpi_ras2.c b/drivers/ras/acpi_ras2.c
new file mode 100644
index 000000000000..af53196949bc
--- /dev/null
+++ b/drivers/ras/acpi_ras2.c
@@ -0,0 +1,504 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+/*
+ * ACPI RAS2 memory driver
+ *
+ * Copyright (c) 2024-2026 HiSilicon Limited.
+ *
+ */
+
+#undef pr_fmt
+#define pr_fmt(fmt) "ACPI RAS2 MEMORY: " fmt
+
+#include <linux/bitfield.h>
+#include <linux/delay.h>
+#include <linux/edac.h>
+#include <linux/kthread.h>
+#include <linux/platform_device.h>
+#include <acpi/ras2.h>
+
+#define RAS2_SUPPORT_HW_PARTOL_SCRUB BIT(0)
+#define RAS2_TYPE_PATROL_SCRUB 0x0000
+
+#define RAS2_GET_PATROL_PARAMETERS 0x01
+#define RAS2_START_PATROL_SCRUBBER 0x02
+#define RAS2_STOP_PATROL_SCRUBBER 0x03
+
+/*
+ * RAS2 patrol scrub
+ */
+#define RAS2_PS_SC_HRS_IN_MASK GENMASK(15, 8)
+#define RAS2_PS_EN_BACKGROUND BIT(0)
+#define RAS2_PS_SC_HRS_OUT_MASK GENMASK(7, 0)
+#define RAS2_PS_MIN_SC_HRS_OUT_MASK GENMASK(15, 8)
+#define RAS2_PS_MAX_SC_HRS_OUT_MASK GENMASK(23, 16)
+#define RAS2_PS_FLAG_SCRUB_RUNNING BIT(0)
+
+#define RAS2_SCRUB_NAME_LEN 128
+#define RAS2_HOUR_IN_SECS 3600
+
+struct acpi_ras2_ps_shared_mem {
+ struct acpi_ras2_shmem common;
+ struct acpi_ras2_patrol_scrub_param params;
+};
+
+#define TO_ACPI_RAS2_PS_SHMEM(_addr) \
+ container_of(_addr, struct acpi_ras2_ps_shared_mem, common)
+
+static int ras2_hw_scrub_set_enabled_bg(struct device *dev, void *drv_data, bool enable);
+
+static int ras2_is_patrol_scrub_support(struct ras2_mem_ctx *ras2_ctx)
+{
+ struct acpi_ras2_shmem __iomem *common = (void *)ras2_ctx->comm_addr;
+
+ guard(mutex)(ras2_ctx->pcc_lock);
+ common->set_caps[0] = 0;
+
+ return common->features[0] & RAS2_SUPPORT_HW_PARTOL_SCRUB;
+}
+
+static int ras2_update_patrol_scrub_params_cache(struct ras2_mem_ctx *ras2_ctx)
+{
+ struct acpi_ras2_ps_shared_mem __iomem *ps_sm =
+ TO_ACPI_RAS2_PS_SHMEM(ras2_ctx->comm_addr);
+ int ret;
+
+ ps_sm->common.set_caps[0] = RAS2_SUPPORT_HW_PARTOL_SCRUB;
+ ps_sm->params.command = RAS2_GET_PATROL_PARAMETERS;
+ ps_sm->params.req_addr_range[0] = ras2_ctx->mem_base;
+ ps_sm->params.req_addr_range[1] = ras2_ctx->mem_size;
+ ret = ras2_send_pcc_cmd(ras2_ctx, PCC_CMD_EXEC_RAS2);
+ if (ret) {
+ dev_err(ras2_ctx->dev, "Failed to read patrol scrub parameters\n");
+ return ret;
+ }
+
+ ras2_ctx->min_scrub_cycle = FIELD_GET(RAS2_PS_MIN_SC_HRS_OUT_MASK,
+ ps_sm->params.scrub_params_out);
+ ras2_ctx->max_scrub_cycle = FIELD_GET(RAS2_PS_MAX_SC_HRS_OUT_MASK,
+ ps_sm->params.scrub_params_out);
+ ras2_ctx->scrub_cycle_hrs = FIELD_GET(RAS2_PS_SC_HRS_OUT_MASK,
+ ps_sm->params.scrub_params_out);
+ if (ras2_ctx->bg_scrub) {
+ ras2_ctx->od_scrub = false;
+ ras2_ctx->base = 0;
+ ras2_ctx->size = 0;
+ return 0;
+ }
+
+ if (ps_sm->params.flags & RAS2_PS_FLAG_SCRUB_RUNNING) {
+ ras2_ctx->od_scrub = true;
+ ras2_ctx->base = ps_sm->params.actl_addr_range[0];
+ ras2_ctx->size = ps_sm->params.actl_addr_range[1];
+ } else {
+ ras2_ctx->od_scrub = false;
+ }
+
+ return 0;
+}
+
+/* Context - PCC lock must be held */
+static int ras2_get_demand_scrub_running(struct ras2_mem_ctx *ras2_ctx, bool *running)
+{
+ struct acpi_ras2_ps_shared_mem __iomem *ps_sm =
+ TO_ACPI_RAS2_PS_SHMEM(ras2_ctx->comm_addr);
+ int ret;
+
+ if (!ras2_ctx->od_scrub) {
+ *running = false;
+ return 0;
+ }
+
+ ps_sm->common.set_caps[0] = RAS2_SUPPORT_HW_PARTOL_SCRUB;
+ ps_sm->params.command = RAS2_GET_PATROL_PARAMETERS;
+ ps_sm->params.req_addr_range[0] = ras2_ctx->mem_base;
+ ps_sm->params.req_addr_range[1] = ras2_ctx->mem_size;
+
+ ret = ras2_send_pcc_cmd(ras2_ctx, PCC_CMD_EXEC_RAS2);
+ if (ret) {
+ dev_err(ras2_ctx->dev, "Failed to read patrol scrub parameters\n");
+ return ret;
+ }
+
+ *running = ps_sm->params.flags & RAS2_PS_FLAG_SCRUB_RUNNING;
+ if (!(*running))
+ ras2_ctx->od_scrub = false;
+
+ return 0;
+}
+
+static int ras2_scrub_monitor_thread(void *p)
+{
+ struct ras2_mem_ctx *ras2_ctx = (struct ras2_mem_ctx *)p;
+ bool running;
+ int ret;
+
+ while (!kthread_should_stop()) {
+ if (!ras2_ctx->reenable_bg_scrub)
+ return 0;
+
+ mutex_lock(ras2_ctx->pcc_lock);
+ ret = ras2_get_demand_scrub_running(ras2_ctx, &running);
+ mutex_unlock(ras2_ctx->pcc_lock);
+ if (ret)
+ return ret;
+
+ if (!running) {
+ ras2_ctx->base = 0;
+ ras2_ctx->size = 0;
+ return ras2_hw_scrub_set_enabled_bg(ras2_ctx->dev, ras2_ctx, true);
+ }
+ msleep(1000);
+ }
+
+ return 0;
+}
+
+static int ras2_hw_scrub_read_min_scrub_cycle(struct device *dev, void *drv_data, u32 *min)
+{
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+
+ *min = ras2_ctx->min_scrub_cycle * RAS2_HOUR_IN_SECS;
+
+ return 0;
+}
+
+static int ras2_hw_scrub_read_max_scrub_cycle(struct device *dev, void *drv_data, u32 *max)
+{
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+
+ *max = ras2_ctx->max_scrub_cycle * RAS2_HOUR_IN_SECS;
+
+ return 0;
+}
+
+static int ras2_hw_scrub_cycle_read(struct device *dev, void *drv_data, u32 *scrub_cycle_secs)
+{
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+
+ *scrub_cycle_secs = ras2_ctx->scrub_cycle_hrs * RAS2_HOUR_IN_SECS;
+
+ return 0;
+}
+
+static int ras2_hw_scrub_cycle_write(struct device *dev, void *drv_data, u32 scrub_cycle_secs)
+{
+ u32 scrub_cycle_hrs = scrub_cycle_secs / RAS2_HOUR_IN_SECS;
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+ bool running;
+ int ret;
+
+ if (ras2_ctx->bg_scrub)
+ return -EBUSY;
+
+ guard(mutex)(ras2_ctx->pcc_lock);
+ ret = ras2_get_demand_scrub_running(ras2_ctx, &running);
+ if (ret)
+ return ret;
+
+ if (running)
+ return -EBUSY;
+
+ if (scrub_cycle_hrs < ras2_ctx->min_scrub_cycle ||
+ scrub_cycle_hrs > ras2_ctx->max_scrub_cycle)
+ return -EINVAL;
+
+ ras2_ctx->scrub_cycle_hrs = scrub_cycle_hrs;
+
+ return 0;
+}
+
+static int ras2_hw_scrub_read_addr(struct device *dev, void *drv_data, u64 *base)
+{
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+ int ret;
+
+ /*
+ * When BG scrubbing is enabled the actual address range is not valid.
+ * Return -EBUSY now unless find out a method to retrieve actual full PA range.
+ */
+ if (ras2_ctx->bg_scrub)
+ return -EBUSY;
+
+ ret = ras2_update_patrol_scrub_params_cache(ras2_ctx);
+ if (ret)
+ return ret;
+
+ *base = ras2_ctx->base;
+
+ return 0;
+}
+
+static int ras2_hw_scrub_read_size(struct device *dev, void *drv_data, u64 *size)
+{
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+ int ret;
+
+ if (ras2_ctx->bg_scrub)
+ return -EBUSY;
+
+ ret = ras2_update_patrol_scrub_params_cache(ras2_ctx);
+ if (ret)
+ return ret;
+
+ *size = ras2_ctx->size;
+
+ return 0;
+}
+
+static int ras2_hw_scrub_write_addr(struct device *dev, void *drv_data, u64 base)
+{
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+ bool running;
+ int ret;
+
+ guard(mutex)(ras2_ctx->pcc_lock);
+ ret = ras2_get_demand_scrub_running(ras2_ctx, &running);
+ if (ret)
+ return ret;
+
+ if (running)
+ return -EBUSY;
+
+ ras2_ctx->base = base;
+
+ return 0;
+}
+
+static int ras2_hw_scrub_write_size(struct device *dev, void *drv_data, u64 size)
+{
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+ bool running;
+ int ret;
+
+ if (!size)
+ return -EINVAL;
+
+ guard(mutex)(ras2_ctx->pcc_lock);
+ ret = ras2_get_demand_scrub_running(ras2_ctx, &running);
+ if (ret)
+ return ret;
+
+ if (running)
+ return -EBUSY;
+
+ ras2_ctx->size = size;
+
+ return 0;
+}
+
+static int ras2_hw_scrub_get_enabled_bg(struct device *dev, void *drv_data, bool *enabled)
+{
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+
+ *enabled = ras2_ctx->bg_scrub;
+
+ return 0;
+}
+
+static int ras2_hw_scrub_set_enabled_bg(struct device *dev, void *drv_data, bool enable)
+{
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+ struct acpi_ras2_ps_shared_mem __iomem *ps_sm = TO_ACPI_RAS2_PS_SHMEM(ras2_ctx->comm_addr);
+ bool running;
+ int ret;
+
+ guard(mutex)(ras2_ctx->pcc_lock);
+ ret = ras2_get_demand_scrub_running(ras2_ctx, &running);
+ if (ret)
+ return ret;
+
+ ps_sm->common.set_caps[0] = RAS2_SUPPORT_HW_PARTOL_SCRUB;
+ if (enable) {
+ if (ras2_ctx->bg_scrub || running)
+ return -EBUSY;
+
+ ps_sm->params.req_addr_range[0] = 0;
+ ps_sm->params.req_addr_range[1] = 0;
+ ps_sm->params.scrub_params_in &= ~RAS2_PS_SC_HRS_IN_MASK;
+ ps_sm->params.scrub_params_in |= FIELD_PREP(RAS2_PS_SC_HRS_IN_MASK,
+ ras2_ctx->scrub_cycle_hrs);
+ ps_sm->params.command = RAS2_START_PATROL_SCRUBBER;
+ } else {
+ if (!ras2_ctx->bg_scrub)
+ return -EPERM;
+
+ ps_sm->params.command = RAS2_STOP_PATROL_SCRUBBER;
+ }
+
+ ps_sm->params.scrub_params_in &= ~RAS2_PS_EN_BACKGROUND;
+ ps_sm->params.scrub_params_in |= FIELD_PREP(RAS2_PS_EN_BACKGROUND, enable);
+ ret = ras2_send_pcc_cmd(ras2_ctx, PCC_CMD_EXEC_RAS2);
+ if (ret) {
+ dev_err(dev, "Failed to %s background scrubbing\n",
+ str_enable_disable(enable));
+ return ret;
+ }
+
+ ras2_ctx->bg_scrub = enable;
+ if (enable) {
+ ras2_ctx->reenable_bg_scrub = false;
+ /* Update the cache to account for rounding of supplied parameters and similar */
+ return ras2_update_patrol_scrub_params_cache(ras2_ctx);
+ }
+
+ return 0;
+}
+
+static int ras2_hw_scrub_get_enabled_od(struct device *dev, void *drv_data, bool *enabled)
+{
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+ bool running;
+ int ret;
+
+ guard(mutex)(ras2_ctx->pcc_lock);
+ ret = ras2_get_demand_scrub_running(ras2_ctx, &running);
+ if (ret)
+ return ret;
+
+ *enabled = running;
+
+ return 0;
+}
+
+static int ras2_hw_scrub_set_enabled_od(struct device *dev, void *drv_data, bool enable)
+{
+ struct ras2_mem_ctx *ras2_ctx = drv_data;
+ struct acpi_ras2_ps_shared_mem __iomem *ps_sm = TO_ACPI_RAS2_PS_SHMEM(ras2_ctx->comm_addr);
+ struct task_struct *thrd;
+ bool running;
+ int ret;
+
+ if (!enable)
+ return -EOPNOTSUPP;
+
+ /* Stop any background scrub currently in progress */
+ if (ras2_ctx->bg_scrub) {
+ ret = ras2_hw_scrub_set_enabled_bg(dev, drv_data, false);
+ if (ret)
+ return ret;
+
+ ras2_ctx->reenable_bg_scrub = true;
+ thrd = kthread_run(ras2_scrub_monitor_thread, ras2_ctx,
+ "ras2_scrub_nid%d", ras2_ctx->sys_comp_nid);
+ if (IS_ERR(thrd)) {
+ ras2_ctx->reenable_bg_scrub = false;
+ ras2_hw_scrub_set_enabled_bg(dev, drv_data, true);
+ return PTR_ERR(thrd);
+ }
+ }
+
+ guard(mutex)(ras2_ctx->pcc_lock);
+ ret = ras2_get_demand_scrub_running(ras2_ctx, &running);
+ if (ret)
+ return ret;
+
+ if (running)
+ return -EBUSY;
+
+ /* May add more validity checks for the address range in the future if necessary */
+ if (!ras2_ctx->size || ras2_ctx->base < ras2_ctx->mem_base) {
+ dev_err(dev, "%s: Invalid address range, base=0x%llx size=0x%llx\n",
+ __func__, ras2_ctx->base, ras2_ctx->size);
+ return -ERANGE;
+ }
+
+ ps_sm->common.set_caps[0] = RAS2_SUPPORT_HW_PARTOL_SCRUB;
+ ps_sm->params.scrub_params_in &= ~RAS2_PS_SC_HRS_IN_MASK;
+ ps_sm->params.scrub_params_in |= FIELD_PREP(RAS2_PS_SC_HRS_IN_MASK,
+ ras2_ctx->scrub_cycle_hrs);
+ ps_sm->params.req_addr_range[0] = ras2_ctx->base;
+ ps_sm->params.req_addr_range[1] = ras2_ctx->size;
+ ps_sm->params.scrub_params_in &= ~RAS2_PS_EN_BACKGROUND;
+ ps_sm->params.command = RAS2_START_PATROL_SCRUBBER;
+
+ ret = ras2_send_pcc_cmd(ras2_ctx, PCC_CMD_EXEC_RAS2);
+ if (ret) {
+ dev_err(dev, "Failed to start demand scrubbing rc(%d)\n", ret);
+ if (ret != -EBUSY) {
+ ps_sm->params.req_addr_range[0] = 0;
+ ps_sm->params.req_addr_range[1] = 0;
+ ras2_ctx->od_scrub = false;
+ ras2_ctx->base = 0;
+ ras2_ctx->size = 0;
+ }
+ return ret;
+ }
+
+ ras2_ctx->od_scrub = enable;
+
+ return ras2_update_patrol_scrub_params_cache(ras2_ctx);
+}
+
+static const struct edac_scrub_ops ras2_scrub_ops = {
+ .read_addr = ras2_hw_scrub_read_addr,
+ .read_size = ras2_hw_scrub_read_size,
+ .write_addr = ras2_hw_scrub_write_addr,
+ .write_size = ras2_hw_scrub_write_size,
+ .get_enabled_bg = ras2_hw_scrub_get_enabled_bg,
+ .set_enabled_bg = ras2_hw_scrub_set_enabled_bg,
+ .get_enabled_od = ras2_hw_scrub_get_enabled_od,
+ .set_enabled_od = ras2_hw_scrub_set_enabled_od,
+ .get_min_cycle = ras2_hw_scrub_read_min_scrub_cycle,
+ .get_max_cycle = ras2_hw_scrub_read_max_scrub_cycle,
+ .get_cycle_duration = ras2_hw_scrub_cycle_read,
+ .set_cycle_duration = ras2_hw_scrub_cycle_write,
+};
+
+static int ras2_probe(struct auxiliary_device *auxdev, const struct auxiliary_device_id *id)
+{
+ struct ras2_mem_ctx *ras2_ctx = container_of(auxdev, struct ras2_mem_ctx, adev);
+ struct edac_dev_feature ras_features;
+ char scrub_name[RAS2_SCRUB_NAME_LEN];
+ unsigned long start_pfn, size_pfn;
+ int ret;
+
+ if (!ras2_is_patrol_scrub_support(ras2_ctx))
+ return -EOPNOTSUPP;
+
+ /*
+ * Retrieve the PA range of the NUMA domain and use it as the
+ * 'Requested Address Range', when send RAS2 command
+ * GET_PATROL_PARAMETERS to get parameters that apply to all addresses
+ * in the NUMA domain as well as when send command START_PATROL_SCRUBBER
+ * to start the demand scrubbing.
+ */
+ start_pfn = node_start_pfn(ras2_ctx->sys_comp_nid);
+ size_pfn = node_spanned_pages(ras2_ctx->sys_comp_nid);
+ if (!size_pfn) {
+ pr_debug("Failed to find PA range of NUMA node(%u)\n", ras2_ctx->sys_comp_nid);
+ return -EPERM;
+ }
+
+ ras2_ctx->mem_base = __pfn_to_phys(start_pfn);
+ ras2_ctx->mem_size = __pfn_to_phys(size_pfn);
+ ret = ras2_update_patrol_scrub_params_cache(ras2_ctx);
+ if (ret)
+ return ret;
+
+ sprintf(scrub_name, "acpi_ras_mem%d", auxdev->id);
+
+ ras_features.ft_type = RAS_FEAT_SCRUB;
+ ras_features.instance = 0;
+ ras_features.scrub_ops = &ras2_scrub_ops;
+ ras_features.ctx = ras2_ctx;
+
+ return edac_dev_register(&auxdev->dev, scrub_name, NULL, 1, &ras_features);
+}
+
+static const struct auxiliary_device_id ras2_mem_dev_id_table[] = {
+ { .name = RAS2_AUX_DEV_NAME "." RAS2_MEM_DEV_ID_NAME, },
+ { }
+};
+
+MODULE_DEVICE_TABLE(auxiliary, ras2_mem_dev_id_table);
+
+static struct auxiliary_driver ras2_mem_driver = {
+ .name = RAS2_MEM_DEV_ID_NAME,
+ .probe = ras2_probe,
+ .id_table = ras2_mem_dev_id_table,
+};
+module_auxiliary_driver(ras2_mem_driver);
+
+MODULE_IMPORT_NS("ACPI_RAS2");
+MODULE_DESCRIPTION("ACPI RAS2 memory driver");
+MODULE_LICENSE("GPL");
diff --git a/include/acpi/ras2.h b/include/acpi/ras2.h
index f4574e8e0a12..136d6958d03e 100644
--- a/include/acpi/ras2.h
+++ b/include/acpi/ras2.h
@@ -37,6 +37,19 @@ struct device;
* is associated with. See ACPI spec 6.5 Table 5.80: RAS2
* Platform Communication Channel Descriptor format,
* Field: Instance
+ * @mem_base: Base of the lowest physical continuous memory range
+ * of the memory associated with the NUMA domain
+ * @mem_size Size of the lowest physical continuous memory range
+ * of the memory associated with the NUMA domain
+ * @base: Base address of the memory region to scrub
+ * @size: Size of the memory region to scrub
+ * @scrub_cycle_hrs: Current scrub rate in hours
+ * @min_scrub_cycle: Minimum scrub rate supported
+ * @max_scrub_cycle: Maximum scrub rate supported
+ * @od_scrub: Status of demand scrubbing (memory region)
+ * @bg_scrub: Status of background patrol scrubbing
+ * @reenable_bg_scrub: Flag indicates restart background scrubbing after demand
+ * scrubbing is finished
*/
struct ras2_mem_ctx {
struct auxiliary_device adev;
@@ -45,6 +58,16 @@ struct ras2_mem_ctx {
void *sspcc;
struct mutex *pcc_lock;
u32 sys_comp_nid;
+ u64 mem_base;
+ u64 mem_size;
+ u64 base;
+ u64 size;
+ u8 scrub_cycle_hrs;
+ u8 min_scrub_cycle;
+ u8 max_scrub_cycle;
+ bool od_scrub;
+ bool bg_scrub;
+ bool reenable_bg_scrub;
};
#ifdef CONFIG_ACPI_RAS2
diff --git a/include/linux/edac.h b/include/linux/edac.h
index fa32f2aca22f..2342ff38e9d5 100644
--- a/include/linux/edac.h
+++ b/include/linux/edac.h
@@ -680,6 +680,8 @@ enum edac_dev_feat {
* @write_size: set offset of the scrubbing range.
* @get_enabled_bg: check if currently performing background scrub.
* @set_enabled_bg: start or stop a bg-scrub.
+ * @get_enabled_od: check if currently performing demand scrub.
+ * @set_enabled_od: start or stop a demand-scrub.
* @get_min_cycle: get minimum supported scrub cycle duration in seconds.
* @get_max_cycle: get maximum supported scrub cycle duration in seconds.
* @get_cycle_duration: get current scrub cycle duration in seconds.
@@ -692,6 +694,8 @@ struct edac_scrub_ops {
int (*write_size)(struct device *dev, void *drv_data, u64 size);
int (*get_enabled_bg)(struct device *dev, void *drv_data, bool *enable);
int (*set_enabled_bg)(struct device *dev, void *drv_data, bool enable);
+ int (*get_enabled_od)(struct device *dev, void *drv_data, bool *enable);
+ int (*set_enabled_od)(struct device *dev, void *drv_data, bool enable);
int (*get_min_cycle)(struct device *dev, void *drv_data, u32 *min);
int (*get_max_cycle)(struct device *dev, void *drv_data, u32 *max);
int (*get_cycle_duration)(struct device *dev, void *drv_data, u32 *cycle);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v3 03/24] PCI: Require Live Update preserved devices are in singleton iommu_groups
From: David Matlack @ 2026-03-25 17:29 UTC (permalink / raw)
To: Yi Liu
Cc: Alex Williamson, Bjorn Helgaas, Adithya Jayachandran,
Alexander Graf, Alex Mastro, Andrew Morton, Ankit Agrawal,
Arnd Bergmann, Askar Safin, Borislav Petkov (AMD), Chris Li,
Dapeng Mi, David Rientjes, Feng Tang, Jacob Pan, Jason Gunthorpe,
Jason Gunthorpe, Jonathan Corbet, Josh Hilke, Kees Cook,
Kevin Tian, kexec, kvm, Leon Romanovsky, Leon Romanovsky,
linux-doc, linux-kernel, linux-kselftest, linux-mm, linux-pci,
Li RongQing, Lukas Wunner, Marco Elver, Michał Winiarski,
Mike Rapoport, Parav Pandit, Pasha Tatashin, Paul E. McKenney,
Pawan Gupta, Peter Zijlstra (Intel), Pranjal Shrivastava,
Pratyush Yadav, Raghavendra Rao Ananta, Randy Dunlap,
Rodrigo Vivi, Saeed Mahameed, Samiullah Khawaja, Shuah Khan,
Vipin Sharma, Vivek Kasireddy, William Tu, Zhu Yanjun
In-Reply-To: <b16f93af-1ec6-43f5-b4d0-b1d390e3c23c@intel.com>
On 2026-03-25 07:12 PM, Yi Liu wrote:
>
>
> On 3/25/26 02:00, David Matlack wrote:
> > On 2026-03-24 09:07 PM, Yi Liu wrote:
> > > On 3/24/26 07:57, David Matlack wrote:
> > > > Require that Live Update preserved devices are in singleton iommu_groups
> > > > during preservation (outgoing kernel) and retrieval (incoming kernel).
> > > >
> > > > PCI devices preserved across Live Update will be allowed to perform
> > > > memory transactions throughout the Live Update. Thus IOMMU groups for
> > > > preserved devices must remain fixed. Since all current use cases for
> > > > Live Update are for PCI devices in singleton iommu_groups, require that
> > > > as a starting point. This avoids the complexity of needing to enforce
> > > > arbitrary iommu_group topologies while still allowing all current use
> > > > cases.
> > > >
> > > > Suggested-by: Jason Gunthorpe <jgg@nvidia.com>
> > > > Signed-off-by: David Matlack <dmatlack@google.com>
> > > > ---
> > > > drivers/pci/liveupdate.c | 34 +++++++++++++++++++++++++++++++++-
> > > > 1 file changed, 33 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/pci/liveupdate.c b/drivers/pci/liveupdate.c
> > > > index bec7b3500057..a3dbe06650ff 100644
> > > > --- a/drivers/pci/liveupdate.c
> > > > +++ b/drivers/pci/liveupdate.c
> > > > @@ -75,6 +75,8 @@
> > > > *
> > > > * * The device must not be a Physical Function (PF).
> > > > *
> > > > + * * The device must be the only device in its IOMMU group.
> > > > + *
> > > > * Preservation Behavior
> > > > * =====================
> > > > *
> > > > @@ -105,6 +107,7 @@
> > > > #include <linux/bsearch.h>
> > > > #include <linux/io.h>
> > > > +#include <linux/iommu.h>
> > > > #include <linux/kexec_handover.h>
> > > > #include <linux/kho/abi/pci.h>
> > > > #include <linux/liveupdate.h>
> > > > @@ -222,6 +225,31 @@ static void pci_ser_delete(struct pci_ser *ser, struct pci_dev *dev)
> > > > ser->nr_devices--;
> > > > }
> > > > +static int count_devices(struct device *dev, void *__nr_devices)
> > > > +{
> > > > + (*(int *)__nr_devices)++;
> > > > + return 0;
> > > > +}
> > > > +
> > >
> > > there was a related discussion on the singleton group check. have you
> > > considered the device_group_immutable_singleton() in below link?
> > >
> > > https://lore.kernel.org/linux-iommu/20220421052121.3464100-4-baolu.lu@linux.intel.com/
> >
> > Thanks for the link.
> >
> > Based on the discussion in the follow-up threads, I think the only check
> > in that function that is needed on top of what is in this patch to
> > ensure group immutability is this one:
> >
> > /*
> > * The device could be considered to be fully isolated if
> > * all devices on the path from the device to the host-PCI
> > * bridge are protected from peer-to-peer DMA by ACS.
> > */
> > if (!pci_acs_path_enabled(pdev, NULL, REQ_ACS_FLAGS))
> > return false;
> >
> > However, this would restrict Live Update support to only device
> > topologies that have these flags enabled. I am not yet sure if this
> > would be overly restrictive for the scenarios we care about supporting.
>
> yes. It's a bit different from that thread in which not only require
> singleton group but also need to be immutable.
>
> > An alternative way to ensure immutability would be to block adding
> > devices at probe time. i.e. Fail pci_device_group() if the device being
> > added has liveupdate_incoming=True, or if the group already contains a
> > device with liveupdate_{incoming,outgoing}=True. We would still need the
> > check in pci_liveupdate_preserve() to pretect against setting
> > liveupdate_outgoing=True on a device in a multi-device group.
>
> this looks good to me. But you'll disallow hotplug-in during liveupdate.
> not sure about if any decision w.r.t. hotplug. is it acceptable?
Anyone doing hotplug during the middle of a Live Update is asking for
trouble IMO. And it would only prevent a hot-plugged device from coming
up if it were to be added to the iommu_group as an existing preserved
device. I think that is reasonable.
> BTW. A question not specific to this patch. If failure happens after
> executing kexec, is there any chance to fallback to the prior kernel?
There are many failure paths during the reboot() syscall that can return
back to userspace, and then userspace can figure out how to bring the
system (e.g. VMs) back online on the current kernel.
But otherwise, kexec is currently a one way door. Once you kexec, into
the new kernel, you would have to do another Live Update to get back
into the previous kernel.
^ permalink raw reply
* Re: [PATCH net-next v3 03/13] net: introduce ndo_set_rx_mode_async and dev_rx_mode_work
From: Stanislav Fomichev @ 2026-03-25 17:34 UTC (permalink / raw)
To: Jakub Kicinski, Stanislav Fomichev, netdev, davem, edumazet,
pabeni, horms, corbet, skhan, andrew+netdev, michael.chan,
pavan.chebbi, anthony.l.nguyen, przemyslaw.kitszel, saeedm,
tariqt, mbloch, alexanderduyck, kernel-team, johannes, sd,
jianbol, dtatulea, mohsin.bashr, jacob.e.keller, willemb,
skhawaja, bestswngs, aleksandr.loktionov, kees, linux-doc,
linux-kernel, intel-wired-lan, linux-rdma, linux-wireless,
linux-kselftest, leon
In-Reply-To: <acP59NM6HZhV9oAe@mini-arch>
On 03/25, Stanislav Fomichev wrote:
> On 03/24, Jakub Kicinski wrote:
> > On Tue, 24 Mar 2026 15:49:27 -0700 Stanislav Fomichev wrote:
> > > > > Not sure why cancel+release, maybe you're thinking about the unregister
> > > > > path? This is rtnl_unlock -> netdev_run_todo -> __rtnl_unlock + some
> > > > > extras.
> > > > >
> > > > > And the flush is here to plumb the addresses to the real devices
> > > > > before we return to the callers. Mostly because of the following
> > > > > things we have in the tests:
> > > > >
> > > > > # TEST: team cleanup mode lacp [FAIL]
> > > > > # macvlan unicast address not found on a slave
> > > > >
> > > > > Can you explain a bit more on the suggestion?
> > > >
> > > > Oh, I thought it's here for unregister! Feels like it'd be cleaner to
> > > > add the flush in dev_*c_add() and friends? How hard would it be to
> > > > identify the callers in atomic context?
> > >
> > > Not sure we can do it in dev_xc_add because it runs under rtnl :-(
> > > I currently do flush in netdev_run_todo because that's the place that
> > > doesn't hold rtnl. Otherwise flush will get stuck because the work
> > > handler grabs it...
> >
> > I was thinking of something a'la linkwatch. We can "steal" / "flush"
> > the pending work inline. I guess linkwatch is a major source of races
> > over the years...
> >
> > Does the macvlan + team problem still happens with the current
> > implementation minus the flush? We are only flushing once so only
> > pushing the addresses thru one layer of async callbacks.
>
> Yes, it does happen consistently when I remove the flush. It also
> happens with my internal v4, so I need to look again at what's going on.
> Not sure whether it's my internal regression or I was just sloppy/lucky
> (since you're correct in pointing out that we flush only once).
Hmm, the test does 'team -d' in the background. That's why it works for
bonding, but not the teaming. I'll update the test to a bunch of
'ip' commands instead of starting a daemon..
> Before I went down the workqueue route, I had a simple
> net_todo_list-like approach: `list_add_tail` on enqueue and
> `while(!list_empty) run_work()` on rtnl_unlock. This had a nice properly of
> tracking re-submissions (by checking whether the device's list_head is
> linked into the list or not) and it was relatively easy to do the
> recursive flush. Let me try get back to this approach and see whether
> it solves the flush? Not sure what wq buys us at this point.
Will still look into that, maybe something similar to the linkwatch as
you mentioned.
^ permalink raw reply
* Re: [PATCH v8 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Jim Mattson @ 2026-03-25 17:50 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel, kvm, Asit Mallick,
Tao Zhang, bpf, netdev, linux-doc
In-Reply-To: <20260324-vmscape-bhb-v8-2-68bb524b3ab9@linux.intel.com>
On Tue, Mar 24, 2026 at 11:19 AM Pawan Gupta
<pawan.kumar.gupta@linux.intel.com> wrote:
>
> As a mitigation for BHI, clear_bhb_loop() executes branches that overwrites
> the Branch History Buffer (BHB). On Alder Lake and newer parts this
> sequence is not sufficient because it doesn't clear enough entries. This
> was not an issue because these CPUs have a hardware control (BHI_DIS_S)
> that mitigates BHI in kernel.
>
> BHI variant of VMSCAPE requires isolating branch history between guests and
> userspace. Note that there is no equivalent hardware control for userspace.
> To effectively isolate branch history on newer CPUs, clear_bhb_loop()
> should execute sufficient number of branches to clear a larger BHB.
>
> Dynamically set the loop count of clear_bhb_loop() such that it is
> effective on newer CPUs too. Use the hardware control enumeration
> X86_FEATURE_BHI_CTRL to select the appropriate loop count.
>
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
> arch/x86/entry/entry_64.S | 21 ++++++++++++++++-----
> arch/x86/net/bpf_jit_comp.c | 7 -------
> 2 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index 3a180a36ca0e..8128e00ca73f 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -1535,8 +1535,17 @@ SYM_CODE_END(rewind_stack_and_make_dead)
> SYM_FUNC_START(clear_bhb_loop)
> ANNOTATE_NOENDBR
> push %rbp
> + /* BPF caller may require %rax to be preserved */
> + push %rax
Shouldn't the "push %rax" come after "mov %rsp, %rbp"?
> mov %rsp, %rbp
> - movl $5, %ecx
^ permalink raw reply
* Re: [PATCH v3 4/5] KVM: arm64: Enable HDBSS support and handle HDBSSF events
From: Leonardo Bras @ 2026-03-25 18:05 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
will, yuzenghui, wangzhou1, liuyonglong, Jonathan.Cameron,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose
In-Reply-To: <20260225040421.2683931-5-zhengtian10@huawei.com>
Hello Tian,
I am currently working on HACDBS enablement(which will be rebased on top of
this patchset) and due to the fact HACDBS and HDBSS are kind of
complementary I will sometimes come with some questions for issues I have
faced myself on that part. :)
(see below)
On Wed, Feb 25, 2026 at 12:04:20PM +0800, Tian Zheng wrote:
> From: eillon <yezhenyu2@huawei.com>
>
> HDBSS is enabled via an ioctl from userspace (e.g. QEMU) at the start of
> migration. This feature is only supported in VHE mode.
>
> Initially, S2 PTEs doesn't contain the DBM attribute. During migration,
> write faults are handled by user_mem_abort, which relaxes permissions
> and adds the DBM bit when HDBSS is active. Once DBM is set, subsequent
> writes no longer trap, as the hardware automatically transitions the page
> from writable-clean to writable-dirty.
>
> KVM does not scan S2 page tables to consume DBM. Instead, when HDBSS is
> enabled, the hardware observes the clean->dirty transition and records
> the corresponding page into the HDBSS buffer.
>
> During sync_dirty_log, KVM kicks all vCPUs to force VM-Exit, ensuring
> that check_vcpu_requests flushes the HDBSS buffer and propagates the
> accumulated dirty information into the userspace-visible dirty bitmap.
>
> Add fault handling for HDBSS including buffer full, external abort, and
> general protection fault (GPF).
>
> Signed-off-by: eillon <yezhenyu2@huawei.com>
> Signed-off-by: Tian Zheng <zhengtian10@huawei.com>
> ---
> arch/arm64/include/asm/esr.h | 5 ++
> arch/arm64/include/asm/kvm_host.h | 17 +++++
> arch/arm64/include/asm/kvm_mmu.h | 1 +
> arch/arm64/include/asm/sysreg.h | 11 ++++
> arch/arm64/kvm/arm.c | 102 ++++++++++++++++++++++++++++++
> arch/arm64/kvm/hyp/vhe/switch.c | 19 ++++++
> arch/arm64/kvm/mmu.c | 70 ++++++++++++++++++++
> arch/arm64/kvm/reset.c | 3 +
> 8 files changed, 228 insertions(+)
>
> diff --git a/arch/arm64/include/asm/esr.h b/arch/arm64/include/asm/esr.h
> index 81c17320a588..2e6b679b5908 100644
> --- a/arch/arm64/include/asm/esr.h
> +++ b/arch/arm64/include/asm/esr.h
> @@ -437,6 +437,11 @@
> #ifndef __ASSEMBLER__
> #include <asm/types.h>
>
> +static inline bool esr_iss2_is_hdbssf(unsigned long esr)
> +{
> + return ESR_ELx_ISS2(esr) & ESR_ELx_HDBSSF;
> +}
> +
> static inline unsigned long esr_brk_comment(unsigned long esr)
> {
> return esr & ESR_ELx_BRK64_ISS_COMMENT_MASK;
> diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> index 5d5a3bbdb95e..57ee6b53e061 100644
> --- a/arch/arm64/include/asm/kvm_host.h
> +++ b/arch/arm64/include/asm/kvm_host.h
> @@ -55,12 +55,17 @@
> #define KVM_REQ_GUEST_HYP_IRQ_PENDING KVM_ARCH_REQ(9)
> #define KVM_REQ_MAP_L1_VNCR_EL2 KVM_ARCH_REQ(10)
> #define KVM_REQ_VGIC_PROCESS_UPDATE KVM_ARCH_REQ(11)
> +#define KVM_REQ_FLUSH_HDBSS KVM_ARCH_REQ(12)
>
> #define KVM_DIRTY_LOG_MANUAL_CAPS (KVM_DIRTY_LOG_MANUAL_PROTECT_ENABLE | \
> KVM_DIRTY_LOG_INITIALLY_SET)
>
> #define KVM_HAVE_MMU_RWLOCK
>
> +/* HDBSS entry field definitions */
> +#define HDBSS_ENTRY_VALID BIT(0)
> +#define HDBSS_ENTRY_IPA GENMASK_ULL(55, 12)
> +
> /*
> * Mode of operation configurable with kvm-arm.mode early param.
> * See Documentation/admin-guide/kernel-parameters.txt for more information.
> @@ -84,6 +89,7 @@ int __init kvm_arm_init_sve(void);
> u32 __attribute_const__ kvm_target_cpu(void);
> void kvm_reset_vcpu(struct kvm_vcpu *vcpu);
> void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu);
> +void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu);
>
> struct kvm_hyp_memcache {
> phys_addr_t head;
> @@ -405,6 +411,8 @@ struct kvm_arch {
> * the associated pKVM instance in the hypervisor.
> */
> struct kvm_protected_vm pkvm;
> +
> + bool enable_hdbss;
> };
>
> struct kvm_vcpu_fault_info {
> @@ -816,6 +824,12 @@ struct vcpu_reset_state {
> bool reset;
> };
>
> +struct vcpu_hdbss_state {
> + phys_addr_t base_phys;
> + u32 size;
> + u32 next_index;
> +};
> +
> struct vncr_tlb;
>
> struct kvm_vcpu_arch {
> @@ -920,6 +934,9 @@ struct kvm_vcpu_arch {
>
> /* Per-vcpu TLB for VNCR_EL2 -- NULL when !NV */
> struct vncr_tlb *vncr_tlb;
> +
> + /* HDBSS registers info */
> + struct vcpu_hdbss_state hdbss;
> };
>
> /*
> diff --git a/arch/arm64/include/asm/kvm_mmu.h b/arch/arm64/include/asm/kvm_mmu.h
> index d968aca0461a..3fea8cfe8869 100644
> --- a/arch/arm64/include/asm/kvm_mmu.h
> +++ b/arch/arm64/include/asm/kvm_mmu.h
> @@ -183,6 +183,7 @@ int kvm_phys_addr_ioremap(struct kvm *kvm, phys_addr_t guest_ipa,
>
> int kvm_handle_guest_sea(struct kvm_vcpu *vcpu);
> int kvm_handle_guest_abort(struct kvm_vcpu *vcpu);
> +void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu);
>
> phys_addr_t kvm_mmu_get_httbr(void);
> phys_addr_t kvm_get_idmap_vector(void);
> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
> index f4436ecc630c..d11f4d0dd4e7 100644
> --- a/arch/arm64/include/asm/sysreg.h
> +++ b/arch/arm64/include/asm/sysreg.h
> @@ -1039,6 +1039,17 @@
>
> #define GCS_CAP(x) ((((unsigned long)x) & GCS_CAP_ADDR_MASK) | \
> GCS_CAP_VALID_TOKEN)
> +
> +/*
> + * Definitions for the HDBSS feature
> + */
> +#define HDBSS_MAX_SIZE HDBSSBR_EL2_SZ_2MB
> +
> +#define HDBSSBR_EL2(baddr, sz) (((baddr) & GENMASK(55, 12 + sz)) | \
> + FIELD_PREP(HDBSSBR_EL2_SZ_MASK, sz))
> +
> +#define HDBSSPROD_IDX(prod) FIELD_GET(HDBSSPROD_EL2_INDEX_MASK, prod)
> +
> /*
> * Definitions for GICv5 instructions]
> */
> diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> index 29f0326f7e00..d64da05e25c4 100644
> --- a/arch/arm64/kvm/arm.c
> +++ b/arch/arm64/kvm/arm.c
> @@ -125,6 +125,87 @@ int kvm_arch_vcpu_should_kick(struct kvm_vcpu *vcpu)
> return kvm_vcpu_exiting_guest_mode(vcpu) == IN_GUEST_MODE;
> }
>
> +void kvm_arm_vcpu_free_hdbss(struct kvm_vcpu *vcpu)
> +{
> + struct page *hdbss_pg;
> +
> + hdbss_pg = phys_to_page(vcpu->arch.hdbss.base_phys);
> + if (hdbss_pg)
> + __free_pages(hdbss_pg, vcpu->arch.hdbss.size);
> +
> + vcpu->arch.hdbss.size = 0;
> +}
> +
> +static int kvm_cap_arm_enable_hdbss(struct kvm *kvm,
> + struct kvm_enable_cap *cap)
> +{
> + unsigned long i;
> + struct kvm_vcpu *vcpu;
> + struct page *hdbss_pg = NULL;
> + __u64 size = cap->args[0];
> + bool enable = cap->args[1] ? true : false;
> +
> + if (!system_supports_hdbss())
> + return -EINVAL;
> +
> + if (size > HDBSS_MAX_SIZE)
> + return -EINVAL;
> +
> + if (!enable && !kvm->arch.enable_hdbss) /* Already Off */
> + return 0;
> +
> + if (enable && kvm->arch.enable_hdbss) /* Already On, can't set size */
> + return -EINVAL;
> +
> + if (!enable) { /* Turn it off */
> + kvm->arch.mmu.vtcr &= ~(VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA);
> +
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + /* Kick vcpus to flush hdbss buffer. */
> + kvm_vcpu_kick(vcpu);
> +
> + kvm_arm_vcpu_free_hdbss(vcpu);
> + }
> +
> + kvm->arch.enable_hdbss = false;
> +
> + return 0;
> + }
> +
> + /* Turn it on */
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + hdbss_pg = alloc_pages(GFP_KERNEL_ACCOUNT, size);
> + if (!hdbss_pg)
> + goto error_alloc;
> +
> + vcpu->arch.hdbss = (struct vcpu_hdbss_state) {
> + .base_phys = page_to_phys(hdbss_pg),
> + .size = size,
> + .next_index = 0,
> + };
> + }
> +
> + kvm->arch.enable_hdbss = true;
> + kvm->arch.mmu.vtcr |= VTCR_EL2_HD | VTCR_EL2_HDBSS | VTCR_EL2_HA;
> +
> + /*
> + * We should kick vcpus out of guest mode here to load new
> + * vtcr value to vtcr_el2 register when re-enter guest mode.
> + */
> + kvm_for_each_vcpu(i, vcpu, kvm)
> + kvm_vcpu_kick(vcpu);
> +
> + return 0;
> +
> +error_alloc:
> + kvm_for_each_vcpu(i, vcpu, kvm) {
> + if (vcpu->arch.hdbss.base_phys)
> + kvm_arm_vcpu_free_hdbss(vcpu);
> + }
> +
> + return -ENOMEM;
> +}
> +
> int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> struct kvm_enable_cap *cap)
> {
> @@ -182,6 +263,11 @@ int kvm_vm_ioctl_enable_cap(struct kvm *kvm,
> r = 0;
> set_bit(KVM_ARCH_FLAG_EXIT_SEA, &kvm->arch.flags);
> break;
> + case KVM_CAP_ARM_HW_DIRTY_STATE_TRACK:
> + mutex_lock(&kvm->lock);
> + r = kvm_cap_arm_enable_hdbss(kvm, cap);
> + mutex_unlock(&kvm->lock);
> + break;
> default:
> break;
> }
> @@ -471,6 +557,9 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long ext)
> r = kvm_supports_cacheable_pfnmap();
> break;
>
> + case KVM_CAP_ARM_HW_DIRTY_STATE_TRACK:
> + r = system_supports_hdbss();
> + break;
> default:
> r = 0;
> }
> @@ -1120,6 +1209,9 @@ static int check_vcpu_requests(struct kvm_vcpu *vcpu)
> if (kvm_dirty_ring_check_request(vcpu))
> return 0;
>
> + if (kvm_check_request(KVM_REQ_FLUSH_HDBSS, vcpu))
> + kvm_flush_hdbss_buffer(vcpu);
> +
> check_nested_vcpu_requests(vcpu);
> }
>
> @@ -1898,7 +1990,17 @@ long kvm_arch_vcpu_unlocked_ioctl(struct file *filp, unsigned int ioctl,
>
> void kvm_arch_sync_dirty_log(struct kvm *kvm, struct kvm_memory_slot *memslot)
> {
> + /*
> + * Flush all CPUs' dirty log buffers to the dirty_bitmap. Called
> + * before reporting dirty_bitmap to userspace. Send a request with
> + * KVM_REQUEST_WAIT to flush buffer synchronously.
> + */
> + struct kvm_vcpu *vcpu;
> +
> + if (!kvm->arch.enable_hdbss)
> + return;
>
> + kvm_make_all_cpus_request(kvm, KVM_REQ_FLUSH_HDBSS);
> }
>
> static int kvm_vm_ioctl_set_device_addr(struct kvm *kvm,
> diff --git a/arch/arm64/kvm/hyp/vhe/switch.c b/arch/arm64/kvm/hyp/vhe/switch.c
> index 9db3f11a4754..600cbc4f8ae9 100644
> --- a/arch/arm64/kvm/hyp/vhe/switch.c
> +++ b/arch/arm64/kvm/hyp/vhe/switch.c
> @@ -213,6 +213,23 @@ static void __vcpu_put_deactivate_traps(struct kvm_vcpu *vcpu)
> local_irq_restore(flags);
> }
>
> +static void __load_hdbss(struct kvm_vcpu *vcpu)
> +{
> + struct kvm *kvm = vcpu->kvm;
> + u64 br_el2, prod_el2;
> +
> + if (!kvm->arch.enable_hdbss)
> + return;
> +
> + br_el2 = HDBSSBR_EL2(vcpu->arch.hdbss.base_phys, vcpu->arch.hdbss.size);
> + prod_el2 = vcpu->arch.hdbss.next_index;
> +
> + write_sysreg_s(br_el2, SYS_HDBSSBR_EL2);
> + write_sysreg_s(prod_el2, SYS_HDBSSPROD_EL2);
> +
> + isb();
> +}
> +
I see in the code below you trust that the tracking will happen with
PAGE_SIZE granularity (you track with PAGE_SHIFT).
That may be a problem when we have guest memory backed by hugepages or
transparent huge pages.
When we are using HDBSS, there is no fault happening, so we have no way of
doing on-demand block splitting, so we need to make use of eager block
splitting, _before_ we start to track anything, or else we may have
different-sized pages in the HDBSS buffer, which is harder to deal with.
Suggestion: do the eager splitting before we enable HDBSS.
For this to happen, we have to enable the EAGER_SPLIT_CHUNK_SIZE
capability, which can only be enabled when all memslots are empty.
I suggest doing that at kvm_init_stage2_mmu(), and checking if HDBSS is
in which case we set mmu->split_page_chunk_size to PAGESIZE.
I will send a patch you can put before this one to make sure it works :)
Thanks!
Leo
> void kvm_vcpu_load_vhe(struct kvm_vcpu *vcpu)
> {
> host_data_ptr(host_ctxt)->__hyp_running_vcpu = vcpu;
> @@ -220,10 +237,12 @@ void kvm_vcpu_load_vhe(struct kvm_vcpu *vcpu)
> __vcpu_load_switch_sysregs(vcpu);
> __vcpu_load_activate_traps(vcpu);
> __load_stage2(vcpu->arch.hw_mmu, vcpu->arch.hw_mmu->arch);
> + __load_hdbss(vcpu);
> }
>
> void kvm_vcpu_put_vhe(struct kvm_vcpu *vcpu)
> {
> + kvm_flush_hdbss_buffer(vcpu);
> __vcpu_put_deactivate_traps(vcpu);
> __vcpu_put_switch_sysregs(vcpu);
>
> diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
> index 070a01e53fcb..42b0710a16ce 100644
> --- a/arch/arm64/kvm/mmu.c
> +++ b/arch/arm64/kvm/mmu.c
> @@ -1896,6 +1896,9 @@ static int user_mem_abort(struct kvm_vcpu *vcpu, phys_addr_t fault_ipa,
> if (writable)
> prot |= KVM_PGTABLE_PROT_W;
>
> + if (writable && kvm->arch.enable_hdbss && logging_active)
> + prot |= KVM_PGTABLE_PROT_DBM;
> +
> if (exec_fault)
> prot |= KVM_PGTABLE_PROT_X;
>
> @@ -2033,6 +2036,70 @@ int kvm_handle_guest_sea(struct kvm_vcpu *vcpu)
> return 0;
> }
>
> +void kvm_flush_hdbss_buffer(struct kvm_vcpu *vcpu)
> +{
> + int idx, curr_idx;
> + u64 br_el2;
> + u64 *hdbss_buf;
> + struct kvm *kvm = vcpu->kvm;
> +
> + if (!kvm->arch.enable_hdbss)
> + return;
> +
> + curr_idx = HDBSSPROD_IDX(read_sysreg_s(SYS_HDBSSPROD_EL2));
> + br_el2 = HDBSSBR_EL2(vcpu->arch.hdbss.base_phys, vcpu->arch.hdbss.size);
> +
> + /* Do nothing if HDBSS buffer is empty or br_el2 is NULL */
> + if (curr_idx == 0 || br_el2 == 0)
> + return;
> +
> + hdbss_buf = page_address(phys_to_page(vcpu->arch.hdbss.base_phys));
> + if (!hdbss_buf)
> + return;
> +
> + guard(write_lock_irqsave)(&vcpu->kvm->mmu_lock);
> + for (idx = 0; idx < curr_idx; idx++) {
> + u64 gpa;
> +
> + gpa = hdbss_buf[idx];
> + if (!(gpa & HDBSS_ENTRY_VALID))
> + continue;
> +
> + gpa &= HDBSS_ENTRY_IPA;
> + kvm_vcpu_mark_page_dirty(vcpu, gpa >> PAGE_SHIFT);
> + }
Here ^
> +
> + /* reset HDBSS index */
> + write_sysreg_s(0, SYS_HDBSSPROD_EL2);
> + vcpu->arch.hdbss.next_index = 0;
> + isb();
> +}
> +
> +static int kvm_handle_hdbss_fault(struct kvm_vcpu *vcpu)
> +{
> + u64 prod;
> + u64 fsc;
> +
> + prod = read_sysreg_s(SYS_HDBSSPROD_EL2);
> + fsc = FIELD_GET(HDBSSPROD_EL2_FSC_MASK, prod);
> +
> + switch (fsc) {
> + case HDBSSPROD_EL2_FSC_OK:
> + /* Buffer full, which is reported as permission fault. */
> + kvm_flush_hdbss_buffer(vcpu);
> + return 1;
> + case HDBSSPROD_EL2_FSC_ExternalAbort:
> + case HDBSSPROD_EL2_FSC_GPF:
> + return -EFAULT;
> + default:
> + /* Unknown fault. */
> + WARN_ONCE(1,
> + "Unexpected HDBSS fault type, FSC: 0x%llx (prod=0x%llx, vcpu=%d)\n",
> + fsc, prod, vcpu->vcpu_id);
> + return -EFAULT;
> + }
> +}
> +
> /**
> * kvm_handle_guest_abort - handles all 2nd stage aborts
> * @vcpu: the VCPU pointer
> @@ -2071,6 +2138,9 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu)
>
> is_iabt = kvm_vcpu_trap_is_iabt(vcpu);
>
> + if (esr_iss2_is_hdbssf(esr))
> + return kvm_handle_hdbss_fault(vcpu);
> +
> if (esr_fsc_is_translation_fault(esr)) {
> /* Beyond sanitised PARange (which is the IPA limit) */
> if (fault_ipa >= BIT_ULL(get_kvm_ipa_limit())) {
> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
> index 959532422d3a..c03a4b310b53 100644
> --- a/arch/arm64/kvm/reset.c
> +++ b/arch/arm64/kvm/reset.c
> @@ -161,6 +161,9 @@ void kvm_arm_vcpu_destroy(struct kvm_vcpu *vcpu)
> free_page((unsigned long)vcpu->arch.ctxt.vncr_array);
> kfree(vcpu->arch.vncr_tlb);
> kfree(vcpu->arch.ccsidr);
> +
> + if (vcpu->kvm->arch.enable_hdbss)
> + kvm_arm_vcpu_free_hdbss(vcpu);
> }
>
> static void kvm_vcpu_reset_sve(struct kvm_vcpu *vcpu)
> --
> 2.33.0
>
^ permalink raw reply
* [PATCH] arm64/kvm: Enable eager hugepage splitting if HDBSS is available
From: Leonardo Bras @ 2026-03-25 18:20 UTC (permalink / raw)
To: Tian Zheng
Cc: Leonardo Bras, maz, oupton, catalin.marinas, corbet, pbonzini,
will, yuzenghui, wangzhou1, liuyonglong, Jonathan.Cameron,
yezhenyu2, linuxarm, joey.gouly, kvmarm, kvm, linux-arm-kernel,
linux-doc, linux-kernel, skhan, suzuki.poulose
In-Reply-To: <acQj5grOdZT8LUGp@devkitleo>
FEAT_HDBSS speeds up guest memory dirty tracking by avoiding a page fault
and saving the entry in a tracking structure.
That may be a problem when we have guest memory backed by hugepages or
transparent huge pages, as it's not possible to do on-demand hugepage
splitting, relying only on eager hugepage splitting.
So, at stage2 initialization, enable eager hugepage splitting with
chunk = PAGE_SIZE if the system supports HDBSS.
Signed-off-by: Leonardo Bras <leo.bras@arm.com>
---
arch/arm64/kvm/mmu.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kvm/mmu.c b/arch/arm64/kvm/mmu.c
index 070a01e53fcb..bdfa72b7c073 100644
--- a/arch/arm64/kvm/mmu.c
+++ b/arch/arm64/kvm/mmu.c
@@ -993,22 +993,26 @@ int kvm_init_stage2_mmu(struct kvm *kvm, struct kvm_s2_mmu *mmu, unsigned long t
mmu->last_vcpu_ran = alloc_percpu(typeof(*mmu->last_vcpu_ran));
if (!mmu->last_vcpu_ran) {
err = -ENOMEM;
goto out_destroy_pgtable;
}
for_each_possible_cpu(cpu)
*per_cpu_ptr(mmu->last_vcpu_ran, cpu) = -1;
- /* The eager page splitting is disabled by default */
- mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
+ /* The eager page splitting is disabled by default if system has no HDBSS */
+ if (system_supports_hacdbs())
+ mmu->split_page_chunk_size = PAGE_SIZE;
+ else
+ mmu->split_page_chunk_size = KVM_ARM_EAGER_SPLIT_CHUNK_SIZE_DEFAULT;
+
mmu->split_page_cache.gfp_zero = __GFP_ZERO;
mmu->pgd_phys = __pa(pgt->pgd);
if (kvm_is_nested_s2_mmu(kvm, mmu))
kvm_init_nested_s2_mmu(mmu);
return 0;
out_destroy_pgtable:
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v5 00/21] Virtual Swap Space
From: YoungJun Park @ 2026-03-25 18:36 UTC (permalink / raw)
To: Nhat Pham
Cc: kasong, Liam.Howlett, akpm, apopple, axelrasmussen, baohua,
baolin.wang, bhe, byungchul, cgroups, chengming.zhou, chrisl,
corbet, david, dev.jain, gourry, hannes, hughd, jannh,
joshua.hahnjy, lance.yang, lenb, linux-doc, linux-kernel,
linux-mm, linux-pm, lorenzo.stoakes, matthew.brost, mhocko,
muchun.song, npache, pavel, peterx, peterz, pfalcato, rafael,
rakie.kim, roman.gushchin, rppt, ryan.roberts, shakeel.butt,
shikemeng, surenb, tglx, vbabka, weixugc, ying.huang, yosry.ahmed,
yuanchu, zhengqi.arch, ziy, kernel-team, riel
In-Reply-To: <20260320192735.748051-1-nphamcs@gmail.com>
On Fri, Mar 20, 2026 at 12:27:14PM -0700, Nhat Pham wrote:
>
> This patch series is based on 6.19. There are a couple more
> swap-related changes in mainline that I would need to coordinate
> with, but I still want to send this out as an update for the
> regressions reported by Kairui Song in [15]. It's probably easier
> to just build this thing rather than dig through that series of
> emails to get the fix patch :)
Hi Nhat,
I wanted to fully understand the patches before asking questions,
but reviewing everything takes time, and I didn't want to miss the
timing. So let me share some thoughts and ask about your direction.
These are the perspectives I'm coming from:
Pros:
- The architecture is very clean.
- Zero entries currently consume swap space, which can prevent
actual swap usage in some cases.
- It resolves zswap's dependency on swap device size.
- And so on.
Cons:
- An additional virtual allocation step is introduced per every swap.
- not easy to merge (change swap infrastructure totally?)
To address the cons, I think if we can demonstrate that the
benefits always outweigh the costs, it could fully replace the
existing mechanism. However, if this can be applied selectively,
we get only the pros without the cons.
1. Modularization
You removed CONFIG_* and went with a unified approach. I recall
you were also considering a module-based structure at some point.
What are your thoughts on that direction?
If we take that approach, we could extend the recent swap ops
patchset (https://lore.kernel.org/linux-mm/20260302104016.163542-1-bhe@redhat.com/)
as follows:
- Make vswap a swap module
- Have cluster allocation functions reside in swapops
- Enable vswap through swapon
I think this could result in a similar structure. An additional
benefit would be that it enables various configurations:
- vswap + regular swap together
- vswap only
- And other combinations
And merge is not that hard. it is not the total change of swap infra structure.
But, swapoff fastness might disappear? it is not that critical as I think.
2. Flash-friendly swap integration (for my use case)
I've been thinking about the flash-friendly swap concept that
I mentioned before and recently proposed:
(https://lore.kernel.org/linux-mm/aZW0voL4MmnMQlaR@yjaykim-PowerEdge-T330/)
One of its core functions requires buffering RAM-swapped pages
and writing them sequentially at an appropriate time -- not
immediately, but in proper block-sized units, sequentially.
This means allocated offsets must essentially be virtual, and
physical offsets need to be managed separately at the actual
write time.
If we integrate this into the current vswap, we would either
need vswap itself to handle the sequential writes (bypassing
the physical device and receiving pages directly), or swapon
a swap device and have vswap obtain physical offsets from it.
But since those offsets cannot be used directly (due to
buffering and sequential write requirements), they become
virtual too, resulting in:
virtual -> virtual -> physical
This triple indirection is not ideal.
However, if the modularization from point 1 is achieved and
vswap acts as a swap device itself, then we can cleanly
establish a:
virtual -> physical
relationship within it.
I noticed you seem to be exploring collaboration with Kairui
as well. I'm curious whether you have a compromise direction
in mind, or if you plan to stick with the current approach.
P.S. I definitely want to review the vswap code in detail
when I get the time. great work and code.
Thanks,
Youngjun Park
^ permalink raw reply
* Re: [PATCH v3] docs: driver-api: fix 6 spelling typos in Documentation/driver-api
From: Jonathan Corbet @ 2026-03-25 18:36 UTC (permalink / raw)
To: Tomás Pando
Cc: skhan, linux-doc, linux-kernel, Tomás Pando, Randy Dunlap
In-Reply-To: <20260324163604.5710-1-tovictakamine@gmail.com>
Tomás Pando <tovictakamine@gmail.com> writes:
> Fix minor spelling mistakes in the driver-api documentation. These
> changes improve readability in ACPI, CXL, DMA and PCI docs.
> v3: Added reviewed-by from Randy Dunlap.
> v2: Added full name as requested by Jon Corbet.
>
> Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
> Signed-off-by: Tomás Pando <tovictakamine@gmail.com>
> ---
> Documentation/driver-api/acpi/acpi-drivers.rst | 2 +-
> Documentation/driver-api/cxl/platform/acpi/cedt.rst | 2 +-
> Documentation/driver-api/cxl/platform/bios-and-efi.rst | 2 +-
> Documentation/driver-api/dmaengine/pxa_dma.rst | 2 +-
> Documentation/driver-api/libata.rst | 2 +-
> Documentation/driver-api/pci/p2pdma.rst | 2 +-
> 6 files changed, 6 insertions(+), 6 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Ville Syrjälä @ 2026-03-25 18:43 UTC (permalink / raw)
To: Maxime Ripard
Cc: Nicolas Frattaroli, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <20260325-magnificent-ultraviolet-oarfish-baefbc@houat>
On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > +enum drm_connector_color_format {
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > + * semantics.
> > > > > > > + *
> > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > + * YCbCr 4:2:0.
> > > > > > > + *
> > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > + * how HDMI does it).
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > + * not subsampled)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > + * with horizontal subsampling)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > +
> > > > > > > + /**
> > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > + */
> > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > >
> > > > > > Seems like this should document what the quantization range
> > > > > > should be for each format.
> > > > > >
> > > > >
> > > > > I don't think so? If you want per-component bit depth values,
> > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > enum is more abstract than that, and is there to communicate
> > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > by other properties.
> > > > >
> > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > be added; no digital display protocol standard supports it to my
> > > > > knowledge, and hopefully none ever will.
> > > >
> > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > >
> > > > The i915 behaviour is that YCbCr is always limited range,
> > > > RGB can either be full or limited range depending on the
> > > > "Broadcast RGB" property and other related factors.
> > >
> > > So far the HDMI state has both the format and quantization range as
> > > different fields. I'm not sure we need to document the range in the
> > > format field, maybe only mention it's not part of the format but has a
> > > field of its own?
> >
> > I think we only have it for RGB (on some drivers only?). For YCbCr
> > I think the assumption is limited range everywhere.
> >
> > But I'm not really concerned about documenting struct members.
> > What I'm talking about is the *uapi* docs. Surely userspace
> > will want to know what the new property actually does so the
> > uapi needs to be documented properly. And down the line some
> > new driver might also implement the wrong behaviour if there
> > is no clear specification.
>
> Ack
>
> > So I'm thinking (or perhaps hoping) the rule might be something like:
> > - YCbCr limited range
> > - RGB full range if "Broadcast RGB" property is not present
>
> Isn't it much more complicated than that for HDMI though? My
> recollection was that any VIC but VIC1 would be limited range, and
> anything else full range?
Do we have some driver that implements the CTA-861 CE vs. IT mode
logic but doesn't expose the "Broadcast RGB" property? I was hoping
those would always go hand in hand now.
>
> > - RGB full or limited range based on the "Broadcast RGB" property
> > if it's present
> >
> > I think the "Broadcast RGB" property itself might also be lacking
> > proper uapi docs, so that may need to be remedied as well.
>
> I took care of documenting it when merging the HDMI helpers:
> https://docs.kernel.org/gpu/drm-kms.html#hdmi-specific-connector-properties
>
> Maxime
--
Ville Syrjälä
Intel
^ permalink raw reply
* Re: [PATCH v8 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-03-25 18:44 UTC (permalink / raw)
To: Jim Mattson
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Borislav Petkov, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
David Laight, Andy Lutomirski, Thomas Gleixner, Ingo Molnar,
David Ahern, Martin KaFai Lau, Eduard Zingerman, Song Liu,
Yonghong Song, John Fastabend, Stanislav Fomichev, Hao Luo,
Paolo Bonzini, Jonathan Corbet, linux-kernel, kvm, Asit Mallick,
Tao Zhang, bpf, netdev, linux-doc
In-Reply-To: <CALMp9eTZRucL+CUSp1yUPG0aSTpyQ=po1EmurZhX9+R+vxgbPA@mail.gmail.com>
On Wed, Mar 25, 2026 at 10:50:58AM -0700, Jim Mattson wrote:
> On Tue, Mar 24, 2026 at 11:19 AM Pawan Gupta
> <pawan.kumar.gupta@linux.intel.com> wrote:
> >
> > As a mitigation for BHI, clear_bhb_loop() executes branches that overwrites
> > the Branch History Buffer (BHB). On Alder Lake and newer parts this
> > sequence is not sufficient because it doesn't clear enough entries. This
> > was not an issue because these CPUs have a hardware control (BHI_DIS_S)
> > that mitigates BHI in kernel.
> >
> > BHI variant of VMSCAPE requires isolating branch history between guests and
> > userspace. Note that there is no equivalent hardware control for userspace.
> > To effectively isolate branch history on newer CPUs, clear_bhb_loop()
> > should execute sufficient number of branches to clear a larger BHB.
> >
> > Dynamically set the loop count of clear_bhb_loop() such that it is
> > effective on newer CPUs too. Use the hardware control enumeration
> > X86_FEATURE_BHI_CTRL to select the appropriate loop count.
> >
> > Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> > Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > ---
> > arch/x86/entry/entry_64.S | 21 ++++++++++++++++-----
> > arch/x86/net/bpf_jit_comp.c | 7 -------
> > 2 files changed, 16 insertions(+), 12 deletions(-)
> >
> > diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> > index 3a180a36ca0e..8128e00ca73f 100644
> > --- a/arch/x86/entry/entry_64.S
> > +++ b/arch/x86/entry/entry_64.S
> > @@ -1535,8 +1535,17 @@ SYM_CODE_END(rewind_stack_and_make_dead)
> > SYM_FUNC_START(clear_bhb_loop)
> > ANNOTATE_NOENDBR
> > push %rbp
> > + /* BPF caller may require %rax to be preserved */
> > + push %rax
>
> Shouldn't the "push %rax" come after "mov %rsp, %rbp"?
Right, thanks for catching that.
> > mov %rsp, %rbp
> > - movl $5, %ecx
^ 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