Skip to content

[Deepin-Kernel-SIG] [linux 6.6-y] [Upstream] Update kernel base to 6.6.100 #977

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 113 commits into from
Jul 28, 2025

Conversation

opsiff
Copy link
Member

@opsiff opsiff commented Jul 27, 2025

Update kernel base to 6.6.100.

Summary by Sourcery

Update kernel base to 6.6.100, merging the upstream stable 6.6.100 release which includes numerous driver fixes, subsystem improvements, and architecture support enhancements.

Bug Fixes:

  • Fix L2CAP MTU negotiation per Bluetooth 6.1 spec for ERTM channels
  • Resolve USB hub resume path to allow SS link training before runtime suspend
  • Correct SPI validation to support octal mode in both TX and RX
  • Address various resource handling and reference bugs in RXRPC, SMB oplock breaks, and wangxun Ethernet driver

Enhancements:

  • Add ARM64 SME CPU feature detection and matching in arm64 ELF HWCAP
  • Enhance Bluetooth btusb firmware loader to extract board IDs and unify NVM naming
  • Automate VLAN ID 0 hardware filter addition/removal on device up/down
  • Improve PWM regulator boot-on initialization to maintain output stability
  • Support mux-state selection and deselection in OMAP I²C driver
  • Validate Comedi insnlist lengths and pad minimal sample counts
  • Strengthen nf_conntrack hash insertion by ordering confirmed‐bit sets after RCU insertion
  • Refine io_uring connect logic to handle in-progress errors and retrieve socket error codes

Build:

  • Bump kernel version macros to SUBLEVEL 100

Copy link

sourcery-ai bot commented Jul 27, 2025

Reviewer's Guide

This PR updates the kernel base to 6.6.100 by bumping the version in Makefile and merging a large set of upstream commits. The changes include driver fixes and feature enhancements across Bluetooth (QCA firmware naming), USB (Tegra XUSB, core hub resume), networking (VLAN zero filtering, QFQ scheduler, netfilter), various platform drivers (PWM regulator, I²C mux, Comedi), arch support (ARM64 SME), BPF JIT and selftests, plus numerous cleanups and small fixes.

Class diagram for QCA Bluetooth firmware naming update

classDiagram
    class qca_version {
        +u16 flag
        +u16 chip_id
        +u16 platform_id
        +u32 rom_version
        +u32 ram_version
    }
    class btusb {
        +qca_extract_board_id(ver: qca_version): u16
        +btusb_generate_qca_nvm_name(fwname, max_size, ver: qca_version)
    }
    qca_version <.. btusb : uses
Loading

Class diagram for Tegra XUSB padctl changes

classDiagram
    class tegra_xusb_padctl_soc {
        +bool trk_hw_mode
        +bool trk_update_on_idle
    }
    class tegra_xusb_padctl {
        +tegra_xusb_padctl_soc *soc
        +lock
    }
    class tegra_xusb_usb2_port {
        +regulator supply
    }
    tegra_xusb_padctl_soc <.. tegra_xusb_padctl : used by
    tegra_xusb_usb2_port <.. tegra_xusb_padctl : used in methods
Loading

Class diagram for Comedi insnlist ioctl and length check

classDiagram
    class comedi_device {
        +class_dev
    }
    class comedi_insn {
        +unsigned int n
        +unsigned int *data
        +unsigned int insn
    }
    class comedi_fops {
        +do_insnlist_ioctl(dev: comedi_device, ...)
        +check_insnlist_len(dev: comedi_device, n_insns: unsigned int): int
    }
    comedi_device <.. comedi_fops : used by
    comedi_insn <.. comedi_fops : used by
Loading

Class diagram for PWM regulator boot_on initialization

classDiagram
    class pwm_regulator_data {
        +pwm
        +enb_gpio
    }
    class regulator_init_data {
        +constraints.boot_on
    }
    class pwm_regulator {
        +pwm_regulator_init_boot_on(pdev, drvdata: pwm_regulator_data, init_data: regulator_init_data): int
    }
    pwm_regulator_data <.. pwm_regulator : used by
    regulator_init_data <.. pwm_regulator : used by
Loading

Class diagram for VLAN device event and VLAN 0 auto filter

classDiagram
    class net_device {
        +features
        +name
        +vlan_info
    }
    class vlan_info {
        +auto_vid0: bool
    }
    class vlan {
        +vlan_vid0_add(dev: net_device)
        +vlan_vid0_del(dev: net_device)
        +vlan_device_event(...)
    }
    net_device <.. vlan : used by
    vlan_info <.. vlan : used by
Loading

Class diagram for ARM64 SME feature detection

classDiagram
    class arm64_cpu_capabilities {
    }
    class has_sme_feature {
        +has_sme_feature(cap: arm64_cpu_capabilities, scope: int): bool
    }
    arm64_cpu_capabilities <.. has_sme_feature : used by
Loading

Class diagram for Wangxun wx_rx_buffer and wx_cb changes

classDiagram
    class wx_cb {
        +dma_addr_t dma
        +u16 append_cnt
        +bool dma_released
    }
    class wx_rx_buffer {
        +struct sk_buff *skb
        +dma_addr_t dma
        +struct page *page
        +unsigned int page_offset
    }
Loading

Class diagram for aspeed_lpc_snoop_channel enable/disable logic

classDiagram
    class aspeed_lpc_snoop_channel {
        +bool enabled
        +kfifo fifo
        +wait_queue_head_t wq
        +miscdevice miscdev
    }
    class aspeed_lpc_snoop {
        +aspeed_lpc_snoop_channel chan[]
        +regmap
    }
    aspeed_lpc_snoop_channel <.. aspeed_lpc_snoop : used by
Loading

Class diagram for netfilter conntrack confirmation and status bit

classDiagram
    class nf_conn {
        +unsigned long status
        +unsigned long timeout
    }
    class nf_conntrack_core {
        +__nf_conntrack_confirm(skb)
        +nf_ct_resolve_clash_harder(skb, repl_idx)
    }
    nf_conn <.. nf_conntrack_core : used by
Loading

Class diagram for I2C OMAP mux state integration

classDiagram
    class omap_i2c_dev {
        +mux_state: struct mux_state *
    }
    class mux_state {
    }
    omap_i2c_dev o-- mux_state
Loading

Class diagram for net/bluetooth/l2cap_core.c MTU adjustment

classDiagram
    class l2cap_chan {
        +u16 imtu
        +u16 omtu
        +u8 mode
    }
    class l2cap_core {
        +l2cap_parse_conf_req(chan: l2cap_chan, ...)
    }
    l2cap_chan <.. l2cap_core : used by
Loading

Class diagram for net/bluetooth/smp.c command handling

classDiagram
    class smp_chan {
        +unsigned long allow_cmd
    }
    class smp {
        +smp_sig_channel(chan: l2cap_chan, skb)
    }
    smp_chan <.. smp : used by
Loading

Class diagram for net/8021q/vlan.c VLAN info

classDiagram
    class vlan_info {
        +bool auto_vid0
    }
    class net_device {
        +vlan_info *vlan_info
    }
    vlan_info <.. net_device : used by
Loading

Class diagram for net/packet/af_packet.c tpacket_snd changes

classDiagram
    class packet_sock {
        +struct tx_ring
        +struct sk_buff *skb
        +mutex pg_vec_lock
    }
    class tpacket_snd {
        +tpacket_snd(po: packet_sock, msg: msghdr)
    }
    packet_sock <.. tpacket_snd : used by
Loading

Class diagram for net/sched/sch_qfq.c QFQ class and aggregate

classDiagram
    class qfq_class {
        +qfq_aggregate *agg
        +common
    }
    class qfq_aggregate {
        +u32 class_weight
        +u32 lmax
    }
    qfq_class o-- qfq_aggregate
Loading

Class diagram for net/sched/sch_htb.c htb_prio and htb_class

classDiagram
    class htb_prio {
        +row
        +ptr
        +last_ptr_id
    }
    class htb_class {
    }
    htb_prio <.. htb_class : used by
Loading

Class diagram for net/rxrpc/recvmsg.c call release handling

classDiagram
    class rxrpc_call {
        +flags
        +recvmsg_link
        +user_mutex
    }
    class rxrpc_recvmsg {
        +rxrpc_recvmsg(sock, msg, len, ...)
    }
    rxrpc_call <.. rxrpc_recvmsg : used by
Loading

Class diagram for net/bridge/br_switchdev.c multicast IGMP check

classDiagram
    class net_bridge_port {
        +flags
        +hwdom
    }
    class br_switchdev {
        +nbp_switchdev_can_offload_tx_fwd(p: net_bridge_port, skb)
    }
    net_bridge_port <.. br_switchdev : used by
Loading

Class diagram for drivers/iio/adc/max1363.c mode list changes

classDiagram
    class max1363_modes {
    }
    class max1236_mode_list {
        +max1363_modes[]
    }
    class max1238_mode_list {
        +max1363_modes[]
    }
    max1363_modes <.. max1236_mode_list : used by
    max1363_modes <.. max1238_mode_list : used by
Loading

Class diagram for drivers/iio/adc/stm32-adc-core.c irq handler

classDiagram
    class stm32_adc_priv {
        +irq[]
        +cfg
    }
    class stm32_adc_irq_probe {
        +stm32_adc_irq_probe(pdev, priv: stm32_adc_priv)
    }
    stm32_adc_priv <.. stm32_adc_irq_probe : used by
Loading

Class diagram for drivers/i2c/busses/i2c-stm32.c DMA mapping

classDiagram
    class stm32_i2c_dma {
        +chan_using
        +dma_buf
        +dma_len
        +dma_data_dir
    }
    class stm32_i2c_prep_dma_xfer {
        +stm32_i2c_prep_dma_xfer(dev, dma: stm32_i2c_dma, ...)
    }
    stm32_i2c_dma <.. stm32_i2c_prep_dma_xfer : used by
Loading

Class diagram for drivers/i2c/busses/i2c-stm32f7.c DMA callback

classDiagram
    class stm32f7_i2c_dev {
        +dma: stm32_i2c_dma *
        +dev
    }
    class stm32_i2c_dma {
        +chan_using
        +dma_buf
        +dma_len
        +dma_data_dir
    }
    class stm32f7_i2c_dma_callback {
        +stm32f7_i2c_dma_callback(arg)
    }
    stm32f7_i2c_dev <.. stm32f7_i2c_dma_callback : used by
    stm32_i2c_dma <.. stm32f7_i2c_dma_callback : used by
Loading

Class diagram for drivers/net/ethernet/wangxun/libwx/wx_lib.c rx buffer changes

classDiagram
    class wx_rx_buffer {
        +struct sk_buff *skb
        +dma_addr_t dma
        +struct page *page
        +unsigned int page_offset
    }
Loading

Class diagram for drivers/net/ethernet/wangxun/libwx/wx_hw.c rx ring reset

classDiagram
    class wx_ring {
        +next_to_clean
        +next_to_use
        +rx_buffer_info
        +count
    }
    class wx {
    }
    wx_ring <.. wx : used by
Loading

Class diagram for drivers/net/ethernet/xilinx/xilinx_emaclite.c aligned read

classDiagram
    class xemaclite_aligned_read {
        +xemaclite_aligned_read(src_ptr, dest_ptr, length)
    }
Loading

Class diagram for drivers/usb/serial/ftdi_sio.c NDI Emguide Gemini support

classDiagram
    class ftdi_sio_ids {
        +FTDI_NDI_VID
        +FTDI_NDI_EMGUIDE_GEMINI_PID
    }
    class id_table_combined {
        +id_table_combined[]
    }
    ftdi_sio_ids <.. id_table_combined : used by
Loading

Class diagram for drivers/usb/serial/option.c Telit and Foxconn device IDs

classDiagram
    class option_ids {
        +option_ids[]
    }
Loading

Class diagram for drivers/usb/core/hub.c hub resume and post_resume_work

classDiagram
    class usb_hub {
        +post_resume_work
        +hdev
        +intfdev
    }
    class hub_post_resume {
        +hub_post_resume(ws)
    }
    usb_hub <.. hub_post_resume : used by
Loading

Class diagram for drivers/usb/gadget/configfs.c webusb_landingPage_store

