Re: Fwd: New Defects reported by Coverity Scan for Das U-Boot

Chris Morgan
2026-02-18T23:14:39Z

On Fri, Feb 13, 2026 at 04:09:27PM -0600, Tom Rini wrote:
> Latest Coverity Scan report, now that it's back up and so a little out
> of sync with the usual schedule.
>
> ---------- Forwarded message ---------
> From: <scan-admin@coverity.com>
> Date: Fri, Feb 13, 2026 at 4:03 PM
> Subject: New Defects reported by Coverity Scan for Das U-Boot
> To: <tom.rini@gmail.com>
>
>
> Hi,
>
> Please find the latest report on new defect(s) introduced to *Das U-Boot*
> found with Coverity Scan.
>
> - *New Defects Found:* 1
> - 2 defect(s), reported by Coverity Scan earlier, were marked fixed in
> the recent build analyzed by Coverity Scan.
> - *Defects Shown:* Showing 1 of 1 defect(s)
>
> Defect Details
>
> ** CID 328330: Integer handling issues (NO_EFFECT)
> /drivers/usb/dwc3/core.c: 106 in dwc3_core_soft_reset()
>
>
> _____________________________________________________________________________________________
> *** CID 328330: Integer handling issues (NO_EFFECT)
> /drivers/usb/dwc3/core.c: 106 in dwc3_core_soft_reset()
> 100 done:
> 101 /*
> 102 * For DWC_usb31 controller 1.80a and prior, once DCTL.CSFRST bit
> 103 * is cleared, we must wait at least 50ms before accessing the PHY
> 104 * domain (synchronization delay).
> 105 */
> >>> CID 328330: Integer handling issues (NO_EFFECT)
> >>> This greater-than-or-equal-to-zero comparison of an unsigned value is always true. "dwc->revision >= 0U".
> 106 if (DWC3_VER_IS_WITHIN(DWC31, ANY, 180A))
> 107 mdelay(50);
> 108
> 109 return 0;
> 110 }
> 111
>
>
> View Defects in Coverity Scan
> <https://scan.coverity.com/projects/das-u-boot?tab=overview>
>
> Best regards,
>
> The Coverity Scan Admin Team
>
> ----- End forwarded message -----
>
> --
> Tom

I'm not *entirely* sure what to do to fix this issue, but it looks
like maybe the issue is that all we're trying to do here is make sure
that the version is DWC31_REVISION_180A or earlier, and this is done in
mainline by checking between revisions _ANY and revisions _180A
(instead of creating a new macro). Since the DWC31_REVISION_ANY is set
as 0 this means that condition will always evaluate as true. In this
case though that's fine, because all we really care about is if the
second condition of the macro is true (whether or not we are equal to
or less than revision _180A).

I copied this stuff directly out of the mainline Linux driver so as to
maintain some semblance of parity (and because I needed the stuff that
used this specific macro for gadget mode), however it looks like to stop
this Coverity error I need to create a new macro, possibly a
DWC3_VER_IS_AFTER() macro. Or is it simply fine to say that I
acknowledge the issue, but given the context don't think it's an issue
if the comparison to zero always returns true because it's just a reused
macro with two conditions and we only care about the second condition?

Thank you,
Chris