Re: What happened to SUSPEND_SAVE_STATE?

[Pavel Machek]

Hi!

> > > diff -Nru a/drivers/pcmcia/i82365.c b/drivers/pcmcia/i82365.c
> > > --- a/drivers/pcmcia/i82365.c	Wed Sep 10 23:18:34 2003
> > > +++ b/drivers/pcmcia/i82365.c	Wed Sep 10 23:18:34 2003
> > > @@ -1351,11 +1351,27 @@
> > >  
> > >  /*====================================================================*/
> > >  
> > > +static int i82365_suspend(struct device *dev, u32 state, u32 level)
> > > +{
> > > +	int ret = 0;
> > > +	if (level == SUSPEND_SAVE_STATE)
> > > +		ret = pcmcia_socket_dev_suspend(dev, state);
> > > +	return ret;
> > > +}
> > > +
> > > +static int i82365_resume(struct device *dev, u32 level)
> > > +{
> > > +	int ret = 0;
> > > +	if (level == RESUME_RESTORE_STATE)
> > > +		ret = pcmcia_socket_dev_resume(dev);
> > > +	return ret;
> > > +}
> > > +
> > >  static struct device_driver i82365_driver = {
> > >  	.name = "i82365",
> > >  	.bus = &platform_bus_type,
> > > -	.suspend = pcmcia_socket_dev_suspend,
> > > -	.resume = pcmcia_socket_dev_resume,
> > > +	.suspend = i82365_suspend,
> > > +	.resume = i82365_resume,
> > >  };
> > >  
> > >  static struct platform_device i82365_device = {
> > 
> > I was not able to find *any* place in the tree that would call suspend
> > with SUSPEND_SAVE_STATE as level. Maybe just my grep was wrong?
> 
> It is correct for the time being.  Well, as far as the ARM tree goes.
> At the moment, the attitude towards platform devices seems to be "tough,
> live with it."  So, I have my own work-arounds, and until such time that
> mainline comes up with a solution, I'm happy.

Ok, it probably means I should not try to fix pcmcia tonight. Patrick,
what is the goal with "u32 level" in struct device_driver? Should the
code be fixed to call it with SUSPEND_SAVE_STATE etc? Or is there some
other plan?
								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/