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.
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
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.
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.
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.
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.
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.
If this is set, then don't clean the firmware at the end. This is needed to store the built firmware as artifact in jenkins, for passing it along to another job.
