27 Feb, 2019
1 commit
-
[ Upstream commit b5bfc21af5cb3d53f9cee0ef82eaa43762a90f81 ]
When we probe a SFP module, we expect to be able to call the upstream
device's module_insert() function so that the upstream link can be
configured. However, when the upstream device is delayed, we currently
may end up probing the module before the upstream device is available,
and lose the module_insert() call.Avoid this by holding off probing the module until the SFP bus is
properly connected to both the SFP socket driver and the upstream
driver.Signed-off-by: Russell King
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
17 Dec, 2018
1 commit
-
[ Upstream commit d7f7e0018b96fd1a30a968faa9464eb57372c1ec ]
The link modes that sfp_parse_support() detects are stored in the
'modes' bitmap. There is no reason to make an exception for 1000Base-PX
or 1000Base-BX10.Fixes: 03145864bd0f ("sfp: support 1G BiDi (eg, FiberStore SFP-GE-BX) modules")
Signed-off-by: Baruch Siach
Acked-by: Russell King
Signed-off-by: David S. Miller
Signed-off-by: Greg Kroah-Hartman
19 Sep, 2018
1 commit
-
If a network interface is created prior to the SFP socket being
available, ethtool can request module information. This unfortunately
leads to an oops:Unable to handle kernel NULL pointer dereference at virtual address 00000008
pgd = (ptrval)
[00000008] *pgd=7c400831, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1480 Comm: ethtool Not tainted 4.19.0-rc3 #138
Hardware name: Broadcom Northstar Plus SoC
PC is at sfp_get_module_info+0x8/0x10
LR is at dev_ethtool+0x218c/0x2afcFix this by not filling in the network device's SFP bus pointer until
SFP is fully bound, thereby avoiding the core calling into the SFP bus
code.Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages")
Reported-by: Florian Fainelli
Tested-by: Florian Fainelli
Signed-off-by: Russell King
Signed-off-by: David S. Miller
12 Jul, 2018
2 commits
-
It was been observed that with a particular order of initialisation,
the netdev can be up, but the SFP module still has its TX_DISABLE
signal asserted. This occurs when the network device brought up before
the SFP kernel module has been inserted by userspace.This occurs because sfp-bus layer does not hear about the change in
network device state, and so assumes that it is still down. Set
netdev->sfp when the upstream is registered to work around this problem.Signed-off-by: Russell King
Signed-off-by: David S. Miller -
We fail to correctly clean up after a bus registration failure, which
can lead to an incorrect assumption about the registration state of
the upstream or sfp cage.Signed-off-by: Russell King
Signed-off-by: David S. Miller
12 May, 2018
1 commit
-
The bpf syscall and selftests conflicts were trivial
overlapping changes.The r8169 change involved moving the added mdelay from 'net' into a
different function.A TLS close bug fix overlapped with the splitting of the TLS state
into separate TX and RX parts. I just expanded the tests in the bug
fix from "ctx->conf == X" into "ctx->tx_conf == X && ctx->rx_conf
== X".Signed-off-by: David S. Miller
09 May, 2018
1 commit
-
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
Acked-by: Russell King
Signed-off-by: David S. Miller
05 May, 2018
1 commit
-
In an SFP EEPROM values can be read to get information about a given SFP
module. One of those is the bitrate, which can be determined using a
nominal bitrate in addition with min and max values (in %). The SFP code
currently compute both BR,min and BR,max values thanks to this nominal
and min,max values.This patch fixes the BR,min computation as the min value should be
subtracted to the nominal one, not added.Fixes: 9962acf7fb8c ("sfp: add support for 1000Base-PX and 1000Base-BX10")
Signed-off-by: Antoine Tenart
Signed-off-by: David S. Miller
30 Mar, 2018
1 commit
-
Provide a pointer to the SFP bus in struct net_device, so that the
ethtool module EEPROM methods can access the SFP directly, rather
than needing every user to provide a hook for it.Reviewed-by: Andrew Lunn
Signed-off-by: Russell King
Signed-off-by: Florian Fainelli
Reviewed-by: Andrew Lunn
Signed-off-by: Russell King
Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller
01 Mar, 2018
2 commits
-
Negotiate the interface format with the MAC rather than requiring it to
be a fixed type specified solely by the SFP module. This allows modules
that can work with several different interface signalling formats to
select a format compatible with the MAC - for example, a Fiber module
supporing Gigabit ethernet and faster connected to a Gigabit only MAC
needs to select the 1000BASE-X mode.Signed-off-by: Russell King
Signed-off-by: David S. Miller -
Some BiDi modules (eg, FiberStore SFP-GE-BX) are not compliant with
1000BASE-BX as they use different wavelengths from the 1000BASE-BX
standard (eg, 1310nm/1550nm rather than 1310nm/1490nm). These modules
support 1000BASE-X ethernet, so detect them by a failure to find any
other support, the 8B10B encoding and a bit rate that falls within the
1Gbps window.Signed-off-by: Russell King
Signed-off-by: David S. Miller
24 Jan, 2018
1 commit
-
We forgot to update the kernel doc header above sfp_register_upstream()
Fixes: c19bb00070dd ("sfp: convert to fwnode")
Signed-off-by: Florian Fainelli
Signed-off-by: David S. Miller
09 Jan, 2018
1 commit
03 Jan, 2018
4 commits
-
Improve the support for direct-attach copper so that we avoid kernel
warning messages, and report the appropriate PORT_DA type to userspace.
Direct Attach cables can use a number of protocols depending on their
range of speeds.Signed-off-by: Russell King
Signed-off-by: David S. Miller -
Add support for decoding the transceiver information for 1000Base-PX and
1000Base-BX10. These use 1000BASE-X protocol.Signed-off-by: Russell King
Signed-off-by: David S. Miller -
Don't try to guess the support mask from the connector type - this is
mostly irrelevant to the speeds that the transceiver supports.Signed-off-by: Russell King
Signed-off-by: David S. Miller -
When we remove a socket or upstream, and the other side isn't
registered, we dereference a NULL pointer, causing a kernel oops.
Fix this.Fixes: ce0aa27ff3f6 ("sfp: add sfp-bus to bridge between network devices and sfp cages")
Signed-off-by: Russell King
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
06 Dec, 2017
3 commits
-
Convert sfp-bus to use fwnode rather than device_node internally, so
we can support more than just device tree firmware.Signed-off-by: Russell King
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
drivers/net/phy/sfp-bus.c:298:13: warning: context imbalance in 'sfp_bus_release' - wrong count at exit
Signed-off-by: Russell King
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller -
Add kernel-doc documentation for sfp kernel APIs, and link it into the
networking kapi documentation under "Network device support".Signed-off-by: Russell King
Reviewed-by: Florian Fainelli
Signed-off-by: David S. Miller
01 Nov, 2017
1 commit
-
Perform a number of stylistic changes to phylink.c, sfp.c and sfp-bus.c:
- align with netdev-style comments
- align function arguments to the opening parenthesis
- remove blank lines
- fixup a few lines over 80 columnsSigned-off-by: Florian Fainelli
Signed-off-by: David S. Miller
07 Aug, 2017
1 commit
-
Signed-off-by: Russell King
Reviewed-by: Andrew Lunn
Signed-off-by: David S. Miller