| Message ID | 1562769391-31803-1-git-send-email-pthombar@cadence.com |
|---|---|
| Headers | show |
| Series | net: macb: cover letter | expand |
As announced clearly yesterday on this list, the net-next tree is closed. Please resubmit these changes when the tree opens back up again. Thank you.
Hi David, Ok, I will resubmit it. Regards, Parshuram Thombare
On Wed, Jul 10, 2019 at 03:36:31PM +0100, Parshuram Thombare wrote: > Hello ! > > This is 6th version of patch set containing following patches > for Cadence ethernet controller driver. Hi Parshuram 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? Thanks Andrew
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. Regards, Parshuram Thombare
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.
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. O.K. Given Russells reply, i suggest you submit the MDIO Clause 45 patch, and throw all the other patches away. Andrew