Skip to content

Merge tag 'v6.18.52' into qcom-6.18.y - #1158

Open
nsiddams (nsiddams) wants to merge 3233 commits into
qualcomm-linux:qcom-6.18.yfrom
nsiddams:6.18.52-lts
Open

nsiddams (nsiddams) wants to merge 3233 commits into
qualcomm-linux:qcom-6.18.yfrom
nsiddams:6.18.52-lts

Conversation

@nsiddams

@nsiddams nsiddams (nsiddams) commented Sep 22, 2026 •

Copy link
Copy Markdown

CR:4702380

Ruoyu Wang (Ryuwang3) and others added 30 commits September 14, 2026 13:36
[ Upstream commit 7b196e2 ]

mv88e6352_pcs_link_check() ignores errors returned by
port_get_cmode(). If the port status register read fails,
mv88e6352_port_get_cmode() returns without setting cmode. The link check
then compares an uninitialized value and may incorrectly treat the PCS
as active.

Save the return value and fail the link check after releasing the
register lock. marvell_c22_pcs_get_state() initializes the reported link
state to down before calling the check, so a read failure is handled
safely until a later poll succeeds.

This issue was found by a static analysis checker and confirmed by manual
source review.

Fixes: 8576455 ("net: dsa: mv88e6xxx: convert 88e6352 to phylink_pcs")
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Reviewed-by: Vladimir Oltean <olteanv@gmail.com>
Link: https://patch.msgid.link/20260813153131.3952970-1-ruoyuw560@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9466ef3 ]

The TCP receive queue can hold adjacent skbs whose sequence ranges
overlap. The tls fast-path reads the record header with skb_copy_bits()
by byte offset, which assumes skbs do not overlap, so a header split
across the overlap is misread and the connection aborts
(-EMSGSIZE/-EINVAL). tls_strp_check_queue_ok() detects such overlaps but
only ran after the header was parsed, never covering the header itself.

Observed with parallel kTLS connections on:
- ConnectX-7 + IPsec crypto offload + GRO
- VirtIO (8 queues) + GRO

Fixes: 84c61fe ("tls: rx: do not use the standard strparser")
Signed-off-by: Maximilian Immanuel Brandtner <maxbr@linux.ibm.com>
Link: https://patch.msgid.link/20260813121337.3300688-1-maxbr@linux.ibm.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 21040c7 ]

A notification should be emitted only when the vlan delete was successful
and not otherwise. The proper check is if br/nbp_vlan_delete returned 0.

Fixes: f545923 ("net: bridge: vlan: notify on vlan add/delete/change flags")
Signed-off-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260814141640.64958-1-razor@blackwall.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 4deb3ed ]

Since commit 053fc4f ("fuse: fix UAF in rcu pathwalks"),
fuse_conn_put() frees the fuse_conn through call_rcu() rather than
synchronously.  For cuse, fc->release is cuse_fc_release(), which
lives in the cuse module.  If the module is removed before the RCU
grace period ends, the callback jumps into freed module memory:

      userspace / module unload      |        RCU softirq
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 close(/dev/cuse)                    |
  cuse_channel_release()             |
   fuse_dev_release()                |
    fuse_conn_put(fch->conn)         |
     call_rcu(delayed_release) ------+---> callback queued
                                     |
 rmmod cuse                          |
  cuse_exit()                        |
   cuse_channel_destroy()            |
   ...                               |
   return                            |
                                     |
 <module text freed>                 |
                                     |  rcu_do_batch()
                                     |   delayed_release()
                                     |    fc->release()
                                     |     -> cuse_fc_release()
                                     |        ^^^ freed text!

The freed module text is unmapped by vfree(), so the jump into the
stale callback triggers a page-fault Oops.  If the virtual address
is subsequently reused, the callback could execute unrelated code
(undefined behaviour).

Fix this by calling rcu_barrier() in cuse_exit() so that any pending
fuse_conn release callback completes before the module is removed.

Fixes: 053fc4f ("fuse: fix UAF in rcu pathwalks")
Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit de603b9 ]

read_log_rec_buf() copies a log record into a caller buffer starting at

	u32 off = lsn_to_page_off(log, lsn) + log->record_header_len;

log->record_header_len (and log->data_off, used for the following pages)
comes verbatim from the on-disk restart area and is only checked for
8-byte alignment in is_rst_area_valid(), so off can exceed
log->page_size. "tail = log->page_size - off" then underflows and
memcpy() reads past the page_size-sized buffer returned by
read_log_page(), spilling adjacent slab memory into the replay buffer.

This is reachable by mounting a crafted NTFS image:

 BUG: KASAN: slab-out-of-bounds in read_log_rec_buf+0x216/0x580
 Read of size 64 at addr ffff88800a877ff8 by task exploit/127
  read_log_rec_buf fs/ntfs3/fslog.c:2299
  log_replay fs/ntfs3/fslog.c:4216
  ntfs_loadlog_and_replay fs/ntfs3/fsntfs.c:324
  ntfs_fill_super fs/ntfs3/super.c:1392
  get_tree_bdev_flags fs/super.c:1694
  __x64_sys_mount fs/namespace.c:4360
 The buggy address is located 4088 bytes to the right of
 the 4096-byte region [ffff88800a876000, ffff88800a877000)

Reject an in-page offset outside the current page before the copy.

Fixes: b46acd6 ("fs/ntfs3: Add NTFS journal")
Assisted-by: Claude:claude-opus-4-8
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
[almaz.alexandrovich@paragon-software.com: replaced the >= sign with >]
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c22f91d ]

When an EA record has a non-zero ef->size, ntfs_read_ea() only checks
that the record fits in the remaining buffer (ea_size > bytes), not that
ef->size is large enough to hold the record's own name_len + 1 + elength.

A crafted image can pass validation with, e.g., ef->size = 24 but
elength = 0xffff. ntfs_get_ea() then trusts elength and copies it out of
the undersized record, reading past the kmalloc(info->size) allocation
and leaking heap memory to userspace via getxattr():

 BUG: KASAN: slab-out-of-bounds in ntfs_get_ea (fs/ntfs3/xattr.c:302)
 Read of size 65535 at addr ffff888100794550 by task exploit
  __asan_memcpy (mm/kasan/shadow.c:105)
  ntfs_get_ea (fs/ntfs3/xattr.c:302)
  ntfs_getxattr (fs/ntfs3/xattr.c:848)
  __vfs_getxattr (fs/xattr.c:441)
  vfs_getxattr (fs/xattr.c:474)
  do_getxattr (fs/xattr.c:800)
  path_getxattrat (fs/xattr.c:868)
  do_syscall_64 (arch/x86/entry/syscall_64.c:94)

 The buggy address is located 80 bytes inside of
  allocated 84-byte region in cache kmalloc-96

Compute the size the record needs and require ef->size to cover it.

Fixes: 0e8235d ("fs/ntfs3: Check fields while reading")
Reported-by: Xiang Mei <xmei5@asu.edu>
Assisted-by: Claude:claude-opus-4-8
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c6441be ]

When CONFIG_QCOM_UBWC_CONFIG=n, compiler needs to know the definition
of ERR_PTR otherwise there will be a compilation error:

In file included from drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp_v13.c:7:
./include/linux/soc/qcom/ubwc.h: In function ‘qcom_ubwc_config_get_data’:
./include/linux/soc/qcom/ubwc.h:45:16: error: implicit declaration of
function ‘ERR_PTR’ [-Wimplicit-function-declaration]

Fix this by including <linux/err.h>

Fixes: 1924272 ("soc: qcom: Add UBWC config provider")
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Daniel Baluta <daniel.baluta@nxp.com>
Tested-by: Nathan Chancellor <nathan@kernel.org> # build
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 928f659 ]

fuse_iget() can return NULL when its inode allocation fails, but
fuse_fill_super_submount() passed the result straight to get_fuse_inode()
and decremented fi->nlookup without checking it:

        root = fuse_iget(sb, parent_fi->nodeid, ...);
        fi = get_fuse_inode(root);
        fi->nlookup--;

Inside fuse_iget() the inode allocation can fail and return NULL.  The
submount root takes the iget5_locked() path, whose alloc_inode() can fail
under memory pressure (the auto-submount branch can fail the same way in
new_inode() or fuse_alloc_submount_lookup()):

        inode = iget5_locked(sb, nodeid, fuse_inode_eq, fuse_inode_set,
                             &nodeid);
        if (!inode)
                return NULL;

A NULL root makes get_fuse_inode() a container_of() on NULL and the
nlookup decrement a write to a bogus address, oopsing the mount.  With
CONFIG_KASAN the following null pointer dereference is reported when the
root inode allocation of an auto-submount fails (e.g. under memory
pressure):

==================================================================
BUG: KASAN: null-ptr-deref in fuse_get_tree_submount+0x656/0x8b0
Read of size 8 at addr 00000000000002b0 by task ls/942
CPU: 0 PID: 942 Comm: ls Tainted: G W 6.6 qualcomm-linux#15
Call Trace:
 <TASK>
 fuse_get_tree_submount+0x656/0x8b0
 vfs_get_tree+0x48/0x140
 fc_mount+0x13/0x50
 fuse_dentry_automount+0x7a/0xb0
 __traverse_mounts+0xca/0x330
 step_into+0x339/0xac0
 path_lookupat+0xc5/0x2f0
 filename_lookup+0x163/0x2a0
 vfs_statx+0xd5/0x200
 do_statx+0x83/0xd0
 __x64_sys_statx+0xa0/0xc0
 do_syscall_64+0x37/0x90
 entry_SYSCALL_64_after_hwframe+0x78/0xe2
 </TASK>
==================================================================

Return -ENOMEM instead; the caller tears down the partially built
superblock on error, matching the other error returns in this
function.

Fixes: 1866d77 ("fuse: Allow fuse_fill_super_common() for submounts")
Signed-off-by: Baokun Li <libaokun@linux.alibaba.com>
Reviewed-by: Jingbo Xu <jefflexu@linux.alibaba.com>
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit c139e7e ]

print_conn_list() compares the raw hardware connection list with the
connection list cached by the HDA driver.  When they differ, it prints an
additional "In-driver Connection" line so that /proc/asound/card*/codec#*
shows the topology actually used by the driver.

The comparison currently passes conn_len directly to memcmp().  However,
conn_len is a number of connection-list entries, while memcmp() expects a
size in bytes.  Both list and conn are arrays of hda_nid_t, which is u16,
so only half of the connection data is compared.

For example, for two-entry lists such as:

  hardware: 0x0c 0x0d
  cached:   0x0c 0x0e

conn_len is 2, and the current comparison checks only the first hda_nid_t.
The lists are therefore incorrectly treated as identical even though the
second connection differs.

