Subject: Re: [PATCH v4] rust: list: Add unsafe for container_of
From: Philipp Stanner <[email-masked]>
To: Miguel Ojeda <[email-masked]>, Philipp Stanner <[email-masked]>
Cc: Miguel Ojeda <[email-masked]>, Boqun Feng <[email-masked]>, Gary Guo <[email-masked]>, Björn Roy Baron <[email-masked]>, Benno Lossin <[email-masked]>, Andreas Hindborg <[email-masked]>, Alice Ryhl <[email-masked]>, Trevor Gross <[email-masked]>, Danilo Krummrich <[email-masked]>, Tamir Duberstein <[email-masked]>, Christian Schrefl <[email-masked]>, [email-masked], [email-masked], [email-masked]
Date: Mon, 23 Feb 2026 08:33:55 +0100
List-Id: <stable.vger.kernel.org>

On Fri, 2026-02-20 at 02:08 +0100, Miguel Ojeda wrote:
> On Mon, Feb 16, 2026 at 2:17 PM Philipp Stanner <[email-masked]> wrote:
> > 
> > Add unsafe blocks to container_of to fix the issue.
> 
> So I don't think this was tested with `CLIPPY=1`, because there are
> other safety comments missing even after this is applied.
> 
> Please note that `CLIPPY=1` must remain clean for all Rust code:
> 
>     https://rust-for-linux.com/contributing#submit-checklist-addendum
> 
> I have pushed to `rust-fixes` the patch with placeholders to show what
> is missing.
> 
> I am not sure if I will keep it there.
> 

Feel free to drop it for now, I can go through it properly with the
list author to see what the most accurate formulation would be.

From - Mon Feb 23 08:43:26 2026
Delivery-date: Mon, 23 Feb 2026 08:11:12 +0000
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t71834267; cv=none; b=h+0JRQGLZGZPQEWRWm+bwXWXmkRpyyU/afaAg9T1B/ZYbJz6JSiF32BuosORsQHrVXJYecJatcWLq+t9UqnvvxuxnE/XKwivg8SxwlG+o/0w1hlD5dVPp/sO34b95g4MgWy0B5MUxNepd3L2TjDBvhNoYpsHh6kyZIYPsPEZtGUARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t71834267; c=relaxed/simple;
	bh=QLIG/cvAGKHL/QsPZAk+8/0vWlzhWoHy3RyVHMRjPY8=;
	h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:
	 To:Cc:Content-Type; b=LYN3lbIaivsTjSEoTHcIX0JTDPDBAZ2vz+z6yRd+jN9hhS9JaAOSbHtkdxtUIeKVI3NsoKG0SSWVt5cMM8hhL8VydoYW6pWk4VEScF53xnwLmm9wS1L8ZBatiPmUY/KqUi4b41G+OVkiIifSqxT9gQZl7wBa9r+xou7Rfrx4p40ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=chromium.org; spf=pass smtp.mailfrom=chromium.org; dkim=pass (1024-bit key) header.d=chromium.org header.i=@chromium.org header.b=gN5sxjFt; arc=none smtp.client-ip 9.85.208.50
        d100.net; s 230601; t71834264; x72439064;
        h=content-transfer-encoding:cc:to:subject:message-id:date:from
         :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from
         :to:cc:subject:date:message-id:reply-to;
        bh=fPcLFGqvXQ/TrcZMbc9zEuLscnPpwUEKK1FNGlp3euE=;
        b=ZS1+LJo5d7n2dA6XeVLZCtpUon8Y9t+gNWH1dE/h1lVDPFdJvbq0v3kMrLB6yTD1ru
         LIROfeAGZuUTTWsRcM2GnmgoRqWkuPhCCN+fAVdhwJjovebwWg2oRQPAxMtfbWrdEXsL
         WdOKfBh9J/o7E4zJJuO/Du6S0W5+AVUxe22zF4kicx5ayN1o9/TB791jNHaAc9pq9+Rg
         OULBW0uD5FhJHVj7sFOCqmugqpNUEzcVwztkXqkk+iWmMBgeS9hplG7QrjQ9PDXzaNxz
         zJwRX7+T+0gR8+goqjaf9uyHhklGuH5plQnVdS+RGedpUouY/JyUXA3C3Az13A/f52QK
         UDEw=
