* Re: [PATCH] PCI: epf-mhi: return 0 on success instead of positive jiffies
2026-02-06 20:05 [PATCH] PCI: epf-mhi: return 0 on success instead of positive jiffies Daniel Hodges
@ 2026-02-09 5:06 ` Krishna Chaitanya Chundru
2026-02-26 7:20 ` Manivannan Sadhasivam
2026-02-27 19:15 ` Bjorn Helgaas
2 siblings, 0 replies; 6+ messages in thread
From: Krishna Chaitanya Chundru @ 2026-02-09 5:06 UTC (permalink / raw)
To: Daniel Hodges, mani, kwilczynski
Cc: kishon, bhelgaas, mhi, linux-arm-msm, linux-pci, linux-kernel,
stable
On 2/7/2026 1:35 AM, Daniel Hodges wrote:
> wait_for_completion_timeout() returns the number of jiffies remaining
> on success (positive value) or 0 on timeout. The pci_epf_mhi_edma_read()
> and pci_epf_mhi_edma_write() functions use the return value directly as
> their own return value, only converting timeout (0) to -ETIMEDOUT.
>
> On success, they return the positive jiffies value. The callers in
> drivers/bus/mhi/ep/ring.c check for errors with "if (ret < 0)" for
> read_sync and "if (ret)" for write_sync. This causes write_sync success
> cases to be incorrectly treated as errors since the positive jiffies
> value is non-zero.
>
> Fix by setting ret to 0 when wait_for_completion_timeout() succeeds.
>
> Fixes: 7b99aaaddabb ("PCI: epf-mhi: Add eDMA support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel Hodges <git@danielhodges.dev>
Reviewed-by: Krishna Chaitanya Chundru<krishna.chundru@oss.qualcomm.com>
- Krishna Chaitanya.
> ---
> drivers/pci/endpoint/functions/pci-epf-mhi.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pci/endpoint/functions/pci-epf-mhi.c b/drivers/pci/endpoint/functions/pci-epf-mhi.c
> index 6643a88c7a0c..2f077d0b7957 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-mhi.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-mhi.c
> @@ -367,6 +367,8 @@ static int pci_epf_mhi_edma_read(struct mhi_ep_cntrl *mhi_cntrl,
> dev_err(dev, "DMA transfer timeout\n");
> dmaengine_terminate_sync(chan);
> ret = -ETIMEDOUT;
> + } else {
> + ret = 0;
> }
>
> err_unmap:
> @@ -438,6 +440,8 @@ static int pci_epf_mhi_edma_write(struct mhi_ep_cntrl *mhi_cntrl,
> dev_err(dev, "DMA transfer timeout\n");
> dmaengine_terminate_sync(chan);
> ret = -ETIMEDOUT;
> + } else {
> + ret = 0;
> }
>
> err_unmap:
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] PCI: epf-mhi: return 0 on success instead of positive jiffies
2026-02-06 20:05 [PATCH] PCI: epf-mhi: return 0 on success instead of positive jiffies Daniel Hodges
2026-02-09 5:06 ` Krishna Chaitanya Chundru
@ 2026-02-26 7:20 ` Manivannan Sadhasivam
2026-02-27 19:15 ` Bjorn Helgaas
2 siblings, 0 replies; 6+ messages in thread
From: Manivannan Sadhasivam @ 2026-02-26 7:20 UTC (permalink / raw)
To: kwilczynski, Daniel Hodges
Cc: kishon, bhelgaas, mhi, linux-arm-msm, linux-pci, linux-kernel,
stable
On Fri, 06 Feb 2026 15:05:29 -0500, Daniel Hodges wrote:
> wait_for_completion_timeout() returns the number of jiffies remaining
> on success (positive value) or 0 on timeout. The pci_epf_mhi_edma_read()
> and pci_epf_mhi_edma_write() functions use the return value directly as
> their own return value, only converting timeout (0) to -ETIMEDOUT.
>
> On success, they return the positive jiffies value. The callers in
> drivers/bus/mhi/ep/ring.c check for errors with "if (ret < 0)" for
> read_sync and "if (ret)" for write_sync. This causes write_sync success
> cases to be incorrectly treated as errors since the positive jiffies
> value is non-zero.
>
> [...]
Applied, thanks!
[1/1] PCI: epf-mhi: return 0 on success instead of positive jiffies
commit: f6797680fe312ae6d32a773eb4d33400f24555c2
Best regards,
--
Manivannan Sadhasivam <mani@kernel.org>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] PCI: epf-mhi: return 0 on success instead of positive jiffies
2026-02-06 20:05 [PATCH] PCI: epf-mhi: return 0 on success instead of positive jiffies Daniel Hodges
2026-02-09 5:06 ` Krishna Chaitanya Chundru
2026-02-26 7:20 ` Manivannan Sadhasivam
@ 2026-02-27 19:15 ` Bjorn Helgaas
2026-03-02 5:54 ` Manivannan Sadhasivam
2 siblings, 1 reply; 6+ messages in thread
From: Bjorn Helgaas @ 2026-02-27 19:15 UTC (permalink / raw)
To: Daniel Hodges
Cc: mani, kwilczynski, kishon, bhelgaas, mhi, linux-arm-msm,
linux-pci, linux-kernel, stable
On Fri, Feb 06, 2026 at 03:05:29PM -0500, Daniel Hodges wrote:
> wait_for_completion_timeout() returns the number of jiffies remaining
> on success (positive value) or 0 on timeout. The pci_epf_mhi_edma_read()
> and pci_epf_mhi_edma_write() functions use the return value directly as
> their own return value, only converting timeout (0) to -ETIMEDOUT.
>
> On success, they return the positive jiffies value. The callers in
> drivers/bus/mhi/ep/ring.c check for errors with "if (ret < 0)" for
> read_sync and "if (ret)" for write_sync. This causes write_sync success
> cases to be incorrectly treated as errors since the positive jiffies
> value is non-zero.
>
> Fix by setting ret to 0 when wait_for_completion_timeout() succeeds.
>
> Fixes: 7b99aaaddabb ("PCI: epf-mhi: Add eDMA support")
> Cc: stable@vger.kernel.org
> Signed-off-by: Daniel Hodges <git@danielhodges.dev>
Thanks for the patch!
Two questions: first, is there any reason why __mhi_ep_cache_ring()
tests for "ret < 0" but mhi_ep_ring_add_element() tests for "ret"
(non-zero)? Could/should they both test just for non-zero, which I
think is the typical style?
Second, the subject and commit log are perfectly correct but basically
at the level of describing the C code. I propose something along
these lines:
PCI: epf-mhi: Return 0, not remaining timeout, when eDMA ops complete
pci_epf_mhi_edma_read() and pci_epf_mhi_edma_write() start DMA
operations and wait for completion with a timeout.
On successful completion, they previously returned the remaining
timeout, which callers may treat as an error. In particular,
mhi_ep_ring_add_element(), which calls pci_epf_mhi_edma_write() via
mhi_cntrl->write_sync(), interprets any non-zero return value as
failure.
Return 0 on success instead of the remaining timeout to prevent
mhi_ep_ring_add_element() from treating successful completion as an
error.
> ---
> drivers/pci/endpoint/functions/pci-epf-mhi.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/pci/endpoint/functions/pci-epf-mhi.c b/drivers/pci/endpoint/functions/pci-epf-mhi.c
> index 6643a88c7a0c..2f077d0b7957 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-mhi.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-mhi.c
> @@ -367,6 +367,8 @@ static int pci_epf_mhi_edma_read(struct mhi_ep_cntrl *mhi_cntrl,
> dev_err(dev, "DMA transfer timeout\n");
> dmaengine_terminate_sync(chan);
> ret = -ETIMEDOUT;
> + } else {
> + ret = 0;
> }
>
> err_unmap:
> @@ -438,6 +440,8 @@ static int pci_epf_mhi_edma_write(struct mhi_ep_cntrl *mhi_cntrl,
> dev_err(dev, "DMA transfer timeout\n");
> dmaengine_terminate_sync(chan);
> ret = -ETIMEDOUT;
> + } else {
> + ret = 0;
> }
>
> err_unmap:
> --
> 2.52.0
>
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] PCI: epf-mhi: return 0 on success instead of positive jiffies
2026-02-27 19:15 ` Bjorn Helgaas
@ 2026-03-02 5:54 ` Manivannan Sadhasivam
2026-03-02 14:59 ` Daniel Hodges
0 siblings, 1 reply; 6+ messages in thread
From: Manivannan Sadhasivam @ 2026-03-02 5:54 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Daniel Hodges, kwilczynski, kishon, bhelgaas, mhi, linux-arm-msm,
linux-pci, linux-kernel, stable
On Fri, Feb 27, 2026 at 01:15:10PM -0600, Bjorn Helgaas wrote:
> On Fri, Feb 06, 2026 at 03:05:29PM -0500, Daniel Hodges wrote:
> > wait_for_completion_timeout() returns the number of jiffies remaining
> > on success (positive value) or 0 on timeout. The pci_epf_mhi_edma_read()
> > and pci_epf_mhi_edma_write() functions use the return value directly as
> > their own return value, only converting timeout (0) to -ETIMEDOUT.
> >
> > On success, they return the positive jiffies value. The callers in
> > drivers/bus/mhi/ep/ring.c check for errors with "if (ret < 0)" for
> > read_sync and "if (ret)" for write_sync. This causes write_sync success
> > cases to be incorrectly treated as errors since the positive jiffies
> > value is non-zero.
> >
> > Fix by setting ret to 0 when wait_for_completion_timeout() succeeds.
> >
> > Fixes: 7b99aaaddabb ("PCI: epf-mhi: Add eDMA support")
> > Cc: stable@vger.kernel.org
> > Signed-off-by: Daniel Hodges <git@danielhodges.dev>
>
> Thanks for the patch!
>
> Two questions: first, is there any reason why __mhi_ep_cache_ring()
> tests for "ret < 0" but mhi_ep_ring_add_element() tests for "ret"
> (non-zero)? Could/should they both test just for non-zero, which I
> think is the typical style?
>
Yes, agree. I've sent a patch to fix this. Thanks for spotting!
> Second, the subject and commit log are perfectly correct but basically
> at the level of describing the C code. I propose something along
> these lines:
>
> PCI: epf-mhi: Return 0, not remaining timeout, when eDMA ops complete
>
> pci_epf_mhi_edma_read() and pci_epf_mhi_edma_write() start DMA
> operations and wait for completion with a timeout.
>
> On successful completion, they previously returned the remaining
> timeout, which callers may treat as an error. In particular,
> mhi_ep_ring_add_element(), which calls pci_epf_mhi_edma_write() via
> mhi_cntrl->write_sync(), interprets any non-zero return value as
> failure.
>
> Return 0 on success instead of the remaining timeout to prevent
> mhi_ep_ring_add_element() from treating successful completion as an
> error.
>
Ammended the commit with the above, thanks!
- Mani
--
மணிவண்ணன் சதாசிவம்
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [PATCH] PCI: epf-mhi: return 0 on success instead of positive jiffies
2026-03-02 5:54 ` Manivannan Sadhasivam
@ 2026-03-02 14:59 ` Daniel Hodges
0 siblings, 0 replies; 6+ messages in thread
From: Daniel Hodges @ 2026-03-02 14:59 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: Bjorn Helgaas, Daniel Hodges, kwilczynski, kishon, bhelgaas, mhi,
linux-arm-msm, linux-pci, linux-kernel, stable
On Mon, Mar 02, 2026 at 11:24:23AM +0530, Manivannan Sadhasivam wrote:
> On Fri, Feb 27, 2026 at 01:15:10PM -0600, Bjorn Helgaas wrote:
> > On Fri, Feb 06, 2026 at 03:05:29PM -0500, Daniel Hodges wrote:
> > > wait_for_completion_timeout() returns the number of jiffies remaining
> > > on success (positive value) or 0 on timeout. The pci_epf_mhi_edma_read()
> > > and pci_epf_mhi_edma_write() functions use the return value directly as
> > > their own return value, only converting timeout (0) to -ETIMEDOUT.
> > >
> > > On success, they return the positive jiffies value. The callers in
> > > drivers/bus/mhi/ep/ring.c check for errors with "if (ret < 0)" for
> > > read_sync and "if (ret)" for write_sync. This causes write_sync success
> > > cases to be incorrectly treated as errors since the positive jiffies
> > > value is non-zero.
> > >
> > > Fix by setting ret to 0 when wait_for_completion_timeout() succeeds.
> > >
> > > Fixes: 7b99aaaddabb ("PCI: epf-mhi: Add eDMA support")
> > > Cc: stable@vger.kernel.org
> > > Signed-off-by: Daniel Hodges <git@danielhodges.dev>
> >
> > Thanks for the patch!
> >
> > Two questions: first, is there any reason why __mhi_ep_cache_ring()
> > tests for "ret < 0" but mhi_ep_ring_add_element() tests for "ret"
> > (non-zero)? Could/should they both test just for non-zero, which I
> > think is the typical style?
> >
>
> Yes, agree. I've sent a patch to fix this. Thanks for spotting!
>
> > Second, the subject and commit log are perfectly correct but basically
> > at the level of describing the C code. I propose something along
> > these lines:
> >
> > PCI: epf-mhi: Return 0, not remaining timeout, when eDMA ops complete
> >
> > pci_epf_mhi_edma_read() and pci_epf_mhi_edma_write() start DMA
> > operations and wait for completion with a timeout.
> >
> > On successful completion, they previously returned the remaining
> > timeout, which callers may treat as an error. In particular,
> > mhi_ep_ring_add_element(), which calls pci_epf_mhi_edma_write() via
> > mhi_cntrl->write_sync(), interprets any non-zero return value as
> > failure.
> >
> > Return 0 on success instead of the remaining timeout to prevent
> > mhi_ep_ring_add_element() from treating successful completion as an
> > error.
> >
>
> Ammended the commit with the above, thanks!
>
> - Mani
Thanks for cleaning up! I meant to get around to this, but got a little
distracted with some other things.
-Daniel
^ permalink raw reply [flat|nested] 6+ messages in thread