From: Alistair Francis <alistair23@gmail.com>
To: Mark Brown <broonie@kernel.org>
Cc: Alistair Francis <alistair@alistair23.me>,
lee.jones@linaro.org, Rob Herring <robh+dt@kernel.org>,
lgirdwood@gmail.com, dl-linux-imx <linux-imx@nxp.com>,
Sascha Hauer <kernel@pengutronix.de>,
devicetree <devicetree@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 4/6] regulator: Initial commit of sy7636a
Date: Thu, 21 Jan 2021 22:24:10 -0800 [thread overview]
Message-ID: <CAKmqyKMyXk_OjTKD24Qxn4QXJ4FwP4yDQqtmTsxAJMJzy34PcA@mail.gmail.com> (raw)
In-Reply-To: <20210118123158.GE4455@sirena.org.uk>
On Mon, Jan 18, 2021 at 4:32 AM Mark Brown <broonie@kernel.org> wrote:
>
> On Sat, Jan 16, 2021 at 08:25:37PM -0800, Alistair Francis wrote:
>
> > --- /dev/null
> > +++ b/drivers/regulator/sy7636a-regulator.c
> > @@ -0,0 +1,233 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Functions to access SY3686A power management chip voltages
> > + *
>
> Please make the entire comment a C++ one so things look more
> intentional.
Fixed.
>
> > + * Copyright (C) 2019 reMarkable AS - http://www.remarkable.com/
> > + *
> > + * Author: Lars Ivar Miljeteig <lars.ivar.miljeteig@remarkable.com>
>
> This probably needs an update.
>
> > + * This program is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU General Public License as
> > + * published by the Free Software Foundation version 2.
> > + *
> > + * This program is distributed "as is" WITHOUT ANY WARRANTY of any
> > + * kind, whether express or implied; without even the implied warranty
> > + * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> > + * GNU General Public License for more details.
>
> This boilerplate is redundant and should be removed.
Fixed.
>
> > +static int get_vcom_voltage_op(struct regulator_dev *rdev)
> > +{
> > + int ret = get_vcom_voltage_mv(rdev->regmap);
> > +
>
> Why is this get_vcom_voltage_mv() function not in the regulator driver,
> and why is it not just inline here? It also needs namespacing.
I'm not sure what you mean, can you please explain?
>
> > +static int disable_regulator(struct regulator_dev *rdev)
> > +{
> > + struct sy7636a *sy7636a = dev_get_drvdata(rdev->dev.parent);
> > + int ret = 0;
> > +
> > + mutex_lock(&sy7636a->reglock);
> > + ret = regulator_disable_regmap(rdev);
> > + usleep_range(30000, 35000);
> > + mutex_unlock(&sy7636a->reglock);
>
> Why do you need this delay here, and what purpose is this lock intended
The delay is to allow a power ramp up, I have added a comment.
> to serve? I can't understand what it's intended to protect.
Apparently the mutex is to protect enable/disable, I don't think it's
required and I will remove it.
>
> > + mutex_lock(&sy7636a->reglock);
> > + ret = regulator_is_enabled_regmap(rdev);
> > + mutex_unlock(&sy7636a->reglock);
>
> This lock usage in particular looks confused.
>
> > + ret = regulator_enable_regmap(rdev);
> > + if (ret)
> > + goto finish;
>
> > + if (!pwr_good) {
> > + dev_err(&rdev->dev, "Power good signal timeout after %u ms\n",
> > + jiffies_to_msecs(t1 - t0));
> > + ret = -ETIME;
> > + goto finish;
> > + }
>
> This doesn't undo the underlying enable, leaving the regulator in a
> partially enabled state.
Thanks, fixed.
>
> > +static const struct regulator_ops sy7636a_vcom_volt_ops = {
> > + .get_voltage = get_vcom_voltage_op,
> > + .enable = enable_regulator_pgood,
> > + .disable = disable_regulator,
> > + .is_enabled = sy7636a_regulator_is_enabled,
> > +};
>
> The namespacing for functions is very random and prone to clashes.
Fixed.
> Given the power good signal I'd also expect a get_status() operation.
Added.
>
> > +static int sy7636a_regulator_suspend(struct device *dev)
> > +{
> > + int ret;
> > + struct sy7636a *sy7636a = dev_get_drvdata(dev->parent);
> > +
> > + ret = get_vcom_voltage_mv(sy7636a->regmap);
> > +
> > + if (ret > 0)
> > + sy7636a->vcom = (unsigned int)ret;
> > +
> > + return 0;
> > +}
>
> What's going on here, and if you are going to store this value over
> suspend why not store it in a variable of the correct type? In general
It is part of the vendor's kernel, they specifically added it to
ensure vcom is set on resume.
I have fixed the variable type.
> it's surprising to need a suspend operation for a regulator.
>
> > + sy7636a->pgood_gpio = gdp;
> > + dev_info(sy7636a->dev,
> > + "Power good GPIO registered (gpio# %d)\n",
> > + desc_to_gpio(sy7636a->pgood_gpio));
>
> This print is just adding noise to the boot process.
Removed.
Alistair
next prev parent reply other threads:[~2021-01-22 6:28 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-17 4:25 [PATCH 1/6] devicetree/bindings: Initial commit of silergy,sy7636a.yaml Alistair Francis
2021-01-17 4:25 ` [PATCH 2/6] mfd: Initial commit of sy7636a Alistair Francis
2021-02-04 10:31 ` Lee Jones
2021-03-21 2:18 ` Alistair Francis
2021-03-23 9:35 ` Lee Jones
2021-03-25 13:49 ` Alistair Francis
2021-01-17 4:25 ` [PATCH 3/6] devicetree/bindings: Initial commit of silergy,sy7636a-regulator.yaml Alistair Francis
2021-01-18 12:35 ` Mark Brown
2021-01-18 12:42 ` Mark Brown
2021-01-22 5:05 ` Alistair Francis
2021-01-18 15:47 ` Rob Herring
2021-01-17 4:25 ` [PATCH 4/6] regulator: Initial commit of sy7636a Alistair Francis
2021-01-18 12:31 ` Mark Brown
2021-01-22 6:24 ` Alistair Francis [this message]
2021-01-22 13:37 ` Mark Brown
2021-01-23 8:34 ` Alistair Francis
2021-01-17 4:25 ` [PATCH 5/6] arch/arm: reMarkable2: Enable silergy,sy7636a Alistair Francis
2021-01-17 4:25 ` [PATCH 6/6] arch/arm: reMarkable2: Enable lcdif Alistair Francis
2021-01-18 15:47 ` [PATCH 1/6] devicetree/bindings: Initial commit of silergy,sy7636a.yaml Rob Herring
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=CAKmqyKMyXk_OjTKD24Qxn4QXJ4FwP4yDQqtmTsxAJMJzy34PcA@mail.gmail.com \
--to=alistair23@gmail.com \
--cc=alistair@alistair23.me \
--cc=broonie@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=kernel@pengutronix.de \
--cc=lee.jones@linaro.org \
--cc=lgirdwood@gmail.com \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=robh+dt@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;
as well as URLs for NNTP newsgroup(s).