[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <fb88cec7-fc54-456e-ae6d-62bb4c2504ba@amd.com>
Date: Tue, 21 Jan 2025 10:52:28 +0530
From: "Mukunda,Vijendar" <vijendar.mukunda@....com>
To: Mark Brown <broonie@...nel.org>,
Mario Limonciello <mario.limonciello@....com>
Cc: alsa-devel@...a-project.org, lgirdwood@...il.com, perex@...ex.cz,
tiwai@...e.com, Basavaraj.Hiregoudar@....com, Sunil-kumar.Dommati@....com,
venkataprasad.potturu@....com, linux-sound@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2 12/23] ASoC: amd: acp70: add acp ip interrupt handler
On 21/01/25 00:58, Mark Brown wrote:
> On Mon, Jan 20, 2025 at 12:47:18PM -0600, Mario Limonciello wrote:
>> On 1/20/2025 12:39, Mark Brown wrote:
>>> That does feel like quirks and new features rather than a completely
>>> distinct IP.
>> I see it as different forms of tech debt. Either you keep track of which
>> features the 62 vs 70 hardware supports by different drivers or add logic in
>> all the relevant functions().
>> The former increases LoC but reduces risk for mistake (IE avoid oops, I
>> forgot this is only supported on 70+ when adding new features).
> Until someone fixes a bug or does some subsystem wide cleanup which
> affects both copies of the code (perhaps that already happened since the
> code was copied!). There's a reason why this is the general kernel
> style.
>
>> Changing code that affects a lot of hardware means a lot more testing too.
>> Perhaps after Vijendar's series lands he can split up some of the purely
>> duplicated functions into helpers or callbacks and arrange all that testing?
> Well, it was getting a new spin anyway for the bits that didn't have the
> serial numbers filed off.
Will drop code duplication and come up with new patch series.
Powered by blists - more mailing lists