drivers: can: relax exact-divisibility requirement in timing calc

[tbitcs]

Summary

can_calc_timing_internal() requires core_clock % (prescaler * bitrate) == 0 — an
exact integer number of time quanta — before it will evaluate a prescaler candidate. On
SoCs whose CAN peripheral clock is derived from a PLL or FLL (rather than a clean integer
divisor of the system clock), this condition is never satisfied for any prescaler and the
function returns -ENOTSUP, making can_calc_timing() and can_set_bitrate() fail for
all standard bitrates.

Root Cause

if (core_clock % (prescaler * bitrate)) {
    /* No integer total_tq for this prescaler setting */
    continue;
}
total_tq = core_clock / (prescaler * bitrate);

On NXP MKV58F (Kinetis KV58, 120 MHz CAN clock derived from a 180 MHz PLL), the
standard CiA 301 bitrates require a prescaler of 12. With prescaler=12 and
bitrate=500000: 120000000 % (12 * 500000) = 0, so that one happens to work. But for
other clock/bitrate/prescaler combinations on similar SoCs the remainder is non-zero for
every prescaler, and the timing search silently returns -ENOTSUP.

The same issue affects any target where the CAN module clock is not an exact integer
multiple of the chosen bitrate for every legal prescaler value.

Fix

Replace the exact-divisibility test with nearest-integer rounding for total_tq
using 64-bit arithmetic, then verify that the resulting actual bitrate deviates by no
more than 5000 ppm (0.5%) from the requested value. CiA 601 allows up to 1.58% for
nominal bitrates; the 0.5% threshold gives comfortable margin while unlocking prescalers
that would otherwise be skipped.

Additional changes in the same commit:

• Add tq_min/tq_max bounds derived from the hardware segment limits so that
  prescalers yielding an unrealisable total_tq are still skipped efficiently.
• Tighten the early-exit condition: break only when both the sample-point error is
  zero and real_bitrate == bitrate exactly (previously a zero SP error alone
  stopped the search even when the bitrate had a rounding remainder).
• Use 64-bit arithmetic throughout to prevent overflow in prescaler * bitrate.
• Minor: add U suffix on /2 in the SJW default calculation; parenthesise the ternary
  in the return statement.

Tests

tests/drivers/can/timing/src/main.c is updated in the same commit:

• assert_bitrate_correct() is generalised to a tolerance-based check (±5000 ppm)
  instead of an exact equality. This is needed because the fixed algorithm now finds
  timing on non-integer-multiple clocks where before it returned -ENOTSUP and the
  assertion was never reached.
• A new test_timing_non_integer_clock ztest is added. It iterates the four core CiA 301
  nominal bitrates (125k/250k/500k/1M bps), calls can_calc_timing() on the board's CAN
  device, and asserts success plus ≤5000 ppm bitrate error. The test passes on boards with
  exact-multiple clocks (0 ppm error) and on boards with PLL-derived clocks (small but
  acceptable error).

Verified on NXP MKV58F (Kinetis KV58, 120 MHz CAN clock):

• Before: can_set_bitrate(500k) → -ENOTSUP
• After: prescaler=12 seg1S1=6 seg2=2 sample-point err=9‰ ✓

checkpatch.pl reports 0 errors, 0 warnings.

Related

• Issue NXP S32 CANXL: The initial calculated data phase timing may not accurate as expected #77436 (NXP S32 CANXL
  prescaler constraint — different root cause, same symptom class)
• PR NXP S32 CANXL correct the calculating initial timing #77439 — @henrikbrixandersen noted
  he intended a more generic solution for the timing algorithm; this proposes one.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud