From: "Nuno Sá" <noname.nuno@gmail.com>
To: Andi Shyti <andi.shyti@kernel.org>, Jonathan Cameron <jic23@kernel.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
Nuno Sa <nuno.sa@analog.com>, Petr Mladek <pmladek@suse.com>,
Lars-Peter Clausen <lars@metafoo.de>,
Olivier Moysan <olivier.moysan@foss.st.com>,
Jyoti Bhayana <jbhayana@google.com>,
Chris Down <chris@chrisdown.name>,
John Ogness <john.ogness@linutronix.de>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kernel.org, linux-iio@vger.kernel.org
Subject: Re: [PATCH 3/4] iio: backend: make use of dev_errp_probe()
Date: Mon, 08 Apr 2024 11:05:39 +0200 [thread overview]
Message-ID: <5264b2cddd5d3cbba5e9d5e55f8c7069347ec38b.camel@gmail.com> (raw)
In-Reply-To: <7ejh2r6zcripnptn3nbw2sa3mlfyleg4qg74rryxlut3fysneg@kuqwo5z2l65n>
On Sat, 2024-04-06 at 20:54 +0200, Andi Shyti wrote:
> Hi,
>
> On Sat, Apr 06, 2024 at 05:07:17PM +0100, Jonathan Cameron wrote:
> > On Thu, 4 Apr 2024 18:12:25 +0300
> > Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> >
> > > On Thu, Apr 04, 2024 at 04:58:27PM +0200, Nuno Sá wrote:
> > > > On Thu, 2024-04-04 at 15:23 +0300, Andy Shevchenko wrote:
> > > > > On Thu, Apr 04, 2024 at 01:06:25PM +0200, Nuno Sa wrote:
> > > > > > Using dev_errp_probe() to simplify the code.
> > >
> > > ...
> > >
> > > > > > + if (IS_ERR(fwnode))
> > > > > > + return dev_errp_probe(dev, PTR_ERR(fwnode),
> > > > > > + "Cannot get Firmware
> > > > > > reference\n");
> > > > >
> > > > > ERR_CAST() seems quite good candidate to have here.
> > > > >
> > > > > return dev_errp_probe(dev, fwnode, "Cannot get
> > > > > Firmware
> > > > > reference\n");
> > > > >
> > > > > (Assuming dev_errp_probe() magically understands that, note you may
> > > > > have it as
> > > > > a macro and distinguish parameter type with _Generic() or so and
> > > > > behave
> > > > > differently: ERR_PTR() vs. ERR_CAST(), see acpi_dev_hid_uid_match()
> > > > > implementation, but also keep in mind that it doesn't distinguish
> > > > > NULL/0,
> > > > > there
> > > > > is a patch available in the mailing list to fix that, though.)
> > > >
> > > > Do we care that much for going with that trouble?
> > >
> > > I don't think we do. We are not supposed to be called with ret == 0/NULL.
> > > That's why I pointed out to the current version.
> > >
> > > > I understand like this we go
> > > > PTR_ERR() to then comeback to ERR_PTR() but this for probe() which is
> > > > not a
> > > > fastpath. So perhaps we could just keep it simple?
> > >
> > > It's not about performance, it's about readability. See the difference
> > > between
> > > yours and mine.
> > >
> >
> > You are suggesting making it transparently take an error ptr or an integer?
> > Whilst clever, I'm not seeing that as a good idea for readability /
> > reviewability.
> > I expect something that looks like a function to take the same parameters
> > (other vargs)
> > always. _Generic messes with that.
> >
> > Maybe I just don't like to learn new things! If consensus comes down in
> > favour
> > of _Generic trickery then I'll get used to it eventually.
>
> the whole point of the dev_err_...() functions is to add trickery
> in order to reduce code and brackets.
>
I'm not sure I'm completely convinced on having more helpers but also no strong
opinion tbh. But see below...
> The way I see this is to have a combination of functions:
>
> - takes integer, returns integer -> dev_err_probe()
> - takes integer, returns pointer -> dev_errp_probe() (or dev_err_ptr_probe())
> - takes pointer, return integer -> ? dev_ptr_err_probe()
This is pretty much all the dev_err_probe(dev, PTR_ERR(), ...) we already have
out there. Do we really want to have this variant?
> - takes pointer, returns pointer -> ? dev_ptr_probe()
dev_ptr_probe() misses to be clear about being an error and think this is pretty
much the ERR_CAST() case right? Maybe dev_err_cast_ptr_probe()? Or
dev_err_cast_probe()?
- Nuno Sá
next prev parent reply other threads:[~2024-04-08 9:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 11:06 [PATCH 0/4] dev_printk: add dev_errp_probe() helper Nuno Sa
2024-04-04 11:06 ` [PATCH 1/4] dev_printk: add new " Nuno Sa
2024-04-06 18:35 ` Andi Shyti
2024-04-08 8:57 ` Nuno Sá
2024-04-04 11:06 ` [PATCH 2/4] iio: temperature: ltc2983: convert to dev_err_probe() Nuno Sa
2024-04-04 12:18 ` Andy Shevchenko
2024-04-06 18:38 ` Andi Shyti
2024-04-04 11:06 ` [PATCH 3/4] iio: backend: make use of dev_errp_probe() Nuno Sa
2024-04-04 12:23 ` Andy Shevchenko
2024-04-04 14:58 ` Nuno Sá
2024-04-04 15:12 ` Andy Shevchenko
2024-04-06 16:07 ` Jonathan Cameron
2024-04-06 18:54 ` Andi Shyti
2024-04-08 9:05 ` Nuno Sá [this message]
2024-04-08 9:01 ` Nuno Sá
2024-04-04 11:06 ` [PATCH 4/4] iio: common: scmi_iio: convert to dev_err_probe() Nuno Sa
2024-04-04 12:15 ` [PATCH 0/4] dev_printk: add dev_errp_probe() helper Andy Shevchenko
2024-04-04 12:18 ` Andy Shevchenko
2024-04-04 15:03 ` Nuno Sá
2024-04-04 15:15 ` 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=5264b2cddd5d3cbba5e9d5e55f8c7069347ec38b.camel@gmail.com \
--to=noname.nuno@gmail.com \
--cc=andi.shyti@kernel.org \
--cc=andriy.shevchenko@linux.intel.com \
--cc=chris@chrisdown.name \
--cc=gregkh@linuxfoundation.org \
--cc=jbhayana@google.com \
--cc=jic23@kernel.org \
--cc=john.ogness@linutronix.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nuno.sa@analog.com \
--cc=olivier.moysan@foss.st.com \
--cc=pmladek@suse.com \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).