On Wed, Feb 18, 2026 at 05:02:27PM -0600, Chris Morgan wrote: > 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?
So, looking at the Coverity Scan dashboard for the kernel, there's just nothing on drivers/usb/dwc3/core.c (at all, even closed), which I think is odd, but I also think I've updated the filter correctly. I'll put your comments in the dashboard here for the issue and mark as intentional, thanks! -- Tom
signature.asc
Description: PGP signature
