public inbox for linux-clk@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Boyd <sboyd@kernel.org>
To: Maxime Ripard <maxime@cerno.tech>,
	Mike Turquette <mturquette@baylibre.com>,
	linux-clk@vger.kernel.org
Cc: Naresh Kamboju <naresh.kamboju@linaro.org>,
	Alexander Stein <alexander.stein@ew.tq-group.com>,
	Marek Szyprowski <m.szyprowski@samsung.com>,
	Tony Lindgren <tony@atomide.com>,
	Jerome Brunet <jbrunet@baylibre.com>,
	Yassine Oudjana <y.oudjana@protonmail.com>,
	Neil Armstrong <narmstrong@baylibre.com>,
	Maxime Ripard <maxime@cerno.tech>
Subject: Re: [PATCH 14/22] clk: Introduce clk_hw_init_rate_request()
Date: Fri, 22 Apr 2022 20:46:21 -0700	[thread overview]
Message-ID: <20220423034623.A43CBC385A0@smtp.kernel.org> (raw)
In-Reply-To: <20220408091037.2041955-15-maxime@cerno.tech>

Quoting Maxime Ripard (2022-04-08 02:10:29)
> diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
> index 399080456e45..83dd5f1df0b9 100644
> --- a/drivers/clk/clk.c
> +++ b/drivers/clk/clk.c
> @@ -1396,6 +1396,26 @@ static void clk_core_init_rate_req(struct clk_core * const core,
>         }
>  }
>  
> +/**
> + * clk_hw_init_rate_request - Initializes a clk_rate_request
> + * @hw: the clk for which we want to submit a rate request
> + * @req: the clk_rate_request structure we want to initialise
> + * @rate: the rate which is to be requested
> + *
> + * Initializes and fills a clk_rate_request structure to submit to

s/and fills//

> + * __clk_determine_rate or similar functions.

__clk_determine_rate()

> + */
> +void clk_hw_init_rate_request(struct clk_hw * const hw,

I don't get why it isn't 'const struct clk_hw *hw', but it looks to be
following clk_core_init_rate_req() so that can be figured out later.
Please remove the const from here regardless; it's not doing anything.

> +                             struct clk_rate_request *req,
> +                             unsigned long rate)
> +{
> +       if (WARN_ON(!hw || !req))

Why would you call it without those two items? Another copy/paste from
clk_core_init_rate_req()?

> +               return;
> +
> +       clk_core_init_rate_req(hw->core, req, rate);
> +}
> +EXPORT_SYMBOL_GPL(clk_hw_init_rate_request);
> +
>  static bool clk_core_can_round(struct clk_core * const core)
>  {
>         return core->ops->determine_rate || core->ops->round_rate;
> diff --git a/include/linux/clk-provider.h b/include/linux/clk-provider.h
> index c10dc4c659e2..39e4ed301ec5 100644
> --- a/include/linux/clk-provider.h
> +++ b/include/linux/clk-provider.h
> @@ -42,6 +42,8 @@ struct dentry;
>   * struct clk_rate_request - Structure encoding the clk constraints that
>   * a clock user might require.
>   *
> + * Should be initialized by calling clk_hw_init_rate_request().

How is that enforced?

This has only become a problem after commit 948fb0969eae ("clk: Always
clamp the rounded rate") from what I can tell. I guess we can't skip the
clamp when both min/max are zero though because it may be stack junk?
But I looked at all the call sites and either they zero initialize the
whole struct (qcom) or they copy the req from what is passed into the
determine_rate clk_op (others). So we could simply not clamp if both
values are equal to zero and then qcom would be happy, but that has been
fixed by setting the min/max to 0 and max instead. That leaves the other
users, which already copy what is being passed in, i.e. what is done by
clk_core_init_rate_req().

I guess my question is who is going to use this? And if we can't even
enforce that it is used then it feels like we shouldn't add it. Maybe it
can be useful to cleanup the core request initialization logic because
it's sort of spread out but probably not as a clk_hw API.

> + *
>   * @rate:              Requested clock rate. This field will be adjusted by
>   *                     clock drivers according to hardware capabilities.
>   * @min_rate:          Minimum rate imposed by clk users.

  reply	other threads:[~2022-04-23  3:46 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-08  9:10 [PATCH 00/22] clk: More clock rate fixes and tests Maxime Ripard
2022-04-08  9:10 ` [PATCH 01/22] clk: Drop the rate range on clk_put() Maxime Ripard
2022-04-08  9:10 ` [PATCH 02/22] clk: tests: Add test suites description Maxime Ripard
2022-04-23  4:06   ` Stephen Boyd
2022-04-08  9:10 ` [PATCH 03/22] clk: tests: Add reference to the orphan mux bug report Maxime Ripard
2022-04-08  9:10 ` [PATCH 04/22] clk: tests: Add tests for uncached clock Maxime Ripard
2022-04-08  9:10 ` [PATCH 05/22] clk: tests: Add tests for single parent mux Maxime Ripard
2022-04-08  9:10 ` [PATCH 06/22] clk: tests: Add tests for mux with multiple parents Maxime Ripard
2022-04-08  9:10 ` [PATCH 07/22] clk: tests: Add some tests for orphan " Maxime Ripard
2022-04-08  9:10 ` [PATCH 08/22] clk: Take into account uncached clocks in clk_set_rate_range() Maxime Ripard
2022-04-08  9:10 ` [PATCH 09/22] clk: Fix clk_get_parent() documentation Maxime Ripard
2022-04-08  9:10 ` [PATCH 10/22] clk: Set req_rate on reparenting Maxime Ripard
2022-04-08  9:10 ` [PATCH 11/22] clk: Skip set_rate_range if our clock is orphan Maxime Ripard
2022-04-08  9:10 ` [PATCH 12/22] clk: Add our request boundaries in clk_core_init_rate_req Maxime Ripard
2022-04-08  9:10 ` [PATCH 13/22] clk: Change clk_core_init_rate_req prototype Maxime Ripard
2022-04-08  9:10 ` [PATCH 14/22] clk: Introduce clk_hw_init_rate_request() Maxime Ripard
2022-04-23  3:46   ` Stephen Boyd [this message]
2022-04-23  7:17     ` Maxime Ripard
2022-04-08  9:10 ` [PATCH 15/22] clk: Add missing clk_core_init_rate_req calls Maxime Ripard
2022-04-23  3:51   ` Stephen Boyd
2022-04-23  7:32     ` Maxime Ripard
2022-04-08  9:10 ` [PATCH 16/22] clk: Remove redundant clk_core_init_rate_req() call Maxime Ripard
2022-04-23  4:02   ` Stephen Boyd
2022-04-23  7:44     ` Maxime Ripard
2022-04-08  9:10 ` [PATCH 17/22] clk: Switch from __clk_determine_rate to clk_core_round_rate_nolock Maxime Ripard
2022-04-08  9:10 ` [PATCH 18/22] clk: Introduce clk_core_has_parent() Maxime Ripard
2022-04-08  9:10 ` [PATCH 19/22] clk: Stop forwarding clk_rate_requests to the parent Maxime Ripard
2022-04-08  9:10 ` [PATCH 20/22] clk: Zero the clk_rate_request structure Maxime Ripard
2022-04-08  9:10 ` [PATCH 21/22] clk: Test the clock pointer in clk_hw_get_name() Maxime Ripard
2022-04-08  9:10 ` [PATCH 22/22] clk: Prevent a clock without a rate to register Maxime Ripard
2022-04-08  9:18   ` Jerome Brunet
2022-04-08 10:41     ` Maxime Ripard
2022-04-08 11:24       ` Jerome Brunet
2022-04-08 12:55         ` Maxime Ripard
2022-04-08 14:48           ` Jerome Brunet
2022-04-08 15:36             ` Maxime Ripard
2022-04-11  7:40               ` Neil Armstrong
2022-04-12 12:56                 ` Maxime Ripard
2022-04-11  8:20               ` Jerome Brunet
2022-04-23  4:42       ` Stephen Boyd
2022-04-23  9:17         ` Maxime Ripard
2022-04-29  2:08           ` Stephen Boyd
2022-04-29 15:45             ` Maxime Ripard
2022-04-08 12:17     ` Marek Szyprowski
2022-04-08 12:25       ` Maxime Ripard
2022-04-08 13:46         ` Marek Szyprowski
2022-04-23  4:12   ` Stephen Boyd
2022-04-23  7:49     ` Maxime Ripard
2022-04-10 12:06 ` [PATCH 00/22] clk: More clock rate fixes and tests Yassine Oudjana
2022-04-11 11:39   ` Maxime Ripard
2022-04-11  6:25 ` (EXT) " Alexander Stein
2022-04-11  7:24   ` Alexander Stein
2022-04-11 11:54     ` Maxime Ripard

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=20220423034623.A43CBC385A0@smtp.kernel.org \
    --to=sboyd@kernel.org \
    --cc=alexander.stein@ew.tq-group.com \
    --cc=jbrunet@baylibre.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    --cc=maxime@cerno.tech \
    --cc=mturquette@baylibre.com \
    --cc=naresh.kamboju@linaro.org \
    --cc=narmstrong@baylibre.com \
    --cc=tony@atomide.com \
    --cc=y.oudjana@protonmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox