linux-kernel - Re: [PATCH v1] soc: mediatek: pm-domains: Fix the power glitch issue

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3a55f44998645308bb1b4fd65ef550682ebe6ba0.camel@mediatek.com>
Date:   Fri, 11 Mar 2022 10:54:51 +0800
From:   Chun-Jie Chen <chun-jie.chen@...iatek.com>
To:     Miles Chen <miles.chen@...iatek.com>
CC:     <Project_Global_Chrome_Upstream_Group@...iatek.com>,
        <drinkcat@...omium.org>, <eballetbo@...il.com>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>,
        <linux-mediatek@...ts.infradead.org>, <matthias.bgg@...il.com>,
        <srv_heupstream@...iatek.com>
Subject: Re: [PATCH v1] soc: mediatek: pm-domains: Fix the power glitch issue

On Thu, 2022-03-10 at 11:59 +0800, Miles Chen wrote:
> Hi Chun-Jie,
> 
> > Power reset maybe generate unexpected signal. In order to avoid
> > the glitch issue, we need to enable isolation first to guarantee
> > the
> > stable signal when power reset is triggered.
> > 
> > Fixes: 59b644b01cf4 ("soc: mediatek: Add MediaTek SCPSYS power
> > domains")
> > Signed-off-by: Chun-Jie Chen <chun-jie.chen@...iatek.com>
> > ---
> > This patch is based on 5.17-rc1.
> > ---
> > drivers/soc/mediatek/mtk-pm-domains.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/soc/mediatek/mtk-pm-domains.c
> > b/drivers/soc/mediatek/mtk-pm-domains.c
> > index b762bc40f56b..0195f6c3396b 100644
> > --- a/drivers/soc/mediatek/mtk-pm-domains.c
> > +++ b/drivers/soc/mediatek/mtk-pm-domains.c
> > @@ -272,9 +272,9 @@ static int scpsys_power_off(struct
> > generic_pm_domain *genpd)
> > 	clk_bulk_disable_unprepare(pd->num_subsys_clks, pd-
> > >subsys_clks);
> > 
> > 	/* subsys power off */
> > -	regmap_clear_bits(scpsys->base, pd->data->ctl_offs,
> > PWR_RST_B_BIT);
> > 	regmap_set_bits(scpsys->base, pd->data->ctl_offs, PWR_ISO_BIT);
> > 	regmap_set_bits(scpsys->base, pd->data->ctl_offs,
> > PWR_CLK_DIS_BIT);
> > +	regmap_clear_bits(scpsys->base, pd->data->ctl_offs,
> > PWR_RST_B_BIT);
> > 	regmap_clear_bits(scpsys->base, pd->data->ctl_offs,
> > PWR_ON_2ND_BIT);
> > 	regmap_clear_bits(scpsys->base, pd->data->ctl_offs,
> > PWR_ON_BIT);
> 
>  
> Does it mean that we have to do power off by:
> regmap_set_bits(PWR_ISO_BIT)
> regmap_clear_bits(PWR_RST_B_BIT )
> 
> and do power on by:
> regmap_set_bits(PWR_RST_B_BIT)
> regmap_clear_bits(PWR_ISO_BIT)
> 
> But scpsys_power_on() has the following sequence:
> regmap_clear_bits(PWR_ISO_BIT)
> regmap_set_bits(PWR_RST_B_BIT)
> 
> Thanks,
> Miles

Hi Miles,

This control sequence is suggested by hardware designer,
and when PWR_RST_B from 0 -> 1, it will trigger to exit from reset
state to running state, if we still enable isolation then can't start
running normally, so we need to disable isolation first in power on
sequence.

Thanks!