ulli-kroll/rtw88-usb

try add support for jaguar-1 devices

Opened this issue · 9 comments

ulli-kroll commented

This driver may support jaguar-1 devices.
i.e
rtl8812
rtl8814
rtl8821

neojou commented

It can support rtl8812, but not rtl8814 and rtl8821 yet, for you information.

ulli-kroll commented

Sorry for delay
I've been busy for the past few months

I know
rtw88-usb i.e. has fixed/max number of RF ( 2 ) paths, not suitable for 8814
and I know 8812/8821 can use the same driver, but are in some places different.

kimocoder commented

This issue report.. just love it.
If we could move the rtl8812au drivers in there, moving it from the nl80211/cfg80211 and into this would be a dream

dsx724 commented

@neojou @ulli-kroll We have a few projects around 8723DU, 8821CU, and 8822CS and I was wondering if there's some timeline or some way we can externally contribute to this effort? We cannot use kernel modules so that is why this is so important for us.

ulli-kroll commented

@ALL
you can play around if you like ;-)

Last time @neojou refactored the code, he splits the pci from the usb part.
This is a result from upstream driver in vanilla linux.

The only this he missing are the usb id's which are in the wild.
I will update them, also I do a check for rtw8723du.

For 8822cs
This is SPI
First I don't have any hardware to test
Second, I don't have any GPL sources
Third and most important:
I have currently NO timeline nor spare time for this
This is a complete new interface type (for me)
... and currently my head is already spinning from
the rtw8812au/rtl8814au/rtl8821au devices

ulli-kroll commented

@neojou

Some question for the experts ;-)
I didn't checked this with newer code in rtw8822bu/rtw88cu devices
because some header files a roaming around not belonging to the above devices.

rtl8814au has, as we all know up to four RX/TX paths
the gpl sources I found on Edimax site using this

typedef struct _Phy_Status_Rpt_8812 {
/*	DWORD 3*/
	s1Byte			rxevm[2];	         /*DW3 byte 1 DW3 byte 2	stream 1 and stream 2 RX EVM*/
	s1Byte			rxsnr[2];	         /*DW3 byte 3 DW4 byte 0	path-A and path-B RX SNR*/
};

which is in my opinion wrong
this is from rtw8822bu code

struct _phy_status_rpt_jaguar2_type1 {
	/* DW4 */
	s8		rxevm[4];			/* s(8,1) */

	/* DW5 */
	s8		cfo_tail[4];			/* s(8,7) */

	/* DW6 */
	s8		rxsnr[4];			/* s(8,1) */
};

The endianness is some other part of the story ;-)

ulli-kroll commented

Answer not (more) needed ;-)
Found some hint in phy_SetBBSwingByBand_8814A()
so rtl8814/rtw8814a some kind of jaguar2 hmmm.

  • 👍1
CGarces commented

Answer not (more) needed ;-) Found some hint in phy_SetBBSwingByBand_8814A() so rtl8814/rtw8814a some kind of jaguar2 hmmm.

Based on the RTL propietary driver, 8814A is a JAGUAR2 driver just look at

https://github.com/jwrdegoede/rtl8189ES_linux/blob/master/include/hal_intf.h#L456-L457

#define IS_HARDWARE_TYPE_JAGUAR2(_Adapter)		\
(IS_HARDWARE_TYPE_8814A(_Adapter) || IS_HARDWARE_TYPE_8821B(_Adapter) || IS_HARDWARE_TYPE_8822B(_Adapter))
ulli-kroll commented

There is (maybe) also some hardware bug in handling usb control messages with
rtl8821b/rtl8822b/rtl8822c
verified in recent rtl8814a/rtl8822b sources ...
IIRC this is in the RF register range.
but they introduced some other bug. they didn't understand ranges in C
must verify this finding and dump this into code here