Re: [PATCH 02/11] staging: r8188eu: Remove wrapper around spin_lock_bh
On Fri, Dec 20, 2013 at 10:36:09AM -0600, Larry Finger wrote: On 12/20/2013 01:14 AM, Dan Carpenter wrote: On Thu, Dec 19, 2013 at 10:38:34PM -0600, Larry Finger wrote: Some comment lines that mentioned spin_lock_bh() are also removed. Signed-off-by: Larry Finger larry.fin...@lwfinger.net @@ -1509,10 +1509,6 @@ _func_enter_; rtw_p2p_set_state(pwdinfo, P2P_STATE_FIND_PHASE_SEARCH); - _enter_critical_bh(pmlmepriv-lock, irqL); - _exit_critical_bh(pmlmepriv-lock, irqL); - - _func_exit_; } This is a functionality change that slipped in. This is like spin_unlock_wait() where you want to wait until the lock is released. In this code it's probably unintended? But don't put these things into a patch without mentioning it. Dan, Yes, I should have mentioned that I was removing a pointless lock/unlock sequence. Upon further checking, I see that the original driver I received from Realtek did have a reason for locking there, but a line was dropped from the code. This section should contain the following: diff --git a/drivers/staging/rtl8188eu/core/rtw_p2p.c b/drivers/staging/rtl8188eu/core/rtw_p2p.c index 402fd21..b376d09 100644 --- a/drivers/staging/rtl8188eu/core/rtw_p2p.c +++ b/drivers/staging/rtl8188eu/core/rtw_p2p.c @@ -1505,6 +1505,9 @@ _func_enter_; rtw_p2p_set_state(pwdinfo, P2P_STATE_FIND_PHASE_SEARCH); +spin_lock_bh(pmlmepriv-lock); +rtw_sitesurvey_cmd(struct adapter padapter, ssid, 1, NULL, 0); +spin_unlock_bh(pmlmepriv-lock); _func_exit_; } Thanks for reading the patches. @Greg: Is it OK if I leave the previous patch alone and submit the above as a separate change? Yes, just send a follow-on change would be fine, I'll take this as-is. thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 02/11] staging: r8188eu: Remove wrapper around spin_lock_bh
On 12/20/2013 01:14 AM, Dan Carpenter wrote: On Thu, Dec 19, 2013 at 10:38:34PM -0600, Larry Finger wrote: Some comment lines that mentioned spin_lock_bh() are also removed. Signed-off-by: Larry Finger larry.fin...@lwfinger.net @@ -1509,10 +1509,6 @@ _func_enter_; rtw_p2p_set_state(pwdinfo, P2P_STATE_FIND_PHASE_SEARCH); - _enter_critical_bh(pmlmepriv-lock, irqL); - _exit_critical_bh(pmlmepriv-lock, irqL); - - _func_exit_; } This is a functionality change that slipped in. This is like spin_unlock_wait() where you want to wait until the lock is released. In this code it's probably unintended? But don't put these things into a patch without mentioning it. Dan, Yes, I should have mentioned that I was removing a pointless lock/unlock sequence. Upon further checking, I see that the original driver I received from Realtek did have a reason for locking there, but a line was dropped from the code. This section should contain the following: diff --git a/drivers/staging/rtl8188eu/core/rtw_p2p.c b/drivers/staging/rtl8188eu/core/rtw_p2p.c index 402fd21..b376d09 100644 --- a/drivers/staging/rtl8188eu/core/rtw_p2p.c +++ b/drivers/staging/rtl8188eu/core/rtw_p2p.c @@ -1505,6 +1505,9 @@ _func_enter_; rtw_p2p_set_state(pwdinfo, P2P_STATE_FIND_PHASE_SEARCH); +spin_lock_bh(pmlmepriv-lock); +rtw_sitesurvey_cmd(struct adapter padapter, ssid, 1, NULL, 0); +spin_unlock_bh(pmlmepriv-lock); _func_exit_; } Thanks for reading the patches. @Greg: Is it OK if I leave the previous patch alone and submit the above as a separate change? Larry ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH 02/11] staging: r8188eu: Remove wrapper around spin_lock_bh
On Thu, Dec 19, 2013 at 10:38:34PM -0600, Larry Finger wrote: Some comment lines that mentioned spin_lock_bh() are also removed. Signed-off-by: Larry Finger larry.fin...@lwfinger.net @@ -1509,10 +1509,6 @@ _func_enter_; rtw_p2p_set_state(pwdinfo, P2P_STATE_FIND_PHASE_SEARCH); - _enter_critical_bh(pmlmepriv-lock, irqL); - _exit_critical_bh(pmlmepriv-lock, irqL); - - _func_exit_; } This is a functionality change that slipped in. This is like spin_unlock_wait() where you want to wait until the lock is released. In this code it's probably unintended? But don't put these things into a patch without mentioning it. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
