From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
To: Axel Lin <axel.lin@ingics.com>
Cc: Mark Brown <broonie@kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] regulator: hi6421v600: Fix setting wrong driver_data
Date: Wed, 30 Jun 2021 08:54:16 +0200 [thread overview]
Message-ID: <20210630085416.4b3d9864@coco.lan> (raw)
In-Reply-To: <20210622043329.392072-1-axel.lin@ingics.com>
Em Tue, 22 Jun 2021 12:33:29 +0800
Axel Lin <axel.lin@ingics.com> escreveu:
> Current code set "config.driver_data = sreg" but sreg only init the mutex,
> the othere fields are just zero. Fix it by pass *info to config.driver_data
> so each regulator can get corresponding data by rdev_get_drvdata().
>
> Separate enable_mutex from struct hi6421_spmi_reg_info since only need one
> mutex for the driver.
>
> Fixes: d2dfd50a0b57 ("staging: hikey9xx: hi6421v600-regulator: move LDO config from DT")
> Signed-off-by: Axel Lin <axel.lin@ingics.com>
As discussed on a separate thread, this patch is broken. See below.
> ---
> drivers/regulator/hi6421v600-regulator.c | 26 ++++++++++++++----------
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/regulator/hi6421v600-regulator.c b/drivers/regulator/hi6421v600-regulator.c
> index b5a19938fd3a..21153ee03a3f 100644
> --- a/drivers/regulator/hi6421v600-regulator.c
> +++ b/drivers/regulator/hi6421v600-regulator.c
> @@ -16,13 +16,15 @@
> #include <linux/regulator/driver.h>
> #include <linux/spmi.h>
>
> +struct hi6421_spmi_reg_priv {
> + /* Serialize regulator enable logic */
> + struct mutex enable_mutex;
> +};
> +
> struct hi6421_spmi_reg_info {
> struct regulator_desc desc;
> u8 eco_mode_mask;
> u32 eco_uA;
> -
> - /* Serialize regulator enable logic */
> - struct mutex enable_mutex;
> };
>
> static const unsigned int ldo3_voltages[] = {
> @@ -96,11 +98,12 @@ static const unsigned int ldo34_voltages[] = {
>
> static int hi6421_spmi_regulator_enable(struct regulator_dev *rdev)
> {
> - struct hi6421_spmi_reg_info *sreg = rdev_get_drvdata(rdev);
> + struct hi6421_spmi_reg_priv *priv;
> int ret;
>
> + priv = dev_get_drvdata(rdev->dev.parent);
> /* cannot enable more than one regulator at one time */
> - mutex_lock(&sreg->enable_mutex);
> + mutex_lock(&priv->enable_mutex);
>
> ret = regmap_update_bits(rdev->regmap, rdev->desc->enable_reg,
> rdev->desc->enable_mask,
> @@ -109,7 +112,7 @@ static int hi6421_spmi_regulator_enable(struct regulator_dev *rdev)
> /* Avoid powering up multiple devices at the same time */
> usleep_range(rdev->desc->off_on_delay, rdev->desc->off_on_delay + 60);
>
> - mutex_unlock(&sreg->enable_mutex);
> + mutex_unlock(&priv->enable_mutex);
>
> return ret;
> }
> @@ -225,7 +228,7 @@ static int hi6421_spmi_regulator_probe(struct platform_device *pdev)
> {
> struct device *pmic_dev = pdev->dev.parent;
> struct regulator_config config = { };
> - struct hi6421_spmi_reg_info *sreg;
> + struct hi6421_spmi_reg_priv *priv;
> struct hi6421_spmi_reg_info *info;
> struct device *dev = &pdev->dev;
> struct hi6421_spmi_pmic *pmic;
> @@ -241,17 +244,18 @@ static int hi6421_spmi_regulator_probe(struct platform_device *pdev)
> if (WARN_ON(!pmic))
> return -ENODEV;
>
> - sreg = devm_kzalloc(dev, sizeof(*sreg), GFP_KERNEL);
> - if (!sreg)
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> return -ENOMEM;
>
> - mutex_init(&sreg->enable_mutex);
> + mutex_init(&priv->enable_mutex);
> + platform_set_drvdata(pdev, priv);
>
> for (i = 0; i < ARRAY_SIZE(regulator_info); i++) {
> info = ®ulator_info[i];
>
> config.dev = pdev->dev.parent;
This is the main problem of this patch. See, pdev->dev.parent is
actually the device's parent (e. g. the SPMI controller's device).
Looking at (devm_)regulator_register() implementation, it uses it to
store the rdev->dev.parent:
struct regulator_dev *
regulator_register(const struct regulator_desc *regulator_desc,
const struct regulator_config *cfg)
{
...
dev = cfg->dev;
...
rdev->dev.parent = dev;
So, while you used platform_set_drvdata() to set the data for the
regulator's platform driver, when the driver tries to access the
mutex, the code does, instead:
static int hi6421_spmi_regulator_enable(struct regulator_dev *rdev)
{
struct hi6421_spmi_reg_info *sreg = rdev_get_drvdata(rdev);
struct hi6421_spmi_reg_priv *priv;
int ret;
priv = dev_get_drvdata(rdev->dev.parent);
mutex_lock(&priv->enable_mutex);
At this point, priv will be set to the value of the SPMI controller
dev data, instead of pointing to the area stored via
platform_set_drvdata().
As the data stored there is not the enable_mutex, a call to
mutex_lock() makes the device to hang at boot time (or to cause some
other random issue, as it is using a different memory than what
it was expected).
Thanks,
Mauro
prev parent reply other threads:[~2021-06-30 6:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 4:33 [PATCH] regulator: hi6421v600: Fix setting wrong driver_data Axel Lin
2021-06-22 15:14 ` Mark Brown
2021-06-25 16:39 ` Mauro Carvalho Chehab
2021-06-26 0:48 ` Axel Lin
2021-06-30 6:54 ` Mauro Carvalho Chehab [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210630085416.4b3d9864@coco.lan \
--to=mchehab+huawei@kernel.org \
--cc=axel.lin@ingics.com \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox