From: Thierry Reding <thierry.reding@gmail.com>
To: Sven Van Asbroeck <thesven73@gmail.com>
Cc: "Clemens Gruber" <clemens.gruber@pqgruber.com>,
linux-pwm@vger.kernel.org,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Lee Jones" <lee.jones@linaro.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Mika Westerberg" <mika.westerberg@linux.intel.com>,
"David Jander" <david@protonic.nl>
Subject: Re: [PATCH v5 1/7] pwm: pca9685: Switch to atomic API
Date: Mon, 22 Mar 2021 08:58:35 +0100 [thread overview]
Message-ID: <YFhOK7YuOtTI+gfa@orome.fritz.box> (raw)
In-Reply-To: <CAGngYiW7vcJjz36xsBYx5n7=j1_5sE5a1AGpqC3Jj+tw0+FAXQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]
On Thu, Dec 17, 2020 at 12:10:10PM -0500, Sven Van Asbroeck wrote:
> On Thu, Dec 17, 2020 at 11:48 AM Clemens Gruber
> <clemens.gruber@pqgruber.com> wrote:
> >
> > I can initialize the values to 0 of course and check the file for other
> > places with missing initializations.
> >
> > Or would it be better to check the return codes of regmap_read/write in
> > such cases? I'm not sure.
>
> I think that checking the regmap_read/write return values is overkill
> in this driver. These functions can't realistically fail, except if the i2c
> bus is bad, i.e. h/w failure or intermittency. And that's an externality
> which I believe we can ignore.
I think there are (rare) occasions where it's fine to not check for
errors, i.e. if you definitively know that calls can't fail. However,
given that this uses regmap and you don't really know what's backing
this, I think it's always better to err on the side of caution and
properly check the return values.
The fact that this can be externally caused is actually a reason why
we shouldn't be ignoring any errors. If there's a chip that's hogging
the I2C bus or if you've even just mistyped the I2C client's address
in DT, it's better if the PWM driver tells you with an error message
than if it is silently ignoring the errors and keeps you guessing at
why the PWM isn't behaving the way it should.
Granted, the error code isn't always going to pinpoint exactly what's
going wrong, but for serious errors often the I2C bus driver will let
you know with an extra error message. However, it's much easier to go
looking for that error message if the PWM driver lets you know that
something went wrong.
Please just add full checking of regmap operations.
Thierry
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-03-22 7:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-15 21:22 [PATCH v5 1/7] pwm: pca9685: Switch to atomic API Clemens Gruber
2020-12-15 21:22 ` [PATCH v5 2/7] pwm: pca9685: Support hardware readout Clemens Gruber
2020-12-15 21:22 ` [PATCH v5 3/7] pwm: pca9685: Improve runtime PM behavior Clemens Gruber
2020-12-15 21:22 ` [PATCH v5 4/7] pwm: pca9685: Reset registers to POR state in probe Clemens Gruber
2020-12-17 4:02 ` Sven Van Asbroeck
2020-12-17 17:45 ` Clemens Gruber
2021-03-01 21:46 ` Uwe Kleine-König
2021-03-04 13:16 ` Clemens Gruber
2020-12-15 21:22 ` [PATCH v5 5/7] pwm: pca9685: Support staggered output ON times Clemens Gruber
2020-12-17 4:02 ` Sven Van Asbroeck
2020-12-17 17:50 ` Clemens Gruber
2020-12-15 21:22 ` [PATCH v5 6/7] dt-bindings: pwm: pca9685: Add nxp,staggered-outputs property Clemens Gruber
2020-12-15 21:22 ` [PATCH v5 7/7] pwm: pca9685: Restrict period change for prescaler users Clemens Gruber
2020-12-17 4:03 ` Sven Van Asbroeck
2020-12-17 18:07 ` Clemens Gruber
2020-12-17 18:17 ` Sven Van Asbroeck
2020-12-17 3:58 ` [PATCH v5 1/7] pwm: pca9685: Switch to atomic API Sven Van Asbroeck
2020-12-17 16:48 ` Clemens Gruber
2020-12-17 17:10 ` Sven Van Asbroeck
2021-03-01 21:41 ` Uwe Kleine-König
2021-03-04 13:10 ` Clemens Gruber
2021-03-22 7:58 ` Thierry Reding [this message]
2021-03-27 15:54 ` Clemens Gruber
2021-03-01 21:44 ` Uwe Kleine-König
2021-03-04 13:12 ` Clemens Gruber
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=YFhOK7YuOtTI+gfa@orome.fritz.box \
--to=thierry.reding@gmail.com \
--cc=clemens.gruber@pqgruber.com \
--cc=david@protonic.nl \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=thesven73@gmail.com \
--cc=u.kleine-koenig@pengutronix.de \
/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).