Hi Simon, Serdes equalizer parameters are raw hex values and it is not useful to end user. It is only useful to engineer who is familiar with serdes/ physical lane. So we decided not to implement it as new ethtool option.
Thanks Anil Kumar Samal -----Original Message----- From: Simon Horman <[email protected]> Sent: Monday, June 17, 2024 7:53 AM To: Jakub Kicinski <[email protected]> Cc: Samal, Anil <[email protected]>; [email protected]; [email protected]; Pepiak, Leszek <[email protected]>; Kitszel, Przemyslaw <[email protected]>; Czapnik, Lukasz <[email protected]>; Nguyen, Anthony L <[email protected]>; Brandeburg, Jesse <[email protected]> Subject: Re: [PATCH iwl-next v3 3/3] ice: Implement driver functionality to dump serdes equalizer values On Fri, Jun 14, 2024 at 05:55:59PM -0700, Jakub Kicinski wrote: > On Fri, 14 Jun 2024 05:58:17 -0700 Anil Samal wrote: > > To debug link issues in the field, serdes Tx/Rx equalizer values > > help to determine the health of serdes lane. > > > > Extend 'ethtool -d' option to dump serdes Tx/Rx equalizer. > > The following list of equalizer param is supported > > a. rx_equalization_pre2 > > b. rx_equalization_pre1 > > c. rx_equalization_post1 > > d. rx_equalization_bflf > > e. rx_equalization_bfhf > > f. rx_equalization_drate > > g. tx_equalization_pre1 > > h. tx_equalization_pre3 > > i. tx_equalization_atten > > j. tx_equalization_post1 > > k. tx_equalization_pre2 > > I'd be tempted to create a dedicated way to dump vendor specific > signal quality indicators (both for Ethernet and PCIe). Feels little > cleaner than appending to a flat mixed-purpose dump. But either way is > fine by me, TBH. Much better than vendor tools poking into the BAR... +1 In particular, I agree that either way ethtool -d is better than than vendor tools poking into the BAR. Because the Kernel can mediate access to the hardware and see the data.
