All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Geert Uytterhoeven" <geert+renesas@glider.be>
Cc: devicetree@vger.kernel.org, wsa+renesas@sang-engineering.com,
	conor+dt@kernel.org, linux-clk@vger.kernel.org, robh@kernel.org
Subject: Re: [PATCH v3 09/12] clk: renesas: r8a78000: Add SCMI remapping support
Date: Wed, 02 Sep 2026 11:41:15 +0000	[thread overview]
Message-ID: <20260902114115.B1D6E1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <2a88d6c67bc8218d21f5180842354ed62c0c2aac.1788338320.git.geert+renesas@glider.be>

Thank you for your contribution! Sashiko AI review found 4 potential issue(s) to consider:
- [High] Leaked consumer `struct clk` instances and module references in `fill_clk_map()`.
- [High] Dangling `clk_hw` pointer dereference (Use-After-Free) due to missing device link to the SCMI provider.
- [Medium] Device node reference for `scmi_clk_np` is leaked on all exit paths in `r8a78000_cpg_probe`.
- [Low] Invalid `IS_ERR` check on `clk_hw` pointer resulting in unreachable error handling.
--

commit b6862fd9407ed1d4841735e0f963211d95acd921
Author: Geert Uytterhoeven <geert+renesas@glider.be>

clk: renesas: r8a78000: Add SCMI remapping support
    
Extend the Clock Pulse Generator driver for R-Car X5H with SCMI support,
to remap DT clock IDs to abstractions (clocks) offered by the SCMI
firmware implementation present when running on a system with a
supported SCMI firmware implementation.

> diff --git a/drivers/clk/renesas/r8a78000-cpg.c b/drivers/clk/renesas/r8a78000-cpg.c
> index 873d521ed3d6f..2273047315db5 100644
> --- a/drivers/clk/renesas/r8a78000-cpg.c
> +++ b/drivers/clk/renesas/r8a78000-cpg.c

[ ... ]

