diff options
| author | Paolo Abeni <pabeni@redhat.com> | 2023-11-23 17:27:35 +0300 |
|---|---|---|
| committer | Paolo Abeni <pabeni@redhat.com> | 2023-11-23 17:27:35 +0300 |
| commit | e50a8061feac92edd7cb9315a078edd03a96715f (patch) | |
| tree | f3745a786e5810567a8c6a0b05d1280d653be1b3 /drivers/net/ethernet/intel/i40e | |
| parent | d9775fb6d011cb97b4106c40840dc982be99fec3 (diff) | |
| parent | 7758017911a4f2578d54c318e8fe77bcb5899054 (diff) | |
| download | linux-e50a8061feac92edd7cb9315a078edd03a96715f.tar.xz | |
Merge branch 'ice-restore-timestamp-config-after-reset'
Tony Nguyen says:
====================
ice: restore timestamp config after reset
Jake Keller says:
We recently discovered during internal validation that the ice driver has
not been properly restoring Tx timestamp configuration after a device reset,
which resulted in application failures after a device reset.
After some digging, it turned out this problem is two-fold. Since the
introduction of the PTP support the driver has been clobbering the storage
of the current timestamp configuration during reset. Thus after a reset, the
driver will no longer perform Tx or Rx timestamps, and will report
timestamp configuration as disabled if SIOCGHWTSTAMP ioctl is issued.
In addition, the recently merged auxiliary bus support code missed that
PFINT_TSYN_MSK must be reprogrammed on the clock owner for E822 devices.
Failure to restore this register configuration results in the driver no
longer responding to interrupts from other ports. Depending on the traffic
pattern, this can either result in increased latency responding to
timestamps on the non-owner ports, or it can result in the driver never
reporting any timestamps. The configuration of PFINT_TSYN_MSK was only done
during initialization. Due to this, the Tx timestamp issue persists even if
userspace reconfigures timestamping.
This series fixes both issues, as well as removes a redundant Tx ring field
since we can rely on the skb flag as the primary detector for a Tx timestamp
request.
Note that I don't think this series will directly apply to older stable
releases (even v6.6) as we recently refactored a lot of the PTP code to
support auxiliary bus. Patch 2/3 only matters for the post-auxiliary bus
implementation. The principle of patch 1/3 and 3/3 could apply as far back
as the initial PTP support, but I don't think it will apply cleanly as-is.
====================
Link: https://lore.kernel.org/r/20231121211259.3348630-1-anthony.l.nguyen@intel.com
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Diffstat (limited to 'drivers/net/ethernet/intel/i40e')
0 files changed, 0 insertions, 0 deletions