> -----Original Message-----
> From: Martin Kaistra <martin.kaistra@xxxxxxxxxxxxx>
> Sent: Wednesday, April 5, 2023 11:31 PM
> To: Bitterblue Smith <rtl8821cerfe2@xxxxxxxxx>
> Cc: Jes Sorensen <Jes.Sorensen@xxxxxxxxx>; Kalle Valo <kvalo@xxxxxxxxxx>; Ping-Ke Shih
> <pkshih@xxxxxxxxxxx>; Sebastian Andrzej Siewior <bigeasy@xxxxxxxxxxxxx>; linux-wireless@xxxxxxxxxxxxxxx
> Subject: Re: [RFC PATCH 00/14] wifi: rtl8xxxu: Add AP mode support for 8188f
>
> Am 23.03.23 um 18:12 schrieb Bitterblue Smith:
> > On 22/03/2023 19:18, Martin Kaistra wrote:
> >> This series intends to bring AP mode support to the rtl8xxxu driver,
> >> more specifically for the 8188f, because this is the HW I have.
> >> The work is based on the vendor driver as I do not have access to
> >> datasheets.
> >>
> >> This is an RFC, so that there can be a discussion first before
> >> potentially implementing support for the other chips in this driver, if
> >> required.
> >>
> >
> > Hi!
> >
> > I ran into some problems while testing this.
> >
> > First, a null pointer dereference in rtl8xxxu_config_filter() when
> > turning on the AP. priv->vif was NULL:
> >
> > if (priv->vif->type != NL80211_IFTYPE_AP) {
> >
> > I changed it like this:
> >
> > if (priv->vif && priv->vif->type != NL80211_IFTYPE_AP) {
> >
> > Then I was able to turn on the AP and connect my phone to it. However,
> > the system froze after a few seconds. I had `journalctl --follow`
> > running. The last thing printed before the system froze was the DHCP
> > stuff (discover, offer, request, ack). The phone said it was connected,
> > but speedtest.net didn't have time to load before the freeze.
>
> Hi
>
> I could reproduce a frozen system with my hostapd setup, though it
> doesn't happen reliably and I don't have an error message when it happens.
>
> What I can see on the other hand, are WARNING messages which happen
> sometimes in include/net/mac80211.h:2936 (ieee80211_get_tx_rate()).
> This might be unrelated, I am not sure.
>
> Is this function even supposed to work in combination with
> HAS_RATE_CONTROL set?
I'm not familiar with rate control of mac80211, so I didn't have comment
about rate control and HAS_RATE_CONTROL before.
Simply checking rate_control_get_rate() that is to fill info->control.rates[],
but it doesn't do it if HAS_RATE_CONTROL is set:
if (ieee80211_hw_check(&sdata->local->hw, HAS_RATE_CONTROL))
return;
So, I think it will not work with HAS_RATE_CONTROL set. Fortunately,
rtl8xxxu only works on 2 GHz band, and only management frames use
info->control.rates[] to decide TX rate, so always TX management frames
with 1M CCK rate (hw_rate = 0) is fine.
> Also, why are we putting rate into txdesc for all
> packets (ie. also when USE_DRIVER_RATE is not set) when the firmware
> sets the rate based on the rate_mask?
Conceptually, if USE_DRIVER_RATE is set, rate info of txdesc is adopted.
Otherwise, rate register controlled by firmware is adopted. That means
if USE_DRIVER_RATE isn't set, rate info of txdesc is ignored.
rtl8xxxu_update_rate_mask() is to tell firmware the all supported rate mask,
and firmware choose proper TX and retry rate, and set to register.
Ping-Ke
