All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Madalin Bucur (OSS)" <madalin.bucur@oss.nxp.com>
To: Andrew Lunn <andrew@lunn.ch>,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc: "Madalin Bucur (OSS)" <madalin.bucur@oss.nxp.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"davem@davemloft.net" <davem@davemloft.net>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"f.fainelli@gmail.com" <f.fainelli@gmail.com>,
	"hkallweit1@gmail.com" <hkallweit1@gmail.com>,
	"shawnguo@kernel.org" <shawnguo@kernel.org>
Subject: RE: [PATCH 1/6] net: phy: add interface modes for XFI, SFI
Date: Fri, 3 Jan 2020 16:21:09 +0000	[thread overview]
Message-ID: <DB8PR04MB6985AD897CC0159E324DF992EC230@DB8PR04MB6985.eurprd04.prod.outlook.com> (raw)
In-Reply-To: <20200103133523.GA22988@lunn.ch>

> -----Original Message-----
> From: Andrew Lunn <andrew@lunn.ch>
> Sent: Friday, January 3, 2020 3:35 PM
> To: Russell King - ARM Linux admin <linux@armlinux.org.uk>
> Cc: Madalin Bucur (OSS) <madalin.bucur@oss.nxp.com>;
> devicetree@vger.kernel.org; davem@davemloft.net; netdev@vger.kernel.org;
> f.fainelli@gmail.com; hkallweit1@gmail.com; shawnguo@kernel.org
> Subject: Re: [PATCH 1/6] net: phy: add interface modes for XFI, SFI
> 
> > What I might be willing to accept is if we were to introduce
> > XFI_10GBASER, XFI_10GBASEW, XFI_10GFC, XFI_G709 and their SFI
> > counterparts - but, there would remain one HUGE problem with that,
> > which is the total lack of specification of the board characteristics
> > required to achieve XFI electrical compliance.
> 
> Hi Russell
> 
> The four RGMII variants are precedents for mixing protocol and
> 'electrical' properties, in terms of clock delays. But having four
> RGMII variants has been a pain point, implementations getting it
> wrong, etc.

I always thought that a separate property would of simplified code a lot,
there are things to be done for RGMII and one ends up with ugly code:

        /* check RGMII support */
        if (iface == PHY_INTERFACE_MODE_RGMII ||
            iface == PHY_INTERFACE_MODE_RGMII_ID ||
            iface == PHY_INTERFACE_MODE_RGMII_RXID ||
            iface == PHY_INTERFACE_MODE_RGMII_TXID)

That's the reason I've commented on the recent patch set, that maybe it's
time to stop and fix this mess properly, provided that we find a better
solution.

> So i would avoid mixing them in one property. I would prefer we keep
> phy-mode as a protocol property, and we define additional DT
> properties to describe the electrical parts of the SERDES interface.
> 
> Madalin, what electrical properties do you actually need in DT?  I
> guess you need to know if it is using XFI or SFI. But that is only the
> start. Do you want to place all the other properties in DT as well, or
> are they in a board specific firmware blobs, and you just need to know
> if you should use the XFI blob or the SFI blob?

I do not have other electrical propertied to set. Nor do I have a different
blob to load. We're using u-boot as a a bootloader. It supports SFI as a
valid mode for a long time now:

commit d11e9347461cff9ce89e6e65764f73fad0f19c6f
Author: Stefan Roese <sr@denx.de>
Date:   Thu Feb 23 11:58:26 2017 +0100

    net: include/phy.h: Add new PHY interface modes

    This patch adds the new PHY interface modes XAUI, RXAUI and SFI that will
    be used by the PPv2.2 support in the Marvell mvpp2 ethernet driver.

    Signed-off-by: Stefan Roese <sr@denx.de>
    Cc: Stefan Chulski <stefanc@marvell.com>
    Cc: Kostya Porotchkin <kostap@marvell.com>
    Cc: Nadav Haklai <nadavh@marvell.com>
    Acked-by: Joe Hershberger <joe.hershberger@ni.com>