classDiagram
    class config_item {
    }
    class webusb_landingPage_store {
        +webusb_landingPage_store(item: config_item, page, len)
    }
    config_item <.. webusb_landingPage_store : used by
Loading

Class diagram for drivers/usb/musb/musb_gadget.c gadget stop/disconnect

classDiagram
    class musb {
        +g: usb_gadget
        +controller
    }
    class usb_gadget {
        +state
    }
    musb <.. usb_gadget : uses
Loading

Class diagram for drivers/thunderbolt/usb4.c and tb.h set_wake changes

classDiagram
    class tb_switch {
    }
    class usb4_switch_set_wake {
        +usb4_switch_set_wake(sw: tb_switch, flags: unsigned int, runtime: bool)
    }
    tb_switch <.. usb4_switch_set_wake : used by
Loading

Class diagram for drivers/thunderbolt/switch.c set_wake changes

classDiagram
    class tb_switch {
    }
    class tb_switch_set_wake {
        +tb_switch_set_wake(sw: tb_switch, flags: unsigned int, runtime: bool)
    }
    tb_switch <.. tb_switch_set_wake : used by
Loading

Class diagram for drivers/soundwire/amd_manager.c suspend and work sync

classDiagram
    class amd_sdw_manager {
        +amd_sdw_work
        +power_mode_mask
    }
    class amd_suspend {
        +amd_suspend(dev)
    }
    amd_sdw_manager <.. amd_suspend : used by
Loading

Class diagram for drivers/hid/hid-core.c report buffer allocation

classDiagram
    class hid_report {
        +id
        +type
    }
    class hid_device {
        +ll_driver
    }
    class hid_alloc_report_buf {
        +hid_alloc_report_buf(report: hid_report, flags)
    }
    class __hid_request {
        +__hid_request(hid: hid_device, report: hid_report, reqtype)
    }
    hid_report <.. hid_alloc_report_buf : used by
    hid_report <.. __hid_request : used by
    hid_device <.. __hid_request : used by
Loading

Class diagram for drivers/nvmem/imx-ocotp-ele.c and imx-ocotp.c mac-address swap

classDiagram
    class u_boot_env {
    }
    class imx_ocotp_cell_pp {
        +imx_ocotp_cell_pp(context, id, index, buf, bytes)
    }
    u_boot_env <.. imx_ocotp_cell_pp : used by
Loading

Class diagram for drivers/nvmem/u-boot-env.c CRC32 parsing

classDiagram
    class u_boot_env {
        +parse()
    }
Loading

Class diagram for drivers/net/ethernet/mellanox/mlx5/core/en_rx.c LRO update

classDiagram
    class mlx5e_lro_update_hdr {
        +mlx5e_lro_update_hdr(skb, cqe, cqe_bcnt): unsigned int
    }
Loading

Class diagram for drivers/net/ethernet/intel/ice/ice_lag.c switchdev running check

classDiagram
    class ice_pf {
        +lag: ice_lag *
    }
    class ice_lag {
        +upper_netdev
    }
    ice_pf o-- ice_lag
Loading

Class diagram for drivers/net/hyperv/netvsc_drv.c bonding flags

classDiagram
    class net_device {
        +flags
        +priv_flags
    }
Loading

Class diagram for drivers/mmc/host/sdhci_am654.c quirks2 update

classDiagram
    class sdhci_pltfm_data {
        +quirks2
    }
Loading

Class diagram for drivers/mmc/host/bcm2835.c dma_unmap_sg fix

classDiagram
    class bcm2835_host {
        +dma_chan
    }
Loading

Class diagram for fs/isofs/inode.c file type validation

classDiagram
    class inode {
        +i_mode
        +i_op
        +i_data
        +i_rdev
        +i_ino
    }
Loading

Class diagram for fs/smb/client/file.c oplock break superblock ref

classDiagram
    class cifsFileInfo {
        +dentry
        +oplock_break
    }
    class inode {
        +i_sb
    }
    class cifs_sb_info {
    }
    cifsFileInfo <.. inode : uses
    inode <.. cifs_sb_info : uses
Loading

Class diagram for fs/smb/client/smb2ops.c crypt_message wait

classDiagram
    class TCP_Server_Info {
    }
    class crypt_message {
        +crypt_message(server: TCP_Server_Info, num_rqst, ...)
    }
    TCP_Server_Info <.. crypt_message : used by
Loading

Class diagram for kernel/bpf/helpers.c bpf_bprintf_prepare pointer handling

classDiagram
    class bpf_bprintf_prepare {
        +bpf_bprintf_prepare(fmt, fmt_size, raw_args, ...)
    }
Loading

Class diagram for kernel/cgroup/legacy_freezer.c cgroup_freezing

classDiagram
    class freezer {
        +state
    }
    class task_struct {
        +freezer: freezer *
    }
    class cgroup_freezing {
        +cgroup_freezing(task: task_struct): bool
    }
    freezer <.. task_struct : used by
    task_struct <.. cgroup_freezing : used by
Loading

Class diagram for kernel/trace/trace_events.c event registration locking

classDiagram
    class trace_event_call {
        +list
        +flags
        +refcnt
    }
    class trace_array {
    }
    class __register_event {
        +__register_event(call: trace_event_call, mod)
    }
    class __trace_add_event_dirs {
        +__trace_add_event_dirs(tr: trace_array)
    }
    trace_event_call <.. __register_event : used by
    trace_event_call <.. __trace_add_event_dirs : used by
Loading

Class diagram for io_uring/net.c io_connect changes

classDiagram
    class io_kiocb {
        +flags
        +file
    }
    class io_connect {
        +io_connect(req: io_kiocb, issue_flags)
    }
    io_kiocb <.. io_connect : used by
Loading

Class diagram for io_uring/poll.c poll check events

classDiagram
    class io_kiocb {
        +cqe
        +apoll_events
    }
    class io_poll_check_events {
        +io_poll_check_events(req: io_kiocb, ts)
    }
    io_kiocb <.. io_poll_check_events : used by
Loading

Class diagram for fs/cachefiles/io.c and ondemand.c write iter

classDiagram
    class cachefiles_object {
    }
    class cachefiles_ondemand_fd_write_iter {
        +cachefiles_ondemand_fd_write_iter(kiocb, iter)
    }
    class __cachefiles_write {
        +__cachefiles_write(object: cachefiles_object, file, pos, iter, ...)
    }
    cachefiles_object <.. cachefiles_ondemand_fd_write_iter : used by
    cachefiles_object <.. __cachefiles_write : used by
Loading

Class diagram for drivers/md/dm-bufio.c __evict_many cond_resched

classDiagram
    class dm_bufio_client {
    }
    class __evict_many {
        +__evict_many(c: dm_bufio_client, ...)
    }
    dm_bufio_client <.. __evict_many : used by
Loading

Class diagram for drivers/comedi/drivers.c dio config and update state

classDiagram
    class comedi_insn {
        +chanspec
    }
    class comedi_subdevice {
        +n_chan
        +io_bits
        +subdev_flags
        +insn_bits
    }
    class comedi_dio_insn_config {
        +comedi_dio_insn_config(dev, insn: comedi_insn, data, mask)
    }
    class comedi_dio_update_state {
        +comedi_dio_update_state(s: comedi_subdevice, data)
    }
    comedi_insn <.. comedi_dio_insn_config : used by
    comedi_subdevice <.. comedi_dio_update_state : used by
Loading

Class diagram for drivers/comedi/drivers/aio_iiro_16.c IRQ validation

classDiagram
    class comedi_device {
        +board_name
    }
    class comedi_devconfig {
        +options[]
    }
    class aio_iiro_16_attach {
        +aio_iiro_16_attach(dev: comedi_device, it: comedi_devconfig)
    }
    comedi_device <.. aio_iiro_16_attach : used by
    comedi_devconfig <.. aio_iiro_16_attach : used by
Loading

Class diagram for drivers/comedi/drivers/das16m1.c IRQ validation

classDiagram
    class comedi_device {
        +board_name
    }
    class comedi_devconfig {
        +options[]
    }
    class das16m1_attach {
        +das16m1_attach(dev: comedi_device, it: comedi_devconfig)
    }
    comedi_device <.. das16m1_attach : used by
    comedi_devconfig <.. das16m1_attach : used by
Loading

Class diagram for drivers/comedi/drivers/das6402.c IRQ validation

classDiagram
    class comedi_device {
        +board_name
    }
    class comedi_devconfig {
        +options[]
    }
    class das6402_attach {
        +das6402_attach(dev: comedi_device, it: comedi_devconfig)
    }
    comedi_device <.. das6402_attach : used by
    comedi_devconfig <.. das6402_attach : used by
Loading

Class diagram for drivers/comedi/drivers/pcl812.c IRQ validation

classDiagram
    class comedi_device {
        +board_name
    }
    class comedi_devconfig {
        +options[]
    }
    class pcl812_attach {
        +pcl812_attach(dev: comedi_device, it: comedi_devconfig)
    }
    comedi_device <.. pcl812_attach : used by
    comedi_devconfig <.. pcl812_attach : used by
Loading

File-Level Changes

Change Details Files
Version bump to 6.6.100
  • Incremented PATCHLEVEL in Makefile to SUBLEVEL 100
Makefile
Refactor QCA board ID extraction and NVM naming
  • Added qca_extract_board_id() helper
  • Rewrote btusb_generate_qca_nvm_name() to use helper and simplified snprintf logic
drivers/bluetooth/btusb.c
Tegra XUSB pad controller updates
  • Unify TRK_HW_MODE and CYA_TRK_CODE_UPDATE_ON_IDLE handling
  • Introduce trk_update_on_idle flag in soc struct
  • Revamp OTG ID override API to pass port and manage regulator enable/disable
drivers/phy/tegra/xusb-tegra186.c
drivers/phy/tegra/xusb.h
Hardware VLAN filter zero VLAN handling
  • Extracted VLAN 0 add/delete to vlan_vid0_add()/vlan_vid0_del()
  • Replaced inline NETDEV_UP/DOWN blocks in notifier with these helpers
  • Added auto_vid0 flag to vlan_info
net/8021q/vlan.c
net/8021q/vlan.h
PWM regulator duty-cycle and boot-on improvements
  • Adjust duty cycle when PWM disabled
  • Add pwm_regulator_init_boot_on() to preserve duty cycle on enable
  • Call new init in probe sequence
drivers/regulator/pwm-regulator.c
USB core hub post-resume training delay
  • Define USB_SS_PORT_U0_WAKE_TIME and post_resume_work
  • Schedule delayed work after HUB_RESUME for SS hubs
  • Flush work in quiesce, init in probe
drivers/usb/core/hub.c
drivers/usb/core/hub.h
COMEDI insnlist validation and padding
  • Enforce MIN_SAMPLES padding after write insns
  • Add check_insnlist_len() to block excessive lists
  • Apply same MIN_SAMPLES logic in do_insn_ioctl
drivers/comedi/comedi_fops.c
OMAP I²C mux selection support
  • Obtain mux_state if 'mux-states' property present
  • Select/deselect mux in probe error paths and remove
drivers/i2c/busses/i2c-omap.c
QFQ scheduler redundant update avoidance
  • Capture old weight and lmax under sch_tree_lock
  • Compare against new values to skip no-op updates
  • Use old_weight in delta_w calculation
net/sched/sch_qfq.c
Netfilter conntrack confirmed flag ordering
  • Delay set_bit(IPS_CONFIRMED_BIT) until after __nf_conntrack_hash_insert()
  • Insert smp_mb__before_atomic() barriers around bit set
net/netfilter/nf_conntrack_core.c
ARM64 SME feature probing and hwcap updates
  • Add has_sme_feature() under CONFIG_ARM64_SME
  • Switch HWCAP_CAP entries to HWCAP_CAP_MATCH_ID
arch/arm64/kernel/cpufeature.c
BPF JIT PLT entry NULL target safety
  • Treat NULL target as ret to avoid stale execution
  • Use target ?: ret assignment in bpf_jit_plt()
arch/s390/net/bpf_jit_comp.c

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@deepin-ci-robot
Copy link

deepin pr auto review

代码审查反馈:

  1. Makefile中,版本号从6.99更新到6.100,确认是否有必要更新版本号,以及是否遵循了版本号的更新规则。

  2. imx8mm-verdin.dtsi文件中,新增了regulator-always-on属性,确认这是否符合硬件设计要求。

  3. imx8mp-venice-gw74xx.dts文件中,将spi-max-frequency36MHz降低到25MHz,确认这是否会影响SPI设备的正常工作。

  4. px30-ringneck.dtsi文件中,新增了cs-gpios属性,并指定了GPIO引脚,确认这是否符合硬件设计要求。

  5. cpufeature.c文件中,对SME(Software Memory Extension)特性的支持进行了修改,确认这是否符合硬件和软件的兼容性要求。

  6. bpf_jit_comp.c文件中,对PLT(Procedure Linkage Table)的处理进行了修改,确认这是否会影响BPF程序的执行。

  7. xen.c文件中,修改了kvm_xen_schedop_poll函数的错误处理逻辑,确认这是否符合错误处理的最佳实践。

  8. blk-sysfs.c文件中,移除了blk_unregister_queue函数中对kobject_put的调用,确认这是否会影响设备的正确注销。

  9. domain_governor.c文件中,对CPU电源管理的逻辑进行了修改,确认这是否会影响系统的电源管理策略。

  10. btusb.c文件中,新增了对蓝牙设备板ID的处理逻辑,确认这是否符合蓝牙设备的规范。

  11. comedi_fops.c文件中,对do_insnlist_ioctldo_insn_ioctl函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  12. drivers.c文件中,对comedi_dio_insn_config函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  13. aio_iiro_16.c文件中,对aio_iiro_16_attach函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  14. das16m1.c文件中,对das16m1_attach函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  15. das6402.c文件中,对das6402_attach函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  16. pcl812.c文件中,对pcl812_attach函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  17. nbpfaxi.c文件中,对nbpf_probe函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  18. gfx_v8_0.c文件中,对gfx_v8_0_kcq_init_queue函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  19. hid-core.c文件中,对hid_alloc_report_buf函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  20. corsair-cpro.c文件中,对ccp_raw_event函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  21. i2c-omap.c文件中,新增了对I2C设备的mux状态的支持,确认这是否符合硬件设计要求。

  22. i2c-stm32.c文件中,对stm32_i2c_prep_dma_xfer函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  23. i2c-stm32f7.c文件中,对stm32f7_i2c_dma_callback函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  24. fxls8962af-core.c文件中,对fxls8962af_buffer_predisable函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  25. max1363.c文件中,对max1363_events数组的定义进行了修改,确认这是否会影响设备的正确操作。

  26. stm32-adc-core.c文件中,对stm32_adc_irq_probe函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  27. xpad.c文件中,新增了对Acer NGR200设备的支持,确认这是否符合设备规范。

  28. dm-bufio.c文件中,对__evict_many函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  29. memstick.c文件中,对h_memstick_read_dev_id函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  30. bcm2835.c文件中,对bcm2835_prepare_dma函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  31. sdhci-pci-core.c文件中,对glk_broken_cqhci函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  32. sdhci_am654.c文件中,对sdhci_am654_pdata结构体的quirks2字段进行了修改,确认这是否会影响设备的正确操作。

  33. ice_lag.c文件中,对ice_lag_is_switchdev_running函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  34. en_rx.c文件中,对mlx5e_lro_update_hdr函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  35. main.c文件中,新增了对ConnectX-10设备的支持,确认这是否符合设备规范。

  36. wx_hw.c文件中,对wx_configure_rx_ring函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  37. wx_lib.c文件中,对wx_clean_rx_ring函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  38. wx_type.h文件中,对wx_cb结构体的定义进行了修改,确认这是否会影响设备的正确操作。

  39. xilinx_emaclite.c文件中,对xemaclite_aligned_read函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  40. netvsc_drv.c文件中,对netvsc_prepare_bonding函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  41. phy_device.c文件中,对phy_probe函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  42. sierra_net.c文件中,对sierra_net_bind函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  43. core.c文件中,对nvme_fail_nonready_command函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  44. imx-ocotp-ele.c文件中,对imx_ocotp_cell_pp函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  45. imx-ocotp.c文件中,对imx_ocotp_cell_pp函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  46. u-boot-env.c文件中,对u_boot_env_parse函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  47. xusb-tegra186.c文件中,对tegra186_utmi_phy_set_mode函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  48. xusb.h文件中,对tegra_xusb_padctl_soc结构体的定义进行了修改,确认这是否会影响设备的正确操作。

  49. pwm-regulator.c文件中,对pwm_regulator_init_continuous函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  50. aspeed-lpc-snoop.c文件中,对aspeed_lpc_enable_snoop函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  51. amd_manager.c文件中,对amd_sdw_send_cmd_get_resp函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  52. spi.c文件中,对__spi_validate函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  53. switch.c文件中,对tb_switch_set_wake函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  54. usb4.c文件中,对usb4_switch_set_wake函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  55. pch_uart.c文件中,对pch_dma_tx_complete函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  56. hub.c文件中,对hub_activate函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  57. dwc3-qcom.c文件中,对dwc3_qcom_probe函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  58. configfs.c文件中,对webusb_landingPage_store函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  59. ftdi_sio.c文件中,对ftdi_sio_ids.h文件进行了修改,确认这是否会影响设备的正确操作。

  60. option.c文件中,对option_ids数组进行了修改,确认这是否会影响设备的正确操作。

  61. cachefiles/io.c文件中,对__cachefiles_write函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  62. cachefiles/ondemand.c文件中,对cachefiles_ondemand_fd_write_iter函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  63. isofs/inode.c文件中,对isofs_read_inode函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  64. namespace.c文件中,对clone_private_mount函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  65. smb/client/file.c文件中,对cifs_oplock_break函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  66. smb/client/smb2ops.c文件中,对crypt_message函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  67. cfg80211.h文件中,对cfg80211_scan_request结构体的定义进行了修改,确认这是否会影响设备的正确操作。

  68. nf_conntrack.h文件中,对nf_ct_should_gc函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  69. rxrpc.h文件中,对rxrpc_call_see_already_released事件进行了定义,确认这是否会影响设备的正确操作。

  70. io_uring/net.c文件中,对io_connect函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  71. io_uring/poll.c文件中,对io_poll_check_events函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  72. bpf/helpers.c文件中,对bpf_bprintf_prepare函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  73. legacy_freezer.c文件中,对cgroup_freezing函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  74. loadavg.c文件中,对calc_load_fold_active函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  75. sched.h文件中,对rq结构体的定义进行了修改,确认这是否会影响设备的正确操作。

  76. trace_events.c文件中,对__register_event函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  77. trace_osnoise.c文件中,对__timerlat_dump_stack函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  78. trace_probe.c文件中,对parse_btf_arg函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  79. vlan.c文件中,对vlan_vid0_addvlan_vid0_del函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  80. hci_sync.c文件中,对hci_get_random_address函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  81. l2cap_core.c文件中,对l2cap_parse_conf_req函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  82. l2cap_sock.c文件中,对l2cap_sock_resume_cb函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  83. smp.c文件中,对smp_timeout函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  84. smp.h文件中,对smp.h文件进行了修改,确认这是否会影响设备的正确操作。

  85. br_switchdev.c文件中,对nbp_switchdev_can_offload_tx_fwd函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  86. addrconf.c文件中,对addrconf_init函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  87. mcast.c文件中,对mld_del_delrec函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  88. rpl_iptunnel.c文件中,对rpl_do_srh_inline函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  89. nf_conntrack_core.c文件中,对__nf_conntrack_confirm函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  90. af_packet.c文件中,对tpacket_snd函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  91. pep.c文件中,对pep_sock_accept函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  92. rxrpc/call_accept.c文件中,对rxrpc_discard_prealloc函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  93. rxrpc/output.c文件中,对rxrpc_reject_packet函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  94. rxrpc/recvmsg.c文件中,对rxrpc_recvmsg函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  95. sched/sch_htb.c文件中,对htb_lookup_leaf函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  96. sched/sch_qfq.c文件中,对qfq_change_classqfq_delete_class函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  97. sched/sch_qfq.c文件中,对qfq_dump_classqfq_dump_class_stats函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  98. tls/tls_strp.c文件中,对tls_strp_read_sock函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  99. hda/patch_realtek.c文件中,对alc269_fixup_tbl数组进行了修改,确认这是否会影响设备的正确操作。

  100. fsl_sai.c文件中,对fsl_sai_config_disable函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  101. bpf/prog_tests/dummy_st_ops.c文件中,对test_dummy_sleepable_reject_null函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

  102. bpf/progs/dummy_st_ops_success.c文件中,对dummy_st_ops_success.c文件进行了修改,确认这是否会影响设备的正确操作。

  103. net/udpgro.sh文件中,对run_onerun_one_nat函数的错误处理逻辑进行了修改,确认这是否会影响设备的正确操作。

以上是对代码审查的反馈,希望能够帮助到您。

Copy link

@sourcery-ai sourcery-ai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @opsiff - I've reviewed your changes - here's some feedback:

  • This patchset spans numerous subsystems and drivers; please consider splitting it into smaller, subsystem-focused commits or series to make review and backporting more manageable.
  • Several new error paths (e.g., after dma_map or kcalloc) allocate resources before failing—ensure every failure branch properly cleans up allocated buffers, mappings, and registrations to prevent leaks.
  • For all newly added delayed_work or workqueue items (e.g., hub_post_resume_work), verify that they’re always initialized, flushed, and canceled in corresponding removal or teardown paths to avoid use-after-free or stray work execution.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- This patchset spans numerous subsystems and drivers; please consider splitting it into smaller, subsystem-focused commits or series to make review and backporting more manageable.
- Several new error paths (e.g., after dma_map or kcalloc) allocate resources before failing—ensure every failure branch properly cleans up allocated buffers, mappings, and registrations to prevent leaks.
- For all newly added delayed_work or workqueue items (e.g., hub_post_resume_work), verify that they’re always initialized, flushed, and canceled in corresponding removal or teardown paths to avoid use-after-free or stray work execution.

Sourcery is free for open source - if you like our reviews please consider sharing them ✨
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.

@Avenger-285714 Avenger-285714 requested a review from Copilot July 28, 2025 03:30
Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This pull request updates the kernel base to version 6.6.100, incorporating upstream stable release fixes and enhancements across multiple subsystems. The update includes numerous driver fixes, subsystem improvements, and architecture support enhancements as part of the routine kernel maintenance process.

  • Update of SUBLEVEL version macro from 99 to 100 in the main Makefile
  • Comprehensive bug fixes across networking, bluetooth, USB, storage, and other drivers
  • Performance and security improvements in core kernel components

Reviewed Changes

Copilot reviewed 108 out of 108 changed files in this pull request and generated no comments.

Show a summary per file
File Description
Makefile Updates kernel version to 6.6.100
tools/testing/selftests/net/udpgro.sh Increases test iteration count for UDP GRO testing
tools/testing/selftests/bpf/ Simplifies BPF test programs and removes null parameter tests
sound/soc/fsl/fsl_sai.c Fixes audio software reset logic for consumer mode
sound/pci/hda/patch_realtek.c Adds audio quirk for ASUS G712LWS
net/ Multiple networking fixes including TLS, packet handling, and connection tracking
fs/ Various filesystem fixes for SMB, ISO9660, and cachefiles
drivers/ Extensive driver updates across USB, GPU, network, and other subsystems
arch/ Architecture-specific fixes for ARM64 and x86 platforms
Comments suppressed due to low confidence (1)

