From: Troy Mitchell <troy.mitchell@linux.spacemit.com>
To: Alex Elder <elder@ieee.org>,
Dan Carpenter <dan.carpenter@linaro.org>,
Troy Mitchell <troy.mitchell@linux.spacemit.com>
Cc: linux-sound@vger.kernel.org, spacemit@lists.linux.dev
Subject: Re: [bug report] ASoC: spacemit: add i2s support for K1 SoC
Date: Mon, 27 Oct 2025 10:50:19 +0800 [thread overview]
Message-ID: <7804C2A506CC6DCB+aP7d6y8yrqlbKwbN@kernel.org> (raw)
In-Reply-To: <eee35fa0-0a5f-4730-b6e4-a1b92dc5000f@ieee.org>
On Fri, Oct 24, 2025 at 11:06:04AM -0500, Alex Elder wrote:
> On 10/24/25 6:43 AM, Dan Carpenter wrote:
> > On Fri, Oct 24, 2025 at 07:37:51PM +0800, Troy Mitchell wrote:
> > > On Fri, Oct 24, 2025 at 02:25:40PM +0300, Dan Carpenter wrote:
> > > > 424 i2s->reset = devm_reset_control_get_exclusive(&pdev->dev, NULL);
> > > > 425 if (IS_ERR(i2s->reset))
> > > > 426 return dev_err_probe(i2s->dev, PTR_ERR(i2s->reset),
> > > > 427 "failed to get reset control");
> > > > 428
> > > > 429 dev_set_drvdata(i2s->dev, i2s);
> > > > 430
> > > > 431 spacemit_i2s_init_dai(i2s, &dai, res->start + SSDATR);
> > > > ^^^^
> > > > dai is not initialized on failure. Generally in the kernel we always
> > > > check for allocation failures. Even when they can't happen in real life.
> > > > I was hoping they were going to make a rule that allocations under 4k
> > > > wouldn't have to be checked but it hasn't happened yet.
> > > Should I send a fix patch now, or should I wait for the maintainer to
> > > revert it first, and then fix this error and send?
> > >
> > > Thanks for your report!
> > >
> >
> > You should send a follow on patch which just fixes the one issue. If the
> > maintainer wants to squash them together that's very easy to do in git.
>
> Yes I agree, send a new patch, no point in reverting. But I think
> a fix commit is better than squashing (for what that's worth).
>
>
> A very simple fix is assigning *dp to NULL in spacemit_i2s_init_dai().
>
> if (dp)
> *dp = dai ? : NULL;
>
> Also: Why aren't you checking for spacemit_i2s_init_dai() returning
> an error? (Another--separate--suggested fix.)
The cause of this error was that we did not check the return value.
Indeed, this was an oversight on my part, and I have sent a fix for it.
- Troy
>
> -Alex
>
> >
> > regards,
> > dan carpenter
> >
> >
>
>
prev parent reply other threads:[~2025-10-27 2:51 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-24 11:25 [bug report] ASoC: spacemit: add i2s support for K1 SoC Dan Carpenter
2025-10-24 11:37 ` Troy Mitchell
2025-10-24 11:43 ` Dan Carpenter
2025-10-24 16:06 ` Alex Elder
2025-10-27 2:50 ` Troy Mitchell [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=7804C2A506CC6DCB+aP7d6y8yrqlbKwbN@kernel.org \
--to=troy.mitchell@linux.spacemit.com \
--cc=dan.carpenter@linaro.org \
--cc=elder@ieee.org \
--cc=linux-sound@vger.kernel.org \
--cc=spacemit@lists.linux.dev \
/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