There are many things pushed down to u-boot so the Linux driver has less
work to do, that's one of the reasons there is little left there. Ideally
this dependency should be removed but then we'd need to make a clearer
distinction. As you've noticed, currently I don't even need to distinguish
XFI from SFI because for basic scenarios the code does the same thing.
Problem is, if I select a common denominator now, and later I need to
make this distinction, I'll need to update device trees, code, etc. Just
like "xgmii" was just fine as a placeholder until recently. I'd rather use
a correct description now.

> We can probably define a vendor neutral DT property for XFI vs SFI,
> but i expect all the other electrical properties are going to be
> vendor specific.
> 
>        Andrew

  reply	other threads:[~2020-01-03 16:21 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-19 15:21 [PATCH 0/6] Add PHY connection types for XFI and SFI Madalin Bucur
2019-12-19 15:21 ` [PATCH 1/6] net: phy: add interface modes for XFI, SFI Madalin Bucur
2019-12-19 17:28   ` Russell King - ARM Linux admin
2019-12-19 18:32     ` Madalin Bucur
2019-12-19 19:03       ` Russell King - ARM Linux admin
2019-12-19 21:34         ` Madalin Bucur (OSS)
2019-12-19 21:49           ` Russell King - ARM Linux admin
2019-12-20  7:38             ` Madalin Bucur (OSS)
2019-12-20  9:16               ` Russell King - ARM Linux admin
2019-12-20  9:29                 ` Andrew Lunn
2019-12-20  9:39                   ` Madalin Bucur (OSS)
2019-12-20 10:06                     ` Andrew Lunn
2019-12-23  7:50                       ` Madalin Bucur (OSS)
2019-12-23  8:26                         ` Russell King - ARM Linux admin
2019-12-23  9:57                           ` Madalin Bucur (OSS)
2019-12-23 10:57                             ` Russell King - ARM Linux admin
2019-12-23 12:07       ` Russell King - ARM Linux admin
2019-12-23 13:46         ` Andrew Lunn
2019-12-23 14:30           ` Russell King - ARM Linux admin
2020-01-03  7:01         ` Madalin Bucur (OSS)
2020-01-03  9:27           ` Russell King - ARM Linux admin
2020-01-03  9:42             ` Russell King - ARM Linux admin
2020-01-03 12:03               ` Madalin Bucur (OSS)
2020-01-03 12:53                 ` Russell King - ARM Linux admin
2020-01-03 13:35                   ` Andrew Lunn
2020-01-03 16:21                     ` Madalin Bucur (OSS) [this message]
2020-01-03 17:17                       ` Andrew Lunn
2020-01-06  9:34                         ` Madalin Bucur (OSS)
2020-01-03 15:57                   ` Madalin Bucur (OSS)
2020-01-03 17:19                     ` Russell King - ARM Linux admin
2020-01-06 10:17                       ` Madalin Bucur (OSS)
2020-01-06 13:57                         ` Andrew Lunn
2020-01-06 15:03                           ` Madalin Bucur (OSS)
2019-12-19 15:21 ` [PATCH 2/6] arm64: dts: ls104xardb: set correct PHY interface mode Madalin Bucur
2019-12-19 16:05   ` Andrew Lunn
2019-12-19 18:09     ` Madalin Bucur (OSS)
2019-12-19 15:21 ` [PATCH 3/6] net: fsl/fman: rename IF_MODE_XGMII to IF_MODE_10G Madalin Bucur
2019-12-19 15:21 ` [PATCH 4/6] net: fsl/fman: add support for PHY_INTERFACE_MODE_XFI Madalin Bucur
2019-12-19 15:21 ` [PATCH 5/6] net: fsl/fman: add support for PHY_INTERFACE_MODE_SFI Madalin Bucur
2019-12-19 17:30   ` Russell King - ARM Linux admin
2019-12-19 18:50     ` Madalin Bucur (OSS)
2019-12-19 15:21 ` [PATCH 6/6] net: phy: aquantia: add support for PHY_INTERFACE_MODE_XFI Madalin Bucur

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=DB8PR04MB6985AD897CC0159E324DF992EC230@DB8PR04MB6985.eurprd04.prod.outlook.com \
    --to=madalin.bucur@oss.nxp.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=devicetree@vger.kernel.org \
    --cc=f.fainelli@gmail.com \
    --cc=hkallweit1@gmail.com \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=shawnguo@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.