[PATCH v2 0/6] Updates to MHI channel handling

[PATCH v2 0/6] Updates to MHI channel handling

[Bhaumik Bhatt]

MHI specification shows a state machine with support for STOP channel command
and the validity of certain state transitions. MHI host currently does not
provide any mechanism to stop a channel and restart it without resetting it.
There are also times when the device moves on to a different execution
environment while client drivers on the host are unaware of it and still
attempt to reset the channels facing unnecessary timeouts.

This series addresses the above areas to provide support for stopping an MHI
channel, resuming it back, improved documentation and improving upon channel
state machine handling in general.

This set of patches was tested on arm64 architecture.

v2:
-Renamed the newly introduced APIs to mhi_start_transfer() / mhi_stop_transfer()
-Added improved documentation to avoid confusion with the new APIs
-Removed the __ prefix from mhi_unprepare_channel() API for consistency.

Bhaumik Bhatt (6):
  bus: mhi: core: Allow receiving a STOP channel command response
  bus: mhi: core: Improvements to the channel handling state machine
  bus: mhi: core: Add support to stop or start channel data transfers
  bus: mhi: core: Check execution environment for channel before issuing
    reset
  bus: mhi: core: Remove __ prefix for MHI channel unprepare function
  bus: mhi: Improve documentation on channel transfer setup APIs

 drivers/bus/mhi/core/init.c     |  11 +-
 drivers/bus/mhi/core/internal.h |  12 +++
 drivers/bus/mhi/core/main.c     | 226 ++++++++++++++++++++++++++++------------
 include/linux/mhi.h             |  37 ++++++-
 4 files changed, 215 insertions(+), 71 deletions(-)

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

[PATCH v2 1/6] bus: mhi: core: Allow receiving a STOP channel command response

[Bhaumik Bhatt]

Add support to receive the response to a STOP channel command to the
MHI bus. If a client would like to STOP a channel instead of issuing
a RESET to it, this would provide support for it.

Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
---
 drivers/bus/mhi/core/init.c | 5 +++--
 drivers/bus/mhi/core/main.c | 5 +++++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 8cefa35..4d34d62 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev)
 
 		mutex_lock(&mhi_chan->mutex);
 
-		if (ch_state[dir] == MHI_CH_STATE_ENABLED &&
-		    !mhi_chan->offload_ch)
+		if ((ch_state[dir] == MHI_CH_STATE_ENABLED ||
+		     ch_state[dir] == MHI_CH_STATE_STOP) &&
+		     !mhi_chan->offload_ch)
 			mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
 
 		mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index f953e2a..ad881a1 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl,
 		cmd_tre->dword[0] = MHI_TRE_CMD_RESET_DWORD0;
 		cmd_tre->dword[1] = MHI_TRE_CMD_RESET_DWORD1(chan);
 		break;
+	case MHI_CMD_STOP_CHAN:
+		cmd_tre->ptr = MHI_TRE_CMD_STOP_PTR;
+		cmd_tre->dword[0] = MHI_TRE_CMD_STOP_DWORD0;
+		cmd_tre->dword[1] = MHI_TRE_CMD_STOP_DWORD1(chan);
+		break;
 	case MHI_CMD_START_CHAN:
 		cmd_tre->ptr = MHI_TRE_CMD_START_PTR;
 		cmd_tre->dword[0] = MHI_TRE_CMD_START_DWORD0;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 2/6] bus: mhi: core: Improvements to the channel handling state machine

[Bhaumik Bhatt]

Add support to enable sending the stop channel command and
improve the channel handling state machine such that all commands
go through a common function. This can help ensure that the state
machine is not violated in any way and adheres to the MHI
specification.

Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
---
 drivers/bus/mhi/core/init.c     |   6 ++
 drivers/bus/mhi/core/internal.h |  12 +++
 drivers/bus/mhi/core/main.c     | 163 ++++++++++++++++++++++++----------------
 3 files changed, 116 insertions(+), 65 deletions(-)

diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
index 4d34d62..c9b1de8 100644
--- a/drivers/bus/mhi/core/init.c
+++ b/drivers/bus/mhi/core/init.c
@@ -51,6 +51,12 @@ const char * const mhi_state_str[MHI_STATE_MAX] = {
 	[MHI_STATE_SYS_ERR] = "SYS_ERR",
 };
 
+const char * const mhi_ch_state_type_str[MHI_CH_STATE_TYPE_MAX] = {
+	[MHI_CH_STATE_TYPE_RESET] = "RESET",
+	[MHI_CH_STATE_TYPE_STOP] = "STOP",
+	[MHI_CH_STATE_TYPE_START] = "START",
+};
+
 static const char * const mhi_pm_state_str[] = {
 	[MHI_PM_STATE_DISABLE] = "DISABLE",
 	[MHI_PM_STATE_POR] = "POR",
diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
index 2df8de5..f4efb15 100644
--- a/drivers/bus/mhi/core/internal.h
+++ b/drivers/bus/mhi/core/internal.h
@@ -369,6 +369,18 @@ enum mhi_ch_state {
 	MHI_CH_STATE_ERROR = 0x5,
 };
 
+enum mhi_ch_state_type {
+	MHI_CH_STATE_TYPE_RESET,
+	MHI_CH_STATE_TYPE_STOP,
+	MHI_CH_STATE_TYPE_START,
+	MHI_CH_STATE_TYPE_MAX,
+};
+
+extern const char * const mhi_ch_state_type_str[MHI_CH_STATE_TYPE_MAX];
+#define TO_CH_STATE_TYPE_STR(state) (((state) >= MHI_CH_STATE_TYPE_MAX) ? \
+				     "INVALID_STATE" : \
+				     mhi_ch_state_type_str[state])
+
 #define MHI_INVALID_BRSTMODE(mode) (mode != MHI_DB_BRST_DISABLE && \
 				    mode != MHI_DB_BRST_ENABLE)
 
diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index ad881a1..1226933 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1220,56 +1220,120 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl,
 	return 0;
 }
 
