From: Hanjie Lin <hanjie.lin@amlogic.com>
To: Jerome Brunet <jbrunet@baylibre.com>,
Kishon Vijay Abraham I <kishon@ti.com>
Cc: Yue Wang <yue.wang@amlogic.com>, <linux-kernel@vger.kernel.org>,
<linux-amlogic@lists.infradead.org>, <linux-pci@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
Kevin Hilman <khilman@baylibre.com>,
Carlo Caione <carlo@caione.org>, Rob Herring <robh@kernel.org>,
<shawn.lin@rock-chips.com>
Subject: Re: [PATCH 2/2] PCI: meson: add the Amlogic Meson PCIe phy driver
Date: Fri, 17 Aug 2018 19:17:09 +0800 [thread overview]
Message-ID: <d6f7e1bf-bbfa-01a0-e86b-d7d8e27c097c@amlogic.com> (raw)
In-Reply-To: <8eb76c5b173a8e8f8f90b9d2204c1b3b0de06c51.camel@baylibre.com>
On 2018/8/17 16:09, Jerome Brunet wrote:
> On Fri, 2018-08-17 at 14:12 +0800, Hanjie Lin wrote:
>>
>> On 2018/8/16 16:33, Jerome Brunet wrote:
>>> On Thu, 2018-08-16 at 11:05 +0800, Hanjie Lin wrote:
>>>>
>>>> On 2018/8/14 18:41, Jerome Brunet wrote:
>>>>> On Tue, 2018-08-14 at 02:12 -0400, Hanjie Lin wrote:
>>>>>> From: Yue Wang <yue.wang@amlogic.com>
>>>>>>
>>>>>> The Meson-PCIE-PHY controller supports the 5-Gbps data rate
>>>>>> of the PCI Express Gen 2 specification and is backwardcompatible
>>>>>> with the 2.5-Gbps Gen 1.1 specification with only
>>>>>> inferred idle detection supported on AMLOGIC SoCs.
>>>>>
>>>>> It looks like the sole purpose of this driver is to provide the reset lines to
>>>>> pcie driver.
>>>>>
>>>>> I wonder why we need this ? Can't the pcie driver claim the reset lines itself.
>>>>>
>>>>> Also, an init of this phy will always reset both port. What will happen if the
>>>>> first port is in use and the 2nd port comes up ??
>>>>>
>>>>> Looks the the pcie driver should claim 'apb' and 'phy' reset lines as "shared"
>>>>> reset and the required 'port' as 'exclusive'
>>>>>
>>>>
>>>> Thank you for your response.
>>>>
>>>> Yes, 'apb' and 'phy' reset lines are shared, and ‘port' reset line is exclusive.
>>>> If we handle all reset lines during the first port initial sequence,
>>>> and when the second port comes up, we will do nothing about the rest lines,
>>>> and don't need a extra API to do ‘port' reset;
>>>
>>> With which other driver are your control shared ?
>>>
>>> Looks it is the answer is none since this phy driver will reset both port
>>> already, even if one is used.
>>>
>>> In this case the fact that you are using shared control is just abusing the
>>> framework to reset once.
>>>
>>> As far as I can tell, this driver makes no sense. The appropriate reset lines
>>> should be given directly to your pcie driver.
>>>
>>>
>>>
>>> .
>>>
>>
>> Amlogic AXG SOC includes two pcie controllers and pipes when only one pcie phy:
>>
>> (port_a reset)
>> |PCIE_RC_A---->PCIE_PIPE_A------|
>> (apb_reset) | | (phy reset)
>> APB BUS---> | | PCIE_PHY
>> | |
>> | (port_b_reset) |
>> |PCIE_RC_B---->PCIE_PIPE_B------|
>>
>> The phy_reset affect the PCIE_PHY.
>> The port_a_reset affect the PCIE_PIPE_A, port_b_reset affect the PCIE_PIPE_B.
>>
>> As your suggestion we will move the 'port' reset to controller driver,
>> and keeping the phy driver to process the 'apb' and 'phy' reset or any
>> more changes of the phy in future.
>
> As far as I can tell from this diagram, It would only make sense for the "phy"
> reset line to be controlled by your phy driver.
>
> The apb and port is obviously related to the pcie device/driver itself, not the
> PHY. And whether you 1 or 2 reset lines in it, IMO it is overkill and
> unnecessary to make a phy driver for this.
>
Yeah, that makes sense.
We will move 'apb' reset to controller driver in next version too.
Thanks.
>>
>
>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: Hanjie Lin <hanjie.lin@amlogic.com>
To: Jerome Brunet <jbrunet@baylibre.com>,
Kishon Vijay Abraham I <kishon@ti.com>
Cc: Rob Herring <robh@kernel.org>,
Kevin Hilman <khilman@baylibre.com>,
shawn.lin@rock-chips.com, linux-kernel@vger.kernel.org,
Yue Wang <yue.wang@amlogic.com>,
linux-pci@vger.kernel.org, Carlo Caione <carlo@caione.org>,
linux-amlogic@lists.infradead.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 2/2] PCI: meson: add the Amlogic Meson PCIe phy driver
Date: Fri, 17 Aug 2018 19:17:09 +0800 [thread overview]
Message-ID: <d6f7e1bf-bbfa-01a0-e86b-d7d8e27c097c@amlogic.com> (raw)
In-Reply-To: <8eb76c5b173a8e8f8f90b9d2204c1b3b0de06c51.camel@baylibre.com>
CgpPbiAyMDE4LzgvMTcgMTY6MDksIEplcm9tZSBCcnVuZXQgd3JvdGU6Cj4gT24gRnJpLCAyMDE4
LTA4LTE3IGF0IDE0OjEyICswODAwLCBIYW5qaWUgTGluIHdyb3RlOgo+Pgo+PiBPbiAyMDE4Lzgv
MTYgMTY6MzMsIEplcm9tZSBCcnVuZXQgd3JvdGU6Cj4+PiBPbiBUaHUsIDIwMTgtMDgtMTYgYXQg
MTE6MDUgKzA4MDAsIEhhbmppZSBMaW4gd3JvdGU6Cj4+Pj4KPj4+PiBPbiAyMDE4LzgvMTQgMTg6
NDEsIEplcm9tZSBCcnVuZXQgd3JvdGU6Cj4+Pj4+IE9uIFR1ZSwgMjAxOC0wOC0xNCBhdCAwMjox
MiAtMDQwMCwgSGFuamllIExpbiB3cm90ZToKPj4+Pj4+IEZyb206IFl1ZSBXYW5nIDx5dWUud2Fu
Z0BhbWxvZ2ljLmNvbT4KPj4+Pj4+Cj4+Pj4+PiBUaGUgTWVzb24tUENJRS1QSFkgY29udHJvbGxl
ciBzdXBwb3J0cyB0aGUgNS1HYnBzIGRhdGEgcmF0ZQo+Pj4+Pj4gb2YgdGhlIFBDSSBFeHByZXNz
IEdlbiAyIHNwZWNpZmljYXRpb24gYW5kIGlzIGJhY2t3YXJkY29tcGF0aWJsZQo+Pj4+Pj4gd2l0
aCB0aGUgMi41LUdicHMgR2VuIDEuMSBzcGVjaWZpY2F0aW9uIHdpdGggb25seQo+Pj4+Pj4gaW5m
ZXJyZWQgaWRsZSBkZXRlY3Rpb24gc3VwcG9ydGVkIG9uIEFNTE9HSUMgU29Dcy4KPj4+Pj4KPj4+
Pj4gSXQgbG9va3MgbGlrZSB0aGUgc29sZSBwdXJwb3NlIG9mIHRoaXMgZHJpdmVyIGlzIHRvIHBy
b3ZpZGUgdGhlIHJlc2V0IGxpbmVzIHRvCj4+Pj4+IHBjaWUgZHJpdmVyLgo+Pj4+Pgo+Pj4+PiBJ
IHdvbmRlciB3aHkgd2UgbmVlZCB0aGlzID8gQ2FuJ3QgdGhlIHBjaWUgZHJpdmVyIGNsYWltIHRo
ZSByZXNldCBsaW5lcyBpdHNlbGYuCj4+Pj4+Cj4+Pj4+IEFsc28sIGFuIGluaXQgb2YgdGhpcyBw
aHkgd2lsbCBhbHdheXMgcmVzZXQgYm90aCBwb3J0LiBXaGF0IHdpbGwgaGFwcGVuIGlmIHRoZQo+
Pj4+PiBmaXJzdCBwb3J0IGlzIGluIHVzZSBhbmQgdGhlIDJuZCBwb3J0IGNvbWVzIHVwID8/IAo+
Pj4+Pgo+Pj4+PiBMb29rcyB0aGUgdGhlIHBjaWUgZHJpdmVyIHNob3VsZCBjbGFpbSAnYXBiJyBh
bmQgJ3BoeScgcmVzZXQgbGluZXMgYXMgInNoYXJlZCIKPj4+Pj4gcmVzZXQgYW5kIHRoZSByZXF1
aXJlZCAncG9ydCcgYXMgJ2V4Y2x1c2l2ZScKPj4+Pj4KPj4+Pgo+Pj4+IFRoYW5rIHlvdSBmb3Ig
eW91ciByZXNwb25zZS4KPj4+Pgo+Pj4+IFllcywgJ2FwYicgYW5kICdwaHknIHJlc2V0IGxpbmVz
IGFyZSBzaGFyZWQsIGFuZCDigJhwb3J0JyByZXNldCBsaW5lIGlzIGV4Y2x1c2l2ZS4KPj4+PiBJ
ZiB3ZSBoYW5kbGUgYWxsIHJlc2V0IGxpbmVzIGR1cmluZyB0aGUgZmlyc3QgcG9ydCBpbml0aWFs
IHNlcXVlbmNlLCAKPj4+PiBhbmQgd2hlbiB0aGUgc2Vjb25kIHBvcnQgY29tZXMgdXAsIHdlIHdp
bGwgZG8gbm90aGluZyBhYm91dCB0aGUgcmVzdCBsaW5lcywgCj4+Pj4gYW5kIGRvbid0IG5lZWQg
YSBleHRyYSBBUEkgdG8gZG8g4oCYcG9ydCcgcmVzZXQ7Cj4+Pgo+Pj4gV2l0aCB3aGljaCBvdGhl
ciBkcml2ZXIgYXJlIHlvdXIgY29udHJvbCBzaGFyZWQgPwo+Pj4KPj4+IExvb2tzIGl0IGlzIHRo
ZSBhbnN3ZXIgaXMgbm9uZSBzaW5jZSB0aGlzIHBoeSBkcml2ZXIgd2lsbCByZXNldCBib3RoIHBv
cnQKPj4+IGFscmVhZHksIGV2ZW4gaWYgb25lIGlzIHVzZWQuCj4+Pgo+Pj4gSW4gdGhpcyBjYXNl
IHRoZSBmYWN0IHRoYXQgeW91IGFyZSB1c2luZyBzaGFyZWQgY29udHJvbCBpcyBqdXN0IGFidXNp
bmcgdGhlCj4+PiBmcmFtZXdvcmsgdG8gcmVzZXQgb25jZS4KPj4+Cj4+PiBBcyBmYXIgYXMgSSBj
YW4gdGVsbCwgdGhpcyBkcml2ZXIgbWFrZXMgbm8gc2Vuc2UuIFRoZSBhcHByb3ByaWF0ZSByZXNl
dCBsaW5lcwo+Pj4gc2hvdWxkIGJlIGdpdmVuIGRpcmVjdGx5IHRvIHlvdXIgcGNpZSBkcml2ZXIu
IAo+Pj4KPj4+Cj4+Pgo+Pj4gLgo+Pj4KPj4KPj4gQW1sb2dpYyBBWEcgU09DIGluY2x1ZGVzIHR3
byBwY2llIGNvbnRyb2xsZXJzIGFuZCBwaXBlcyB3aGVuIG9ubHkgb25lIHBjaWUgcGh5OiAKPj4K
Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKHBvcnRfYSByZXNldCkKPj4g
ICAgICAgICAgICAgICAgICAgICAgIHxQQ0lFX1JDX0EtLS0tPlBDSUVfUElQRV9BLS0tLS0tfCAK
Pj4gICAgIChhcGJfcmVzZXQpICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
fCAgKHBoeSByZXNldCkKPj4gICAgIEFQQiBCVVMtLS0+ICAgICAgIHwgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgfCAgIFBDSUVfUEhZCj4+ICAgICAgICAgICAgICAgICAgICAgICB8ICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKPj4gICAgICAgICAgICAgICAgICAgICAgIHwg
ICAgICAgICAgICAgKHBvcnRfYl9yZXNldCkgICAgfAo+PiAgICAgICAgICAgICAgICAgICAgICAg
fFBDSUVfUkNfQi0tLS0+UENJRV9QSVBFX0ItLS0tLS18Cj4+Cj4+IFRoZSBwaHlfcmVzZXQgYWZm
ZWN0IHRoZSBQQ0lFX1BIWS4KPj4gVGhlIHBvcnRfYV9yZXNldCBhZmZlY3QgdGhlIFBDSUVfUElQ
RV9BLCBwb3J0X2JfcmVzZXQgYWZmZWN0IHRoZSBQQ0lFX1BJUEVfQi4gCj4+Cj4+IEFzIHlvdXIg
c3VnZ2VzdGlvbiB3ZSB3aWxsIG1vdmUgdGhlICdwb3J0JyByZXNldCB0byBjb250cm9sbGVyIGRy
aXZlciwKPj4gYW5kIGtlZXBpbmcgdGhlIHBoeSBkcml2ZXIgdG8gcHJvY2VzcyB0aGUgJ2FwYicg
YW5kICdwaHknIHJlc2V0IG9yIGFueQo+PiBtb3JlIGNoYW5nZXMgb2YgdGhlIHBoeSBpbiBmdXR1
cmUuCj4gCj4gQXMgZmFyIGFzIEkgY2FuIHRlbGwgZnJvbSB0aGlzIGRpYWdyYW0sIEl0IHdvdWxk
IG9ubHkgbWFrZSBzZW5zZSBmb3IgdGhlICJwaHkiCj4gcmVzZXQgbGluZSB0byBiZSBjb250cm9s
bGVkIGJ5IHlvdXIgcGh5IGRyaXZlci4KPiAKPiBUaGUgYXBiIGFuZCBwb3J0IGlzIG9idmlvdXNs
eSByZWxhdGVkIHRvIHRoZSBwY2llIGRldmljZS9kcml2ZXIgaXRzZWxmLCBub3QgdGhlCj4gUEhZ
LiBBbmQgd2hldGhlciB5b3UgMSBvciAyIHJlc2V0IGxpbmVzIGluIGl0LCBJTU8gaXQgaXMgb3Zl
cmtpbGwgYW5kCj4gdW5uZWNlc3NhcnkgdG8gbWFrZSBhIHBoeSBkcml2ZXIgZm9yIHRoaXMuIAo+
IAoKWWVhaCwgdGhhdCBtYWtlcyBzZW5zZS4KV2Ugd2lsbCBtb3ZlICdhcGInIHJlc2V0IHRvIGNv
bnRyb2xsZXIgZHJpdmVyIGluIG5leHQgdmVyc2lvbiB0b28uCgpUaGFua3MuCgo+Pgo+IAo+IAo+
IC4KPiAKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCmxp
bnV4LWFybS1rZXJuZWwgbWFpbGluZyBsaXN0CmxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFk
ZWFkLm9yZwpodHRwOi8vbGlzdHMuaW5mcmFkZWFkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2xpbnV4
LWFybS1rZXJuZWwK
WARNING: multiple messages have this Message-ID (diff)
From: hanjie.lin@amlogic.com (Hanjie Lin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 2/2] PCI: meson: add the Amlogic Meson PCIe phy driver
Date: Fri, 17 Aug 2018 19:17:09 +0800 [thread overview]
Message-ID: <d6f7e1bf-bbfa-01a0-e86b-d7d8e27c097c@amlogic.com> (raw)
In-Reply-To: <8eb76c5b173a8e8f8f90b9d2204c1b3b0de06c51.camel@baylibre.com>
On 2018/8/17 16:09, Jerome Brunet wrote:
> On Fri, 2018-08-17 at 14:12 +0800, Hanjie Lin wrote:
>>
>> On 2018/8/16 16:33, Jerome Brunet wrote:
>>> On Thu, 2018-08-16 at 11:05 +0800, Hanjie Lin wrote:
>>>>
>>>> On 2018/8/14 18:41, Jerome Brunet wrote:
>>>>> On Tue, 2018-08-14 at 02:12 -0400, Hanjie Lin wrote:
>>>>>> From: Yue Wang <yue.wang@amlogic.com>
>>>>>>
>>>>>> The Meson-PCIE-PHY controller supports the 5-Gbps data rate
>>>>>> of the PCI Express Gen 2 specification and is backwardcompatible
>>>>>> with the 2.5-Gbps Gen 1.1 specification with only
>>>>>> inferred idle detection supported on AMLOGIC SoCs.
>>>>>
>>>>> It looks like the sole purpose of this driver is to provide the reset lines to
>>>>> pcie driver.
>>>>>
>>>>> I wonder why we need this ? Can't the pcie driver claim the reset lines itself.
>>>>>
>>>>> Also, an init of this phy will always reset both port. What will happen if the
>>>>> first port is in use and the 2nd port comes up ??
>>>>>
>>>>> Looks the the pcie driver should claim 'apb' and 'phy' reset lines as "shared"
>>>>> reset and the required 'port' as 'exclusive'
>>>>>
>>>>
>>>> Thank you for your response.
>>>>
>>>> Yes, 'apb' and 'phy' reset lines are shared, and ?port' reset line is exclusive.
>>>> If we handle all reset lines during the first port initial sequence,
>>>> and when the second port comes up, we will do nothing about the rest lines,
>>>> and don't need a extra API to do ?port' reset;
>>>
>>> With which other driver are your control shared ?
>>>
>>> Looks it is the answer is none since this phy driver will reset both port
>>> already, even if one is used.
>>>
>>> In this case the fact that you are using shared control is just abusing the
>>> framework to reset once.
>>>
>>> As far as I can tell, this driver makes no sense. The appropriate reset lines
>>> should be given directly to your pcie driver.
>>>
>>>
>>>
>>> .
>>>
>>
>> Amlogic AXG SOC includes two pcie controllers and pipes when only one pcie phy:
>>
>> (port_a reset)
>> |PCIE_RC_A---->PCIE_PIPE_A------|
>> (apb_reset) | | (phy reset)
>> APB BUS---> | | PCIE_PHY
>> | |
>> | (port_b_reset) |
>> |PCIE_RC_B---->PCIE_PIPE_B------|
>>
>> The phy_reset affect the PCIE_PHY.
>> The port_a_reset affect the PCIE_PIPE_A, port_b_reset affect the PCIE_PIPE_B.
>>
>> As your suggestion we will move the 'port' reset to controller driver,
>> and keeping the phy driver to process the 'apb' and 'phy' reset or any
>> more changes of the phy in future.
>
> As far as I can tell from this diagram, It would only make sense for the "phy"
> reset line to be controlled by your phy driver.
>
> The apb and port is obviously related to the pcie device/driver itself, not the
> PHY. And whether you 1 or 2 reset lines in it, IMO it is overkill and
> unnecessary to make a phy driver for this.
>
Yeah, that makes sense.
We will move 'apb' reset to controller driver in next version too.
Thanks.
>>
>
>
> .
>
WARNING: multiple messages have this Message-ID (diff)
From: hanjie.lin@amlogic.com (Hanjie Lin)
To: linus-amlogic@lists.infradead.org
Subject: [PATCH 2/2] PCI: meson: add the Amlogic Meson PCIe phy driver
Date: Fri, 17 Aug 2018 19:17:09 +0800 [thread overview]
Message-ID: <d6f7e1bf-bbfa-01a0-e86b-d7d8e27c097c@amlogic.com> (raw)
In-Reply-To: <8eb76c5b173a8e8f8f90b9d2204c1b3b0de06c51.camel@baylibre.com>
On 2018/8/17 16:09, Jerome Brunet wrote:
> On Fri, 2018-08-17 at 14:12 +0800, Hanjie Lin wrote:
>>
>> On 2018/8/16 16:33, Jerome Brunet wrote:
>>> On Thu, 2018-08-16 at 11:05 +0800, Hanjie Lin wrote:
>>>>
>>>> On 2018/8/14 18:41, Jerome Brunet wrote:
>>>>> On Tue, 2018-08-14 at 02:12 -0400, Hanjie Lin wrote:
>>>>>> From: Yue Wang <yue.wang@amlogic.com>
>>>>>>
>>>>>> The Meson-PCIE-PHY controller supports the 5-Gbps data rate
>>>>>> of the PCI Express Gen 2 specification and is backwardcompatible
>>>>>> with the 2.5-Gbps Gen 1.1 specification with only
>>>>>> inferred idle detection supported on AMLOGIC SoCs.
>>>>>
>>>>> It looks like the sole purpose of this driver is to provide the reset lines to
>>>>> pcie driver.
>>>>>
>>>>> I wonder why we need this ? Can't the pcie driver claim the reset lines itself.
>>>>>
>>>>> Also, an init of this phy will always reset both port. What will happen if the
>>>>> first port is in use and the 2nd port comes up ??
>>>>>
>>>>> Looks the the pcie driver should claim 'apb' and 'phy' reset lines as "shared"
>>>>> reset and the required 'port' as 'exclusive'
>>>>>
>>>>
>>>> Thank you for your response.
>>>>
>>>> Yes, 'apb' and 'phy' reset lines are shared, and ?port' reset line is exclusive.
>>>> If we handle all reset lines during the first port initial sequence,
>>>> and when the second port comes up, we will do nothing about the rest lines,
>>>> and don't need a extra API to do ?port' reset;
>>>
>>> With which other driver are your control shared ?
>>>
>>> Looks it is the answer is none since this phy driver will reset both port
>>> already, even if one is used.
>>>
>>> In this case the fact that you are using shared control is just abusing the
>>> framework to reset once.
>>>
>>> As far as I can tell, this driver makes no sense. The appropriate reset lines
>>> should be given directly to your pcie driver.
>>>
>>>
>>>
>>> .
>>>
>>
>> Amlogic AXG SOC includes two pcie controllers and pipes when only one pcie phy:
>>
>> (port_a reset)
>> |PCIE_RC_A---->PCIE_PIPE_A------|
>> (apb_reset) | | (phy reset)
>> APB BUS---> | | PCIE_PHY
>> | |
>> | (port_b_reset) |
>> |PCIE_RC_B---->PCIE_PIPE_B------|
>>
>> The phy_reset affect the PCIE_PHY.
>> The port_a_reset affect the PCIE_PIPE_A, port_b_reset affect the PCIE_PIPE_B.
>>
>> As your suggestion we will move the 'port' reset to controller driver,
>> and keeping the phy driver to process the 'apb' and 'phy' reset or any
>> more changes of the phy in future.
>
> As far as I can tell from this diagram, It would only make sense for the "phy"
> reset line to be controlled by your phy driver.
>
> The apb and port is obviously related to the pcie device/driver itself, not the
> PHY. And whether you 1 or 2 reset lines in it, IMO it is overkill and
> unnecessary to make a phy driver for this.
>
Yeah, that makes sense.
We will move 'apb' reset to controller driver in next version too.
Thanks.
>>
>
>
> .
>
next prev parent reply other threads:[~2018-08-17 11:17 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-14 6:12 [PATCH 0/2] add the Amlogic Meson PCIe phy driver Hanjie Lin
2018-08-14 6:12 ` Hanjie Lin
2018-08-14 6:12 ` Hanjie Lin
2018-08-14 6:12 ` Hanjie Lin
2018-08-14 6:12 ` Hanjie Lin
2018-08-14 6:12 ` [PATCH 1/2] dt-bindings: PCI: meson: add DT bindings for Amlogic Meson PCIe Phy controller Hanjie Lin
2018-08-14 6:12 ` Hanjie Lin
2018-08-14 6:12 ` Hanjie Lin
2018-08-14 6:12 ` Hanjie Lin
2018-08-14 6:12 ` Hanjie Lin
2018-08-14 22:50 ` Rob Herring
2018-08-14 22:50 ` Rob Herring
2018-08-14 22:50 ` Rob Herring
2018-08-14 22:50 ` Rob Herring
2018-08-16 3:01 ` Hanjie Lin
2018-08-16 3:01 ` Hanjie Lin
2018-08-16 3:01 ` Hanjie Lin
2018-08-16 3:01 ` Hanjie Lin
2018-08-16 3:01 ` Hanjie Lin
2018-08-14 6:12 ` [PATCH 2/2] PCI: meson: add the Amlogic Meson PCIe phy driver Hanjie Lin
2018-08-14 6:12 ` Hanjie Lin
2018-08-14 6:12 ` Hanjie Lin
2018-08-14 6:12 ` Hanjie Lin
2018-08-14 10:41 ` Jerome Brunet
2018-08-14 10:41 ` Jerome Brunet
2018-08-14 10:41 ` Jerome Brunet
2018-08-14 10:41 ` Jerome Brunet
2018-08-16 3:05 ` Hanjie Lin
2018-08-16 3:05 ` Hanjie Lin
2018-08-16 3:05 ` Hanjie Lin
2018-08-16 3:05 ` Hanjie Lin
2018-08-16 8:33 ` Jerome Brunet
2018-08-16 8:33 ` Jerome Brunet
2018-08-16 8:33 ` Jerome Brunet
2018-08-16 8:33 ` Jerome Brunet
2018-08-17 6:12 ` Hanjie Lin
2018-08-17 6:12 ` Hanjie Lin
2018-08-17 6:12 ` Hanjie Lin
2018-08-17 6:12 ` Hanjie Lin
2018-08-17 8:09 ` Jerome Brunet
2018-08-17 8:09 ` Jerome Brunet
2018-08-17 8:09 ` Jerome Brunet
2018-08-17 8:09 ` Jerome Brunet
2018-08-17 11:17 ` Hanjie Lin [this message]
2018-08-17 11:17 ` Hanjie Lin
2018-08-17 11:17 ` Hanjie Lin
2018-08-17 11:17 ` Hanjie Lin
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=d6f7e1bf-bbfa-01a0-e86b-d7d8e27c097c@amlogic.com \
--to=hanjie.lin@amlogic.com \
--cc=carlo@caione.org \
--cc=jbrunet@baylibre.com \
--cc=khilman@baylibre.com \
--cc=kishon@ti.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=robh@kernel.org \
--cc=shawn.lin@rock-chips.com \
--cc=yue.wang@amlogic.com \
/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.