All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>
Cc: netdev <netdev@vger.kernel.org>, charles-antoine.couret@nexvision.fr
Subject: Re: FWD: [PATCH v2] Marvell phy: add fiber status check for some components
Date: Mon, 11 Apr 2016 12:47:28 -0700	[thread overview]
Message-ID: <570BFF50.6060909@gmail.com> (raw)
In-Reply-To: <20160404132552.GH21828@lunn.ch>

On 04/04/16 06:25, Andrew Lunn wrote:
>> >From 564b767163d19355a3b5efaad195e93796570c71 Mon Sep 17 00:00:00 2001
>> From: Charles-Antoine Couret <charles-antoine.couret@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

  parent reply	other threads:[~2016-04-11 19:49 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-04 13:25 FWD: [PATCH v2] Marvell phy: add fiber status check for some components Andrew Lunn
2016-04-08 15:45 ` Charles-Antoine Couret
2016-04-11 19:47 ` Florian Fainelli [this message]
2016-04-13  9:27   ` Charles-Antoine Couret
2016-04-29  8:28   ` Charles-Antoine Couret
2016-05-27  9:23     ` Charles-Antoine Couret
2016-06-02 14:56       ` Andrew Lunn
2016-07-12 15:00         ` [PATCH v3] Marvell phy: add fiber status check and configuration for some phys Charles-Antoine Couret
2016-07-12 15:18           ` Andrew Lunn
2016-07-12 15:34             ` Charles-Antoine Couret
2016-07-12 15:57           ` Andrew Lunn
2016-07-13  9:14             ` Charles-Antoine Couret
2016-07-13 13:26               ` Andrew Lunn
2016-07-13 13:46                 ` Charles-Antoine Couret
2016-07-13 15:39                   ` Andrew Lunn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=570BFF50.6060909@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=charles-antoine.couret@nexvision.fr \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.