-static void __mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
-				    struct mhi_chan *mhi_chan)
+static int mhi_update_channel_state(struct mhi_controller *mhi_cntrl,
+				    struct mhi_chan *mhi_chan,
+				    enum mhi_ch_state_type to_state)
 {
-	int ret;
 	struct device *dev = &mhi_cntrl->mhi_dev->dev;
+	enum mhi_cmd_type cmd = MHI_CMD_NOP;
+	int ret = -EIO;
+
+	dev_dbg(dev, "Updating channel %s(%d) state to: %s\n", mhi_chan->name,
+		mhi_chan->chan, TO_CH_STATE_TYPE_STR(to_state));
+
+	switch (to_state) {
+	case MHI_CH_STATE_TYPE_RESET:
+		write_lock_irq(&mhi_chan->lock);
+		if (mhi_chan->ch_state != MHI_CH_STATE_STOP &&
+		    mhi_chan->ch_state != MHI_CH_STATE_ENABLED &&
+		    mhi_chan->ch_state != MHI_CH_STATE_SUSPENDED) {
+			write_unlock_irq(&mhi_chan->lock);
+			goto exit_invalid_state;
+		}
+		mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
+		write_unlock_irq(&mhi_chan->lock);
 
-	dev_dbg(dev, "Entered: unprepare channel:%d\n", mhi_chan->chan);
+		cmd = MHI_CMD_RESET_CHAN;
+		break;
+	case MHI_CH_STATE_TYPE_STOP:
+		if (mhi_chan->ch_state != MHI_CH_STATE_ENABLED)
+			goto exit_invalid_state;
 
-	/* no more processing events for this channel */
-	mutex_lock(&mhi_chan->mutex);
-	write_lock_irq(&mhi_chan->lock);
-	if (mhi_chan->ch_state != MHI_CH_STATE_ENABLED &&
-	    mhi_chan->ch_state != MHI_CH_STATE_SUSPENDED) {
-		write_unlock_irq(&mhi_chan->lock);
-		mutex_unlock(&mhi_chan->mutex);
-		return;
+		cmd = MHI_CMD_STOP_CHAN;
+		break;
+	case MHI_CH_STATE_TYPE_START:
+		if (mhi_chan->ch_state != MHI_CH_STATE_STOP &&
+		    mhi_chan->ch_state != MHI_CH_STATE_DISABLED)
+			goto exit_invalid_state;
+
+		cmd = MHI_CMD_START_CHAN;
+		break;
+	default:
+		goto exit_invalid_state;
 	}
 
-	mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
-	write_unlock_irq(&mhi_chan->lock);
+	/* bring host and device out of suspended states */
+	ret = mhi_device_get_sync(mhi_cntrl->mhi_dev);
+	if (ret)
+		return ret;
+	mhi_cntrl->runtime_get(mhi_cntrl);
 
 	reinit_completion(&mhi_chan->completion);
-	read_lock_bh(&mhi_cntrl->pm_lock);
-	if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
-		read_unlock_bh(&mhi_cntrl->pm_lock);
-		goto error_invalid_state;
+	ret = mhi_send_cmd(mhi_cntrl, mhi_chan, cmd);
+	if (ret) {
+		dev_err(dev, "Failed to send %s(%d) %s command\n",
+			mhi_chan->name, mhi_chan->chan,
+			TO_CH_STATE_TYPE_STR(to_state));
+		goto exit_command_failure;
 	}
 
-	mhi_cntrl->wake_toggle(mhi_cntrl);
-	read_unlock_bh(&mhi_cntrl->pm_lock);
+	ret = wait_for_completion_timeout(&mhi_chan->completion,
+				       msecs_to_jiffies(mhi_cntrl->timeout_ms));
+	if (!ret || mhi_chan->ccs != MHI_EV_CC_SUCCESS) {
+		dev_err(dev, "Failed to receive %s(%d) %s command completion\n",
+			mhi_chan->name, mhi_chan->chan,
+			TO_CH_STATE_TYPE_STR(to_state));
+		ret = -EIO;
+		goto exit_command_failure;
+	}
 
-	mhi_cntrl->runtime_get(mhi_cntrl);
+	ret = 0;
+
+	if (to_state != MHI_CH_STATE_TYPE_RESET) {
+		write_lock_irq(&mhi_chan->lock);
+		mhi_chan->ch_state = (to_state == MHI_CH_STATE_TYPE_START) ?
+				      MHI_CH_STATE_ENABLED : MHI_CH_STATE_STOP;
+		write_unlock_irq(&mhi_chan->lock);
+	}
+
+	dev_dbg(dev, "Channel %s(%d) state change to %s successful\n",
+		mhi_chan->name, mhi_chan->chan, TO_CH_STATE_TYPE_STR(to_state));
+
+exit_command_failure:
 	mhi_cntrl->runtime_put(mhi_cntrl);
-	ret = mhi_send_cmd(mhi_cntrl, mhi_chan, MHI_CMD_RESET_CHAN);
-	if (ret)
-		goto error_invalid_state;
+	mhi_device_put(mhi_cntrl->mhi_dev);
 
-	/* even if it fails we will still reset */
-	ret = wait_for_completion_timeout(&mhi_chan->completion,
-				msecs_to_jiffies(mhi_cntrl->timeout_ms));
-	if (!ret || mhi_chan->ccs != MHI_EV_CC_SUCCESS)
-		dev_err(dev,
-			"Failed to receive cmd completion, still resetting\n");
+	return ret;
+
+exit_invalid_state:
+	dev_err(dev, "Channel %s(%d) update to %s not allowed\n",
+		mhi_chan->name, mhi_chan->chan, TO_CH_STATE_TYPE_STR(to_state));
+
+	return -EINVAL;
+}
+
+static void __mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
+				    struct mhi_chan *mhi_chan)
+{
+	int ret;
+	struct device *dev = &mhi_cntrl->mhi_dev->dev;
+
+	dev_dbg(dev, "Entered: unprepare channel:%d\n", mhi_chan->chan);
+
+	/* no more processing events for this channel */
+	mutex_lock(&mhi_chan->mutex);
+
+	ret = mhi_update_channel_state(mhi_cntrl, mhi_chan,
+				       MHI_CH_STATE_TYPE_RESET);
+	if (ret)
+		dev_err(dev, "Failed to reset channel, still resetting\n");
 
-error_invalid_state:
 	if (!mhi_chan->offload_ch) {
 		mhi_reset_chan(mhi_cntrl, mhi_chan);
 		mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
 	}
-	dev_dbg(dev, "chan:%d successfully resetted\n", mhi_chan->chan);
+	dev_dbg(dev, "chan:%d successfully reset\n", mhi_chan->chan);
+
 	mutex_unlock(&mhi_chan->mutex);
 }
 
@@ -1291,14 +1355,6 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
 
 	mutex_lock(&mhi_chan->mutex);
 
-	/* If channel is not in disable state, do not allow it to start */
-	if (mhi_chan->ch_state != MHI_CH_STATE_DISABLED) {
-		ret = -EIO;
-		dev_dbg(dev, "channel: %d is not in disabled state\n",
-			mhi_chan->chan);
-		goto error_init_chan;
-	}
-
 	/* Check of client manages channel context for offload channels */
 	if (!mhi_chan->offload_ch) {
 		ret = mhi_init_chan_ctxt(mhi_cntrl, mhi_chan);
@@ -1306,34 +1362,11 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
 			goto error_init_chan;
 	}
 
-	reinit_completion(&mhi_chan->completion);
-	read_lock_bh(&mhi_cntrl->pm_lock);
-	if (MHI_PM_IN_ERROR_STATE(mhi_cntrl->pm_state)) {
-		read_unlock_bh(&mhi_cntrl->pm_lock);
-		ret = -EIO;
-		goto error_pm_state;
-	}
-
-	mhi_cntrl->wake_toggle(mhi_cntrl);
-	read_unlock_bh(&mhi_cntrl->pm_lock);
-	mhi_cntrl->runtime_get(mhi_cntrl);
-	mhi_cntrl->runtime_put(mhi_cntrl);
-
-	ret = mhi_send_cmd(mhi_cntrl, mhi_chan, MHI_CMD_START_CHAN);
+	ret = mhi_update_channel_state(mhi_cntrl, mhi_chan,
+				       MHI_CH_STATE_TYPE_START);
 	if (ret)
 		goto error_pm_state;
 
-	ret = wait_for_completion_timeout(&mhi_chan->completion,
-				msecs_to_jiffies(mhi_cntrl->timeout_ms));
-	if (!ret || mhi_chan->ccs != MHI_EV_CC_SUCCESS) {
-		ret = -EIO;
-		goto error_pm_state;
-	}
-
-	write_lock_irq(&mhi_chan->lock);
-	mhi_chan->ch_state = MHI_CH_STATE_ENABLED;
-	write_unlock_irq(&mhi_chan->lock);
-
 	/* Pre-allocate buffer for xfer ring */
 	if (mhi_chan->pre_alloc) {
 		int nr_el = get_nr_avail_ring_elements(mhi_cntrl,
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 3/6] bus: mhi: core: Add support to stop or start channel data transfers

[Bhaumik Bhatt]

Some MHI client drivers may want to request a pause or halt of
data transfer activity on their channels. Support for this does
not exist and must be introduced, wherein the channel context is
not reset or cleared but only the STOP channel command is issued.
This would need to be paired with an API that allows resuming the
data transfer activity on channels by use of the START channel
command. This API assumes that the context information is already
setup. Enable this using two new APIs, mhi_start_transfer() and
mhi_stop_transfer().

Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
---
 drivers/bus/mhi/core/main.c | 41 +++++++++++++++++++++++++++++++++++++++++
 include/linux/mhi.h         | 19 +++++++++++++++++++
 2 files changed, 60 insertions(+)

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 1226933..1a969f4 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1560,6 +1560,47 @@ void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev)
 }
 EXPORT_SYMBOL_GPL(mhi_unprepare_from_transfer);
 
