]> git.ipfire.org Git - thirdparty/openembedded/openembedded-core.git/commit
linux-yocto/6.18: beaglebone black: boot and graphics fixes
authorBruce Ashfield <bruce.ashfield@gmail.com>
Fri, 6 Feb 2026 20:27:25 +0000 (15:27 -0500)
committerRichard Purdie <richard.purdie@linuxfoundation.org>
Wed, 11 Feb 2026 12:30:37 +0000 (12:30 +0000)
commitfc75960c7f0b028b85c9fcf09756964a3d28eb78
tree2268d6aac95b7f0a125bc6d82b943d54860defdf
parent32d4a635981d23905c92f4aadd758e74657474d4
linux-yocto/6.18: beaglebone black: boot and graphics fixes

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>
meta/recipes-kernel/linux/linux-yocto-rt_6.18.bb
meta/recipes-kernel/linux/linux-yocto-tiny_6.18.bb
meta/recipes-kernel/linux/linux-yocto_6.18.bb