On 2016-06-09 13:08, Thomas Gleixner wrote: > On Tue, 7 Jun 2016, Dong Aisheng wrote: >> Then it may need introduce a lot changes and increase many new core APIs. >> Is that a problem? > > No. That's all better than each driver having broken workarounds. It's a > common problem so it wants to be addressed at the core level. There you have a > central point to do this and you can still catch abusers which call stuff from > the wrong context. The hacks in the drivers don't allow that because they look > at the context, i.e. irq disabled, instead of checking the system state.
IMHO, the hacky part of my patch was how I detected whether to use sleep or delay. That said I am ok with API extension too, I guess it is fairly common use case... I found at least 6 clock prepare functions with sleep in it (and some udelays, all between 1-100). Your proposed solution uses "early_boot_or_suspend_resume" which I did not found as a convenient function in the wild :-) How would you implement that? -- Stefan