arch/arm64/kernel/cpufeature.c:2932

  • Missing opening parenthesis. The line should use HWCAP_CAP_MATCH_ID like the other lines.
	HWCAP_CAP(ID_MATCH_ID(has_sme_feature, AA64SMFR0_EL1, I8I32, IMP, CAP_HWCAP, KERNEL_HWCAP_SME_I8I32),

@Avenger-285714
Copy link
Collaborator

/approve

@deepin-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: Avenger-285714

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

Wayne Chang and others added 18 commits July 28, 2025 15:19
commit cefc1caee9dd06c69e2d807edc5949b329f52b22 upstream.

When transitioning from USB_ROLE_DEVICE to USB_ROLE_NONE, the code
assumed that the regulator should be disabled. However, if the regulator
is marked as always-on, regulator_is_enabled() continues to return true,
leading to an incorrect attempt to disable a regulator which is not
enabled.

This can result in warnings such as:

[  250.155624] WARNING: CPU: 1 PID: 7326 at drivers/regulator/core.c:3004
_regulator_disable+0xe4/0x1a0
[  250.155652] unbalanced disables for VIN_SYS_5V0

To fix this, we move the regulator control logic into
tegra186_xusb_padctl_id_override() function since it's directly related
to the ID override state. The regulator is now only disabled when the role
transitions from USB_ROLE_HOST to USB_ROLE_NONE, by checking the VBUS_ID
register. This ensures that regulator enable/disable operations are
properly balanced and only occur when actually transitioning to/from host
mode.

Fixes: 49d46e3 ("phy: tegra: xusb: Add set_mode support for UTMI phy on Tegra186")
Cc: stable@vger.kernel.org
Signed-off-by: Wayne Chang <waynec@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20250502092606.2275682-1-waynec@nvidia.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 5367cdeb75cb6c687ca468450bceb2602ab239d8)
commit 24c63c590adca310e0df95c77cf7aa5552bc3fc5 upstream.

The logic that drives the pad calibration values resides in the
controller reset domain and so the calibration values are only being
captured when the controller is out of reset. However, by clearing the
CYA_TRK_CODE_UPDATE_ON_IDLE bit, the calibration values can be set
while the controller is in reset.

The CYA_TRK_CODE_UPDATE_ON_IDLE bit was previously cleared based on the
trk_hw_mode flag, but this dependency is not necessary. Instead,
introduce a new flag, trk_update_on_idle, to independently control this
bit.

Fixes: d8163a3 ("phy: tegra: xusb: Add Tegra234 support")
Cc: stable@vger.kernel.org
Signed-off-by: Wayne Chang <waynec@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20250519090929.3132456-2-waynec@nvidia.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 491175c139e50a7bcdf711e9d354868796388228)
commit 7be54870e9bf5ed0b4fe2a23b41a630527882de5 upstream.

Periodic calibration updates (~10µs) may overlap with transfers when
PCIe NVMe SSD, LPDDR, and USB2 devices operate simultaneously, causing
crosstalk on Tegra234 devices. Hence disable periodic calibration updates
and make this a one-time calibration.

Fixes: d8163a3 ("phy: tegra: xusb: Add Tegra234 support")
Cc: stable@vger.kernel.org
Signed-off-by: Haotien Hsu <haotienh@nvidia.com>
Signed-off-by: Wayne Chang <waynec@nvidia.com>
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/r/20250519090929.3132456-3-waynec@nvidia.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ad2437f4abcae4410771bb6625981365e001a871)
commit 252f4ac08cd2f16ecd20e4c5e41ac2a17dd86942 upstream.

Add Telit Cinterion FE910C04 (ECM) composition:
0x10c7: ECM + tty (AT) + tty (AT) + tty (diag)

usb-devices output:
T:  Bus=01 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  7 Spd=480 MxCh= 0
D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
P:  Vendor=1bc7 ProdID=10c7 Rev=05.15
S:  Manufacturer=Telit Cinterion
S:  Product=FE910
S:  SerialNumber=f71b8b32
C:  #Ifs= 5 Cfg#= 1 Atr=e0 MxPwr=500mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=06 Prot=00 Driver=cdc_ether
E:  Ad=82(I) Atr=03(Int.) MxPS=  16 Ivl=32ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=00 Driver=cdc_ether
E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I:  If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=85(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=86(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I:  If#= 4 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
E:  Ad=87(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms

Cc: stable@vger.kernel.org
Signed-off-by: Fabio Porcedda <fabio.porcedda@gmail.com>
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 84c320060d5374c5863ccd76e5a8685c66d2e041)
commit 08f49cdb71f3759368fded4dbc9dde35a404ec2b upstream.

T99W640 is designed based on Qualconn SDX72 chip. There are 3
serial ports to be enumerated: Diag, NMEA and AT.

Test evidence as below:
T:  Bus=04 Lev=01 Prnt=01 Port=01 Cnt=01 Dev#=  2 Spd=5000 MxCh= 0
D:  Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs=  1
P:  Vendor=0489 ProdID=e167 Rev=05.15
S:  Manufacturer=QCOM
S:  Product=SDXPINNL USB WWAN Adapter
S:  SerialNumber=cc1f1d92
C:  #Ifs= 6 Cfg#= 1 Atr=a0 MxPwr=896mA
I:  If#= 0 Alt= 0 #EPs= 1 Cls=02(commc) Sub=0e Prot=00 Driver=cdc_mbim
E:  Ad=82(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
I:  If#= 1 Alt= 1 #EPs= 2 Cls=0a(data ) Sub=00 Prot=02 Driver=cdc_mbim
E:  Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:  If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=83(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=84(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I:  If#= 3 Alt= 0 #EPs= 1 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E:  Ad=85(I) Atr=03(Int.) MxPS=  64 Ivl=32ms
I:  If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=40 Driver=option
E:  Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=87(I) Atr=03(Int.) MxPS=  10 Ivl=32ms
I:  If#= 5 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=option
E:  Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E:  Ad=88(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms

0&1: MBIM, 2:Modem, 3:GNSS(non-serial port), 4: NMEA, 5:Diag

Signed-off-by: Slark Xiao <slark_xiao@163.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 909d80414869f680e5f01056b7a080d5ecf83917)
commit c980666b6958d9a841597331b38115a29a32250e upstream.

NDI (Northern Digital Inc.) is introducing a new product called the
EMGUIDE GEMINI that will use an FTDI chip for USB serial communications.
Add the NDI EMGUIDE GEMINI product ID that uses the NDI Vendor ID
rather than the FTDI Vendor ID, unlike older products.

Signed-off-by: Ryan Mann <rmann@ndigital.com>
Cc: stable@vger.kernel.org
Signed-off-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 311c434f5d76cddf936062fc1c0ada30dbdfc0a0)
commit 67a59f82196c8c4f50c83329f0577acfb1349b50 upstream.

When unplugging the USB cable or disconnecting a gadget in usb peripheral mode with
echo "" > /sys/kernel/config/usb_gadget/<your_gadget>/UDC,
/sys/class/udc/musb-hdrc.0/state does not change from USB_STATE_CONFIGURED.

Testing on dwc2/3 shows they both update the state to USB_STATE_NOTATTACHED.

Add calls to usb_gadget_set_state in musb_g_disconnect and musb_gadget_stop
to fix both cases.

Fixes: 49401f4 ("usb: gadget: introduce gadget state tracking")
Cc: stable@vger.kernel.org
Co-authored-by: Yehowshua Immanuel <yehowshua.immanuel@twosixtech.com>
Signed-off-by: Yehowshua Immanuel <yehowshua.immanuel@twosixtech.com>
Signed-off-by: Drew Hamilton <drew.hamilton@zetier.com>
Link: https://lore.kernel.org/r/20250701154126.8543-1-drew.hamilton@zetier.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit ec35a7125d945ed66bf1147ace59db414a259ac6)
commit 3014168731b7930300aab656085af784edc861f6 upstream.

When writing an empty string to either 'qw_sign' or 'landingPage'
sysfs attributes, the store functions attempt to access page[l - 1]
before validating that the length 'l' is greater than zero.

This patch fixes the vulnerability by adding a check at the beginning
of os_desc_qw_sign_store() and webusb_landingPage_store() to handle
the zero-length input case gracefully by returning immediately.

Signed-off-by: Xinyu Liu <katieeliu@tencent.com>
Cc: stable <stable@kernel.org>
Link: https://lore.kernel.org/r/tencent_B1C9481688D0E95E7362AB2E999DE8048207@qq.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 58bdd5160184645771553ea732da5c2887fc9bd1)
commit c870cbbd71fccda71d575f0acd4a8d2b7cd88861 upstream.

If the DMA mapping failed, it produced an error log with the wrong
device name:
"stm32-dma3 40400000.dma-controller: rejecting DMA map of vmalloc memory"
Fix this issue by replacing the dev with the I2C dev.

Fixes: bb8822c ("i2c: i2c-stm32: Add generic DMA API")
Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
Cc: <stable@vger.kernel.org> # v4.18+
Acked-by: Alain Volmat <alain.volmat@foss.st.com>
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/20250704-i2c-upstream-v4-1-84a095a2c728@foss.st.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit e6a2ff56b06e194e5c6abf4b53b93f14267040c7)
commit 58d71d4242ce057955c783a14c82270c71f9e1e8 upstream.

commit 1a760d10ded37 ("thunderbolt: Fix a logic error in wake on connect")
fixated on the USB4 port sysfs wakeup file not working properly to control
policy, but it had an unintended side effect that the sysfs file controls
policy both at runtime and at suspend time. The sysfs file is supposed to
only control behavior while system is suspended.

Pass whether programming a port for runtime into usb4_switch_set_wake()
and if runtime then ignore the value in the sysfs file.

Cc: stable@vger.kernel.org
Reported-by: Alexander Kovacs <Alexander.Kovacs@amd.com>
Tested-by: Alexander Kovacs <Alexander.Kovacs@amd.com>
Fixes: 1a760d10ded37 ("thunderbolt: Fix a logic error in wake on connect")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit dc52aff53465e446f771dfceb318a40737c68ff0)
commit 2cdde91c14ec358087f43287513946d493aef940 upstream.

The tb_dp_port_set_hops() function was incorrectly clearing
ADP_DP_CS_1_AUX_RX_HOPID_MASK twice. According to the function's
purpose, it should clear both TX and RX AUX HopID fields.  Replace the
first instance with ADP_DP_CS_1_AUX_TX_HOPID_MASK to ensure proper
configuration of both AUX directions.

Fixes: 9817638 ("thunderbolt: Convert DP adapter register names to follow the USB4 spec")
Cc: stable@vger.kernel.org
Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 0cd051cb5852c340755db676dc25cb8e9b7e2e41)
commit 2aa4ad626ee7f817a8f4715a47b318cfdc1714c9 upstream.

The commit "13bcd440f2ff nvmem: core: verify cell's raw_len" caused an
extension of the "mac-address" cell from 6 to 8 bytes due to word_size
of 4 bytes. This led to a required byte swap of the full buffer length,
which caused truncation of the mac-address when read.

Previously, the mac-address was incorrectly truncated from
70:B3:D5:14:E9:0E to 00:00:70:B3:D5:14.

Fix the issue by swapping only the first 6 bytes to correctly pass the
mac-address to the upper layers.

Fixes: 13bcd44 ("nvmem: core: verify cell's raw_len")
Cc: stable@vger.kernel.org
Signed-off-by: Steffen Bätz <steffen@innosonix.de>
Tested-by: Alexander Stein <alexander.stein@ew.tq-group.com>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250712181729.6495-3-srini@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 0f6f30f5b01ac249e5efe4ce7b0b67871a0274f1)
commit bcce05041b21888f10b80ea903dcfe51a25c586e upstream.

The controller should have been set as XTYPE_XBOX360 and not XTYPE_XBOX.
Also the entry is in the wrong place. Fix it.

Reported-by: Vicki Pfau <vi@endrift.com>
Signed-off-by: Nilton Perim Neto <niltonperimneto@gmail.com>
Link: https://lore.kernel.org/r/20250708033126.26216-2-niltonperimneto@gmail.com
Fixes: 22c69d786ef8 ("Input: xpad - support Acer NGR 200 Controller")
Cc: stable@vger.kernel.org
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit db44a558b3afc10eb1573ec857621769ba6a2bb6)
commit 6c0e9f05c9d7875995b0e92ace71be947f280bbd upstream.

The dma_sync_sg_for_device() functions should be called with the same
nents as the dma_map_sg(), not the value the map function returned
according to the documentation in Documentation/core-api/dma-api.rst:450:
	With the sync_sg API, all the parameters must be the same
	as those passed into the sg mapping API.

Fixes: da3564e ("pch_uart: add multi-scatter processing")
Cc: stable <stable@kernel.org>
Signed-off-by: Thomas Fourier <fourier.thomas@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20250701113452.18590-2-fourier.thomas@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 415d4966cb5400e740b9865fb7b7559fa27a0692)
commit 710505212e3272396394f8cf78e3ddfd05df3f22 upstream.

The current SPI framework does not verify if the SPI device supports
8 IO mode when doing an 8-bit transfer. This patch adds a check to
ensure that if the transfer tx_nbits or rx_nbits is 8, the SPI mode must
support 8 IO. If not, an error is returned, preventing undefined behavior.

Fixes: d6a711a ("spi: Fix OCTAL mode support")
Cc: stable@vger.kernel.org
Signed-off-by: Cheng Ming Lin <chengminglin@mxic.com.tw>
Link: https://patch.msgid.link/20250714031023.504752-1-linchengming884@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 82b29ee8ba906b651950ea73711595136478b6b6)
commit b1bf1a782fdf5c482215c0c661b5da98b8e75773 upstream.

If "try_verify_in_tasklet" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP
is enabled for dm-bufio. However, when bufio tries to evict buffers, there
is a chance to trigger scheduling in spin_lock_bh, the following warning
is hit:

BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2
preempt_count: 201, expected: 0
RCU nest depth: 0, expected: 0
4 locks held by kworker/2:2/123:
 #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970
 #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970
 #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710
 #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710
Preemption disabled at:
[<0000000000000000>] 0x0
CPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 deepin-community#305 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014
Workqueue: dm_bufio_cache do_global_cleanup
Call Trace:
 <TASK>
 dump_stack_lvl+0x53/0x70
 __might_resched+0x360/0x4e0
 do_global_cleanup+0x2f5/0x710
 process_one_work+0x7db/0x1970
 worker_thread+0x518/0xea0
 kthread+0x359/0x690
 ret_from_fork+0xf3/0x1b0
 ret_from_fork_asm+0x1a/0x30
 </TASK>

That can be reproduced by:

  veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb
  SIZE=$(blockdev --getsz /dev/vda)
  dmsetup create myverity -r --table "0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 <data_blocks> 1 sha256 <root_hash> <salt> 1 try_verify_in_tasklet"
  mount /dev/dm-0 /mnt -o ro
  echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes
  [read files in /mnt]

Cc: stable@vger.kernel.org	# v6.4+
Fixes: 450e8de ("dm bufio: improve concurrent IO performance")
Signed-off-by: Wang Shuai <wangshuai12@xiaomi.com>
Signed-off-by: Sheng Yong <shengyong1@xiaomi.com>
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 469a39a33a9934af157299bf11c58f6e6cb53f85)
…d report ID

commit 4f15ee98304b96e164ff2340e1dfd6181c3f42aa upstream.

When the report ID is not used, the low level transport drivers expect
the first byte to be 0. However, currently the allocated buffer not
account for that extra byte, meaning that instead of having 8 guaranteed
bytes for implement to be working, we only have 7.

Reported-by: Alan Stern <stern@rowland.harvard.edu>
Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/
Cc: stable@vger.kernel.org
Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://patch.msgid.link/20250710-report-size-null-v2-1-ccf922b7c4e5@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit fcda39a9c5b834346088c14b1374336b079466c1)
commit 0d0777ccaa2d46609d05b66ba0096802a2746193 upstream.

The low level transport driver expects the first byte to be the report
ID, even when the report ID is not use (in which case they just shift
the buffer).

However, __hid_request() whas not offsetting the buffer it used by one
in this case, meaning that the raw_request() callback emitted by the
transport driver would be stripped of the first byte.

Note: this changes the API for uhid devices when a request is made
through hid_hw_request. However, several considerations makes me think
this is fine:
- every request to a HID device made through hid_hw_request() would see
  that change, but every request made through hid_hw_raw_request()
  already has the new behaviour. So that means that the users are
  already facing situations where they might have or not the first byte
  being the null report ID when it is 0. We are making things more
  straightforward in the end.
- uhid is mainly used for BLE devices
- uhid is also used for testing, but I don't see that change a big issue
- for BLE devices, we can check which kernel module is calling
  hid_hw_request()
- and in those modules, we can check which are using a Bluetooth device
- and then we can check if the command is used with a report ID or not.
- surprise: none of the kernel module are using a report ID 0
- and finally, bluez, in its function set_report()[0], does the same
  shift if the report ID is 0 and the given buffer has a size > 0.

[0] https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/input/hog-lib.c#n879

Reported-by: Alan Stern <stern@rowland.harvard.edu>
Closes: https://lore.kernel.org/linux-input/c75433e0-9b47-4072-bbe8-b1d14ea97b13@rowland.harvard.edu/
Reported-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=8258d5439c49d4c35f43
Tested-by: syzbot+8258d5439c49d4c35f43@syzkaller.appspotmail.com
Fixes: 4fa5a7f ("HID: core: implement generic .request()")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20250710-report-size-null-v2-2-ccf922b7c4e5@kernel.org
Signed-off-by: Benjamin Tissoires <bentiss@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a1c0b87b76824d14979ec7634fc3126b1b64c25a)
kuba-moo and others added 28 commits July 28, 2025 15:19
[ Upstream commit 4ab26bce3969f8fd925fe6f6f551e4d1a508c68b ]

After recent changes in net-next TCP compacts skbs much more
aggressively. This unearthed a bug in TLS where we may try
to operate on an old skb when checking if all skbs in the
queue have matching decrypt state and geometry.

    BUG: KASAN: slab-use-after-free in tls_strp_check_rcv+0x898/0x9a0 [tls]
    (net/tls/tls_strp.c:436 net/tls/tls_strp.c:530 net/tls/tls_strp.c:544)
    Read of size 4 at addr ffff888013085750 by task tls/13529

    CPU: 2 UID: 0 PID: 13529 Comm: tls Not tainted 6.16.0-rc5-virtme
    Call Trace:
     kasan_report+0xca/0x100
     tls_strp_check_rcv+0x898/0x9a0 [tls]
     tls_rx_rec_wait+0x2c9/0x8d0 [tls]
     tls_sw_recvmsg+0x40f/0x1aa0 [tls]
     inet_recvmsg+0x1c3/0x1f0

Always reload the queue, fast path is to have the record in the queue
when we wake, anyway (IOW the path going down "if !strp->stm.full_len").

Fixes: 0d87bbd ("tls: strp: make sure the TCP skbs do not have overlapping data")
Link: https://patch.msgid.link/20250716143850.1520292-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 1f3a429c21e0e43e8b8c55d30701e91411a4df02)
… runtime

[ Upstream commit 579d4f9ca9a9a605184a9b162355f6ba131f678d ]

Assuming the "rx-vlan-filter" feature is enabled on a net device, the
8021q module will automatically add or remove VLAN 0 when the net device
is put administratively up or down, respectively. There are a couple of
problems with the above scheme.

The first problem is a memory leak that can happen if the "rx-vlan-filter"
feature is disabled while the device is running:

 # ip link add bond1 up type bond mode 0
 # ethtool -K bond1 rx-vlan-filter off
 # ip link del dev bond1

When the device is put administratively down the "rx-vlan-filter"
feature is disabled, so the 8021q module will not remove VLAN 0 and the
memory will be leaked [1].

Another problem that can happen is that the kernel can automatically
delete VLAN 0 when the device is put administratively down despite not
adding it when the device was put administratively up since during that
time the "rx-vlan-filter" feature was disabled. null-ptr-unref or
bug_on[2] will be triggered by unregister_vlan_dev() for refcount
imbalance if toggling filtering during runtime:

$ ip link add bond0 type bond mode 0
$ ip link add link bond0 name vlan0 type vlan id 0 protocol 802.1q
$ ethtool -K bond0 rx-vlan-filter off
$ ifconfig bond0 up
$ ethtool -K bond0 rx-vlan-filter on
$ ifconfig bond0 down
$ ip link del vlan0

Root cause is as below:
step1: add vlan0 for real_dev, such as bond, team.
register_vlan_dev
    vlan_vid_add(real_dev,htons(ETH_P_8021Q),0) //refcnt=1
step2: disable vlan filter feature and enable real_dev
step3: change filter from 0 to 1
vlan_device_event
    vlan_filter_push_vids
        ndo_vlan_rx_add_vid //No refcnt added to real_dev vlan0
step4: real_dev down
vlan_device_event
    vlan_vid_del(dev, htons(ETH_P_8021Q), 0); //refcnt=0
        vlan_info_rcu_free //free vlan0
step5: delete vlan0
unregister_vlan_dev
    BUG_ON(!vlan_info); //vlan_info is null

Fix both problems by noting in the VLAN info whether VLAN 0 was
automatically added upon NETDEV_UP and based on that decide whether it
should be deleted upon NETDEV_DOWN, regardless of the state of the
"rx-vlan-filter" feature.

[1]
unreferenced object 0xffff8880068e3100 (size 256):
  comm "ip", pid 384, jiffies 4296130254
  hex dump (first 32 bytes):
    00 20 30 0d 80 88 ff ff 00 00 00 00 00 00 00 00  . 0.............
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 81ce31fa):
    __kmalloc_cache_noprof+0x2b5/0x340
    vlan_vid_add+0x434/0x940
    vlan_device_event.cold+0x75/0xa8
    notifier_call_chain+0xca/0x150
    __dev_notify_flags+0xe3/0x250
    rtnl_configure_link+0x193/0x260
    rtnl_newlink_create+0x383/0x8e0
    __rtnl_newlink+0x22c/0xa40
    rtnl_newlink+0x627/0xb00
    rtnetlink_rcv_msg+0x6fb/0xb70
    netlink_rcv_skb+0x11f/0x350
    netlink_unicast+0x426/0x710
    netlink_sendmsg+0x75a/0xc20
    __sock_sendmsg+0xc1/0x150
    ____sys_sendmsg+0x5aa/0x7b0
    ___sys_sendmsg+0xfc/0x180

[2]
kernel BUG at net/8021q/vlan.c:99!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 0 UID: 0 PID: 382 Comm: ip Not tainted 6.16.0-rc3 deepin-community#61 PREEMPT(voluntary)
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:unregister_vlan_dev (net/8021q/vlan.c:99 (discriminator 1))
RSP: 0018:ffff88810badf310 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88810da84000 RCX: ffffffffb47ceb9a
RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88810e8b43c8
RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6cefe80
R10: ffffffffb677f407 R11: ffff88810badf3c0 R12: ffff88810e8b4000
R13: 0000000000000000 R14: ffff88810642a5c0 R15: 000000000000017e
FS:  00007f1ff68c20c0(0000) GS:ffff888163a24000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1ff5dad240 CR3: 0000000107e56000 CR4: 00000000000006f0
Call Trace:
 <TASK>
rtnl_dellink (net/core/rtnetlink.c:3511 net/core/rtnetlink.c:3553)
rtnetlink_rcv_msg (net/core/rtnetlink.c:6945)
netlink_rcv_skb (net/netlink/af_netlink.c:2535)
netlink_unicast (net/netlink/af_netlink.c:1314 net/netlink/af_netlink.c:1339)
netlink_sendmsg (net/netlink/af_netlink.c:1883)
____sys_sendmsg (net/socket.c:712 net/socket.c:727 net/socket.c:2566)
___sys_sendmsg (net/socket.c:2622)
__sys_sendmsg (net/socket.c:2652)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)

Fixes: ad1afb0 ("vlan_dev: VLAN 0 should be treated as "no vlan tag" (802.1p packet)")
Reported-by: syzbot+a8b046e462915c65b10b@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=a8b046e462915c65b10b
Suggested-by: Ido Schimmel <idosch@idosch.org>
Signed-off-by: Dong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20250716034504.2285203-2-dongchenchen2@huawei.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit bb515c41306454937464da055609b5fb0a27821b)
[ Upstream commit 683dc24da8bf199bb7446e445ad7f801c79a550e ]

Do not offload IGMP/MLD messages as it could lead to IGMP/MLD Reports
being unintentionally flooded to Hosts. Instead, let the bridge decide
where to send these IGMP/MLD messages.

Consider the case where the local host is sending out reports in response
to a remote querier like the following:

       mcast-listener-process (IP_ADD_MEMBERSHIP)
          \
          br0
         /   \
      swp1   swp2
        |     |
  QUERIER     SOME-OTHER-HOST

