> -----Original Message----- > From: Joakim Zhang <qiangqing.zhang@xxxxxxx> > Sent: 2019年11月27日 17:37 > To: Sean Nyekjaer <sean@xxxxxxxxxx>; mkl@xxxxxxxxxxxxxx; > linux-can@xxxxxxxxxxxxxxx > Cc: dl-linux-imx <linux-imx@xxxxxxx>; netdev@xxxxxxxxxxxxxxx > Subject: RE: [PATCH V2 0/4] can: flexcan: fixes for stop mode > > > > -----Original Message----- > > From: Sean Nyekjaer <sean@xxxxxxxxxx> > > Sent: 2019年11月27日 16:13 > > To: Joakim Zhang <qiangqing.zhang@xxxxxxx>; mkl@xxxxxxxxxxxxxx; > > linux-can@xxxxxxxxxxxxxxx > > Cc: dl-linux-imx <linux-imx@xxxxxxx>; netdev@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH V2 0/4] can: flexcan: fixes for stop mode > > > > > > > > On 27/11/2019 07.12, Sean Nyekjaer wrote: > > > > > > > > > On 27/11/2019 06.56, Joakim Zhang wrote: > > >> Could you help check the patch set? With your suggestions, I > > >> have cooked a patch to exit stop mode during probe stage. > > >> > > >> IMHO, I think this patch is unneed, now in flexcan driver, > > >> enter stop mode when suspend, and then exit stop mode when resume. > > >> AFAIK, as long as flexcan_suspend has been called, flexcan_resume > > >> will be called, unless the system hang during suspend/resume. If > > >> so, only code reset can activate OS again. Could you please tell me > > >> how does CAN stucked in stop mode at your side? > > > > > > Hi Joakim, > > > > > > Thanks I'll test this :-) > > > Guess I will have do some hacking to get it stuck in stop mode. > > > > > > We have a lot of devices in the field that doesn't have: > > > "can: flexcan: fix deadlock when using self wakeup" > > > > > > And they have traffic on both CAN interfaces, that way it's quite > > > easy to get them stuck in stop mode. > > > > > > /Sean > > > > Hi Joakim, > > > > I have been testing this. > > I have a hacked version of the driver that calls > > flexcan_enter_stop_mode() as the last step in the probe function. > > > > First insert of flexcan.ko when stop mode is activated: > > flexcan 2090000.flexcan: Linked as a consumer to regulator.4 > > > > flexcan 2090000.flexcan: registering netdev failed > > > > flexcan 2090000.flexcan: Dropping the link to regulator.4 > > > > flexcan: probe of 2090000.flexcan failed with error -110 > > > > flexcan 2094000.flexcan: Linked as a consumer to regulator.4 > > > > flexcan 2094000.flexcan: registering netdev failed > > > > flexcan 2094000.flexcan: Dropping the link to regulator.4 > > > > flexcan: probe of 2094000.flexcan failed with error -110 > > > > > > When I insert a flexcan.ko with the patch > > "can: flexcan: try to exit stop mode during probe stage": > > flexcan 2090000.flexcan: Linked as a consumer to regulator.4 > > > > flexcan 2090000.flexcan: Unbalanced pm_runtime_enable! > > > > flexcan 2094000.flexcan: Linked as a consumer to regulator.4 > > > > flexcan 2094000.flexcan: Unbalanced pm_runtime_enable! > > > > I works as I expected but, I think we need to do some pm_runtime > > cleanup when bailing with error -110. > > Anyways it works great, thanks for your work on this. > > Hi Sean, > > Thanks for your quirk test, I used unbind/bind to test, do not meet such issue. > I will build as a module to have a test. One more should confirm with you, you inserted a flexcan.ko after stop mode activated without fix patch firstly, and then inserted a flexcan.ko with fix patch. If yes, this could cause unbalanced pm_runtime_enabled. The reason is that firstly inserted the flexcan.ko would enable device runtime pm, and then you inserted flexcan.ko enable device runtime pm again. Could you please insert flexcan.ko with fix patch directly after stop mode activated? Best Regards, Joakim Zhang > Best Regards, > Joakim Zhang > > /Sean
