From: Amit Sunil Dhamne <amitsd@google.com>
To: "Matti Vaittinen" <mazziesaccount@gmail.com>,
"Sebastian Reichel" <sre@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"André Draszik" <andre.draszik@linaro.org>,
"Lee Jones" <lee@kernel.org>,
"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
"Badhri Jagan Sridharan" <badhri@google.com>,
"Heikki Krogerus" <heikki.krogerus@linux.intel.com>,
"Peter Griffin" <peter.griffin@linaro.org>,
"Tudor Ambarus" <tudor.ambarus@linaro.org>,
"Alim Akhtar" <alim.akhtar@samsung.com>,
"Mark Brown" <broonie@kernel.org>,
"Andrew Morton" <akpm@linux-foundation.org>
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 <rdbabiera@google.com>, Kyle Tso <kyletso@google.com>
Subject: Re: [PATCH v6 4/6] lib/linear_ranges: Add linear_range_get_selector_high_array
Date: Tue, 17 Feb 2026 17:45:40 -0800 [thread overview]
Message-ID: <b1df24fd-bbb6-4991-be52-dc1ef694db25@google.com> (raw)
In-Reply-To: <5d889f66-7697-4a39-beed-33ace693a1ef@gmail.com>
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@google.com>
>>
>> Add a helper function to find the selector for a given value in a linear
>> range array. The selector should be such that the value it represents
>> should be higher or equal to the given value.
>>
>> Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
>> ---
>> include/linux/linear_range.h | 3 +++
>> lib/linear_ranges.c | 36 ++++++++++++++++++++++++++++++++++++
>> 2 files changed, 39 insertions(+)
>>
>> diff --git a/include/linux/linear_range.h b/include/linux/linear_range.h
>> index 2e4f4c3539c0..0f3037f1a94f 100644
>> --- a/include/linux/linear_range.h
>> +++ b/include/linux/linear_range.h
>> @@ -57,5 +57,8 @@ void linear_range_get_selector_within(const struct
>> linear_range *r,
>> int linear_range_get_selector_low_array(const struct linear_range *r,
>> int ranges, unsigned int val,
>> unsigned int *selector, bool *found);
>> +int linear_range_get_selector_high_array(const struct linear_range *r,
>> + int ranges, unsigned int val,
>> + unsigned int *selector, bool *found);
>> #endif
>> diff --git a/lib/linear_ranges.c b/lib/linear_ranges.c
>> index a1a7dfa881de..c85583678f6b 100644
>> --- 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.
Regards,
Amit
>
>> + *
>> + * Return: 0 on success, -EINVAL if range array is invalid or does
>> not contain
>> + * range with a value greater or equal to given value
>> + */
>> +int linear_range_get_selector_high_array(const struct linear_range *r,
>> + int ranges, unsigned int val,
>> + unsigned int *selector, bool *found)
>> +{
>> + int i;
>> + int ret;
>> +
>> + for (i = 0; i < ranges; i++) {
>> + ret = linear_range_get_selector_high(&r[i], val, selector,
>> + found);
>> + if (!ret)
>> + return 0;
>> + }
>> +
>> + return -EINVAL;
>> +}
>> +EXPORT_SYMBOL_GPL(linear_range_get_selector_high_array);
>> +
>> /**
>> * linear_range_get_selector_within - return linear range selector
>> for value
>> * @r: pointer to linear range where selector is looked from
>>
>
>
next prev parent reply other threads:[~2026-02-18 1:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-14 3:12 [PATCH v6 0/6] Introduce MAX77759 charger driver Amit Sunil Dhamne via B4 Relay
2026-02-14 3:12 ` [PATCH v6 1/6] dt-bindings: mfd: maxim,max77759: reference power-supply schema and add regulator property Amit Sunil Dhamne via B4 Relay
2026-02-14 3:12 ` [PATCH v6 2/6] dt-bindings: usb: maxim,max33359: Add supply property for vbus Amit Sunil Dhamne via B4 Relay
2026-02-14 3:12 ` [PATCH v6 3/6] mfd: max77759: add register bitmasks and modify irq configs for charger Amit Sunil Dhamne via B4 Relay
2026-02-17 12:30 ` André Draszik
2026-02-14 3:12 ` [PATCH v6 4/6] lib/linear_ranges: Add linear_range_get_selector_high_array Amit Sunil Dhamne via B4 Relay
2026-02-16 13:58 ` Matti Vaittinen
2026-02-18 1:45 ` Amit Sunil Dhamne [this message]
2026-02-18 8:17 ` Matti Vaittinen
2026-02-18 20:05 ` Amit Sunil Dhamne
2026-02-14 3:12 ` [PATCH v6 5/6] power: supply: max77759: add charger driver Amit Sunil Dhamne via B4 Relay
2026-02-14 8:56 ` kernel test robot
2026-02-17 13:14 ` André Draszik
2026-02-18 5:35 ` Amit Sunil Dhamne
2026-02-14 3:12 ` [PATCH v6 6/6] usb: typec: tcpm/tcpci_maxim: deprecate WAR for setting charger mode Amit Sunil Dhamne via B4 Relay
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b1df24fd-bbb6-4991-be52-dc1ef694db25@google.com \
--to=amitsd@google.com \
--cc=akpm@linux-foundation.org \
--cc=alim.akhtar@samsung.com \
--cc=andre.draszik@linaro.org \
--cc=badhri@google.com \
--cc=broonie@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=heikki.krogerus@linux.intel.com \
--cc=krzk+dt@kernel.org \
--cc=kyletso@google.com \
--cc=lee@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mazziesaccount@gmail.com \
--cc=peter.griffin@linaro.org \
--cc=rdbabiera@google.com \
--cc=robh@kernel.org \
--cc=sre@kernel.org \
--cc=tudor.ambarus@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox