--- /dev/null
+From 2daf8ac812c3d78c642fe7652f62e29df5e3da20 Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Wed, 24 Jun 2026 17:38:11 +0100
+Subject: afs: Fix further netns teardown to cancel the preallocation charger
+
+From: David Howells <dhowells@redhat.com>
+
+commit 2daf8ac812c3d78c642fe7652f62e29df5e3da20 upstream.
+
+When an afs network namespace is torn down, it cancels and waits for the
+work item that keeps the preallocated rxrpc call/conn/peer queue charged
+before disabling incoming (i.e. listen 0), but there's a small window in
+which it can be requeued by an incoming call wending through the I/O
+thread.
+
+Fix this by cancelling the charger work item again after reducing the
+listen backlog to zero.
+
+Fixes: 47694fbc9d24 ("afs: Fix netns teardown to cancel the preallocation charger")
+Reported-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Link: https://sashiko.dev/#/patchset/20260609140911.838677-1-dhowells%40redhat.com
+cc: Li Daming <d4n.for.sec@gmail.com>
+cc: Ren Wei <n05ec@lzu.edu.cn>
+cc: Marc Dionne <marc.dionne@auristor.com>
+cc: Jeffrey Altman <jaltman@auristor.com>
+cc: Simon Horman <horms@kernel.org>
+cc: linux-afs@lists.infradead.org
+cc: stable@kernel.org
+Link: https://patch.msgid.link/20260624163819.3017002-5-dhowells@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/afs/rxrpc.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/fs/afs/rxrpc.c
++++ b/fs/afs/rxrpc.c
+@@ -111,8 +111,13 @@ void afs_close_socket(struct afs_net *ne
+ _enter("");
+
+ cancel_work_sync(&net->charge_preallocation_work);
++ /* Future work items should now see ->live is false. */
++
+ kernel_listen(net->socket, 0);
++
++ /* Make sure work items are no longer running. */
+ flush_workqueue(afs_async_calls);
++ cancel_work_sync(&net->charge_preallocation_work);
+
+ if (net->spare_incoming_call) {
+ afs_put_call(net->spare_incoming_call);
--- /dev/null
+From 47694fbc9d24ab6bf210f91e8efe06a10a478064 Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Tue, 9 Jun 2026 15:09:08 +0100
+Subject: afs: Fix netns teardown to cancel the preallocation charger
+
+From: David Howells <dhowells@redhat.com>
+
+commit 47694fbc9d24ab6bf210f91e8efe06a10a478064 upstream.
+
+Fix the teardown of an afs network namespace to make sure it cancels the
+work item that keeps the preallocated rxrpc call/conn/peer queue charged
+before incoming calls are disabled (i.e. listen 0).
+
+Also, if net->live is false because the afs netns is being deleted, make
+afs_charge_preallocation() skip charging and make afs_rx_new_call() avoid
+requeuing the charger.
+
+(This was found by AI review).
+
+Fixes: 00e907127e6f ("rxrpc: Preallocate peers, conns and calls for incoming service requests")
+Reported-by: Simon Horman <horms@kernel.org>
+Signed-off-by: David Howells <dhowells@redhat.com>
+cc: Li Daming <d4n.for.sec@gmail.com>
+cc: Ren Wei <n05ec@lzu.edu.cn>
+cc: Marc Dionne <marc.dionne@auristor.com>
+cc: Jeffrey Altman <jaltman@auristor.com>
+cc: linux-afs@lists.infradead.org
+cc: stable@kernel.org
+Link: https://patch.msgid.link/20260609140911.838677-5-dhowells@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/afs/rxrpc.c | 6 ++++--
+ 1 file changed, 4 insertions(+), 2 deletions(-)
+
+--- a/fs/afs/rxrpc.c
++++ b/fs/afs/rxrpc.c
+@@ -110,6 +110,7 @@ void afs_close_socket(struct afs_net *ne
+ {
+ _enter("");
+
++ cancel_work_sync(&net->charge_preallocation_work);
+ kernel_listen(net->socket, 0);
+ flush_workqueue(afs_async_calls);
+
+@@ -737,7 +738,7 @@ void afs_charge_preallocation(struct wor
+ container_of(work, struct afs_net, charge_preallocation_work);
+ struct afs_call *call = net->spare_incoming_call;
+
+- for (;;) {
++ while (READ_ONCE(net->live)) {
+ if (!call) {
+ call = afs_alloc_call(net, &afs_RXCMxxxx, GFP_KERNEL);
+ if (!call)
+@@ -782,7 +783,8 @@ static void afs_rx_new_call(struct sock
+ {
+ struct afs_net *net = afs_sock2net(sk);
+
+- queue_work(afs_wq, &net->charge_preallocation_work);
++ if (net->live)
++ queue_work(afs_wq, &net->charge_preallocation_work);
+ }
+
+ /*
--- /dev/null
+From 0b70716081c6462be9b2928ad736d0d527b09678 Mon Sep 17 00:00:00 2001
+From: Matvey Kovalev <matvey.kovalev@ispras.ru>
+Date: Mon, 22 Jun 2026 10:08:37 +0100
+Subject: afs: fix NULL pointer dereference in afs_get_tree()
+
+From: Matvey Kovalev <matvey.kovalev@ispras.ru>
+
+commit 0b70716081c6462be9b2928ad736d0d527b09678 upstream.
+
+afs_alloc_sbi() uses kzalloc for memory allocation. And, if
+ctx->dyn_root is not null, as->cell and as->volume are null.
+In trace_afs_get_tree() they are dereferenced.
+
+KASAN error message:
+
+KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
+CPU: 2 PID: 18478 Comm: syz-executor.7 Not tainted 5.10.246-syzkaller #0
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1
+04/01/2014
+RIP: 0010:perf_trace_afs_get_tree+0x1d9/0x550
+include/trace/events/afs.h:1365
+
+Call Trace:
+trace_afs_get_tree include/trace/events/afs.h:1365 [inline]
+afs_get_tree+0x922/0x1350 fs/afs/super.c:599
+vfs_get_tree+0x8e/0x300 fs/super.c:1572
+do_new_mount fs/namespace.c:3011 [inline]
+path_mount+0x14a5/0x2220 fs/namespace.c:3341
+do_mount fs/namespace.c:3354 [inline]
+__do_sys_mount fs/namespace.c:3562 [inline]
+__se_sys_mount fs/namespace.c:3539 [inline]
+__x64_sys_mount+0x283/0x300 fs/namespace.c:3539
+ do_syscall_64+0x33/0x50 arch/x86/entry/common.c:46
+entry_SYSCALL_64_after_hwframe+0x67/0xd1
+
+Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
+
+Fixes: 80548b03991f5 ("afs: Add more tracepoints")
+Cc: stable@vger.kernel.org
+Signed-off-by: Matvey Kovalev <matvey.kovalev@ispras.ru>
+Signed-off-by: David Howells <dhowells@redhat.com>
+Link: https://patch.msgid.link/20260622090856.2746629-4-dhowells@redhat.com
+cc: Marc Dionne <marc.dionne@auristor.com>
+cc: linux-afs@lists.infradead.org
+Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/afs/super.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/fs/afs/super.c
++++ b/fs/afs/super.c
+@@ -598,7 +598,8 @@ static int afs_get_tree(struct fs_contex
+ }
+
+ fc->root = dget(sb->s_root);
+- trace_afs_get_tree(as->cell, as->volume);
++ if (!ctx->dyn_root)
++ trace_afs_get_tree(as->cell, as->volume);
+ _leave(" = 0 [%p]", sb);
+ return 0;
+
--- /dev/null
+From 018f2dc3a42098d3b04edd1480adc51d268adb14 Mon Sep 17 00:00:00 2001
+From: Chen-Yu Tsai <wens@kernel.org>
+Date: Thu, 25 Dec 2025 18:36:12 +0800
+Subject: dt-bindings: media: sun4i-a10-video-engine: Add interconnect properties
+
+From: Chen-Yu Tsai <wens@kernel.org>
+
+commit 018f2dc3a42098d3b04edd1480adc51d268adb14 upstream.
+
+The Allwinner video engine sits behind the MBUS that is represented as
+an interconnect.
+
+Make sure that the interconnect properties are valid in the binding.
+
+Fixes: d41662e52a03 ("media: dt-bindings: media: allwinner,sun4i-a10-video-engine: Add R40 compatible")
+Cc: stable@vger.kernel.org
+Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
+Acked-by: Rob Herring (Arm) <robh@kernel.org>
+Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com>
+Signed-off-by: Nicolas Dufresne <nicolas.dufresne@collabora.com>
+Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml | 10 ++++++++++
+ 1 file changed, 10 insertions(+)
+
+--- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
++++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml
+@@ -63,6 +63,16 @@ properties:
+ CMA pool to use for buffers allocation instead of the default
+ CMA pool.
+
++ # FIXME: This should be made required eventually once every SoC will
++ # have the MBUS declared.
++ interconnects:
++ maxItems: 1
++
++ # FIXME: This should be made required eventually once every SoC will
++ # have the MBUS declared.
++ interconnect-names:
++ const: dma-mem
++
+ required:
+ - compatible
+ - reg
--- /dev/null
+From 6aa38ef0eab32df5409b72d62509de6ba09cea50 Mon Sep 17 00:00:00 2001
+From: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
+Date: Tue, 9 Jun 2026 14:26:40 +0800
+Subject: dt-bindings: power: imx93: Add MIPI PHY power domain
+
+From: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
+
+commit 6aa38ef0eab32df5409b72d62509de6ba09cea50 upstream.
+
+Add MIPI PHY power domain for shared PHY resources used by both
+MIPI DSI and CSI blocks.
+
+Signed-off-by: Guoniu Zhou <guoniu.zhou@oss.nxp.com>
+Reviewed-by: Frank Li <Frank.Li@nxp.com>
+Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
+Reviewed-by: Peng Fan <peng.fan@nxp.com>
+Fixes: e9aa77d413c9 ("soc: imx: add i.MX93 media blk ctrl driver")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ulf Hansson <ulfh@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/dt-bindings/power/fsl,imx93-power.h | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/include/dt-bindings/power/fsl,imx93-power.h
++++ b/include/dt-bindings/power/fsl,imx93-power.h
+@@ -11,5 +11,6 @@
+ #define IMX93_MEDIABLK_PD_PXP 2
+ #define IMX93_MEDIABLK_PD_LCDIF 3
+ #define IMX93_MEDIABLK_PD_ISI 4
++#define IMX93_MEDIABLK_PD_MIPI_PHY 5
+
+ #endif
--- /dev/null
+From 5fae9a928482d4845bca169a3a098789203a1ca4 Mon Sep 17 00:00:00 2001
+From: Ian Bridges <icb@fastmail.org>
+Date: Wed, 24 Jun 2026 16:11:36 -0500
+Subject: fbcon: fix NULL pointer dereference for a console without vc_data
+
+From: Ian Bridges <icb@fastmail.org>
+
+commit 5fae9a928482d4845bca169a3a098789203a1ca4 upstream.
+
+fbcon_new_modelist() runs when a framebuffer's modelist changes. For each
+console mapped to it with fb_display[i].mode set, it reads vc_cons[i].d and
+passes the vc_num to fbcon_set_disp(). This assumes a console with a mode
+set has a vc_data, but it can be NULL. fbcon_set_disp() sets
+fb_display[i].mode before it checks vc_data, and fbcon_deinit() leaves the
+mode set after the vc_data is freed. fbcon_new_modelist() then dereferences
+the NULL vc_data.
+
+Keep fb_display[i].mode set only while the console has a vc_data. Check
+vc_data before setting the mode in fbcon_set_disp(), and clear the mode in
+fbcon_deinit(). The existing mode check in fbcon_new_modelist() then skips
+such consoles.
+
+Reported-by: syzbot+42525d636f430fd5d983@syzkaller.appspotmail.com
+Closes: https://syzkaller.appspot.com/bug?extid=42525d636f430fd5d983
+Cc: stable@vger.kernel.org
+Assisted-by: Claude:claude-opus-4-8
+Signed-off-by: Ian Bridges <icb@fastmail.org>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/core/fbcon.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/video/fbdev/core/fbcon.c
++++ b/drivers/video/fbdev/core/fbcon.c
+@@ -1201,6 +1201,7 @@ static void fbcon_deinit(struct vc_data
+ int idx;
+
+ fbcon_free_font(p);
++ p->mode = NULL;
+ idx = con2fb_map[vc->vc_num];
+
+ if (idx == -1)
+@@ -1371,14 +1372,14 @@ static void fbcon_set_disp(struct fb_inf
+
+ p = &fb_display[unit];
+
+- if (var_to_display(p, var, info))
+- return;
+-
+ vc = vc_cons[unit].d;
+
+ if (!vc)
+ return;
+
++ if (var_to_display(p, var, info))
++ return;
++
+ default_mode = vc->vc_display_fg;
+ svc = *default_mode;
+ t = &fb_display[svc->vc_num];
--- /dev/null
+From a15b773fe4ffa450b56347cc506b2d1405600f5d Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Fri, 17 Apr 2026 05:19:29 +0000
+Subject: media: uvcvideo: Avoid partial metadata buffers
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit a15b773fe4ffa450b56347cc506b2d1405600f5d upstream.
+
+If the metadata queue that is empty receives a new buffer while we are
+in the middle of processing a frame, the first metadata buffer will
+contain partial information.
+
+Avoid this by tracking the state of the metadata buffer and making sure
+that it is in sync with the data buffer.
+
+Now that we are at it, make sure that we skip buffers of size 1 or 0.
+They are not allowed by the spec... but it is a simple check to add and
+better be safe than sorry.
+
+Fixes: 088ead255245 ("media: uvcvideo: Add a metadata device node")
+Cc: stable@vger.kernel.org
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Link: https://patch.msgid.link/20260417-uvc-meta-partial-v2-2-31d274af7d2d@chromium.org
+Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_video.c | 13 +++++++++----
+ 1 file changed, 9 insertions(+), 4 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_video.c
++++ b/drivers/media/usb/uvc/uvc_video.c
+@@ -1152,7 +1152,9 @@ static void uvc_video_stats_stop(struct
+ * uvc_video_decode_end will never be called with a NULL buffer.
+ */
+ static int uvc_video_decode_start(struct uvc_streaming *stream,
+- struct uvc_buffer *buf, const u8 *data, int len)
++ struct uvc_buffer *buf,
++ struct uvc_buffer *meta_buf,
++ const u8 *data, int len)
+ {
+ u8 header_len;
+ u8 fid;
+@@ -1225,6 +1227,8 @@ static int uvc_video_decode_start(struct
+
+ /* TODO: Handle PTS and SCR. */
+ buf->state = UVC_BUF_STATE_ACTIVE;
++ if (meta_buf)
++ meta_buf->state = UVC_BUF_STATE_ACTIVE;
+ }
+
+ /*
+@@ -1441,7 +1445,7 @@ static void uvc_video_decode_meta(struct
+ ktime_t time;
+ const u8 *scr;
+
+- if (!meta_buf || length == 2)
++ if (length <= 2 || !meta_buf || meta_buf->state != UVC_BUF_STATE_ACTIVE)
+ return;
+
+ has_pts = mem[1] & UVC_STREAM_PTS;
+@@ -1558,7 +1562,7 @@ static void uvc_video_decode_isoc(struct
+ /* Decode the payload header. */
+ mem = urb->transfer_buffer + urb->iso_frame_desc[i].offset;
+ do {
+- ret = uvc_video_decode_start(stream, buf, mem,
++ ret = uvc_video_decode_start(stream, buf, meta_buf, mem,
+ urb->iso_frame_desc[i].actual_length);
+ if (ret == -EAGAIN)
+ uvc_video_next_buffers(stream, &buf, &meta_buf);
+@@ -1607,7 +1611,8 @@ static void uvc_video_decode_bulk(struct
+ */
+ if (stream->bulk.header_size == 0 && !stream->bulk.skip_payload) {
+ do {
+- ret = uvc_video_decode_start(stream, buf, mem, len);
++ ret = uvc_video_decode_start(stream, buf, meta_buf, mem,
++ len);
+ if (ret == -EAGAIN)
+ uvc_video_next_buffers(stream, &buf, &meta_buf);
+ } while (ret == -EAGAIN);
--- /dev/null
+From ba649fff36c1fe68489a86d00285224907edd436 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Wed, 13 May 2026 11:49:23 +0000
+Subject: media: uvcvideo: Do not add clock samples with small sof delta
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit ba649fff36c1fe68489a86d00285224907edd436 upstream.
+
+Some UVC 1.1 cameras running in fast isochronous mode tend to spam the
+USB host with a lot of empty packets. These packets contain clock
+information and are added to the clock buffer but do not add any
+accuracy to the calculation. In fact, it is quite the opposite, in our
+calculations, only the first and the last timestamp is used, and we only
+have 32 slots.
+
+Ignore the samples that will produce less than MIN_HW_TIMESTAMP_DIFF
+data.
+
+Fixes: 141270bd95d4 ("media: uvcvideo: Refactor clock circular buffer")
+Cc: stable@vger.kernel.org
+Tested-by: Yunke Cao <yunkec@google.com>
+Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-4-7a64838b0b02@chromium.org
+Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_video.c | 14 ++++++++++++--
+ 1 file changed, 12 insertions(+), 2 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_video.c
++++ b/drivers/media/usb/uvc/uvc_video.c
+@@ -532,6 +532,15 @@ static void uvc_video_clock_add_sample(s
+ spin_unlock_irqrestore(&clock->lock, flags);
+ }
+
++static inline u16 sof_diff(u16 a, u16 b)
++{
++ /*
++ * Because the result is modulo 2048 (via & 2047), we do not need a
++ * special case for a < b.
++ */
++ return (a - b) & 2047;
++}
++
+ static void
+ uvc_video_clock_decode(struct uvc_streaming *stream, struct uvc_buffer *buf,
+ const u8 *data, int len)
+@@ -652,12 +661,13 @@ uvc_video_clock_decode(struct uvc_stream
+ sample.dev_sof = (sample.dev_sof + stream->clock.sof_offset) & 2047;
+
+ /*
+- * To limit the amount of data, drop SCRs with an SOF identical to the
++ * To limit the amount of data, drop SCRs with an SOF similar to the
+ * previous one. This filtering is also needed to support UVC 1.5, where
+ * all the data packets of the same frame contains the same SOF. In that
+ * case only the first one will match the host_sof.
+ */
+- if (sample.dev_sof == stream->clock.last_sof)
++ if (sof_diff(sample.dev_sof, stream->clock.last_sof) <=
++ (UVC_MIN_HW_TIMESTAMP_DIFF / stream->clock.size))
+ return;
+
+ uvc_video_clock_add_sample(&stream->clock, &sample);
--- /dev/null
+From 2f24ac8dd87983a55f0498898f34a5f2b735b802 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Mon, 23 Mar 2026 09:53:53 +0000
+Subject: media: uvcvideo: Fix buffer sequence in frame gaps
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit 2f24ac8dd87983a55f0498898f34a5f2b735b802 upstream.
+
+In UVC, the FID flips with every frame. For every FID flip, we increase
+the stream sequence number.
+
+Now, if a FID flips multiple times and there is no data transferred between
+the flips, the buffer sequence number will be set to the value of the
+stream sequence number after the first flip.
+
+Userspace uses the buffer sequence number to determine if there have been
+missing frames. With the current behaviour, userspace will think that the
+gap is in the wrong location.
+
+This patch modifies uvc_video_decode_start() to provide the correct buffer
+sequence number and timestamp.
+
+Cc: stable@kernel.org
+Fixes: 650b95feee35 ("[media] uvcvideo: Generate discontinuous sequence numbers when frames are lost")
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_video.c | 17 +++++++++++++----
+ 1 file changed, 13 insertions(+), 4 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_video.c
++++ b/drivers/media/usb/uvc/uvc_video.c
+@@ -1181,6 +1181,19 @@ static int uvc_video_decode_start(struct
+ stream->sequence++;
+ if (stream->sequence)
+ uvc_video_stats_update(stream);
++
++ /*
++ * On a FID flip initialize sequence number and timestamp.
++ *
++ * The driver already takes care of injecting FID flips for
++ * UVC_QUIRK_STREAM_NO_FID and UVC_QUIRK_MJPEG_NO_EOF.
++ */
++ if (buf) {
++ buf->buf.field = V4L2_FIELD_NONE;
++ buf->buf.sequence = stream->sequence;
++ buf->buf.vb2_buf.timestamp =
++ ktime_to_ns(uvc_video_get_time());
++ }
+ }
+
+ uvc_video_clock_decode(stream, buf, data, len);
+@@ -1221,10 +1234,6 @@ static int uvc_video_decode_start(struct
+ return -ENODATA;
+ }
+
+- buf->buf.field = V4L2_FIELD_NONE;
+- buf->buf.sequence = stream->sequence;
+- buf->buf.vb2_buf.timestamp = ktime_to_ns(uvc_video_get_time());
+-
+ /* TODO: Handle PTS and SCR. */
+ buf->state = UVC_BUF_STATE_ACTIVE;
+ if (meta_buf)
--- /dev/null
+From edc1917599c5339aedc83135cade66517e0a2972 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Wed, 13 May 2026 11:49:20 +0000
+Subject: media: uvcvideo: Fix dev_sof filtering in hw timestamp
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit edc1917599c5339aedc83135cade66517e0a2972 upstream.
+
+To avoid filling the clock circular buffer with duplicated data we only
+add it if the new value sof is different than the last added sof.
+
+The issue is that we compare the unprocess sof with the processed sof.
+If there is a sof_offset, or UVC_QUIRK_INVALID_DEVICE_SOF is enabled,
+the comparison will not work as expected.
+
+This patch moves the comparison to the right place.
+
+Fixes: 141270bd95d4 ("media: uvcvideo: Refactor clock circular buffer")
+Cc: stable@vger.kernel.org
+Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Tested-by: Yunke Cao <yunkec@google.com>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-1-7a64838b0b02@chromium.org
+Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_video.c | 19 ++++++++++---------
+ 1 file changed, 10 insertions(+), 9 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_video.c
++++ b/drivers/media/usb/uvc/uvc_video.c
+@@ -578,16 +578,7 @@ uvc_video_clock_decode(struct uvc_stream
+ if (!has_scr)
+ return;
+
+- /*
+- * To limit the amount of data, drop SCRs with an SOF identical to the
+- * previous one. This filtering is also needed to support UVC 1.5, where
+- * all the data packets of the same frame contains the same SOF. In that
+- * case only the first one will match the host_sof.
+- */
+ sample.dev_sof = get_unaligned_le16(&data[header_size - 2]);
+- if (sample.dev_sof == stream->clock.last_sof)
+- return;
+-
+ sample.dev_stc = get_unaligned_le32(&data[header_size - 6]);
+
+ /*
+@@ -659,6 +650,16 @@ uvc_video_clock_decode(struct uvc_stream
+ }
+
+ sample.dev_sof = (sample.dev_sof + stream->clock.sof_offset) & 2047;
++
++ /*
++ * To limit the amount of data, drop SCRs with an SOF identical to the
++ * previous one. This filtering is also needed to support UVC 1.5, where
++ * all the data packets of the same frame contains the same SOF. In that
++ * case only the first one will match the host_sof.
++ */
++ if (sample.dev_sof == stream->clock.last_sof)
++ return;
++
+ uvc_video_clock_add_sample(&stream->clock, &sample);
+ stream->clock.last_sof = sample.dev_sof;
+ }
--- /dev/null
+From f078966ca1fb1b3865d8e6bbe2705cfd277fc637 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Mon, 23 Mar 2026 09:53:52 +0000
+Subject: media: uvcvideo: Fix sequence number when no EOF
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit f078966ca1fb1b3865d8e6bbe2705cfd277fc637 upstream.
+
+If the driver could not detect the EOF, the sequence number is increased
+twice:
+ 1) When we enter uvc_video_decode_start() with the old buffer and FID has
+ flipped => We return -EAGAIN and last_fid is not flipped
+ 2) When we enter uvc_video_decode_start() with the new buffer.
+
+Fix this issue by moving the new frame detection logic earlier in
+uvc_video_decode_start().
+
+This also has some nice side affects:
+
+- The error status from the new packet will no longer get propagated
+ to the previous frame-buffer.
+- uvc_video_clock_decode() will no longer update the previous frame
+ buf->stf with info from the new packet.
+- uvc_video_clock_decode() and uvc_video_stats_decode() will no longer
+ get called twice for the same packet.
+
+Cc: stable@kernel.org
+Fixes: 650b95feee35 ("[media] uvcvideo: Generate discontinuous sequence numbers when frames are lost")
+Reported-by: Hans de Goede <hansg@kernel.org>
+Closes: https://lore.kernel.org/linux-media/CANiDSCuj4cPuB5_v2xyvAagA5FjoN8V5scXiFFOeD3aKDMqkCg@mail.gmail.com/T/#me39fb134e8c2c085567a31548c3403eb639625e4
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
+Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_video.c | 92 +++++++++++++++++++-------------------
+ 1 file changed, 47 insertions(+), 45 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_video.c
++++ b/drivers/media/usb/uvc/uvc_video.c
+@@ -1192,6 +1192,53 @@ static int uvc_video_decode_start(struct
+ fid = data[1] & UVC_STREAM_FID;
+
+ /*
++ * Mark the buffer as done if we're at the beginning of a new frame.
++ * End of frame detection is better implemented by checking the EOF
++ * bit (FID bit toggling is delayed by one frame compared to the EOF
++ * bit), but some devices don't set the bit at end of frame (and the
++ * last payload can be lost anyway). We thus must check if the FID has
++ * been toggled.
++ *
++ * stream->last_fid is initialized to -1, and buf->bytesused to 0,
++ * so the first isochronous frame will never trigger an end of frame
++ * detection.
++ *
++ * Empty buffers (bytesused == 0) don't trigger end of frame detection
++ * as it doesn't make sense to return an empty buffer. This also
++ * avoids detecting end of frame conditions at FID toggling if the
++ * previous payload had the EOF bit set.
++ */
++ if (fid != stream->last_fid && buf && buf->bytesused != 0) {
++ uvc_dbg(stream->dev, FRAME,
++ "Frame complete (FID bit toggled)\n");
++ buf->state = UVC_BUF_STATE_READY;
++
++ return -EAGAIN;
++ }
++
++ /*
++ * Some cameras, when running two parallel streams (one MJPEG alongside
++ * another non-MJPEG stream), are known to lose the EOF packet for a frame.
++ * We can detect the end of a frame by checking for a new SOI marker, as
++ * the SOI always lies on the packet boundary between two frames for
++ * these devices.
++ */
++ if (stream->dev->quirks & UVC_QUIRK_MJPEG_NO_EOF &&
++ (stream->cur_format->fcc == V4L2_PIX_FMT_MJPEG ||
++ stream->cur_format->fcc == V4L2_PIX_FMT_JPEG) &&
++ buf && buf->bytesused != 0) {
++ const u8 *packet = data + header_len;
++
++ if (len >= header_len + 2 &&
++ packet[0] == 0xff && packet[1] == JPEG_MARKER_SOI) {
++ buf->state = UVC_BUF_STATE_READY;
++ buf->error = 1;
++ stream->last_fid ^= UVC_STREAM_FID;
++ return -EAGAIN;
++ }
++ }
++
++ /*
+ * Increase the sequence number regardless of any buffer states, so
+ * that discontinuous sequence numbers always indicate lost frames.
+ */
+@@ -1258,51 +1305,6 @@ static int uvc_video_decode_start(struct
+ meta_buf->state = UVC_BUF_STATE_ACTIVE;
+ }
+
+- /*
+- * Mark the buffer as done if we're at the beginning of a new frame.
+- * End of frame detection is better implemented by checking the EOF
+- * bit (FID bit toggling is delayed by one frame compared to the EOF
+- * bit), but some devices don't set the bit at end of frame (and the
+- * last payload can be lost anyway). We thus must check if the FID has
+- * been toggled.
+- *
+- * stream->last_fid is initialized to -1, so the first isochronous
+- * frame will never trigger an end of frame detection.
+- *
+- * Empty buffers (bytesused == 0) don't trigger end of frame detection
+- * as it doesn't make sense to return an empty buffer. This also
+- * avoids detecting end of frame conditions at FID toggling if the
+- * previous payload had the EOF bit set.
+- */
+- if (fid != stream->last_fid && buf->bytesused != 0) {
+- uvc_dbg(stream->dev, FRAME,
+- "Frame complete (FID bit toggled)\n");
+- buf->state = UVC_BUF_STATE_READY;
+- return -EAGAIN;
+- }
+-
+- /*
+- * Some cameras, when running two parallel streams (one MJPEG alongside
+- * another non-MJPEG stream), are known to lose the EOF packet for a frame.
+- * We can detect the end of a frame by checking for a new SOI marker, as
+- * the SOI always lies on the packet boundary between two frames for
+- * these devices.
+- */
+- if (stream->dev->quirks & UVC_QUIRK_MJPEG_NO_EOF &&
+- (stream->cur_format->fcc == V4L2_PIX_FMT_MJPEG ||
+- stream->cur_format->fcc == V4L2_PIX_FMT_JPEG)) {
+- const u8 *packet = data + header_len;
+-
+- if (len >= header_len + 2 &&
+- packet[0] == 0xff && packet[1] == JPEG_MARKER_SOI &&
+- buf->bytesused != 0) {
+- buf->state = UVC_BUF_STATE_READY;
+- buf->error = 1;
+- stream->last_fid ^= UVC_STREAM_FID;
+- return -EAGAIN;
+- }
+- }
+-
+ stream->last_fid = fid;
+
+ return header_len;
--- /dev/null
+From 1719d78f832dda8dd3f09a867ba74e05d6f11308 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Wed, 13 May 2026 11:49:22 +0000
+Subject: media: uvcvideo: Relax the constrains for interpolating the hw clock
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit 1719d78f832dda8dd3f09a867ba74e05d6f11308 upstream.
+
+In the initial version we set the min value to 250msec. Looks like
+100msec can also provide a good value.
+
+Now that we are at it, add a macro to make it cleaner.
+
+Fixes: 6243c83be6ee8 ("media: uvcvideo: Allow hw clock updates with buffers not full")
+Cc: stable@vger.kernel.org
+Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Tested-by: Yunke Cao <yunkec@google.com>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-3-7a64838b0b02@chromium.org
+Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_video.c | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_video.c
++++ b/drivers/media/usb/uvc/uvc_video.c
+@@ -489,6 +489,13 @@ static int uvc_commit_video(struct uvc_s
+ * Clocks and timestamps
+ */
+
++/*
++ * The accuracy of the hardware timestamping depends on having enough data to
++ * interpolate between the different clock domains. This value is sof cycles,
++ * this is, milliseconds.
++ */
++#define UVC_MIN_HW_TIMESTAMP_DIFF 100
++
+ static inline ktime_t uvc_video_get_time(void)
+ {
+ if (uvc_clock_param == CLOCK_MONOTONIC)
+@@ -849,13 +856,13 @@ void uvc_video_clock_update(struct uvc_s
+ * buffer, but RAM is expensive these days, specially the infinitely
+ * big.
+ *
+- * The value of 1/4th of a second was determined by running Android's
+- * CTS on different devices.
++ * The value of UVC_MIN_HW_TIMESTAMP_DIFF was determined by running
++ * Android's CTS on different devices.
+ *
+- * dev_sof runs at 1KHz, and we have a fixed point precision of
+- * 16 bits.
++ * y1 and y2 are dev_sof with a fixed point precision of 16 bits.
+ */
+- if (clock->size != clock->count && (y2 - y1) < ((1000 / 4) << 16))
++ if (clock->size != clock->count &&
++ (y2 - y1) < (UVC_MIN_HW_TIMESTAMP_DIFF << 16))
+ goto done;
+
+ y = (u64)(y2 - y1) * (1ULL << 31) + (u64)y1 * (u64)x2
--- /dev/null
+From ede7de6e6b3db552d10ac50557d69c50d1b08486 Mon Sep 17 00:00:00 2001
+From: Ricardo Ribalda <ribalda@chromium.org>
+Date: Wed, 13 May 2026 11:49:21 +0000
+Subject: media: uvcvideo: Use hw timestaming if the clock buffer is full
+
+From: Ricardo Ribalda <ribalda@chromium.org>
+
+commit ede7de6e6b3db552d10ac50557d69c50d1b08486 upstream.
+
+In some situations, even with a full clock buffer, it does not contain
+250msec of data. This results in the driver jumping back from software
+to hardware timestapsing creating a nasty artifact in the video.
+
+If the clock buffer is full, use it to calculate the timestamp instead
+of defaulting to software stamps, the reduced accuracy is less visible
+than jumping from one timestamping mechanism to the other.
+
+Fixes: 6243c83be6ee8 ("media: uvcvideo: Allow hw clock updates with buffers not full")
+Cc: stable@vger.kernel.org
+Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Tested-by: Yunke Cao <yunkec@google.com>
+Signed-off-by: Ricardo Ribalda <ribalda@chromium.org>
+Link: https://patch.msgid.link/20260513-uvc-hwtimestamp-v3-2-7a64838b0b02@chromium.org
+Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
+Signed-off-by: Hans Verkuil <hverkuil+cisco@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/media/usb/uvc/uvc_video.c | 17 ++++++++++++-----
+ 1 file changed, 12 insertions(+), 5 deletions(-)
+
+--- a/drivers/media/usb/uvc/uvc_video.c
++++ b/drivers/media/usb/uvc/uvc_video.c
+@@ -829,15 +829,22 @@ void uvc_video_clock_update(struct uvc_s
+ y2 += 2048 << 16;
+
+ /*
+- * Have at least 1/4 of a second of timestamps before we
+- * try to do any calculation. Otherwise we do not have enough
+- * precision. This value was determined by running Android CTS
+- * on different devices.
++ * If the buffer is not full, we want to gather at least 1/4th of
++ * timestamps before using HW timestamping. We do this to avoid jitter
++ * on the initial frames.
++ *
++ * If the buffer is full we would use it regardless of how much data
++ * it represents. This could be solved with an infinite big circular
++ * buffer, but RAM is expensive these days, specially the infinitely
++ * big.
++ *
++ * The value of 1/4th of a second was determined by running Android's
++ * CTS on different devices.
+ *
+ * dev_sof runs at 1KHz, and we have a fixed point precision of
+ * 16 bits.
+ */
+- if ((y2 - y1) < ((1000 / 4) << 16))
++ if (clock->size != clock->count && (y2 - y1) < ((1000 / 4) << 16))
+ goto done;
+
+ y = (u64)(y2 - y1) * (1ULL << 31) + (u64)y1 * (u64)x2
--- /dev/null
+From 4bdb9e471f5b1ac9cbe4add5de7ff085a0ec303c Mon Sep 17 00:00:00 2001
+From: David Howells <dhowells@redhat.com>
+Date: Wed, 24 Jun 2026 17:38:17 +0100
+Subject: rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)
+
+From: David Howells <dhowells@redhat.com>
+
+commit 4bdb9e471f5b1ac9cbe4add5de7ff085a0ec303c upstream.
+
+Fix rxrpc_recvmsg() to also drop the ref it holds on an already-released
+call if MSG_PEEK is in force (the function holds a ref on the call
+irrespective of whether MSG_PEEK is specified or not).
+
+Fixes: 962fb1f651c2 ("rxrpc: Fix recv-recv race of completed call")
+Link: https://sashiko.dev/#/patchset/20260616155749.2125907-1-dhowells%40redhat.com
+Signed-off-by: David Howells <dhowells@redhat.com>
+cc: Marc Dionne <marc.dionne@auristor.com>
+cc: Jeffrey Altman <jaltman@auristor.com>
+cc: Simon Horman <horms@kernel.org>
+cc: linux-afs@lists.infradead.org
+cc: stable@kernel.org
+Link: https://patch.msgid.link/20260624163819.3017002-11-dhowells@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/rxrpc/recvmsg.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/net/rxrpc/recvmsg.c
++++ b/net/rxrpc/recvmsg.c
+@@ -429,8 +429,7 @@ try_again:
+ if (test_bit(RXRPC_CALL_RELEASED, &call->flags)) {
+ rxrpc_see_call(call, rxrpc_call_see_already_released);
+ mutex_unlock(&call->user_mutex);
+- if (!(flags & MSG_PEEK))
+- rxrpc_put_call(call, rxrpc_call_put_recvmsg);
++ rxrpc_put_call(call, rxrpc_call_put_recvmsg);
+ goto try_again;
+ }
+
--- /dev/null
+From 16c8ae9735c5bd7e54dd7478d6348e0fc860842d Mon Sep 17 00:00:00 2001
+From: Jeffrey Altman <jaltman@auristor.com>
+Date: Tue, 9 Jun 2026 15:09:05 +0100
+Subject: rxrpc: rxrpc_verify_data ensure rx_dec_buffer alloc
+
+From: Jeffrey Altman <jaltman@auristor.com>
+
+commit 16c8ae9735c5bd7e54dd7478d6348e0fc860842d upstream.
+
+rxrpc_recvmsg_data() calls rxrpc_verify_data() whenever the
+rxrpc_call.rx_dec_buffer is unallocated and assumes that upon
+successful return that rx_dec_buffer must be allocated.
+However, rxrpc_verify_data() does not request an allocation if
+the rxrpc_skb_priv.len is zero.
+
+In addition, failure to allocate rx_dec_buffer will result in a
+call to skb_copy_bits() with a NULL destination which can
+trigger a NULL pointer dereference.
+
+To prevent these issues rxrpc_verify_data() is modified to
+always attempt to allocate the rxrpc_call.rx_dec_buffer if it
+is NULL.
+
+This issue was identified with assistance of a private
+sashiko instance.
+
+Fixes: d2bc90cf6c75cb ("rxrpc: Fix DATA decrypt vs splice() by copying data to buffer in recvmsg")
+Reported-by: Simon Horman <simon.horman@redhat.com>
+Signed-off-by: Jeffrey Altman <jaltman@auristor.com>
+Signed-off-by: David Howells <dhowells@redhat.com>
+cc: Jiayuan Chen <jiayuan.chen@linux.dev>
+cc: Marc Dionne <marc.dionne@auristor.com>
+cc: linux-afs@lists.infradead.org
+cc: stable@kernel.org
+Link: https://patch.msgid.link/20260609140911.838677-2-dhowells@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/rxrpc/recvmsg.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/net/rxrpc/recvmsg.c
++++ b/net/rxrpc/recvmsg.c
+@@ -157,7 +157,7 @@ static int rxrpc_verify_data(struct rxrp
+ struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
+ int ret;
+
+- if (sp->len > call->rx_dec_bsize) {
++ if (sp->len > call->rx_dec_bsize || !call->rx_dec_buffer) {
+ /* Make sure we can hold a 1412-byte jumbo subpacket and make
+ * sure that the buffer size is aligned to a crypto blocksize.
+ */
--- /dev/null
+From 061b627ba534230a18ec4d7251562af12325d06a Mon Sep 17 00:00:00 2001
+From: Matthias Feser <mfe@KBSgmbhfr.onmicrosoft.com>
+Date: Tue, 26 May 2026 07:35:09 +0000
+Subject: serial: 8250_omap: clear rx_running on zero-length DMA completes
+
+From: Matthias Feser <mfe@KBSgmbhfr.onmicrosoft.com>
+
+commit 061b627ba534230a18ec4d7251562af12325d06a upstream.
+
+On AM33xx RX DMA only triggers when the FIFO reaches the
+configured threshold (typically 48 bytes). For smaller bursts
+no DMA request is issued and the FIFO is drained by RX timeout.
+
+In this case __dma_rx_do_complete() can legitimately see count == 0.
+
+The current code exits early in this case and does not clear
+dma->rx_running, leaving the DMA state inconsistent. This can
+prevent RX DMA from restarting and may cause
+omap_8250_rx_dma_flush() to fail, marking DMA as broken.
+
+Fix this by clearing dma->rx_running once the DMA transfer has
+completed or been terminated, even if no data was transferred.
+
+Fixes: a5fd8945a478 ("serial: 8250: 8250_omap.c: Clear DMA RX running status only after DMA termination is done")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Matthias Feser <mfe@KBSgmbhfr.onmicrosoft.com>
+Reviewed-by: Moteen Shah <m-shah@ti.com>
+Link: https://patch.msgid.link/BE3P281MB55155F2F5795E411F5A65282EE0B2@BE3P281MB5515.DEUP281.PROD.OUTLOOK.COM
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/8250/8250_omap.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/8250/8250_omap.c
++++ b/drivers/tty/serial/8250/8250_omap.c
+@@ -965,11 +965,12 @@ static void __dma_rx_do_complete(struct
+ dev_err(p->port.dev, "teardown incomplete\n");
+ }
+ }
++
++ dma->rx_running = 0;
+ if (!count)
+ goto out;
+ ret = tty_insert_flip_string(tty_port, dma->rx_buf, count);
+
+- dma->rx_running = 0;
+ p->port.icount.rx += ret;
+ p->port.icount.buf_overrun += count - ret;
+ out:
--- /dev/null
+From a483b1a91b33b7533280e7c3efd2bc1275caef18 Mon Sep 17 00:00:00 2001
+From: Tapio Reijonen <tapio.reijonen@vaisala.com>
+Date: Mon, 15 Jun 2026 06:38:40 +0000
+Subject: serial: max310x: implement gpio_chip::get_direction()
+
+From: Tapio Reijonen <tapio.reijonen@vaisala.com>
+
+commit a483b1a91b33b7533280e7c3efd2bc1275caef18 upstream.
+
+It's strongly recommended for GPIO drivers to always implement the
+.get_direction() callback - even when the direction is tracked in
+software. The GPIO core emits a warning when the callback is missing
+and a user reads the direction of a line, e.g. via
+/sys/kernel/debug/gpio.
+
+The MAX310X keeps the GPIO direction in the GPIOCFG register (a set bit
+selects output), which the existing direction_input/output callbacks
+already program, so the current direction can be read back directly.
+
+Fixes: f65444187a66 ("serial: New serial driver MAX310X")
+Cc: stable <stable@kernel.org>
+Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
+Reviewed-by: Linus Walleij <linusw@kernel.org>
+Reviewed-by: Bartosz Golaszewski <bartosz.golaszewski@oss.qualcomm.com>
+Reviewed-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
+Link: https://patch.msgid.link/20260615-b4-serial-max310x-gpio-get-direction-v2-1-4704ba2b181a@vaisala.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/max310x.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+--- a/drivers/tty/serial/max310x.c
++++ b/drivers/tty/serial/max310x.c
+@@ -1198,6 +1198,17 @@ static void max310x_gpio_set(struct gpio
+ value ? 1 << (offset % 4) : 0);
+ }
+
++static int max310x_gpio_get_direction(struct gpio_chip *chip, unsigned int offset)
++{
++ struct max310x_port *s = gpiochip_get_data(chip);
++ struct uart_port *port = &s->p[offset / 4].port;
++ unsigned int val;
++
++ val = max310x_port_read(port, MAX310X_GPIOCFG_REG);
++
++ return val & BIT(offset % 4) ? GPIO_LINE_DIRECTION_OUT : GPIO_LINE_DIRECTION_IN;
++}
++
+ static int max310x_gpio_direction_input(struct gpio_chip *chip, unsigned int offset)
+ {
+ struct max310x_port *s = gpiochip_get_data(chip);
+@@ -1407,6 +1418,7 @@ static int max310x_probe(struct device *
+ s->gpio.owner = THIS_MODULE;
+ s->gpio.parent = dev;
+ s->gpio.label = devtype->name;
++ s->gpio.get_direction = max310x_gpio_get_direction;
+ s->gpio.direction_input = max310x_gpio_direction_input;
+ s->gpio.get = max310x_gpio_get;
+ s->gpio.direction_output= max310x_gpio_direction_output;
--- /dev/null
+From 22dd2777e6c180e1c945b00f6d18550979436324 Mon Sep 17 00:00:00 2001
+From: Stephan Gerhold <stephan.gerhold@linaro.org>
+Date: Mon, 6 Jul 2026 20:03:32 +0200
+Subject: serial: msm: Disable DMA for kernel console UART
+
+From: Stephan Gerhold <stephan.gerhold@linaro.org>
+
+commit 22dd2777e6c180e1c945b00f6d18550979436324 upstream.
+
+At the moment, concurrent writes from userspace and the kernel to the
+console can trigger a race condition that results in an infinite loop of
+the same messages printed over and over again. This is most likely to
+happen during system startup or shutdown when the init system starts/stops
+a large number of system services that interact with various kernel code.
+
+When userspace writes to the TTY device, the driver initiates an
+asynchronous DMA transfer and releases the port lock. At the same moment,
+the kernel printk path might grab the port lock and re-configure the UART
+controller for PIO, without waiting for the DMA operation to complete. It
+seems like this collision results in zero progress being reported for the
+DMA engine, so the same text is printed to the console over and over again.
+
+For the kernel console, we want a reliable output path that will be
+functional even during crashes etc. So rather than implementing complex
+code to synchronize the kernel console write routines with the userspace
+DMA write routines, simply disable DMA for the console UART instance.
+
+Similar checks exist in many other serial drivers, e.g. 8250_port.c,
+imx.c, sh-sci.c etc.
+
+Cc: stable <stable@kernel.org>
+Fixes: 3a878c430fd6 ("tty: serial: msm: Add TX DMA support")
+Signed-off-by: Stephan Gerhold <stephan.gerhold@linaro.org>
+Acked-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260706-serial-msm-console-dma-collision-v1-1-3179b8cb1d89@linaro.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/tty/serial/msm_serial.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/tty/serial/msm_serial.c
++++ b/drivers/tty/serial/msm_serial.c
+@@ -1228,7 +1228,8 @@ static int msm_startup(struct uart_port
+ data |= MSM_UART_MR1_AUTO_RFR_LEVEL0 & rfr_level;
+ msm_write(port, data, MSM_UART_MR1);
+
+- if (msm_port->is_uartdm) {
++ /* Disable DMA for console to prevent PIO/DMA collisions */
++ if (msm_port->is_uartdm && !uart_console(port)) {
+ msm_request_tx_dma(msm_port, msm_port->uart.mapbase);
+ msm_request_rx_dma(msm_port, msm_port->uart.mapbase);
+ }
crypto-hisi-trng-remove-crypto_rng-interface.patch
time-jiffies-register-jiffies-clocksource-before-usa.patch
time-jiffies-change-register_refined_jiffies-to-void.patch
+media-uvcvideo-use-hw-timestaming-if-the-clock-buffer-is-full.patch
+media-uvcvideo-avoid-partial-metadata-buffers.patch
+media-uvcvideo-fix-buffer-sequence-in-frame-gaps.patch
+media-uvcvideo-fix-dev_sof-filtering-in-hw-timestamp.patch
+media-uvcvideo-do-not-add-clock-samples-with-small-sof-delta.patch
+media-uvcvideo-relax-the-constrains-for-interpolating-the-hw-clock.patch
+media-uvcvideo-fix-sequence-number-when-no-eof.patch
+dt-bindings-media-sun4i-a10-video-engine-add-interconnect-properties.patch
+dt-bindings-power-imx93-add-mipi-phy-power-domain.patch
+serial-msm-disable-dma-for-kernel-console-uart.patch
+serial-max310x-implement-gpio_chip-get_direction.patch
+serial-8250_omap-clear-rx_running-on-zero-length-dma-completes.patch
+rxrpc-rxrpc_verify_data-ensure-rx_dec_buffer-alloc.patch
+rxrpc-fix-leak-of-released-call-in-recvmsg-msg_peek.patch
+afs-fix-netns-teardown-to-cancel-the-preallocation-charger.patch
+afs-fix-null-pointer-dereference-in-afs_get_tree.patch
+afs-fix-further-netns-teardown-to-cancel-the-preallocation-charger.patch
+fbcon-fix-null-pointer-dereference-for-a-console-without-vc_data.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
