Add omitted mutex_unlock to one of wl12xx_op_start fail paths (when
wl12xx_chip_wakeup fails).
[v2]
Power off the device, because:
\= cite from http://marc.info/?l=linux-kernel&m=124755028209880&w=2
If the chip cannot be booted, why should it remain powered on?
In some rare cases, the chip might fail to initialize, but can
recover if powered off and on again, so turning it off at this
point is the right thing to do. =/
Signed-off-by: Jiri Slaby <[email protected]>
---
drivers/net/wireless/wl12xx/main.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
index 603d611..d30683c 100644
--- a/drivers/net/wireless/wl12xx/main.c
+++ b/drivers/net/wireless/wl12xx/main.c
@@ -336,7 +336,7 @@ static int wl12xx_op_start(struct ieee80211_hw *hw)
ret = wl12xx_chip_wakeup(wl);
if (ret < 0)
- return ret;
+ goto out;
ret = wl->chip.op_boot(wl);
if (ret < 0)
--
1.6.3.2
ext Jiri Slaby wrote:
> Add omitted mutex_unlock to one of wl12xx_op_start fail paths (when
> wl12xx_chip_wakeup fails).
>
> [v2]
> Power off the device, because:
> \= cite from http://marc.info/?l=linux-kernel&m=124755028209880&w=2
> If the chip cannot be booted, why should it remain powered on?
> In some rare cases, the chip might fail to initialize, but can
> recover if powered off and on again, so turning it off at this
> point is the right thing to do. =/
>
> Signed-off-by: Jiri Slaby <[email protected]>
> ---
>
Looks good now. Thanks!
Reviewed-by: Luciano Coelho <[email protected]>
> drivers/net/wireless/wl12xx/main.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/wireless/wl12xx/main.c b/drivers/net/wireless/wl12xx/main.c
> index 603d611..d30683c 100644
> --- a/drivers/net/wireless/wl12xx/main.c
> +++ b/drivers/net/wireless/wl12xx/main.c
> @@ -336,7 +336,7 @@ static int wl12xx_op_start(struct ieee80211_hw *hw)
>
> ret = wl12xx_chip_wakeup(wl);
> if (ret < 0)
> - return ret;
> + goto out;
>
> ret = wl->chip.op_boot(wl);
> if (ret < 0)
>
--
Cheers,
Luca.
Jiri Slaby <[email protected]> writes:
> Add omitted mutex_unlock to one of wl12xx_op_start fail paths (when
> wl12xx_chip_wakeup fails).
Thanks for fixing this.
> [v2]
> Power off the device, because:
> \= cite from http://marc.info/?l=linux-kernel&m=124755028209880&w=2
> If the chip cannot be booted, why should it remain powered on?
> In some rare cases, the chip might fail to initialize, but can
> recover if powered off and on again, so turning it off at this
> point is the right thing to do. =/
Yes, I agree with this.
> Signed-off-by: Jiri Slaby <[email protected]>
> ---
> drivers/net/wireless/wl12xx/main.c | 2 +-
Unfortunately this won't apply to wireless-testing because main.c is
renamed to wl1251_main.c. Can you respin the patch or do you want me to
do it? I'm sending other wl12xx patches anyway and it's easy for me to
rebase this one at the same time.
--
Kalle Valo
On 07/16/2009 11:09 AM, Kalle Valo wrote:
>> Signed-off-by: Jiri Slaby <[email protected]>
>> ---
>> drivers/net/wireless/wl12xx/main.c | 2 +-
>
> Unfortunately this won't apply to wireless-testing because main.c is
> renamed to wl1251_main.c.
> Can you respin the patch or do you want me to
> do it? I'm sending other wl12xx patches anyway and it's easy for me to
> rebase this one at the same time.
It seems to be fixed now. But currently I'm confused by wl1251_plt_start
and wl1251_plt_stop. They take a lock but doesn't unlock it at all.
Neither their callies. Is it hidden somewhere deeper?
Jiri Slaby <[email protected]> writes:
> But currently I'm confused by wl1251_plt_start and wl1251_plt_stop.
> They take a lock but doesn't unlock it at all. Neither their callies.
> Is it hidden somewhere deeper?
I guess that's a bug which creeped in when I ported the patches from our
internal tree. I'll just remove plt start/stop functions altogether,
they need to ported to the new nl80211 test mode interface anyway.
Oh damn, I just noticed that I added wl1251_netlink.c accidentally to
wireless-testing tree. It should definitely not be there, instead we
need to use nl80211 test command interface. I'll send a patch to remove
the private netlink stuff soon. John, sorry about this.
--
Kalle Valo