Re: [PATCH v6 4/6] lib/linear_ranges: Add linear_range_get_selector_high_array

[Matti Vaittinen]

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 <amitsd@xxxxxxxxxx>

// 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 <mazziesaccount@xxxxxxxxx>


---
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland

~~ When things go utterly wrong vim users can always type :help! ~~