From: Conor Dooley <conor@kernel.org>
To: Jan Kiszka <jan.kiszka@siemens.com>
Cc: Jonathan Cameron <jic23@kernel.org>,
linux-iio@vger.kernel.org, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
linux-kernel@vger.kernel.org,
Bao Cheng Su <baocheng.su@siemens.com>,
Chao Zeng <chao.zeng@siemens.com>,
devicetree@vger.kernel.org
Subject: Re: [PATCH 2/3] dt-bindings: iio: Add everlight pm16d17 binding
Date: Tue, 13 Aug 2024 16:52:37 +0100 [thread overview]
Message-ID: <20240813-captivity-spellbind-d36ca0f31e22@spud> (raw)
In-Reply-To: <f6476e06cd8d1cf3aff6563530612c536cd45716.1723527641.git.jan.kiszka@siemens.com>
[-- Attachment #1: Type: text/plain, Size: 4815 bytes --]
On Tue, Aug 13, 2024 at 07:40:41AM +0200, Jan Kiszka wrote:
> From: Chao Zeng <chao.zeng@siemens.com>
>
> Add the binding document for the everlight pm16d17 sensor.
>
> Signed-off-by: Chao Zeng <chao.zeng@siemens.com>
> Co-developed-by: Baocheng Su <baocheng.su@siemens.com>
> Signed-off-by: Baocheng Su <baocheng.su@siemens.com>
Ditto here Jan.
> ---
> .../iio/proximity/everlight,pm16d17.yaml | 95 +++++++++++++++++++
> 1 file changed, 95 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/proximity/everlight,pm16d17.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/proximity/everlight,pm16d17.yaml b/Documentation/devicetree/bindings/iio/proximity/everlight,pm16d17.yaml
> new file mode 100644
> index 000000000000..fadc3075181a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/proximity/everlight,pm16d17.yaml
> @@ -0,0 +1,95 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/proximity/everlight,pm16d17.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Everlight PM-16D17 Ambient Light & Proximity Sensor
> +
> +maintainers:
> + - Chao Zeng <chao.zeng@siemens.com>
> +
> +description: |
> + This sensor uses standard I2C interface. Interrupt function is not covered.
Bindings should be complete, even if software doesn't use the
interrupts. Can you document them please.
> + Datasheet: https://en.everlight.com/sensor/category-proximity_sensor/digital_proximity_sensor/
Do you have a link to a datasheet? The link to the pm16d17 here 404s for
me.
> +
> +properties:
> + compatible:
> + enum:
> + - everlight,pm16d17
> +
> + reg:
> + maxItems: 1
> +
> + ps-gain:
> + description: Receiver gain of proximity sensor
> + $ref: /schemas/types.yaml#/definitions/uint32
> + enum: [1, 2, 4, 8]
> + default: 1
> +
> + ps-itime:
How did you get itime from conversion time? To the layman (like me!)
conversion-time would make more sense...
Also, "ps"? The whole thing is a proxy sensor, so why have that prefix
on properties. What is missing however is a vendor prefix.
> + description: Conversion time for proximity sensor [ms]
> + $ref: /schemas/types.yaml#/definitions/string
Instead of a string, please use the -us suffix, and put this in
microseconds instead.
In total, that would be s/ps-itime/everlight,conversion-time-us/.
I would, however, like to know why this is a property of the hardware.
What factors do you have to consider when determining what value to put
in here?
> + enum:
> + - "0.4"
> + - "0.8"
> + - "1.6"
> + - "3.2"
> + - "6.3"
> + - "12.6"
> + - "25.2"
> + default: "0.4"
> +
> + ps-wtime:
> + description: Waiting time for proximity sensor [ms]
> + $ref: /schemas/types.yaml#/definitions/string
All of the same comments apply here. E.g. why "wtime" isntead of
"waiting-time" and so on.
I would really like to know why these things are properties of the
hardware, rather than something that software should control.
> + enum:
> + - "12.5"
> + - "25"
> + - "50"
> + - "100"
> + - "200"
> + - "400"
> + - "800"
> + - "1600"
> + default: "12.5"
> +
> + ps-ir-led-pulse-count:
> + description: IR LED drive pulse count
> + $ref: /schemas/types.yaml#/definitions/uint32
All custom properties require a vendor prefix, not "ps". Again, what
makes this a property of the hardware, rather than something that
software should control?
> + minimum: 1
> + maximum: 256
> + default: 1
> +
> + ps-offset-cancel:
> + description: |
> + When PS offset cancel function is enabled, the result of subtracting any
> + value specified by the PS offset cancel register from the internal PS
> + output data is written to the PS output data register.
Again, what makes this a property of the hardware? What hardware related
factors determine that value that you put in here?
Thanks,
Conor.
> + $ref: /schemas/types.yaml#/definitions/uint32
> + default: 0
> + maximum: 65535
> +
> +required:
> + - compatible
> + - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + i2c {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + lightsensor: pm16d17@44 {
> + compatible = "everlight,pm16d17";
> + reg = <0x44>;
> +
> + ps-gain = <1>;
> + ps-itime = "0.4";
> + ps-wtime = "12.5";
> + ps-ir-led-pulse-count = <1>;
> + ps-offset-cancel = <280>;
> + };
> + };
> --
> 2.43.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-08-13 15:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-13 5:40 [PATCH 0/3] iio: Add Everlight PM16D17 proximity sensor Jan Kiszka
2024-08-13 5:40 ` [PATCH 1/3] dt-bindings: vendor-prefixes: Add EVERLIGHT Jan Kiszka
2024-08-13 15:41 ` Conor Dooley
2024-08-13 15:46 ` Krzysztof Kozlowski
2024-08-13 15:53 ` Conor Dooley
2024-08-13 5:40 ` [PATCH 2/3] dt-bindings: iio: Add everlight pm16d17 binding Jan Kiszka
2024-08-13 15:52 ` Conor Dooley [this message]
2024-08-16 1:48 ` Li, Hua Qian
2024-08-16 16:11 ` Conor Dooley
2024-08-17 13:42 ` Jonathan Cameron
2024-08-26 7:12 ` Li, Hua Qian
2024-08-26 9:49 ` Jonathan Cameron
2024-08-14 19:10 ` Jonathan Cameron
2024-08-15 8:13 ` Jan Kiszka
2024-08-13 5:40 ` [PATCH 3/3] iio: proximity: Add support for everlight pmd16d17 sensor Jan Kiszka
2024-08-15 5:51 ` kernel test robot
2024-08-15 21:54 ` kernel test robot
2024-08-17 14:02 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240813-captivity-spellbind-d36ca0f31e22@spud \
--to=conor@kernel.org \
--cc=baocheng.su@siemens.com \
--cc=chao.zeng@siemens.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=jan.kiszka@siemens.com \
--cc=jic23@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.