Re: [PATCH v4 2/2] iio: adc: Add Nuvoton MA35D1 EADC driver

[Jonathan Cameron <jic23@kernel.org>]

On Thu, 12 Nov 2026 09:26:00 +0800
Chi-Wen Weng <cwweng.linux@gmail.com> wrote:

> Andy Shevchenko 於 2026/11/11 下午 10:05 寫道:
> > On Tue, Nov 10, 2026 at 08:08:03PM -0600, Victor Chernyakin wrote:
> > 
> > ...
> >   
> >>> +	if (!num_channels)
> >>> +		return dev_err_probe(dev, -ENOENT, "no ADC channels configured\n");
> >>> +
> >>> +	if (num_channels > MA35D1_EADC_MAX_EXT_CHANNELS)
> >>> +		return dev_err_probe(dev, -ENOSPC, "too many ADC channels\n");
> >>> +
> >>> +	channels = devm_kcalloc(dev, size_add(num_channels, 1),
> >>> +				sizeof(*channels), GFP_KERNEL);  
> >>
> >> Couldn't size_add() just be regular +?
> >> (Question to Andy who originally suggested it)
> >> We've just checked that num_channels is small and won't overflow.  
> > 
> > While that's true, the other aspect(s) of this is in play. Namely we want to
> > have the same pattern over the kernel that makes code robust (tomorrow some
> > cases can be modified unnoticed with opening such an issue again) along with
> > the potential of finding those patterns and update in case of mass-updates
> > of low-level API, and I have heard for the matter of fact that devm_*alloc*()
> > are in the plans to move to something like k*alloc_obj*() or k*alloc_flex().
> >   
For what is is worth we now have devm_kzalloc_objs() in tree. 
I'd imagine a mass conversion is on the cards, similar to what
was done for the other allocation functions. 
However, it's controversial so probably don't jump on that just yet!

https://lore.kernel.org/all/CAHk-=wgYBrhvo2NAG_Ja-0ovPf=xO20Gcopv9Yrr1u=QVxECZw@mail.gmail.com/


> 
> Thanks Victor and Andy for the discussion.
> 
> I'll keep size_add() for consistency and future-proofing, as Andy suggested.
> 
> Thanks,
> Chi-Wen
>