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?
