linux-kernel - Re: [PATCH v5 5/6] media: dt-bindings: ov5693: document YAML binding

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:   Tue, 12 Jul 2022 17:32:45 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Jacopo Mondi <jacopo@...ndi.org>,
        Tommaso Merciai <tommaso.merciai@...rulasolutions.com>
Cc:     linuxfancy@...glegroups.com, linux-amarula@...rulasolutions.com,
        quentin.schulz@...obroma-systems.com,
        Daniel Scally <djrscally@...il.com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-media@...r.kernel.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 5/6] media: dt-bindings: ov5693: document YAML binding

On 12/07/2022 17:25, Jacopo Mondi wrote:
> Hi Krzysztof
>    could you have a look at the below question ?

Sorry, there was a bunch of quoted text without end. When you reply
under quote, please remove the rest of the quote. None of us have a lot
of time to waste on scrolling emails...

> 
> If no need to resend from Tommaso I think the series could be
> collected for v5.20.
> 
> On Mon, Jul 11, 2022 at 11:37:05AM +0200, Jacopo Mondi wrote:
>> Hi Tommaso, Krzysztof,
>>
>>    This has been reviewed by Krzysztof already, so I guess it's fine,
>> but let me ask anyway
>>
>> On Thu, Jun 30, 2022 at 03:48:34PM +0200, Tommaso Merciai wrote:
>>> Add documentation of device tree in YAML schema for the OV5693
>>> CMOS image sensor from Omnivision
>>>
>>> Signed-off-by: Tommaso Merciai <tommaso.merciai@...rulasolutions.com>
>>> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
>>> ---
>>> Changes since v1:
>>>  - Fix allOf position as suggested by Krzysztof
>>>  - Remove port description as suggested by Krzysztof
>>>  - Fix EOF as suggested by Krzysztof
>>>
>>> Changes since v2:
>>>  - Fix commit body as suggested by Krzysztof
>>>
>>> Changes since v3:
>>>  - Add reviewed-by tags, suggested by Jacopo, Krzysztof
>>>
>>> Changes since v4:
>>>  - Remove wrong Sakari reviewed-by tag, suggested by Krzysztof, Sakari
>>>
>>>  .../bindings/media/i2c/ovti,ov5693.yaml       | 106 ++++++++++++++++++
>>>  MAINTAINERS                                   |   1 +
>>>  2 files changed, 107 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
>>> new file mode 100644
>>> index 000000000000..b83c9fc04023
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5693.yaml
>>> @@ -0,0 +1,106 @@
>>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>>> +# Copyright (c) 2022 Amarulasolutions
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/media/i2c/ovti,ov5693.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: Omnivision OV5693 CMOS Sensor
>>> +
>>> +maintainers:
>>> +  - Tommaso Merciai <tommaso.merciai@...rulasolutions.com>
>>> +
>>> +description: |
>>> +  The Omnivision OV5693 is a high performance, 1/4-inch, 5 megapixel, CMOS
>>> +  image sensor that delivers 2592x1944 at 30fps. It provides full-frame,
>>> +  sub-sampled, and windowed 10-bit MIPI images in various formats via the
>>> +  Serial Camera Control Bus (SCCB) interface.
>>> +
>>> +  OV5693 is controlled via I2C and two-wire Serial Camera Control Bus (SCCB).
>>> +  The sensor output is available via CSI-2 serial data output (up to 2-lane).
>>> +
>>> +allOf:
>>> +  - $ref: /schemas/media/video-interface-devices.yaml#
>>> +
>>> +properties:
>>> +  compatible:
>>> +    const: ovti,ov5693
>>> +
>>> +  reg:
>>> +    maxItems: 1
>>> +
>>> +  clocks:
>>> +    description:
>>> +      System input clock (aka XVCLK). From 6 to 27 MHz.
>>> +    maxItems: 1
>>> +
>>> +  dovdd-supply:
>>> +    description:
>>> +      Digital I/O voltage supply, 1.8V.
>>> +
>>> +  avdd-supply:
>>> +    description:
>>> +      Analog voltage supply, 2.8V.
>>> +
>>> +  dvdd-supply:
>>> +    description:
>>> +      Digital core voltage supply, 1.2V.
>>> +
>>> +  reset-gpios:
>>> +    description:
>>> +      The phandle and specifier for the GPIO that controls sensor reset.
>>> +      This corresponds to the hardware pin XSHUTDN which is physically
>>> +      active low.
>>> +    maxItems: 1
>>> +
>>> +required:
>>> +  - compatible
>>> +  - reg
>>> +  - clocks
>>> +  - dovdd-supply
>>> +  - avdd-supply
>>> +  - dvdd-supply
>>
>> Should supplies be made mandatory ? Sensors are often powered by fixed
>> rails. Do we want DTS writers to create "fixed-regulators" for all of
>> them ? The fact the regulator framework creates dummies if there's no
>> entry in .dts for a regulator makes me think it's fine to have them
>> optional, but I understand how Linux works should not be an indication
>> of how a bindings should look like.
>>
> 
> This question ^ :)

My generic answer for generic devices would be - if resource is
physically required (one need to connect the wire), I would say it
should be also required in the bindings. This also forces driver
developer to think about these resources and might result on
portable/better code.

However your point is correct that it might create many "fake"
regulators, because pretty often these are fixed on the board and not
controllable. Therefore I am fine with not requiring them - to adjust
the bindings to real life cases.

Best regards,
Krzysztof