Re: [PATCH net-next v2 4/6] net: wangxun: extract the close_suspend sequence

[Jakub Kicinski <kuba@kernel.org>]

This is an AI-generated review of your patch. The human sending this
email has considered the AI review valid, or at least plausible.
---
net: wangxun: extract the close_suspend sequence

Refactor the .ndo_close implementation by extracting the necessary
hardware shutdown sequence into a dedicated close_suspend function.
This is for later implementation of PCIe error callback function in
libwx.

> diff --git a/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c b/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c
> index ec14dd47cd428..2bd00eade11d2 100644
> --- a/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c
> +++ b/drivers/net/ethernet/wangxun/ngbe/ngbe_main.c
[ ... ]
> @@ -547,7 +555,7 @@ static void ngbe_dev_shutdown(struct pci_dev *pdev, bool *enable_wake)
>  	netif_device_detach(netdev);
>  
>  	if (netif_running(netdev))
> -		ngbe_close(netdev);
> +		ngbe_close_suspend(wx);

Is there a chance this change to ngbe_close_suspend could cause issues
with the PTP clock state during suspend and resume?

Previously, calling ngbe_close would invoke wx_ptp_stop, which unregisters
the PTP clock and stops its background worker. The new ngbe_close_suspend
only calls wx_ptp_suspend.

This leaves the PTP clock registered and its worker thread active since
wx_ptp_do_aux_work will continue to reschedule itself.

On system resume, if ngbe_resume calls ngbe_open, which then calls
wx_ptp_init, wx_ptp_init will unconditionally call
seqlock_init(&wx->hw_tc_lock).

Will this re-initialize an active lock, potentially leading to lockdep
splats or silent lock corruption if the worker thread or a userspace
process accesses the PTP chardev concurrently?

>  	wx_clear_interrupt_scheme(wx);
>  	rtnl_unlock();
>