[4.14] Fix GCC 6.4.0 and 7.3.0 warnings

[nathanchance]

I ran into these warnings on the latest 4.14 branch.

../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c: In function ‘aes_cipher’:
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c:1504:5: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
     for (j = 0; j < 8; j++)
     ^~~
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c:1507:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
  payload_index = hdrlen + 8;
  ^~~~~~~~~~~~~
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c: In function ‘aes_decipher’:
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c:1878:5: warning: this ‘for’ clause does not guard... [-Wmisleading-indentation]
     for (j = 0; j < 8; j++)
     ^~~
../drivers/net/wireless/realtek/rtl8192cu/core/rtw_security.c:1881:2: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the ‘for’
  payload_index = hdrlen + 8;
  ^~~~~~~~~~~~~
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c: In function ‘vchiq_open’:
../drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c:1735:7: warning: unused variable ‘ret’ [-Wunused-variable]
   int ret;
       ^~~

Pretty simple to fix and now make > /dev/null is clean.

[popcornmix]

We've actually picked a newer source of the rtl8192cu patches in later kernels, so this patch won't affect them, but otherwise no objections.
@pelwell ?

[lategoodbye]

FWIW with the Linaro toolchain gcc-linaro-7.2.1-2017.11, i'm getting more warnings (didn't check for false-positive):

drivers/net/wireless/realtek/rtl8192cu/core/rtw_mlme_ext.c: In function ‘mgt_dispatcher’:
drivers/net/wireless/realtek/rtl8192cu/core/rtw_mlme_ext.c:734:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
    if(check_fwstate(pmlmepriv, WIFI_AP_STATE) == _TRUE)
      ^
drivers/net/wireless/realtek/rtl8192cu/core/rtw_mlme_ext.c:739:3: note: here
   case WIFI_ASSOCREQ:
   ^~~~

drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/rtl8192c_phycfg.c: In function ‘phy_TxPwrIdxToDbm’:
drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/rtl8192c_phycfg.c:2365:10: warning: this statement may fall through [-Wimplicit-fallthrough=]
   Offset = -8;
   ~~~~~~~^~~~
drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/rtl8192c_phycfg.c:2366:2: note: here
  default:
  ^~~~~~~
drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/usb/usb_halinit.c: In function ‘GetHwReg8192CU’:
drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/usb/usb_halinit.c:5694:20: warning: this statement may fall through [-Wimplicit-fallthrough=]
    *((u16 *)(val)) = pHalData->BasicRateSet;
    ~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/wireless/realtek/rtl8192cu/hal/rtl8192c/usb/usb_halinit.c:5695:3: note: here
   case HW_VAR_TXPAUSE:
   ^~~~
drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_linux.c: In function ‘set_group_key’:
drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_linux.c:7383:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
    keylen = 16;
    ~~~~~~~^~~~
drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_linux.c:7384:3: note: here
   default:
   ^~~~~~~
drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c: In function ‘set_group_key’:
drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c:822:11: warning: this statement may fall through [-Wimplicit-fallthrough=]
    keylen = 16;
    ~~~~~~~^~~~
drivers/net/wireless/realtek/rtl8192cu/os_dep/linux/ioctl_cfg80211.c:823:3: note: here
   default:
   ^~~~~~~
drivers/usb/host/dwc_otg/dwc_otg_fiq_fsm.c: In function ‘fiq_fsm_update_hs_isoc’:
drivers/usb/host/dwc_otg/dwc_otg_fiq_fsm.c:595:61: warning: statement will never be executed [-Wswitch-unreachable]
   st->hctsiz_copy.b.xfersize = nrpackets * st->hcchar_copy.b.mps;
                                            ~~~~~~~~~~~~~~~~~^~~~

[nathanchance]

@lategoodbye Yeah GCC 7.x will have newer warnings, I'd be open to fixing those as well if they are.

[nathanchance]

@popcornmix just FYI, I just did a build off of the 4.16.y branch and both patches apply and are relevant.

[popcornmix]

Okay, the 8192cu change might be best submitted here: https://github.com/pvaret/rtl8192cu-fixes
as that is where we'll pull future 8192cu updates from.

[nathanchance]

Perfect, will go ahead and take a look at submitting them there!

[nathanchance]

@popcornmix Just so I am clear about the flow cycle here so I don't waste your time in the future, should I be basing patches on the 4.16.y branch and then porting the relevant ones back to the older branches? Which branches are active and worthy of these fixes? I want to make you guys do the least amount of work since these aren't mission critical fixes.

[pelwell]

This is correct, but it would be better to replace the kmalloc above with kzalloc and delete this line.

[pelwell]

All fine apart from me preferring a kmalloc -> kzalloc fix.

[nathanchance]

@pelwell, done, thank you!

[popcornmix]

4.14 will be the next kernel used by raspbian and is LTS so we are likely to stick with it as stable kernel for some time. (Most likely until some new feature, perhaps in the drm/vc4 area which evolves quite rapidly makes the switch worthwhile).

So I'd suggest PR-ing to 4.14 in general.

Ignore kernels older than 4.14 - they are unlikely to get further updates.

The newer kernels are mostly for bleeding edge testers and are used by some other distributions, and obviously will be used when we finally move to a newer stable kernel. Most kernels aren't LTS and we typically will stop updating the tree when kernel.org marks it as EOL.

If the PR to 4.14 applies cleanly to newer kernel trees, just let us know and we'll cherry pick changes. If it's more complicated then separate PRs are useful.

[popcornmix]

The original code is showing that WIRELESS_MODE_G and WIRELESS_MODE_N_24G have been handled explicitly and need Offset = -8. The default case generally means we'll pick a sane value, but it's less clear if it will be correct if new modes are added.

I think the real bug is the missing break statement after the assignment, and fixing it that way makes it clear that WIRELESS_MODE_G/WIRELESS_MODE_N_24G are being handled explicitly.

The compiler will generate the same code is all cases, but add the break rather than removing the labels provides more information to a programmer reading the code.

This also applies to the following two similar patches.

[nathanchance]

Will push that change here shortly.

[pelwell]

Ditto for the other two similar instances.

[nathanchance]

All three instances fixed properly.

[pelwell]

Thanks!