aboutsummaryrefslogtreecommitdiff
path: root/drivers/usb/cdns3/cdns3-debug.h
diff options
context:
space:
mode:
authorSascha Hauer <[email protected]>2023-04-17 16:03:56 +0200
committerKalle Valo <[email protected]>2023-04-20 15:34:38 +0300
commit14705f969d98187a1cc2682e0c9bd2e230b8098f (patch)
treecbae647558fcda9f9aae635a2509c0419ee21eda /drivers/usb/cdns3/cdns3-debug.h
parenta6f187f92bcc2b17821538b4a11d61764e68b091 (diff)
wifi: rtw88: rtw8821c: Fix rfe_option field width
On my RTW8821CU chipset rfe_option reads as 0x22. Looking at the vendor driver suggests that the field width of rfe_option is 5 bit, so rfe_option should be masked with 0x1f. Without this the rfe_option comparisons with 2 further down the driver evaluate as false when they should really evaluate as true. The effect is that 2G channels do not work. rfe_option is also used as an array index into rtw8821c_rfe_defs[]. rtw8821c_rfe_defs[34] (0x22) was added as part of adding USB support, likely because rfe_option reads as 0x22. As this now becomes 0x2, rtw8821c_rfe_defs[34] is no longer used and can be removed. Note that this might not be the whole truth. In the vendor driver there are indeed places where the unmasked rfe_option value is used. However, the driver has several places where rfe_option is tested with the pattern if (rfe_option == 2 || rfe_option == 0x22) or if (rfe_option == 4 || rfe_option == 0x24), so that rfe_option BIT(5) has no influence on the code path taken. We therefore mask BIT(5) out from rfe_option entirely until this assumption is proved wrong by some chip variant we do not know yet. Signed-off-by: Sascha Hauer <[email protected]> Tested-by: Alexandru gagniuc <[email protected]> Tested-by: Larry Finger <[email protected]> Tested-by: ValdikSS <[email protected]> Cc: [email protected] Reviewed-by: Ping-Ke Shih <[email protected]> Signed-off-by: Kalle Valo <[email protected]> Link: https://lore.kernel.org/r/[email protected]
Diffstat (limited to 'drivers/usb/cdns3/cdns3-debug.h')
0 files changed, 0 insertions, 0 deletions