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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 22 Sep 2022 13:01:42 +0200
From:   Marco Felsch <m.felsch@...gutronix.de>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        devicetree@...r.kernel.org, jacopo@...ndi.org,
        Sakari Ailus <sakari.ailus@...ux.intel.com>,
        kieran.bingham+renesas@...asonboard.com,
        linux-kernel@...r.kernel.org, kishon@...com, hverkuil@...all.nl,
        vkoul@...nel.org, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, linux-phy@...ts.infradead.org,
        mchehab@...nel.org, kernel@...gutronix.de,
        linux-media@...r.kernel.org
Subject: Re: [PATCH v2 3/4] media: dt-bindings: add bindings for Toshiba
 TC358746

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