On 12/17/2025 9:16 AM, Manivannan Sadhasivam via B4 Relay wrote: > From: Manivannan Sadhasivam <[email protected]> > > MHI stack offers the 'auto_queue' feature, which allows the MHI stack to > auto queue the buffers for the RX path (DL channel). Though this feature > simplifies the client driver design, it introduces race between the client > drivers and the MHI stack. For instance, with auto_queue, the 'dl_callback' > for the DL channel may get called before the client driver is fully probed. > This means, by the time the dl_callback gets called, the client driver's > structures might not be initialized, leading to NULL ptr dereference. > > Currently, the drivers have to workaround this issue by initializing the > internal structures before calling mhi_prepare_for_transfer_autoqueue(). > But even so, there is a chance that the client driver's internal code path > may call the MHI queue APIs before mhi_prepare_for_transfer_autoqueue() is > called, leading to similar NULL ptr dereference. This issue has been > reported on the Qcom X1E80100 CRD machines affecting boot. > > So to properly fix all these races, drop the MHI 'auto_queue' feature > altogether and let the client driver (QRTR) manage the RX buffers manually. > In the QRTR driver, queue the RX buffers based on the ring length during > probe and recycle the buffers in 'dl_callback' once they are consumed. This > also warrants removing the setting of 'auto_queue' flag from controller > drivers. > > Currently, this 'auto_queue' feature is only enabled for IPCR DL channel. > So only the QRTR client driver requires the modification. > > Cc: [email protected] > Fixes: 227fee5fc99e ("bus: mhi: core: Add an API for auto queueing buffers > for DL channel") > Fixes: 68a838b84eff ("net: qrtr: start MHI channel after endpoit creation") > Reported-by: Johan Hovold <[email protected]> > Closes: > https://lore.kernel.org/linux-arm-msm/[email protected] > Suggested-by: Chris Lew <[email protected]> > Signed-off-by: Manivannan Sadhasivam <[email protected]>
Acked-by: Jeff Johnson <[email protected]> # drivers/net/wireless/ath/...
