linux-kernel - RE: [PATCH v2 3/3] net: macb: add support for high speed interface

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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <BY5PR07MB6514F3B5E2A1B910218F7EFBD32C0@BY5PR07MB6514.namprd07.prod.outlook.com>
Date:   Sat, 21 Dec 2019 11:08:18 +0000
From:   Milind Parab <mparab@...ence.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
CC:     "andrew@...n.ch" <andrew@...n.ch>,
        "antoine.tenart@...tlin.com" <antoine.tenart@...tlin.com>,
        "f.fainelli@...il.com" <f.fainelli@...il.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "hkallweit1@...il.com" <hkallweit1@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Dhananjay Vilasrao Kangude <dkangude@...ence.com>,
        "a.fatoum@...gutronix.de" <a.fatoum@...gutronix.de>,
        "brad.mouring@...com" <brad.mouring@...com>,
        Parshuram Raju Thombare <pthombar@...ence.com>,
        "Nicolas.Ferre@...rochip.com" <Nicolas.Ferre@...rochip.com>
Subject: RE: [PATCH v2 3/3] net: macb: add support for high speed interface

>>
>> Additional 3rd party I2C IP required (not part of GEM) for module
>> interrogation (MDIO to I2C handled by SW
>>  +--------------+                                  +-----------+
>>  |              |       |        |                 |  SFP+     |
>>  | GEM MAC/DMA  | <---> | SerDes | <---- SFI-----> | Optical   |
>>  |   USX PCS|   |       | (PMA)  |                 | Module    |
>>  +--------------+                                  +-----------+
>>                                                          ^
>>         +--------+                                       |
>>         | I2C    |                                       |
>>         | Master | <-------------------------------------|
>>         +--------+
>The kernel supports this through the sfp and phylink support. SFI is
>more commonly known as 10GBASE-R. Note that this is *not* USXGMII.
>Link status needs to come from the MAC side, so macb_mac_pcs_get_state()
>is required.
>
>> Rate determined by 10GBASE-T PHY capability through auto-negotiation.
>> I2C IP required
>>  +--------------+                                  +-----------+
>>  |              |       |        |                 |  SFP+ to  |
>>  | GEM MAC/DMA  | <---> | SerDes | <---- SFI-----> | 10GBASE-T |
>>  |   USX PCS|   |       | (PMA)  |                 |           |
>>  +--------------+                                  +-----------+
>>                                                          ^
>>         +--------+                                       |
>>         | I2C    |                                       |
>>         | Master | <-------------------------------------|
>>         +--------+
>
>The 10G copper module I have uses 10GBASE-R, 5000BASE-X, 2500BASE-X,
>and SGMII (without in-band status), dynamically switching between
>these depending on the results of the copper side negotiation.
>
>> USXGMII PHY. Uses MDIO or equivalent for status xfer
>>  +-------------+                                    +--------+
>>  |             |       |        |                   |        |
>>  | GEM MAC/DMA | <---> | SerDes | <--- USXGMII ---> |  PHY   |
>>  |  USX PCS    |       | (PMA)  |                   |        |
>>  +-------------+                                    +--------+
>>        ^                                                 ^
>>        |_____________________ MDIO ______________________|
>
>Overall, please implement phylink properly for your MAC, rather than
>the current half-hearted approach that *will* break in various
>circumstances.
>

We would need more time to get back on the restructured implementation. 
While we work on that, is it okay to accept patch 1/3 and patch 2/3?