In the above setup, br0 will want to br_forward() reports for
mcast-listener-process's group(s) via swp1 to QUERIER; but since the
source hwdom is 0, the report is eligible for tx offloading, and is
flooded by hardware to both swp1 and swp2, reaching SOME-OTHER-HOST as
well. (Example and illustration provided by Tobias.)

Fixes: 4721119 ("net: bridge: switchdev: allow the TX data plane forwarding to be offloaded")
Signed-off-by: Joseph Huang <Joseph.Huang@garmin.com>
Acked-by: Nikolay Aleksandrov <razor@blackwall.org>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20250716153551.1830255-1-Joseph.Huang@garmin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 7b0d42318393186f218b8a617ff3d0a01693274c)
[ Upstream commit 0e1d5d9b5c5966e2e42e298670808590db5ed628 ]

htb_lookup_leaf has a BUG_ON that can trigger with the following:

tc qdisc del dev lo root
tc qdisc add dev lo root handle 1: htb default 1
tc class add dev lo parent 1: classid 1:1 htb rate 64bit
tc qdisc add dev lo parent 1:1 handle 2: netem
tc qdisc add dev lo parent 2:1 handle 3: blackhole
ping -I lo -c1 -W0.001 127.0.0.1

The root cause is the following:

1. htb_dequeue calls htb_dequeue_tree which calls the dequeue handler on
   the selected leaf qdisc
2. netem_dequeue calls enqueue on the child qdisc
3. blackhole_enqueue drops the packet and returns a value that is not
   just NET_XMIT_SUCCESS
4. Because of this, netem_dequeue calls qdisc_tree_reduce_backlog, and
   since qlen is now 0, it calls htb_qlen_notify -> htb_deactivate ->
   htb_deactiviate_prios -> htb_remove_class_from_row -> htb_safe_rb_erase
5. As this is the only class in the selected hprio rbtree,
   __rb_change_child in __rb_erase_augmented sets the rb_root pointer to
   NULL
6. Because blackhole_dequeue returns NULL, netem_dequeue returns NULL,
   which causes htb_dequeue_tree to call htb_lookup_leaf with the same
   hprio rbtree, and fail the BUG_ON

The function graph for this scenario is shown here:
 0)               |  htb_enqueue() {
 0) + 13.635 us   |    netem_enqueue();
 0)   4.719 us    |    htb_activate_prios();
 0) # 2249.199 us |  }
 0)               |  htb_dequeue() {
 0)   2.355 us    |    htb_lookup_leaf();
 0)               |    netem_dequeue() {
 0) + 11.061 us   |      blackhole_enqueue();
 0)               |      qdisc_tree_reduce_backlog() {
 0)               |        qdisc_lookup_rcu() {
 0)   1.873 us    |          qdisc_match_from_root();
 0)   6.292 us    |        }
 0)   1.894 us    |        htb_search();
 0)               |        htb_qlen_notify() {
 0)   2.655 us    |          htb_deactivate_prios();
 0)   6.933 us    |        }
 0) + 25.227 us   |      }
 0)   1.983 us    |      blackhole_dequeue();
 0) + 86.553 us   |    }
 0) # 2932.761 us |    qdisc_warn_nonwc();
 0)               |    htb_lookup_leaf() {
 0)               |      BUG_ON();
 ------------------------------------------

The full original bug report can be seen here [1].

We can fix this just by returning NULL instead of the BUG_ON,
as htb_dequeue_tree returns NULL when htb_lookup_leaf returns
NULL.

[1] https://lore.kernel.org/netdev/pF5XOOIim0IuEfhI-SOxTgRvNoDwuux7UHKnE_Y5-zVd4wmGvNk2ceHjKb8ORnzw0cGwfmVu42g9dL7XyJLf1NEzaztboTWcm0Ogxuojoeo=@willsroot.io/

Fixes: 512bb43 ("pkt_sched: sch_htb: Optimize WARN_ONs in htb_dequeue_tree() etc.")
Signed-off-by: William Liu <will@willsroot.io>
Signed-off-by: Savino Dicanosa <savy@syst3mfailure.io>
Link: https://patch.msgid.link/20250717022816.221364-1-will@willsroot.io
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 7ff2d83ecf2619060f30ecf9fad4f2a700fca344)
[ Upstream commit 962fb1f651c2cf2083e0c3ef53ba69e3b96d3fbc ]

If a call receives an event (such as incoming data), the call gets placed
on the socket's queue and a thread in recvmsg can be awakened to go and
process it.  Once the thread has picked up the call off of the queue,
further events will cause it to be requeued, and once the socket lock is
dropped (recvmsg uses call->user_mutex to allow the socket to be used in
parallel), a second thread can come in and its recvmsg can pop the call off
the socket queue again.

In such a case, the first thread will be receiving stuff from the call and
the second thread will be blocked on call->user_mutex.  The first thread
can, at this point, process both the event that it picked call for and the
event that the second thread picked the call for and may see the call
terminate - in which case the call will be "released", decoupling the call
from the user call ID assigned to it (RXRPC_USER_CALL_ID in the control
message).

The first thread will return okay, but then the second thread will wake up
holding the user_mutex and, if it sees that the call has been released by
the first thread, it will BUG thusly:

	kernel BUG at net/rxrpc/recvmsg.c:474!

Fix this by just dequeuing the call and ignoring it if it is seen to be
already released.  We can't tell userspace about it anyway as the user call
ID has become stale.

Fixes: 248f219 ("rxrpc: Rewrite the data and ack handling code")
Reported-by: Junvyyang, Tencent Zhuque Lab <zhuque@tencent.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
cc: LePremierHomme <kwqcheii@proton.me>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
Link: https://patch.msgid.link/20250717074350.3767366-3-dhowells@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 7692bde890061797f3dece0148d7859e85c55778)
[ Upstream commit e9c0b96ec0a34fcacdf9365713578d83cecac34c ]

Under some circumstances, such as when a server socket is closing, ABORT
packets will be generated in response to incoming packets.  Unfortunately,
this also may include generating aborts in response to incoming aborts -
which may cause a cycle.  It appears this may be made possible by giving
the client a multicast address.

Fix this such that rxrpc_reject_packet() will refuse to generate aborts in
response to aborts.

Fixes: 248f219 ("rxrpc: Rewrite the data and ack handling code")
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Jeffrey Altman <jaltman@auristor.com>
cc: Marc Dionne <marc.dionne@auristor.com>
cc: Junvyyang, Tencent Zhuque Lab <zhuque@tencent.com>
cc: LePremierHomme <kwqcheii@proton.me>
cc: Linus Torvalds <torvalds@linux-foundation.org>
cc: Simon Horman <horms@kernel.org>
cc: linux-afs@lists.infradead.org
Link: https://patch.msgid.link/20250717074350.3767366-5-dhowells@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit 74bb4de32d92e9eda56680bc720edc662d416269)
[ Upstream commit 14a67b42cb6f3ab66f41603c062c5056d32ea7dd ]

This reverts commit cff5f49.

