From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: "Shuming [范書銘]" <shumingf@realtek.com>
Cc: "broonie@kernel.org" <broonie@kernel.org>,
"lgirdwood@gmail.com" <lgirdwood@gmail.com>,
"linux-sound@vger.kernel.org" <linux-sound@vger.kernel.org>,
"lars@metafoo.de" <lars@metafoo.de>,
"Flove(HsinFu)" <flove@realtek.com>,
"Oder Chiou" <oder_chiou@realtek.com>,
"Jack Yu" <jack.yu@realtek.com>,
"Derek [方德義]" <derek.fang@realtek.com>
Subject: Re: [PATCH 1/2] ASoC: SDCA: remove the max count of initialization table
Date: Wed, 25 Mar 2026 10:58:17 +0000 [thread overview]
Message-ID: <acO/yaoSOJDijWB+@opensource.cirrus.com> (raw)
In-Reply-To: <1bdba8facd57429ca8a191dcd0496c5e@realtek.com>
On Wed, Mar 25, 2026 at 10:51:24AM +0000, Shuming [范書銘] wrote:
> > On Wed, Mar 25, 2026 at 05:20:17PM +0800, shumingf@realtek.com wrote:
> > > From: Shuming Fan <shumingf@realtek.com>
> > > The number of the initialization table may exceed 2048.
> > > Therefore, this patch removes the limitation and allows the driver to
> > > allocate memory dynamically based on the size of the initialization table.
> >
> > We were concerned this might be a little too low. Are we sure we want to
> > remove the limit rather than just increasing the allowed size? I feel like I can
> > see arguments for both ways, on one hand this is input to the driver rather
> > than part of it so it feels sensible to sanity check it, on the other hand its the
> > BIOS so really we should be able to trust that.
>
> I think we should trust the BIOS.
> If the BIOS is updated, the number may increase.
> It's difficult to define a fixed value for this argument.
Alright, lets go with that then.
Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Thanks,
Charles
next prev parent reply other threads:[~2026-03-25 10:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-25 9:20 [PATCH 1/2] ASoC: SDCA: remove the max count of initialization table shumingf
2026-03-25 10:00 ` Charles Keepax
2026-03-25 10:51 ` Shuming [范書銘]
2026-03-25 10:58 ` Charles Keepax [this message]
2026-03-25 12:22 ` (subset) " Mark Brown
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=acO/yaoSOJDijWB+@opensource.cirrus.com \
--to=ckeepax@opensource.cirrus.com \
--cc=broonie@kernel.org \
--cc=derek.fang@realtek.com \
--cc=flove@realtek.com \
--cc=jack.yu@realtek.com \
--cc=lars@metafoo.de \
--cc=lgirdwood@gmail.com \
--cc=linux-sound@vger.kernel.org \
--cc=oder_chiou@realtek.com \
--cc=shumingf@realtek.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.