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

[Sirat]

On Tue, Mar 24, 2026 at 11:29 PM David Lechner <dlechner@xxxxxxxxxxxx> wrote:
>
> 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.
>
>
I was thinking about the drain logic. But looks like it is not needed.
Dropping predisable too.
Thanks for the insight!

Sirat