From: Mark Brown <broonie@kernel.org>
To: Alistair Francis <alistair@alistair23.me>
Cc: lee.jones@linaro.org, robh+dt@kernel.org, lgirdwood@gmail.com,
linux-imx@nxp.com, kernel@pengutronix.de,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
alistair23@gmail.com
Subject: Re: [PATCH v4 3/5] regulator: sy7636a: Initial commit
Date: Tue, 30 Mar 2021 20:05:18 +0100 [thread overview]
Message-ID: <20210330190518.GL4976@sirena.org.uk> (raw)
In-Reply-To: <20210326015511.218-3-alistair@alistair23.me>
[-- Attachment #1: Type: text/plain, Size: 3465 bytes --]
On Thu, Mar 25, 2021 at 09:55:09PM -0400, Alistair Francis wrote:
> Initial support for the Silergy SY7636A-regulator Power Management chip.
In general this driver seems like it's trying to implement a bunch of
policy and extra features beyond standard regulator support - please
strip it back more, if you feel that there's things that really do need
to be added in the driver itself post them as separate patches. It's
also open coding some features the core provides. This should all make
the driver much smaller and simpler.
> +++ b/Documentation/ABI/testing/sysfs-driver-sy7636a-regulator
> @@ -0,0 +1,21 @@
> +What: /sys/bus/regulator/drivers/sy7636a-regulator/state
> +Date: April 2021
> +KernelVersion: 5.12
None of these sysfs files are appropriate for a driver, if they are
useful they should be added to the core (but some of them seem like
they duplicate files that already exist, this one being an example).
There's absolutely nothing device specific about any of them.
> +static int sy7636a_disable_regulator(struct regulator_dev *rdev)
> +{
> + int ret = 0;
> +
> + ret = regulator_disable_regmap(rdev);
> + // Delay for ~35ms after disabling the regulator, to allow power ramp
> + // down to go undisturbed
> + usleep_range(30000, 35000);
If this is needed add it to the core, but really this sort of stuff is
going to be very board specific - it'll depend on what the load on the
regulator is - and it's pretty rare for anything to care, you don't have
the same issues you have on enable.
> +static int sy7636a_regulator_is_enabled(struct regulator_dev *rdev)
> +{
> + return regulator_is_enabled_regmap(rdev);
> +}
Just use the generic operation, this wrapper is not adding anything
except code size.
> +static int sy7636a_get_status(struct regulator_dev *rdev)
> +{
> + struct sy7636a *sy7636a = dev_get_drvdata(rdev->dev.parent);
> + int pwr_good = 0;
> + const unsigned int wait_time = 500;
> + unsigned int wait_cnt;
> + int ret = 0;
> +
> + for (wait_cnt = 0; wait_cnt < wait_time; wait_cnt++) {
> + pwr_good = gpiod_get_value_cansleep(sy7636a->pgood_gpio);
> + if (pwr_good < 0) {
> + dev_err(&rdev->dev, "Failed to read pgood gpio: %d\n", pwr_good);
> + ret = pwr_good;
> + return ret;
> + } else if (pwr_good)
> + break;
This should just read the status, if the caller wants to retry for a
while then the caller can make that decision.
> + ret = regulator_enable_regmap(rdev);
> + if (ret)
> + goto finish;
> +
> + for (wait_cnt = 0; wait_cnt < wait_time; wait_cnt++) {
> + pwr_good = gpiod_get_value_cansleep(sy7636a->pgood_gpio);
> + if (pwr_good < 0) {
> + dev_err(&rdev->dev, "Failed to read pgood gpio: %d\n", pwr_good);
Use poll_enabled_time to check the status, no need for a custom enable
operation.
> + ret = pwr_good;
> + goto finish;
> + } else if (pwr_good)
> + break;
As per coding-style.rst both sides of the if statement should use braces
if one does.
> + ret = sysfs_create_group(&rdev->dev.kobj, &sy7636a_sysfs_attr_group);
> + if (ret) {
> + dev_err(sy7636a->dev, "Failed to create sysfs attributes\n");
> + return ret;
> + }
*If* the driver is creating sysfs devices it *definitely* shouldn't be
creating and destroying them dynamically at runtime.
> + ret = sy7636a_regulator_init(sy7636a);
> + if (ret) {
> + dev_err(sy7636a->dev, "Failed to initialize regulator: %d\n", ret);
> + return ret;
> + }
This function has one caller and one statement in it, just inline it.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2021-03-30 19:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-26 1:55 [PATCH v4 1/5] dt-bindings: mfd: Initial commit of silergy,sy7636a.yaml Alistair Francis
2021-03-26 1:55 ` [PATCH v4 2/5] mfd: sy7636a: Initial commit Alistair Francis
2021-03-30 19:08 ` Mark Brown
2021-03-26 1:55 ` [PATCH v4 3/5] regulator: " Alistair Francis
2021-03-30 19:05 ` Mark Brown [this message]
2021-03-26 1:55 ` [PATCH v4 4/5] ARM: imx_v6_v7_defconfig: Enable silergy,sy7636a Alistair Francis
2021-03-26 1:55 ` [PATCH v4 5/5] ARM: dts: imx7d: remarkable2: " Alistair Francis
2021-03-27 15:14 ` [PATCH v4 1/5] dt-bindings: mfd: 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=20210330190518.GL4976@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alistair23@gmail.com \
--cc=alistair@alistair23.me \
--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