[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXv+5Gf9+rc+vLcr-JFhO561G8dw38ksV3drat+DyCfWEVakQ@mail.gmail.com>
Date: Thu, 26 Sep 2024 16:43:52 +0800
From: Chen-Yu Tsai <wenst@...omium.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Ulf Hansson <ulf.hansson@...aro.org>, Matthias Brugger <matthias.bgg@...il.com>,
AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>, Mark Brown <broonie@...nel.org>,
devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-mediatek@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-pm@...r.kernel.org, Douglas Anderson <dianders@...omium.org>,
Johan Hovold <johan@...nel.org>, Pablo Sun <pablo.sun@...iatek.com>,
Macpaul Lin <macpaul.lin@...iatek.com>,
Sebastian Reichel <sebastian.reichel@...labora.com>
Subject: Re: [PATCH v8 2/3] regulator: Add devres version of of_regulator_get_optional()
On Wed, Sep 25, 2024 at 6:56 PM Andy Shevchenko
<andriy.shevchenko@...ux.intel.com> wrote:
>
> On Wed, Sep 25, 2024 at 05:38:05PM +0800, Chen-Yu Tsai wrote:
> > There are existing uses for a devres version of of_regulator_get_optional()
> > in power domain drivers. On MediaTek platforms, power domains may have
> > regulator supplies tied to them. The driver currently tries to use
> > devm_regulator_get() to not have to manage the lifecycle, but ends up
> > doing it in a very hacky way by replacing the device node of the power
> > domain controller device to the device node of the power domain that is
> > currently being registered, getting the supply, and reverting the device
> > node.
> >
> > Provide a better API so that the hack can be replaced.
>
> ...
>
> > +#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?
Also, _of_regulator_get() does not have a stub version for !CONFIG_OF.
> > +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.
ChenYu
> > +}
>
> > +#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.
Powered by blists - more mailing lists