This can happen legitimately when codec fixups replace a cached connection
list with snd_hda_override_conn_list().  The codec routing used by the
driver is not affected, but the proc output can hide the overridden
driver-visible routing and provide misleading topology information during
codec debugging.

Convert the entry count to a byte size so that memcmp() covers the
complete connection list.

Fixes: 8b2c7a5 ("ALSA: hda - Add In-driver connection info")
Signed-off-by: Xu Rao <raoxu@uniontech.com>
Link: https://patch.msgid.link/7B802A4E225CC808+20260818083808.2735120-1-raoxu@uniontech.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit bc2dc66 ]

vxlan_mdb_flush() iterates over the MDB entries using
hlist_for_each_entry_safe(), which only tolerates the removal of the
current entry. Contrary to the comment above the loop, the removal of an
entry can trigger the removal of another entry.

Flushing the remotes of a (*, G) entry also removes the (S, G) entries
that were created for its source list, once they are left without
remotes:

vxlan_mdb_remotes_flush()
-> vxlan_mdb_remote_del()
   -> vxlan_mdb_remote_srcs_del()
      -> vxlan_mdb_remote_src_del()
         -> vxlan_mdb_remote_src_fwd_del()
            -> __vxlan_mdb_del()
               -> vxlan_mdb_entry_put()

Such an entry can be located after the (*, G) entry in the list, as
vxlan_mdb_entry_get() returns an existing entry without moving it to the
head of the list. This order is obtained by adding the (S, G) entry
before the (*, G) entry, the latter with NLM_F_REPLACE, as the addition
of the source otherwise fails with -EEXIST. The (S, G) entry is then the
entry saved by hlist_for_each_entry_safe() and it is freed while the
(*, G) entry is processed. The next iteration calls hlist_del() on it
again, writing LIST_POISON1 to LIST_POISON2 [1].

Besides device deletion, the flush is also reachable from RTM_DELMDB
with NLM_F_BULK.

Fix by re-reading the next entry after the remotes were flushed. The
current entry cannot be removed by this flush, as source lists can only
be configured on (*, G) entries and the removed entries are (S, G)
entries. It is therefore still linked and its next pointer reflects the
removals.

[1]
BUG: KASAN: wild-memory-access in vxlan_mdb_entry_put.part.0+0x328/0x588
Write of size 8 at addr dead000000000122 by task ip/327

CPU: 3 UID: 1000 PID: 327 Comm: ip Not tainted 7.2.0-rc7 qualcomm-linux#2 PREEMPT
Call trace:
 vxlan_mdb_entry_put.part.0+0x328/0x588
 vxlan_mdb_flush+0x1d8/0x25c
 vxlan_mdb_fini+0x8c/0x100
 vxlan_uninit+0x1c/0x7c
 unregister_netdevice_many_notify+0x954/0xd4c
 rtnl_dellink+0x210/0x530
 rtnetlink_rcv_msg+0x434/0x4d0
 netlink_rcv_skb+0xc4/0x204
 rtnetlink_rcv+0x18/0x24
 netlink_unicast+0x4b8/0x548
 netlink_sendmsg+0x29c/0x560
 ____sys_sendmsg+0x390/0x3ec
 ___sys_sendmsg+0x114/0x188
 __sys_sendmsg+0xf0/0x178
 __arm64_sys_sendmsg+0x48/0x60
 invoke_syscall.constprop.0+0x58/0x180
 el0_svc_common.constprop.0+0x74/0x140
 do_el0_svc+0x30/0x40
 el0_svc+0x38/0x98
 el0t_64_sync_handler+0xa0/0xe4
 el0t_64_sync+0x198/0x19c

Fixes: a3a48de ("vxlan: mdb: Add MDB control path support")
Signed-off-by: Baul Lee <baul.lee@xbow.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260814153547.29567-1-baul.lee@xbow.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit cb7643b ]

On QEMU rtl8139 model, frames that arrive while the interface is
suspended still end up in the stack after resume. With pm_test=devices,
which keeps devices suspended for 5s, 200 frames sent to interface
during that time and 50 frames after resume, eth0 reports 113
received frames.

cp_suspend() is supposed to stop receiver and the transmitter, but
the mask is wrong: (~RxOn | ~TxOn) is ~0, nothing is cleared and Cmd
still reads 0x0d when cp_suspend() returns.

Use ~(RxOn | TxOn) so both bits are actually cleared.

Fixes: 1da177e ("Linux-2.6.12-rc2")
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20260817043057.20099-1-kmehltretter@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8acf691 ]

smc_sk_init() calls sk->sk_prot->hash(sk) before several fields are
fully initialised: clcsock_release_lock, the saved clcsk_* callbacks,
use_fallback/fallback_rsn, and conn.close_work.  Once hash() returns the
socket is visible to concurrent hash walkers, which can then observe
uninitialised state.

Move hash(sk) to the end of smc_sk_init() so the socket is published
only after it is fully constructed.

Fixes: d0e3565 ("net/smc: refactoring initialization of smc sock")
Reviewed-by: Hidayath Khan <hidayath@linux.ibm.com>
Reviewed-by: Sidraya Jayagond <sidraya@linux.ibm.com>
Signed-off-by: Mahanta Jambigi <mjambigi@linux.ibm.com>
Link: https://patch.msgid.link/20260813074315.554926-1-mjambigi@linux.ibm.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 5ab078e ]

The get_instance_id() macro walks the per-type attribute array with
'i <= instances_count'.  Each array is allocated with exactly
instances_count entries, so the valid range is [0, instances_count)
and the last iteration reads one element past the end.  On a name miss
that out-of-bounds attribute_name is handed to strcmp(), which reads on
until it finds a NUL byte.

Every kobject in these ksets is built from an entry that was populated,
so a miss does not look reachable from sysfs today.  The bound is wrong
either way and the read is out of bounds.

