Skip to content

Loading builds...

Changes

#4436 (Mar 30, 2026, 3:15:50 PM)

firmware: fix timers, add missing return

Change-Id: I5b12284c88d8fe6e4fe55cc4cd2aad550d276af4
ewild at

#4434 (Mar 29, 2026, 11:09:14 PM)

firmware: add tear-free 64bit load/store helpers for jiffies

On Cortex-M4 a 64bit load may compile to two separate LDR
instructions which can lead to torn reads due to interrupts.
LDRD/STRD are restartable, they either complete or restart from
scratch, so the result is always consistent. The only "downside" is the
required alignment, which is fine.

Change-Id: I729c0fdfb5b228b03c2df1cf098743100b1ea625
ewild at
firmware: replace libosmocore fsm timers

Concurrent access from main loop and the different uart irqs was not
going well and caused crashes. The libosmocore fsm does still allocate
one internal timer, but it is not used by the firmware, so libosmocore
will not touch the rbtree.

Additionally ignore checkpatch jiffies complaints because we're trying
to do firmware here.

Closes: SYS#7877
Change-Id: Id2bd67b3946bb451008965f0b68b4a919f4d10bd
ewild at

#4397 (Mar 12, 2026, 8:17:53 PM)

ensure libosmocore logging is properly disabled for builds

Change-Id: I169a059d8daff0a3993318a4ea3ab7adcb05fee3
laforge at
ccid: generate proper error for short messages

Change-Id: I3bf0bebd361666a2f3d0341444415a6f25d2b4bf
laforge at
firmware: fix msgb/list mixed irq access handling

This fixes the mishandling of in_progress and the queues in the submit
functions that are in part irq driven, too, and ensures nothing breaks
by preventing concurrent access from irqs to the queues. Applying the
same pattern to all functions/cases is fine either way.

On top of all of tha the out ep was irq driven, so if submit_next_out
fails it was stuck, now fixed by attempted submit from main loop, and of
course the queue manipulation should be irq safe here as well.

Change-Id: I9212bfa7688cb4d3161ba963b854225744128632
laforge at

#4392 (Mar 10, 2026, 7:14:39 PM)

ccid_slot_fsm.c: Reject T=0 TPDU > 260 bytes

The CCID v1.1 ch 6.1.4 specification states a T=0 TPDU must not exceed 260 bytes,
so let's properly handle this error case.

Change-Id: Iceb0013adf448fe56c909fd8ccf14a021d8b7331
laforge at

#4391 (Mar 10, 2026, 4:33:08 PM)

ccid: Fix CCID RDR_to_PC_Parameters (missing bProtocolNum)

Our RDR_to_PC_Parameters message was broken, as it was missing
the bProtocolNum value after the header.  Let's fix that.

Change-Id: I67d5cb876d20b29f4759d5b194606f34b8b966c4
laforge at
ccid: Fix [unused] RDR_to_PC_Hardware_Error struct definition

Our definition of the message was wrong; it is an interrupt endpoint
message without the full header of the bulk-in endpoint. Luckily the
definition was not used in the code base, so this is not fixing any
problem visible on the protocol level.

Change-Id: Ieb756c37402c4ebea32cc3cd23ba3842f4c0df3e
laforge at

#4390 (Mar 10, 2026, 10:47:57 AM)

ccid_device: Reject XfrBlock with zero-length data

While the CCID v1.1 spec seems to declare dwLength == 0 is within
the valid range, it's of course a no-op as we cannot transact a TPDU
that isn't there.

Change-Id: I65df88477e4b1c03dc20a8d41e5cbd1c9f363ba8
Closes: OS#6969
laforge at

#4389 (Mar 10, 2026, 9:32:56 AM)

main: fix crash when ccid_df_write_in() fails

The OSMO_ASSERT(msg->list.next != LLIST_POISON1) are checking msgb
which has been removed from the llist.
All llist members which aren't part of a list have LLIST_POISON1 assigned.

These OSMO_ASSERT()s will always trigger this msgb.

Fixes: a684bc4e38b4 ("Make ch9 usb tests work")
Change-Id: I49c81fba756f3620638b6c6c664f53e4a8758ef9
laforge at
main: don't access msgbs after giving them away

Because of IRQ, it is dangerous to access a msgb,
which has been giving away to a queue (ownership transfer).

Further OSMO_ASSERT() should never fail on a queue'd object,
except it has been taken already from an IRQ context.
Fix a potential crash.

Fixes: a684bc4e38b4 ("Make ch9 usb tests work")
Change-Id: I79844f77d5cd75e08b0eb44b22c4ad223cb79dcb
laforge at

#4371 (Mar 2, 2026, 8:03:13 AM)

clang-format: set ColumnLimit: 0

While our coding style says "we accept line lengths of up to 120
characters", in practice we oftentimes end up preferring longer lines
(e.g. due to having comments at the end, or to keep them consistent with
similar but shorter lines).

The checkpatch config has already been adjusted to just ignore the line
length completely. Adjust the clang-format config to do the same.

Related: osmo-ci I88fd86ac550fddb3017aeceb647c3d9e75367372
Change-Id: I1f0d511d90a0725f195e08dd6a99eb3d55bd6fc1
Oliver Smith at