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: <[email protected]> > Date: Fri, Feb 13, 2026 at 4:03 PM > Subject: New Defects reported by Coverity Scan for Das U-Boot > To: <[email protected]> > > > 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
