On 2/18/20 2:20 AM, Rick Chen wrote: > Hi Sean > >> For clocks not in the CCF, their parents will not have UCLASS_CLK, so we >> just enable them as normal. The enable count is local to the struct clk, >> but this will never result in the actual en-/dis-able op being called >> (unless the same struct clk is enabled twice). >> >> For clocks in the CCF, we always traverse up the tree when enabling. >> Previously, CCF clocks without id set would be skipped, stopping the >> traversal too early. >> >> Signed-off-by: Sean Anderson <sean...@gmail.com> >> Acked-by: Lukasz Majewski <lu...@denx.de> >> --- >> >> Changes in v4: >> - Lint >> >> Changes in v3: >> - New >> >> drivers/clk/clk-uclass.c | 59 ++++++++++++++++++---------------------- >> 1 file changed, 26 insertions(+), 33 deletions(-) >> > > When I tried to apply this patch-set, there occur a conflict as below: > > Applying: clk: Always use the supplied struct clk > Applying: clk: Check that ops of composite clock components exist before > calling > Applying: clk: Unconditionally recursively en-/dis-able clocks > error: patch failed: drivers/clk/clk-uclass.c:491 > error: drivers/clk/clk-uclass.c: patch does not apply > Patch failed at 0003 clk: Unconditionally recursively en-/dis-able clocks > > Thanks > Rick
Hm, perhaps you are applying it on a different commit. My series is based off of c00bd81ae0 Merge branch 'next' of https://gitlab.denx.de/u-boot/custodians/u-boot-mpc83xx What are you applying to? --Sean
