On Mon, 18 May 2009, Magnus Damm wrote: > > Let's put it this way: Yes, SUSPENDED/FROZEN/OFF is software state. > > In other words, it's really the state of the _driver_ (since the driver > > is software). It isn't the device state; that is, it's not a hardware > > state. So yes, you can keep that information -- but it's not what you > > said you wanted; above you said you wanted to keep the state of each > > _device_ somewhere. > > I'd like to keep the state of the driver _instance_. Basically what > struct device represents. Not struct device_driver. Sorry for being > unclear, I mean struct device when I use the word device. Driver and > hardware specific state and information should be kept out of common > data structures. But that's just common sense, no? Same as keeping bus > specific information together with the bus data structures. > > So to clarify, we have many drivers with multiple driver instances on > SuperH. A good example is the CEU platform driver, each driver > instance (video capture) is hooked up to a hardware block located > somewhere in io memory space. We have one struct device_driver but may > have multiple struct devices. I'm interested in the state of struct > device. That's fine. My only nit is to point out that the state of the struct device isn't the same thing as the state of the device itself. So long as we're clear on that, there's no problem. > How about this: "execute some struct device ->freeze() callbacks and > take a note of this by putting driver instances in FROZEN state". Does > it make more sense? Yes, but you do have to be careful. If there's a possibility that a user process might be running and might try to send I/O to your frozen driver then you wouldn't want to do this. Alan Stern _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
