[PATCH v2 3/4] media: dt-bindings: add bindings for Toshiba TC358746

[Marco Felsch]

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
> 
>