[Intel-wired-lan] [PATCH intel-next v1] ice: be consistent around PTP de-registration

[Tony Nguyen]

On 4/7/2025 4:20 PM, Jesse Brandeburg wrote:

iwl-next, not intel-next :)

> From: Jesse Brandeburg <jbrandeburg at 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 <jbrandeburg at 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);