mbox series

[iwl-next,v3,0/3] ice:Support to dump PHY config, FEC

Message ID 20240524135255.3607422-1-anil.samal@intel.com (mailing list archive)
Headers show
Series ice:Support to dump PHY config, FEC | expand

Message

Samal, Anil May 24, 2024, 1:51 p.m. UTC
Implementation to dump PHY configuration and FEC statistics to
facilitate link level debugging of customer issues.  Implementation has
two parts 
  
a.     Serdes equalization
        # ethtool  -d eth0 
        Output: 
        Offset          Values
        ------          ------
        0x0000:         00 00 00 00 03 00 00 00 05 00 00 00 01 08 00 40
        0x0010:         01 00 00 40 00 00 39 3c 01 00 00 00 00 00 00 00
        0x0020:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        ……
        …..
        0x01f0:         01 00 00 00 ef be ad de 8f 00 00 00 00 00 00 00
        0x0200:         00 00 00 00 ef be ad de 00 00 00 00 00 00 00 00
        0x0210:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x0220:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x0230:         00 00 00 00 00 00 00 00 00 00 00 00 fa ff 00 00
        0x0240:         06 00 00 00 03 00 00 00 00 00 00 00 00 00 00 00
        0x0250:         0f b0 0f b0 00 00 00 00 00 00 00 00 00 00 00 00
        0x0260:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x0270:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x0280:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x0290:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x02a0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x02b0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x02c0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x02d0:         00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
        0x02e0:         00 00 00 00 00 00 00 00 00 00 00 00
Current implementation appends 176 bytes i.e. 44 bytes * 4 serdes lane.
For port with 2 serdes lane, first 88 bytes are valid values and
remaining 88 bytes are filled with zero. Similarly for port with 1
serdes lane, first 44 bytes are valid and remaining 132 bytes are marked
zero. 

Each set of serdes equalizer parameter (i.e. set of 44 bytes) follows
below order 
    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
Where each individual equalizer parameter is of 4 bytes. As ethtool
prints values as individual bytes, for little endian machine these
values will be in reverse byte order. 

b.	FEC block counts
        # ethtool  -I --show-fec eth0
        Output:
         FEC parameters for eth0:
        Supported/Configured FEC encodings: Auto RS BaseR
        Active FEC encoding: RS
        Statistics:
        corrected_blocks: 0
         uncorrectable_blocks: 0

This series do following:
Patch 1 – Implementation to support user provided flag for side band
queue command. 
Patch 2 – Currently driver does not have a way to derive serdes lane
number, pcs quad , pcs port from port number.So we introduced a
mechanism to derive above info. 
          Ethtool interface extension to include FEC statistics counter.
Patch 3 – Ethtool interface extension to include serdes equalizer
output.

v1 -> v2, 
   Squashed 4 commit to 3 commit. 
   Removed extra null check of arguments.
   Removed initialization of local variable that are not required.

v2 -> v3
   updated the argument for sideband queue function from "flag" to
"flags"

 .../net/ethernet/intel/ice/ice_adminq_cmd.h   |  51 ++
 drivers/net/ethernet/intel/ice/ice_common.c   |  99 +++-
 drivers/net/ethernet/intel/ice/ice_common.h   |  28 +-
 drivers/net/ethernet/intel/ice/ice_ethtool.c  | 449 +++++++++++++++++-
 drivers/net/ethernet/intel/ice/ice_ethtool.h  |  29 ++
 .../net/ethernet/intel/ice/ice_hw_autogen.h   |   2 +
 drivers/net/ethernet/intel/ice/ice_ptp_hw.c   |  16 +-
 drivers/net/ethernet/intel/ice/ice_type.h     |   8 +
 8 files changed, 669 insertions(+), 13 deletions(-)

Comments

Jacob Keller May 24, 2024, 9:11 p.m. UTC | #1
On 5/24/2024 6:51 AM, Anil Samal wrote:
> Implementation to dump PHY configuration and FEC statistics to
> facilitate link level debugging of customer issues.  Implementation has
> two parts 
>   

What commit is this based off of? I believe we have slightly conflicting
work already queued in IWL next-queue, and the NIPA automation is unable
to apply this series for testing:

> [IWL-NIPA] Patch: https://patchwork.ozlabs.org/patch/1939088
> Pass: 1 Warn: 0 Fail: 1
> 
> Patch: https://patchwork.ozlabs.org/patch/1939088
> results path: results/408098/1939088
> 
> Test: apply
> Fail - Patch does not apply to next-queue
> 
> Test: tree_selection
> Okay - Clearly marked for next-queue

Normally, basing directly on net-next is fine. Unfortunately, I am
having trouble properly resolving the conflicts with the work on the
queue already.

If you could rebase this on top of dev-queue [1] that would be appreciated.

[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git/commit/?h=dev-queue
Samal, Anil June 8, 2024, 6:14 p.m. UTC | #2
Hi Jacob, 
Can you please help me with the branch name that I should rebase? 
Last time I rebased to "dev-queue" branch of "git clone git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git". 

Let me know, if I should use a different branch for rebasing. 

Thanks
Anil 

-----Original Message-----
From: Keller, Jacob E <jacob.e.keller@intel.com> 
Sent: Friday, May 24, 2024 2:11 PM
To: Samal, Anil <anil.samal@intel.com>; intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org; Pepiak, Leszek <leszek.pepiak@intel.com>; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>; Czapnik, Lukasz <lukasz.czapnik@intel.com>; Nguyen, Anthony L <anthony.l.nguyen@intel.com>
Subject: Re: [PATCH iwl-next v3 0/3] ice:Support to dump PHY config, FEC



On 5/24/2024 6:51 AM, Anil Samal wrote:
> Implementation to dump PHY configuration and FEC statistics to 
> facilitate link level debugging of customer issues.  Implementation 
> has two parts
>   

What commit is this based off of? I believe we have slightly conflicting work already queued in IWL next-queue, and the NIPA automation is unable to apply this series for testing:

> [IWL-NIPA] Patch: https://patchwork.ozlabs.org/patch/1939088
> Pass: 1 Warn: 0 Fail: 1
> 
> Patch: https://patchwork.ozlabs.org/patch/1939088
> results path: results/408098/1939088
> 
> Test: apply
> Fail - Patch does not apply to next-queue
> 
> Test: tree_selection
> Okay - Clearly marked for next-queue

Normally, basing directly on net-next is fine. Unfortunately, I am having trouble properly resolving the conflicts with the work on the queue already.

If you could rebase this on top of dev-queue [1] that would be appreciated.

[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git/commit/?h=dev-queue
Jacob Keller June 10, 2024, 6:57 p.m. UTC | #3
On 6/8/2024 11:14 AM, Samal, Anil wrote:
> Hi Jacob, 
> Can you please help me with the branch name that I should rebase? 
> Last time I rebased to "dev-queue" branch of "git clone git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git". 
> 
> Let me know, if I should use a different branch for rebasing. 
> 
> Thanks
> Anil 
> 

That is typically the correct branch. I suspect what happened is that
other work got applied to this branch between when you fetched and when
you sent the work. (Or possibly between when you sent and when I tried
to apply).