All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frank Wunderlich <frank-w@public-files.de>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: "Frank Wunderlich" <linux@fw-web.de>,
	linux-rockchip@lists.infradead.org,
	"Kishon Vijay Abraham I" <kishon@ti.com>,
	"Vinod Koul" <vkoul@kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Johan Jonker" <jbx6244@gmail.com>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
Date: Tue, 19 Apr 2022 19:49:12 +0200	[thread overview]
Message-ID: <trinity-597cf8a3-2ad4-41e6-b3c9-b949f8610533-1650390552136@3c-app-gmx-bap70> (raw)
In-Reply-To: <38e60bb2-123b-09cf-d6ef-3a07c6984108@linaro.org>

> Gesendet: Montag, 18. April 2022 um 17:52 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> > diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> > new file mode 100644
> > index 000000000000..58a8ce175f13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
>
> Filename: vendor,hardware
> so for example "rockchip,pcie3-phy" although Rob proposed recently for
> other bindings using compatible as a base:
> https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/

ok, i rename

> > @@ -0,0 +1,77 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip PCIe v3 phy
> > +
> > +maintainers:
> > +  - Heiko Stuebner <heiko@sntech.de>
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - rockchip,rk3568-pcie3-phy
> > +      - rockchip,rk3588-pcie3-phy
> > +
> > +  reg:
> > +    maxItems: 2
> > +
> > +  clocks:
> > +    minItems: 1
> > +    maxItems: 3
> > +
> > +  clock-names:
> > +    contains:
> > +      anyOf:
> > +        - enum: [ refclk_m, refclk_n, pclk ]
>
> 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).

> > +
> > +  "#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

> > +    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
      use PHY_MODE_PCIE_AGGREGATION (4) as default

> > +
> > +
>
> Just one blank line.
>
> > +required:
> > +  - compatible
> > +  - reg
> > +  - rockchip,phy-grf
>
> phy-cells as well
>
> > +
> > +additionalProperties: false
> > +
> > +unevaluatedProperties: false
>
> Just one please, additionalProperties.
ok

> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/rk3568-cru.h>
> > +    pcie30phy: phy@fe8c0000 {
> > +      compatible = "rockchip,rk3568-pcie3-phy";
> > +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> > +      #phy-cells = <0>;
> > +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> > +       <&cru PCLK_PCIE30PHY>;
>
> Align the entry with opening '<'. Usually the most readable is one clock
> per line.

ok

> > +      clock-names = "refclk_m", "refclk_n", "pclk";
> > +      resets = <&cru SRST_PCIE30PHY>;
> > +      reset-names = "phy";
> > +      rockchip,phy-grf = <&pcie30_phy_grf>;
> > +    };

regards Frank

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

WARNING: multiple messages have this Message-ID (diff)
From: Frank Wunderlich <frank-w@public-files.de>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: "Frank Wunderlich" <linux@fw-web.de>,
	linux-rockchip@lists.infradead.org,
	"Kishon Vijay Abraham I" <kishon@ti.com>,
	"Vinod Koul" <vkoul@kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Johan Jonker" <jbx6244@gmail.com>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
Date: Tue, 19 Apr 2022 19:49:12 +0200	[thread overview]
Message-ID: <trinity-597cf8a3-2ad4-41e6-b3c9-b949f8610533-1650390552136@3c-app-gmx-bap70> (raw)
In-Reply-To: <38e60bb2-123b-09cf-d6ef-3a07c6984108@linaro.org>

> Gesendet: Montag, 18. April 2022 um 17:52 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> > diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> > new file mode 100644
> > index 000000000000..58a8ce175f13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
>
> Filename: vendor,hardware
> so for example "rockchip,pcie3-phy" although Rob proposed recently for
> other bindings using compatible as a base:
> https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/

ok, i rename

> > @@ -0,0 +1,77 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip PCIe v3 phy
> > +
> > +maintainers:
> > +  - Heiko Stuebner <heiko@sntech.de>
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - rockchip,rk3568-pcie3-phy
> > +      - rockchip,rk3588-pcie3-phy
> > +
> > +  reg:
> > +    maxItems: 2
> > +
> > +  clocks:
> > +    minItems: 1
> > +    maxItems: 3
> > +
> > +  clock-names:
> > +    contains:
> > +      anyOf:
> > +        - enum: [ refclk_m, refclk_n, pclk ]
>
> 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).

> > +
> > +  "#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

> > +    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
      use PHY_MODE_PCIE_AGGREGATION (4) as default

> > +
> > +
>
> Just one blank line.
>
> > +required:
> > +  - compatible
> > +  - reg
> > +  - rockchip,phy-grf
>
> phy-cells as well
>
> > +
> > +additionalProperties: false
> > +
> > +unevaluatedProperties: false
>
> Just one please, additionalProperties.
ok

> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/rk3568-cru.h>
> > +    pcie30phy: phy@fe8c0000 {
> > +      compatible = "rockchip,rk3568-pcie3-phy";
> > +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> > +      #phy-cells = <0>;
> > +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> > +       <&cru PCLK_PCIE30PHY>;
>
> Align the entry with opening '<'. Usually the most readable is one clock
> per line.

ok

> > +      clock-names = "refclk_m", "refclk_n", "pclk";
> > +      resets = <&cru SRST_PCIE30PHY>;
> > +      reset-names = "phy";
> > +      rockchip,phy-grf = <&pcie30_phy_grf>;
> > +    };

regards Frank

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy

WARNING: multiple messages have this Message-ID (diff)
From: Frank Wunderlich <frank-w@public-files.de>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: "Frank Wunderlich" <linux@fw-web.de>,
	linux-rockchip@lists.infradead.org,
	"Kishon Vijay Abraham I" <kishon@ti.com>,
	"Vinod Koul" <vkoul@kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Johan Jonker" <jbx6244@gmail.com>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
Date: Tue, 19 Apr 2022 19:49:12 +0200	[thread overview]
Message-ID: <trinity-597cf8a3-2ad4-41e6-b3c9-b949f8610533-1650390552136@3c-app-gmx-bap70> (raw)
In-Reply-To: <38e60bb2-123b-09cf-d6ef-3a07c6984108@linaro.org>

> Gesendet: Montag, 18. April 2022 um 17:52 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> > diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> > new file mode 100644
> > index 000000000000..58a8ce175f13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
>
> Filename: vendor,hardware
> so for example "rockchip,pcie3-phy" although Rob proposed recently for
> other bindings using compatible as a base:
> https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/

ok, i rename

> > @@ -0,0 +1,77 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip PCIe v3 phy
> > +
> > +maintainers:
> > +  - Heiko Stuebner <heiko@sntech.de>
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - rockchip,rk3568-pcie3-phy
> > +      - rockchip,rk3588-pcie3-phy
> > +
> > +  reg:
> > +    maxItems: 2
> > +
> > +  clocks:
> > +    minItems: 1
> > +    maxItems: 3
> > +
> > +  clock-names:
> > +    contains:
> > +      anyOf:
> > +        - enum: [ refclk_m, refclk_n, pclk ]
>
> 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).

> > +
> > +  "#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

> > +    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
      use PHY_MODE_PCIE_AGGREGATION (4) as default

> > +
> > +
>
> Just one blank line.
>
> > +required:
> > +  - compatible
> > +  - reg
> > +  - rockchip,phy-grf
>
> phy-cells as well
>
> > +
> > +additionalProperties: false
> > +
> > +unevaluatedProperties: false
>
> Just one please, additionalProperties.
ok

> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/rk3568-cru.h>
> > +    pcie30phy: phy@fe8c0000 {
> > +      compatible = "rockchip,rk3568-pcie3-phy";
> > +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> > +      #phy-cells = <0>;
> > +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> > +       <&cru PCLK_PCIE30PHY>;
>
> Align the entry with opening '<'. Usually the most readable is one clock
> per line.

ok

> > +      clock-names = "refclk_m", "refclk_n", "pclk";
> > +      resets = <&cru SRST_PCIE30PHY>;
> > +      reset-names = "phy";
> > +      rockchip,phy-grf = <&pcie30_phy_grf>;
> > +    };

regards Frank

WARNING: multiple messages have this Message-ID (diff)
From: Frank Wunderlich <frank-w@public-files.de>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: "Frank Wunderlich" <linux@fw-web.de>,
	linux-rockchip@lists.infradead.org,
	"Kishon Vijay Abraham I" <kishon@ti.com>,
	"Vinod Koul" <vkoul@kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
	"Heiko Stuebner" <heiko@sntech.de>,
	"Lorenzo Pieralisi" <lorenzo.pieralisi@arm.com>,
	"Krzysztof Wilczyński" <kw@linux.com>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	"Johan Jonker" <jbx6244@gmail.com>,
	"Peter Geis" <pgwipeout@gmail.com>,
	"Michael Riesch" <michael.riesch@wolfvision.net>,
	linux-phy@lists.infradead.org, devicetree@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org
Subject: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
Date: Tue, 19 Apr 2022 19:49:12 +0200	[thread overview]
Message-ID: <trinity-597cf8a3-2ad4-41e6-b3c9-b949f8610533-1650390552136@3c-app-gmx-bap70> (raw)
In-Reply-To: <38e60bb2-123b-09cf-d6ef-3a07c6984108@linaro.org>

