Re: [PATCH v1 0/2] kstrtox: make _parse_integer() flexible

[Rodrigo Alencar]

On 26/06/03 12:51PM, Rodrigo Alencar wrote:
> On 26/06/03 01:23PM, Petr Mladek wrote:
> > On Tue 2026-06-02 22:29:45, Andy Shevchenko wrote:
> > > Currently every new wrapper on _parse_integer_limit() will need a new name
> > > to share with users while keeping some optional arguments to be initialised
> > > explicitly. Since there is an attempt to expand this more, I decided to
> > > suggest this mini series to avoid namespace pollution and unneeded churn in
> > > the future.
> > > 
> > > To expand this API more, the possible future change may be:
> > > 
> > >  unsigned int _parse_integer_limit(const char *s, unsigned int base, unsigned long long *res,
> > > -                                  size_t max_chars);
> > > +                                  size_t max_chars, $new_opt_arg);
> > > 
> > >  #define _parse_integer0(s, base, res, ...)                                              \
> > > -        _parse_integer_limit(s, base, res, INT_MAX);
> > > +        _parse_integer_limit(s, base, res, INT_MAX, $new_opt_arg=$default);
> > > 
> > >  #define _parse_integer1(s, base, res, max_chars, ...)                                   \
> > > -        _parse_integer_limit(s, base, res, max_chars);
> > > +        _parse_integer_limit(s, base, res, max_chars, $new_opt_arg=$default);
> > > 
> > > +#define _parse_integer2(s, base, res, max_chars, new_opt_arg, ...)                      \
> > > +        _parse_integer_limit(s, base, res, max_chars, new_opt_arg);
> > 
> > I guess that this is about _parse_integer_limit_init() from
> > https://lore.kernel.org/all/20260531-adf41513-iio-driver-v15-2-da09adf1c0dd@xxxxxxxxxx/
> > 
> > I personally find
> > 
> >     _parse_integer(*s, base. *res)
> >     _parse_integer_limit(*s, base, *res, max_chars)
> >     _parse_integer_limit_init(*s, base, init, *res, max_chars)
> >
> 
> What could also be done is having a _parse_integer_ext() that would
> contain all the necessary arguments (one that should be indicated
> not to be used) and define all the other variations as static inline
> functions. I suppose that combines both ideas, being a pattern that
> is also used elsewhere:
> 
> 	devm_regulator_get()
> 	devm_regulator_get_enable()
> 	devm_regulator_get_enable_optional() 

Actually the example pattern with static inline is not this one, it is
under linux/reset.h with __devm_reset_control_get().

If every one agrees I can add that to the v16 of the patch series
of the PLL driver.
  
-- 
Kind regards,

Rodrigo Alencar