[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <cdf11f66-92f5-7431-9e76-6a5c92eb4d91@geanix.com>
Date: Sun, 8 Dec 2019 11:47:55 +0100
From: Sean Nyekjaer <sean@...nix.com>
To: Marc Kleine-Budde <mkl@...gutronix.de>,
Joakim Zhang <qiangqing.zhang@....com>,
"linux-can@...r.kernel.org" <linux-can@...r.kernel.org>
Cc: dl-linux-imx <linux-imx@....com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [PATCH V2 2/4] can: flexcan: try to exit stop mode during probe
stage
On 07/12/2019 21.32, Marc Kleine-Budde wrote:
> On 12/5/19 12:32 PM, Sean Nyekjaer wrote:
>>> If yes, I think we don't need check stop mode in probe stage, since
>>> issue has disappeared automatically.
>>
>> If one have devices deployed where:
>> "can: flexcan: fix deadlock when using self wakeup" isn't applied.
>> They could have devices stuck in stop-mode.
>
> Ok.
>
> But both patches:
>
> can: flexcan: fix deadlock when using self wakeup
> can: flexcan: try to exit stop mode during probe stage
>
> are not yet mainline, so if "can: flexcan: fix deadlock when using self
> wakeup" fixes the problem and goes into stable we don't need "can:
> flexcan: try to exit stop mode during probe stage", right?
>
>> That's what i meant by this patch doesn't do any harm to have the check
>> included.
>
> I don't want to have code in the driver that serves no purpose.
>
Fine with me, I'm continuing to have the patch included in my tree until
all devices are upgraded with:
can: flexcan: fix deadlock when using self wakeup
/Sean
> regards,
> Marc
>
Powered by blists - more mailing lists