From: Stephen Boyd <sboyd@kernel.org>
To: Heiko Stuebner <heiko@sntech.de>, mturquette@baylibre.com
Cc: linux-clk@vger.kernel.org, linux-kernel@vger.kernel.org,
liujianfeng1994@gmail.com, sebastian.reichel@collabora.com,
cristian.ciocaltea@collabora.com, heiko@sntech.de
Subject: Re: [PATCH v2] clk: check for disabled clock-provider in of_clk_get_hw_from_clkspec
Date: Wed, 26 Feb 2025 14:32:28 -0800 [thread overview]
Message-ID: <24b641332461006bdedd5a4d682fb040.sboyd@kernel.org> (raw)
In-Reply-To: <20250222223733.2990179-1-heiko@sntech.de>
Quoting Heiko Stuebner (2025-02-22 14:37:33)
> of_clk_get_hw_from_clkspec checks all available clock-providers by
> compairing their of-nodes to the one from the clkspec. If no matching
> clock-provider is found, the function returns EPROBE_DEFER to cause a
> re-check at a later date.
>
> If a matching clock-provider is found, an authoritative answer can be
> retrieved from it whether the clock exists or not.
>
> This does not take into account that the clock-provider may never appear,
> because it's node is disabled. This can happen for example when a clock
> is optional, provided by a separate block which just never gets enabled.
>
> One example of this happening is the rk3588's VOP, which has optional
> additional display-clock-supplies coming from PLLs inside the hdmiphy
> blocks. These can be used for better rates, but the system will also
> work without them.
>
> The problem around that is described in the followups to:
> https://lore.kernel.org/dri-devel/20250215-vop2-hdmi1-disp-modes-v1-3-81962a7151d6@collabora.com/
>
> As we already know the of-node of the presumed clock-provider, just add
> a check via of_device_is_available whether this is a "valid" device node.
> This prevents eternal defer-loops.
>
> Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
> Signed-off-by: Heiko Stuebner <heiko@sntech.de>
> ---
Applied to clk-next (unless this needs to fix something urgent?)
Please write a unit test (or many). I also wonder if we should use a
different return value so that we don't try to look up the clk by name
(see clk_core_fill_parent_index()). We could go even further and stop
trying to find the clk over and over again too. Maybe -ENODEV can
indicate that and we can cache that parent entry value so we stop
trying.
next prev parent reply other threads:[~2025-02-26 22:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-22 22:37 [PATCH v2] clk: check for disabled clock-provider in of_clk_get_hw_from_clkspec Heiko Stuebner
2025-02-26 22:32 ` Stephen Boyd [this message]
2025-02-27 14:36 ` Heiko Stübner
2025-02-27 22:02 ` Stephen Boyd
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=24b641332461006bdedd5a4d682fb040.sboyd@kernel.org \
--to=sboyd@kernel.org \
--cc=cristian.ciocaltea@collabora.com \
--cc=heiko@sntech.de \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=liujianfeng1994@gmail.com \
--cc=mturquette@baylibre.com \
--cc=sebastian.reichel@collabora.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.