On Thu, May 02, 2019 at 11:18:01AM -0700, Nick Desaulniers wrote: > On Thu, May 2, 2019 at 8:16 AM Nathan Chancellor > <natechancellor@xxxxxxxxx> wrote: > > > > When building with -Wuninitialized, Clang warns: > > > > drivers/net/wireless/rsi/rsi_91x_sdio.c:940:43: warning: variable 'data' > > is uninitialized when used here [-Wuninitialized] > > put_unaligned_le32(TA_HOLD_THREAD_VALUE, data); > > ^~~~ > > drivers/net/wireless/rsi/rsi_91x_sdio.c:930:10: note: initialize the > > variable 'data' to silence this warning > > u8 *data; > > ^ > > = NULL > > 1 warning generated. > > > > Using Clang's suggestion of initializing data to NULL wouldn't work out > > because data will be dereferenced by put_unaligned_le32. Use kzalloc to > > properly initialize data, which matches a couple of other places in this > > driver. > > > > Fixes: e5a1ecc97e5f ("rsi: add firmware loading for 9116 device") > > Link: https://github.com/ClangBuiltLinux/linux/issues/464 > > Signed-off-by: Nathan Chancellor <natechancellor@xxxxxxxxx> > > --- > > drivers/net/wireless/rsi/rsi_91x_sdio.c | 21 ++++++++++++++------- > > 1 file changed, 14 insertions(+), 7 deletions(-) > > > > diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c > > index f9c67ed473d1..b35728564c7b 100644 > > --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c > > +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c > > @@ -929,11 +929,15 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter) > > u32 addr; > > u8 *data; > > > > + data = kzalloc(sizeof(u32), GFP_KERNEL); > > Something fishy is going on here. We allocate 4 B but declare data as > a u8* (pointer to individual bytes)? In general, dynamically > allocating that few bytes is a code smell; either you meant to just > use the stack, or this memory's lifetime extends past the lifetime of > this stackframe, at which point you probably just meant to stack > allocate space in a higher parent frame and pass this preallocated > memory down to the child frame to get filled in. > > Reading through this code, I don't think that the memory is meant to > outlive the stack frame. Is there a reason why we can't just declare > data as: > > u8 data [4]; data was __le32 in rsi_reset_chip() before commit f700546682a6 ("rsi: fix nommu_map_sg overflow kernel panic"). I wonder if this would be okay for this function: ------------------------------------------------- diff --git a/drivers/net/wireless/rsi/rsi_91x_sdio.c b/drivers/net/wireless/rsi/rsi_91x_sdio.c index f9c67ed473d1..0330c50ab99c 100644 --- a/drivers/net/wireless/rsi/rsi_91x_sdio.c +++ b/drivers/net/wireless/rsi/rsi_91x_sdio.c @@ -927,7 +927,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter) { int status; u32 addr; - u8 *data; + u8 data; status = rsi_sdio_master_access_msword(adapter, TA_BASE_ADDR); if (status < 0) { @@ -937,7 +937,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter) } rsi_dbg(INIT_ZONE, "%s: Bring TA out of reset\n", __func__); - put_unaligned_le32(TA_HOLD_THREAD_VALUE, data); + put_unaligned_le32(TA_HOLD_THREAD_VALUE, &data); addr = TA_HOLD_THREAD_REG | RSI_SD_REQUEST_MASTER; status = rsi_sdio_write_register_multiple(adapter, addr, (u8 *)&data, @@ -947,7 +947,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter) return status; } - put_unaligned_le32(TA_SOFT_RST_CLR, data); + put_unaligned_le32(TA_SOFT_RST_CLR, &data); addr = TA_SOFT_RESET_REG | RSI_SD_REQUEST_MASTER; status = rsi_sdio_write_register_multiple(adapter, addr, (u8 *)&data, @@ -957,7 +957,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter) return status; } - put_unaligned_le32(TA_PC_ZERO, data); + put_unaligned_le32(TA_PC_ZERO, &data); addr = TA_TH0_PC_REG | RSI_SD_REQUEST_MASTER; status = rsi_sdio_write_register_multiple(adapter, addr, (u8 *)&data, @@ -967,7 +967,7 @@ static int rsi_sdio_ta_reset(struct rsi_hw *adapter) return -EINVAL; } - put_unaligned_le32(TA_RELEASE_THREAD_VALUE, data); + put_unaligned_le32(TA_RELEASE_THREAD_VALUE, &data); addr = TA_RELEASE_THREAD_REG | RSI_SD_REQUEST_MASTER; status = rsi_sdio_write_register_multiple(adapter, addr, (u8 *)&data, > > then use ARRAY_SIZE(data) or RSI_9116_REG_SIZE in rsi_reset_chip(), > getting rid of the kzalloc/kfree? > > (Sorry, I hate when a simple fixup becomes a "hey let's rewrite all > this code" thus becoming "that guy.") If we aren't actually improving the code, then why bother? :) Thank you for the review! Nathan > -- > Thanks, > ~Nick Desaulniers