[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <6a57032b-3726-4074-9212-f0f16269f11c@kernel.org>
Date: Mon, 10 Nov 2025 12:38:47 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Gary Yang <gary.yang@...tech.com>,
"p.zabel@...gutronix.de" <p.zabel@...gutronix.de>,
"robh@...nel.org" <robh@...nel.org>, "krzk+dt@...nel.org"
<krzk+dt@...nel.org>, "conor+dt@...nel.org" <conor+dt@...nel.org>
Cc: "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
cix-kernel-upstream <cix-kernel-upstream@...tech.com>
Subject: Re: 回复: 回复: [PATCH 2/3] Reset: cix: add support for cix sky1 resets
On 10/11/2025 12:32, Gary Yang wrote:
> Hi krzysztof:
>
>> -----邮件原件-----
>> 发件人: Krzysztof Kozlowski <krzk@...nel.org>
>> 发送时间: 2025年11月10日 19:22
>> 收件人: Gary Yang <gary.yang@...tech.com>; p.zabel@...gutronix.de;
>> robh@...nel.org; krzk+dt@...nel.org; conor+dt@...nel.org
>> 抄送: devicetree@...r.kernel.org; linux-kernel@...r.kernel.org;
>> linux-arm-kernel@...ts.infradead.org; cix-kernel-upstream
>> <cix-kernel-upstream@...tech.com>
>> 主题: Re: 回复: [PATCH 2/3] Reset: cix: add support for cix sky1 resets
>>
>> EXTERNAL EMAIL
>>
>> On 10/11/2025 12:18, Gary Yang wrote:
>>>>
>>>>> +static struct platform_driver sky1_reset_driver = {
>>>>> + .probe = sky1_reset_probe,
>>>>> + .driver = {
>>>>> + .name = KBUILD_MODNAME,
>>>>> + .of_match_table = sky1_reset_dt_ids,
>>>>> + },
>>>>> +};
>>>>> +static int __init reset_sky1_init(void) {
>>>>> + return platform_driver_register(&sky1_reset_driver);
>>>>> +}
>>>>> +subsys_initcall(reset_sky1_init);
>>>>
>>>> This should be rather just module_platform_driver. Does not look like
>>>> part of subsystem, but looks like regular driver.
>>>>
>>>
>>> Some modules depend reset module. When boot system, these modules
>> can't probe before register reset.
>>
>> Which modules? You statement is so imprecise that my only answer is:
>> sorry, deferred probe is old thing now and everyone should use it.
>>
>>> To make these modules probe earlier, we use subsys_initcall() to
>>> instead of module_platform_driver(). Do you have better suggestions?
>>
>> Look how deferred probe works.
>>
>
> Yes, you're right. But deferred probe needs to take more time on booting.
> To make the boot faster, better experiences, we have to use subsys_initcall()
Again, imprecise statement. How faster? With such arguments - twice
(first list of unspecified modules and now of unspecified boot faster)
the answer is the same. And I will not wait for third imprecise
argument, because this is not a ping pong game.
Anyway, manual core ordering is not the solution.
Best regards,
Krzysztof
Powered by blists - more mailing lists