Thanks for the review. On the service-gating concern: I will keep GC_IN_SERVICE set on the failed-resume rescan exit, so the existing gate is preserved until the old device is removed. A freshly probed device starts with clear flags, so the bit naturally resets across the rescan, and no second service or tx-timeout work can be admitted while mana_serv_rescan() tears the device down.
On the lock scope: agreed that holding the driver-core device lock across mana_gd_suspend() + the msleep() + mana_gd_resume() is far too broad. Narrowing it is not as simple as swapping in a driver-private mutex, though. A mutex embedded in struct gdma_context cannot itself protect the drvdata lookup, which happens before such a lock can be taken, and mana_gd_remove() cannot take-then-free-then-release a lock that lives inside the object being freed. What this race actually needs is a drain boundary: close admission of new reset work, wait for the already-admitted work to finish, and only then clear drvdata and tear the context down. I am aligning this with Long Li's in-flight series "[PATCH net v4 0/7] net: mana: HW channel reliability and hardening fixes", which is establishing the HWC teardown lifecycle model (the setup_active state and explicit destroy ordering), so that the reset/remove rework follows the same HWC lifecycle and teardown ordering, rather than introducing an independent synchronization scheme that could conflict with that work. I will send a reworked version once that direction is settled.
