linux-kernel - Aw: Re: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <trinity-a5ae4007-e6e3-4869-80ad-3783109b6d4c-1650400612809@3c-app-gmx-bap70>
Date:   Tue, 19 Apr 2022 22:36:52 +0200
From:   Frank Wunderlich <frank-w@...lic-files.de>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     Frank Wunderlich <linux@...web.de>,
        linux-rockchip@...ts.infradead.org,
        Kishon Vijay Abraham I <kishon@...com>,
        Vinod Koul <vkoul@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Heiko Stuebner <heiko@...ech.de>,
        Lorenzo Pieralisi <lorenzo.pieralisi@....com>,
        Krzysztof Wilczyński <kw@...ux.com>,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        Johan Jonker <jbx6244@...il.com>,
        Peter Geis <pgwipeout@...il.com>,
        Michael Riesch <michael.riesch@...fvision.net>,
        linux-phy@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-pci@...r.kernel.org
Subject: Aw: Re:  Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3
 phy

> Gesendet: Dienstag, 19. April 2022 um 21:43 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@...aro.org>
> An: "Frank Wunderlich" <frank-w@...lic-files.de>
> Cc: "Frank Wunderlich" <linux@...web.de>, linux-rockchip@...ts.infradead.org, "Kishon Vijay Abraham I" <kishon@...com>, "Vinod Koul" <vkoul@...nel.org>, "Rob Herring" <robh+dt@...nel.org>, "Krzysztof Kozlowski" <krzk+dt@...nel.org>, "Heiko Stuebner" <heiko@...ech.de>, "Lorenzo Pieralisi" <lorenzo.pieralisi@....com>, "Krzysztof Wilczyński" <kw@...ux.com>, "Bjorn Helgaas" <bhelgaas@...gle.com>, "Philipp Zabel" <p.zabel@...gutronix.de>, "Johan Jonker" <jbx6244@...il.com>, "Peter Geis" <pgwipeout@...il.com>, "Michael Riesch" <michael.riesch@...fvision.net>, linux-phy@...ts.infradead.org, devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
> Betreff: Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
>
> On 19/04/2022 19:49, Frank Wunderlich wrote:
> >> The list should be strictly ordered (defined), so:
> >>   items:
> >>     - const: ...
> >>     - const: ...
> >>     - const: ...
> >>   minItems: 1
> >>
> >> However the question is - why the clocks have different amount? Is it
> >> per different SoC implementation?
> > 
> > i only know the rk3568, which needs the clocks defined here, don't know about rk3588 yet.
> > in rk3568 TPM i have the pcie-part seems missing (at least the specific register definition), so i had used the driver as i got it from the downstream kernel.
> > 
> > not yet looked if i find a rk3588 TPM and if this part is there as i cannot test it (one of the reasons this is a rfc/rft).
> 
> You can skip RK3588 compatible or define it this strictly also for that
> chip.

currently driver does clk_bulk initialization so i would define it like you suggested (without any SoC specific switch):

  clocks:
    minItems: 1
    maxItems: 3

  clock-names:
    items:
      - const: "refclk_m"
      - const: "refclk_n"
      - const: "pclk"

    minItems: 1

> >>> +
> >>> +  "#phy-cells":
> >>> +    const: 0
> >>> +
> >>> +  resets:
> >>> +    maxItems: 1
> >>> +
> >>> +  reset-names:
> >>> +    const: phy
> >>> +
> >>> +  rockchip,phy-grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description: phandle to the syscon managing the phy "general register files"
> >>> +
> >>> +  rockchip,pipe-grf:
> >>> +    $ref: /schemas/types.yaml#/definitions/phandle
> >>> +    description: phandle to the syscon managing the pipe "general register files"
> >>> +
> >>> +  rockchip,pcie30-phymode:
> >>> +    $ref: '/schemas/types.yaml#/definitions/uint32'
> >>> +    description: |
> >>> +      use PHY_MODE_PCIE_AGGREGATION if not defined
> >>
> >> I don't understand the description. Do you mean here a case when the
> >> variable is missing?
> > 
> > yes, if the property is not set, then value is PHY_MODE_PCIE_AGGREGATION = 4
> 
> Then just use "default: 4"
> 
> > 
> >>> +    minimum: 0x0
> >>> +    maximum: 0x4
> >>
> >> Please explain these values. Register values should not be part of
> >> bindings, but instead some logical behavior of hardware or its logic.
> > 
> > it's a bitmask, so maybe
> > 
> >     description: |
> >       bit0: bifurcation for port 0
> >       bit1: bifurcation for port 1
> >       bit2: aggregation
> 
> That's good. I got impression you have a header with these values. If
> yes - mention it here.
> 
> >       use PHY_MODE_PCIE_AGGREGATION (4) as default
> 
> Just use default as I wrote above.

so like this?

  rockchip,pcie30-phymode:
    $ref: '/schemas/types.yaml#/definitions/uint32'
    description: |
      set the phy-mode for enabling bifurcation
      bit0: bifurcation for port 0
      bit1: bifurcation for port 1
      bit2: aggregation
      constants are defined in the dt-bindings/phy/phy-rockchip-pcie3.h
    minimum: 0x0
    maximum: 0x4
    default: 0x4

regards Frank