On 11/18/24 5:24 AM, Marcelo Schmitt wrote: > On 11/15, David Lechner wrote: >> On 11/14/24 5:50 PM, Marcelo Schmitt wrote: >>> Extend the AD4000 series device tree documentation to also describe >>> PulSAR devices. >>> >>> Signed-off-by: Marcelo Schmitt <marcelo.schmitt@xxxxxxxxxx> >>> --- ... >>> >>> $ref: /schemas/spi/spi-peripheral-props.yaml# >>> >>> @@ -63,6 +78,38 @@ properties: >>> >>> - const: adi,adaq4003 >>> >>> + - const: adi,ad7946 >>> + - items: >>> + - enum: >>> + - adi,ad7942 >>> + - const: adi,ad7946 >>> + >>> + - const: adi,ad7983 >>> + - items: >>> + - enum: >>> + - adi,ad7980 >>> + - adi,ad7988-5 >>> + - adi,ad7686 >>> + - adi,ad7685 >>> + - adi,ad7694 >>> + - adi,ad7988-1 >>> + - const: adi,ad7983 >>> + >>> + - const: adi,ad7688 >>> + - items: >>> + - enum: >>> + - adi,ad7693 >>> + - adi,ad7687 >>> + - const: adi,ad7688 >>> + >>> + - const: adi,ad7984 >>> + - items: >>> + - enum: >>> + - adi,ad7982 >>> + - adi,ad7690 >>> + - adi,ad7691 >>> + - const: adi,ad7984 >>> + >> >> IMHO, having fallbacks just makes the bindings harder to use and doesn't >> actually provide any useful benefit. >> > Having fallbacks was a suggestion from a dt maintainer to the ad4000 series. > I assumed they would ask it for PulSAR too. Will wait a comment from a dt > maintainer to change it. > >> And with this many chips, it can be easy to overlook a small difference >> in one chips, like ad7694 not having VIO pin, so is it really fallback >> compatible? Easier to just avoid the question and not have fallbacks. >> > The absence of a VIO pin does not change how the driver handles the devices. > They are compatible from software perspective. > OK. Another difference for consideration that I noticed is that on some chips, the SDO line can generate a BUSY interrupt while others can't. Not sure if that matters from the point of view of fallbacks or not.
