From: Jacob Keller Date: Fri, 2 Dec 2016 20:32:58 +0000 (-0800) Subject: i40e: don't warn every time we clear an Rx timestamp register X-Git-Url: https://git.stricted.de/?a=commitdiff_plain;h=e6e3fc2bd3ee03117e1ce388c897fc3b2da97d65;p=GitHub%2Fmoto-9609%2Fandroid_kernel_motorola_exynos9610.git i40e: don't warn every time we clear an Rx timestamp register The intent of this message was to indicate to a user that we might have missed a timestamp event for a valid packet. The original method of detecting the missed events relied on waiting until all 4 registers were filled. A recent commit d55458c0cd7a5 ("i40e: replace PTP Rx timestamp hang logic") replaced this logic with much better detection scheme that could detect a stalled Rx timestamp register even when other registers were still functional. The new logic means that a message will be displayed almost as soon as a timestamp for a dropped frame occurs. This new logic highlights that the hardware will attempt timestamp for frames which it later decides to drop. The most prominent example is when a multicast PTP frame is received on a multicast address that we are not subscribed to. Because the hardware initiates the Rx timestamp as soon as possible, it will latch an RXTIME register, but then drop the packet. This results in users being confused by the message as they are not expecting to see dropped timestamp messages unless their application also indicates that timestamps were missing. Resolve this by reducing the severity and frequency of the displayed message. We now only print the message if 3 or 4 of the RXTIME registers are stalled and get cleared within the same watchdog event. This ensures that the common case does not constantly display the message. Additionally, since the message is likely not as meaningful to most users, reduce the message to a dev_dbg instead of a dev_warn. Users can still get a count of the number of timestamps dropped by reading the ethtool statistics value, if necessary. Change-ID: I35494442226a444c418dfb4f91a3070d06c8435c Signed-off-by: Jacob Keller Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher --- diff --git a/drivers/net/ethernet/intel/i40e/i40e_ptp.c b/drivers/net/ethernet/intel/i40e/i40e_ptp.c index 9e49ffafce28..2caee35528fa 100644 --- a/drivers/net/ethernet/intel/i40e/i40e_ptp.c +++ b/drivers/net/ethernet/intel/i40e/i40e_ptp.c @@ -280,7 +280,7 @@ void i40e_ptp_rx_hang(struct i40e_vsi *vsi) { struct i40e_pf *pf = vsi->back; struct i40e_hw *hw = &pf->hw; - int i; + unsigned int i, cleared = 0; /* Since we cannot turn off the Rx timestamp logic if the device is * configured for Tx timestamping, we check if Rx timestamping is @@ -306,14 +306,25 @@ void i40e_ptp_rx_hang(struct i40e_vsi *vsi) time_is_before_jiffies(pf->latch_events[i] + HZ)) { rd32(hw, I40E_PRTTSYN_RXTIME_H(i)); pf->latch_event_flags &= ~BIT(i); - pf->rx_hwtstamp_cleared++; - dev_warn(&pf->pdev->dev, - "Clearing a missed Rx timestamp event for RXTIME[%d]\n", - i); + cleared++; } } spin_unlock_bh(&pf->ptp_rx_lock); + + /* Log a warning if more than 2 timestamps got dropped in the same + * check. We don't want to warn about all drops because it can occur + * in normal scenarios such as PTP frames on multicast addresses we + * aren't listening to. However, administrator should know if this is + * the reason packets aren't receiving timestamps. + */ + if (cleared > 2) + dev_dbg(&pf->pdev->dev, + "Dropped %d missed RXTIME timestamp events\n", + cleared); + + /* Finally, update the rx_hwtstamp_cleared counter */ + pf->rx_hwtstamp_cleared += cleared; } /**