Changes

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

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

Change-Id: Iceb0013adf448fe56c909fd8ccf14a021d8b7331

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

main: rework panic handler

When an OSMO_ASSERT() fails it will call the osmo panic handler.
Previous it will always calls into a breakpoint which will require
a power-cycle.

Change the default (for production) to use a system reset.
But still allow calling into breakpoint by setting `break_on_panic` via SWD.

Change-Id: I91c732001e848ec5509bf81af8aac1a2a80eb718

main: rework panic handler

When an OSMO_ASSERT() fails it will call the osmo panic handler.
Previous it will always calls into a breakpoint which will require
a power-cycle.

Change the default (for production) to use a system reset.
But still allow calling into breakpoint by setting `break_on_panic` via SWD.

Change-Id: I91c732001e848ec5509bf81af8aac1a2a80eb718

main: rework panic handler

When an OSMO_ASSERT() fails it will call the osmo panic handler.
Previous it will always calls into a breakpoint which will require
a power-cycle.

Change the default (for production) to use a system reset.
But still allow calling into breakpoint by setting `break_on_panic` via SWD.

Change-Id: I91c732001e848ec5509bf81af8aac1a2a80eb718

main: rework panic handler

When an OSMO_ASSERT() fails it will call the osmo panic handler.
Previous it will always calls into a breakpoint which will require
a power-cycle.

Change the default (for production) to use a system reset.
But still allow calling into breakpoint by setting `break_on_panic` via SWD.

Change-Id: I91c732001e848ec5509bf81af8aac1a2a80eb718

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

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

ccid_common: iso_handle_fsm_events: add missing return

Fix warning about control reaches end of non-void function.

Change-Id: I4066c8a1ab1eadb3d8f8cbaf5aa0afbbb2e5dd80

ccid: fix rdr_to_pc_parameters and rdr_to_pc_hardware_error

Change-Id: I67d5cb876d20b29f4759d5b194606f34b8b966c4

fix wait time extension handling

wait time ext byte was mishandled as sw1 and sw2, which broke transfers that took a long time, i.e. crypto ops during esim interactions.

Closes: SYS#7869
Change-Id: I7527a4337ae857b9b2a4e982606fac770e677d73

fix wait time extension handling

Change-Id: I7527a4337ae857b9b2a4e982606fac770e677d73