Linux clock framework development
 help / color / mirror / Atom feed
From: Cristian Marussi <cristian.marussi@arm.com>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: linux-clk@vger.kernel.org
Subject: Re: [bug report] clk: scmi: Allocate CLK operations dynamically
Date: Tue, 20 Feb 2024 11:09:35 +0000	[thread overview]
Message-ID: <ZdSIb9mcarW9-uBX@pluto> (raw)
In-Reply-To: <904dd0c0-cbe4-47e0-a475-9f5352c7eb5c@moroto.mountain>

On Tue, Feb 20, 2024 at 01:13:21PM +0300, Dan Carpenter wrote:
> Hello Cristian Marussi,
> 
Hi,

> The patch 11f5b1a48a70: "clk: scmi: Allocate CLK operations
> dynamically" from Feb 14, 2024 (linux-next), leads to the following
> Smatch static checker warning:
> 
> 	drivers/clk/clk-scmi.c:362 scmi_clocks_probe()
> 	error: uninitialized symbol 'atomic_threshold'.
> 
> drivers/clk/clk-scmi.c
>     307 static int scmi_clocks_probe(struct scmi_device *sdev)
>     308 {
>     309         int idx, count, err;
>     310         unsigned int atomic_threshold;
>     311         bool is_atomic;
>     312         struct clk_hw **hws;
>     313         struct clk_hw_onecell_data *clk_data;
>     314         struct device *dev = &sdev->dev;
>     315         struct device_node *np = dev->of_node;
>     316         const struct scmi_handle *handle = sdev->handle;
>     317         struct scmi_protocol_handle *ph;
>     318 
>     319         if (!handle)
>     320                 return -ENODEV;
>     321 
>     322         scmi_proto_clk_ops =
>     323                 handle->devm_protocol_get(sdev, SCMI_PROTOCOL_CLOCK, &ph);
>     324         if (IS_ERR(scmi_proto_clk_ops))
>     325                 return PTR_ERR(scmi_proto_clk_ops);
>     326 
>     327         count = scmi_proto_clk_ops->count_get(ph);
>     328         if (count < 0) {
>     329                 dev_err(dev, "%pOFn: invalid clock output count\n", np);
>     330                 return -EINVAL;
>     331         }
>     332 
>     333         clk_data = devm_kzalloc(dev, struct_size(clk_data, hws, count),
>     334                                 GFP_KERNEL);
>     335         if (!clk_data)
>     336                 return -ENOMEM;
>     337 
>     338         clk_data->num = count;
>     339         hws = clk_data->hws;
>     340 
>     341         is_atomic = handle->is_transport_atomic(handle, &atomic_threshold);
> 
> atomic_threshold is not initialized when is_atomic is false.
>

yes

>     342 
>     343         for (idx = 0; idx < count; idx++) {
>     344                 struct scmi_clk *sclk;
>     345                 const struct clk_ops *scmi_ops;
>     346 
>     347                 sclk = devm_kzalloc(dev, sizeof(*sclk), GFP_KERNEL);
>     348                 if (!sclk)
>     349                         return -ENOMEM;
>     350 
>     351                 sclk->info = scmi_proto_clk_ops->info_get(ph, idx);
>     352                 if (!sclk->info) {
>     353                         dev_dbg(dev, "invalid clock info for idx %d\n", idx);
>     354                         devm_kfree(dev, sclk);
>     355                         continue;
>     356                 }
>     357 
>     358                 sclk->id = idx;
>     359                 sclk->ph = ph;
>     360                 sclk->dev = dev;
>     361 
> --> 362                 scmi_ops = scmi_clk_ops_alloc(sclk, is_atomic, atomic_threshold);
>                                                             ^^^^^^^^^^ ^^^^^^^^^^^^^^^^
> Here we're passing uninitialized data, but it's only used when
> is_atomic is true.  This is okay if scmi_clk_ops_alloc() is inlined,
> but it is considered a bug when it's not inlined.
>

Ok, I will add an explicit initialization to mute smatch but why is it
this considered a bug only when not inlined, because it cannot verify
that it is indeed not used when uninitialized ?

Thanks,
Cristian

>     363                 if (!scmi_ops)
>     364                         return -ENOMEM;
>     365 
>     366                 /* Initialize clock parent data. */
>     367                 if (sclk->info->num_parents > 0) {
>     368                         sclk->parent_data = devm_kcalloc(dev, sclk->info->num_parents,
>     369                                                          sizeof(*sclk->parent_data), GFP_KERNEL);
>     370                         if (!sclk->parent_data)
>     371                                 return -ENOMEM;
>     372 
>     373                         for (int i = 0; i < sclk->info->num_parents; i++) {
>     374                                 sclk->parent_data[i].index = sclk->info->parents[i];
>     375                                 sclk->parent_data[i].hw = hws[sclk->info->parents[i]];
>     376                         }
>     377                 }
>     378 
>     379                 err = scmi_clk_ops_init(dev, sclk, scmi_ops);
>     380                 if (err) {
>     381                         dev_err(dev, "failed to register clock %d\n", idx);
>     382                         devm_kfree(dev, sclk->parent_data);
>     383                         devm_kfree(dev, scmi_ops);
>     384                         devm_kfree(dev, sclk);
>     385                         hws[idx] = NULL;
>     386                 } else {
>     387                         dev_dbg(dev, "Registered clock:%s%s\n",
>     388                                 sclk->info->name,
>     389                                 scmi_ops->enable ? " (atomic ops)" : "");
>     390                         hws[idx] = &sclk->hw;
>     391                 }
>     392         }
>     393 
>     394         return devm_of_clk_add_hw_provider(dev, of_clk_hw_onecell_get,
>     395                                            clk_data);
>     396 }
> 
> regards,
> dan carpenter

      reply	other threads:[~2024-02-20 11:09 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-20 10:13 [bug report] clk: scmi: Allocate CLK operations dynamically Dan Carpenter
2024-02-20 11:09 ` Cristian Marussi [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=ZdSIb9mcarW9-uBX@pluto \
    --to=cristian.marussi@arm.com \
    --cc=dan.carpenter@linaro.org \
    --cc=linux-clk@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox