On Thu, 6 Oct 2022 18:32:22 +0300 Matti Vaittinen <mazziesaccount@xxxxxxxxx> wrote: > Hi dee Ho Krzysztof, > > On 10/6/22 18:23, Krzysztof Kozlowski wrote: > > On 06/10/2022 16:37, Matti Vaittinen wrote: > >> KX022A is a 3-axis Accelerometer from ROHM/Kionix. The sensor features > >> include variable ODRs, I2C and SPI control, FIFO/LIFO with watermark IRQ, > >> tap/motion detection, wake-up & back-to-sleep events, four acceleration > >> ranges (2, 4, 8 and 16g) and probably some other cool features. > >> > > > > Thank you for your patch. There is something to discuss/improve. > > > >> + > >> +properties: > >> + compatible: > >> + const: kionix,kx022a > >> + > >> + reg: > >> + maxItems: 1 > >> + > >> + interrupts: > >> + minItems: 1 > >> + maxItems: 2 > >> + > >> + interrupt-names: > >> + minItems: 1 > >> + maxItems: 2 > >> + items: > >> + enum: > >> + - INT1 > >> + - INT2 > > > > This allows any order, which I assume was your intention. > > Yes. I don't see real need to restrict ordering - besides, with my > yaml/schema skills it'd took eternity to find corrct example(s) ;) > > My intention is that the user can give either one of these - or both. > Order needs naturally to match the order of IRQs - but this we can't know. > > > However maybe > > at least fix it a bit like: > > minItems: 1 > > items: > > - enum: [ int1, int2] > > - const: int2 > > If you say so XD > I can fix this for v3 :) If my limited understanding is correct, one advantage of this restriction is that we can't have "INT1", "INT1" though that may be prevented elsewhere... There is no loss of useful flexibility in how Krzysztof suggested doing it so looks like a good suggestion to me. Jonathan