aboutsummaryrefslogtreecommitdiffstats
path: root/src/osmo-bsc/gsm_data.c
diff options
context:
space:
mode:
authorNeels Hofmeyr <neels@hofmeyr.de>2021-04-27 23:17:14 +0000
committerNeels Hofmeyr <neels@hofmeyr.de>2021-05-27 17:06:21 +0200
commit0951d756655d7c637efd450d125f7a9ae38098eb (patch)
tree9fbb7624307603e47d0856c8a0594a2981ac5dff /src/osmo-bsc/gsm_data.c
parentd587574d7b9613f2cc733aa4a82d5a9c6f068193 (diff)
make sure channel mode and s15_s0 are updated only after an ACK
I noticed during testing that an lchan used as TCH/F in fact still had its channel mode set to Signalling -- because on Assignment, the Speech mode used to be placed in the *previous* lchan and the new lchan was never updated after the Activ ACK. This is unbearable confusion which I complained about numerous times, so far mostly for cosmetic reasons. But implementing re-assignment properly actually requires this to be cleaned up. Keep all volatile chan mode settings in lchan->activate.* or lchan->modify.*, and only update lchan->* members when an ACK has been received for those settings. So a failed request keeps a sane state. Make sure that those settings are in fact updated in the proper lchan, upon an ACK, so that subsequent re-assignment or mode-modify know the accurate lchan state. Related are upcoming patches that sort out the AMR multirate configuration in a similar fashion, see Iebac2dc26412d877e5364f90d6f2ed7a7952351e Ia7519d2fa9e7f0b61b222d27d077bde4660c40b9 Ie57f9d0e3912632903d9740291225bfd1634ed47. Related: SYS#5315 OS#4940 OS#3787 OS#3833 Change-Id: Ie0da36124d73efc28a8809b63d7c96e2167fc412
Diffstat (limited to 'src/osmo-bsc/gsm_data.c')
-rw-r--r--src/osmo-bsc/gsm_data.c16
1 files changed, 16 insertions, 0 deletions
diff --git a/src/osmo-bsc/gsm_data.c b/src/osmo-bsc/gsm_data.c
index 781db7c62..a37106491 100644
--- a/src/osmo-bsc/gsm_data.c
+++ b/src/osmo-bsc/gsm_data.c
@@ -685,6 +685,22 @@ enum gsm_phys_chan_config gsm_pchan_by_lchan_type(enum gsm_chan_t type)
}
}
+enum channel_rate chan_t_to_chan_rate(enum gsm_chan_t chan_t)
+{
+ switch (chan_t) {
+ case GSM_LCHAN_SDCCH:
+ return CH_RATE_SDCCH;
+ case GSM_LCHAN_TCH_F:
+ return CH_RATE_FULL;
+ case GSM_LCHAN_TCH_H:
+ return CH_RATE_HALF;
+ default:
+ /* For other channel types, the channel_rate value is never used. It is fine to return an invalid value,
+ * and callers don't actually need to check for this. */
+ return -1;
+ }
+}
+
/* Can the timeslot in principle be used as this PCHAN kind? */
bool ts_is_capable_of_pchan(struct gsm_bts_trx_ts *ts, enum gsm_phys_chan_config pchan)
{