[PATCH v2] can: Fix bug in suspend/resume
soren.brinkmann at xilinx.com
Fri Nov 14 07:05:14 PST 2014
On Fri, 2014-11-14 at 09:54AM +0100, Marc Kleine-Budde wrote:
> On 11/14/2014 09:16 AM, Kedareswara rao Appana wrote:
> > The drvdata in the suspend/resume is of type struct net_device,
> > not the platform device.Enable the clocks in the suspend before
> > accessing the registers of the CAN.
> > Signed-off-by: Kedareswara rao Appana <appanad at xilinx.com>
> > ---
> > Changes for v2:
> > - Removed the struct platform_device* from suspend/resume
> > as suggest by Lothar.
> > - The clocks are getting disabled and un prepared at the end of the probe.
> > In the suspend the driver is doing a register write.In order
> > To do that register write we have to again enable and prepare the clocks.
> Please look the at suspend/resume code and count the
> clock_enable/disable manually. After a suspend/resume cycle, you have
> enabled the clock twice, but disabled it once.
> I think you have to abstract the clock handling behind runtime PM. I
> haven't done this myself yet, but the strong feeling that this is a
> possible solution to your problem. These links might help:
I agree, the clock handling looks weird. Also the clk_disable calls in
xcan_get_berr_counter() look suspicious to me, but I might be wrong.
I think you can take a look at gpio-zynq for an example for runtime_pm
usage. I think the usage model in that driver is similar to here.
More information about the linux-arm-kernel