All of lore.kernel.org
 help / color / mirror / Atom feed
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Frank Wunderlich <frank-w@public-files.de>
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: Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
Date: Tue, 19 Apr 2022 21:43:13 +0200	[thread overview]
Message-ID: <fce0337a-0c71-a040-0a01-f20b55eb568b@linaro.org> (raw)
In-Reply-To: <trinity-597cf8a3-2ad4-41e6-b3c9-b949f8610533-1650390552136@3c-app-gmx-bap70>

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.

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

Best regards,
Krzysztof

WARNING: multiple messages have this Message-ID (diff)
From: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Frank Wunderlich <frank-w@public-files.de>
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: Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
Date: Tue, 19 Apr 2022 21:43:13 +0200	[thread overview]
Message-ID: <fce0337a-0c71-a040-0a01-f20b55eb568b@linaro.org> (raw)
In-Reply-To: <trinity-597cf8a3-2ad4-41e6-b3c9-b949f8610533-1650390552136@3c-app-gmx-bap70>

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.

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

Best regards,
Krzysztof

_______________________________________________
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: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Frank Wunderlich <frank-w@public-files.de>
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: Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
Date: Tue, 19 Apr 2022 21:43:13 +0200	[thread overview]
Message-ID: <fce0337a-0c71-a040-0a01-f20b55eb568b@linaro.org> (raw)
In-Reply-To: <trinity-597cf8a3-2ad4-41e6-b3c9-b949f8610533-1650390552136@3c-app-gmx-bap70>

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.

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

Best regards,
Krzysztof

-- 
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: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
To: Frank Wunderlich <frank-w@public-files.de>
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: Re: Aw: Re: [RFC/RFT 1/6] dt-bindings: phy: rockchip: add pcie3 phy
Date: Tue, 19 Apr 2022 21:43:13 +0200	[thread overview]
Message-ID: <fce0337a-0c71-a040-0a01-f20b55eb568b@linaro.org> (raw)
In-Reply-To: <trinity-597cf8a3-2ad4-41e6-b3c9-b949f8610533-1650390552136@3c-app-gmx-bap70>

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.

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

Best regards,
Krzysztof

_______________________________________________
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 19:43 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     ` Aw: " Frank Wunderlich
2022-04-19 17:49       ` Frank Wunderlich
2022-04-19 17:49       ` Frank Wunderlich
2022-04-19 17:49       ` Frank Wunderlich
2022-04-19 19:43       ` Krzysztof Kozlowski [this message]
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=fce0337a-0c71-a040-0a01-f20b55eb568b@linaro.org \
    --to=krzysztof.kozlowski@linaro.org \
    --cc=bhelgaas@google.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frank-w@public-files.de \
    --cc=heiko@sntech.de \
    --cc=jbx6244@gmail.com \
    --cc=kishon@ti.com \
    --cc=krzk+dt@kernel.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.