From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.19]) (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 42FBA3EEACB for ; Thu, 6 Aug 2026 08:23:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.19 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786004585; cv=none; b=bcG3wIB3Sx8dufZSupaFGF+/s4g0cFPYE86/lh7mlfPe6/QUp2AW+qVlH9wfjQP2pMjTmQi1GQYIzf70t/zcNwq5CKElUcGaHUp/DHMuYgEFS9YNKdmBrTTiQdcRikoydL+ipW6eAu0db2XbMPEJ1u72wR0xfDd5q3Hq1qQQiNo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786004585; c=relaxed/simple; bh=W3Gwx6PiXbfMH4c+5D0vzeSAHyQlwmWb44IzQgNR7A8=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=CUIT3odk3QIn5PDp/gh3Mh8eJm3LQgtAM4oD/92n9gea8LpSu9sXmuDkmpw9BSdubCXD3jJSlvNCh0D5Qq5URmJCM2iw2d0EbdVYzuLTMy9LPO02vvore4sr5b0KOtQBQJt3Lb8nOH27sF7nqmzrBvFylfe2Nkm+foQE4EHbU3E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=mMFpU1BC; arc=none smtp.client-ip=198.175.65.19 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="mMFpU1BC" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1786004583; x=1817540583; h=message-id:date:mime-version:subject:to:cc:references: from:in-reply-to:content-transfer-encoding; bh=W3Gwx6PiXbfMH4c+5D0vzeSAHyQlwmWb44IzQgNR7A8=; b=mMFpU1BC8VGdjsv6M6AFXz/1Oyu6E48tARoRGj0VG/l56jvrER2adtNA jgCLujjnkxlf60wKmNdDaxo2DYWkwScEsnE2VXuyPM1KqIDCe3BOJcwFf kVGvH+AUmmCS7LD7z8Bp/9uBIgUEAdXYBa5xP3NKMK3kSa2ZNVMwoDl8i fvAWMabNyRSKMAanINQLieBECbPXrCD7saGSnl12UbH6U0YsfHRt4lCxc 8hNoUSl4FuGorOWbrXrlbLMkcwbFKQWyg3HFGwvofnEs/+03nsfOPfOdB UjxbENsa7ifYvsYJpI9bsERATHcG1qnc2xcCSexsYtC0xP7uiJ7dzutI6 g==; X-CSE-ConnectionGUID: 1cHP5sukQUOv3sJXKrkn/A== X-CSE-MsgGUID: 19048PC5Rh6HgXoCP8v4Uw== X-IronPort-AV: E=McAfee;i="6800,10657,11866"; a="86533703" X-IronPort-AV: E=Sophos;i="6.25,208,1779174000"; d="scan'208";a="86533703" Received: from fmviesa006.fm.intel.com ([10.60.135.146]) by orvoesa111.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Aug 2026 01:23:01 -0700 X-CSE-ConnectionGUID: I8JtkWpWQJKAcpMkfmEdRA== X-CSE-MsgGUID: 1vAWcFTBSXSNomUXGQfYmg== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,208,1779174000"; d="scan'208";a="257738406" Received: from mjarzebo-mobl1.ger.corp.intel.com (HELO [10.245.246.7]) ([10.245.246.7]) by fmviesa006-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Aug 2026 01:22:58 -0700 Message-ID: <38c16850-57de-4d6d-bdef-ef1270d5bd19@linux.intel.com> Date: Thu, 6 Aug 2026 11:23:37 +0300 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] regcache: Use a consistent sort for defaults table To: Mark Brown Cc: Charles Keepax , Richard Fitzgerald , Pierre-Louis Bossart , linux-kernel@vger.kernel.org References: <20260805-regmap-regcache-sort-v1-1-162186aad8b9@kernel.org> Content-Language: en-US From: =?UTF-8?Q?P=C3=A9ter_Ujfalusi?= In-Reply-To: <20260805-regmap-regcache-sort-v1-1-162186aad8b9@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 05/08/2026 20:51, Mark Brown wrote: > When we look up registers in the defaults table we use a binary search, > and we have a regcache_sort_defaults() API to help drivers that constuct > their defaults tables on the fly. Unfortunately the lookup and the sort > don't use the same comparison function, and to make matters worse the > comparison function used during lookups is written for signed register > numbers rather than the unsigned ones we actually have so can produce > suprising results when some of the addresses have the top bit set. > > Standardise on the more explicitly coded function to ensure consistent > results. Reviewed-by: Peter Ujfalusi > > Signed-off-by: Mark Brown > --- > drivers/base/regmap/regcache.c | 10 +--------- > 1 file changed, 1 insertion(+), 9 deletions(-) > > diff --git a/drivers/base/regmap/regcache.c b/drivers/base/regmap/regcache.c > index aa8f2efed779..480bc76f9a02 100644 > --- a/drivers/base/regmap/regcache.c > +++ b/drivers/base/regmap/regcache.c > @@ -727,14 +727,6 @@ unsigned int regcache_get_val(struct regmap *map, const void *base, > return -1; > } > > -static int regcache_default_cmp(const void *a, const void *b) > -{ > - const struct reg_default *_a = a; > - const struct reg_default *_b = b; > - > - return _a->reg - _b->reg; > -} > - > int regcache_lookup_reg(struct regmap *map, unsigned int reg) > { > struct reg_default key; > @@ -744,7 +736,7 @@ int regcache_lookup_reg(struct regmap *map, unsigned int reg) > key.def = 0; > > r = bsearch(&key, map->reg_defaults, map->num_reg_defaults, > - sizeof(struct reg_default), regcache_default_cmp); > + sizeof(struct reg_default), regcache_defaults_cmp); > > if (r) > return r - map->reg_defaults; > > --- > base-commit: 075b74841bd0065a3bda3440873c747938e69b68 > change-id: 20260805-regmap-regcache-sort-8d144a68bf8d > > Best regards, > -- > Mark Brown > -- Péter