Rex-BC Chen <rex-bc.chen@xxxxxxxxxxxx> writes: > On Fri, 2022-04-08 at 13:32 -0700, Kevin Hilman wrote: >> Rex-BC Chen <rex-bc.chen@xxxxxxxxxxxx> writes: >> >> > From: Jia-Wei Chang <jia-wei.chang@xxxxxxxxxxxx> >> > >> > For some MediaTek SoCs, like MT8186, it's possible that the sram >> > regulator >> > is shared between CPU and CCI. >> > >> > Signed-off-by: Jia-Wei Chang <jia-wei.chang@xxxxxxxxxxxx> >> >> nit: missing your sign-off. >> >> > --- >> > drivers/cpufreq/mediatek-cpufreq.c | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/drivers/cpufreq/mediatek-cpufreq.c >> > b/drivers/cpufreq/mediatek-cpufreq.c >> > index 9e9bce0ff235..8f688d47e64b 100644 >> > --- a/drivers/cpufreq/mediatek-cpufreq.c >> > +++ b/drivers/cpufreq/mediatek-cpufreq.c >> > @@ -435,7 +435,7 @@ static int mtk_cpu_dvfs_info_init(struct >> > mtk_cpu_dvfs_info *info, int cpu) >> > } >> > >> > /* Both presence and absence of sram regulator are valid cases. >> > */ >> > - info->sram_reg = regulator_get_exclusive(cpu_dev, "sram"); >> > + info->sram_reg = regulator_get_optional(cpu_dev, "sram"); >> >> The changelog says that this regulator may be shared with CCI, so I >> understand it's no longer exclusive. But here you make it optional, >> which should be explained in the changelog. If it's not actually >> optional, then it should just be normal "get". >> >> Kevin > > Hello Kevin, > > Since cpufreq and cci devfreq might share the same sram regulator in > MediaTek SoC, it is no longer exclusive as you mentioned. > > The reason to use regulator_get_optional is we hope regulator framework > can return error for error handling rather than a dummy handler from > regulator_get api. > > I will add this to commit message in next version. OK, sounds good. Thanks, Kevin
