Re: [PATCH v7 1/2] dt-bindings: iio: proximity: add ST VL53L1X ToF sensor

[Jonathan Cameron]

On Wed, 25 Mar 2026 20:38:48 +0600
Sirat <email@xxxxxxxx> wrote:

> On Wed, Mar 25, 2026 at 8:06 PM Jonathan Cameron
> <jonathan.cameron@xxxxxxxxxx> wrote:
> >
> > On Wed, 25 Mar 2026 14:44:13 +0100
> > Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:
> >  
> > > On 25/03/2026 14:38, Jonathan Cameron wrote:  
> > > > On Wed, 25 Mar 2026 15:18:05 +0600
> > > > Sirat <email@xxxxxxxx> wrote:
> > > >  
> > > >> On Wed, Mar 25, 2026 at 2:58 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:  
> > > >>>
> > > >>> On 25/03/2026 09:48, Sirat wrote:  
> > > >>>> On Wed, Mar 25, 2026 at 2:05 PM Krzysztof Kozlowski <krzk@xxxxxxxxxx> wrote:  
> > > >>>>>
> > > >>>>> On Wed, Mar 25, 2026 at 12:32:22PM +0600, Siratul Islam wrote:  
> > > >>>>>> Add device tree binding documentation for the STMicroelectronics
> > > >>>>>> VL53L1X Time-of-Flight ranging sensor connected via I2C.
> > > >>>>>>
> > > >>>>>> Make vdd-supply required. The device requires power to operate
> > > >>>>>> and the property should have been required from the start.  
> > > >>>>>
> > > >>>>> That's ABI break and device for many years was working fine, so this
> > > >>>>> should not be changed.
> > > >>>>>  
> > > >>>> Jonathan and David asked that vdd-supply be made required. I feel like
> > > >>>> there is a conflict here that I am not able to resolve myself.
> > > >>>>
> > > >>>> What I think about it is the binding does not correctly describe the
> > > >>>> hardware and we should consider this a bug and fix it.
> > > >>>> The driver worked because of a fallback mechanism (dummy/fake
> > > >>>> regulator) and not because power was optional.
> > > >>>>  
> > > >>>
> > > >>>
> > > >>> I looked at v6 and v5 and I do not see such comment for binding that
> > > >>> existing device should change ABI. Can you point me to it?
> > > >>>  
> > > >> "Make it required and add a note to the commit message to say why the
> > > >> requirement should always have been there. Devices tend not to work
> > > >> with no power." - Jonathan (v3:
> > > >> https://lore.kernel.org/linux-iio/20260322115704.10b2e0d4@jic23-huawei)
> > > >>
> > > >> "No, bindings should not depend on driver implementation." - David
> > > >> (When I asked if I should  drop the hard requirement in the binding,
> > > >> v6: https://lore.kernel.org/linux-iio/55e92148-b5de-4fb8-af0b-9476235341bc@xxxxxxxxxxxx/)
> > > >>
> > > >> "From the point of view of the devicetree, it doesn't matter what the
> > > >> driver does. It matters that the chip can't work without power. ;-)" -
> > > >> David (v1: https://lore.kernel.org/linux-iio/d0ec6a2f-6d30-4774-8950-15dd3c4b020b@xxxxxxxxxxxx)
> > > >>
> > > >> I'm not sure if this is the correct way to quote. But I have added the links.  
> > > >
> > > > This came up a few years back - though I doubt I can track down the
> > > > exact discussion however.
> > > >
> > > > From a Linux point of view we are breaking binding checks only if the
> > > > supply (that should always have been there as chips tend not to work
> > > > well without power) is not present.  We absolutely have to
> > > > keep the driver running whether or not the supply is specified.
> > > > Do other DT users provide such a constraint? I've no idea.
> > > >
> > > > If the DT maintainer preference is leave it not required (perhaps
> > > > with a comment saying new users of the binding should supply it)
> > > > then that's fine by me. I'll keep it in mind for future similar changes.  
> > >
> > > If this was other ABI, e.g. clock, then answer would be - do not require
> > > it, because that's ABI break. Therefore I would stick to that also to
> > > regulators. Once Rob also expressed such thoughts, although noting that
> > > it is not that big deal.
> > >
> > > New device in this binding of course should require the supply.  
> > Seems my memory was less than perfect on this :
> > https://lore.kernel.org/linux-iio/20241119140409.GA1093349-robh@xxxxxxxxxx/#t
> >
> > Rob expressed that we are inconsistent on this, but he'd rather not
> > have regulators as a special case.
> >
> > So let's only make this required for the new device.
> >  
> So since it is a new device, how do I require this? should we split to
> a new binding (like I had in v1) and make that required. That would
> also allow us to correctly name the xshut pin.
> 
> Or do we do the "allOf:" exclusion? In that case, I think it wouldn't
> make sense to someone reading the binding without the context of
> commit history, as it would imply one of the devices explicitly
> doesn't need power.
This + add a comment that it's only not required for other devices
for backwards compatibility reasons.

> 
> I'm willing to do whichever is prefered tough and move this forward.
> >
> >  
> Thanks,
> 
> Sirat