From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <stable-owner@vger.kernel.org>
Received: from lelv0143.ext.ti.com ([198.47.23.248]:47600 "EHLO
        lelv0143.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1726266AbeK0Alv (ORCPT
        <rfc822;stable@vger.kernel.org>); Mon, 26 Nov 2018 19:41:51 -0500
Date: Mon, 26 Nov 2018 07:47:38 -0600
From: Bin Liu <b-liu@ti.com>
To: Vinod Koul <vkoul@kernel.org>
CC: Peter Ujfalusi <peter.ujfalusi@ti.com>,
        <dmaengine@vger.kernel.org>, <linux-usb@vger.kernel.org>,
        <stable@vger.kernel.org>
Subject: Re: [PATCH] dma: cppi41: delete channel from pending list when stop
 channel
Message-ID: <20181126134738.GD27653@uda0271908>
References: <20181112154322.24337-1-b-liu@ti.com>
 <20181124142803.GI3175@vkoul-mobl.Dlink>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20181124142803.GI3175@vkoul-mobl.Dlink>
Sender: stable-owner@vger.kernel.org
List-ID: <stable.vger.kernel.org>

Hi,

On Sat, Nov 24, 2018 at 07:58:03PM +0530, Vinod Koul wrote:
> On 12-11-18, 09:43, Bin Liu wrote:
> > The driver defines three states for a cppi channel.
> > - idle: .chan_busy == 0 && not in .pending list
> > - pending: .chan_busy == 0 && in .pending list
> > - busy: .chan_busy == 1 && not in .pending list
> > 
> > There are cases in which the cppi channel could be in the pending state
> > when cppi41_dma_issue_pending() is called after cppi41_runtime_suspend()
> > is called.
> > 
> > cppi41_stop_chan() has a bug for these cases to set channels to idle state.
> > It only checks the .chan_busy flag, but not the .pending list, then later
> > when cppi41_runtime_resume() is called the channels in .pending list will
> > be transitioned to busy state.
> > 
> > Removing channels from the .pending list solves the problem.
> 
> I would like some testing, given that intent is to go to stable.
> Peter..?

FYI, this cppi41 dma driver is *only* used by musb controller driver. In
the past I received multiple reports for this issue, but I wasn't able
to reproduce it using similar test cases. The only way I could trigger
the issue is to do system suspend/resume test on AM335x with a USB hub
attached to the usb host port. This issue only happens once in the very
*first* time suspend/resume test after reboot.

Regards,
-Bin.