On Wed, 2019-09-25 at 21:06 -0700, John Stultz wrote: > On Wed, Sep 25, 2019 at 6:34 PM Chunfeng Yun <chunfeng.yun@xxxxxxxxxxxx> wrote: > > On Wed, 2019-09-25 at 23:42 +0000, John Stultz wrote: > > > +++ b/Documentation/devicetree/bindings/usb/hisi,dwc3.txt > > > @@ -0,0 +1,52 @@ > > > +HiSi SuperSpeed DWC3 USB SoC controller > > > + > > > +Required properties: > > > +- compatible: should contain "hisilicon,hi3660-dwc3" for HiSi SoC > > > +- clocks: A list of phandle + clock-specifier pairs for the > > > + clocks listed in clock-names > > > +- clock-names: Should contain the following: > > > + "clk_usb3phy_ref" Phy reference clk > > It's not good idea to apply phy's clock in dwc3's node > > Hey! Thanks for taking a look at this! > > So first, my apologies, I'm not the driver author and I don't have any > real specs on the hardware other then what's in the source tree I'm > working on. Not the ideal person to be documenting the binding, but I > realized we still needed some binding documentation (although a few > other dwc-of-simple compat entries are undocumented), so this is my > rough stab at it. :/ > > Given the name clk_usb3phy_ref I'm assuming its a phy reference clock, > but I honestly don't know if I'm getting that wrong. It all seems to > be leveraging the fact that the dwc-of-simple driver batch enables and > disables all the clocks w/o really looking at the names. > > Do you have a recommendation for what would be best here? I suspect > it's necessary to enable/disable the clk in a similar path(though I'm > unfortunately traveling this week so I can't validate that). Do I try > to move the clk_usb3phy_ref clock enable/disable handling to somewhere > else? If it's phy clock, we should enable/disable it in phy driver, maybe we'd better ask for help from Yu Chen > > thanks > -john
