On 4/9/2025 2:54 PM, Tony Nguyen wrote:
>
>
> 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
>
+1, I think a v2 should just remove the entire call to
ptp_clock_unregister here. It's the wrong place to do it. It causing
problems is further evidence of this.
>>
>> xa_destroy(&pf->dyn_ports);
>> xa_destroy(&pf->sf_nums);
