mhi.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Manivannan Sadhasivam <mani@kernel.org>
To: Qiang Yu <quic_qianyu@quicinc.com>
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 13:38:37 +0530	[thread overview]
Message-ID: <20240422080837.GC9775@thinkpad> (raw)
In-Reply-To: <a5ea5263-8acb-48dd-a4e1-bc48a9bdf791@quicinc.com>

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

-- 
மணிவண்ணன் சதாசிவம்

  parent reply	other threads:[~2024-04-22  8:08 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 [this message]
2024-04-22 12:06               ` Qiang Yu

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=20240422080837.GC9775@thinkpad \
    --to=mani@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhi@lists.linux.dev \
    --cc=quic_cang@quicinc.com \
    --cc=quic_jhugo@quicinc.com \
    --cc=quic_mrana@quicinc.com \
    --cc=quic_qianyu@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).