On mar 28-04-2020 21:21:17, Sam Ravnborg wrote:
> Hi Ricardo.
>
> Thanks for looking into this bridge binding.
> Some comments in the following.
Thanks for reviewing it, Sam. I agree with your suggestions, some
comments below:
> Can you define it as an enum like this:
>
> enum: [-4, -3, -2, -1, 0, 1, 2, 3]
>
> And then maybe in the descrition describe how they map to 0..7.
> The problem is that the binding is an API so we cannot just change
> the interpretation of the value 0 etc.
This is similar to what I wanted to do at first, specifying minimum and
maximum values, but it'd have the same problem with the yaml
checker. See, problem is in the yaml checking itself, the actual
parameter parsing in the driver already works with negative integers.
The issue with this particular property is that:
- it's vendor specific, so it must have a type definition.
- the actual value is signed, so the proper type definition to use
should be a signed integer.
- but then, if you use a negative value for this it will be cast into
a very large u32 (that's what cells are, after all) beyond the
maximum value of a positive int32.
- Range constraints can't be properly checked either, since any
negative integer interpreted as unsigned will result in a positive
number beyond the top end of the value range (3 in this case).
So unless there's a way of making the yaml check process aware of
negative integers, I think the only way to pass the checks is to use
unsigned integers and avoid defining the range constraints.
FWIW, the only other similar case I found (adi,ltc2983.yaml) uses uint64
and no range constraints.
Cheers,
Ricardo
