On 04/04/16 06:25, Andrew Lunn wrote: >> >From 564b767163d19355a3b5efaad195e93796570c71 Mon Sep 17 00:00:00 2001 >> From: Charles-Antoine Couret <charles-antoine.cou...@nexvision.fr> >> Date: Fri, 1 Apr 2016 16:16:35 +0200 >> Subject: [PATCH] Marvell phy: add fiber status check for some components >> >> Marvell's phy could have two modes: fiber and copper. Currently, the driver >> checks only the copper mode registers to get the status link which could be >> wrong. >> >> This commit add a handler to check fiber then copper status link. >> If the fiber link is activated, the driver would use this information. >> Else, it would use the copper status. > > Hi Florian > > What do you think about this? > > This works for basic status information. But what about other ethtool > options? Setting the speed and duplex, turning pause on/off, etc.
Agreed, it seems like a PHY configured for fiber will need to provide these informations differently, or does the standard BMSR register provide accurate information already? > > 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 - have two paths in drv->read_status which take care of reading one status or the other? Are there other side effects for other register accesses (say, statistics, or auto-negotiation) that need to be fiber vs. copper aware? > > 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? -- Florian
