Re: [PATCH][next] iio: adc: make read-only const array config static

On Wed, Jul 15, 2026 at 02:34:50PM +0100, Colin King (gmail) wrote:
> On 15/07/2026 14:32, Andy Shevchenko wrote:
> > On Wed, Jul 15, 2026 at 01:22:32PM +0300, Dan Carpenter wrote:
> > > On Tue, Jul 14, 2026 at 08:08:10PM +0300, Andy Shevchenko wrote:
> > > > On Tue, Jul 14, 2026 at 05:50:12PM +0100, Colin Ian King wrote:

...

> > > > In all patches like this it's always a bikeshedding possible of moving static
> > > > data outside of a function. I have no strong opinion in these cases (when the
> > > > data solely used by a single function), but in general it might give different
> > > > readability experience (it's harder to notice static data in the local function
> > > > definition block). So I leave this exercise to the maintainers of the respective
> > > > pieces of the code.
> > > 
> > > It's an interesting point...
> > > 
> > > At one point Smatch didn't track static variables and it used to
> > > generate occasional false positives.  And it's like you say, those
> > > little "static" qualifiers are hard to spot in a wall of declaration
> > > text.  I've never considered moving the declarations out of the
> > > function scope but it might be a good idea?
> > 
> > Maybe, as I said, I have no strong opinion here. I am all ears to hear
> > what others think.
> 
> For small arrays it's a moot point if this type of change is useful, so

Yep, it actually becomes a trade-off between generated code and existing data.
With a small difference that static const may be located in ROM (important for
the embedded devices with minimum available memory).

> I'm OK if it's not accepted. I appreciate the feedback.

Me too.

> > > But in this case since this data is const, the static vs not-static
> > > doesn't affect flow analysis or readability.
> > 
> > It doesn't affect flow analysis, but we also have David's point about
> > amount of data to be static may affect the code generation.

...

> > The main point I have is that stumbling over the 'static' in the definition
> > block might rise some additional questions and slow down the understanding of
> > the code (by reading).


-- 
With Best Regards,
Andy Shevchenko