| Message ID | 20230814141739.25552-1-josua@solid-run.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | [v2] net: sfp: handle 100G/25G active optical cables in sfp_parse_support | expand |
On Mon, Aug 14, 2023 at 04:17:39PM +0200, Josua Mayer wrote: > Handle extended compliance code 0x1 (SFF8024_ECC_100G_25GAUI_C2M_AOC) > for active optical cables supporting 25G and 100G speeds. > > Since the specification makes no statement about transmitter range, and > as the specific sfp module that had been tested features only 2m fiber - > short-range (SR) modes are selected. > > The 100G speed is irrelevant because it would require multiple fibers / > multiple SFP28 modules combined under one netdev. > sfp-bus.c only handles a single module per netdev, so only 25Gbps modes > are selected. > > sfp_parse_support already handles SFF8024_ECC_100GBASE_SR4_25GBASE_SR > with compatible properties, however that entry is a contradiction in > itself since with SFP(28) 100GBASE_SR4 is impossible - that would likely > be a mode for qsfp modules only. > > Add a case for SFF8024_ECC_100G_25GAUI_C2M_AOC selecting 25gbase-r > interface mode and 25000baseSR link mode. > Also enforce SFP28 bitrate limits on the values read from sfp eeprom as > requested by Russell King. > > Tested with fs.com S28-AO02 AOC SFP28 module. > > Signed-off-by: Josua Mayer <josua@solid-run.com> > --- > V1 -> V2: added separate case SFF8024_ECC_100G_25GAUI_C2M_AOC > V1 -> V2: added bitrate check for eeprom values > > drivers/net/phy/sfp-bus.c | 11 +++++++++++ > 1 file changed, 11 insertions(+) > > diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c > index e8dd47bffe43..a4b0bb50e2eb 100644 > --- a/drivers/net/phy/sfp-bus.c > +++ b/drivers/net/phy/sfp-bus.c > @@ -258,6 +258,17 @@ void sfp_parse_support(struct sfp_bus *bus, const struct sfp_eeprom_id *id, > switch (id->base.extended_cc) { > case SFF8024_ECC_UNSPEC: > break; > + case SFF8024_ECC_100G_25GAUI_C2M_AOC: > + if (br_min <= 28000 && br_max >= 25000) { > + /* 25GBASE-R, possibly with FEC */ > + __set_bit(PHY_INTERFACE_MODE_25GBASER, interfaces); > + /* > + * There is currently no link mode for 25000base > + * with unspecified range, reuse SR. > + */ Hi Josua, a minor nit from my side: : if you have to re-spin for some other reason, the multi-line comment style for Networking code is: /* This is * something. */ > + phylink_set(modes, 25000baseSR_Full); > + } > + break; > case SFF8024_ECC_100GBASE_SR4_25GBASE_SR: > phylink_set(modes, 100000baseSR4_Full); > phylink_set(modes, 25000baseSR_Full); > -- > 2.35.3 > >
On Mon, 14 Aug 2023 16:17:39 +0200 Josua Mayer wrote: > Handle extended compliance code 0x1 (SFF8024_ECC_100G_25GAUI_C2M_AOC) > for active optical cables supporting 25G and 100G speeds. > > Since the specification makes no statement about transmitter range, and > as the specific sfp module that had been tested features only 2m fiber - > short-range (SR) modes are selected. FWIW this got marked as "changes requested" in patchwork by DaveM. Since we didn't get an Ack from Russell, would you mind fixing the comment style and reposting?
Hi Jakub, Am 17.08.23 um 18:30 schrieb Jakub Kicinski: > On Mon, 14 Aug 2023 16:17:39 +0200 Josua Mayer wrote: >> Handle extended compliance code 0x1 (SFF8024_ECC_100G_25GAUI_C2M_AOC) >> for active optical cables supporting 25G and 100G speeds. >> >> Since the specification makes no statement about transmitter range, and >> as the specific sfp module that had been tested features only 2m fiber - >> short-range (SR) modes are selected. > FWIW this got marked as "changes requested" in patchwork by DaveM. > Since we didn't get an Ack from Russell, would you mind fixing > the comment style and reposting? I will post a v3 soon!
diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c index e8dd47bffe43..a4b0bb50e2eb 100644 --- a/drivers/net/phy/sfp-bus.c +++ b/drivers/net/phy/sfp-bus.c @@ -258,6 +258,17 @@ void sfp_parse_support(struct sfp_bus *bus, const struct sfp_eeprom_id *id, switch (id->base.extended_cc) { case SFF8024_ECC_UNSPEC: break; + case SFF8024_ECC_100G_25GAUI_C2M_AOC: + if (br_min <= 28000 && br_max >= 25000) { + /* 25GBASE-R, possibly with FEC */ + __set_bit(PHY_INTERFACE_MODE_25GBASER, interfaces); + /* + * There is currently no link mode for 25000base + * with unspecified range, reuse SR. + */ + phylink_set(modes, 25000baseSR_Full); + } + break; case SFF8024_ECC_100GBASE_SR4_25GBASE_SR: phylink_set(modes, 100000baseSR4_Full); phylink_set(modes, 25000baseSR_Full);
Handle extended compliance code 0x1 (SFF8024_ECC_100G_25GAUI_C2M_AOC) for active optical cables supporting 25G and 100G speeds. Since the specification makes no statement about transmitter range, and as the specific sfp module that had been tested features only 2m fiber - short-range (SR) modes are selected. The 100G speed is irrelevant because it would require multiple fibers / multiple SFP28 modules combined under one netdev. sfp-bus.c only handles a single module per netdev, so only 25Gbps modes are selected. sfp_parse_support already handles SFF8024_ECC_100GBASE_SR4_25GBASE_SR with compatible properties, however that entry is a contradiction in itself since with SFP(28) 100GBASE_SR4 is impossible - that would likely be a mode for qsfp modules only. Add a case for SFF8024_ECC_100G_25GAUI_C2M_AOC selecting 25gbase-r interface mode and 25000baseSR link mode. Also enforce SFP28 bitrate limits on the values read from sfp eeprom as requested by Russell King. Tested with fs.com S28-AO02 AOC SFP28 module. Signed-off-by: Josua Mayer <josua@solid-run.com> --- V1 -> V2: added separate case SFF8024_ECC_100G_25GAUI_C2M_AOC V1 -> V2: added bitrate check for eeprom values drivers/net/phy/sfp-bus.c | 11 +++++++++++ 1 file changed, 11 insertions(+)