netdev - Re: Altera TSE driver not working in 100mbps mode

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: <20200930235925.GB3996795@lunn.ch>
Date:   Thu, 1 Oct 2020 01:59:25 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     David Bilsby <d.bilsby@...gin.net>
Cc:     Petko Manolov <petkan@...leusys.com>,
        Thor Thayer <thor.thayer@...ux.intel.com>,
        netdev@...r.kernel.org, Russell King <rmk+kernel@...linux.org.uk>
Subject: Re: Altera TSE driver not working in 100mbps mode

> I now seem to be tantalisingly close to getting it working. I can see
> network packets arriving if I do a "tcpdump -i eth0" using a copper
> 10/100/1000Base-T SFP, but no packets seem to be transmitted. I'm guessing
> I've maybe messed up on the device tree entries for either the SFP config or
> maybe how it links back to the TSE. In the TSE device tree section I added
> the following as suggested by your original post:
> 
>         sfp = <&sfp_eth_b>;
> 
>         managed = “in-band-status”;
> 
> Should I have added anything for the "phy-handle", thinks it's "<0>" at the
> moment?

If you have an SFP, you don't need a phy-handle, because you don't
have a copper PHY as such, just an SFP cage. What is in the cage is
phylinks problem.

> For the SFP device tree section I added the following at the top level which
> broadly followed the "sff,sfp" document:
> 
> / {
> 
>     sfp_eth_b: sfp-eth-b {
> 
>         compatible = “sff,sfp”;
> 
>         i2c-bus = <sfp_b_i2c>;
> 
>         los-gpios = <&pca9506 10 GPIO_ACTIVE_HIGH>;
> 
>         …
> 
>     };
> 
> };
> 
> The SFP cage is connected to the "sfp_b_i2c" I2C bus, this is actually off
> an I2C mux but that I'm hoping will be handled by Linux as it has a driver
> for the MUX chip.

That should work, there are other systems like this. 

> I assume the default SFP I2C address (0x50) is used by the PhyLink
> layer so there is no need to specify that?

You say you have a copper module inserted. This does not seem to be
well specified, and how you talk to the PHY does not seem to be well
defined. PHYLINK will try to setup an MDIO bus over I2C using an I2C
address which some vendors uses, and then probe around to try to find
the PHY. Any indication in dmesg that it found it? Most seem to use a
Marvell PHY, but there are some with Broadcom.

> The LED indicators for my set up are off another I2C GPIO expander
> (PCA9506), so I used those references for the LOS, etc "gpios"
> entries. This section also has the "tx-disable-gpios" property,
> again I referenced the appropriate pin off the PCA9506, so I guess
> if I got that wrong then that could explain the failure on the Tx
> side. That said none of the LED GPIOs I hooked up seemed to light so
> maybe there is something up there.
> Any hints would be most welcome.

What does ethtool -m show? With a copper module you might not get too
much useful information.

Also, what does ethtool on the link peer show? Has auto-neg worked?
What link modes are being advertised, etc?

The subject of this email thread is:

Altera TSE driver not working in 100mbps mode

Are you doing your testing at 1G or 100Mbps? I would suggest starting
out at 1G if you can.

      Andrew