+static int mhi_update_transfer_state(struct mhi_device *mhi_dev,
+				     enum mhi_ch_state_type to_state)
+{
+	struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
+	struct mhi_chan *mhi_chan;
+	int dir, ret;
+
+	for (dir = 0; dir < 2; dir++) {
+		mhi_chan = dir ? mhi_dev->ul_chan : mhi_dev->dl_chan;
+
+		if (!mhi_chan)
+			continue;
+
+		/*
+		 * Bail out if one of the channels fail as client will reset
+		 * both upon failure
+		 */
+		mutex_lock(&mhi_chan->mutex);
+		ret = mhi_update_channel_state(mhi_cntrl, mhi_chan, to_state);
+		if (ret) {
+			mutex_unlock(&mhi_chan->mutex);
+			return ret;
+		}
+		mutex_unlock(&mhi_chan->mutex);
+	}
+
+	return 0;
+}
+
+int mhi_stop_transfer(struct mhi_device *mhi_dev)
+{
+	return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_STOP);
+}
+EXPORT_SYMBOL_GPL(mhi_stop_transfer);
+
+int mhi_start_transfer(struct mhi_device *mhi_dev)
+{
+	return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_START);
+}
+EXPORT_SYMBOL_GPL(mhi_start_transfer);
+
 int mhi_poll(struct mhi_device *mhi_dev, u32 budget)
 {
 	struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index 52b3c60..aee8494 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -702,6 +702,25 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);
 void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev);
 
 /**
+ * mhi_stop_transfer - Pauses ongoing channel activity by issuing the STOP
+ *                     channel command to both UL and DL channels. This command
+ *                     does not reset the channel context and the client drivers
+ *                     can issue mhi_start_transfer to resume activity.
+ * @mhi_dev: Device associated with the channels
+ */
+int mhi_stop_transfer(struct mhi_device *mhi_dev);
+
+/**
+ * mhi_start_transfer - Resumes channel activity by issuing the START channel
+ *                      command to both UL and DL channels. This command assumes
+ *                      the channel context is already setup and the client
+ *                      drivers can issue mhi_stop_transfer to pause activity if
+ *                      required.
+ * @mhi_dev: Device associated with the channels
+ */
+int mhi_start_transfer(struct mhi_device *mhi_dev);
+
+/**
  * mhi_poll - Poll for any available data in DL direction
  * @mhi_dev: Device associated with the channels
  * @budget: # of events to process
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 4/6] bus: mhi: core: Check execution environment for channel before issuing reset

[Bhaumik Bhatt]

A client can attempt to unprepare certain channels for transfer even
after the execution environment they are supposed to run in has changed.
In the event that happens, the device need not be notified of the reset
and the host can proceed with clean up for the channel context and
memory allocated for it on the host.

Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
---
 drivers/bus/mhi/core/main.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index 1a969f4..e8af85a 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1323,11 +1323,24 @@ static void __mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
 	/* no more processing events for this channel */
 	mutex_lock(&mhi_chan->mutex);
 
+	if (!(BIT(mhi_cntrl->ee) & mhi_chan->ee_mask)) {
+		dev_err(dev,
+			"Current EE: %s Required EE Mask: 0x%x for chan: %s\n",
+			TO_MHI_EXEC_STR(mhi_cntrl->ee), mhi_chan->ee_mask,
+			mhi_chan->name);
+		goto exit_unprepare_channel;
+	}
+
 	ret = mhi_update_channel_state(mhi_cntrl, mhi_chan,
 				       MHI_CH_STATE_TYPE_RESET);
 	if (ret)
 		dev_err(dev, "Failed to reset channel, still resetting\n");
 
+exit_unprepare_channel:
+	write_lock_irq(&mhi_chan->lock);
+	mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
+	write_unlock_irq(&mhi_chan->lock);
+
 	if (!mhi_chan->offload_ch) {
 		mhi_reset_chan(mhi_cntrl, mhi_chan);
 		mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 5/6] bus: mhi: core: Remove __ prefix for MHI channel unprepare function

[Bhaumik Bhatt]

The __mhi_unprepare_channel() API does not require the __ prefix.
Get rid of it and make the internal function consistent with the
other function names.

Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
---
 drivers/bus/mhi/core/main.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
index e8af85a..19156d4 100644
--- a/drivers/bus/mhi/core/main.c
+++ b/drivers/bus/mhi/core/main.c
@@ -1312,8 +1312,8 @@ static int mhi_update_channel_state(struct mhi_controller *mhi_cntrl,
 	return -EINVAL;
 }
 
-static void __mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
-				    struct mhi_chan *mhi_chan)
+static void mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
+				  struct mhi_chan *mhi_chan)
 {
 	int ret;
 	struct device *dev = &mhi_cntrl->mhi_dev->dev;
@@ -1433,7 +1433,7 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
 
 error_pre_alloc:
 	mutex_unlock(&mhi_chan->mutex);
-	__mhi_unprepare_channel(mhi_cntrl, mhi_chan);
+	mhi_unprepare_channel(mhi_cntrl, mhi_chan);
 
 	return ret;
 }
@@ -1550,7 +1550,7 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev)
 		if (!mhi_chan)
 			continue;
 
-		__mhi_unprepare_channel(mhi_cntrl, mhi_chan);
+		mhi_unprepare_channel(mhi_cntrl, mhi_chan);
 	}
 
 	return ret;
@@ -1568,7 +1568,7 @@ void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev)
 		if (!mhi_chan)
 			continue;
 
-		__mhi_unprepare_channel(mhi_cntrl, mhi_chan);
+		mhi_unprepare_channel(mhi_cntrl, mhi_chan);
 	}
 }
 EXPORT_SYMBOL_GPL(mhi_unprepare_from_transfer);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH v2 6/6] bus: mhi: Improve documentation on channel transfer setup APIs

[Bhaumik Bhatt]

The mhi_prepare_for_transfer() and mhi_unprepare_from_transfer()
APIs could use better explanation, especially with the addition
of two new APIs to start and stop the transfers on channels. Add
better set of information for those APIs to avoid confusion going
forward.

Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
---
 include/linux/mhi.h | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/include/linux/mhi.h b/include/linux/mhi.h
index aee8494..ee9537f 100644
--- a/include/linux/mhi.h
+++ b/include/linux/mhi.h
@@ -690,13 +690,27 @@ int mhi_device_get_sync(struct mhi_device *mhi_dev);
 void mhi_device_put(struct mhi_device *mhi_dev);
 
 /**
- * mhi_prepare_for_transfer - Setup channel for data transfer
+ * mhi_prepare_for_transfer - Setup UL and DL channels for data transfer.
+ *                            Allocate and initialize the channel context and
+ *                            also issue the START channel command to both
+ *                            channels. Channels can be started only if both
+ *                            host and device execution environments match and
+ *                            channels are in a DISABLED state.
  * @mhi_dev: Device associated with the channels
  */
 int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);
 
 /**
- * mhi_unprepare_from_transfer - Unprepare the channels
+ * mhi_unprepare_from_transfer - Reset UL and DL channels for data transfer.
+ *                               Issue the RESET channel command and let the
+ *                               device clean-up the context so no incoming
+ *                               transfers are seen on the host. Free memory
+ *                               associated with the context on host. If device
+ *                               is unresponsive, only perform a host side
+ *                               clean-up. Channels can be reset only if both
+ *                               host and device execution environments match
+ *                               and channels are in an ENABLED, STOPPED or
+ *                               SUSPENDED state.
  * @mhi_dev: Device associated with the channels
  */
 void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH v2 1/6] bus: mhi: core: Allow receiving a STOP channel command response

[Manivannan Sadhasivam]

On Wed, Nov 11, 2020 at 11:21:08AM -0800, Bhaumik Bhatt wrote:
> Add support to receive the response to a STOP channel command to the
> MHI bus. If a client would like to STOP a channel instead of issuing
> a RESET to it, this would provide support for it.
> 
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> ---
>  drivers/bus/mhi/core/init.c | 5 +++--
>  drivers/bus/mhi/core/main.c | 5 +++++
>  2 files changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index 8cefa35..4d34d62 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev)
>  
>  		mutex_lock(&mhi_chan->mutex);
>  
> -		if (ch_state[dir] == MHI_CH_STATE_ENABLED &&
> -		    !mhi_chan->offload_ch)
> +		if ((ch_state[dir] == MHI_CH_STATE_ENABLED ||
> +		     ch_state[dir] == MHI_CH_STATE_STOP) &&

This enum is not defined in this patch so it'll break. Please add a separate
patch which introduces the new state enums alone and then have patches 1/2
as a followup.

Also this change is not belonging to this commit I believe.

Thanks,
Mani

> +		     !mhi_chan->offload_ch)
>  			mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
>  
>  		mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index f953e2a..ad881a1 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl,
>  		cmd_tre->dword[0] = MHI_TRE_CMD_RESET_DWORD0;
>  		cmd_tre->dword[1] = MHI_TRE_CMD_RESET_DWORD1(chan);
>  		break;
> +	case MHI_CMD_STOP_CHAN:
> +		cmd_tre->ptr = MHI_TRE_CMD_STOP_PTR;
> +		cmd_tre->dword[0] = MHI_TRE_CMD_STOP_DWORD0;
> +		cmd_tre->dword[1] = MHI_TRE_CMD_STOP_DWORD1(chan);
> +		break;
>  	case MHI_CMD_START_CHAN:
>  		cmd_tre->ptr = MHI_TRE_CMD_START_PTR;
>  		cmd_tre->dword[0] = MHI_TRE_CMD_START_DWORD0;
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH v2 2/6] bus: mhi: core: Improvements to the channel handling state machine

[Manivannan Sadhasivam]

