linux-kernel - Re: [PATCH] regulator: bd718x7: Remove double indirection for bd718xx_pmic

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] [day] [month] [year] [list]

Message-ID: <20181029083025.GA20774@localhost.localdomain>
Date:   Mon, 29 Oct 2018 10:30:25 +0200
From:   Matti Vaittinen <matti.vaittinen@...rohmeurope.com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Liam Girdwood <lgirdwood@...il.com>,
        Mark Brown <broonie@...nel.org>, Arnd Bergmann <arnd@...db.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] regulator: bd718x7: Remove double indirection for
 bd718xx_pmic_inits.rdatas


On Sun, Oct 28, 2018 at 05:09:22PM +0100, Geert Uytterhoeven wrote:
> With gcc 4.1:
> 
>     drivers/regulator/bd718x7-regulator.c: In function ‘bd718xx_probe’:
>     drivers/regulator/bd718x7-regulator.c:1020: warning: initialization from incompatible pointer type
>     drivers/regulator/bd718x7-regulator.c:1024: warning: initialization from incompatible pointer type
> 
> Apparently this old compiler can't handle the obscure double
> indirection.

That was surprizing for me. Besides I don't see why this is obscure ;)

> However, there is no need for a double indirection.  Just store a
> pointer to the array instead, like other drivers tend to do.

But that's _exactly_ what we have here. A pointer to an array of
structs, not pointer to a struct - or pointer to the first member of an
array =)

But this is one of the cases where practicality should be preferred. And
you are correct. It is easier to understand when we have simple pointer
to a struct - and moreover it should work on all compilers, right?
So this looks good to me.

> Fixes: 494edd266b945f36 ("regulator/mfd: Support ROHM BD71847 power management IC")
> Signed-off-by: Geert Uytterhoeven <geert@...ux-m68k.org>
> ---
> Compile-tested only.
> ---
>  drivers/regulator/bd718x7-regulator.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/regulator/bd718x7-regulator.c b/drivers/regulator/bd718x7-regulator.c
> index 3a47e0372e77c812..fff5bc4faa2c99aa 100644
> --- a/drivers/regulator/bd718x7-regulator.c
> +++ b/drivers/regulator/bd718x7-regulator.c
> @@ -1007,7 +1007,7 @@ static const struct bd718xx_regulator_data bd71837_regulators[] = {
>  };
>  
>  struct bd718xx_pmic_inits {
> -	const struct bd718xx_regulator_data (*r_datas)[];
> +	const struct bd718xx_regulator_data *r_datas;
>  	unsigned int r_amount;
>  };
>  
> @@ -1017,11 +1017,11 @@ static int bd718xx_probe(struct platform_device *pdev)
>  	struct regulator_config config = { 0 };
>  	struct bd718xx_pmic_inits pmic_regulators[] = {
>  		[BD718XX_TYPE_BD71837] = {
> -			.r_datas = &bd71837_regulators,
> +			.r_datas = bd71837_regulators,
>  			.r_amount = ARRAY_SIZE(bd71837_regulators),
>  		},
>  		[BD718XX_TYPE_BD71847] = {
> -			.r_datas = &bd71847_regulators,
> +			.r_datas = bd71847_regulators,
>  			.r_amount = ARRAY_SIZE(bd71847_regulators),
>  		},
>  	};
> @@ -1059,7 +1059,7 @@ static int bd718xx_probe(struct platform_device *pdev)
>  		struct regulator_dev *rdev;
>  		const struct bd718xx_regulator_data *r;
>  
> -		r = &(*pmic_regulators[mfd->chip_type].r_datas)[i];
> +		r = &pmic_regulators[mfd->chip_type].r_datas[i];
>  		desc = &r->desc;
>  
>  		config.dev = pdev->dev.parent;
> -- 
> 2.17.1
> 

-- 
Matti Vaittinen
ROHM Semiconductors

~~~ "I don't think so," said Rene Descartes.  Just then, he vanished ~~~