netdev - Re: [drivers/net/phy/sfp] intermittent failure in state machine checks

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: <18687669-e6f5-79f1-6cf9-d62d65f195db@gmx.net>
Date:   Fri, 10 Jan 2020 09:50:00 +0000
From:   ѽ҉ᶬḳ℠ <vtol@....net>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev@...r.kernel.org
Subject: Re: [drivers/net/phy/sfp] intermittent failure in state machine
 checks


On 10/01/2020 09:27, Russell King - ARM Linux admin wrote:
> On Thu, Jan 09, 2020 at 11:50:14PM +0000, ѽ҉ᶬḳ℠ wrote:
>> On 09/01/2020 23:10, Russell King - ARM Linux admin wrote:
>>> Please don't use mii-tool with SFPs that do not have a PHY; the "PHY"
>>> registers are emulated, and are there just for compatibility. Please
>>> use ethtool in preference, especially for SFPs.
>> Sure, just ethtool is not much of help for this particular matter, all there
>> is ethtool -m and according to you the EEPROM dump is not to be relied on.
> How about just "ethtool eth2" ?

Settings for eth2:
         Supported ports: [ TP ]
         Supported link modes:   1000baseX/Full
         Supported pause frame use: Symmetric
         Supports auto-negotiation: Yes
         Supported FEC modes: Not reported
         Advertised link modes:  1000baseX/Full
         Advertised pause frame use: Symmetric
         Advertised auto-negotiation: Yes
         Advertised FEC modes: Not reported
         Speed: 1000Mb/s
         Duplex: Full
         Port: Twisted Pair
         PHYAD: 0
         Transceiver: internal
         Auto-negotiation: on
         MDI-X: Unknown
         Supports Wake-on: d
         Wake-on: d
         Link detected: yes

And i2cdetect -l

i2c-3   i2c             i2c-0-mux (chan_id 2)                   I2C adapter
i2c-1   i2c             i2c-0-mux (chan_id 0)                   I2C adapter
i2c-8   i2c             i2c-0-mux (chan_id 7)                   I2C adapter
i2c-6   i2c             i2c-0-mux (chan_id 5)                   I2C adapter
i2c-4   i2c             i2c-0-mux (chan_id 3)                   I2C adapter
i2c-2   i2c             i2c-0-mux (chan_id 1)                   I2C adapter
i2c-0   i2c             mv64xxx_i2c adapter                     I2C adapter
i2c-7   i2c             i2c-0-mux (chan_id 6)                   I2C adapter
i2c-5   i2c             i2c-0-mux (chan_id 4)                   I2C adapter

>
>>> CONFIG_DEBUG_GPIO is not the same as having debugfs support enabled.
>>> If debugfs is enabled, then gpiolib will provide the current state
>>> of gpios through debugfs.  debugfs is normally mounted on
>>> /sys/kernel/debug, but may not be mounted by default depending on
>>> policy.  Looking in /proc/filesystems will tell you definitively
>>> whether debugfs is enabled or not in the kernel.
>> debugsfs is mounted but ls -af /sys/kernel/debug/gpio only producing
>> (oddly):
>>
>> /sys/kernel/debug/gpio
> Try "cat /sys/kernel/debug/gpio"

gpiochip2: GPIOs 504-511, parent: i2c/8-0071, pca9538, can sleep:
  gpio-504 (                    |tx-fault            ) in  lo IRQ
  gpio-505 (                    |tx-disable          ) out lo
  gpio-506 (                    |rate-select0        ) in  lo
  gpio-507 (                    |los                 ) in  lo IRQ
  gpio-508 (                    |mod-def0            ) in  lo IRQ

___

Probably unrelated, just for posterity noticed in the logs:

pca953x 8-0071: 8-0071 supply vcc not found, using dummy regulator
___
Meantime Allnet responded, which basically sums up to (blame ping pong - 
it is not me but go and look there instead...)

- driver support is not being handled by Allnet but by Metanoia, latter 
being designer and manufacturer
- Allnet does not have the buying power to persuade Metanoia to look 
into the matter
- it would appear that SFP.C is trying to communicate with Fiber-GBIC 
and fails since the signal reports may not be 100% compatible

Pending is their feedback about SFP MSA conformity.