4.19.193 kernel for Android, any success?

[videostormdev]

I have built this driver for kernel version 4.19.193 for Android 11 (rockchip sdk).

Builds ok and I can modprobe the drivers to insert them. However, they aren't functional.

Using both 8821cs and 8822bu adapter (separately).

They will create a wlan0 interface which can be reported by iw. They just can't scan or connect to any networks.

The logs for the USB device dont' show any errors. The SDIO device sometimes shows a single sdio read32 and write8 failure.

Any ideas? Has anyone had success with this driver in Android?

[lwfinger]

I am concerned that your patches needed to get the drivers to build with 4.19 may have crippled the drivers. Could you please provide those patches for review?

[videostormdev]

Thanks for the reply!

It was simple, I removed three static_assert() statements as they didn't resolve. I reasoned they were compile time check only.

rtw8821c.c://static_assert(ARRAY_SIZE(rf_para_tx_8821c) == ARRAY_SIZE(rf_para_rx_8821c));
rtw8822b.c://static_assert(ARRAY_SIZE(rf_para_tx_8822b) == ARRAY_SIZE(rf_para_rx_8822b));
tx.c://static_assert(ARRAY_SIZE(ac_to_hwq) == IEEE80211_NUM_ACS);

I also had to add the module_sdio_driver() define to the linux kernel sdio_func.h header file. I reasoned this is a macro definition which will be handled by the compiler, so just modifying the header is ok

<
< /**
< * module_sdio_driver() - Helper macro for registering a SDIO driver
< * @__sdio_driver: sdio_driver struct
< *
< * Helper macro for SDIO drivers which do not do anything special in module
< * init/exit. This eliminates a lot of boilerplate. Each module may only
< * use this macro once, and calling it replaces module_init() and module_exit()
< */
< #define module_sdio_driver(__sdio_driver)
< module_driver(__sdio_driver, sdio_register_driver,
< sdio_unregister_driver)

[RENANZG]

@lwfinger

May have useful information:
https://github.com/morrownr/USB-WiFi

In Readme could have a section of "useful links".

Thanks

[masbug]

I have the same problem as @videostormdev. iw wlan0 scan hangs but newer version outputs an error. This is the debug output using iw 5.19:

# iw --debug wlan0 scan
-- Debug: Sent Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 44
    .type = 18 <0x12>
    .flags = 5 <REQUEST,ACK>
    .seq = 946693883
    .port = -817882502
  [GENERIC NETLINK HEADER] 4 octets
    .cmd = 33
    .version = 0
    .unused = 0
  [PAYLOAD] 24 octets
    08 00 03 00 07 00 00 00 08 00 2d 00 04 00 01 00 ..........-.....
    08 00 9e 00 00 40 00 00                         .....@..
---------------------------  END NETLINK MESSAGE   ---------------------------
-- Debug: Received Message:
--------------------------   BEGIN NETLINK MESSAGE ---------------------------
  [NETLINK HEADER] 16 octets
    .nlmsg_len = 64
    .type = 2 <ERROR>
    .flags = 0 <>
    .seq = 946693883
    .port = -817882502
  [ERRORMSG] 20 octets
    .error = 1 "Unknown error -1"
  [ORIGINAL MESSAGE] 16 octets
    .nlmsg_len = 16
    .type = 18 <0x12>
    .flags = 5 <REQUEST,ACK>
    .seq = 946693883
    .port = -817882502
---------------------------  END NETLINK MESSAGE   ---------------------------
ERROR: received positive netlink error code 1
command failed: Protocol error (-71)

What could be the issue? What to look at? dmesg is otherwise free of any errors...

[masbug]

I found the cause of "netlink error code 1". 1 is returned from rtw_ops_hw_scan in mac80211.c:

static int rtw_ops_hw_scan(struct ieee80211_hw *hw, struct ieee80211_vif *vif,
			   struct ieee80211_scan_request *req)
{
	struct rtw_dev *rtwdev = hw->priv;
	int ret;

	if (!rtw_fw_feature_check(&rtwdev->fw, FW_FEATURE_SCAN_OFFLOAD))
		return 1; // <- here

	if (test_bit(RTW_FLAG_SCANNING, rtwdev->flags))
		return -EBUSY;
        ...

...because rtwdev->fw.feature == 0. The reason for this is use of legacy firmware:

static void update_firmware_info(struct rtw_dev *rtwdev,
				 struct rtw_fw_state *fw)
{
	if (rtw_chip_wcpu_11n(rtwdev))
		__update_firmware_info_legacy(rtwdev, fw); // doesn't set feature
	else
		__update_firmware_info(rtwdev, fw); // sets feature
}

So in my case (rtl8723du) I have to comment out these lines in mac80211.c:

	.reconfig_complete	= rtw_reconfig_complete,
	//.hw_scan		= rtw_ops_hw_scan,
	//.cancel_hw_scan		= rtw_ops_cancel_hw_scan,
	.sta_rc_update		= rtw_ops_sta_rc_update,

Scan then works as expected.

[brianwitte]

@videostormdev, @RENANZG, @masbug -- Thank you for following up on this.

I am @lwfinger's new co-maintainer and I am still getting up to speed. I started a new job and had little time to get solid time in these open issues.

I will be reproducing this and reporting back as soon as I can.

Again, thank you for diving into this and providing context around the issue and possible fixes.