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.