linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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);
>>
>

  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).