From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Jeff LaBundy <jeff@labundy.com>
Cc: James Ogletree <jogletre@opensource.cirrus.com>,
<dmitry.torokhov@gmail.com>, <robh+dt@kernel.org>,
<krzysztof.kozlowski+dt@linaro.org>, <conor+dt@kernel.org>,
<lee@kernel.org>, <broonie@kernel.org>,
<patches@opensource.cirrus.com>, <linux-sound@vger.kernel.org>,
<linux-input@vger.kernel.org>, <devicetree@vger.kernel.org>
Subject: Re: [PATCH v9 1/5] firmware: cs_dsp: Add write sequencer interface
Date: Mon, 11 Mar 2024 10:14:17 +0000 [thread overview]
Message-ID: <Ze7ZeY+FTPuk0zyE@ediswmail9.ad.cirrus.com> (raw)
In-Reply-To: <Ze4GEKkXoRA/4Sga@nixie71>
On Sun, Mar 10, 2024 at 02:12:16PM -0500, Jeff LaBundy wrote:
> On Fri, Mar 08, 2024 at 10:24:17PM +0000, James Ogletree wrote:
> > + switch (op_code) {
> > + case CS_DSP_WSEQ_FULL:
> > + cs_dsp_chunk_write(&ch, 32, op_new->address);
> > + cs_dsp_chunk_write(&ch, 32, op_new->data);
> > + break;
> > + case CS_DSP_WSEQ_L16:
> > + case CS_DSP_WSEQ_H16:
> > + cs_dsp_chunk_write(&ch, 24, op_new->address);
> > + cs_dsp_chunk_write(&ch, 16, op_new->data);
> > + break;
> > + default:
> > + ret = -EINVAL;
> > + cs_dsp_err(dsp, "Op code not supported: %X\n", op_code);
> > + goto op_new_free;
>
> There is no need to drop down and call devm_kfree() here; it's sufficient
> to simply return -EINVAL. The devres core will free any instances of
> cs_dsp_wseq_op when the driver is unbound.
>
> I imagine you're calling devm_kfree() to protect against the case where
> the driver successfully probes, but the contents of the firmware are found
> to be invalid later. In that case, yes, this newly allocated memory will
> persist throughout the length of the driver's life.
>
> That's an error condition though; if it happens, the customer will surely
> remove the module, correct the .wmfw or .bin file, then insert the module
> again. All we need to do here is make sure that memory does not leak after
> the module is removed, and device-managed allocation already handles this.
>
I disagree here. This is the write function, there is no guarantee
this is even called at probe time. This is generic code going
into the DSP library and will presumably get re-used for different
purposes and on different parts in the future. Freeing on the error
path is much safer here.
> > +int cs_dsp_wseq_multi_write(struct cs_dsp *dsp, struct cs_dsp_wseq *wseq,
> > + const struct reg_sequence *reg_seq, int num_regs,
> > + u8 op_code, bool update)
> > +{
> > + int ret, i;
> > +
> > + for (i = 0; i < num_regs; i++) {
> > + ret = cs_dsp_wseq_write(dsp, wseq, reg_seq[i].reg,
> > + reg_seq[i].def, update, op_code);
> > + if (ret)
> > + return ret;
> > + }
> > +
> > + return 0;
>
> This is absolutely a nit-pick, but in cs_dsp_wseq_init(), you use the pattern
> of breaking on error and always returning ret; here you return on error. Both
> are functionally equivalent but it would be nice to be consistent in terms of
> style.
>
> If you do opt to match cs_dsp_wseq_multi_write() to cs_dsp_wseq_init(), I do
> think you'll need to initialize ret to zero here as well to avoid a compiler
> warning for the num_regs = 0 case.
I would be inclined to make cs_dsp_wseq_init function like this
one personally, rather than the other way around. Generally best
to return if there is no clean up to do.
Thanks,
Charles
next prev parent reply other threads:[~2024-03-11 10:14 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-08 22:24 [PATCH v9 0/5] Add support for CS40L50 James Ogletree
2024-03-08 22:24 ` [PATCH v9 1/5] firmware: cs_dsp: Add write sequencer interface James Ogletree
2024-03-10 19:12 ` Jeff LaBundy
2024-03-11 10:14 ` Charles Keepax [this message]
2024-03-14 14:40 ` Jeff LaBundy
2024-03-15 9:29 ` Charles Keepax
2024-03-08 22:24 ` [PATCH v9 2/5] dt-bindings: input: cirrus,cs40l50: Add initial DT binding James Ogletree
2024-03-10 19:29 ` Jeff LaBundy
2024-03-11 6:31 ` Krzysztof Kozlowski
2024-03-14 14:42 ` Jeff LaBundy
2024-03-08 22:24 ` [PATCH v9 3/5] mfd: cs40l50: Add support for CS40L50 core driver James Ogletree
2024-03-10 23:40 ` Jeff LaBundy
2024-03-11 10:30 ` Charles Keepax
2024-03-14 15:15 ` Jeff LaBundy
2024-03-14 21:03 ` James Ogletree
2024-03-08 22:24 ` [PATCH v9 4/5] Input: cs40l50 - Add support for the CS40L50 haptic driver James Ogletree
2024-03-14 15:54 ` Jeff LaBundy
2024-03-15 20:23 ` James Ogletree
2024-03-08 22:24 ` [PATCH v9 5/5] ASoC: cs40l50: Support I2S streaming to CS40L50 James Ogletree
2024-03-14 16:05 ` Jeff LaBundy
2024-03-14 16:22 ` Mark Brown
2024-03-20 0:41 ` James Ogletree
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=Ze7ZeY+FTPuk0zyE@ediswmail9.ad.cirrus.com \
--to=ckeepax@opensource.cirrus.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmitry.torokhov@gmail.com \
--cc=jeff@labundy.com \
--cc=jogletre@opensource.cirrus.com \
--cc=krzysztof.kozlowski+dt@linaro.org \
--cc=lee@kernel.org \
--cc=linux-input@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=patches@opensource.cirrus.com \
--cc=robh+dt@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