Hi Geert-san, > From: Geert Uytterhoeven, Sent: Friday, October 25, 2019 4:47 PM > > Hi Shimoda-san, > > On Fri, Oct 25, 2019 at 3:36 AM Yoshihiro Shimoda > <yoshihiro.shimoda.uh@xxxxxxxxxxx> wrote: > > > From: Geert Uytterhoeven, Sent: Thursday, October 24, 2019 8:35 PM > > <snip> > > > > --- a/drivers/clk/renesas/rcar-usb2-clock-sel.c > > > > +++ b/drivers/clk/renesas/rcar-usb2-clock-sel.c > > > > > @@ -131,6 +156,14 @@ static int rcar_usb2_clock_sel_probe(struct platform_device *pdev) > > > > pm_runtime_enable(dev); > > > > pm_runtime_get_sync(dev); > > > > > > pm_runtime_get_sync() will have already enabled the first module clock listed in > > > the DT "clocks" property. > > > > > > If you want the driver to manage all clocks itself, perhaps the PM Runtime > > > calls should be dropped? > > > > I'm thinking PM Runtime calls are related to power domain control so that we cannot > > drop it. Or, since the hardware is the Always-on domain, can we drop it anyway? > > That's right: if the hardware block ever ends up in a non-always-on > power domain, > you won't have a choice but to use PM Runtime. So, should I keep the PM Runtime calls? # In such the case, I should add to describe power-domains property into # the dt-binding doc though :) Best regards, Yoshihiro Shimoda
