On 22-09-21, Krzysztof Kozlowski wrote:

On 21/09/2022 10:35, Marco Felsch wrote:

quoted

On 22-09-21, Krzysztof Kozlowski wrote:

quoted

On 20/09/2022 19:32, Laurent Pinchart wrote:

quoted

quoted

quoted

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.

quoted

quoted

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

quoted

Adapting a binding is just 1 commit and
since the property is already existing, there is no breaking change.

Best regards,
Krzysztof