All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Maxime Ripard <maxime@cerno.tech>,
	Michael Turquette <mturquette@baylibre.com>
Cc: linux-kernel@vger.kernel.org,
	AngeloGioacchino Del Regno 
	<angelogioacchino.delregno@collabora.com>,
	Maxime Ripard <maxime@cerno.tech>,
	linux-clk@vger.kernel.org
Subject: Re: [PATCH 4/4] clk: Warn if we register a mux without determine_rate
Date: Tue, 25 Oct 2022 19:07:58 -0700	[thread overview]
Message-ID: <20221026020800.38AC8C433C1@smtp.kernel.org> (raw)
In-Reply-To: <20221018-clk-range-checks-fixes-v1-4-f3ef80518140@cerno.tech>

Quoting Maxime Ripard (2022-10-18 06:52:59)
> The determine_rate hook allows to select the proper parent and its rate
> for a given clock configuration. On another hand, set_parent is there to
> change the parent of a mux.
> 
> Some clocks provide a set_parent hook but don't implement
> determine_rate. In such a case, set_parent is pretty much useless since
> the clock framework will always assume the current parent is to be used,
> and we will thus never change it.
> 
> This situation can be solved in two ways:
>   - either we don't need to change the parent, and we thus shouldn't
>     implement set_parent;
>   - or we don't want to change the parent, in this case we should set
>     CLK_SET_RATE_NO_REPARENT;
>   - or we're missing a determine_rate implementation.
> 
> The latter is probably just an oversight from the driver's author, and
> we should thus raise their awareness about the fact that the current
> state of the driver is confusing.

There is another case which is a leaf clk that is a mux where you only
expect clk_set_parent() to be used, and not clk_set_rate(). This use
case is odd though, so I'm not sure how much we care.

> 
> It's not clear at this point how many drivers are affected though, so
> let's make it a warning instead of an error for now.
> 
> Signed-off-by: Maxime Ripard <maxime@cerno.tech>
> ---
>  drivers/clk/clk.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 57b83665e5c3..11c41d987ff4 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -3700,6 +3700,11 @@ static int __clk_core_init(struct clk_core *core)
>                 goto out;
>         }
>  
> +       /* TODO: Promote to an error */

The documentation should be updated in this patch (see the table of
hardware characteristics in Documentation/driver-api/clk.rst).

> +       if (core->ops->set_parent && !core->ops->determine_rate)
> +               pr_warn("%s: %s must implement .set_parent & .determine_rate\n",

You can grep for it:

 $ git grep -W 'struct clk_ops .*='

but I'm fairly certain a coccinelle script can detect most of these
because clk_ops are usually statically defined (although not always).

Either way I already see that 'owl_comp_div_ops' will trigger this
warning. And 'at91sam9x5_smd_ops' looks even more likely. Given that I'm
not super keen on applying this patch.

  parent reply	other threads:[~2022-10-26  2:08 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18 13:52 [PATCH 0/4] clk: Rate range improvements Maxime Ripard
2022-10-18 13:52 ` [PATCH 1/4] clk: Remove WARN_ON NULL parent in clk_core_init_rate_req() Maxime Ripard
2022-10-18 14:35   ` AngeloGioacchino Del Regno
2022-10-28  0:06   ` Stephen Boyd
2022-10-18 13:52 ` [PATCH 2/4] clk: Initialize the clk_rate_request even if clk_core is NULL Maxime Ripard
2022-10-18 14:35   ` AngeloGioacchino Del Regno
2022-10-28  0:09   ` Stephen Boyd
2022-10-18 13:52 ` [PATCH 3/4] clk: Initialize max_rate in struct clk_rate_request Maxime Ripard
2022-10-18 14:35   ` AngeloGioacchino Del Regno
2022-10-28  0:09   ` Stephen Boyd
2022-10-18 13:52 ` [PATCH 4/4] clk: Warn if we register a mux without determine_rate Maxime Ripard
2022-10-18 14:34   ` AngeloGioacchino Del Regno
2022-10-26  2:07   ` Stephen Boyd [this message]
2022-10-26 13:52     ` maxime
2022-10-27 21:45       ` Stephen Boyd
2022-11-03 12:39         ` Maxime Ripard
2022-11-03 12:33     ` Maxime Ripard
2022-11-04 18:10       ` 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=20221026020800.38AC8C433C1@smtp.kernel.org \
    --to=sboyd@kernel.org \
    --cc=angelogioacchino.delregno@collabora.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime@cerno.tech \
    --cc=mturquette@baylibre.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.