On Wed, Oct 2, 2019 at 11:04 PM Jes Sorensen <jes.sorensen@xxxxxxxxx> wrote:
Honestly, I also thought of that but there's no meaningful description for these
In general I think it looks good! One nit below:
Sorry I have been traveling for the last three weeks, so just catching up.
+void rtl8723bu_set_coex_with_type(struct rtl8xxxu_priv *priv, u8 type)
+{
+ switch (type) {
+ case 0:
+ rtl8xxxu_write32(priv, REG_BT_COEX_TABLE1, 0x55555555);
+ rtl8xxxu_write32(priv, REG_BT_COEX_TABLE2, 0x55555555);
+ rtl8xxxu_write32(priv, REG_BT_COEX_TABLE3, 0x00ffffff);
+ rtl8xxxu_write8(priv, REG_BT_COEX_TABLE4, 0x03);
+ break;
+ case 1:
+ case 3:
The one item here, I would prefer introducing some defined types to
avoid the hard coded type numbers. It's much easier to read and debug
when named.
numbers in the vendor driver. Even based on where they're invoked, I can merely
give a rough definition on 0. So I left it as it is for the covenience
if I have to do
cross-comparison with vendor driver in the future for some possible
unknown bugs.
If you shortened the name of the function to rtl8723bu_set_coex() youI think the rtl8723bu_set_ps_tdma() function would cause the line length problem
won't have problems with line lengths at the calling point.
more than rtl8723bu_set_coex_with_type() at the calling point. But as the same
debug reason as mentioned, I may like to keep it because I don't know how to
categorize the 5 magic parameters. I also reference the latest rtw88
driver code,
it seems no better solution so far. I'll keep watching if there's any
better idea.