public inbox for linux-clk@vger.kernel.org
 help / color / mirror / Atom feed
From: <Conor.Dooley@microchip.com>
To: <geert@linux-m68k.org>, <Daire.McNamara@microchip.com>
Cc: <mturquette@baylibre.com>, <sboyd@kernel.org>,
	<linux-clk@vger.kernel.org>, <robh+dt@kernel.org>,
	<devicetree@vger.kernel.org>, <krzysztof.kozlowski@canonical.com>,
	<david.abdurachmanov@gmail.com>, <palmer@dabbelt.com>,
	<Cyril.Jean@microchip.com>
Subject: Re: [PATCH v6 2/2] clk: microchip: Add driver for Microchip PolarFire SoC
Date: Wed, 8 Dec 2021 15:29:35 +0000	[thread overview]
Message-ID: <3e2a08f5-d1b0-e2d3-c418-4b5b352f0800@microchip.com> (raw)
In-Reply-To: <CAMuHMdV=QNtz0rRLQv+=k+GGuSyKANFjGQ1YTKaKwcmzsvf5RA@mail.gmail.com>

Hi Geert,
Just going to ack the other items you raised for now, but curious about 
this one:
On 06/12/2021 15:53, Geert Uytterhoeven wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>> +static void mpfs_clk_unregister_cfg(struct device *dev, struct clk_hw *hw)
>> +{
>> +       struct mpfs_cfg_hw_clock *cfg_hw = to_mpfs_cfg_clk(hw);
>> +
>> +       devm_clk_hw_unregister(dev, hw);
>> +       kfree(cfg_hw);
> 
> This is freeing a part of the big array allocated with devm_kzalloc()?
I took a look at this, and I don't think it is freeing the devm 
allocated array.

To me, what is actually being freed is an element in the array of 
structs passed to mpfs_clk_register_cfgs in the probe function.
However, this struct is statically defined - so its elements shouldn't 
be freed at all?

drivers/clk/clk-bm1880.c has the same behaviour in the unregister 
function, where it calls kfree on the elements of a static array of clk 
structs. So if my understanding is correct it would need fixing there too.

Cheers,
Conor.
>> +}
>> +
>> +static struct clk_hw *mpfs_clk_register_cfg(struct device *dev,
>> +                                           struct mpfs_cfg_hw_clock *cfg_hw,
>> +                                           void __iomem *sys_base)
>> +{
>> +       struct clk_hw *hw;
>> +       int err;
>> +
>> +       cfg_hw->sys_base = sys_base;
>> +       cfg_hw->lock = &mpfs_clk_lock;
>> +
>> +       hw = &cfg_hw->hw;
>> +       err = devm_clk_hw_register(dev, hw);
>> +       if (err)
>> +               return ERR_PTR(err);
>> +
>> +       return hw;
>> +}
>> +
>> +static int mpfs_clk_register_cfgs(struct device *dev, struct mpfs_cfg_hw_clock *cfg_hws,
>> +                                 int num_clks, struct mpfs_clock_data *data)
> 
> unsigned int num_clks
> 
>> +{
>> +       struct clk_hw *hw;
>> +       void __iomem *sys_base = data->base;
>> +       unsigned int i, id;
>> +
>> +       for (i = 0; i < num_clks; i++) {
>> +               struct mpfs_cfg_hw_clock *cfg_hw = &cfg_hws[i];
>> +
>> +               hw = mpfs_clk_register_cfg(dev, cfg_hw, sys_base);
>> +               if (IS_ERR(hw)) {
>> +                       dev_err(dev, "%s: failed to register clock %s\n", __func__,
> 
> I guess the __func__ can be dropped, as the clock name is unique?
> 
>> +                               cfg_hw->cfg.name);
>> +                       goto err_clk;
>> +               }
>> +
>> +               id = cfg_hws[i].cfg.id;
>> +               data->hw_data.hws[id] = hw;
>> +       }
>> +
>> +       return 0;
>> +
>> +err_clk:
>> +       while (i--)
>> +               mpfs_clk_unregister_cfg(dev, data->hw_data.hws[cfg_hws[i].cfg.id]);
>> +
>> +       return PTR_ERR(hw);
>> +}

  reply	other threads:[~2021-12-08 15:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-30 14:07 [PATCH v6 0/2] CLK: microchip: Add clkcfg driver for Microchip PolarFire SoC conor.dooley
2021-11-30 14:07 ` [PATCH v6 1/2] dt-bindings: clk: microchip: Add Microchip PolarFire host binding conor.dooley
2021-12-06 15:12   ` Geert Uytterhoeven
2021-11-30 14:07 ` [PATCH v6 2/2] clk: microchip: Add driver for Microchip PolarFire SoC conor.dooley
2021-12-06 15:53   ` Geert Uytterhoeven
2021-12-08 15:29     ` Conor.Dooley [this message]
2021-12-08 18:28       ` Geert Uytterhoeven

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=3e2a08f5-d1b0-e2d3-c418-4b5b352f0800@microchip.com \
    --to=conor.dooley@microchip.com \
    --cc=Cyril.Jean@microchip.com \
    --cc=Daire.McNamara@microchip.com \
    --cc=david.abdurachmanov@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=geert@linux-m68k.org \
    --cc=krzysztof.kozlowski@canonical.com \
    --cc=linux-clk@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=palmer@dabbelt.com \
    --cc=robh+dt@kernel.org \
    --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