Changes

osmo-bts-omldummy: properly report NM_ATT_IPACC_SUPP_FEATURES

osmo-bts-omldummy is used as the OML backend in the ttcn3-bsc-test.
The common OML code encodes bts->support.* and trx->support.* fields
verbatim into the IPA Supported Features IE (NM_ATT_IPACC_SUPP_FEATURES)
in Get Attributes Responses.  Since bts_model_init() and
bts_model_trx_init() never initialized these fields, they were reported
as all-zeros to osmo-bsc.

osmo-bsc now inspects the supported channel modes before activating a
channel.  An all-zero chan_modes value (present but no bits set) causes
osmo-bsc to reject every speech mode, breaking all assignment-related
TTCN-3 test cases.

Initialize ciphers, gprs_codings, freq_bands, chan_types and chan_modes
to sensible values, matching what osmo-bts-virtual does, so that
osmo-bts-omldummy reports its capabilities correctly.

Change-Id: I7fe83f78c829c300e70a59509847b815a77974d7
Fixes: 0978d1df ("oml: implement handling of NM_ATT_IPACC_SUPP_FEATURES")
Related: OS#6324

struct trx_power_params: fix inaccurate comment

Change-Id: I1bdb7fab24fee28dbeac0ed05e13f650e08c98e9
Fixes: 4c632421 ("bts_shutdown_fsm: fix spurious RAMP_COMPL events in WAIT_TRX_CLOSED")

osmo-bts-trx: rx_data_fn(): fix copy-paste in comment

Change-Id: Ibf35c468310a690fd873cf968bb2c44b493ca5ea

osmo-bts-trx: rx_rach_fn(): remove redundant fall-back

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.

Change-Id: I4cdc03dc6631ca17d13a3067ad03020e3e97eab1

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.

Change-Id: Ia71393e871187d6b44b7f520eb421bab354aafd1