> On Fri, Apr 3, 2020 at 6:56 AM Ang, Chee Hong <chee.hong....@intel.com>
> wrote:
> >
> > > On Thu, Apr 2, 2020 at 7:28 PM Ang, Chee Hong
> > > <chee.hong....@intel.com>
> > > wrote:
> > > > > On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote:
> > > > > > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass <s...@chromium.org>
> wrote:
> > > > > > > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko
>
> > > > > > > > > > > > This reverts commit
> > > 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c.
>
> > > > > Adding SoCFPGA folks to this thread as the first commit
> > > > > (82de42fa1468) is also breaking platforms there and then their
> > > > > fix for that problem is also causing problems, if I follow right.
> > >
> > > > Yes. This commit (82de42fa1468) breaks our A10 platform.
> > > > I did submit similar patch to move some init code from
> > > > ofdata_to_platdata() to
> > > probe() for our clock driver as well.
> > > > Check out the thread here:
> > > > https://lists.denx.de/pipermail/u-boot/2020-April/405252.html
> > >
> > > I see half or less of the messages in the thread by above link.
> > > Can you summarize what should have been done in order to fix this?
> > 1) Fix in the driver (broken by this commit: 82de42fa1468) by moving some
> code from ofdata_to_platdata() to probe().
> > 2) Fix the DM core.
> > Simon and Marek were discussing about these 2 options.
> > Perhaps Simon can help shed some light here.
>
> I have a question. Does revert of
> 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c makes any difference to
> SoCFPGA?
This commit: 82de42fa1468 break our SoCFPGA A10 clock driver.
This commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c does not affect our
SoCFPGA platforms.
We just want to know which way to go. Fixing our A10 clock driver or fix the DM
core.
Seems like this commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c go with option
1 (fixing the driver).
>
> --
> With Best Regards,
> Andy Shevchenko
