Message ID | 1027342a-97dd-83cd-f363-43cff49967e2@lwfinger.net (mailing list archive) |
---|---|
State | Not Applicable |
Delegated to: | Johannes Berg |
Headers | show |
Series | rtw88: Problem with sdio.c | expand |
Dne sreda, 24. maj 2023 ob 20:51:53 CEST je Larry Finger napisal(a): > Martin, > > When I applied your latest changes to my rtw88 repo, the driver for 8723ds > broke. The dmesg log first showed things like: > > [ 3.603884] rtw_8723ds mmc1:0001:1: Firmware version 48.0.0, H2C version 0 > [ 3.615430] sunxi-mmc 4021000.mmc: unaligned scatterlist: os e80 length 2 > [ 3.622248] sunxi-mmc 4021000.mmc: map DMA failed > [ 3.626974] rtw_8723ds mmc1:0001:1: sdio read16 failed (0x10040): -22 > [ 3.633435] sunxi-mmc 4021000.mmc: unaligned scatterlist: os e80 length 2 > [ 3.640236] sunxi-mmc 4021000.mmc: map DMA failed > > There were similar messages for write16 operations. This was fixed in: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb0ddaaa5db09d7d216fcbf0e68779be223a1128 Best regards, Jernej > > I was able to "fix" the problem by turning off rea16/write16 operations for the > RTW8723DS with the following patch that uses the rtw_chip_wcpu_11n() function: > > diff --git a/sdio.c b/sdio.c > index 1647cdc..2051c30 100644 > --- a/sdio.c > +++ b/sdio.c > @@ -87,7 +87,7 @@ static void rtw_sdio_writew(struct rtw_dev *rtwdev, u16 val, > u32 addr, > u8 buf[2]; > int i; > > - if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2)) { > + if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2) && !rtw_chip_wcpu_11n(rtwdev)) { > sdio_writew(rtwsdio->sdio_func, val, addr, err_ret); > return; > } > @@ -125,7 +125,7 @@ static u16 rtw_sdio_readw(struct rtw_dev *rtwdev, u32 addr, > int *err_ret) > u8 buf[2]; > int i; > > - if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2)) > + if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2) && !rtw_chip_wcpu_11n(rtwdev)) > return sdio_readw(rtwsdio->sdio_func, addr, err_ret); > > for (i = 0; i < 2; i++) { > > This leaves 16-bit reads and write enabled for the other chips. Alternatives > would be to detect when this particular SDIO controller is in use, or last of > all, add a module parameter. > > Larry >
On 5/24/23 14:18, Jernej Škrabec wrote: > > This was fixed in: > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb0ddaaa5db09d7d216fcbf0e68779be223a1128 That fix is in the kernel mainline source, but not in wireless-next, where I got my source. I hope it gets resolved correctly. Larry
Larry Finger <Larry.Finger@lwfinger.net> writes: > On 5/24/23 14:18, Jernej Škrabec wrote: >> >> This was fixed in: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cb0ddaaa5db09d7d216fcbf0e68779be223a1128 > > That fix is in the kernel mainline source, but not in wireless-next, > where I got my source. I hope it gets resolved correctly. The fix should come to wireless-next after the next (no pun intended) net-next pull request. One way to avoid this problem of not having all the fixes is to use the wireless-testing tree: https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-testing.git/ In that tree Bob Copeland periodically pulls both wireless and wireless-next to the latest -rc releases and that way you can easily get all the latest wireless code from one tree. For example I use wireless-testing as the baseline for all my ath1*k drivers testing. But do note that the tree is rebased so the history is not stable.
diff --git a/sdio.c b/sdio.c index 1647cdc..2051c30 100644 --- a/sdio.c +++ b/sdio.c @@ -87,7 +87,7 @@ static void rtw_sdio_writew(struct rtw_dev *rtwdev, u16 val, u32 addr, u8 buf[2]; int i; - if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2)) { + if (rtw_sdio_use_memcpy_io(rtwdev, addr, 2) && !rtw_chip_wcpu_11n(rtwdev)) { sdio_writew(rtwsdio->sdio_func, val, addr, err_ret); return;