From: Jonathan Cameron <jic23@kernel.org>
To: Nuno Sa <nuno.sa@analog.com>
Cc: <linux-iio@vger.kernel.org>, <devicetree@vger.kernel.org>,
Lars-Peter Clausen <lars@metafoo.de>,
Michael Hennerich <Michael.Hennerich@analog.com>,
Rob Herring <robh+dt@kernel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
Conor Dooley <conor+dt@kernel.org>
Subject: Re: [PATCH 3/6] iio: temperature: ltc2983: convert to dev_err_probe()
Date: Sat, 24 Feb 2024 18:44:01 +0000 [thread overview]
Message-ID: <20240224184341.791e5263@jic23-huawei> (raw)
In-Reply-To: <20240222-ltc2983-misc-improv-v1-3-cf7d4457e98c@analog.com>
On Thu, 22 Feb 2024 13:55:54 +0100
Nuno Sa <nuno.sa@analog.com> wrote:
> Use dev_err_probe() in the probe() path. While at it, made some simple
> improvements:
> * Declare a struct device *dev helper. This also makes the style more
> consistent (some places the helper was used and not in other places);
> * Explicitly included the err.h and errno.h headers;
> * Removed an useless else if().
>
> Signed-off-by: Nuno Sa <nuno.sa@analog.com>
Hmm. Up to you whether you rebase on top of the device_for_each_child_node_scoped()
patch - mostly depends if you give the new version a reviewed by or not!
If they land in the other order I can fix it up whilst applying.
After that series is in place though the number of places this will do
dev_err_probe(dev, ret, "message\n");
return ERR_PTR(ret);
Makes me wonder whether
return ERR_PTR(dev_err_probe(dev, ret, "message\n")); is
too ugly or not?
Maybe we need a dev_err_probe_ret_ptr() but that's also ugly.
One comment inline which is why I didn't just pick this up today and send
a new version of this patch in my series.
Jonathan
> ---
> drivers/iio/temperature/ltc2983.c | 190 ++++++++++++++++++++------------------
> 1 file changed, 98 insertions(+), 92 deletions(-)
>
> diff --git a/drivers/iio/temperature/ltc2983.c b/drivers/iio/temperature/ltc2983.c
> index 23f2d43fc040..4b096aa3fbd8 100644
> --- a/drivers/iio/temperature/ltc2983.c
> +++ b/drivers/iio/temperature/ltc2983.c
> @@ -8,6 +8,8 @@
> #include <linux/bitfield.h>
> #include <linux/completion.h>
> #include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/errno.h>
> #include <linux/kernel.h>
> #include <linux/iio/iio.h>
> #include <linux/interrupt.h>
> @@ -656,11 +658,12 @@ ltc2983_thermocouple_new(const struct fwnode_handle *child, struct ltc2983_data
> const struct ltc2983_sensor *sensor)
> {
> struct ltc2983_thermocouple *thermo;
> + struct device *dev = &st->spi->dev;
> struct fwnode_handle *ref;
> u32 oc_current;
> int ret;
>
> - thermo = devm_kzalloc(&st->spi->dev, sizeof(*thermo), GFP_KERNEL);
> + thermo = devm_kzalloc(dev, sizeof(*thermo), GFP_KERNEL);
> if (!thermo)
> return ERR_PTR(-ENOMEM);
>
> @@ -687,8 +690,9 @@ ltc2983_thermocouple_new(const struct fwnode_handle *child, struct ltc2983_data
> LTC2983_THERMOCOUPLE_OC_CURR(3);
> break;
> default:
> - dev_err(&st->spi->dev,
> - "Invalid open circuit current:%u", oc_current);
> + dev_err_probe(dev, -EINVAL,
> + "Invalid open circuit current:%u",
> + oc_current);
Hmm. I'm in two minds on these.
We don't get the advantage of return dev_error_probe() and I'm not seeing these
hitting EPROBE_DEFER so getting the debug advantages.
> return ERR_PTR(-EINVAL);
> }
next prev parent reply other threads:[~2024-02-24 18:44 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 12:55 [PATCH 0/6] iio: temperature: ltc2983: small improvements Nuno Sa
2024-02-22 12:55 ` [PATCH 1/6] iio: temperature: ltc2983: make use of spi_get_device_match_data() Nuno Sa
2024-02-24 18:31 ` Jonathan Cameron
2024-02-22 12:55 ` [PATCH 2/6] iio: temperature: ltc2983: rename ltc2983_parse_dt() Nuno Sa
2024-02-24 18:32 ` Jonathan Cameron
2024-02-22 12:55 ` [PATCH 3/6] iio: temperature: ltc2983: convert to dev_err_probe() Nuno Sa
2024-02-24 18:44 ` Jonathan Cameron [this message]
2024-02-26 8:41 ` Nuno Sá
2024-02-22 12:55 ` [PATCH 4/6] iio: temperature: ltc2983: explicitly set the name in chip_info Nuno Sa
2024-02-24 18:47 ` Jonathan Cameron
2024-02-22 12:55 ` [PATCH 5/6] dt-bindings: iio: temperature: ltc2983: document power supply Nuno Sa
2024-02-22 15:40 ` Conor Dooley
2024-02-22 16:41 ` Nuno Sá
2024-02-22 17:54 ` Conor Dooley
2024-02-22 19:15 ` Jonathan Cameron
2024-02-23 8:17 ` Nuno Sá
2024-02-23 18:43 ` Conor Dooley
2024-02-22 12:55 ` [PATCH 6/6] iio: temperature: ltc2983: support vdd regulator Nuno Sa
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=20240224184341.791e5263@jic23-huawei \
--to=jic23@kernel.org \
--cc=Michael.Hennerich@analog.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=nuno.sa@analog.com \
--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