On Thu, 2006-06-22 at 15:31 -0700, Linus Torvalds wrote: > > On Fri, 23 Jun 2006, Benjamin Herrenschmidt wrote: > > > > The problem is that what you call "controller setup" might well happen > > as part of normal operations of a given device. > > Give one _reasonable_ example. automatic rotating keys is one that came to mind, automatic controller timing demotion is another, I could certainly find more... damn even hard disks have that sort of state (think about host protected area setting.. ok unlikely that this changed in the middle of a suspend cycle unless you hotswap just at the wrong time). However there aren't that many examples tho becasue there is not that many state that need to be saved ! (which adds to my argument that save_state is generally not even needed and thus by splitting it out, you won't really help your debugging problem). > > I think you are trying to change a model that is not broken... > > Bzzt. Thank you for playing. I really think it's not that model that is broken :) > The fact is, this thing has been broken for years. At some point, we have > to just accept the fact that it's not just "drivers". There's something > else that is broken, and I bet it's the model. Why ? I have fixed drivers used on powermac and it works like a charm. Drivers are broken, the model is sane. really. > The fact that drivers don't get fixed should be a big hint. The main reason is the video problem (chips not coming back on resume and needing a POST). This has always been the main issue and that's what is causing STR not to work for a lot of people. > And yes, maybe I'm wrong, but even if I am, what have we got to lose? > Nothing. The thing doesn't work reliably now. The model does and I think your model would 1- break all existing drivers that got it right since they have to be changed and 2- won't help with the actual problems :) > And you haven't actually answered any of my fundamental issues, which > boils down to > > - debuggability > - not doing five things in the same routine. I'm confident you won't get help on the first one, by splitting save_state since that's not that which is a problem, but the actual suspend. The later, well, it just has to be that way. (And it's not 5, it's 3 and actually boils down to 2 in most drivers since there is nothing to save and the first one, blocking of userland activity, usually tends to be a one liner with the appropriate support from the subsystem). > but instead you have brought up total red herrings that have nothing to do > with either (including apparently the totally ludicrous claim that it's > "easier" for drivers to have just one complicated function). I've brought a real concern that you'll resume devices in a different state than what was last set at suspend time and change a model that isn't broken. Ben.
