Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <4953fc69a26bee930bccdeb612f1ce740a4294df.1578921062.git.Jose.Abreu@synopsys.com>
 <20200113133845.GD11788@lunn.ch> <BN8PR12MB32666F34D45D7881BDD4CAB3D3350@BN8PR12MB3266.namprd12.prod.outlook.com>
 <20200113141817.GN25745@shell.armlinux.org.uk>
In-Reply-To: <20200113141817.GN25745@shell.armlinux.org.uk>
From:   Vladimir Oltean <olteanv@gmail.com>
Date:   Mon, 13 Jan 2020 16:50:18 +0200
Message-ID: <CA+h21hqYeq_D5hLi8yssNko6ucNSVCFMQxqkvGcGxL86niu7pA@mail.gmail.com>
Subject: Re: [RFC net-next] net: phy: Add basic support for Synopsys XPCS
 using a PHY driver
To:     Russell King - ARM Linux admin <linux@armlinux.org.uk>
Cc:     Jose Abreu <Jose.Abreu@synopsys.com>, Andrew Lunn <andrew@lunn.ch>,
        "netdev@vger.kernel.org" <netdev@vger.kernel.org>,
        Joao Pinto <Joao.Pinto@synopsys.com>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Russell,

On Mon, 13 Jan 2020 at 16:19, Russell King - ARM Linux admin
<linux@armlinux.org.uk> wrote:
>
> I've recently suggested a patch to phylink to add a generic helper to
> read the state from a generic 802.3 clause 37 PCS, but I guess that
> won't be sufficient for an XPCS.  However, it should give some clues
> if you're intending to use phylink.
>

I don't think the PCS implementations out there are sufficiently
similar to be driven by a unified driver, and at least nothing
mandates that for now. Although the configuration interface is MDIO
with registers quasi-compliant to C22 or C45, many times bits in
BMCR/BMSR are not implemented, you can't typically achieve full
functionality [ sometimes not at all ] without writing to some
vendor-specific registers, there might be errata workarounds that need
to be implemented through PCS writes, often the PCS driver needs to be
correlated with a MMIO region corresponding to that SerDes lane for
stuff such as eye parameters.
The code duplication isn't even all that bad.

_But_ I am not sure how PHYLINK comes into play here. A PHY driver
should work with the plain PHY library too. Dealing with clause 73
autoneg indicates to me that this is more than just a MAC PCS,
therefore it shouldn't be tied in with PHYLINK.

Thanks,
-Vladimir