+ Lukasz On Wed, Jan 1, 2020 at 4:12 AM Sean Anderson <sean...@gmail.com> wrote: > > CCF clocks should always use the struct clock passed to their methods for > extracting the driver-specific clock information struct. Previously, many > functions would use the clk->dev->priv if the device was bound. This could > cause > problems with composite clocks. The individual clocks in a composite clock did > not have the ->dev field filled in. This was fine, because the device-specific > clock information would be used. However, since there was no ->dev, there was > no > way to get the parent clock. This caused the recalc_rate method of the CCF > divider clock to fail. One option would be to use the clk->priv field to get > the > composite clock and from there get the appropriate parent device. However, > this > would tie the implementation to the composite clock. In general, different > devices should not rely on the contents of ->priv from another device. > > The simple solution to this problem is to just always use the supplied struct > clock. The composite clock now fills in the ->dev pointer of its child clocks. > This allows child clocks to make calls like clk_get_parent() without issue. > > imx avoided the above problem by using a custom get_rate function with > composite > clocks. > > Signed-off-by: Sean Anderson <sean...@gmail.com> > ---
Acked-by: Jagan Teki <ja...@amarulasolutions.com>