On 22-09-21, Krzysztof Kozlowski wrote: > On 21/09/2022 10:35, Marco Felsch wrote: > > On 22-09-21, Krzysztof Kozlowski wrote: > >> On 20/09/2022 19:32, Laurent Pinchart wrote: > >>>>> > >>>>> Explicit bus types in DT indeed makes it easier for drivers, so if a > >>>>> device can support multiple bus types (even if not implemented yet in > >>>>> the corresponding drivers), the property should be there. > >>>> > >>>> Okay, I will make it required. > >>>> > >>>>>> Why do you have hsync-active and vsync-active if both are always zero? Can > >>>>>> the hardware not support other configuration? > >>>> > >>>> Sure the device supports toggling the logic but it is not implemented. > >>>> So the bindings needs to enforce it to 0 right now. As soon as it is > >>>> implemented & tested, we can say that both is supported :) > >>> > >>> Bindings are not supposed to be limited by the existing driver > >>> implementation, so you can already allow both polarities, and just > >>> reject the unsupported options in the driver at probe time. Future > >>> updates to the driver won't require a binding change. > >>> > >> > >> +1 > > > > I don't wanna do that because this let the binding user assume that > > this mode is already supported. > > What do you mean by "not supported"? By which system? By which firmware > element? Bindings are used by several operating systems and several > projects. And they can use it and of course extend it, since the propery is available. > That's not the argument. > > Bindings should be complete. Lack of knowledge and datasheets is a good > exception from this rule. Looking at Linux driver is not good exception. So if I get you right, you are saying that the bindings should always be complete and describe all ever possible combinations? I am on your side that the properties should be there from day one. But listing all possible values regardless of the support.. I don't know and yes, I know that other projects using these bindings as well. But if those other projects support more than now, they can extend it and send patches. Since this is a new binding, the only user is Linux and listing all possible values can lead into erroneous assumption. No system-integrator wants to check the driver why a listed property is not supported instead most the time it is the other way. If it is listed, than it should be supported. Anyway I don't wanna make a big deal out of it. I will add all possible values to the binding if that is what you want :) Regards, Marco > > Adapting a binding is just 1 commit and > > since the property is already existing, there is no breaking change. > Best regards, > Krzysztof > >
