Mailing List Archive

[PATCH 2/2] regulator: hi655x: Bump parent pmic module use count
The hi655x-regulator driver depends on the parent pmic/mfc
device driver but doesn't increase its use count. This results
in system crashes if the parent module is unloaded while the
regulators are still in use. Add explicit module get/put
calls to keep the parent from being unloaded.

Signed-off-by: Jeremy Linton <lintonrjeremy@gmail.com>
---
drivers/regulator/hi655x-regulator.c | 26 ++++++++++++++++++++++++--
1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/hi655x-regulator.c b/drivers/regulator/hi655x-regulator.c
index aca1846..5a461d4 100644
--- a/drivers/regulator/hi655x-regulator.c
+++ b/drivers/regulator/hi655x-regulator.c
@@ -185,16 +185,29 @@ static int hi655x_regulator_probe(struct platform_device *pdev)
struct hi655x_pmic *pmic;
struct regulator_config config = { };
struct regulator_dev *rdev;
+ struct device *parent = pdev->dev.parent;

- pmic = dev_get_drvdata(pdev->dev.parent);
+ if (!parent) {
+ dev_err(&pdev->dev, "no regulator parent node\n");
+ return -ENODEV;
+ }
+
+ pmic = dev_get_drvdata(parent);
if (!pmic) {
dev_err(&pdev->dev, "no pmic in the regulator parent node\n");
return -ENODEV;
}

+ if (!try_module_get(parent->driver->owner)) {
+ dev_err(&pdev->dev, "unable to get parent module\n");
+ return -ENODEV;
+ }
+
regulator = devm_kzalloc(&pdev->dev, sizeof(*regulator), GFP_KERNEL);
- if (!regulator)
+ if (!regulator) {
+ module_put(parent->driver->owner);
return -ENOMEM;
+ }

platform_set_drvdata(pdev, regulator);

@@ -214,11 +227,20 @@ static int hi655x_regulator_probe(struct platform_device *pdev)
return 0;
}

+static int hi655x_regulator_remove(struct platform_device *pdev)
+{
+ struct device *parent = pdev->dev.parent;
+
+ module_put(parent->driver->owner);
+ return 0;
+}
+
static struct platform_driver hi655x_regulator_driver = {
.driver = {
.name = "hi655x-regulator",
},
.probe = hi655x_regulator_probe,
+ .remove = hi655x_regulator_remove
};
module_platform_driver(hi655x_regulator_driver);

--
2.10.2
Re: [PATCH 2/2] regulator: hi655x: Bump parent pmic module use count [ In reply to ]
On Mon, Mar 20, 2017 at 11:53:41PM -0500, Jeremy Linton wrote:

> + if (!try_module_get(parent->driver->owner)) {
> + dev_err(&pdev->dev, "unable to get parent module\n");
> + return -ENODEV;
> + }
> +

If this makes sense it should be being done in the driver core, not open
coded in individual drivers.
Re: [PATCH 2/2] regulator: hi655x: Bump parent pmic module use count [ In reply to ]
Hi,

On Tue, Mar 21, 2017 at 6:08 AM, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Mar 20, 2017 at 11:53:41PM -0500, Jeremy Linton wrote:
>
>> + if (!try_module_get(parent->driver->owner)) {
>> + dev_err(&pdev->dev, "unable to get parent module\n");
>> + return -ENODEV;
>> + }
>> +
>
> If this makes sense it should be being done in the driver core, not open
> coded in individual drivers.

Well, this is only really required for the drivers that are oddly
split like these two. It doesn't appear to be necessary for say the
max77* regulators which consume the pmic node, and register
regulators.

I don't understand why it was done this way, and I'm not sure that
this driver shouldn't be triggered based on 'hi655x-regulator' device
(which is being registered by the hi655x-pmic/mfd driver). The only
thing I know for sure, is that its broken in its current
configuration.

Initially I tried a variation on the previous patch, which instead of
trying to double consume the hi655x-pmic platform device, it tried to
consume the hi655x-regulator, but for whatever reason that didn't
work. At least part of the problem with that solution is that depmod
(and therefore tools which are building the initrd) don't understand
the driver relationships here, so simply saying that dw_mmc_k3 is
required for boot doesn't result in the correct set of drivers being
put in the initrd, as one would expect if there were simple symbol
dependencies.
Re: [PATCH 2/2] regulator: hi655x: Bump parent pmic module use count [ In reply to ]
On Tue, Mar 21, 2017 at 03:23:50PM -0500, Jeremy Linton wrote:

> I don't understand why it was done this way, and I'm not sure that
> this driver shouldn't be triggered based on 'hi655x-regulator' device
> (which is being registered by the hi655x-pmic/mfd driver). The only
> thing I know for sure, is that its broken in its current
> configuration.

That's exactly what it should be doing.