linux-kernel - Re: [PATCH] media: dt-bindings: ov2685: convert to dtschema

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 14 Mar 2023 19:36:03 +0100
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Luca Weiss <luca@...tu.xyz>, Sakari Ailus <sakari.ailus@....fi>
Cc:     Rob Herring <robh@...nel.org>, linux-kernel@...r.kernel.org,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        ~postmarketos/upstreaming@...ts.sr.ht,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-media@...r.kernel.org, Rob Herring <robh+dt@...nel.org>,
        devicetree@...r.kernel.org,
        Shunqian Zheng <zhengsq@...k-chips.com>,
        phone-devel@...r.kernel.org,
        Helen Koike <helen.koike@...labora.com>
Subject: Re: [PATCH] media: dt-bindings: ov2685: convert to dtschema

On 14/03/2023 19:33, Luca Weiss wrote:
>>>> ia/i2c/ovti,ov2685.yaml
>>>
>>> Looks like rockchip-isp1.yaml uses very incomplete sensor examples in
>>> their
>>> binding example, which sort of makes sense since those bindings are
>>> showing
>>> the rockchip isp bindings and contain the bare minimum to show how a
>>> sensor is connected in dt.
>>>
>>> Not sure how to solve this - ov2685 is also one of three sensors that are
>>> used very abbreviated there.
>>
>> Could these regulators be simply made optional?
> 
> Sure, from driver side it would just get dummy regulators instead.
> 
> Still the clocks are also missing in this rockchip example. Any suggestion 
> what to do about those?
> 
> Honestly I don't want to spend too much time on some ISP docs that I don't 
> really care about, would be nice if the maintainers of that could do that...

In perfect world, the bindings describe the hardware and if hardware
requires supply or clock to operate, then it should be required in the
binding. If some other DTS do not validate - their problem...

In practice, we make tradeoffs. But is it the case here? The binding was
always requiring supplies and clocks, so there is no reason to make
supplies optional. Unless you know the device and they are really optional.

Best regards,
Krzysztof