> Gesendet: Montag, 18. April 2022 um 17:52 Uhr
> Von: "Krzysztof Kozlowski" <krzysztof.kozlowski@linaro.org>
> > diff --git a/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
> > new file mode 100644
> > index 000000000000..58a8ce175f13
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/phy/rockchip-pcie3-phy.yaml
>
> Filename: vendor,hardware
> so for example "rockchip,pcie3-phy" although Rob proposed recently for
> other bindings using compatible as a base:
> https://lore.kernel.org/linux-devicetree/YlhkwvGdcf4ozTzG@robh.at.kernel.org/

ok, i rename

> > @@ -0,0 +1,77 @@
> > +# SPDX-License-Identifier: GPL-2.0
> > +%YAML 1.2
> > +---
> > +$id: http://devicetree.org/schemas/phy/rockchip-pcie3-phy.yaml#
> > +$schema: http://devicetree.org/meta-schemas/core.yaml#
> > +
> > +title: Rockchip PCIe v3 phy
> > +
> > +maintainers:
> > +  - Heiko Stuebner <heiko@sntech.de>
> > +
> > +properties:
> > +  compatible:
> > +    enum:
> > +      - rockchip,rk3568-pcie3-phy
> > +      - rockchip,rk3588-pcie3-phy
> > +
> > +  reg:
> > +    maxItems: 2
> > +
> > +  clocks:
> > +    minItems: 1
> > +    maxItems: 3
> > +
> > +  clock-names:
> > +    contains:
> > +      anyOf:
> > +        - enum: [ refclk_m, refclk_n, pclk ]
>
> 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).

> > +
> > +  "#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

> > +    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
      use PHY_MODE_PCIE_AGGREGATION (4) as default

> > +
> > +
>
> Just one blank line.
>
> > +required:
> > +  - compatible
> > +  - reg
> > +  - rockchip,phy-grf
>
> phy-cells as well
>
> > +
> > +additionalProperties: false
> > +
> > +unevaluatedProperties: false
>
> Just one please, additionalProperties.
ok

> > +
> > +examples:
> > +  - |
> > +    #include <dt-bindings/clock/rk3568-cru.h>
> > +    pcie30phy: phy@fe8c0000 {
> > +      compatible = "rockchip,rk3568-pcie3-phy";
> > +      reg = <0x0 0xfe8c0000 0x0 0x20000>;
> > +      #phy-cells = <0>;
> > +      clocks = <&pmucru CLK_PCIE30PHY_REF_M>, <&pmucru CLK_PCIE30PHY_REF_N>,
> > +       <&cru PCLK_PCIE30PHY>;
>
> Align the entry with opening '<'. Usually the most readable is one clock
> per line.

ok

> > +      clock-names = "refclk_m", "refclk_n", "pclk";
> > +      resets = <&cru SRST_PCIE30PHY>;
> > +      reset-names = "phy";
> > +      rockchip,phy-grf = <&pcie30_phy_grf>;
> > +    };

regards Frank

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2022-04-19 17:50 UTC|newest]