Commit cff5f49 ("cgroup_freezer: cgroup_freezing: Check if not
frozen") modified the cgroup_freezing() logic to verify that the FROZEN
flag is not set, affecting the return value of the freezing() function,
in order to address a warning in __thaw_task.

A race condition exists that may allow tasks to escape being frozen. The
following scenario demonstrates this issue:

CPU 0 (get_signal path)		CPU 1 (freezer.state reader)
try_to_freeze			read freezer.state
__refrigerator			freezer_read
				update_if_frozen
WRITE_ONCE(current->__state, TASK_FROZEN);
				...
				/* Task is now marked frozen */
				/* frozen(task) == true */
				/* Assuming other tasks are frozen */
				freezer->state |= CGROUP_FROZEN;
/* freezing(current) returns false */
/* because cgroup is frozen (not freezing) */
break out
__set_current_state(TASK_RUNNING);
/* Bug: Task resumes running when it should remain frozen */

The existing !frozen(p) check in __thaw_task makes the
WARN_ON_ONCE(freezing(p)) warning redundant. Removing this warning enables
reverting the commit cff5f49 ("cgroup_freezer: cgroup_freezing: Check
if not frozen") to resolve the issue.

The warning has been removed in the previous patch. This patch revert the
commit cff5f49 ("cgroup_freezer: cgroup_freezing: Check if not
frozen") to complete the fix.

Fixes: cff5f49 ("cgroup_freezer: cgroup_freezing: Check if not frozen")
Reported-by: Zhong Jiawei<zhongjiawei1@huawei.com>
Signed-off-by: Chen Ridong <chenridong@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
(cherry picked from commit f371ad6471ee1036b90eef1cab764cdff029c37e)
commit 36569780b0d64de283f9d6c2195fd1a43e221ee8 upstream.

The commit e6fe3f4 ("sched: Make multiple runqueue task counters
32-bit") changed nr_uninterruptible to an unsigned int. But the
nr_uninterruptible values for each of the CPU runqueues can grow to
large numbers, sometimes exceeding INT_MAX. This is valid, if, over
time, a large number of tasks are migrated off of one CPU after going
into an uninterruptible state. Only the sum of all nr_interruptible
values across all CPUs yields the correct result, as explained in a
comment in kernel/sched/loadavg.c.

Change the type of nr_uninterruptible back to unsigned long to prevent
overflows, and thus the miscalculation of load average.

Fixes: e6fe3f4 ("sched: Make multiple runqueue task counters 32-bit")

Signed-off-by: Aruna Ramakrishna <aruna.ramakrishna@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20250709173328.606794-1-aruna.ramakrishna@oracle.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 496efa228f0dd58980d301e379e5561a9b612eaa)
commit dfd2ee0 upstream.

Both addrconf_verify_work() and addrconf_dad_work() acquire rtnl,
there is no point trying to have one thread per cpu.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: David Ahern <dsahern@kernel.org>
Link: https://lore.kernel.org/r/20240201173031.3654257-1-edumazet@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Brett A C Sheffield <bacs@librecast.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 4cb17b11c8af2fa9de840ffe7fc0bb712f894242)
…ight userns

commit c28f922c9dcee0e4876a2c095939d77fe7e15116 upstream.

What we want is to verify there is that clone won't expose something
hidden by a mount we wouldn't be able to undo.  "Wouldn't be able to undo"
may be a result of MNT_LOCKED on a child, but it may also come from
lacking admin rights in the userns of the namespace mount belongs to.

clone_private_mnt() checks the former, but not the latter.

There's a number of rather confusing CAP_SYS_ADMIN checks in various
userns during the mount, especially with the new mount API; they serve
different purposes and in case of clone_private_mnt() they usually,
but not always end up covering the missing check mentioned above.

Reviewed-by: Christian Brauner <brauner@kernel.org>
Reported-by: "Orlando, Noah" <Noah.Orlando@deshaw.com>
Fixes: 427215d ("ovl: prevent private clone if bind mount is not allowed")
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
[ merge conflict resolution: clone_private_mount() was reworked in
  db04662 ("fs: allow detached mounts in clone_private_mount()").
  Tweak the relevant ns_capable check so that it works on older kernels ]
Signed-off-by: Noah Orlando <Noah.Orlando@deshaw.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit dc6a664089f10eab0fb36b6e4f705022210191d2)
commit a75ad2fc76a2ab70817c7eed3163b66ea84ca6ac upstream.

We have a number of hwcaps for various SME subfeatures enumerated via
ID_AA64SMFR0_EL1. Currently we advertise these without cross checking
against the main SME feature, advertised in ID_AA64PFR1_EL1.SME which
means that if the two are out of sync userspace can see a confusing
situation where SME subfeatures are advertised without the base SME
hwcap. This can be readily triggered by using the arm64.nosme override
which only masks out ID_AA64PFR1_EL1.SME, and there have also been
reports of VMMs which do the same thing.

Fix this as we did previously for SVE in 0647379 ("arm64: Filter
out SVE hwcaps when FEAT_SVE isn't implemented") by filtering out the
SME subfeature hwcaps when FEAT_SME is not present.

Fixes: 5e64b86 ("arm64/sme: Basic enumeration support")
Reported-by: Yury Khrustalev <yury.khrustalev@arm.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/r/20250620-arm64-sme-filter-hwcaps-v1-1-02b9d3c2d8ef@kernel.org
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit d5024dc5e6446fc01f28d5d7cdf8d84677ef87c0)
commit 8f5b7e2bec1c36578fdaa74a6951833541103e27 upstream.

USB3 devices connected behind several external suspended hubs may not
be detected when plugged in due to aggressive hub runtime pm suspend.

The hub driver immediately runtime-suspends hubs if there are no
active children or port activity.

There is a delay between the wake signal causing hub resume, and driver
visible port activity on the hub downstream facing ports.
Most of the LFPS handshake, resume signaling and link training done
on the downstream ports is not visible to the hub driver until completed,
when device then will appear fully enabled and running on the port.

This delay between wake signal and detectable port change is even more
significant with chained suspended hubs where the wake signal will
propagate upstream first. Suspended hubs will only start resuming
downstream ports after upstream facing port resumes.

The hub driver may resume a USB3 hub, read status of all ports, not
yet see any activity, and runtime suspend back the hub before any
port activity is visible.

This exact case was seen when conncting USB3 devices to a suspended
Thunderbolt dock.

USB3 specification defines a 100ms tU3WakeupRetryDelay, indicating
USB3 devices expect to be resumed within 100ms after signaling wake.
if not then device will resend the wake signal.

Give the USB3 hubs twice this time (200ms) to detect any port
changes after resume, before allowing hub to runtime suspend again.

Cc: stable <stable@kernel.org>
Fixes: 2839f5b ("USB: Turn on auto-suspend for USB 3.0 hubs.")
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20250611112441.2267883-1-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 15fea75a788681dd36a869dd90ff4f0461ea0714)
…ime pm

commit a49e1e2e785fb3621f2d748581881b23a364998a upstream.

Delayed work to prevent USB3 hubs from runtime-suspending immediately
after resume was added in commit 8f5b7e2bec1c ("usb: hub: fix detection
of high tier USB3 devices behind suspended hubs").

This delayed work needs be flushed if system suspends, or hub needs to
be quiesced for other reasons right after resume. Not flushing it
triggered issues on QC SC8280XP CRD board during suspend/resume testing.

Fix it by flushing the delayed resume work in hub_quiesce()

The delayed work item that allow hub runtime suspend is also scheduled
just before calling autopm get. Alan pointed out there is a small risk
that work is run before autopm get, which would call autopm put before
get, and mess up the runtime pm usage order.
Swap the order of work sheduling and calling autopm get to solve this.

Cc: stable <stable@kernel.org>
Fixes: 8f5b7e2bec1c ("usb: hub: fix detection of high tier USB3 devices behind suspended hubs")
Reported-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Closes: https://lore.kernel.org/linux-usb/acaaa928-832c-48ca-b0ea-d202d5cd3d6c@oss.qualcomm.com
Reported-by: Alan Stern <stern@rowland.harvard.edu>
Closes: https://lore.kernel.org/linux-usb/c73fbead-66d7-497a-8fa1-75ea4761090a@rowland.harvard.edu
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Link: https://lore.kernel.org/r/20250626130102.3639861-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 71f5c98d2931eea3f1b4d6c4771215b8448f5d2b)
commit 9bd9c8026341f75f25c53104eb7e656e357ca1a2 upstream.

Delayed work that prevents USB3 hubs from runtime-suspending too early
needed to be flushed in hub_quiesce() to resolve issues detected on
QC SC8280XP CRD board during suspend resume testing.

This flushing did however trigger new issues on Raspberry Pi 3B+, which
doesn't have USB3 ports, and doesn't queue any post resume delayed work.

The flushed 'hub->init_work' item is used for several purposes, and
is originally initialized with a 'NULL' work function. The work function
is also changed on the fly, which may contribute to the issue.

Solve this by creating a dedicated delayed work item for post resume work,
and flush that delayed work in hub_quiesce()

Cc: stable <stable@kernel.org>
Fixes: a49e1e2e785f ("usb: hub: Fix flushing and scheduling of delayed work that tunes runtime pm")
Reported-by: Mark Brown <broonie@kernel.org>
Closes: https://lore.kernel.org/linux-usb/aF5rNp1l0LWITnEB@finisterre.sirena.org.uk
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Tested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> # SC8280XP CRD
Tested-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20250627164348.3982628-2-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 668c7b47a5eec8b3beb5b97d0a3a33699d6e1d1e)
commit 2521106fc732b0b75fd3555c689b1ed1d29d273c upstream.

Hub driver warm-resets ports in SS.Inactive or Compliance mode to
recover a possible connected device. The port reset code correctly
detects if a connection is lost during reset, but hub driver
port_event() fails to take this into account in some cases.
port_event() ends up using stale values and assumes there is a
connected device, and will try all means to recover it, including
power-cycling the port.

Details:
This case was triggered when xHC host was suspended with DbC (Debug
Capability) enabled and connected. DbC turns one xHC port into a simple
usb debug device, allowing debugging a system with an A-to-A USB debug
cable.

xhci DbC code disables DbC when xHC is system suspended to D3, and
enables it back during resume.
We essentially end up with two hosts connected to each other during
suspend, and, for a short while during resume, until DbC is enabled back.
The suspended xHC host notices some activity on the roothub port, but
can't train the link due to being suspended, so xHC hardware sets a CAS
(Cold Attach Status) flag for this port to inform xhci host driver that
the port needs to be warm reset once xHC resumes.

CAS is xHCI specific, and not part of USB specification, so xhci driver
tells usb core that the port has a connection and link is in compliance
mode. Recovery from complinace mode is similar to CAS recovery.

xhci CAS driver support that fakes a compliance mode connection was added
in commit 8bea2bd ("usb: Add support for root hub port status CAS")

Once xHCI resumes and DbC is enabled back, all activity on the xHC
roothub host side port disappears. The hub driver will anyway think
port has a connection and link is in compliance mode, and hub driver
will try to recover it.

The port power-cycle during recovery seems to cause issues to the active
DbC connection.

Fix this by clearing connect_change flag if hub_port_reset() returns
-ENOTCONN, thus avoiding the whole unnecessary port recovery and
initialization attempt.

Cc: stable@vger.kernel.org
Fixes: 8bea2bd ("usb: Add support for root hub port status CAS")
Tested-by: Łukasz Bartosik <ukaszb@chromium.org>
Signed-off-by: Mathias Nyman <mathias.nyman@linux.intel.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Link: https://lore.kernel.org/r/20250623133947.3144608-1-mathias.nyman@linux.intel.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 824fa25c85e869018502e8d5450d2eef1c0ff3af)
commit ef8abc0ba49ce717e6bc4124e88e59982671f3b5 upstream.

Leaving the USB BCR asserted prevents the associated GDSC to turn on. This
blocks any subsequent attempts of probing the device, e.g. after a probe
deferral, with the following showing in the log:

[    1.332226] usb30_prim_gdsc status stuck at 'off'

Leave the BCR deasserted when exiting the driver to avoid this issue.

Cc: stable <stable@kernel.org>
Fixes: a4333c3 ("usb: dwc3: Add Qualcomm DWC3 glue driver")
Acked-by: Thinh Nguyen <Thinh.Nguyen@synopsys.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>
Link: https://lore.kernel.org/r/20250709132900.3408752-1-krishna.kurapati@oss.qualcomm.com
[ adapted to individual clock management instead of bulk clock operations ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6cfbff5f8dc9982aaa253dbb515c5834d008c103)
commit b6ef830 upstream.

Some SoCs require muxes in the routing for SDA and SCL lines.
Therefore, add support for setting the mux by reading the mux-states
property from the dt-node.

Signed-off-by: Jayesh Choudhary <j-choudhary@ti.com>
Link: https://lore.kernel.org/r/20250318103622.29979-3-j-choudhary@ti.com
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Stable-dep-of: a9503a2ecd95 ("i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit caa86f8b6c30b109a6511322aa9680afe13d3397)
commit 666c23af755dccca8c25b5d5200ca28153c69a05 upstream.

If an error occurs after calling mux_state_select(), mux_state_deselect()
should be called as already done in the remove function.

Fixes: b6ef830 ("i2c: omap: Add support for setting mux")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: <stable@vger.kernel.org> # v6.15+
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/998542981b6d2435c057dd8b9fe71743927babab.1749913149.git.christophe.jaillet@wanadoo.fr
Stable-dep-of: a9503a2ecd95 ("i2c: omap: Handle omap_i2c_init() errors in omap_i2c_probe()")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit a7b84035baa8bbc347b02c3339fc7407b4ebe91d)
commit a9503a2ecd95e23d7243bcde7138192de8c1c281 upstream.

omap_i2c_init() can fail. Handle this error in omap_i2c_probe().

Fixes: 010d442 ("i2c: New bus driver for TI OMAP boards")
Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Cc: <stable@vger.kernel.org> # v2.6.19+
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Link: https://lore.kernel.org/r/565311abf9bafd7291ca82bcecb48c1fac1e727b.1751701715.git.christophe.jaillet@wanadoo.fr
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 7e5ec0059e4dddb2cc373cff594a179c04b90e8d)
commit 6a7d11e upstream.

If a PWM output is disabled then it's voltage has to be calculated
based on a zero duty cycle (for normal polarity) or duty cycle being
equal to the PWM period (for inverted polarity). Add support for this
to pwm_regulator_get_voltage().

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://msgid.link/r/20240113224628.377993-3-martin.blumenstingl@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit cad3ec23e398542c28283bcf3708dc4b71c2eb75)
commit b3cbdcc upstream.