On Wed, Nov 11, 2020 at 11:21:09AM -0800, Bhaumik Bhatt wrote:
> Add support to enable sending the stop channel command and
> improve the channel handling state machine such that all commands
> go through a common function. This can help ensure that the state
> machine is not violated in any way and adheres to the MHI
> specification.
> 
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> ---
>  drivers/bus/mhi/core/init.c     |   6 ++
>  drivers/bus/mhi/core/internal.h |  12 +++
>  drivers/bus/mhi/core/main.c     | 163 ++++++++++++++++++++++++----------------
>  3 files changed, 116 insertions(+), 65 deletions(-)
> 
> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> index 4d34d62..c9b1de8 100644
> --- a/drivers/bus/mhi/core/init.c
> +++ b/drivers/bus/mhi/core/init.c
> @@ -51,6 +51,12 @@ const char * const mhi_state_str[MHI_STATE_MAX] = {
>  	[MHI_STATE_SYS_ERR] = "SYS_ERR",
>  };
>  
> +const char * const mhi_ch_state_type_str[MHI_CH_STATE_TYPE_MAX] = {
> +	[MHI_CH_STATE_TYPE_RESET] = "RESET",
> +	[MHI_CH_STATE_TYPE_STOP] = "STOP",
> +	[MHI_CH_STATE_TYPE_START] = "START",
> +};
> +
>  static const char * const mhi_pm_state_str[] = {
>  	[MHI_PM_STATE_DISABLE] = "DISABLE",
>  	[MHI_PM_STATE_POR] = "POR",
> diff --git a/drivers/bus/mhi/core/internal.h b/drivers/bus/mhi/core/internal.h
> index 2df8de5..f4efb15 100644
> --- a/drivers/bus/mhi/core/internal.h
> +++ b/drivers/bus/mhi/core/internal.h
> @@ -369,6 +369,18 @@ enum mhi_ch_state {
>  	MHI_CH_STATE_ERROR = 0x5,
>  };
>  
> +enum mhi_ch_state_type {
> +	MHI_CH_STATE_TYPE_RESET,
> +	MHI_CH_STATE_TYPE_STOP,
> +	MHI_CH_STATE_TYPE_START,
> +	MHI_CH_STATE_TYPE_MAX,
> +};
> +

As said in previous patch, this needs to be moved to a separate one.

> +extern const char * const mhi_ch_state_type_str[MHI_CH_STATE_TYPE_MAX];
> +#define TO_CH_STATE_TYPE_STR(state) (((state) >= MHI_CH_STATE_TYPE_MAX) ? \
> +				     "INVALID_STATE" : \
> +				     mhi_ch_state_type_str[state])
> +
>  #define MHI_INVALID_BRSTMODE(mode) (mode != MHI_DB_BRST_DISABLE && \
>  				    mode != MHI_DB_BRST_ENABLE)
>  
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index ad881a1..1226933 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -1220,56 +1220,120 @@ int mhi_send_cmd(struct mhi_controller *mhi_cntrl,
>  	return 0;
>  }
>  

[...]

> +static void __mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
> +				    struct mhi_chan *mhi_chan)
> +{
> +	int ret;
> +	struct device *dev = &mhi_cntrl->mhi_dev->dev;
> +
> +	dev_dbg(dev, "Entered: unprepare channel:%d\n", mhi_chan->chan);

Please get rid of these debug prints. We have some of them right now but they
should be removed at some point. For debugging, use ftrace.

Thanks,
Mani

Re: [PATCH v2 3/6] bus: mhi: core: Add support to stop or start channel data transfers

[Manivannan Sadhasivam]

On Wed, Nov 11, 2020 at 11:21:10AM -0800, Bhaumik Bhatt wrote:
> Some MHI client drivers may want to request a pause or halt of
> data transfer activity on their channels. Support for this does
> not exist and must be introduced, wherein the channel context is
> not reset or cleared but only the STOP channel command is issued.
> This would need to be paired with an API that allows resuming the
> data transfer activity on channels by use of the START channel
> command. This API assumes that the context information is already
> setup. Enable this using two new APIs, mhi_start_transfer() and
> mhi_stop_transfer().
> 
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> ---
>  drivers/bus/mhi/core/main.c | 41 +++++++++++++++++++++++++++++++++++++++++
>  include/linux/mhi.h         | 19 +++++++++++++++++++
>  2 files changed, 60 insertions(+)
> 
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index 1226933..1a969f4 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -1560,6 +1560,47 @@ void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev)
>  }
>  EXPORT_SYMBOL_GPL(mhi_unprepare_from_transfer);
>  
> +static int mhi_update_transfer_state(struct mhi_device *mhi_dev,
> +				     enum mhi_ch_state_type to_state)
> +{
> +	struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
> +	struct mhi_chan *mhi_chan;
> +	int dir, ret;
> +
> +	for (dir = 0; dir < 2; dir++) {
> +		mhi_chan = dir ? mhi_dev->ul_chan : mhi_dev->dl_chan;
> +
> +		if (!mhi_chan)
> +			continue;
> +
> +		/*
> +		 * Bail out if one of the channels fail as client will reset
> +		 * both upon failure
> +		 */
> +		mutex_lock(&mhi_chan->mutex);

Hmm. The documentation about wait_for_completion*() used in
mhi_update_channel_state()says below,

"As all variants of wait_for_completion() can (obviously) block for a long
time depending on the nature of the activity they are waiting for, so in
most cases you probably don't want to call this with held mutexes."

> +		ret = mhi_update_channel_state(mhi_cntrl, mhi_chan, to_state);
> +		if (ret) {
> +			mutex_unlock(&mhi_chan->mutex);
> +			return ret;
> +		}
> +		mutex_unlock(&mhi_chan->mutex);
> +	}
> +
> +	return 0;
> +}
> +
> +int mhi_stop_transfer(struct mhi_device *mhi_dev)
> +{
> +	return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_STOP);
> +}
> +EXPORT_SYMBOL_GPL(mhi_stop_transfer);
> +
> +int mhi_start_transfer(struct mhi_device *mhi_dev)
> +{
> +	return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_START);
> +}
> +EXPORT_SYMBOL_GPL(mhi_start_transfer);
> +
>  int mhi_poll(struct mhi_device *mhi_dev, u32 budget)
>  {
>  	struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
> diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> index 52b3c60..aee8494 100644
> --- a/include/linux/mhi.h
> +++ b/include/linux/mhi.h
> @@ -702,6 +702,25 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);
>  void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev);
>  
>  /**
> + * mhi_stop_transfer - Pauses ongoing channel activity by issuing the STOP
> + *                     channel command to both UL and DL channels. This command
> + *                     does not reset the channel context and the client drivers
> + *                     can issue mhi_start_transfer to resume activity.
> + * @mhi_dev: Device associated with the channels
> + */
> +int mhi_stop_transfer(struct mhi_device *mhi_dev);
> +
> +/**
> + * mhi_start_transfer - Resumes channel activity by issuing the START channel
> + *                      command to both UL and DL channels. This command assumes
> + *                      the channel context is already setup and the client
> + *                      drivers can issue mhi_stop_transfer to pause activity if
> + *                      required.
> + * @mhi_dev: Device associated with the channels
> + */
> +int mhi_start_transfer(struct mhi_device *mhi_dev);
> +
> +/**

Align the comment header properly.

Thanks,
Mani

>   * mhi_poll - Poll for any available data in DL direction
>   * @mhi_dev: Device associated with the channels
>   * @budget: # of events to process
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH v2 5/6] bus: mhi: core: Remove __ prefix for MHI channel unprepare function

[Manivannan Sadhasivam]

On Wed, Nov 11, 2020 at 11:21:12AM -0800, Bhaumik Bhatt wrote:
> The __mhi_unprepare_channel() API does not require the __ prefix.
> Get rid of it and make the internal function consistent with the
> other function names.
> 
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>

Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>

Thanks,
Mani

> ---
>  drivers/bus/mhi/core/main.c | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> index e8af85a..19156d4 100644
> --- a/drivers/bus/mhi/core/main.c
> +++ b/drivers/bus/mhi/core/main.c
> @@ -1312,8 +1312,8 @@ static int mhi_update_channel_state(struct mhi_controller *mhi_cntrl,
>  	return -EINVAL;
>  }
>  
> -static void __mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
> -				    struct mhi_chan *mhi_chan)
> +static void mhi_unprepare_channel(struct mhi_controller *mhi_cntrl,
> +				  struct mhi_chan *mhi_chan)
>  {
>  	int ret;
>  	struct device *dev = &mhi_cntrl->mhi_dev->dev;
> @@ -1433,7 +1433,7 @@ int mhi_prepare_channel(struct mhi_controller *mhi_cntrl,
>  
>  error_pre_alloc:
>  	mutex_unlock(&mhi_chan->mutex);
> -	__mhi_unprepare_channel(mhi_cntrl, mhi_chan);
> +	mhi_unprepare_channel(mhi_cntrl, mhi_chan);
>  
>  	return ret;
>  }
> @@ -1550,7 +1550,7 @@ int mhi_prepare_for_transfer(struct mhi_device *mhi_dev)
>  		if (!mhi_chan)
>  			continue;
>  
> -		__mhi_unprepare_channel(mhi_cntrl, mhi_chan);
> +		mhi_unprepare_channel(mhi_cntrl, mhi_chan);
>  	}
>  
>  	return ret;
> @@ -1568,7 +1568,7 @@ void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev)
>  		if (!mhi_chan)
>  			continue;
>  
> -		__mhi_unprepare_channel(mhi_cntrl, mhi_chan);
> +		mhi_unprepare_channel(mhi_cntrl, mhi_chan);
>  	}
>  }
>  EXPORT_SYMBOL_GPL(mhi_unprepare_from_transfer);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH v2 6/6] bus: mhi: Improve documentation on channel transfer setup APIs

[Manivannan Sadhasivam]

On Wed, Nov 11, 2020 at 11:21:13AM -0800, Bhaumik Bhatt wrote:
> The mhi_prepare_for_transfer() and mhi_unprepare_from_transfer()
> APIs could use better explanation, especially with the addition
> of two new APIs to start and stop the transfers on channels. Add
> better set of information for those APIs to avoid confusion going
> forward.
> 
> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> ---
>  include/linux/mhi.h | 18 ++++++++++++++++--
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> index aee8494..ee9537f 100644
> --- a/include/linux/mhi.h
> +++ b/include/linux/mhi.h
> @@ -690,13 +690,27 @@ int mhi_device_get_sync(struct mhi_device *mhi_dev);
>  void mhi_device_put(struct mhi_device *mhi_dev);
>  
>  /**
> - * mhi_prepare_for_transfer - Setup channel for data transfer
> + * mhi_prepare_for_transfer - Setup UL and DL channels for data transfer.
> + *                            Allocate and initialize the channel context and
> + *                            also issue the START channel command to both
> + *                            channels. Channels can be started only if both
> + *                            host and device execution environments match and
> + *                            channels are in a DISABLED state.

It'd be good if you can add a note about how this API differs from
mhi_start_transfer() API. The content says the difference but an explicit
comparision would be good.

Thanks,
Mani

>   * @mhi_dev: Device associated with the channels
>   */
>  int mhi_prepare_for_transfer(struct mhi_device *mhi_dev);
>  
>  /**
> - * mhi_unprepare_from_transfer - Unprepare the channels
> + * mhi_unprepare_from_transfer - Reset UL and DL channels for data transfer.
> + *                               Issue the RESET channel command and let the
> + *                               device clean-up the context so no incoming
> + *                               transfers are seen on the host. Free memory
> + *                               associated with the context on host. If device
> + *                               is unresponsive, only perform a host side
> + *                               clean-up. Channels can be reset only if both
> + *                               host and device execution environments match
> + *                               and channels are in an ENABLED, STOPPED or
> + *                               SUSPENDED state.
>   * @mhi_dev: Device associated with the channels
>   */
>  void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev);
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project
> 

Re: [PATCH v2 1/6] bus: mhi: core: Allow receiving a STOP channel command response

[Bhaumik Bhatt]

Hi Mani,

On 2020-11-15 23:13, Manivannan Sadhasivam wrote:
> On Wed, Nov 11, 2020 at 11:21:08AM -0800, Bhaumik Bhatt wrote:
>> Add support to receive the response to a STOP channel command to the
>> MHI bus. If a client would like to STOP a channel instead of issuing
>> a RESET to it, this would provide support for it.
>> 
>> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
>> ---
>>  drivers/bus/mhi/core/init.c | 5 +++--
>>  drivers/bus/mhi/core/main.c | 5 +++++
>>  2 files changed, 8 insertions(+), 2 deletions(-)
>> 
>> diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
>> index 8cefa35..4d34d62 100644
>> --- a/drivers/bus/mhi/core/init.c
>> +++ b/drivers/bus/mhi/core/init.c
>> @@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev)
>> 
>>  		mutex_lock(&mhi_chan->mutex);
>> 
>> -		if (ch_state[dir] == MHI_CH_STATE_ENABLED &&
>> -		    !mhi_chan->offload_ch)
>> +		if ((ch_state[dir] == MHI_CH_STATE_ENABLED ||
>> +		     ch_state[dir] == MHI_CH_STATE_STOP) &&
> 
> This enum is not defined in this patch so it'll break. Please add a 
> separate
> patch which introduces the new state enums alone and then have patches 
> 1/2
> as a followup.
> 
It is actually already defined and present in internal.h as enum 
mhi_ch_state.

The old set of enums has MHI_CH_STATE_STOP from enum mhi_ch_state and 
the new
enum I introduced is MHI_CH_STATE_TYPE_STOP from enum enum 
mhi_ch_state_type.

If it seems confusing, suggestions to renaming them are welcome.

> Also this change is not belonging to this commit I believe.
> 
I included this change here because, a channel can be in "stopped" state 
and
a user module could be unloaded or a crash could force a driver remove 
leading
us to come this check.

If you think I should move it as a separate patch, let me know.
> Thanks,
> Mani
> 
>> +		     !mhi_chan->offload_ch)
>>  			mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
>> 
>>  		mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
>> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
>> index f953e2a..ad881a1 100644
>> --- a/drivers/bus/mhi/core/main.c
>> +++ b/drivers/bus/mhi/core/main.c
>> @@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller 
>> *mhi_cntrl,
>>  		cmd_tre->dword[0] = MHI_TRE_CMD_RESET_DWORD0;
>>  		cmd_tre->dword[1] = MHI_TRE_CMD_RESET_DWORD1(chan);
>>  		break;
>> +	case MHI_CMD_STOP_CHAN:
>> +		cmd_tre->ptr = MHI_TRE_CMD_STOP_PTR;
>> +		cmd_tre->dword[0] = MHI_TRE_CMD_STOP_DWORD0;
>> +		cmd_tre->dword[1] = MHI_TRE_CMD_STOP_DWORD1(chan);
>> +		break;
>>  	case MHI_CMD_START_CHAN:
>>  		cmd_tre->ptr = MHI_TRE_CMD_START_PTR;
>>  		cmd_tre->dword[0] = MHI_TRE_CMD_START_DWORD0;
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project
>> 

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

Re: [PATCH v2 3/6] bus: mhi: core: Add support to stop or start channel data transfers

[Bhaumik Bhatt]

Hi Mani,

On 2020-11-16 04:43, Manivannan Sadhasivam wrote:
> On Wed, Nov 11, 2020 at 11:21:10AM -0800, Bhaumik Bhatt wrote:
>> Some MHI client drivers may want to request a pause or halt of
>> data transfer activity on their channels. Support for this does
>> not exist and must be introduced, wherein the channel context is
>> not reset or cleared but only the STOP channel command is issued.
>> This would need to be paired with an API that allows resuming the
>> data transfer activity on channels by use of the START channel
>> command. This API assumes that the context information is already
>> setup. Enable this using two new APIs, mhi_start_transfer() and
>> mhi_stop_transfer().
>> 
>> Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
>> ---
>>  drivers/bus/mhi/core/main.c | 41 
>> +++++++++++++++++++++++++++++++++++++++++
>>  include/linux/mhi.h         | 19 +++++++++++++++++++
>>  2 files changed, 60 insertions(+)
>> 
>> diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
>> index 1226933..1a969f4 100644
>> --- a/drivers/bus/mhi/core/main.c
>> +++ b/drivers/bus/mhi/core/main.c
>> @@ -1560,6 +1560,47 @@ void mhi_unprepare_from_transfer(struct 
>> mhi_device *mhi_dev)
>>  }
>>  EXPORT_SYMBOL_GPL(mhi_unprepare_from_transfer);
>> 
>> +static int mhi_update_transfer_state(struct mhi_device *mhi_dev,
>> +				     enum mhi_ch_state_type to_state)
>> +{
>> +	struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
>> +	struct mhi_chan *mhi_chan;
>> +	int dir, ret;
>> +
>> +	for (dir = 0; dir < 2; dir++) {
>> +		mhi_chan = dir ? mhi_dev->ul_chan : mhi_dev->dl_chan;
>> +
>> +		if (!mhi_chan)
>> +			continue;
>> +
>> +		/*
>> +		 * Bail out if one of the channels fail as client will reset
>> +		 * both upon failure
>> +		 */
>> +		mutex_lock(&mhi_chan->mutex);
> 
> Hmm. The documentation about wait_for_completion*() used in
> mhi_update_channel_state()says below,
> 
> "As all variants of wait_for_completion() can (obviously) block for a 
> long
> time depending on the nature of the activity they are waiting for, so 
> in
> most cases you probably don't want to call this with held mutexes."
> 
Yes, that is understood. The mhi_chan->mutex is only used to lock any 
channel
enable/start/stop/disable type operations, since these have to be in 
order, it
is essential that we wait for one of the operations to finish before the 
next
one.

Also we avoid a race, for example, at a time when a device crash forces 
a driver
"remove" call, while an operation to start/stop a channel is already 
going on.
>> +		ret = mhi_update_channel_state(mhi_cntrl, mhi_chan, to_state);
>> +		if (ret) {
>> +			mutex_unlock(&mhi_chan->mutex);
>> +			return ret;
>> +		}
>> +		mutex_unlock(&mhi_chan->mutex);
>> +	}
>> +
>> +	return 0;
>> +}
>> +
>> +int mhi_stop_transfer(struct mhi_device *mhi_dev)
>> +{
>> +	return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_STOP);
>> +}
>> +EXPORT_SYMBOL_GPL(mhi_stop_transfer);
>> +
>> +int mhi_start_transfer(struct mhi_device *mhi_dev)
>> +{
>> +	return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_START);
>> +}
>> +EXPORT_SYMBOL_GPL(mhi_start_transfer);
>> +
>>  int mhi_poll(struct mhi_device *mhi_dev, u32 budget)
>>  {
>>  	struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
>> diff --git a/include/linux/mhi.h b/include/linux/mhi.h
>> index 52b3c60..aee8494 100644
>> --- a/include/linux/mhi.h
>> +++ b/include/linux/mhi.h
>> @@ -702,6 +702,25 @@ int mhi_prepare_for_transfer(struct mhi_device 
>> *mhi_dev);
>>  void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev);
>> 
>>  /**
>> + * mhi_stop_transfer - Pauses ongoing channel activity by issuing the 
>> STOP
>> + *                     channel command to both UL and DL channels. 
>> This command
>> + *                     does not reset the channel context and the 
>> client drivers
>> + *                     can issue mhi_start_transfer to resume 
>> activity.
>> + * @mhi_dev: Device associated with the channels
>> + */
>> +int mhi_stop_transfer(struct mhi_device *mhi_dev);
>> +
>> +/**
>> + * mhi_start_transfer - Resumes channel activity by issuing the START 
>> channel
>> + *                      command to both UL and DL channels. This 
>> command assumes
>> + *                      the channel context is already setup and the 
>> client
>> + *                      drivers can issue mhi_stop_transfer to pause 
>> activity if
>> + *                      required.
>> + * @mhi_dev: Device associated with the channels
>> + */
>> +int mhi_start_transfer(struct mhi_device *mhi_dev);
>> +
>> +/**
> 
> Align the comment header properly.
> 
So I am trying to follow the documentation style for other functions in 
the same
file. Is there any particular format you want me to refer to?

I use all spaces for the lines after the first one to align them just 
like the
rest of them.

> Thanks,
> Mani
> 
>>   * mhi_poll - Poll for any available data in DL direction
>>   * @mhi_dev: Device associated with the channels
>>   * @budget: # of events to process
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project
>> 

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

Re: [PATCH v2 3/6] bus: mhi: core: Add support to stop or start channel data transfers

[Manivannan Sadhasivam]

On Mon, Nov 16, 2020 at 12:56:16PM -0800, Bhaumik Bhatt wrote:
> Hi Mani,
> 
> On 2020-11-16 04:43, Manivannan Sadhasivam wrote:
> > On Wed, Nov 11, 2020 at 11:21:10AM -0800, Bhaumik Bhatt wrote:
> > > Some MHI client drivers may want to request a pause or halt of
> > > data transfer activity on their channels. Support for this does
> > > not exist and must be introduced, wherein the channel context is
> > > not reset or cleared but only the STOP channel command is issued.
> > > This would need to be paired with an API that allows resuming the
> > > data transfer activity on channels by use of the START channel
> > > command. This API assumes that the context information is already
> > > setup. Enable this using two new APIs, mhi_start_transfer() and
> > > mhi_stop_transfer().
> > > 
> > > Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> > > ---
> > >  drivers/bus/mhi/core/main.c | 41
> > > +++++++++++++++++++++++++++++++++++++++++
> > >  include/linux/mhi.h         | 19 +++++++++++++++++++
> > >  2 files changed, 60 insertions(+)
> > > 
> > > diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> > > index 1226933..1a969f4 100644
> > > --- a/drivers/bus/mhi/core/main.c
> > > +++ b/drivers/bus/mhi/core/main.c
> > > @@ -1560,6 +1560,47 @@ void mhi_unprepare_from_transfer(struct
> > > mhi_device *mhi_dev)
> > >  }
> > >  EXPORT_SYMBOL_GPL(mhi_unprepare_from_transfer);
> > > 
> > > +static int mhi_update_transfer_state(struct mhi_device *mhi_dev,
> > > +				     enum mhi_ch_state_type to_state)
> > > +{
> > > +	struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
> > > +	struct mhi_chan *mhi_chan;
> > > +	int dir, ret;
> > > +
> > > +	for (dir = 0; dir < 2; dir++) {
> > > +		mhi_chan = dir ? mhi_dev->ul_chan : mhi_dev->dl_chan;
> > > +
> > > +		if (!mhi_chan)
> > > +			continue;
> > > +
> > > +		/*
> > > +		 * Bail out if one of the channels fail as client will reset
> > > +		 * both upon failure
> > > +		 */
> > > +		mutex_lock(&mhi_chan->mutex);
> > 
> > Hmm. The documentation about wait_for_completion*() used in
> > mhi_update_channel_state()says below,
> > 
> > "As all variants of wait_for_completion() can (obviously) block for a
> > long
> > time depending on the nature of the activity they are waiting for, so in
> > most cases you probably don't want to call this with held mutexes."
> > 
> Yes, that is understood. The mhi_chan->mutex is only used to lock any
> channel
> enable/start/stop/disable type operations, since these have to be in order,
> it
> is essential that we wait for one of the operations to finish before the
> next
> one.
> 
> Also we avoid a race, for example, at a time when a device crash forces a
> driver
> "remove" call, while an operation to start/stop a channel is already going
> on.

Can't you just drop the lock before calling wait_for_completion() and
acquire later? You should add a comment for that also!

