public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Lunn <andrew@lunn.ch>
To: Moritz Fischer <moritz.fischer@ettus.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Kees Cook <keescook@chromium.org>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	netdev@vger.kernel.org, Alex Williams <alex.williams@ni.com>
Subject: Re: [PATCH net-next 2/3] net: nixge: Add support for having nixge as subdevice
Date: Thu, 30 Aug 2018 19:42:56 +0200	[thread overview]
Message-ID: <20180830174256.GC31581@lunn.ch> (raw)
In-Reply-To: <CAAtXAHceYgPx4A7F14AYEQs9RFo2hP6JTkApHa_GtbxVcdiQNA@mail.gmail.com>

On Thu, Aug 30, 2018 at 09:39:39AM -0700, Moritz Fischer wrote:
> Hi Andrew,
> 
> On Wed, Aug 29, 2018 at 8:11 PM, Andrew Lunn <andrew@lunn.ch> wrote:
> 
> > Could you tell us more about the parent device. I'm guessing PCIe.  Is
> > it x86 so no device tree? Are there cases where it does not have a PHY
> > connected? What is connected instead? SFP? A switch? Can there be
> > multiple PHYs on the MDIO bus?
> 
> The device is part of a larger FPGA design. One use case that I was trying
> to support with this patch is PCIe with x86 (hopefully on it's own PF...)
> Since the whole design isn't completely done, these are the use cases I
> see upcoming and current:
> 
> ARM(64):
> a) DT: PHY over MDIO (current use case), fixed-link with GPIO (coming)
> b) DT: SFP (potentially coming)
> 
> x86:
> a) no PHY (coming)-> fixed-link with GPIO
> b) SFP (potentially), PHY over MDIO (potentially)

Hi Mortiz

For SFP, you need to convert this driver to use phylink. That will
also help you with fixed-link, since phylink will handle probing that
for you.

But this brings its own problems. phylink and sfp currently has no
support for platform devices. The SFP driver needs to know which i2c
bus to use, and which GPIOs are connected to the SFP. phylink parses
the device tree to find out if there is an SFP device, or a fixed
link, etc. I don't know of any conceptual reason why platform data
would not work, it just needs implementing.

There also does not appear to be any in kernel users of the device
tree binding. That gives you some flexibility in that you could think
about making non-backwards compatible changes in the binding. I would
definitely want to move PHYs into an mdio subnode.

I'm not aware of any x86 drivers using fixed link. What they generally
do is register the mdio bus using mdiobus_register() and then use
phy_find_first() to get a PHY. This works O.K. for PCs, laptops, and
PCIe cards where there is only one PHY on the bus. What you might be
able to do is always register the MDIO bus, and if you fail to find a
PHY, instantiate a fixed-link and use that instead.

Reality is, all the core work in this area has been pushed by the
embedded world, which is ARM and device tree. For Intel and Server
style networking, drivers tend to either ignore the Linux core code
and write there own PHY and MDIO bus drivers, or it is all done in
firmware.

     Andrew

  reply	other threads:[~2018-08-30 17:43 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-30  0:40 [PATCH net-next 0/3] nixge: fixed-link support Moritz Fischer
2018-08-30  0:40 ` [PATCH net-next 1/3] net: nixge: Add support for fixed-link subnodes Moritz Fischer
2018-08-30  3:04   ` Andrew Lunn
2018-08-30 17:21     ` Moritz Fischer
2018-08-30 17:54       ` Andrew Lunn
2018-08-30 21:09         ` Moritz Fischer
2018-08-30 17:44   ` kbuild test robot
2018-08-30  0:40 ` [PATCH net-next 2/3] net: nixge: Add support for having nixge as subdevice Moritz Fischer
2018-08-30  1:07   ` Moritz Fischer
2018-08-30  3:11   ` Andrew Lunn
2018-08-30 16:39     ` Moritz Fischer
2018-08-30 17:42       ` Andrew Lunn [this message]
2018-08-30  0:40 ` [PATCH net-next 3/3] net: nixge: Use sysdev instead of ndev->dev.parent for DMA Moritz Fischer

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=20180830174256.GC31581@lunn.ch \
    --to=andrew@lunn.ch \
    --cc=alex.williams@ni.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=moritz.fischer@ettus.com \
    --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