Change `spin_until_cond` in set_controller_mode

[agerasym-sonatus]

linux/drivers/net/can/llce/llce_can.c

Line 267 in 810f396

spin_until_cond(state_transition_timeout(conf_chan, exp_state, timeout));

spin_until_cond is a bad choice. It is a busy wait, it is blocking the cpu core on startup and resume from suspend for up to 500ms.
Please, replace it with msleep or other yilding wait.

[gprocopciucnxp]

Hi @agerasym-sonatus,

Thank you for reaching out and letting us know about a potential problem that you have spotted while reviewing the code.

Indeed, the spin_until_cond macro, on ARM64, continuously spins on the CPU while executing the yield ASM instruction in between. It puts heavy pressure on the CPU and should be improved.

Regarding the proposed msleep solution: while it would solve the busy-wait problem, the kernel provides a better standard pattern for this use case - read_poll_timeout() - which periodically evaluates the condition with sleeps in between.

Using read_poll_timeout() will:

• Eliminate the CPU busy-wait problem you identified
• Exit immediately when the state transition completes successfully
• Significantly reduce CPU cycles wasted during the wait

On the other hand, if the controller is not able to transition to the specified state, then we will only get the advantage of reducing the spent CPU cycles, while the overall wall-clock execution time will be the same or slightly increase (by up to one polling interval) depending on the sleep period between condition evaluations. This is an acceptable trade-off given that:

1. The normal case (successful transition) benefits from immediate exit
2. The timeout case is an error scenario where slightly longer wait is acceptable
3. The CPU resource savings are significant, especially during boot/resume

To help us better understand the impact and priority of this issue, could you please share some additional details:

• How did you discover this issue - through code review, runtime testing, or performance profiling?
• Are you observing any specific symptoms or side effects in your system (e.g., delayed boot times, slow resume, unresponsive system during CAN initialization)?
• Have you measured CPU usage or noticed any particular scenarios where this becomes problematic?
• What is your typical use case - frequent suspend/resume cycles, or primarily boot-time initialization?

Regards,
Ghennadi

[agerasym-sonatus]

@gprocopciucnxp,

• How did you discover this issue - through code review, runtime testing, or performance profiling?
  code review + debugging other issue

• Are you observing any specific symptoms or side effects in your system (e.g., delayed boot times, slow resume, unresponsive system during CAN initialization)?
  resume from suspend to RAM seems to be affected by this, because it takes 0-5 retries to set_controller_mode, so it spins for up to 2,5 sec.

• Have you measured CPU usage or noticed any particular scenarios where this becomes problematic?
  not measured precisely
  the scenario is a resume from suspend to RAM. LLCE seems to be not ready and set_controller_mode is timing out.

• What is your typical use case - frequent suspend/resume cycles, or primarily boot-time initialization?
  suspend/resume cycles, haven't seen a timeout during coldboot

[gprocopciucnxp]

Hi @agerasym-sonatus ,

Thank you for your feedback. We will investigate the issue and provide a fix in upcoming releases.

Regards,
Ghennadi