06:40 <sgerhold> krzk: Do you have an opinion for the fallback compatible dianders suggested on the list for my atna33xc20 panel patch? Basically the question is if the hardcoded resolution/timings that were briefly assigned to the existing compatible long ago (but not anymore) still count as "ABI" for the compatible. For the driver we have nowadays the fallback

06:40 <sgerhold> compatible would work fine, and it would be a bit cleaner to use that.

06:48 <krzk> sgerhold: did not check that much, but assuming original code was incomplete or buggy, it does not define the ABI.

06:48 <krzk> Imagine someone adds incomplete support - does that define the ABI? No.

06:49 <krzk> The question is whether the devices are compatible, although it is a bit odd that for Linux they were not compatible some time ago, but now they are...

06:59 <sgerhold> krzk: It comes down to the question of how much of the interface we consider for the compatible. If we only take the non-discoverable part for the binding (i.e. the non-standard power sequence) they are compatible. The amount of pixels we need to send to the panels are not compatible, but this is discoverable at runtime without encoding it in the

06:59 <sgerhold> DT.

06:59 <sgerhold> I think it makes sense to consider just the non-discoverable part, in which case the fallback compatible would be better

07:48 <krzk> sgerhold: yeah

10:07 <javierm> krzk: interesting, so your position is that a DT "ABI" could be broken when if the original driver code was buggy?

10:09 <javierm> in other words, the driver could be fixed even if that would affect existing users that were relying on the buggy behaviour ?

10:12 <javierm> krzk: I'm asking because in the past I tried to fix a driver and was nacked because it would break DT backwared compatiblity, even when folks though that it would indeed be the correct behaviour

10:13 <javierm> https://patchwork.kernel.org/project/dri-devel/patch/20231116180743.2763021-3-javierm@redhat.com/ FYI

10:33 <krzk> javierm: I don't get the comparison to breaking ABI. What is getting broken in this example? Nothing. It's a new device.

10:35 <javierm> krzk: ah, I see. I misunderstood your conversation with sgerhold then, it was about adding a new compatible string vs the fallback compatible that was used before adding such new compatible ?

10:37 <javierm> nevermind then, this phrase from you caught my attention "but assuming original code was incomplete or buggy, it does not define the ABI" but now I get it in the context of adding a new compatilbe string