* Re: [PATCH net-next 09/10] docs: net: render the checksum comment in checksum-offloads.rst
From: Willem de Bruijn @ 2026-05-26 18:56 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
vladimir.oltean, willemb, sdf.kernel, ecree.xilinx,
jesse.brandeburg, linux-doc, Jakub Kicinski
In-Reply-To: <20260526160151.2793354-10-kuba@kernel.org>
Jakub Kicinski wrote:
> checksum-offloads.rst seems like a better place to render
> the checksum comment than skbuff.rst.
>
> Remove the stale references to sections in that comment
> (it no longer has A, B, C, D, E sections).
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH net-next 08/10] docs: net: add Rx notes to the checksum guide
From: Willem de Bruijn @ 2026-05-26 18:56 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
vladimir.oltean, willemb, sdf.kernel, ecree.xilinx,
jesse.brandeburg, linux-doc, Jakub Kicinski
In-Reply-To: <20260526160151.2793354-9-kuba@kernel.org>
Jakub Kicinski wrote:
> The Rx checksum processing gives people pause. The two main questions
> in my experience are:
> - what to do with bad IPv4 checksum; and
> - what to do with packets with bad checksum.
>
> Folks often feel the urge to drop the latter, to "avoid overloading
> the host".
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Thanks, this is is an important clarification.
> ---
> Documentation/networking/checksum-offloads.rst | 17 ++++++++++++++++-
> 1 file changed, 16 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/networking/checksum-offloads.rst b/Documentation/networking/checksum-offloads.rst
> index 907aed9f3a3b..d838fe5c1606 100644
> --- a/Documentation/networking/checksum-offloads.rst
> +++ b/Documentation/networking/checksum-offloads.rst
> @@ -19,7 +19,6 @@ take advantage of checksum offload capabilities of various NICs.
>
> Things that should be documented here but aren't yet:
>
> -* RX Checksum Offload
> * CHECKSUM_UNNECESSARY conversion
>
>
> @@ -139,3 +138,19 @@ In Linux, RCO is implemented individually in each encapsulation protocol, and
> most tunnel types have flags controlling its use. For instance, VXLAN has the
> configuration flag VXLAN_F_REMCSUM_TX to indicate that RCO should be used when
> transmitting.
> +
> +
> +RX Checksum Offload
> +===================
> +
> +RX checksum offload is controlled via NETIF_F_RXCSUM. When disabled the driver
> +must not set skb->ip_summed on ingress packets. As mentioned, IPv4 checksum
> +is not offloaded, the RXCSUM feature controls the offload of verification of
> +transport layer checksums.
> +
> +Note that packets with bad TCP/UDP checksums must still be passed
> +to the stack. skb->ip_summed of such packets can be set to ``CHECKSUM_COMPLETE``
when also setting skb->csum
> +or left at ``CHECKSUM_NONE``. Drivers **must not discard** packets with
> +bad TCP/UDP checksum and must not configure the device to drop them.
> +Checksum validation is relatively inexpensive and having bad packets reflected
> +in SNMP counters is crucial for network monitoring.
> --
> 2.54.0
>
^ permalink raw reply
* Re: [PATCH v2 0/4] mm/zswap: Implement per-cgroup proactive writeback
From: Yosry Ahmed @ 2026-05-26 18:55 UTC (permalink / raw)
To: Hao Jia
Cc: Andrew Morton, tj, hannes, shakeel.butt, mhocko, mkoutny, nphamcs,
chengming.zhou, muchun.song, roman.gushchin, cgroups, linux-mm,
linux-kernel, linux-doc, Hao Jia
In-Reply-To: <9b2ac88c-a67f-2512-d898-3dadd50ec03e@gmail.com>
On Tue, May 26, 2026 at 4:56 AM Hao Jia <jiahao.kernel@gmail.com> wrote:
>
>
>
> On 2026/5/26 03:24, Andrew Morton wrote:
> > On Mon, 25 May 2026 20:22:38 +0800 Hao Jia <jiahao.kernel@gmail.com> wrote:
> >
> >> Zswap currently writes back pages to backing swap reactively, triggered
> >> either by the shrinker or by the pool reaching its size limit. Although
> >> proactive memory reclaim can automatically write back a portion of zswap
> >> pages via the shrinker, it cannot explicitly control the amount of
> >> writeback for a specific memory cgroup. Moreover, proactive memory reclaim
> >> may not always be triggered during a steady state.
> >>
> >> In certain scenarios, it is desirable to trigger writeback in advance to
> >> free up memory. For example, users may want to prepare for an upcoming
> >> memory-intensive workload by flushing cold memory to the backing storage
> >> when the system is relatively idle.
> >>
> >> This patch series introduces a "zswap_writeback_only" key to memory.reclaim
> >> cgroup interface, allowing users to proactively write back cold compressed
> >> pages from zswap to the backing swap device. When specified, this key
> >> bypasses standard memory reclaim and exclusively performs proactive zswap
> >> writeback up to the requested budget. If omitted, the default reclaim
> >> behavior remains unchanged.
> >
> > Thanks. AI review found a few things to complain about, one of them
> > described as "preexisting".
> >
>
> Thanks Andrew. I have replied to the AI's review comments in a separate
> email and posted v3.
> https://lore.kernel.org/all/20260526114601.67041-1-jiahao.kernel@gmail.com
Generally speaking, please give time for reviewers to take a look
before sending a new version. Less than a day is usually too fast
(unless you're iterating super fast with the reviewers). Review
feedback does not have to be addressed immediately, usually wait for a
bit to collect as much feedback as possible before spinning a new
version.
I will take a look at v3 soon, thank you.
^ permalink raw reply
* Re: [PATCH net-next 00/10] docs: net: updates for old and cobwebbed docs
From: Randy Dunlap @ 2026-05-26 18:48 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
vladimir.oltean, willemb, sdf.kernel, ecree.xilinx,
jesse.brandeburg, linux-doc
In-Reply-To: <20260526160151.2793354-1-kuba@kernel.org>
Hi,
On 5/26/26 9:01 AM, Jakub Kicinski wrote:
> I'm hoping to start feeding our docs into the AI review tools, instead
> of maintaining a separate repo with review prompts. To experiment with
> that we have to refresh the docs a little bit.
>
> A read thru our current docs makes one slightly question the value
> of including them in reviews. But directionally, I feel, it's probably
> still right. I'm hoping the Rx Checksum section about not dropping packets
> for example to be impactful. I don't think the current AI agents or
> review docs include this guidance.
>
> Jakub Kicinski (10):
> docs: net: netdevices: small fixes and clarifications
> docs: net: fix minor issues with driver guide
> docs: net: statistics: fix kernel-internal stats list
> docs: net: update devmem code examples
> docs: net: fix minor issues with the NAPI guide
> docs: net: refresh netdev feature guidance
> docs: net: fix minor issues with checksum offloads
> docs: net: add Rx notes to the checksum guide
> docs: net: render the checksum comment in checksum-offloads.rst
> docs: net: fix minor issues with segmentation offloads
>
> .../networking/checksum-offloads.rst | 67 ++++++++++++-------
> Documentation/networking/devmem.rst | 27 +++-----
> Documentation/networking/driver.rst | 7 +-
> Documentation/networking/napi.rst | 11 ++-
> Documentation/networking/netdev-features.rst | 60 +++++++++++------
> Documentation/networking/netdevices.rst | 31 +++++----
> .../networking/segmentation-offloads.rst | 37 +++++++++-
> Documentation/networking/skbuff.rst | 6 --
> Documentation/networking/statistics.rst | 19 ++++--
> 9 files changed, 172 insertions(+), 93 deletions(-)
>
There is one more cleanup that you could do. Current (linux-next) docs builds
give this warning:
WARNING: ../include/linux/netdevice.h:2622 Excess struct member 'ax25_ptr' description in 'net_device'
--
~Randy
^ permalink raw reply
* Re: [PATCH net-next 06/10] docs: net: refresh netdev feature guidance
From: Maxime Chevallier @ 2026-05-26 18:41 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
vladimir.oltean, willemb, sdf.kernel, ecree.xilinx,
jesse.brandeburg, linux-doc
In-Reply-To: <20260526160151.2793354-7-kuba@kernel.org>
Hi Jakub
On 5/26/26 18:01, Jakub Kicinski wrote:
>
> 1. netdev->hw_features set contains features whose state may possibly
> be changed (enabled or disabled) for a particular device by user's
> - request. This set should be initialized in ndo_init callback and not
> - changed later.
> + request. Drivers normally initialize this set before registration or
> + in the ndo_init callback. Changes after registration should be made
> + very carefully as other parts of the code may assume hw_features are
> + static. At the very least changes must be made under rtnl_lock and
> + the netdev instance lock, and followed by netdev_update_features().
Feel free to keep this description as-is, but can we get somewhere the
actual meaning of "hw" in "hw_features" ? I've seen this cause confusion
before as this is sometimes wrongly interpreted as "Hardware features",
which isn't correct as the hardware may do stuff without allowing users
to change that behaviour.
I vaguely recall something along the lines of "Host-Writeable features",
but I am not sure at all about that...
Maxime
^ permalink raw reply
* Re: [PATCH v12 01/15] kasan: sw_tags: Use arithmetic shift for shadow computation
From: Catalin Marinas @ 2026-05-26 18:29 UTC (permalink / raw)
To: Maciej Wieczor-Retman
Cc: Will Deacon, Jonathan Corbet, Shuah Khan, Andrey Ryabinin,
Alexander Potapenko, Andrey Konovalov, Dmitry Vyukov,
Vincenzo Frascino, Andrew Morton, Jan Kiszka, Kieran Bingham,
Nathan Chancellor, Nick Desaulniers, Bill Wendling, Justin Stitt,
Samuel Holland, Maciej Wieczor-Retman, linux-arm-kernel,
linux-doc, linux-kernel, kasan-dev, workflows, linux-mm, llvm
In-Reply-To: <c36fe46e1dde1a759e8ffdd0fe9439bdf2c66dd8.1774872838.git.m.wieczorretman@pm.me>
On Mon, Mar 30, 2026 at 02:33:05PM +0000, Maciej Wieczor-Retman wrote:
> diff --git a/Documentation/arch/arm64/kasan-offsets.sh b/Documentation/arch/arm64/kasan-offsets.sh
> index 2dc5f9e18039..ce777c7c7804 100644
> --- a/Documentation/arch/arm64/kasan-offsets.sh
> +++ b/Documentation/arch/arm64/kasan-offsets.sh
> @@ -5,8 +5,12 @@
>
> print_kasan_offset () {
> printf "%02d\t" $1
> - printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \
> - - (1 << (64 - 32 - $2)) ))
> + if [[ $2 -ne 4 ]] then
Nitpick: does this need a semicolon before 'then'?
I can see Sashiko raised it here:
https://sashiko.dev/#/patchset/cover.1774872838.git.m.wieczorretman@pm.me
> + printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) \
> + - (1 << (64 - 32 - $2)) ))
> + else
> + printf "0x%08x00000000\n" $(( (0xffffffff & (-1 << ($1 - 1 - 32))) ))
> + fi
> }
>
> echo KASAN_SHADOW_SCALE_SHIFT = 3
[...]
> diff --git a/scripts/gdb/linux/kasan.py b/scripts/gdb/linux/kasan.py
> index 56730b3fde0b..4b86202b155f 100644
> --- a/scripts/gdb/linux/kasan.py
> +++ b/scripts/gdb/linux/kasan.py
> @@ -7,7 +7,8 @@
> #
>
> import gdb
> -from linux import constants, mm
> +from linux import constants, utils, mm
> +from ctypes import c_int64 as s64
>
> def help():
> t = """Usage: lx-kasan_mem_to_shadow [Hex memory addr]
> @@ -39,6 +40,8 @@ class KasanMemToShadow(gdb.Command):
> else:
> help()
> def kasan_mem_to_shadow(self, addr):
> + if constants.CONFIG_KASAN_SW_TAGS and not utils.is_target_arch('x86'):
Does this need to be constants.LX_CONFIG_KASAN_SW_TAGS? I don't claim I
fully understand this script but the other constants.* use LX_*.
> + addr = s64(addr)
> return (addr >> self.p_ops.KASAN_SHADOW_SCALE_SHIFT) + self.p_ops.KASAN_SHADOW_OFFSET
And, again, Sashiko mentions that the bitwise right shift here will fail
after the cast to c_int64. I just tried this in python:
>>> from ctypes import c_int64 as s64
>>> s64(0xffff000008eca008) >> 4
Traceback (most recent call last):
File "<python-input-1>", line 1, in <module>
s64(0xffff000008eca008) >> 4
~~~~~~~~~~~~~~~~~~~~~~~~^^~~
TypeError: unsupported operand type(s) for >>: 'c_long' and 'int'
I guess it's hidden by the wrong check on
constants.CONFIG_KASAN_SW_TAGS.
Otherwise I think the changes are fine. If you fix the above, feel free
to add:
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* [PATCH 3/3] ALSA: usb-audio: Add quirk flag for Sennheiser MOMENTUM 3
From: Rong Zhang @ 2026-05-26 17:49 UTC (permalink / raw)
To: Jaroslav Kysela, Takashi Iwai, Jonathan Corbet, Shuah Khan
Cc: Gordon Chen, linux-sound, linux-doc, linux-kernel, Rong Zhang
In-Reply-To: <20260527-uac-quirk-get-cur-vol-v1-0-e9362b712e5e@rong.moe>
The Sennheiser MOMENTUM 3 is a wireless around-ear headphones featuring
ANC, which can be connected via Bluetooth or USB-C.
When connecting via USB-C, its UAC mixer works fine and precisely
corresponds to the reported dB range. However, the mixer's volume
GET_CUR method is somehow stubbed and returns a constant value (15dB).
Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky
mixers"), the sticky check considers the mixer to be sticky and
unnecessarily disables the mixer.
Add a quirk table entry matching VID/PID=0x1377/0x6004 and applying
the MIXER_SKIP_GET_CUR_VOL quirk flag, so that the mixer is usable
again.
Quirky device sample:
usb 7-1.4.4.1.1.1: new full-speed USB device number 30 using xhci_hcd
usb 7-1.4.4.1.1.1: New USB device found, idVendor=1377, idProduct=6004, bcdDevice=38.85
usb 7-1.4.4.1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 7-1.4.4.1.1.1: Product: MOMENTUM 3
usb 7-1.4.4.1.1.1: Manufacturer: Sennheiser electronic GmbH & Co. KG
usb 7-1.4.4.1.1.1: SerialNumber: <REDACTED>
usb 7-1.4.4.1.1.1: Found last interface = 0
usb 7-1.4.4.1.1.1: 1:1: add audio endpoint 0x3
usb 7-1.4.4.1.1.1: Creating new data endpoint #3
usb 7-1.4.4.1.1.1: 1:1 Set sample rate 48000, clock 0
usb 7-1.4.4.1.1.1: 6:0: sticky mixer values (0/11520/768 => 3840), disabling
usb 7-1.4.4.1.1.1: [6] FU [PCM Playback Volume] skipped due to invalid volume
input: Sennheiser electronic GmbH & Co. KG MOMENTUM 3 as /devices/pci0000:00/0000:00:08.3/0000:67:00.4/usb7/7-1/7-1.4/7-1.4.4/7-1.4.4.1/7-1.4.4.1.1/7-1.4.4.1.1.1/7-1.4.4.1.1.1:1.2/0003:1377:6004.002B/input/input208
input: Sennheiser electronic GmbH & Co. KG MOMENTUM 3 Consumer Control as /devices/pci0000:00/0000:00:08.3/0000:67:00.4/usb7/7-1/7-1.4/7-1.4.4/7-1.4.4.1/7-1.4.4.1.1/7-1.4.4.1.1.1/7-1.4.4.1.1.1:1.2/0003:1377:6004.002B/input/input209
hid-generic 0003:1377:6004.002B: input,hiddev99,hidraw12: USB HID v1.11 Device [Sennheiser electronic GmbH & Co. KG MOMENTUM 3] on usb-0000:67:00.4-1.4.4.1.1.1/input2
Signed-off-by: Rong Zhang <i@rong.moe>
---
sound/usb/quirks.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index fbd44baace68..8cd8f475ec1f 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2357,6 +2357,8 @@ static const struct usb_audio_quirk_flags_table quirk_flags_table[] = {
QUIRK_FLAG_FORCE_IFACE_RESET | QUIRK_FLAG_IFACE_DELAY),
DEVICE_FLG(0x1224, 0x2a25, /* Jieli Technology USB PHY 2.0 */
QUIRK_FLAG_GET_SAMPLE_RATE | QUIRK_FLAG_MIC_RES_16),
+ DEVICE_FLG(0x1377, 0x6004, /* Sennheiser MOMENTUM 3 */
+ QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL),
DEVICE_FLG(0x1395, 0x740a, /* Sennheiser DECT */
QUIRK_FLAG_GET_SAMPLE_RATE),
DEVICE_FLG(0x1397, 0x0507, /* Behringer UMC202HD */
--
2.53.0
^ permalink raw reply related
* [PATCH 0/3] ALSA: usb-audio: Add QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL for Sennheiser MOMENTUM 3
From: Rong Zhang @ 2026-05-26 17:49 UTC (permalink / raw)
To: Jaroslav Kysela, Takashi Iwai, Jonathan Corbet, Shuah Khan
Cc: Gordon Chen, linux-sound, linux-doc, linux-kernel, Rong Zhang
Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky
mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to
identify devices with sticky mixers. Unfortunately, even though most
devices with sticky GET_CUR also have corresponding sticky SET_CUR,
which I actually met more since the commit had been merged, there is
also a rare case that some devices may have volume mixers that responds
to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky
check to consider the mixer to be sticky and unnecessarily disable it.
Add QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL to prevent sending GET_CUR to
mixers by returning -ENXIO early. The error effectively skips the sticky
check as it's only meaningful when the mixer has some sort of self-
awareness. Similar to QUIRK_FLAG_GET_SAMPLE_RATE, this should also help
if some unmet devices can't tolerate volume GET_CUR in other ways.
The Sennheiser MOMENTUM 3 needs the quirk flag. Though its UAC mixer
works fine and precisely corresponds to the reported dB range, the
mixer's volume GET_CUR method is somehow stubbed and returns a constant
value (15dB), resulting in it being disabled by the sticky check.
Signed-off-by: Rong Zhang <i@rong.moe>
---
Rong Zhang (3):
ALSA: doc: usb-audio: Add doc for QUIRK_FLAG_IFB_SILENCE_ON_EMPTY
ALSA: usb-audio: Add QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL
ALSA: usb-audio: Add quirk flag for Sennheiser MOMENTUM 3
Documentation/sound/alsa-configuration.rst | 10 ++++++++++
sound/usb/mixer.c | 5 +++++
sound/usb/quirks.c | 3 +++
sound/usb/usbaudio.h | 6 ++++++
4 files changed, 24 insertions(+)
---
base-commit: a23812004228d4b041a858b927db787a7ff80f50
change-id: 20260527-uac-quirk-get-cur-vol-d0b292c3e796
Thanks,
Rong
^ permalink raw reply
* [PATCH 2/3] ALSA: usb-audio: Add QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL
From: Rong Zhang @ 2026-05-26 17:49 UTC (permalink / raw)
To: Jaroslav Kysela, Takashi Iwai, Jonathan Corbet, Shuah Khan
Cc: Gordon Chen, linux-sound, linux-doc, linux-kernel, Rong Zhang
In-Reply-To: <20260527-uac-quirk-get-cur-vol-v1-0-e9362b712e5e@rong.moe>
Since commit 86aa1ea1f15c ("ALSA: usb-audio: Do not expose sticky
mixers"), the UAC mixer core utilizes volume SET_CUR and GET_CUR to
identify devices with sticky mixers. Unfortunately, even though most
devices with sticky GET_CUR also have corresponding sticky SET_CUR,
which I actually met more since the commit had been merged, there is
also a rare case that some devices may have volume mixers that responds
to SET_CUR properly but with its GET_CUR stubbed. This cause the sticky
check to consider the mixer to be sticky and unnecessarily disable it.
Add QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL to prevent sending GET_CUR to
mixers by returning -ENXIO early. The error effectively skips the sticky
check as it's only meaningful when the mixer has some sort of self-
awareness. Similar to QUIRK_FLAG_GET_SAMPLE_RATE, this should also help
if some unmet devices can't tolerate volume GET_CUR in other ways.
Signed-off-by: Rong Zhang <i@rong.moe>
---
Documentation/sound/alsa-configuration.rst | 4 ++++
sound/usb/mixer.c | 5 +++++
sound/usb/quirks.c | 1 +
sound/usb/usbaudio.h | 6 ++++++
4 files changed, 16 insertions(+)
diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst
index 4b30cd63c5a5..bc3bc65c379a 100644
--- a/Documentation/sound/alsa-configuration.rst
+++ b/Documentation/sound/alsa-configuration.rst
@@ -2389,6 +2389,10 @@ quirk_flags
from snd_usb_handle_sync_urb. Instead fall through and enqueue a
packet_info containing only size-0 packets, so the OUT ring keeps
moving (emits silence). Needed by Behringer Flow 8 (1397:050c).
+ * bit 30: ``mixer_skip_get_cur_vol``
+ Skip reading current volume for mixers, as some devices return
+ constant values or errors but otherwise works fine, i.e., setting
+ volume takes desired effect.
This module supports multiple devices, autoprobe and hotplugging.
diff --git a/sound/usb/mixer.c b/sound/usb/mixer.c
index d61bde654219..3b745aebb181 100644
--- a/sound/usb/mixer.c
+++ b/sound/usb/mixer.c
@@ -420,6 +420,11 @@ static int get_cur_ctl_value(struct usb_mixer_elem_info *cval,
static inline int get_cur_mix_raw(struct usb_mixer_elem_info *cval,
int channel, int *value)
{
+ struct snd_usb_audio *chip = cval->head.mixer->chip;
+
+ if (chip->quirk_flags & QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL)
+ return -ENXIO;
+
return get_ctl_value(cval, UAC_GET_CUR,
(cval->control << 8) | channel,
value);
diff --git a/sound/usb/quirks.c b/sound/usb/quirks.c
index e2c95be38aca..fbd44baace68 100644
--- a/sound/usb/quirks.c
+++ b/sound/usb/quirks.c
@@ -2605,6 +2605,7 @@ static const char *const snd_usb_audio_quirk_flag_names[] = {
QUIRK_STRING_ENTRY(MIXER_PLAYBACK_LINEAR_VOL),
QUIRK_STRING_ENTRY(MIXER_CAPTURE_LINEAR_VOL),
QUIRK_STRING_ENTRY(IFB_SILENCE_ON_EMPTY),
+ QUIRK_STRING_ENTRY(MIXER_SKIP_GET_CUR_VOL),
NULL
};
diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h
index 9afcad8f143a..f4e048788f0b 100644
--- a/sound/usb/usbaudio.h
+++ b/sound/usb/usbaudio.h
@@ -242,6 +242,10 @@ extern bool snd_usb_skip_validation;
* from snd_usb_handle_sync_urb. Instead fall through and enqueue a
* packet_info containing only size-0 packets, so the OUT ring keeps
* moving (emits silence). Needed by Behringer Flow 8 (1397:050c).
+ * QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL
+ * Skip reading current volume for mixers, as some devices return constant
+ * values or errors but otherwise works fine, i.e., setting volume takes
+ * desired effect.
*/
enum {
@@ -275,6 +279,7 @@ enum {
QUIRK_TYPE_MIXER_PLAYBACK_LINEAR_VOL = 27,
QUIRK_TYPE_MIXER_CAPTURE_LINEAR_VOL = 28,
QUIRK_TYPE_IFB_SILENCE_ON_EMPTY = 29,
+ QUIRK_TYPE_MIXER_SKIP_GET_CUR_VOL = 30,
/* Please also edit snd_usb_audio_quirk_flag_names */
};
@@ -310,5 +315,6 @@ enum {
#define QUIRK_FLAG_MIXER_PLAYBACK_LINEAR_VOL QUIRK_FLAG(MIXER_PLAYBACK_LINEAR_VOL)
#define QUIRK_FLAG_MIXER_CAPTURE_LINEAR_VOL QUIRK_FLAG(MIXER_CAPTURE_LINEAR_VOL)
#define QUIRK_FLAG_IFB_SILENCE_ON_EMPTY QUIRK_FLAG(IFB_SILENCE_ON_EMPTY)
+#define QUIRK_FLAG_MIXER_SKIP_GET_CUR_VOL QUIRK_FLAG(MIXER_SKIP_GET_CUR_VOL)
#endif /* __USBAUDIO_H */
--
2.53.0
^ permalink raw reply related
* [PATCH 1/3] ALSA: doc: usb-audio: Add doc for QUIRK_FLAG_IFB_SILENCE_ON_EMPTY
From: Rong Zhang @ 2026-05-26 17:49 UTC (permalink / raw)
To: Jaroslav Kysela, Takashi Iwai, Jonathan Corbet, Shuah Khan
Cc: Gordon Chen, linux-sound, linux-doc, linux-kernel, Rong Zhang
In-Reply-To: <20260527-uac-quirk-get-cur-vol-v1-0-e9362b712e5e@rong.moe>
QUIRK_FLAG_IFB_SILENCE_ON_EMPTY was introduced into usb-audio before
without appropriate documentation, so add it.
Fixes: a23812004228 ("ALSA: usb-audio: add IFB_SILENCE_ON_EMPTY quirk for Behringer Flow 8")
Signed-off-by: Rong Zhang <i@rong.moe>
---
Documentation/sound/alsa-configuration.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/sound/alsa-configuration.rst b/Documentation/sound/alsa-configuration.rst
index f75f08763941..4b30cd63c5a5 100644
--- a/Documentation/sound/alsa-configuration.rst
+++ b/Documentation/sound/alsa-configuration.rst
@@ -2383,6 +2383,12 @@ quirk_flags
``V(x) = k * x``; ``dB(x) = 20 * log10(x)``. Overrides bit 24
* bit 28: ``mixer_capture_linear_vol``
Similar to bit 27 but for capture streams. Overrides bit 25
+ * bit 29: ``ifb_silence_on_empty``
+ In implicit feedback mode, when an entire capture URB returns with
+ all iso_frame_desc[i].status != 0 (bytes==0), do not silently return
+ from snd_usb_handle_sync_urb. Instead fall through and enqueue a
+ packet_info containing only size-0 packets, so the OUT ring keeps
+ moving (emits silence). Needed by Behringer Flow 8 (1397:050c).
This module supports multiple devices, autoprobe and hotplugging.
--
2.53.0
^ permalink raw reply related
* [sailus-media-tree:metadata 59/126] htmldocs: Documentation/userspace-api/media/v4l/subdev-config-model.rst:6: WARNING: duplicate label media_subdev_config_model, other instance in Documentation/userspace-api/media/v4l/dev-subdev.rst
From: kernel test robot @ 2026-05-26 17:47 UTC (permalink / raw)
To: Sakari Ailus
Cc: oe-kbuild-all, linux-media, Tomi Valkeinen, Lad Prabhakar,
Mirela Rabulea, Jacopo Mondi, linux-doc
tree: git://linuxtv.org/sailus/media_tree.git metadata
head: 5b470f2ed717705b51f4a799722dffb34a37f10a
commit: 643ed29222de6019c0321bbb7d7d65e6a50fcf4f [59/126] media: Documentation: Add subdev configuration models, raw sensor model
compiler: clang version 20.1.8 (https://github.com/llvm/llvm-project 87f0227cb60147a26a1eeb4fb06e3b505e9c7261)
docutils: docutils (Docutils 0.21.2, Python 3.13.5, on linux)
reproduce: (https://download.01.org/0day-ci/archive/20260526/202605261948.2WptznsW-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202605261948.2WptznsW-lkp@intel.com/
All warnings (new ones prefixed by >>):
Documentation/userspace-api/landlock:550: ./include/uapi/linux/landlock.h:45: ERROR: Unknown target name: "network flags". [docutils]
Documentation/userspace-api/landlock:550: ./include/uapi/linux/landlock.h:50: ERROR: Unknown target name: "scope flags". [docutils]
Documentation/userspace-api/landlock:550: ./include/uapi/linux/landlock.h:24: ERROR: Unknown target name: "filesystem flags". [docutils]
Documentation/userspace-api/landlock:559: ./include/uapi/linux/landlock.h:168: ERROR: Unknown target name: "filesystem flags". [docutils]
Documentation/userspace-api/landlock:559: ./include/uapi/linux/landlock.h:191: ERROR: Unknown target name: "network flags". [docutils]
>> Documentation/userspace-api/media/v4l/subdev-config-model.rst:6: WARNING: duplicate label media_subdev_config_model, other instance in Documentation/userspace-api/media/v4l/dev-subdev.rst
>> Documentation/userspace-api/media/v4l/subdev-config-model.rst:35: WARNING: duplicate label media_subdev_config_model_common_raw_sensor, other instance in Documentation/userspace-api/media/v4l/dev-subdev.rst
>> Documentation/userspace-api/media/v4l/subdev-config-model.rst:: WARNING: duplicate label media_subdev_config_model_common_raw_sensor_subdev, other instance in Documentation/userspace-api/media/v4l/dev-subdev.rst
Documentation/networking/skbuff:36: ./include/linux/skbuff.h:181: WARNING: Failed to create a cross reference. A title or caption not found: 'crc' [ref.ref]
Documentation/userspace-api/media/drivers/camera-sensor.rst:147: WARNING: undefined label: 'media-metadata-layout-ccs' [ref.ref]
vim +6 Documentation/userspace-api/media/v4l/subdev-config-model.rst
4
5 Sub-device configuration models
> 6 ===============================
7
8 The V4L2 specification defines a subdev API that exposes three type of
9 configuration elements: formats, selection rectangles and controls. The
10 specification contains generic information about how those configuration
11 elements behave, but not precisely how they apply to particular hardware
12 features. We leave some leeway to drivers to decide how to map selection
13 rectangles to device features, as long as they comply with the V4L2
14 specification. This is needed as hardware features differ between devices, so
15 it's the driver's responsibility to handle this mapping.
16
17 Unfortunately, this lack of clearly defined mapping in the specification has led
18 to different drivers mapping the same hardware features to different API
19 elements, or implementing the API elements with slightly different
20 behaviours. Furthermore, many drivers have implemented selection rectangles in
21 ways that do not comply with the V4L2 specification. All of this makes userspace
22 development difficult.
23
24 Sub-device configuration models specify in detail what the user space can expect
25 from a sub-device in terms of V4L2 sub-device interface support, semantics
26 included.
27
28 A sub-device may implement more than one configuration model at the same
29 time. The implemented configuration models can be obtained from the sub-device's
30 ``V4L2_CID_CONFIG_MODEL`` control.
31
32 .. _media_subdev_config_model_common_raw_sensor:
33
34 Common raw camera sensor model
> 35 ------------------------------
36
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* [PATCH -next] mtd: spi-nor: testing locking, fix new doc build warnings
From: Randy Dunlap @ 2026-05-26 17:23 UTC (permalink / raw)
To: linux-doc
Cc: Randy Dunlap, Jonathan Corbet, Shuah Khan, Pratyush Yadav,
Michael Walle, Takahiro Kuwano, linux-mtd, Miquel Raynal,
Richard Weinberger, Vignesh Raghavendra
Add a blank line to prevent documentation build warnings:
Documentation/driver-api/mtd/spi-nor.rst:215: ERROR: Unexpected indentation. [docutils]
Documentation/driver-api/mtd/spi-nor.rst:216: WARNING: Block quote ends without a blank line; unexpected unindent. [docutils]
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
---
# for spi-nor/next
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Shuah Khan <skhan@linuxfoundation.org>
Cc: Pratyush Yadav <pratyush@kernel.org>
Cc: Michael Walle <mwalle@kernel.org>
Cc: Takahiro Kuwano <takahiro.kuwano@infineon.com>
Cc: linux-mtd@lists.infradead.org
Cc: Miquel Raynal <miquel.raynal@bootlin.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Vignesh Raghavendra <vigneshr@ti.com>
Documentation/driver-api/mtd/spi-nor.rst | 1 +
1 file changed, 1 insertion(+)
--- linux-next-20260525.orig/Documentation/driver-api/mtd/spi-nor.rst
+++ linux-next-20260525/Documentation/driver-api/mtd/spi-nor.rst
@@ -211,6 +211,7 @@ section, after the ``---`` marker.
must adapt `bs` accordingly.
Warning: These tests may hard lock your device! Make sure:
+
- The device is not hard locked already (#WP strapped to low and
SR_SRWD bit set)
- If you have a WPn pin, you may want to set `no-wp` in your DT for
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/mlx5: Apply devlink default eswitch mode during init
From: Mark Bloch @ 2026-05-26 17:13 UTC (permalink / raw)
To: Jiri Pirko
Cc: Tariq Toukan, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Andrew Lunn, David S. Miller, Jonathan Corbet, Shuah Khan,
Simon Horman, Saeed Mahameed, Leon Romanovsky,
Borislav Petkov (AMD), Andrew Morton, Randy Dunlap,
Thomas Gleixner, Petr Mladek, Peter Zijlstra (Intel), Tejun Heo,
Vlastimil Babka, Feng Tang, Christian Brauner, Dave Hansen,
Dapeng Mi, Kees Cook, Marco Elver, Li RongQing, Eric Biggers,
Paul E. McKenney, linux-doc, linux-kernel, netdev, linux-rdma,
Gal Pressman, Dragos Tatulea, Jiri Pirko, Shay Drori,
Moshe Shemesh
In-Reply-To: <ahXF2aQZNOwHdCG_@FV6GYCPJ69>
On 26/05/2026 19:23, Jiri Pirko wrote:
> Tue, May 26, 2026 at 05:03:57PM +0200, mbloch@nvidia.com wrote:
>>
>>
>> On 26/05/2026 17:07, Jiri Pirko wrote:
>>> Tue, May 26, 2026 at 11:44:46AM +0200, mbloch@nvidia.com wrote:
>>>>
>>>>
>>>> On 26/05/2026 10:44, Jiri Pirko wrote:
>>>>> Thu, May 21, 2026 at 09:24:34AM +0200, tariqt@nvidia.com wrote:
>>>>>> From: Mark Bloch <mbloch@nvidia.com>
>>>>>>
>>>>>> Apply devlink default eswitch mode for mlx5 devices after successful
>>>>>> device initialization while holding the devlink instance lock.
>>>>>>
>>>>>> At this point the devlink instance is registered and the mlx5 devlink
>>>>>> operations are available, so the default eswitch mode can be applied to
>>>>>> the matching PCI devlink handle.
>>>>>>
>>>>>> Signed-off-by: Mark Bloch <mbloch@nvidia.com>
>>>>>> Reviewed-by: Shay Drori <shayd@nvidia.com>
>>>>>> Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
>>>>>> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
>>>>>> ---
>>>>>> drivers/net/ethernet/mellanox/mlx5/core/main.c | 17 +++++++++++++++++
>>>>>> 1 file changed, 17 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/main.c b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>>>>>> index 0c6e4efe38c8..4528097f3d84 100644
>>>>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
>>>>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
>>>>>> @@ -1391,6 +1391,21 @@ static void mlx5_unload(struct mlx5_core_dev *dev)
>>>>>> mlx5_free_bfreg(dev, &dev->priv.bfreg);
>>>>>> }
>>>>>>
>>>>>> +static void mlx5_devl_apply_default_esw_mode(struct mlx5_core_dev *dev)
>>>>>> +{
>>>>>> + struct devlink *devlink = priv_to_devlink(dev);
>>>>>> + int err;
>>>>>> +
>>>>>> + if (!MLX5_ESWITCH_MANAGER(dev))
>>>>>> + return;
>>>>>> +
>>>>>> + devl_assert_locked(devlink);
>>>>>> + err = devl_apply_default_esw_mode(devlink);
>>>>>> + if (err)
>>>>>> + mlx5_core_warn(dev, "Couldn't apply default eswitch mode, err %d\n",
>>>>>> + err);
>>>>>> +}
>>>>>> +
>>>>>> int mlx5_init_one_devl_locked(struct mlx5_core_dev *dev)
>>>>>> {
>>>>>> bool light_probe = mlx5_dev_is_lightweight(dev);
>>>>>> @@ -1437,6 +1452,7 @@ int mlx5_init_one_devl_locked(struct mlx5_core_dev *dev)
>>>>>> mlx5_core_err(dev, "mlx5_hwmon_dev_register failed with error code %d\n", err);
>>>>>>
>>>>>> mutex_unlock(&dev->intf_state_mutex);
>>>>>> + mlx5_devl_apply_default_esw_mode(dev);
>>>>>
>>>>> I wonder how we can make this work for all. I mean, other driver would
>>>>> silently ignore this command like arg, right? Any idea how to make all
>>>>> drivers follow the arg from very beginning?
>>>>>
>>>>
>>>> I have a follow-up series that adds the call to all drivers which support
>>>> setting eswitch mode. When going over the other drivers, what I found is
>>>> that the right point to apply the default is driver specific, drivers
>>>> I have patch for:
>>>>
>>>> 46e16c6d9836 net: Apply devlink esw mode defaults
>>>> ab4f54102ba9 bnxt_en: Apply devlink default eswitch mode during init
>>>> b48cce1607bb liquidio: Apply devlink default eswitch mode during init
>>>> 4ea54b0fe04a ice: Apply devlink default eswitch mode during init
>>>> b7faddaa1c90 octeontx2-af: Apply devlink default eswitch mode during init
>>>> 74b0c22c47b9 octeontx2-pf: Apply devlink default eswitch mode during init
>>>> 5000e4c3d768 nfp: Apply devlink default eswitch mode during init
>>>> 97a218e95e41 netdevsim: Apply devlink default eswitch mode during init
>>>>
>>>> I don't think doing this generically from devlink is realistic. devlink
>>>> doesn't really know when a given driver is ready to change eswitch mode.
>>>> Some drivers need SR-IOV state, representor setup, or other init pieces to
>>>> be ready first, and the locking is not identical across drivers either.
>>>
>>>
>>> Low hanging fruit would be just to call ops->eswitch_mode_set at the end
>>> of register. Multiple reasons:
>>>
>>> 1) end of devl_register is exactly the point userspace is free to issue
>>> the eswitch mode set. Driver should be ready to handle it.
>>> 2) all drivers would transparently get this functionality, without
>>> actually knowing this kernel command line arg ever existed, without
>>> odd wiring call of related exported function. I prefer that stongly.
>>> 3) you should add a there warning for the case this arg is passed yet
>>> the driver does not implement eswitch_mode_set. User should
>>> get a feedback like this, not silent ignore.
>>>
>>> The only loose end is see it the void return of devl_register().
>>> Multiple ways to handle the possibly failed eswitch_mode_set(). I would
>>> probably just go for pr_warn, seems to be the most correct.
>>>
>>> Make sense?
>>
>> I see the point, but I don't think devl_register() (at least not the only place)
>> is the right place.
>>
>> There is a small but important difference between userspace doing
>> "devlink eswitch set" after register is done, and devlink core calling
>> eswitch_mode_set() from inside the register flow.
>>
>> Some drivers call devlink_register() while holding the device lock.
>> liquidio is one example. If devlink core calls ops->eswitch_mode_set() from
>> there, we may start the full eswitch mode change while holding that lock.
>> That mode change can create representors, register netdevs, take rtnl,
>> allocate resources, etc. I don't think we want this to become an implicit
>> side effect of devlink registration.
>
> I believe your AI may untagle liquidio locking :)
I didn't try to solve that one with ai. Most drivers were fairly simple
so I didn't use ai at all. bnxt was the one where I needed a bit of help :)
>
>
>>
>> For mlx5, the placement after intf_state_mutex is also intentional:
>>
>> mutex_unlock(&dev->intf_state_mutex);
>> mlx5_devl_apply_default_esw_mode(dev);
>>
>> We can't call it while holding intf_state_mutex because the mode set path
>> takes it internally, and switchdev mode may also create IB representors.
>>
>> Also, devl_register() only covers the first registration. The mlx5 call in
>> mlx5_load_one_devl_locked() is for reload/fw reset recovery kind of flows.
>> In those flows devlink is already registered, so devl_register() is not
>> called again, but the driver state was rebuilt and we may need to apply the
>> default again.
>
> Call it from reload too, right?
Yes, that was my first thought: apply it from devl_register() for the first
registration and from devlink_reload() after a successful DRIVER_REINIT.
That covers the clean devlink reload path but....(see bellow)
>
>
>>
>> Same for reload, fw reset and pci recovery in general. If the driver tears
>> down and rebuilds eswitch related state, the place to apply the default is
>> in that driver's reinit flow, not in devl_register().
>>
>> When I went over the other drivers, the right place was not always the same
>> as devlink registration. I'm not an expert in any of them, so I hope I got
>> the details right, but for example octeontx2 AF needs sr-iov and the
>> representor switch state to be initialized first. nfp can do it after
>> app/vNIC init while the devlink lock is already held. liquidio should do it
>> only after dropping the PCI device lock.
>
> Idk, perhaps do it from devlink_post_register_work of some kind? That
> would allow you to have the same locking ordering as a userspace cal
l.
I thought about a workqueue too, it was actually my first idea.
The problem is that then we race with userspace. In the mlx5 version here the
default is applied while the devlink lock is still held, before userspace can
come in and issue its own eswitch set. If we defer it to post-register work,
the devlink instance is already visible and userspace can get there first
and then we might change the user configuration.
Also, the bigger issue for mlx5 is not only initial registration or devlink
reload. Some recovery paths, pci resume, and fw reset flows rebuild the driver
state without going through devlink at all. I did not find a clean way for
devlink core to infer all those points by itself.
To handle that from devlink I would still need to add some api for the driver
to tell devlink "I just reinitialized, apply the default now". but nce I had
that driver call , it felt simpler and clearer to let the driver call
the helper directly at the points where it knows eswitch mode is safe.
I agree that handling all of this inside devlink would be the better option.
I just couldn't make it work in a clean way.
Mark
>
>>
>> Mark
>>
>>>
>>>
>>>>
>>>> Also, since this knob is only about eswitch mode, I don't think we need to
>>>> touch every devlink driver. Drivers that don't implement eswitch_mode_set()
>>>> would just ignore it anyway. The follow-up only wires the default into
>>>> drivers that actually support changing eswitch mode.
>>>>
>>>> Mark
>>>>
>>>>>
>>>>>> return 0;
>>>>>>
>>>>>> err_register:
>>>>>> @@ -1538,6 +1554,7 @@ int mlx5_load_one_devl_locked(struct mlx5_core_dev *dev, bool recovery)
>>>>>> goto err_attach;
>>>>>>
>>>>>> mutex_unlock(&dev->intf_state_mutex);
>>>>>> + mlx5_devl_apply_default_esw_mode(dev);
>>>>>> return 0;
>>>>>>
>>>>>> err_attach:
>>>>>> --
>>>>>> 2.44.0
>>>>>>
>>>>
>>
^ permalink raw reply
* Re: (subset) [PATCH v4 1/1] leds: Introduce the multi_max_intensity sysfs attribute
From: Lee Jones @ 2026-05-26 17:09 UTC (permalink / raw)
To: Armin Wolf
Cc: pavel, linux-kernel, corbet, skhan, linux-leds, linux-doc, wse,
jacek.anaszewski, pobrn, m.tretter
In-Reply-To: <b04d64b7-1a50-4b3d-95f3-2bcb502c0a5b@gmx.de>
On Sat, 23 May 2026, Armin Wolf wrote:
> Am 20.05.26 um 16:34 schrieb Lee Jones:
>
> > On Sat, 09 May 2026 23:46:03 +0200, Armin Wolf wrote:
> > > Some multicolor LEDs support global brightness control in hardware,
> > > meaning that the maximum intensity of the color components is not
> > > connected to the maximum global brightness. Such LEDs cannot be
> > > described properly by the current multicolor LED class interface,
> > > because it assumes that the maximum intensity of each color component
> > > is described by the maximum global brightness of the LED.
> > >
> > > [...]
> > Applied, thanks!
> >
> > [1/1] leds: Introduce the multi_max_intensity sysfs attribute
> > commit: b1a9b7a904af2c793850f83a4801a013a718fc47
>
> Thank you :)
>
> I just noticed that i forgot to update the Date field inside the sysfs documentation, it should
> have been:
>
> Date: May 2026
> KernelVersion: 7.2
>
> Should i send a separate patch for this or can you edit the patch inplace?
Subsequent patch please.
--
Lee Jones
^ permalink raw reply
* Re: [PATCH v5 12/13] Documentation: ABI: testing: add docs for ad9910 sysfs entries
From: Rodrigo Alencar @ 2026-05-26 17:08 UTC (permalink / raw)
To: Jonathan Cameron, Rodrigo Alencar
Cc: rodrigo.alencar, linux-iio, devicetree, linux-kernel, linux-doc,
linux-hardening, Lars-Peter Clausen, Michael Hennerich,
David Lechner, Andy Shevchenko, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Jonathan Corbet, Shuah Khan,
Kees Cook, Gustavo A. R. Silva
In-Reply-To: <20260522192040.4e6b11eb@jic23-huawei>
On 26/05/22 07:20PM, Jonathan Cameron wrote:
> On Wed, 20 May 2026 19:47:25 +0100
> Rodrigo Alencar <455.rodrigo.alencar@gmail.com> wrote:
>
> > On 26/05/17 07:37PM, Rodrigo Alencar via B4 Relay wrote:
> > > From: Rodrigo Alencar <rodrigo.alencar@analog.com>
> > >
> > > Add custom ABI documentation file for the DDS AD9910 with sysfs entries to
> > > control Parallel Port, Digital Ramp Generator and OSK parameters.
> >
> > ...
> > This will become just offset with altcurrent channels. I noticed we have a IIO_PHASE
> > iio_chan_type, could we have a IIO_FREQUENCY too? Parallel port needs actual raw
> > frequency values in that case to be written to the dma buffer.
> >
> Sure to IIO_FREQUENCY. I thought we already did but seems not!
> The Phase one is a bit special given it's use in resolvers and distance sensors
> but perhaps it is the right solution here.
>
>
> > Then we may have buffer capable channels for the parallel port:
> >
> > out_altcurrent120
> > offset
>
> So that's the amplitude envelope control.
>
> > out_phase120
> > offset
>
> So this is the phase adjustment being controlled.
>
> > out_frequency120
>
> And this is the frequency being controlled.
>
> > scale
> > offset
>
> >
> > Problem is that the math for the actual frequency output is:
> >
> > f_OUT = f_FTW + (f_RAW * FM)
> >
> > where f_FTW is a base frequency (already scaled), FM is a
> > modulation gain and f_RAW is the contribution from the parallel
> > port, which is the already scaled:
> >
> > f_RAW = RAW * f_SYSCLK / 2^32
> > f_FTW = FTW * f_SYSCLK / 2^32
> >
> > so the above becomes:
> >
> > f_OUT = (FTW * f_SYSCLK / 2^32) + (RAW * f_SYSCLK / 2^32) * FM
> > f_OUT = (FTW/FM + RAW) * f_SYSCLK * FM / 2^32
> >
> > if I make:
> >
> > SCALE = f_SYSCLK * FM / 2^32
> > OFFSET = FTW/FM
> > f_OUT = (OFFSET + RAW) * SCALE
> >
> > That would work for a IIO_FREQUENCY channel type, problem is that both
> > scale and offset would depend on the modulation gain (FM)... I suppose
> > scale should be setting that and offset assumes it is constant to act
> > only on FTW.
>
> I'm not that concerned about the coupling - it's a bit of a useability
> issue I guess as not obvious which should be the fixed one. Can we do
> cache written values and try and compensate to get a pair that is nearest
> to whatever we try to drive (in either order of setting them?)
Yeah.. or just document a proper sequence to write things, and indicate that
writing has side effects and one may read the other attributes to assert
the desired configuration. See that f_SYSCLK is also another configurable
variable. Maybe it is not really practical to cache all user choices and derive
all the other configurations as one changes.
> >
> > I suppose we can keep altcurrent for other modes as phase and frequency
> > can be attributes (knobs) for them. However, in parallel mode we are effectively
> > pushing frequency, phase or amplitude values into the buffer.
>
> Given that's the thing we are controlling. My Friday evening tired brain agrees
> that it makes sense to use channel types rather than adjustments on something else.
>
> I'll think some more on this. We've never had continuous (well digital
> so near continous) control of either phase or frequency before - it's just
> be symbol stuff with a couple of points to set.
>
>
> >
> > The polar destination is a corner case, but can be solved when both
> > phase and altcurrent channels are enabled. When that happens we can
> > change the scan_type with has_ext_scan_type = 1, so the 16-bit data
> > bus is split between the two.
> >
> For now I'll just nod at that!
I took a look at get_current_scan_type() and I faced the issue:
user checks the scan format type before enabling the buffers
In this case I have a scan type that changes with the scan mask:
altcurrent and phase both selected for buffer transmission would
have the scan type changed so that the 16-bit data bus is split
between 2 8-bit chunks.
That may also get confusing values for offset and scale. Then I decided
to have 5 parallel port channels with fixed scan_type:
0. out_altcurrent120 - amplitude destination (16-bits)
1. out_phase120 - phase destination (16-bits)
2. out_frequency120 - frequency destination (16-bits)
3. out_altcurrent121 - polar destination (8-bits)
4. out_phase121 - polar destination (8-bits)
with the possible scan masks:
0x01: amplitude
0x02: phase
0x04: frequency
0x18: polar
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v2 2/2] cgroup/dmem: add dmem.memcg control file for double-charging to memcg
From: Eric Chanudet @ 2026-05-26 16:59 UTC (permalink / raw)
To: Michal Koutný
Cc: Johannes Weiner, Michal Hocko, Roman Gushchin, Shakeel Butt,
Muchun Song, Andrew Morton, Maarten Lankhorst, Maxime Ripard,
Natalie Vock, Tejun Heo, Jonathan Corbet, Shuah Khan, cgroups,
linux-mm, linux-kernel, dri-devel, T.J. Mercier,
Christian König, Maxime Ripard, Albert Esteve, Dave Airlie,
linux-doc
In-Reply-To: <ahBxB5a9sX9DEWvl@localhost.localdomain>
On Fri, May 22, 2026 at 05:26:16PM +0200, Michal Koutný wrote:
> Hello Eric.
>
> On Tue, May 19, 2026 at 11:59:02AM -0400, Eric Chanudet <echanude@redhat.com> wrote:
> > Add a root-only cgroupfs file "dmem.memcg" that lets an administrator
> > configure whether allocations in a dmem region should also be charged to
> > the memory controller.
>
> This kinda makes sense as it is not unlike io.cost.* device
> configurators.
>
> Just for my better understanding -- will there be a space for userspace
> to switch this? (No charged dmem allocations happen before responsible
> userspace runs, so that the attribute remains unlocked.)
>
> (I'm rather indifferent about the actual double charging/non-charging
> matter.)
Yes, this is intended to be configured before the user space stack that
would start allocating things is started. Once it has started (and tried
to charge something), the configuration is locked
>
> >
> > To handle inheritance, dmem adds a depends_on the memory controller,
> > unless MEMCG isn't configured in.
> >
> > Double-charging is disabled by default. Once a charge is attempted, the
> > setting is locked to prevent inconsistent accounting by a small 4-state
> > machine (off, on, locked off, locked on).
> >
> > The memcg to charge is derived from the pool's cgroup, since the pool
> > holds a reference to the dmem cgroup state that keeps the cgroup alive
> > until it gets uncharged.
> >
> > Signed-off-by: Eric Chanudet <echanude@redhat.com>
> > ---
> > Documentation/admin-guide/cgroup-v2.rst | 23 +++++
> > kernel/cgroup/dmem.c | 158 +++++++++++++++++++++++++++++++-
> > 2 files changed, 178 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
> > index 6efd0095ed995b1550317662bc1b56c7a7f3db23..1d2fa55ddf0faa17baa916a8914d3033e8e42359 100644
> > --- a/Documentation/admin-guide/cgroup-v2.rst
> > +++ b/Documentation/admin-guide/cgroup-v2.rst
> > @@ -2828,6 +2828,29 @@ DMEM Interface Files
> > drm/0000:03:00.0/vram0 12550144
> > drm/0000:03:00.0/stolen 8650752
> >
> > + dmem.memcg
> > + A readwrite nested-keyed file that exists only on the root
> > + cgroup.
>
> Strictly speaking this is not nested-keyed but flat keyed [1],
Indeed,
> which leads me to realization that this is the first instance of a boolean.
> All in call, such a composition comes to my mind (latter is RO):
>
> drm/0000:03:00.0/vram0 enable=0|1 locked=0|1
>
So per[1] 1 key, 2 sub-keys (enable RW, locked RO), that looks better
and match the documentation, thanks!
>
>
> > +static ssize_t dmem_cgroup_memcg_write(struct kernfs_open_file *of, char *buf,
> > + size_t nbytes, loff_t off)
> > +{
> > + while (buf) {
> > + struct dmem_cgroup_region *region;
> > + char *options, *name;
> > + bool flag;
> > +
> > + options = buf;
> > + buf = strchr(buf, '\n');
> > + if (buf)
> > + *buf++ = '\0';
>
> I recall there was a discussion about accepting only a single device per
> write(2) (at the same time I see this idiom is still present in other
> dmem.* files, so this is nothing to change in _this_ patch).
I would second that. When setting say dmem.max for 2 regions, with a
typo on the second, the first one is set, but write still get EINVAL.
Also, I just notice dmemcg_limit_write() returns EINVAL if the region is
not found (this patch returns ENODEV).
>
> Thanks,
> Michal
>
> [1] https://www.kernel.org/doc/html/latest/admin-guide/cgroup-v2.html#format
--
Eric Chanudet
^ permalink raw reply
* [PATCH v6 19/19] drm/bridge_connector: Convert to atomic_create_state
From: Maxime Ripard @ 2026-05-26 16:46 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart
In-Reply-To: <20260526-drm-mode-config-init-v6-0-852346394200@kernel.org>
The connector created by drm_bridge_connector only initializes a
pristine state in reset, which is equivalent to what
atomic_create_state would expect. Convert to it.
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/display/drm_bridge_connector.c | 15 +++++++++++----
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 50408af746d8..cafa498c3848 100644
--- a/drivers/gpu/drm/display/drm_bridge_connector.c
+++ b/drivers/gpu/drm/display/drm_bridge_connector.c
@@ -263,26 +263,33 @@ static void drm_bridge_connector_debugfs_init(struct drm_connector *connector,
if (bridge->funcs->debugfs_init)
bridge->funcs->debugfs_init(bridge, root);
}
}
-static void drm_bridge_connector_reset(struct drm_connector *connector)
+static struct drm_connector_state *
+drm_bridge_connector_create_state(struct drm_connector *connector)
{
struct drm_bridge_connector *bridge_connector =
to_drm_bridge_connector(connector);
+ struct drm_connector_state *conn_state;
+
+ conn_state = drm_atomic_helper_connector_create_state(connector);
+ if (IS_ERR(conn_state))
+ return conn_state;
- drm_atomic_helper_connector_reset(connector);
if (bridge_connector->bridge_hdmi)
__drm_atomic_helper_connector_hdmi_state_init(connector,
- connector->state);
+ conn_state);
+
+ return conn_state;
}
static const struct drm_connector_funcs drm_bridge_connector_funcs = {
- .reset = drm_bridge_connector_reset,
.detect = drm_bridge_connector_detect,
.force = drm_bridge_connector_force,
.fill_modes = drm_helper_probe_single_connector_modes,
+ .atomic_create_state = drm_bridge_connector_create_state,
.atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.debugfs_init = drm_bridge_connector_debugfs_init,
.oob_hotplug_event = drm_bridge_connector_oob_hotplug_event,
};
--
2.54.0
^ permalink raw reply related
* [PATCH v6 18/19] drm/tidss: Convert to atomic_create_state
From: Maxime Ripard @ 2026-05-26 16:46 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart
In-Reply-To: <20260526-drm-mode-config-init-v6-0-852346394200@kernel.org>
Our driver uses reset to create the various object states, but only
calls the helper that allocate a new state. They are thus strictly
equivalent to the new atomic_create_state helpers, so let's switch to
these.
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/tidss/tidss_crtc.c | 17 +++++++----------
drivers/gpu/drm/tidss/tidss_plane.c | 2 +-
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/tidss/tidss_crtc.c b/drivers/gpu/drm/tidss/tidss_crtc.c
index acab9307bdf3..400329aa2200 100644
--- a/drivers/gpu/drm/tidss/tidss_crtc.c
+++ b/drivers/gpu/drm/tidss/tidss_crtc.c
@@ -355,24 +355,21 @@ static void tidss_crtc_destroy_state(struct drm_crtc *crtc,
__drm_atomic_helper_crtc_destroy_state(&tstate->base);
kfree(tstate);
}
-static void tidss_crtc_reset(struct drm_crtc *crtc)
+static struct drm_crtc_state *tidss_crtc_create_state(struct drm_crtc *crtc)
{
struct tidss_crtc_state *tstate;
- if (crtc->state)
- tidss_crtc_destroy_state(crtc, crtc->state);
-
tstate = kzalloc_obj(*tstate);
- if (!tstate) {
- crtc->state = NULL;
- return;
- }
+ if (!tstate)
+ return ERR_PTR(-ENOMEM);
- __drm_atomic_helper_crtc_reset(crtc, &tstate->base);
+ __drm_atomic_helper_crtc_state_init(&tstate->base, crtc);
+
+ return &tstate->base;
}
static struct drm_crtc_state *tidss_crtc_duplicate_state(struct drm_crtc *crtc)
{
struct tidss_crtc_state *state, *current_state;
@@ -403,14 +400,14 @@ static void tidss_crtc_destroy(struct drm_crtc *crtc)
drm_crtc_cleanup(crtc);
kfree(tcrtc);
}
static const struct drm_crtc_funcs tidss_crtc_funcs = {
- .reset = tidss_crtc_reset,
.destroy = tidss_crtc_destroy,
.set_config = drm_atomic_helper_set_config,
.page_flip = drm_atomic_helper_page_flip,
+ .atomic_create_state = tidss_crtc_create_state,
.atomic_duplicate_state = tidss_crtc_duplicate_state,
.atomic_destroy_state = tidss_crtc_destroy_state,
.enable_vblank = tidss_crtc_enable_vblank,
.disable_vblank = tidss_crtc_disable_vblank,
};
diff --git a/drivers/gpu/drm/tidss/tidss_plane.c b/drivers/gpu/drm/tidss/tidss_plane.c
index 1a8b44fb45f8..6d82976c2db1 100644
--- a/drivers/gpu/drm/tidss/tidss_plane.c
+++ b/drivers/gpu/drm/tidss/tidss_plane.c
@@ -176,12 +176,12 @@ static const struct drm_plane_helper_funcs tidss_primary_plane_helper_funcs = {
};
static const struct drm_plane_funcs tidss_plane_funcs = {
.update_plane = drm_atomic_helper_update_plane,
.disable_plane = drm_atomic_helper_disable_plane,
- .reset = drm_atomic_helper_plane_reset,
.destroy = drm_plane_destroy,
+ .atomic_create_state = drm_atomic_helper_plane_create_state,
.atomic_duplicate_state = drm_atomic_helper_plane_duplicate_state,
.atomic_destroy_state = drm_atomic_helper_plane_destroy_state,
};
struct tidss_plane *tidss_plane_create(struct tidss_device *tidss,
--
2.54.0
^ permalink raw reply related
* [PATCH v6 17/19] drm/drv: Switch skeleton to drm_mode_config_create_initial_state()
From: Maxime Ripard @ 2026-05-26 16:46 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard
In-Reply-To: <20260526-drm-mode-config-init-v6-0-852346394200@kernel.org>
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.
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
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;
*
* ret = drm_dev_register(drm);
* if (ret)
* return ret;
*
--
2.54.0
^ permalink raw reply related
* [PATCH v6 16/19] drm/mode-config: Create drm_mode_config_create_initial_state()
From: Maxime Ripard @ 2026-05-26 16:46 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart
In-Reply-To: <20260526-drm-mode-config-init-v6-0-852346394200@kernel.org>
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>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/drm_atomic.c | 12 +++++-
drivers/gpu/drm/drm_mode_config.c | 89 +++++++++++++++++++++++++++++++++++++++
include/drm/drm_mode_config.h | 1 +
3 files changed, 100 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 3c5714481ad2..796de2bbcb0c 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -58,12 +58,20 @@
* object states are allocated 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 allocates a new
- * default state and stores it in the object state pointer.
+ * - at driver initialization time, the driver calls
+ * drm_mode_config_create_initial_state() to allocate an initial,
+ * pristine, state for each object and stores it in the objects state
+ * pointer. Historically, this was one of drm_mode_config_reset() job,
+ * so one might still encounter it in a driver.
+ *
+ * - When resuming from suspend, drm_mode_config_reset() resets the
+ * software and hardware state to a known default and stores it in the
+ * object's state pointer. Not all objects are affected by
+ * drm_mode_config_reset() though.
*
* - whenever a new update is needed:
*
* + drm_atomic_commit_alloc() allocates a new &drm_atomic_commit
* instance.
diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index 9d240817f8b6..f432f485a914 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>
@@ -314,10 +315,98 @@ 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
+ * @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) {
+ drm_connector_list_iter_end(&conn_iter);
+ 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 e584652ddf67..d8f5b7e9673e 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
--
2.54.0
^ permalink raw reply related
* [PATCH v6 15/19] drm/connector: Add new atomic_create_state callback
From: Maxime Ripard @ 2026-05-26 16:46 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart
In-Reply-To: <20260526-drm-mode-config-init-v6-0-852346394200@kernel.org>
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>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@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 | 26 ++++++++++++++++++++++++++
drivers/gpu/drm/drm_connector.c | 10 +++++++++-
drivers/gpu/drm/drm_mode_config.c | 31 ++++++++++++++++++++++++++++++-
include/drm/drm_atomic_state_helper.h | 2 ++
include/drm/drm_connector.h | 16 ++++++++++++++++
5 files changed, 83 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index e2e5a1b8a820..07686e94aae0 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -532,10 +532,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
+ * @connector: connector object
+ *
+ * Allocates and initializes pristine @drm_connector_state.
+ *
+ * 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_connector.c b/drivers/gpu/drm/drm_connector.c
index 3fa4d2082cd7..a0b132c658a1 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -616,11 +616,19 @@ int drmm_connector_hdmi_init(struct drm_device *dev,
/*
* drm_connector_attach_max_bpc_property() requires the
* connector to have a state.
*/
- if (connector->funcs->reset)
+ if (connector->funcs->atomic_create_state) {
+ struct drm_connector_state *state;
+
+ state = connector->funcs->atomic_create_state(connector);
+ if (IS_ERR(state))
+ return PTR_ERR(state);
+
+ connector->state = state;
+ } else if (connector->funcs->reset)
connector->funcs->reset(connector);
drm_connector_attach_max_bpc_property(connector, 8, max_bpc);
connector->max_bpc = max_bpc;
diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c
index 2e2cd18a14b4..9d240817f8b6 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -235,10 +235,36 @@ static int drm_mode_config_crtc_reset_with_create_state(struct drm_crtc *crtc)
}
return drm_mode_config_crtc_create_state(crtc);
}
+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;
+}
+
+static int drm_mode_config_connector_reset_with_create_state(struct drm_connector *connector)
+{
+ if (connector->state) {
+ connector->funcs->atomic_destroy_state(connector, connector->state);
+ connector->state = NULL;
+ }
+
+ return drm_mode_config_connector_create_state(connector);
+}
+
/**
* drm_mode_config_reset - call ->reset callbacks
* @dev: drm device
*
* This functions calls all the crtc's, encoder's and connector's ->reset
@@ -278,13 +304,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_reset_with_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 9634a70e0401..f4b6d8833bc2 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -73,10 +73,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_commit *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 5ad62c207d00..529755c2e862 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:
+ *
+ * Allocate a pristine, initialized, state for the connector
+ * object and return 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, 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
--
2.54.0
^ permalink raw reply related
* [PATCH v6 14/19] drm/hdmi: Rename __drm_atomic_helper_connector_hdmi_reset()
From: Maxime Ripard @ 2026-05-26 16:46 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart, Laurent Pinchart
In-Reply-To: <20260526-drm-mode-config-init-v6-0-852346394200@kernel.org>
__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>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
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 | 15 ++++++++-------
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, 15 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_bridge_connector.c b/drivers/gpu/drm/display/drm_bridge_connector.c
index 649969fca141..50408af746d8 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 4867edbf2622..a331ebdd65af 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() - Initialize all HDMI @drm_connector_state resources
* @connector: DRM connector
- * @new_conn_state: connector state to reset
+ * @new_conn_state: connector state to initialize
*
* 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 07e2afcb4f95..3cad8f9bc529 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 c9819c3fc635..e89e1af7a811 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 a161d3b00a25..74dce4be0c00 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 0adc30c55ec9..13375bd0f4ae 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_commit *state);
int drm_atomic_helper_connector_hdmi_update_audio_infoframe(struct drm_connector *connector,
--
2.54.0
^ permalink raw reply related
* [PATCH v6 13/19] drm/atomic-state-helper: Rename __drm_atomic_helper_connector_state_reset()
From: Maxime Ripard @ 2026-05-26 16:46 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart, Laurent Pinchart
In-Reply-To: <20260526-drm-mode-config-init-v6-0-852346394200@kernel.org>
__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>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
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 8762171c9432..e2e5a1b8a820 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -474,24 +474,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 - Initialize the connector state
* @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
@@ -506,11 +506,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 213f7e298008..9634a70e0401 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -68,11 +68,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);
--
2.54.0
^ permalink raw reply related
* [PATCH v6 12/19] drm/crtc: Add new atomic_create_state callback
From: Maxime Ripard @ 2026-05-26 16:46 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard
In-Reply-To: <20260526-drm-mode-config-init-v6-0-852346394200@kernel.org>
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>
Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
---
drivers/gpu/drm/drm_atomic_state_helper.c | 25 +++++++++++++++++++++++
drivers/gpu/drm/drm_mode_config.c | 34 ++++++++++++++++++++++++++++++-
include/drm/drm_atomic_state_helper.h | 2 ++
include/drm/drm_crtc.h | 16 +++++++++++++++
4 files changed, 76 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c b/drivers/gpu/drm/drm_atomic_state_helper.c
index b277f92f4532..8762171c9432 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -122,10 +122,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
+ * @crtc: crtc object
+ *
+ * Allocates and initializes pristine @drm_crtc_state.
+ *
+ * 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_state_init(state, crtc);
+
+ 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 fa609357858f..2e2cd18a14b4 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -206,10 +206,39 @@ static int drm_mode_config_plane_reset_with_create_state(struct drm_plane *plane
}
return drm_mode_config_plane_create_state(plane);
}
+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);
+
+ if (drm_dev_has_vblank(crtc->dev))
+ drm_crtc_vblank_reset(crtc);
+
+ crtc->state = crtc_state;
+
+ return 0;
+}
+
+static int drm_mode_config_crtc_reset_with_create_state(struct drm_crtc *crtc)
+{
+ if (crtc->state) {
+ crtc->funcs->atomic_destroy_state(crtc, crtc->state);
+ crtc->state = NULL;
+ }
+
+ return drm_mode_config_crtc_create_state(crtc);
+}
+
/**
* drm_mode_config_reset - call ->reset callbacks
* @dev: drm device
*
* This functions calls all the crtc's, encoder's and connector's ->reset
@@ -237,13 +266,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_reset_with_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_reset_with_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 0bb72453464a..213f7e298008 100644
--- a/include/drm/drm_atomic_state_helper.h
+++ b/include/drm/drm_atomic_state_helper.h
@@ -43,10 +43,12 @@ 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);
+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 c6dbe8b7db9e..152349f973e3 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:
+ *
+ * Allocate a pristine, initialized, state for the CRTC object
+ * and return 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
--
2.54.0
^ permalink raw reply related
* [PATCH v6 11/19] drm/atomic-state-helper: Rename __drm_atomic_helper_crtc_state_reset()
From: Maxime Ripard @ 2026-05-26 16:46 UTC (permalink / raw)
To: Maarten Lankhorst, Thomas Zimmermann, David Airlie, Simona Vetter,
Jonathan Corbet, Shuah Khan, Dmitry Baryshkov, Jyri Sarha,
Tomi Valkeinen, Andrzej Hajda, Neil Armstrong, Robert Foss,
Laurent Pinchart, 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
Cc: dri-devel, linux-doc, linux-kernel, Daniel Stone, intel-gfx,
intel-xe, linux-arm-kernel, linux-sunxi, Maxime Ripard,
Laurent Pinchart, Laurent Pinchart
In-Reply-To: <20260526-drm-mode-config-init-v6-0-852346394200@kernel.org>
__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>
Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
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 ab171bfe6e86..b277f92f4532 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 - Initialize the CRTC state
* @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 03de219f7a64..7486f2dc60ef 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 8d1ef268fdef..0bb72453464a 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,
--
2.54.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox