The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Charles Keepax <ckeepax@opensource.cirrus.com>
To: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
Cc: Mark Brown <broonie@kernel.org>,
	Richard Fitzgerald <rf@opensource.cirrus.com>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.dev>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] regcache: Sort the local copy of an unsorted reg_defaults array
Date: Wed, 5 Aug 2026 15:07:43 +0100	[thread overview]
Message-ID: <anNDr50ithyTYrTA@opensource.cirrus.com> (raw)
In-Reply-To: <20260805132250.2637-1-peter.ujfalusi@linux.intel.com>

On Wed, Aug 05, 2026 at 04:22:50PM +0300, Peter Ujfalusi wrote:
> regcache_lookup_reg() bsearch()es the reg_defaults array, which requires
> it to be sorted by ascending register address.  Entries following a
> descending step are never found, so regcache_reg_needs_sync() reports
> that they need a sync and they are written to the device on every
> regcache_sync() even when they were never touched.
> 
> Detect the misordering while reg_defaults is validated against the
> register stride and sort the local copy.  The check needs no new loop
> and sort() only runs for the affected drivers, which are also warned
> about.
> 
> Note that sort() is not stable, so for arrays with duplicated register
> addresses it remains unspecified which entry is found.
> 
> Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
> ---
> Hi,
> 
> Fixes for affected in-tree codec drivers have been posted separately, so this
> is meant as a safety net for out-of-tree and future drivers rather than a
> replacement for fixing them, as discussed on the Cirrus codec patches.
> 
> I'm not sure about the print level: dev_warn() makes the problem visible to
> whoever boots the affected machine, but the person who can act on it is the
> driver author.  Should this be dev_dbg()?

Keep it at least as a warn, you need something annoying or no one
will take notice, it is quite likely people will apply debug on
their driver, much less likely they will apply it to the regmap
core. I still lean towards not sorting the defaults for people,
but not so strongly as to object if there is a rough concensus
forming around doing so.

Reviewed-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Tested-by: Charles Keepax <ckeepax@opensource.cirrus.com>

Thanks,
Charles

  reply	other threads:[~2026-08-05 14:08 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-05 13:22 [PATCH] regcache: Sort the local copy of an unsorted reg_defaults array Peter Ujfalusi
2026-08-05 14:07 ` Charles Keepax [this message]
2026-08-05 14:34   ` Mark Brown
2026-08-06 12:01 ` 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=anNDr50ithyTYrTA@opensource.cirrus.com \
    --to=ckeepax@opensource.cirrus.com \
    --cc=broonie@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peter.ujfalusi@linux.intel.com \
    --cc=pierre-louis.bossart@linux.dev \
    --cc=rf@opensource.cirrus.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox