A MCC (multi-channel concurrency) schedule is like the following.
   |<                mcc interval                 >|
   |<    duration ref     >|<    duration aux     >|
   |< tob ref >|< toa ref >|< tob aux >|< toa aux >|
               V                       V
           tbtt ref                tbtt aux
               |<    beacon offset    >|
Original logic might unexpectedly calculate toa (time offset ahead) of
auxiliary role to be negative even when there is no role timing limit.
If toa-aux is negative, TBTT-aux would in logic fall into duration-ref.
Then, if auxiliary role is GO unfortunately, it cannot guarantee that
beacons will TX well. So now, when deciding the lower bound of toa-ref,
take toa-aux into account. Make toa-aux at least be zero in normal cases.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20250422014620.18421-13-pkshih@realtek.com
 
        struct rtw89_mcc_role *ref = &mcc->role_ref;
        struct rtw89_mcc_role *aux = &mcc->role_aux;
        struct rtw89_mcc_config *config = &mcc->config;
+       u16 mcc_intvl = config->mcc_interval;
        u16 bcn_ofst = config->beacon_offset;
        u16 bt_dur_in_mid = 0;
        u16 max_bcn_ofst;
 
        res = bcn_ofst - bt_dur_in_mid;
        upper = min_t(s16, ref->duration, res);
-       lower = 0;
+       lower = max_t(s16, 0, ref->duration - (mcc_intvl - bcn_ofst));
 
        if (ref->limit.enable) {
                upper = min_t(s16, upper, ref->limit.max_toa);