From: Ricardo Ribalda <[email-masked]>
Date: Mon, 23 Feb 2026 09:10:49 +0100
Subject: Re: [REGRESSION] Display freeze on VT switch back to X11 since v6.16
To: =?UTF-8?B?QW5kcsOpcyBQw6lyZXo=?= <[email-masked]>
Cc: [email-masked], 
	Laurent Pinchart <[email-masked]>, Hans de Goede <[email-masked]>, 
	Mauro Carvalho Chehab <[email-masked]>, Jani Nikula <[email-masked]>, 
	Rodrigo Vivi <[email-masked]>, Joonas Lahtinen <[email-masked]>, 
	Tvrtko Ursulin <[email-masked]>, David Airlie <[email-masked]>, 
	Simona Vetter <[email-masked]>, [email-masked], 
	[email-masked], [email-masked], 
	[email-masked], [email-masked], 
	[email-masked]
DKIMCheck: Server passes DKIM test, 0 Spam score
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.234.253.10 listed in zen.spamhaus.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             zen.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: chromium.org]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: 4

Hi Andrés

Thanks for doing the bisecting

On Sun, 22 Feb 2026 at 22:56, Andrés Pérez <[email-masked]> wrote:
>
> # OVERVIEW
>
> Since kernel v6.16.1, switching from an X11 session to a text VT and back
> freezes the display on a ThinkPad P15 Gen 2. The system remains responsive
> over SSH; only the display is frozen. Bisecting identified commit
> d1b618e7954802fe ("media: uvcvideo: Do not turn on the camera for some
> ioctls") as the trigger. Reverting the logic change in that commit
> fixes VT switching
> on v6.16.1, v6.17.9, and v6.18.9, but that is not an actual solution. Wayland
> compositors (e.g., river and sway) are not affected.
>
> Last good:  v6.15.9
> First bad:  v6.16.1
> Bisect result: d1b618e7954802fe media: uvcvideo: Do not turn on the
> camera for some ioctls
>
> ## Hardware:   Lenovo ThinkPad P15 Gen 2i (20YQ0031US)
> CPU:        Intel Core i7-11800H (Tiger Lake-H)
> iGPU:        Intel UHD Graphics (TGL GT1)
> dGPU:       NVIDIA T1200 (not involved in eDP output; driver: nvidia-open)
> Display:    15.6" 1920x1080 eDP, 10 bpc capable (EDID 1.4)
> Webcam:     Integrated Camera on PCH xHCI (Bus 003 Port 004)
> Firmware:   LENOVO N37ET61W (1.97)
> OS:         Arch Linux, Nix home-manager, X11 + xmonad, no display manager
>
> ## Symptoms and reproduction steps:
> 1. Boot, start X11 on tty1 (startx).
> 2. Switch to tty2 (Ctrl+Alt+F2): works.
> 3. Switch back to tty1 (Ctrl+Alt+F1): display freezes.
>    - Frozen on the last frame shown before switching away.
>    - System is fully responsive over SSH.
>    - Other VTs switch normally between each other as long as X11 is
> not active on them.
>    - Killing X does not recover the display. A reboot is required.
>
> # DEBUG ANALYSIS
>
> On v6.16.1, the VT switch back to X triggers a full modeset due to pipe
> configuration mismatches detected by intel_pipe_config_compare:
>
> [drm:intel_pipe_config_compare] fastset requirement not met in pipe_bpp
>   (expected 30, found 24)
> [drm:intel_pipe_config_compare] fastset requirement not met in dp_m_n
>   (expected link 269484/524288, found link 336855/524288)
> [drm:intel_pipe_config_compare] fastset requirement not met in dpll_hw_state
>   (expected cfgcr0: 0xe001a5, found cfgcr0: 0x1c2)
> [drm:intel_pipe_config_compare] fastset requirement not met in port_clock
>   (expected 270000, found 216000)
> [drm:intel_atomic_check] forcing full modeset
>
> On v6.15.9, the same VT switch shows no such messages.
> no pipe_config_compare runs, no modeset, no freeze.
>
> # BISECT AND VERIFICATION
>
> The bisect converged on d1b618e7954802fe in the uvcvideo driver. This
> commit adds a switch statement to uvc_v4l2_unlocked_ioctl that allows
> certain V4L2 IOCTLS to call video_ioctl2 directly without first calling
> uvc_pm_get/uvc_pm_put. Prior to this commit, all ioctls called uvc_pm_get
> before video_ioctl2.
>
> ## VT switching verification across kernel versions:
>
>   v6.12.74 arch pkg:   WORKS
>   v6.15.9 arch pkg:    WORKS
>   v6.15.9 from source: WORKS
>   v6.16.1 with d1b618e reverted:     WORKS
>   v6.17.9 with PM wrapping restored: WORKS
>   v6.18.9 with PM wrapping restored: WORKS
>
>   v6.16.1 from source:  FREEZES
>   v6.16.1 arch pkg:     FREEZES
>   v6.17.9 arch pkg:     FREEZES
>   v6.18.9 from source:  FREEZES
>   v6.18.9 arch pkg:     FREEZES
>
> ## Things that do not eliminate the freeze
>
>   - module_blacklist=uvcvideo on boot
>   - CONFIG_USB_VIDEO_CLASS=n (compiled out)

This is puzzling me a bit... You are saying that if you do not build
the uvc driver, the freeze is still happening?

Am I understanding this correctly?

>   - i915.enable_psr=0
>   - Bypassing intel_vrr_transcoder_enable/disable (no-op)
>   - xrandr --output eDP-1 --set "max bpc" 10
>   - Xorg config FBDepth 30 (No effect on pipe_bpp)
>
> ## Workaround patch
>
> Reverting the optimization from d1b618e to restore the unconditional
> uvc_pm_get/put wrapping for all ioctls. This is not a proper fix.
>
> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
> index 9e4a251eca88..15057b47ec4f 100644
> --- a/drivers/media/usb/uvc/uvc_v4l2.c
> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
> @@ -1199,33 +1199,12 @@ static long uvc_v4l2_unlocked_ioctl(struct file *file,
>   unsigned int converted_cmd = v4l2_translate_cmd(cmd);
>   int ret;
>
> - /* The following IOCTLs need to turn on the camera. */
> - switch (converted_cmd) {
> - case UVCIOC_CTRL_MAP:
> - case UVCIOC_CTRL_QUERY:
> - case VIDIOC_G_CTRL:
> - case VIDIOC_G_EXT_CTRLS:
> - case VIDIOC_G_INPUT:
> - case VIDIOC_QUERYCTRL:
> - case VIDIOC_QUERYMENU:
> - case VIDIOC_QUERY_EXT_CTRL:
> - case VIDIOC_S_CTRL:
> - case VIDIOC_S_EXT_CTRLS:
> - case VIDIOC_S_FMT:
> - case VIDIOC_S_INPUT:
> - case VIDIOC_S_PARM:
> - case VIDIOC_TRY_EXT_CTRLS:
> - case VIDIOC_TRY_FMT:
> - ret = uvc_pm_get(handle->stream->dev);
> - if (ret)
> - return ret;
> - ret = video_ioctl2(file, cmd, arg);
> - uvc_pm_put(handle->stream->dev);
> + ret = uvc_pm_get(handle->stream->dev);
> + if (ret)
>   return ret;
> - }
> -
> - /* The other IOCTLs can run with the camera off. */
> - return video_ioctl2(file, cmd, arg);
> + ret = video_ioctl2(file, cmd, arg);
> + uvc_pm_put(handle->stream->dev);
> + return ret;
>  }
>
>  const struct v4l2_ioctl_ops uvc_ioctl_ops = {
>
> Andrés
>

-- 
Ricardo Ribalda

From - Mon Feb 23 08:43:26 2026
Delivery-date: Mon, 23 Feb 2026 08:18:57 +0000
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t71834733; cv=none; b=SZmyi8S4V+yIlciQ+4rd1p/lQwt5DEuHmAjo7fwNIK2FGBDgtqIEyEad21FapAMONs97BXrqraPUUY+FozkKrLbjsOIkZgoseY8pZpMPCVKkhPdtPoBuBdaG+LD72xLYzXL7j3OpShguBSev20eKs9dbsDKYovytAksn0lpmOy4ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t71834733; c=relaxed/simple;
	bh=mfi2oIDXNC1HeAdz8FltvcXDHo2fg6vdS90o6q5YbVM=;
	h=Mime-Version:Content-Type:Date:Message-Id:Subject:Cc:From:To:
	 References:In-Reply-To; b�7ddZhukQsCQSFFCE9PscK1bnZu8s2WeT8UaUWBCAUL3DN77vRr4BCOPgvg77RGi6qUuxS6MbH1zdR29REKOebk6SxUQDbAFricwCEDOkXelEPZbuAYMeXSXtuFPHqMcDE11GfVWd5zkvAZh6DcquFGtYYc0V08t3fI4F78VwgARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=od8D7jdW; arc=none smtp.client-ip.30.226.201
Date: Mon, 23 Feb 2026 09:18:49 +0100
Subject: Re: [PATCH v2 1/2] mtd: spi-nor: sst: Fix write enable before AAI
 sequence
Cc: <[email-masked]>, <[email-masked]>,
 <[email-masked]>, <[email-masked]>, <[email-masked]>,
 <[email-masked]>, "Sanjaikumar V S"
 <[email-masked]>, <[email-masked]>
From: "Michael Walle" <[email-masked]>
To: "Sanjaikumar V S" <[email-masked]>,
 <[email-masked]>
DKIMCheck: Server passes DKIM test, 0 Spam score
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.232.135.74 listed in list.dnswl.org]
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.232.135.74 listed in zen.spamhaus.org]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -0.1 DKIM_VALID_EF          Message has a valid DKIM or DK signature from
                             envelope-from domain
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
 -0.0 DKIMWL_WL_HIGH         DKIMwl.org - High trust sender
SpamTally: Final spam score: -11

--ccacc5352b054326ba4c60c385f192b499ae4e18e1c3c67f98baab600635
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

Hi,

On Fri Feb 20, 2026 at 10:42 AM CET, Sanjaikumar V S wrote:
> From: Sanjaikumar V S <[email-masked]>
>
> When writing to SST flash starting at an odd address, a single byte is
> first programmed using the byte program (BP) command. After this
> operation completes, the flash hardware automatically clears the Write
> Enable Latch (WEL) bit.
>
> If an AAI (Auto Address Increment) word program sequence follows, it
> requires WEL to be set. Without re-enabling writes, the AAI sequence
> fails.
>
> Add spi_nor_write_enable() after the odd-address byte program, but only
> when an AAI sequence will follow (len > 2 bytes remaining).
>
> Cc: [email-masked]
> Signed-off-by: Sanjaikumar V S <[email-masked]>

Very strange. If that is correct, it actually never worked
correctly.

Fixes: b199489d37b2 ("mtd: spi-nor: add the framework for SPI NOR")

You've said, you didn't test this. Shouldn't it be pretty easy to
write to an odd offset? Also, from reading the code, it looks like
if write ends on an odd offset, it doesn't work either?

> ---
>  drivers/mtd/spi-nor/sst.c | 7 +++++++
>  1 file changed, 7 insertions(+)
>
> diff --git a/drivers/mtd/spi-nor/sst.c b/drivers/mtd/spi-nor/sst.c
> index 175211fe6a5e..fe714e6d0914 100644
> --- a/drivers/mtd/spi-nor/sst.c
> +++ b/drivers/mtd/spi-nor/sst.c
> @@ -210,6 +210,13 @@ static int sst_nor_write(struct mtd_info *mtd, loff_t to, size_t len,
>  
>  		to++;
>  		actual++;
> +
> +		/* BP clears WEL, re-enable if AAI sequence follows */
> +		if (actual < len - 1) {

For brevity, I'd drop the repeated condition and just do the
write_enable unconditionally.

-michael

> +			ret = spi_nor_write_enable(nor);
> +			if (ret)
> +				goto out;
> +		}
>  	}
>  
>  	/* Write out most of the data here. */

