Condition `synch_seq != RACH_SYNCH_SEQ_TS0` is unlikely to be true, given that no other synch. sequences are defined by 3GPP TS 45.002. Even if this happens for whatever reason (e.g. a bug), assigning `synch_seq` to `RACH_SYNCH_SEQ_TS0` is not needed, as `synch_seq` is never read after the switch statement. The logging message is not useful either, since we already print the synch. seq. above.
bts_shutdown_fsm: fix spurious RAMP_COMPL events in WAIT_TRX_CLOSED
With multiple TRXes ramping down in lockstep, both their final ramp-timer callbacks fire back-to-back in the same event loop pass, setting p_total_cur_mdBm to the target value for both before any async hardware acknowledgement arrives. When the first SETPOWER ack returns and fires ramp_down_compl_cb() for TRX0, the remaining-TRX check in st_wait_ramp_down_compl() inspects p_total_cur_mdBm for TRX1 and finds it already at the target - concluding that all TRXes are done. The FSM then transitions to WAIT_TRX_CLOSED, and the second ack (for TRX1) fires ramp_down_compl_cb() into the wrong state, producing:
BTS_SHUTDOWN(...){WAIT_TRX_CLOSED}: Event BTS_SHUTDOWN_EV_TRX_RAMP_COMPL not permitted
The root cause is that p_total_cur_mdBm is a *requested* value set in the timer callback, not a confirmed one. The hardware confirmation arrives asynchronously via power_trx_change_compl() -> power_ramp_do_step(), which is also where compl_cb() is invoked.
Fix by adding a 'complete' flag to trx_power_params.ramp that is:
* cleared when _power_ramp_start() begins a new ramp, and * set just before compl_cb() is called in power_ramp_do_step()
The shutdown FSM remaining-TRX count then checks !ramp.complete instead of comparing p_total_cur_mdBm against the target, correctly reflecting which TRXes have actually received hardware confirmation of ramp completion.
