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@xxxxxxxxxx> > > --- > > 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. Thanks, Sören -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
