Re: [PATCH v6 2/2] iio: proximity: add driver for ST VL53L1X ToF sensor

[David Lechner]

On 3/24/26 10:17 AM, Sirat wrote:
> On Sun, Mar 22, 2026 at 7:52 PM Sirat <email@xxxxxxxx> wrote:
>>
>> On Sun, Mar 22, 2026 at 5:03 PM Jonathan Cameron <jic23@xxxxxxxxxx> wrote:
>>>
>>> On Sat, 21 Mar 2026 19:37:58 -0500
>>> David Lechner <dlechner@xxxxxxxxxxxx> wrote:
>>>
>>>> On 3/21/26 5:39 PM, Sirat wrote:
>>>>> On Sat, Mar 21, 2026 at 11:09 PM David Lechner <dlechner@xxxxxxxxxxxx> wrote:
>>>>>>
>>>>>> On 3/19/26 2:07 PM, Siratul Islam wrote:
>> ...
>>>>
>>>> If you do a buffered read, which stop ranging when it is done,
>>>> then how can the direct read work after that?
>>>>
>>>> Can we just start and stop ranging momentarily for a direct
>>>> read?
>>> If the latency is high, then worth considering whether autosuspend
>>> and runtime pm can help. That way a burst of reads will see low
>>> latency after the first one but we won't be wasting power when
>>> no one cares.
>>>
>>> J
>>>>
>>>> Otherwise, is seems like we would want to have ranging always
>>>> enabled.
>>>>
>> Maybe we should go with continuous ranging then since it's the
>> vendor-intended behaviour.
>> Since there is no hardware single-shot mode, by design, I think the
>> driver should just behave
>> as the hardware intended.
>>>>
>>>
> Just for the record, I'm dropping postenable, and keeping predisable
> for only the cleanup.
> 
> Thanks,
> Sirat

predisable must clean up anything done in postenable. So it doesn't
make sense to have predisable without a postenable.

If there is something unusual going on here, it will need comments
with a clear explanation of why it still works when it is breaking
the convention.