Skip to content

K
Kernel

openeuler / Kernel
大约 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 20 1月, 2023 4 次提交
  3. 07 12月, 2022 1 次提交
  5. 25 10月, 2022 6 次提交
  7. 03 10月, 2022 5 次提交
  9. 20 9月, 2022 5 次提交
  11. 18 8月, 2022 1 次提交
  13. 30 6月, 2022 1 次提交
  15. 24 6月, 2022 1 次提交
  17. 04 5月, 2022 1 次提交
  19. 03 3月, 2022 1 次提交
  21. 18 1月, 2022 1 次提交
    • R
      net: sfp: fix high power modules without diagnostic monitoring · 5765cee1
      由 Russell King (Oracle) 提交于 
      Commit 7cfa9c92 ("net: sfp: avoid power switch on address-change
modules") unintetionally changed the semantics for high power modules
without the digital diagnostics monitoring. We repeatedly attempt to
read the power status from the non-existing 0xa2 address in a futile
hope this failure is temporary:

[    8.856051] sfp sfp-eth3: module NTT              0000000000000000 rev 0000  sn 0000000000000000 dc 160408
[    8.865843] mvpp2 f4000000.ethernet eth3: switched to inband/1000base-x link mode
[    8.873469] sfp sfp-eth3: Failed to read EEPROM: -5
[    8.983251] sfp sfp-eth3: Failed to read EEPROM: -5
[    9.103250] sfp sfp-eth3: Failed to read EEPROM: -5

We previosuly assumed such modules were powered up in the correct mode,
continuing without further configuration as long as the required power
class was supported by the host.

Restore this behaviour, while preserving the intent of subsequent
patches to avoid the "Address Change Sequence not supported" warning
if we are not going to be accessing the DDM address.

Fixes: 7cfa9c92 ("net: sfp: avoid power switch on address-change modules")
Reported-by: N照山周一郎 <teruyama@springboard-inc.jp>
Tested-by: N照山周一郎 <teruyama@springboard-inc.jp>
Signed-off-by: NRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5765cee1
  23. 05 10月, 2021 1 次提交
  25. 17 6月, 2021 1 次提交
  27. 12 4月, 2021 1 次提交
  29. 29 1月, 2021 2 次提交
    • P
      net: sfp: add mode quirk for GPON module Ubiquiti U-Fiber Instant · f0b4f847
      由 Pali Rohár 提交于 
      The Ubiquiti U-Fiber Instant SFP GPON module has nonsensical information
stored in its EEPROM. It claims to support all transceiver types including
10G Ethernet. Clear all claimed modes and set only 1000baseX_Full, which is
the only one supported.

This module has also phys_id set to SFF, and the SFP subsystem currently
does not allow to use SFP modules detected as SFFs. Add exception for this
module so it can be detected as supported.

This change finally allows to detect and use SFP GPON module Ubiquiti
U-Fiber Instant on Linux system.

EEPROM content of this SFP module is (where XX is serial number):

00: 02 04 0b ff ff ff ff ff ff ff ff 03 0c 00 14 c8    ???........??.??
10: 00 00 00 00 55 42 4e 54 20 20 20 20 20 20 20 20    ....UBNT
20: 20 20 20 20 00 18 e8 29 55 46 2d 49 4e 53 54 41        .??)UF-INSTA
30: 4e 54 20 20 20 20 20 20 34 20 20 20 05 1e 00 36    NT      4   ??.6
40: 00 06 00 00 55 42 4e 54 XX XX XX XX XX XX XX XX    .?..UBNTXXXXXXXX
50: 20 20 20 20 31 34 30 31 32 33 20 20 60 80 02 41        140123  `??A
Signed-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      f0b4f847
    • P
      net: sfp: add workaround for Realtek RTL8672 and RTL9601C chips · 426c6cbc
      由 Pali Rohár 提交于 
      The workaround for VSOL V2801F brand based GPON SFP modules added in commit
0d035bed ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0
workaround") works only for IDs added explicitly to the list. Since there
are rebranded modules where OEM vendors put different strings into the
vendor name field, we cannot base workaround on IDs only.

Moreover the issue which the above mentioned commit tried to work around is
generic not only to VSOL based modules, but rather to all GPON modules
based on Realtek RTL8672 and RTL9601C chips.

These include at least the following GPON modules:
* V-SOL V2801F
* C-Data FD511GX-RM0
* OPTON GP801R
* BAUDCOM BD-1234-SFM
* CPGOS03-0490 v2.0
* Ubiquiti U-Fiber Instant
* EXOT EGS1

These Realtek chips have broken EEPROM emulator which for N-byte read
operation returns just the first byte of EEPROM data, followed by N-1
zeros.

Introduce a new function, sfp_id_needs_byte_io(), which detects SFP modules
with broken EEPROM emulator based on N-1 zeros and switch to 1 byte EEPROM
reading operation.

Function sfp_i2c_read() now always uses single byte reading when it is
required and when function sfp_hwmon_probe() detects single byte access,
it disables registration of hwmon device, because in this case we cannot
reliably and atomically read 2 bytes as is required by the standard for
retrieving values from diagnostic area.

(These Realtek chips are broken in a way that violates SFP standards for
diagnostic interface. Kernel in this case simply cannot do anything less
of skipping registration of the hwmon interface.)

This patch fixes reading of EEPROM content from SFP modules based on
Realtek RTL8672 and RTL9601C chips. Diagnostic interface of EEPROM stays
broken and cannot be fixed.

Fixes: 0d035bed ("net: sfp: VSOL V2801F / CarlitoxxPro CPGOS03-0490 v2.0 workaround")
Co-developed-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Signed-off-by: NPali Rohár <pali@kernel.org>
Signed-off-by: NJakub Kicinski <kuba@kernel.org>
      426c6cbc
  31. 13 1月, 2021 1 次提交
  33. 12 1月, 2021 1 次提交
    • R
      net: sfp: cope with SFPs that set both LOS normal and LOS inverted · 624407d2
      由 Russell King 提交于 
      The SFP MSA defines two option bits in byte 65 to indicate how the
Rx_LOS signal on SFP pin 8 behaves:

bit 2 - Loss of Signal implemented, signal inverted from standard
        definition in SFP MSA (often called "Signal Detect").
bit 1 - Loss of Signal implemented, signal as defined in SFP MSA
        (often called "Rx_LOS").

Clearly, setting both bits results in a meaningless situation: it would
mean that LOS is implemented in both the normal sense (1 = signal loss)
and inverted sense (0 = signal loss).

Unfortunately, there are modules out there which set both bits, which
will be initially interpret as "inverted" sense, and then, if the LOS
signal changes state, we will toggle between LINK_UP and WAIT_LOS
states.

Change our LOS handling to give well defined behaviour: only interpret
these bits as meaningful if exactly one is set, otherwise treat it as
if LOS is not implemented.
Signed-off-by: NRussell King <rmk+kernel@armlinux.org.uk>
Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
Link: https://lore.kernel.org/r/E1kyYQa-0004iR-CU@rmk-PC.armlinux.org.ukSigned-off-by: NJakub Kicinski <kuba@kernel.org>
      624407d2
  35. 10 12月, 2020 1 次提交
  37. 03 11月, 2020 1 次提交
  39. 27 8月, 2020 1 次提交
  41. 24 8月, 2020 1 次提交
  43. 18 7月, 2020 1 次提交
  45. 08 7月, 2020 1 次提交