On Thu, Sep 26, 2024 at 04:43:52PM +0800, Chen-Yu Tsai wrote:
> On Wed, Sep 25, 2024 at 6:56 PM Andy Shevchenko
> <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote:
> > On Wed, Sep 25, 2024 at 05:38:05PM +0800, Chen-Yu Tsai wrote:
...
> > > +#if IS_ENABLED(CONFIG_OF)
> >
> > Do we really need this?
>
> What's the point of going through devres_* stuff if we already know
> _of_regulator_get() is going to fail anyway?
With devm_add_action*() this will be other way around and there are plenty of
APIs done this way. The ifdeffery is simply ugly in the code.
> Also, _of_regulator_get() does not have a stub version for !CONFIG_OF.
So, what prevents us from adding it?
> > > +static struct regulator *_devm_of_regulator_get(struct device *dev, struct device_node *node,
> > > + const char *id, int get_type)
> > > +{
> > > + struct regulator **ptr, *regulator;
> > > +
> > > + ptr = devres_alloc(devm_regulator_release, sizeof(*ptr), GFP_KERNEL);
> > > + if (!ptr)
> > > + return ERR_PTR(-ENOMEM);
> > > +
> > > + regulator = _of_regulator_get(dev, node, id, get_type);
> > > + if (!IS_ERR(regulator)) {
> > > + *ptr = regulator;
> > > + devres_add(dev, ptr);
> > > + } else {
> > > + devres_free(ptr);
> > > + }
> > > +
> > > + return regulator;
> >
> > Why not using devm_add_action() / devm_add_action_or_reset()
> > (whichever suits better here)?
>
> Cargo cult from _devm_regulator_get() in this file. However since this is
> meant to share the same release function, both functions need to use the
> same mechanism.
>
> I could also argue that this is not an action, but an allocation, and so
> devres_alloc() seems to make more sense.
It's rather matter of the naming of the devm_add_action*() APIs, but again,
we have plenty of APIs using it when it's allocation and not strictly speaking
an action.
> > > +}
> >
> > > +#endif
...
> > > +static inline struct regulator *__must_check devm_of_regulator_get_optional(struct device *dev,
> > > + struct device_node *node,
> > > + const char *id)
> >
> > I don't know the conventions here, but I find better to have it as
> >
> > static inline __must_check struct regulator *
> > devm_of_regulator_get_optional(struct device *dev, struct device_node *node, const char *id)
> >
> > Similar to other stubs and declarations.
>
> I don't think there are any conventions. This file already has three types:
>
> 1. Wrap the line with the function name on the second line
> 2. Wrap the arguments; wrapped arguments aligned to the left parenthesis.
> 3. Wrap the arguments; wrapped arguments aligned with aribtrary number of
> tabs.
>
> I prefer the way I have put them.
The way you put it despite relaxed limit is slightly harder to read.
I don't remember many headers that do so-o indented parameters. Besides
your way defers the burden of resplit to the future in case one more parameter
needs to be added which will excess the 100 limit.
Also __must_check is somehow misplaced in my opinion (talking from my
experience and this can be simply checked by grepping other headers).
That said, I prefer the way I suggested or something alike.
--
With Best Regards,
Andy Shevchenko
