[Coverity CID :203452]Control flow issues in /drivers/timer/xlnx_psttc_timer.c

[aasthagr]

Static code scan issues seen in File: /drivers/timer/xlnx_psttc_timer.c
Category: Control flow issues
Function: xttc_calculate_interval
Component: Drivers
CID: 203452
Please fix or provide comments to square it off in coverity in the link: https://scan9.coverity.com/reports.htm#v32951/p12996

[aescolar]

@bbolen this code came from your PR #9316 from this commit 4ef9d4b , could you take a look at it?

[aescolar]

Related to #18365

[LeiW000]

Does anyone know where DT_INST_0_CDNS_TTC_CLOCK_FREQUENCY is defined? Without it, I can't figure out how to fix the issue.

[bbolen]

It's generated by qemu_cortex_r5.dts.

This is really a consequence of using compile time definition of TIMER_INPUT_CLKHZ and TIMER_FREQ. coverity just sees one set of values and can deduce a certain set of code paths can't be hit, but a different set of values for those defines may take a different path. So you really don't want to remove the paths marked as DEADCODE in this case. I was trying to see if I could rearrange the function so that coverity wouldn't see anything as deadcode, but I haven't come up with a way yet to handle all cases. The same information applies to #18365

[galak]

It's generated by qemu_cortex_r5.dts.

This is really a consequence of using compile time definition of TIMER_INPUT_CLKHZ and TIMER_FREQ. coverity just sees one set of values and can deduce a certain set of code paths can't be hit, but a different set of values for those defines may take a different path. So you really don't want to remove the paths marked as DEADCODE in this case. I was trying to see if I could rearrange the function so that coverity wouldn't see anything as deadcode, but I haven't come up with a way yet to handle all cases. The same information applies to #18365

I think we mark the coverity issue a 'false positive' (in coverity).

[LeiW000]

I think we mark the coverity issue a 'false positive' (in coverity).
@galak , do you know who is able to do it?

[galak]

I think we mark the coverity issue a 'false positive' (in coverity).
@galak , do you know who is able to do it?

If you are a contributor/member I think you can update the state in https://scan.coverity.com

[LeiW000]

We should ignore it in coverity. It is possible that "TIMER_INPUT_CLKHZ" is defined with a very large number by user in qemu_cortex_r5.dts.

I have updated "CID 203452" in coverity to ignore it. So, I think we can close the issue now.