-
Notifications
You must be signed in to change notification settings - Fork 94
[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
[Deepin-Kernel-SIG] [linux 6.6-y] [Upstream] Update kernel base to 6.6.100 #977
Conversation
Reviewer's GuideThis 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 updateclassDiagram
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
Class diagram for Tegra XUSB padctl changesclassDiagram
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
Class diagram for Comedi insnlist ioctl and length checkclassDiagram
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
Class diagram for PWM regulator boot_on initializationclassDiagram
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
Class diagram for VLAN device event and VLAN 0 auto filterclassDiagram
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
Class diagram for ARM64 SME feature detectionclassDiagram
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
Class diagram for Wangxun wx_rx_buffer and wx_cb changesclassDiagram
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
}
Class diagram for aspeed_lpc_snoop_channel enable/disable logicclassDiagram
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
Class diagram for netfilter conntrack confirmation and status bitclassDiagram
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
Class diagram for I2C OMAP mux state integrationclassDiagram
class omap_i2c_dev {
+mux_state: struct mux_state *
}
class mux_state {
}
omap_i2c_dev o-- mux_state
Class diagram for net/bluetooth/l2cap_core.c MTU adjustmentclassDiagram
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
Class diagram for net/bluetooth/smp.c command handlingclassDiagram
class smp_chan {
+unsigned long allow_cmd
}
class smp {
+smp_sig_channel(chan: l2cap_chan, skb)
}
smp_chan <.. smp : used by
Class diagram for net/8021q/vlan.c VLAN infoclassDiagram
class vlan_info {
+bool auto_vid0
}
class net_device {
+vlan_info *vlan_info
}
vlan_info <.. net_device : used by
Class diagram for net/packet/af_packet.c tpacket_snd changesclassDiagram
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
Class diagram for net/sched/sch_qfq.c QFQ class and aggregateclassDiagram
class qfq_class {
+qfq_aggregate *agg
+common
}
class qfq_aggregate {
+u32 class_weight
+u32 lmax
}
qfq_class o-- qfq_aggregate
Class diagram for net/sched/sch_htb.c htb_prio and htb_classclassDiagram
class htb_prio {
+row
+ptr
+last_ptr_id
}
class htb_class {
}
htb_prio <.. htb_class : used by
Class diagram for net/rxrpc/recvmsg.c call release handlingclassDiagram
class rxrpc_call {
+flags
+recvmsg_link
+user_mutex
}
class rxrpc_recvmsg {
+rxrpc_recvmsg(sock, msg, len, ...)
}
rxrpc_call <.. rxrpc_recvmsg : used by
Class diagram for net/bridge/br_switchdev.c multicast IGMP checkclassDiagram
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
Class diagram for drivers/iio/adc/max1363.c mode list changesclassDiagram
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
Class diagram for drivers/iio/adc/stm32-adc-core.c irq handlerclassDiagram
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
Class diagram for drivers/i2c/busses/i2c-stm32.c DMA mappingclassDiagram
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
Class diagram for drivers/i2c/busses/i2c-stm32f7.c DMA callbackclassDiagram
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
Class diagram for drivers/net/ethernet/wangxun/libwx/wx_lib.c rx buffer changesclassDiagram
class wx_rx_buffer {
+struct sk_buff *skb
+dma_addr_t dma
+struct page *page
+unsigned int page_offset
}
Class diagram for drivers/net/ethernet/wangxun/libwx/wx_hw.c rx ring resetclassDiagram
class wx_ring {
+next_to_clean
+next_to_use
+rx_buffer_info
+count
}
class wx {
}
wx_ring <.. wx : used by
Class diagram for drivers/net/ethernet/xilinx/xilinx_emaclite.c aligned readclassDiagram
class xemaclite_aligned_read {
+xemaclite_aligned_read(src_ptr, dest_ptr, length)
}
Class diagram for drivers/usb/serial/ftdi_sio.c NDI Emguide Gemini supportclassDiagram
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
Class diagram for drivers/usb/serial/option.c Telit and Foxconn device IDsclassDiagram
class option_ids {
+option_ids[]
}
Class diagram for drivers/usb/core/hub.c hub resume and post_resume_workclassDiagram
class usb_hub {
+post_resume_work
+hdev
+intfdev
}
class hub_post_resume {
+hub_post_resume(ws)
}
usb_hub <.. hub_post_resume : used by
Class diagram for drivers/usb/gadget/configfs.c webusb_landingPage_storeclassDiagram
class config_item {
}
class webusb_landingPage_store {
+webusb_landingPage_store(item: config_item, page, len)
}
config_item <.. webusb_landingPage_store : used by
Class diagram for drivers/usb/musb/musb_gadget.c gadget stop/disconnectclassDiagram
class musb {
+g: usb_gadget
+controller
}
class usb_gadget {
+state
}
musb <.. usb_gadget : uses
Class diagram for drivers/thunderbolt/usb4.c and tb.h set_wake changesclassDiagram
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
Class diagram for drivers/thunderbolt/switch.c set_wake changesclassDiagram
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
Class diagram for drivers/soundwire/amd_manager.c suspend and work syncclassDiagram
class amd_sdw_manager {
+amd_sdw_work
+power_mode_mask
}
class amd_suspend {
+amd_suspend(dev)
}
amd_sdw_manager <.. amd_suspend : used by
Class diagram for drivers/hid/hid-core.c report buffer allocationclassDiagram
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
Class diagram for drivers/nvmem/imx-ocotp-ele.c and imx-ocotp.c mac-address swapclassDiagram
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
Class diagram for drivers/nvmem/u-boot-env.c CRC32 parsingclassDiagram
class u_boot_env {
+parse()
}
Class diagram for drivers/net/ethernet/mellanox/mlx5/core/en_rx.c LRO updateclassDiagram
class mlx5e_lro_update_hdr {
+mlx5e_lro_update_hdr(skb, cqe, cqe_bcnt): unsigned int
}
Class diagram for drivers/net/ethernet/intel/ice/ice_lag.c switchdev running checkclassDiagram
class ice_pf {
+lag: ice_lag *
}
class ice_lag {
+upper_netdev
}
ice_pf o-- ice_lag
Class diagram for drivers/net/hyperv/netvsc_drv.c bonding flagsclassDiagram
class net_device {
+flags
+priv_flags
}
Class diagram for drivers/mmc/host/sdhci_am654.c quirks2 updateclassDiagram
class sdhci_pltfm_data {
+quirks2
}
Class diagram for drivers/mmc/host/bcm2835.c dma_unmap_sg fixclassDiagram
class bcm2835_host {
+dma_chan
}
Class diagram for fs/isofs/inode.c file type validationclassDiagram
class inode {
+i_mode
+i_op
+i_data
+i_rdev
+i_ino
}
Class diagram for fs/smb/client/file.c oplock break superblock refclassDiagram
class cifsFileInfo {
+dentry
+oplock_break
}
class inode {
+i_sb
}
class cifs_sb_info {
}
cifsFileInfo <.. inode : uses
inode <.. cifs_sb_info : uses
Class diagram for fs/smb/client/smb2ops.c crypt_message waitclassDiagram
class TCP_Server_Info {
}
class crypt_message {
+crypt_message(server: TCP_Server_Info, num_rqst, ...)
}
TCP_Server_Info <.. crypt_message : used by
Class diagram for kernel/bpf/helpers.c bpf_bprintf_prepare pointer handlingclassDiagram
class bpf_bprintf_prepare {
+bpf_bprintf_prepare(fmt, fmt_size, raw_args, ...)
}
Class diagram for kernel/cgroup/legacy_freezer.c cgroup_freezingclassDiagram
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
Class diagram for kernel/trace/trace_events.c event registration lockingclassDiagram
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
Class diagram for io_uring/net.c io_connect changesclassDiagram
class io_kiocb {
+flags
+file
}
class io_connect {
+io_connect(req: io_kiocb, issue_flags)
}
io_kiocb <.. io_connect : used by
Class diagram for io_uring/poll.c poll check eventsclassDiagram
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
Class diagram for fs/cachefiles/io.c and ondemand.c write iterclassDiagram
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
Class diagram for drivers/md/dm-bufio.c __evict_many cond_reschedclassDiagram
class dm_bufio_client {
}
class __evict_many {
+__evict_many(c: dm_bufio_client, ...)
}
dm_bufio_client <.. __evict_many : used by
Class diagram for drivers/comedi/drivers.c dio config and update stateclassDiagram
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
Class diagram for drivers/comedi/drivers/aio_iiro_16.c IRQ validationclassDiagram
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
Class diagram for drivers/comedi/drivers/das16m1.c IRQ validationclassDiagram
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
Class diagram for drivers/comedi/drivers/das6402.c IRQ validationclassDiagram
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
Class diagram for drivers/comedi/drivers/pcl812.c IRQ validationclassDiagram
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
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
deepin pr auto review代码审查反馈:
以上是对代码审查的反馈,希望能够帮助到您。 |
There was a problem hiding this 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.
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
There was a problem hiding this 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),
/approve |
[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 |
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)
[ 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)
45fae10
to
c1bd6fc
Compare
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:
Enhancements:
Build: