From: Baochen Qiang <quic_bqiang@quicinc.com>
To: Jeffrey Hugo <quic_jhugo@quicinc.com>,
Kalle Valo <kvalo@kernel.org>, <mhi@lists.linux.dev>
Cc: <ath11k@lists.infradead.org>, <linux-wireless@vger.kernel.org>
Subject: Re: [PATCH RFC 2/8] bus: mhi: host: add new interfaces to handle MHI channels directly
Date: Mon, 13 Nov 2023 08:32:00 +0800 [thread overview]
Message-ID: <6c21c0ae-ddaf-4c62-9017-1cbbf2eaa429@quicinc.com> (raw)
In-Reply-To: <5d77e9da-4a83-547a-08d9-5d7626e2a600@quicinc.com>
On 11/13/2023 12:18 AM, Jeffrey Hugo wrote:
> On 11/11/2023 8:59 PM, Baochen Qiang wrote:
>>
>> On 11/11/2023 1:14 AM, Jeffrey Hugo wrote:
>>> On 11/10/2023 3:21 AM, Kalle Valo wrote:
>>>> From: Baochen Qiang <quic_bqiang@quicinc.com>
>>>>
>>>> When using mhi_power_down_no_destroy() MHI hosts need to unprepare
>>>> MHI channels
>>>> by themselves. Similarly, MHI stack will also not create new MHI
>>>> device since
>>>> old devices were not destroyed, so MHI hosts need to prepare
>>>> channels as well.
>>>> Hence add these two interfaces to make that possible.
>>>>
>>>> Tested-on: WCN6855 hw2.0 PCI
>>>> WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
>>>>
>>>> Signed-off-by: Baochen Qiang <quic_bqiang@quicinc.com>
>>>> Signed-off-by: Kalle Valo <quic_kvalo@quicinc.com>
>>>> ---
>>>> drivers/bus/mhi/host/main.c | 91
>>>> +++++++++++++++++++++++++++++++++++++
>>>> include/linux/mhi.h | 18 ++++++++
>>>> 2 files changed, 109 insertions(+)
>>>>
>>>> diff --git a/drivers/bus/mhi/host/main.c b/drivers/bus/mhi/host/main.c
>>>> index dcf627b36e82..9bcf8a49c000 100644
>>>> --- a/drivers/bus/mhi/host/main.c
>>>> +++ b/drivers/bus/mhi/host/main.c
>>>> @@ -1667,6 +1667,49 @@ int
>>>> mhi_prepare_for_transfer_autoqueue(struct mhi_device *mhi_dev)
>>>> }
>>>> EXPORT_SYMBOL_GPL(mhi_prepare_for_transfer_autoqueue);
>>>> +static int __mhi_prepare_for_transfer_autoqueue(struct device
>>>> *dev, void *data)
>>>> +{
>>>> + struct mhi_device *mhi_dev;
>>>> + struct mhi_chan *ul_chan, *dl_chan;
>>>> + enum mhi_ee_type ee = MHI_EE_MAX;
>>>> +
>>>> + if (dev->bus != &mhi_bus_type)
>>>> + return 0;
>>>> +
>>>> + mhi_dev = to_mhi_device(dev);
>>>> +
>>>> + /* Only prepare virtual devices thats attached to bus */
>>>
>>> "that are"?
>>>
>> It means MHI devices with a type of MHI_DEVICE_XFER. See also
>> mhi_destroy_device();
>
> I think you are confused about my comment. "thats" is not correct
> English. I was suggesting you replace it with "that are", but there
> are many ways to reword the comment.
Sorry for misunderstood your comment. Will refine it in next version.
>
>>
>>
>>>> + if (mhi_dev->dev_type == MHI_DEVICE_CONTROLLER)
>>>> + return 0;
>>>> +
>>>> + ul_chan = mhi_dev->ul_chan;
>>>> + dl_chan = mhi_dev->dl_chan;
>>>> +
>>>> + /*
>>>> + * If execution environment is specified, remove only those
>>>> devices that
>>>> + * started in them based on ee_mask for the channels as we
>>>> move on to a
>>>> + * different execution environment
>>>> + */
>>>> + if (data)
>>>> + ee = *(enum mhi_ee_type *)data;
>>>> +
>>>> + if (ul_chan && ee != MHI_EE_MAX && !(ul_chan->ee_mask & BIT(ee)))
>>>> + return 0;
>>>> +
>>>> +
>>>> + if (dl_chan && ee != MHI_EE_MAX && !(dl_chan->ee_mask & BIT(ee)))
>>>> + return 0;
>>>> +
>>>> + return mhi_prepare_for_transfer_autoqueue(mhi_dev);
>>>> +}
>>>> +
>>>> +int mhi_prepare_all_for_transfer_autoqueue(struct mhi_controller
>>>> *mhi_cntrl)
>>>> +{
>>>> + return device_for_each_child(&mhi_cntrl->mhi_dev->dev, NULL,
>>>> + __mhi_prepare_for_transfer_autoqueue);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(mhi_prepare_all_for_transfer_autoqueue);
>>>
>>> This seems broken. It appears to configure all channels as
>>> autoqueue, regardless of how the controller initially configured
>>> them. This would only be safe to use if all channels were
>>> configured for autoqueue, but would silently cause issues otherwise.
>>
>> Thanks for pointing that. Yes, it is not correct to treat all
>> channels as autoqueue regardless of its initial configuration. So how
>> about change as below:
>
> Seems ok.
>
>>
>> /* The difference between mhi_prepare_for_transfer_autoqueue() and
>> mhi_prepare_for_transfer() comes from how to treat downlink channel */
>>
>> mhi_prepare_for_transfer_dev(struct device *dev, ...)
>>
>> {
>>
>> ...
>>
>> dl_chan = mhi_dev->dl_chan;
>>
>> ...
>>
>> if (dl_chan->pre_alloc)
>>
>> mhi_prepare_for_transfer_autoqueue(dev);
>>
>> else
>>
>> mhi_prepare_for_transfer(dev);
>>
>> }
>>
>> /* And then iterate all devices and call
>> mhi_prepare_for_transfer_dev() for each. */
>>
>> int mhi_prepare_all_for_transfer(struct mhi_controller *mhi_cntrl)
>> {
>> return device_for_each_child(&mhi_cntrl->mhi_dev->dev, NULL,
>> mhi_prepare_for_transfer_dev);
>> }
>> EXPORT_SYMBOL_GPL(mhi_prepare_all_for_transfer);
>>
>
next prev parent reply other threads:[~2023-11-13 0:32 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-10 10:21 [PATCH RFC 0/8] wifi: ath11k: hibernation support Kalle Valo
2023-11-10 10:21 ` [PATCH RFC 1/8] bus: mhi: host: add mhi_power_down_no_destroy() Kalle Valo
2023-11-14 1:26 ` Mayank Rana
2023-11-10 10:21 ` [PATCH RFC 2/8] bus: mhi: host: add new interfaces to handle MHI channels directly Kalle Valo
2023-11-10 17:14 ` Jeffrey Hugo
2023-11-12 3:59 ` Baochen Qiang
2023-11-12 16:18 ` Jeffrey Hugo
2023-11-13 0:32 ` Baochen Qiang [this message]
2023-11-10 10:21 ` [PATCH RFC 3/8] wifi: ath11k: handle irq enable/disable in several code path Kalle Valo
2023-11-10 10:21 ` [PATCH RFC 4/8] wifi: ath11k: remove MHI LOOPBACK channels Kalle Valo
2023-11-10 16:54 ` Jeffrey Hugo
2023-11-12 4:24 ` Baochen Qiang
2023-11-12 16:15 ` Jeffrey Hugo
2023-11-13 0:30 ` Baochen Qiang
2023-11-13 14:15 ` Kalle Valo
2023-11-13 14:26 ` Jeffrey Hugo
2023-11-13 15:04 ` Kalle Valo
2023-11-10 10:21 ` [PATCH RFC 5/8] wifi: ath11k: do not dump SRNG statistics during resume Kalle Valo
2023-11-10 10:22 ` [PATCH RFC 6/8] wifi: ath11k: fix warning on DMA ring capabilities event Kalle Valo
2023-11-10 10:22 ` [PATCH RFC 7/8] wifi: ath11k: thermal: don't try to register multiple times Kalle Valo
2023-11-10 10:22 ` [PATCH RFC 8/8] wifi: ath11k: support hibernation Kalle Valo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6c21c0ae-ddaf-4c62-9017-1cbbf2eaa429@quicinc.com \
--to=quic_bqiang@quicinc.com \
--cc=ath11k@lists.infradead.org \
--cc=kvalo@kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=mhi@lists.linux.dev \
--cc=quic_jhugo@quicinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).