Uh oh!
There was an error while loading. Please reload this page.
Prepare qcom-next based on tag 'Linux 6.18' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git - #125
Closed
Salendarsingh Gaud (sgaud-quic) wants to merge 387 commits into
Conversation
Implement the infrastructure for using the new DMA controller lock/unlock feature of the BAM driver. No functional change for now. Link: https://lore.kernel.org/lkml/20251106-qcom-qce-cmd-descr-v8-10-ecddca23ca26@linaro.org/ Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
With everything else in place, we can now switch to actually using the BAM DMA for register I/O with DMA engine locking. Link: https://lore.kernel.org/lkml/20251106-qcom-qce-cmd-descr-v8-11-ecddca23ca26@linaro.org/ Signed-off-by: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
…-SOM platform HAMOA IoT SOM requires PCIe3 and PCIe5 connectivity for SATA controller and SDX65. Add the required sideband signals (PERST#, WAKE#, CLKREQ#), pinctrl states and power supply properties in the device tree, which PCIe3 and PCIe5 require. Link: https://lore.kernel.org/all/20251112090316.936187-2-ziyue.zhang@oss.qualcomm.com/ Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…IOT-EVK board HAMAO IoT EVK uses PCIe5 to connect an SDX65 module for WWAN functionality and PCIe3 to connect a SATA controller. These interfaces require multiple voltage rails: PCIe5 needs 3.3V supplied by vreg_wwan, while PCIe3 requires 12V, 3.3V, and 3.3V AUX rails, controlled via PMIC GPIOs. Add the required fixed regulators with related pin configuration, and connect them to the PCIe3 and PCIe5 ports to ensure proper power for the SDX65 module and SATA controller. Link: https://lore.kernel.org/all/20251112090316.936187-3-ziyue.zhang@oss.qualcomm.com/ Signed-off-by: Ziyue Zhang <ziyue.zhang@oss.qualcomm.com> Reviewed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
…aco-evk Enables PCIe0 and PCIe1 controller and phy-nodes. PCIe0 is routed to an m.2 E key connector on the mainboard for wifi attaches while PCIe1 routes to a standard PCIe x4 expansion slot. Link: https://lore.kernel.org/all/20251111-monaco-evk-pci-v1-1-8013d0d6a7ca@quicinc.com/ Signed-off-by: Sushrut Shree Trivedi <quic_sushruts@quicinc.com>
SM6150 and QCS615 are two names for the same die, collectively known as 'talos'. Follow the example of other platforms and rename SM6150 to talos.dtsi. Link: https://lore.kernel.org/r/20250923-rename-dts-v1-3-21888b68c781@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
QUP devices are currently marked with opp-shared in their OPP table, causing the kernel to treat them as part of a shared OPP domain. This leads to the qcom_geni_serial driver failing to probe with error -EBUSY (-16). Remove the opp-shared property to ensure the OPP framework treats the QUP OPP table as device-specific, allowing the serial driver to probe successfully Link: https://lore.kernel.org/all/20251111170350.525832-1-viken.dadhaniya@oss.qualcomm.com/ Fixes: f6746dc ("arm64: dts: qcom: qcs615: Add QUPv3 configuration") Signed-off-by: Viken Dadhaniya <viken.dadhaniya@oss.qualcomm.com>
Enable WLAN on qcs8300-ride by adding a node for the PMU module of the WCN6855 and assigning its LDO power outputs to the existing WiFi module. On the qcs8300-ride platform, the corresponding firmware and BDF are QCA6698AQ instead of WCN6855, which have been added in the 20250211 release. Link: https://lore.kernel.org/all/20251113055148.2729943-1-wei.zhang@oss.qualcomm.com/ Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Wei Zhang <wei.zhang@oss.qualcomm.com>
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies. Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module. The module provides a 3.3V supply, which originates from the main board’s 12V rail. To represent this power hierarchy in the device tree, add a fixed 12V regulator node as the DC-IN source and link it to the 3.3V regulator node. Link: https://lore.kernel.org/all/20251112071147.1450258-2-wei.deng@oss.qualcomm.com/ Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Document scm compatible for the Qualcomm Kaanapali SoC. Reviewed-by: Eugen Hristev <eugen.hristev@linaro.org> Signed-off-by: Jingyi Wang <jingyi.wang@oss.qualcomm.com> Acked-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251022-knp-soc-binding-v2-3-3cd3f390f3e2@oss.qualcomm.com/
There's a WCN6855 WiFi/Bluetooth module on an M.2 card. To make Bluetooth work, we need to define the necessary device tree nodes, including UART configuration and power supplies. Since there is no standard M.2 binding in the device tree at present, the PMU is described using dedicated PMU nodes to represent the internal regulators required by the module. The module provides a 3.3V supply, which originates from the main board’s 12V rail. To represent this power hierarchy in the device tree, add a fixed 12V regulator node as the DC-IN source and link it to the 3.3V regulator node. Link: https://lore.kernel.org/all/20251113130519.2647081-1-wei.deng@oss.qualcomm.com/ Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
Document compatible string for the QFPROM on Lemans platform. Link: https://lore.kernel.org/all/20250910-a663-gpu-support-v6-2-5da15827b249@oss.qualcomm.com/ Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Signed-off-by: Haitao Xu <haitxu@qti.qualcomm.com>
Add support for Adreno 612 GPU found in SM6150/QCS615 chipsets. A612 falls under ADRENO_6XX_GEN1 family and is a cut down version of A615 GPU. A612 has a new IP called Reduced Graphics Management Unit or RGMU which is a small state machine which helps to toggle GX GDSC (connected to CX rail) to implement IFPC feature. It doesn't support any other features of a full fledged GMU like clock control, resource voting to rpmh etc. So we need linux clock driver support like other gmu-wrapper implementations to control gpu core clock and gpu GX gdsc. This patch skips RGMU core initialization and act more like a gmu-wrapper case. Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> Link: https://lore.kernel.org/all/20251107-qcs615-spin-2-v2-1-a2d7c4fbf6e6@oss.qualcomm.com/
Add MIPI OST(Open System Trace) protocol support for stm to format the traces. The OST Protocol abstracts the underlying layers from the sending and receiving applications, thus removing dependencies on the connection media and platform implementation. OST over STP packet consists of Header/Payload/End. Header is designed to include the information required by all OST packets. Information that is not shared by all packets is left to the higher layer protocols. Thus, the OST Protocol Header can be regarded as the first part of a complete OST Packet Header, while a higher layer header can be regarded as an extension designed for a specific purpose. +--------+--------+--------+--------+ | start |version |entity |protocol| +--------+--------+--------+--------+ | stm version | magic | +-----------------------------------+ | cpu | +-----------------------------------+ | timestamp | | | +-----------------------------------+ | tgid | | | +-----------------------------------+ | payload | +-----------------------------------+ | ... | end | +-----------------------------------+ In header, there will be STARTSIMPLE/VERSION/ENTITY/PROTOCOL. STARTSIMPLE is used to signal the beginning of a simplified OST protocol. The Version field is a one byte, unsigned number identifying the version of the OST Protocol. The Entity ID field is a one byte unsigned number that identifies the source. The Protocol ID field is a one byte unsigned number identifying the higher layer protocol of the OST Packet, i.e. identifying the format of the data after the OST Protocol Header. OST Control Protocol ID value represents the common control protocol, the remaining Protocol ID values may be used by any higher layer protocols capable of being transported by the OST Protocol. Link: https://lore.kernel.org/all/20251024-p_ost-v4-1-3652a06fd055@oss.qualcomm.com/ Signed-off-by: Tingwei Zhang <tingwei.zhang@oss.qualcomm.com> Signed-off-by: Yuanfang Zhang <yuanfang.zhang@oss.qualcomm.com> Signed-off-by: Jinlong Mao <jinlong.mao@oss.qualcomm.com> Signed-off-by: Yingchao Deng <yingchao.deng@oss.qualcomm.com>
Enable ST33HTPM TPM over SPI16 on the LeMans IoT EVK by adding the required SPI and TPM nodes. Link: https://lore.kernel.org/all/20251114-enable-tpm-lemans-v1-1-c8d8b580ace7@oss.qualcomm.com/ Signed-off-by: Khalid Faisal Ansari <khalid.ansari@oss.qualcomm.com>
Enable ST33HTPM TPM over SPI10 on the Monaco IoT EVK by adding the required SPI and TPM nodes. Link: https://lore.kernel.org/all/20251114-enable-tpm-monaco-v1-1-4ed566838698@oss.qualcomm.com/ Signed-off-by: Khalid Faisal Ansari <khalid.ansari@oss.qualcomm.com>
Add reserved memory region for audio PD dynamic loading and remote heap requirement. Also add LPASS and ADSP_HEAP VMIDs. Link: https://lore.kernel.org/all/20251117070819.492-1-jianping.li@oss.qualcomm.com/ Signed-off-by: Jianping Li <jianping.li@oss.qualcomm.com>
The static TPDM device is intended for sources that do not require MMIO mapping. Its compatible string should be documented clearly, along with an example illustrating how to define a static TPDM node in the DT. Link: https://lore.kernel.org/all/20251028-add_static_tpdm_support-v4-1-84e21b98e727@oss.qualcomm.com/ Reviewed-by: Rob Herring (Arm) <robh@kernel.org> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
Add CoreSight DT nodes for AOSS, QDSS, Turing, and Modem blocks to enable the STM and TPDM sources to route trace data to the ETF for debugging. Link: https://lore.kernel.org/all/20251117-add-coresight-nodes-for-pakala-v1-1-d26bfaa44fe7@oss.qualcomm.com/ Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
…en4 2-lanes PHY The fourth and sixth PCIe instances on Glymur are both Gen4 2-lane PHY. So document the compatible. Link: https://lore.kernel.org/all/20251015-phy-qcom-pcie-add-glymur-v1-1-1af8fd14f033@linaro.org/ Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Glymur platform has two Gen4 2-lanes controllers, the fourth and sixth instances. Add support for their PHYs. Link: https://lore.kernel.org/all/20251015-phy-qcom-pcie-add-glymur-v1-2-1af8fd14f033@linaro.org/ Signed-off-by: Abel Vesa <abel.vesa@linaro.org>
Add Kaanapali compatible consistent with CAMSS CCI interfaces. Signed-off-by: Hangxiang Ma <hangxiang.ma@oss.qualcomm.com> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Andi Shyti <andi.shyti@kernel.org> Link: https://lore.kernel.org/r/20251028-add-support-for-camss-on-kaanapali-v4-1-7eb484c89585@oss.qualcomm.com Signed-off-by: Yijie Yang <yijie.yang@oss.qualcomm.com>
Make all struct platform_inst_fw_cap instances constant, they are not modified at runtime. Link: https://gitlab.freedesktop.org/linux-media/media-committers/-/commit/e5894eeefdebf5a6d7512cd23efec78071985738 Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Make all struct iris_platform_data instances constant, they are not modified at runtime. Link: https://gitlab.freedesktop.org/linux-media/media-committers/-/commit/7a02a8b98419c992faf8ab714cf4df7da99b2c46 Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The value of the PIPE property depends on the number of pipes available on the platform and is frequently the only difference between several fw_caps. In order to reduce duplciation, use num_vpp_pipe from the iris_platform_data rather than hardcoding the value into the fw_cap. Link: https://gitlab.freedesktop.org/linux-media/media-committers/-/commit/6c67d1cf18dce081f126a6aeb9f7cbd328805591 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
…d qcs8300 Now as we have removed PIPE value from inst_fw_caps_dec there should be no difference between inst_fw_caps of QCS8300 and SM8550+. Drop the QCS8300-specific tables and use generic one instead. The differences between QCS8300 and SM8550 data comes from a non-conflict merge of commit d22037f ("media: iris: Set platform capabilities to firmware for encoder video device") (which added .set callbacks), and commit 6bdfa3f ("media: iris: Add platform-specific capabilities for encoder video device") (which added QCS8300 data, but not the callbacks). Link: https://gitlab.freedesktop.org/linux-media/media-committers/-/commit/69dfada4c9d077fefc968cca8186ce975d874d49 Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
In preparation to adding more Gen1 platforms, which will share a significant amount of data, rename the SM8250 platform file to iris_platform_gen1.c. Link: https://gitlab.freedesktop.org/linux-media/media-committers/-/commit/3b72f5e206e65d57df99677dc3142be913cc2114 Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
As a part of migrating code from the old Venus driver to the new Iris one, add support for the SC7280 platform. It is very similar to SM8250, but it (currently) uses no reset controls (there is an optional GCC-generated reset, it will be added later) and no AON registers region. Extend the VPU ops to support optional clocks and skip the AON shutdown for this platform. Link: https://gitlab.freedesktop.org/linux-media/media-committers/-/commit/542e3540ddd75f0a46dd365978476bcc1dda5b5a Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com> Reviewed-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>
…ge during STOP handling
Currently v4l2_m2m_ioctl_{de,enc}coder_cmd is being invoked during STOP
command handling. However, this is not required as the iris driver has
its own drain and stop handling mechanism in place.
Using the m2m command API in this context leads to incorrect behavior,
where the LAST flag is prematurely attached to a capture buffer,
when there are no buffers in m2m source queue. But, in this scenario
even though the source buffers are returned to client, hardware might
still need to process the pending capture buffers.
Attaching LAST flag prematurely can result in the capture buffer being
removed from the destination queue before the hardware has finished
processing it, causing issues when the buffer is eventually returned by
the hardware.
To prevent this, remove the m2m API usage in stop handling.
Link: https://lore.kernel.org/linux-media/20251102-iris-drain-fix-v1-1-7f88d187fb48@oss.qualcomm.com/
Fixes: d091007 ("media: iris: add support for drain sequence")
Fixes: 75db90a ("media: iris: Add support for drain sequence in encoder video device")
Reviewed-by: Vikash Garodia <vikash.garodia@oss.qualcomm.com>
Signed-off-by: Dikshita Agarwal <dikshita.agarwal@oss.qualcomm.com>Enable BT on qcs8300-ride by adding a BT device tree node. Since the platform uses the QCA6698 Bluetooth chip. While the QCA6698 shares the same IP core as the WCN6855, it has different RF components and RAM sizes, requiring new firmware files. Use the firmware-name property to specify the NVM and rampatch firmware to load. Link: https://lore.kernel.org/all/20251118140406.1551669-2-wei.deng@oss.qualcomm.com/ Signed-off-by: Wei Deng <wei.deng@oss.qualcomm.com>
# Conflicts: # arch/arm64/boot/dts/qcom/Makefile
# Conflicts: # include/linux/firmware/qcom/qcom_scm.h
Adding merge log file and topic_SHA1 file Signed-off-by: Salendarsingh Gaud <sgaud@qti.qualcomm.com>
Salendarsingh Gaud (sgaud-quic)
deleted the
qcom-next-staging-6.18-20251210
branch
December 11, 2025 07:30
Salendarsingh Gaud (sgaud-quic) pushed a commit
to sgaud-quic/kernel
that referenced
this pull request
Apr 1, 2026
The devm_free_irq() and devm_request_irq() functions should not be
executed in an atomic context.
During device suspend, all userspace processes and most kernel threads
are frozen. Additionally, we flush all tx/rx status, disable all macb
interrupts, and halt rx operations. Therefore, it is safe to split the
region protected by bp->lock into two independent sections, allowing
devm_free_irq() and devm_request_irq() to run in a non-atomic context.
This modification resolves the following lockdep warning:
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 501, name: rtcwake
preempt_count: 1, expected: 0
RCU nest depth: 1, expected: 0
7 locks held by rtcwake/501:
#0: ffff0008038c3408 (sb_writers#5){.+.+}-{0:0}, at: vfs_write+0xf8/0x368
#1: ffff0008049a5e88 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0xbc/0x1c8
#2: ffff00080098d588 (kn->active#70){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xcc/0x1c8
#3: ffff800081c84888 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0x1ec/0x290
#4: ffff0008009ba0f8 (&dev->mutex){....}-{4:4}, at: device_suspend+0x118/0x4f0
#5: ffff800081d00458 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x48
#6: ffff0008031fb9e0 (&bp->lock){-.-.}-{3:3}, at: macb_suspend+0x144/0x558
irq event stamp: 8682
hardirqs last enabled at (8681): [<ffff8000813c7d7c>] _raw_spin_unlock_irqrestore+0x44/0x88
hardirqs last disabled at (8682): [<ffff8000813c7b58>] _raw_spin_lock_irqsave+0x38/0x98
softirqs last enabled at (7322): [<ffff8000800f1b4c>] handle_softirqs+0x52c/0x588
softirqs last disabled at (7317): [<ffff800080010310>] __do_softirq+0x20/0x2c
CPU: 1 UID: 0 PID: 501 Comm: rtcwake Not tainted 7.0.0-rc3-next-20260310-yocto-standard+ qualcomm-linux#125 PREEMPT
Hardware name: ZynqMP ZCU102 Rev1.1 (DT)
Call trace:
show_stack+0x24/0x38 (C)
__dump_stack+0x28/0x38
dump_stack_lvl+0x64/0x88
dump_stack+0x18/0x24
__might_resched+0x200/0x218
__might_sleep+0x38/0x98
__mutex_lock_common+0x7c/0x1378
mutex_lock_nested+0x38/0x50
free_irq+0x68/0x2b0
devm_irq_release+0x24/0x38
devres_release+0x40/0x80
devm_free_irq+0x48/0x88
macb_suspend+0x298/0x558
device_suspend+0x218/0x4f0
dpm_suspend+0x244/0x3a0
dpm_suspend_start+0x50/0x78
suspend_devices_and_enter+0xec/0x560
pm_suspend+0x194/0x290
state_store+0x110/0x158
kobj_attr_store+0x1c/0x30
sysfs_kf_write+0xa8/0xd0
kernfs_fop_write_iter+0x11c/0x1c8
vfs_write+0x248/0x368
ksys_write+0x7c/0xf8
__arm64_sys_write+0x28/0x40
invoke_syscall+0x4c/0xe8
el0_svc_common+0x98/0xf0
do_el0_svc+0x28/0x40
el0_svc+0x54/0x1e0
el0t_64_sync_handler+0x84/0x130
el0t_64_sync+0x198/0x1a0
Fixes: 558e35c ("net: macb: WoL support for GEM type of Ethernet controller")
Cc: stable@vger.kernel.org
Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com>
Signed-off-by: Kevin Hao <haokexin@gmail.com>
Link: https://patch.msgid.link/20260318-macb-irq-v2-1-f1179768ab24@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>svankas (svankas) pushed a commit
to svankas/kernel
that referenced
this pull request
Apr 3, 2026
commit 317e493 upstream. The devm_free_irq() and devm_request_irq() functions should not be executed in an atomic context. During device suspend, all userspace processes and most kernel threads are frozen. Additionally, we flush all tx/rx status, disable all macb interrupts, and halt rx operations. Therefore, it is safe to split the region protected by bp->lock into two independent sections, allowing devm_free_irq() and devm_request_irq() to run in a non-atomic context. This modification resolves the following lockdep warning: BUG: sleeping function called from invalid context at kernel/locking/mutex.c:591 in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 501, name: rtcwake preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 0 7 locks held by rtcwake/501: #0: ffff0008038c3408 (sb_writers#5){.+.+}-{0:0}, at: vfs_write+0xf8/0x368 qualcomm-linux#1: ffff0008049a5e88 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0xbc/0x1c8 qualcomm-linux#2: ffff00080098d588 (kn->active#70){.+.+}-{0:0}, at: kernfs_fop_write_iter+0xcc/0x1c8 qualcomm-linux#3: ffff800081c84888 (system_transition_mutex){+.+.}-{4:4}, at: pm_suspend+0x1ec/0x290 qualcomm-linux#4: ffff0008009ba0f8 (&dev->mutex){....}-{4:4}, at: device_suspend+0x118/0x4f0 qualcomm-linux#5: ffff800081d00458 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire+0x4/0x48 qualcomm-linux#6: ffff0008031fb9e0 (&bp->lock){-.-.}-{3:3}, at: macb_suspend+0x144/0x558 irq event stamp: 8682 hardirqs last enabled at (8681): [<ffff8000813c7d7c>] _raw_spin_unlock_irqrestore+0x44/0x88 hardirqs last disabled at (8682): [<ffff8000813c7b58>] _raw_spin_lock_irqsave+0x38/0x98 softirqs last enabled at (7322): [<ffff8000800f1b4c>] handle_softirqs+0x52c/0x588 softirqs last disabled at (7317): [<ffff800080010310>] __do_softirq+0x20/0x2c CPU: 1 UID: 0 PID: 501 Comm: rtcwake Not tainted 7.0.0-rc3-next-20260310-yocto-standard+ qualcomm-linux#125 PREEMPT Hardware name: ZynqMP ZCU102 Rev1.1 (DT) Call trace: show_stack+0x24/0x38 (C) __dump_stack+0x28/0x38 dump_stack_lvl+0x64/0x88 dump_stack+0x18/0x24 __might_resched+0x200/0x218 __might_sleep+0x38/0x98 __mutex_lock_common+0x7c/0x1378 mutex_lock_nested+0x38/0x50 free_irq+0x68/0x2b0 devm_irq_release+0x24/0x38 devres_release+0x40/0x80 devm_free_irq+0x48/0x88 macb_suspend+0x298/0x558 device_suspend+0x218/0x4f0 dpm_suspend+0x244/0x3a0 dpm_suspend_start+0x50/0x78 suspend_devices_and_enter+0xec/0x560 pm_suspend+0x194/0x290 state_store+0x110/0x158 kobj_attr_store+0x1c/0x30 sysfs_kf_write+0xa8/0xd0 kernfs_fop_write_iter+0x11c/0x1c8 vfs_write+0x248/0x368 ksys_write+0x7c/0xf8 __arm64_sys_write+0x28/0x40 invoke_syscall+0x4c/0xe8 el0_svc_common+0x98/0xf0 do_el0_svc+0x28/0x40 el0_svc+0x54/0x1e0 el0t_64_sync_handler+0x84/0x130 el0t_64_sync+0x198/0x1a0 Fixes: 558e35c ("net: macb: WoL support for GEM type of Ethernet controller") Cc: stable@vger.kernel.org Reviewed-by: Théo Lebrun <theo.lebrun@bootlin.com> Signed-off-by: Kevin Hao <haokexin@gmail.com> Link: https://patch.msgid.link/20260318-macb-irq-v2-1-f1179768ab24@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Name SHA Commits
tech/bsp/clk aea4f0c 8
tech/bsp/interconnect 938409e 2
tech/security/firmware-smc a50984a 2
tech/bsp/soc-infra 797d5a2 18
tech/bsp/pinctrl 9a297f4 2
tech/bsp/remoteproc 464fb78 13
tech/bus/peripherals 486bcf7 1
tech/bus/pci/all 205830c 8
tech/bus/pci/pwrctl c36944e 7
tech/bus/usb/dwc c29f570 1
tech/debug/eud eb36d9d 1
tech/debug/hwtracing 9616409 34
tech/pmic/misc 8fba65f 14
tech/pmic/regulator 81fc8fb 6
tech/mem/iommu fc1b59c 1
tech/mm/audio/all 37d1752 1
tech/mm/camss d1d2c38 3
tech/mm/drm 378575e 38
tech/mm/fastrpc dba4eb2 3
tech/mm/video 1af1bf9 13
tech/mm/gpu 66e3106 2
tech/net/ath 7ed8cea 2
tech/net/eth c280d7e 1
tech/net/bluetooth b5902f2 2
tech/pm/pmdomain c2e58ee 3
tech/pm/power 9fe45cf 7
tech/pm/thermal 44a5bf0 1
tech/security/crypto 0ff2ae7 11
tech/security/ice e614034 3
tech/storage/all ba8c93d 6
tech/all/dt/qcs6490 91a5f25 7
tech/all/dt/qcs9100 ae04b95 15
tech/all/dt/qcs8300 6fc2c39 28
tech/all/dt/qcs615 ac047bf 8
tech/all/dt/hamoa 731b038 10
tech/all/dt/glymur 6e186f9 20
tech/all/dt/kaanapali 746a202 3
tech/all/dt/pakala e0326f1 4
tech/all/config b2866ec 28
tech/overlay/dt 03e0b7b 5
tech/all/workaround 841239d 3