linux-kernel - Re: [PATCH v1] pmdomain: imx8m-blk-ctrl: fix suspend/resume order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <513930aa50c2f55e7853a53dd42f43ac219ff384.camel@gmail.com>
Date: Tue, 25 Jun 2024 08:32:40 +0100
From: Vitor Soares <ivitro@...il.com>
To: Ulf Hansson <ulf.hansson@...aro.org>, Lucas Stach
 <l.stach@...gutronix.de>
Cc: Shawn Guo <shawnguo@...nel.org>, Sascha Hauer <s.hauer@...gutronix.de>, 
 Pengutronix Kernel Team <kernel@...gutronix.de>, Fabio Estevam
 <festevam@...il.com>, Vitor Soares <vitor.soares@...adex.com>,
 linux-pm@...r.kernel.org, imx@...ts.linux.dev, 
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
 stable@...r.kernel.org
Subject: Re: [PATCH v1] pmdomain: imx8m-blk-ctrl: fix suspend/resume order

On Fri, 2024-05-10 at 11:34 +0200, Ulf Hansson wrote:
> On Thu, 18 Apr 2024 at 17:52, Vitor Soares <ivitro@...il.com> wrote:
> > 
> > From: Vitor Soares <vitor.soares@...adex.com>
> > 
> > During the probe, the genpd power_dev is added to the dpm_list after
> > blk_ctrl due to its parent/child relationship. Making the blk_ctrl
> > suspend after and resume before the genpd power_dev.
> > 
> > As a consequence, the system hangs when resuming the VPU due to the
> > power domain dependency.
> > 
> > To ensure the proper suspend/resume order, add a device link betweem
> > blk_ctrl and genpd power_dev. It guarantees genpd power_dev is suspended
> > after and resumed before blk-ctrl.
> 
> Before discussing $subject patch, would you mind explaining to me why
> imx8m-blk-ctrl needs to use the ->suspend() callback at all?
> 
> Looking closer at that code (imx8m_blk_ctrl_suspend()), it calls
> pm_runtime_get_sync() for devices to power on "everything". Why isn't
> that managed by the consumer drivers (on a case by case basis) that
> are managing the devices that are attached to the genpds instead?
> 
> Kind regards
> Uffe
> 

Hi Lucas, you know the driver architecture better than I do. Would you mind
addressing Ulf concerns?


In addition to that, I would say that given that this is a bug fix, it would be
nice to have it merged. Having a buggy driver in the kernel is not solving this
kind of architectural question.


Best regards,
Vitor Soares

> > 
> > Cc: <stable@...r.kernel.org>
> > Closes:
> > https://lore.kernel.org/all/fccbb040330a706a4f7b34875db1d896a0bf81c8.camel@gmail.com/
> > Link: https://lore.kernel.org/all/20240409085802.290439-1-ivitro@gmail.com/
> > Fixes: 2684ac05a8c4 ("soc: imx: add i.MX8M blk-ctrl driver")
> > Suggested-by: Lucas Stach <l.stach@...gutronix.de>
> > Signed-off-by: Vitor Soares <vitor.soares@...adex.com>
> > ---
> > 
> > This is a new patch, but is a follow-up of:
> > https://lore.kernel.org/all/20240409085802.290439-1-ivitro@gmail.com/
> > 
> > As suggested by Lucas, we are addressing this PM issue in the imx8m-blk-ctrl
> > driver instead of in the imx8mm.dtsi.
> > 
> >  drivers/pmdomain/imx/imx8m-blk-ctrl.c | 16 ++++++++++++++++
> >  1 file changed, 16 insertions(+)
> > 
> > diff --git a/drivers/pmdomain/imx/imx8m-blk-ctrl.c
> > b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
> > index ca942d7929c2..cd0d2296080d 100644
> > --- a/drivers/pmdomain/imx/imx8m-blk-ctrl.c
> > +++ b/drivers/pmdomain/imx/imx8m-blk-ctrl.c
> > @@ -283,6 +283,20 @@ static int imx8m_blk_ctrl_probe(struct platform_device
> > *pdev)
> >                         goto cleanup_pds;
> >                 }
> > 
> > +               /*
> > +                * Enforce suspend/resume ordering by making genpd power_dev
> > a
> > +                * provider of blk-ctrl. Genpd power_dev is suspended after
> > and
> > +                * resumed before blk-ctrl.
> > +                */
> > +               if (!device_link_add(dev, domain->power_dev,
> > DL_FLAG_STATELESS)) {
> > +                       ret = -EINVAL;
> > +                       dev_err_probe(dev, ret,
> > +                                     "failed to link to %s\n", data->name);
> > +                       pm_genpd_remove(&domain->genpd);
> > +                       dev_pm_domain_detach(domain->power_dev, true);
> > +                       goto cleanup_pds;
> > +               }
> > +
> >                 /*
> >                  * We use runtime PM to trigger power on/off of the upstream
> > GPC
> >                  * domain, as a strict hierarchical parent/child power
> > domain
> > @@ -324,6 +338,7 @@ static int imx8m_blk_ctrl_probe(struct platform_device
> > *pdev)
> >         of_genpd_del_provider(dev->of_node);
> >  cleanup_pds:
> >         for (i--; i >= 0; i--) {
> > +               device_link_remove(dev, bc->domains[i].power_dev);
> >                 pm_genpd_remove(&bc->domains[i].genpd);
> >                 dev_pm_domain_detach(bc->domains[i].power_dev, true);
> >         }
> > @@ -343,6 +358,7 @@ static void imx8m_blk_ctrl_remove(struct platform_device
> > *pdev)
> >         for (i = 0; bc->onecell_data.num_domains; i++) {
> >                 struct imx8m_blk_ctrl_domain *domain = &bc->domains[i];
> > 
> > +               device_link_remove(&pdev->dev, domain->power_dev);
> >                 pm_genpd_remove(&domain->genpd);
> >                 dev_pm_domain_detach(domain->power_dev, true);
> >         }
> > --
> > 2.34.1
> >