linux-kernel - Re: [PATCH v5 5/5] hwmon: Add support for Amphenol ChipCap 2

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 18 Jan 2024 13:49:55 +0000
From: Mark Brown <broonie@...nel.org>
To: Javier Carrasco <javier.carrasco.cruz@...il.com>
Cc: Rob Herring <robh+dt@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Jean Delvare <jdelvare@...e.com>,
	Guenter Roeck <linux@...ck-us.net>,
	Jonathan Corbet <corbet@....net>,
	Liam Girdwood <lgirdwood@...il.com>, Rob Herring <robh@...nel.org>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-hwmon@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH v5 5/5] hwmon: Add support for Amphenol ChipCap 2

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.

> +	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.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)