From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: linux-hwmon@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org,
"Carsten Spieß" <mail@carsten-spiess.de>,
"Guenter Roeck" <linux@roeck-us.net>,
"Geert Uytterhoeven" <geert+renesas@glider.be>,
"Magnus Damm" <magnus.damm@gmail.com>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>
Subject: Re: [PATCH v1 1/1] hwmon: (isl28022) Don't check for specific errors when parsing properties
Date: Thu, 19 Feb 2026 16:30:53 +0200 [thread overview]
Message-ID: <aZcenabXYsOdBu84@smile.fi.intel.com> (raw)
In-Reply-To: <CAMuHMdX9CdQNBGegrfHz+-UpuyO-rmHEQ2HUa=JjVpG_0ryacg@mail.gmail.com>
On Thu, Feb 19, 2026 at 03:21:29PM +0100, Geert Uytterhoeven wrote:
> On Thu, 19 Feb 2026 at 15:06, Andy Shevchenko
> <andriy.shevchenko@linux.intel.com> wrote:
> > Instead of checking for the specific error codes (that can be considered
> > a layering violation to some extent) check for the property existence first
> > and then either parse it, or apply a default value.
> IIRC, we have removed superfluous presence checks all over the tree
> during the past few years? E.g. of_property_read_*() is documented to
> return -EINVAL if a property does not exist.
Even though, it's still fragile. When we have a check for explicit device
presence, we wouldn't care of the error code we get in case of unsuccessful
parsing.
> So this patch looks like a step back to me...
Obviously I have a disagreement here, this is step forward to weaken
the dependency on the certain error code in the cases when we can avoid
that. Motivation is mentioned in the commit message.
Also note, -EINVAL can sneak in tons of mysterious ways as it's one of
the most overloaded error code in the kernel, its semantic is basically
equals to "an error happened".
Having the code above, we make it robust against some subtle nuances which
may not be discovered in time.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2026-02-19 14:30 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260219140532.2259235-1-andriy.shevchenko@linux.intel.com>
2026-02-19 14:21 ` [PATCH v1 1/1] hwmon: (isl28022) Don't check for specific errors when parsing properties Geert Uytterhoeven
2026-02-19 14:30 ` Andy Shevchenko [this message]
2026-02-20 20:49 ` Guenter Roeck
2026-03-17 20:51 ` Andy Shevchenko
2026-03-17 21:09 ` Andy Shevchenko
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=aZcenabXYsOdBu84@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=devicetree@vger.kernel.org \
--cc=geert+renesas@glider.be \
--cc=geert@linux-m68k.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=magnus.damm@gmail.com \
--cc=mail@carsten-spiess.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