e1000e: don't modify SYSTIM registers during SIOCSHWTSTAMP ioctl
Subsystems (2)
PATCH v3 1/1 e1000e: don't modify SYSTIM registers during SIOCSHWTSTAMP ioctl
The e1000e_config_hwtstamp function was incorrectly resetting the SYSTIM registers every time the ioctl was being run. If you happened to be running ptp4l and lost the PTP connect (removing cable, or blocking the UDP traffic for example), then ptp4l will eventually perform a restart which involves re-requesting timestamp settings. In e1000e this has the unfortunate and incorrect result of resetting SYSTIME to the kernel time. Since kernel time is usually in UTC, and PTP time is in TAI, this results in the leap second being re-applied.
Fix this by extracting the SYSTIME reset out into its own function, e1000e_ptp_reset, which we call during reset to restore the hardware registers. This function will (a) restart the timecounter based on the new system time, (b) restore the previous PPB setting, and (c) restore the previous hwtstamp settings.
In order to perform (b), I had to modify the adjfreq ptp function pointer to store the old delta each time it is called. This also has the side effect of restoring the correct base timinca register correctly. The driver does not need to explicitly zero the ptp_delta variable since the entire adapter structure comes zero-initialized.
---
3rd time's a charm? This time I verified it should compile and run now, without crashes, and without compilation errors.
Notes:
This patch conflicts with Brian's "e1000e fix ptp time reset on newtork interruption", and that patch MUST be removed from the queue before applying this one.
- Changes since v1
* move e1000e_init_ptp prior to reset so that PTP clock is created first
* handle NULL ptp_clock_info gracefully.
- Changes since v2
* fix stupid compilation error
* fix stupid null pointer check (who WROTE THIS CODE?!?!??!! ;)
drivers/net/ethernet/intel/e1000e/e1000.h | 1 + drivers/net/ethernet/intel/e1000e/netdev.c | 65 ++++++++++++++++++++++-------- drivers/net/ethernet/intel/e1000e/ptp.c | 2 + 3 files changed, 52 insertions(+), 16 deletions(-)
drivers/net/ethernet/intel/e1000e/e1000.h +1 -0
@@ -347,6 +347,7 @@ struct e1000_adapter {struct ptp_clock *ptp_clock;struct ptp_clock_info ptp_clock_info;struct pm_qos_request pm_qos_req; +s32 ptp_delta;u16 eee_advert; };
drivers/net/ethernet/intel/e1000e/netdev.c +49 -16
101 lines not on this page · raw message
drivers/net/ethernet/intel/e1000e/ptp.c +2 -0
@@ -79,6 +79,8 @@ static int e1000e_phc_adjfreq(struct ptp_clock_info *ptp, s32 delta)ew32 (TIMINCA , timinca); + adapter->ptp_delta = delta; +spin_unlock_irqrestore (&adapter->systim_lock, flags);return 0 ;
Signature · 1 line
2.8.1.369.geae769a
PATCH v3 1/1 e1000e: don't modify SYSTIM registers during SIOCSHWTSTAMP ioctl
Quoted 37 lines · Jacob Keller
The
e1000e_config_hwtstampfunction was incorrectly resetting the SYSTIM registers every time the ioctl was being run. If you happened to be running ptp4l and lost the PTP connect (removing cable, or blocking the UDP traffic for example), then ptp4l will eventually perform a restart which involves re-requesting timestamp settings. In e1000e this has the unfortunate and incorrect result of resetting SYSTIME to the kernel time. Since kernel time is usually in UTC, and PTP time is in TAI, this results in the leap second being re-applied.Fix this by extracting the SYSTIME reset out into its own function,
e1000e_ptp_reset, which we call during reset to restore the hardware registers. This function will (a) restart the timecounter based on the new system time, (b) restore the previous PPB setting, and (c) restore the previous hwtstamp settings.In order to perform (b), I had to modify the adjfreq ptp function pointer to store the old delta each time it is called. This also has the side effect of restoring the correct base timinca register correctly. The driver does not need to explicitly zero the
ptp_deltavariable since the entire adapter structure comes zero-initialized.Reported-by Brian Walsh <[email protected]>Signed-off-by Jacob Keller <[email protected]>---
3rd time's a charm? This time I verified it should compile and run now, without crashes, and without compilation errors.
Notes:
This patch conflicts with Brian's "e1000e fix ptp time reset on newtork interruption", and that patch MUST be removed from the queue before applying this one.- Changes since v1
* movee1000e_init_ptpprior to reset so that PTP clock is created first
* handle NULLptp_clock_infogracefully.
Quoted 9 lines
- Changes since v2
* fix stupid compilation error
* fix stupid null pointer check (who WROTE THIS CODE?!?!??!! ;)drivers/net/ethernet/intel/e1000e/e1000.h | 1 + drivers/net/ethernet/intel/e1000e/netdev.c | 65 ++++++++++++++++++++++-------- drivers/net/ethernet/intel/e1000e/ptp.c | 2 + 3 files changed, 52 insertions(+), 16 deletions(-)
Fixes the leapsecond time jump I was trying to fix.
Keller
PATCH v3 1/1 e1000e: don't modify SYSTIM registers during SIOCSHWTSTAMP ioctl
Quoted 64 lines · Brian Walsh
Quoted 57 lines · Jacob Keller
The
e1000e_config_hwtstampfunction was incorrectly resetting the SYSTIM
registers every time the ioctl was being run. If you happened to be running ptp4l and lost the PTP connect (removing cable, or blocking the
UDP traffic for example), then ptp4l will eventually perform a restart
which involves re-requesting timestamp settings. In e1000e this has the
unfortunate and incorrect result of resetting SYSTIME to the kernel time. Since kernel time is usually in UTC, and PTP time is in TAI, this
results in the leap second being re-applied.Fix this by extracting the SYSTIME reset out into its own function,
e1000e_ptp_reset, which we call during reset to restore the hardware
registers. This function will (a) restart the timecounter based on the
new system time, (b) restore the previous PPB setting, and (c) restore
the previous hwtstamp settings.In order to perform (b), I had to modify the adjfreq ptp function pointer to store the old delta each time it is called. This also has the
side effect of restoring the correct base timinca register correctly.
The driver does not need to explicitly zero theptp_deltavariable since
the entire adapter structure comes zero-initialized.Reported-by Brian Walsh <[email protected]>Signed-off-by Jacob Keller <[email protected]>---
3rd time's a charm? This time I verified it should compile and run now,
without crashes, and without compilation errors.Notes:
????This patch conflicts with Brian's "e1000e fix ptp time reset on newtork
????interruption", and that patch MUST be removed from the queue before applying
????this one.
????
????- Changes since v1
????* movee1000e_init_ptpprior to reset so that PTP clock is created first
????* handle NULLptp_clock_infogracefully.
????
????- Changes since v2
????* fix stupid compilation error
????* fix stupid null pointer check (who WROTE THIS CODE?!?!??!! ;)Quoted 6 lines
?drivers/net/ethernet/intel/e1000e/e1000.h??|??1 + ?drivers/net/ethernet/intel/e1000e/netdev.c | 65
++++++++++++++++++++++--------
?drivers/net/ethernet/intel/e1000e/ptp.c????|??2 + ?3 files changed, 52 insertions(+), 16 deletions(-)
Quoted 3 lines
Fixes the leapsecond time jump I was trying to fix.
Tested-by Brian Walsh <[email protected]>
Thanks for testing this Brian, and sorry for the version thrash. I'm glad it resolves the issue for you.
Regards,
Jake
Keller
PATCH v3 1/1 e1000e: don't modify SYSTIM registers during SIOCSHWTSTAMP ioctl
In reply to Jacob KellerQuoted 30 lines · Jacob Keller
The
e1000e_config_hwtstampfunction was incorrectly resetting the SYSTIM
registers every time the ioctl was being run. If you happened to be running ptp4l and lost the PTP connect (removing cable, or blocking the
UDP traffic for example), then ptp4l will eventually perform a restart
which involves re-requesting timestamp settings. In e1000e this has the
unfortunate and incorrect result of resetting SYSTIME to the kernel time. Since kernel time is usually in UTC, and PTP time is in TAI, this
results in the leap second being re-applied.Fix this by extracting the SYSTIME reset out into its own function,
e1000e_ptp_reset, which we call during reset to restore the hardware registers. This function will (a) restart the timecounter based on the
new system time, (b) restore the previous PPB setting, and (c) restore
the previous hwtstamp settings.In order to perform (b), I had to modify the adjfreq ptp function pointer to store the old delta each time it is called. This also has the
side effect of restoring the correct base timinca register correctly. The driver does not need to explicitly zero theptp_deltavariable since
the entire adapter structure comes zero-initialized.
Quoted 3 lines
Reported-by Brian Walsh <[email protected]>Signed-off-by Jacob Keller <[email protected]>
Unfortunately, Todd Fujinaka found an issue with this patch on e1000e devices which do not support timestamping. I forgot to add a check to the HW_TIMESTAMP flag. I cleaned up a few other minor things as well in v4. Sorry (again) for the thrash, we'll get this worked out.
Jeff, can you drop this patch from the queue a v4 is incoming.
Regards,
Jake