[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFoxggSnRZxQ7QBbF2-akoj8TTMGawxeH_0ZnPQ7CBCnUA@mail.gmail.com>
Date: Wed, 23 Apr 2025 09:58:08 +0200
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Saravana Kannan <saravanak@...gle.com>
Cc: Stephen Boyd <sboyd@...nel.org>, linux-pm@...r.kernel.org,
"Rafael J . Wysocki" <rafael@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Michael Grzeschik <m.grzeschik@...gutronix.de>, Bjorn Andersson <andersson@...nel.org>,
Abel Vesa <abel.vesa@...aro.org>, Devarsh Thakkar <devarsht@...v0571a.ent.ti.com>,
Peng Fan <peng.fan@....nxp.com>, Tomi Valkeinen <tomi.valkeinen@...asonboard.com>,
Johan Hovold <johan@...nel.org>, Maulik Shah <maulik.shah@....qualcomm.com>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 08/11] pmdomain: core: Add internal ->sync_state() support
for genpd providers
On Fri, 18 Apr 2025 at 02:24, Saravana Kannan <saravanak@...gle.com> wrote:
>
> On Thu, Apr 17, 2025 at 7:25 AM Ulf Hansson <ulf.hansson@...aro.org> wrote:
> >
> > If the genpd provider's fwnode doesn't have an associated struct device
> > with it, we can make use of the generic genpd->dev and it corresponding
> > driver internally in genpd to manage ->sync_state().
> >
> > More precisely, while adding a genpd OF provider let's check if the fwnode
> > has a device and if not, make the preparation to handle ->sync_state()
> > internally through the genpd_provider_driver and the genpd_provider_bus.
> >
> > Signed-off-by: Ulf Hansson <ulf.hansson@...aro.org>
> > ---
> > drivers/pmdomain/core.c | 36 ++++++++++++++++++++++++++++++++++++
> > include/linux/pm_domain.h | 7 +++++++
> > 2 files changed, 43 insertions(+)
> >
> > diff --git a/drivers/pmdomain/core.c b/drivers/pmdomain/core.c
> > index 512f89e6d302..9c5a77bf59d2 100644
> > --- a/drivers/pmdomain/core.c
> > +++ b/drivers/pmdomain/core.c
> > @@ -2374,6 +2374,7 @@ int pm_genpd_init(struct generic_pm_domain *genpd,
> > INIT_WORK(&genpd->power_off_work, genpd_power_off_work_fn);
> > atomic_set(&genpd->sd_count, 0);
> > genpd->status = is_off ? GENPD_STATE_OFF : GENPD_STATE_ON;
> > + genpd->sync_state = GENPD_SYNC_STATE_OFF;
> > genpd->device_count = 0;
> > genpd->provider = NULL;
> > genpd->device_id = -ENXIO;
> > @@ -2656,6 +2657,7 @@ int of_genpd_add_provider_simple(struct device_node *np,
> > struct generic_pm_domain *genpd)
> > {
> > struct fwnode_handle *fwnode;
> > + struct device *dev;
> > int ret;
> >
> > if (!np || !genpd)
> > @@ -2665,6 +2667,10 @@ int of_genpd_add_provider_simple(struct device_node *np,
> > return -EINVAL;
> >
> > fwnode = &np->fwnode;
> > + dev = fwnode->dev;
> > +
> > + if (!dev)
> > + genpd->sync_state = GENPD_SYNC_STATE_SIMPLE;
>
> I don't want people directly poking into fwnode.
There are already other subsystems doing it like this. Like
drivers/gpio/gpiolib.c for example. I didn't think it was a big deal,
my bad!
>
> Use get_device_from_fwnode() that's in drivers/base/core.c? Might need
> to move it to a header. Make sure to put_device() it back.
Sure, I can certainly do that!
>
> Or ideally, figure it out using some other means like looking for
> #power-domain-cells number? (if that'll always give the right answer).
> Point being, the framework should know which type it's registering
> even if there was no fwnode/fw_devlink.
When adding the genpd-of-provider we are only passing a device node.
Looking for "#power-domain-cells" can't tell us whether the node will
have a device or not.
>
> >
> > device_set_node(&genpd->dev, fwnode);
> >
> > @@ -2718,8 +2724,10 @@ int of_genpd_add_provider_onecell(struct device_node *np,
> > {
> > struct generic_pm_domain *genpd;
> > struct fwnode_handle *fwnode;
> > + struct device *dev;
> > unsigned int i;
> > int ret = -EINVAL;
> > + bool sync_state = false;
> >
> > if (!np || !data)
> > return -EINVAL;
> > @@ -2728,6 +2736,10 @@ int of_genpd_add_provider_onecell(struct device_node *np,
> > data->xlate = genpd_xlate_onecell;
> >
> > fwnode = &np->fwnode;
> > + dev = fwnode->dev;
>
> Can you do this some other way please? I really don't like this look up.
Okay, I will use get_device_from_fwnode().
Thanks again for reviewing!
[...]
Kind regards
Uffe
Powered by blists - more mailing lists