linux-kernel - Re: [PATCH v5 4/4] clk: eyeq: add 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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <02cbfefaf7db9220652c2f9605838f96.sboyd@kernel.org>
Date: Wed, 23 Oct 2024 15:12:35 -0700
From: Stephen Boyd <sboyd@...nel.org>
To: Conor Dooley <conor+dt@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Michael Turquette <mturquette@...libre.com>, Rob Herring <robh@...nel.org>, Théo Lebrun <theo.lebrun@...tlin.com>
Cc: devicetree@...r.kernel.org, linux-clk@...r.kernel.org, linux-kernel@...r.kernel.org, Vladimir Kondratiev <vladimir.kondratiev@...ileye.com>, Grégory Clement <gregory.clement@...tlin.com>, Thomas Petazzoni <thomas.petazzoni@...tlin.com>, Tawfik Bayouk <tawfik.bayouk@...ileye.com>
Subject: Re: [PATCH v5 4/4] clk: eyeq: add driver

Quoting Théo Lebrun (2024-10-23 04:08:31)
> On Thu Oct 17, 2024 at 8:48 PM CEST, Stephen Boyd wrote:
> > Quoting Théo Lebrun (2024-10-07 06:49:19)
> > > +/* Required early for UART. */
> >
> > I still don't get this. UART isn't an early device. It's only the
> > interrupt controller and the timer that matter. Does MIPS do something
> > special for UARTs?
> 
> Our hardware has a PL011. That is AMBA stuff; they get probed before
> platform devices by of_platform_bus_create(). "pll-per" on EyeQ5 must
> be available at that time.
> 
> In concrete terms, if we don't register pll-per on EyeQ5 at
> of_clk_init(), we stare at void because the serial fails probing.
> I haven't digged into why EPROBE_DEFER doesn't do its job. Anyway we
> don't want our serial to stall for some time during our boot process.
> 

Ok thanks for the details. It sounds like there's a bug in there
somewhere. Eventually this should be removed.

Can you dump_stack() in clk_get() when the "pll-per" clk is claimed?

I suspect of_clk_get_hw_from_clkspec() is seeing NULL if
of_clk_hw_onecell_get() is being used and the clk_hw pointer isn't set
yet. NULL is a valid clk and it will be returned to the consumer. You'll
want to write a custom 'get' function for of_clk_add_hw_provider() that
returns -EPROBE_DEFER for any clk that isn't registered early. Then the
AMBA stuff should defer probe until the "full" clk provider is
registered.