[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <01c7887bce5a4c3fade980464c155b27@realtek.com>
Date: Mon, 6 Jan 2025 00:31:41 +0000
From: Ping-Ke Shih <pkshih@...ltek.com>
To: Vasily Khoruzhick <anarsoul@...il.com>
CC: Kalle Valo <kvalo@...nel.org>, Fiona Klute <fiona.klute@....de>,
Bitterblue Smith <rtl8821cerfe2@...il.com>,
"linux-wireless@...r.kernel.org"
<linux-wireless@...r.kernel.org>,
"linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org"
<stable@...r.kernel.org>
Subject: RE: [PATCH] wifi: rtw88: 8703b: Fix RX/TX issues
Vasily Khoruzhick <anarsoul@...il.com> wrote:
>
> On Fri, Jan 3, 2025 at 1:13 AM Ping-Ke Shih <pkshih@...ltek.com> wrote:
> >
> > Vasily Khoruzhick <anarsoul@...il.com> wrote:
> > > Fix 3 typos in 8703b driver. 2 typos in calibration routines are not
> > > fatal and do not seem to have any impact, just fix them to match vendor
> > > driver.
> >
> > Just curious how you can find these typos?
>
> I added traces to sdio_* functions in linux (see [1]), so I can
> capture register access traces. I captured the traces from both rtw88
> and the vendor driver and wrote a simple parser that decodes the
> traces, see [2]. I guess it would be easier with an USB device, where
> we have usbmon. I really wish there was something like usbmon for
> SDIO.
>
> I also added traces for C2H messages to both drivers, since they go
> through sdio_memcpy_fromio() that I don't trace.
>
> Once I had the traces, I manually compared them (along with register
> dumps, rtw88 has it in debugfs, vendor driver in proc) trying to find
> the writes that do not match. Unfortunately, rtw88 and vendor driver
> flows are different enough, so I couldn't come up with a way to
> compare it automatically
>
> Adrian and Bitterblue supported me on #linux-wireless on IRC, and one
> of the typos in IQK calibration was actually found by Bitterblue.
>
> It took ~5 evenings and 1 weekend to get to REG_OFDM0_TX_PSD_NOISE
> (0xce4). Once I changed it from 0 to 0x10000000 via reg_write over
> debugfs, it magically fixed the issue. I changed it back to 0 to
> confirm that it breaks it again, and then back to 0x10000000 to see it
> working. Then it was just a matter of grep to find where this register
> is written in rtw88 and compare the corresponding code to the vendor
> driver.
>
> [1] https://github.com/anarsoul/rtl8723cs-re/blob/master/sdio_traces.patch
> [2] https://github.com/anarsoul/rtl8723cs-re
>
Cool. I did similar works when we rewrite rtw89 from vendor drivers.
Sometimes we also found flaws of vendor driver by their difference.
Ping-Ke
Powered by blists - more mailing lists