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]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