From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: Karl Mehltretter <kmehltretter@gmail.com>
Cc: Georgi Djakov <djakov@kernel.org>,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] interconnect: Add kernel-doc for devm_of_icc_get(), icc_enable() and icc_disable()
Date: Mon, 7 Sep 2026 16:41:25 +0800 [thread overview]
Message-ID: <ap54tQSLFZs4N_KU@google.com> (raw)
In-Reply-To: <20260907020504.24783-1-kmehltretter@gmail.com>
Hi Karl,
On Mon, Sep 07, 2026 at 04:05:04AM +0200, Karl Mehltretter wrote:
> Documentation/driver-api/interconnect.rst lists devm_of_icc_get(),
> icc_enable() and icc_disable() in its kernel-doc directive for
> drivers/interconnect/core.c, but none of the three functions has a
> kernel-doc comment. The directive silently produces nothing for them, so
> the consumer API section of the rendered documentation never shows
> them.
>
> Add kernel-doc comments in the style of the neighbouring functions.
>
> Assisted-by: LLM
> Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
> ---
> drivers/interconnect/core.c | 31 +++++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/drivers/interconnect/core.c b/drivers/interconnect/core.c
> index 4aa991a54101..6f854375201d 100644
> --- a/drivers/interconnect/core.c
> +++ b/drivers/interconnect/core.c
> @@ -423,6 +423,17 @@ static void devm_icc_release(struct device *dev, void *res)
> icc_put(*(struct icc_path **)res);
> }
>
> +/**
> + * devm_of_icc_get() - get a path handle from a DT node based on name
> + * @dev: device pointer for the consumer device
> + * @name: interconnect path name
> + *
> + * This function is the resource managed version of of_icc_get(). The path
> + * is released with icc_put() automatically when @dev is unbound.
> + *
> + * Return: icc_path pointer on success or ERR_PTR() on error. NULL is returned
> + * when the API is disabled or the "interconnects" DT property is missing.
> + */
> struct icc_path *devm_of_icc_get(struct device *dev, const char *name)
> {
> struct icc_path **ptr, *path;
> @@ -786,12 +797,32 @@ static int __icc_enable(struct icc_path *path, bool enable)
> path->reqs[0].peak_bw);
> }
>
> +/**
> + * icc_enable() - enable a path
> + * @path: reference to the path returned by icc_get()
Since a path can also be obtained from other functions like
of_icc_get() or of_icc_get_by_index(), maybe it would be better to
describe it simply as:
* @path: interconnect path
This would also keep it consistent with neighboring functions such as
icc_set_bw() and icc_get_name().
> + *
> + * Mark all requests on the path as enabled and reapply the bandwidth that
> + * was last set with icc_set_bw(). A NULL @path is ignored.
Since __icc_enable() explicitly returns 0 when path is NULL, it might
be a bit clearer to mention the return value explicitly, e.g.:
Passing a NULL @path is a no-op and returns 0.
Regards,
Kuan-Wei
> + *
> + * Return: 0 on success, or an appropriate error code otherwise.
> + */
> int icc_enable(struct icc_path *path)
> {
> return __icc_enable(path, true);
> }
> EXPORT_SYMBOL_GPL(icc_enable);
>
> +/**
> + * icc_disable() - disable a path
> + * @path: reference to the path returned by icc_get()
> + *
> + * Mark all requests on the path as disabled, so that they no longer count
> + * towards the aggregated bandwidth, and reapply the constraints. The
> + * requested bandwidth is kept and restored by icc_enable(). A NULL @path is
> + * ignored.
> + *
> + * Return: 0 on success, or an appropriate error code otherwise.
> + */
> int icc_disable(struct icc_path *path)
> {
> return __icc_enable(path, false);
> --
> 2.53.0
>
>
prev parent reply other threads:[~2026-09-07 8:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-07 2:05 [PATCH] interconnect: Add kernel-doc for devm_of_icc_get(), icc_enable() and icc_disable() Karl Mehltretter
2026-09-07 8:41 ` Kuan-Wei Chiu [this message]
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=ap54tQSLFZs4N_KU@google.com \
--to=visitorckw@gmail.com \
--cc=djakov@kernel.org \
--cc=kmehltretter@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
/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.