> @@ -120,11 +159,15 @@ static struct clk_hw **register_fixed_clks(struct device *dev)
>  }
>  
>  static const struct clk_map *fill_clk_map(struct r8a78000_cpg_priv *priv,
> -					  const struct clk_map_in *map_in)
> +					  const struct clk_map_in *map_in,
> +					  struct device_node *scmi_clk_np)
>  {
> +	struct of_phandle_args scmi_spec;
>  	struct device *dev = priv->dev;
>  	struct clk_hw **fixed_hws;
>  	struct clk_map *map;
> +	struct clk_hw *hw;
> +	struct clk *clk;
>  	unsigned int i;
>  
>  	fixed_hws = register_fixed_clks(dev);
> @@ -143,7 +186,38 @@ static const struct clk_map *fill_clk_map(struct r8a78000_cpg_priv *priv,
>  			break;
>  
>  		map[i].fw_id = map_in[i].fw_id;
> -		map[i].hw = fixed_hws[map[i].fw_id];
> +		if (map[i].fw_id >= FIXED_CLK_OFFSET) {
> +			enum fixed_clk idx = map[i].fw_id - FIXED_CLK_OFFSET;
> +
> +			map[i].hw = fixed_hws[idx];
> +			continue;
> +		}
> +
> +		scmi_spec.np = scmi_clk_np;
> +		scmi_spec.args_count = 1;
> +		scmi_spec.args[0] = map[i].fw_id;
> +
> +		clk = of_clk_get_from_provider(&scmi_spec);
> +		if (IS_ERR(clk))
> +			return dev_err_cast_probe(dev, clk,
> +				"Failed to get SCMI clock %u\n", map[i].fw_id);
> +
> +		hw = __clk_get_hw(clk);
> +		if (IS_ERR(hw))

[Severity: Low]
Is this error check reachable?  `__clk_get_hw()` extracts the hardware clock
from a valid `struct clk` and returns either a `struct clk_hw *` or `NULL`,
but it never returns an `ERR_PTR`.

> +			return dev_err_cast_probe(dev, hw,
> +				"Failed to get SCMI clock hw %u\n",
> +				map[i].fw_id);
> +
> +		if (!hw) {
> +			/* CLOCK_ATTRIBUTES is not supported */
> +			dev_warn(dev, "SCMI clock %u is NULL\n", map[i].fw_id);
> +			continue;
> +		}
> +
> +		dev_dbg(priv->dev, "SCMI clock %u is %s at %lu Hz\n",
> +			map[i].fw_id, clk_hw_get_name(hw), clk_hw_get_rate(hw));
> +
> +		map[i].hw = hw;

[Severity: High]
Does this code leak the consumer `struct clk` instances and module references?

`of_clk_get_from_provider()` dynamically allocates a consumer `struct clk` and
increments the SCMI provider's module reference.  This function extracts the
`clk_hw` pointer but abandons the `clk` pointer without calling `clk_put()`.

[Severity: High]
Could caching these raw `clk_hw` pointers without a device link lead to a
use-after-free?

If the SCMI provider is unbound via sysfs, it unregisters its clocks and frees
the `clk_hw` objects.  Because `renesas,scmi-firmware` is a custom property,
`fw_devlink` won't automatically establish unbind ordering.  This means a
subsequent clock request could cause the clock core to dereference a dangling
`clk_hw` pointer.

>  	}
>  
>  	devm_kfree(dev, fixed_hws);

[ ... ]

> @@ -152,20 +226,79 @@ static const struct clk_map *fill_clk_map(struct r8a78000_cpg_priv *priv,
>  
>  static int r8a78000_cpg_probe(struct platform_device *pdev)
>  {
> +	struct device_node *scmi __free(device_node) = NULL;
> +	struct device_node *scmi_clk_np = NULL;

[Severity: Medium]
Does this code leak the device node reference?

`scmi_clk_np` is later assigned the result of `scmi_find_proto()`, which
acquires a node reference, but `scmi_clk_np` lacks the `__free(device_node)`
cleanup attribute and is never manually freed before returning on both success
and error paths.

>  	struct device *dev = &pdev->dev;
> +	const struct cpg_data *cpg_data;

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1788338320.git.geert+renesas@glider.be?part=9

  reply	other threads:[~2026-09-02 11:41 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-02 11:29 [PATCH v3 00/12] R-Car X5H Ironhide CPG/MDLC SCMI remapping support Geert Uytterhoeven
2026-09-02 11:29 ` [PATCH v3 01/12] dt-bindings: clock: renesas,r8a78000-cpg: Add renesas,scmi-firmware property Geert Uytterhoeven
2026-09-04 14:03   ` Sudeep Holla
2026-09-04 14:42     ` Geert Uytterhoeven
2026-09-02 11:29 ` [PATCH v3 02/12] dt-bindings: power: renesas,r8a78000-mdlc: Add firmware property Geert Uytterhoeven
2026-09-04 14:03   ` Sudeep Holla
2026-09-02 11:29 ` [PATCH v3 03/12] firmware: arm_scmi: Add scmi_get_base_info() Geert Uytterhoeven
2026-09-02 11:29 ` [PATCH v3 04/12] of: property: fw_devlink: Add support for renesas,scmi-firmware Geert Uytterhoeven
2026-09-02 11:29 ` [PATCH v3 05/12] pmdomain: Make genpd_get_from_provider() public Geert Uytterhoeven
2026-09-02 11:40   ` sashiko-bot
2026-09-02 11:29 ` [PATCH v3 06/12] reset: Extract __reset_control_get_from_provider() Geert Uytterhoeven
2026-09-03  8:55   ` Philipp Zabel
2026-09-02 11:29 ` [PATCH v3 07/12] reset: Add reset_control_get_from_provider_exclusive() Geert Uytterhoeven
2026-09-02 11:38   ` sashiko-bot
2026-09-02 11:44   ` Geert Uytterhoeven
2026-09-03 10:03   ` Philipp Zabel
2026-09-02 11:29 ` [PATCH v3 08/12] clk: renesas: r8a78000: Add clk_hw to clk_map Geert Uytterhoeven
2026-09-02 11:29 ` [PATCH v3 09/12] clk: renesas: r8a78000: Add SCMI remapping support Geert Uytterhoeven
2026-09-02 11:41   ` sashiko-bot [this message]
2026-09-02 11:29 ` [PATCH v3 10/12] pmdomain: " Geert Uytterhoeven
2026-09-02 11:47   ` sashiko-bot
2026-09-02 11:29 ` [PATCH v3 11/12] arm64: dts: renesas: ironhide: Enable SCMI devpd, sys, clock, and reset Geert Uytterhoeven
2026-09-02 11:29 ` [PATCH v3 12/12] arm64: dts: renesas: ironhide: Add CPG/MDLC renesas,scmi-firmware properties Geert Uytterhoeven
2026-09-02 11:40   ` sashiko-bot

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=20260902114115.B1D6E1F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=linux-clk@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=wsa+renesas@sang-engineering.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.