linux-kernel - Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

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]

Message-ID: <70826dc1-d9ea-dc98-f591-c80f1904806a@cogentembedded.com>
Date:   Tue, 27 Mar 2018 11:27:39 +0300
From:   Sergei Shtylyov <sergei.shtylyov@...entembedded.com>
To:     jacopo mondi <jacopo@...ndi.org>,
        Andrzej Hajda <a.hajda@...sung.com>
Cc:     Vladimir Zapolskiy <vladimir_zapolskiy@...tor.com>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>,
        Rob Herring <robh@...nel.org>,
        Laurent Pinchart <laurent.pinchart@...asonboard.com>,
        architt@...eaurora.org, airlied@...ux.ie, horms@...ge.net.au,
        magnus.damm@...il.com, geert@...ux-m68k.org,
        niklas.soderlund@...natech.se, mark.rutland@....com,
        dri-devel@...ts.freedesktop.org, linux-renesas-soc@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document
 THC63LVD1024 LVDS decoder

Hello!

On 3/27/2018 10:33 AM, jacopo mondi wrote:
[...]
>>>>>> Document Thine THC63LVD1024 LVDS decoder device tree bindings.
>>>>>>
>>>>>> Signed-off-by: Jacopo Mondi <jacopo+renesas@...ndi.org>
>>>>>> Reviewed-by: Andrzej Hajda <a.hajda@...sung.com>
>>>>>> Reviewed-by: Niklas Söderlund <niklas.soderlund+renesas@...natech.se>
>>>>>> ---
>>>>>>   .../bindings/display/bridge/thine,thc63lvd1024.txt | 66 +++++++++++++++++++
>>>>>>   1 file changed, 66 insertions(+)
>>>>>>   create mode 100644
>>>>>> Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>>>>
>>>>>> diff --git
>>>>>> a/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>>>> new file mode 100644
>>>>>> index 0000000..8225c6a
>>>>>> --- /dev/null
>>>>>> +++
>>>>>> b/Documentation/devicetree/bindings/display/bridge/thine,thc63lvd1024.txt
>>>>>> @@ -0,0 +1,66 @@
>>>>>> +Thine Electronics THC63LVD1024 LVDS decoder
>>>>>> +-------------------------------------------
>>>>>> +
>>>>>> +The THC63LVD1024 is a dual link LVDS receiver designed to convert LVDS
>>>>>> streams
>>>>>> +to parallel data outputs. The chip supports single/dual input/output modes,
>>>>>> +handling up to two two input LVDS stream and up to two digital CMOS/TTL
>>>>>> outputs.
>>>>>> +
>>>>>> +Single or dual operation modes, output data mapping and DDR output modes
>>>>>> are
>>>>>> +configured through input signals and the chip does not expose any control
>>>>>> bus.
>>>>>> +
>>>>>> +Required properties:
>>>>>> +- compatible: Shall be "thine,thc63lvd1024"
>>>>>> +
>>>>>> +Optional properties:
>>>>>> +- vcc-supply: Power supply for TTL output and digital circuitry
>>>>>> +- cvcc-supply: Power supply for TTL CLOCKOUT signal
>>>>>> +- lvcc-supply: Power supply for LVDS inputs
>>>>>> +- pvcc-supply: Power supply for PLL circuitry
>>>>> As explained in a comment to one of the previous versions of this series, I'm
>>>>> tempted to make vcc-supply mandatory and drop the three other power supplies
>>>>> for now, as I believe there's very little chance they will be connected to
>>>>> separately controllable regulators (all supplies use the same voltage). In the
>>>>> very unlikely event that this occurs in design we need to support in the
>>>>> future, the cvcc, lvcc and pvcc supplies can be added later as optional
>>>>> without breaking backward compatibility.
>>>> I'm okay with that.
>>>>
>>>>> Apart from that,
>>>>>
>>>>> Reviewed-by: Laurent Pinchart <laurent.pinchart@...asonboard.com>
>>>>>
>>>>>> +- pdwn-gpios: Power down GPIO signal. Active low
>>>> powerdown-gpios is the semi-standard name.
>>>>
>>> right, I've also noticed it. If possible please avoid shortenings in
>>> property names.
>>
>> It is not shortening, it just follow pin name from decoder's datasheet.
>>
>>>
>>>>>> +- oe-gpios: Output enable GPIO signal. Active high
>>>>>> +
>>> And this one is also a not ever met property name, please consider to
>>> rename it to 'enable-gpios', for instance display panels define it.
>>
>>
>> Again, it follows datasheet naming scheme. Has something changed in DT
>> conventions?
> 
> Seconded. My understanding is that the property name should reflect
> what reported in the the chip manual. For THC63LVD1024 the enable and
> power down pins are named 'OE' and 'PDWN' respectively.

    But don't we need the vendor prefix in the prop names then, like 
"renesas,oe-gpios" then?

> Thanks
>     j

MBR, Sergei