On Thu, Sep 26, 2024 at 8:26 PM Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> wrote: > > 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. It's still extra code that doesn't get compiled out. > > Also, _of_regulator_get() does not have a stub version for !CONFIG_OF. > > So, what prevents us from adding it? Because there's no need if the only internal user isn't using it. I could also move them over to of_regulator.c. _of_regulator_get() stays internal to that file, and devm_regulator_release() gets exposed instead. Does that sound better? > > > > +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. OK. Still the mechanism used needs to match that of the existing API. So devres_add() it is for now. > > > > +} > > > > > > > +#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). Seems correct to me. It's between the return type and the function name.