Integrating the following commit(s) to linux-yocto/6.18:
1/2 [
Author: Kevin Hao
Email: haokexin@gmail.com
Subject: net: cpsw_new: Execute ndo_set_rx_mode callback in a work queue
Date: Wed, 4 Feb 2026 14:27:57 +0800
commit
c0b5dc73a38f954e780f93a549b8fe225235c07a from net
Commit
1767bb2d47b7 ("ipv6: mcast: Don't hold RTNL for
IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP.") removed the RTNL lock for
IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP operations. However, this
change triggered the following call trace on my BeagleBone Black board:
WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124, CPU#0: rpcbind/496
RTNL: assertion failed at net/8021q/vlan_core.c (236)
Modules linked in:
CPU: 0 UID: 997 PID: 496 Comm: rpcbind Not tainted 6.19.0-rc6-next-
20260122-yocto-standard+ #8 PREEMPT
Hardware name: Generic AM33XX (Flattened Device Tree)
Call trace:
unwind_backtrace from show_stack+0x28/0x2c
show_stack from dump_stack_lvl+0x30/0x38
dump_stack_lvl from __warn+0xb8/0x11c
__warn from warn_slowpath_fmt+0x130/0x194
warn_slowpath_fmt from vlan_for_each+0x120/0x124
vlan_for_each from cpsw_add_mc_addr+0x54/0xd8
cpsw_add_mc_addr from __hw_addr_ref_sync_dev+0xc4/0xec
__hw_addr_ref_sync_dev from __dev_mc_add+0x78/0x88
__dev_mc_add from igmp6_group_added+0x84/0xec
igmp6_group_added from __ipv6_dev_mc_inc+0x1fc/0x2f0
__ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4
__ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168
do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8
ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c
do_sock_setsockopt from __sys_setsockopt+0x84/0xac
__sys_setsockopt from ret_fast_syscall+0x0/0x5
This trace occurs because vlan_for_each() is called within
cpsw_ndo_set_rx_mode(), which expects the RTNL lock to be held.
Since modifying vlan_for_each() to operate without the RTNL lock is not
straightforward, and because ndo_set_rx_mode() is invoked both with and
without the RTNL lock across different code paths, simply adding
rtnl_lock() in cpsw_ndo_set_rx_mode() is not a viable solution.
To resolve this issue, we opt to execute the actual processing within
a work queue, following the approach used by the icssg-prueth driver.
Fixes: 1767bb2d47b7 ("ipv6: mcast: Don't hold RTNL for IPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP.")
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20260203-bbb-v5-1-ea0ea217a85c@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
2/2 [
Author: Kevin Hao
Email: haokexin@gmail.com
Subject: drm/tilcdc: Set preferred depth
Date: Wed, 4 Feb 2026 14:27:58 +0800
The commit
c91acda3a380 ("drm/gem: Check for valid formats") adds a
check for valid pixel formats on drm_gem_fb_create(), but this breaks
the X server on the beaglebone black board.
We have set 'DefaultDepth' to 16 in our xorg.conf. In the X modesetting
driver, the drmmode_get_default_bpp() is used to guess the default
depth/bpp. First it tries to get them via DRM_CAP_DUMB_PREFERRED_DEPTH
ioctl, and if it fail, then try to create a FB with 'depth = 24' and
'bpp = 32' to check whether this depth/dpp is a valid combo. Before the
kernel commit
c91acda3a380, the FB always can be created successfully.
This will avoid the bpp to be set to 24 forcibly. But after kernel
commit
c91acda3a380, the FB will not be created successfully due to the
check of the valid pixel format. Then the bpp is set to 24, but the
'depth = 16' and 'bpp = 24' combo is not a valid pixel format.
Fix this issue by explicitly setting the preferred_depth in this driver.
With this change, the modesetting driver would choose the correct
depth/bpp combo based on our setting in xorg.conf.
Fixes: c91acda3a380 ("drm/gem: Check for valid formats")
Cc: stable@vger.kernel.org
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Link: https://lore.kernel.org/r/20240317033918.535716-1-haokexin@gmail.com/
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
}
-SRCREV_machine ?= "4cab0751277e181dc5d1b163b0e85f734725adfb"
-SRCREV_meta ?= "c809ea8463218ea51f3aee6a9471ef593407d4cf"
+SRCREV_machine ?= "1292f3b6fc58f2b157bea9c8703188fd1f4ccd50"
+SRCREV_meta ?= "240c73660dec670caa087090b0a1b2bfb0b8b308"
SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https \
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-6.18;destsuffix=${KMETA};protocol=https"
KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
-SRCREV_machine ?= "bafdbc156dae11ada271e112c2e331d9f9b2653d"
-SRCREV_meta ?= "c809ea8463218ea51f3aee6a9471ef593407d4cf"
+SRCREV_machine ?= "13406870d76895304abb5722793d4abe03b40549"
+SRCREV_meta ?= "240c73660dec670caa087090b0a1b2bfb0b8b308"
PV = "${LINUX_VERSION}+git"
KBRANCH:qemuloongarch64 ?= "v6.18/standard/base"
KBRANCH:qemumips64 ?= "v6.18/standard/mti-malta"
-SRCREV_machine:qemuarm ?= "3247ad9a8d55ba35c8707f44ff4e51c434a1feb7"
-SRCREV_machine:qemuarm64 ?= "bafdbc156dae11ada271e112c2e331d9f9b2653d"
-SRCREV_machine:qemuloongarch64 ?= "bafdbc156dae11ada271e112c2e331d9f9b2653d"
+SRCREV_machine:qemuarm ?= "b36eb7592b944efb3f0c022a25bffb30a74f429b"
+SRCREV_machine:qemuarm64 ?= "13406870d76895304abb5722793d4abe03b40549"
+SRCREV_machine:qemuloongarch64 ?= "13406870d76895304abb5722793d4abe03b40549"
SRCREV_machine:qemumips ?= "62ea92a539f58803a222be98b81118403074206e"
-SRCREV_machine:qemuppc ?= "bafdbc156dae11ada271e112c2e331d9f9b2653d"
-SRCREV_machine:qemuriscv64 ?= "bafdbc156dae11ada271e112c2e331d9f9b2653d"
-SRCREV_machine:qemuriscv32 ?= "bafdbc156dae11ada271e112c2e331d9f9b2653d"
-SRCREV_machine:qemux86 ?= "bafdbc156dae11ada271e112c2e331d9f9b2653d"
-SRCREV_machine:qemux86-64 ?= "bafdbc156dae11ada271e112c2e331d9f9b2653d"
+SRCREV_machine:qemuppc ?= "13406870d76895304abb5722793d4abe03b40549"
+SRCREV_machine:qemuriscv64 ?= "13406870d76895304abb5722793d4abe03b40549"
+SRCREV_machine:qemuriscv32 ?= "13406870d76895304abb5722793d4abe03b40549"
+SRCREV_machine:qemux86 ?= "13406870d76895304abb5722793d4abe03b40549"
+SRCREV_machine:qemux86-64 ?= "13406870d76895304abb5722793d4abe03b40549"
SRCREV_machine:qemumips64 ?= "9fb4ff0187c85426f21fd40d4c61b742800f65c4"
-SRCREV_machine ?= "bafdbc156dae11ada271e112c2e331d9f9b2653d"
-SRCREV_meta ?= "c809ea8463218ea51f3aee6a9471ef593407d4cf"
+SRCREV_machine ?= "13406870d76895304abb5722793d4abe03b40549"
+SRCREV_meta ?= "240c73660dec670caa087090b0a1b2bfb0b8b308"
# set your preferred provider of linux-yocto to 'linux-yocto-upstream', and you'll
# get the <version>/base branch, which is pure upstream -stable, and the same
projects / thirdparty / openembedded / openembedded-core-contrib.git / commitdiff
