[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMknhBGAL4m5RtQsLCOiSUofAGw89R2We9MDMzfvaT=5o-4M8Q@mail.gmail.com>
Date: Thu, 28 Mar 2024 10:54:50 -0500
From: David Lechner <dlechner@...libre.com>
To: Jonathan Cameron <jic23@...nel.org>
Cc: Jonathan Corbet <corbet@....net>, Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
Jean Delvare <jdelvare@...e.com>, Guenter Roeck <linux@...ck-us.net>,
Support Opensource <support.opensource@...semi.com>,
Cosmin Tanislav <cosmin.tanislav@...log.com>, Lars-Peter Clausen <lars@...afoo.de>,
Michael Hennerich <Michael.Hennerich@...log.com>, Antoniu Miclaus <antoniu.miclaus@...log.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Dmitry Torokhov <dmitry.torokhov@...il.com>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-hwmon@...r.kernel.org, linux-iio@...r.kernel.org,
linux-staging@...ts.linux.dev, linux-input@...r.kernel.org
Subject: Re: [PATCH RFC 1/7] regulator: devres: add APIs for reference supplies
On Thu, Mar 28, 2024 at 8:48 AM Jonathan Cameron <jic23@...nel.org> wrote:
>
> On Wed, 27 Mar 2024 18:18:50 -0500
> David Lechner <dlechner@...libre.com> wrote:
>
> > A common use case for regulators is to supply a reference voltage to an
> > analog input or output device. This adds two new devres APIs to get,
> > enable, and get the voltage in a single call. This allows eliminating
> > boilerplate code in drivers that use reference supplies in this way.
> >
> > devm_regulator_get_enable_get_voltage() is intended for cases where the
> Maybe avoid the double get?
> devm_regulator_get_enable_read_voltage() perhaps?
ok with me
>
> > supply is required to provide an external reference voltage.
> >
> > devm_regulator_get_optional_enable_get_voltage() is intended for cases
> > where the supply is optional and device typically uses an internal
> > reference voltage if the supply is not available.
> >
> > Signed-off-by: David Lechner <dlechner@...libre.com>
>
> In general I'll find this very useful (there are 50+ incidence
I didn't find quite that many. Still close to 40 though.
> of the pattern this can replace in IIO).
> I would keep it more similar to other devm regulator related functions
> and not do error printing internally though.
I did this because it seems like we could be losing potentially losing
useful information when something goes wrong making it harder to
troubleshoot which function actually failed. But looking into it more,
the regulator functions already print errors for many of the error
paths, so printing more errors does seem a bit redundant. So I will
remove the dev_error_probe() in v2.
Powered by blists - more mailing lists