Re: [PATCH v8 4/4] iio: cdc: add Texas Instruments FDC1004 driver

[Andy Shevchenko <andriy.shevchenko@intel.com>]

On Wed, Nov 11, 2026 at 08:10:49AM -0600, Victor Chernyakin wrote:

...

> > > > > +static const int fdc1004_calibbias_decomposed[] = {
> > > > > +	lower_32_bits(fdc1004_calibbias[0]), upper_32_bits(fdc1004_calibbias[0]),
> > > > > +	lower_32_bits(fdc1004_calibbias[1]), upper_32_bits(fdc1004_calibbias[1]),
> > > > > +	lower_32_bits(fdc1004_calibbias[2]), upper_32_bits(fdc1004_calibbias[2]),
> > > > > +};
> > > > > +
> > > > > +static const int fdc1004_calibscale_decomposed[] = {
> > > > > +	lower_32_bits(fdc1004_calibscale[0]), upper_32_bits(fdc1004_calibscale[0]),
> > > > > +	lower_32_bits(fdc1004_calibscale[1]), upper_32_bits(fdc1004_calibscale[1]),
> > > > > +	lower_32_bits(fdc1004_calibscale[2]), upper_32_bits(fdc1004_calibscale[2]),
> > > > > +};

> > > > Can we prepare them dynamically at runtime? Use global variables and a macro
> > > > from once.h to make the populate function a singleton, so we don't have as many
> > > > copies as devices on the system that are driven by this code. We can probably
> > > > do this later, though.
> > > 
> > > Are you sure there's a separate copy for each device? In my understanding,
> > > these static variables are loaded along with the module, and the module
> > > is loaded only once and shared between all devices.
> > 
> > I started my paragraph with "Can we prepare them dynamically at runtime?"
> > which assumes that the rest of the paragraph is elaborating that idea.
> 
> Oh, I see how I misread that, sorry.
> 
> Here's the implementation I tried:
> 
> static int fdc1004_calibbias_decomposed[6];
> static int fdc1004_calibscale_decomposed[6];
> 
> static void fdc1004_init_decomposed_arrays(void)
> {
> 	for (int i = 0; i < ARRAY_SIZE(fdc1004_calibbias); i++) {

This is not fully correct.

> 		iio_val_s64_decompose(fdc1004_calibbias[i], &fdc1004_calibbias_decomposed[2 * i],
> 							    &fdc1004_calibbias_decomposed[2 * i + 1]);
> 		iio_val_s64_decompose(fdc1004_calibscale[i], &fdc1004_calibscale_decomposed[2 * i],
> 							     &fdc1004_calibscale_decomposed[2 * i + 1]);
> 	}
> }

This can be reduced to supply the pointers to the arrays along with the size
to some helper and call it twice (three functions), but that might be not
better either by size.

> static int fdc1004_read_avail(...)
> {
> 	DO_ONCE(fdc1004_init_decomposed_arrays);
> 	....
> }
> 
> Running bloat-o-meter, the code got quite a bit bigger unfortunately:
> 
> Function                                     old     new   delta
> fdc1004_read_avail                           141     369    +228
> ____versions                                1408    1536    +128
> ____version_ext_names                        406     437     +31
> ___once_key                                    -      16     +16
> ____version_ext_crcs                          88      96      +8
> ___done                                        -       1      +1
> Total: Before=8750, After=9162, chg +4.71%
> 
> (This was compiling with KCFLAGS="-Os". I also tried KCFLAGS="-O2" and
> the result is very similar)

However, this is not about the size of the binary, it's about robustness of
the code and having one point of data. As I already mentioned, this is just
an idea how to solve it, maybe Jonathan and others have a better one...

-- 
With Best Regards,
Andy Shevchenko