On Wed, Jan 17, 2024 at 12:35:42AM +0000, Ping-Ke Shih wrote: > + Sascha for question 3) > > (no other comments for now) > > > -----Original Message----- > > From: Martin Blumenstingl <martin.blumenstingl@xxxxxxxxxxxxxx> > > Sent: Wednesday, January 17, 2024 6:07 AM > > To: Ping-Ke Shih <pkshih@xxxxxxxxxxx>; Viacheslav <adeep@xxxxxxxxx> > > Cc: linux-wireless@xxxxxxxxxxxxxxx; Jernej Škrabec <jernej.skrabec@xxxxxxxxx> > > Subject: Re: rtw88: rtl8822cs AP mode not working > > > > Hi Ping-Ke and Viacheslav, > > > > On Mon, Jan 15, 2024 at 3:17 AM Ping-Ke Shih <pkshih@xxxxxxxxxxx> wrote: > > [...] > > > > > I don't have this kind of wifi cards, could you help to check if AP mode > > > > > works in your side? > > > > I'll check that in the next few days. > > AP mode is also not working for me, I get the same problem as > > Viacheslav reported. > > > > > > Also I'm wondering where code enables beacons (is it > > > > rtw_core_enable_beacon() or is there another relevant function?). > > > > Knowing that would be helpful to analyze this further. > > > > > > The main function to get and set beacon template to firmware is > > > rtw_fw_download_rsvd_page(). The basic concept is to put beacon frame via > > > qsel=BCN to a special TX FIFO area called "reserve page", and then > > > hardware/firmware will send beacon in interval of 100ms. > > Thanks for the explanation - that helped me find a better starting point! > > > > I didn't have much time in the past few days, but I have some findings > > and questions: > > 1) I found the following comment/code in the downstream driver [0]: > > /* > > * Disable Hw protection for a time which revserd for Hw sending beacon. > > * Fix download reserved page packet fail that access collision with > > the protection time. > > */ > > val8 = rtw_read8(adapter, REG_BCN_CTRL_8822C); > > restore[1] = val8; > > val8 &= ~BIT_EN_BCN_FUNCTION_8822C; > > val8 |= BIT_DIS_TSF_UDT_8822C; > > rtw_write8(adapter, REG_BCN_CTRL_8822C, val8); > > > > This is not part of the upstream rtw88 driver, so I made a patch and > > attached it. > > Unfortunately it doesn't fix the problem. > > > > 2) PCI is the only HCI which does not need the checksum in the > > pkt_Info (USB and SDIO need the checksum). > > The checksum is added by rtw_tx_fill_txdesc_checksum() which is only > > called in usb.c and sdio.c. > > My understanding is that for reserved pages we can have more than one > > pkt_info in the buffer (my starting point for this thought is > > rtw_fill_rsvd_page_desc() from fw.c). > > In usb.c and sdio.c we're only calculating the checksum for the very > > first pkt_info, not for any subsequent ones (I didn't even know that > > it's possible to have more than one pkt_Info outside of RX and TX > > aggregation). > > However, it seems that the downstream code calculates the TX checksum > > for *all* pkt_info in the buffer, see [1] > > This code is missing from rtw88 at the moment. Since I didn't have > > time I did not try to implement this yet. > > > > 3) Has anybody tried AP mode with rtw88 on a (supported) USB chipset? > > If my thought (from #2) is correct then AP mode would show the same > > problems there. I haven't tried AP mode with the rtw88 driver. Shame on me, but I didn't want to open that can of worms at that time. Regards, Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
