Re: [PATCH v2 02/12] dt-bindings: iio: dac: ad5696: rework on power supplies

[Jonathan Cameron]

On Tue, 9 Jun 2026 17:12:29 +0100
Conor Dooley <conor@xxxxxxxxxx> wrote:

> On Tue, Jun 09, 2026 at 12:40:08PM +0100, Rodrigo Alencar wrote:
> > On 09/06/26 10:28, sashiko-bot@xxxxxxxxxx wrote:  
> > > Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> > > - [High] Adding `vdd-supply`, `vlogic-supply`, and unconditionally requiring `vref-supply` breaks backward compatibility for existing device trees.
> > > - [Medium] Making `vlogic-supply` unconditionally required forces device trees to document a non-existent hardware connection for single-channel devices.
> > > --
> > > 
> > > commit 8357cd3efa5f819678f24f0cbf0a39208f4078bc
> > > Author: Rodrigo Alencar <rodrigo.alencar@xxxxxxxxxx>
> > > Subject: dt-bindings: iio: dac: ad5696: rework on power supplies
> > > 
> > > This commit reworks the power supply bindings for the ad5696 DAC series. It
> > > adds vdd-supply, vlogic-supply, and vref-supply, deprecates vcc-supply, and
> > > updates the required properties.
> > >   
> > > > diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> > > > index 2dcc049f30e91..e5fbaec4adf71 100644
> > > > --- a/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml
> > > > +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5696.yaml  
> > > 
> > > [ ... ]
> > >   
> > > > @@ -55,8 +65,21 @@ properties:
> > > >  required:
> > > >    - compatible
> > > >    - reg
> > > > +  - vdd-supply
> > > > +  - vlogic-supply  
> > > 
> > > [Severity: High]
> > > Does adding vdd-supply and vlogic-supply to the global required list break
> > > backward compatibility for existing device trees? Older device trees that
> > > omitted these will now fail dtbs_check.  
> > 
> > Yes, for correctness, it breaks the dtbs_check. In the driver side
> > we would rely on the dummy/stub regulator in case those are not declared.  
> 
> Ye I wouldn't be overly worried here. Sashiko has particular difficulty
> with these kinds of changes.
> 
> >   
> > > [Severity: Medium]
> > > Does making vlogic-supply unconditionally required force device trees to
> > > document a non-existent hardware connection? Single-channel devices in this
> > > family (such as adi,ad5693, adi,ad5693r, and adi,ad5311r) physically do not
> > > have a dedicated VLOGIC pin.  
> > 
> > VLOGIC does exist for those parts. However, as mentioned before, for some
> > tiny packages it is internally connected to VDD:
> > 
> > - 10-Lead MSOP package for AD5693R/AD5691R exposes the VLOGIC pin
> > - 8-Lead LFCSP package for AD5693R/AD5692R/AD5691R/AD5693 does NOT expose the VLOGIC pin
> > 
> > I think we agreed to make it required and user can just repeat the vdd-supply
> > value or not have it at all. Driver would rely on the dummy/stub regulator.  
> 
> Yeah, I dunno. I think this is just a judgement call, and maybe worth
> having a comment in the binding for to explain it.

Yes. A breadcrumb type of comment that just says that it may be internally wired
in which case set it to same as the other one.

> 
> >    
> > > >  
> > > >  allOf:
> > > > +  - if:
> > > > +      properties:
> > > > +        compatible:
> > > > +          contains:
> > > > +            anyOf:
> > > > +              - const: adi,ad5693
> > > > +              - const: adi,ad5694
> > > > +              - const: adi,ad5696
> > > > +    then:
> > > > +      required:
> > > > +        - vref-supply  
> > > 
> > > [Severity: High]
> > > Does unconditionally requiring vref-supply break older device trees that
> > > correctly utilized the formerly valid vcc-supply?
> > > 
> > > To preserve DT ABI compatibility, should the schema allow either vcc-supply or
> > > vref-supply to satisfy the reference voltage requirement?  
> > 
> > Same here. For correctness, it breaks DT ABI.
> >   
> > > -- 
> > > Sashiko AI review · https://sashiko.dev/#/patchset/20260609-ad5686-new-features-v2-0-70b423f5c76d@xxxxxxxxxx?part=2  
> > 
> > -- 
> > Kind regards,
> > 
> > Rodrigo Alencar