> > > +		ret = mhi_update_channel_state(mhi_cntrl, mhi_chan, to_state);
> > > +		if (ret) {
> > > +			mutex_unlock(&mhi_chan->mutex);
> > > +			return ret;
> > > +		}
> > > +		mutex_unlock(&mhi_chan->mutex);
> > > +	}
> > > +
> > > +	return 0;
> > > +}
> > > +
> > > +int mhi_stop_transfer(struct mhi_device *mhi_dev)
> > > +{
> > > +	return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_STOP);
> > > +}
> > > +EXPORT_SYMBOL_GPL(mhi_stop_transfer);
> > > +
> > > +int mhi_start_transfer(struct mhi_device *mhi_dev)
> > > +{
> > > +	return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_START);
> > > +}
> > > +EXPORT_SYMBOL_GPL(mhi_start_transfer);
> > > +
> > >  int mhi_poll(struct mhi_device *mhi_dev, u32 budget)
> > >  {
> > >  	struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
> > > diff --git a/include/linux/mhi.h b/include/linux/mhi.h
> > > index 52b3c60..aee8494 100644
> > > --- a/include/linux/mhi.h
> > > +++ b/include/linux/mhi.h
> > > @@ -702,6 +702,25 @@ int mhi_prepare_for_transfer(struct mhi_device
> > > *mhi_dev);
> > >  void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev);
> > > 
> > >  /**
> > > + * mhi_stop_transfer - Pauses ongoing channel activity by issuing
> > > the STOP
> > > + *                     channel command to both UL and DL channels.
> > > This command
> > > + *                     does not reset the channel context and the
> > > client drivers
> > > + *                     can issue mhi_start_transfer to resume
> > > activity.
> > > + * @mhi_dev: Device associated with the channels
> > > + */
> > > +int mhi_stop_transfer(struct mhi_device *mhi_dev);
> > > +
> > > +/**
> > > + * mhi_start_transfer - Resumes channel activity by issuing the
> > > START channel
> > > + *                      command to both UL and DL channels. This
> > > command assumes
> > > + *                      the channel context is already setup and
> > > the client
> > > + *                      drivers can issue mhi_stop_transfer to
> > > pause activity if
> > > + *                      required.
> > > + * @mhi_dev: Device associated with the channels
> > > + */
> > > +int mhi_start_transfer(struct mhi_device *mhi_dev);
> > > +
> > > +/**
> > 
> > Align the comment header properly.
> > 
> So I am trying to follow the documentation style for other functions in the
> same
> file. Is there any particular format you want me to refer to?
> 
> I use all spaces for the lines after the first one to align them just like
> the
> rest of them.
> 

The diff shows me of below style:

/**
+ *
+ *
...
+ /**

I just asked to fix this.

Thanks,
Mani

> > Thanks,
> > Mani
> > 
> > >   * mhi_poll - Poll for any available data in DL direction
> > >   * @mhi_dev: Device associated with the channels
> > >   * @budget: # of events to process
> > > --
> > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> > > Forum,
> > > a Linux Foundation Collaborative Project
> > > 
> 
> Thanks,
> Bhaumik
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [PATCH v2 1/6] bus: mhi: core: Allow receiving a STOP channel command response

[Manivannan Sadhasivam]

On Mon, Nov 16, 2020 at 09:36:09AM -0800, Bhaumik Bhatt wrote:
> Hi Mani,
> 
> On 2020-11-15 23:13, Manivannan Sadhasivam wrote:
> > On Wed, Nov 11, 2020 at 11:21:08AM -0800, Bhaumik Bhatt wrote:
> > > Add support to receive the response to a STOP channel command to the
> > > MHI bus. If a client would like to STOP a channel instead of issuing
> > > a RESET to it, this would provide support for it.
> > > 
> > > Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
> > > ---
> > >  drivers/bus/mhi/core/init.c | 5 +++--
> > >  drivers/bus/mhi/core/main.c | 5 +++++
> > >  2 files changed, 8 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
> > > index 8cefa35..4d34d62 100644
> > > --- a/drivers/bus/mhi/core/init.c
> > > +++ b/drivers/bus/mhi/core/init.c
> > > @@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev)
> > > 
> > >  		mutex_lock(&mhi_chan->mutex);
> > > 
> > > -		if (ch_state[dir] == MHI_CH_STATE_ENABLED &&
> > > -		    !mhi_chan->offload_ch)
> > > +		if ((ch_state[dir] == MHI_CH_STATE_ENABLED ||
> > > +		     ch_state[dir] == MHI_CH_STATE_STOP) &&
> > 
> > This enum is not defined in this patch so it'll break. Please add a
> > separate
> > patch which introduces the new state enums alone and then have patches
> > 1/2
> > as a followup.
> > 
> It is actually already defined and present in internal.h as enum
> mhi_ch_state.
> 
> The old set of enums has MHI_CH_STATE_STOP from enum mhi_ch_state and the
> new
> enum I introduced is MHI_CH_STATE_TYPE_STOP from enum enum
> mhi_ch_state_type.
> 
> If it seems confusing, suggestions to renaming them are welcome.
> 

Ah, sorry. I got confused with MHI_CH_STATE_TYPE_STOP and MHI_CH_STATE_STOP.
Ignore my previous comment.

Thanks,
Mani

> > Also this change is not belonging to this commit I believe.
> > 
> I included this change here because, a channel can be in "stopped" state and
> a user module could be unloaded or a crash could force a driver remove
> leading
> us to come this check.
> 
> If you think I should move it as a separate patch, let me know.
> > Thanks,
> > Mani
> > 
> > > +		     !mhi_chan->offload_ch)
> > >  			mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
> > > 
> > >  		mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
> > > diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
> > > index f953e2a..ad881a1 100644
> > > --- a/drivers/bus/mhi/core/main.c
> > > +++ b/drivers/bus/mhi/core/main.c
> > > @@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller
> > > *mhi_cntrl,
> > >  		cmd_tre->dword[0] = MHI_TRE_CMD_RESET_DWORD0;
> > >  		cmd_tre->dword[1] = MHI_TRE_CMD_RESET_DWORD1(chan);
> > >  		break;
> > > +	case MHI_CMD_STOP_CHAN:
> > > +		cmd_tre->ptr = MHI_TRE_CMD_STOP_PTR;
> > > +		cmd_tre->dword[0] = MHI_TRE_CMD_STOP_DWORD0;
> > > +		cmd_tre->dword[1] = MHI_TRE_CMD_STOP_DWORD1(chan);
> > > +		break;
> > >  	case MHI_CMD_START_CHAN:
> > >  		cmd_tre->ptr = MHI_TRE_CMD_START_PTR;
> > >  		cmd_tre->dword[0] = MHI_TRE_CMD_START_DWORD0;
> > > --
> > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
> > > Forum,
> > > a Linux Foundation Collaborative Project
> > > 
> 
> Thanks,
> Bhaumik
> -- 
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Project

Re: [PATCH v2 1/6] bus: mhi: core: Allow receiving a STOP channel command response

[Bhaumik Bhatt]

On 2020-11-21 09:16 AM, Manivannan Sadhasivam wrote:
> On Mon, Nov 16, 2020 at 09:36:09AM -0800, Bhaumik Bhatt wrote:
>> Hi Mani,
>> 
>> On 2020-11-15 23:13, Manivannan Sadhasivam wrote:
>> > On Wed, Nov 11, 2020 at 11:21:08AM -0800, Bhaumik Bhatt wrote:
>> > > Add support to receive the response to a STOP channel command to the
>> > > MHI bus. If a client would like to STOP a channel instead of issuing
>> > > a RESET to it, this would provide support for it.
>> > >
>> > > Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
>> > > ---
>> > >  drivers/bus/mhi/core/init.c | 5 +++--
>> > >  drivers/bus/mhi/core/main.c | 5 +++++
>> > >  2 files changed, 8 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/drivers/bus/mhi/core/init.c b/drivers/bus/mhi/core/init.c
>> > > index 8cefa35..4d34d62 100644
>> > > --- a/drivers/bus/mhi/core/init.c
>> > > +++ b/drivers/bus/mhi/core/init.c
>> > > @@ -1267,8 +1267,9 @@ static int mhi_driver_remove(struct device *dev)
>> > >
>> > >  		mutex_lock(&mhi_chan->mutex);
>> > >
>> > > -		if (ch_state[dir] == MHI_CH_STATE_ENABLED &&
>> > > -		    !mhi_chan->offload_ch)
>> > > +		if ((ch_state[dir] == MHI_CH_STATE_ENABLED ||
>> > > +		     ch_state[dir] == MHI_CH_STATE_STOP) &&
>> >
>> > This enum is not defined in this patch so it'll break. Please add a
>> > separate
>> > patch which introduces the new state enums alone and then have patches
>> > 1/2
>> > as a followup.
>> >
>> It is actually already defined and present in internal.h as enum
>> mhi_ch_state.
>> 
>> The old set of enums has MHI_CH_STATE_STOP from enum mhi_ch_state and 
>> the
>> new
>> enum I introduced is MHI_CH_STATE_TYPE_STOP from enum enum
>> mhi_ch_state_type.
>> 
>> If it seems confusing, suggestions to renaming them are welcome.
>> 
> 
> Ah, sorry. I got confused with MHI_CH_STATE_TYPE_STOP and 
> MHI_CH_STATE_STOP.
> Ignore my previous comment.
> 
> Thanks,
> Mani
> 
No problem.
>> > Also this change is not belonging to this commit I believe.
>> >
>> I included this change here because, a channel can be in "stopped" 
>> state and
>> a user module could be unloaded or a crash could force a driver remove
>> leading
>> us to come this check.
>> 
>> If you think I should move it as a separate patch, let me know.
>> > Thanks,
>> > Mani
>> >
>> > > +		     !mhi_chan->offload_ch)
>> > >  			mhi_deinit_chan_ctxt(mhi_cntrl, mhi_chan);
>> > >
>> > >  		mhi_chan->ch_state = MHI_CH_STATE_DISABLED;
>> > > diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
>> > > index f953e2a..ad881a1 100644
>> > > --- a/drivers/bus/mhi/core/main.c
>> > > +++ b/drivers/bus/mhi/core/main.c
>> > > @@ -1194,6 +1194,11 @@ int mhi_send_cmd(struct mhi_controller
>> > > *mhi_cntrl,
>> > >  		cmd_tre->dword[0] = MHI_TRE_CMD_RESET_DWORD0;
>> > >  		cmd_tre->dword[1] = MHI_TRE_CMD_RESET_DWORD1(chan);
>> > >  		break;
>> > > +	case MHI_CMD_STOP_CHAN:
>> > > +		cmd_tre->ptr = MHI_TRE_CMD_STOP_PTR;
>> > > +		cmd_tre->dword[0] = MHI_TRE_CMD_STOP_DWORD0;
>> > > +		cmd_tre->dword[1] = MHI_TRE_CMD_STOP_DWORD1(chan);
>> > > +		break;
>> > >  	case MHI_CMD_START_CHAN:
>> > >  		cmd_tre->ptr = MHI_TRE_CMD_START_PTR;
>> > >  		cmd_tre->dword[0] = MHI_TRE_CMD_START_DWORD0;
>> > > --
>> > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>> > > Forum,
>> > > a Linux Foundation Collaborative Project
>> > >
>> 
>> Thanks,
>> Bhaumik
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project

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

Re: [PATCH v2 3/6] bus: mhi: core: Add support to stop or start channel data transfers

[Bhaumik Bhatt]

On 2020-11-21 09:05 AM, Manivannan Sadhasivam wrote:
> On Mon, Nov 16, 2020 at 12:56:16PM -0800, Bhaumik Bhatt wrote:
>> Hi Mani,
>> 
>> On 2020-11-16 04:43, Manivannan Sadhasivam wrote:
>> > On Wed, Nov 11, 2020 at 11:21:10AM -0800, Bhaumik Bhatt wrote:
>> > > Some MHI client drivers may want to request a pause or halt of
>> > > data transfer activity on their channels. Support for this does
>> > > not exist and must be introduced, wherein the channel context is
>> > > not reset or cleared but only the STOP channel command is issued.
>> > > This would need to be paired with an API that allows resuming the
>> > > data transfer activity on channels by use of the START channel
>> > > command. This API assumes that the context information is already
>> > > setup. Enable this using two new APIs, mhi_start_transfer() and
>> > > mhi_stop_transfer().
>> > >
>> > > Signed-off-by: Bhaumik Bhatt <bbhatt@codeaurora.org>
>> > > ---
>> > >  drivers/bus/mhi/core/main.c | 41
>> > > +++++++++++++++++++++++++++++++++++++++++
>> > >  include/linux/mhi.h         | 19 +++++++++++++++++++
>> > >  2 files changed, 60 insertions(+)
>> > >
>> > > diff --git a/drivers/bus/mhi/core/main.c b/drivers/bus/mhi/core/main.c
>> > > index 1226933..1a969f4 100644
>> > > --- a/drivers/bus/mhi/core/main.c
>> > > +++ b/drivers/bus/mhi/core/main.c
>> > > @@ -1560,6 +1560,47 @@ void mhi_unprepare_from_transfer(struct
>> > > mhi_device *mhi_dev)
>> > >  }
>> > >  EXPORT_SYMBOL_GPL(mhi_unprepare_from_transfer);
>> > >
>> > > +static int mhi_update_transfer_state(struct mhi_device *mhi_dev,
>> > > +				     enum mhi_ch_state_type to_state)
>> > > +{
>> > > +	struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
>> > > +	struct mhi_chan *mhi_chan;
>> > > +	int dir, ret;
>> > > +
>> > > +	for (dir = 0; dir < 2; dir++) {
>> > > +		mhi_chan = dir ? mhi_dev->ul_chan : mhi_dev->dl_chan;
>> > > +
>> > > +		if (!mhi_chan)
>> > > +			continue;
>> > > +
>> > > +		/*
>> > > +		 * Bail out if one of the channels fail as client will reset
>> > > +		 * both upon failure
>> > > +		 */
>> > > +		mutex_lock(&mhi_chan->mutex);
>> >
>> > Hmm. The documentation about wait_for_completion*() used in
>> > mhi_update_channel_state()says below,
>> >
>> > "As all variants of wait_for_completion() can (obviously) block for a
>> > long
>> > time depending on the nature of the activity they are waiting for, so in
>> > most cases you probably don't want to call this with held mutexes."
>> >
>> Yes, that is understood. The mhi_chan->mutex is only used to lock any
>> channel
>> enable/start/stop/disable type operations, since these have to be in 
>> order,
>> it
>> is essential that we wait for one of the operations to finish before 
>> the
>> next
>> one.
>> 
>> Also we avoid a race, for example, at a time when a device crash 
>> forces a
>> driver
>> "remove" call, while an operation to start/stop a channel is already 
>> going
>> on.
> 
> Can't you just drop the lock before calling wait_for_completion() and
> acquire later? You should add a comment for that also!
> 
So, based on the MHI device sending a command completion, we do not 
expect to
receive it out of order and for tighter control, we also do not want to 
allow
multiple commands to be issued unless one has been responded to or times 
out due
to reasons outside of MHI's control.

