fixeria has submitted this change. ( https://gerrit.osmocom.org/c/osmo-bts/+/27558 )
Change subject: trx_sched_ul_burst(): get rid of the 'switch' statement ......................................................................
trx_sched_ul_burst(): get rid of the 'switch' statement
Both TRXC_RACH and TRXC_PTCCH are handled in the rx_rach_fn(), so we can eliminate the need of having a 'switch' statement in the general (perfrmance critical) code path.
Change-Id: I66d8785a63215af37a77e258039549e4e6292e49 --- M src/common/scheduler.c M src/osmo-bts-trx/sched_lchan_rach.c 2 files changed, 7 insertions(+), 10 deletions(-)
Approvals: Jenkins Builder: Verified fixeria: Looks good to me, approved osmith: Looks good to me, but someone else must approve laforge: Looks good to me, but someone else must approve
diff --git a/src/common/scheduler.c b/src/common/scheduler.c index b27d7ea..e6a664f 100644 --- a/src/common/scheduler.c +++ b/src/common/scheduler.c @@ -1546,16 +1546,9 @@
/* handle NOPE indications */ if (bi->flags & TRX_BI_F_NOPE_IND) { - switch (bi->chan) { - case TRXC_PTCCH: - case TRXC_RACH: - /* For some logical channel types NOPE.ind is valueless. */ - return 0; - default: - /* NOTE: Uplink burst handler must check bi->burst_len before - * accessing bi->burst to avoid uninitialized memory access. */ - return func(l1ts, bi); - } + /* NOTE: Uplink burst handler must check bi->burst_len before + * accessing bi->burst to avoid uninitialized memory access. */ + return func(l1ts, bi); }
/* decrypt */ diff --git a/src/osmo-bts-trx/sched_lchan_rach.c b/src/osmo-bts-trx/sched_lchan_rach.c index c3abf32..5d9d0b1 100644 --- a/src/osmo-bts-trx/sched_lchan_rach.c +++ b/src/osmo-bts-trx/sched_lchan_rach.c @@ -112,6 +112,10 @@ uint8_t ra; int rc;
+ /* Ignore NOPE indications, they're of no use here */ + if (bi->flags & TRX_BI_F_NOPE_IND) + return 0; + /* TSC (Training Sequence Code) is an optional parameter of the UL burst * indication. We need this information in order to decide whether an * Access Burst is 11-bit encoded or not (see OS#1854). If this information