Smatch: False positive in __dwc3_gadget_kick_transfer()

Smatch: False positive in __dwc3_gadget_kick_transfer()

[Zeeshan Ahmad]

Hi Dan,

I am performing a logic audit of the DWC3 driver and encountered a 
consistent Smatch warning in drivers/usb/dwc3/gadget.c that appears 
to be a false positive.

The warning:
drivers/usb/dwc3/gadget.c:1691 __dwc3_gadget_kick_transfer() warn: missing error code? 'ret'

The code:
1680:         ret = dwc3_prepare_trbs(dep);
1681:         if (ret < 0)
1682:                 return ret;
...
1690:         if (!ret && !starting)
1691:                 return ret;

In this context, ret = 0 is a valid success state. As noted in the 
comment at line 1676, it is normal to have no new TRBs prepared. 
The return at line 1691 signifies that no update to the transfer 
is required, which is a successful "no-op" rather than a failure.

It seems Smatch is flagging this because it expects a non-zero 
error code when the primary logic of a function is bypassed by 
a conditional check.

Best regards,
Zeeshan Ahmad

Re: Smatch: False positive in __dwc3_gadget_kick_transfer()

[Dan Carpenter]

On Wed, Mar 04, 2026 at 02:04:08PM +0500, Zeeshan Ahmad wrote:
> Hi Dan,
> 
> I am performing a logic audit of the DWC3 driver and encountered a 
> consistent Smatch warning in drivers/usb/dwc3/gadget.c that appears 
> to be a false positive.
> 
> The warning:
> drivers/usb/dwc3/gadget.c:1691 __dwc3_gadget_kick_transfer() warn: missing error code? 'ret'
> 
> The code:
> 1680:         ret = dwc3_prepare_trbs(dep);
> 1681:         if (ret < 0)
> 1682:                 return ret;
> ...
> 1690:         if (!ret && !starting)
> 1691:                 return ret;

Just do "return 0;"  It's more readable, since it removes a level of
indirection and we don't have to think about what ret is.

I always recall a discuss between my managers:
Q: But if we do that then how will they know where the zero comes from?
A: We'll make our zeroes will *extra* round.  :P

regards,
dan carpenter

Re: Smatch: False positive in __dwc3_gadget_kick_transfer()

[Zeeshan Ahmad]

Hi Dan,

Thank you for the explanation and the manager's joke.

On Wed, Mar 4, 2026 at 7:09 PM Dan Carpenter <dan.carpenter@linaro.org> wrote:

> Just do "return 0;"  It's more readable, since it removes a level of
> indirection and we don't have to think about what ret is.

I agree. Since the !ret condition ensures that ret is 0 at that
point, using an explicit return makes the successful "no-op" path
immediately clear to the reader and removes the logical overhead of
tracking the variable.

> I always recall a discuss between my managers:
> Q: But if we do that then how will they know where the zero comes from?
> A: We'll make our zeroes will *extra* round.  :P

I will ensure my zeros are extra round in the patch. I'll prepare a
clean-up patch for the USB tree to implement this and silence the
warning.

Best regards,
Zeeshan