Re: [PATCH v2 3/3] net: macb: add support for high speed interface

[Nicolas.Ferre]

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