Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1605306 > unrolled thread

[PATCH 2/2] regulator: hi655x: Bump parent pmic module use count

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  [PATCH 2/2] regulator: hi655x: Bump parent pmic module use count Jeremy Linton <lintonrjeremy@gmail.com> - 2017-03-21 06:00 +0100
    Re: [PATCH 2/2] regulator: hi655x: Bump parent pmic module use count Mark Brown <broonie@kernel.org> - 2017-03-21 12:10 +0100
      Re: [PATCH 2/2] regulator: hi655x: Bump parent pmic module use count Jeremy Linton <lintonrjeremy@gmail.com> - 2017-03-21 21:30 +0100
        Re: [PATCH 2/2] regulator: hi655x: Bump parent pmic module use count Mark Brown <broonie@kernel.org> - 2017-03-22 13:50 +0100

#1605306 — [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

[toc] | [next] | [standalone]

#1605502

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1605976

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.

[toc] | [prev] | [next] | [standalone]

#1606429

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web