netdev - Re: [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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180508123026.GJ16141@n2100.armlinux.org.uk>
Date:   Tue, 8 May 2018 13:30:26 +0100
From:   Russell King - ARM Linux <linux@...linux.org.uk>
To:     Antoine Tenart <antoine.tenart@...tlin.com>
Cc:     davem@...emloft.net, 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: Re: [PATCH net-next] net: phy: sfp: handle cases where neither
 BR,min nor BR,max is given

On Fri, May 04, 2018 at 05:21:03PM +0200, Antoine Tenart wrote:
> 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.

The electronic engineer in me says that using zero isn't really valid
because there are coupling capacitors in the SFP module that block DC.
These blocking capacitors are required by the SFP+ specs to have a high
pass pole of between 20kHz and 100kHz - in other words, frequencies
below this are attenuated by the coupling capacitors.  The relationship
between this and the bit rate will be a function of the encoding, so we
can't come to a definitive figure without some math (and I want to be
lazy about that!)

Practically, we're talking about SerDes Ethernet, where the bit rate is
no lower than 100Mbps [*], which will always have a frequency well above
this cut-off.  So, I don't have any problem with your approach to
setting the minimum to zero.  Therefore,

Acked-by: Russell King <rmk+kernel@...linux.org.uk>

Please send me the EEPROM dump using:

ethtool -m <ethernetdevice> raw on > foo.bin

so I can add it to my database for future testing and validation.

Thanks.

* - 10Mbps SGMII is 1Gbps SGMII with each bit repeated 100 times.
    100Mbps SGMII is 1Gbps SGMII with each bit repeated 10 times.
    There is a capability bits for transceivers supporting
    100base-FX/LX but no one has tested those yet.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up