10:32 <mwalle> krzk: robher: re https://patchwork.ozlabs.org/project/devicetree-bindings/patch/20221202151204.3318592-4-michael@walle.cc/, any updates on this? it is marked as changes requested in PW, so I just want to make sure it doesn't get lost

10:33 <krzk> mwalle changes requested means it is expected to see next version, so the ball is on your side

10:36 <mwalle> krzk: there's need for a discussion (at least that's how is see it), see my last mail there. So I'm not sure, what else I'm supposed to do

10:37 <mwalle> (except for waiting for an answer from you or rob, but since it is marked as changes requested, I'm not sure there will be any. hence i just asked :)

10:41 <krzk> It's still not correct. You wrote there "Arguable, but you can interpret "use broken-interrupts" as no-op if there are no broken interrupts." - but that's not how DTS works. You cannot add properties which are not describing hardware assuming these are "no-ops"

10:41 <krzk> mwalle: the dts describes the hardware here, so if there are broken interrupts, but interrupts are not broken, it is not proper description anymore.

10:45 <krzk> mwalle what is more, once broken interrupts are in some DTS - given kernel will always interpret them as broken or always ignore, right? How do you see the "opt-in" to work (in respect of the ABI)?

10:56 <robmur01> FWIW it does seem a bit backwards to me for a DT property to state that whoever consumes the DT "can live with the consequences"... How does the DT know?

11:00 <robmur01> especially if consumers who don't actually know what they're doing are just going to see the standard property, try to use it as expected, and have a bad time

11:01 <robmur01> basically it isn't workable to have a property that says "hey, that thing over there isn't what it looks like"

11:09 <mwalle> krzk: ok i see your point. and maybe that property has a wrong name, but ultimately, it's just a hint that the systems designer wants to use the interrupts even if they don't work as expected, because they work on that particular hardware.

11:09 <mwalle> krzk: the interrupt line is there but it's broken, there are device trees out there with that property, so all we can do is to not use the interrupts for that PHY

11:11 <mwalle> krzk: but as a systems designer who is aware of the consequences and knowing that they don't apply to my board, how could i then tell the driver to use it anyway

11:14 <mwalle> robmur01: the board designer knows, for example, because maybe the interrupt isn't shared. maybe this could also be deduced by the driver. mh.

11:19 <krzk> mwalle if you can move any of this into the kernel (auto-detection), then it's better. Anyway, in general I could find the use of that property, especially if commit msg includes some of our talk. However you still have robher concerns about missing compatible and that schema cannot validate such binding.

11:21 <mwalle> krzk: I'd need to know if the interrupt line is a shared one. But I don't think thats possible, because it could be shared at any later time, i.e. when other drivers registers for that irq

11:22 <krzk> mwalle: hm, don't you need to put SHARED flag if any driver shares it? IOW, if there is SHARED flag you assume it is shared?

11:24 <mwalle> krzk: regaring the compatibility, does that only apply to the example? as mentioned in my mail, that seems to be a problem of any network phy bindings, see for example the qca,ar803x.yaml

11:25 <mwalle> krzk: the shared flag only means that this irq *can* be shared with others (which also sets this flag), no? But I'd need to know (in advance) if this line is actually shared on that board

11:26 <krzk> mwalle: qca,ar803 would have the same problem. If it was referenced from other bindings, this would solve the problem.

11:34 <mwalle> krzk: what other bindings? Could you give an example? TBH, I don't know how the custom properties are supposed to work. I was under the impression that you can just mix and combine them in one node. Eg. you could have qca,.. and maxlinear,.. in one node.

11:35 <mwalle> krzk: yes I know, that would imply that there is one device tree for two different board variants, one with a maxlinear phy and one with a qca phy

11:37 <mwalle> krzk: IMHO that is a real use case. with the chip shortage lately, some OEMs switch to different PHYs. Which should work because they are probed automatically, unless of course they have some device tree properties...

11:42 <mwalle> krzk: I don't think qca,ar803x.yaml is the only one. I think any phy bindings have that problem. 'grep "ref.*ethernet-phy.yaml" Documentation/devicetree/bindings/net/*yaml'

12:29 <krzk> mwalle: bindings for parent device node should reference specific phy then, not ethernet-phy.

14:38 <robher> mwalle: the kernel could walk all the interrupt properties and determine if an interrupt is shared. (assuming a complete DT)

14:41 <geertu> mwalle: oh, shared interrupts

14:53 <mwalle> krzk: so an mdio bus controller should reference all available phys? i mean there could be any phy on that bus

14:54 <mwalle> robher: mh, I see, nice idea. would that be something for drivers/of/ ?

15:37 <robher> mwalle: Yeah, unless we can do the same thing with ACPI and then there should be a common interface.

15:38 <robher> Though the backend for DT would still probably live in drivers/of/

16:55 <robmur01> not sure it's practical for ACPI, since it would involve rounding up GSIVs from all manner of vendor-defined static tables, not just the namespace

17:23 <Arch1> hello