wireguard-linux/drivers/bus/mhi, branch stable

Merge tag 'mhi-for-v7.3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mani/mhi into char-misc-next

2026-08-07T14:13:17Z

Manivannan writes: MHI Host -------- - Add SAHARA channel support in the pci_generic driver for Foxconn products. This allows capturing crashdump (ramdump) using the in-kernel sahara client driver. - Add support for devices with no M3 state. Some devices do not support the M3 power state due to hardware issues. For those devices, MHI bus will now run the full host-side suspend/resume sequence but skip the device-side M3/M0 handshake, so any transfer queued by clients during suspend is deferred until resume. - Set 'mhi_cntrl->no_m3' flag in the pci_generic driver for the QDU100 device so that the MHI bus also skips the M3 transition during system suspend. Earlier, the flag was only used to disable runtime PM, but the system suspend path was still transitioning the device to M3. - Fix sys error transition latency by polling for the state transition in mhi_pm_sys_error_transition() instead of waiting up to 24 seconds for an interrupt from the device. Since a device that has been reset (e.g., via AT!RESET) is not guaranteed to raise one. - Flush the posted write after writing to MHI_SOC_RESET_REQ_OFFSET in mhi_soc_reset() so that the reset actually reaches the device before the caller's post-reset delay begins. - Fix controller cleanup on EDL sysfs failure in mhi_register_controller(). The error path was leaving the device registered when sysfs_create_file() failed. MHI Endpoint ------------ - Add mhi_cntrl->flush_async() callback to drain the in-flight async DMA read/write operations issued through the MHI controller driver. This is used by the MHI EP stack before disconnect to avoid UAF where a late DMA completion could invoke a now-invalid xfer_cb(). - Implement the flush_async() callback in the PCI EPF MHI controller driver by waiting for the in-flight DMA operations to complete and then flushing the DMA workqueue. Since I'm the maintainer for this PCI EPF driver, I'm taking this patch through MHI tree due to dependency. - Flush the in-flight async transfers before notifying disconnect in mhi_ep_abort_transfer() to fix a UAF, where a success callback delivered after the -ENOTCONN notification could reference resources already freed by the client. - Fix device refcount leak in the error path of mhi_ep_create_device() when dev_set_name() or device_add() fails. Common ------ - Clean up kernel-doc warnings in include/linux/mhi.h. - Add Jeff Hugo as the Reviewer of MHI bus. * tag 'mhi-for-v7.3' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/mani/mhi: PCI: epf-mhi: Implement mhi_cntrl->flush_async() to flush DMA read/write bus: mhi: ep: Flush async transfers before notifying disconnect in mhi_ep_abort_transfer() bus: mhi: ep: Add mhi_cntrl->flush_async() callback to flush the async read/write bus: mhi: Clean up some kernel-doc warnings bus: mhi: host: Fix controller cleanup on EDL sysfs failure bus: mhi: pci_generic: Add SAHARA channel support for Foxconn products bus: mhi: host: pci_generic: Set 'mhi_cntrl->no_m3' flag bus: mhi: host: Add support for devices with no M3 state bus: mhi: host: Flush the posted write after writing to MHI_SOC_RESET_REQ_OFFSET MAINTAINERS: Add Jeff Hugo as the Reviewer of MHI bus bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation bus: mhi: core: Fix sys error transition latency

bus: mhi: ep: Flush async transfers before notifying disconnect in mhi_ep_abort_transfer()

2026-07-30T05:19:51Z

