Re: [PATCH 0/3] ASoC: cs35l41/cs35l45/cs4265: sort the reg_defaults tables

Richard Fitzgerald <[email protected]> Wed, 5 Aug 2026 12:38:16 +0100
Newsgroups org.kernel.vger.linux-sound,org.kernel.vger.stable
Message-ID <[email protected]>
On 05/08/2026 12:31 pm, Charles Keepax wrote:
> On Wed, Aug 05, 2026 at 02:25:52PM +0300, Péter Ujfalusi wrote:
>>
>>
>> On 05/08/2026 13:36, Richard Fitzgerald wrote:
>>> On 05/08/2026 11:17 am, Péter Ujfalusi wrote:
>>>>
>>>>
>>>> On 05/08/2026 13:10, Charles Keepax wrote:
>>>>>>> I don't think we need to sort them. Just fail, so that an unsorted
>>>>>>> table
>>>>>>> must be fixed.
>>>>>>
>>>>>> That would be a big regression all around the place, ordering w/ the
>>>>>> debug message if developer is interested is much better.
>>>>>
>>>>> I think I would come down between the two of you. I definitely
>>>>> agree with Richard on don't sort them, just encourages drivers to
>>>>> be wrong. But I also agree with you, don't hard fail. I would
>>>>> vote for just print an error message and carry on. That way no
>>>>> regressions, but also a nice big warning message to let people
>>>>> know what is wrong when they see problems.
>>>>
>>>> I usually try to avoid alarming/annoying users with error messages, on
>>>> the other hand I agree that w/o some pressure, these will never be
>>>> corrected at root either ;)
>>>>
>>>> On the yet another hand, if the regcache have means to fix this, it
>>>> might be put into use as well.
>>>> A dev_warn at max to get attention or info level perhaps and fixing it
>>>> up?
>>>>
>>> I asked Codex (GPT5) to search for all reg_default tables with out-of
>>> order entries or duplicate entries, looking only at those assigned to
>>> struct regmap_config.reg_defaults (some reg_defaults tables are used for
>>> patching - those are allowed to be out-of-order).
>>>
>>> It came up with this:
>>>
>>> Restricting results to tables referenced by struct
>>> regmap_config.reg_defaults, 39 files violate the rule:
>>
>> and some of these have duplicate addresses with different default values.
>>
>> I can send more fixes while I'm at this for the clear cases, for Cirrus,
>> Realtek and TI I have sent few patches.
>>
> 
> I was just having a look at cs42l43 so you can skip that one
> unless you already fixed it up.
> 
> Thanks,
> Charles

And I've sent a patch to fix cs_dsp_mock_regmap.c. That one was actually
defining the table in order but had a typo in one of the addresses.