On Mon, Jan 5, 2026 at 10:03 AM Russell King (Oracle) linux@armlinux.org.uk wrote:
I'd like to restate my question, as it is the crux of the issue: as the PTP clock remains registered during the firmware change, userspace can interact with that device in every way possible.
If the firmware is in the process of being changed, and e.g. bnxt_ptp_enable() were to be called by way of userspace interacting with the PTP clock, we have already established that bnxt_ptp_enable() will talk to the firmware - but what happens if bnxt_ptp_enable() attempts to while the firmware is being changed? Is this safe?
I believe we have code to deal with that. During FW upgrade/downgrade/reset, the BNXT_STATE_IN_FW_RESET flag should be set. The operation that needs to be avoided in this window is reading the clock registers. A quick check of the code shows that we take the ptp_lock and check the flag before we call readl().