--ccacc5352b054326ba4c60c385f192b499ae4e18e1c3c67f98baab600635
Content-Type: application/pgp-signature; name="signature.asc"

--ccacc5352b054326ba4c60c385f192b499ae4e18e1c3c67f98baab600635--

From - Mon Feb 23 08:43:26 2026
Delivery-date: Mon, 23 Feb 2026 08:26:53 +0000
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t71835206; cv=none; b=VWI3Ac6blQSe/0h5zR/MhU+HUX4BeiIsydoNklr55GB2FYHcK0w7Te8W1ExtBQlgyAdRDPzgJqbXaVqk1SEIIiiW6REhBAhto1KDlLTiT96AvfcMiP79THjbGqyOn9mmimNlwPkdqiWaBZi+wXj4KT4ICL4suuXryabM2ZwhQxcARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t71835206; c=relaxed/simple;
	bh=sm6q1+ERW/BaOcu2jshdc2Eho9GqqWDTk0xMpvA9awk=;
	h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From:
	 In-Reply-To:Content-Type; b=WH75nYszYLDFqvtBcTTPPqq6GP8pmBRxow43Japq5IWrWQaCc1WFj7WRG3GUwXlGcuTNdKl+PsvvHhk12mB9QhNiNUK3puMQRBzuyz+xTuur5Pu1JFcvzypPLDHw04TtErWwMgcbEgky03SWHGoKayke7fPEAEoS6KU/Wms8F4IARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=leemhuis.info; spf=pass smtp.mailfrom=leemhuis.info; dkim=pass (2048-bit key) header.d=leemhuis.info header.i=@leemhuis.info header.b=YuCSGlnB; arc=none smtp.client-ip8.68.63.98
