On 2/18/26 12:17 AM, Matti Vaittinen wrote:

On 18/02/2026 03:45, Amit Sunil Dhamne wrote:

quoted

On 2/16/26 5:58 AM, Matti Vaittinen wrote:

quoted

On 14/02/2026 05:12, Amit Sunil Dhamne via B4 Relay wrote:

quoted

From: Amit Sunil Dhamne <amitsd@google.com>

// snip

quoted

quoted

quoted

--- 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 <mazziesaccount@gmail.com>

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! ~~