Hello Eugen,
Thank you for discussing this with me!
In this specific code scenario, the lock acquisition order is strictly fixed (e.g., pc->lock is always acquired before vc->lock). This sequence is linear and won't interleave with other code paths in a conflicting nested pattern (e.g., the pc → vc sequence never coexists with a potential vc → pc sequence). Therefore, a standard spin_lock() is sufficient to safely prevent deadlocks, and explicitly declaring a nesting level via spin_lock_nested() is unnecessary.
Additionally, using spin_lock_nested() would require specifying an extra nesting subclass parameter. This adds unnecessary complexity to the code and could adversely affect maintainability for other developers working on it in the future.
Best regards, Qiu-ji Chen
On 6/6/25 12:14, Qiu-ji Chen wrote:
On 6/6/25 10:17, Qiu-ji Chen wrote:
Fixed a flag reuse bug in the mtk_cqdma_tx_status() function.
If the first spin_lock_irqsave already saved the irq flags and disabled them, would it be meaningful to actually use a simple spin_lock for the second lock ? Or rather spin_lock_nested since there is a second nested lock taken ?
Eugen
Hello Eugen,
Thanks for helpful suggestion. The modification has been submitted in patch v2 as discussed.
Best regards, Qiu-ji Chen
You are welcome, but in fact I suggested two alternatives. Any reason you picked this one instead of the other ?