[PATCH] Revert "clk: Detect failure to set defaults"

[Marek Vasut]

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.