try add support for jaguar-1 devices

[ulli-kroll]

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

[neojou]

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

[ulli-kroll]

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]

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]

@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]

@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]

@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]

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

[CGarces]

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]

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