linux-kernel - Re: [PATCH v3 3/4] regulator: core: Parse coupled regulators properties

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, 12 Dec 2017 11:35:11 +0000
From:   Mark Brown <broonie@...nel.org>
To:     Maciej Purski <m.purski@...sung.com>
Cc:     linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
        Liam Girdwood <lgirdwood@...il.com>,
        Rob Herring <robh+dt@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Marek Szyprowski <m.szyprowski@...sung.com>,
        Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
Subject: Re: [PATCH v3 3/4] regulator: core: Parse coupled regulators
 properties

On Thu, Dec 07, 2017 at 10:46:14AM +0100, Maciej Purski wrote:

> +static int check_coupled_regulators_array(struct coupling_desc *c_desc,
> +					  int index)
> +{

> +	/* Different number of regulators coupled */
> +	if (of_count_phandle_with_args(node, "regulator-coupled-with", 0) !=
> +				      (n_coupled - 1))
> +		return -EINVAL;

This is still DT only code in the core file, we really need the core to
not know anything about DT so that we know that we can support this
feature with other firmwares if we need to.  Just move all the parsing
code into the of_regulator.c then have a second step that goes through
and validates extra stuff like the presence of set voltage operations in
the generic code.

> +		if (c_desc->coupled_rdevs[i]->constraints->max_spread !=
> +		    rdev->constraints->max_spread) {
> +			rdev_err(rdev, "coupled regulators max_spread mismatch\n");
> +			goto err;
> +		}

It's better to print out failing values when things go wrong - it really
helps people debug their DTs if the error messages are specific about
what went wrong.  This applies to a bunch of the errors here.

> +	mutex_lock(&regulator_list_mutex);
> +	regulator_resolve_coupling(rdev);
> +	mutex_unlock(&regulator_list_mutex);
> +

I'd really expect us to be failing to probe if we run into an error.
Otherwise we could end up doing bad things to the hardware at runtime
later on, or confusing ourselves and crashing with partially set up
datastructures.  It's also not 100% clear to me how we handle the case
where only some of the coupled regulators have probed.

> diff --git a/drivers/regulator/internal.h b/drivers/regulator/internal.h
> index 2f3218b..6290384 100644
> --- a/drivers/regulator/internal.h
> +++ b/drivers/regulator/internal.h
> @@ -16,6 +16,8 @@
>  #ifndef __REGULATOR_INTERNAL_H
>  #define __REGULATOR_INTERNAL_H
>  
> +#include <linux/regulator/driver.h>
> +

Why do we need this?

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