On Thu, Aug 22, 2024 at 11:29:24AM +0200, Christian König wrote: > Am 22.08.24 um 10:21 schrieb Thomas Hellström: > > On Thu, 2024-08-22 at 09:55 +0200, Christian König wrote: > > > In my opinion device drivers should *never* resume runtime PM in a > > > shrinker callback in the first place. > > Runtime PM resume is allowed even from irq context if carefully > > implemented by the driver and flagged as such to the core. > > > > https://docs.kernel.org/power/runtime_pm.html > > > > Resuming runtime PM from reclaim therefore shouldn't be an issue IMO, > > and really up to the driver. > > Mhm when it's up to the driver on which level to use runtime PM then that at > least explains why the framework doesn't have lockdep annotations. Aside on the lockdep question: Per-device lockdep annotations would be doable I think (since the rules really are per-device). But lockdep really doesn't cope too well with too many dynamic lockdep classes, so that's maybe the reason this was never done? It's the same with module reload, eventually you run out of lockdep class keys :-/ What we perhaps could do is register a driver lockdep key (which is static), that runtime pm core code could optionally use when set? Hm, thinking about this some more, if we embed this in struct device_driver when it's statically created, this could work perhaps automatically? -Sima -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
