linux-kernel - Re: [PATCH v2 1/2] dt-bindings: iio: pressure: add honeywell,hsc030

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: <ZVtv8x8LqGMhCisw@sunspire>
Date:   Mon, 20 Nov 2023 16:40:51 +0200
From:   Petre Rodan <petre.rodan@...dimension.ro>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     linux-kernel@...r.kernel.org, linux-iio@...r.kernel.org,
        devicetree@...r.kernel.org, Conor Dooley <conor+dt@...nel.org>,
        Lars-Peter Clausen <lars@...afoo.de>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        linux-kernel-mentees@...ts.linuxfoundation.org,
        Jonathan Cameron <jic23@...nel.org>
Subject: Re: [PATCH v2 1/2] dt-bindings: iio: pressure: add honeywell,hsc030


Hello!

On Mon, Nov 20, 2023 at 03:04:07PM +0100, Krzysztof Kozlowski wrote:
> On 20/11/2023 14:42, Petre Rodan wrote:
> 
> >>> +properties:
> >>> +  compatible:
> >>> +    enum:
> >>> +      - honeywell,hsc
> >>
> >> Way too generic
> > 
> > I'm new to this, please excuse my ignorance.
> > my driver covers all Honeywell pressure sensors under the "TruStability board mount HSC/SSC" moniker.
> 
> We talk here about bindings, not driver. For the driver you can use
> whatever name is approved by reviewers of your driver.
> 
> > that is why my intention was to provide a rather generic name for the driver itself.
> > are you afraid that they will come up with a different device that they will call "hsc" in the future?
> > in this case honeywell,trustability-hsc would be fine?
> > 
> > as I see you prefer to target a particular chip, but I am a bit afraid that the end-user will be confused by needing to set up something like
> > 
> > pressure@28 {
> > 	compatible = "honeywell,hsc030pa";
> 
> The compatible should be specific, thus for example match exact model
> number.

there are an infinite number of combinations of 4 transfer functions and 118 ranges + one custom range, so providing an array with all specific chips that could end up as compatible is out of the question.
I was aiming at providing a generic name for the binding and get the transfer function and the pressure range as required parameters.

> If you can guarantee that all devices from given family are the same in
> respect of programming model and hardware requirements (e.g. supplies),
> then you could go with family name. However such guarantees are rarely
> given.

I see your point.

> Therefore for mprls0025pa I agreed for using one specific model
> for entire family.
> 
> https://lore.kernel.org/all/d577bc44-780f-f25d-29c6-ed1d353b540c@linaro.org/
> 
> 
> > 	reg = <0x28>;
> > 	honeywell,transfer-function = <0>;
> > 	honeywell,pressure-range = "250MD";
> > };
> > 
> > ie. specifying "hsc030pa" as driver while his chip is not in the 030PA range, but 250MD.
> > 
> > so do you prefer
> >  honeywell,trustability-hsc  OR
> >  honeywell,hsc030pa
> 
> I think the latter, just like we did for mprls0025pa. How many devices
> do you have there?

both hsc and ssc have 118 ranges, 4 transfer functions and both can be requested from the manufacturer with custom measurement ranges.

ok,I will rename hsc->hsc030pa in the code as you requested.

> >>> +  honeywell,pmin-pascal:
> >>> +    description: |
> >>> +      Minimum pressure value the sensor can measure in pascal.
> >>> +      To be specified only if honeywell,range_str is set to "NA".
> >>> +    $ref: /schemas/types.yaml#/definitions/int32
> >>
> >> That's uint32. Why do you need negative values?
> > 
> > signed int32 is intentional. some chips have two physical input ports and measure a pressure differential in which case pmin is negative.
> > see either of the pdfs at page 14, table 8, column 2, row 7+
> 
> Then the best would be to change the type in other bindings to have
> int32 everywhere... but dtschema also requires unt32:
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/property-units.yaml

yeah, and also '-kpascal' might be too coarse of a unit when we talk about sensors that have a -125 .. 125 pascal measurement range as '0.5ND' has.

cheers,
peter

-- 
petre rodan