Skip to contentSkip to conversation

rtlwifi: rtl8723ae: Fix missing break in switch statement

PATCH Superseded Gustavo A. R. Silva 2 participants 5 messages Apr 16, 2019

Subsystems (3)

v1 of 2 Superseded Latest is v2 →

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 rtlwifi: rtl8723ae: Fix missing break in switch statement

Add missing break statement in order to prevent the code from falling through to case 0x1025, and erroneously setting rtlhal->oem_id to RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and none of the cases in switch (rtlefuse->eeprom_smid) match.

This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough.

Fixes 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")
---
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c | 1 +
 1 file changed, 1 insertion(+)
drivers/net/wireless/realtek/rtlwifi/rtl8723ae/hw.c +1 -0
index 6bab162e1bb8..655460f61bbc 100644
@@ -1675,6 +1675,7 @@ static void _rtl8723e_read_adapter_info(struct ieee80211_hw *hw,
 					rtlhal->oem_id = RT_CID_819X_LENOVO;
 					break;
 				}
+				break;
 			case 0x1025:
 				rtlhal->oem_id = RT_CID_819X_ACER;
 				break;
Signature · 1 line
2.21.0
#1 lore raw
Quoted 11 lines · Gustavo A. R. Silva

Add missing break statement in order to prevent the code from falling through to case 0x1025, and erroneously setting rtlhal->oem_id to RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and none of the cases in switch (rtlefuse->eeprom_smid) match.

This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough.

Fixes 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")

You have marked this for wireless-drivers but the commit is 2.5 years old, so I think wireless-drivers-next is more approriate.

Signature · 1 line
Kalle Valo
#2 lore raw
Quoted 10 lines · Kalle Valo
Quoted 8 lines · Gustavo A. R. Silva

Add missing break statement in order to prevent the code from falling through to case 0x1025, and erroneously setting rtlhal->oem_id to RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and none of the cases in switch (rtlefuse->eeprom_smid) match.

This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough.

Quoted 7 lines
Quoted 3 lines
Fixes 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")

You have marked this for wireless-drivers but the commit is 2.5 years old, so I think wireless-drivers-next is more approriate.

Yeah. This can actually be applied to both of them. What I'd like is to have this applied to stable, so I thought wireless-drivers was a more straightforward way.

Anyway, I'll update the tag and respin.

Thanks
--
Gustavo

#3 lore raw
Quoted 15 lines · Gustavo A. R. Silva
Quoted 14 lines · Kalle Valo
Quoted 11 lines · Gustavo A. R. Silva

Add missing break statement in order to prevent the code from falling through to case 0x1025, and erroneously setting rtlhal->oem_id to RT_CID_819X_ACER when rtlefuse->eeprom_svid is equal to 0x10EC and none of the cases in switch (rtlefuse->eeprom_smid) match.

This bug was found thanks to the ongoing efforts to enable -Wimplicit-fallthrough.

Fixes 238ad2ddf34b ("rtlwifi: rtl8723ae: Clean up the hardware info routine")
Quoted 7 lines
Quoted 3 lines

You have marked this for wireless-drivers but the commit is 2.5 years old, so I think wireless-drivers-next is more approriate.

Yeah. This can actually be applied to both of them. What I'd like is to have this applied to stable, so I thought wireless-drivers was a more straightforward way.

Sure, makes sense. But I just want to keep the number of patches going to wireless-drivers to the minimum, I really want to avoid conflicts as much as possible. That's why I'm keeping the bar high for w-d.

Quoted 1 line

Anyway, I'll update the tag and respin.

Thanks.

Signature · 1 line
Kalle Valo
#4 lore raw
Quoted 4 lines · Kalle Valo
Quoted 4 lines
Quoted 3 lines

You have marked this for wireless-drivers but the commit is 2.5 years old, so I think wireless-drivers-next is more approriate.

Quoted 8 lines
Quoted 3 lines

Yeah. This can actually be applied to both of them. What I'd like is to have this applied to stable, so I thought wireless-drivers was a more straightforward way.

Sure, makes sense. But I just want to keep the number of patches going to wireless-drivers to the minimum, I really want to avoid conflicts as much as possible. That's why I'm keeping the bar high for w-d.

Yep. I've got it.

I just sent v2:

https://lore.kernel.org/patchwork/patch/1062748/

Thanks
--
Gustavo