Skip to content

Conversation

@ccli8
Copy link
Owner

@ccli8 ccli8 commented Jun 18, 2024

This is a draft of supporting 64-bit clock module index on NuMaker SoC series. Relevant points include:

  1. No m55m1x yet, take m2l31x as an example
  2. Implementation of 64-bit clock module index:
    1. In clock header file for DT, the 32-bit value of expanded FOO_MODULE macro is an index into table of actual 64-bit clock module index
      NOTE: See dt-bindings/clock/numaker_m2l31x_clock.h
    2. In clock ontrol driver, the table of actual 64-bit clock module index is placed there and the driver will be soc-conditional to index into the table.

…aft 3)

This is a draft of supporting 64-bit clock module index on NuMaker SoC series.
Relevant points include:
1. No m55m1x yet, take m2l31x as an example
2. Implementation of 64-bit clock module index:
   (1) In clock header file for DT, the 32-bit value of expanded FOO_MODULE macro
       is an index into table of actual 64-bit clock module index
       NOTE: See dt-bindings/clock/numaker_m2l31x_clock.h
   (2) In clock ontrol driver, the table of actual 64-bit clock module index is
       placed there and the driver will be soc-conditional to index into the table.

Signed-off-by: Chun-Chieh Li <[email protected]>
ccli8 pushed a commit that referenced this pull request Oct 29, 2025
The "_too_small" test variants intentionally configure an isolated buffer
pool with only 2 buffers to validate proper error handling when the pool
is exhausted during notification of 16 msg_subscriber observers. These
tests are likely to fail on SMP systems due to a buffer recycling race
condition:

Expected behavior (uniprocessor):
  Publisher Thread:
    1. Allocate buf1 for bar_msg_sub1 ✓
    2. k_fifo_put(sub1_fifo, buf1)
    3. Allocate buf2 for bar_msg_sub2 ✓
    4. k_fifo_put(sub2_fifo, buf2)
    5. Try allocate buf3 for bar_msg_sub3 → FAIL -ENOMEM

  Subscriber threads process messages after notification completes,
  pool exhausts at subscriber #3 as expected.

SMP race condition:
  CPU 0 (Publisher):         CPU 1 (bar_msg_sub1):  CPU 2 (bar_msg_sub2):
  ------------------         ---------------------  ---------------------
  Alloc buf1 ✓
  k_fifo_put(sub1, buf1)
                             k_fifo_get() → buf1
                             zbus_sub_wait_msg()
                             net_buf_unref()
                             → buf1 FREED!
  Alloc buf2 ✓
  (reuses buf1!)
  k_fifo_put(sub2, buf2)
                                                    k_fifo_get() → buf2
                                                    net_buf_unref()
                                                    → buf2 FREED!
  Alloc buf3 ✓
  (reuses buf1 again!)
  ...continues...
  All 16 allocations succeed!

On SMP systems, subscriber threads on other CPUs may consume and free
buffers quickly enough that they are recycled back to the pool before the
publisher's notification loop can exhaust it. The test's assumption that
notification completes before subscribers run does not hold with parallel
execution.

Since this is a test design limitation (not a zbus bug), filter SMP
configurations from these specific test variants rather than attempt to
artificially slow down subscribers or change thread priorities.

Signed-off-by: Nicolas Pitre <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants