Re: [PATCH v3 3/6] staging: r8188eu: add error handling of rtw_read8
From: Nick Desaulniers <hidden>
Date: 2021-08-25 17:11:59
Also in:
lkml, oe-kbuild-all
On Wed, Aug 25, 2021 at 6:44 AM Pavel Skripkin [off-list ref] wrote:
On 8/25/21 4:34 PM, Dan Carpenter wrote:quoted
On Wed, Aug 25, 2021 at 04:02:26PM +0300, Pavel Skripkin wrote:quoted
quoted
This is not related to your patch. Ignore it.quoted
quoted
vim +2022 drivers/staging/r8188eu/hal/usb_halinit.cquoted
2020 case HW_VAR_BCN_VALID: 2021 /* BCN_VALID, BIT(16) of REG_TDECTRL = BIT(0) of REG_TDECTRL+2, write 1 to clear, Clear by sw */quoted
2022 u8 tmp;Hm, I don't know anything about ARM compilers, so should I wrap this code block with {}?Yep.quoted
My local gcc 11.1.1 (x86_64) does not produce any warnings/errorsYou should figure out whats up with that because it shouldn't compile with the gcc options that the kernel uses.AFAIK, at least 2 guys except me in this CC list compiled my series without errors/warnings. Maybe, staging tree is missing some Makefile updates? I'll resend series this evening anyway, but this is strange....Hm... In my version of GCC the error is: drivers/staging/r8188eu/hal/usb_halinit.c:1870:3: error: a label can only be part of a statement and a declaration is not a statement That's a different error from what I was expecting. It's caused by having a declaration directly after a case statement. The warning that I was expecting was from -Wdeclaration-after-statement and it looks like this: warning: ISO C90 forbids mixed declarations and code [-Wdeclaration-after-statement] You really should try investigate why this compiles for you because something is going wrong. It should not build without a warning.Looks like it's bug in gcc 11.1.1. I've rebuilt this module with gcc 10 (gcc-10 (SUSE Linux) 10.3.1 20210707 [revision 048117e16c77f82598fca9af585500572d46ad73]) and build fails with error described above My default gcc is gcc (SUSE Linux) 11.1.1 20210721 [revision 076930b9690ac3564638636f6b13bbb6bc608aea] Any idea? :)
The original report said the build was with clang-14, which is near top of tree and unreleased. It's possible that that build had a bug that hopefully was reverted. -- Thanks, ~Nick Desaulniers