linux-kernel - Re: [PATCH] regulator: core bugfix: Use normal enable for always

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: Windows password security audit tool. GUI, reports in PDF.

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

Date:	Tue, 18 Feb 2014 09:14:20 +0900
From:	Mark Brown <broonie@...nel.org>
To:	Markus Pargmann <mpa@...gutronix.de>
Cc:	Liam Girdwood <lgirdwood@...il.com>, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org, kernel@...gutronix.de,
	stable@...r.kernel.org
Subject: Re: [PATCH] regulator: core bugfix: Use normal enable for always_on
 regulators

On Sun, Feb 16, 2014 at 08:00:56PM +0100, Markus Pargmann wrote:

Please use more standard subject lines, don't do things like "core
bugfix", just write a normal changelog.

> +static int _regulator_do_enable_no_delay(struct regulator_dev *rdev)
> +{
> +	int ret;
> +
> +	if (rdev->ena_pin) {
> +		ret = regulator_ena_gpio_ctrl(rdev, true);
> +		if (ret < 0)
> +			return ret;
> +		rdev->ena_gpio_state = 1;
> +	} else if (rdev->desc->ops->enable) {
> +		ret = rdev->desc->ops->enable(rdev);
> +	} else {
> +		ret = -EINVAL;
> +	}
> +
> +	return ret;
> +}

I don't understand this.  Why is this called _no_delay() and why don't
we want to delay when applying constraints?  We don't want to ever be in
a position where we think a supply is enabled but it has in fact not
finished ramping, and of course enable() may in fact be blocking anyway.

The use of the common code to do enable is good fix but this just seems
odd.

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