[PATCH] Revert "clk: Detect failure to set defaults"
Tom Rini
trini at konsulko.com
Wed Jan 5 20:37:08 CET 2022
On Wed, Jan 05, 2022 at 08:35:19PM +0100, Marek Vasut wrote:
> On 1/1/22 22:41, Sean Anderson wrote:
> > Hi Marek,
>
> Hi,
>
> > Please CC clock maintainers for future patches.
>
> btw. I'm surprised the commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646 has
> zero reviews/acks from clock maintainers.
>
> > On 1/1/22 1:51 PM, Marek Vasut wrote:
> > > This reverts commit 92f1e9a4b31c0bf0f4f61ab823a6a88657323646.
> > > The aforementioned patch causes massive breakage on all platforms which
> > > have 'assigned-clock' DT property in their DT which references any clock
> > > that are not supported by the platform clock driver. That can easily
> > > happen either in SPL, or because the clock driver is reduced. Currently
> > > it seems all iMX8M are affected and fail to boot altogether.
> > >
> > > Signed-off-by: Marek Vasut <marex at denx.de>
> > > Cc: Peng Fan <peng.fan at oss.nxp.com>
> > > Cc: Simon Glass <sjg at chromium.org>
> > > ---
> > > drivers/clk/clk-uclass.c | 6 +-----
> > > 1 file changed, 1 insertion(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/clk/clk-uclass.c b/drivers/clk/clk-uclass.c
> > > index f2d26427543..094b1abf13c 100644
> > > --- a/drivers/clk/clk-uclass.c
> > > +++ b/drivers/clk/clk-uclass.c
> > > @@ -846,17 +846,13 @@ void devm_clk_put(struct udevice *dev, struct
> > > clk *clk)
> > > int clk_uclass_post_probe(struct udevice *dev)
> > > {
> > > - int ret;
> > > -
> > > /*
> > > * when a clock provider is probed. Call clk_set_defaults()
> > > * also after the device is probed. This takes care of cases
> > > * where the DT is used to setup default parents and rates
> > > * using assigned-clocks
> > > */
> > > - ret = clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > - if (ret)
> > > - return log_ret(ret);
> > > + clk_set_defaults(dev, CLK_DEFAULTS_POST);
> > > return 0;
> > > }
> > >
> >
> > See [1] for previous discussion. For more background,
> >
> > - Device trees for i.MX are sync'd with Linux.
> > - General clock assignments may live in the clock-controller node,
>
> clock assignments can be anywhere, even in non-clock-controller nodes.
>
> > including those which U-Boot does not implement, but which Linux does.
> > It's OK to not set up these clocks, but U-Boot doesn't know that and
> > fails.
> >
> > We don't necessarily need to revert this commit, but we do need a way to
> > say "it's OK not to set the defaults, since we can function without
> > them". Tom suggested doing this in the clock driver last time. I think a
> > Kconfig or a device tree property would work, perhaps something like
> > 'u-boot,clock-defaults-optional'.
>
> We didn't need custom DT properties before, Linux doesn't need them either,
> so that approach seems wrong.
>
> If the clock driver could say "skip unimplemented clock, because I don't
> implement them and that is OK", that sounds like the right approach.
>
> Unless the 2022.01 release should be completely broken for a lot of
> platforms, I would propose we revert the clock uclass patch now and re-add
> it right after the release, so we would not roll out a completely broken
> release and would have more time to fix this properly.
It'll be no more broken than v2021.10 was for whatever platforms have
problems here, yes? Since that's what has the problematic commit.
--
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20220105/3ba3d669/attachment.sig>
More information about the U-Boot
mailing list