On 4/7/2025 4:20 PM, Jesse Brandeburg wrote:
iwl-next, not intel-next :)
From: Jesse Brandeburg <jbrandeb...@cloudflare.com>
The driver was being inconsistent when de-registering its PTP clock. Make
sure to NULL out the pointer once it is freed in all cases. The driver was
mostly already doing so, but a couple spots were missed.
Signed-off-by: Jesse Brandeburg <jbrandeb...@cloudflare.com>
---
NOTE: we saw some odd behavior on one or two machines where the ports
completed init, PTP completed init, then port 0 was "hot removed" via
sysfs, and later panics on ptp->index being 1 while being called by
ethtool. This caused me to look over this area and see this inconsistency.
I wasn't able to confirm any for-sure bug.
---
drivers/net/ethernet/intel/ice/ice_main.c | 5 ++++-
drivers/net/ethernet/intel/ice/ice_ptp.c | 4 ++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_main.c
b/drivers/net/ethernet/intel/ice/ice_main.c
index 049edeb60104..8c1b496e84ef 100644
--- a/drivers/net/ethernet/intel/ice/ice_main.c
+++ b/drivers/net/ethernet/intel/ice/ice_main.c
@@ -3968,8 +3968,11 @@ static void ice_deinit_pf(struct ice_pf *pf)
pf->avail_rxqs = NULL;
}
- if (pf->ptp.clock)
+ if (pf->ptp.clock) {
ptp_clock_unregister(pf->ptp.clock);
+ pf->ptp.clock = NULL;
+ }
+ pf->ptp.state = ICE_PTP_UNINIT;
Hi Jesse,
It looks like we get a proper removal/unregister in ice_ptp_release()
which is called from ice_deinit_features(). From what I'm seeing, I
don't think the unregister should be done here at all.
Thanks,
Tony
xa_destroy(&pf->dyn_ports);
xa_destroy(&pf->sf_nums);
