Messages in this thread | | | Date | Thu, 18 Jan 2024 16:04:20 +0000 | From | Mark Brown <> | Subject | Re: [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] | |