07:21 <mwalle> geertu: actually, I guess compatible = "everspin,mr25h256"; won't produce a dtb check error because no binding is matching (unless there is a check for undefined compatible strings)

07:26 <geertu> mwalle: Doesn't it match "everspin,mr25h(10|40|128|256)" in Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml? And yes, "make dtbs_check" recently gained a check for undocumented compatible values.

07:26 <mwalle> geertu: not if jedec,spi-nor is not there

07:27 <mwalle> (or I missed something when I tried it myself)

07:43 <geertu> mwalle: You're right.

07:43 <geertu> If I change the compatible value slightly, it does complain:

07:43 <geertu> failed to match any schema with compatible: ['everspin,mr25h257']

07:44 <geertu> So the warning is suppressed incorrectly if there's a partial match?

07:44 <geertu> robher: ^

07:59 <mripard_> geertu: the way that is used to determine is relevant for a given node is through a "select" clause

07:59 <mripard_> which contains a schema, and if that sub-schema applies, then the rest of the schema applies to that node

08:00 <mripard_> it's fairly redundant, so the tools usually generate it from the compatible list unless it's been already set

08:01 <mripard_> in your case, the schema will only be applied if the compatible is what is under properties/compatible

08:01 <mripard_> which is basically: does it contain jedec,spi-nor or not

08:02 <geertu> mripard_: If I use "mxicy,mx25r1635f", it does complain:

08:02 <mripard_> if it doesn't, then the schema will not be applied, and thus would be silently ignored

08:02 <geertu> flash@0: compatible: 'oneOf' conditional failed, one must be fixed: ['mxicy,mx25r1635f'] is too short

08:02 <geertu> 'mxicy,mx25r1635f' does not match

08:02 <geertu> '^((((micron|spansion|st),)?(m25p(40|80|16|32|64|128)|n25q(32b|064|128a11|128a13|256a|512a|164k)))|atmel,at25df(321a|641|081a)|everspin,mr25h(10|40|128|256)|(mxicy|macronix),mx25l(4005a|1606e|6405d|8005|12805d|25635e)|(mxicy|macronix),mx25u(4033|4035)|(spansion,)?s25fl(128s|256s1|512s|008k|064k|164k)|(sst|microchip),sst25vf(016b|032b|040b)|(sst,)?sst26wf016b|(sst,)?sst25wf(040b|080)|winbond,w25x(80|32)|(w

08:02 <geertu> inbond,)?w25q(16|32(w|dw)?|64(dw)?|80bl|128(fw)?|256))$' 'jedec,spi-nor' was expected

08:02 <mripard_> maybe the pattern is wrong / handled a bit differently then?

08:03 <geertu> So there is some difference in matching with a pattern or an enum

08:06 <mripard_> you can try to write a select clause yourself if it helps, Documentation/devicetree/bindings/eeprom/at24.yaml has an example

08:10 <geertu> mripard_: Shouldn't the existing logic in Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml handle that fine?

08:17 <mripard_> https://paste.ack.tf/cc14f0@raw

08:17 <mripard_> this is what the expanded schema looks like

08:17 <mripard_> the pattern is completely ignored

08:18 <mripard_> or rather, it's not treated as a pattern but as a plain string

08:20 <mripard_> this is the function that generates that select

08:20 <mripard_> https://github.com/devicetree-org/dt-schema/blob/master/dtschema/lib.py#L454

08:21 <mripard_> I guess if we have a pattern, we'd want to have a contains/oneOf with either the pattern of the enum with all the "string" compatibles

08:34 <geertu> mripard_: Indeed, the pattern is converted to a fixed string in the select statement of the expanded schema.

09:22 <prabhakarlad> Hi All, are there any pointers on triggering CPU parity errors ?

13:50 <robher> mripard, geertu: uh-oh!

15:55 <geertu> robher: I didn't know it took 35 iterations to get right. Was that sufficient, or were 3 or 4 more needed? ;-)

16:40 <robher> geertu: it might be a record.

19:05 <geertu> robher: yeah, multi-color LED framework was merged at v31/v32