Date: Mon, 23 Feb 2026 09:26:37 +0100
Subject: Re: [REGRESSION] Display freeze on VT switch back to X11 since v6.16
To: Ricardo Ribalda <[email-masked]>,
 =?UTF-8?B?QW5kcsOpcyBQw6lyZXo=?= <[email-masked]>
Cc: [email-masked],
 Laurent Pinchart <[email-masked]>,
 Hans de Goede <[email-masked]>, Mauro Carvalho Chehab
 <[email-masked]>, Jani Nikula <[email-masked]>,
 Rodrigo Vivi <[email-masked]>,
 Joonas Lahtinen <[email-masked]>,
 Tvrtko Ursulin <[email-masked]>, David Airlie <[email-masked]>,
 Simona Vetter <[email-masked]>, [email-masked],
 [email-masked], [email-masked],
 [email-masked], [email-masked],
 [email-masked]
From: Thorsten Leemhuis <[email-masked]>
DKIMCheck: Server passes DKIM test, 0 Spam score
                             dbl.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: leemhuis.info]
  0.0 RCVD_IN_DNSWL_BLOCKED  RBL: ADMINISTRATOR NOTICE: The query to
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.234.253.10 listed in list.dnswl.org]
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.234.253.10 listed in zen.spamhaus.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.0 URIBL_ZEN_BLOCKED_OPENDNS ADMINISTRATOR NOTICE: The query to
                             zen.spamhaus.org was blocked due to usage
                             of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [URIs: leemhuis.info]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
SpamTally: Final spam score: 4

