linux-kernel - RE: [PATCH] clk:aspeed:Fix reset driver probe from builtin_platform to core

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: <HK0PR06MB33804909AFB349EEECAF9D4BF2BC9@HK0PR06MB3380.apcprd06.prod.outlook.com>
Date:   Mon, 18 Oct 2021 00:54:42 +0000
From:   Ryan Chen <ryan_chen@...eedtech.com>
To:     Stephen Boyd <sboyd@...nel.org>, Andrew Jeffery <andrew@...id.au>,
        Joel Stanley <joel@....id.au>,
        Michael Turquette <mturquette@...libre.com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] clk:aspeed:Fix reset driver probe from builtin_platform
 to core_initcal

Hello,
> -----Original Message-----
> From: Stephen Boyd <sboyd@...nel.org>
> Sent: Sunday, October 17, 2021 9:45 AM
> To: Andrew Jeffery <andrew@...id.au>; Joel Stanley <joel@....id.au>; Michael
> Turquette <mturquette@...libre.com>; linux-clk@...r.kernel.org;
> linux-kernel@...r.kernel.org; Ryan Chen <ryan_chen@...eedtech.com>
> Subject: Re: [PATCH] clk:aspeed:Fix reset driver probe from builtin_platform to
> core_initcal
> 
> Quoting Ryan Chen (2021-10-04 23:45:13)
> > Change the reset probe sequence from builtin_platform to core_initcal.
> > For avoid some driver is probe but failed due to reset driver not probe.
> 
> I don't get it. Does something never try probe again because it can't get the
> reset it wants? I understand that builtin_platform_driver() moves the initcall
> level later than core_initcall() so this is a workaround for some driver probe
> ordering problem?
The most of driver have reset function in probe. if driver probe need do the reset 
(ex: devm_reset_control_get_shared) but reset driver not ready (devm_reset_controller_register),
that driver probe will cause the fail, than after reset driver probe, there will have second probe In driver. 
That the reason I put reset probe in core_initcall.
And also you can see that the reason most soc chip do the devm_reset_controller_register in core_initcall.

> 
> >
> > Fixes: d3d04f6c330a ("clk: Add support for AST2600 SoC")
> > Signed-off-by: Ryan Chen <ryan_chen@...eedtech.com>