linux-kernel - Re: [PATCH v2 1/3] dt-bindings: phy: qcom,usb-snps-femto-v2: Add phy override params bindings

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: <20220314081613.GA28402@hu-pkondeti-hyd.qualcomm.com>
Date:   Mon, 14 Mar 2022 13:46:13 +0530
From:   Pavan Kondeti <quic_pkondeti@...cinc.com>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...onical.com>
CC:     Pavan Kondeti <quic_pkondeti@...cinc.com>,
        Sandeep Maheswaram <quic_c_sanm@...cinc.com>,
        Rob Herring <robh+dt@...nel.org>,
        Andy Gross <agross@...nel.org>,
        Bjorn Andersson <bjorn.andersson@...aro.org>,
        "Kishon Vijay Abraham I" <kishon@...com>,
        Vinod Koul <vkoul@...nel.org>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        Wesley Cheng <wcheng@...eaurora.org>,
        Stephen Boyd <swboyd@...omium.org>,
        Doug Anderson <dianders@...omium.org>,
        Matthias Kaehlcke <mka@...omium.org>,
        <devicetree@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <linux-phy@...ts.infradead.org>,
        <linux-usb@...r.kernel.org>, <quic_ppratap@...cinc.com>,
        <quic_kriskura@...cinc.com>
Subject: Re: [PATCH v2 1/3] dt-bindings: phy: qcom,usb-snps-femto-v2: Add phy
 override params bindings

Hi Krzysztof,

On Mon, Mar 14, 2022 at 08:39:57AM +0100, Krzysztof Kozlowski wrote:
> On 14/03/2022 04:29, Pavan Kondeti wrote:
> > Hi Krzysztof,
> > 
> > On Thu, Mar 03, 2022 at 04:59:22PM +0100, Krzysztof Kozlowski wrote:
> >> On 03/03/2022 07:13, Sandeep Maheswaram wrote:
> >>> Add device tree bindings for SNPS phy tuning parameters.
> >>>
> >>> Signed-off-by: Sandeep Maheswaram <quic_c_sanm@...cinc.com>
> >>> ---
> >>>  .../bindings/phy/qcom,usb-snps-femto-v2.yaml       | 125 +++++++++++++++++++++
> >>>  1 file changed, 125 insertions(+)
> >>>
> >>> diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
> >>> index 0dfe691..227c097 100644
> >>> --- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
> >>> +++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml
> >>> @@ -50,6 +50,131 @@ properties:
> >>>    vdda33-supply:
> >>>      description: phandle to the regulator 3.3V supply node.
> >>>  
> >>> +  qcom,hs-disconnect:
> >>> +    $ref: /schemas/types.yaml#/definitions/uint32
> >>> +    description:
> >>> +      This adjusts the voltage level for the threshold used to
> >>> +      detect a disconnect event at the host. Possible values are.
> >>
> >> ':', instead of full stop.
> >>
> >>> +      7 -> +21.56%
> >>> +      6 -> +17.43%
> >>> +      5 -> +13.32%
> >>> +      4 -> +9.73%
> >>> +      3 -> +6.3
> >>> +      2 -> +3.17%
> >>> +      1 -> 0, Design default%
> >>
> >> Use "default:" instead. Here and in other places.
> >>
> >>> +      0 -> -2.72%
> >>
> >> In current form this should be an enum... but actually current form is
> >> wrong. You should not store register values in DT. What if next version
> >> of hardware has a different meaning of these values?
> >>
> >> Instead, you should store here meaningful values, not register values.
> >>
> > 
> > Thanks for the feedback.
> > 
> > The values in % really makes the tuning easy. People look at the eye diagram
> > and decided whether to increase/decrease the margin. The absolute values
> > may not be that useful. All we need is an "adjustment" here. The databook
> > it self does not give any absolute values.
> > 
> > I agree to the "enum" suggestion which we have been following for the
> > qusb2 driver already. 
> > 
> > The values have not changed in the last 5 years for this hardware block, so
> > defining enums for the % values would be really helpful. 
> 
> I did not say you cannot store here percentages. Quite opposite - store
> here the percentages. Just do not store register value. No. Please read
> my comment again - meaningful values are needed.
> 

IIUC, you are asking us to come up with a meaningful values to encode the
percentage values. However, all the % increments are not linear, so we can't
come up with {min, max} scheme. Lets take an example of hostdisconnect
threshold.

As per the data book,

+      7 -> +21.56%
+      6 -> +17.43%
+      5 -> +13.32%
+      4 -> +9.73%
+      3 -> +6.3
+      2 -> +3.17%
+      1 -> 0, Design default%
+      0 -> -2.72%

so how do we give meaningful values here? Does the below scheme make sense
to you?

#define QCOM_SNPS_FEMTO_HS_DISCONNECT_NEG_2P72	(-272)
#define QCOM_SNPS_FEMTO_HS_DISCONNECT_DEFAULT	0
#define QCOM_SNPS_FEMTO_HS_DISCONNECT_3P17	317
#define QCOM_SNPS_FEMTO_HS_DISCONNECT_6P3	63
..
..

In the driver, we have a mapping (which can be per SoC if required in future)
that takes these values and convert to the correct values for a given
register.

Thanks,
Pavan