linux-kernel - Re: [PATCH v2 3/3] clk: meson: a1: add support for Amlogic A1 clock driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1ca0c5e1-8417-c5dc-7ad1-80ea707554b2@amlogic.com>
Date:   Tue, 26 Nov 2019 10:35:17 +0800
From:   Jian Hu <jian.hu@...ogic.com>
To:     Jerome Brunet <jbrunet@...libre.com>,
        Neil Armstrong <narmstrong@...libre.com>
CC:     Kevin Hilman <khilman@...libre.com>, Rob Herring <robh@...nel.org>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Michael Turquette <mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        Qiufang Dai <qiufang.dai@...ogic.com>,
        Jianxin Pan <jianxin.pan@...ogic.com>,
        Victor Wan <victor.wan@...ogic.com>,
        Chandle Zou <chandle.zou@...ogic.com>,
        <linux-clk@...r.kernel.org>, <linux-amlogic@...ts.infradead.org>,
        <linux-arm-kernel@...ts.infradead.org>,
        <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 3/3] clk: meson: a1: add support for Amlogic A1 clock
 driver



On 2019/11/25 21:51, Jian Hu wrote:
> 
> 
> On 2019/11/25 20:30, Jerome Brunet wrote:
>>
>> On Mon 25 Nov 2019 at 13:01, Jian Hu <jian.hu@...ogic.com> wrote:
>>
>>> On 2019/11/25 18:14, Jerome Brunet wrote:
>>>>
>>>> On Thu 21 Nov 2019 at 04:21, Jian Hu <jian.hu@...ogic.com> wrote:
>>>>
>>>>> Hi, Jerome
>>>>>
>>>>> On 2019/11/20 23:35, Jerome Brunet wrote:
>>>>>>
>>>>>> On Wed 20 Nov 2019 at 10:28, Jian Hu <jian.hu@...ogic.com> wrote:
>>>>>>
>>>>>>> Hi, jerome
>>>>>>>
>>>>>>> Is there any problem about fixed_pll_dco's parent_data?
>>>>>>>
>>>>>>> Now both name and fw_name are described in parent_data.
>>>>>>
>>>>>> Yes, there is a problem.  This approach is incorrect, as I've 
>>>>>> tried to
>>>>>> explain a couple times already. Let me try to re-summarize why this
>>>>>> approach is incorrect.
>>>>>>
>>>>>> Both fw_name and name should be provided when it is possible that
>>>>>> the DT does not describe the input clock. IOW, it is only for 
>>>>>> controllers
>>>>>> which relied on the global name so far and are now starting to 
>>>>>> describe
>>>>>> the clock input in DT
>>>>>>
>>>>>> This is not your case.
>>>>>> Your controller is new and DT will have the correct
>>>>>> info
>>>>>>
>>>>>> You are trying work around an ordering issue by providing both 
>>>>>> fw_name
>>>>>> and name. This is not correct and I'll continue to nack it.
>>>>>>
>>>>>> If the orphan clock is not reparented as you would expect, I 
>>>>>> suggest you
>>>>>> try to look a bit further at how the reparenting of orphans is 
>>>>>> done in
>>>>>> CCF and why it does not match your expectation.
>>>>>>
>>>>> I have debugged the handle for orphan clock in CCF, Maybe you are 
>>>>> missing
>>>>> the last email.
>>>>
>>>> Nope, got it the first time
>>>>
>>>>> Even though the clock index exit, it will get failed for the orphan 
>>>>> clock's
>>>>> parent clock due to it has not beed added to the provider.
>>>>
>>>> If the provider is not registered yet, of course any query to it won't
>>>> work. This why I have suggested to this debug *further* :
>>>>
>>>> * Is the orphan reparenting done when a new provider is registered ?
>>>> * If not, should it be done ? is this your problem ?
>>>>
>>
>> Apparently, I was not clear enough so I'll rephrase
>>
>>> Yes, the orphan reparenting is done when the new provider is
>>> registered.
>>
>> No it is not done yet. Please check the code.
>>
>> The reparenting of orphan is done only on clock registration, not on
>> provider registeration. Now that clocks can be specified by DT, this
>> probably needs to added.The action of reparenting the orphan is before 
>> the provider registration 
> with the current code.
>>
>> That is your problem.
> Yes, if the provider is registered before the clock registration, it
> will reparent successfully.
>>
>> Please fix the underlying issue, then you can post your series again.
>>
>>>
>>> Reparenting the orphan will be done when each clock is registered by
>>> devm_clk_hw_register. And at this time the provider has not been
>>> registered. After all clocks are registered by devm_clk_hw_register, the
>>> provider will be registered by devm_of_clk_add_hw_provider.
>>>
>>> Reparenting the orphan will fail when fw_name is added alone, the 
>>> couse is
>>> that devm_clk_hw_register is always running ahead of
>>> devm_of_clk_add_hw_provider.
>>
>> Please stop bringing the topic of "fw_name" and "name" field together, I
>> told you 3 times why this is wrong. It is not going to change.
>>
>>>
>>> That is why it will failed to get parent for the orphan clock.
>>
>> It fails because the provider is not registered when you try to reparent
>> the orphan.
>>
>> It shows that you should try again once the provider is registered.
>>
> OK, I have exchanged the position for devm_clk_hw_register and 
> devm_of_clk_add_hw_provider in meson-eeclk.c.
> 
> It reparents successfully for orphan clock.
> 
> Is is ok that put devm_of_clk_add_hw_provider ahead?
> 
> As far as I am concerned, there is no any effect.Sorry, If the provider is registered first, I find it will affect the 
assigned-clock-parents and assigned-clock-rates configurations in DT 
when the provider is registered.

It will fail to set the assigned parent and assigned rate for one clock 
because of the related clocks are not registered yet.

Moreover, registering provider is always after clock registration in 
other vendor clock drivers.

Maybe registering provider is better after the clock registration.


>>>
>>>
>>>
>>>>
>>>> .
>>>>
>>
>> .
>>