kernel: timer: Add timer observer hooks for extensibility

[VijsharQC]

Introduce lifecycle observer callbacks (init, start, stop, expiry) for k_timer using Zephyr's iterable sections pattern. This enables external modules to extend timer functionality without modifying kernel internals.

[github-actions]

Hello @VijsharQC, and thank you very much for your first pull request to the Zephyr project!
Our Continuous Integration pipeline will execute a series of checks on your Pull Request commit messages and code, and you are expected to address any failures by updating the PR. Please take a look at our commit message guidelines to find out how to format your commit messages, and at our contribution workflow to understand how to update your Pull Request. If you haven't already, please make sure to review the project's Contributor Expectations and update (by amending and force-pushing the commits) your pull request if necessary.
If you are stuck or need help please join us on Discord and ask your question there. Additionally, you can escalate the review when applicable. 😊

[pdgendt]

Can't comment on the usefulness of the feature, but I do have some implementation suggestions.

[VijsharQC]

Hi @pdgendt, Thank you for the suggestions. Made changes as per those.
The idea behind these changes are to extend the timer functionality to allow user-driven customization and flexibility.

[pdgendt]

I think this needs tests.

[npitre]

Can you provide examples of what this is useful for?

[VijsharQC]

There are few cases where timers may need to operate only in specific modes. This approach allows vendors to add custom functionality to manage those timers without making significant changes to Zephyr’s core timer implementation.

[pdgendt]

Still missing some sample/test, it's currently not being built in CI.

Ideally a sample is added with a use case to prove the usefulness of the feature.

[VijsharQC]

After adding the test code, I see that it is failing with below error. The failure is specific to the qemu_x86 board.
Can you please suggest a way to resolve this.

INFO - 962/962 qemu_x86_tiny/atom kernel.timer.timer_observer FAILED Timeout (qemu 119.955s )
INFO - /__w/zephyr/zephyr/twister-out/qemu_x86_tiny_atom/zephyr/tests/kernel/timer/timer_observer/kernel.timer.timer_observer/handler.log
ERROR - SeaBIOS (version zephyr-v1.16.3-2-0-gf8da0cc-zephyr)
Booting from ROM..
ASSERTION FAIL [page_frames_initialized] @ WEST_TOPDIR/zephyr/kernel/mmu.c:1625
page fault at 0x4011b015 happened too early
E: EAX: 0x4010a805, EBX: 0x4011b015, ECX: 0x4010a805, EDX: 0x40117ee0
E: ESI: 0x4011b015, EDI: 0x00000000, EBP: 0x40117f08, ESP: 0x40117ed4
E: EFLAGS: 0x00000012 CS: 0x0008 CR3: 0x00110000
E: EIP: 0x40105bcd
E: call trace:
E: 0: 0x40104818
E: 1: 0x40105add
E: 2: 0x4010070e
E: 3: 0x4010404a
E: 4: 0x40100411
E: 5: 0x40106c94
E: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
E: Current thread: 0x40111000 (main)
E: Halting system

[peter-mitsis]

This test assumes that there will only be a single timer in the system--an assumption that is unlikely to hold for all boards. A quick grep in the drivers/ directory shows that there are many drivers that use k_timer; without delving deep into their use cases, it seems reasonable that they may interfere with the expected counts. I'm not sure what the best way to resolve that would be. (It might be to just document it as a comment here noting that those boards should be excluded from the test as they show up).

[pdgendt]

Or only increment the counters if the timer instance matches the test timer

static void obs_on_expiry(struct k_timer *timer)
{
	if (timer == &test_periodic_timer) {
		obs.expiry_cnt++;
	}
}

[VijsharQC]

Hi @pdgendt , @peter-mitsis - thank you for the suggestions.

I did try updating the observer callbacks so that they only increment counts when the timer instance matches test_periodic_timer. Unfortunately, the tests are still failing with the same issue.

As mentioned by @peter-mitsis, I’ve excluded qemu_x86_tiny for this test.

[sonarqubecloud]

Quality Gate passed

Issues
4 New issues
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