RE: rtlwifi/rtl8192cu AP mode broken with PS STA

[Pkshih]

> -Original Message-
> From: Larry Finger [mailto:larry.fin...@gmail.com] On Behalf Of Larry Finger
> Sent: Monday, April 19, 2021 9:23 AM
> To: Pkshih; Maciej S. Szmigiero
> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; 
> linux-kernel@vger.kernel.org;
> johan...@sipsolutions.net; kv...@codeaurora.org
> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> 
> On 4/18/21 7:32 PM, Pkshih wrote:
> >
> >> -Original Message-
> >> From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name]
> >> Sent: Sunday, April 18, 2021 2:08 AM
> >> To: Pkshih
> >> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; 
> >> linux-kernel@vger.kernel.org;
> >> johan...@sipsolutions.net; kv...@codeaurora.org; Larry Finger
> >> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> >>
> >> On 08.04.2021 21:04, Maciej S. Szmigiero wrote:
> >>> On 08.04.2021 06:42, Pkshih wrote:
> >>>>> -Original Message-
> >>>>> From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name]
> >>>>> Sent: Thursday, April 08, 2021 4:53 AM
> >>>>> To: Larry Finger; Pkshih
> >>>>> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; 
> >>>>> linux-kernel@vger.kernel.org;
> >>>>> johan...@sipsolutions.net; kv...@codeaurora.org
> >>>>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> >>>>>
> >>> (...)
> >>>>>> Maceij,
> >>>>>>
> >>>>>> Does this patch fix the problem?
> >>>>>
> >>>>> The beacon seems to be updating now and STAs no longer get stuck in PS
> >>>>> mode.
> >>>>> Although sometimes (every 2-3 minutes with continuous 1s interval pings)
> >>>>> there is around 5s delay in updating the transmitted beacon - don't know
> >>>>> why, maybe the NIC hardware still has the old version in queue?
> >>>>
> >>>> Since USB device doesn't update every beacon, dtim_count isn't updated 
> >>>> neither.
> >>>> It leads STA doesn't awake properly. Please try to fix dtim_period=1 in
> >>>> hostapd.conf, which tells STA awakes every beacon interval.
> >>>
> >>> The situation is the same with dtim_period=1.
> >>>
> >> (...)
> >>
> >> Ping-Ke,
> >> are you going to submit your set_tim() patch so at least the AP mode is
> >> usable with PS STAs or are you waiting for a solution to the delayed
> >> beacon update issue?
> >>
> >
> > I'm still trying to get a 8192cu, and then I can reproduce the symptom you
> > met. However, I'm busy now; maybe I have free time two weeks later.
> >
> > Do you think I submit the set_tim() patch with your Reported-by and 
> > Tested-by first?
> 
> PK,
> 
> I would say yes. Get the fix in as soon as possible.
> 

I have sent a patch that only 8192cu, which is the only one USB device 
supported by rtlwifi,
schedules a work to update beacon content to wifi card.

https://lore.kernel.org/linux-wireless/20210419065956.6085-1-pks...@realtek.com/T/#u

--
Ping-Ke

RE: rtlwifi/rtl8192cu AP mode broken with PS STA

[Pkshih]

> -Original Message-
> From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name]
> Sent: Sunday, April 18, 2021 2:08 AM
> To: Pkshih
> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; 
> linux-kernel@vger.kernel.org;
> johan...@sipsolutions.net; kv...@codeaurora.org; Larry Finger
> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> 
> On 08.04.2021 21:04, Maciej S. Szmigiero wrote:
> > On 08.04.2021 06:42, Pkshih wrote:
> >>> -Original Message-
> >>> From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name]
> >>> Sent: Thursday, April 08, 2021 4:53 AM
> >>> To: Larry Finger; Pkshih
> >>> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; 
> >>> linux-kernel@vger.kernel.org;
> >>> johan...@sipsolutions.net; kv...@codeaurora.org
> >>> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> >>>
> > (...)
> >>>> Maceij,
> >>>>
> >>>> Does this patch fix the problem?
> >>>
> >>> The beacon seems to be updating now and STAs no longer get stuck in PS
> >>> mode.
> >>> Although sometimes (every 2-3 minutes with continuous 1s interval pings)
> >>> there is around 5s delay in updating the transmitted beacon - don't know
> >>> why, maybe the NIC hardware still has the old version in queue?
> >>
> >> Since USB device doesn't update every beacon, dtim_count isn't updated 
> >> neither.
> >> It leads STA doesn't awake properly. Please try to fix dtim_period=1 in
> >> hostapd.conf, which tells STA awakes every beacon interval.
> >
> > The situation is the same with dtim_period=1.
> >
> (...)
> 
> Ping-Ke,
> are you going to submit your set_tim() patch so at least the AP mode is
> usable with PS STAs or are you waiting for a solution to the delayed
> beacon update issue?
> 

I'm still trying to get a 8192cu, and then I can reproduce the symptom you
met. However, I'm busy now; maybe I have free time two weeks later.

Do you think I submit the set_tim() patch with your Reported-by and Tested-by 
first?

Thanks 
Ping-Ke

RE: rtlwifi/rtl8192cu AP mode broken with PS STA

[Pkshih]

> -Original Message-
> From: Maciej S. Szmigiero [mailto:m...@maciej.szmigiero.name]
> Sent: Thursday, April 08, 2021 4:53 AM
> To: Larry Finger; Pkshih
> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; 
> linux-kernel@vger.kernel.org;
> johan...@sipsolutions.net; kv...@codeaurora.org
> Subject: Re: rtlwifi/rtl8192cu AP mode broken with PS STA
> 
> On 07.04.2021 06:21, Larry Finger wrote:
> > On 4/6/21 9:48 PM, Pkshih wrote:
> >> On Tue, 2021-04-06 at 11:25 -0500, Larry Finger wrote:
> >>> On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
> >>>> On 06.04.2021 12:00, Kalle Valo wrote:
> >>>>> "Maciej S. Szmigiero"  writes:
> >>>>>
> >>>>>> On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using 
> >>>>>>> PS,
> >>>>>>> since the driver does not update its beacon to account for TIM 
> >>>>>>> changes,
> >>>>>>> so a station that is sleeping will never learn that it has packets
> >>>>>>> buffered at the AP.
> >>>>>>>
> >>>>>>> Looking at the code, the rtl8192cu driver implements neither the 
> >>>>>>> set_tim()
> >>>>>>> callback, nor does it explicitly update beacon data periodically, so 
> >>>>>>> it
> >>>>>>> has no way to learn that it had changed.
> >>>>>>>
> >>>>>>> This results in the AP mode being virtually unusable with STAs that do
> >>>>>>> PS and don't allow for it to be disabled (IoT devices, mobile phones,
> >>>>>>> etc.).
> >>>>>>>
> >>>>>>> I think the easiest fix here would be to implement set_tim() for 
> >>>>>>> example
> >>>>>>> the way rt2x00 driver does: queue a work or schedule a tasklet to 
> >>>>>>> update
> >>>>>>> the beacon data on the device.
> >>>>>>
> >>>>>> Are there any plans to fix this?
> >>>>>> The driver is listed as maintained by Ping-Ke.
> >>>>>
> >>>>> Yeah, power save is hard and I'm not surprised that there are drivers
> >>>>> with broken power save mode support. If there's no fix available we
> >>>>> should stop supporting AP mode in the driver.
> >>>>>
> >>>> https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api
> >>>> clearly documents that "For AP mode, it must (...) react to the set_tim()
> >>>> callback or fetch each beacon from mac80211".
> >>>> The driver isn't doing either so no wonder the beacon it is sending
> >>>> isn't getting updated.
> >>>> As I have said above, it seems to me that all that needs to be done here
> >>>> is to queue a work in a set_tim() callback, then call
> >>>> send_beacon_frame() from rtlwifi/core.c from this work.
> >>>> But I don't know the exact device semantics, maybe it needs some other
> >>>> notification that the beacon has changed, too, or even tries to
> >>>> manage the TIM bitmap by itself.
> >>>> It would be a shame to lose the AP mode for such minor thing, though.
> >>>> I would play with this myself, but unfortunately I don't have time
> >>>> to work on this right now.
> >>>> That's where my question to Realtek comes: are there plans to actually
> >>>> fix this?
> >>>
> >>> Yes, I am working on this. My only question is "if you are such an expert 
> >>> on the
> >>> problem, why do you not fix it?"
> >>>
> >>> The example in rx200 is not particularly useful, and I have not found any 
> >>> other
> >>> examples.
> >>>
> >>
> >> Hi Larry,
> >>
> >> I have a draft patch that forks a work to do send_beacon_frame(), whose
> >> behavior like Maciej mentioned.
> 
> That's great, thanks!
> 
> >> I did test on RTL8821AE; it works well. But, it seems already work well 
> >> even
> >> I don't apply this patch, and I'm still digging why.
> 
> It looks like PCI rtlwifi hardware uses a tasklet (spec

Re: rtlwifi/rtl8192cu AP mode broken with PS STA

[Pkshih]

On Tue, 2021-04-06 at 11:25 -0500, Larry Finger wrote:
> On 4/6/21 7:06 AM, Maciej S. Szmigiero wrote:
> > On 06.04.2021 12:00, Kalle Valo wrote:
> >> "Maciej S. Szmigiero"  writes:
> >>
> >>> On 29.03.2021 00:54, Maciej S. Szmigiero wrote:
>  Hi,
> 
>  It looks like rtlwifi/rtl8192cu AP mode is broken when a STA is using PS,
>  since the driver does not update its beacon to account for TIM changes,
>  so a station that is sleeping will never learn that it has packets
>  buffered at the AP.
> 
>  Looking at the code, the rtl8192cu driver implements neither the 
>  set_tim()
>  callback, nor does it explicitly update beacon data periodically, so it
>  has no way to learn that it had changed.
> 
>  This results in the AP mode being virtually unusable with STAs that do
>  PS and don't allow for it to be disabled (IoT devices, mobile phones,
>  etc.).
> 
>  I think the easiest fix here would be to implement set_tim() for example
>  the way rt2x00 driver does: queue a work or schedule a tasklet to update
>  the beacon data on the device.
> >>>
> >>> Are there any plans to fix this?
> >>> The driver is listed as maintained by Ping-Ke.
> >>
> >> Yeah, power save is hard and I'm not surprised that there are drivers
> >> with broken power save mode support. If there's no fix available we
> >> should stop supporting AP mode in the driver.
> >>
> > 
> > https://wireless.wiki.kernel.org/en/developers/documentation/mac80211/api
> > clearly documents that "For AP mode, it must (...) react to the set_tim()
> > callback or fetch each beacon from mac80211".
> > 
> > The driver isn't doing either so no wonder the beacon it is sending
> > isn't getting updated.
> > 
> > As I have said above, it seems to me that all that needs to be done here
> > is to queue a work in a set_tim() callback, then call
> > send_beacon_frame() from rtlwifi/core.c from this work.
> > 
> > But I don't know the exact device semantics, maybe it needs some other
> > notification that the beacon has changed, too, or even tries to
> > manage the TIM bitmap by itself.
> > 
> > It would be a shame to lose the AP mode for such minor thing, though.
> > 
> > I would play with this myself, but unfortunately I don't have time
> > to work on this right now.
> > 
> > That's where my question to Realtek comes: are there plans to actually
> > fix this?
> 
> Yes, I am working on this. My only question is "if you are such an expert on 
> the 
> problem, why do you not fix it?"
> 
> The example in rx200 is not particularly useful, and I have not found any 
> other 
> examples.
> 

Hi Larry,

I have a draft patch that forks a work to do send_beacon_frame(), whose
behavior like Maciej mentioned.
I did test on RTL8821AE; it works well. But, it seems already work well even
I don't apply this patch, and I'm still digging why.

I don't have a rtl8192cu dongle on hand, but I'll try to find one.

---
Ping-Ke

From 44be80232aa49737c035ee4656d20a22f573d33e Mon Sep 17 00:00:00 2001
From: Ping-Ke Shih 
Date: Tue, 6 Apr 2021 19:55:59 +0800
Subject: [PATCH] rtlwifi: implement set_tim by update beacon content

Once beacon content is changed, we update the content to wifi card by
send_beacon_frame().

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/core.c | 30 +
 drivers/net/wireless/realtek/rtlwifi/core.h |  1 +
 drivers/net/wireless/realtek/rtlwifi/pci.c  |  3 +++
 drivers/net/wireless/realtek/rtlwifi/usb.c  |  3 +++
 drivers/net/wireless/realtek/rtlwifi/wifi.h |  1 +
 5 files changed, 38 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c b/drivers/net/wireless/realtek/rtlwifi/core.c
index 965bd9589045..ca47a70d9a86 100644
--- a/drivers/net/wireless/realtek/rtlwifi/core.c
+++ b/drivers/net/wireless/realtek/rtlwifi/core.c
@@ -1018,6 +1018,25 @@ static void send_beacon_frame(struct ieee80211_hw *hw,
 	}
 }
 
+void rtl_update_beacon_work_callback(struct work_struct *work)
+{
+	struct rtl_works *rtlworks =
+	container_of(work, struct rtl_works, update_beacon_work);
+	struct ieee80211_hw *hw = rtlworks->hw;
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+	struct ieee80211_vif *vif = rtlpriv->mac80211.vif;
+
+	if (!vif) {
+		WARN_ONCE(true, "no vif to update beacon\n");
+		return;
+	}
+
+	mutex_lock(>locks.conf_mutex);
+	send_beacon_frame(hw, vif);
+	mutex_unlock(>locks.conf_mutex);
+}
+EXPORT_SYMBOL_GPL(rtl_update_beacon_work_callback);
+
 static void rtl_op_bss_info_changed(struct ieee80211_hw *hw,
 struct ieee80211_vif *vif,
 struct ieee80211_bss_conf *bss_conf,
@@ -1747,6 +1766,16 @@ static void rtl_op_flush(struct ieee80211_hw *hw,
 		rtlpriv->intf_ops->flush(hw, queues, drop);
 }
 
+static int rtl_op_set_tim(struct ieee80211_hw *hw, struct ieee80211_sta *sta,
+			  bool set)
+{
+	struct rtl_priv *rtlpriv = rtl_priv(hw);
+
+	schedule_work(>works.update_beacon_work);
+
+	return 0;
+}
+
 /*	Description:
  *		This routine deals 

Re: [PATCH v2] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop

[Pkshih]

On Tue, 2021-02-23 at 09:08 +0200, Kalle Valo wrote:
> Pkshih  writes:
> 
> >> > --- a/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
> >> > +++ b/drivers/net/wireless/realtek/rtw88/rtw8822ce.c
> >> > @@ -25,7 +25,6 @@ static struct pci_driver rtw_8822ce_driver = {
> >> >  .id_table = rtw_8822ce_id_table,
> >> >  .probe = rtw_pci_probe,
> >> >  .remove = rtw_pci_remove,
> >> > -.driver.pm = _pm_ops,
> >> 
> >> Why just 8822ce? Why not remove rtw_pm_ops entirely if it just creates
> >> problems?
> >
> > I think we can't remove rtw_pm_ops, because wowlan will not work.
> 
> Ah. A comment code in the code stating that would be nice.
> 

I'll do it. 
Thanks.

Re: [PATCH v2] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop

[Pkshih]

On Mon, 2021-02-22 at 20:57 +0800, Hao Chen wrote:
> Because I only have the `HONOR magic 14` laptop with rtl8822ce wifi chip 
> :-(
> 
> I will try to find out why the target platform can't properly resume with
> this declaration.Thanks.
> 
> 在 2021/2/22 下午7:36, Pkshih 写道:
> > On Mon, 2021-02-22 at 12:29 +0200, Kalle Valo wrote:
> >> Hao Chen  writes:
> >>
> >>> The laptop's wifi disconnect after the laptop HONOR MagicBook 14
> >>> sleep to S3/S4 and wake up.
> >>>
> >>> The dmesg of kernel report:
> >>> "[   99.990168] pcieport :00:01.2: can't change power state from D3hot
> >>> to D0 (config space inaccessible)
> >>> [   99.990176] ACPI: EC: interrupt unblocked
> >>> [   99.993334] rtw_pci :01:00.0: can't change power state from D3hot
> >>> to D0 (config space inaccessible)
> >>> ..
> >>> [  102.133500] rtw_pci :01:00.0: mac power on failed
> >>> [  102.133503] rtw_pci :01:00.0: failed to power on mac
> >>> [  102.133505] [ cut here ]
> >>> [  102.133506] Hardware became unavailable upon resume. This could be a
> >>> software issue prior to suspend or a hardware issue.
> >>> [  102.133569] WARNING: CPU: 4 PID: 5612 at net/mac80211/util.c:2232
> >>> ieee80211_reconfig+0x9b/0x1490 [mac80211]
> >>> [  102.133570] Modules linked in: ccm rfcomm uvcvideo videobuf2_vmalloc
> >>> videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc cmac bnep
> >>> btusb btrtl btbcm btintel edac_mce_amd bluetooth kvm_amd ecdh_generic
> >>> ecc kvm nls_iso8859_1 rtwpci rtw88 crct10dif_pclmul crc32_pclmul mac80211
> >>> ghash_clmulni_intel aesni_intel snd_hda_codec_realtek crypto_simd 
> >>> huawei_wmi
> >>> snd_hda_codec_generic cryptd cfg80211 wmi_bmof serio_raw sparse_keymap
> >>> ledtrig_audio sp5100_tco glue_helper joydev snd_hda_codec_hdmi 
> >>> snd_hda_intel
> >>> snd_intel_dspcfg wdat_wdt snd_hda_codec snd_hda_core pcspkr snd_hwdep 
> >>> snd_pcm
> >>> efi_pstore snd_timer libarc4 k10temp snd soundcore snd_pci_acp3x ccp 
> >>> mac_hid
> >>> binfmt_misc ip_tables x_tables autofs4 amdgpu amd_iommu_v2 gpu_sched
> >>> i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt 
> >>> fb_sys_fops
> >>> usbmouse cec nvme hid_generic i2c_piix4 usbhid nvme_core drm wmi video
> >>> [  102.133617] CPU: 4 PID: 5612 Comm: kworker/u32:16 Not tainted 
> >>> 5.7.7-amd64-desktop-8822 #3
> >>> [  102.133618] Hardware name: HUAWEI NBLL-WXX9/NBLL-WXX9-PCB, BIOS 1.06 
> >>> 09/29/2020
> >>> [  102.133623] Workqueue: events_unbound async_run_entry_fn
> >>> [  102.133651] RIP: 0010:ieee80211_reconfig+0x9b/0x1490 [mac80211]
> >>> [  102.133654] Code: 31 db e8 e8 fb 27 c2 41 c6 85 34 05 00 00 00 4c 89 
> >>> ef e8 38
> >>> 56 fc ff 89 45 b8 85 c0 74 4c 48 c7 c7 d0 0c 09 c1 e8 01 e0 25 c2 <0f> 0b 
> >>> 4c
> >>> 89 ef e8 2b d1 ff ff e9 02 03 00 00 80 7d 9f 00 0f 85 1d
> >>> [  102.133655] RSP: 0018:be52c059fd08 EFLAGS: 00010286
> >>> [  102.133657] RAX:  RBX:  RCX: 
> >>> 0007
> >>> [  102.133658] RDX: 0007 RSI: 0096 RDI: 
> >>> 9d573f519cc0
> >>> [  102.133659] RBP: be52c059fd80 R08: ffd96245 R09: 
> >>> 0002cb80
> >>> [  102.133660] R10: 00016989e54c R11: 0002a360 R12: 
> >>> 9d5731f50300
> >>> [  102.133661] R13: 9d5731f50800 R14: 9d5731f504c8 R15: 
> >>> 8463fbef
> >>> [  102.133664] FS:  () GS:9d573f50() 
> >>> knlGS:
> >>> [  102.133665] CS:  0010 DS:  ES:  CR0: 80050033
> >>> [  102.133666] CR2:  CR3: 00033320a000 CR4: 
> >>> 00340ee0
> >>> [  102.133667] Call Trace:
> >>> [  102.133673]  ? enqueue_entity+0xe3/0x680
> >>> [  102.133705]  ieee80211_resume+0x55/0x70 [mac80211]
> >>> [  102.133729]  wiphy_resume+0x84/0x130 [cfg80211]
> >>> [  102.133752]  ? addresses_show+0xa0/0xa0 [cfg80211]
> >>> [  102.133757]  dpm_run_callback+0x5b/0x150
> >>> [  102.133760]  device_resume+0xad/0x1f0
> >>> [  102.133762]  async_resume+0x1d/0x30
> >>> [  102.133764]  async_run_entry_fn+0x3e/0x170
&g

Re: [PATCH v2] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop

[Pkshih]

On Mon, 2021-02-22 at 12:29 +0200, Kalle Valo wrote:
> Hao Chen  writes:
> 
> > The laptop's wifi disconnect after the laptop HONOR MagicBook 14
> > sleep to S3/S4 and wake up.
> >
> > The dmesg of kernel report:
> > "[   99.990168] pcieport :00:01.2: can't change power state from D3hot
> > to D0 (config space inaccessible)
> > [   99.990176] ACPI: EC: interrupt unblocked
> > [   99.993334] rtw_pci :01:00.0: can't change power state from D3hot
> > to D0 (config space inaccessible)
> > ..
> > [  102.133500] rtw_pci :01:00.0: mac power on failed
> > [  102.133503] rtw_pci :01:00.0: failed to power on mac
> > [  102.133505] [ cut here ]
> > [  102.133506] Hardware became unavailable upon resume. This could be a
> > software issue prior to suspend or a hardware issue.
> > [  102.133569] WARNING: CPU: 4 PID: 5612 at net/mac80211/util.c:2232
> > ieee80211_reconfig+0x9b/0x1490 [mac80211]
> > [  102.133570] Modules linked in: ccm rfcomm uvcvideo videobuf2_vmalloc
> > videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc cmac bnep 
> > btusb btrtl btbcm btintel edac_mce_amd bluetooth kvm_amd ecdh_generic 
> > ecc kvm nls_iso8859_1 rtwpci rtw88 crct10dif_pclmul crc32_pclmul mac80211 
> > ghash_clmulni_intel aesni_intel snd_hda_codec_realtek crypto_simd huawei_wmi
> > snd_hda_codec_generic cryptd cfg80211 wmi_bmof serio_raw sparse_keymap
> > ledtrig_audio sp5100_tco glue_helper joydev snd_hda_codec_hdmi snd_hda_intel
> > snd_intel_dspcfg wdat_wdt snd_hda_codec snd_hda_core pcspkr snd_hwdep 
> > snd_pcm
> > efi_pstore snd_timer libarc4 k10temp snd soundcore snd_pci_acp3x ccp mac_hid
> > binfmt_misc ip_tables x_tables autofs4 amdgpu amd_iommu_v2 gpu_sched 
> > i2c_algo_bit ttm drm_kms_helper syscopyarea sysfillrect sysimgblt 
> > fb_sys_fops
> > usbmouse cec nvme hid_generic i2c_piix4 usbhid nvme_core drm wmi video
> > [  102.133617] CPU: 4 PID: 5612 Comm: kworker/u32:16 Not tainted 
> > 5.7.7-amd64-desktop-8822 #3
> > [  102.133618] Hardware name: HUAWEI NBLL-WXX9/NBLL-WXX9-PCB, BIOS 1.06 
> > 09/29/2020
> > [  102.133623] Workqueue: events_unbound async_run_entry_fn
> > [  102.133651] RIP: 0010:ieee80211_reconfig+0x9b/0x1490 [mac80211]
> > [  102.133654] Code: 31 db e8 e8 fb 27 c2 41 c6 85 34 05 00 00 00 4c 89 ef 
> > e8 38
> > 56 fc ff 89 45 b8 85 c0 74 4c 48 c7 c7 d0 0c 09 c1 e8 01 e0 25 c2 <0f> 0b 4c
> > 89 ef e8 2b d1 ff ff e9 02 03 00 00 80 7d 9f 00 0f 85 1d
> > [  102.133655] RSP: 0018:be52c059fd08 EFLAGS: 00010286
> > [  102.133657] RAX:  RBX:  RCX: 
> > 0007
> > [  102.133658] RDX: 0007 RSI: 0096 RDI: 
> > 9d573f519cc0
> > [  102.133659] RBP: be52c059fd80 R08: ffd96245 R09: 
> > 0002cb80
> > [  102.133660] R10: 00016989e54c R11: 0002a360 R12: 
> > 9d5731f50300
> > [  102.133661] R13: 9d5731f50800 R14: 9d5731f504c8 R15: 
> > 8463fbef
> > [  102.133664] FS:  () GS:9d573f50() 
> > knlGS:
> > [  102.133665] CS:  0010 DS:  ES:  CR0: 80050033
> > [  102.133666] CR2:  CR3: 00033320a000 CR4: 
> > 00340ee0
> > [  102.133667] Call Trace:
> > [  102.133673]  ? enqueue_entity+0xe3/0x680
> > [  102.133705]  ieee80211_resume+0x55/0x70 [mac80211]
> > [  102.133729]  wiphy_resume+0x84/0x130 [cfg80211]
> > [  102.133752]  ? addresses_show+0xa0/0xa0 [cfg80211]
> > [  102.133757]  dpm_run_callback+0x5b/0x150
> > [  102.133760]  device_resume+0xad/0x1f0
> > [  102.133762]  async_resume+0x1d/0x30
> > [  102.133764]  async_run_entry_fn+0x3e/0x170
> > [  102.133768]  process_one_work+0x1ab/0x380
> > [  102.133771]  worker_thread+0x37/0x3b0
> > [  102.133774]  kthread+0x120/0x140
> > [  102.133776]  ? create_worker+0x1b0/0x1b0
> > [  102.133778]  ? kthread_park+0x90/0x90
> > [  102.133782]  ret_from_fork+0x22/0x40
> > [  102.133785] ---[ end trace 46229bfd3a4273be ]---
> > [  102.134137] [ cut here ]
> > [  102.134141] wlp1s0:  Failed check-sdata-in-driver check, flags: 0x0
> > [  102.134195] WARNING: CPU: 0 PID: 5612 at net/mac80211/driver-ops.h:19
> > drv_remove_interface+0xfe/0x110 [mac80211]"
> >
> > When try to pointer the driver.pm to NULL, the problem is fixed.
> > It makes the sleep and wake procedure expected when pm's ops not NULL.
> >
> > By `git blame` command, I know that the assignment of .driver.pm =
> > RTW_PM_OPS was in commit 44bc17f7f5b3 ("rtw88: support wowlan feature for
> > 8822c"), and another
> > commit 7dc7c41607d1 ("rtw88: avoid unused function warnings")
> > pointed out rtw_pci_resume() and rtw_pci_suspend() are not used at
> > all.
> >
> > So I think it's safe to remove them.
> >
> > Fixes: 7dc7c41607d1 ("rtw88: avoid unused function warnings")
> > Fixes: 44bc17f7f5b3 ("rtw88: support wowlan feature for 8822c")
> >
> > Signed-off-by: Hao Chen 
> > ---
> >  drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 1 -
> >  1 

Re: [PATCH] rtw88: 8822ce: fix wifi disconnect after S3/S4 on HONOR laptop

[Pkshih]

On Mon, 2021-02-22 at 09:27 +0200, Kalle Valo wrote:
> 陈浩  writes:
> 
> > By git blame command, I know that the assignment of .driver.pm =
> > RTW_PM_OPS
> >
> > was in commit 44bc17f7f5b3b("rtw88: support wowlan feature for
> > 8822c"),
> >
> > and another commit 7dc7c41607d19("avoid unused function warnings")
> >
> > pointed out rtw_pci_resume() and rtw_pci_suspend() are not used at
> > all.
> >
> > So I think it's safe to remove them.
> >

I think ".driver.pm = _pm_ops" is a switch to enable wowlan feature.
That means that wowlan doesn't work without this declaration.

> > Currently, I find that the rtl8822ce wifi chip and the pci bridge of
> > it are not linked by pci
> >
> > after wake up by `lspci` command.
> >
> > when I set `pcie_aspm.policy=performance ` in the GRUB. The machine
> > sleep and
> >
> > wake up normal.So I think when this ops is assignmented,the sleep and
> > wake up procedure
> >
> > may cause pci device not linked.

Please try setting module parameter disable_aspm=1 with pci.ko.

Could I know what the CPU and pci bridge chipset are used by HONOR laptop?

> 
> Please don't use HTML, our lists automatically drop all HTML email.
> 

Re: [PATCH v2] rtlwifi: rtl8192se: Simplify bool comparison.

[Pkshih]

On Tue, 2021-01-19 at 14:32 +0800, Jiapeng Zhong wrote:
> Fix the follow coccicheck warnings:
> 
> ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:2305:6-27:
> WARNING: Comparison of 0/1 to bool variable.
> 
> ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:1376:5-26:
> WARNING: Comparison of 0/1 to bool variable.
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Zhong 
> ---
> Changes in v2:
>   -Modified subject.
> 

You forget to remove the period at the end of subject.
i.e.
"rtlwifi: rtl8192se: Simplify bool comparison"

---
Ping-Ke

Re: [PATCH] rtlwifi/rtl8192se: Simplify bool comparison.

[Pkshih]

On Fri, 2021-01-15 at 10:06 +, Jiapeng Zhong wrote:
> Fix the follow coccicheck warnings:
> 
> ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:2305:6-27:
> WARNING: Comparison of 0/1 to bool variable.
> 
> ./drivers/net/wireless/realtek/rtlwifi/rtl8192se/hw.c:1376:5-26:
> WARNING: Comparison of 0/1 to bool variable.
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Zhong 
> 

[snip]

The subject should be "rtlwifi: rtl8192se: Simplify bool comparison".
(No period at the end of subject)

Others look good to me.

---
Ping-Ke

Re: [PATCH] wireless: realtek: Simplify bool comparison

[Pkshih]

On Tue, 2021-01-12 at 16:39 +0800, YANG LI wrote:
> Fix the following coccicheck warning:
> ./drivers/net/wireless/realtek/rtlwifi/ps.c:803:7-21: WARNING:
> Comparison to bool
> 
> Reported-by: Abaci Robot 
> Signed-off-by: YANG LI 
> ---
>  drivers/net/wireless/realtek/rtlwifi/ps.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/ps.c
> b/drivers/net/wireless/realtek/rtlwifi/ps.c
> index f9988225..629c032 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/ps.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
> @@ -798,9 +798,9 @@ static void rtl_p2p_noa_ie(struct ieee80211_hw *hw, void
> *data,
>   ie += 3 + noa_len;
>   }
>  
> - if (find_p2p_ie == true) {
> + if (find_p2p_ie) {
>   if ((p2pinfo->p2p_ps_mode > P2P_PS_NONE) &&
> - (find_p2p_ps_ie == false))
> + (!find_p2p_ps_ie))
>   rtl_p2p_ps_cmd(hw, P2P_PS_DISABLE);
>   }
>  }

The subject prefix should be "rtlwifi:".
And, I think it's ok to merge this patch with another patch 
("rtlwifi: rtl8821ae: style: Simplify bool comparison").
Because both of them are trivial fixes and belong to rtlwifi.

---
Ping-Ke

Re: [PATCH] rtlwifi: rtl8821ae: style: Simplify bool comparison

[Pkshih]

On Tue, 2021-01-12 at 16:33 +0800, YANG LI wrote:
> Fix the following coccicheck warning:
> ./drivers/net/wireless/realtek/rtlwifi/rtl8821ae/phy.c:3853:7-17:
> WARNING: Comparison of 0/1 to bool variable
> 
> Reported-by: Abaci Robot 
> Signed-off-by: YANG LI 
> 

I think your name of Signed-off-by should be "Yang Li".

And, the subject prefix "rtlwifi: " is preferred.

---
Ping-Ke

Re: [PATCH] rtw88: debug: style: Simplify bool comparison

[Pkshih]

On Mon, 2021-01-11 at 09:22 +, YANG LI wrote:
> Fix the following coccicheck warning:
>  ./drivers/net/wireless/realtek/rtw88/debug.c:800:17-23: WARNING:
> Comparison of 0/1 to bool variable
> 
> Signed-off-by: YANG LI 
> Reported-by: Abaci Robot---
>  drivers/net/wireless/realtek/rtw88/debug.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 

I think that "rtw88:" or "rtw88: debug:" as subject prefix is enough.
Others are good to me.

---
Ping-Ke

Re: [PATCH wireless -next] rtw88: Delete useless kfree code

[Pkshih]

On Wed, 2020-12-16 at 13:04 +, Zheng Yongjun wrote:
> The parameter of kfree function is NULL, so kfree code is useless, delete it.
> 
> Signed-off-by: Zheng Yongjun 

Acked-by: Ping-Ke Shih 

> ---
>  drivers/net/wireless/realtek/rtw88/main.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/main.c
> b/drivers/net/wireless/realtek/rtw88/main.c
> index 565efd880624..15568cd670a3 100644
> --- a/drivers/net/wireless/realtek/rtw88/main.c
> +++ b/drivers/net/wireless/realtek/rtw88/main.c
> @@ -1249,7 +1249,6 @@ static void rtw_set_supported_band(struct ieee80211_hw
> *hw,
>  
>  err_out:
>   rtw_err(rtwdev, "failed to set supported band\n");
> - kfree(sband);
>  }
>  
>  static void rtw_unset_supported_band(struct ieee80211_hw *hw,

Re: [PATCH][next] rtw88: coex: fix missing unitialization of variable 'interval'

[Pkshih]

On Thu, 2020-12-03 at 17:51 +, Colin King wrote:
> From: Colin Ian King 
> 
> Currently the variable 'interval' is not initialized and is only set
> to 1 when oex_stat->bt_418_hid_existi is true.  Fix this by inintializing
> variable interval to 0 (which I'm assuming is the intended default).
> 
> Addresses-Coverity: ("Uninitalized scalar variable")
> Fixes: 5b2e9a35e456 ("rtw88: coex: add feature to enhance HID coexistence
> performance")
> Signed-off-by: Colin Ian King 

Thanks for your fix.

Acked-by: Ping-Ke Shih 

> ---
>  drivers/net/wireless/realtek/rtw88/coex.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/coex.c
> b/drivers/net/wireless/realtek/rtw88/coex.c
> index c704c6885a18..24530cafcba7 100644
> --- a/drivers/net/wireless/realtek/rtw88/coex.c
> +++ b/drivers/net/wireless/realtek/rtw88/coex.c
> @@ -2051,7 +2051,7 @@ static void rtw_coex_action_bt_a2dp_hid(struct rtw_dev
> *rtwdev)
>   struct rtw_coex_dm *coex_dm = >dm;
>   struct rtw_efuse *efuse = >efuse;
>   struct rtw_chip_info *chip = rtwdev->chip;
> - u8 table_case, tdma_case, interval;
> + u8 table_case, tdma_case, interval = 0;
>   u32 slot_type = 0;
>   bool is_toggle_table = false;
>  
> -- 
> 2.29.2
> 
> 
> --Please consider the environment before printing this e-mail.

RE: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, .remove and .shutdown

[Pkshih]

> -Original Message-
> From: Lee Jones [mailto:lee.jo...@linaro.org]
> Sent: Friday, November 27, 2020 4:57 PM
> To: Pkshih
> Cc: Tony Chuang; kv...@codeaurora.org; linux-kernel@vger.kernel.org; 
> linux-wirel...@vger.kernel.org;
> da...@davemloft.net; net...@vger.kernel.org; k...@kernel.org
> Subject: Re: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, 
> .remove and .shutdown
> 
> On Fri, 27 Nov 2020, Pkshih wrote:
> 
> > On Fri, 2020-11-27 at 07:38 +, Lee Jones wrote:
> > > On Fri, 27 Nov 2020, Pkshih wrote:
> > >
> > > >
> > > > The subject prefix doesn't need 'realtek:'; use 'rtw88:'.
> > > >
> > > > On Thu, 2020-11-26 at 13:31 +, Lee Jones wrote:
> > > > > Also strip out other duplicates from driver specific headers.
> > > > >
> > > > > Ensure 'main.h' is explicitly included in 'pci.h' since the latter
> > > > > uses some defines from the former.  It avoids issues like:
> > > > >
> > > > >  from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5:
> > > > >  drivers/net/wireless/realtek/rtw88/pci.h:209:28: error:
> > > > > ‘RTK_MAX_TX_QUEUE_NUM’ undeclared here (not in a function); did you 
> > > > > mean
> > > > > ‘RTK_MAX_RX_DESC_NUM’?
> > > > >  209 | DECLARE_BITMAP(tx_queued, RTK_MAX_TX_QUEUE_NUM);
> > > > >  | ^~~~
> > > > >
> > > > > Fixes the following W=1 kernel build warning(s):
> > > > >
> > > > >  drivers/net/wireless/realtek/rtw88/pci.c:1488:5: warning: no previous
> > > > > prototype for ‘rtw_pci_probe’ [-Wmissing-prototypes]
> > > > >  1488 | int rtw_pci_probe(struct pci_dev *pdev,
> > > > >  | ^
> > > > >  drivers/net/wireless/realtek/rtw88/pci.c:1568:6: warning: no previous
> > > > > prototype for ‘rtw_pci_remove’ [-Wmissing-prototypes]
> > > > >  1568 | void rtw_pci_remove(struct pci_dev *pdev)
> > > > >  | ^~
> > > > >  drivers/net/wireless/realtek/rtw88/pci.c:1590:6: warning: no previous
> > > > > prototype for ‘rtw_pci_shutdown’ [-Wmissing-prototypes]
> > > > >  1590 | void rtw_pci_shutdown(struct pci_dev *pdev)
> > > > >  | ^~~~
> > > > >
> > > > > Cc: Yan-Hsuan Chuang 
> > > > > Cc: Kalle Valo 
> > > > > Cc: "David S. Miller" 
> > > > > Cc: Jakub Kicinski 
> > > > > Cc: linux-wirel...@vger.kernel.org
> > > > > Cc: net...@vger.kernel.org
> > > > > Signed-off-by: Lee Jones 
> > > > > ---
> > > > >  drivers/net/wireless/realtek/rtw88/pci.h   | 8 
> > > > >  drivers/net/wireless/realtek/rtw88/rtw8723de.c | 1 +
> > > > >  drivers/net/wireless/realtek/rtw88/rtw8723de.h | 4 
> > > > >  drivers/net/wireless/realtek/rtw88/rtw8821ce.c | 1 +
> > > > >  drivers/net/wireless/realtek/rtw88/rtw8821ce.h | 4 
> > > > >  drivers/net/wireless/realtek/rtw88/rtw8822be.c | 1 +
> > > > >  drivers/net/wireless/realtek/rtw88/rtw8822be.h | 4 
> > > > >  drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 1 +
> > > > >  drivers/net/wireless/realtek/rtw88/rtw8822ce.h | 4 
> > > > >  9 files changed, 12 insertions(+), 16 deletions(-)
> > > > >
> > > > > diff --git a/drivers/net/wireless/realtek/rtw88/pci.h
> > > > > b/drivers/net/wireless/realtek/rtw88/pci.h
> > > > > index ca17aa9cf7dc7..cda56919a5f0f 100644
> > > > > --- a/drivers/net/wireless/realtek/rtw88/pci.h
> > > > > +++ b/drivers/net/wireless/realtek/rtw88/pci.h
> > > > > @@ -5,6 +5,8 @@
> > > > >  #ifndef __RTK_PCI_H_
> > > > >  #define __RTK_PCI_H_
> > > > >
> > > > > +#include "main.h"
> > > > > +
> > > >
> > > > Please #include "main.h" ahead of "pci.h" in each of rtw8e.c.
> > >
> > > You mean instead of in pci.h?
> > >
> > > Surely that's a hack.
> > >
> >
> > I mean don't include main.h in pci.h, but include both of them in each
> > of rtw8e.c.
> >
> > +#include "main.h"
> > +#include "pci.h"
> 
> Yes, that's what I thought you meant.  I think that's a hack.
> 
> Source files shouldn't rely on the ordering of include files to
> resolve dependencies.  In fact, a lot of subsystems require includes to
> be in alphabetical order.
> 
> If a source or header file references a resource from a specific
> header file (for instance here pci.h uses defines from main.h) then it
> should explicitly include it.
> 
> Can you tell me the technical reason as to why these drivers are
> handled differently please?
> 

No technical reason, but that's our coding convention that needs some
changes now.
Could you point out where kernel or subsystem describes the rules?
Or, point out the subsystem you mentioned above.
Then, I can study and follow the rules for further development.

Thank you
---
Ping-Ke

Re: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, .remove and .shutdown

[Pkshih]

On Fri, 2020-11-27 at 07:38 +, Lee Jones wrote:
> On Fri, 27 Nov 2020, Pkshih wrote:
> 
> > 
> > The subject prefix doesn't need 'realtek:'; use 'rtw88:'.
> > 
> > On Thu, 2020-11-26 at 13:31 +, Lee Jones wrote:
> > > Also strip out other duplicates from driver specific headers.
> > > 
> > > Ensure 'main.h' is explicitly included in 'pci.h' since the latter
> > > uses some defines from the former.  It avoids issues like:
> > > 
> > >  from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5:
> > >  drivers/net/wireless/realtek/rtw88/pci.h:209:28: error:
> > > ‘RTK_MAX_TX_QUEUE_NUM’ undeclared here (not in a function); did you mean
> > > ‘RTK_MAX_RX_DESC_NUM’?
> > >  209 | DECLARE_BITMAP(tx_queued, RTK_MAX_TX_QUEUE_NUM);
> > >  | ^~~~
> > > 
> > > Fixes the following W=1 kernel build warning(s):
> > > 
> > >  drivers/net/wireless/realtek/rtw88/pci.c:1488:5: warning: no previous
> > > prototype for ‘rtw_pci_probe’ [-Wmissing-prototypes]
> > >  1488 | int rtw_pci_probe(struct pci_dev *pdev,
> > >  | ^
> > >  drivers/net/wireless/realtek/rtw88/pci.c:1568:6: warning: no previous
> > > prototype for ‘rtw_pci_remove’ [-Wmissing-prototypes]
> > >  1568 | void rtw_pci_remove(struct pci_dev *pdev)
> > >  | ^~
> > >  drivers/net/wireless/realtek/rtw88/pci.c:1590:6: warning: no previous
> > > prototype for ‘rtw_pci_shutdown’ [-Wmissing-prototypes]
> > >  1590 | void rtw_pci_shutdown(struct pci_dev *pdev)
> > >  | ^~~~
> > > 
> > > Cc: Yan-Hsuan Chuang 
> > > Cc: Kalle Valo 
> > > Cc: "David S. Miller" 
> > > Cc: Jakub Kicinski 
> > > Cc: linux-wirel...@vger.kernel.org
> > > Cc: net...@vger.kernel.org
> > > Signed-off-by: Lee Jones 
> > > ---
> > >  drivers/net/wireless/realtek/rtw88/pci.h   | 8 
> > >  drivers/net/wireless/realtek/rtw88/rtw8723de.c | 1 +
> > >  drivers/net/wireless/realtek/rtw88/rtw8723de.h | 4 
> > >  drivers/net/wireless/realtek/rtw88/rtw8821ce.c | 1 +
> > >  drivers/net/wireless/realtek/rtw88/rtw8821ce.h | 4 
> > >  drivers/net/wireless/realtek/rtw88/rtw8822be.c | 1 +
> > >  drivers/net/wireless/realtek/rtw88/rtw8822be.h | 4 
> > >  drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 1 +
> > >  drivers/net/wireless/realtek/rtw88/rtw8822ce.h | 4 
> > >  9 files changed, 12 insertions(+), 16 deletions(-)
> > > 
> > > diff --git a/drivers/net/wireless/realtek/rtw88/pci.h
> > > b/drivers/net/wireless/realtek/rtw88/pci.h
> > > index ca17aa9cf7dc7..cda56919a5f0f 100644
> > > --- a/drivers/net/wireless/realtek/rtw88/pci.h
> > > +++ b/drivers/net/wireless/realtek/rtw88/pci.h
> > > @@ -5,6 +5,8 @@
> > >  #ifndef __RTK_PCI_H_
> > >  #define __RTK_PCI_H_
> > >  
> > > +#include "main.h"
> > > +
> > 
> > Please #include "main.h" ahead of "pci.h" in each of rtw8e.c.
> 
> You mean instead of in pci.h?
> 
> Surely that's a hack.
> 

I mean don't include main.h in pci.h, but include both of them in each
of rtw8e.c.

+#include "main.h"
+#include "pci.h"

---
Ping-Ke

Re: [PATCH 17/17] realtek: rtw88: pci: Add prototypes for .probe, .remove and .shutdown

[Pkshih]

The subject prefix doesn't need 'realtek:'; use 'rtw88:'.

On Thu, 2020-11-26 at 13:31 +, Lee Jones wrote:
> Also strip out other duplicates from driver specific headers.
> 
> Ensure 'main.h' is explicitly included in 'pci.h' since the latter
> uses some defines from the former.  It avoids issues like:
> 
>  from drivers/net/wireless/realtek/rtw88/rtw8822be.c:5:
>  drivers/net/wireless/realtek/rtw88/pci.h:209:28: error:
> ‘RTK_MAX_TX_QUEUE_NUM’ undeclared here (not in a function); did you mean
> ‘RTK_MAX_RX_DESC_NUM’?
>  209 | DECLARE_BITMAP(tx_queued, RTK_MAX_TX_QUEUE_NUM);
>  | ^~~~
> 
> Fixes the following W=1 kernel build warning(s):
> 
>  drivers/net/wireless/realtek/rtw88/pci.c:1488:5: warning: no previous
> prototype for ‘rtw_pci_probe’ [-Wmissing-prototypes]
>  1488 | int rtw_pci_probe(struct pci_dev *pdev,
>  | ^
>  drivers/net/wireless/realtek/rtw88/pci.c:1568:6: warning: no previous
> prototype for ‘rtw_pci_remove’ [-Wmissing-prototypes]
>  1568 | void rtw_pci_remove(struct pci_dev *pdev)
>  | ^~
>  drivers/net/wireless/realtek/rtw88/pci.c:1590:6: warning: no previous
> prototype for ‘rtw_pci_shutdown’ [-Wmissing-prototypes]
>  1590 | void rtw_pci_shutdown(struct pci_dev *pdev)
>  | ^~~~
> 
> Cc: Yan-Hsuan Chuang 
> Cc: Kalle Valo 
> Cc: "David S. Miller" 
> Cc: Jakub Kicinski 
> Cc: linux-wirel...@vger.kernel.org
> Cc: net...@vger.kernel.org
> Signed-off-by: Lee Jones 
> ---
>  drivers/net/wireless/realtek/rtw88/pci.h   | 8 
>  drivers/net/wireless/realtek/rtw88/rtw8723de.c | 1 +
>  drivers/net/wireless/realtek/rtw88/rtw8723de.h | 4 
>  drivers/net/wireless/realtek/rtw88/rtw8821ce.c | 1 +
>  drivers/net/wireless/realtek/rtw88/rtw8821ce.h | 4 
>  drivers/net/wireless/realtek/rtw88/rtw8822be.c | 1 +
>  drivers/net/wireless/realtek/rtw88/rtw8822be.h | 4 
>  drivers/net/wireless/realtek/rtw88/rtw8822ce.c | 1 +
>  drivers/net/wireless/realtek/rtw88/rtw8822ce.h | 4 
>  9 files changed, 12 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/pci.h
> b/drivers/net/wireless/realtek/rtw88/pci.h
> index ca17aa9cf7dc7..cda56919a5f0f 100644
> --- a/drivers/net/wireless/realtek/rtw88/pci.h
> +++ b/drivers/net/wireless/realtek/rtw88/pci.h
> @@ -5,6 +5,8 @@
>  #ifndef __RTK_PCI_H_
>  #define __RTK_PCI_H_
>  
> +#include "main.h"
> +

Please #include "main.h" ahead of "pci.h" in each of rtw8e.c.

>  #define RTK_DEFAULT_TX_DESC_NUM 128
>  #define RTK_BEQ_TX_DESC_NUM  256
>  
> @@ -212,6 +214,12 @@ struct rtw_pci {
>   void __iomem *mmap;
>  };
>  
> +const struct dev_pm_ops rtw_pm_ops;
> +
> +int rtw_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id);
> +void rtw_pci_remove(struct pci_dev *pdev);
> +void rtw_pci_shutdown(struct pci_dev *pdev);
> +
>  static inline u32 max_num_of_tx_queue(u8 queue)
>  {
>   u32 max_num;
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8723de.c
> b/drivers/net/wireless/realtek/rtw88/rtw8723de.c
> index c81eb4c336425..2dd689441e8dc 100644
> --- a/drivers/net/wireless/realtek/rtw88/rtw8723de.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8723de.c
> @@ -4,6 +4,7 @@
>  
>  #include 
>  #include 

I mean here:
#include "main.h"

> +#include "pci.h"
>  #include "rtw8723de.h"
>  
>  static const struct pci_device_id rtw_8723de_id_table[] = {
> 

[snip]

---
Ping-Ke

Re: [PATCH v2 1/4] rtlwifi: rtl8188ee: avoid accessing the data mapped to streaming DMA

[Pkshih]

On Wed, 2020-11-18 at 09:53 +0800, Jia-Ju Bai wrote:
> In rtl88ee_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on
> line 677:
>   dma_addr_t mapping = dma_map_single(..., skb->data, ...);
> 
> On line 680, skb->data is assigned to hdr after cast:
>   struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
> 
> Then hdr->frame_control is accessed on line 681:
>   __le16 fc = hdr->frame_control;
> 
> This DMA access may cause data inconsistency between CPU and hardwre.
> 
> To fix this bug, hdr->frame_control is accessed before the DMA mapping.
> 
> Signed-off-by: Jia-Ju Bai 

This patchset looks good to me.
Thank you.

Acked-by: Ping-Ke Shih 

> ---
>  drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
> b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
> index b9775eec4c54..c948dafa0c80 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
> @@ -674,12 +674,12 @@ void rtl88ee_tx_fill_cmddesc(struct ieee80211_hw *hw,
>   u8 fw_queue = QSLT_BEACON;
>   __le32 *pdesc = (__le32 *)pdesc8;
>  
> - dma_addr_t mapping = dma_map_single(>pdev->dev, skb->data,
> - skb->len, DMA_TO_DEVICE);
> -
>   struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
>   __le16 fc = hdr->frame_control;
>  
> + dma_addr_t mapping = dma_map_single(>pdev->dev, skb->data,
> + skb->len, DMA_TO_DEVICE);
> +
>   if (dma_mapping_error(>pdev->dev, mapping)) {
>   rtl_dbg(rtlpriv, COMP_SEND, DBG_TRACE,
>   "DMA mapping error\n");

Re: [PATCH] rtw88: coex: remove the unreached code in rtw_coex_set_tdma

[Pkshih]

On Sat, 2020-11-14 at 15:22 +, xiakaixu1...@gmail.com wrote:
> From: Kaixu Xia 
> 
> The value of the bool variable ap_enable is always false, so the first
> if branch is unreached code. Remove it.
> 
> Reported-by: Tosk Robot 
> Signed-off-by: Kaixu Xia 
> ---
>  drivers/net/wireless/realtek/rtw88/coex.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/coex.c
> b/drivers/net/wireless/realtek/rtw88/coex.c
> index aa08fd7d9fcd..9c7963e45755 100644
> --- a/drivers/net/wireless/realtek/rtw88/coex.c
> +++ b/drivers/net/wireless/realtek/rtw88/coex.c
> @@ -863,18 +863,8 @@ static void rtw_coex_set_tdma(struct rtw_dev *rtwdev, u8
> byte1, u8 byte2,
>   struct rtw_coex_dm *coex_dm = >dm;
>   struct rtw_chip_info *chip = rtwdev->chip;
>   u8 ps_type = COEX_PS_WIFI_NATIVE;
> - bool ap_enable = false;

The variable 'ap_enable' is used to indicate a vif is running in AP mode.
At the first coex version, rtw88 doesn't support AP mode yet, so ap_enable
is set to false. For now, AP mode is ready, and I can send a patch to set
proper value depends on vif mode.

Since I'm submitting coex patches to upgrade the code. In order to avoid
conflicting, I'll send the patch to set proper ap_enable after all my patches
are merged.


> -
> - if (ap_enable && (byte1 & BIT(4) && !(byte1 & BIT(5 {
> - byte1 &= ~BIT(4);
> - byte1 |= BIT(5);
> -
> - byte5 |= BIT(5);
> - byte5 &= ~BIT(6);
>  
> - ps_type = COEX_PS_WIFI_NATIVE;
> - rtw_coex_power_save_state(rtwdev, ps_type, 0x0, 0x0);
> - } else if (byte1 & BIT(4) && !(byte1 & BIT(5))) {
> + if (byte1 & BIT(4) && !(byte1 & BIT(5))) {
>   if (chip->pstdma_type == COEX_PSTDMA_FORCE_LPSOFF)
>   ps_type = COEX_PS_LPS_OFF;
>   else
> -- 
> 2.20.0
> 

---
Ping-Ke

Re: [PATCH] rtl8192ce: avoid accessing the data mapped to streaming DMA

[Pkshih]

On Mon, 2020-10-19 at 11:09 +0800, Jia-Ju Bai wrote:
> In rtl92ce_tx_fill_cmddesc(), skb->data is mapped to streaming DMA on
> line 530:
>   dma_addr_t mapping = dma_map_single(..., skb->data, ...);
> 
> On line 533, skb->data is assigned to hdr after cast:
>   struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
> 
> Then hdr->frame_control is accessed on line 534:
>   __le16 fc = hdr->frame_control;
> 
> This DMA access may cause data inconsistency between CPU and hardwre.
> 
> To fix this bug, hdr->frame_control is accessed before the DMA mapping.
> 
> Signed-off-by: Jia-Ju Bai 
> ---
>  drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c
> b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c
> index c0635309a92d..4165175cf5c0 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/trx.c
> @@ -527,12 +527,12 @@ void rtl92ce_tx_fill_cmddesc(struct ieee80211_hw *hw,
>   u8 fw_queue = QSLT_BEACON;
>   __le32 *pdesc = (__le32 *)pdesc8;
>  
> - dma_addr_t mapping = dma_map_single(>pdev->dev, skb->data,
> - skb->len, DMA_TO_DEVICE);
> -
>   struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
>   __le16 fc = hdr->frame_control;
>  
> + dma_addr_t mapping = dma_map_single(>pdev->dev, skb->data,
> + skb->len, DMA_TO_DEVICE);
> +
>   if (dma_mapping_error(>pdev->dev, mapping)) {
>   rtl_dbg(rtlpriv, COMP_SEND, DBG_TRACE,
>   "DMA mapping error\n");

The changes of the series patches are good to me. 
But, please use 'rtlwifi: ' as subject prefix, like "rtlwifi: rtl8192ce: ...",
and send them as a patchset I think this would be better to maintainer.

Thank you

---
PK

Re: [PATCH] rtlwifi: Fix non-canonical address access issues

[Pkshih]

On Tue, 2020-10-27 at 11:16 +0800, WeitaoWangoc wrote:
> During realtek USB wireless NIC initialization, it's unexpected
> disconnection will cause urb sumbmit fail. On the one hand,
> _rtl_usb_cleanup_rx will be called to clean up rx stuff, especially for
> rtl_wq. On the other hand, disconnection will cause rtl_usb_disconnect
> and _rtl_usb_cleanup_rx to be called. So, rtl_wq will be flush/destroy
> twice, which will cause non-canonical address 0xdead0122 access
> and general protection fault.
> 
> Fixed this issue by remove _rtl_usb_cleanup_rx when urb sumbmit fail.
> 
> Signed-off-by: WeitaoWangoc 

Thanks for your patch.

Acked-by: Ping-Ke Shih 

> ---
>  drivers/net/wireless/realtek/rtlwifi/usb.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c
> b/drivers/net/wireless/realtek/rtlwifi/usb.c
> index 06e073d..d62b87f 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/usb.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
> @@ -731,7 +731,6 @@ static int _rtl_usb_receive(struct ieee80211_hw *hw)
>  
>  err_out:
>   usb_kill_anchored_urbs(>rx_submitted);
> - _rtl_usb_cleanup_rx(hw);
>   return err;
>  }
>  

Re: [PATCH] Net/Usb:Fix realtek wireless NIC non-canonical address access issues

[Pkshih]

On Tue, 2020-10-20 at 19:38 +0800, WeitaoWangoc wrote:

For rtlwifi driver, please use 'rtlwifi: ' as prefix of mail subject, like
"rtlwifi: Fix non-canonical address access issues"

> During realtek USB wireless NIC initialization, it's unexpected
> disconnection will cause urb sumbmit fail.On the one hand,

nit: add space right after period, like "... fail. On the one hand ..."

> _rtl_usb_cleanup_rx will be called to clean up rx stuff, especially
> for rtl_wq. On the other hand, disconnection will cause rtl_usb_disconnect
> and _rtl_usb_cleanup_rx to be called.Finnally,rtl_wq will be flush/destroy
> twice,which will cause non-canonical address 0xdead0122 access and
> general protection fault.
> 
> Fixed this issue by remove _rtl_usb_cleanup_rx when urb sumbmit fail.
> 
> Signed-off-by: WeitaoWangoc 
> ---
>  drivers/net/wireless/realtek/rtlwifi/usb.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c
> b/drivers/net/wireless/realtek/rtlwifi/usb.c
> index 06e073d..d62b87f 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/usb.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
> @@ -731,7 +731,6 @@ static int _rtl_usb_receive(struct ieee80211_hw *hw)
>  
>  err_out:
>   usb_kill_anchored_urbs(>rx_submitted);
> - _rtl_usb_cleanup_rx(hw);
>   return err;
>  }
>  

Re: [PATCH net-next 06/11] rtlwifi: fix -Wpointer-sign warning

[Pkshih]

On Mon, 2020-10-26 at 22:29 +0100, Arnd Bergmann wrote:
> From: Arnd Bergmann 
> 
> There are thousands of warnings in a W=2 build from just one file:
> 
> drivers/net/wireless/realtek/rtlwifi/rtl8821ae/table.c:3788:15: warning:
> pointer targets in initialization of 'u8 *' {aka 'unsigned char *'} from 'char
> *' differ in signedness [-Wpointer-sign]
> 
> Change the types to consistently use 'const char *' for the
> strings.
> 
> Signed-off-by: Arnd Bergmann 

Acked-by: Ping-Ke Shih 

> ---
>  .../wireless/realtek/rtlwifi/rtl8821ae/phy.c  | 81 ++-
>  .../realtek/rtlwifi/rtl8821ae/table.c |  4 +-
>  .../realtek/rtlwifi/rtl8821ae/table.h |  4 +-
>  3 files changed, 45 insertions(+), 44 deletions(-)
> 

[snip]

Re: [PATCH 2/6] rtlwifi: Remove unnecessary parenthese in rtl_dbg uses

[Pkshih]

On Mon, 2020-07-27 at 01:27 -0700, Joe Perches wrote:
> On Mon, 2020-07-27 at 06:07 +0000, Pkshih wrote:
> > On Sat, 2020-07-25 at 12:55 -0700, Joe Perches wrote:
> > > Make these statements a little simpler.
> []
> > > diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> []
> > > @@ -874,11 +874,10 @@ static void halbtc_display_wifi_status(struct
> > > btc_coexist *btcoexist,
> > >   seq_printf(m, "\n %-35s = %s / %s/ %s/ AP=%d ",
> > >      "Wifi freq/ bw/ traffic",
> > >      gl_btc_wifi_freq_string[wifi_freq],
> > > -    ((wifi_under_b_mode) ? "11b" :
> > > - gl_btc_wifi_bw_string[wifi_bw]),
> > > -    ((!wifi_busy) ? "idle" : ((BTC_WIFI_TRAFFIC_TX ==
> > > -   wifi_traffic_dir) ?
> "uplink" :
> > > -  "downlink")),
> > > +    wifi_under_b_mode ? "11b" :
> gl_btc_wifi_bw_string[wifi_bw],
> > > +    (!wifi_busy ? "idle" :
> > > + wifi_traffic_dir == BTC_WIFI_TRAFFIC_TX ? "uplink" :
> > > + "downlink"),
> > 
> > I think this would be better
> > 
> > +      !wifi_busy ? "idle" :
> > +      (wifi_traffic_dir == BTC_WIFI_TRAFFIC_TX ? "uplink" :
> > +   "downlink"),
> 
> It seems most repeated test1 ? : test2 ? : test3 ?:
> uses do not have the style you suggest in the kernel.
> 

Your change is 
(test1 ? : test2 ? :)

So, I think you would like to have parenthesis intentionally.
If so, 
test1 ? : (test2 ? :)
would be better.


If not,
test1 ? : test2 ? :
may be what you want (without any parenthesis).

Re: [PATCH 2/6] rtlwifi: Remove unnecessary parenthese in rtl_dbg uses

[Pkshih]

On Sat, 2020-07-25 at 12:55 -0700, Joe Perches wrote:
> Make these statements a little simpler.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/net/wireless/realtek/rtlwifi/base.c   | 14 +--
>  .../rtlwifi/btcoexist/halbtc8192e2ant.c   | 23 ++-
>  .../rtlwifi/btcoexist/halbtc8821a2ant.c   | 12 +-
>  .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c  |  9 
>  drivers/net/wireless/realtek/rtlwifi/pci.c|  2 +-
>  5 files changed, 30 insertions(+), 30 deletions(-)
> 
> 

[...]

> diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> index 8d28c68f083e..f9a2d8a6730c 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> @@ -874,11 +874,10 @@ static void halbtc_display_wifi_status(struct
> btc_coexist *btcoexist,
>   seq_printf(m, "\n %-35s = %s / %s/ %s/ AP=%d ",
>      "Wifi freq/ bw/ traffic",
>      gl_btc_wifi_freq_string[wifi_freq],
> -    ((wifi_under_b_mode) ? "11b" :
> - gl_btc_wifi_bw_string[wifi_bw]),
> -    ((!wifi_busy) ? "idle" : ((BTC_WIFI_TRAFFIC_TX ==
> -   wifi_traffic_dir) ? "uplink" :
> -  "downlink")),
> +    wifi_under_b_mode ? "11b" : gl_btc_wifi_bw_string[wifi_bw],
> +    (!wifi_busy ? "idle" :
> + wifi_traffic_dir == BTC_WIFI_TRAFFIC_TX ? "uplink" :
> + "downlink"),

I think this would be better

+      !wifi_busy ? "idle" :
+      (wifi_traffic_dir == BTC_WIFI_TRAFFIC_TX ? "uplink" :
+   "downlink"),



>      ap_num);
>  
>   /* power status  */
> diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c
> b/drivers/net/wireless/realtek/rtlwifi/pci.c
> index 1d0af72ee780..3189d1c50d52 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/pci.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
> @@ -557,7 +557,7 @@ static void _rtl_pci_tx_isr(struct ieee80211_hw *hw, int
> prio)
>   if (rtlpriv->rtlhal.earlymode_enable)
>   skb_pull(skb, EM_HDR_LEN);
>  
> - rtl_dbg(rtlpriv, (COMP_INTR | COMP_SEND), DBG_TRACE,
> + rtl_dbg(rtlpriv, COMP_INTR | COMP_SEND, DBG_TRACE,
>   "new ring->idx:%d, free: skb_queue_len:%d, free:
> seq:%x\n",
>   ring->idx,
>   skb_queue_len(>queue),

Re: [PATCH] rtlwifi: core: use eth_broadcast_addr() to assign broadcast

[Pkshih]

On Mon, 2020-07-27 at 02:16 +, Xu Wang wrote:
> This patch is to use eth_broadcast_addr() to assign broadcast address
> insetad of memcpy().
> 
> Signed-off-by: Xu Wang 
> ---
>  drivers/net/wireless/realtek/rtlwifi/core.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c
> b/drivers/net/wireless/realtek/rtlwifi/core.c
> index 4dd82c6052f0..8bb49b77b5c8 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/core.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
> @@ -1512,7 +1512,6 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum
> set_key_cmd cmd,
>   bool wep_only = false;
>   int err = 0;
>   u8 mac_addr[ETH_ALEN];
> - u8 bcast_addr[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
>  
>   rtlpriv->btcoexist.btc_info.in_4way = false;
>  


'bcast_addr' is also used by debug:

        RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,  
 "%s hardware based encryption for keyidx: %d, mac: %pM\n", 
  cmd == SET_KEY ? "Using" : "Disabling", key->keyidx,  
  sta ? sta->addr : bcast_addr); 

If you turn on CONFIG_RTLWIFI_DEBUG, compiler must warn an error.
So, NACK.

> @@ -1634,7 +1633,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum
> set_key_cmd cmd,
>   memcpy(rtlpriv->sec.key_buf[key_idx],
>      key->key, key->keylen);
>   rtlpriv->sec.key_len[key_idx] = key->keylen;
> - memcpy(mac_addr, bcast_addr, ETH_ALEN);
> + eth_broadcast_addr(mac_addr);
>   } else {/* pairwise key */
>   RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
>    "set pairwise key\n");

Re: [PATCH] rtlwifi: btcoex: remove redundant initialization of variables ant_num and single_ant_path

[Pkshih]

On Thu, 2020-07-23 at 17:32 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The variables ant_num and single_ant_path are being initialized with a
> value that is never read and are being updated later with a new value.
> The initializations are redundant and can be removed.
> 
> Addresses-Coverity: ("Unused value")
> Signed-off-by: Colin Ian King 

Acked-by: Ping-Ke Shih 

Thank you

> ---
>  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> index a4940a3842de..4949f99844b5 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> @@ -1318,7 +1318,7 @@ bool exhalbtc_bind_bt_coex_withadapter(void *adapter)
>  {
>   struct rtl_priv *rtlpriv = adapter;
>   struct btc_coexist *btcoexist = rtl_btc_coexist(rtlpriv);
> - u8 ant_num = 2, chip_type, single_ant_path = 0;
> + u8 ant_num, chip_type, single_ant_path;
>  
>   if (!btcoexist)
>   return false;

Re: [PATCH] rtlwifi/*/dm.c: Use const in swing_table declarations

[Pkshih]

On Mon, 2020-06-29 at 11:12 +0800, Pkshih wrote:
> On Sun, 2020-06-28 at 19:51 -0700, j...@perches.com wrote:
> > On 2020-06-28 19:09, Pkshih wrote:
> > > On Sun, 2020-06-28 at 03:17 -0700, Joe Perches wrote:
> > > 
> > > Use 'rtlwifi:' as subject title prefix is enough, likes
> > >   rtlwifi: Use const in swing_table declarations
> > 
> > We disagree.
> > 
> > I like knowing what content is changed via patch subject lines
> > as there are 3 rtlwifi drivers being changed by this one patch.
> 
> If 3 drivers are needed to be listed, I'd use below subject
> 
> "rtlwifi: Use const in rtl8188ee/rtl8723be/rtl8821ae swing_table declarations"
> 
> > 
> > But your choice, you can change it if you choose.
> > 
> > >> Reduce data usage about 1KB by using const.
> > []
> > > Please remove below type casting: 
> > > 
> > > @@ -1872,10 +1872,10 @@ static void 
> > > rtl8821ae_get_delta_swing_table(struct
> > > ieee80211_hw *hw,
> > > *up_b = rtl8821ae_delta_swing_table_idx_5gb_p[2];
> > > *down_b = rtl8821ae_delta_swing_table_idx_5gb_n[2];
> > > } else {
> > > -   *up_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
> > > -   *down_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
> > > -   *up_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
> > > -   *down_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
> > > +   *up_a = rtl8818e_delta_swing_table_idx_24gb_p;
> > > +   *down_a = rtl8818e_delta_swing_table_idx_24gb_n;
> > > +   *up_b = rtl8818e_delta_swing_table_idx_24gb_p;
> > > +   *down_b = rtl8818e_delta_swing_table_idx_24gb_n;
> > 
> > The compiler is quiet about this so I believe this to be
> > an unrelated change and whitespace correction.
> 
> I know compiler doesn't warn this, but it looks wired to cast 'const u8 *'
> to 'u8 *' to 'const u8 *'.
> 
> 
> > 
> > Of course you could modify it if you choose.
> > 
> > btw: There's an unnecessary return at the 2nd instance
> >   of this cast removal too.
> 
> It seems like to copy from rtl8812ae_get_delta_swing_table(), so
> I can remove it by another patch.
> 

Two patches are sent:

rtlwifi: 8821ae: remove unused path B parameters from swing table
rtlwifi: Use const in 8188ee/8723be/8821ae swing_table declarations

---
Thanks
PK

Re: [PATCH] rtlwifi/*/dm.c: Use const in swing_table declarations

[Pkshih]

On Sun, 2020-06-28 at 19:51 -0700, j...@perches.com wrote:
> On 2020-06-28 19:09, Pkshih wrote:
> > On Sun, 2020-06-28 at 03:17 -0700, Joe Perches wrote:
> > 
> > Use 'rtlwifi:' as subject title prefix is enough, likes
> >   rtlwifi: Use const in swing_table declarations
> 
> We disagree.
> 
> I like knowing what content is changed via patch subject lines
> as there are 3 rtlwifi drivers being changed by this one patch.

If 3 drivers are needed to be listed, I'd use below subject

"rtlwifi: Use const in rtl8188ee/rtl8723be/rtl8821ae swing_table declarations"

> 
> But your choice, you can change it if you choose.
> 
> >> Reduce data usage about 1KB by using const.
> []
> > Please remove below type casting: 
> > 
> > @@ -1872,10 +1872,10 @@ static void 
> > rtl8821ae_get_delta_swing_table(struct
> > ieee80211_hw *hw,
> > *up_b = rtl8821ae_delta_swing_table_idx_5gb_p[2];
> > *down_b = rtl8821ae_delta_swing_table_idx_5gb_n[2];
> > } else {
> > -   *up_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
> > -   *down_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
> > -   *up_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
> > -   *down_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
> > +   *up_a = rtl8818e_delta_swing_table_idx_24gb_p;
> > +   *down_a = rtl8818e_delta_swing_table_idx_24gb_n;
> > +   *up_b = rtl8818e_delta_swing_table_idx_24gb_p;
> > +   *down_b = rtl8818e_delta_swing_table_idx_24gb_n;
> 
> The compiler is quiet about this so I believe this to be
> an unrelated change and whitespace correction.

I know compiler doesn't warn this, but it looks wired to cast 'const u8 *'
to 'u8 *' to 'const u8 *'.


> 
> Of course you could modify it if you choose.
> 
> btw: There's an unnecessary return at the 2nd instance
>   of this cast removal too.

It seems like to copy from rtl8812ae_get_delta_swing_table(), so
I can remove it by another patch.

> 
> cheers, Joe
> 
> --Please consider the environment before printing this e-mail.

Re: [PATCH] rtlwifi/*/dm.c: Use const in swing_table declarations

[Pkshih]

On Sun, 2020-06-28 at 03:17 -0700, Joe Perches wrote:

Use 'rtlwifi:' as subject title prefix is enough, likes
  rtlwifi: Use const in swing_table declarations

> Reduce data usage about 1KB by using const.
> 
> Signed-off-by: Joe Perches 
> ---
>  .../net/wireless/realtek/rtlwifi/rtl8188ee/dm.c|  4 +-
>  .../net/wireless/realtek/rtlwifi/rtl8723be/dm.c|  4 +-
>  .../net/wireless/realtek/rtlwifi/rtl8821ae/dm.c| 98 -
> -
>  3 files changed, 56 insertions(+), 50 deletions(-)
> 
> 
[...]
> 
>  
>  static void rtl8812ae_get_delta_swing_table(struct ieee80211_hw *hw,
> - u8 **up_a, u8 **down_a,
> - u8 **up_b, u8 **down_b)
> + const u8 **up_a,
> + const u8 **down_a,
> + const u8 **up_b,
> + const u8 **down_b)
>  {
>   struct rtl_priv *rtlpriv = rtl_priv(hw);
>   struct rtl_phy *rtlphy = >phy;
> 

Please remove below type casting: 

@@ -1872,10 +1872,10 @@ static void rtl8821ae_get_delta_swing_table(struct
ieee80211_hw *hw,
*up_b = rtl8821ae_delta_swing_table_idx_5gb_p[2];
*down_b = rtl8821ae_delta_swing_table_idx_5gb_n[2];
} else {
-   *up_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
-   *down_a = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
-   *up_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_p;
-   *down_b = (u8 *)rtl8818e_delta_swing_table_idx_24gb_n;
+   *up_a = rtl8818e_delta_swing_table_idx_24gb_p;
+   *down_a = rtl8818e_delta_swing_table_idx_24gb_n;
+   *up_b = rtl8818e_delta_swing_table_idx_24gb_p;
+   *down_b = rtl8818e_delta_swing_table_idx_24gb_n;
}
return;
 }


[...]

Re: [PATCH][next] rtw88: 8723d: fix incorrect setting of ldo_pwr

[Pkshih]

On Thu, 2020-05-14 at 18:13 +, Colin King wrote:
> From: Colin Ian King 
> 
> Currently ldo_pwr has the LDO25 voltage bits set to zero and then
> it is overwritten with the new voltage setting. The assignment
> looks incorrect, it should be bit-wise or'ing in the new voltage
> setting rather than a direct assignment.
> 
> Addresses-Coverity: ("Unused value")
> Fixes: 1afb5eb7a00d ("rtw88: 8723d: Add cfg_ldo25 to control LDO25")
> Signed-off-by: Colin Ian King 

Thank you for your fix.

Acked-by: Ping-Ke Shih 

> ---
>  drivers/net/wireless/realtek/rtw88/rtw8723d.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtw88/rtw8723d.c
> b/drivers/net/wireless/realtek/rtw88/rtw8723d.c
> index b517af417e0e..2c6e417c5bca 100644
> --- a/drivers/net/wireless/realtek/rtw88/rtw8723d.c
> +++ b/drivers/net/wireless/realtek/rtw88/rtw8723d.c
> @@ -561,7 +561,7 @@ static void rtw8723d_cfg_ldo25(struct rtw_dev *rtwdev,
> bool enable)
>   ldo_pwr = rtw_read8(rtwdev, REG_LDO_EFUSE_CTRL + 3);
>   if (enable) {
>   ldo_pwr &= ~BIT_MASK_LDO25_VOLTAGE;
> - ldo_pwr = (BIT_LDO25_VOLTAGE_V25 << 4) | BIT_LDO25_EN;
> + ldo_pwr |= (BIT_LDO25_VOLTAGE_V25 << 4) | BIT_LDO25_EN;
>   } else {
>   ldo_pwr &= ~BIT_LDO25_EN;
>   }
> -- 
> 2.25.1
> 
> 
> --Please consider the environment before printing this e-mail.

Re: [PATCH] rtlwifi: Remove unnecessary NULL check in rtl_regd_init

[Pkshih]

On Tue, 2019-10-22 at 17:47 -0700, Nathan Chancellor wrote:
> When building with Clang + -Wtautological-pointer-compare:
> 
> drivers/net/wireless/realtek/rtlwifi/regd.c:389:33: warning: comparison
> of address of 'rtlpriv->regd' equal to a null pointer is always false
> [-Wtautological-pointer-compare]
> if (wiphy == NULL || >regd == NULL)
>   ~^~~~
> 1 warning generated.
> 
> The address of an array member is never NULL unless it is the first
> struct member so remove the unnecessary check. This was addressed in
> the staging version of the driver in commit f986978b32b3 ("Staging:
> rtlwifi: remove unnecessary NULL check").
> 
> While we are here, fix the following checkpatch warning:
> 
> CHECK: Comparison to NULL could be written "!wiphy"
> 35: FILE: drivers/net/wireless/realtek/rtlwifi/regd.c:389:
> +   if (wiphy == NULL)
> 
> Fixes: 0c8173385e54 ("rtl8192ce: Add new driver")
> Link:https://github.com/ClangBuiltLinux/linux/issues/750
> Signed-off-by: Nathan Chancellor 

Looks good.
Thanks for your fix.

Acked-by: Ping-Ke Shih 

> ---
>  drivers/net/wireless/realtek/rtlwifi/regd.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c
> b/drivers/net/wireless/realtek/rtlwifi/regd.c
> index c10432cd703e..8be31e0ad878 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/regd.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
> @@ -386,7 +386,7 @@ int rtl_regd_init(struct ieee80211_hw *hw,
>   struct wiphy *wiphy = hw->wiphy;
>   struct country_code_to_enum_rd *country = NULL;
>  
> - if (wiphy == NULL || >regd == NULL)
> + if (!wiphy)
>   return -EINVAL;
>  
>   /* init country_code from efuse channel plan */

Re: [PATCH v2] rtlwifi: Fix potential overflow on P2P code

[Pkshih]

On Fri, 2019-10-18 at 07:43 -0400, Laura Abbott wrote:
> Nicolas Waisman noticed that even though noa_len is checked for
> a compatible length it's still possible to overrun the buffers
> of p2pinfo since there's no check on the upper bound of noa_num.
> Bound noa_num against P2P_MAX_NOA_NUM.
> 
> Reported-by: Nicolas Waisman 
> Signed-off-by: Laura Abbott 

Acked-by: Ping-Ke Shih 
and Please CC to stable
Cc: Stable  # 4.4+

---

Hi Kalle,

This bug was existing since v3.10, and directory of wireless drivers were
moved at v4.4. Do I need send another patch to fix this issue for longterm
kernel v3.16.75?

Thanks
PK


> ---
> v2: Use P2P_MAX_NOA_NUM instead of erroring out.
> ---
>  drivers/net/wireless/realtek/rtlwifi/ps.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/ps.c
> b/drivers/net/wireless/realtek/rtlwifi/ps.c
> index 70f04c2f5b17..fff8dda14023 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/ps.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
> @@ -754,6 +754,9 @@ static void rtl_p2p_noa_ie(struct ieee80211_hw *hw, void
> *data,
>   return;
>   } else {
>   noa_num = (noa_len - 2) / 13;
> + if (noa_num > P2P_MAX_NOA_NUM)
> + noa_num = P2P_MAX_NOA_NUM;
> +
>   }
>   noa_index = ie[3];
>   if (rtlpriv->psc.p2p_ps_info.p2p_ps_mode ==
> @@ -848,6 +851,9 @@ static void rtl_p2p_action_ie(struct ieee80211_hw *hw,
> void *data,
>   return;
>   } else {
>   noa_num = (noa_len - 2) / 13;
> + if (noa_num > P2P_MAX_NOA_NUM)
> + noa_num = P2P_MAX_NOA_NUM;
> +
>   }
>   noa_index = ie[3];
>   if (rtlpriv->psc.p2p_ps_info.p2p_ps_mode ==

RE: [PATCH] rtlwifi: Fix potential overflow on P2P code

[Pkshih]

> -Original Message-
> From: linux-wireless-ow...@vger.kernel.org 
> [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf
> Of Laura Abbott
> Sent: Thursday, October 17, 2019 4:57 AM
> To: Pkshih; Kalle Valo
> Cc: Laura Abbott; David S. Miller; linux-wirel...@vger.kernel.org; 
> net...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Nicolas Waisman
> Subject: [PATCH] rtlwifi: Fix potential overflow on P2P code
> 
> Nicolas Waisman noticed that even though noa_len is checked for
> a compatible length it's still possible to overrun the buffers
> of p2pinfo since there's no check on the upper bound of noa_num.
> Bounds check noa_num against P2P_MAX_NOA_NUM.
> 
> Reported-by: Nicolas Waisman 
> Signed-off-by: Laura Abbott 
> ---
> Compile tested only as this was reported to the security list.
> ---
>  drivers/net/wireless/realtek/rtlwifi/ps.c | 14 ++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/ps.c 
> b/drivers/net/wireless/realtek/rtlwifi/ps.c
> index 70f04c2f5b17..c5cff598383d 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/ps.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/ps.c
> @@ -754,6 +754,13 @@ static void rtl_p2p_noa_ie(struct ieee80211_hw *hw, void 
> *data,
>   return;
>   } else {
>   noa_num = (noa_len - 2) / 13;
> + if (noa_num > P2P_MAX_NOA_NUM) {
> + RT_TRACE(rtlpriv, COMP_INIT, DBG_LOUD,
> +  "P2P notice of absence: 
> invalid noa_num.%d\n",
> +  noa_num);
> + return;

As the discussion at , I think it'd be better to use
the min between noa_num and P2P_MAX_NOA_NUM, and fall through the code instead
of return. Because ignore all NoA isn't better than apply two of them.


> + }
> +
>   }
>   noa_index = ie[3];
>   if (rtlpriv->psc.p2p_ps_info.p2p_ps_mode ==
> @@ -848,6 +855,13 @@ static void rtl_p2p_action_ie(struct ieee80211_hw *hw, 
> void *data,
>   return;
>   } else {
>   noa_num = (noa_len - 2) / 13;
> + if (noa_num > P2P_MAX_NOA_NUM) {
> + RT_TRACE(rtlpriv, COMP_FW, DBG_LOUD,
> +  "P2P notice of absence: 
> invalid noa_len.%d\n",
> +  noa_len);
> + return;
> +
> + }
>   }
>   noa_index = ie[3];
>   if (rtlpriv->psc.p2p_ps_info.p2p_ps_mode ==
> --
> 2.21.0

RE: [PATCH] rtlwifi: rtl8723ae: Remove unused 'rtstatus' variable

[Pkshih]

> -Original Message-
> From: Austin Kim [mailto:austindh@gmail.com]
> Sent: Monday, September 23, 2019 9:35 PM
> To: Pkshih; kv...@codeaurora.org; da...@davemloft.net
> Cc: linux-wirel...@vger.kernel.org; net...@vger.kernel.org; 
> linux-kernel@vger.kernel.org
> Subject: Re: [PATCH] rtlwifi: rtl8723ae: Remove unused 'rtstatus' variable
> 
> Hello, Maintainers...
> Would you please review above patch if you are available?
> 

You can check status of your patch here
https://patchwork.kernel.org/project/linux-wireless/list/?series=174859
If your patch is existing in patchwork, maintainer doesn't forget it.

Another thing is to avoid top posting that makes maintainer hard to read mail.

---
PK

Re: [PATCH 0/3] rtlwifi: use generic rtl_evm_db_to_percentage

[Pkshih]

On Tue, 2019-09-10 at 21:04 +0200, Michael Straube wrote:
> Functions _rtl92{c,d}_evm_db_to_percentage are functionally identical
> to the generic version rtl_evm_db_to percentage. This series converts
> rtl8192ce, rtl8192cu and rtl8192de to use the generic version.
> 
> Michael Straube (3):
>   rtlwifi: rtl8192ce: replace _rtl92c_evm_db_to_percentage with generic
> version
>   rtlwifi: rtl8192cu: replace _rtl92c_evm_db_to_percentage with generic
> version
>   rtlwifi: rtl8192de: replace _rtl92d_evm_db_to_percentage with generic
> version
> 
>  .../wireless/realtek/rtlwifi/rtl8192ce/trx.c  | 23 +--
>  .../wireless/realtek/rtlwifi/rtl8192cu/mac.c  | 18 +--
>  .../wireless/realtek/rtlwifi/rtl8192de/trx.c  | 18 ++-
>  3 files changed, 4 insertions(+), 55 deletions(-)
> 

I checked the generic version and removed functions, and they are indeed
identical. Thanks for your patches.

Acked-by: Ping-Ke Shih 

Re: [PATCH] rtlwifi: remove unneeded function _rtl_dump_channel_map()

[Pkshih]

On Wed, 2019-07-24 at 22:10 +0800, YueHaibing wrote:
> Now _rtl_dump_channel_map() does not do any actual
> thing using the channel. So remove it.
> 
> Signed-off-by: YueHaibing 
> ---
>  drivers/net/wireless/realtek/rtlwifi/regd.c | 18 --
>  1 file changed, 18 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/regd.c
> b/drivers/net/wireless/realtek/rtlwifi/regd.c
> index 6ccb5b9..c10432c 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/regd.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/regd.c
> @@ -276,22 +276,6 @@ static void _rtl_reg_apply_world_flags(struct wiphy
> *wiphy,
>   return;
>  }
>  
> -static void _rtl_dump_channel_map(struct wiphy *wiphy)
> -{
> - enum nl80211_band band;
> - struct ieee80211_supported_band *sband;
> - struct ieee80211_channel *ch;
> - unsigned int i;
> -
> - for (band = 0; band < NUM_NL80211_BANDS; band++) {
> - if (!wiphy->bands[band])
> - continue;
> - sband = wiphy->bands[band];
> - for (i = 0; i < sband->n_channels; i++)
> - ch = >channels[i];
> - }
> -}
> -
>  static int _rtl_reg_notifier_apply(struct wiphy *wiphy,
>      struct regulatory_request *request,
>      struct rtl_regulatory *reg)
> @@ -309,8 +293,6 @@ static int _rtl_reg_notifier_apply(struct wiphy *wiphy,
>   break;
>   }
>  
> - _rtl_dump_channel_map(wiphy);
> -
>   return 0;
>  }
>  

Acked-by: Ping-Ke Shih 

RE: linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8*/sw.c: many redundant assignments ?

[Pkshih]

> -Original Message-
> From: David Binderman [mailto:dcb...@hotmail.com]
> Sent: Monday, July 22, 2019 4:12 PM
> To: Pkshih; kv...@codeaurora.org; da...@davemloft.net; 
> linux-wirel...@vger.kernel.org;
> net...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8*/sw.c: many 
> redundant assignments ?
> 
> Hello there,
> 
> > [linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c:120]: 
> > (warning) Redundant
> assignment of 'rtlpriv->cfg->mod_params->disable_watchdog' to itself.
> > [linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c:134]: 
> > (warning) Redundant
> assignment of 'rtlpriv->cfg->mod_params->disable_watchdog' to itself.
> > [linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c:133]: 
> > (warning) Redundant
> assignment of 'rtlpriv->cfg->mod_params->disable_watchdog' to itself.
> > [linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c:150]: 
> > (warning) Redundant
> assignment of 'rtlpriv->cfg->mod_params->disable_watchdog' to itself.
> > [linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/sw.c:118]: 
> > (warning) Redundant
> assignment of 'rtlpriv->cfg->mod_params->sw_crypto' to itself.
> > [linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8192ce/sw.c:116]: 
> > (warning) Redundant
> assignment of 'rtlpriv->cfg->mod_params->sw_crypto' to itself.
> > [linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/sw.c:42]: 
> > (warning) Redundant
> assignment of 'rtlpriv->cfg->mod_params->sw_crypto' to itself.
> > [linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8192se/sw.c:164]: 
> > (warning) Redundant
> assignment of 'rtlpriv->cfg->mod_params->sw_crypto' to itself.
> > [linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8723ae/sw.c:132]: 
> > (warning) Redundant
> assignment of 'rtlpriv->cfg->mod_params->sw_crypto' to itself.
> > [linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8723be/sw.c:131]: 
> > (warning) Redundant
> assignment of 'rtlpriv->cfg->mod_params->sw_crypto' to itself.
> > [linux-5.2.2/drivers/net/wireless/realtek/rtlwifi/rtl8821ae/sw.c:148]: 
> > (warning) Redundant
> assignment of 'rtlpriv->cfg->mod_params->sw_crypto' to itself.
> 
> Might be worth a look
> 

I send a patch to fix it.
https://patchwork.kernel.org/patch/11053745/

Thank you.

---
PK

Re: [PATCH] rtlwifi: btcoex: fix issue possible condition with no effect (if == else)

[Pkshih]

On Fri, 2019-07-12 at 19:15 +, Hariprasad Kelam wrote:
> fix below issue reported by coccicheck
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c:514:1-3:
> WARNING: possible condition with no effect (if == else)
> 
> Signed-off-by: Hariprasad Kelam 
> ---
>  drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> index 152242a..191dafd0 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
> @@ -509,13 +509,7 @@ static u32 halbtc_get_wifi_link_status(struct btc_coexist
> *btcoexist)
>  
>  static s32 halbtc_get_wifi_rssi(struct rtl_priv *rtlpriv)
>  {
> - int undec_sm_pwdb = 0;
> -
> - if (rtlpriv->mac80211.link_state >= MAC80211_LINKED)
> - undec_sm_pwdb = rtlpriv->dm.undec_sm_pwdb;
> - else /* associated entry pwdb */
> - undec_sm_pwdb = rtlpriv->dm.undec_sm_pwdb;
> - return undec_sm_pwdb;
> + return rtlpriv->dm.undec_sm_pwdb;
>  }
>  
>  static bool halbtc_get(void *void_btcoexist, u8 get_type, void *out_buf)

It looks good to me. Thank you.

Acked-by: Ping-Ke Shih 

Re: [PATCH] net:rtlwifi:move spin_lock_bh to spin_lock in tasklet

[Pkshih]

On Tue, 2019-03-19 at 22:31 +0800, Jeff Xie wrote:
> It is unnecessary to call spin_lock_bh in a tasklet.
> 
> Signed-off-by: Jeff Xie 
> 
> ---
>  drivers/net/wireless/realtek/rtlwifi/pci.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c
> b/drivers/net/wireless/realtek/rtlwifi/pci.c
> index 48ca521..4055e0a 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/pci.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
> @@ -499,16 +499,16 @@ static void _rtl_pci_tx_chk_waitq(struct ieee80211_hw
> *hw)
>  
>   memset(_desc, 0, sizeof(struct rtl_tcb_desc));
>  
> - spin_lock_bh(>locks.waitq_lock);
> + spin_lock(>locks.waitq_lock);
>   if (!skb_queue_empty(>skb_waitq[tid]) &&
>   (ring->entries - skb_queue_len(>queue) >
>    rtlhal->max_earlymode_num)) {
>   skb = skb_dequeue(>skb_waitq[tid]);
>   } else {
> - spin_unlock_bh(>locks.waitq_lock);
> + spin_unlock(>locks.waitq_lock);
>   break;
>   }
> - spin_unlock_bh(>locks.waitq_lock);
> + spin_unlock(>locks.waitq_lock);
>  
>   /* Some macaddr can't do early mode. like
>    * multicast/broadcast/no_qos data

The mail subject should be 'rtlwifi: move ', and the other looks good to me.

Acked-by: Ping-Ke Shih 

Re: [PATCH] wireless: remove unneeded semicolon

[Pkshih]

On Fri, 2019-01-18 at 11:32 +0800, YueHaibing wrote:
> remove unneeded semicolon
> 
> Signed-off-by: YueHaibing 
> ---
>  drivers/net/wireless/ath/ath10k/wmi.h | 2 +-
>  drivers/net/wireless/ath/ath6kl/init.c| 2 +-
>  drivers/net/wireless/broadcom/brcm80211/brcmfmac/bcmsdh.c | 2 +-
>  drivers/net/wireless/ray_cs.c | 2 +-
>  drivers/net/wireless/realtek/rtlwifi/rtl8723be/phy.c  | 6 +++---

For rtlwifi driver,
Acked-by: Ping-Ke Shih 

Re: [PATCH] rtlwifi: Fix non-working BSS STA mode

[Pkshih]

On Thu, 2018-12-13 at 13:36 +0800, Kai Heng Feng wrote:
> > On Dec 13, 2018, at 08:35, Pkshih  wrote:
> > 
> > On Wed, 2018-12-12 at 13:13 +0800, Kai-Heng Feng wrote:
> >> Once BSS STA mode gets started, it can be scanned by other clients but
> >> cannot entablish a connection.
> >  ^^^ typo: establish
> >> 
> >> Turns out the set_bcn_reg() and its *_set_beacon_related_registers()
> >> callbacks never get called so it has problem beaconing.
> >> 
> >> Enable the function in rtl_op_bss_info_changed() can make BSS STA mode
> >> start to work.
> >> 
> >> Signed-off-by: Kai-Heng Feng 
> >> ---
> >>  drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >> 
> >> diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c
> >> b/drivers/net/wireless/realtek/rtlwifi/core.c
> >> index 4bf7967590ca..11d27a5cc576 100644
> >> --- a/drivers/net/wireless/realtek/rtlwifi/core.c
> >> +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
> >> @@ -1054,7 +1054,7 @@ static void rtl_op_bss_info_changed(struct
> ieee80211_hw
> >> *hw,
> >>     "BSS_CHANGED_BEACON_ENABLED\n");
> >>  
> >>    /*start hw beacon interrupt. */
> >> -  /*rtlpriv->cfg->ops->set_bcn_reg(hw); */
> >> +  rtlpriv->cfg->ops->set_bcn_reg(hw);
> >>    mac->beacon_enabled = 1;
> >>    rtlpriv->cfg->ops-
> >update_interrupt_mask(hw,
> >>    rtlpriv->cfg->maps
> > 
> > Which wifi chip do you use? And, please share your test scenario.
> 
> It’s Realtek 8723DE, which is currently not supported in mainline so I use
> rtl8723de in rtlwifi_new [1] to test it out.
> 
> The test scenario is simply enable hotspot through network manager, which uses
> wpa_supplicant to do the work.
> 
> [1] https://github.com/lwfinger/rtlwifi_new
> 

Since rtl8723de isn't supported yet, this patch would be pending.
I'll take time to check whether it works on existing chips.

Thanks
PK

Re: [PATCH] rtlwifi: Fix non-working BSS STA mode

[Pkshih]

On Wed, 2018-12-12 at 13:13 +0800, Kai-Heng Feng wrote:
> Once BSS STA mode gets started, it can be scanned by other clients but
> cannot entablish a connection.
         ^^^ typo: establish
> 
> Turns out the set_bcn_reg() and its *_set_beacon_related_registers()
> callbacks never get called so it has problem beaconing.
> 
> Enable the function in rtl_op_bss_info_changed() can make BSS STA mode
> start to work.
> 
> Signed-off-by: Kai-Heng Feng 
> ---
>  drivers/net/wireless/realtek/rtlwifi/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c
> b/drivers/net/wireless/realtek/rtlwifi/core.c
> index 4bf7967590ca..11d27a5cc576 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/core.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
> @@ -1054,7 +1054,7 @@ static void rtl_op_bss_info_changed(struct ieee80211_hw
> *hw,
>    "BSS_CHANGED_BEACON_ENABLED\n");
>  
>   /*start hw beacon interrupt. */
> - /*rtlpriv->cfg->ops->set_bcn_reg(hw); */
> + rtlpriv->cfg->ops->set_bcn_reg(hw);
>   mac->beacon_enabled = 1;
>   rtlpriv->cfg->ops->update_interrupt_mask(hw,
>   rtlpriv->cfg->maps

Which wifi chip do you use? And, please share your test scenario.

Thanks

Re: [PATCH] staging: rtlwifi: Removed unused define and code efuse_re_pg* from wifi.h

[Pkshih]

On Mon, 2018-10-01 at 07:15 +0300, Kalle Valo wrote:
> Joe Perches  writes:
> 
> > On Sun, 2018-09-30 at 20:29 +0200, Rick Veens wrote:
> >> The following:
> >>  bool efuse_re_pg_sec1flag;
> >>  u8 efuse_re_pg_data[8];
> >> are not referenced anywhere in the rtlwifi code.
> >> 
> >> Signed-off-by: Rick Veens 
> >> ---
> >>  drivers/staging/rtlwifi/wifi.h | 4 
> >
> > Presumably the equivalent uses in
> > drivers/net/wireless/realtek/rtlwifi/wifi.h
> > should be removed as well.
> 
> But if it's needed, just do it in separate patch as the patches go via
> different trees.
> 

I can send this patch.

--
PK

Re: [PATCH] staging: rtlwifi: Removed unused define and code efuse_re_pg* from wifi.h

[Pkshih]

On Mon, 2018-10-01 at 07:15 +0300, Kalle Valo wrote:
> Joe Perches  writes:
> 
> > On Sun, 2018-09-30 at 20:29 +0200, Rick Veens wrote:
> >> The following:
> >>  bool efuse_re_pg_sec1flag;
> >>  u8 efuse_re_pg_data[8];
> >> are not referenced anywhere in the rtlwifi code.
> >> 
> >> Signed-off-by: Rick Veens 
> >> ---
> >>  drivers/staging/rtlwifi/wifi.h | 4 
> >
> > Presumably the equivalent uses in
> > drivers/net/wireless/realtek/rtlwifi/wifi.h
> > should be removed as well.
> 
> But if it's needed, just do it in separate patch as the patches go via
> different trees.
> 

I can send this patch.

--
PK

Re: [PATCH] staging: r8822be: Fix RTL8822be can't find any wireless AP

[Pkshih]

On Sun, 2018-07-08 at 11:30 -0500, Larry Finger wrote:
> On 07/06/2018 12:44 AM, pks...@realtek.com wrote:
> > From: Ping-Ke Shih 
> > 
> > RTL8822be can't bring up properly on ASUS X530UN, and dmesg says:
> > [ 8.591333] r8822be: module is from the staging directory, the quality
> > is unknown, you have been warned.
> > [ 8.593122] r8822be :02:00.0: enabling device ( -> 0003)
> > [ 8.669163] r8822be: Using firmware rtlwifi/rtl8822befw.bin
> > [ 9.289939] r8822be: rtlwifi: wireless switch is on
> > [ 10.056426] r8822be :02:00.0 wlp2s0: renamed from wlan0
> > ...
> > [ 11.952534] r8822be: halmac_init_hal failed
> > [ 11.955933] r8822be: halmac_init_hal failed
> > [ 11.956227] r8822be: halmac_init_hal failed
> > [ 22.007942] r8822be: halmac_init_hal failed
> > 
> > Jian-Hong reported it works if turn off ASPM with module parameter aspm=0.
> > In order to fix this problem kindly, this commit don't turn off aspm but
> > enlarge ASPM L1 latency to 7.
> > 
> > Reported-by: Jian-Hong Pan 
> > Tested-by: Jian-Hong Pan 
> > Signed-off-by: Ping-Ke Shih 
> 
> This patch definitely needs a Cc for stable. Otherwise I ACK it.
> 

Hi Larry,

This patch had been applied by Greg, and CC'ed to stable.
Thanks for your reminder. 

PK

Re: [PATCH] staging: r8822be: Fix RTL8822be can't find any wireless AP

[Pkshih]

On Sun, 2018-07-08 at 11:30 -0500, Larry Finger wrote:
> On 07/06/2018 12:44 AM, pks...@realtek.com wrote:
> > From: Ping-Ke Shih 
> > 
> > RTL8822be can't bring up properly on ASUS X530UN, and dmesg says:
> > [ 8.591333] r8822be: module is from the staging directory, the quality
> > is unknown, you have been warned.
> > [ 8.593122] r8822be :02:00.0: enabling device ( -> 0003)
> > [ 8.669163] r8822be: Using firmware rtlwifi/rtl8822befw.bin
> > [ 9.289939] r8822be: rtlwifi: wireless switch is on
> > [ 10.056426] r8822be :02:00.0 wlp2s0: renamed from wlan0
> > ...
> > [ 11.952534] r8822be: halmac_init_hal failed
> > [ 11.955933] r8822be: halmac_init_hal failed
> > [ 11.956227] r8822be: halmac_init_hal failed
> > [ 22.007942] r8822be: halmac_init_hal failed
> > 
> > Jian-Hong reported it works if turn off ASPM with module parameter aspm=0.
> > In order to fix this problem kindly, this commit don't turn off aspm but
> > enlarge ASPM L1 latency to 7.
> > 
> > Reported-by: Jian-Hong Pan 
> > Tested-by: Jian-Hong Pan 
> > Signed-off-by: Ping-Ke Shih 
> 
> This patch definitely needs a Cc for stable. Otherwise I ACK it.
> 

Hi Larry,

This patch had been applied by Greg, and CC'ed to stable.
Thanks for your reminder. 

PK

Re: RTL8723BE performance regression

[Pkshih]

On Wed, 2018-05-09 at 13:33 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 8, 2018 at 1:37 AM, Pkshih <pks...@realtek.com> wrote:
> > On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> >> On Tue, May 1, 2018 at 10:58 PM, Pkshih <pks...@realtek.com> wrote:
> >> > On Wed, 2018-05-02 at 05:44 +, Pkshih wrote:
> >> >>
> >> >> > -Original Message-
> >> >> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> >> >> > Sent: Wednesday, May 02, 2018 6:41 AM
> >> >> > To: Larry Finger
> >> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> >> >> > Chaoming_Li; Kalle
> Valo;
> >> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo 
> >> >> > Rechi Vita; linux@endl
> ess
> >> m.c
> >> >> om
> >> >> > Subject: Re: RTL8723BE performance regression
> >> >> >
> >> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger 
> >> >> > <larry.fin...@lwfinger.net> wrote:
> >> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >> >> > >>
> >> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger 
> >> >> > >> <larry.fin...@lwfinger.net>
> >> >> > >> wrote:
> >> >> > >>
> >> >> > >> (...)
> >> >> > >>
> >> >> > >>> As the antenna selection code changes affected your first 
> >> >> > >>> bisection, do
> >> >> > >>> you
> >> >> > >>> have one of those HP laptops with only one antenna and the 
> >> >> > >>> incorrect
> >> >> > >>> coding
> >> >> > >>> in the FUSE?
> >> >> > >>
> >> >> > >>
> >> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- 
> >> >> > >> this
> >> >> > >> was needed to achieve a good performance in the past, before this
> >> >> > >> regression. I've also opened the laptop chassis and confirmed the
> >> >> > >> antenna cable is plugged to the connector labeled with "1" on the
> >> >> > >> card.
> >> >> > >>
> >> >> > >>> If so, please make sure that you still have the same signal
> >> >> > >>> strength for good and bad cases. I have tried to keep the driver 
> >> >> > >>> and the
> >> >> > >>> btcoex code in sync, but there may be some combinations of antenna
> >> >> > >>> configuration and FUSE contents that cause the code to fail.
> >> >> > >>>
> >> >> > >>
> >> >> > >> What is the recommended way to monitor the signal strength?
> >> >> > >
> >> >> > >
> >> >> > > The btcoex code is developed for multiple platforms by a different 
> >> >> > > group
> >> >> > > than the Linux driver. I think they made a change that caused 
> >> >> > > ant_sel to
> >> >> > > switch from 1 to 2. At least numerous comments at
> >> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that 
> >> >> > > change.
> >> >> > >
> >> >> > > Mhy recommended method is to verify the wifi device name with "iw 
> >> >> > > dev". Then
> >> >> > > using that device
> >> >> > >
> >> >> > > sudo iw dev  scan | egrep "SSID|signal"
> >> >> > >
> >> >> >
> >> >> > I have confirmed that the performance regression is indeed tied to
> >> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
> >> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> >> >> > also switched to testing bandwidth in controlled LAN environment using
> >> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> >> >> > machine connected to the 2.4 GHz radio and the machine running the
> >> >> > i

Re: RTL8723BE performance regression

[Pkshih]

On Wed, 2018-05-09 at 13:33 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 8, 2018 at 1:37 AM, Pkshih  wrote:
> > On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> >> On Tue, May 1, 2018 at 10:58 PM, Pkshih  wrote:
> >> > On Wed, 2018-05-02 at 05:44 +, Pkshih wrote:
> >> >>
> >> >> > -Original Message-
> >> >> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> >> >> > Sent: Wednesday, May 02, 2018 6:41 AM
> >> >> > To: Larry Finger
> >> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> >> >> > Chaoming_Li; Kalle
> Valo;
> >> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo 
> >> >> > Rechi Vita; linux@endl
> ess
> >> m.c
> >> >> om
> >> >> > Subject: Re: RTL8723BE performance regression
> >> >> >
> >> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger 
> >> >> >  wrote:
> >> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >> >> > >>
> >> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger 
> >> >> > >> 
> >> >> > >> wrote:
> >> >> > >>
> >> >> > >> (...)
> >> >> > >>
> >> >> > >>> As the antenna selection code changes affected your first 
> >> >> > >>> bisection, do
> >> >> > >>> you
> >> >> > >>> have one of those HP laptops with only one antenna and the 
> >> >> > >>> incorrect
> >> >> > >>> coding
> >> >> > >>> in the FUSE?
> >> >> > >>
> >> >> > >>
> >> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- 
> >> >> > >> this
> >> >> > >> was needed to achieve a good performance in the past, before this
> >> >> > >> regression. I've also opened the laptop chassis and confirmed the
> >> >> > >> antenna cable is plugged to the connector labeled with "1" on the
> >> >> > >> card.
> >> >> > >>
> >> >> > >>> If so, please make sure that you still have the same signal
> >> >> > >>> strength for good and bad cases. I have tried to keep the driver 
> >> >> > >>> and the
> >> >> > >>> btcoex code in sync, but there may be some combinations of antenna
> >> >> > >>> configuration and FUSE contents that cause the code to fail.
> >> >> > >>>
> >> >> > >>
> >> >> > >> What is the recommended way to monitor the signal strength?
> >> >> > >
> >> >> > >
> >> >> > > The btcoex code is developed for multiple platforms by a different 
> >> >> > > group
> >> >> > > than the Linux driver. I think they made a change that caused 
> >> >> > > ant_sel to
> >> >> > > switch from 1 to 2. At least numerous comments at
> >> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that 
> >> >> > > change.
> >> >> > >
> >> >> > > Mhy recommended method is to verify the wifi device name with "iw 
> >> >> > > dev". Then
> >> >> > > using that device
> >> >> > >
> >> >> > > sudo iw dev  scan | egrep "SSID|signal"
> >> >> > >
> >> >> >
> >> >> > I have confirmed that the performance regression is indeed tied to
> >> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
> >> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> >> >> > also switched to testing bandwidth in controlled LAN environment using
> >> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> >> >> > machine connected to the 2.4 GHz radio and the machine running the
> >> >> > iperf3 server connected via ethernet.
> >> >> >
> >> >>
> >> >> We have n

Re: RTL8723BE performance regression

[Pkshih]

On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 1, 2018 at 10:58 PM, Pkshih <pks...@realtek.com> wrote:
> > On Wed, 2018-05-02 at 05:44 +, Pkshih wrote:
> >>
> >> > -Original Message-
> >> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> >> > Sent: Wednesday, May 02, 2018 6:41 AM
> >> > To: Larry Finger
> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> >> > Chaoming_Li; Kalle Valo;
> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo 
> >> > Rechi Vita; linux@endless
> m.c
> >> om
> >> > Subject: Re: RTL8723BE performance regression
> >> >
> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <larry.fin...@lwfinger.net> 
> >> > wrote:
> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >> > >>
> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger 
> >> > >> <larry.fin...@lwfinger.net>
> >> > >> wrote:
> >> > >>
> >> > >> (...)
> >> > >>
> >> > >>> As the antenna selection code changes affected your first bisection, 
> >> > >>> do
> >> > >>> you
> >> > >>> have one of those HP laptops with only one antenna and the incorrect
> >> > >>> coding
> >> > >>> in the FUSE?
> >> > >>
> >> > >>
> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> > >> was needed to achieve a good performance in the past, before this
> >> > >> regression. I've also opened the laptop chassis and confirmed the
> >> > >> antenna cable is plugged to the connector labeled with "1" on the
> >> > >> card.
> >> > >>
> >> > >>> If so, please make sure that you still have the same signal
> >> > >>> strength for good and bad cases. I have tried to keep the driver and 
> >> > >>> the
> >> > >>> btcoex code in sync, but there may be some combinations of antenna
> >> > >>> configuration and FUSE contents that cause the code to fail.
> >> > >>>
> >> > >>
> >> > >> What is the recommended way to monitor the signal strength?
> >> > >
> >> > >
> >> > > The btcoex code is developed for multiple platforms by a different 
> >> > > group
> >> > > than the Linux driver. I think they made a change that caused ant_sel 
> >> > > to
> >> > > switch from 1 to 2. At least numerous comments at
> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that 
> >> > > change.
> >> > >
> >> > > Mhy recommended method is to verify the wifi device name with "iw 
> >> > > dev". Then
> >> > > using that device
> >> > >
> >> > > sudo iw dev  scan | egrep "SSID|signal"
> >> > >
> >> >
> >> > I have confirmed that the performance regression is indeed tied to
> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> >> > also switched to testing bandwidth in controlled LAN environment using
> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> >> > machine connected to the 2.4 GHz radio and the machine running the
> >> > iperf3 server connected via ethernet.
> >> >
> >>
> >> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: 
> >> cleanup
> >> 8723be ant_sel definition"). You can use the above commit and do the same
> >> experiments (with ant_sel=0, 1 and 2) in your side, and then share your 
> >> results.
> >> Since performance is tied to signal strength, you can only share signal 
> >> strength.
> >>
> >
> > Please pay attention to cold reboot once ant_sel is changed.
> >
> 
> I've tested the commit mentioned above and it fixes the problem on top
> of v4.16 (in addition to the latest wireless-drivers-next also been
> fixed as it already contains such commit). On v4.15, we also need the
> following commits before "af8a41cccf8f rtlwifi: c

Re: RTL8723BE performance regression

[Pkshih]

On Mon, 2018-05-07 at 14:49 -0700, João Paulo Rechi Vita wrote:
> On Tue, May 1, 2018 at 10:58 PM, Pkshih  wrote:
> > On Wed, 2018-05-02 at 05:44 +0000, Pkshih wrote:
> >>
> >> > -Original Message-
> >> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> >> > Sent: Wednesday, May 02, 2018 6:41 AM
> >> > To: Larry Finger
> >> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> >> > Chaoming_Li; Kalle Valo;
> >> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo 
> >> > Rechi Vita; linux@endless
> m.c
> >> om
> >> > Subject: Re: RTL8723BE performance regression
> >> >
> >> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger  
> >> > wrote:
> >> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >> > >>
> >> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger 
> >> > >> 
> >> > >> wrote:
> >> > >>
> >> > >> (...)
> >> > >>
> >> > >>> As the antenna selection code changes affected your first bisection, 
> >> > >>> do
> >> > >>> you
> >> > >>> have one of those HP laptops with only one antenna and the incorrect
> >> > >>> coding
> >> > >>> in the FUSE?
> >> > >>
> >> > >>
> >> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> > >> was needed to achieve a good performance in the past, before this
> >> > >> regression. I've also opened the laptop chassis and confirmed the
> >> > >> antenna cable is plugged to the connector labeled with "1" on the
> >> > >> card.
> >> > >>
> >> > >>> If so, please make sure that you still have the same signal
> >> > >>> strength for good and bad cases. I have tried to keep the driver and 
> >> > >>> the
> >> > >>> btcoex code in sync, but there may be some combinations of antenna
> >> > >>> configuration and FUSE contents that cause the code to fail.
> >> > >>>
> >> > >>
> >> > >> What is the recommended way to monitor the signal strength?
> >> > >
> >> > >
> >> > > The btcoex code is developed for multiple platforms by a different 
> >> > > group
> >> > > than the Linux driver. I think they made a change that caused ant_sel 
> >> > > to
> >> > > switch from 1 to 2. At least numerous comments at
> >> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that 
> >> > > change.
> >> > >
> >> > > Mhy recommended method is to verify the wifi device name with "iw 
> >> > > dev". Then
> >> > > using that device
> >> > >
> >> > > sudo iw dev  scan | egrep "SSID|signal"
> >> > >
> >> >
> >> > I have confirmed that the performance regression is indeed tied to
> >> > signal strength: on the good cases signal was between -16 and -8 dBm,
> >> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> >> > also switched to testing bandwidth in controlled LAN environment using
> >> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> >> > machine connected to the 2.4 GHz radio and the machine running the
> >> > iperf3 server connected via ethernet.
> >> >
> >>
> >> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: 
> >> cleanup
> >> 8723be ant_sel definition"). You can use the above commit and do the same
> >> experiments (with ant_sel=0, 1 and 2) in your side, and then share your 
> >> results.
> >> Since performance is tied to signal strength, you can only share signal 
> >> strength.
> >>
> >
> > Please pay attention to cold reboot once ant_sel is changed.
> >
> 
> I've tested the commit mentioned above and it fixes the problem on top
> of v4.16 (in addition to the latest wireless-drivers-next also been
> fixed as it already contains such commit). On v4.15, we also need the
> following commits before "af8a41cccf8f rtlwifi: cleanup 8723be ant_sel
> definition" to have a good performance again:
> 
>

Re: RTL8723BE performance regression

[Pkshih]

On Wed, 2018-05-02 at 05:44 +, Pkshih wrote:
> 
> > -Original Message-
> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> > Sent: Wednesday, May 02, 2018 6:41 AM
> > To: Larry Finger
> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> > Chaoming_Li; Kalle Valo;
> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi 
> > Vita; linux@endlessm.c
> om
> > Subject: Re: RTL8723BE performance regression
> > 
> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <larry.fin...@lwfinger.net> 
> > wrote:
> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> > >>
> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <larry.fin...@lwfinger.net>
> > >> wrote:
> > >>
> > >> (...)
> > >>
> > >>> As the antenna selection code changes affected your first bisection, do
> > >>> you
> > >>> have one of those HP laptops with only one antenna and the incorrect
> > >>> coding
> > >>> in the FUSE?
> > >>
> > >>
> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> > >> was needed to achieve a good performance in the past, before this
> > >> regression. I've also opened the laptop chassis and confirmed the
> > >> antenna cable is plugged to the connector labeled with "1" on the
> > >> card.
> > >>
> > >>> If so, please make sure that you still have the same signal
> > >>> strength for good and bad cases. I have tried to keep the driver and the
> > >>> btcoex code in sync, but there may be some combinations of antenna
> > >>> configuration and FUSE contents that cause the code to fail.
> > >>>
> > >>
> > >> What is the recommended way to monitor the signal strength?
> > >
> > >
> > > The btcoex code is developed for multiple platforms by a different group
> > > than the Linux driver. I think they made a change that caused ant_sel to
> > > switch from 1 to 2. At least numerous comments at
> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> > >
> > > Mhy recommended method is to verify the wifi device name with "iw dev". 
> > > Then
> > > using that device
> > >
> > > sudo iw dev  scan | egrep "SSID|signal"
> > >
> > 
> > I have confirmed that the performance regression is indeed tied to
> > signal strength: on the good cases signal was between -16 and -8 dBm,
> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> > also switched to testing bandwidth in controlled LAN environment using
> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> > machine connected to the 2.4 GHz radio and the machine running the
> > iperf3 server connected via ethernet.
> > 
> 
> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup 
> 8723be ant_sel definition"). You can use the above commit and do the same 
> experiments (with ant_sel=0, 1 and 2) in your side, and then share your 
> results.
> Since performance is tied to signal strength, you can only share signal 
> strength.
> 

Please pay attention to cold reboot once ant_sel is changed.

Re: RTL8723BE performance regression

[Pkshih]

On Wed, 2018-05-02 at 05:44 +, Pkshih wrote:
> 
> > -Original Message-
> > From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> > Sent: Wednesday, May 02, 2018 6:41 AM
> > To: Larry Finger
> > Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> > Chaoming_Li; Kalle Valo;
> > linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi 
> > Vita; linux@endlessm.c
> om
> > Subject: Re: RTL8723BE performance regression
> > 
> > On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger  
> > wrote:
> > > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> > >>
> > >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger 
> > >> wrote:
> > >>
> > >> (...)
> > >>
> > >>> As the antenna selection code changes affected your first bisection, do
> > >>> you
> > >>> have one of those HP laptops with only one antenna and the incorrect
> > >>> coding
> > >>> in the FUSE?
> > >>
> > >>
> > >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> > >> was needed to achieve a good performance in the past, before this
> > >> regression. I've also opened the laptop chassis and confirmed the
> > >> antenna cable is plugged to the connector labeled with "1" on the
> > >> card.
> > >>
> > >>> If so, please make sure that you still have the same signal
> > >>> strength for good and bad cases. I have tried to keep the driver and the
> > >>> btcoex code in sync, but there may be some combinations of antenna
> > >>> configuration and FUSE contents that cause the code to fail.
> > >>>
> > >>
> > >> What is the recommended way to monitor the signal strength?
> > >
> > >
> > > The btcoex code is developed for multiple platforms by a different group
> > > than the Linux driver. I think they made a change that caused ant_sel to
> > > switch from 1 to 2. At least numerous comments at
> > > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> > >
> > > Mhy recommended method is to verify the wifi device name with "iw dev". 
> > > Then
> > > using that device
> > >
> > > sudo iw dev  scan | egrep "SSID|signal"
> > >
> > 
> > I have confirmed that the performance regression is indeed tied to
> > signal strength: on the good cases signal was between -16 and -8 dBm,
> > whereas in bad cases signal was always between -50 to - 40 dBm. I've
> > also switched to testing bandwidth in controlled LAN environment using
> > iperf3, as suggested by Steve deRosier, with the DUT being the only
> > machine connected to the 2.4 GHz radio and the machine running the
> > iperf3 server connected via ethernet.
> > 
> 
> We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup 
> 8723be ant_sel definition"). You can use the above commit and do the same 
> experiments (with ant_sel=0, 1 and 2) in your side, and then share your 
> results.
> Since performance is tied to signal strength, you can only share signal 
> strength.
> 

Please pay attention to cold reboot once ant_sel is changed.

RE: RTL8723BE performance regression

[Pkshih]

> -Original Message-
> From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> Sent: Wednesday, May 02, 2018 6:41 AM
> To: Larry Finger
> Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> Chaoming_Li; Kalle Valo;
> linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi 
> Vita; li...@endlessm.com
> Subject: Re: RTL8723BE performance regression
> 
> On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger <larry.fin...@lwfinger.net> 
> wrote:
> > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >>
> >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger <larry.fin...@lwfinger.net>
> >> wrote:
> >>
> >> (...)
> >>
> >>> As the antenna selection code changes affected your first bisection, do
> >>> you
> >>> have one of those HP laptops with only one antenna and the incorrect
> >>> coding
> >>> in the FUSE?
> >>
> >>
> >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> was needed to achieve a good performance in the past, before this
> >> regression. I've also opened the laptop chassis and confirmed the
> >> antenna cable is plugged to the connector labeled with "1" on the
> >> card.
> >>
> >>> If so, please make sure that you still have the same signal
> >>> strength for good and bad cases. I have tried to keep the driver and the
> >>> btcoex code in sync, but there may be some combinations of antenna
> >>> configuration and FUSE contents that cause the code to fail.
> >>>
> >>
> >> What is the recommended way to monitor the signal strength?
> >
> >
> > The btcoex code is developed for multiple platforms by a different group
> > than the Linux driver. I think they made a change that caused ant_sel to
> > switch from 1 to 2. At least numerous comments at
> > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> >
> > Mhy recommended method is to verify the wifi device name with "iw dev". Then
> > using that device
> >
> > sudo iw dev  scan | egrep "SSID|signal"
> >
> 
> I have confirmed that the performance regression is indeed tied to
> signal strength: on the good cases signal was between -16 and -8 dBm,
> whereas in bad cases signal was always between -50 to - 40 dBm. I've
> also switched to testing bandwidth in controlled LAN environment using
> iperf3, as suggested by Steve deRosier, with the DUT being the only
> machine connected to the 2.4 GHz radio and the machine running the
> iperf3 server connected via ethernet.
> 

We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup 
8723be ant_sel definition"). You can use the above commit and do the same 
experiments (with ant_sel=0, 1 and 2) in your side, and then share your results.
Since performance is tied to signal strength, you can only share signal 
strength.

Regards
PK

RE: RTL8723BE performance regression

[Pkshih]

> -Original Message-
> From: João Paulo Rechi Vita [mailto:jprv...@gmail.com]
> Sent: Wednesday, May 02, 2018 6:41 AM
> To: Larry Finger
> Cc: Steve deRosier; 莊彥宣; Pkshih; Birming Chiu; Shaofu; Steven Ting; 
> Chaoming_Li; Kalle Valo;
> linux-wireless; Network Development; LKML; Daniel Drake; João Paulo Rechi 
> Vita; li...@endlessm.com
> Subject: Re: RTL8723BE performance regression
> 
> On Tue, Apr 3, 2018 at 7:51 PM, Larry Finger  
> wrote:
> > On 04/03/2018 09:37 PM, João Paulo Rechi Vita wrote:
> >>
> >> On Tue, Apr 3, 2018 at 7:28 PM, Larry Finger 
> >> wrote:
> >>
> >> (...)
> >>
> >>> As the antenna selection code changes affected your first bisection, do
> >>> you
> >>> have one of those HP laptops with only one antenna and the incorrect
> >>> coding
> >>> in the FUSE?
> >>
> >>
> >> Yes, that is why I've been passing ant_sel=1 during my tests -- this
> >> was needed to achieve a good performance in the past, before this
> >> regression. I've also opened the laptop chassis and confirmed the
> >> antenna cable is plugged to the connector labeled with "1" on the
> >> card.
> >>
> >>> If so, please make sure that you still have the same signal
> >>> strength for good and bad cases. I have tried to keep the driver and the
> >>> btcoex code in sync, but there may be some combinations of antenna
> >>> configuration and FUSE contents that cause the code to fail.
> >>>
> >>
> >> What is the recommended way to monitor the signal strength?
> >
> >
> > The btcoex code is developed for multiple platforms by a different group
> > than the Linux driver. I think they made a change that caused ant_sel to
> > switch from 1 to 2. At least numerous comments at
> > github.com/lwfinger/rtlwifi_new claimed they needed to make that change.
> >
> > Mhy recommended method is to verify the wifi device name with "iw dev". Then
> > using that device
> >
> > sudo iw dev  scan | egrep "SSID|signal"
> >
> 
> I have confirmed that the performance regression is indeed tied to
> signal strength: on the good cases signal was between -16 and -8 dBm,
> whereas in bad cases signal was always between -50 to - 40 dBm. I've
> also switched to testing bandwidth in controlled LAN environment using
> iperf3, as suggested by Steve deRosier, with the DUT being the only
> machine connected to the 2.4 GHz radio and the machine running the
> iperf3 server connected via ethernet.
> 

We have new experimental results in commit af8a41cccf8f46 ("rtlwifi: cleanup 
8723be ant_sel definition"). You can use the above commit and do the same 
experiments (with ant_sel=0, 1 and 2) in your side, and then share your results.
Since performance is tied to signal strength, you can only share signal 
strength.

Regards
PK

[PATCH v2 0/9] rtlwifi: btcoex: Add 8822b btcoex support

[pkshih]

From: Ping-Ke Shih 

v2: fix misspelling and boolean expression in patch 1/9

Patches 1-2 are revised by patches 12 of previous patchset. 8822b coex
files are split into two patches, and I remove some comments and apply
'static const' to version related variables.
Patches 3-4 aren't changed. (identical to patches 13-15 of previous patchset)
Patches 6-7 remove comments and apply 'static const' to existing files.
Patches 8-9 remove global variables, and use local variables instead.

Ping-Ke Shih (9):
  rtlwifi: btcoex: Add 8822b1ant coex files
  rtlwifi: btcoex: Add 8822b2ant coex files
  rtlwifi: btcoex: Add 8822b header files to precomp.h
  rtlwifi: btcoex: Add 8822b routine to btc interfaces
  rtlwifi: btcoex: Add 8822b to Makefile
  rtlwifi: btcoex: remove comments that are not meaningful
  rtlwifi: btcoex: Add modifier const to version related variables
  rtlwifi: btcoex: Add struct members to replace global varaibles
  rtlwifi: btcoex: Remove global variables of chip specific context

 .../wireless/realtek/rtlwifi/btcoexist/Makefile|3 +
 .../realtek/rtlwifi/btcoexist/halbt_precomp.h  |9 +-
 .../realtek/rtlwifi/btcoexist/halbtc8192e2ant.c|   68 +-
 .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c|   82 +-
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c|   82 +-
 .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c|   71 +-
 .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c|   64 +-
 .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.c| 5365 +++
 .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.h|  413 ++
 .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.c| 5429 
 .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.h|  434 ++
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   |  100 +
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |   24 +
 13 files changed, 12005 insertions(+), 139 deletions(-)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b2ant.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b2ant.h

-- 
2.15.1

[PATCH v2 8/9] rtlwifi: btcoex: Add struct members to replace global varaibles

[pkshih]

From: Ping-Ke Shih 

Chip specific context plays as global variables that will not support
multiple devices simultaneously. This patch adds 'union' fields to hold
the variables, and next patch will remove all of them.

To use the declaration of fields in halbtcoutsrc.h, I move the including
order in header file halbt_precomp.h, and declare two struct terms for
chip specific header files.

Signed-off-by: Ping-Ke Shih 
---
 .../realtek/rtlwifi/btcoexist/halbt_precomp.h  |  6 +-
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   | 24 ++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
index 858318fd3d63..e21222b48c2c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
@@ -35,7 +35,6 @@
 #include "../ps.h"
 #include "../pci.h"
 
-#include "halbtcoutsrc.h"
 
 /* Interface type */
 #define RT_PCI_INTERFACE   1
@@ -43,6 +42,9 @@
 #define RT_SDIO_INTERFACE  3
 #define DEV_BUS_TYPE   RT_PCI_INTERFACE
 
+struct btc_coexist;
+struct wifi_only_cfg;
+
 #include "halbtc8192e2ant.h"
 #include "halbtc8723b1ant.h"
 #include "halbtc8723b2ant.h"
@@ -52,6 +54,8 @@
 #include "halbtc8822b2ant.h"
 #include "halbtc8822bwifionly.h"
 
+#include "halbtcoutsrc.h"
+
 #define GetDefaultAdapter(padapter)padapter
 
 #define BIT0   0x0001
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index 9eae87d19120..46355ce32f1b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -693,6 +693,30 @@ struct btc_coexist {
enum btc_chip_interface chip_interface;
struct btc_bt_link_info bt_link_info;
 
+   /* context for each chip */
+   union {
+   struct coex_dm_8192e_2ant coex_dm_8192e_2ant;
+   struct coex_dm_8723b_1ant coex_dm_8723b_1ant;
+   struct coex_dm_8723b_2ant coex_dm_8723b_2ant;
+   struct coex_dm_8821a_1ant coex_dm_8821a_1ant;
+   struct coex_dm_8821a_2ant coex_dm_8821a_2ant;
+   struct coex_dm_8822b_1ant coex_dm_8822b_1ant;
+   struct coex_dm_8822b_2ant coex_dm_8822b_2ant;
+   };
+   union {
+   struct coex_sta_8192e_2ant coex_sta_8192e_2ant;
+   struct coex_sta_8723b_1ant coex_sta_8723b_1ant;
+   struct coex_sta_8723b_2ant coex_sta_8723b_2ant;
+   struct coex_sta_8821a_1ant coex_sta_8821a_1ant;
+   struct coex_sta_8821a_2ant coex_sta_8821a_2ant;
+   struct coex_sta_8822b_1ant coex_sta_8822b_1ant;
+   struct coex_sta_8822b_2ant coex_sta_8822b_2ant;
+   };
+   union {
+   struct rfe_type_8822b_1ant rfe_type_8822b_1ant;
+   struct rfe_type_8822b_2ant rfe_type_8822b_2ant;
+   };
+
/* boolean variables to replace BT_AUTO_REPORT_ONLY_Y_ZANT
 * configuration parameters
 */
-- 
2.15.1

[PATCH v2 0/9] rtlwifi: btcoex: Add 8822b btcoex support

[pkshih]

From: Ping-Ke Shih 

v2: fix misspelling and boolean expression in patch 1/9

Patches 1-2 are revised by patches 12 of previous patchset. 8822b coex
files are split into two patches, and I remove some comments and apply
'static const' to version related variables.
Patches 3-4 aren't changed. (identical to patches 13-15 of previous patchset)
Patches 6-7 remove comments and apply 'static const' to existing files.
Patches 8-9 remove global variables, and use local variables instead.

Ping-Ke Shih (9):
  rtlwifi: btcoex: Add 8822b1ant coex files
  rtlwifi: btcoex: Add 8822b2ant coex files
  rtlwifi: btcoex: Add 8822b header files to precomp.h
  rtlwifi: btcoex: Add 8822b routine to btc interfaces
  rtlwifi: btcoex: Add 8822b to Makefile
  rtlwifi: btcoex: remove comments that are not meaningful
  rtlwifi: btcoex: Add modifier const to version related variables
  rtlwifi: btcoex: Add struct members to replace global varaibles
  rtlwifi: btcoex: Remove global variables of chip specific context

 .../wireless/realtek/rtlwifi/btcoexist/Makefile|3 +
 .../realtek/rtlwifi/btcoexist/halbt_precomp.h  |9 +-
 .../realtek/rtlwifi/btcoexist/halbtc8192e2ant.c|   68 +-
 .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c|   82 +-
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c|   82 +-
 .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c|   71 +-
 .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c|   64 +-
 .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.c| 5365 +++
 .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.h|  413 ++
 .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.c| 5429 
 .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.h|  434 ++
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   |  100 +
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   |   24 +
 13 files changed, 12005 insertions(+), 139 deletions(-)
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b1ant.h
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b2ant.c
 create mode 100644 
drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8822b2ant.h

-- 
2.15.1

[PATCH v2 8/9] rtlwifi: btcoex: Add struct members to replace global varaibles

[pkshih]

From: Ping-Ke Shih 

Chip specific context plays as global variables that will not support
multiple devices simultaneously. This patch adds 'union' fields to hold
the variables, and next patch will remove all of them.

To use the declaration of fields in halbtcoutsrc.h, I move the including
order in header file halbt_precomp.h, and declare two struct terms for
chip specific header files.

Signed-off-by: Ping-Ke Shih 
---
 .../realtek/rtlwifi/btcoexist/halbt_precomp.h  |  6 +-
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.h   | 24 ++
 2 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
index 858318fd3d63..e21222b48c2c 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
@@ -35,7 +35,6 @@
 #include "../ps.h"
 #include "../pci.h"
 
-#include "halbtcoutsrc.h"
 
 /* Interface type */
 #define RT_PCI_INTERFACE   1
@@ -43,6 +42,9 @@
 #define RT_SDIO_INTERFACE  3
 #define DEV_BUS_TYPE   RT_PCI_INTERFACE
 
+struct btc_coexist;
+struct wifi_only_cfg;
+
 #include "halbtc8192e2ant.h"
 #include "halbtc8723b1ant.h"
 #include "halbtc8723b2ant.h"
@@ -52,6 +54,8 @@
 #include "halbtc8822b2ant.h"
 #include "halbtc8822bwifionly.h"
 
+#include "halbtcoutsrc.h"
+
 #define GetDefaultAdapter(padapter)padapter
 
 #define BIT0   0x0001
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
index 9eae87d19120..46355ce32f1b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.h
@@ -693,6 +693,30 @@ struct btc_coexist {
enum btc_chip_interface chip_interface;
struct btc_bt_link_info bt_link_info;
 
+   /* context for each chip */
+   union {
+   struct coex_dm_8192e_2ant coex_dm_8192e_2ant;
+   struct coex_dm_8723b_1ant coex_dm_8723b_1ant;
+   struct coex_dm_8723b_2ant coex_dm_8723b_2ant;
+   struct coex_dm_8821a_1ant coex_dm_8821a_1ant;
+   struct coex_dm_8821a_2ant coex_dm_8821a_2ant;
+   struct coex_dm_8822b_1ant coex_dm_8822b_1ant;
+   struct coex_dm_8822b_2ant coex_dm_8822b_2ant;
+   };
+   union {
+   struct coex_sta_8192e_2ant coex_sta_8192e_2ant;
+   struct coex_sta_8723b_1ant coex_sta_8723b_1ant;
+   struct coex_sta_8723b_2ant coex_sta_8723b_2ant;
+   struct coex_sta_8821a_1ant coex_sta_8821a_1ant;
+   struct coex_sta_8821a_2ant coex_sta_8821a_2ant;
+   struct coex_sta_8822b_1ant coex_sta_8822b_1ant;
+   struct coex_sta_8822b_2ant coex_sta_8822b_2ant;
+   };
+   union {
+   struct rfe_type_8822b_1ant rfe_type_8822b_1ant;
+   struct rfe_type_8822b_2ant rfe_type_8822b_2ant;
+   };
+
/* boolean variables to replace BT_AUTO_REPORT_ONLY_Y_ZANT
 * configuration parameters
 */
-- 
2.15.1

[PATCH v2 4/9] rtlwifi: btcoex: Add 8822b routine to btc interfaces

[pkshih]

From: Ping-Ke Shih 

Add 8822b routines to run btcoex algorithm

Signed-off-by: Ping-Ke Shih 
---
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 100 +
 1 file changed, 100 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 8b6b07a936f5..e0f9985582f9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1441,6 +1441,11 @@ void exhalbtc_power_on_setting(struct btc_coexist 
*btcoexist)
ex_btc8723b2ant_power_on_setting(btcoexist);
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8723b1ant_power_on_setting(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_power_on_setting(btcoexist);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_power_on_setting(btcoexist);
}
 }
 
@@ -1454,6 +1459,11 @@ void exhalbtc_pre_load_firmware(struct btc_coexist 
*btcoexist)
if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8723b2ant_pre_load_firmware(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_pre_load_firmware(btcoexist);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_pre_load_firmware(btcoexist);
}
 }
 
@@ -1479,11 +1489,21 @@ void exhalbtc_init_hw_config(struct btc_coexist 
*btcoexist, bool wifi_only)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_init_hwconfig(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_init_hw_config(btcoexist, wifi_only);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_init_hw_config(btcoexist, wifi_only);
+
+   halbtc_set_default_port_id_cmd(btcoexist);
+   halbtc_send_wifi_port_id_cmd(btcoexist);
}
 }
 
 void exhalbtc_init_hw_config_wifi_only(struct wifi_only_cfg *wifionly_cfg)
 {
+   if (IS_HARDWARE_TYPE_8822B(wifionly_cfg->adapter))
+   ex_hal8822b_wifi_only_hw_config(wifionly_cfg);
 }
 
 void exhalbtc_init_coex_dm(struct btc_coexist *btcoexist)
@@ -1506,6 +1526,11 @@ void exhalbtc_init_coex_dm(struct btc_coexist *btcoexist)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_init_coex_dm(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_init_coex_dm(btcoexist);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_init_coex_dm(btcoexist);
}
 
btcoexist->initilized = true;
@@ -1541,6 +1566,11 @@ void exhalbtc_ips_notify(struct btc_coexist *btcoexist, 
u8 type)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_ips_notify(btcoexist, ips_type);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_ips_notify(btcoexist, ips_type);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_ips_notify(btcoexist, ips_type);
}
 
halbtc_normal_low_power(btcoexist);
@@ -1574,6 +1604,11 @@ void exhalbtc_lps_notify(struct btc_coexist *btcoexist, 
u8 type)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_lps_notify(btcoexist, lps_type);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_lps_notify(btcoexist, lps_type);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_lps_notify(btcoexist, lps_type);
}
 }
 
@@ -1607,6 +1642,11 @@ void exhalbtc_scan_notify(struct btc_coexist *btcoexist, 
u8 type)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
  

[PATCH v2 4/9] rtlwifi: btcoex: Add 8822b routine to btc interfaces

[pkshih]

From: Ping-Ke Shih 

Add 8822b routines to run btcoex algorithm

Signed-off-by: Ping-Ke Shih 
---
 .../realtek/rtlwifi/btcoexist/halbtcoutsrc.c   | 100 +
 1 file changed, 100 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
index 8b6b07a936f5..e0f9985582f9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtcoutsrc.c
@@ -1441,6 +1441,11 @@ void exhalbtc_power_on_setting(struct btc_coexist 
*btcoexist)
ex_btc8723b2ant_power_on_setting(btcoexist);
else if (btcoexist->board_info.btdm_ant_num == 1)
ex_btc8723b1ant_power_on_setting(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_power_on_setting(btcoexist);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_power_on_setting(btcoexist);
}
 }
 
@@ -1454,6 +1459,11 @@ void exhalbtc_pre_load_firmware(struct btc_coexist 
*btcoexist)
if (IS_HARDWARE_TYPE_8723B(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8723b2ant_pre_load_firmware(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_pre_load_firmware(btcoexist);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_pre_load_firmware(btcoexist);
}
 }
 
@@ -1479,11 +1489,21 @@ void exhalbtc_init_hw_config(struct btc_coexist 
*btcoexist, bool wifi_only)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_init_hwconfig(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_init_hw_config(btcoexist, wifi_only);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_init_hw_config(btcoexist, wifi_only);
+
+   halbtc_set_default_port_id_cmd(btcoexist);
+   halbtc_send_wifi_port_id_cmd(btcoexist);
}
 }
 
 void exhalbtc_init_hw_config_wifi_only(struct wifi_only_cfg *wifionly_cfg)
 {
+   if (IS_HARDWARE_TYPE_8822B(wifionly_cfg->adapter))
+   ex_hal8822b_wifi_only_hw_config(wifionly_cfg);
 }
 
 void exhalbtc_init_coex_dm(struct btc_coexist *btcoexist)
@@ -1506,6 +1526,11 @@ void exhalbtc_init_coex_dm(struct btc_coexist *btcoexist)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_init_coex_dm(btcoexist);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_init_coex_dm(btcoexist);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_init_coex_dm(btcoexist);
}
 
btcoexist->initilized = true;
@@ -1541,6 +1566,11 @@ void exhalbtc_ips_notify(struct btc_coexist *btcoexist, 
u8 type)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_ips_notify(btcoexist, ips_type);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_ips_notify(btcoexist, ips_type);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_ips_notify(btcoexist, ips_type);
}
 
halbtc_normal_low_power(btcoexist);
@@ -1574,6 +1604,11 @@ void exhalbtc_lps_notify(struct btc_coexist *btcoexist, 
u8 type)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if (btcoexist->board_info.btdm_ant_num == 2)
ex_btc8192e2ant_lps_notify(btcoexist, lps_type);
+   } else if (IS_HARDWARE_TYPE_8822B(btcoexist->adapter)) {
+   if (btcoexist->board_info.btdm_ant_num == 1)
+   ex_btc8822b1ant_lps_notify(btcoexist, lps_type);
+   else if (btcoexist->board_info.btdm_ant_num == 2)
+   ex_btc8822b2ant_lps_notify(btcoexist, lps_type);
}
 }
 
@@ -1607,6 +1642,11 @@ void exhalbtc_scan_notify(struct btc_coexist *btcoexist, 
u8 type)
} else if (IS_HARDWARE_TYPE_8192E(btcoexist->adapter)) {
if 

[PATCH v2 7/9] rtlwifi: btcoex: Add modifier const to version related variables

[pkshih]

From: Ping-Ke Shih 

The variables declared as 'static' look a little weird. Since they are
version of btcoex and only used to display in debug message, this patch
changes them to 'static const' to make it clear.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
index 959af05117d7..a4704b2fbeb9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
@@ -36,8 +36,8 @@ static const char *const glbt_info_src_8192e_2ant[] = {
"BT Info[bt auto report]",
 };
 
-static u32 glcoex_ver_date_8192e_2ant = 20130902;
-static u32 glcoex_ver_8192e_2ant = 0x34;
+static const u32 glcoex_ver_date_8192e_2ant = 20130902;
+static const u32 glcoex_ver_8192e_2ant = 0x34;
 
 static u8 btc8192e2ant_bt_rssi_state(struct btc_coexist *btcoexist,
 u8 level_num, u8 rssi_thresh,
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
index e97e907e66cd..31b716fa2524 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
@@ -36,8 +36,8 @@ static const char *const glbt_info_src_8723b_1ant[] = {
"BT Info[bt auto report]",
 };
 
-static u32 glcoex_ver_date_8723b_1ant = 20130918;
-static u32 glcoex_ver_8723b_1ant = 0x47;
+static const u32 glcoex_ver_date_8723b_1ant = 20130918;
+static const u32 glcoex_ver_8723b_1ant = 0x47;
 
 static void halbtc8723b1ant_updatera_mask(struct btc_coexist *btcoexist,
  bool force_exec, u32 dis_rate_mask)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index e9a7f303cdda..8c1cec306bf1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -36,8 +36,8 @@ static const char *const glbt_info_src_8723b_2ant[] = {
"BT Info[bt auto report]",
 };
 
-static u32 glcoex_ver_date_8723b_2ant = 20131113;
-static u32 glcoex_ver_8723b_2ant = 0x3f;
+static const u32 glcoex_ver_date_8723b_2ant = 20131113;
+static const u32 glcoex_ver_8723b_2ant = 0x3f;
 
 static u8 btc8723b2ant_bt_rssi_state(struct btc_coexist *btcoexist,
 u8 level_num, u8 rssi_thresh,
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c
index 39dc5966700b..cb34a33ae99a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c
@@ -38,8 +38,8 @@ static const char *const glbt_info_src_8821a_1ant[] = {
  "BT Info[bt auto report]",
 };
 
-static u32 glcoex_ver_date_8821a_1ant = 20130816;
-static u32 glcoex_ver_8821a_1ant = 0x41;
+static const u32 glcoex_ver_date_8821a_1ant = 20130816;
+static const u32 glcoex_ver_8821a_1ant = 0x41;
 
 static u8 btc8821a1ant_bt_rssi_state(struct btc_coexist *btcoexist,
 u8 level_num, u8 rssi_thresh,
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
index 264796616d8a..14510d514e2f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
@@ -36,8 +36,8 @@ static const char *const glbt_info_src_8821a_2ant[] = {
"BT Info[bt auto report]",
 };
 
-static u32 glcoex_ver_date_8821a_2ant = 20130618;
-static u32 glcoex_ver_8821a_2ant = 0x5050;
+static const u32 glcoex_ver_date_8821a_2ant = 20130618;
+static const u32 glcoex_ver_8821a_2ant = 0x5050;
 
 static u8 btc8821a2ant_bt_rssi_state(struct btc_coexist *btcoexist,
 u8 level_num, u8 rssi_thresh,
-- 
2.15.1

[PATCH v2 7/9] rtlwifi: btcoex: Add modifier const to version related variables

[pkshih]

From: Ping-Ke Shih 

The variables declared as 'static' look a little weird. Since they are
version of btcoex and only used to display in debug message, this patch
changes them to 'static const' to make it clear.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c | 4 ++--
 5 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
index 959af05117d7..a4704b2fbeb9 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
@@ -36,8 +36,8 @@ static const char *const glbt_info_src_8192e_2ant[] = {
"BT Info[bt auto report]",
 };
 
-static u32 glcoex_ver_date_8192e_2ant = 20130902;
-static u32 glcoex_ver_8192e_2ant = 0x34;
+static const u32 glcoex_ver_date_8192e_2ant = 20130902;
+static const u32 glcoex_ver_8192e_2ant = 0x34;
 
 static u8 btc8192e2ant_bt_rssi_state(struct btc_coexist *btcoexist,
 u8 level_num, u8 rssi_thresh,
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
index e97e907e66cd..31b716fa2524 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
@@ -36,8 +36,8 @@ static const char *const glbt_info_src_8723b_1ant[] = {
"BT Info[bt auto report]",
 };
 
-static u32 glcoex_ver_date_8723b_1ant = 20130918;
-static u32 glcoex_ver_8723b_1ant = 0x47;
+static const u32 glcoex_ver_date_8723b_1ant = 20130918;
+static const u32 glcoex_ver_8723b_1ant = 0x47;
 
 static void halbtc8723b1ant_updatera_mask(struct btc_coexist *btcoexist,
  bool force_exec, u32 dis_rate_mask)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index e9a7f303cdda..8c1cec306bf1 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -36,8 +36,8 @@ static const char *const glbt_info_src_8723b_2ant[] = {
"BT Info[bt auto report]",
 };
 
-static u32 glcoex_ver_date_8723b_2ant = 20131113;
-static u32 glcoex_ver_8723b_2ant = 0x3f;
+static const u32 glcoex_ver_date_8723b_2ant = 20131113;
+static const u32 glcoex_ver_8723b_2ant = 0x3f;
 
 static u8 btc8723b2ant_bt_rssi_state(struct btc_coexist *btcoexist,
 u8 level_num, u8 rssi_thresh,
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c
index 39dc5966700b..cb34a33ae99a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c
@@ -38,8 +38,8 @@ static const char *const glbt_info_src_8821a_1ant[] = {
  "BT Info[bt auto report]",
 };
 
-static u32 glcoex_ver_date_8821a_1ant = 20130816;
-static u32 glcoex_ver_8821a_1ant = 0x41;
+static const u32 glcoex_ver_date_8821a_1ant = 20130816;
+static const u32 glcoex_ver_8821a_1ant = 0x41;
 
 static u8 btc8821a1ant_bt_rssi_state(struct btc_coexist *btcoexist,
 u8 level_num, u8 rssi_thresh,
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
index 264796616d8a..14510d514e2f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a2ant.c
@@ -36,8 +36,8 @@ static const char *const glbt_info_src_8821a_2ant[] = {
"BT Info[bt auto report]",
 };
 
-static u32 glcoex_ver_date_8821a_2ant = 20130618;
-static u32 glcoex_ver_8821a_2ant = 0x5050;
+static const u32 glcoex_ver_date_8821a_2ant = 20130618;
+static const u32 glcoex_ver_8821a_2ant = 0x5050;
 
 static u8 btc8821a2ant_bt_rssi_state(struct btc_coexist *btcoexist,
 u8 level_num, u8 rssi_thresh,
-- 
2.15.1

[PATCH v2 3/9] rtlwifi: btcoex: Add 8822b header files to precomp.h

[pkshih]

From: Ping-Ke Shih 

Add 8822b header files to precomp.h for routing functions.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
index 02dff4c3f664..858318fd3d63 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
@@ -48,6 +48,9 @@
 #include "halbtc8723b2ant.h"
 #include "halbtc8821a2ant.h"
 #include "halbtc8821a1ant.h"
+#include "halbtc8822b1ant.h"
+#include "halbtc8822b2ant.h"
+#include "halbtc8822bwifionly.h"
 
 #define GetDefaultAdapter(padapter)padapter
 
-- 
2.15.1

[PATCH v2 9/9] rtlwifi: btcoex: Remove global variables of chip specific context

[pkshih]

From: Ping-Ke Shih 

Remove the global varaibles, and use local varialbes that point the fields
defined in 'struct btc_coexist' instead, so it is possible to support
multiple devices.

Signed-off-by: Ping-Ke Shih 
---
 .../realtek/rtlwifi/btcoexist/halbtc8192e2ant.c| 44 --
 .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c| 56 +++--
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c| 57 +++--
 .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c| 45 +-
 .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c| 39 +++--
 .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.c| 78 --
 .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.c| 95 --
 7 files changed, 376 insertions(+), 38 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
index a4704b2fbeb9..b85e42628bac 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
@@ -25,11 +25,6 @@
 
 #include "halbt_precomp.h"
 
-static struct coex_dm_8192e_2ant glcoex_dm_8192e_2ant;
-static struct coex_dm_8192e_2ant *coex_dm = _dm_8192e_2ant;
-static struct coex_sta_8192e_2ant glcoex_sta_8192e_2ant;
-static struct coex_sta_8192e_2ant *coex_sta = _sta_8192e_2ant;
-
 static const char *const glbt_info_src_8192e_2ant[] = {
"BT Info[wifi fw]",
"BT Info[bt rsp]",
@@ -44,6 +39,7 @@ static u8 btc8192e2ant_bt_rssi_state(struct btc_coexist 
*btcoexist,
 u8 rssi_thresh1)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct coex_sta_8192e_2ant *coex_sta = >coex_sta_8192e_2ant;
int bt_rssi = 0;
u8 bt_rssi_state = coex_sta->pre_bt_rssi_state;
 
@@ -106,6 +102,7 @@ static u8 btc8192e2ant_wifi_rssi_state(struct btc_coexist 
*btcoexist,
   u8 rssi_thresh1)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct coex_sta_8192e_2ant *coex_sta = >coex_sta_8192e_2ant;
int wifi_rssi = 0;
u8 wifi_rssi_state = coex_sta->pre_wifi_rssi_state[index];
 
@@ -171,6 +168,7 @@ static void btc8192e2ant_monitor_bt_enable_disable(struct 
btc_coexist
   *btcoexist)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct coex_sta_8192e_2ant *coex_sta = >coex_sta_8192e_2ant;
static bool pre_bt_disabled;
static u32 bt_disable_cnt;
bool bt_active = true, bt_disabled = false;
@@ -252,6 +250,7 @@ static u32 btc8192e2ant_decide_ra_mask(struct btc_coexist 
*btcoexist,
 static void btc8192e2ant_update_ra_mask(struct btc_coexist *btcoexist,
bool force_exec, u32 dis_rate_mask)
 {
+   struct coex_dm_8192e_2ant *coex_dm = >coex_dm_8192e_2ant;
coex_dm->cur_ra_mask = dis_rate_mask;
 
if (force_exec || (coex_dm->pre_ra_mask != coex_dm->cur_ra_mask))
@@ -263,6 +262,7 @@ static void btc8192e2ant_update_ra_mask(struct btc_coexist 
*btcoexist,
 static void btc8192e2ant_auto_rate_fallback_retry(struct btc_coexist 
*btcoexist,
  bool force_exec, u8 type)
 {
+   struct coex_dm_8192e_2ant *coex_dm = >coex_dm_8192e_2ant;
bool wifi_under_b_mode = false;
 
coex_dm->cur_arfr_type = type;
@@ -302,6 +302,7 @@ static void btc8192e2ant_auto_rate_fallback_retry(struct 
btc_coexist *btcoexist,
 static void btc8192e2ant_retry_limit(struct btc_coexist *btcoexist,
 bool force_exec, u8 type)
 {
+   struct coex_dm_8192e_2ant *coex_dm = >coex_dm_8192e_2ant;
coex_dm->cur_retry_limit_type = type;
 
if (force_exec || (coex_dm->pre_retry_limit_type !=
@@ -325,6 +326,7 @@ static void btc8192e2ant_retry_limit(struct btc_coexist 
*btcoexist,
 static void btc8192e2ant_ampdu_maxtime(struct btc_coexist *btcoexist,
   bool force_exec, u8 type)
 {
+   struct coex_dm_8192e_2ant *coex_dm = >coex_dm_8192e_2ant;
coex_dm->cur_ampdu_time_type = type;
 
if (force_exec || (coex_dm->pre_ampdu_time_type !=
@@ -350,6 +352,7 @@ static void btc8192e2ant_limited_tx(struct btc_coexist 
*btcoexist,
u8 arfr_type, u8 retry_limit_type,
u8 ampdu_time_type)
 {
+   struct coex_dm_8192e_2ant *coex_dm = >coex_dm_8192e_2ant;
u32 dis_ra_mask = 0x0;
 
coex_dm->cur_ra_mask_type = ra_mask_type;
@@ -390,6 +393,7 @@ static void btc8192e2ant_limited_rx(struct btc_coexist 
*btcoexist,
 static void btc8192e2ant_monitor_bt_ctr(struct btc_coexist *btcoexist)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct coex_sta_8192e_2ant *coex_sta = >coex_sta_8192e_2ant;
u32 reg_hp_txrx, 

[PATCH v2 3/9] rtlwifi: btcoex: Add 8822b header files to precomp.h

[pkshih]

From: Ping-Ke Shih 

Add 8822b header files to precomp.h for routing functions.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
index 02dff4c3f664..858318fd3d63 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbt_precomp.h
@@ -48,6 +48,9 @@
 #include "halbtc8723b2ant.h"
 #include "halbtc8821a2ant.h"
 #include "halbtc8821a1ant.h"
+#include "halbtc8822b1ant.h"
+#include "halbtc8822b2ant.h"
+#include "halbtc8822bwifionly.h"
 
 #define GetDefaultAdapter(padapter)padapter
 
-- 
2.15.1

[PATCH v2 9/9] rtlwifi: btcoex: Remove global variables of chip specific context

[pkshih]

From: Ping-Ke Shih 

Remove the global varaibles, and use local varialbes that point the fields
defined in 'struct btc_coexist' instead, so it is possible to support
multiple devices.

Signed-off-by: Ping-Ke Shih 
---
 .../realtek/rtlwifi/btcoexist/halbtc8192e2ant.c| 44 --
 .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c| 56 +++--
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c| 57 +++--
 .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c| 45 +-
 .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c| 39 +++--
 .../realtek/rtlwifi/btcoexist/halbtc8822b1ant.c| 78 --
 .../realtek/rtlwifi/btcoexist/halbtc8822b2ant.c| 95 --
 7 files changed, 376 insertions(+), 38 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
index a4704b2fbeb9..b85e42628bac 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
@@ -25,11 +25,6 @@
 
 #include "halbt_precomp.h"
 
-static struct coex_dm_8192e_2ant glcoex_dm_8192e_2ant;
-static struct coex_dm_8192e_2ant *coex_dm = _dm_8192e_2ant;
-static struct coex_sta_8192e_2ant glcoex_sta_8192e_2ant;
-static struct coex_sta_8192e_2ant *coex_sta = _sta_8192e_2ant;
-
 static const char *const glbt_info_src_8192e_2ant[] = {
"BT Info[wifi fw]",
"BT Info[bt rsp]",
@@ -44,6 +39,7 @@ static u8 btc8192e2ant_bt_rssi_state(struct btc_coexist 
*btcoexist,
 u8 rssi_thresh1)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct coex_sta_8192e_2ant *coex_sta = >coex_sta_8192e_2ant;
int bt_rssi = 0;
u8 bt_rssi_state = coex_sta->pre_bt_rssi_state;
 
@@ -106,6 +102,7 @@ static u8 btc8192e2ant_wifi_rssi_state(struct btc_coexist 
*btcoexist,
   u8 rssi_thresh1)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct coex_sta_8192e_2ant *coex_sta = >coex_sta_8192e_2ant;
int wifi_rssi = 0;
u8 wifi_rssi_state = coex_sta->pre_wifi_rssi_state[index];
 
@@ -171,6 +168,7 @@ static void btc8192e2ant_monitor_bt_enable_disable(struct 
btc_coexist
   *btcoexist)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct coex_sta_8192e_2ant *coex_sta = >coex_sta_8192e_2ant;
static bool pre_bt_disabled;
static u32 bt_disable_cnt;
bool bt_active = true, bt_disabled = false;
@@ -252,6 +250,7 @@ static u32 btc8192e2ant_decide_ra_mask(struct btc_coexist 
*btcoexist,
 static void btc8192e2ant_update_ra_mask(struct btc_coexist *btcoexist,
bool force_exec, u32 dis_rate_mask)
 {
+   struct coex_dm_8192e_2ant *coex_dm = >coex_dm_8192e_2ant;
coex_dm->cur_ra_mask = dis_rate_mask;
 
if (force_exec || (coex_dm->pre_ra_mask != coex_dm->cur_ra_mask))
@@ -263,6 +262,7 @@ static void btc8192e2ant_update_ra_mask(struct btc_coexist 
*btcoexist,
 static void btc8192e2ant_auto_rate_fallback_retry(struct btc_coexist 
*btcoexist,
  bool force_exec, u8 type)
 {
+   struct coex_dm_8192e_2ant *coex_dm = >coex_dm_8192e_2ant;
bool wifi_under_b_mode = false;
 
coex_dm->cur_arfr_type = type;
@@ -302,6 +302,7 @@ static void btc8192e2ant_auto_rate_fallback_retry(struct 
btc_coexist *btcoexist,
 static void btc8192e2ant_retry_limit(struct btc_coexist *btcoexist,
 bool force_exec, u8 type)
 {
+   struct coex_dm_8192e_2ant *coex_dm = >coex_dm_8192e_2ant;
coex_dm->cur_retry_limit_type = type;
 
if (force_exec || (coex_dm->pre_retry_limit_type !=
@@ -325,6 +326,7 @@ static void btc8192e2ant_retry_limit(struct btc_coexist 
*btcoexist,
 static void btc8192e2ant_ampdu_maxtime(struct btc_coexist *btcoexist,
   bool force_exec, u8 type)
 {
+   struct coex_dm_8192e_2ant *coex_dm = >coex_dm_8192e_2ant;
coex_dm->cur_ampdu_time_type = type;
 
if (force_exec || (coex_dm->pre_ampdu_time_type !=
@@ -350,6 +352,7 @@ static void btc8192e2ant_limited_tx(struct btc_coexist 
*btcoexist,
u8 arfr_type, u8 retry_limit_type,
u8 ampdu_time_type)
 {
+   struct coex_dm_8192e_2ant *coex_dm = >coex_dm_8192e_2ant;
u32 dis_ra_mask = 0x0;
 
coex_dm->cur_ra_mask_type = ra_mask_type;
@@ -390,6 +393,7 @@ static void btc8192e2ant_limited_rx(struct btc_coexist 
*btcoexist,
 static void btc8192e2ant_monitor_bt_ctr(struct btc_coexist *btcoexist)
 {
struct rtl_priv *rtlpriv = btcoexist->adapter;
+   struct coex_sta_8192e_2ant *coex_sta = >coex_sta_8192e_2ant;
u32 reg_hp_txrx, reg_lp_txrx, u32tmp;
u32 reg_hp_tx = 

[PATCH v2 6/9] rtlwifi: btcoex: remove comments that are not meaningful

[pkshih]

From: Ping-Ke Shih 

The comments aren't meaningful and the use of '***...***' isn't upstream
style, so remove them. This patch doesn't change any code.

Signed-off-by: Ping-Ke Shih 
---
 .../realtek/rtlwifi/btcoexist/halbtc8192e2ant.c| 22 +---
 .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c| 24 +-
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c| 23 ++---
 .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c| 22 +---
 .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c| 23 +
 5 files changed, 6 insertions(+), 108 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
index 8fce371749d3..959af05117d7 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
@@ -22,23 +22,9 @@
  * Larry Finger 
  *
  */
-/**
- * Description:
- *
- * This file is for RTL8192E Co-exist mechanism
- *
- * History
- * 2012/11/15 Cosa first check in.
- *
- **/
 
-/**
- *   include files
- **/
 #include "halbt_precomp.h"
-/**
- *   Global variables, these are static variables
- **/
+
 static struct coex_dm_8192e_2ant glcoex_dm_8192e_2ant;
 static struct coex_dm_8192e_2ant *coex_dm = _dm_8192e_2ant;
 static struct coex_sta_8192e_2ant glcoex_sta_8192e_2ant;
@@ -53,12 +39,6 @@ static const char *const glbt_info_src_8192e_2ant[] = {
 static u32 glcoex_ver_date_8192e_2ant = 20130902;
 static u32 glcoex_ver_8192e_2ant = 0x34;
 
-/**
- *   local function proto type if needed
- **/
-/**
- *   local function start with btc8192e2ant_
- **/
 static u8 btc8192e2ant_bt_rssi_state(struct btc_coexist *btcoexist,
 u8 level_num, u8 rssi_thresh,
 u8 rssi_thresh1)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
index 59553db020ef..e97e907e66cd 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
@@ -23,23 +23,8 @@
  *
  */
 
-/***
- * Description:
- *
- * This file is for RTL8723B Co-exist mechanism
- *
- * History
- * 2012/11/15 Cosa first check in.
- *
- ***/
-
-/***
- * include files
- ***/
 #include "halbt_precomp.h"
-/***
- * Global variables, these are static variables
- ***/
+
 static struct coex_dm_8723b_1ant glcoex_dm_8723b_1ant;
 static struct coex_dm_8723b_1ant *coex_dm = _dm_8723b_1ant;
 static struct coex_sta_8723b_1ant glcoex_sta_8723b_1ant;
@@ -54,13 +39,6 @@ static const char *const glbt_info_src_8723b_1ant[] = {
 static u32 glcoex_ver_date_8723b_1ant = 20130918;
 static u32 glcoex_ver_8723b_1ant = 0x47;
 
-/***
- * local function proto type if needed
- ***/
-/***
- * local function start with halbtc8723b1ant_
- ***/
-
 static void halbtc8723b1ant_updatera_mask(struct btc_coexist *btcoexist,
  bool force_exec, u32 dis_rate_mask)
 {
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 73ec31972944..e9a7f303cdda 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -22,22 +22,9 @@
  * Larry Finger 
  *
  

[PATCH v2 5/9] rtlwifi: btcoex: Add 8822b to Makefile

[pkshih]

From: Ping-Ke Shih 

Add btcoex of 8822b to Makefile.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
index d15c58737388..37108c379bd0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
@@ -4,6 +4,9 @@ btcoexist-objs :=   halbtc8192e2ant.o   \
halbtc8723b2ant.o   \
halbtc8821a1ant.o   \
halbtc8821a2ant.o   \
+   halbtc8822b1ant.o   \
+   halbtc8822b2ant.o   \
+   halbtc8822bwifionly.o   \
halbtcoutsrc.o  \
rtl_btc.o
 
-- 
2.15.1

[PATCH v2 6/9] rtlwifi: btcoex: remove comments that are not meaningful

[pkshih]

From: Ping-Ke Shih 

The comments aren't meaningful and the use of '***...***' isn't upstream
style, so remove them. This patch doesn't change any code.

Signed-off-by: Ping-Ke Shih 
---
 .../realtek/rtlwifi/btcoexist/halbtc8192e2ant.c| 22 +---
 .../realtek/rtlwifi/btcoexist/halbtc8723b1ant.c| 24 +-
 .../realtek/rtlwifi/btcoexist/halbtc8723b2ant.c| 23 ++---
 .../realtek/rtlwifi/btcoexist/halbtc8821a1ant.c| 22 +---
 .../realtek/rtlwifi/btcoexist/halbtc8821a2ant.c| 23 +
 5 files changed, 6 insertions(+), 108 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
index 8fce371749d3..959af05117d7 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8192e2ant.c
@@ -22,23 +22,9 @@
  * Larry Finger 
  *
  */
-/**
- * Description:
- *
- * This file is for RTL8192E Co-exist mechanism
- *
- * History
- * 2012/11/15 Cosa first check in.
- *
- **/
 
-/**
- *   include files
- **/
 #include "halbt_precomp.h"
-/**
- *   Global variables, these are static variables
- **/
+
 static struct coex_dm_8192e_2ant glcoex_dm_8192e_2ant;
 static struct coex_dm_8192e_2ant *coex_dm = _dm_8192e_2ant;
 static struct coex_sta_8192e_2ant glcoex_sta_8192e_2ant;
@@ -53,12 +39,6 @@ static const char *const glbt_info_src_8192e_2ant[] = {
 static u32 glcoex_ver_date_8192e_2ant = 20130902;
 static u32 glcoex_ver_8192e_2ant = 0x34;
 
-/**
- *   local function proto type if needed
- **/
-/**
- *   local function start with btc8192e2ant_
- **/
 static u8 btc8192e2ant_bt_rssi_state(struct btc_coexist *btcoexist,
 u8 level_num, u8 rssi_thresh,
 u8 rssi_thresh1)
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
index 59553db020ef..e97e907e66cd 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b1ant.c
@@ -23,23 +23,8 @@
  *
  */
 
-/***
- * Description:
- *
- * This file is for RTL8723B Co-exist mechanism
- *
- * History
- * 2012/11/15 Cosa first check in.
- *
- ***/
-
-/***
- * include files
- ***/
 #include "halbt_precomp.h"
-/***
- * Global variables, these are static variables
- ***/
+
 static struct coex_dm_8723b_1ant glcoex_dm_8723b_1ant;
 static struct coex_dm_8723b_1ant *coex_dm = _dm_8723b_1ant;
 static struct coex_sta_8723b_1ant glcoex_sta_8723b_1ant;
@@ -54,13 +39,6 @@ static const char *const glbt_info_src_8723b_1ant[] = {
 static u32 glcoex_ver_date_8723b_1ant = 20130918;
 static u32 glcoex_ver_8723b_1ant = 0x47;
 
-/***
- * local function proto type if needed
- ***/
-/***
- * local function start with halbtc8723b1ant_
- ***/
-
 static void halbtc8723b1ant_updatera_mask(struct btc_coexist *btcoexist,
  bool force_exec, u32 dis_rate_mask)
 {
diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
index 73ec31972944..e9a7f303cdda 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c
@@ -22,22 +22,9 @@
  * Larry Finger 
  *
  */

[PATCH v2 5/9] rtlwifi: btcoex: Add 8822b to Makefile

[pkshih]

From: Ping-Ke Shih 

Add btcoex of 8822b to Makefile.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile 
b/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
index d15c58737388..37108c379bd0 100644
--- a/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
+++ b/drivers/net/wireless/realtek/rtlwifi/btcoexist/Makefile
@@ -4,6 +4,9 @@ btcoexist-objs :=   halbtc8192e2ant.o   \
halbtc8723b2ant.o   \
halbtc8821a1ant.o   \
halbtc8821a2ant.o   \
+   halbtc8822b1ant.o   \
+   halbtc8822b2ant.o   \
+   halbtc8822bwifionly.o   \
halbtcoutsrc.o  \
rtl_btc.o
 
-- 
2.15.1

Re: [rtlwifi-btcoex] Suspicious code in halbtc8821a1ant driver

[Pkshih]

On Thu, 2018-04-05 at 01:25 +, Gustavo A. R. Silva wrote:
> Hi all,
> 
> While doing some static analysis I came across the following piece of code at
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c:1581:
> 
> 1581 static void btc8821a1ant_act_bt_sco_hid_only_busy(struct btc_coexist 
> *btcoexist,
> 1582   u8 wifi_status)
> 1583 {
> 1584 /* tdma and coex table */
> 1585 btc8821a1ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 5);
> 1586 
> 1587 if (BT_8821A_1ANT_WIFI_STATUS_NON_CONNECTED_ASSO_AUTH_SCAN ==
> 1588 wifi_status)
> 1589 btc8821a1ant_coex_table_with_type(btcoexist, 
> NORMAL_EXEC, 1);
> 1590 else
> 1591 btc8821a1ant_coex_table_with_type(btcoexist, 
> NORMAL_EXEC, 1);
> 1592 }
> 
> The issue here is that the code for both branches of the if-else statement is 
> identical.
> 
> The if-else was introduced a year ago in this commit c6821613e653
> 
> I wonder if an argument should be changed in any of the calls to
> btc8821a1ant_coex_table_with_type?
> 
> 

It looks weird. Since we're in spring vacation, I'll check my colleague next 
Monday.

PK

Re: [rtlwifi-btcoex] Suspicious code in halbtc8821a1ant driver

[Pkshih]

On Thu, 2018-04-05 at 01:25 +, Gustavo A. R. Silva wrote:
> Hi all,
> 
> While doing some static analysis I came across the following piece of code at
> drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8821a1ant.c:1581:
> 
> 1581 static void btc8821a1ant_act_bt_sco_hid_only_busy(struct btc_coexist 
> *btcoexist,
> 1582   u8 wifi_status)
> 1583 {
> 1584 /* tdma and coex table */
> 1585 btc8821a1ant_ps_tdma(btcoexist, NORMAL_EXEC, true, 5);
> 1586 
> 1587 if (BT_8821A_1ANT_WIFI_STATUS_NON_CONNECTED_ASSO_AUTH_SCAN ==
> 1588 wifi_status)
> 1589 btc8821a1ant_coex_table_with_type(btcoexist, 
> NORMAL_EXEC, 1);
> 1590 else
> 1591 btc8821a1ant_coex_table_with_type(btcoexist, 
> NORMAL_EXEC, 1);
> 1592 }
> 
> The issue here is that the code for both branches of the if-else statement is 
> identical.
> 
> The if-else was introduced a year ago in this commit c6821613e653
> 
> I wonder if an argument should be changed in any of the calls to
> btc8821a1ant_coex_table_with_type?
> 
> 

It looks weird. Since we're in spring vacation, I'll check my colleague next 
Monday.

PK

Re: [PATCH 06/12] wireless: Convert simple uses of a static const Ethernet broadcast address

[Pkshih]

On Sat, 2018-03-31 at 00:05 -0700, Joe Perches wrote:
> Use the new ether_broadcast_addr global instead to save some object code.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/net/wireless/admtek/adm8211.c   | 3 +--
>  drivers/net/wireless/ath/carl9170/mac.c | 4 +---
>  drivers/net/wireless/broadcom/b43/main.c| 3 +--
>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 3 +--
>  drivers/net/wireless/realtek/rtlwifi/core.c | 5 ++---
>  drivers/net/wireless/rndis_wlan.c   | 6 +-
>  drivers/net/wireless/ti/wl1251/main.c   | 5 +
>  drivers/net/wireless/ti/wlcore/main.c   | 5 +
>  8 files changed, 9 insertions(+), 25 deletions(-)
> 
>  
> diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c
> b/drivers/net/wireless/realtek/rtlwifi/core.c
> index cfea57efa7f4..8c534a93dad5 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/core.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
> @@ -1527,7 +1527,6 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum 
> set_key_cmd cmd,
>   bool wep_only = false;
>   int err = 0;
>   u8 mac_addr[ETH_ALEN];
> - u8 bcast_addr[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
>  
>   rtlpriv->btcoexist.btc_info.in_4way = false;
>  
> @@ -1544,7 +1543,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum 
> set_key_cmd cmd,
>   RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
>    "%s hardware based encryption for keyidx: %d, mac: %pM\n",
>     cmd == SET_KEY ? "Using" : "Disabling", key->keyidx,
> -   sta ? sta->addr : bcast_addr);
> +   sta ? sta->addr : ether_broadcast_addr);
>   rtlpriv->sec.being_setkey = true;
>   rtl_ips_nic_on(hw);
>   mutex_lock(>locks.conf_mutex);
> @@ -1649,7 +1648,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum 
> set_key_cmd cmd,
>   memcpy(rtlpriv->sec.key_buf[key_idx],
>      key->key, key->keylen);
>   rtlpriv->sec.key_len[key_idx] = key->keylen;
> - memcpy(mac_addr, bcast_addr, ETH_ALEN);
> + memcpy(mac_addr, ether_broadcast_addr, ETH_ALEN);

Use ether_addr_copy(mac_addr, ether_broadcast_addr) ?


>   } else {/* pairwise key */
>   RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
>    "set pairwise key\n");

Re: [PATCH 06/12] wireless: Convert simple uses of a static const Ethernet broadcast address

[Pkshih]

On Sat, 2018-03-31 at 00:05 -0700, Joe Perches wrote:
> Use the new ether_broadcast_addr global instead to save some object code.
> 
> Signed-off-by: Joe Perches 
> ---
>  drivers/net/wireless/admtek/adm8211.c   | 3 +--
>  drivers/net/wireless/ath/carl9170/mac.c | 4 +---
>  drivers/net/wireless/broadcom/b43/main.c| 3 +--
>  drivers/net/wireless/marvell/mwifiex/cfg80211.c | 3 +--
>  drivers/net/wireless/realtek/rtlwifi/core.c | 5 ++---
>  drivers/net/wireless/rndis_wlan.c   | 6 +-
>  drivers/net/wireless/ti/wl1251/main.c   | 5 +
>  drivers/net/wireless/ti/wlcore/main.c   | 5 +
>  8 files changed, 9 insertions(+), 25 deletions(-)
> 
>  
> diff --git a/drivers/net/wireless/realtek/rtlwifi/core.c
> b/drivers/net/wireless/realtek/rtlwifi/core.c
> index cfea57efa7f4..8c534a93dad5 100644
> --- a/drivers/net/wireless/realtek/rtlwifi/core.c
> +++ b/drivers/net/wireless/realtek/rtlwifi/core.c
> @@ -1527,7 +1527,6 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum 
> set_key_cmd cmd,
>   bool wep_only = false;
>   int err = 0;
>   u8 mac_addr[ETH_ALEN];
> - u8 bcast_addr[ETH_ALEN] = { 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
>  
>   rtlpriv->btcoexist.btc_info.in_4way = false;
>  
> @@ -1544,7 +1543,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum 
> set_key_cmd cmd,
>   RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
>    "%s hardware based encryption for keyidx: %d, mac: %pM\n",
>     cmd == SET_KEY ? "Using" : "Disabling", key->keyidx,
> -   sta ? sta->addr : bcast_addr);
> +   sta ? sta->addr : ether_broadcast_addr);
>   rtlpriv->sec.being_setkey = true;
>   rtl_ips_nic_on(hw);
>   mutex_lock(>locks.conf_mutex);
> @@ -1649,7 +1648,7 @@ static int rtl_op_set_key(struct ieee80211_hw *hw, enum 
> set_key_cmd cmd,
>   memcpy(rtlpriv->sec.key_buf[key_idx],
>      key->key, key->keylen);
>   rtlpriv->sec.key_len[key_idx] = key->keylen;
> - memcpy(mac_addr, bcast_addr, ETH_ALEN);
> + memcpy(mac_addr, ether_broadcast_addr, ETH_ALEN);

Use ether_addr_copy(mac_addr, ether_broadcast_addr) ?


>   } else {/* pairwise key */
>   RT_TRACE(rtlpriv, COMP_SEC, DBG_DMESG,
>    "set pairwise key\n");

Re: [PATCH] rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

[Pkshih]

On Wed, 2018-02-07 at 12:51 -0800, Matthias Kaehlcke wrote:
> El Wed, Feb 07, 2018 at 02:35:59PM -0600 Larry Finger ha dit:
> 
> > On 02/07/2018 02:26 PM, Matthias Kaehlcke wrote:
> > > In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal
> > > is assigned to itself in an if ... else statement, apparently only to
> > > document that the branch condition is handled and that a previously read
> > > value should be returned unmodified. The self-assignment causes clang to
> > > raise the following warning:
> > > 
> > > drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13:
> > >error: explicitly assigning value of variable of type 'u32'
> > >  (aka 'unsigned int') to itself [-Werror,-Wself-assign]
> > >writeVal = writeVal;
> > > 
> > > Replace the self-assignment with a semicolon, which still serves to
> > > document the 'handling' of the branch condition.
> > > 
> > > Signed-off-by: Matthias Kaehlcke 
> > > ---
> > >   drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> > > index 9cff6bc4049c..4db92496c122 100644
> > > --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> > > +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> > > @@ -301,7 +301,7 @@ static void 
> > > _rtl92c_get_txpower_writeval_by_regulatory(struct ieee80211_hw
> *hw,
> > >   writeVal = writeVal - 0x06060606;
> > >   else if (rtlpriv->dm.dynamic_txhighpower_lvl ==
> > >    TXHIGHPWRLEVEL_BT2)
> > > - writeVal = writeVal;
> > > + ;
> > >   *(p_outwriteval + rf) = writeVal;
> > >   }
> > >   }
> > > 
> > 
> > As the branch condition does nothing, why not remove it and save the
> > compiler's optimizer a bit of work? The code looks strange, but it matches
> > the rest of Realtek's USB drivers.

Agree Larry's comment.

> 
> Sure, I am happy to change it to whatever the authors/maintainers prefer.
> 
> I'll wait a bit before respinning for if others feel strongly about
> keeping the branch.
> 
> --Please consider the environment before printing this e-mail.

Re: [PATCH] rtlwifi: rtl8192cu: Remove variable self-assignment in rf.c

[Pkshih]

On Wed, 2018-02-07 at 12:51 -0800, Matthias Kaehlcke wrote:
> El Wed, Feb 07, 2018 at 02:35:59PM -0600 Larry Finger ha dit:
> 
> > On 02/07/2018 02:26 PM, Matthias Kaehlcke wrote:
> > > In _rtl92c_get_txpower_writeval_by_regulatory() the variable writeVal
> > > is assigned to itself in an if ... else statement, apparently only to
> > > document that the branch condition is handled and that a previously read
> > > value should be returned unmodified. The self-assignment causes clang to
> > > raise the following warning:
> > > 
> > > drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c:304:13:
> > >error: explicitly assigning value of variable of type 'u32'
> > >  (aka 'unsigned int') to itself [-Werror,-Wself-assign]
> > >writeVal = writeVal;
> > > 
> > > Replace the self-assignment with a semicolon, which still serves to
> > > document the 'handling' of the branch condition.
> > > 
> > > Signed-off-by: Matthias Kaehlcke 
> > > ---
> > >   drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c | 2 +-
> > >   1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> > > index 9cff6bc4049c..4db92496c122 100644
> > > --- a/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> > > +++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192cu/rf.c
> > > @@ -301,7 +301,7 @@ static void 
> > > _rtl92c_get_txpower_writeval_by_regulatory(struct ieee80211_hw
> *hw,
> > >   writeVal = writeVal - 0x06060606;
> > >   else if (rtlpriv->dm.dynamic_txhighpower_lvl ==
> > >    TXHIGHPWRLEVEL_BT2)
> > > - writeVal = writeVal;
> > > + ;
> > >   *(p_outwriteval + rf) = writeVal;
> > >   }
> > >   }
> > > 
> > 
> > As the branch condition does nothing, why not remove it and save the
> > compiler's optimizer a bit of work? The code looks strange, but it matches
> > the rest of Realtek's USB drivers.

Agree Larry's comment.

> 
> Sure, I am happy to change it to whatever the authors/maintainers prefer.
> 
> I'll wait a bit before respinning for if others feel strongly about
> keeping the branch.
> 
> --Please consider the environment before printing this e-mail.

Re: [PATCH] staging: rtlwifi: remove redundant initialization of 'cfg_cmd'

[Pkshih]

On Fri, 2018-01-26 at 13:52 +, Colin King wrote:
> From: Colin Ian King 
> 
> The initialization of cfg_cmd is redundant as the value is never read
> and it is being re-assigned to cfg_cmd = pwrcfgcmd[ary_idx] inside a
> loop, hence it can be removed.
> 
> Cleans up clang warning:
> drivers/staging/rtlwifi/core.c:1819:22: warning: Value stored to
> 'cfg_cmd' during its initialization is never read
> 
> Signed-off-by: Colin Ian King 

It looks good to me.

Acked-by: Ping-Ke Shih 

> ---
>  drivers/staging/rtlwifi/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/rtlwifi/core.c b/drivers/staging/rtlwifi/core.c
> index a43d37452e8b..3ec039498208 100644
> --- a/drivers/staging/rtlwifi/core.c
> +++ b/drivers/staging/rtlwifi/core.c
> @@ -1816,7 +1816,7 @@ bool rtl_hal_pwrseqcmdparsing(struct rtl_priv *rtlpriv,
> u8 cut_version,
>     u8 faversion, u8 interface_type,
>     struct wlan_pwr_cfg pwrcfgcmd[])
>  {
> - struct wlan_pwr_cfg cfg_cmd = {0};
> + struct wlan_pwr_cfg cfg_cmd;
>   bool polling_bit = false;
>   u32 ary_idx = 0;
>   u8 value = 0;
> -- 
> 2.15.1
> 
> 
> --Please consider the environment before printing this e-mail.

Re: [PATCH] staging: rtlwifi: remove redundant initialization of 'cfg_cmd'

[Pkshih]

On Fri, 2018-01-26 at 13:52 +, Colin King wrote:
> From: Colin Ian King 
> 
> The initialization of cfg_cmd is redundant as the value is never read
> and it is being re-assigned to cfg_cmd = pwrcfgcmd[ary_idx] inside a
> loop, hence it can be removed.
> 
> Cleans up clang warning:
> drivers/staging/rtlwifi/core.c:1819:22: warning: Value stored to
> 'cfg_cmd' during its initialization is never read
> 
> Signed-off-by: Colin Ian King 

It looks good to me.

Acked-by: Ping-Ke Shih 

> ---
>  drivers/staging/rtlwifi/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/rtlwifi/core.c b/drivers/staging/rtlwifi/core.c
> index a43d37452e8b..3ec039498208 100644
> --- a/drivers/staging/rtlwifi/core.c
> +++ b/drivers/staging/rtlwifi/core.c
> @@ -1816,7 +1816,7 @@ bool rtl_hal_pwrseqcmdparsing(struct rtl_priv *rtlpriv,
> u8 cut_version,
>     u8 faversion, u8 interface_type,
>     struct wlan_pwr_cfg pwrcfgcmd[])
>  {
> - struct wlan_pwr_cfg cfg_cmd = {0};
> + struct wlan_pwr_cfg cfg_cmd;
>   bool polling_bit = false;
>   u32 ary_idx = 0;
>   u8 value = 0;
> -- 
> 2.15.1
> 
> 
> --Please consider the environment before printing this e-mail.

[PATCH] rtlwifi: Remove seq_number from rtl_tid_data

[pkshih]

From: Ping-Ke Shih 

Since mac80211 maintains the sequence number for each STA/TID,
driver doesn't need to maintain a copy.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/base.c |  6 ++
 drivers/net/wireless/realtek/rtlwifi/pci.c  | 17 -
 drivers/net/wireless/realtek/rtlwifi/usb.c  | 17 -
 drivers/net/wireless/realtek/rtlwifi/wifi.h |  1 -
 4 files changed, 2 insertions(+), 39 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index 0b34886321f1..9f35b25bddf2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -1618,9 +1618,8 @@ int rtl_tx_agg_start(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
 
RT_TRACE(rtlpriv, COMP_SEND, DBG_DMESG,
 "on ra = %pM tid = %d seq:%d\n", sta->addr, tid,
-tid_data->seq_number);
+*ssn);
 
-   *ssn = tid_data->seq_number;
tid_data->agg.agg_state = RTL_AGG_START;
 
ieee80211_start_tx_ba_cb_irqsafe(vif, sta->addr, tid);
@@ -1679,8 +1678,7 @@ int rtl_rx_agg_start(struct ieee80211_hw *hw,
tid_data = _entry->tids[tid];
 
RT_TRACE(rtlpriv, COMP_RECV, DBG_DMESG,
-"on ra = %pM tid = %d seq:%d\n", sta->addr, tid,
-tid_data->seq_number);
+"on ra = %pM tid = %d\n", sta->addr, tid);
 
tid_data->agg.rx_agg_state = RTL_RX_AGG_START;
return 0;
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index b9a6d23364be..eb12818b46b3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1623,7 +1623,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
  struct rtl_tcb_desc *ptcb_desc)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_sta_info *sta_entry = NULL;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct rtl8192_tx_ring *ring;
struct rtl_tx_desc *pdesc;
@@ -1635,9 +1634,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
__le16 fc = rtl_get_fc(skb);
u8 *pda_addr = hdr->addr1;
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-   /*ssn */
-   u8 tid = 0;
-   u16 seq_number = 0;
u8 own;
u8 temp_one = 1;
 
@@ -1699,19 +1695,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
return skb->len;
}
 
-   if (ieee80211_is_data_qos(fc)) {
-   tid = rtl_get_tid(skb);
-   if (sta) {
-   sta_entry = (struct rtl_sta_info *)sta->drv_priv;
-   seq_number = (le16_to_cpu(hdr->seq_ctrl) &
- IEEE80211_SCTL_SEQ) >> 4;
-   seq_number += 1;
-
-   if (!ieee80211_has_morefrags(hdr->frame_control))
-   sta_entry->tids[tid].seq_number = seq_number;
-   }
-   }
-
if (ieee80211_is_data(fc))
rtlpriv->cfg->ops->led_control(hw, LED_CTL_TX);
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c 
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 5590d07d0918..39b033b3b53a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -952,17 +952,12 @@ static void _rtl_usb_tx_preprocess(struct ieee80211_hw 
*hw,
   u16 hw_queue)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct rtl_tx_desc *pdesc = NULL;
struct rtl_tcb_desc tcb_desc;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
__le16 fc = hdr->frame_control;
u8 *pda_addr = hdr->addr1;
-   /* ssn */
-   u8 *qc = NULL;
-   u8 tid = 0;
-   u16 seq_number = 0;
 
memset(_desc, 0, sizeof(struct rtl_tcb_desc));
if (ieee80211_is_auth(fc)) {
@@ -983,20 +978,8 @@ static void _rtl_usb_tx_preprocess(struct ieee80211_hw *hw,
rtlpriv->stats.txbytesbroadcast += skb->len;
else
rtlpriv->stats.txbytesunicast += skb->len;
-   if (ieee80211_is_data_qos(fc)) {
-   qc = ieee80211_get_qos_ctl(hdr);
-   tid = qc[0] & IEEE80211_QOS_CTL_TID_MASK;
-   seq_number = (le16_to_cpu(hdr->seq_ctrl) &
-IEEE80211_SCTL_SEQ) >> 4;
-   seq_number += 1;
-   seq_number <<= 4;
-   }
rtlpriv->cfg->ops->fill_tx_desc(hw, hdr, (u8 *)pdesc, NULL, info, sta, 
skb,
hw_queue, _desc);
-   if (!ieee80211_has_morefrags(hdr->frame_control)) {
-   if (qc)
-   

[PATCH] rtlwifi: Remove seq_number from rtl_tid_data

[pkshih]

From: Ping-Ke Shih 

Since mac80211 maintains the sequence number for each STA/TID,
driver doesn't need to maintain a copy.

Signed-off-by: Ping-Ke Shih 
---
 drivers/net/wireless/realtek/rtlwifi/base.c |  6 ++
 drivers/net/wireless/realtek/rtlwifi/pci.c  | 17 -
 drivers/net/wireless/realtek/rtlwifi/usb.c  | 17 -
 drivers/net/wireless/realtek/rtlwifi/wifi.h |  1 -
 4 files changed, 2 insertions(+), 39 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/base.c 
b/drivers/net/wireless/realtek/rtlwifi/base.c
index 0b34886321f1..9f35b25bddf2 100644
--- a/drivers/net/wireless/realtek/rtlwifi/base.c
+++ b/drivers/net/wireless/realtek/rtlwifi/base.c
@@ -1618,9 +1618,8 @@ int rtl_tx_agg_start(struct ieee80211_hw *hw, struct 
ieee80211_vif *vif,
 
RT_TRACE(rtlpriv, COMP_SEND, DBG_DMESG,
 "on ra = %pM tid = %d seq:%d\n", sta->addr, tid,
-tid_data->seq_number);
+*ssn);
 
-   *ssn = tid_data->seq_number;
tid_data->agg.agg_state = RTL_AGG_START;
 
ieee80211_start_tx_ba_cb_irqsafe(vif, sta->addr, tid);
@@ -1679,8 +1678,7 @@ int rtl_rx_agg_start(struct ieee80211_hw *hw,
tid_data = _entry->tids[tid];
 
RT_TRACE(rtlpriv, COMP_RECV, DBG_DMESG,
-"on ra = %pM tid = %d seq:%d\n", sta->addr, tid,
-tid_data->seq_number);
+"on ra = %pM tid = %d\n", sta->addr, tid);
 
tid_data->agg.rx_agg_state = RTL_RX_AGG_START;
return 0;
diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index b9a6d23364be..eb12818b46b3 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -1623,7 +1623,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
  struct rtl_tcb_desc *ptcb_desc)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_sta_info *sta_entry = NULL;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct rtl8192_tx_ring *ring;
struct rtl_tx_desc *pdesc;
@@ -1635,9 +1634,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
__le16 fc = rtl_get_fc(skb);
u8 *pda_addr = hdr->addr1;
struct rtl_pci *rtlpci = rtl_pcidev(rtl_pcipriv(hw));
-   /*ssn */
-   u8 tid = 0;
-   u16 seq_number = 0;
u8 own;
u8 temp_one = 1;
 
@@ -1699,19 +1695,6 @@ static int rtl_pci_tx(struct ieee80211_hw *hw,
return skb->len;
}
 
-   if (ieee80211_is_data_qos(fc)) {
-   tid = rtl_get_tid(skb);
-   if (sta) {
-   sta_entry = (struct rtl_sta_info *)sta->drv_priv;
-   seq_number = (le16_to_cpu(hdr->seq_ctrl) &
- IEEE80211_SCTL_SEQ) >> 4;
-   seq_number += 1;
-
-   if (!ieee80211_has_morefrags(hdr->frame_control))
-   sta_entry->tids[tid].seq_number = seq_number;
-   }
-   }
-
if (ieee80211_is_data(fc))
rtlpriv->cfg->ops->led_control(hw, LED_CTL_TX);
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/usb.c 
b/drivers/net/wireless/realtek/rtlwifi/usb.c
index 5590d07d0918..39b033b3b53a 100644
--- a/drivers/net/wireless/realtek/rtlwifi/usb.c
+++ b/drivers/net/wireless/realtek/rtlwifi/usb.c
@@ -952,17 +952,12 @@ static void _rtl_usb_tx_preprocess(struct ieee80211_hw 
*hw,
   u16 hw_queue)
 {
struct rtl_priv *rtlpriv = rtl_priv(hw);
-   struct rtl_mac *mac = rtl_mac(rtl_priv(hw));
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct rtl_tx_desc *pdesc = NULL;
struct rtl_tcb_desc tcb_desc;
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)(skb->data);
__le16 fc = hdr->frame_control;
u8 *pda_addr = hdr->addr1;
-   /* ssn */
-   u8 *qc = NULL;
-   u8 tid = 0;
-   u16 seq_number = 0;
 
memset(_desc, 0, sizeof(struct rtl_tcb_desc));
if (ieee80211_is_auth(fc)) {
@@ -983,20 +978,8 @@ static void _rtl_usb_tx_preprocess(struct ieee80211_hw *hw,
rtlpriv->stats.txbytesbroadcast += skb->len;
else
rtlpriv->stats.txbytesunicast += skb->len;
-   if (ieee80211_is_data_qos(fc)) {
-   qc = ieee80211_get_qos_ctl(hdr);
-   tid = qc[0] & IEEE80211_QOS_CTL_TID_MASK;
-   seq_number = (le16_to_cpu(hdr->seq_ctrl) &
-IEEE80211_SCTL_SEQ) >> 4;
-   seq_number += 1;
-   seq_number <<= 4;
-   }
rtlpriv->cfg->ops->fill_tx_desc(hw, hdr, (u8 *)pdesc, NULL, info, sta, 
skb,
hw_queue, _desc);
-   if (!ieee80211_has_morefrags(hdr->frame_control)) {
-   if (qc)
-   mac->tids[tid].seq_number = seq_number;
-