Re: [PATCH] wifi: brcmfmac: drain bus_reset work on device removal

On Thu, Jul 09, 2026 at 05:23:37PM -0700, Eddie Phillips wrote:

Is this safe in a softIRQ context?
mutex_lock() sleeps until it can get the lock.

Thanks for taking a look. I agree this is not the right interface shape.

The current call sites I traced reach brcmf_fw_crashed() from the PCIe
threaded IRQ path or from SDIO workqueue context, but brcmf_fw_crashed()
is a core helper and the reset scheduling path should not grow a hidden
sleepable-context requirement. I will respin this part so the arming gate
does not use a mutex.

How about if brcmf_pcie_remove() calls brcmf_bus_cancel_reset_work(),
takes the lock and calls cancel_work_sync(), sleeps. If debugfs
path is already running, it can invoke the worker thread. Is there
potential that both try to reset?

Yes, that is a real issue with this version. The lock only serializes
scheduling against the cancel point. If the reset work has already started,
cancel_work_sync() waits for it, but the worker may already be executing the
bus reset teardown path; remove can then continue and run its own teardown
afterwards.

So the patch needs a stronger state/ownership model than just
schedule-vs-cancel serialization. I will rework it so reset and remove cannot
both own the same teardown sequence, and will send a v2 after auditing the
PCIe/SDIO/USB paths again.

Thanks,
Fan