lkml.org 
[lkml]   [2024]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 5/5] hwmon: Add support for Amphenol ChipCap 2
On Thu, Jan 18, 2024 at 04:30:37PM +0100, Javier Carrasco wrote:
> On 18.01.24 14:49, Mark Brown wrote:
> > On Mon, Jan 15, 2024 at 09:02:25PM +0100, Javier Carrasco wrote:

> >> +static int cc2_enable(struct cc2_data *data)
> >> +{
> >> + int ret;

> >> + if (regulator_is_enabled(data->regulator))
> >> + return 0;

> > This is generally a sign that the regulator API usage is not good, the
> > driver should not rely on references to the regulator held by anything
> > else since whatever else is holding the regulator on could turn it off
> > at any time. If the driver did the enable itself then it should know
> > that it did so and not need to query.

> The driver handles a dedicated regulator, but I wanted to account for
> the cases where the attempts to enable and disable the regulator fail
> and keep parity. If the disabling attempt fails, will the regulator not
> stay enabled? In that case, an additional call to regulator_enable would
> not be required, right?
> That is the only reason I am using regulator_is_enabled(), but maybe
> things don't work like that.

With exclusive use you can get away with this, you should have a comment
for that case though.

> >> + ret = regulator_enable(data->regulator);
> >> + if (ret < 0)
> >> + return ret;
> >> +
> >> + /*
> >> + * TODO: the startup-delay-us property of the regulator might be
> >> + * added to the delay (if provided).
> >> + * Currently there is no interface to read its value apart from
> >> + * a direct access to regulator->rdev->constraints->enable_time,
> >> + * which is discouraged like any direct access to the regulator_dev
> >> + * structure. This would be relevant in cases where the startup delay
> >> + * is in the range of milliseconds.
> >> + */
> >> + usleep_range(CC2_STARTUP_TIME_US, CC2_STARTUP_TIME_US + 125);

> > Note that the regulator startup delay is the time taken for the
> > regulator to power up so if the device needs additional delay then that
> > will always need to be in addition to whatever the regulator is doing.

> What I mean by that is that the device cannot be ready until the
> regulator powers it up (obvious) plus the start up time of the device
> itself once it gets powered up. So if a regulator takes for example 1 ms
> to power up, the sleep function could (and should) wait for 1 ms longer.

No, the sleep function should do nothing of the sort - if any delay is
neeeded for the regulator it will be handled as part of enabling the
regulator. This is not exposed to client drivers because it is
transparent to them.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2024-01-18 17:04    [W:0.040 / U:2.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site