We share a common completion variable for a channel and multiple 
commands issued
for channel state changes can result in the completions being 
mishandled.

For example, if we send two commands for the same channel - stop and 
reset and
end up dropping/re-acquiring the lock while waiting for stop channel 
completion
as a response, we could see a reinit_completion() before the complete() 
and the
waiter keeps waiting as a result because the complete() is not seen till 
the
next command response comes in. We may also have to move to 
complete_all() for
this purpose, as these could come from different threads.

Another example is a failure to move states could be seen when dropping 
and
re-acquiring the lock if stop and start channel commands are issued back 
to back
whereas we will not see the issue with current behavior as a start will 
wait for
a stop to fully complete.
>> > > +		ret = mhi_update_channel_state(mhi_cntrl, mhi_chan, to_state);
>> > > +		if (ret) {
>> > > +			mutex_unlock(&mhi_chan->mutex);
>> > > +			return ret;
>> > > +		}
>> > > +		mutex_unlock(&mhi_chan->mutex);
>> > > +	}
>> > > +
>> > > +	return 0;
>> > > +}
>> > > +
>> > > +int mhi_stop_transfer(struct mhi_device *mhi_dev)
>> > > +{
>> > > +	return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_STOP);
>> > > +}
>> > > +EXPORT_SYMBOL_GPL(mhi_stop_transfer);
>> > > +
>> > > +int mhi_start_transfer(struct mhi_device *mhi_dev)
>> > > +{
>> > > +	return mhi_update_transfer_state(mhi_dev, MHI_CH_STATE_TYPE_START);
>> > > +}
>> > > +EXPORT_SYMBOL_GPL(mhi_start_transfer);
>> > > +
>> > >  int mhi_poll(struct mhi_device *mhi_dev, u32 budget)
>> > >  {
>> > >  	struct mhi_controller *mhi_cntrl = mhi_dev->mhi_cntrl;
>> > > diff --git a/include/linux/mhi.h b/include/linux/mhi.h
>> > > index 52b3c60..aee8494 100644
>> > > --- a/include/linux/mhi.h
>> > > +++ b/include/linux/mhi.h
>> > > @@ -702,6 +702,25 @@ int mhi_prepare_for_transfer(struct mhi_device
>> > > *mhi_dev);
>> > >  void mhi_unprepare_from_transfer(struct mhi_device *mhi_dev);
>> > >
>> > >  /**
>> > > + * mhi_stop_transfer - Pauses ongoing channel activity by issuing
>> > > the STOP
>> > > + *                     channel command to both UL and DL channels.
>> > > This command
>> > > + *                     does not reset the channel context and the
>> > > client drivers
>> > > + *                     can issue mhi_start_transfer to resume
>> > > activity.
>> > > + * @mhi_dev: Device associated with the channels
>> > > + */
>> > > +int mhi_stop_transfer(struct mhi_device *mhi_dev);
>> > > +
>> > > +/**
>> > > + * mhi_start_transfer - Resumes channel activity by issuing the
>> > > START channel
>> > > + *                      command to both UL and DL channels. This
>> > > command assumes
>> > > + *                      the channel context is already setup and
>> > > the client
>> > > + *                      drivers can issue mhi_stop_transfer to
>> > > pause activity if
>> > > + *                      required.
>> > > + * @mhi_dev: Device associated with the channels
>> > > + */
>> > > +int mhi_start_transfer(struct mhi_device *mhi_dev);
>> > > +
>> > > +/**
>> >
>> > Align the comment header properly.
>> >
>> So I am trying to follow the documentation style for other functions 
>> in the
>> same
>> file. Is there any particular format you want me to refer to?
>> 
>> I use all spaces for the lines after the first one to align them just 
>> like
>> the
>> rest of them.
>> 
> 
> The diff shows me of below style:
> 
> /**
> + *
> + *
> ...
> + /**
> 
> I just asked to fix this.
> 
I don't see an extra space. Is that it? All functions I see are of the 
style:
/**
  * foo - function desc
  *
  * @param: Desc
  *
  */
> Thanks,
> Mani
> 
>> > Thanks,
>> > Mani
>> >
>> > >   * mhi_poll - Poll for any available data in DL direction
>> > >   * @mhi_dev: Device associated with the channels
>> > >   * @budget: # of events to process
>> > > --
>> > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
>> > > Forum,
>> > > a Linux Foundation Collaborative Project
>> > >
>> 
>> Thanks,
>> Bhaumik
>> --
>> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora 
>> Forum,
>> a Linux Foundation Collaborative Project

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