[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AF233D1473C1364ABD51D28909A1B1B75C12D381@pgsmsx114.gar.corp.intel.com>
Date: Fri, 7 Jun 2019 00:23:06 +0000
From: "Ong, Boon Leong" <boon.leong.ong@...el.com>
To: Jose Abreu <Jose.Abreu@...opsys.com>,
Florian Fainelli <f.fainelli@...il.com>,
"Voon, Weifeng" <weifeng.voon@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Maxime Coquelin <mcoquelin.stm32@...il.com>,
Russell King <linux@...linux.org.uk>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Giuseppe Cavallaro" <peppe.cavallaro@...com>,
Andrew Lunn <andrew@...n.ch>,
"Alexandre Torgue" <alexandre.torgue@...com>,
biao huang <biao.huang@...iatek.com>,
"Kweh, Hock Leong" <hock.leong.kweh@...el.com>
Subject: RE: [PATCH net-next v6 2/5] net: stmmac: introducing support for
DWC xPCS logics
>-----Original Message-----
>From: Jose Abreu [mailto:Jose.Abreu@...opsys.com]
>Sent: Wednesday, June 5, 2019 9:13 PM
>To: Florian Fainelli <f.fainelli@...il.com>; Voon, Weifeng
><weifeng.voon@...el.com>; David S. Miller <davem@...emloft.net>;
>Maxime Coquelin <mcoquelin.stm32@...il.com>; Russell King
><linux@...linux.org.uk>
>Cc: netdev@...r.kernel.org; linux-kernel@...r.kernel.org; Giuseppe
>Cavallaro <peppe.cavallaro@...com>; Andrew Lunn <andrew@...n.ch>;
>Alexandre Torgue <alexandre.torgue@...com>; biao huang
><biao.huang@...iatek.com>; Ong, Boon Leong
><boon.leong.ong@...el.com>; Kweh, Hock Leong
><hock.leong.kweh@...el.com>
>Subject: RE: [PATCH net-next v6 2/5] net: stmmac: introducing support for
>DWC xPCS logics
>
>From: Florian Fainelli <f.fainelli@...il.com>
>
>> +Russell,
>>
>> On 6/4/2019 11:58 AM, Voon Weifeng wrote:
>> > From: Ong Boon Leong <boon.leong.ong@...el.com>
>> >
>> > xPCS is DWC Ethernet Physical Coding Sublayer that may be integrated
>> > into a GbE controller that uses DWC EQoS MAC controller. An example of
>> > HW configuration is shown below:-
>> >
>> > <-----------------GBE Controller---------->|<--External PHY chip-->
>> >
>> > +----------+ +----+ +---+ +--------------+
>> > | EQoS | <-GMII->| DW |<-->|PHY| <-- SGMII --> | External GbE |
>> > | MAC | |xPCS| |IF | | PHY Chip |
>> > +----------+ +----+ +---+ +--------------+
>> > ^ ^ ^
>> > | | |
>> > +---------------------MDIO-------------------------+
>> >
>> > xPCS is a Clause-45 MDIO Manageable Device (MMD) and we need a way
>to
>> > differentiate it from external PHY chip that is discovered over MDIO.
>> > Therefore, xpcs_phy_addr is introduced in stmmac platform data
>> > (plat_stmmacenet_data) for differentiating xPCS from 'phy_addr' that
>> > belongs to external PHY.
>>
>> Assuming this DW xPCS can be found with designs other than STMMAC
>would
>> not it make sense to model this as some kind of PHY/MDIO bridge? A
>> little bit like what drivers/net/phy/xilinx_gmii2rgmii.c tries to do?
>
>Yes, DW XPCS is a separate IP that can be sold without the MAC.
Hi Florian, thanks for pointing out the PHY driver for GMII to RGMII converter
implementation. It seems like community would like dwxpcs to take the
converter phy driver direction.
We would like to check with community what is the MAC controller that is
using above PHY driver so that we can dig deeper into the PHY & MAC driver
architecture. We would like to map the existing usage of dwxpcs.c in 3/5 of
this series is architecturally ready for PHY driver framework or new APIs
would need to be defined.
Thanks
Boon Leong
Powered by blists - more mailing lists