Thread overview: 108+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-16 13:54 [RFC/RFT 0/6] RK3568 PCIe V3 support Frank Wunderlich
2022-04-16 13:54 ` Frank Wunderlich
2022-04-16 13:54 ` Frank Wunderlich
2022-04-16 13:54 ` Frank Wunderlich
2022-04-16 13:54 ` [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-18 15:52   ` Krzysztof Kozlowski
2022-04-18 15:52     ` Krzysztof Kozlowski
2022-04-18 15:52     ` Krzysztof Kozlowski
2022-04-18 15:52     ` Krzysztof Kozlowski
2022-04-19 17:49     ` Frank Wunderlich [this message]
2022-04-19 17:49       ` Aw: " Frank Wunderlich
2022-04-19 17:49       ` Frank Wunderlich
2022-04-19 17:49       ` Frank Wunderlich
2022-04-19 19:43       ` Krzysztof Kozlowski
2022-04-19 19:43         ` Krzysztof Kozlowski
2022-04-19 19:43         ` Krzysztof Kozlowski
2022-04-19 19:43         ` Krzysztof Kozlowski
2022-04-19 20:36         ` Aw: " Frank Wunderlich
2022-04-19 20:36           ` Frank Wunderlich
2022-04-19 20:36           ` Frank Wunderlich
2022-04-19 20:36           ` Frank Wunderlich
2022-04-19 20:48           ` Krzysztof Kozlowski
2022-04-19 20:48             ` Krzysztof Kozlowski
2022-04-19 20:48             ` Krzysztof Kozlowski
2022-04-19 20:48             ` Krzysztof Kozlowski
2022-04-16 13:54 ` [RFC/RFT 2/6] dt-bindings: soc: grf: add pcie30-{phy,pipe}-grf Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-18 15:54   ` Krzysztof Kozlowski
2022-04-18 15:54     ` Krzysztof Kozlowski
2022-04-18 15:54     ` Krzysztof Kozlowski
2022-04-18 15:54     ` Krzysztof Kozlowski
2022-04-19 17:29     ` Aw: " Frank Wunderlich
2022-04-19 17:29       ` Frank Wunderlich
2022-04-19 17:29       ` Frank Wunderlich
2022-04-19 17:29       ` Frank Wunderlich
2022-04-19 19:40       ` Krzysztof Kozlowski
2022-04-19 19:40         ` Krzysztof Kozlowski
2022-04-19 19:40         ` Krzysztof Kozlowski
2022-04-19 19:40         ` Krzysztof Kozlowski
2022-04-20 13:04         ` Aw: " Frank Wunderlich
2022-04-20 13:04           ` Frank Wunderlich
2022-04-20 13:04           ` Frank Wunderlich
2022-04-20 13:04           ` Frank Wunderlich
2022-04-16 13:54 ` [RFC/RFT 3/6] phy: rockchip: Support pcie v3 Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-18 10:38   ` Vinod Koul
2022-04-18 10:38     ` Vinod Koul
2022-04-18 10:38     ` Vinod Koul
2022-04-18 10:38     ` Vinod Koul
2022-04-18 15:57   ` Krzysztof Kozlowski
2022-04-18 15:57     ` Krzysztof Kozlowski
2022-04-18 15:57     ` Krzysztof Kozlowski
2022-04-18 15:57     ` Krzysztof Kozlowski
2022-04-20  7:29   ` Philipp Zabel
2022-04-20  7:29     ` Philipp Zabel
2022-04-20  7:29     ` Philipp Zabel
2022-04-20  7:29     ` Philipp Zabel
2022-04-16 13:54 ` [RFC/RFT 4/6] PCI: rockchip-dwc: add pcie bifurcation Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 23:30   ` Bjorn Helgaas
2022-04-16 23:30     ` Bjorn Helgaas
2022-04-16 23:30     ` Bjorn Helgaas
2022-04-16 23:30     ` Bjorn Helgaas
2022-04-17  9:08     ` Aw: " Frank Wunderlich
2022-04-17  9:08       ` Frank Wunderlich
2022-04-17  9:08       ` Frank Wunderlich
2022-04-17  9:08       ` Frank Wunderlich
2022-04-18 15:53       ` Bjorn Helgaas
2022-04-18 15:53         ` Bjorn Helgaas
2022-04-18 15:53         ` Bjorn Helgaas
2022-04-18 15:53         ` Bjorn Helgaas
2022-04-18 16:17         ` Peter Geis
2022-04-18 16:17           ` Peter Geis
2022-04-18 16:17           ` Peter Geis
2022-04-18 16:17           ` Peter Geis
2022-04-21 15:41           ` Aw: " Frank Wunderlich
2022-04-21 15:41             ` Frank Wunderlich
2022-04-21 15:41             ` Frank Wunderlich
2022-04-21 15:41             ` Frank Wunderlich
2022-04-16 13:54 ` [RFC/RFT 5/6] arm64: dts: rockchip: rk3568: Add PCIe v3 nodes Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54 ` [RFC/RFT 6/6] arm64: dts: rockchip: Add PCIe v3 nodes to BPI-R2-Pro Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-16 13:54   ` Frank Wunderlich
2022-04-18 15:57   ` Krzysztof Kozlowski
2022-04-18 15:57     ` Krzysztof Kozlowski
2022-04-18 15:57     ` Krzysztof Kozlowski
2022-04-18 15:57     ` Krzysztof Kozlowski
2022-05-11 19:26 ` [RFC/RFT 0/6] RK3568 PCIe V3 support Piotr Oniszczuk
2022-05-11 19:26   ` Piotr Oniszczuk
2022-05-11 19:26   ` Piotr Oniszczuk
2022-05-11 19:26   ` Piotr Oniszczuk
2022-05-11 20:10   ` Frank Wunderlich
2022-05-11 20:10     ` Frank Wunderlich
2022-05-11 20:10     ` Frank Wunderlich
2022-05-11 20:10     ` Frank Wunderlich

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=trinity-597cf8a3-2ad4-41e6-b3c9-b949f8610533-1650390552136@3c-app-gmx-bap70 \
    --to=frank-w@public-files.de \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=heiko@sntech.de \
    --cc=jbx6244@gmail.com \
    --cc=kishon@ti.com \
    --cc=krzk+dt@kernel.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=kw@linux.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-phy@lists.infradead.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux@fw-web.de \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=michael.riesch@wolfvision.net \
    --cc=p.zabel@pengutronix.de \
    --cc=pgwipeout@gmail.com \
    --cc=robh+dt@kernel.org \
    --cc=vkoul@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.