Re: [PATCH RESEND v2 3/5] clk: mxl: Avoid disabling gate clocks from clk driver

[Rahul Tanwar <rtanwar@maxlinear.com>]

Hi Stephen,

On 12/10/2022 1:43 am, Stephen Boyd wrote:
> This email was sent from outside of MaxLinear.
> 
> 
> Quoting Rahul Tanwar (2022-10-11 00:28:56)
>>
>> I agree that what you are suggesting is the ideal way to handle such
>> clks. If i understand you correctly, you are suggesting below (please
>> correct me if i am mistaken):
>>
>> 1. Disable/remove such clocks from corresponding driver's devicetree
>> nodes. This will make devm_clk_get() or clk_get() return failure.
> 
> No. Don't remove anything from devicetree, simply make the clk provider
> return NULL when the clk_src_get() function pointer is asked for the clk
> index that represents the clks that have no abilities to do anything.
> 
>>
>> 2. Modify all drivers which use such clks
>>
>> from:
>>
>>      clk = devm_clk_get(...);
>>      if (IS_ERR(clk))
>>          return -ERROR;
>>      clk_prepare_enable(clk);
>>      clk_get/set_rate();
>>      ...
>>
>> to:
>>      clk = devm_clk_get(...);
>>      if (!(IS_ERR(clk)) {
>>          clk_prepare_enable(clk);
>>          clk_get/set_rate();
>>          ...
>>      } else {
>>         // print error info - do nothing, no clk_ops calls
>>      }
> 
> No. Nothing in the drivers changes. The 'clk' pointer will be NULL, that
> will not make the 'if (IS_ERR(clk))' condition be true, so return -ERROR
> won't happen. Similarly, clk_prepare_enable() will return 0 when called
> with a NULL pointer. Please try it out.
> 
>>
>> But the problem that we have is that 80% of the clks that we use fall
>> under this category (around 65 clks). And if we follow this approach,
>> then we will have to make above changes in all of the drivers which use
>> these clks & retest them again. That seems like a overhaul. We already
>> keep a internal driver flag in each clk entry data structure and we
>> already use it in the driver for other types of clks for e.g MUX_CLKs.
>> So using the internal flag to handle this becomes a preferable &
>> existing driver design aligned approach for us.
>>
> 
> There isn't an overhaul.
> 


After going through the code again together with your comments, now i 
understand exactly what you are suggesting. I will make the changes 
accordingly in v4. Thanks for your valuable inputs.

Rahul

>