On 29/02/16 10:14, Jon Hunter wrote:

On 29/02/16 07:15, Thierry Reding wrote:

quoted

* PGP Signed by an unknown key

On Fri, Feb 26, 2016 at 03:48:37PM +0000, Jon Hunter wrote:

quoted

The genpd framework allows users to add power-domains via the
pm_genpd_init() function, however, there is no corresponding function
to remove a power-domain. For most devices this may be fine as the power
domains are never removed, however, for devices that wish to populate
the power-domains from within a driver, having the ability to remove a
power domain if the probing of the device fails or the driver is unloaded
is necessary. Therefore, add a function to remove a power-domain. Please
note that the power domain can only be removed if there are no devices
using the power-domain and it is not linked to another domain.

So I guess this introduces a problem not uncommon to other types of
resources. If you remove the driver, even if you fail ->remove() the
module may still go away along with any code associated with it. So
even if the PM domains can't be removed, you can't prevent the module
from going away. That could be somewhat mitigated if we were holding a
module reference count, because then the only way to unload the driver
would be via sysfs (we could prevent that too, which might be the best
way to do this today).

There is work underway to solve this generically, Rafael was working on
this, so I'm not sure we need to add additional infrastructure to the PM
domain code as part of this series. But we may want to mark the Tegra
PMC driver as .suppress_bind_attrs = true, to make sure it can't be
removed.

I see what you are saying. It nearly seemed to me that I should use
BUG_ON() if we fail to remove a genpd in the PMC driver, however, I know
that using BUG_ON should be avoided. I will add the suppress_bind_attrs
= true for the PMC driver as that does make sense for now.

Just to let you know, the PMC driver already has suppress_bind_attrs =
true.

Cheers
Jon