From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-dy1-f178.google.com (mail-dy1-f178.google.com [74.125.82.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 7DA3F2F39A1 for ; Wed, 18 Feb 2026 20:05:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771445138; cv=none; b=d0mWSUwCnXmd4KBXF7Ks77QIquXzxH9v98AN/E5zCWkxE4bwENhBNXkTL/QfKcX6UHTRQG7AzproHPAcq9wJbEvOM58NgMlPb9gjHHT3kRg5fTQ2GB0C08+LeMnL7Ni/Nw8Otfj7i0+f45NeFupRSBTtl3IWGiKrR4xYFuvw+Ew= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771445138; c=relaxed/simple; bh=Eb8WztYruLPtpbjUq44P2hChG8R4NOCFEJN+uEHJMMk=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=es+fC7hut2YKzaUITiUDmOy4YrjoKIBHAkmONYpIZ+ih2g9Ap5NVinV9Uw9PFiOBAqWwDhJSwyFTBoYyWSjSHDeCno7Is1WeuyL2Z8oBormAiRniRmAer/VibOX44PtWw5XgzNNCU0c5c1v7jtlucKnJKXX5hh6k6OYtEf1jyr8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=dRPrj7he; arc=none smtp.client-ip=74.125.82.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dRPrj7he" Received: by mail-dy1-f178.google.com with SMTP id 5a478bee46e88-2b86ce04c5cso335061eec.1 for ; Wed, 18 Feb 2026 12:05:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1771445136; x=1772049936; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=ruwMDgtbpwkbLzJMSDs2l3vNnZLc2ZiEeFBqv+MGVhg=; b=dRPrj7heC/vfUsmGojrAEh7xjifEi2K+5ikryz/EC9J7P9XlzGI3qouVczByYM1bGd yTSj+o7bCuk6WcccyIG3fu+Qvr8BYPYzEY/rp2tc9+LtVIELy3ewyj5gLQqx/ttugou2 0kkowdferefjOvocOP+WvlEyCgQ7ThxJ6i/Oo7fBIJ8Kk3CEGvEeNe+x3TBwi5rl8XnR Ulepf87PwFOUUQTO3AB/y0T87WU81BSx+ioby/YFLsiSmLZE3n6NlzPUauHKHAnbKZSG RaKVr/l+aLWp/KiH4qiVdYH4EEZoqfLlmIZITWaC5hzCNUgWKyQZTPwjPzUU5gOJc6NV 4hVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771445136; x=1772049936; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ruwMDgtbpwkbLzJMSDs2l3vNnZLc2ZiEeFBqv+MGVhg=; b=ioOBlGDfBJrU0NYtKqNz/Nt7I9d9jyGpJeoSc4CMBZzgT9PSsUtei0C+bS5ZoqBoEg NWFz2DpaqUR0ehnYAGPZT9zfkcoiiYmdB5aubyxElxsqsbmQC7O9s6p2krCAcl300o/p djbBuLd4cokuJwkXaTDFcZNPnxDdiXRYsY/rG7mdMyA0kciZjt2uropeMe3+mGy26qB1 //HHHE0iATE2hjoWPkmIT6wpNm+WoqGBAjV2kWF7Y34wJqprBP0hgN+NtDVgmsXmRYZQ 56gNoTMis/21fU0HW+o+depfa/cBkoIZfbOpxyZC40d3qTaNKOuF46464aD8RP/GYMik Rtow== X-Gm-Message-State: AOJu0YyjiIRDgoBZ/HnLOdzI2KIeRC3V3Ik4+S2WEV91NzkrMTIf4aaS 2z7NF4mTQZDUQY0BSHlp9IqymoHL/MNA5simExdjHYU6xRx5JkIUEYGPeg8POpsfzQ== X-Gm-Gg: AZuq6aL+KvRtIgk8pR7G722XJvYRwjMAjzPaOzpsylgPcbclYvMEZ7HmXBcIiat5M8S vEJAEy6h151LvZcKArXPrgEOwiTCVBTp0KVcLdM2xgBYcE8eDyNdUoB0Pk91YgAsFUaLokegoVO +8UAaljKm/S8wCcykrybsCQ1Fwmk/aDAI0FXuGkHwJH1KnC2yW2T+CtKApUkI6F+NE+PQpYzNQz jftgH0QkU7enWDMOVBSQjnEkvuwSq7wrxdEBM31BYp16H9qnJkwT+XVLUluXz89/h3Ef+vxyf4A NN2sr4OzCPCd0S7HgRlW+u7rBKuDGKxDvZFLMIzVZ6kg67Ssq9IrFbwbKjQX4w8I7agQMKdlD+M cSSB8wQhzRDkajYx1R5kMtR05Rrp/qoKhdMlI8UFL8Hva+71dElImt888gJxZgq8N9nXIJ1fIBL ABvn3m3Z+Fsbi34E/tB5dxXglEZTV/Qlbc2bUmEyfoGp+yzdSpRk+iQmmzanRaKyLPQcFtcYE79 EYcAB81SwTdzCr81xMIiXLX+g== X-Received: by 2002:a05:7301:100e:b0:2ba:a04a:8353 with SMTP id 5a478bee46e88-2babc44eb66mr9413193eec.27.1771445135121; Wed, 18 Feb 2026 12:05:35 -0800 (PST) Received: from ?IPV6:2a00:79e0:2e7c:8:c8f1:53bf:725c:563b? ([2a00:79e0:2e7c:8:c8f1:53bf:725c:563b]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-2bacb543e8dsm19410069eec.5.2026.02.18.12.05.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 18 Feb 2026 12:05:34 -0800 (PST) Message-ID: Date: Wed, 18 Feb 2026 12:05:32 -0800 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 v6 4/6] lib/linear_ranges: Add linear_range_get_selector_high_array To: Matti Vaittinen , Sebastian Reichel , Rob Herring , Krzysztof Kozlowski , Conor Dooley , =?UTF-8?Q?Andr=C3=A9_Draszik?= , Lee Jones , Greg Kroah-Hartman , Badhri Jagan Sridharan , Heikki Krogerus , Peter Griffin , Tudor Ambarus , Alim Akhtar , Mark Brown , Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, devicetree@vger.kernel.org, linux-usb@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-samsung-soc@vger.kernel.org, RD Babiera , Kyle Tso References: <20260214-max77759-charger-v6-0-28c09bda74b4@google.com> <20260214-max77759-charger-v6-4-28c09bda74b4@google.com> <5d889f66-7697-4a39-beed-33ace693a1ef@gmail.com> <66dab64b-ca3e-4ae0-81d6-0500899757e5@gmail.com> Content-Language: en-US From: Amit Sunil Dhamne In-Reply-To: <66dab64b-ca3e-4ae0-81d6-0500899757e5@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 2/18/26 12:17 AM, Matti Vaittinen wrote: > On 18/02/2026 03:45, Amit Sunil Dhamne wrote: >> >> On 2/16/26 5:58 AM, Matti Vaittinen wrote: >>> On 14/02/2026 05:12, Amit Sunil Dhamne via B4 Relay wrote: >>>> From: Amit Sunil Dhamne > > // snip > >>>> --- a/lib/linear_ranges.c >>>> +++ b/lib/linear_ranges.c >>>> @@ -241,6 +241,42 @@ int linear_range_get_selector_high(const >>>> struct linear_range *r, >>>>   } >>>>   EXPORT_SYMBOL_GPL(linear_range_get_selector_high); >>>>   +/** >>>> + * linear_range_get_selector_high_array - return linear range >>>> selector for value >>>> + * @r:        pointer to array of linear ranges where selector is >>>> looked from >>>> + * @ranges:    amount of ranges to scan from array >>>> + * @val:    value for which the selector is searched >>>> + * @selector:    address where found selector value is updated >>>> + * @found:    flag to indicate that given value was in the range >>>> + * >>>> + * Scan array of ranges for selector for which range value matches >>>> given >>>> + * input value. Value is matching if it is equal or higher than >>>> given value >>>> + * If given value is found to be in a range scanning is stopped >>>> and @found is >>>> + * set true. If a range with values greater than given value is found >>>> + * but the range min is being greater than given value, then the >>>> range's >>>> + * lowest selector is updated to @selector and scanning is stopped. >>> >>> Is there a reason why the scanning is stopped here? What ensures >>> that the rest of the ranges wouldn't contain a better match? >>> >>> The logic is now different from the >>> linear_range_get_selector_low_array(), and I would like to >>> understand why? It'd be nice if these APIs were 'symmetric' to avoid >>> confusion. Hence, I would like to know rationale behind making them >>> different. >> >> >> The rationale for this being asymmetric is to find the tightest upper >> bound for `value` < minimum value across the linear range array. >> >> To better illustrate this with an example. I have 2 entries in the >> linear range array [ [4, 8], [11, 15] ]. Let's assume I pass a value >> of "2". >> >> Based on my current approach, the call to get_selector_high() would >> successfully return with `found`=false and a selector value >> corresponding to "4". >> >> However, if I continued to search, I would end up the selector >> corresponding to "11". A selector corresponding to "4" is much >> closer/ tighter than "2". >> >> For values higher than the highest value in any range, this would >> keep iterating and end up returning an -EINVAL. >> >> For in range values this would work as expected. >> >> This implementation assumes that the linear ranges are provided in >> sorted order, an assumption that I believe already underlies the >> existing *_low_array() logic. > > Ah. I think ... I didn't think. :) > > It definitely makes sense to stop scanning if the range_min already > was greater than the given target value. Thanks for the patience and > for adding this missing piece :) > > Reviewed-by: Matti Vaittinen Thanks for the review! :) Regards, Amit > > > --- > Matti Vaittinen > Linux kernel developer at ROHM Semiconductors > Oulu Finland > > ~~ When things go utterly wrong vim users can always type :help! ~~