Re: [RFC] Adding RTL8189ES SDIO support to rtw88

[Luka Gejak <luka.gejak@linux.dev>]

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.

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.

[ ... ]

> 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/

Best regards,
Luka Gejak