netdev - Re: FWD: [PATCH v2] Marvell phy: add fiber status check for some components

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: <d3b31c38-a15c-bf49-d787-1a7dcd11849d@nexvision.fr>
Date:	Fri, 29 Apr 2016 10:28:01 +0200
From:	Charles-Antoine Couret <charles-antoine.couret@...vision.fr>
To:	Florian Fainelli <f.fainelli@...il.com>,
	Andrew Lunn <andrew@...n.ch>
Cc:	netdev <netdev@...r.kernel.org>
Subject: Re: FWD: [PATCH v2] Marvell phy: add fiber status check for some
 components

Le 11/04/2016 à 21:47, Florian Fainelli a écrit :
>> Do we actually need to stay on page 1 if fibre is in use? How do we
>> initially change to page 1 when the fibre link is still down?
> 
> I also do not feel very comfortable with reading the fiber status first,
> and then copper and then combine these two. At the very best, could we
> do something like:
> 
> - identify if the PHY is configured for fiber in drv->probe or
> drv->config_init, retain that information

But, how configure in runtime the user choice? Add a driver option?
Else, a default choice should be added in init/probe function and the user should change by ethtool or driver recompilation.

> - have two paths in drv->read_status which take care of reading one
> status or the other?

I worked for a solution around that.
But the Marvell's datasheet seems to agree with my previous method:

Extract:
"Notes on Determining which Media Linked Up

Since there are two sets of IEEE registers (one for copper and the other for fiber) the software needs
to be aware of register 22.7:0 so that the correct set of registers are selected. In general the
sequence is as follows.

1-Set the Auto-Negotiation registers of the copper medium. (This step may not be necessary if the
hardware configuration defaults are acceptable).

2-Set the Auto-Negotiation registers of the fiber medium. (This step may not be necessary if the
hardware configuration defaults are acceptable).

3-Poll for link status.Go to step 4 if there is link.

4-Once there is link determine whether the link is copper or fiber medium.

5-Look at the Auto-Negotiation results for the medium that established link.

6-Poll for link status. If link status goes down then go back to step 3."

By default, the phy is configured to be connected on both interfaces with any preference. The first connected was selected.
A preference could be added, but it is not a force mode.

Extract:
"Preferred Media

The device can be programmed to give one media priority over the other. In other words if the
non-preferred media establishes link first and subsequently energy is detected on the preferred
media, the PHY will drop link on the non-preferred media for 4 seconds and give the preferred media
a chance to establish link."

We don't have registers to know really if Copper or Fiber is selected. We can know only by checking status registers as in my commit.

>> Should we be using the old mechanism to swap between TP, BNC and AUI
>> to swap between copper and fibre?
> 
> Did you mean using ethtool -s <iface> port fibre for instance?

So, to implement that I have to renable the port change in phy_ethtool_sset function.
But, the datasheet seems to disagree with this method.

Finally, what do I have to do? I continue my previous way or your suggestion?
I prefer to respect the datasheet, but if it's better for you to follow the other way, I will implement that.

Thank you in advance and have a nice day.
Regards,
Charles-Antoine Couret