mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
To: Stephen Boyd <sboyd@kernel.org>,
	Anas Iqbal <mohd.abd.6602@gmail.com>,
	linux-clk@vger.kernel.org, mturquette@baylibre.com
Cc: mhiramat@kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clk: uniphier: mux: fix signedness bug in get_parent
Date: Wed, 25 Mar 2026 14:11:43 +0900	[thread overview]
Message-ID: <09fc1857-e554-48ec-8862-54f0650b1c58@socionext.com> (raw)
In-Reply-To: <177431305509.5403.15386021337517970667@lazor>

Hi,

On 2026/03/24 9:44, Stephen Boyd wrote:
> Quoting Anas Iqbal (2026-03-18 04:02:51)
>> The uniphier_clk_mux_get_parent() function returns a u8, but
>> propagates negative error codes such as -EINVAL and regmap_read()
>> failures. These values are implicitly converted to large unsigned
>> integers, resulting in invalid parent indices.
>>
>> The clk_ops.get_parent() callback is expected to return a valid
>> parent index and does not support error codes. Fix this by returning
>> 0 as a safe fallback in error cases.
> 
> A large number will exceed the number of parents possible for the clk
> and turn into a failure to find the parent in the parent map. There's
> nothing to do here besides implement clk_ops::get_parent_hw()[1] and fix
> all the drivers.
> 
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git/log/?h=clk-parent-rewrite

Certainly, the return value of .get_parent() is now u8, which doesn't
correctly detect an error in the function.

Some other implementations prevent .get_parent() from detecting regmap_read()
errors, but if it does, the read value is undefined.
If access to the parent fails, the only option is to propagate the error as
Stephen suggested, however, that affects all drivers, not just this one.

Thank you,

---
Best Regards
Kunihiko Hayashi

      reply	other threads:[~2026-03-25  5:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-18 11:02 Anas Iqbal
2026-03-18 17:05 ` Brian Masney
2026-03-24  0:44 ` Stephen Boyd
2026-03-25  5:11   ` Kunihiko Hayashi [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=09fc1857-e554-48ec-8862-54f0650b1c58@socionext.com \
    --to=hayashi.kunihiko@socionext.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-clk@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@kernel.org \
    --cc=mohd.abd.6602@gmail.com \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®