[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZFGqhM0VYFdorkRa@finisterre.sirena.org.uk>
Date: Wed, 3 May 2023 09:27:48 +0900
From: Mark Brown <broonie@...nel.org>
To: Shenghao Ding <13916275206@....com>
Cc: lgirdwood@...il.com, perex@...ex.cz,
pierre-louis.bossart@...ux.intel.com, kevin-lu@...com,
shenghao-ding@...com, alsa-devel@...a-project.org,
linux-kernel@...r.kernel.org, x1077012@...com, peeyush@...com,
navada@...com, gentuser@...il.com
Subject: Re: [PATCH v1 3/5] firmware: tasdevice_fmw: tasdevice firmware
loading lib
On Tue, May 02, 2023 at 01:32:35PM +0800, Shenghao Ding wrote:
> Create tasdevice firmware lib.
> drivers/firmware/Kconfig | 1 +
> drivers/firmware/Makefile | 1 +
> drivers/firmware/ti/Kconfig | 5 +
> drivers/firmware/ti/Makefile | 3 +
> drivers/firmware/ti/tasdevice-fmw.c | 2380 +++++++++++++++++++++++++++
> 5 files changed, 2390 insertions(+)
Given how large this part of the code for these devices is it definitely
makes sense to split it into a separate commit like you've done but are
there any non-audio devices in this series which will share the same
firmware style? If not then it probably makes sense to keep the code in
sound/soc/codecs, though a separate file would still make sense.
There's some devices that do keep firmware interface code in the
firmware directory but in those cases the devices have other, non-audio,
functionality which also uses the firmware (eg, always on monitoring)
but I've not seen any of the tas devices like that. If there are some
then the split you've made here makes sense.
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists