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

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

[Marek Vasut]

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@denx.de>
Cc: Peng Fan <peng.fan@oss.nxp.com>
Cc: Simon Glass <sjg@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;
 }
-- 
2.34.1

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

[Sean Anderson]

Hi Marek,

Please CC clock maintainers for future patches.

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@denx.de>
> Cc: Peng Fan <peng.fan@oss.nxp.com>
> Cc: Simon Glass <sjg@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,
   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'.

--Sean

[1] https://lore.kernel.org/u-boot/20211029012801.15193-1-peng.fan@oss.nxp.com/

Re: [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@denx.de>
>> Cc: Peng Fan <peng.fan@oss.nxp.com>
>> Cc: Simon Glass <sjg@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.

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 3464 bytes --]

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@denx.de>
> > > Cc: Peng Fan <peng.fan@oss.nxp.com>
> > > Cc: Simon Glass <sjg@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Marek Vasut]

On 1/5/22 20:37, Tom Rini wrote:
> 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@denx.de>
>>>> Cc: Peng Fan <peng.fan@oss.nxp.com>
>>>> Cc: Simon Glass <sjg@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.

So it seems. Does that mean we are OK with releasing such a broken 
release, even though there is an easy way to improve the situation ?

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

[Sean Anderson]

On 1/5/22 2:37 PM, Tom Rini wrote:
> 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.

At the time, I reviewed it. However, I was also not a clock maintainer
at that point, and my RB was not picked up when Simon sent v2.

Ultimately the original problem was that errors when assigning clocks
automatically were generally not reported. The only way to detect them
was to verify that the clocks were configured correctly after the fact.
My attempt to address this was [2].

[1] https://lore.kernel.org/u-boot/e9eea30a-970b-7d70-267f-520071b483f1@gmail.com/
[2] https://lore.kernel.org/u-boot/20210409021313.433558-2-seanga2@gmail.com/

>>> 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@denx.de>
>>>> Cc: Peng Fan <peng.fan@oss.nxp.com>
>>>> Cc: Simon Glass <sjg@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.

Sure, but since those assignments are made only when the device is
probed, it is generally safe to assume that they are necessary for the
device to function. This is opposed to assignments in the clock node,
which may be OK to ignore (as long as the system functions properly).

>>>     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.

I agree with Marek here. We knew this broke boards before v2021.10 was
released, but it was not reverted for that release. We should not make
the same mistake again.
Reviewed-by: Sean Anderson <seanga2@gmail.com>

[3] https://lore.kernel.org/u-boot/dbde2b83044ce9f3e8c360e9ddce0fa8db16f8ef.camel@nedap.com/

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

[Fabio Estevam]

Hi Marek,

On Sat, Jan 1, 2022 at 3:51 PM Marek Vasut <marex@denx.de> 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@denx.de>
> Cc: Peng Fan <peng.fan@oss.nxp.com>
> Cc: Simon Glass <sjg@chromium.org>

Reviewed-by: Fabio Estevam <festevam@gmail.com>

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 4240 bytes --]

On Wed, Jan 05, 2022 at 08:56:50PM +0100, Marek Vasut wrote:
> On 1/5/22 20:37, Tom Rini wrote:
> > 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@denx.de>
> > > > > Cc: Peng Fan <peng.fan@oss.nxp.com>
> > > > > Cc: Simon Glass <sjg@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.
> 
> So it seems. Does that mean we are OK with releasing such a broken release,
> even though there is an easy way to improve the situation ?

I will defer to the clock maintainer who I see agrees with your patch.
I was just noting that we'd already shipped one release so a last minute
revert is not something I'm happy about either.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Simon Glass]

Hi,

On Wed, 5 Jan 2022 at 13:57, Tom Rini <trini@konsulko.com> wrote:
>
> On Wed, Jan 05, 2022 at 08:56:50PM +0100, Marek Vasut wrote:
> > On 1/5/22 20:37, Tom Rini wrote:
> > > 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@denx.de>
> > > > > > Cc: Peng Fan <peng.fan@oss.nxp.com>
> > > > > > Cc: Simon Glass <sjg@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.
> >
> > So it seems. Does that mean we are OK with releasing such a broken release,
> > even though there is an easy way to improve the situation ?
>
> I will defer to the clock maintainer who I see agrees with your patch.
> I was just noting that we'd already shipped one release so a last minute
> revert is not something I'm happy about either.

I'll just note that we should not be ignoring errors. It makes things
very hard to debug. The root cause of this issue, IMO, is that the
clock subsystem started ignoring errors. People relied on that and
then it was hard to put the cat back in the bag.

But we should put the cat back in the bag and use a DT property to
indicate that the defaults are advisory only, for the case where the
U-Boot driver does not support a clock.

So long we we can undo this patch immediately after the release, you can add my:
Reviewed-by: Simon Glass <sjg@chromium.org>

Regards,
Simon

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

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

On Sat, Jan 01, 2022 at 07:51:39PM +0100, 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@denx.de>
> Cc: Peng Fan <peng.fan@oss.nxp.com>
> Cc: Simon Glass <sjg@chromium.org>
> Reviewed-by: Sean Anderson <seanga2@gmail.com>
> Reviewed-by: Fabio Estevam <festevam@gmail.com>
> Reviewed-by: Simon Glass <sjg@chromium.org>

Applied to u-boot/master, thanks!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

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

[Sean Anderson]

Hi Tom,

On 1/5/22 3:57 PM, Tom Rini wrote:
> I will defer to the clock maintainer who I see agrees with your patch.
> I was just noting that we'd already shipped one release so a last minute
> revert is not something I'm happy about either.

Do you want me to send a PR for this or can you pick it up directly?

--Sean

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

[Fabio Estevam]

On Sun, Jan 9, 2022 at 5:32 PM Sean Anderson <seanga2@gmail.com> wrote:

> Do you want me to send a PR for this or can you pick it up directly?

This one has already been applied:
https://source.denx.de/u-boot/u-boot/-/commit/75f080df46f28f24a617652c8af028cc349f908b