From: Ong, Boon Leong <redacted>
Date: Jan/24/2020, 08:56:28 (UTC+00:00)
quoted
Why not use rtnl_is_locked() instead of the boolean ?
We know that stmmac_open() is called with rtnl_mutex locked by caller.
And, stmmac_resume() is called without rtnl_mutex is locked by caller.
If we replace the boolean with rtnl_is_locked(), then we will have the
following logics in stmmac_hw_setup():-
if (!rtnl_is_locked) ---- (A)
rtnl_lock();
netif_set_real_num_rx_queues();
netif_set_real_num_tx_queues();
if (!rtnl_is_locked) ---- (B)
rtnl_unlock();
For stmmac_open(), (A) is false but (B) is true.
So, the stmmac_open() exits with rtnl_mutex is released.
Here, the above logic does not perserve the original rtnl_mutex
is locked when stmmac_open() is called.
For stmmac_resume(), (A) is true, and (B) is also true.
So, the stmmac_resume() exits with rtnl_mutex is released.
Here, the above logic works well as the original rtnl_mutex is released
when stmmac_resume() is called.
So, as far as I can see, the proposed boolean approach works fine for both
stmmac_open() and stmmac_resume().
Do you agree?
Can't you just wrap all the HW related logic in stmmac_resume() and
stmmac_suspend() with the rtnl lock ? Seems like the right thing to do and
you won't need the boolean.
---
Thanks,
Jose Miguel Abreu