The matching macro in hp-bioscfg carried the same off-by-one and was
corrected by commit 2515071 ("platform/x86: hp-bioscfg: Fix kernel
panic in GET_INSTANCE_ID macro").  That macro takes a kobject pointer
out of the out-of-bounds element and dereferences it, so it could fault.
This one reads a char array.

Use '<' to match the allocation.

Fixes: e8a60aa ("platform/x86: Introduce support for Systems Management Driver over WMI for Dell Systems")
Assisted-by: Claude:claude-opus-5
Signed-off-by: HyeongJun An <sammiee5311@gmail.com>
Link: https://patch.msgid.link/20260814132535.4169956-1-sammiee5311@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 98f28d8 ]

A common pattern in epoll network servers is to eagerly accept all
pending connections from the non-blocking listening socket after
epoll_wait indicates the socket is ready by calling accept in a loop
until EAGAIN is returned indicating that the backlog is empty.

Scheduling a timeout for a non-blocking accept with an empty backlog
meant AF_VSOCK sockets used by epoll network servers incurred hundreds
of microseconds of additional latency per accept loop compared to
AF_INET or AF_UNIX sockets.

Signed-off-by: Laurence Rowe <laurencerowe@gmail.com>
Reviewed-by: Bobby Eshleman <bobbyeshleman@meta.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20260402204918.130395-1-laurencerowe@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Stable-dep-of: b8c899c ("vsock: don't check the listener's sk_err in vsock_accept()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b8c899c ]

Syzbot reported an issue which can be reproduced with these steps:
	r0 = socket(AF_VSOCK, SOCK_STREAM, 0)
	bind(r0, {VMADDR_CID_ANY, PORT})
	connect(r0, {VMADDR_CID_LOCAL, PORT}) -> -1, EPROTO (self-connect)
	listen(r0, backlog)                   -> 0
	r1 = socket(AF_VSOCK, SOCK_STREAM, 0)
	connect(r1, {VMADDR_CID_LOCAL, PORT}) -> 0
	accept(r0)                            -> -1, EPROTO (stale sk_err)

Basically, it creates a socket (r0) and triggers a self-connect after
binding it. This self-connect fails with EPROTO because it loops back
to r0 while the socket is still in the TCP_SYN_SENT state, causing it
to be incorrectly dispatched to the connecting-client path. The
unexpected packet type encountered there sets sk_err to EPROTO.

After that, it invokes a listen() call on the same socket. This
listen() call succeeds because the kernel's listening path never
inspects or clears sk_err. Then, a new socket (r1) is created as a
normal client and connects to r0. However, vsock_accept() rejects this
incoming connection because the listener's sk_err still holds the
EPROTO error from the earlier failed self-connect.

This rejection causes the child socket created for r1's connection to
never be freed on virtio or hyperv transports; only the VMCI transport
implements pending_work to revisit and clean up a rejected socket.

For a non-blocking connect(), vsock_connect() may return -EINPROGRESS
immediately, and vsock_connect_timeout() can later set sk->sk_err
asynchronously.

Since no vsock transport ever sets sk_err on a socket while it is in
TCP_LISTEN state, checking it in vsock_accept() serves no purpose and
only carries forward errors left behind by earlier, unrelated
connection attempts on the same socket. Remove the checks so accept()
no longer rejects valid incoming connections because of a stale
error, which also avoids the resource leak described above.

Fixes: d021c34 ("VSOCK: Introduce VM Sockets")
Reported-by: syzbot+1b2c9c4a0f8708082678@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=1b2c9c4a0f8708082678
Suggested-by: Michal Luczaj <mhal@rbox.co>
Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Link: https://patch.msgid.link/20260813173024.2362935-2-phind.uet@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 96cbf89 ]

vsock_connect() returns sk_err to userspace but does not clear it:
  if (sk->sk_err) {
            err = -sk->sk_err;

For a blocking connect() the error has already been delivered as
connect()'s return value, so leaving it set causes subsequent operations
like poll()/epoll() to keep reporting POLLERR even though the connect
failure was already delivered.

The error should be consumed once it has been returned to userspace.
Switch to sock_error(), which reads and clears sk_err atomically,
matching the behavior of other protocol implementations such as
__inet_stream_connect().

Fixes: d021c34 ("VSOCK: Introduce VM Sockets")
Tested-by: Wupeng Ma <mawupeng1@huawei.com>
Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
Signed-off-by: Nguyen Dinh Phi <phind.uet@gmail.com>
Link: https://patch.msgid.link/20260813173024.2362935-4-phind.uet@gmail.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e213939 ]

The password PSWD_ENCODINGS parser reads password_obj[elem + pos_values]
while copying the supported password encodings from the ACPI package.

The outer loop only guarantees that elem is within password_obj_count.
The encoding count is bounded by MAX_ENCODINGS_SIZE, but that does not
guarantee that the ACPI package contains enough entries for all
elem + pos_values accesses.

A malformed package can therefore declare a non-zero encoding count
without providing enough string objects, causing the parser to read past
the ACPI package array and pass an out-of-bounds string pointer and
length to hp_convert_hexstr_to_str().

Add the same computed-index bounds check used by the other offset-based
package parsing loops before reading password_obj[elem + pos_values].

Fixes: 8646a3b ("platform/x86: hp-bioscfg: passwdobj-attributes")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
Link: https://patch.msgid.link/20260708090937.740435-1-lgs201920130244@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3921bb8 ]

hsmp_hwmon_write() takes the user-supplied hwmon value as a signed long
and assigns "val / MICROWATT_PER_MILLIWATT" to msg.args[0], which is a
__u32.  MICROWATT_PER_MILLIWATT is an unsigned long, so a negative write
to power1_cap (e.g. "echo -1 > power1_cap") is first converted to a huge
unsigned value by the division and then stored into the u32 argument.

As a result a nonsensical, multi-gigawatt socket power limit is sent to
the SMU via HSMP_SET_SOCKET_POWER_LIMIT instead of the write being
rejected.

Reject negative values with -EINVAL before the conversion.

Tested with HSMP enabled:

  CAP=$(dirname $(grep -l amd_hsmp_hwmon \
        /sys/class/hwmon/hwmon*/name | head -1))/power1_cap

  # negative write
  echo -1000000 > $CAP ; echo "ret=$?"
  # valid positive write must still work
  echo 400000000 > $CAP ; echo "ret=$?"

Before:
  # echo -1000000 > $CAP ; echo "ret=$?"
  ret=0                             <- accepted; bogus limit sent to SMU
  # echo 400000000 > $CAP ; echo "ret=$?"
  ret=0

After:
  # echo -1000000 > $CAP ; echo "ret=$?"
  bash: echo: write error: Invalid argument
  ret=1                             <- rejected with -EINVAL
  # echo 400000000 > $CAP ; echo "ret=$?"
  ret=0                             <- valid write still works

Fixes: 92c025d ("platform/x86/amd/hsmp: Report power via hwmon sensors")
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260812090012.140193-1-hemanth.selam@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 46b14c6 ]

rsh_log_store() calls the FIELD_PREP() macro without including the
required header file, resulting a build error:

  CC      drivers/platform/mellanox/mlxbf-bootctl.o
drivers/platform/mellanox/mlxbf-bootctl.c: In function ‘rsh_log_store’:
drivers/platform/mellanox/mlxbf-bootctl.c:429:16: error: implicit declaration of function ‘FIELD_PREP’ [-Wimplicit-function-declaration]
  429 |         data = FIELD_PREP(MLXBF_RSH_LOG_TYPE_MASK, MLXBF_RSH_LOG_TYPE_MSG);
      |                ^~~~~~~~~~

Fix this by including the <linux/bitfield.h> file.

Fixes: e9d1b2d ("mlxbf-bootctl: Add sysfs file for BlueField boot log")
Signed-off-by: Nikolay Kulikov <nikolayof23@gmail.com>
Link: https://patch.msgid.link/20260810-mellanox_fix_implicit_declaration-v1-1-352e647b8f28@gmail.com
Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8ccc9bf ]

Empty NLA_NESTED attributes are valid, and bonding uses them to clear
the ARP and NS target lists. When either target attribute is empty,
nla_for_each_nested() does not execute, so err retains an uninitialized
value before it is tested. The request can consequently return an
unpredictable error after clearing the targets.

Initialize err to zero so an empty target list completes successfully.
Non-empty lists still propagate errors from __bond_opt_set() unchanged.

This issue was found by a static analysis checker and confirmed by manual
source review.

Fixes: 4fb0ef5 ("bonding: convert arp_ip_target to use the new option API")
Signed-off-by: Ruoyu Wang <ruoyuw560@gmail.com>
Reviewed-by: Nikolay Aleksandrov <razor@blackwall.org>
Acked-by: Jay Vosburgh <jv@jvosburgh.net>
Reviewed-by: Hangbin Liu <liuhangbin@kylinos.cn>
Link: https://patch.msgid.link/20260813153126.3952893-1-ruoyuw560@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0b1c2af ]

sashiko is reporting that trying to read /sys/kernel/debug/ref_tracker/*
causes use-afer-free crash when either alloc_percpu() or dev_addr_init()
in alloc_netdev_mqs() failed, for commit 4d92b95 ("net: add net device
refcount tracker infrastructure") added ref_tracker_dir_exit() to only
free_netdev() path.

Closes: https://sashiko.dev/#/patchset/56c707e7-1fb0-43ec-b8fb-cf6f451e513e%40I-love.SAKURA.ne.jp
Fixes: 4d92b95 ("net: add net device refcount tracker infrastructure")
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Link: https://patch.msgid.link/b06ce35d-e7bc-47a5-8e0a-e82be7e4dd08@I-love.SAKURA.ne.jp
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 281eb47 ]

The page reporting callback submits an sg list to the reporting
virtqueue.  With VIRTIO_RING_F_INDIRECT_DESC negotiated and
total_sg > 1 (which it typically is), virtqueue_add reports it to the
host by allocating an indirect descriptor via kmalloc(GFP_KERNEL).

This is not pretty: the reporting worker isolates potentially hundreds
of MB of free pages from the buddy allocator (reported pages are at
least pageblock_order, and the sg can contain up to
PAGE_REPORTING_CAPACITY entries of varying orders).  As the result,
very theoretically, the kmalloc might trigger OOM when we have in fact a
ton of free memory.

Clear VIRTIO_RING_F_INDIRECT_DESC, to avoid using indirect descriptors.

Fixes: b0c504f ("virtio-balloon: add support for providing free page reports to host")
Assisted-by: Claude:claude-opus-4-6
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <73fac8a629fd9aca7bb3265ac243a769c28af25d.1783232420.git.mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit bd670e5 ]

vdpasim_create() leaves vdpasim->worker as an ERR_PTR when
kthread_run_worker() fails. The error path then drops the device
reference, which releases the partially initialized simulator.

vdpasim_free() unconditionally passes the worker pointer to
kthread_destroy_worker(), so the ERR_PTR is dereferenced and can trigger
a general protection fault.

Store the worker error, clear the pointer, and only clean up the worker
when it was successfully initialized. Also make the release path tolerate
partially initialized objects by guarding virtqueue and IOTLB cleanup,
since the same release path can be reached from other initialization
failures.

I found this bug myself, though the patch was written with AI assistance.

Fixes: 76acfa7 ("vdpa_sim: use kthread worker")
Assisted-by: OpenAI-Codex:GPT-5
Reviewed-by: Eugenio Pérez <eperezma@redhat.com>
Signed-off-by: Linfeng Sun <linfeng.sun.dev@gamil.com>
Message-ID: <20260620100959.2070316-1-slf@hdu.edu.cn>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0d8aebe ]

The generic virtio bus .shutdown handler, virtio_dev_shutdown(), breaks
and resets a device once it has established that the driver has no
.shutdown of its own. A driver that does implement .shutdown, to quiesce
its own activity first, still needs the same break and reset afterwards
and would otherwise have to open code it.

Factor the break + synchronize_cbs + reset sequence out of
virtio_dev_shutdown() into an exported virtio_device_shutdown() helper so
such drivers can reuse it instead of duplicating the core logic.

No functional change.

Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260624140846.2616797-2-den@openvz.org>
Stable-dep-of: 7e17eef ("virtio_balloon: quiesce balloon work before device shutdown")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 29536a9 ]

virtballoon_remove() stops all of the balloon's asynchronous work (the
free page reporting worker, the inflate/deflate and stats workers, the
OOM notifier and the free page shrinker) before tearing the device
down. A following change needs the same teardown from a .shutdown
handler, so move it into a virtballoon_quiesce() helper.

No functional change.

Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260624140846.2616797-3-den@openvz.org>
Stable-dep-of: 7e17eef ("virtio_balloon: quiesce balloon work before device shutdown")
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7e17eef ]

Commit 8bd2fa0 ("virtio: break and reset virtio devices on
device_shutdown()") added a generic virtio bus .shutdown handler that
breaks and resets every virtio device during device_shutdown(), i.e. on
reboot and kexec.

virtio_balloon provides no .shutdown of its own, so that generic path
runs while the balloon's asynchronous work is still armed. Once the
device has been broken, virtqueue_add_inbuf() in
virtballoon_free_page_report() returns -EIO and trips its
WARN_ON_ONCE(). On a kernel booted with panic_on_warn that turns an
ordinary reboot, for example a kexec based upgrade, into a fatal panic
in the middle of device_shutdown(), so the machine never reaches the
new kernel.

Relaxing that single WARN_ON_ONCE() would only hide the symptom: the
inflate/deflate and OOM paths do not warn, they call
wait_event(vb->acked, ...) and would instead block forever on a broken
queue that can no longer complete. The device has to be quiesced, not
just kept quiet.

Add a .shutdown handler that quiesces the balloon via the shared
virtballoon_quiesce() helper while the device is still alive, and only
then breaks and resets it via virtio_device_shutdown(). Unlike
virtballoon_remove() the balloon workqueue is not destroyed, as shutdown
does not free the device and cancel_work_sync() together with stop_update
already prevent any further work from being queued.

Fixes: 8bd2fa0 ("virtio: break and reset virtio devices on device_shutdown()")
Signed-off-by: Denis V. Lunev <den@openvz.org>
Reviewed-by: David Hildenbrand (Arm) <david@kernel.org>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260624140846.2616797-4-den@openvz.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 92a7b13 ]

The clear_user() call in VHOST_GET_FEATURES_ARRAY incorrectly starts
at argp, which is the beginning of the features array, overwriting the
data just written by copy_to_user(). It should start after the copied
elements at argp + copied * sizeof(u64) to only zero the trailing
unused space.

Use size_mul() for both the offset and length calculations so the
arithmetic stays consistent with the surrounding code and remains
overflow-safe.

Fixes: 333c515 ("vhost-net: allow configuring extended features")
Signed-off-by: Yufeng Wang <wangyufeng@kylinos.cn>
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260626070438.59149-1-r4o5m6e8o@163.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit dc3f1ee ]

In vp_find_vqs_intx(), the admin vq was set up using the local
queue_idx counter instead of avq->vq_index (the actual queue index
obtained from the device). This differs from vp_find_vqs_msix() which
correctly uses avq->vq_index. Using the wrong index causes the admin
virtqueue to be mapped to an incorrect hardware queue.

Fix it by using avq->vq_index consistent with the msix path.

Fixes: af22bbe ("virtio: create admin queues alongside other virtqueues")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Message-ID: <20260629033538.2476-1-lirongqing@baidu.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 23ae56d ]

In add_direct_chain(), newly allocated direct MR entries are added to
the local list 'tmp', which is spliced into mr->head only on success.
On the error path, the cleanup loop was incorrectly iterating over
mr->head instead of tmp.

Fix by iterating over 'tmp' in the err_alloc cleanup path.

Fixes: 94abbcc ("vdpa/mlx5: Add shared memory registration code")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Acked-by: Eugenio Pérez <eperezma@redhat.com>
Reviewed-by: Dragos Tatulea <dtatulea@nvidia.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260701113608.1972-1-lirongqing@baidu.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 68e00d9 ]

RTC class operations run with rtc_device.ops_lock held. The virtio RTC
alarm requests currently wait without a timeout for the device to return
their requestq buffers.

On surprise removal, virtio-pci marks the virtqueues broken before
unregistering the virtio device. If an alarm request is waiting when the
device stops responding, viortc_remove() blocks in viortc_class_stop()
while trying to acquire ops_lock. The request cannot complete and device
removal hangs until the waiting task is signalled.

Use the same 60-second timeout as clock read requests for alarm reads,
alarm programming, and alarm interrupt enable requests. The existing
message reference counting keeps a timed-out request alive until a late
response or device teardown.

Fixes: 9d4f22f ("virtio_rtc: Add RTC class driver")
Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: GuoHan Zhao <zhaoguohan@kylinos.cn>
Reviewed-by: Peter Hilber <peter.hilber@oss.qualcomm.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Message-ID: <20260714024352.71307-1-zhaoguohan@kylinos.cn>
Signed-off-by: Sasha Levin <sashal@kernel.org>
@qcomlnxci

Copy link
Copy Markdown

Test Matrix

Test Case hamoa-iot-evk-multimedia lemans-evk-multimedia monaco-evk-multimedia purwa-iot-evk-multimedia qcs615-ride-multimedia qcs6490-rb3gen2-multimedia qcs8300-ride-multimedia qcs9100-ride-r3-multimedia shikra-iqs-evk-multimedia
Audio_Card_Registration ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip
BT_FW_KMD_Service ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
BT_ON_OFF ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
BT_SCAN ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ❌ Fail
CPUFreq_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
CPU_affinity ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
DSP_AudioPD ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip
Ethernet_Basic_Validation ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip ❌ Fail ⚠️ skip
Freq_Scaling ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
GIC ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ❌ Fail
IPA ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
Interrupts ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
KVM_Driver ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ❌ Fail
KVM_EL2_DTB ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ❌ Fail
KVM_Infra ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ❌ Fail
OpenCV ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
PCIe ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ❌ Fail
Probe_Failure_Check ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail
RMNET ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
UFS_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip
USBHost ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ❌ Fail ✅ Pass ❌ Fail
WiFi_Firmware_Driver ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
WiFi_OnOff ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip
adsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip
cdsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
gpdsp_remoteproc ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip
hotplug ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
irq ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
kaslr ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
pinctrl ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
qcom_hwrng ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
rngtest ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
shmbridge ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
smmu ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ✅ Pass ✅ Pass ❌ Fail ✅ Pass
watchdog ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass
wpss_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass

@qcomlnxci

Copy link
Copy Markdown

Test Matrix

Test Case hamoa-iot-evk-multimedia lemans-evk-multimedia monaco-evk-multimedia purwa-iot-evk-multimedia qcs615-ride-multimedia qcs6490-rb3gen2-multimedia qcs8300-ride-multimedia qcs9100-ride-r3-multimedia shikra-iqs-evk-multimedia
Audio_Card_Registration ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ◻️ ⚠️ skip ⚠️ skip ⚠️ skip
BT_FW_KMD_Service ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
BT_ON_OFF ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
BT_SCAN ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ❌ Fail
CPUFreq_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
CPU_affinity ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
DSP_AudioPD ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ⚠️ skip
Ethernet_Basic_Validation ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ◻️ ❌ Fail ⚠️ skip ⚠️ skip
Freq_Scaling ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
GIC ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ❌ Fail
IPA ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
Interrupts ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
KVM_Driver ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ◻️ ❌ Fail ❌ Fail ❌ Fail
KVM_EL2_DTB ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ◻️ ❌ Fail ❌ Fail ❌ Fail
KVM_Infra ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ◻️ ❌ Fail ❌ Fail ❌ Fail
OpenCV ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
PCIe ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ❌ Fail
Probe_Failure_Check ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ◻️ ❌ Fail ❌ Fail ❌ Fail
RMNET ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
UFS_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ⚠️ skip
USBHost ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ❌ Fail
WiFi_Firmware_Driver ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
WiFi_OnOff ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ⚠️ skip
adsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ⚠️ skip
cdsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
gpdsp_remoteproc ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ◻️ ✅ Pass ✅ Pass ⚠️ skip
hotplug ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
irq ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
kaslr ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
pinctrl ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
qcom_hwrng ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ◻️
rngtest ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
shmbridge ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
smmu ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ◻️ ✅ Pass ❌ Fail ✅ Pass
watchdog ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass
wpss_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️ ✅ Pass ✅ Pass ✅ Pass

@qcomlnxci

Copy link
Copy Markdown

Test Matrix

Test Case hamoa-iot-evk-multimedia lemans-evk-multimedia monaco-evk-multimedia purwa-iot-evk-multimedia qcs615-ride-multimedia qcs6490-rb3gen2-multimedia qcs8300-ride-multimedia qcs9100-ride-r3-multimedia shikra-iqs-evk-multimedia
Audio_Card_Registration ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ✅ Pass ⚠️ skip ⚠️ skip ◻️
BT_FW_KMD_Service ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
BT_ON_OFF ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
BT_SCAN ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
CPUFreq_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
CPU_affinity ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
DSP_AudioPD ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Ethernet_Basic_Validation ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ⚠️ skip ❌ Fail ◻️
Freq_Scaling ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
GIC ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
IPA ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Interrupts ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
KVM_Driver ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ◻️
KVM_EL2_DTB ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ◻️
KVM_Infra ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ◻️
OpenCV ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
PCIe ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Probe_Failure_Check ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ◻️
RMNET ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
UFS_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
USBHost ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ❌ Fail ✅ Pass ◻️
WiFi_Firmware_Driver ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
WiFi_OnOff ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
adsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
cdsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
gpdsp_remoteproc ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ✅ Pass ✅ Pass ◻️
hotplug ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
irq ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
kaslr ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
pinctrl ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
qcom_hwrng ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
rngtest ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
shmbridge ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
smmu ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ✅ Pass ✅ Pass ❌ Fail ◻️
watchdog ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
wpss_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️

@qcomlnxci

Copy link
Copy Markdown

Test Matrix

Test Case hamoa-iot-evk-multimedia lemans-evk-multimedia monaco-evk-multimedia purwa-iot-evk-multimedia qcs615-ride-multimedia qcs6490-rb3gen2-multimedia qcs8300-ride-multimedia qcs9100-ride-r3-multimedia shikra-iqs-evk-multimedia
Audio_Card_Registration ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ✅ Pass ⚠️ skip ⚠️ skip ◻️
BT_FW_KMD_Service ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
BT_ON_OFF ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
BT_SCAN ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
CPUFreq_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
CPU_affinity ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
DSP_AudioPD ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Ethernet_Basic_Validation ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ❌ Fail ⚠️ skip ◻️
Freq_Scaling ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
GIC ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
IPA ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Interrupts ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
KVM_Driver ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ◻️
KVM_EL2_DTB ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ◻️
KVM_Infra ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ◻️
OpenCV ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
PCIe ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Probe_Failure_Check ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ◻️
RMNET ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
UFS_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
USBHost ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ✅ Pass ✅ Pass ◻️
WiFi_Firmware_Driver ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
WiFi_OnOff ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
adsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
cdsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
gpdsp_remoteproc ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ✅ Pass ✅ Pass ◻️
hotplug ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
irq ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
kaslr ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
pinctrl ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
qcom_hwrng ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
rngtest ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
shmbridge ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
smmu ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ✅ Pass ✅ Pass ❌ Fail ◻️
watchdog ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
wpss_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37623783352

# Error File:Line PR-introduced? Root Cause
1 ERROR (duplicate_node_names): /soc@0/interconnect@2a0c0000: Duplicate node name arch/arm64/boot/dts/qcom/lemans.dtsi:7666 No Pre-existing duplicate node definition in lemans.dtsi; the interconnect@2a0c0000 node is defined twice in the device tree

Verdict

The single build error is pre-existing and not introduced by this PR. The PR does not modify or add any interconnect nodes at address 0x2a0c0000.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

PR #1158 — validate-patch

PR: #1158

Verdict Issues Detailed Report
❌ 0 Full report

Final Summary

  1. Lore link present: No — bulk stable kernel merge (6.18.44 → 6.18.52); no lore.kernel.org links found or expected for this type of merge
  2. Lore link matches PR commits: N/A — no lore links to compare against
  3. Upstream patch status: N/A — this is a stable kernel merge from kernel.org, not a discrete upstream patch posting
  4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

Note: The validate-patch skill is designed for discrete patches with lore.kernel.org attribution. Stable kernel merges require a different validation workflow focused on version verification, build testing, and regression checking rather than per-patch lore attribution.

Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #1158 - Linux stable kernel update 6.18.44 → 6.18.52
Upstream commit: N/A (stable kernel merge, not a single lore patch)
Verdict: ❌ FAIL

Step 1 — Parse the PR and Check for Lore Link

Analysis: This PR contains 90,453 file changes across 5+ million lines, representing a Linux stable kernel version bump from 6.18.44 to 6.18.52. The lore evidence report confirms: status: no-lore-links with reason: no lore.kernel.org Link tags found in pr.patch.

Conclusion: No lore.kernel.org link found in the PR. This is a bulk stable kernel merge, not a discrete patch with upstream attribution.

Commit Message

Check Status Note
Subject matches upstream ❌ No commit message present in pr.patch (plain diff format)
Body preserves rationale ❌ No commit message body
Fixes tag present/correct N/A Not applicable for stable merges
Authorship preserved ❌ No author metadata in plain diff
Backport note (if applicable) ❌ No commit message

Diff

File Status Notes
Makefile ⚠️ VERSION bump: 6.18.44 → 6.18.52 (stable update)
90,452 other files ⚠️ Bulk stable kernel changes - cannot validate individual patch attribution

Issues

  1. No lore attribution: This PR is a bulk stable kernel merge (6.18.44 → 6.18.52) with no individual patch attribution via lore.kernel.org links. The validate-patch skill requires lore links to verify patch correctness and upstream status.

  2. No commit message: The pr.patch file is a plain diff without git commit metadata (no From:, Date:, Subject:, or commit body). Cannot verify commit message correctness, authorship, or trailers.

  3. Scope exceeds single-patch validation: With 90,453 files changed, this is not a discrete patch but a bulk merge of hundreds or thousands of upstream stable commits. Each individual fix in the stable series would need its own lore link for proper validation.

  4. Integration presence partial: The integration_presence_report.md shows overall_status: PARTIAL with the note: "skipped exhaustive tree-content check for large patch (1254957 added lines, 2741 files)". The commit is not definitively confirmed in qcom-next or topics branches.

Verdict

FAIL — This PR cannot be validated using the validate-patch skill because:

  • No lore.kernel.org links present (required by the skill)
  • Bulk stable merge, not a discrete upstream patch
  • No commit message metadata for verification
  • Integration presence check was partial/incomplete due to patch size

Recommendation

For stable kernel merges of this type:

  1. Use a different validation approach: Stable kernel merges should be validated by:

    • Verifying the source tag/branch from kernel.org stable tree
    • Confirming the version bump is correct (6.18.44 → 6.18.52 ✓)
    • Running build and boot tests
    • Checking for known regressions in the stable release notes
  2. Add commit message: Even for bulk merges, include a commit message with:

    Merge Linux stable 6.18.52
    
    Merge stable kernel release v6.18.52 from kernel.org.
    
    Release notes: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.18.52
    
    Signed-off-by: <maintainer>
    
  3. Consider incremental merges: If individual stable fixes need attribution, consider cherry-picking specific commits with proper UPSTREAM: or BACKPORT: prefixes and lore links, rather than bulk merging.

  4. Integration verification: The partial integration presence status should be resolved - either by:

    • Completing the exhaustive tree-content check, or
    • Verifying the stable tag directly against kernel.org, or
    • Confirming this is a new integration not yet in qcom-next

Final Summary

  1. Lore link present: No — bulk stable kernel merge (6.18.44 → 6.18.52); no lore.kernel.org links found or expected for this type of merge
  2. Lore link matches PR commits: N/A — no lore links to compare against
  3. Upstream patch status: N/A — this is a stable kernel merge from kernel.org, not a discrete upstream patch posting
  4. PR present in qcom-next/topics: Partial — integration presence check was incomplete due to patch size (1254957 added lines, 2741 files); exhaustive tree-content verification was skipped

Note: The validate-patch skill is designed for discrete patches with lore.kernel.org attribution. Stable kernel merges require a different validation workflow focused on version verification, build testing, and regression checking rather than per-patch lore attribution.

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: ba86f67908354f41f269ca1d64b22e4624766dcf
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/1 `` partial - skipped exhaustive tree-content check for large patch (1254957 added lines, 2741 files) partial - skipped exhaustive tree-content check for large patch (1254957 added lines, 2741 files) partial

Final Status

overall_status: PARTIAL
present_commits: 0/1
partial_commits: 1/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

@qlijarvis

Copy link
Copy Markdown

PR #1158 — checker-log-analyzer

PR: #1158
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37626077447

Checker Result Summary
Checker Result Summary
checkpatch ❌ 36 commits with errors, many with warnings
dt-binding-check ⏭️ No DT binding changes
dtb-check ❌ DTB validation failures on ipq5018 ethernet-phy clocks
sparse-check ✅ Passed
check-uapi-headers ❌ UAPI ABI changes detected (nl80211, if_xdp)
check-patch-compliance ❌ All 3231 commits missing required prefix
tag-check ❌ All 3231 commits missing required subject prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1158 (qualcomm-linux/kernel)
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/37626077447

Checker Result Summary
checkpatch ❌ 36 commits with errors, many with warnings
dt-binding-check ⏭️ No DT binding changes
dtb-check ❌ DTB validation failures on ipq5018 ethernet-phy clocks
sparse-check ✅ Passed
check-uapi-headers ❌ UAPI ABI changes detected (nl80211, if_xdp)
check-patch-compliance ❌ All 3231 commits missing required prefix
tag-check ❌ All 3231 commits missing required subject prefix

❌ check-patch-compliance

Root cause: Every commit in this PR (3231 total) lacks a required subject-line prefix.

Failure details:

Checking commit: KVM: s390: pci: Fix resource leak on IRQ registration failure
Commit summary does not start with a required prefix

Checking commit: mount: honour SB_NOUSER in the new mount API
Commit summary does not start with a required prefix

Checking commit: sched/fair: Separate se->vlag from se->vprot
Commit summary does not start with a required prefix

[... 3228 more commits with the same failure ...]

Fix:

This PR appears to be a large upstream merge or integration containing 3231 commits from mainline Linux. Each commit must be prefixed with one of:

  • UPSTREAM: — if merged into Linus's mainline tree
  • FROMLIST: — if posted to mailing list but not yet merged
  • FROMGIT: — if taken from a maintainer git tree
  • BACKPORT: — if backported with modifications

For a bulk rebase/prefix operation:

git rebase -i <base_sha>
# For each commit, mark as 'edit', then:
git commit --amend -m "UPSTREAM: $(git log -1 --format=%s)"
git rebase --continue

Reproduce locally:

./scripts/check-patch-compliance.sh <base>..<head>

❌ tag-check

Root cause: All 3231 commits lack the mandatory subject-line prefix required for branches other than qcom-next/qcom-next-staging.

Failure details:

Sample commits without prefix:

  • KVM: s390: pci: Fix resource leak on IRQ registration failure
  • mount: honour SB_NOUSER in the new mount API
  • sched/fair: Separate se->vlag from se->vprot
  • arm64: dts: qcom: rename x1e80100 to hamoa
  • NFS: Pin the 'struct nfs_server' during a FREE_STATEID call

Fix:

Every commit must start with one of these prefixes:

  • UPSTREAM: / FROMLIST: / FROMGIT: / BACKPORT: / QCLINUX: / PENDING: / WORKAROUND:

For bulk prefix addition:

git filter-branch --msg-filter 'echo "UPSTREAM: $(cat)"' <base>..<head>
# Or use git rebase -i for manual control

Note: If the target branch is qcom-next or qcom-next-staging, this check does not apply. Please confirm the target branch.


❌ checkpatch

Root cause: 36 commits have checkpatch ERRORs (blocking), many more have WARNINGs.

Failure details:

Example ERROR (commit 62fefb8):

ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' 
  - ie: 'commit 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag")'
ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' 
  - ie: 'commit 66951e4860d3 ("sched/fair: Fix update_cfs_group() vs DELAY_DEQUEUE")'
total: 2 errors, 2 warnings, 1 checks, 201 lines checked

Example WARNING (commit 1e2b408):

WARNING: DT compatible string vendor "pci17cb" appears un-documented
  -- check ./Documentation/devicetree/bindings/vendor-prefixes.yaml

Example WARNING (commit 8aba384):

WARNING: line length of 103 exceeds 100 columns
WARNING: line length of 116 exceeds 100 columns
WARNING: line length of 123 exceeds 100 columns
WARNING: line length of 124 exceeds 100 columns

Fix:

  1. For commit description style errors: Use full 12+ char SHA1 and quoted title in commit body references
  2. For undocumented DT vendor: Add pci17cb to Documentation/devicetree/bindings/vendor-prefixes.yaml
  3. For long lines: Wrap at 100 chars (code) or 75 chars (commit body)

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git <base>..<head>

❌ dtb-check

Root cause: DTB validation failures on ipq5018 boards — ethernet-phy clocks property has too many cells.

Failure details:

/opt/actions-runner/_work/kernel-config/kernel-config/kernel/temp-out/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dtb: 
  ethernet-phy@7 (ethernet-phy-id004d.d0c0): clocks: [[9, 36], [9, 37]] is too long
  from schema $id: http://devicetree.org/schemas/net/qca,ar803x.yaml

/opt/actions-runner/_work/kernel-config/kernel-config/kernel/temp-out/arch/arm64/boot/dts/qcom/ipq5018-tplink-archer-ax55-v1.dtb: 
  ethernet-phy@7 (ethernet-phy-id004d.d0c0): clocks: [[9, 36], [9, 37]] is too long
  from schema $id: http://devicetree.org/schemas/net/qca,ar803x.yaml

Fix:

The qca,ar803x.yaml binding expects a single clock phandle, but the DTS provides two clocks <&gcc 36>, <&gcc 37>.

Check the binding requirements:

cat Documentation/devicetree/bindings/net/qca,ar803x.yaml

If the binding allows only one clock, remove the extra clock reference. If two clocks are needed, update the binding YAML to allow maxItems: 2.

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dtb

❌ check-uapi-headers

Root cause: UAPI ABI changes detected in nl80211.h and if_xdp.h — new enumerators and struct members added.

Failure details:

==== ABI differences detected in include/linux/nl80211.h ====
    [C] 'enum nl80211_attrs' changed:
      11 enumerator insertions:
        'nl80211_attrs::NL80211_ATTR_EPP_PEER' value '346'
        'nl80211_attrs::NL80211_ATTR_UHR_CAPABILITY' value '347'
        'nl80211_attrs::NL80211_ATTR_DISABLE_UHR' value '348'
        'nl80211_attrs::NL80211_ATTR_UHR_OPERATION' value '350'
        [... 7 more ...]
      4 enumerator changes:
        'nl80211_attrs::NL80211_ATTR_MAX' from value '346' to '357'
        'nl80211_attrs::NUM_NL80211_ATTR' from value '347' to '358'

==== ABI differences detected in include/linux/if_xdp.h ====
    [C] 'struct {__u16 csum_start; __u16 csum_offset; __u64 launch_time;}' changed:
      1 data member insertion:
        '__u32 reserved', at offset 32 (in bits)

Analysis:

These are additive changes only — new enum values and a reserved struct field. UAPI changes are acceptable if:

  • New fields/values are added (✅ this case)
  • Existing fields are NOT removed or reordered (✅ confirmed)
  • Struct size remains compatible (✅ reserved field added at end)

Verdict: These UAPI changes are backwards-compatible and acceptable for merge. The checker flags any UAPI change, but additive changes are safe.

Reproduce locally:

./scripts/check-uapi.sh -b <head_sha> -p <base_sha> -l uapi_errors.log

Verdict

❌ BLOCKERS — Cannot merge as-is

Critical issues:

  1. All 3231 commits missing required subject prefix — Every commit must be prefixed with UPSTREAM:, FROMLIST:, FROMGIT:, BACKPORT:, QCLINUX:, PENDING:, or WORKAROUND: (unless target branch is qcom-next or qcom-next-staging — please confirm)
  2. 36 commits with checkpatch ERRORs — Must fix commit description style errors
  3. DTB validation failure — ipq5018 ethernet-phy clocks property exceeds binding requirements

Non-blocking issues:

  • UAPI changes are additive and backwards-compatible (acceptable)
  • Checkpatch WARNINGs should be reviewed but are not blockers
  • Sparse check passed

Recommended action:

  1. Confirm the target branch — if qcom-next or qcom-next-staging, skip prefix requirement
  2. If not qcom-next/staging: bulk-prefix all commits with UPSTREAM: (or appropriate prefix)
  3. Fix the 36 checkpatch ERROR commits (commit description style)
  4. Fix ipq5018 DTB clocks property (remove extra clock or update binding)
  5. Re-run CI after fixes

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37626043612

# Error File:Line PR-introduced? Root Cause
1 Duplicate DT node name arch/arm64/boot/dts/qcom/lemans.dtsi:7666 No Pre-existing duplicate interconnect@2a0c0000 node definition in lemans.dtsi

Verdict

The single build error is pre-existing and not introduced by this PR. The PR does not modify the code region where the error occurs.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

PR #1158 — validate-patch

PR: #1158

Verdict Issues Detailed Report
❌ 0 Full report

Final Summary

  1. Lore link present: No - no lore.kernel.org link found in pr.patch
  2. Lore link matches PR commits: N/A - no lore link to compare against
  3. Upstream patch status: Unknown - cannot determine without lore link or commit metadata
  4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence
Verdict: ❌ — click to expand

Patch Validation Report

PR: #1158 (title unknown - no commit metadata available)
Upstream: (none found)
Verdict: ❌ FAIL

Reason

No lore.kernel.org link was found in the PR description or commit message(s).
This skill only validates patches against a lore.kernel.org source.

The PR contains a massive tree-wide change (90,453 files, 5M+ lines) with no commit message metadata, no subject line, no author information, and no upstream attribution.

Commit Message

Cannot evaluate - no commit message metadata present in pr.patch.

Diff

Cannot evaluate against upstream - no lore source to compare against.

Patch statistics:

  • Files changed: 90,453
  • Total lines: 5,097,807
  • Sample changes: Documentation fixes (typos, formatting), ABI documentation updates, driver code modifications

Issues

  1. No lore link - The PR has no Link: tag pointing to lore.kernel.org
  2. No commit metadata - pr.patch is a raw unified diff with no From:, Subject:, Date:, or commit message
  3. No upstream attribution - No prefix (UPSTREAM:, FROMLIST:, BACKPORT:, QCLINUX:, etc.) to indicate the source or nature of changes
  4. Massive scope - 90K+ files changed suggests this may be a merge commit, rebase artifact, or automated tree-wide change that should be split into logical commits

Verdict

Do not merge. This PR cannot be validated without:

  1. A proper commit message with subject, body, and authorship
  2. Upstream attribution via lore.kernel.org links (for upstream changes) or appropriate prefix (QCLINUX: for vendor-only)
  3. Logical decomposition if this represents multiple independent changes

Recommendation

If this is an upstream merge or sync:

  • Add UPSTREAM: prefix and link to the merge commit or tag in torvalds/linux
  • Include merge commit message explaining what is being integrated

If this is a vendor-only tree-wide change:

  • Add QCLINUX: prefix and detailed commit message explaining the rationale
  • Consider splitting into logical, reviewable chunks

If this is a backport or cherry-pick:

  • Add appropriate prefix (BACKPORT:, FROMLIST:, FROMGIT:)
  • Add Link: tags to each upstream source commit
  • Preserve original authorship

Final Summary

  1. Lore link present: No - no lore.kernel.org link found in pr.patch
  2. Lore link matches PR commits: N/A - no lore link to compare against
  3. Upstream patch status: Unknown - cannot determine without lore link or commit metadata
  4. PR present in qcom-next/topics: Partial - integration presence check was skipped due to patch size (1,254,957 added lines, 2,741 files); exhaustive tree-content verification not performed

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: ba86f67908354f41f269ca1d64b22e4624766dcf
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/1 `` partial - skipped exhaustive tree-content check for large patch (1254957 added lines, 2741 files) partial - skipped exhaustive tree-content check for large patch (1254957 added lines, 2741 files) partial

Final Status

overall_status: PARTIAL
present_commits: 0/1
partial_commits: 1/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

@qlijarvis

Copy link
Copy Markdown

PR #1158 — checker-log-analyzer

PR: #1158
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37637451360

Checker Result Summary
Checker Result Summary
checkpatch ❌ Multiple commit description style errors
dt-binding-check ⏭️ No DT binding changes
dtb-check ❌ DTB validation failures
sparse-check ✅ Passed
check-uapi-headers ❌ UAPI ABI compatibility issues
check-patch-compliance ❌ All 3231 commits missing required prefix
tag-check ❌ All 3231 commits missing required subject prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1158 - Linux 6.18.52 stable merge
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/37637451360

Checker Result Summary
checkpatch ❌ Multiple commit description style errors
dt-binding-check ⏭️ No DT binding changes
dtb-check ❌ DTB validation failures
sparse-check ✅ Passed
check-uapi-headers ❌ UAPI ABI compatibility issues
check-patch-compliance ❌ All 3231 commits missing required prefix
tag-check ❌ All 3231 commits missing required subject prefix

❌ checkpatch

Root cause: Multiple commits have improperly formatted commit references in their commit messages.

Failure details:

ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")'
- Found in multiple commits referencing upstream commits
- Examples: references to commits 6d71a9c61604, 66951e4860d3, 461daba06bdc, etc.

ERROR: Unrecognized email address: 'AI Mode in Google Search (no mail address)'
- Invalid email format in commit metadata

ERROR: Macros with complex values should be enclosed in parentheses
ERROR: space prohibited after that '*' (ctx:WxW)
ERROR: code indent should use tabs where possible
- Various coding style violations

Fix:

  1. For commit reference errors: Use the full format commit <12+ chars> ("<title>") when referencing other commits
  2. For email errors: Fix or remove invalid email addresses
  3. For coding style: Apply standard kernel coding style fixes

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git <base>..<head>

❌ check-patch-compliance

Root cause: All 3231 commits in this PR lack the required subject-line prefix tag.

Failure details:
Every commit fails with:

Commit summary does not start with a required prefix

Sample commits missing prefixes:

  • KVM: s390: pci: Fix resource leak on IRQ registration failure
  • mount: honour SB_NOUSER in the new mount API
  • sched/fair: Separate se->vlag from se->vprot
  • arm64: dts: qcom: rename x1e80100 to hamoa
  • ... (3227 more commits)

Fix:

This is a Linux 6.18.52 stable kernel merge containing 3231 upstream commits. The check-patch-compliance checker requires every commit to have a prefix (FROMLIST:, FROMGIT:, UPSTREAM:, BACKPORT:, QCLINUX:, PENDING:, or WORKAROUND:).

For a stable kernel merge of this scale, the recommended approach is:

  1. If merging into a branch that requires prefixes (any branch except qcom-next or qcom-next-staging):

    • Add UPSTREAM: prefix to all commits since they are from Linus's mainline tree
    • This can be automated with a script:
    git filter-branch -f --msg-filter 'sed "1s/^/UPSTREAM: /"' <base>..<head>
  2. If merging into qcom-next or qcom-next-staging:

    • These branches do not require subject prefixes
    • Retarget the PR to one of these branches

Reproduce locally:

./scripts/check-patch-compliance.sh <base_sha> <head_sha>

❌ tag-check

Root cause: All 3231 commits lack the mandatory subject-line prefix required for branches other than qcom-next / qcom-next-staging.

Failure details:
Every commit subject line must start with one of:

  • FROMLIST: (posted to mailing list)
  • FROMGIT: (from maintainer tree)
  • UPSTREAM: (merged into Linus's tree)
  • BACKPORT: (backported with modifications)
  • QCLINUX: (vendor-only)
  • PENDING: (work-in-progress)
  • WORKAROUND: (temporary fix)

Fix:
Same as check-patch-compliance above. Since this is a Linux 6.18.52 stable merge, all commits should be prefixed with UPSTREAM:.


❌ dtb-check

Root cause: DTB validation failure on ipq5018-rdp432-c2.dtb - ethernet PHY clock property has too many cells.

Failure details:

/opt/actions-runner/_work/kernel-config/kernel-config/kernel/temp-out/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dtb: 
  ethernet-phy@7 (ethernet-phy-id004d.d0c0): clocks: [[9, 36], [9, 37]] is too long
  from schema $id: http://devicetree.org/schemas/net/qca,ar803x.yaml

Fix:
The qca,ar803x.yaml binding expects a single clock phandle, but the DTS provides two clock cells [9, 36], [9, 37].

Check arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dts and verify the clocks property for ethernet-phy@7:

  • If only one clock is needed, remove the extra cell
  • If two clocks are genuinely required, update the binding schema to allow maxItems: 2

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dtb

❌ check-uapi-headers

Root cause: UAPI ABI compatibility breakage detected in 2 headers.

Failure details:

error - 2/933 UAPI headers compatible with arm64 appear _not_ to be backwards compatible

include/uapi/linux/nl80211.h:
  - 'nl80211_attrs::NL80211_ATTR_INCUMBENT_SIGNAL_INTERFERENCE_BITMAP' value changed from 346 to 349
  - 'nl80211_attrs::NUM_NL80211_ATTR' value changed from 347 to 358
  - 'nl80211_attrs::__NL80211_ATTR_AFTER_LAST' value changed from 347 to 358

include/linux/if_xdp.h:
  - ABI differences detected in struct layout

Fix:
These are enum value shifts in the nl80211 UAPI header, which break ABI compatibility. This typically happens when new enum values are inserted in the middle rather than appended at the end.

For a stable kernel merge:

  • This is likely an upstream issue that was fixed in later stable releases
  • Verify if the enum reordering is intentional (e.g., a deliberate ABI break with proper deprecation)
  • If unintentional, the fix should come from upstream stable

Reproduce locally:

./scripts/check-uapi.sh -b <head_sha> -p <base_sha> -l uapi_errors.log

Verdict

This PR has 4 critical blockers that must be addressed before merge:

  1. 3231 commits missing required UPSTREAM: prefix - This is the primary blocker. For a Linux 6.18.52 stable merge, all commits should be prefixed with UPSTREAM: (or retarget to qcom-next/qcom-next-staging which don't require prefixes).

  2. UAPI ABI compatibility breakage - The nl80211 enum reordering breaks userspace ABI. This needs upstream stable review.

  3. DTB validation failure - The ipq5018-rdp432-c2 ethernet PHY clock property needs correction.

  4. Checkpatch commit reference formatting - Multiple commits have improperly formatted commit references.

Recommended action:

  • If the target branch requires prefixes: Apply UPSTREAM: prefix to all 3231 commits via git filter-branch
  • If the target branch is qcom-next or qcom-next-staging: Retarget the PR to avoid the prefix requirement
  • Address the UAPI ABI breakage (likely needs upstream stable coordination)
  • Fix the DTB clock property issue
  • Fix commit reference formatting issues

@qcomlnxci

Copy link
Copy Markdown

Test Matrix

Test Case hamoa-iot-evk-multimedia lemans-evk-multimedia monaco-evk-multimedia purwa-iot-evk-multimedia qcs615-ride-multimedia qcs6490-rb3gen2-multimedia qcs8300-ride-multimedia qcs9100-ride-r3-multimedia shikra-iqs-evk-multimedia
Audio_Card_Registration ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ✅ Pass ⚠️ skip ⚠️ skip ◻️
BT_FW_KMD_Service ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
BT_ON_OFF ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
BT_SCAN ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
CPUFreq_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
CPU_affinity ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
DSP_AudioPD ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Ethernet_Basic_Validation ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ❌ Fail ⚠️ skip ◻️
Freq_Scaling ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
GIC ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
IPA ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Interrupts ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
KVM_Driver ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ◻️
KVM_EL2_DTB ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ◻️
KVM_Infra ❌ Fail ✅ Pass ✅ Pass ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ◻️
OpenCV ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
PCIe ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
Probe_Failure_Check ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ❌ Fail ◻️
RMNET ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
UFS_Validation ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
USBHost ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ⚠️ skip ✅ Pass ✅ Pass ◻️
WiFi_Firmware_Driver ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
WiFi_OnOff ✅ Pass ✅ Pass ❌ Fail ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
adsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
cdsp_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
gpdsp_remoteproc ⚠️ skip ✅ Pass ✅ Pass ⚠️ skip ⚠️ skip ⚠️ skip ✅ Pass ✅ Pass ◻️
hotplug ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
irq ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
kaslr ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
pinctrl ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
qcom_hwrng ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
rngtest ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
shmbridge ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
smmu ❌ Fail ❌ Fail ✅ Pass ❌ Fail ❌ Fail ✅ Pass ✅ Pass ❌ Fail ◻️
watchdog ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️
wpss_remoteproc ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ✅ Pass ◻️

@qlijarvis

Copy link
Copy Markdown

PR #1158 — validate-patch

PR: #1158

Verdict Issues Detailed Report
❌ 4 Full report

Final Summary

  1. Lore link present: No - no lore.kernel.org link found in PR
  2. Lore link matches PR commits: N/A - no lore link to compare against
  3. Upstream patch status: N/A - cannot determine without lore link; appears to be mainline merge based on version bump
  4. PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence
Verdict: ❌ — click to expand

🔍 Patch Validation

PR: #1158 (title unavailable - network restricted)
Upstream commit: (none found)
Verdict: ❌ FAIL

Reason

No lore.kernel.org link was found in the PR description or commit message(s).
This skill only validates patches against a lore.kernel.org source.

The PR contains a massive diff (90,453 files changed, 5+ million lines) that appears to be a mainline kernel version merge (SUBLEVEL bump from .44 to .52), submitted as a raw diff without commit metadata or lore attribution.

Recommendation

This PR cannot be validated using the validate-patch skill because:

  1. No lore link present - The patch has no Link: tag pointing to lore.kernel.org
  2. No commit message - The PR is a raw diff without author, subject, or commit body
  3. Merge/rebase nature - This appears to be a bulk mainline merge rather than individual upstream patches

For mainline merges:

  • Mainline merges do not require lore links - they integrate upstream kernel releases
  • Validation should focus on merge correctness, not individual patch attribution
  • Use git log to verify the merge brings in the expected upstream commits

If this should contain individual patches:

  • Split the PR into individual commits with proper commit messages
  • Add Link: https://lore.kernel.org/r/<message-id> to each commit
  • Use appropriate prefixes:
    • UPSTREAM: → merged into Linus's tree
    • FROMLIST: → posted to mailing list, not yet merged
    • BACKPORT: → backported with modifications
    • QCLINUX: → vendor-only (no lore link needed)

Commit Message

Check Status Note
Subject matches upstream ❌ No commit message present
Body preserves rationale ❌ No commit message present
Fixes tag present/correct N/A No commit message present
Authorship preserved ❌ No commit metadata present
Backport note (if applicable) N/A No commit message present

Diff

File Status Notes
90,453 files ⚠️ Massive diff - appears to be mainline merge (SUBLEVEL .44 → .52)

Issues

  • No commit metadata: PR submitted as raw diff without author, date, subject, or message body
  • No lore attribution: No Link: tags or upstream references
  • Validation scope exceeded: 90,453 files, 5+ million lines - too large for individual patch validation
  • Merge vs. patch ambiguity: Unclear if this is a mainline merge (expected) or improperly formatted patch series (incorrect)

Verdict

FAIL - Cannot validate: no lore link found, no commit message, submitted as raw diff.

If this is a mainline merge, it should be clearly labeled and does not require lore validation. If this contains upstream patches, it must be reformatted with proper commit messages and lore attribution before validation can proceed.

Final Summary

  1. Lore link present: No - no lore.kernel.org link found in PR
  2. Lore link matches PR commits: N/A - no lore link to compare against
  3. Upstream patch status: N/A - cannot determine without lore link; appears to be mainline merge based on version bump
  4. PR present in qcom-next/topics: Partial - integration check skipped due to patch size (1,254,957 added lines, 2,741 files exceeds limits)

Deterministic Integration Presence

Integration Presence Report

This report is generated by Jarvis before validate-patch runs.
It is the authoritative source for whether PR changes are already present
in qcom-next or in the kernel topic branches.

Kernel repo: /local/mnt/workspace/sgaud/Qgenie/image_pipeline/kernel
qcom-next ref: ba86f67908354f41f269ca1d64b22e4624766dcf
topics remote: topics -> https://github.com/qualcomm-linux/kernel-topics
topics fetch: fetched

Commit Subject qcom-next topics Final
1/1 `` partial - skipped exhaustive tree-content check for large patch (1254957 added lines, 2741 files) partial - skipped exhaustive tree-content check for large patch (1254957 added lines, 2741 files) partial

Final Status

overall_status: PARTIAL
present_commits: 0/1
partial_commits: 1/1
missing_commits: 0/1
topics_checked_for_commits: 1/1
final_summary: PR present in qcom-next/topics: Partial - 1/1 commit(s) only have partial integration evidence

@qlijarvis

Copy link
Copy Markdown

PR #1158 — checker-log-analyzer

PR: #1158
Checker run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37731147370

Checker Result Summary
Checker Result Summary
checkpatch ❌ 3226 commits with warnings/errors
dt-binding-check ⏭️ No DT binding changes
dtb-check ❌ 1 new error: ipq5018-rdp432-c2 ethernet PHY clocks property
sparse-check ✅ Passed
check-uapi-headers ❌ 2 UAPI ABI changes detected
check-patch-compliance ❌ 3231 commits missing required prefix
tag-check ❌ 3231 commits missing required subject prefix

Detailed report: Full report

Checker analysis — click to expand

🤖 CI Checker Analysis (checker-log-analyzer)

PR: #1158 (Large stable kernel merge - 3232 commits)
Source: https://github.com/qualcomm-linux/kernel-config/actions/runs/37731147370
Target branch: qcom-6.18.y

Checker Result Summary
checkpatch ❌ 3226 commits with warnings/errors
dt-binding-check ⏭️ No DT binding changes
dtb-check ❌ 1 new error: ipq5018-rdp432-c2 ethernet PHY clocks property
sparse-check ✅ Passed
check-uapi-headers ❌ 2 UAPI ABI changes detected
check-patch-compliance ❌ 3231 commits missing required prefix
tag-check ❌ 3231 commits missing required subject prefix

❌ check-patch-compliance

Root cause: 3231 out of 3232 commits do not start with a required prefix tag.

Failure details:

Commit summary does not start with a required prefix

This failure appears for nearly every commit in the PR. The target branch is qcom-6.18.y, which is not qcom-next or qcom-next-staging, therefore every commit must start with one of the following prefixes:

  • FROMLIST: — Patch posted to mailing list (lore.kernel.org)
  • FROMGIT: — Patch taken from a maintainer git tree
  • UPSTREAM: — Patch merged into Linus's mainline tree
  • BACKPORT: — Upstream patch backported with modifications
  • QCLINUX: — Vendor-only change with no upstream equivalent
  • PENDING: — Work-in-progress, not yet posted upstream
  • WORKAROUND: — Temporary fix not suitable for upstream

Example failing commits:

KVM: s390: pci: Fix resource leak on IRQ registration failure
mount: honour SB_NOUSER in the new mount API
sched/fair: Separate se->vlag from se->vprot
arm64: dts: qcom: rename x1e80100 to hamoa
NFS: Pin the 'struct nfs_server' during a FREE_STATEID call

Fix: This is a large stable kernel merge (3232 commits). Each commit needs to be prefixed based on its origin:

# For upstream stable commits (most likely scenario):
git rebase -i <base_sha>
# For each commit, mark as 'edit', then:
git commit --amend -m "UPSTREAM: <original subject>"
git rebase --continue

Since this appears to be a stable kernel merge from upstream, the appropriate prefix is likely UPSTREAM: for all commits.

Reproduce locally:

cd kernel
./scripts/check-patch-compliance.sh --base 4c5c1a4c37fc --head 3aa27aa4deed

❌ tag-check

Root cause: 3231 commits do not have a required subject-line prefix tag.

Failure details:

The target branch qcom-6.18.y is not qcom-next or qcom-next-staging, therefore the subject-prefix check is mandatory for every commit.

This is the same root cause as check-patch-compliance — the commits are missing the required prefix tags at the start of their subject lines.

Fix: Same as check-patch-compliance above — add the appropriate prefix (UPSTREAM:, FROMLIST:, FROMGIT:, BACKPORT:, etc.) to every commit subject line.


❌ checkpatch

Root cause: 3226 commits have checkpatch warnings or errors.

Failure details:

Most common issues:

  • 3460 occurrences: WARNING: Unknown commit id — References to commits not in the tree
  • 387 occurrences: WARNING: Reported-by: should be immediately followed by Closes: with a URL
  • 197 occurrences: WARNING: Prefer a maximum 75 chars per line
  • 124 occurrences: WARNING: The commit message has 'stable@', perhaps it also needs a 'Fixes:' tag?
  • 83 occurrences: WARNING: Duplicate signature
  • 48 occurrences: WARNING: line length of X exceeds 100 columns
  • 17 occurrences: ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")'
  • 12 occurrences: ERROR: space required after that ','
  • 12 occurrences: ERROR: space prohibited before that ','

Example errors:

ERROR: Please use git commit description style 'commit <12+ chars of sha1> ("<title line>")' - ie: 'commit 6d71a9c61604 ("sched/fair: Fix EEVDF entity placement bug causing scheduling lag")'
#21: 
The issue reported in 6d71a9c61604 could possibly be explained by

Fix:

For a large stable merge like this, many checkpatch warnings are acceptable (especially "Unknown commit id" which is expected for upstream commits). However, the ERROR level issues should be fixed:

  1. Commit description style errors: Use full 12+ character SHA1s with title in quotes
  2. Spacing errors: Fix spacing around commas and operators
  3. Reported-by/Closes: Add Closes: tag after Reported-by: where applicable

Reproduce locally:

./scripts/checkpatch.pl --strict --ignore FILE_PATH_CHANGES --git 4c5c1a4c37fc..3aa27aa4deed

❌ dtb-check

Root cause: Ethernet PHY clocks property has too many cells in ipq5018-rdp432-c2.dtb.

Failure details:

/opt/actions-runner/_work/kernel-config/kernel-config/kernel/temp-out/arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dtb: 
ethernet-phy@7 (ethernet-phy-id004d.d0c0): clocks: [[9, 36], [9, 37]] is too long

The ethernet-phy@7 node has a clocks property with 2 clock entries [[9, 36], [9, 37]], but the binding expects fewer cells.

Fix:

Check the ethernet-phy-id004d.d0c0 binding to determine the correct number of clock entries. The error suggests the binding expects only 1 clock entry, not 2.

Locate the DTS file:

find arch/arm64/boot/dts/qcom -name "*ipq5018-rdp432-c2*"

Then fix the clocks property in the ethernet-phy@7 node to match the binding requirements.

Reproduce locally:

make -j$(nproc) O=out CHECK_DTBS=y arch/arm64/boot/dts/qcom/ipq5018-rdp432-c2.dtb

❌ check-uapi-headers

Root cause: Two UAPI headers have ABI changes — new fields/enumerators added.

Failure details:

error - 2/933 UAPI headers compatible with arm64 appear _not_ to be backwards compatible

==== ABI differences detected in include/linux/if_xdp.h ====
    [C] 'struct {__u16 csum_start; __u16 csum_offset; __u64 launch_time;}' changed:
      1 data member insertion:
        '__u32 reserved', at offset 32 (in bits)

==== ABI differences detected in include/linux/nl80211.h ====
    [C] 'enum nl80211_attrs' changed:
      11 enumerator insertions:
        'nl80211_attrs::NL80211_ATTR_EPP_PEER' value '346'
        'nl80211_attrs::NL80211_ATTR_UHR_CAPABILITY' value '347'
        ... (9 more)
      4 enumerator changes:
        'nl80211_attrs::NL80211_ATTR_MAX' from value '346' to '357'
        'nl80211_attrs::NUM_NL80211_ATTR' from value '347' to '358'
        'nl80211_attrs::__NL80211_ATTR_AFTER_LAST' from value '347' to '358'

Analysis:

These are additive changes only — new fields and enumerators are being added, not removed or reordered. This is backwards compatible and acceptable for UAPI.

  • if_xdp.h: A new __u32 reserved field is added to a struct
  • nl80211.h: 11 new NL80211 attributes are added to the enum, and the _MAX/_AFTER_LAST sentinels are updated accordingly

Verdict: These changes are acceptable — they extend the UAPI without breaking existing users. This is expected behavior for a stable kernel merge that includes new features.

Reproduce locally:

./scripts/check-uapi.sh -b 3aa27aa4deed -p 4c5c1a4c37fc -l uapi_errors.log

Verdict

This PR has 3 critical blockers that must be fixed before merge:

  1. 3231 commits missing required subject prefix — Every commit must start with UPSTREAM:, FROMLIST:, FROMGIT:, BACKPORT:, QCLINUX:, PENDING:, or WORKAROUND: because the target branch is qcom-6.18.y (not qcom-next or qcom-next-staging).

  2. 17 checkpatch ERROR-level issues — Commit description style errors and spacing errors must be fixed.

  3. 1 dtb-check error — ipq5018-rdp432-c2.dtb ethernet PHY clocks property has incorrect cell count.

Non-blocking issues:

  • 3460 "Unknown commit id" warnings — Expected for upstream stable commits; acceptable.
  • UAPI header changes — Additive only; backwards compatible; acceptable.
  • Other checkpatch warnings — Review recommended but not blocking for a large stable merge.

Recommendation: Fix the 3 critical blockers above before merging. Given the size of this PR (3232 commits), consider using an automated script to add the UPSTREAM: prefix to all commit subjects if this is indeed a stable kernel merge from upstream.

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37892828602

# Error File:Line PR-introduced? Root Cause
- No compilation errors N/A N/A Build completed successfully

Verdict

No build failures detected. The kernel compiled successfully for both standard and RT configurations. The workflow failure was caused by LAVA test job submission failures, not compilation errors.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37892828602

# Error File:Line PR-introduced? Root Cause
N/A No compilation errors N/A N/A All kernel builds completed successfully

Verdict

No compilation errors detected. Both the main kernel build and RT kernel build completed successfully. The workflow failure was caused by LAVA test job submission failures, not compilation issues.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37892828602

Build Status: ✅ SUCCESS

Both the standard kernel build and RT kernel build completed successfully with no compilation errors.

Workflow Failure Root Cause

The workflow was marked as failed due to LAVA test submission failures, not build failures.

Test Target Failure Reason
All 10 test targets LAVA server connectivity issues (timeouts and 502 Bad Gateway errors)

Error Details:

  • HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)
  • 502 Server Error: Bad Gateway for url: https://lava-oss.qualcomm.com/RPC2

Verdict

No compilation errors were introduced by this PR. The workflow failure is entirely due to infrastructure issues with the LAVA test server, which is unrelated to the code changes in the PR.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37892828602

Verdict

No compilation errors found. The kernel builds (both standard and RT) completed successfully. The workflow failure was caused by LAVA test job submission failures, not build errors.

Build Status:

  • ✅ Main kernel build: SUCCESS
  • ✅ RT kernel build: SUCCESS
  • ❌ Test job submissions: FAILED (infrastructure issue, not code issue)

Root Cause: The workflow was marked as failed because LAVA job submissions did not return numeric job IDs, indicating a test infrastructure problem rather than a compilation or code quality issue introduced by this PR.

Recommendation: The PR changes are safe from a compilation perspective. The test submission failures should be investigated separately as an infrastructure issue.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37892828602

# Error File:Line PR-introduced? Root Cause
N/A No compilation errors N/A N/A Build succeeded

Verdict

The build completed successfully. The workflow failure was caused by LAVA test job submission failures (infrastructure issue), not by compilation errors. All kernel builds (both standard and RT) completed without errors.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37892828602

Build Status: ✅ SUCCESS

Both the standard and RT kernel builds completed successfully with no compilation errors.

Build Type Status Details
Standard Build ✅ Pass Completed successfully, artifact uploaded (1.5GB)
RT Build ✅ Pass Completed successfully
All Flat Builds ✅ Pass 10 platform-specific builds completed

Test Status: ❌ FAILED (Infrastructure Issue)

All 10 LAVA test submissions failed due to infrastructure connectivity issues, not due to code problems.

Platform Test Status Failure Reason
hamoa-iot-evk ❌ Failed LAVA connection timeout
lemans-evk ❌ Failed LAVA connection timeout
monaco-evk ❌ Failed LAVA connection timeout
purwa-iot-evk ❌ Failed LAVA connection timeout
qcs615-ride ❌ Failed LAVA connection timeout
qcs6490-rb3gen2 ❌ Failed LAVA connection timeout
qcs8300-ride ❌ Failed LAVA connection timeout
qcs9100-ride-r3 ❌ Failed LAVA connection timeout
qrb2210-rb1 ❌ Failed LAVA connection timeout
shikra-iqs-evk ❌ Failed LAVA connection timeout

Error Message (all platforms):

Unable to connect: HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)

Verdict

0 compilation errors found. The PR introduces no build failures. All kernel builds completed successfully. The workflow failure was caused by LAVA test infrastructure connectivity issues (connection timeouts to lava-oss.qualcomm.com), not by any code changes in the PR.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37892828602

# Error File:Line PR-introduced? Root Cause
N/A No compilation errors N/A N/A Build succeeded; workflow failed due to LAVA test submission timeout

Verdict

No compilation errors found. The kernel build completed successfully. The workflow failure was caused by a LAVA test infrastructure timeout (HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out), not by any code issues in the PR.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37892828602

Build Status: ✅ ALL BUILDS PASSED

The kernel compilation completed successfully for all target configurations:

  • Base build: ✅ Success
  • RT build: ✅ Success
  • All platform builds (hamoa, lemans, monaco, purwa, qcs615, qcs6490-rb3gen2, qcs8300, qcs9100, qrb2210, shikra): ✅ Success

Test Status: ❌ ALL TESTS FAILED

All LAVA test jobs failed due to infrastructure timeout, not code issues:

Unable to connect: HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)
# Error File:Line PR-introduced? Root Cause
1 LAVA connection timeout N/A No Infrastructure issue: LAVA server unreachable during test submission

Verdict

Zero compilation errors. The workflow failure is caused by LAVA test infrastructure timeout, not by any code changes in this PR. All kernel builds completed successfully.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37892828602

✅ Build Status: SUCCESS

The kernel compilation completed successfully for both standard and RT builds. No compilation errors were detected.

❌ Workflow Failure Cause: Test Submission Timeout

The workflow was marked as failed due to LAVA test job submission failures, not build errors. All test jobs failed with:

Unable to connect: HTTPSConnectionPool(host='lava-oss.qualcomm.com', port=443): Read timed out. (read timeout=20.0)
Component Status Details
Kernel Build (standard) ✅ PASS Completed successfully
Kernel Build (RT) ✅ PASS Completed successfully
LAVA Test Submission ❌ FAIL Connection timeout to lava-oss.qualcomm.com

Verdict

No compilation errors found. The PR builds cleanly. The workflow failure is due to infrastructure issues (LAVA server connectivity), not code problems introduced by this PR.

📎 Detailed analysis: Full report

@qlijarvis

Copy link
Copy Markdown

🔨 Build Failure Analysis — PR #1158

PR: #1158
Build run: https://github.com/qualcomm-linux/kernel-config/actions/runs/37892828602

# Error File:Line PR-introduced? Root Cause
N/A No compilation errors N/A N/A Build succeeded

Verdict

The kernel build completed successfully with no compilation errors. The workflow failure was caused by LAVA test job submission failures (infrastructure issue), not by build errors. This PR updates the stable kernel from v6.18.44 to v6.18.52.

📎 Detailed analysis: Full report

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.