On 31/07/2024 03:47, Ping-Ke Shih wrote: > Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote: >> On 30/07/2024 09:33, Ping-Ke Shih wrote: >>> Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx> wrote: >>>> >>>> In AP mode, the firmware stops transmitting beacons if it receives >>>> H2C_CMD_RA_INFO for macid 0. >>>> >>>> Leave macid 0 unused in AP mode. Macid 1 is already reserved for >>>> broadcast/multicast. Assign macid 2 to the first connected client. >>> >>> Seemingly we missed to set mac_id in TX desc for a long time. >>> >>> +#define RTW_TX_DESC_W1_MACID GENMASK(7, 0) >>> #define RTW_TX_DESC_W1_QSEL GENMASK(12, 8) >>> #define RTW_TX_DESC_W1_RATE_ID GENMASK(20, 16) >>> >>> The mac_id should be from rtwvif->mac_id or si->mac_id according to >>> operating mode and role. >>> >>> And I suppose mac_id assignment for AP is mac_id 0 for broadcast/multicast, and >>> other mac_id can be used by connected stations regularly. >>> >> >> What about the concurrent AP + station scenario? Will the >> station vif use the next available macid, whatever that is? >> Just wondering, I don't use concurrent mode. > > My basic idea is to assign mac_id to each vif when adding vif. For station mode, > sta->mac_id will reuse vif->mac_id. For AP mode, I will dynamically allocate an > sta->mac_id to a station, and vif->mac_id is to send broadcast/multicast packets > that are not belong to a sta. For example, > > vif->mac_id sta->mac_id > vif0 (STA mode) 0 0 > vif1 (AP mode) 1 2... > > >> >> Also, do you mean that you will do all this? It's not clear to me. > > I can do it. Or are you interested in this? > No, no, it's all yours. :)
