RE: [RFC] Adding RTL8189ES SDIO support to rtw88

[Ping-Ke Shih <pkshih@realtek.com>]

Luka Gejak <luka.gejak@linux.dev> wrote:
> Hi Igor,
> 
> Thanks for asking before sending it. Ping-Ke has the
> final word on this, so this is only my view after adding RTL8723BS to the
> rtw88.
> 
> On November 10, 2026 5:50:38 AM GMT+01:00, igor@listopad.email wrote:
> 
> > Would support for RTL8189ES SDIO devices, based on the RTL8188E T-series
> > (SDIO ID 024c:8179), be welcome in rtw88?
> 
> I think so. As far as I can see nothing in the kernel binds this SDIO ID
> today. rtlwifi has RTL8188EE on PCIe and rtl8xxxu has RTL8188EU on USB,
> while rtw88 already has the SDIO code and other 8051 based 802.11n chips
> like RTL8703B and RTL8723B.

Maybe one day people can move RTL8188EE to rtw88 as well. For now,
rtw88 is only one driver supporting Realtek WiFi SDIO, so let's add
RTL8189ES to rtw88. 

> 
> On my RTL8723BS series Ping-Ke said it isn't so good to maintain three
> interfaces in the tree drivers, but he kept the existing ones and took the
> new one. So I would expect the same split to be acceptable here.
> 
> Refusing cut I seems fine too. rtl8xxxu does the same for RTL8188EU.
> 
> [ ... ]
> 
> > The implementation adds chip operations, register tables, firmware,
> > and an SDIO binding.
> 
> The firmware in the PR is byte for byte the same as
> rtlwifi/rtl8188eufw.bin, which is already in the firmware repository and
> which rtl8xxxu uses. So I don't think you need a new blob. You could
> request that name, or add a Link: in WHENCE if Ping-Ke prefers an rtw88
> path.

I prefer a Link. One day rtw88 can support RTL8188EE, and remove RTL8188EE
from rtlwifi. It'd be easier to move firmware from rtlwifi/ to rtw88/

> 
> [ ... ]
> 
> > Would this be an acceptable direction for rtw88? Are there architectural
> > concerns or requirements that should be addressed before submitting
> > the series for review?
> 
> From my quick skim of the PR, I think the direction is fine. What I would
> worry about is how much it changes the shared code. It needs an additional
> 20 callbacks in rtw_chip_ops and more than 20 checks for this chip in the
> core and SDIO code. On my series Ping-Ke asked why the existing logic
> didn't work for special cases like these, so I would expect each one to
> need a reason.
> 
> A few examples:
> 
> rtw8188e.c casts rtwdev->priv to struct rtw_sdio, and nothing outside
> sdio.c uses that struct today. Maybe those parts can become hci ops.
> 
> rtw_sdio_tx_handler() reads host->sdio_irq_pending, which as far as I can
> see only the mmc core uses today. TX keeping the IRQ worker away from the
> host also doesn't sound specific to this chip, so I think that wants a
> fix in the common SDIO TX path.
> 
> rtw8188e_efuse_grant() and rtw8188e_false_alarm_statistics() look the same
> as the rtw8723x.c helpers that RTL8723B uses. Maybe those can be shared
> instead of copied.
> 
> A more thorough review will follow once the series is posted.
> 
> For the actual series, please base it on rtw-next instead of the lwfinger
> tree. Several of the core files don't apply there, and the
> LINUX_VERSION_CODE checks have to go. It also needs the Kconfig and
> Makefile entries, the device ID in sdio_ids.h, and the fixes from your
> later commits squashed into the patches they fix. The sign off should use
> a real address instead of the GitHub noreply one.
> 
> You can also take a look at how the RTL8723B series went upstream for
> reference, from the RFC to the version that was applied:
> 
> https://lore.kernel.org/linux-wireless/cover.1784047561.git.luka.gejak@linux.dev/
> https://lore.kernel.org/linux-wireless/20261006130701.120460-1-luka.gejak@linux.dev/

Agree. Luka, Thanks for sharing these experiences.