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: <CAKv63uv87srZ3gJxFASuGWV6cULXkN=gYi_L=BCcd3dgOFQEfw@mail.gmail.com>
Date:   Wed, 22 Nov 2023 13:28:25 +0100
From:   Crt Mori <cmo@...exis.com>
To:     Krzysztof Kozlowski <krzk@...nel.org>
Cc:     Jonathan Cameron <jic23@...nel.org>,
        Rob Herring <robh+dt@...nel.org>, linux-iio@...r.kernel.org,
        linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: iio: temperature: add MLX90635 device bindings

On Wed, 22 Nov 2023 at 12:52, Krzysztof Kozlowski <krzk@...nel.org> wrote:
>
> On 22/11/2023 11:27, Crt Mori wrote:
> > Add device tree bindings for MLX90635 Infra Red contactless temperature
> > sensor.
>
> Please use scripts/get_maintainers.pl to get a list of necessary people
> and lists to CC (and consider --no-git-fallback argument). It might
> happen, that command when run on an older kernel, gives you outdated
> entries. Therefore please be sure you base your patches on recent Linux
> kernel.
>

OK, will put everyone in that list in next spin.

> A nit, subject: drop second/last, redundant "bindings". The
> "dt-bindings" prefix is already stating that these are bindings.
>

 Ok, will fix that in next version (probably main driver review will
get some comments).

> >
> > Signed-off-by: Crt Mori <cmo@...exis.com>
> > ---
> >  .../iio/temperature/melexis,mlx90635.yaml     | 60 +++++++++++++++++++
> >  1 file changed, 60 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/iio/temperature/melexis,mlx90635.yaml
> >
> > diff --git a/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90635.yaml b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90635.yaml
> > new file mode 100644
> > index 000000000000..96463121a806
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/temperature/melexis,mlx90635.yaml
> > @@ -0,0 +1,60 @@
> > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/iio/temperature/melexis,mlx90635.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Melexis MLX90635 contactless Infra Red temperature sensor
> > +
> > +maintainers:
> > +  - Crt Mori <cmo@...exis.com>
> > +
> > +description: |
> > +  https://www.melexis.com/en/documents/documentation/datasheets/datasheet-mlx90635
> > +
> > +  There are various applications for the Infra Red contactless temperature
> > +  sensor and MLX90635 is most suitable for consumer applications where
> > +  measured object temperature is in range between -20 to 100 degrees
> > +  Celsius with relative error of measurement 2 degree Celsius in
> > +  object temperature range for industrial applications, while just 0.2
> > +  degree Celsius for human body measurement applications. Since it can
> > +  operate and measure ambient temperature in range of -20 to 85 degrees
> > +  Celsius it is suitable also for outdoor use.
> > +
> > +  Be aware that electronics surrounding the sensor can increase ambient
> > +  temperature. MLX90635 can be calibrated to reduce the housing effect via
> > +  already existing EEPROM parameters.
> > +
> > +  Since measured object emissivity effects Infra Red energy emitted,
> > +  emissivity should be set before requesting the object temperature.
> > +
> > +properties:
> > +  compatible:
> > +    const: melexis,mlx90635
>
> It's the same as mlx90632. Add it there (as enum).
>

Properties are the same, but then you can't have much differences for
a temperature sensor. It has a bit worse relative measurement error
outside of the human body range and overall different DSP, register
map, even physical size - it's 1.8x1.8 mm compared to 90632 3x3 mm. I
was not sure how it qualifies for adding it as another enum, but I
went with the feeling that if it can reuse the driver, then it is an
enum, otherwise it is a new file. And I could not reuse anything from
90632.

Thanks for quick feedback and best regards,
Crt
> Best regards,
> Krzysztof
>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