mhi_ep_abort_transfer() notifies the client drivers about the channel disconnect using -ENOTCONN and only then flushes the ring workqueue to drain the in-flight transfers. But the async DMA transfers issued by the ring workers can still complete after the notification. And the completion handlers trigger the client xfer_cb() as long as it is set. So a transfer completing during the flush can deliver a success callback to the client even after it has been notified about the disconnect. This can lead to UAF (Use-After-Free) issues as the client can free its per-transfer resources in response to the -ENOTCONN notification and the trailing success callback would then reference the freed resources. So to fix this issue, disable all the channels first to prevent new transfers and then drain both the ring workqueue and the in-flight async transfers before notifying the disconnect. The completion and queue paths bail out once the channel state is not MHI_CH_STATE_RUNNING, so disabling the channels upfront makes sure that no new transfer sneaks in during the drain and all the pending completions are delivered while xfer_cb() is still valid. Reviewed-by: Frank Li Signed-off-by: Manivannan Sadhasivam

bus: mhi: ep: Add mhi_cntrl->flush_async() callback to flush the async read/write

2026-07-30T05:19:51Z

MHI EP stack makes use of the MHI controller drivers like MHI EPF to do read/write to the host memory. And that driver is free to use mechanisms like DMA to offload the read/write operations. So if DMA is used for offload, then there is no guarantee that those DMA operations would be completed by the time mhi_ep_remove() gets called. This can lead to UAF (Use-After-Free) issues as the DMA callback can trigger xfer_cb() even after mhi_ep_remove() has returned. So to fix this issue, introduce the mhi_cntrl->flush_async() callback and call it in mhi_ep_remove() to drain all the in-flight async transfers before disconnecting the channels. The completion handlers keep triggering xfer_cb() as long as it is set. So flushing the transfers after notifying the client about the disconnect (-ENOTCONN) would still let a success callback slip through afterwards and lead to the same UAF. So disable the channels first to prevent new transfers, then flush the in-flight transfers so that their completions are delivered while xfer_cb() is still valid and only then notify the disconnect and clear xfer_cb(). Fixes: 2547beb00ddb ("bus: mhi: ep: Add support for async DMA read operation") Fixes: ee08acb58fe4 ("bus: mhi: ep: Add support for async DMA write operation") Reviewed-by: Frank Li Cc: stable+noautosel@kernel.org # Needs dmaengine driver fix as well Signed-off-by: Manivannan Sadhasivam

bus: mhi: host: Fix controller cleanup on EDL sysfs failure

2026-07-30T05:19:51Z

mhi_register_controller() adds the controller device before creating the optional trigger_edl sysfs file. If sysfs_create_file() fails, the error path only drops the device reference and leaves the device registered. Hence, call device_del() in the error path before put_device(). Fixes: 17553ba8e19d ("bus: mhi: host: Add sysfs entry to force device to enter EDL") Signed-off-by: Yuho Choi Signed-off-by: Manivannan Sadhasivam

bus: mhi: pci_generic: Add SAHARA channel support for Foxconn products

2026-07-30T05:19:51Z

Add SAHARA channel to support capturing crash dump (ramdump) using the in-kernel sahara client driver. Signed-off-by: Slark Xiao [mani: commit log] Signed-off-by: Manivannan Sadhasivam

bus: mhi: host: pci_generic: Set 'mhi_cntrl->no_m3' flag

2026-07-30T05:19:51Z

Commit 0494cf9793b7 ("bus: mhi: host: pci_generic: Disable runtime PM for QDU100") added the 'no_m3' flag to indicate that the QDU100 device doesn't support M3 state and used this flag to skip runtime PM. But it didn't prevent the MHI bus from transitioning the device to M3 during system suspend. So set 'mhi_cntrl->no_m3' flag based on the local 'info->no_m3' flag to indicate MHI bus that this device doesn't support M3 state so that it can skip the transition. Cc: stable+noautosel@kernel.org # depends on the 'mhi_cntrl->no_m3' flag addition Fixes: 0494cf9793b7 ("bus: mhi: host: pci_generic: Disable runtime PM for QDU100") Reported-by: Krishna Chaitanya Chundru Signed-off-by: Manivannan Sadhasivam

bus: mhi: host: Add support for devices with no M3 state

2026-07-30T05:19:50Z

MHI bus transitions the device into M3 state during suspend and back to M0 state during resume. But due to hardware issues, some devices do not support M3 state. To support these devices properly, MHI bus needs to skip transitioning the device to M3 during suspend and back to M0 during resume. For this purpose, introduce the 'mhi_cntrl->no_m3' flag and allow it to be set by the MHI controller drivers. Once set, this flag lets the MHI bus skip transitioning the device to M3/M0 during suspend/resume. But, simply skipping suspend/resume for such devices is not sufficient, as it leaves the MHI host in M0 state with device access enabled. Client drivers that do not implement PM callbacks (for instance, the non-freezable rx_refill worker in mhi_net driver) could then keep ringing channel doorbells and issue MMIO to the device even after the controller driver has disabled it and moved it to D3 during its own suspend, resulting in access to a powered down device. So instead of skipping the entire suspend/resume operation, run the full host suspend/resume sequence but without the device-side M state handshake. During suspend, only transition the host to M3 without sending the MHICTRL M3 command or waiting for the device M3 event. During resume, bring the host back to M0 through mhi_pm_m0_transition() without sending the MHICTRL M0 command. With the host in M3, all device access is gated by MHI_DB_ACCESS_VALID() and MHI_REG_ACCESS_VALID(), so any transfer queued by the clients during suspend is deferred until resume, where mhi_pm_m0_transition() rings the pending doorbells. Signed-off-by: Manivannan Sadhasivam

bus: mhi: host: Flush the posted write after writing to MHI_SOC_RESET_REQ_OFFSET

2026-07-30T05:19:43Z

mhi_soc_reset() tries to reset the device by writing to the MHI_SOC_RESET_REQ_OFFSET register. But it doesn't do a read-back to ensure that the write gets flushed to the device before returning to the caller. This may lead to the delay (if implemented) on the caller to be insufficient, if the posted write doesn't reach the device before the delay. So add a read-back after writing to the MHI_SOC_RESET_REQ_OFFSET register. Fixes: b5a8d233a588 ("bus: mhi: core: Add device hardware reset support") Reported-by: Alex Williamson Closes: https://lore.kernel.org/linux-pci/20260622160822.09350246@shazbot.org Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Reviewed-by: Jeff Hugo Link: https://patch.msgid.link/20260623145134.43976-1-manivannan.sadhasivam@oss.qualcomm.com

bus: mhi: ep: Fix device refcount leak in the error path of MHI device creation

2026-07-09T06:06:26Z

mhi_ep_create_device() takes one device reference for the UL channel and another for the DL channel after allocating the transfer device. These references are normally released by mhi_ep_destroy_device() before the device itself is removed. If dev_set_name() or device_add() fails, the error path currently drops only one reference. The remaining channel references keep the device from being released and leave the channels associated with a device that was never registered. Route both failures through a common unwind path that drops the DL channel reference, the UL channel reference, and the initial reference from device_initialize(). Fixes: 297c77a0f273 ("bus: mhi: ep: Add support for creating and destroying MHI EP devices") Signed-off-by: Yuho Choi Signed-off-by: Manivannan Sadhasivam Link: https://patch.msgid.link/20260603195142.2189386-1-dbgh9129@gmail.com

bus: mhi: core: Fix sys error transition latency

2026-07-09T05:54:15Z

Bring forward the idea to fix the power down latency in mhi_pm_disable_transition() further to mhi_pm_sys_error_transition() so that the transition into system error (triggered by AT!RESET) in the modems won't have to return only after the timeout of up to 24 seconds. Once the device gets reset, there is no guarantee that it will send an interrupt to indicate the state transition. So polling is the sensible option here. Signed-off-by: Qingtao Cao [mani: commit log] Signed-off-by: Manivannan Sadhasivam Reviewed-by: Krishna Chaitanya Chundru Link: https://patch.msgid.link/20260603011333.3306102-2-qingtao.cao.au@gmail.com