netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: Florian Fainelli <f.fainelli@gmail.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net-next v2 3/3] net: phy: marvell10g: add SFP+ support
Date: Sun, 17 Nov 2019 20:25:29 +0100	[thread overview]
Message-ID: <20191117192529.GB4084@lunn.ch> (raw)
In-Reply-To: <20191116214042.GU25745@shell.armlinux.org.uk>

> The answer is... it depends.

Hi Russell

One issue we have had with phylink is people using the interfaces
wrongly. When asking this question, i was thinking about
documentation. Your answer suggests this method is not simply about
the validation you are doing here, it could also be about
configuration of the PHY to fit the module.

Maybe it would be good to add documentation somewhere about the range
of things this call can do?

> So, this patch reflects what can be done with the SFP+ slots on
> Macchiatobin boards today.

This all sounds very hardware dependent. So we are going to need some
more DT properties i guess. Have you thought about this?

Maybe we need to add compatibles sff,sfp+ and sff,sff+ ? Indicate the
board is capable of the higher speeds? And when sfp+/sff+ is used,
maybe a boolean to indicate it is also sff/sfp compatible?
sfp_select_interface() can then look at these properties and return
PHY_INTERFACE_MODE_NA if the board is not capable of supporting the
module?

Would it even make sense to make the PHY interface more like the MAC
interface? A validate function to indicate what it is capable of? A
configure function to configure its mode towards the SFP?

	  Andrew

  reply	other threads:[~2019-11-17 19:25 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-15 19:53 [PATCH net-next v2 0/3] Add support for SFPs behind PHYs Russell King - ARM Linux admin
2019-11-15 19:56 ` [PATCH net-next v2 1/3] dt-bindings: net: add ethernet controller and phy sfp property Russell King
2019-11-16  0:34   ` Rob Herring
2019-11-16 16:08   ` Andrew Lunn
2019-11-15 19:56 ` [PATCH net-next v2 2/3] net: phy: add core phylib sfp support Russell King
2019-11-16 16:08   ` Andrew Lunn
2019-11-15 19:56 ` [PATCH net-next v2 3/3] net: phy: marvell10g: add SFP+ support Russell King
2019-11-16 16:06   ` Andrew Lunn
2019-11-16 21:40     ` Russell King - ARM Linux admin
2019-11-17 19:25       ` Andrew Lunn [this message]
2019-11-17 19:59         ` Russell King - ARM Linux admin
2019-11-19  0:56 ` [PATCH net-next v2 0/3] Add support for SFPs behind PHYs David Miller

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=20191117192529.GB4084@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux@armlinux.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).