On 11/07/2023 16:13, Praveenkumar I wrote: >>>>> - const: calib >>>>> @@ -205,6 +209,24 @@ properties: >>>>> - const: s9_p2_backup >>>>> - const: s10_p1_backup >>>>> - const: s10_p2_backup >>>>> + - items: >>>>> + - const: mode >>>>> + - const: base0 >>>>> + - const: base1 >>>>> + - const: s0_offset >>>>> + - const: s3_offset >>>>> + - const: s4_offset >>>>> + - const: s5_offset >>>>> + - const: s6_offset >>>>> + - const: s7_offset >>>>> + - const: s8_offset >>>>> + - const: s9_offset >>>>> + - const: s10_offset >>>>> + - const: s11_offset >>>>> + - const: s12_offset >>>>> + - const: s13_offset >>>>> + - const: s14_offset >>>>> + - const: s15_offset >>>> Don't introduce new naming style. Existing uses s[0-9]+, without offset >>>> suffix. Why this should be different? >>> As I mentioned above, s[0-9]+_p1 / s[0-9]+p2 is for TSENS V1. TSENS V2 >>> QFPROM layout is different from the existing one. >> I know, I did not write about p1/p2. >> >>> I would like to add mode, base0, base1 and 16 patterns >>> '^s[0-15]+_offset$'. But DT binding check is failing in oneOf/ anyOf >>> condintion. >> This does not explain why you need different style - this "offset" suffix. > In QFPROM, the BIT field names are s0_offset, s3_offset to s15_offset. > s1_offset and s2_offset not present in IPQ5332. > Hence used the same "offset" suffix here. May I know in this case, which > nvmem-cells-names you are suggesting to use? "Existing uses s[0-9]+" so s[0-9]+ Best regards, Krzysztof
