Re: [PATCH] iio: st-sensors: Update ST Sensor bindings

[Maxime Ripard <maxime@cerno.tech>]

[-- Attachment #1: Type: text/plain, Size: 4061 bytes --]

On Mon, Jul 12, 2021 at 03:28:02PM +0100, Jonathan Cameron wrote:
> On Mon, 12 Jul 2021 16:16:13 +0200
> Maxime Ripard <maxime@cerno.tech> wrote:
> 
> > On Mon, Jul 12, 2021 at 02:56:39PM +0100, Jonathan Cameron wrote:
> > > On Mon, 12 Jul 2021 15:04:44 +0200
> > > Maxime Ripard <maxime@cerno.tech> wrote:
> > >   
> > > > Hi,
> > > > 
> > > > On Mon, Apr 12, 2021 at 02:23:31PM +0200, Linus Walleij wrote:  
> > > > > This adjusts the ST Sensor bindings with the more fine-grained
> > > > > syntax checks that were proposed late in the last kernel cycle
> > > > > and colliding with parallel work.
> > > > > 
> > > > > Cc: devicetree@vger.kernel.org
> > > > > Reviewed-by: Rob Herring <robh@kernel.org>
> > > > > Signed-off-by: Linus Walleij <linus.walleij@linaro.org>    
> > > > 
> > > > I'm not really sure of how I supposed to fix this, but this creates an
> > > > issue on the Pinephone
> > > > (arch/arm64/boot/dts/allwinner/sun50i-a64-pinephone-1.2.dts) that has a
> > > > LIS3MDL with only the DRDY pin routed and thus only has a single
> > > > interrupt in the DT.
> > > > 
> > > > One of the if condition in that patch enforces that there's two
> > > > interrupts for the LIS3MDL, but it's not really clear to me why after
> > > > looking at the datasheet?  
> > > 
> > > It shouldn't be enforcing that 2 are specified rather that 2 'might' be
> > > specified.  
> > 
> > But then you don't need that condition at all, it's already what is
> > being enforced by the main schema here:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/iio/st,st-sensors.yaml#n90
> 
> Good point.  I'd argue that we should drop this entry infavour or explicit match
> on one of the others, but perhaps that gives an error?

in an if statement, the schema under then will only be enforced if the
schema under the if is valid. In our case, if we remove the entry like
you suggested, we won't match in any if schema, so the schemas under
then will get ignored, which is what we want.

> > 
> > > maxItems is set, but not minItems.   
> > 
> > Yeah, and if one is missing the other is added with the value of the
> > other.
> 
> Gah.  Indeed, not good and needs fixing.
> 
> > What the schema enforces currently is that (for the common part) the
> > interrupt list can be between 1 and 2 and then for a specific set of
> > compatibles (including the LIS3MDL) it has to be exactly 2.
> > 
> > Even the common part looks weird though, it says that it can handle up
> > to three interrupts but has maxItems: 2?
> 
> That is indeed odd and I expect an omission on the assumption that the minItems
> from the general one would not be overridden. 
>
> @Linus?

As far as schemas work, you can't override a schema with another. They
are all validated in isolation from each other, and they all have to be
valid if you don't want any error.

So the main, global, schema will be validated, and then the smaller
schemas under then will be (if the schemas under their respective if
clause are valid). So it's really as if it was in a separate file
entirely.

> > 
> > > Driver wise, at the moment it looks like we only handle one interrupt.
> > > So to handle selection when two are possible and either 1 or 2 might
> > > be wired up we need to add interrupt names (with default order so we
> > > don't break anything before adding them to the binding).
> > > 
> > > Would that work for this device?  
> > 
> > I don't know the LIS3MDL to comment whether it makes sense or not, but
> > it looks like it's a single sensor so I'm not really sure why we'd need
> > more than one interrupt
> 
> Looks like they are hard wired to specific functions.  Data ready does
> what it says on the tin, but the INT line is used for threshold events.
> Depending on the application a particular device is being used for, it
> might well make sense to only wire either one of them.

Ok, I'll just remove the if clause then

Thanks!
Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]