Re: [PATCH] net: qrtr: Unprepare MHI channels during remove

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Jeff,
On 2020-11-18 10:34 AM, Jeffrey Hugo wrote:
On 11/18/2020 11:20 AM, Bhaumik Bhatt wrote:
Reset MHI device channels when driver remove is called due to
module unload or any crash scenario. This will make sure that
MHI channels no longer remain enabled for transfers since the
MHI stack does not take care of this anymore after the auto-start
channels feature was removed.

Signed-off-by: Bhaumik Bhatt <bbhatt@xxxxxxxxxxxxxx>
---
  net/qrtr/mhi.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/net/qrtr/mhi.c b/net/qrtr/mhi.c
index 7100f0b..2bf2b19 100644
--- a/net/qrtr/mhi.c
+++ b/net/qrtr/mhi.c
@@ -104,6 +104,7 @@ static void qcom_mhi_qrtr_remove(struct mhi_device *mhi_dev)
  	struct qrtr_mhi_dev *qdev = dev_get_drvdata(&mhi_dev->dev);
    	qrtr_endpoint_unregister(&qdev->ep);
+	mhi_unprepare_from_transfer(mhi_dev);
  	dev_set_drvdata(&mhi_dev->dev, NULL);
  }


I admit, I didn't pay much attention to the auto-start being removed,
but this seems odd to me.
It allows fair and common treatment for all client drivers.

As a client, the MHI device is being removed, likely because of some
factor outside of my control, but I still need to clean it up?  This
really feels like something MHI should be handling.
It isn't really outside of a client's control every time. If a client driver module is unloaded for example, it should be in their responsibility to clean up and send commands to close those channels which allows the device to clean
up the context.

In the event of a kernel panic or some device crash outside of a client's control, this function will just free some memory and return right away as MHI
knows not to pursue it over the link anyway.

Some client drivers depend on USB or other drivers, which allows flexibility on their end as to when to call these MHI prepare/unprepare for transfer APIs.

Thanks,
Bhaumik
---
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [Linux for Sparc]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux