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

[Krzysztof Kozlowski]

On 22/09/2022 13:01, Marco Felsch wrote:
> 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?

Not necessarily all combinations, but in general be complete as in
describe entire device. Pretty often we skip describing full device
because our job does not include it and we need to move on. Fine. But
the argument is not really one Linux implementation.

Especially that limiting binding to some subset might make it later
non-extendable. Not possible to grow, because author did not think about
these other features.

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

So let me rephrase the case - there is no such assumption that one,
particular driver supports entire set of bindings. If anyone makes it,
without actually checking, then it is his/hers mistake.

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

Bindings are also not the tool for system integrator to figure out these
things.

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

Best regards,
Krzysztof