Odroid-C1 uses a Monolithic Power Systems MP2161 controlled via PWM for
the VDDEE voltage supply of the Meson8b SoC. Commit 6b9352f ("pwm:
meson: modify and simplify calculation in meson_pwm_get_state") results
in my Odroid-C1 crashing with memory corruption in many different places
(seemingly at random). It turns out that this is due to a currently not
supported corner case.

The VDDEE regulator can generate between 860mV (duty cycle of ~91%) and
1140mV (duty cycle of 0%). We consider it to be enabled by the bootloader
(which is why it has the regulator-boot-on flag in .dts) as well as
being always-on (which is why it has the regulator-always-on flag in
.dts) because the VDDEE voltage is generally required for the Meson8b
SoC to work. The public S805 datasheet [0] states on page 17 (where "A5"
refers to the Cortex-A5 CPU cores):
  [...] So if EE domains is shut off, A5 memory is also shut off. That
  does not matter. Before EE power domain is shut off, A5 should be shut
  off at first.

It turns out that at least some bootloader versions are keeping the PWM
output disabled. This is not a problem due to the specific design of the
regulator: when the PWM output is disabled the output pin is pulled LOW,
effectively achieving a 0% duty cycle (which in return means that VDDEE
voltage is at 1140mV).

The problem comes when the pwm-regulator driver tries to initialize the
PWM output. To do so it reads the current state from the hardware, which
is:
  period: 3666ns
  duty cycle: 3333ns (= ~91%)
  enabled: false
Then those values are translated using the continuous voltage range to
860mV.
Later, when the regulator is being enabled (either by the regulator core
due to the always-on flag or first consumer - in this case the lima
driver for the Mali-450 GPU) the pwm-regulator driver tries to keep the
voltage (at 860mV) and just enable the PWM output. This is when things
start to go wrong as the typical voltage used for VDDEE is 1100mV.

Commit 6b9352f ("pwm: meson: modify and simplify calculation in
meson_pwm_get_state") triggers above condition as before that change
period and duty cycle were both at 0. Since the change to the pwm-meson
driver is considered correct the solution is to be found in the
pwm-regulator driver. Update the duty cycle during driver probe if the
regulator is flagged as boot-on so that a call to pwm_regulator_enable()
(by the regulator core during initialization of a regulator flagged with
boot-on) without any preceding call to pwm_regulator_set_voltage() does
not change the output voltage.

[0] https://dn.odroid.com/S805/Datasheet/S805_Datasheet%20V0.8%2020150126.pdf

Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Link: https://msgid.link/r/20240113224628.377993-4-martin.blumenstingl@googlemail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Chukun Pan <amadeus@jmu.edu.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 8f2852c1d7aab936a60a4c9257dcf7ab9ad46336)
commit dc78f7e59169d3f0e6c3c95d23dc8e55e95741e2 upstream.

On an imx8mm platform with an external clock provider, when running the
receiver (arecord) and triggering an xrun with xrun_injection, we see a
channel swap/offset. This happens sometimes when running only the
receiver, but occurs reliably if a transmitter (aplay) is also
concurrently running.

It seems that the SAI loses track of frame sync during the trigger stop
-> trigger start cycle that occurs during an xrun. Doing just a FIFO
reset in this case does not suffice, and only a software reset seems to
get it back on track.

This looks like the same h/w bug that is already handled for the
producer case, so we now do the reset unconditionally on config disable.

Signed-off-by: Arun Raghavan <arun@asymptotic.io>
Reported-by: Pieterjan Camerlynck <p.camerlynck@televic.com>
Fixes: 3e3f8bd ("ASoC: fsl_sai: fix no frame clk in master mode")
Cc: stable@vger.kernel.org
Reviewed-by: Fabio Estevam <festevam@gmail.com>
Link: https://patch.msgid.link/20250626130858.163825-1-arun@arunraghavan.net
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit b9e50a5169b086dd5915ae117c8a53cd75403574)
…al error"

This reverts commit 264451a which is
commit 3b3b84a upstream.

The updated dummy_st_ops test requires commit 1479eaf ("bpf: mark
bpf_dummy_struct_ops.test_1 parameter as nullable"), which in turn depends on
"Support PTR_MAYBE_NULL for struct_ops arguments" series (see link below),
neither are backported to stable 6.6.

Without them the kernel simply panics from null pointer dereference half way
through running BPF selftests.

    deepin-community#68/1    deny_namespace/unpriv_userns_create_no_bpf:OK
    deepin-community#68/2    deny_namespace/userns_create_bpf:OK
    deepin-community#68      deny_namespace:OK
    [   26.829153] BUG: kernel NULL pointer dereference, address: 0000000000000000
    [   26.831136] #PF: supervisor read access in kernel mode
    [   26.832635] #PF: error_code(0x0000) - not-present page
    [   26.833999] PGD 0 P4D 0
    [   26.834771] Oops: 0000 [#1] PREEMPT SMP PTI
    [   26.835997] CPU: 2 PID: 119 Comm: test_progs Tainted: G           OE      6.6.66-00003-gd80551078e71 #3
    [   26.838774] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
    [   26.841152] RIP: 0010:bpf_prog_8ee9cbe7c9b5a50f_test_1+0x17/0x24
    [   26.842877] Code: 00 00 00 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 7f 00 <8b> 47 00 be 5a 00 00 00 89 77 00 c9 c3 cc cc cc cc cc cc cc cc c0
    [   26.847953] RSP: 0018:ffff9e6b803b7d88 EFLAGS: 00010202
    [   26.849425] RAX: 0000000000000001 RBX: 0000000000000001 RCX: 2845e103d7dffb60
    [   26.851483] RDX: 0000000000000000 RSI: 0000000084d09025 RDI: 0000000000000000
    [   26.853508] RBP: ffff9e6b803b7d88 R08: 0000000000000001 R09: 0000000000000000
    [   26.855670] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9754c0b5f700
    [   26.857824] R13: ffff9754c09cc800 R14: ffff9754c0b5f680 R15: ffff9754c0b5f760
    [   26.859741] FS:  00007f77dee12740(0000) GS:ffff9754fbc80000(0000) knlGS:0000000000000000
    [   26.862087] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   26.863705] CR2: 0000000000000000 CR3: 00000001020e6003 CR4: 0000000000170ee0
    [   26.865689] Call Trace:
    [   26.866407]  <TASK>
    [   26.866982]  ? __die+0x24/0x70
    [   26.867774]  ? page_fault_oops+0x15b/0x450
    [   26.868882]  ? search_bpf_extables+0xb0/0x160
    [   26.870076]  ? fixup_exception+0x26/0x330
    [   26.871214]  ? exc_page_fault+0x64/0x190
    [   26.872293]  ? asm_exc_page_fault+0x26/0x30
    [   26.873352]  ? bpf_prog_8ee9cbe7c9b5a50f_test_1+0x17/0x24
    [   26.874705]  ? __bpf_prog_enter+0x3f/0xc0
    [   26.875718]  ? bpf_struct_ops_test_run+0x1b8/0x2c0
    [   26.876942]  ? __sys_bpf+0xc4e/0x2c30
    [   26.877898]  ? __x64_sys_bpf+0x20/0x30
    [   26.878812]  ? do_syscall_64+0x37/0x90
    [   26.879704]  ? entry_SYSCALL_64_after_hwframe+0x78/0xe2
    [   26.880918]  </TASK>
    [   26.881409] Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)]
    [   26.883095] CR2: 0000000000000000
    [   26.883934] ---[ end trace 0000000000000000 ]---
    [   26.885099] RIP: 0010:bpf_prog_8ee9cbe7c9b5a50f_test_1+0x17/0x24
    [   26.886452] Code: 00 00 00 cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc f3 0f 1e fa 0f 1f 44 00 00 66 90 55 48 89 e5 f3 0f 1e fa 48 8b 7f 00 <8b> 47 00 be 5a 00 00 00 89 77 00 c9 c3 cc cc cc cc cc cc cc cc c0
    [   26.890379] RSP: 0018:ffff9e6b803b7d88 EFLAGS: 00010202
    [   26.891450] RAX: 0000000000000001 RBX: 0000000000000001 RCX: 2845e103d7dffb60
    [   26.892779] RDX: 0000000000000000 RSI: 0000000084d09025 RDI: 0000000000000000
    [   26.894254] RBP: ffff9e6b803b7d88 R08: 0000000000000001 R09: 0000000000000000
    [   26.895630] R10: 0000000000000000 R11: 0000000000000000 R12: ffff9754c0b5f700
    [   26.897008] R13: ffff9754c09cc800 R14: ffff9754c0b5f680 R15: ffff9754c0b5f760
    [   26.898337] FS:  00007f77dee12740(0000) GS:ffff9754fbc80000(0000) knlGS:0000000000000000
    [   26.899972] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [   26.901076] CR2: 0000000000000000 CR3: 00000001020e6003 CR4: 0000000000170ee0
    [   26.902336] Kernel panic - not syncing: Fatal exception
    [   26.903639] Kernel Offset: 0x36000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)
    [   26.905693] ---[ end Kernel panic - not syncing: Fatal exception ]---

Link: https://lore.kernel.org/all/20240209023750.1153905-1-thinker.li@gmail.com/
Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit c148b7282808922b217c442d07d2ccfecbb5210c)
…params"

This reverts commit e7d1930 which is
commit 6a2d30d upstream.

The dummy_st_ops/dummy_sleepable_reject_null test requires commit 980ca8c
("bpf: check bpf_dummy_struct_ops program params for test runs"), which in turn
depends on "Support PTR_MAYBE_NULL for struct_ops arguments" series (see link
below), neither are backported to stable 6.6.

Link: https://lore.kernel.org/all/20240209023750.1153905-1-thinker.li@gmail.com/
Signed-off-by: Shung-Hsi Yu <shung-hsi.yu@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 056b65a02edc6321503fb47f191432df8a6fc80c)
commit e66b0a8 upstream.

Using of_property_read_bool() for non-boolean properties is deprecated
and results in a warning during runtime since commit c141ecc ("of:
Warn when of_property_read_bool() is used on non-boolean properties").

Fixes: b6ef830 ("i2c: omap: Add support for setting mux")
Cc: Jayesh Choudhary <j-choudhary@ti.com>
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Acked-by: Mukesh Kumar Savaliya <quic_msavaliy@quicinc.com>
Link: https://lore.kernel.org/r/20250415075230.16235-1-johan+linaro@kernel.org
Signed-off-by: Andi Shyti <andi.shyti@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 35542cbe66c67c65dff866a4a68083a533730726)
commit 2d7521aa26ec2dc8b877bb2d1f2611a2df49a3cf upstream.

On 11 Oct 2022, it was reported that the crc32 verification
of the u-boot environment failed only on big-endian systems
for the u-boot-env nvmem layout driver with the following error.

  Invalid calculated CRC32: 0x88cd6f09 (expected: 0x096fcd88)

This problem has been present since the driver was introduced,
and before it was made into a layout driver.

The suggested fix at the time was to use further endianness
conversion macros in order to have both the stored and calculated
crc32 values to compare always represented in the system's endianness.
This was not accepted due to sparse warnings
and some disagreement on how to handle the situation.
Later on in a newer revision of the patch, it was proposed to use
cpu_to_le32() for both values to compare instead of le32_to_cpu()
and store the values as __le32 type to remove compilation errors.

The necessity of this is based on the assumption that the use of crc32()
requires endianness conversion because the algorithm uses little-endian,
however, this does not prove to be the case and the issue is unrelated.

Upon inspecting the current kernel code,
there already is an existing use of le32_to_cpu() in this driver,
which suggests there already is special handling for big-endian systems,
however, it is big-endian systems that have the problem.

This, being the only functional difference between architectures
in the driver combined with the fact that the suggested fix
was to use the exact same endianness conversion for the values
brings up the possibility that it was not necessary to begin with,
as the same endianness conversion for two values expected to be the same
is expected to be equivalent to no conversion at all.

After inspecting the u-boot environment of devices of both endianness
and trying to remove the existing endianness conversion,
the problem is resolved in an equivalent way as the other suggested fixes.

Ultimately, it seems that u-boot is agnostic to endianness
at least for the purpose of environment variables.
In other words, u-boot reads and writes the stored crc32 value
with the same endianness that the crc32 value is calculated with
in whichever endianness a certain architecture runs on.

Therefore, the u-boot-env driver does not need to convert endianness.
Remove the usage of endianness macros in the u-boot-env driver,
and change the type of local variables to maintain the same return type.

If there is a special situation in the case of endianness,
it would be a corner case and should be handled by a unique "compatible".

Even though it is not necessary to use endianness conversion macros here,
it may be useful to use them in the future for consistent error printing.

Fixes: d554292 ("nvmem: add driver handling U-Boot environment variables")
Reported-by: INAGAKI Hiroshi <musashino.open@gmail.com>
Link: https://lore.kernel.org/all/20221011024928.1807-1-musashino.open@gmail.com
Cc: stable@vger.kernel.org
Signed-off-by: "Michael C. Pratt" <mcpratt@pm.me>
Signed-off-by: Srinivas Kandagatla <srini@kernel.org>
Link: https://lore.kernel.org/r/20250716144210.4804-1-srini@kernel.org
[ applied changes to drivers/nvmem/u-boot-env.c before code was moved to
  drivers/nvmem/layouts/u-boot-env.c ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 48e8791843206baf76827df1b6ee3cb88a2a17d8)
…rcalls

commit 5a53249d149f48b558368c5338b9921b76a12f8c upstream.

kvm_xen_schedop_poll does a kmalloc_array() when a VM polls the host
for more than one event channel potr (nr_ports > 1).

After the kmalloc_array(), the error paths need to go through the
"out" label, but the call to kvm_read_guest_virt() does not.

Fixes: 92c5896 ("KVM: x86/xen: Use kvm_read_guest_virt() instead of open-coding it badly")
Reviewed-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Manuel Andreas <manuel.andreas@tum.de>
[Adjusted commit message. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 3ee59c38ae7369ad1f7b846e05633ccf0d159fab)
Link: https://lore.kernel.org/r/20250722134333.375479548@linuxfoundation.org
Tested-by: Brett A C Sheffield <bacs@librecast.net>
Tested-by: Florian Fainelli <florian.fainelli@broadcom.com>
Tested-by: Shuah Khan <skhan@linuxfoundation.org>
Tested-by: Miguel Ojeda <ojeda@kernel.org>
Tested-by: Peter Schneider <pschneider1968@googlemail.com>
Tested-by: Mark Brown <broonie@kernel.org>
Tested-by: Harshit Mogalapalli <harshit.m.mogalapalli@oracle.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
Tested-by: Hardik Garg <hargar@linux.microsoft.com>
Tested-by: Ron Economos <re@w6rz.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit dbcb8d8e4163e46066f43e2bd9a6779e594ec900)
@opsiff opsiff force-pushed the linux-stable-update-6.6.100 branch from 45fae10 to c1bd6fc Compare July 28, 2025 07:22
@opsiff opsiff merged commit c1bd6fc into deepin-community:linux-6.6.y Jul 28, 2025
9 of 11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.