On 8/11/20 10:53 AM, Alan Stern wrote: > On Tue, Aug 11, 2020 at 10:29:29AM -0700, Tom Rix wrote: >> On 8/11/20 9:03 AM, Alan Stern wrote: >>> On Tue, Aug 11, 2020 at 08:15:05AM -0700, trix@xxxxxxxxxx wrote: >>>> From: Tom Rix <trix@xxxxxxxxxx> >>>> >>>> clang static analysis reports this representative problem >>>> >>>> realtek_cr.c:639:3: warning: The left expression of the compound >>>> assignment is an uninitialized value. The computed value will >>>> also be garbage >>>> SET_BIT(value, 2); >>>> ^~~~~~~~~~~~~~~~~ >>>> >>>> value is set by a successful call to rts51x_read_mem() >>>> >>>> retval = rts51x_read_mem(us, 0xFE77, &value, 1); >>>> if (retval < 0) >>>> return -EIO; >>>> >>>> A successful call to rts51x_read_mem returns 0, failure can >>>> return positive and negative values. This check is wrong >>>> for a number of functions. Fix the retval check. >>>> >>>> Fixes: 065e60964e29 ("ums_realtek: do not use stack memory for DMA") >>>> Signed-off-by: Tom Rix <trix@xxxxxxxxxx> >>>> --- >>>> drivers/usb/storage/realtek_cr.c | 36 ++++++++++++++++---------------- >>>> 1 file changed, 18 insertions(+), 18 deletions(-) >>>> >>>> diff --git a/drivers/usb/storage/realtek_cr.c b/drivers/usb/storage/realtek_cr.c >>>> index 3789698d9d3c..b983753e2368 100644 >>>> --- a/drivers/usb/storage/realtek_cr.c >>>> +++ b/drivers/usb/storage/realtek_cr.c >>>> @@ -481,16 +481,16 @@ static int enable_oscillator(struct us_data *us) >>>> u8 value; >>>> >>>> retval = rts51x_read_mem(us, 0xFE77, &value, 1); >>>> - if (retval < 0) >>>> + if (retval != STATUS_SUCCESS) >>>> return -EIO; >>> Instead of changing all these call sites, wouldn't it be a lot easier >>> just to change rts51x_read_mem() to make it always return a negative >>> value (such as -EIO) when there's an error? >>> >>> Alan Stern >> I thought about that but there was already existing (retval != >> STATUS_SUCCESS) checks for these calls. > The only values that routine currently returns are > USB_STOR_TRANSPORT_ERROR, -EIO, and 0. None of the callers distinguish > between the first two values, so you can just change the first to the > second. > > Note that STATUS_SUCCESS is simply 0. Yes, i noted all of these already. My change is consistent with the existing correct checks. consistency is important. returning a neg value to reuse the exiting check should mean the STATUS_SUCCESS != 0 checks are changed to neg check. i can do this larger change if required. Tom > > Alan Stern >