Hello Tom, I just sent a fix for the issue in the my "coverity and 64-bit division fixes" series. If it's needed I can split the series and send patches separately.
Regards, Mikhail Kshevetskiy On 10/12/25 22:07, Tom Rini wrote: > On Sun, Oct 12, 2025 at 05:22:15PM +0300, Mikhail Kshevetskiy wrote: >> On 11.10.2025 21:06, Tom Rini wrote: >>> I think unfortunately the report email for when I merged in -next was >>> lost somewhere / wasn't sent. I may be able to get the details out the >>> dashboard. >>> >>> ---------- Forwarded message --------- >>> From: <[email protected]> >>> Date: Fri, Oct 10, 2025 at 7:08 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 >>> - *Defects Shown:* Showing 1 of 1 defect(s) >>> >>> Defect Details >>> >>> ** CID 537478: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> /drivers/spi/spi-mem.c: 528 in spi_mem_calc_op_duration() >>> >>> >>> _____________________________________________________________________________________________ >>> *** CID 537478: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>> /drivers/spi/spi-mem.c: 528 in spi_mem_calc_op_duration() >>> 522 ncycles += ((op->addr.nbytes * 8) / op->addr.buswidth) / >>> (op->addr.dtr ? 2 : 1); >>> 523 >>> 524 /* Dummy bytes are optional for some SPI flash memory >>> operations */ >>> 525 if (op->dummy.nbytes) >>> 526 ncycles += ((op->dummy.nbytes * 8) / >>> op->dummy.buswidth) / >>> (op->dummy.dtr ? 2 : 1); >>> 527 >>>>>> CID 537478: Integer handling issues (OVERFLOW_BEFORE_WIDEN) >>>>>> Potentially overflowing expression "op->data.nbytes * 8U" with type >>>>>> "unsigned int" (32 bits, unsigned) is evaluated using 32-bit arithmetic, >>>>>> and then used in a context that expects an expression of type "u64" (64 >>>>>> bits, unsigned). >>> 528 ncycles += ((op->data.nbytes * 8) / op->data.buswidth) / >>> (op->data.dtr ? 2 : 1); >> >> op->data.nbytes comes from file drivers/mtd/nand/spi/core.c, function >> spinand_select_op_variant(). >> According to the code the max value of op->data.nbytes is >> >> nanddev_per_page_oobsize(nand) + nanddev_page_size(nand) >> >> thus it's slightly more than 4Kb (I never seen flashes with page size >> large than 4Kb). According to this estimation the overflow will never >> happen. >> >> If it make sense, I can try to do something with it > Yes, please see what you can do about it and thanks for explaining that > it shouldn't be an actual problem. >
