netdev - [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given

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-next>] [day] [month] [year] [list]

Message-Id: <20180504152103.18152-1-antoine.tenart@bootlin.com>
Date:   Fri,  4 May 2018 17:21:03 +0200
From:   Antoine Tenart <antoine.tenart@...tlin.com>
To:     davem@...emloft.net, linux@...linux.org.uk
Cc:     Antoine Tenart <antoine.tenart@...tlin.com>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        thomas.petazzoni@...tlin.com, maxime.chevallier@...tlin.com,
        gregory.clement@...tlin.com, miquel.raynal@...tlin.com,
        nadavh@...vell.com, stefanc@...vell.com, ymarkman@...vell.com,
        mw@...ihalf.com
Subject: [PATCH net-next] net: phy: sfp: handle cases where neither BR,min nor BR,max is given

When computing the bitrate using values read from an SFP module EEPROM,
we use the nominal BR plus BR,min and BR,max to determine the
boundaries. But in some cases BR,min and BR,max aren't provided, which
led the SFP code to end up having the nominal value for both the minimum
and maximum bitrate values. When using a passive cable, the nominal
value should be used as the maximum one, and there is no minimum one
so we should use 0.

Signed-off-by: Antoine Tenart <antoine.tenart@...tlin.com>
---

Hi Russell,

I'm not completely sure about this patch as this case is not really
specified in the specification. But the issue is there, and I've discuss
this with others. It seemed logical (at least to us :)) to use the
BR,nominal values as br_max and 0 as br_min when using a passive cable
which only provides BR,nominal as this would be the highest rate at
which the cable could work. And because it's passive, there should be no
issues using it at a lower rate.

I've tested this with one passive cable which only reports its
BR,nominal (which was 10300) while it could be used when using 1000baseX
or 2500baseX modes.

Thanks,
Antoine

 drivers/net/phy/sfp-bus.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/drivers/net/phy/sfp-bus.c b/drivers/net/phy/sfp-bus.c
index fd6c23f69c2f..d437f4f5ed52 100644
--- a/drivers/net/phy/sfp-bus.c
+++ b/drivers/net/phy/sfp-bus.c
@@ -132,6 +132,13 @@ void sfp_parse_support(struct sfp_bus *bus, const struct sfp_eeprom_id *id,
 			br_max = br_nom + br_nom * id->ext.br_min / 100;
 			br_min = br_nom - br_nom * id->ext.br_min / 100;
 		}
+
+		/* When using passive cables, in case neither BR,min nor BR,max
+		 * are specified, set br_min to 0 as the nominal value is then
+		 * used as the maximum.
+		 */
+		if (br_min == br_max && id->base.sfp_ct_passive)
+			br_min = 0;
 	}

 	/* Set ethtool support from the compliance fields. */
-- 
2.17.0