On 2/23/26 09:10, Ricardo Ribalda wrote:
> Hi Andrés
> 
> Thanks for doing the bisecting
> 
> On Sun, 22 Feb 2026 at 22:56, Andrés Pérez <[email-masked]> wrote:
>>
>> # OVERVIEW
>>
>> Since kernel v6.16.1, switching from an X11 session to a text VT and back
>> freezes the display on a ThinkPad P15 Gen 2. The system remains responsive
>> over SSH; only the display is frozen. Bisecting identified commit
>> d1b618e7954802fe ("media: uvcvideo: Do not turn on the camera for some
>> ioctls") as the trigger. Reverting the logic change in that commit
>> fixes VT switching
>> on v6.16.1, v6.17.9, and v6.18.9, but that is not an actual solution. Wayland
>> compositors (e.g., river and sway) are not affected.
>>
>> Last good:  v6.15.9
>> First bad:  v6.16.1
>> Bisect result: d1b618e7954802fe media: uvcvideo: Do not turn on the
>> camera for some ioctls
>>
>> ## Hardware:   Lenovo ThinkPad P15 Gen 2i (20YQ0031US)
>> CPU:        Intel Core i7-11800H (Tiger Lake-H)
>> iGPU:        Intel UHD Graphics (TGL GT1)
>> dGPU:       NVIDIA T1200 (not involved in eDP output; driver: nvidia-open)

Could this be caused by nvidia's own driver, even if it is not supposed
to be involved? Might be worth ruling out with a proper vanilla kernel,
ideally really fresh, so 7.0-rc1.

Ciao, Thorsten

>> Display:    15.6" 1920x1080 eDP, 10 bpc capable (EDID 1.4)
>> Webcam:     Integrated Camera on PCH xHCI (Bus 003 Port 004)
>> Firmware:   LENOVO N37ET61W (1.97)
>> OS:         Arch Linux, Nix home-manager, X11 + xmonad, no display manager
>>
>> ## Symptoms and reproduction steps:
>> 1. Boot, start X11 on tty1 (startx).
>> 2. Switch to tty2 (Ctrl+Alt+F2): works.
>> 3. Switch back to tty1 (Ctrl+Alt+F1): display freezes.
>>    - Frozen on the last frame shown before switching away.
>>    - System is fully responsive over SSH.
>>    - Other VTs switch normally between each other as long as X11 is
>> not active on them.
>>    - Killing X does not recover the display. A reboot is required.
>>
>> # DEBUG ANALYSIS
>>
>> On v6.16.1, the VT switch back to X triggers a full modeset due to pipe
>> configuration mismatches detected by intel_pipe_config_compare:
>>
>> [drm:intel_pipe_config_compare] fastset requirement not met in pipe_bpp
>>   (expected 30, found 24)
>> [drm:intel_pipe_config_compare] fastset requirement not met in dp_m_n
>>   (expected link 269484/524288, found link 336855/524288)
>> [drm:intel_pipe_config_compare] fastset requirement not met in dpll_hw_state
>>   (expected cfgcr0: 0xe001a5, found cfgcr0: 0x1c2)
>> [drm:intel_pipe_config_compare] fastset requirement not met in port_clock
>>   (expected 270000, found 216000)
>> [drm:intel_atomic_check] forcing full modeset
>>
>> On v6.15.9, the same VT switch shows no such messages.
>> no pipe_config_compare runs, no modeset, no freeze.
>>
>> # BISECT AND VERIFICATION
>>
>> The bisect converged on d1b618e7954802fe in the uvcvideo driver. This
>> commit adds a switch statement to uvc_v4l2_unlocked_ioctl that allows
>> certain V4L2 IOCTLS to call video_ioctl2 directly without first calling
>> uvc_pm_get/uvc_pm_put. Prior to this commit, all ioctls called uvc_pm_get
>> before video_ioctl2.
>>
>> ## VT switching verification across kernel versions:
>>
>>   v6.12.74 arch pkg:   WORKS
>>   v6.15.9 arch pkg:    WORKS
>>   v6.15.9 from source: WORKS
>>   v6.16.1 with d1b618e reverted:     WORKS
>>   v6.17.9 with PM wrapping restored: WORKS
>>   v6.18.9 with PM wrapping restored: WORKS
>>
>>   v6.16.1 from source:  FREEZES
>>   v6.16.1 arch pkg:     FREEZES
>>   v6.17.9 arch pkg:     FREEZES
>>   v6.18.9 from source:  FREEZES
>>   v6.18.9 arch pkg:     FREEZES
>>
>> ## Things that do not eliminate the freeze
>>
>>   - module_blacklist=uvcvideo on boot
>>   - CONFIG_USB_VIDEO_CLASS=n (compiled out)
> 
> This is puzzling me a bit... You are saying that if you do not build
> the uvc driver, the freeze is still happening?
> 
> Am I understanding this correctly?
> 
>>   - i915.enable_psr=0
>>   - Bypassing intel_vrr_transcoder_enable/disable (no-op)
>>   - xrandr --output eDP-1 --set "max bpc" 10
>>   - Xorg config FBDepth 30 (No effect on pipe_bpp)
>>
>> ## Workaround patch
>>
>> Reverting the optimization from d1b618e to restore the unconditional
>> uvc_pm_get/put wrapping for all ioctls. This is not a proper fix.
>>
>> diff --git a/drivers/media/usb/uvc/uvc_v4l2.c b/drivers/media/usb/uvc/uvc_v4l2.c
>> index 9e4a251eca88..15057b47ec4f 100644
>> --- a/drivers/media/usb/uvc/uvc_v4l2.c
>> +++ b/drivers/media/usb/uvc/uvc_v4l2.c
>> @@ -1199,33 +1199,12 @@ static long uvc_v4l2_unlocked_ioctl(struct file *file,
>>   unsigned int converted_cmd = v4l2_translate_cmd(cmd);
>>   int ret;
>>
>> - /* The following IOCTLs need to turn on the camera. */
>> - switch (converted_cmd) {
>> - case UVCIOC_CTRL_MAP:
>> - case UVCIOC_CTRL_QUERY:
>> - case VIDIOC_G_CTRL:
>> - case VIDIOC_G_EXT_CTRLS:
>> - case VIDIOC_G_INPUT:
>> - case VIDIOC_QUERYCTRL:
>> - case VIDIOC_QUERYMENU:
>> - case VIDIOC_QUERY_EXT_CTRL:
>> - case VIDIOC_S_CTRL:
>> - case VIDIOC_S_EXT_CTRLS:
>> - case VIDIOC_S_FMT:
>> - case VIDIOC_S_INPUT:
>> - case VIDIOC_S_PARM:
>> - case VIDIOC_TRY_EXT_CTRLS:
>> - case VIDIOC_TRY_FMT:
>> - ret = uvc_pm_get(handle->stream->dev);
>> - if (ret)
>> - return ret;
>> - ret = video_ioctl2(file, cmd, arg);
>> - uvc_pm_put(handle->stream->dev);
>> + ret = uvc_pm_get(handle->stream->dev);
>> + if (ret)
>>   return ret;
>> - }
>> -
>> - /* The other IOCTLs can run with the camera off. */
>> - return video_ioctl2(file, cmd, arg);
>> + ret = video_ioctl2(file, cmd, arg);
>> + uvc_pm_put(handle->stream->dev);
>> + return ret;
>>  }
>>
>>  const struct v4l2_ioctl_ops uvc_ioctl_ops = {
>>
>> Andrés
>>
> 
> 

From - Mon Feb 23 08:43:26 2026
Delivery-date: Mon, 23 Feb 2026 08:41:20 +0000
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t71836036; cv=none; b�qkoiLR9i58z5VWjQo9pO0QAFQGgoS9AmWzbFqRnnXkL/gmdapcleH+sRAt4inuqSvbDX1E3Wsj9uPT6ThSqItK0Q3u1Ku4lY3+Ex6jyB+sLKCfXLh/wAZcbPnkijC6NuZfpn+4MUtd+W/oJOFf7L+7PiLq1nk2D2sA98DzxS8ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t71836036; c=relaxed/simple;
	bh=dsGJfsX/lCAwZRvqmeMK/TH1AGNiHGT2CsWkKbbh2Ok=;
	h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Lxou5N2i/Yl6cyKh7porDDkhJDfYMBVN2NWwowh0Cni/SgjLp71UuPaHuC+7RQLrbMlPeobl5hkd+bO4ecQOBMN8Odu2h5F4EpBf3VdCkipngK4DQXSgVgD6gTV/BVBzdOrJFy+ooDV2dnLR2rCIjJoaSM25Mh9kZcSWqwJw/RUARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=WqnCFg0p; arc=none smtp.client-ip 9.85.215.195
From: Menglong Dong <[email-masked]>
To: [email-masked],
	[email-masked]
Cc: [email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked]
Subject: [PATCH bpf-next 0/3] bpf: fsession support for s390
Date: Mon, 23 Feb 2026 16:40:19 +0800
DKIMCheck: Server passes DKIM test, 0 Spam score
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [104.64.211.4 listed in zen.spamhaus.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider
                             [menglong8.dong[at]gmail.com]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
  0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
                             EnvelopeFrom freemail headers are
                             different
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
SpamTally: Final spam score: 4

Implement bpf fsession for the s390 architecture.

Menglong Dong (3):
  bpf,s390: introduce emit_store_stack_imm64() for trampoline
  bpf,s390: add fsession support for trampolines
  selftests/bpf: enable fsession_test on s390

 arch/s390/net/bpf_jit_comp.c                  | 97 ++++++++++++++-----
 .../selftests/bpf/progs/get_func_args_test.c  |  2 +-
 .../selftests/bpf/progs/get_func_ip_test.c    |  2 +-
 3 files changed, 75 insertions(+), 26 deletions(-)

-- 
2.53.0

From - Mon Feb 23 08:43:33 2026
Delivery-date: Mon, 23 Feb 2026 08:43:29 +0000
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t71836045; cv=none; b=aPumH4UJPt1ncGdQGjowjmw5tM2QPgoRTQyA9MTMc0NSxjl9OqCUNs36AVSIgBnqB4Nd0Qgl7aLpq3ItkgPKwnk0g1PrYzPZCz0JXuS31wfRFOZxralGhG1X5+G91m6RGzx5OZeacWTZYyrRawH/iN5dpBL1drxhRMoZZnMagxIARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org;
	s=arc-20240116; t71836045; c=relaxed/simple;
	bh=nEKT87239/0oP7+UDsczkgsNom6oeFHqhXSC4GmgIow=;
	h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References:
	 MIME-Version; b=Xs1bw/HqaW/EqaQtDFZsskhknfe7+TM4k523Ofv2G2gTeFYf3oLh9QeW2y13ZYZd0z4fYAJg2OwRQUBsONV/gg5DfsuQ3N/mL8SfzZPgcWbeCifszQyBeljmXuvrpwxWf3tJJIAinKPSgY9ZCkSSrzH5p1KN/FlnaXw6xMN+0jcARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=lL0AflJe; arc=none smtp.client-ip 9.85.214.195
From: Menglong Dong <[email-masked]>
To: [email-masked],
	[email-masked]
Cc: [email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked],
	[email-masked]
Subject: [PATCH bpf-next 1/3] bpf,s390: introduce emit_store_stack_imm64() for trampoline
Date: Mon, 23 Feb 2026 16:40:20 +0800
DKIMCheck: Server passes DKIM test, 0 Spam score
                             DNSWL was blocked.  See
                             http://wiki.apache.org/spamassassin/DnsBlocklists#DnsBlocklists-dnsbl-block
                              for more information.
                             [172.105.105.114 listed in list.dnswl.org]
  0.0 RCVD_IN_ZEN_BLOCKED_OPENDNS RBL: ADMINISTRATOR NOTICE: The query
                              to zen.spamhaus.org was blocked due to
                             usage of an open resolver. See
                             https://www.spamhaus.org/returnc/pub/
                             [172.105.105.114 listed in zen.spamhaus.org]
  1.5 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level
                             mail domains are different
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider
                             [menglong8.dong[at]gmail.com]
  0.1 DKIM_SIGNED            Message has a DKIM or DK signature, not necessarily
                             valid
 -0.1 DKIM_VALID             Message has at least one valid DKIM or DK signature
 -0.1 DKIM_VALID_AU          Message has a valid DKIM or DK signature from
                             author's domain
  0.0 FREEMAIL_FORGED_FROMDOMAIN 2nd level domains in From and
                             EnvelopeFrom freemail headers are
                             different
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager
SpamTally: Final spam score: 4

Introduce a helper to store 64-bit immediate on the trampoline stack with
a help of a register.

Signed-off-by: Menglong Dong <[email-masked]>
---
 arch/s390/net/bpf_jit_comp.c | 27 +++++++++++----------------
 1 file changed, 11 insertions(+), 16 deletions(-)

diff --git a/arch/s390/net/bpf_jit_comp.c b/arch/s390/net/bpf_jit_comp.c
index 579461d471bb..763d2491dfa3 100644
--- a/arch/s390/net/bpf_jit_comp.c
+++ b/arch/s390/net/bpf_jit_comp.c
@@ -2506,6 +2506,13 @@ static void load_imm64(struct bpf_jit *jit, int dst_reg, u64 val)
 	EMIT6_IMM(0xc00d0000, dst_reg, val);
 }
 
+static void emit_store_stack_imm64(struct bpf_jit *jit, int tmp_reg, int stack_off, u64 imm)
+{
+	load_imm64(jit, tmp_reg, imm);
+	/* stg %tmp_reg,stack_off(%r15) */
+	EMIT6_DISP_LH(0xe3000000, 0x0024, tmp_reg, REG_0, REG_15, stack_off);
+}
+
 static int invoke_bpf_prog(struct bpf_tramp_jit *tjit,
 			   const struct btf_func_model *m,
 			   struct bpf_tramp_link *tlink, bool save_ret)
@@ -2520,10 +2527,7 @@ static int invoke_bpf_prog(struct bpf_tramp_jit *tjit,
 	 * run_ctx.cookie = tlink->cookie;
 	 */
 
-	/* %r0 = tlink->cookie */
-	load_imm64(jit, REG_W0, tlink->cookie);
-	/* stg %r0,cookie_off(%r15) */
-	EMIT6_DISP_LH(0xe3000000, 0x0024, REG_W0, REG_0, REG_15, cookie_off);
+	emit_store_stack_imm64(jit, REG_W0, cookie_off, tlink->cookie);
 
 	/*
 	 * if ((start = __bpf_prog_enter(p, &run_ctx)) = 0)
@@ -2743,18 +2747,9 @@ static int __arch_prepare_bpf_trampoline(struct bpf_tramp_image *im,
 	 * arg_cnt = m->nr_args;
 	 */
 
-	if (flags & BPF_TRAMP_F_IP_ARG) {
-		/* %r0 = func_addr */
-		load_imm64(jit, REG_0, (u64)func_addr);
-		/* stg %r0,ip_off(%r15) */
-		EMIT6_DISP_LH(0xe3000000, 0x0024, REG_0, REG_0, REG_15,
-			      tjit->ip_off);
-	}
-	/* lghi %r0,nr_bpf_args */
-	EMIT4_IMM(0xa7090000, REG_0, nr_bpf_args);
-	/* stg %r0,arg_cnt_off(%r15) */
-	EMIT6_DISP_LH(0xe3000000, 0x0024, REG_0, REG_0, REG_15,
-		      tjit->arg_cnt_off);
+	if (flags & BPF_TRAMP_F_IP_ARG)
+		emit_store_stack_imm64(jit, REG_0, tjit->ip_off, (u64)func_addr);
+	emit_store_stack_imm64(jit, REG_0, tjit->arg_cnt_off, nr_bpf_args);
 
 	if (flags & BPF_TRAMP_F_CALL_ORIG) {
 		/*
-- 
2.53.0

From - Mon Feb 23 08:44:08 2026
Delivery-date: Mon, 23 Feb 2026 08:44:04 +0000
ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
	t71836053; cv=none; b=dN8JRZXomiwzZKeuyseZ