[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230726161033.GA1102409@dev-arch.thelio-3990X>
Date: Wed, 26 Jul 2023 09:10:33 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Okan Sahin <okan.sahin@...log.com>
Cc: Liam Girdwood <lgirdwood@...il.com>,
Mark Brown <broonie@...nel.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
Conor Dooley <conor+dt@...nel.org>,
Ibrahim Tilki <Ibrahim.Tilki@...log.com>,
linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
llvm@...ts.linux.dev
Subject: Re: [PATCH v3 2/2] regulator: max77857: Add ADI MAX77857/59/MAX77831
Regulator Support
Hi Okan,
On Tue, Jul 18, 2023 at 08:55:02AM -0700, Nathan Chancellor wrote:
<snip>
> > +static struct regulator_desc max77857_regulator_desc = {
> > + .ops = &max77857_regulator_ops,
> > + .name = "max77857",
> > + .linear_ranges = max77857_lin_ranges,
> > + .n_linear_ranges = ARRAY_SIZE(max77857_lin_ranges),
> > + .vsel_mask = 0xFF,
> > + .vsel_reg = MAX77857_REG_CONT2,
> > + .ramp_delay_table = max77857_ramp_table[0],
> > + .n_ramp_values = ARRAY_SIZE(max77857_ramp_table[0]),
> > + .ramp_reg = MAX77857_REG_CONT3,
> > + .ramp_mask = GENMASK(1, 0),
> > + .ramp_delay = max77857_ramp_table[0][0],
>
> This breaks the build with GCC 5.x through 7.x:
>
> drivers/regulator/max77857-regulator.c:312:16: error: initializer element is not constant
> .ramp_delay = max77857_ramp_table[0][0],
> ^~~~~~~~~~~~~~~~~~~
> drivers/regulator/max77857-regulator.c:312:16: note: (near initialization for 'max77857_regulator_desc.ramp_delay')
>
> and clang:
>
> drivers/regulator/max77857-regulator.c:312:16: error: initializer element is not a compile-time constant
> 312 | .ramp_delay = max77857_ramp_table[0][0],
> | ^~~~~~~~~~~~~~~~~~~~~~~~~
> 1 error generated.
>
> This relies on a GCC 8.x+ change that accepts more things as
> compile-time constants, which is being worked on in clang
> (https://reviews.llvm.org/D76096). Since the kernel supports older
> compilers, this will have to be worked around somehow. Perhaps a define
> that can be used in both places?
Was there any update on this? I do not mind sending a patch for this
myself if I have some sort of guidance on how you would prefer for this
to be fixed, should you be too busy to look into it.
Cheers,
Nathan
Powered by blists - more mailing lists