linux-kernel - Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAL_JsqJPcPgS=cKNqv9j5Ch3ZHbUmci1LRedBWV1gV=5kCz68Q@mail.gmail.com>
Date:	Tue, 19 Jan 2016 12:20:46 -0600
From:	Rob Herring <robh+dt@...nel.org>
To:	xuejiancheng <xuejiancheng@...wei.com>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>
Cc:	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Kumar Gala <galak@...eaurora.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Kevin Hilman <khilman@...aro.org>,
	Arnd Bergmann <arnd@...db.de>, Olof Johansson <olof@...om.net>,
	Wei Xu <xuwei5@...ilicon.com>,
	Haojian Zhuang <haojian.zhuang@...aro.org>,
	Zhangfei Gao <zhangfei.gao@...aro.org>,
	Bintian Wang <bintian.wang@...wei.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-clk <linux-clk@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>, yanhaifeng@...ilicon.com,
	yanghongwei@...ilicon.com, suwenping@...ilicon.com,
	ml.yang@...ilicon.com, gaofei@...ilicon.com,
	zhangzhenxing@...ilicon.com, xuejiancheng@...ilicon.com
Subject: Re: [PATCH v5 1/6] clk: hisilicon: add CRG driver for hi3519 soc

On Fri, Jan 15, 2016 at 1:57 AM, xuejiancheng <xuejiancheng@...wei.com> wrote:
>
> On 2016/1/14 21:16, xuejiancheng wrote:
>> Hi Mike,
>>
>> On 2016/1/14 2:57, Michael Turquette wrote:
>>> Quoting xuejiancheng (2016-01-12 19:03:01)
>>>> Hi Stephen,
>>>>    Thank you very much for your reply.
>>>>
>>>> On 2016/1/13 6:12, Stephen Boyd wrote:
>>>>> On 01/08, Jiancheng Xue wrote:
>>>>>> diff --git a/drivers/clk/hisilicon/Kconfig b/drivers/clk/hisilicon/Kconfig
>>>>>> index e434854..b6baebf 100644
>>>>>> --- a/drivers/clk/hisilicon/Kconfig
>>>>>> +++ b/drivers/clk/hisilicon/Kconfig
>>>>>> @@ -1,3 +1,10 @@
>>>>>> +config COMMON_CLK_HI3519
>>>>>> +    tristate "Clock Driver for Hi3519"
>>>>>
>>>>> It looks like this has to be bool. Otherwise it needs to be a
>>>>> platform driver and the hisilicon APIs need to be exported and
>>>>> lose their __init markings.
>>>>>
>>>> Yes,it's a problem. I will fix it in next version. Thank you.
>>>
>>> The best solution would be to make this clock driver a real platform
>>> driver.
>>>
>> Now the work clock of the clocksource timer-sp804 is provided by this driver. So
>> it need to be registered early by CLK_OF_DECLARE. If the timer clock is treated
>> as a fixed-clock provider, this driver can be implemented as a platform driver.
>> Then the crg device must be registered before other clock consumer devices.Accordingly
>> the crg device node must be written above all other clock consumer devices node in dts files.
>> I think it is also a dependence.
>>
>> Can you help me understand why it is better to make this driver a platform driver?
>> Thank you very much!
>>
> arch_initcall(customize_machine)
> -->of_platform_populate
>    -->of_platform_bus_create
>      -->of_amba_device_create
>         -->amba_device_add
>            -->amba_get_enable_pclk
> The call sequence above shows that the clock of the amba device must be registered before
> amba_device_add. The clock of "arm,pl011" uart is registered in the probe function of the
> platform driver "hi3519-crg". So the platform device "hi3519-crg" must be created before
> the amba device "arm,pl011" uart.

It is a problem, but Tomeu had a fix to support deferred probes here.
That was part of the on-demand probing series, but maybe it needs to
be applied separately if we are moving clock drivers to platform
drivers.

Rob