* [PATCH v1] docs/ja_JP: translate more of submitting-patches.rst
From: Akiyoshi Kurita @ 2026-05-04 18:24 UTC (permalink / raw)
To: linux-doc; +Cc: linux-kernel, corbet, akiyks, Akiyoshi Kurita
Translate the "No MIME, no links, no compression, no attachments.
Just plain text" and "Respond to review comments" sections in
Documentation/translations/ja_JP/process/submitting-patches.rst.
Keep the wording close to the English text and wrap lines to match
the style used in the surrounding Japanese translation.
Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org>
---
.../ja_JP/process/submitting-patches.rst | 58 +++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/Documentation/translations/ja_JP/process/submitting-patches.rst b/Documentation/translations/ja_JP/process/submitting-patches.rst
index 928e38a8d34d..d7e04c09f951 100644
--- a/Documentation/translations/ja_JP/process/submitting-patches.rst
+++ b/Documentation/translations/ja_JP/process/submitting-patches.rst
@@ -292,3 +292,61 @@ MAINTAINERS ファイルに記載されている MAN-PAGES メンテナに
man-pages パッチ、少なくとも変更の通知を送って、情報が
マニュアルページに反映されるようにしてください。ユーザー空間 API の
変更は、linux-api@vger.kernel.org にも Cc してください。
+
+MIME、リンク、圧縮、添付ファイルは使わない。プレーンテキストだけ
+----------------------------------------------------------------------
+
+Linus や他のカーネル開発者は、あなたが投稿する変更を読み、
+コメントできる必要があります。カーネル開発者が標準的な
+メールツールを使ってあなたの変更を「引用」し、コードの特定の
+箇所についてコメントできることが重要です。
+
+このため、すべてのパッチはメール本文中に ``inline`` で投稿すべきです。
+これを行う最も簡単な方法は ``git send-email`` を使うことであり、
+強く推奨されます。``git send-email`` の対話型チュートリアルは
+https://git-send-email.io で利用できます。
+
+``git send-email`` を使わないことを選ぶ場合:
+
+.. warning::
+
+ パッチをコピー＆ペーストする場合は、エディタの word-wrap によって
+ パッチが壊れないよう注意してください。
+
+圧縮の有無にかかわらず、パッチを MIME 添付ファイルとして添付しては
+いけません。多くの一般的なメールアプリケーションは、MIME 添付
+ファイルを常にプレーンテキストとして送信するとは限らず、あなたの
+コードにコメントできなくなります。MIME 添付ファイルは Linus が
+処理するのにも少し余分な時間がかかるため、MIME 添付された変更が
+受け入れられる可能性を下げます。
+
+例外: メーラがパッチを壊してしまう場合は、誰かから MIME を使って
+再送するよう求められることがあります。
+
+パッチを変更せずに送信するようメールクライアントを設定するための
+ヒントについては、Documentation/process/email-clients.rst を参照してください。
+
+
+レビューコメントに返答する
+--------------------------
+
+あなたのパッチには、ほぼ確実に、パッチを改善する方法について
+レビューアからコメントが付きます。それは、あなたのメールへの返信という
+形で届きます。それらのコメントには必ず返答してください。レビューアを
+無視することは、こちらも無視されるためのよい方法です。コメントに
+答えるには、単にそのメールへ返信すれば構いません。コード変更に
+つながらないレビューコメントや質問であっても、次のレビューアが状況を
+よりよく理解できるように、ほぼ確実にコメントまたは changelog エントリに
+反映すべきです。
+
+どのような変更を行うのかをレビューアに必ず伝え、時間を割いてくれた
+ことに感謝してください。コードレビューは疲れる、時間のかかる作業であり、
+レビューアが不機嫌になることもあります。そのような場合であっても、
+丁寧に返答し、指摘された問題に対応してください。次の版を送るときは、
+cover letter または個々のパッチに ``patch changelog`` を追加し、前回の
+投稿との差分を説明してください（:ref:`the_canonical_patch_format` を
+参照してください）。あなたのパッチにコメントした人には、パッチの Cc
+リストに追加して、新しい版を知らせてください。
+
+メールクライアントとメーリングリストでの作法についての推奨事項は、
+Documentation/process/email-clients.rst を参照してください。
--
2.47.3
^ permalink raw reply related
* Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
From: Jeff Barnes @ 2026-05-04 18:12 UTC (permalink / raw)
To: Eric Biggers
Cc: Jon Kohler, linux-crypto@vger.kernel.org, Herbert Xu,
linux-doc@vger.kernel.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Linus Torvalds
In-Reply-To: <20260504173952.GA2291@sol>
On May 4 2026, at 1:39 pm, Eric Biggers <ebiggers@kernel.org> wrote:
>
> That seems to be an implementation of FIPS 140-3's integrity self-check.
> A few observations:
>
> - It could easily use userspace SHA-512 code instead. If including
> libcrypto.so in the "FIPS cryptographic boundary" would cause
> certification difficulties, then a sha512.c file could simply be added
> to 'libkcapi-hmaccalc' which is already in it.
Indeed expanding the crypto boundary to include libcrypto.so would cause
certification difficulties, it would mean certifying all of libcrypto.so
with the kernel. There *may* be a case for saying that it is outside the
module boundary but only if:
* The integrity mechanism is clearly external
* The cryptographic module refuses to operate unless integrity is confirmed
* The trust relationship is clearly documented
I don't see how this could be justified cleanly without significant pushback.
>
> - It's compatible with all of the proposed hardening. It doesn't
> require zero-copy performance. It runs as root, so it would be
> compatible with a capability check. "hmac(sha512)" will need to be on
> the algorithm allowlist anyway for iwd.
>
> - FIPS 140-3 might also allow it to be simplified to use a plain hash
> instead of pointlessly using HMAC with a fixed key.
FIPS 140‑3 (via ISO/IEC 19790) draws a hard distinction between:
* Integrity checking (cryptographic protection)
* Integrity measurement (detection only)
A plain hash provides no protection against an attacker who can modify
both the object and its reference hash.
>
> By the way, also on the topic of FIPS 140-3, some people do use AF_ALG
> for ACVP (even though it's not all that great for that purpose, either).
> But ACVP is a testing thing, not something that is needed on production
> systems. ACVP can just be run as root on a testing build; there's no
> need to enable support for it in the actual production build.
Agreed it's not a good use case. Unless/until pkcs1 is supported, I
don't see how you can use it for all of the test cases. Plus as
evidenced by Ubuntu's new cert, it requires validating the library.
>
> - Eric
>
^ permalink raw reply
* Re: [PATCH v3 17/20] drm/drv: Switch skeleton to drm_mode_config_create_initial_state()
From: Laurent Pinchart @ 2026-05-04 18:02 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-17-8b68d9db0d8b@kernel.org>
On Fri, Apr 24, 2026 at 12:18:57PM +0200, Maxime Ripard wrote:
> The driver skeleton currently recommends calling
> drm_mode_config_reset() at probe time to create the initial state.
>
> Now that drm_mode_config_create_initial_state() exists to handle
> initial state allocation without hardware side effects, update the
> skeleton to recommend it instead.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_drv.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 985c283cf59f..f537556b06a8 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -340,11 +340,13 @@ void drm_minor_release(struct drm_minor *minor)
> *
> * // Further setup, display pipeline etc
> *
> * platform_set_drvdata(pdev, drm);
> *
> - * drm_mode_config_reset(drm);
> + * ret = drm_mode_config_create_initial_state(drm);
> + * if (ret)
> + * return ret;
There's one point I'm still not sure to understand properly. The
skeleton example (and the tidss driver, which you convert to the new API
in this series) both call drm_mode_config_helper_resume(). This in turn
calls drm_atomic_helper_resume(), and drm_mode_config_reset(). For
drivers that implement .atomic_create_state() instead of .reset() (such
as tidss, after its conversion in this series), drm_mode_config_reset()
will call the drm_mode_config_*_create_state() helpers, which allocate
and initialize a new state (through .atomic_create_state()), and store
that new state in the object's ->state field. Won't this leak the state
previously stored there ?
> *
> * ret = drm_dev_register(drm);
> * if (ret)
> * return ret;
> *
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 18/20] drm/tidss: Switch to drm_mode_config_create_initial_state()
From: Laurent Pinchart @ 2026-05-04 17:49 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-18-8b68d9db0d8b@kernel.org>
Hi Maxime,
Thank you for the patch.
On Fri, Apr 24, 2026 at 12:18:58PM +0200, Maxime Ripard wrote:
> Now that drm_mode_config_create_initial_state() exists to create the
> initial state, use it instead of drm_mode_config_reset() during
> driver probe.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/tidss/tidss_drv.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/tidss/tidss_drv.c b/drivers/gpu/drm/tidss/tidss_drv.c
> index 1c8cc18bc53c..f5099d5d6e32 100644
> --- a/drivers/gpu/drm/tidss/tidss_drv.c
> +++ b/drivers/gpu/drm/tidss/tidss_drv.c
> @@ -169,11 +169,15 @@ static int tidss_probe(struct platform_device *pdev)
> goto err_runtime_suspend;
> }
>
> drm_kms_helper_poll_init(ddev);
>
> - drm_mode_config_reset(ddev);
> + ret = drm_mode_config_create_initial_state(ddev);
> + if (ret) {
> + dev_err(dev, "failed to create initial state: %d\n", ret);
> + goto err_irq_uninstall;
> + }
There's also a call to drm_mode_config_reset() in tidss_modeset_init(),
shouldn't it be dropped ?
>
> ret = drm_dev_register(ddev, 0);
> if (ret) {
> dev_err(dev, "failed to register DRM device\n");
> goto err_irq_uninstall;
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 16/20] drm/mode-config: Create drm_mode_config_create_initial_state()
From: Laurent Pinchart @ 2026-05-04 17:41 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-16-8b68d9db0d8b@kernel.org>
On Fri, Apr 24, 2026 at 12:18:56PM +0200, Maxime Ripard wrote:
> drm_mode_config_reset() can be used to create the initial state, but
> also to return to the initial state, when doing a suspend/resume cycle
> for example.
>
> It also affects both the software and the hardware, and drivers can
> choose to reset the hardware as well. Most will just create an empty
> state and the synchronisation between hardware and software states will
> effectively be done when the first commit is done.
>
> That dual role can be harmful, since some objects do need to be
> initialized but also need to be preserved across a suspend/resume cycle.
> drm_private_obj are such objects for example.
>
> Thus, create another helper for drivers to call to initialize their
> state when the driver is loaded, so we can make
> drm_mode_config_reset() only about handling suspend/resume and similar.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic.c | 12 +++++-
> drivers/gpu/drm/drm_mode_config.c | 87 +++++++++++++++++++++++++++++++++++++++
> include/drm/drm_mode_config.h | 1 +
> 3 files changed, 98 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 253a00f450b0..f31b6147e682 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -59,12 +59,20 @@
> * when preparing the update and kept alive as long as they are active
> * in the device.
> *
> * Their respective lifetimes are:
> *
> - * - at reset time, the object reset implementation will allocate a new
> - * default state and will store it in the object state pointer.
> + * - at driver initialization time, the driver will allocate an initial,
> + * pristine, state and will store it using
> + * drm_mode_config_create_initial_state().
I think it's useful to keep documented where the state is stored.
* - at driver initialization time, the driver will call
* drm_mode_config_create_initial_state() to allocate an initial, pristine,
* state and store in the object state pointer.
> Historically, this was one
> + * of drm_mode_config_reset() job, so one might still encounter it in
> + * a driver.
> + *
> + * - at reset time, for example during suspend/resume,
> + * drm_mode_config_reset() will reset the software and hardware state
> + * to a known default and will store it in the object's state pointer.
> + * Not all objects are affected by drm_mode_config_reset() though.
Does the reset implementation store a new state in the object's state
pointer, or does it reset the contents of the already allocated state ?
I read the documentation here as meaning the former, if it's actually
the latter it should be reworded.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> *
> * - whenever a new update is needed:
> *
> * + A new &struct drm_atomic_state is allocated using
> * drm_atomic_state_alloc().
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index 92ff907f2485..a43eb825671b 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -21,10 +21,11 @@
> */
>
> #include <linux/export.h>
> #include <linux/uaccess.h>
>
> +#include <drm/drm_atomic.h>
> #include <drm/drm_drv.h>
> #include <drm/drm_encoder.h>
> #include <drm/drm_file.h>
> #include <drm/drm_framebuffer.h>
> #include <drm/drm_managed.h>
> @@ -281,10 +282,96 @@ void drm_mode_config_reset(struct drm_device *dev)
> }
> drm_connector_list_iter_end(&conn_iter);
> }
> EXPORT_SYMBOL(drm_mode_config_reset);
>
> +/**
> + * drm_mode_config_create_initial_state - Allocates the initial state
s/Allocates/Allocate/
> + * @dev: drm device
> + *
> + * This functions creates the initial state for all the objects. Drivers
> + * can use this in e.g. probe to initialize their software state.
> + *
> + * It has two main differences with drm_mode_config_reset(): the reset()
> + * hooks aren't called and thus the hardware will be left untouched, but
> + * also the &drm_private_obj structures will be initialized as opposed
> + * to drm_mode_config_reset() that skips them.
> + *
> + * Returns: 0 on success, negative error value on failure.
> + */
> +int drm_mode_config_create_initial_state(struct drm_device *dev)
> +{
> + struct drm_crtc *crtc;
> + struct drm_colorop *colorop;
> + struct drm_plane *plane;
> + struct drm_connector *connector;
> + struct drm_connector_list_iter conn_iter;
> + struct drm_private_obj *privobj;
> + int ret;
> +
> + drm_for_each_privobj(privobj, dev) {
> + struct drm_private_state *privobj_state;
> +
> + if (privobj->state)
> + continue;
> +
> + if (!privobj->funcs->atomic_create_state)
> + continue;
> +
> + privobj_state = privobj->funcs->atomic_create_state(privobj);
> + if (IS_ERR(privobj_state))
> + return PTR_ERR(privobj_state);
> +
> + privobj->state = privobj_state;
> + }
> +
> + drm_for_each_colorop(colorop, dev) {
> + struct drm_colorop_state *colorop_state;
> +
> + if (colorop->state)
> + continue;
> +
> + colorop_state = drm_atomic_helper_colorop_create_state(colorop);
> + if (IS_ERR(colorop_state))
> + return PTR_ERR(colorop_state);
> +
> + colorop->state = colorop_state;
> + }
> +
> + drm_for_each_plane(plane, dev) {
> + if (plane->state)
> + continue;
> +
> + ret = drm_mode_config_plane_create_state(plane);
> + if (ret)
> + return ret;
> + }
> +
> + drm_for_each_crtc(crtc, dev) {
> + if (crtc->state)
> + continue;
> +
> + ret = drm_mode_config_crtc_create_state(crtc);
> + if (ret)
> + return ret;
> + }
> +
> + drm_connector_list_iter_begin(dev, &conn_iter);
> + drm_for_each_connector_iter(connector, &conn_iter) {
> + if (connector->state)
> + continue;
> +
> + ret = drm_mode_config_connector_create_state(connector);
> + if (ret)
> + return ret;
> + }
> + drm_connector_list_iter_end(&conn_iter);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_mode_config_create_initial_state);
> +
> /*
> * Global properties
> */
> static const struct drm_prop_enum_list drm_plane_type_enum_list[] = {
> { DRM_PLANE_TYPE_OVERLAY, "Overlay" },
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 687c0ee163d2..00009250fde4 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -1005,9 +1005,10 @@ int __must_check drmm_mode_config_init(struct drm_device *dev);
> static inline int drm_mode_config_init(struct drm_device *dev)
> {
> return drmm_mode_config_init(dev);
> }
>
> +int drm_mode_config_create_initial_state(struct drm_device *dev);
> void drm_mode_config_reset(struct drm_device *dev);
> void drm_mode_config_cleanup(struct drm_device *dev);
>
> #endif
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
From: Jeff Barnes @ 2026-05-04 17:41 UTC (permalink / raw)
To: Jon Kohler
Cc: Eric Biggers, linux-crypto@vger.kernel.org, Herbert Xu,
linux-doc@vger.kernel.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Linus Torvalds
In-Reply-To: <4D424F50-7E9F-4B1F-AE9C-86D8526284E6@nutanix.com>
On May 4 2026, at 10:39 am, Jon Kohler <jon@nutanix.com> wrote:
>
> Quick passing observation
> I noticed that when attempting to completely disable these Crypto APIs,
> I was experiencing boot failures with fips=1 enabled systems.
>
> Using 6.18-based kernel with an el9-based user space, I see the
> following hang in the early boot console from dracut-pre-pivot:
> Check integrity of kernel
> libkcapi - Error: AF_ALG: socket syscall failed (errno: -97)
> Allocation of hmac(sha512) cipher failed (-97)
One thing that for certain that would cause this panic is the sha512hmac
binary that does the fips integrity check. On many distros this check is
called, for example by dracut among others, during initramfs to check
the integrity of the kernel before any crypto is used. On failure, the
kernel won't finish boot.
sha512hmac is a binary shipped with kcapitools. It uses libkcapi.
sha512hmac -> libkcapi -> AF_ALG.
Is there a planned replacement for this integrity check? I don't know of
anybody doing this for FIPS yet, but is there a case where IMA / EVM
could be a workaround?
Regards,
Jeff
>
> I haven't looked at every elX version, but at least in el9 and el10,
> they use libkcapi-hmaccalc to provide sha512hmac, which dracut [1]
> uses to calculate the HMAC value in do_fips().
>
> Digging further, I was only able to disable RNG and AEAD APIs, but
> not HASH and SKCIPHER APIs when FIPS was in the picture with el9++.
>
> I’m not sure how other distros do the same, but this could be problematic
> elsehwere if other distros went down the libkcapi route.
>
> [1] https://github.com/dracutdevs/dracut/blob/059/modules.d/01fips/fips.sh#L167
>
>
^ permalink raw reply
* Re: [PATCH] crypto: af_alg - Document the deprecation of AF_ALG
From: Eric Biggers @ 2026-05-04 17:39 UTC (permalink / raw)
To: Jon Kohler
Cc: linux-crypto@vger.kernel.org, Herbert Xu,
linux-doc@vger.kernel.org, linux-api@vger.kernel.org,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Linus Torvalds
In-Reply-To: <4D424F50-7E9F-4B1F-AE9C-86D8526284E6@nutanix.com>
On Mon, May 04, 2026 at 02:39:12PM +0000, Jon Kohler wrote:
> > On Apr 29, 2026, at 9:15 PM, Eric Biggers <ebiggers@kernel.org> wrote:
> >
> > AF_ALG is almost completely unnecessary, and it exposes a massive attack
> > surface that hasn't been standing up to modern vulnerability discovery
> > tools. The latest one even has its own website, providing a small
> > Python script that reliably roots most Linux distros: https://copy.fail/
> >
> > This isn't sustainable, especially as LLMs have accelerated the rate the
> > vulnerabilities are coming in. The effort that is being put into this
> > thing is vastly disproportional to the few programs that actually use
> > it, and those programs would be better served by userspace code anyway.
> >
> > These issues have been noted in many mailing list discussions already.
> > But until now they haven't been reflected in the documentation or
> > kconfig menu itself, and the vulnerabilities are still coming in.
> >
> > Let's go ahead and document the deprecation.
> >
> > This isn't intended to change anything overnight. After all, most Linux
> > distros won't be able to disable the kconfig options quite yet, mainly
> > because of iwd. But this should create a bit more impetus for these
> > userspace programs to be fixed, and the documentation update should also
> > help prevent more users from appearing.
> >
> > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> > ---
>
> Quick passing observation
> I noticed that when attempting to completely disable these Crypto APIs,
> I was experiencing boot failures with fips=1 enabled systems.
>
> Using 6.18-based kernel with an el9-based user space, I see the
> following hang in the early boot console from dracut-pre-pivot:
> Check integrity of kernel
> libkcapi - Error: AF_ALG: socket syscall failed (errno: -97)
> Allocation of hmac(sha512) cipher failed (-97)
>
> I haven't looked at every elX version, but at least in el9 and el10,
> they use libkcapi-hmaccalc to provide sha512hmac, which dracut [1]
> uses to calculate the HMAC value in do_fips().
>
> Digging further, I was only able to disable RNG and AEAD APIs, but
> not HASH and SKCIPHER APIs when FIPS was in the picture with el9++.
>
> I’m not sure how other distros do the same, but this could be problematic
> elsehwere if other distros went down the libkcapi route.
>
> [1] https://github.com/dracutdevs/dracut/blob/059/modules.d/01fips/fips.sh#L167
That seems to be an implementation of FIPS 140-3's integrity self-check.
A few observations:
- It could easily use userspace SHA-512 code instead. If including
libcrypto.so in the "FIPS cryptographic boundary" would cause
certification difficulties, then a sha512.c file could simply be added
to 'libkcapi-hmaccalc' which is already in it.
- It's compatible with all of the proposed hardening. It doesn't
require zero-copy performance. It runs as root, so it would be
compatible with a capability check. "hmac(sha512)" will need to be on
the algorithm allowlist anyway for iwd.
- FIPS 140-3 might also allow it to be simplified to use a plain hash
instead of pointlessly using HMAC with a fixed key.
Anyway, just another one of the long tail of odd users that could have
solved their problem in a better way. This one is at least compatible
with the hardening that's being considered.
By the way, also on the topic of FIPS 140-3, some people do use AF_ALG
for ACVP (even though it's not all that great for that purpose, either).
But ACVP is a testing thing, not something that is needed on production
systems. ACVP can just be run as root on a testing build; there's no
need to enable support for it in the actual production build.
- Eric
^ permalink raw reply
* Re: [PATCH v3 15/20] drm/connector: Add new atomic_create_state callback
From: Laurent Pinchart @ 2026-05-04 17:35 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-15-8b68d9db0d8b@kernel.org>
Hi Maxime,
Thank you for the patch.
On Fri, Apr 24, 2026 at 12:18:55PM +0200, Maxime Ripard wrote:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software state, reset it,
> but also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> reset() also isn't fallible, which makes it harder to handle
> initialization errors properly. This is only really relevant for some
> drivers though, since all the helpers for reset only create a new
> state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect:
> atomic_create_state to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Continue the transition to the new pattern with connectors.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 26 ++++++++++++++++++++++++++
> drivers/gpu/drm/drm_mode_config.c | 21 ++++++++++++++++++++-
> include/drm/drm_atomic_state_helper.h | 2 ++
> include/drm/drm_connector.h | 16 ++++++++++++++++
> 4 files changed, 64 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index f67aacaa3b6e..6140926f4605 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -554,10 +554,36 @@ void drm_atomic_helper_connector_reset(struct drm_connector *connector)
> kfree(connector->state);
> __drm_atomic_helper_connector_reset(connector, conn_state);
> }
> EXPORT_SYMBOL(drm_atomic_helper_connector_reset);
>
> +/**
> + * drm_atomic_helper_connector_create_state - default &drm_connector_funcs.atomic_create_state hook for connectors
Same comment as in 10/20.
> + * @connector: connector object
> + *
> + * Initializes a pristine @drm_connector_state.
"Allocate and initialize ..."
> + *
> + * This is useful for drivers that don't subclass @drm_connector_state.
> + *
> + * RETURNS:
> + * Pointer to new connector state, or ERR_PTR on failure.
> + */
> +struct drm_connector_state *
> +drm_atomic_helper_connector_create_state(struct drm_connector *connector)
> +{
> + struct drm_connector_state *state;
> +
> + state = kzalloc_obj(*state);
> + if (!state)
> + return ERR_PTR(-ENOMEM);
> +
> + __drm_atomic_helper_connector_state_init(state, connector);
> +
> + return state;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_connector_create_state);
> +
> /**
> * drm_atomic_helper_connector_tv_margins_reset - Resets TV connector properties
> * @connector: DRM connector
> *
> * Resets the TV-related properties attached to a connector.
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index 182d9a8104e7..92ff907f2485 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -212,10 +212,26 @@ static int drm_mode_config_crtc_create_state(struct drm_crtc *crtc)
> crtc->state = crtc_state;
>
> return 0;
> }
>
> +static int drm_mode_config_connector_create_state(struct drm_connector *connector)
> +{
> + struct drm_connector_state *conn_state;
> +
> + if (!connector->funcs->atomic_create_state)
> + return 0;
> +
> + conn_state = connector->funcs->atomic_create_state(connector);
> + if (IS_ERR(conn_state))
> + return PTR_ERR(conn_state);
> +
> + connector->state = conn_state;
> +
> + return 0;
> +}
> +
> /**
> * drm_mode_config_reset - call ->reset callbacks
> * @dev: drm device
> *
> * This functions calls all the crtc's, encoder's and connector's ->reset
> @@ -255,13 +271,16 @@ void drm_mode_config_reset(struct drm_device *dev)
> drm_for_each_encoder(encoder, dev)
> if (encoder->funcs && encoder->funcs->reset)
> encoder->funcs->reset(encoder);
>
> drm_connector_list_iter_begin(dev, &conn_iter);
> - drm_for_each_connector_iter(connector, &conn_iter)
> + drm_for_each_connector_iter(connector, &conn_iter) {
> if (connector->funcs->reset)
> connector->funcs->reset(connector);
> + else if (connector->funcs->atomic_create_state)
> + drm_mode_config_connector_create_state(connector);
> + }
> drm_connector_list_iter_end(&conn_iter);
> }
> EXPORT_SYMBOL(drm_mode_config_reset);
>
> /*
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index e7c097e6dfe3..8576cd256737 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -75,10 +75,12 @@ void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
> void __drm_atomic_helper_connector_state_init(struct drm_connector_state *conn_state,
> struct drm_connector *connector);
> void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
> struct drm_connector_state *conn_state);
> void drm_atomic_helper_connector_reset(struct drm_connector *connector);
> +struct drm_connector_state *
> +drm_atomic_helper_connector_create_state(struct drm_connector *connector);
> void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
> int drm_atomic_helper_connector_tv_check(struct drm_connector *connector,
> struct drm_atomic_state *state);
> void drm_atomic_helper_connector_tv_margins_reset(struct drm_connector *connector);
> void
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 3e422a4f2e72..9fb794957d23 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1569,10 +1569,26 @@ struct drm_connector_funcs {
> * when a connector is being hot-unplugged for drivers that support
> * connector hotplugging (e.g. DisplayPort MST).
> */
> void (*destroy)(struct drm_connector *connector);
>
> + /**
> + * @atomic_create_state:
> + *
> + * Allocates a pristine, initialized, state for the connector object
s/Allocates/Allocate/
> + * and returns it. This callback must have no side effects: in
s/returns/return/
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> + * particular, the returned state must not be assigned to the
> + * object's state pointer and it must not affect the hardware
> + * state.
> + *
> + * RETURNS:
> + *
> + * A new, pristine, connector state instance or an error pointer
> + * on failure.
> + */
> + struct drm_connector_state *(*atomic_create_state)(struct drm_connector *connector);
> +
> /**
> * @atomic_duplicate_state:
> *
> * Duplicate the current atomic state for this connector and return it.
> * The core and helpers guarantee that any atomic state duplicated with
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 14/20] drm/hdmi: Rename __drm_atomic_helper_connector_hdmi_reset()
From: Laurent Pinchart @ 2026-05-04 17:32 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-14-8b68d9db0d8b@kernel.org>
On Fri, Apr 24, 2026 at 12:18:54PM +0200, Maxime Ripard wrote:
> __drm_atomic_helper_connector_hdmi_reset() is typically used to
> initialize a newly allocated drm_connector_state when the connector is
> using the HDMI helpers, and is being called by the
> drm_connector_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_connector_state instance, we will need to call
> __drm_atomic_helper_connector_hdmi_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_connector_hdmi_reset() to
> __drm_atomic_helper_connector_hdmi_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/display/drm_bridge_connector.c | 4 ++--
> drivers/gpu/drm/display/drm_hdmi_state_helper.c | 13 +++++++------
> drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 2 +-
> drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 2 +-
> drivers/gpu/drm/vc4/vc4_hdmi.c | 2 +-
> include/drm/display/drm_hdmi_state_helper.h | 4 ++--
> 6 files changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
> index 39cc18f78eda..d72f29b73be3 100644
> --- a/drivers/gpu/drm/display/drm_bridge_connector.c
> +++ b/drivers/gpu/drm/display/drm_bridge_connector.c
> @@ -270,12 +270,12 @@ static void drm_bridge_connector_reset(struct drm_connector *connector)
> struct drm_bridge_connector *bridge_connector =
> to_drm_bridge_connector(connector);
>
> drm_atomic_helper_connector_reset(connector);
> if (bridge_connector->bridge_hdmi)
> - __drm_atomic_helper_connector_hdmi_reset(connector,
> - connector->state);
> + __drm_atomic_helper_connector_hdmi_state_init(connector,
> + connector->state);
> }
>
> static const struct drm_connector_funcs drm_bridge_connector_funcs = {
> .reset = drm_bridge_connector_reset,
> .detect = drm_bridge_connector_detect,
> diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> index 9f3b696aceeb..8bf7ad3c99fb 100644
> --- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> +++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
> @@ -304,29 +304,30 @@
> * --kunitconfig=drivers/gpu/drm/tests \
> * drm_atomic_helper_connector_hdmi_*
> */
>
> /**
> - * __drm_atomic_helper_connector_hdmi_reset() - Initializes all HDMI @drm_connector_state resources
> + * __drm_atomic_helper_connector_hdmi_state_init() - Initializes all HDMI @drm_connector_state resources
While at it, s/Initializers/Initialize/
> * @connector: DRM connector
> * @new_conn_state: connector state to reset
s/to reset/to initialize/
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> *
> * Initializes all HDMI resources from a @drm_connector_state without
> * actually allocating it. This is useful for HDMI drivers, in
> - * combination with __drm_atomic_helper_connector_reset() or
> - * drm_atomic_helper_connector_reset().
> + * combination with __drm_atomic_helper_connector_state_init(),
> + * drm_atomic_helper_connector_reset(), or
> + * drm_atomic_helper_connector_create_state() .
> */
> -void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
> - struct drm_connector_state *new_conn_state)
> +void __drm_atomic_helper_connector_hdmi_state_init(struct drm_connector *connector,
> + struct drm_connector_state *new_conn_state)
> {
> unsigned int max_bpc = connector->max_bpc;
>
> new_conn_state->max_bpc = max_bpc;
> new_conn_state->max_requested_bpc = max_bpc;
> new_conn_state->hdmi.broadcast_rgb = DRM_HDMI_BROADCAST_RGB_AUTO;
> }
> -EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_reset);
> +EXPORT_SYMBOL(__drm_atomic_helper_connector_hdmi_state_init);
>
> static enum hdmi_colorspace
> output_color_format_to_hdmi_colorspace(const struct drm_connector *connector,
> enum drm_output_color_format fmt)
> {
> diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> index dd2a78defdb4..29dfff4f0055 100644
> --- a/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> +++ b/drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c
> @@ -283,11 +283,11 @@ sun4i_hdmi_connector_detect(struct drm_connector *connector, bool force)
> }
>
> static void sun4i_hdmi_connector_reset(struct drm_connector *connector)
> {
> drm_atomic_helper_connector_reset(connector);
> - __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
> + __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
> }
>
> static const struct drm_connector_funcs sun4i_hdmi_connector_funcs = {
> .detect = sun4i_hdmi_connector_detect,
> .fill_modes = drm_helper_probe_single_connector_modes,
> diff --git a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> index a4357efaa983..5d671b281f28 100644
> --- a/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> +++ b/drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c
> @@ -166,11 +166,11 @@ static const struct drm_connector_helper_funcs dummy_connector_helper_funcs = {
> };
>
> static void dummy_hdmi_connector_reset(struct drm_connector *connector)
> {
> drm_atomic_helper_connector_reset(connector);
> - __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
> + __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
> }
>
> static const struct drm_connector_funcs dummy_connector_funcs = {
> .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
> .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
> diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c
> index a99f53dadb28..14fcee05e133 100644
> --- a/drivers/gpu/drm/vc4/vc4_hdmi.c
> +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c
> @@ -506,11 +506,11 @@ static int vc4_hdmi_connector_atomic_check(struct drm_connector *connector,
> }
>
> static void vc4_hdmi_connector_reset(struct drm_connector *connector)
> {
> drm_atomic_helper_connector_reset(connector);
> - __drm_atomic_helper_connector_hdmi_reset(connector, connector->state);
> + __drm_atomic_helper_connector_hdmi_state_init(connector, connector->state);
> drm_atomic_helper_connector_tv_margins_reset(connector);
> }
>
> static const struct drm_connector_funcs vc4_hdmi_connector_funcs = {
> .force = drm_atomic_helper_connector_hdmi_force,
> diff --git a/include/drm/display/drm_hdmi_state_helper.h b/include/drm/display/drm_hdmi_state_helper.h
> index 2349c0d0f00f..f7600aabdd5f 100644
> --- a/include/drm/display/drm_hdmi_state_helper.h
> +++ b/include/drm/display/drm_hdmi_state_helper.h
> @@ -9,12 +9,12 @@ struct drm_connector_state;
> struct drm_display_mode;
> struct hdmi_audio_infoframe;
>
> enum drm_connector_status;
>
> -void __drm_atomic_helper_connector_hdmi_reset(struct drm_connector *connector,
> - struct drm_connector_state *new_conn_state);
> +void __drm_atomic_helper_connector_hdmi_state_init(struct drm_connector *connector,
> + struct drm_connector_state *new_conn_state);
>
> int drm_atomic_helper_connector_hdmi_check(struct drm_connector *connector,
> struct drm_atomic_state *state);
>
> int drm_atomic_helper_connector_hdmi_update_audio_infoframe(struct drm_connector *connector,
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 13/20] drm/atomic-state-helper: Rename __drm_atomic_helper_connector_state_reset()
From: Laurent Pinchart @ 2026-05-04 17:30 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-13-8b68d9db0d8b@kernel.org>
On Fri, Apr 24, 2026 at 12:18:53PM +0200, Maxime Ripard wrote:
> __drm_atomic_helper_connector_state_reset() is used to initialize a
> newly allocated drm_connector_state, and is being typically called by
> the drm_connector_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_connector_state instance, we will need to call
> __drm_atomic_helper_connector_state_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_connector_state_reset() to
> __drm_atomic_helper_connector_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 12 ++++++------
> include/drm/drm_atomic_state_helper.h | 2 +-
> 2 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index b7da134c8c50..f67aacaa3b6e 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -496,24 +496,24 @@ void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
> kfree(state);
> }
> EXPORT_SYMBOL(drm_atomic_helper_plane_destroy_state);
>
> /**
> - * __drm_atomic_helper_connector_state_reset - reset the connector state
> + * __drm_atomic_helper_connector_state_init - Initializes the connector state
s/Initializes/Initialize/
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> * @conn_state: atomic connector state, must not be NULL
> - * @connector: connectotr object, must not be NULL
> + * @connector: connector object, must not be NULL
> *
> * Initializes the newly allocated @conn_state with default
> * values. This is useful for drivers that subclass the connector state.
> */
> void
> -__drm_atomic_helper_connector_state_reset(struct drm_connector_state *conn_state,
> - struct drm_connector *connector)
> +__drm_atomic_helper_connector_state_init(struct drm_connector_state *conn_state,
> + struct drm_connector *connector)
> {
> conn_state->connector = connector;
> }
> -EXPORT_SYMBOL(__drm_atomic_helper_connector_state_reset);
> +EXPORT_SYMBOL(__drm_atomic_helper_connector_state_init);
>
> /**
> * __drm_atomic_helper_connector_reset - reset state on connector
> * @connector: drm connector
> * @conn_state: connector state to assign
> @@ -528,11 +528,11 @@ EXPORT_SYMBOL(__drm_atomic_helper_connector_state_reset);
> void
> __drm_atomic_helper_connector_reset(struct drm_connector *connector,
> struct drm_connector_state *conn_state)
> {
> if (conn_state)
> - __drm_atomic_helper_connector_state_reset(conn_state, connector);
> + __drm_atomic_helper_connector_state_init(conn_state, connector);
>
> connector->state = conn_state;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_connector_reset);
>
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index 129762b99de6..e7c097e6dfe3 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -70,11 +70,11 @@ struct drm_plane_state *
> drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane);
> void __drm_atomic_helper_plane_destroy_state(struct drm_plane_state *state);
> void drm_atomic_helper_plane_destroy_state(struct drm_plane *plane,
> struct drm_plane_state *state);
>
> -void __drm_atomic_helper_connector_state_reset(struct drm_connector_state *conn_state,
> +void __drm_atomic_helper_connector_state_init(struct drm_connector_state *conn_state,
> struct drm_connector *connector);
> void __drm_atomic_helper_connector_reset(struct drm_connector *connector,
> struct drm_connector_state *conn_state);
> void drm_atomic_helper_connector_reset(struct drm_connector *connector);
> void drm_atomic_helper_connector_tv_reset(struct drm_connector *connector);
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 12/20] drm/crtc: Add new atomic_create_state callback
From: Laurent Pinchart @ 2026-05-04 17:28 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-12-8b68d9db0d8b@kernel.org>
On Fri, Apr 24, 2026 at 12:18:52PM +0200, Maxime Ripard wrote:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software state, reset it,
> but also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> reset() also isn't fallible, which makes it harder to handle
> initialization errors properly. This is only really relevant for some
> drivers though, since all the helpers for reset only create a new
> state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect:
> atomic_create_state to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Continue the transition to the new pattern with CRTCs.
>
> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 47 +++++++++++++++++++++++++++++++
> drivers/gpu/drm/drm_mode_config.c | 21 +++++++++++++-
> include/drm/drm_atomic_state_helper.h | 4 +++
> include/drm/drm_crtc.h | 16 +++++++++++
> 4 files changed, 87 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 9cd8550cabb7..b7da134c8c50 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -103,10 +103,32 @@ __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
>
> crtc->state = crtc_state;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_crtc_reset);
>
> +/**
> + * __drm_atomic_helper_crtc_create_state - initializes crtc state
"Initialize a CRTC state"
The name of the function is misleading ("*_create_*" while you state it
performs initialization).
> + * @crtc: crtc object
> + * @state: new state to initialize
> + *
> + * Initializes the newly allocated @state, usually required when
> + * initializing the drivers.
> + *
> + * @state is assumed to be zeroed.
> + *
> + * This is useful for drivers that subclass @drm_crtc_state.
> + */
> +void __drm_atomic_helper_crtc_create_state(struct drm_crtc *crtc,
> + struct drm_crtc_state *state)
> +{
> + __drm_atomic_helper_crtc_state_init(state, crtc);
> +
> + if (drm_dev_has_vblank(crtc->dev))
> + drm_crtc_vblank_reset(crtc);
This is confusing to me (at least before reading the rest of the
series), and itn't mentioned in the function documentation or in the
commit message.
Furthermore, __drm_atomic_helper_crtc_create_state() is later used in
tidss_crtc_create_state(), which is the
drm_crtc_funcs.atomic_create_state() implementation of the tidss driver.
The atomic_create_state documentation states that "This callback must
have no side effect", and drm_crtc_vblank_reset() has side effects.
> +}
> +EXPORT_SYMBOL(__drm_atomic_helper_crtc_create_state);
> +
> /**
> * drm_atomic_helper_crtc_reset - default &drm_crtc_funcs.reset hook for CRTCs
> * @crtc: drm CRTC
> *
> * Resets the atomic state for @crtc by freeing the state pointer (which might
> @@ -122,10 +144,35 @@ void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc)
>
> __drm_atomic_helper_crtc_reset(crtc, crtc_state);
> }
> EXPORT_SYMBOL(drm_atomic_helper_crtc_reset);
>
> +/**
> + * drm_atomic_helper_crtc_create_state - default &drm_crtc_funcs.atomic_create_state hook for crtcs
Same comment as in patch 10/20.
> + * @crtc: crtc object
> + *
> + * Initializes a pristine @drm_crtc_state.
"Allocate and initialize ..."
> + *
> + * This is useful for drivers that don't subclass @drm_crtc_state.
> + *
> + * RETURNS:
> + * Pointer to new crtc state, or ERR_PTR on failure.
> + */
> +struct drm_crtc_state *drm_atomic_helper_crtc_create_state(struct drm_crtc *crtc)
> +{
> + struct drm_crtc_state *state;
> +
> + state = kzalloc_obj(*state);
> + if (!state)
> + return ERR_PTR(-ENOMEM);
> +
> + __drm_atomic_helper_crtc_create_state(crtc, state);
> +
> + return state;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_crtc_create_state);
> +
> /**
> * __drm_atomic_helper_crtc_duplicate_state - copy atomic CRTC state
> * @crtc: CRTC object
> * @state: atomic CRTC state
> *
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index 10b7815cbe48..182d9a8104e7 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -196,10 +196,26 @@ static int drm_mode_config_plane_create_state(struct drm_plane *plane)
> plane->state = plane_state;
>
> return 0;
> }
>
> +static int drm_mode_config_crtc_create_state(struct drm_crtc *crtc)
> +{
> + struct drm_crtc_state *crtc_state;
> +
> + if (!crtc->funcs->atomic_create_state)
> + return 0;
> +
> + crtc_state = crtc->funcs->atomic_create_state(crtc);
> + if (IS_ERR(crtc_state))
> + return PTR_ERR(crtc_state);
> +
> + crtc->state = crtc_state;
> +
> + return 0;
> +}
> +
> /**
> * drm_mode_config_reset - call ->reset callbacks
> * @dev: drm device
> *
> * This functions calls all the crtc's, encoder's and connector's ->reset
> @@ -227,13 +243,16 @@ void drm_mode_config_reset(struct drm_device *dev)
> plane->funcs->reset(plane);
> else if (plane->funcs->atomic_create_state)
> drm_mode_config_plane_create_state(plane);
> }
>
> - drm_for_each_crtc(crtc, dev)
> + drm_for_each_crtc(crtc, dev) {
> if (crtc->funcs->reset)
> crtc->funcs->reset(crtc);
> + else if (crtc->funcs->atomic_create_state)
> + drm_mode_config_crtc_create_state(crtc);
> + }
>
> drm_for_each_encoder(encoder, dev)
> if (encoder->funcs && encoder->funcs->reset)
> encoder->funcs->reset(encoder);
>
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index e7fbbfdc5d69..129762b99de6 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -43,10 +43,14 @@ struct drm_device;
> void __drm_atomic_helper_crtc_state_init(struct drm_crtc_state *state,
> struct drm_crtc *crtc);
> void __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
> struct drm_crtc_state *state);
> void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc);
> +void __drm_atomic_helper_crtc_create_state(struct drm_crtc *crtc,
> + struct drm_crtc_state *state);
> +struct drm_crtc_state *
> +drm_atomic_helper_crtc_create_state(struct drm_crtc *crtc);
> void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
> struct drm_crtc_state *state);
> struct drm_crtc_state *
> drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc);
> void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state);
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 312fc1e745d2..41ea6eadf36f 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -636,10 +636,26 @@ struct drm_crtc_funcs {
> * 0 on success or a negative error code on failure.
> */
> int (*set_property)(struct drm_crtc *crtc,
> struct drm_property *property, uint64_t val);
>
> + /**
> + * @atomic_create_state:
> + *
> + * Allocates a pristine, initialized, state for the CRTC object
s/Allocates/Allocate/
> + * and returns it. This callback must have no side effects: in
> + * particular, the returned state must not be assigned to the
> + * object's state pointer and it must not affect the hardware
> + * state.
> + *
> + * RETURNS:
> + *
> + * A new, pristine, CRTC state instance or an error pointer
> + * on failure.
> + */
> + struct drm_crtc_state *(*atomic_create_state)(struct drm_crtc *crtc);
> +
> /**
> * @atomic_duplicate_state:
> *
> * Duplicate the current atomic state for this CRTC and return it.
> * The core and helpers guarantee that any atomic state duplicated with
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4 07/11] PCI: liveupdate: Inherit ACS flags in incoming preserved devices
From: David Matlack @ 2026-05-04 17:23 UTC (permalink / raw)
To: iommu, kexec, linux-doc, linux-kernel, linux-mm, linux-pci
Cc: Adithya Jayachandran, Alexander Graf, Alex Williamson,
Bjorn Helgaas, Chris Li, David Rientjes, Jacob Pan,
Jason Gunthorpe, Joerg Roedel, Jonathan Corbet, Josh Hilke,
Leon Romanovsky, Lukas Wunner, Mike Rapoport, Parav Pandit,
Pasha Tatashin, Pranjal Shrivastava, Pratyush Yadav, Robin Murphy,
Saeed Mahameed, Samiullah Khawaja, Shuah Khan, Will Deacon,
William Tu, Yi Liu
In-Reply-To: <20260423212316.3431746-8-dmatlack@google.com>
On Thu, Apr 23, 2026 at 2:23 PM David Matlack <dmatlack@google.com> wrote:
>
> Inherit Access Control Services (ACS) flags on all incoming preserved
> devices (endpoints and upstream bridges) during a Live Update.
>
> Inheriting ACS flags avoids changing routing rules while memory
> transactions are in flight from preserved devices. This is also strictly
> necessary to ensure that IOMMU group assignments do not change across
> a Live Update for preserved devices, as changing ACS configurations can
> split or merge IOMMU groups.
>
> Signed-off-by: David Matlack <dmatlack@google.com>
> @@ -1017,6 +1017,15 @@ void pci_enable_acs(struct pci_dev *dev)
> bool enable_acs = false;
> int pos;
>
> + /*
> + * ACS flags must be inherited from the previous kernel during a Live
> + * Update for preserved devices (which includes endpoints and any
> + * upstream bridges) to avoid changing routing while memory transactions
> + * are in flight.
> + */
> + if (pci_liveupdate_incoming(dev))
> + return;
Sashiko caught that pci_enable_acs() is also called from
pci_restore_state() so this patch needs a fix to ensure that ACS flags
do not change or get lost after a save+reset+restore.
^ permalink raw reply
* Re: [PATCH v2] iio: adxl313: fix typos in documentation
From: Joshua Crofts @ 2026-05-04 17:21 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: Wang Zihan, linux-iio, linux-doc
In-Reply-To: <20260504174326.353b6f02@jic23-huawei>
On Mon, 4 May 2026 at 18:43, Jonathan Cameron <jic23@kernel.org> wrote:
>
> On Sat, 2 May 2026 14:07:00 +0800
> Wang Zihan <jiyu03@qq.com> wrote:
>
> > Add missing space in "ADXL313is" and correct "a single types"
> > to "a single type".
> >
> > Signed-off-by: Wang Zihan <jiyu03@qq.com>
> > ---
> > Documentation/iio/adxl313.rst | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/iio/adxl313.rst b/Documentation/iio/adxl313.rst
> > index 966e72c01..3662153a6 100644
> > --- a/Documentation/iio/adxl313.rst
> > +++ b/Documentation/iio/adxl313.rst
> > @@ -11,7 +11,7 @@ This driver supports Analog Device's ADXL313 on SPI/I2C bus.
> >
> > * `ADXL313 <https://www.analog.com/ADXL313>`_
> >
> > -The ADXL313is a low noise density, low power, 3-axis accelerometer with
> > +The ADXL313 is a low noise density, low power, 3-axis accelerometer with
> > selectable measurement ranges. The ADXL313 supports the ±0.5 g, ±1 g, ±2 g and
> > ±4 g ranges.
> >
> > @@ -112,7 +112,7 @@ apply the following formula:
> > Where _offset and _scale are device attributes. If no _offset attribute is
> > present, simply assume its value is 0.
> >
> > -The ADXL313 driver offers data for a single types of channels, the table below
> > +The ADXL313 driver offers data for a single type of channels, the table below
>
> ooh. That's fun grammar. Intent is that there are multiple channels of one type
> but the form used in your corrected version is at best unwieldy given plural
> singular mix. "a single type of channel" is fine for instance but this isn't really.
Ah, my bad, the space is fine but reading it a second time - it does seem off.
--
Kind regards
CJD
^ permalink raw reply
* Re: [PATCH v13 3/4] gpio: rpmsg: add generic rpmsg GPIO driver
From: Arnaud POULIQUEN @ 2026-05-04 17:04 UTC (permalink / raw)
To: Beleswar Prasad Padhi, Mathieu Poirier
Cc: Shenwei Wang, Andrew Lunn, Linus Walleij, Bartosz Golaszewski,
Jonathan Corbet, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bjorn Andersson, Frank Li, Sascha Hauer, Shuah Khan,
linux-gpio@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Pengutronix Kernel Team,
Fabio Estevam, Peng Fan, devicetree@vger.kernel.org,
linux-remoteproc@vger.kernel.org, imx@lists.linux.dev,
linux-arm-kernel@lists.infradead.org, dl-linux-imx,
Bartosz Golaszewski
In-Reply-To: <268f8e00-91bc-43ea-ba95-077cf859e7f3@ti.com>
Hi Beleswar,
On 5/4/26 10:17, Beleswar Prasad Padhi wrote:
> Hi Arnaud,
>
> On 30/04/26 22:10, Arnaud POULIQUEN wrote:
>>
>>
>> On 4/30/26 14:56, Beleswar Prasad Padhi wrote:
>>> Hello Arnaud,
>>>
>>> On 30/04/26 13:05, Arnaud POULIQUEN wrote:
>>>> Hello,
>>>>
>>>> On 4/29/26 21:20, Mathieu Poirier wrote:
>>>>> On Wed, 29 Apr 2026 at 12:07, Padhi, Beleswar <b-padhi@ti.com> wrote:
>>>>>>
>>>>>> Hi Mathieu,
>>>>>>
>>>>>> On 4/29/2026 11:03 PM, Mathieu Poirier wrote:
>>>>>>> On Wed, 29 Apr 2026 at 10:53, Shenwei Wang <shenwei.wang@nxp.com> wrote:
>>>>>
>
> [...]
>
>>>>>> My mental model looks like this for the complete picture:
>>>>>>
>>>>>> 1. namespace/channel#1 = rpmsg-io
>>>>>> a. ept1 -> gpio-controller@1
>>>>>> b. ept2 -> gpio-controller@2
>>>>>>
>>>>>
>>>>> I've asked for one endpoint per GPIO controller since the very
>>>>> beginning. I don't yet have a strong opinion on whether to use one
>>>>> namespace request per GPIO controller or a single request that spins
>>>>> off multiple endpoints. I'll have to look at your link and reflect on
>>>>> that. Regardless of how we proceed on that front, multiplexing needs
>>>>> to happen at the endpoint level rather than the packet level. This is
>>>>> the only way this work can move forward.
>>>>>
>>>>
>>>> I would be more in favor of Mathieu’s proposal: “An endpoint is created with every namespace request.”
>>>>
>>>> If the endpoint is created only on the Linux side, how do we match the Linux endpoint address with the local port field on the remote side?
>>>
>>>
>>> Simply by sending a message to the remote containing the newly created
>>> endpoint and the port idx. Note that is this done just one time, after this
>>> Linux need not have the port field in the message everytime its sending
>>> a message.
>>>
>>>>
>>>> With a multi-namespace approach, the namespace could be rpmsg-io-[addr], where [addr] corresponds to the GPIO controller address in the DT. This would:
>>>
>>>
>>> You will face the same problem in this case also that you asked above:
>>> "how do we match the Linux endpoint address with the local port field
>>> on the remote side?"
>>
>> Sorry I probably introduced confusion here
>> my sentence should be;
>> With a multi-namespace approach, the namespace could be rpmsg-io-[port],
>> where [port] corresponds to the GPIO controller port in the DT.
>>
>>
>> For instance:
>>
>> rpmsg {
>> rpmsg-io {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> gpio@25 {
>> compatible = "rpmsg-gpio";
>> reg = <25>;
>> gpio-controller;
>> #gpio-cells = <2>;
>> #interrupt-cells = <2>;
>> interrupt-controller;
>> };
>>
>> gpio@32 {
>> compatible = "rpmsg-gpio";
>> reg = <32>;
>> gpio-controller;
>> #gpio-cells = <2>;
>> #interrupt-cells = <2>;
>> interrupt-controller;
>> };
>> };
>> };
>>
>> rpmsg-io-25 would match with gpio@25
>> rpmsg-io-32 would match with gpio@32
>>
>>
>>>
>>> Because the endpoint that is created on a namespace request is also
>>> dynamic in nature. How will the remote know which endpoint addr
>>> Linux allocated for a namespace that it announced?
>>>
>>> As an example/PoC, I created a firmware example which announces
>>> 2 name services to Linux, one is the standard "rpmsg_chrdev" and
>>> the other is a TI specific name service "ti.ipc4.ping-pong". You can
>>> see it created 2 different addresses (0x400 and 0x401) for each of
>>> the name service request from the same firmware:
>>>
>>> root@j784s4-evm:~# dmesg | grep virtio0 | grep -i channel
>>> [ 9.290275] virtio_rpmsg_bus virtio0: creating channel ti.ipc4.ping-pong addr 0xd
>>> [ 9.311230] virtio_rpmsg_bus virtio0: creating channel rpmsg_chrdev addr 0xe
>>> [ 9.496645] rpmsg_chrdev virtio0.rpmsg_chrdev.-1.14: DEBUG: Channel formed from src = 0x400 to dst = 0xe
>>> [ 9.707255] rpmsg_client_sample virtio0.ti.ipc4.ping-pong.-1.13: new channel: 0x401 -> 0xd!
>>>
>>> So in this case, rpmsg-io-1 can have different ept addr than rpmsg-io-2
>>> Back to same problem. Simple solution is to reply to remote with the
>>> created ept addr and the index.
>>
>> That why I would like to suggest to use the name service field to identify the port/controller, instead of the endpoint address.
>>>
>>>>
>>>> - match the RPMsg probe with the DT,
>>>
>>>
>>> We can probe from all controllers with a single name service
>>> announcement too.
>>>
>>>> - provide a simple mapping between the port and the endpoint on both sides,
>>>
>>>
>>> We are trying to get rid of this mapping from Linux side to adapt
>>> the gpio-virtio design.
>>>
>>>> - allow multiple endpoints on the remote side,
>>>
>>>
>>> We can support this as well with single nameservice model.
>>> There is no limitation. Remote has to send a message with
>>> its newly created ept that's all.
>>>
>>>> - provide a simple discovery mechanism for remote capabilities.
>>>
>>>
>>> A single announcement: "rpmsg-io" is also discovery mechanism.
>>>
>>> Feel free to let me know if you have concerns with any of the
>>> suggestions!
>>
>> My only concern, whatever the solution, is that we find a smart
>> solution to associate the correct endpoint with the correct GPIO
>> port/controller defined in the DT.
>
>
> In my solution, there is no need to have this map of endpoint to
> GPIO port at Linux side. This aligns more with virtio-gpio design
> as well.
>
>>
>> I may have misunderstood your solution. Could you please help me
>> understand your proposal by explaining how you would handle three
>> GPIO ports defined in the DT, considering that the endpoint
>> addresses on the Linux side can be random?
>> If I assume there is a unique endpoint on the remote side,
>> I do not understand how you can match, on the firmware side,
>> the Linux endpoint address to the GPIO port.
>
>
> Sure, let me take an example:
> Assumptions: 3 GPIO ports in DT, 3 endpoints in Linux (one per port),
> 1 endpoint in remote (0xd) and 1 rpmsg channel (rpmsg-io)
>
> rpmsg {
> rpmsg-io {
> #address-cells = <1>;
> #size-cells = <0>;
>
> gpio@25 {
> compatible = "rpmsg-gpio";
> reg = <25>;
> gpio-controller;
> #gpio-cells = <2>;
> #interrupt-cells = <2>;
> interrupt-controller;
> };
>
> gpio@32 {
> compatible = "rpmsg-gpio";
> reg = <32>;
> gpio-controller;
> #gpio-cells = <2>;
> #interrupt-cells = <2>;
> interrupt-controller;
> };
>
> gpio@35 {
> compatible = "rpmsg-gpio";
> reg = <35>;
> gpio-controller;
> #gpio-cells = <2>;
> #interrupt-cells = <2>;
> interrupt-controller;
> };
> };
> };
>
> Code Flow:
> 1. "rpmsg-io" channel is announced from remote firmware with unique dst
> ept = 0xd.
>
> 2. rpmsg_core.c creates the default dynamic local ept for the channel
> ept = 0x405.
>
> 3. rpmsg_core.c assigns the allocated addr to rpdev device:
> rpdev->src = 0x405 and rpdev->dst = 0xd.
>
> 4. rpmsg_gpio_channel_probe() is triggered. For *each* of the GPIO ports
> in DT, it will trigger rpmsg_gpiochip_register() which will now:
> a. Call port->ept = rpmsg_create_ept(rpdev,
> rpmsg_gpio_channel_callback,
> port,
> {rpdev.id.name,
> RPMSG_ADDR_ANY,
> RPMSG_ADDR_ANY});
> Ex- port->ept->addr = 0x408
>
> b. Prepare a 8-byte message having 2 fields:
> port->ept->addr (0x408) and port->idx (25)
>
> c. Send this message to remote firmware on default channel ept
> (0x405 -> 0xd) by:
> rpmsg_send(rpdev->ept, &message, sizeof(message));
>
> d. Remote side receives this message and creates a map of the
> linux_ept_addr to gpio_port. (0x408 <-> 25)
>
> 5. After this point, any gpio messages sent from Linux from gpio port
> endpoints (Ex- 0x408) can be decoded at remote side by looking up
> its map (Ex- map[0x408] = 25).
>
> 6. Any messages sent from remote to Linux for a particular gpio port can
> also be decoded at Linux by simply fetching the priv pointer to get
> the per-port device:
> struct rpmsg_gpio_port *port = priv;
>
Thanks for the details!
To sum up:
- the default endpoint acts as the GPIO controller (0x405),
- one extra Linux endpoint is created per port defined in DT.
This should work, but my concerns remain the same:
1) This implementation forces the remote processor to handle a single
endpoint instead of one endpoint per port. This may add complexity to
the remote firmware if each port is managed in a separate thread.
2) Linux, as a consumer, should not expose its capabilities to the remote
side (in your proposal it enumerates the ports defined in the DT).
In my view, the remote processor should expose its capabilities as the
provider.
From my perspective, based on your proposal:
1) Linux should send a get_config message to the remote proc (0x405 ->
0xD). 2) The remote processor would respond with the list of ports,
associated
with an remote endpoint addresses.
3) Linux would parse the response, compare it with the DT, enable the GPIO
ports accordingly, creating it local endpoint and associating it with
the remote endpoint.
Using name service to identify the ports should avoid step 1 & 2 ...
At the end, whatever solution is implemented, my main concern is that the
Linux driver design should, if possible, avoid adding unnecessary complexity
or limitations on the remote side (for instance in openAMP project).
Thanks,
Arnaud
> So Linux does not need to send the port idx everytime while sending a
> gpio message anymore.
>
> Thanks,
> Beleswar
>
> [...]
>
^ permalink raw reply
* [PATCH 2/2] Documentation: maple_tree: Clarify behavior when using reserved values
From: Wei-Lin Chang @ 2026-05-04 16:57 UTC (permalink / raw)
To: maple-tree, linux-mm, linux-doc, linux-kernel
Cc: Liam R . Howlett, Alice Ryhl, Andrew Ballance, Jonathan Corbet,
Shuah Khan, Wei-Lin Chang
In-Reply-To: <20260504165746.1422057-1-weilin.chang@arm.com>
It doesn't matter whether the normal or the advanced API is used if the
user uses xa_{mk, to}_value when storing and retrieving the values. Just
specify that the normal API blocks usages of reserved values while the
advanced API does not.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
Documentation/core-api/maple_tree.rst | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/core-api/maple_tree.rst b/Documentation/core-api/maple_tree.rst
index 87020a30ba69..e5ccafb84804 100644
--- a/Documentation/core-api/maple_tree.rst
+++ b/Documentation/core-api/maple_tree.rst
@@ -30,9 +30,9 @@ Tree reserves values with the bottom two bits set to '10' which are below 4096
(ie 2, 6, 10 .. 4094) for internal use. If the entries may use reserved
entries then the users can convert the entries using xa_mk_value() and convert
them back by calling xa_to_value(). Note that xa_{mk, to}_value() bit shifts
-the given data, so the top bit will be lost. If the user needs to use a
-reserved value, then the user can convert the value when using the
-:ref:`maple-tree-advanced-api`, but are blocked by the normal API.
+the given data, so the top bit will be lost. Usage of reserved values is
+blocked by the normal API, and will cause undefined behavior if used with the
+:ref:`maple-tree-advanced-api`.
The Maple Tree can also be configured to support searching for a gap of a given
size (or larger).
--
2.43.0
^ permalink raw reply related
* [PATCH 1/2] Documentation: maple_tree: Point out constraint when using xa_{mk, to}_value
From: Wei-Lin Chang @ 2026-05-04 16:57 UTC (permalink / raw)
To: maple-tree, linux-mm, linux-doc, linux-kernel
Cc: Liam R . Howlett, Alice Ryhl, Andrew Ballance, Jonathan Corbet,
Shuah Khan, Wei-Lin Chang
In-Reply-To: <20260504165746.1422057-1-weilin.chang@arm.com>
Using xa_{mk, to}_value when storing values loses the information of
the top bit from the left shift, point that out in the doc.
Signed-off-by: Wei-Lin Chang <weilin.chang@arm.com>
---
Documentation/core-api/maple_tree.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/core-api/maple_tree.rst b/Documentation/core-api/maple_tree.rst
index ccdd1615cf97..87020a30ba69 100644
--- a/Documentation/core-api/maple_tree.rst
+++ b/Documentation/core-api/maple_tree.rst
@@ -29,8 +29,9 @@ The Maple Tree can store values between ``0`` and ``ULONG_MAX``. The Maple
Tree reserves values with the bottom two bits set to '10' which are below 4096
(ie 2, 6, 10 .. 4094) for internal use. If the entries may use reserved
entries then the users can convert the entries using xa_mk_value() and convert
-them back by calling xa_to_value(). If the user needs to use a reserved
-value, then the user can convert the value when using the
+them back by calling xa_to_value(). Note that xa_{mk, to}_value() bit shifts
+the given data, so the top bit will be lost. If the user needs to use a
+reserved value, then the user can convert the value when using the
:ref:`maple-tree-advanced-api`, but are blocked by the normal API.
The Maple Tree can also be configured to support searching for a gap of a given
--
2.43.0
^ permalink raw reply related
* [PATCH 0/2] Documentation: maple_tree: Improve statements on reserved values
From: Wei-Lin Chang @ 2026-05-04 16:57 UTC (permalink / raw)
To: maple-tree, linux-mm, linux-doc, linux-kernel
Cc: Liam R . Howlett, Alice Ryhl, Andrew Ballance, Jonathan Corbet,
Shuah Khan, Wei-Lin Chang
Hi,
This is another version of [1], where I improved wording.
While using the maple tree and reading its documentation, I found a few
bits confusing, mainly about the reserved values. So here are some
changes hoping to make things clearer.
I am not familiar with the implementation, so if I got something wrong
please let me know.
While looking at the code I also found that although the doc claims the
normal API blocks reserved value stores, the code checks this using
xa_is_advanced(), which only blocks values up to 1026, not up to the max
maple tree reserved value 4094. For this part I am not sure whether the
code needs to be changed or we can also improve the doc.
Any feedback is appreciated, thanks!
[1]: https://lore.kernel.org/linux-mm/20260418204754.120405-1-weilin.chang@arm.com/
Wei-Lin Chang (2):
Documentation: maple_tree: Point out constraint when using xa_{mk,
to}_value
Documentation: maple_tree: Clarify behavior when using reserved values
Documentation/core-api/maple_tree.rst | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
--
2.43.0
^ permalink raw reply
* Re: [PATCH v3 11/20] drm/atomic-state-helper: Rename __drm_atomic_helper_crtc_state_reset()
From: Laurent Pinchart @ 2026-05-04 16:53 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-11-8b68d9db0d8b@kernel.org>
On Fri, Apr 24, 2026 at 12:18:51PM +0200, Maxime Ripard wrote:
> __drm_atomic_helper_crtc_state_reset() is used to initialize a newly
> allocated drm_crtc_state, and is being typically called by the
> drm_crtc_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_crtc_state instance, we will need to call
> __drm_atomic_helper_crtc_state_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_crtc_state_reset() to
> __drm_atomic_helper_crtc_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 10 +++++-----
> drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
> include/drm/drm_atomic_state_helper.h | 2 +-
> 3 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 50fe4eec41a8..9cd8550cabb7 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -61,25 +61,25 @@
> * For other drivers the building blocks are split out, see the documentation
> * for these functions.
> */
>
> /**
> - * __drm_atomic_helper_crtc_state_reset - reset the CRTC state
> + * __drm_atomic_helper_crtc_state_init - Initializes the CRTC state
"Initialize"
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> * @crtc_state: atomic CRTC state, must not be NULL
> * @crtc: CRTC object, must not be NULL
> *
> * Initializes the newly allocated @crtc_state with default
> * values. This is useful for drivers that subclass the CRTC state.
> */
> void
> -__drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *crtc_state,
> - struct drm_crtc *crtc)
> +__drm_atomic_helper_crtc_state_init(struct drm_crtc_state *crtc_state,
> + struct drm_crtc *crtc)
> {
> crtc_state->crtc = crtc;
> crtc_state->background_color = DRM_ARGB64_PREP(0xffff, 0, 0, 0);
> }
> -EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
> +EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_init);
>
> /**
> * __drm_atomic_helper_crtc_reset - reset state on CRTC
> * @crtc: drm CRTC
> * @crtc_state: CRTC state to assign
> @@ -94,11 +94,11 @@ EXPORT_SYMBOL(__drm_atomic_helper_crtc_state_reset);
> void
> __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
> struct drm_crtc_state *crtc_state)
> {
> if (crtc_state)
> - __drm_atomic_helper_crtc_state_reset(crtc_state, crtc);
> + __drm_atomic_helper_crtc_state_init(crtc_state, crtc);
>
> if (drm_dev_has_vblank(crtc->dev))
> drm_crtc_vblank_reset(crtc);
>
> crtc->state = crtc_state;
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c b/drivers/gpu/drm/i915/display/intel_crtc.c
> index b8189cd5d864..a2ed4a76e061 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -179,11 +179,11 @@ struct intel_crtc_state *intel_crtc_state_alloc(struct intel_crtc *crtc)
> void intel_crtc_state_reset(struct intel_crtc_state *crtc_state,
> struct intel_crtc *crtc)
> {
> memset(crtc_state, 0, sizeof(*crtc_state));
>
> - __drm_atomic_helper_crtc_state_reset(&crtc_state->uapi, &crtc->base);
> + __drm_atomic_helper_crtc_state_init(&crtc_state->uapi, &crtc->base);
>
> crtc_state->cpu_transcoder = INVALID_TRANSCODER;
> crtc_state->master_transcoder = INVALID_TRANSCODER;
> crtc_state->hsw_workaround_pipe = INVALID_PIPE;
> crtc_state->scaler_state.scaler_id = -1;
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index df371b2eef3e..e7fbbfdc5d69 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -38,11 +38,11 @@ struct drm_connector_state;
> struct drm_private_obj;
> struct drm_private_state;
> struct drm_modeset_acquire_ctx;
> struct drm_device;
>
> -void __drm_atomic_helper_crtc_state_reset(struct drm_crtc_state *state,
> +void __drm_atomic_helper_crtc_state_init(struct drm_crtc_state *state,
> struct drm_crtc *crtc);
> void __drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
> struct drm_crtc_state *state);
> void drm_atomic_helper_crtc_reset(struct drm_crtc *crtc);
> void __drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc,
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 10/20] drm/plane: Add new atomic_create_state callback
From: Laurent Pinchart @ 2026-05-04 16:52 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-10-8b68d9db0d8b@kernel.org>
Hi Maxime,
Thank you for the patch.
On Fri, Apr 24, 2026 at 12:18:50PM +0200, Maxime Ripard wrote:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software state, reset it,
> but also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> reset() also isn't fallible, which makes it harder to handle
> initialization errors properly. This is only really relevant for some
> drivers though, since all the helpers for reset only create a new
> state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect:
> atomic_create_state to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Continue the transition to the new pattern with planes.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 25 +++++++++++++++++++++++++
> drivers/gpu/drm/drm_mode_config.c | 21 ++++++++++++++++++++-
> include/drm/drm_atomic_state_helper.h | 2 ++
> include/drm/drm_plane.h | 16 ++++++++++++++++
> 4 files changed, 63 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index 285efbf29520..50fe4eec41a8 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -338,10 +338,35 @@ void drm_atomic_helper_plane_reset(struct drm_plane *plane)
> if (plane->state)
> __drm_atomic_helper_plane_reset(plane, plane->state);
> }
> EXPORT_SYMBOL(drm_atomic_helper_plane_reset);
>
> +/**
> + * drm_atomic_helper_plane_create_state - default &drm_plane_funcs.atomic_create_state hook for planes
drm_atomic_helper_colorop_create_state() states "Allocates and
initializes colorop atomic state", while here you document it as
"default hook for planes". Consistency would be good.
> + * @plane: plane object
> + *
> + * Initializes a pristine @drm_plane_state.
"Allocate and initialize ..."
> + *
> + * This is useful for drivers that don't subclass @drm_plane_state.
> + *
> + * RETURNS:
> + * Pointer to new plane state, or ERR_PTR on failure.
> + */
> +struct drm_plane_state *drm_atomic_helper_plane_create_state(struct drm_plane *plane)
> +{
> + struct drm_plane_state *state;
> +
> + state = kzalloc_obj(*state);
> + if (!state)
> + return ERR_PTR(-ENOMEM);
> +
> + __drm_atomic_helper_plane_state_init(state, plane);
> +
> + return state;
> +}
> +EXPORT_SYMBOL(drm_atomic_helper_plane_create_state);
> +
> /**
> * __drm_atomic_helper_plane_duplicate_state - copy atomic plane state
> * @plane: plane object
> * @state: atomic plane state
> *
> diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
> index c33382a38191..10b7815cbe48 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -180,10 +180,26 @@ int drm_mode_getresources(struct drm_device *dev, void *data,
> drm_connector_list_iter_end(&conn_iter);
>
> return ret;
> }
>
> +static int drm_mode_config_plane_create_state(struct drm_plane *plane)
> +{
> + struct drm_plane_state *plane_state;
> +
> + if (!plane->funcs->atomic_create_state)
> + return 0;
> +
> + plane_state = plane->funcs->atomic_create_state(plane);
> + if (IS_ERR(plane_state))
> + return PTR_ERR(plane_state);
> +
> + plane->state = plane_state;
> +
> + return 0;
> +}
> +
> /**
> * drm_mode_config_reset - call ->reset callbacks
> * @dev: drm device
> *
> * This functions calls all the crtc's, encoder's and connector's ->reset
> @@ -204,13 +220,16 @@ void drm_mode_config_reset(struct drm_device *dev)
> struct drm_connector_list_iter conn_iter;
>
> drm_for_each_colorop(colorop, dev)
> drm_colorop_reset(colorop);
>
> - drm_for_each_plane(plane, dev)
> + drm_for_each_plane(plane, dev) {
> if (plane->funcs->reset)
> plane->funcs->reset(plane);
> + else if (plane->funcs->atomic_create_state)
> + drm_mode_config_plane_create_state(plane);
> + }
>
> drm_for_each_crtc(crtc, dev)
> if (crtc->funcs->reset)
> crtc->funcs->reset(crtc);
>
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index 44e8850aae7f..df371b2eef3e 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -53,10 +53,12 @@ void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state);
> void drm_atomic_helper_crtc_destroy_state(struct drm_crtc *crtc,
> struct drm_crtc_state *state);
>
> void __drm_atomic_helper_plane_state_init(struct drm_plane_state *state,
> struct drm_plane *plane);
> +struct drm_plane_state *
> +drm_atomic_helper_plane_create_state(struct drm_plane *plane);
> void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> struct drm_plane_state *state);
> void drm_atomic_helper_plane_reset(struct drm_plane *plane);
> void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
> struct drm_plane_state *state);
> diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
> index 703ef4d1bbbc..886e219c4609 100644
> --- a/include/drm/drm_plane.h
> +++ b/include/drm/drm_plane.h
> @@ -386,10 +386,26 @@ struct drm_plane_funcs {
> * 0 on success or a negative error code on failure.
> */
> int (*set_property)(struct drm_plane *plane,
> struct drm_property *property, uint64_t val);
>
> + /**
> + * @atomic_create_state:
> + *
> + * Allocates a pristine, initialized, state for the plane object
s/Allocates/Allocate/
based on the documentation of other callbacks, and the fact that
imperative style is the usual standard in kernel documentation.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> + * and returns it. This callback must have no side effects: in
> + * particular, the returned state must not be assigned to the
> + * object's state pointer and it must not affect the hardware
> + * state.
> + *
> + * RETURNS:
> + *
> + * A new, pristine, plane state instance or an error pointer
> + * on failure.
> + */
> + struct drm_plane_state *(*atomic_create_state)(struct drm_plane *plane);
> +
> /**
> * @atomic_duplicate_state:
> *
> * Duplicate the current atomic state for this plane and return it.
> * The core and helpers guarantee that any atomic state duplicated with
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2] iio: adxl313: fix typos in documentation
From: Jonathan Cameron @ 2026-05-04 16:43 UTC (permalink / raw)
To: Wang Zihan; +Cc: linux-iio, linux-doc
In-Reply-To: <tencent_EC262467CD5E46CA97CF2B2FDCBCA0565C08@qq.com>
On Sat, 2 May 2026 14:07:00 +0800
Wang Zihan <jiyu03@qq.com> wrote:
> Add missing space in "ADXL313is" and correct "a single types"
> to "a single type".
>
> Signed-off-by: Wang Zihan <jiyu03@qq.com>
> ---
> Documentation/iio/adxl313.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/iio/adxl313.rst b/Documentation/iio/adxl313.rst
> index 966e72c01..3662153a6 100644
> --- a/Documentation/iio/adxl313.rst
> +++ b/Documentation/iio/adxl313.rst
> @@ -11,7 +11,7 @@ This driver supports Analog Device's ADXL313 on SPI/I2C bus.
>
> * `ADXL313 <https://www.analog.com/ADXL313>`_
>
> -The ADXL313is a low noise density, low power, 3-axis accelerometer with
> +The ADXL313 is a low noise density, low power, 3-axis accelerometer with
> selectable measurement ranges. The ADXL313 supports the ±0.5 g, ±1 g, ±2 g and
> ±4 g ranges.
>
> @@ -112,7 +112,7 @@ apply the following formula:
> Where _offset and _scale are device attributes. If no _offset attribute is
> present, simply assume its value is 0.
>
> -The ADXL313 driver offers data for a single types of channels, the table below
> +The ADXL313 driver offers data for a single type of channels, the table below
ooh. That's fun grammar. Intent is that there are multiple channels of one type
but the form used in your corrected version is at best unwieldy given plural
singular mix. "a single type of channel" is fine for instance but this isn't really.
I'd rewrite as
The ADXL313 driver offers data for multiple channels of a single type. The table
below...
(so split he thing up into two sentences as well).
> shows the measurement units for the processed value, which are defined by the
> IIO framework:
>
^ permalink raw reply
* Re: [PATCH v3 09/20] drm/atomic-state-helper: Rename __drm_atomic_helper_plane_state_reset()
From: Laurent Pinchart @ 2026-05-04 16:42 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-9-8b68d9db0d8b@kernel.org>
On Fri, Apr 24, 2026 at 12:18:49PM +0200, Maxime Ripard wrote:
> __drm_atomic_helper_plane_state_reset() is used to initialize a newly
> allocated drm_plane_state, and is being typically called by the
> drm_plane_funcs.reset implementation.
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_plane_state instance, we will need to call
> __drm_atomic_helper_plane_state_reset() from both the reset and
> atomic_create hooks.
>
> To avoid any confusion, we can thus rename
> __drm_atomic_helper_plane_state_reset() to
> __drm_atomic_helper_plane_state_init().
>
> Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/gpu/drm/drm_atomic_state_helper.c | 12 ++++++------
> drivers/gpu/drm/i915/display/intel_plane.c | 2 +-
> include/drm/drm_atomic_state_helper.h | 2 +-
> 3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
> index e1f3d05ad347..285efbf29520 100644
> --- a/drivers/gpu/drm/drm_atomic_state_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_state_helper.c
> @@ -235,19 +235,19 @@ void drm_atomic_helper_crtc_destroy_state(struct drm_crtc *crtc,
> kfree(state);
> }
> EXPORT_SYMBOL(drm_atomic_helper_crtc_destroy_state);
>
> /**
> - * __drm_atomic_helper_plane_state_reset - resets plane state to default values
> + * __drm_atomic_helper_plane_state_init - Initializes the plane state
> * @plane_state: atomic plane state, must not be NULL
> * @plane: plane object, must not be NULL
> *
> * Initializes the newly allocated @plane_state with default
> - * values. This is useful for drivers that subclass the CRTC state.
> + * values. This is useful for drivers that subclass the plane state.
> */
> -void __drm_atomic_helper_plane_state_reset(struct drm_plane_state *plane_state,
> - struct drm_plane *plane)
> +void __drm_atomic_helper_plane_state_init(struct drm_plane_state *plane_state,
> + struct drm_plane *plane)
> {
> u64 val;
>
> plane_state->plane = plane;
> plane_state->rotation = DRM_MODE_ROTATE_0;
> @@ -295,11 +295,11 @@ void __drm_atomic_helper_plane_state_reset(struct drm_plane_state *plane_state,
> plane->hotspot_y_property,
> &val))
> plane_state->hotspot_y = val;
> }
> }
> -EXPORT_SYMBOL(__drm_atomic_helper_plane_state_reset);
> +EXPORT_SYMBOL(__drm_atomic_helper_plane_state_init);
>
> /**
> * __drm_atomic_helper_plane_reset - reset state on plane
> * @plane: drm plane
> * @plane_state: plane state to assign
> @@ -313,11 +313,11 @@ EXPORT_SYMBOL(__drm_atomic_helper_plane_state_reset);
> */
> void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> struct drm_plane_state *plane_state)
> {
> if (plane_state)
> - __drm_atomic_helper_plane_state_reset(plane_state, plane);
> + __drm_atomic_helper_plane_state_init(plane_state, plane);
>
> plane->state = plane_state;
> }
> EXPORT_SYMBOL(__drm_atomic_helper_plane_reset);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_plane.c b/drivers/gpu/drm/i915/display/intel_plane.c
> index 5390ceb21ca4..d013d9228d0b 100644
> --- a/drivers/gpu/drm/i915/display/intel_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_plane.c
> @@ -65,11 +65,11 @@
> static void intel_plane_state_reset(struct intel_plane_state *plane_state,
> struct intel_plane *plane)
> {
> memset(plane_state, 0, sizeof(*plane_state));
>
> - __drm_atomic_helper_plane_state_reset(&plane_state->uapi, &plane->base);
> + __drm_atomic_helper_plane_state_init(&plane_state->uapi, &plane->base);
>
> plane_state->scaler_id = -1;
> }
>
> struct intel_plane *intel_plane_alloc(void)
> diff --git a/include/drm/drm_atomic_state_helper.h b/include/drm/drm_atomic_state_helper.h
> index 900672c6ea90..44e8850aae7f 100644
> --- a/include/drm/drm_atomic_state_helper.h
> +++ b/include/drm/drm_atomic_state_helper.h
> @@ -51,11 +51,11 @@ struct drm_crtc_state *
> drm_atomic_helper_crtc_duplicate_state(struct drm_crtc *crtc);
> void __drm_atomic_helper_crtc_destroy_state(struct drm_crtc_state *state);
> void drm_atomic_helper_crtc_destroy_state(struct drm_crtc *crtc,
> struct drm_crtc_state *state);
>
> -void __drm_atomic_helper_plane_state_reset(struct drm_plane_state *state,
> +void __drm_atomic_helper_plane_state_init(struct drm_plane_state *state,
> struct drm_plane *plane);
> void __drm_atomic_helper_plane_reset(struct drm_plane *plane,
> struct drm_plane_state *state);
> void drm_atomic_helper_plane_reset(struct drm_plane *plane);
> void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane,
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 07/20] drm/colorop: Create drm_atomic_helper_colorop_create_state()
From: Laurent Pinchart @ 2026-05-04 16:41 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-7-8b68d9db0d8b@kernel.org>
On Fri, Apr 24, 2026 at 12:18:47PM +0200, Maxime Ripard wrote:
> Commit 47b5ac7daa46 ("drm/atomic: Add new atomic_create_state callback
> to drm_private_obj") introduced a new pattern for allocating drm object
> states.
>
> Instead of relying on the reset() callback, it created a new
> atomic_create_state hook. This is helpful because reset is a bit
> overloaded: it's used to create the initial software state, reset it,
> but also reset the hardware.
>
> It can also be used either at probe time, to create the initial state
> and possibly reset the hardware to an expected default, but also during
> suspend/resume.
>
> Both these cases come with different expectations too: during the
> initialization, we want to initialize all states, but during
> suspend/resume, drm_private_states for example are expected to be kept
> around.
>
> reset() also isn't fallible, which makes it harder to handle
> initialization errors properly. This is only really relevant for some
> drivers though, since all the helpers for reset only create a new
> state, and don't touch the hardware at all.
>
> It was thus decided to create a new hook that would allocate and
> initialize a pristine state without any side effect:
> atomic_create_state to untangle a bit some of it, and to separate the
> initialization with the actual reset one might need during a
> suspend/resume.
>
> Continue the transition to the new pattern with drm_colorop.
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/gpu/drm/drm_colorop.c | 23 +++++++++++++++++++++++
> include/drm/drm_colorop.h | 2 ++
> 2 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
> index 4c4d0a953e35..c0eecde8c176 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -521,10 +521,33 @@ static void __drm_colorop_state_init(struct drm_colorop_state *colorop_state,
> &val))
> colorop_state->curve_1d_type = val;
> }
> }
>
> +/**
> + * drm_atomic_helper_colorop_create_state - Allocates and initializes colorop atomic state
> + * @colorop: drm colorop
> + *
> + * Initializes a pristine @drm_colorop_state.
> + *
> + * RETURNS:
> + * Pointer to new colorop state, or ERR_PTR on failure.
> + */
> +struct drm_colorop_state *
> +drm_atomic_helper_colorop_create_state(struct drm_colorop *colorop)
> +{
> + struct drm_colorop_state *state;
> +
> + state = kzalloc_obj(*state);
> + if (!state)
> + return ERR_PTR(-ENOMEM);
> +
> + __drm_colorop_state_init(state, colorop);
> +
> + return state;
> +}
> +
> /**
> * __drm_colorop_reset - reset state on colorop
> * @colorop: drm colorop
> * @colorop_state: colorop state to assign
> *
> diff --git a/include/drm/drm_colorop.h b/include/drm/drm_colorop.h
> index bd082854ca74..874ed693329c 100644
> --- a/include/drm/drm_colorop.h
> +++ b/include/drm/drm_colorop.h
> @@ -423,10 +423,12 @@ int drm_plane_colorop_3dlut_init(struct drm_device *dev, struct drm_colorop *col
> struct drm_plane *plane, const struct drm_colorop_funcs *funcs,
> uint32_t lut_size,
> enum drm_colorop_lut3d_interpolation_type interpolation,
> uint32_t flags);
>
> +struct drm_colorop_state *
> +drm_atomic_helper_colorop_create_state(struct drm_colorop *colorop);
> struct drm_colorop_state *
> drm_atomic_helper_colorop_duplicate_state(struct drm_colorop *colorop);
>
> void drm_colorop_atomic_destroy_state(struct drm_colorop *colorop,
> struct drm_colorop_state *state);
>
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v2] iio: adxl313: fix typos in documentation
From: Jonathan Cameron @ 2026-05-04 16:38 UTC (permalink / raw)
To: Wang Zihan; +Cc: joshua.crofts1, linux-iio, linux-doc
In-Reply-To: <tencent_5E6677A3FFCB969503EE5250592E75128807@qq.com>
On Sat, 2 May 2026 20:53:43 +0800
Wang Zihan <jiyu03@qq.com> wrote:
> Hi Joshua,
>
> Thank you for the review!
>
> I apologize for the quick v2. The v1 had an incorrect subject format
> ([PATCH 1/4] instead of [PATCH]) which could cause confusion. I sent
> v2 to correct this formatting issue.
Make sure you include a change log below the ---
That would have let Joshua and the rest of us know why you resent.
Particularly important when doing a quick resend.
Thanks,
Jonathan
>
> I will keep the 24-hour rule in mind for future submissions.
>
> Best regards,
> Wang Zihan
>
^ permalink raw reply
* Re: [PATCH v3 06/20] drm/colorop: Rename __drm_colorop_state_reset()
From: Laurent Pinchart @ 2026-05-04 16:36 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-6-8b68d9db0d8b@kernel.org>
Hi Maxime,
Thank you for the patch.
On Fri, Apr 24, 2026 at 12:18:46PM +0200, Maxime Ripard wrote:
> __drm_colorop_state_reset() is used to initialize a newly allocated
> drm_colorop_state, and is being typically called by drm_colorop_reset().
>
> Since we want to consolidate DRM objects state allocation around the
> atomic_create_state callback that will only allocate and initialize a
> new drm_colorop_state instance, we will need to call
> __drm_colorop_state_reset() from both the reset and atomic_create paths.
>
> To avoid any confusion, we can thus rename __drm_colorop_state_reset()
> to __drm_colorop_state_init().
>
> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> drivers/gpu/drm/drm_colorop.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_colorop.c b/drivers/gpu/drm/drm_colorop.c
> index 48d0b7ae3fc9..4c4d0a953e35 100644
> --- a/drivers/gpu/drm/drm_colorop.c
> +++ b/drivers/gpu/drm/drm_colorop.c
> @@ -498,19 +498,19 @@ void drm_colorop_atomic_destroy_state(struct drm_colorop *colorop,
> __drm_atomic_helper_colorop_destroy_state(state);
> kfree(state);
> }
>
> /**
> - * __drm_colorop_state_reset - resets colorop state to default values
> + * __drm_colorop_state_init - Initializes colorop state to default values
> * @colorop_state: atomic colorop state, must not be NULL
> * @colorop: colorop object, must not be NULL
> *
> * Initializes the newly allocated @colorop_state with default
> * values. This is useful for drivers that subclass the colorop state.
> */
> -static void __drm_colorop_state_reset(struct drm_colorop_state *colorop_state,
> - struct drm_colorop *colorop)
> +static void __drm_colorop_state_init(struct drm_colorop_state *colorop_state,
> + struct drm_colorop *colorop)
> {
> u64 val;
>
> colorop_state->colorop = colorop;
> colorop_state->bypass = true;
> @@ -537,11 +537,11 @@ static void __drm_colorop_state_reset(struct drm_colorop_state *colorop_state,
> */
> static void __drm_colorop_reset(struct drm_colorop *colorop,
> struct drm_colorop_state *colorop_state)
> {
> if (colorop_state)
> - __drm_colorop_state_reset(colorop_state, colorop);
> + __drm_colorop_state_init(colorop_state, colorop);
>
> colorop->state = colorop_state;
> }
>
> void drm_colorop_reset(struct drm_colorop *colorop)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v3 04/20] drm/atomic: Expand atomic_create_state expectations for drm_private_obj
From: Laurent Pinchart @ 2026-05-04 16:34 UTC (permalink / raw)
To: Maxime Ripard
Cc: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Simon Ser, Harry Wentland,
Melissa Wen, Sebastian Wick, Alex Hung, Jani Nikula, Rodrigo Vivi,
Joonas Lahtinen, Tvrtko Ursulin, Chen-Yu Tsai, Samuel Holland,
Dave Stevenson, Maíra Canal, Raspberry Pi Kernel Maintenance,
dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi
In-Reply-To: <20260424-drm-mode-config-init-v3-4-8b68d9db0d8b@kernel.org>
Hi Maxime,
Thank you for the patch.
On Fri, Apr 24, 2026 at 12:18:44PM +0200, Maxime Ripard wrote:
> The atomic_create_state callback documentation for planes, CRTCs, and
> connectors explicitly states the expected behaviour: the returned
> state must not be assigned to the object's state pointer, and hardware
> must not be touched.
>
> The drm_private_state_funcs.atomic_create_state documentation is
> missing this clarification. Add it for consistency.
>
> Signed-off-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
> ---
> include/drm/drm_atomic.h | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index f03cd199aee7..f7f9c6c85f3a 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -263,11 +263,14 @@ struct drm_private_state;
> struct drm_private_state_funcs {
> /**
> * @atomic_create_state:
> *
> * Allocates a pristine, initialized, state for the private
> - * object and returns it.
> + * object and returns it. This callback must have no side
> + * effects: in particular, the returned state must not be
> + * assigned to the object's state pointer and it must not affect
> + * the hardware state.
> *
> * RETURNS:
> *
> * A new, pristine, private state instance or an error pointer
> * on failure.
--
Regards,
Laurent Pinchart
^ 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