[...] > > I actually have a question about a mystery that has been puzzling > me as I work on v5: when unloading the driver that uses the PD > (panthor) and my driver using `modprobe -r panthor mtk_mfg_pmdomain`, > I see that sometimes detach_dev is called with the pd status > reportedly being off, but according to my own power-on/power-off > counting I hacked in, it actually being on. It then proceeds to
Yes, ->detach_dev() may be called for a device, when its corresponding PM domain is both on or off. > call my remove, which results in three splats from the regulator > subsystem as the regulators weren't balanced with disables before > they were freed, which isn't the main problem but more a symptom > of the bigger problem that power_off and power_on calls don't > appear to be balanced by the pmdomain subsystem when a driver is > removed under certain circumstances. If the callbacks aren't called in a properly balanced manner that would be a bug in genpd. Certainly. > > Did I run into a core pmdomain bug here, or do I have to balance > the power_on/off myself somehow in detach_dev? If the latter, I'm > struggling to figure out how I can determine that the PD is still > on without doing my own bookkeeping, as pmdomain core seems to clear > these fields before my detach_dev gets to them :( When genpd_dev_pm_detach() is called, the device is being detached from its genpd and part of that procedure means calling the ->detach_dev() callback. When the device has been detached, we may have the PM domain being powered-on for no good reason. That's why we also punt a work to check if we can turn it off (see the call to genpd_queue_power_off_work()). Kind regards Uffe
