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 for Android: free password hash cracker in your pocket

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

Message-ID: <7aa36539595f52cbe5b5b084e1add6359149724e.camel@microchip.com>
Date:   Wed, 8 Jan 2020 10:32:03 +0000
From:   <Nicolas.Ferre@...rochip.com>
To:     <linux@...linux.org.uk>, <mparab@...ence.com>
CC:     <antoine.tenart@...tlin.com>, <dkangude@...ence.com>,
        <hkallweit1@...il.com>, <andrew@...n.ch>, <davem@...emloft.net>,
        <linux-kernel@...r.kernel.org>, <Claudiu.Beznea@...rochip.com>,
        <netdev@...r.kernel.org>, <f.fainelli@...il.com>,
        <a.fatoum@...gutronix.de>, <brad.mouring@...com>,
        <pthombar@...ence.com>
Subject: Re: [PATCH v2 3/3] net: macb: add support for high speed interface

Le samedi 21 décembre 2019 à 11:08 +0000, Milind Parab a écrit :
> > > 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?

Milind,

I'm not against queuing patches 1 & 2 of this series while the 3rd one is
still in review.

However, I would prefer that you follow-up Jakub Kicinski's advice when he
answered to your v2 serries.

So please, re-send the patches 1 as a "fix" type of patch, making sure that it
still applies after latest Antoine's changes. Then, re-send the 2/3 patch of
the series as a v3 collecting reviews (as I didn't received v2).

When the first 2 are queued by David, we can resume the discussion about your
3rd patch and what I can tell you about this topic is that it's really by
following Russell comments and advice that we will make progress: I won't
accept anything without his acknowledgment, of course.

Best regards,
  Nicolas