[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190725133559.GI1330@shell.armlinux.org.uk>
Date: Thu, 25 Jul 2019 14:36:00 +0100
From: Russell King - ARM Linux admin <linux@...linux.org.uk>
To: Parshuram Raju Thombare <pthombar@...ence.com>
Cc: Andrew Lunn <andrew@...n.ch>,
"nicolas.ferre@...rochip.com" <nicolas.ferre@...rochip.com>,
"davem@...emloft.net" <davem@...emloft.net>,
"f.fainelli@...il.com" <f.fainelli@...il.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"hkallweit1@...il.com" <hkallweit1@...il.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Rafal Ciepiela <rafalc@...ence.com>,
Piotr Sroka <piotrs@...ence.com>,
Anil Joy Varughese <aniljoy@...ence.com>,
Arthur Marris <arthurm@...ence.com>,
Steven Ho <stevenh@...ence.com>,
Milind Parab <mparab@...ence.com>
Subject: Re: [PATCH v6 0/5] net: macb: cover letter
On Thu, Jul 25, 2019 at 01:27:58PM +0000, Parshuram Raju Thombare wrote:
> Hi Andrew,
>
> >One thing which was never clear is how you are testing the features you are
> >adding. Please could you describe your test setup and how each new feature
> >is tested using that hardware. I'm particularly interested in what C45 device
> >are you using? But i expect Russell would like to know more about SFP
> >modules you are using. Do you have any which require 1000BaseX,
> >2500BaseX, or provide copper 1G?
>
> Sorry for late reply.
> Here is a little more information on our setup used for testing C45 patch with a view to
> try clarify a few points.
> Regarding the MDIO communication channel that our controller supports - We have tested
> MDIO transfers through Clause 22, but none of our local PHY's support Clause 45 so our hardware
> team have created an example Clause 45 slave device for us to add support to the driver.
> Note our hardware has been in silicon for 20 years, with customers using their own software to support
> MDIO (both clause 22 and clause 45 functionality) and so this has been in Cadence's hardware controller
> many times.
> The programming interface is not hugely different between the two clauses and therefore we feel the risk is low.
>
> For other features like SGMII, USXGMII we are using kc705 and vcu118 FPGA boards.
> 10G SFP+ module from Tyco electronics is used for testing 10G USXGMII in fixed AN mode.
SFP and SFP+ modules take SGMII, 1000BASE-X, possibly 2500BASE-X and
10GBASE-R all over a single serdes lane.
USXGMII might be used from the MAC to some sort of PHY which then
converts to 10GBASE-R.
If you have a PHY present, then using phylink and trying to link the
MAC directly with the SFP cage in software is the _wrong approach_.
I've stated this several times.
I'm getting to the point of asking you not to persist with your use
of phylink with your driver - I do not believe that your hardware has
any justification for its use, and I also believe that your use of
phylink is positively hurtful to the long term maintenance of phylink
itself.
In other words, you persisting to (ab)use phylink _hurts_ our ability
to maintain it into the future.
I'm also at the point where I'm giving up reviewing your patches - you
don't seem to take the issues I raise on board at all, so I feel like
I'm completely wasting my time trying to get you to make improvements.
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
Powered by blists - more mailing lists