mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Qiang Yu <quic_qianyu@quicinc.com>
To: Manivannan Sadhasivam <mani@kernel.org>
Cc: Mayank Rana <quic_mrana@quicinc.com>, <quic_jhugo@quicinc.com>,
	<mhi@lists.linux.dev>, <linux-arm-msm@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <quic_cang@quicinc.com>
Subject: Re: [PATCH v3 3/3] bus: mhi: host: pci_generic: Add edl callback to enter EDL
Date: Mon, 22 Apr 2024 20:06:06 +0800	[thread overview]
Message-ID: <d9908e10-66d6-4737-b366-80cbc9df1801@quicinc.com> (raw)
In-Reply-To: <20240422080837.GC9775@thinkpad>


On 4/22/2024 4:08 PM, Manivannan Sadhasivam wrote:
> On Wed, Apr 17, 2024 at 12:41:25PM +0800, Qiang Yu wrote:
>
> [...]
>
>>>>>>> +    ret = mhi_get_channel_doorbell(mhi_cntrl, &val);
>>>>>>> +    if (ret)
>>>>>>> +        return ret;
>>>>>> Don't we need error handling part here i.e. calling
>>>>>> mhi_cntrl->runtime_put() as well mhi_device_put() ?
>>>>> Hi Mayank
>>>>>
>>>>> After soc_reset, device will reboot to EDL mode and MHI state
>>>>> will be SYSERR. So host will fail to suspend
>>>>> anyway. The "error handling" we need here is actually to enter
>>>>> EDL mode, this will be done by SYSERR irq.
>>>>> Here, mhi_cntrl->runtime_put() and mhi_device_put() are only to
>>>>> balance mhi_cntrl->runtime_get() and
>>>>> mhi_device_get_sync().
>>>>>
>>>>> Thanks,
>>>>> Qiang
>>>> I am saying is there possibility that mhi_get_channel_doorbell()
>>>> returns error ?
>>>> If yes, then why don't we need error handling as part of it. you are
>>>> exiting if this API return error without doing anything.
>>> I think here mhi_get_channel_doorbell will not return error. But I still
>>> add a error checking because it invoked mhi_read_reg, which is a must
>>> check
>>> API. For modem mhi controller, this API eventually does a memory read.
>>> This memory read will return a normal value if link is up and all f's if
>>> link
>>> is bad.
>>>
>>> Thanks,
>>> Qiang
>> Actually, mhi_get_channel_doorbell should also be used in mhi_init_mmio to
>> replace the getting chdb operation by invoking mhi_read_reg as Mani
>> commented.
>> In mhi_init_mmio, we invoke mhi_read_reg many times, but there is also not
>> additionnal error handling.
>>
>> I'm not very sure the reason but perhaps if mhi_read_reg returns error (I
>> don't
>> know which controller will provide a memory read callback returning errors),
> Take a look at AIC100 driver: drivers/accel/qaic/mhi_controller.c
>
>> most
>> probably something is wrong in PCIe, which is not predictable by MHI and we
>> can
>> not add err handling every time invoking mhi_read_reg. But we have a timer
>> to
>> do health_check in pci_generic.c. If link is down, we will do
>> pci_function_reset
>> to try to reovery.
>>
> Right, but the MHI stack is designed to be bus agnostic. So if we happen to use
> it with other busses like USB, I2C etc... then read APIs may fail.
>
> Even with PCIe, read transaction may return all 1 response and MHI needs to
> treat it as an error condition. But sadly, both pci_generic and ath controllers
> are not checking for invalid read value. But those need to be fixed.
>
> Regarding Mayank's query, you should do error cleanups if
> mhi_get_channel_doorbell() API fails.
>
> - Mani
Hi Mani, Mayank

Checked drivers/accel/qaic/mhi_controller.c, the mhi_read_reg
callback of AIC100 does return -EIO if it reads out all'f.

Considering that pci_generic controller also needs to check for
invalid read value which is not fixed though. It's better to invoke
mhi_cntrl->runtime_put() and mhi_device_put() as error cleanups if
mhi_get_channel_doorbell returns error here.

Let me address all your comments and prepare next version patch.

Thanks,
Qiang
>

      reply	other threads:[~2024-04-22 12:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-15  8:49 [PATCH v3 0/3] Add sysfs entry to EDL mode Qiang Yu
2024-04-15  8:49 ` [PATCH v3 1/3] bus: mhi: host: Add sysfs entry to force device to enter EDL Qiang Yu
2024-04-15 11:56   ` Manivannan Sadhasivam
2024-04-16  5:45     ` Qiang Yu
2024-04-22  7:24       ` Manivannan Sadhasivam
2024-04-22 12:13         ` Qiang Yu
2024-04-15  8:49 ` [PATCH v3 2/3] bus: mhi: host: Add a new API for getting channel doorbell address Qiang Yu
2024-04-15 12:02   ` Manivannan Sadhasivam
2024-04-15  8:49 ` [PATCH v3 3/3] bus: mhi: host: pci_generic: Add edl callback to enter EDL Qiang Yu
2024-04-15 12:12   ` Manivannan Sadhasivam
2024-04-15 23:53   ` Mayank Rana
2024-04-16  3:50     ` Qiang Yu
2024-04-16 18:12       ` Mayank Rana
2024-04-17  3:01         ` Qiang Yu
2024-04-17  4:41           ` Qiang Yu
2024-04-18 17:37             ` Mayank Rana
2024-04-22  8:08             ` Manivannan Sadhasivam
2024-04-22 12:06               ` Qiang Yu [this message]

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=d9908e10-66d6-4737-b366-80cbc9df1801@quicinc.com \
    --to=quic_qianyu@quicinc.com \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mani@kernel.org \
    --cc=mhi@lists.linux.dev \
    --cc=quic_cang@quicinc.com \
    --cc=quic_jhugo@quicinc.com \
    --cc=quic_mrana@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

all inboxes | Powered by JetHome®