From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-181.mta1.migadu.com (mta1.migadu.com [37.59.57.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4EB96331A57 for ; Wed, 5 Aug 2026 08:41:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=37.59.57.117 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785919285; cv=none; b=tfRyLXYFpLq69dMQErZKoXvtKmkfn5MZ6xlcye/2dk9BcBcW71OgbMpE19CM/sjKslfPMSkfppVPoHZ6JUbUc9LuIjpFj1Oc0t/hK6UN8YYXoBePeB6WytZh+cqBuV/69rotAWB12UKXb7eomUXn+tPFrq5JcPH8PA6MLnWqUCY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785919285; c=relaxed/simple; bh=S38Ei+c21Lm+0Gv285ItkWpB1UcixQyvnhryTnK1jY8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=r0aRmV+dg9izwNWIsuKj79hg2CFJui/cwMo8pjw3zA2DE4qnOduDGT7nPMWPdLTzPGT2V94QfOIdAncsbn8ev4uaYy1L0RSLlTFr/9kkQhoYaV6SoqgOzzjK/Z1QXivUKVTpyjrvliFhb5yOqzMPtBj77wT2YUiq5BS5Fj7CEZM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=PGeWpUZ+; arc=none smtp.client-ip=37.59.57.117 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="PGeWpUZ+" Message-ID: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1785919271; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=IRXZcIXeXDWkdhDpN3QIMXR/hfQIQzwwbsAJ/HYacrU=; b=PGeWpUZ+NvGD6QbTsGgBeXEekMXLTlL+cl4bodUSfPyUKfd0ZpmcC65uBGF59BBKl2DqcQ X1Q5TveqW4Uqb8ZV0V8yQfD+s/hOgUrH+eF1noLz3IEdzhdqBE0XEy/gaPGj57DJnvGN3I MRsFFObmkbldVSQ3TB2UVZ/c4fe7Rfk= Date: Wed, 5 Aug 2026 10:40:46 +0200 Precedence: bulk X-Mailing-List: linux-sound@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH 0/3] ASoC: cs35l41/cs35l45/cs4265: sort the reg_defaults tables To: Peter Ujfalusi , Mark Brown , Liam Girdwood , David Rhodes , Richard Fitzgerald Cc: Charles Keepax , Vlad Karpovich , Paul Handrigan , patches@opensource.cirrus.com, linux-sound@vger.kernel.org, stable@vger.kernel.org References: <20260805082413.26174-1-peter.ujfalusi@linux.intel.com> Content-Language: en-US X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Pierre-Louis Bossart In-Reply-To: <20260805082413.26174-1-peter.ujfalusi@linux.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT > reg_defaults must be sorted by ascending register address as > regcache_lookup_reg() locates the entries in it with bsearch(), see commit > fd80df352ba1 ("regcache: Add support for sorting defaults arrays"). > > These three tables have entries which are out of order, so the binary search > does not find part of them. For those registers regcache_reg_needs_sync() > cannot compare the cached value against the default and reports that a sync > is needed, so they are written to the device on every regcache_sync() even > when they were never touched. > > The patches only reorder the existing entries, the text of every entry is > kept verbatim and no default value is changed. Each table was verified by > evaluating the register addresses and replaying lib/bsearch.c on them. > > Entries not reachable by the binary search, per table: > > cs35l41_reg 2 (of 47) > cs35l45_defaults 36 (of 73) > cs4265_reg_defaults 3 (of 16) > > For cs35l45 this is nearly half of the table: the DSP1_RX*_RATE and > DSP1_TX*_RATE registers sit in the middle of it while their addresses are > far above everything else, which cuts the search off from the whole > 0x4c40 - 0xf010 range. > > Found by an audit of all reg_defaults tables under sound/, the SoundWire > codec drivers are fixed by a separate series. Wow. Would it make sense to have a regmap helper to double-check the addresses are indeed in-order in those reg_default tables? I am not sure how this requirement can be enforced by just inspection, a warning would help detect this sort of issues on more platforms.