* [PATCH] mt76: mt7615: introduce mt7615_mcu_send_ram_firmware routine
From: Lorenzo Bianconi @ 2019-07-02 11:39 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
Add mt7615_mcu_send_ram_firmware routine since mt7615_load_ram runs the
same code to send ram firmware to cr4 and n9 mcus. Moreover rename
gen_dl_mode in mt7615_mcu_gen_dl_mode.
This patch does not introduce any behaviour change, it is just code
refactor.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
.../net/wireless/mediatek/mt76/mt7615/mcu.c | 90 +++++++++----------
1 file changed, 42 insertions(+), 48 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 0e72cda52343..03aedf5076ca 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -380,7 +380,7 @@ static int mt7615_load_patch(struct mt7615_dev *dev)
return ret;
}
-static u32 gen_dl_mode(u8 feature_set, bool is_cr4)
+static u32 mt7615_mcu_gen_dl_mode(u8 feature_set, bool is_cr4)
{
u32 ret = 0;
@@ -394,14 +394,45 @@ static u32 gen_dl_mode(u8 feature_set, bool is_cr4)
return ret;
}
+static int
+mt7615_mcu_send_ram_firmware(struct mt7615_dev *dev,
+ const struct mt7615_fw_trailer *hdr,
+ const u8 *data, bool is_cr4)
+{
+ int n_region = is_cr4 ? CR4_REGION_NUM : N9_REGION_NUM;
+ int err, i, offset = 0;
+ u32 len, addr, mode;
+
+ for (i = 0; i < n_region; i++) {
+ mode = mt7615_mcu_gen_dl_mode(hdr[i].feature_set, is_cr4);
+ len = le32_to_cpu(hdr[i].len) + IMG_CRC_LEN;
+ addr = le32_to_cpu(hdr[i].addr);
+
+ err = mt7615_mcu_init_download(dev, addr, len, mode);
+ if (err) {
+ dev_err(dev->mt76.dev, "Download request failed\n");
+ return err;
+ }
+
+ err = mt7615_mcu_send_firmware(dev, data + offset, len);
+ if (err) {
+ dev_err(dev->mt76.dev, "Failed to send firmware to device\n");
+ return err;
+ }
+
+ offset += len;
+ }
+
+ return 0;
+}
+
static int mt7615_load_ram(struct mt7615_dev *dev)
{
const struct firmware *fw;
const struct mt7615_fw_trailer *hdr;
const char *n9_firmware = MT7615_FIRMWARE_N9;
const char *cr4_firmware = MT7615_FIRMWARE_CR4;
- u32 n9_ilm_addr, offset;
- int i, ret;
+ int ret;
ret = request_firmware(&fw, n9_firmware, dev->mt76.dev);
if (ret)
@@ -419,31 +450,12 @@ static int mt7615_load_ram(struct mt7615_dev *dev)
dev_info(dev->mt76.dev, "N9 Firmware Version: %.10s, Build Time: %.15s\n",
hdr->fw_ver, hdr->build_date);
- n9_ilm_addr = le32_to_cpu(hdr->addr);
-
- for (offset = 0, i = 0; i < N9_REGION_NUM; i++) {
- u32 len, addr, mode;
-
- len = le32_to_cpu(hdr[i].len) + IMG_CRC_LEN;
- addr = le32_to_cpu(hdr[i].addr);
- mode = gen_dl_mode(hdr[i].feature_set, false);
-
- ret = mt7615_mcu_init_download(dev, addr, len, mode);
- if (ret) {
- dev_err(dev->mt76.dev, "Download request failed\n");
- goto out;
- }
-
- ret = mt7615_mcu_send_firmware(dev, fw->data + offset, len);
- if (ret) {
- dev_err(dev->mt76.dev, "Failed to send firmware to device\n");
- goto out;
- }
-
- offset += len;
- }
+ ret = mt7615_mcu_send_ram_firmware(dev, hdr, fw->data, false);
+ if (ret)
+ goto out;
- ret = mt7615_mcu_start_firmware(dev, n9_ilm_addr, FW_START_OVERRIDE);
+ ret = mt7615_mcu_start_firmware(dev, le32_to_cpu(hdr->addr),
+ FW_START_OVERRIDE);
if (ret) {
dev_err(dev->mt76.dev, "Failed to start N9 firmware\n");
goto out;
@@ -467,27 +479,9 @@ static int mt7615_load_ram(struct mt7615_dev *dev)
dev_info(dev->mt76.dev, "CR4 Firmware Version: %.10s, Build Time: %.15s\n",
hdr->fw_ver, hdr->build_date);
- for (offset = 0, i = 0; i < CR4_REGION_NUM; i++) {
- u32 len, addr, mode;
-
- len = le32_to_cpu(hdr[i].len) + IMG_CRC_LEN;
- addr = le32_to_cpu(hdr[i].addr);
- mode = gen_dl_mode(hdr[i].feature_set, true);
-
- ret = mt7615_mcu_init_download(dev, addr, len, mode);
- if (ret) {
- dev_err(dev->mt76.dev, "Download request failed\n");
- goto out;
- }
-
- ret = mt7615_mcu_send_firmware(dev, fw->data + offset, len);
- if (ret) {
- dev_err(dev->mt76.dev, "Failed to send firmware to device\n");
- goto out;
- }
-
- offset += len;
- }
+ ret = mt7615_mcu_send_ram_firmware(dev, hdr, fw->data, true);
+ if (ret)
+ goto out;
ret = mt7615_mcu_start_firmware(dev, 0, FW_START_WORKING_PDA_CR4);
if (ret)
--
2.21.0
^ permalink raw reply related
* Re: [RFC PATCH] cfg80211: fix duplicated scan entries after channel switch
From: Sergey Matyukevich @ 2019-07-02 11:50 UTC (permalink / raw)
To: Johannes Berg
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <7c8b3493cd2c48beae5a12e23964c8d3ca181d04.camel@sipsolutions.net>
...
> > To summarize, if BSS channel needs to be updated, then bss_tree should
> > be rebuilt in order to put updated BSS entry into a proper location.
>
> Good catch!
>
> > This commit suggests the following straightforward solution:
> > - if new entry has been already created for BSS after channel switch,
> > then remove it completely
>
> Shouldn't we prefer the new entry?
>
> OTOH, the old entry will likely have a "hold", so it doesn't get removed
> while we're connected ... and the driver etc. might be referencing it.
> So I guess the old entry should be updated with info from the newer one?
>
> > Finally, next scan operation will find BSS entry in expected location
> > in rb_tree. So all the IEs, including HT/VHT operation IEs,
> > will be properly updated.
>
> Right. Although if it was there before, then it already has been updated
> in a sense... But I guess it's a corner case to even get there?
>
> > 1. Tested using iwlwifi and qtnfmac drivers, looks good
>
> Great.
>
> > 2. Alternative approach: remove old BSS entry and keep new a one
> > This approach may have certain benefits for mac80211 drivers.
> > For instance, in this case HT/VHT operation IEs are going to be
> > valid from the start, no need to wait for the next scan.
>
> > However the following procedure for replacing current_bss, protected
> > by wdev->mtx and rdev->bss_lock locks, seems to be insufficient:
> >
> > bss_ref_get(rdev, new);
> > cfg80211_hold_bss(new);
> > wdev->current_bss = new;
> >
> > cfg80211_unhold_bss(old);
> > bss_ref_put(rdev, old);
> > __cfg80211_unlink_bss(rdev, old);
> >
> > When testing this alternative approach using iwlwifi driver,
> > occasional general protection fault crashes have been observed
> > on ieee80211_rx_mgmt_beacon/ieee80211_bss_info_update code paths.
> > So far I haven't yet root caused them.
>
> At the very least you'd also have to update ifmgd->associated in
> mac80211, and that's basically not really possible? Well, I guess we
> could change the channel switch API to return the new one or something.
>
> I guess the better thing would be to go update the old entry with the
> new one's data, before killing the new one.
>
> Not sure it's worth the extra complexity though.
Hello Johannes,
Thanks for review! Summarizing your comments, here are the options
and some of their highlights:
1. replace old entry with the new entry
- no easy way to update ifmgd->associated w/o rework of mac80211 csa
2. keep old entry, remove new entry
- this is what suggested RFC patch does
- works, but update of current_bss entry after csa may be delayed
3. keep old entry, update it using data from new entry, then remove new entry
- this looks like a better approach
Unless I am missing something, the last option can be implemented on top of
the current RFC patch w/o extra complexity. The required bss entry update is
what cfg80211_bss_update function does when bss in question already exists.
So it should be possible to reuse that code.
I will post RFC patch v2 after more testing for both mac80211 and
fullmac cases.
Regards,
Sergey
^ permalink raw reply
* [PATCH] mac80211: HE STA disassoc due to QOS NULL not sent
From: Shay Bar @ 2019-07-02 12:20 UTC (permalink / raw)
To: johannes@sipsolutions.net; +Cc: linux-wireless@vger.kernel.org, Shay Bar
In case of HE AP-STA link, ieee80211_send_nullfunc() will not send the QOS NULL packet to check if AP is still associated.
In this case, probe_send_count will be non zero and ieee80211_sta_work() will later disassociate the AP.
(although it didn't really send a test QOS NULL packet).
Fix is to decrement probe_send_count and not call ieee80211_send_nullfunc() in case of HE link.
Signed-off-by: Shay Bar <shay.bar@celeno.com>
---
net/mac80211/mlme.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/net/mac80211/mlme.c b/net/mac80211/mlme.c
index 379d2ab6d327..bc5ed2dbe69b 100644
--- a/net/mac80211/mlme.c
+++ b/net/mac80211/mlme.c
@@ -2511,7 +2511,10 @@ static void ieee80211_mgd_probe_ap_send(struct ieee80211_sub_if_data *sdata)
if (ieee80211_hw_check(&sdata->local->hw, REPORTS_TX_ACK_STATUS)) {
ifmgd->nullfunc_failed = false;
-ieee80211_send_nullfunc(sdata->local, sdata, false);
+if (!(ifmgd->flags & IEEE80211_STA_DISABLE_HE))
+ifmgd->probe_send_count--;
+else
+ieee80211_send_nullfunc(sdata->local, sdata, false);
} else {
int ssid_len;
--
2.22.0
________________________________
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any retransmission, dissemination, copying or other use of, or taking of any action in reliance upon this information is prohibited. If you received this in error, please contact the sender and delete the material from any computer. Nothing contained herein shall be deemed as a representation, warranty or a commitment by Celeno. No warranties are expressed or implied, including, but not limited to, any implied warranties of non-infringement, merchantability and fitness for a particular purpose.
________________________________
^ permalink raw reply related
* [PATCH][next] ath: fix various spelling mistakes
From: Colin King @ 2019-07-02 12:39 UTC (permalink / raw)
To: Kalle Valo, David S . Miller, Maya Erez, ath10k, linux-wireless,
netdev, wil6210
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There are a bunch of spelling mistakes in two ath drivers, fix
these.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/ath/ath10k/core.c | 2 +-
drivers/net/wireless/ath/ath10k/mac.c | 2 +-
drivers/net/wireless/ath/ath10k/qmi.c | 4 ++--
drivers/net/wireless/ath/wil6210/wmi.c | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/core.c b/drivers/net/wireless/ath/ath10k/core.c
index dc45d16e8d21..a7c25d49683b 100644
--- a/drivers/net/wireless/ath/ath10k/core.c
+++ b/drivers/net/wireless/ath/ath10k/core.c
@@ -2784,7 +2784,7 @@ int ath10k_core_start(struct ath10k *ar, enum ath10k_firmware_mode mode,
status = ath10k_hif_set_target_log_mode(ar, fw_diag_log);
if (status && status != -EOPNOTSUPP) {
- ath10k_warn(ar, "set traget log mode faileds: %d\n", status);
+ ath10k_warn(ar, "set target log mode failed: %d\n", status);
goto err_hif_stop;
}
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index e43a566eef77..20f72ec95b28 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7417,7 +7417,7 @@ static bool ath10k_mac_set_vht_bitrate_mask_fixup(struct ath10k *ar,
err = ath10k_wmi_peer_set_param(ar, arvif->vdev_id, sta->addr,
WMI_PEER_PARAM_FIXED_RATE, rate);
if (err)
- ath10k_warn(ar, "failed to eanble STA %pM peer fixed rate: %d\n",
+ ath10k_warn(ar, "failed to enable STA %pM peer fixed rate: %d\n",
sta->addr, err);
return true;
diff --git a/drivers/net/wireless/ath/ath10k/qmi.c b/drivers/net/wireless/ath/ath10k/qmi.c
index 3b63b6257c43..d28daa2d9449 100644
--- a/drivers/net/wireless/ath/ath10k/qmi.c
+++ b/drivers/net/wireless/ath/ath10k/qmi.c
@@ -643,7 +643,7 @@ int ath10k_qmi_set_fw_log_mode(struct ath10k *ar, u8 fw_log_mode)
wlfw_ini_req_msg_v01_ei, &req);
if (ret < 0) {
qmi_txn_cancel(&txn);
- ath10k_err(ar, "fail to send fw log reqest: %d\n", ret);
+ ath10k_err(ar, "failed to send fw log request: %d\n", ret);
goto out;
}
@@ -652,7 +652,7 @@ int ath10k_qmi_set_fw_log_mode(struct ath10k *ar, u8 fw_log_mode)
goto out;
if (resp.resp.result != QMI_RESULT_SUCCESS_V01) {
- ath10k_err(ar, "fw log request rejectedr: %d\n",
+ ath10k_err(ar, "fw log request rejected: %d\n",
resp.resp.error);
ret = -EINVAL;
goto out;
diff --git a/drivers/net/wireless/ath/wil6210/wmi.c b/drivers/net/wireless/ath/wil6210/wmi.c
index 475b1a233cc9..e1704cdfc03e 100644
--- a/drivers/net/wireless/ath/wil6210/wmi.c
+++ b/drivers/net/wireless/ath/wil6210/wmi.c
@@ -2688,7 +2688,7 @@ int wmi_get_all_temperatures(struct wil6210_priv *wil,
return rc;
if (reply.evt.status == WMI_FW_STATUS_FAILURE) {
- wil_err(wil, "Failed geting TEMP_SENSE_ALL\n");
+ wil_err(wil, "Failed getting TEMP_SENSE_ALL\n");
return -EINVAL;
}
--
2.20.1
^ permalink raw reply related
* Re: [RFC PATCH] cfg80211: fix duplicated scan entries after channel switch
From: Johannes Berg @ 2019-07-02 12:40 UTC (permalink / raw)
To: Sergey Matyukevich
Cc: linux-wireless@vger.kernel.org, Igor Mitsyanko, Mikhail Karpenko
In-Reply-To: <20190702115005.ulcfohbi4mkwpt2c@bars>
Hi Sergey,
On Tue, 2019-07-02 at 11:50 +0000, Sergey Matyukevich wrote:
> Thanks for review! Summarizing your comments, here are the options
> and some of their highlights:
>
> 1. replace old entry with the new entry
> - no easy way to update ifmgd->associated w/o rework of mac80211 csa
Yes, this one's the tricky one. I don't think you can make this work
easily.
> 2. keep old entry, remove new entry
> - this is what suggested RFC patch does
> - works, but update of current_bss entry after csa may be delayed
Correct.
> 3. keep old entry, update it using data from new entry, then remove new entry
> - this looks like a better approach
>
> Unless I am missing something, the last option can be implemented on top of
> the current RFC patch w/o extra complexity. The required bss entry update is
> what cfg80211_bss_update function does when bss in question already exists.
> So it should be possible to reuse that code.
Agree, you just need to sort of invert it, or call it like this:
* relink the old entry, unlink a new entry (if any)
* bss_update() with the new entry if there was one
* it should free one of the entries if I remember correctly
> I will post RFC patch v2 after more testing for both mac80211 and
> fullmac cases.
Sounds good, thanks a lot for working on this!
johannes
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Jes Sorensen @ 2019-07-02 12:42 UTC (permalink / raw)
To: Daniel Drake, Chris Chiu
Cc: Kalle Valo, David Miller, linux-wireless, netdev, Linux Kernel,
Linux Upstreaming Team, Larry Finger
In-Reply-To: <CAD8Lp44R0a1=fVi=fGv69w1ppdcaFV01opkdkhaX-eJ=K=tYeA@mail.gmail.com>
On 7/1/19 4:27 AM, Daniel Drake wrote:
> Hi Chris,
>
> On Thu, Jun 27, 2019 at 5:53 PM Chris Chiu <chiu@endlessm.com> wrote:
>> The WiFi tx power of RTL8723BU is extremely low after booting. So
>> the WiFi scan gives very limited AP list and it always fails to
>> connect to the selected AP. This module only supports 1x1 antenna
>> and the antenna is switched to bluetooth due to some incorrect
>> register settings.
>>
>> This commit hand over the antenna control to PTA, the wifi signal
>> will be back to normal and the bluetooth scan can also work at the
>> same time. However, the btcoexist still needs to be handled under
>> different circumstances. If there's a BT connection established,
>> the wifi still fails to connect until disconneting the BT.
>>
>> Signed-off-by: Chris Chiu <chiu@endlessm.com>
>
> Really nice work finding this!
>
> I know that after this change, you plan to bring over the btcoexist
> code from the vendor driver (or at least the minimum required code)
> for a more complete fix, but I'm curious how you found these magic
> register values and how they compare to the values used by the vendor
> driver with btcoexist?
We definitely don't want to bring over the vendor code, since it's a
pile of spaghetti, but we probably need to get something sorted. This
went down the drain when the bluetooth driver was added without taking
it into account - long after this driver was merged.
Cheers,
Jes
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Jes Sorensen @ 2019-07-02 12:44 UTC (permalink / raw)
To: Chris Chiu, kvalo, davem; +Cc: linux-wireless, netdev, linux-kernel, linux
In-Reply-To: <20190627095247.8792-1-chiu@endlessm.com>
On 6/27/19 5:52 AM, Chris Chiu wrote:
> The WiFi tx power of RTL8723BU is extremely low after booting. So
> the WiFi scan gives very limited AP list and it always fails to
> connect to the selected AP. This module only supports 1x1 antenna
> and the antenna is switched to bluetooth due to some incorrect
> register settings.
>
> This commit hand over the antenna control to PTA, the wifi signal
> will be back to normal and the bluetooth scan can also work at the
> same time. However, the btcoexist still needs to be handled under
> different circumstances. If there's a BT connection established,
> the wifi still fails to connect until disconneting the BT.
>
> Signed-off-by: Chris Chiu <chiu@endlessm.com>
> ---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 9 ++++++---
> drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++-
> 2 files changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> index 3adb1d3d47ac..6c3c70d93ac1 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> /*
> * WLAN action by PTA
> */
> - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04);
> + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c);
>
> /*
> * BT select S0/S1 controlled by WiFi
> @@ -1568,9 +1568,12 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.ant_sel_rsv));
>
> /*
> - * 0x280, 0x00, 0x200, 0x80 - not clear
> + * Different settings per different antenna position.
> + * Antenna switch to BT: 0x280, 0x00 (inverse)
> + * Antenna switch to WiFi: 0x0, 0x280 (inverse)
> + * Antenna controlled by PTA: 0x200, 0x80 (inverse)
> */
> - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
>
> /*
> * Software control, antenna at WiFi side
> diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> index 8136e268b4e6..87b2179a769e 100644
> --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> @@ -3891,12 +3891,13 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
>
> /* Check if MAC is already powered on */
> val8 = rtl8xxxu_read8(priv, REG_CR);
> + val16 = rtl8xxxu_read16(priv, REG_SYS_CLKR);
>
> /*
> * Fix 92DU-VC S3 hang with the reason is that secondary mac is not
> * initialized. First MAC returns 0xea, second MAC returns 0x00
> */
> - if (val8 == 0xea)
> + if (val8 == 0xea || !(val16 & BIT(11)))
> macpower = false;
> else
> macpower = true;
This part I would like to ask you take a good look at the other chips to
make sure you don't break support for 8192cu, 8723au, 8188eu with this.
Cheers,
Jes
^ permalink raw reply
* [PATCH -next] carl9170: remove set but not used variable 'udev'
From: YueHaibing @ 2019-07-02 14:12 UTC (permalink / raw)
To: chunkeey; +Cc: linux-kernel, netdev, linux-wireless, kvalo, davem, YueHaibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/ath/carl9170/usb.c: In function carl9170_usb_disconnect:
drivers/net/wireless/ath/carl9170/usb.c:1110:21:
warning: variable udev set but not used [-Wunused-but-set-variable]
It is not use since commit feb09b293327 ("carl9170:
fix misuse of device driver API")
Reported-by: Hulk Robot <hulkci@huawei.com>
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ath/carl9170/usb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c
index 99f1897..486957a 100644
--- a/drivers/net/wireless/ath/carl9170/usb.c
+++ b/drivers/net/wireless/ath/carl9170/usb.c
@@ -1107,12 +1107,10 @@ static int carl9170_usb_probe(struct usb_interface *intf,
static void carl9170_usb_disconnect(struct usb_interface *intf)
{
struct ar9170 *ar = usb_get_intfdata(intf);
- struct usb_device *udev;
if (WARN_ON(!ar))
return;
- udev = ar->udev;
wait_for_completion(&ar->fw_load_wait);
if (IS_INITIALIZED(ar)) {
--
2.7.4
^ permalink raw reply related
* [PATCH] wireless-regdb: Fix overlapping ranges for Switzerland and Liechtenstein
From: Martin Willi @ 2019-07-02 14:19 UTC (permalink / raw)
To: Seth Forshee; +Cc: wireless-regdb, linux-wireless, Henrik Laxhuber
The commit referenced below changes the 5GHz frequency range 5250-5330
to 5150-5330, making that range overlapping with the existing range
5170-5250. This imposes DFS limitations and a reduced maximum power
level for the range 5170-5250.
The change of the frequency range seems not intentional. Instead the
commit should have changed the 5170-5250 range to 5150-5250, and the
5250-5330 range to 5250-5350 (see [1]).
[1] https://www.ofcomnet.ch/api/rir/1010/05
Fixes: 957a7cff72a3 ("wireless-regdb: update regulatory rules for Switzerland (CH), and Liechtenstein (LI) on 5GHz")
Signed-off-by: Martin Willi <martin@strongswan.org>
---
db.txt | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/db.txt b/db.txt
index d47ab94c3aa5..37393e6a793e 100644
--- a/db.txt
+++ b/db.txt
@@ -271,8 +271,8 @@ country CF: DFS-FCC
# transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
country CH: DFS-ETSI
(2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
- (5150 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
@@ -747,8 +747,8 @@ country LC: DFS-ETSI
# transmitter power control is in use: 5250-5330@23db, 5490-5710@30db
country LI: DFS-ETSI
(2402 - 2482 @ 40), (20)
- (5170 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
- (5150 - 5330 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
+ (5150 - 5250 @ 80), (23), NO-OUTDOOR, AUTO-BW, wmmrule=ETSI
+ (5250 - 5350 @ 80), (20), NO-OUTDOOR, DFS, AUTO-BW, wmmrule=ETSI
(5490 - 5710 @ 160), (27), DFS, wmmrule=ETSI
# 60 GHz band channels 1-4, ref: Etsi En 302 567
(57000 - 66000 @ 2160), (40)
--
2.17.1
^ permalink raw reply related
* [PATCH][next] wil6210: fix wil_cid_valid with negative cid values
From: Colin King @ 2019-07-02 14:40 UTC (permalink / raw)
To: Maya Erez, Kalle Valo, David S . Miller, linux-wireless, wil6210,
netdev
Cc: kernel-janitors, linux-kernel
From: Colin Ian King <colin.king@canonical.com>
There are several occasions where a negative cid value is passed
into wil_cid_valid and this is converted into a u8 causing the
range check of cid >= 0 to always succeed. Fix this by making
the cid argument an int to handle any -ve error value of cid.
An example of this behaviour is in wil_cfg80211_dump_station,
where cid is assigned -ENOENT if the call to wil_find_cid_by_idx
fails, and this -ve value is passed to wil_cid_valid. I believe
that the conversion of -ENOENT to the u8 value 254 which is
greater than wil->max_assoc_sta causes wil_find_cid_by_idx to
currently work fine, but I think is by luck and not the
intended behaviour.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/ath/wil6210/wil6210.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/wil6210/wil6210.h b/drivers/net/wireless/ath/wil6210/wil6210.h
index 6f456b311a39..25a1adcb38eb 100644
--- a/drivers/net/wireless/ath/wil6210/wil6210.h
+++ b/drivers/net/wireless/ath/wil6210/wil6210.h
@@ -1144,7 +1144,7 @@ static inline void wil_c(struct wil6210_priv *wil, u32 reg, u32 val)
/**
* wil_cid_valid - check cid is valid
*/
-static inline bool wil_cid_valid(struct wil6210_priv *wil, u8 cid)
+static inline bool wil_cid_valid(struct wil6210_priv *wil, int cid)
{
return (cid >= 0 && cid < wil->max_assoc_sta);
}
--
2.20.1
^ permalink raw reply related
* [PATCH 0/3] mt76: usb: alignment and endianes improvements
From: Stanislaw Gruszka @ 2019-07-02 15:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Stanislaw Gruszka
Fix endian bug and do some minor optimizations in mt76u_{copy,rr,wr} .
I do not mark cc stable endian fix as noboby reported this issue,
i.e. use the driver on big endian machine, but make it a separate patch,
so it can be backported if needed.
This is on top of:
[PATCH] mt76: round up length on mt76_wr_copy
Stanislaw Gruszka (3):
mt76: usb: fix endian in mt76u_copy
mt76: usb: remove unneeded {put,get}_unaligned
mt76: usb: use full intermediate buffer in mt76u_copy
drivers/net/wireless/mediatek/mt76/mt76.h | 5 ++++-
drivers/net/wireless/mediatek/mt76/usb.c | 27 ++++++++++++++++-----------
2 files changed, 20 insertions(+), 12 deletions(-)
--
1.9.3
^ permalink raw reply
* [PATCH 2/3] mt76: usb: remove unneeded {put,get}_unaligned
From: Stanislaw Gruszka @ 2019-07-02 15:06 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Stanislaw Gruszka
In-Reply-To: <1562079961-15527-1-git-send-email-sgruszka@redhat.com>
Compiler give us guaranties on variables alignment, so use
an variable as buffer when read/write registers and remove
unneeded {put,get}_unaligned.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 5 ++++-
drivers/net/wireless/mediatek/mt76/usb.c | 8 ++++----
2 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index 56bf93a8988e..094e6e543542 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -389,7 +389,10 @@ enum mt76u_out_ep {
#define MCU_RESP_URB_SIZE 1024
struct mt76_usb {
struct mutex usb_ctrl_mtx;
- u8 data[32];
+ union {
+ u8 data[32];
+ __le32 reg_val;
+ };
struct tasklet_struct rx_tasklet;
struct delayed_work stat_work;
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index db90ec6b8775..a61bb8171557 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -95,9 +95,9 @@ static u32 __mt76u_rr(struct mt76_dev *dev, u32 addr)
ret = __mt76u_vendor_request(dev, req,
USB_DIR_IN | USB_TYPE_VENDOR,
- 0, offset, usb->data, sizeof(__le32));
+ 0, offset, &usb->reg_val, sizeof(__le32));
if (ret == sizeof(__le32))
- data = get_unaligned_le32(usb->data);
+ data = le32_to_cpu(usb->reg_val);
trace_usb_reg_rr(dev, addr, data);
return data;
@@ -131,10 +131,10 @@ static void __mt76u_wr(struct mt76_dev *dev, u32 addr, u32 val)
}
offset = addr & ~MT_VEND_TYPE_MASK;
- put_unaligned_le32(val, usb->data);
+ usb->reg_val = cpu_to_le32(val);
__mt76u_vendor_request(dev, req,
USB_DIR_OUT | USB_TYPE_VENDOR, 0,
- offset, usb->data, sizeof(__le32));
+ offset, &usb->reg_val, sizeof(__le32));
trace_usb_reg_wr(dev, addr, val);
}
--
1.9.3
^ permalink raw reply related
* [PATCH 3/3] mt76: usb: use full intermediate buffer in mt76u_copy
From: Stanislaw Gruszka @ 2019-07-02 15:06 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Stanislaw Gruszka
In-Reply-To: <1562079961-15527-1-git-send-email-sgruszka@redhat.com>
Instead of use several 4 bytes usb requests, use full 32 bytes buffer
to copy data to device. With the change we use less requests and copy
exact data size to the device regardless size is multiple of 4 or not.
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/usb.c | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index a61bb8171557..7c564cc68c7c 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -160,19 +160,24 @@ static void mt76u_copy(struct mt76_dev *dev, u32 offset,
const void *data, int len)
{
struct mt76_usb *usb = &dev->usb;
- const u32 *val = data;
- int i, ret;
+ int ret, req_len;
mutex_lock(&usb->usb_ctrl_mtx);
- for (i = 0; i < DIV_ROUND_UP(len, 4); i++) {
- put_unaligned(val[i], usb->data);
+ do {
+ req_len = min_t(int, len, sizeof(usb->data));
+
+ memcpy(usb->data, data, req_len);
+
ret = __mt76u_vendor_request(dev, MT_VEND_MULTI_WRITE,
USB_DIR_OUT | USB_TYPE_VENDOR,
- 0, offset + i * 4, usb->data,
- sizeof(u32));
+ 0, offset, usb->data, req_len);
if (ret < 0)
break;
- }
+
+ data += req_len;
+ offset += req_len;
+ len -= req_len;
+ } while (len > 0);
mutex_unlock(&usb->usb_ctrl_mtx);
}
--
1.9.3
^ permalink raw reply related
* [PATCH 1/3] mt76: usb: fix endian in mt76u_copy
From: Stanislaw Gruszka @ 2019-07-02 15:05 UTC (permalink / raw)
To: linux-wireless; +Cc: Felix Fietkau, Lorenzo Bianconi, Stanislaw Gruszka
In-Reply-To: <1562079961-15527-1-git-send-email-sgruszka@redhat.com>
In contrast to mt76_wr() which we use to program registers,
on mt76_wr_copy() we should not change endian of the data.
Fixes: b40b15e1521f ("mt76: add usb support to mt76 layer")
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
---
drivers/net/wireless/mediatek/mt76/usb.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/usb.c b/drivers/net/wireless/mediatek/mt76/usb.c
index 87ecbe290f99..db90ec6b8775 100644
--- a/drivers/net/wireless/mediatek/mt76/usb.c
+++ b/drivers/net/wireless/mediatek/mt76/usb.c
@@ -165,11 +165,11 @@ static void mt76u_copy(struct mt76_dev *dev, u32 offset,
mutex_lock(&usb->usb_ctrl_mtx);
for (i = 0; i < DIV_ROUND_UP(len, 4); i++) {
- put_unaligned_le32(val[i], usb->data);
+ put_unaligned(val[i], usb->data);
ret = __mt76u_vendor_request(dev, MT_VEND_MULTI_WRITE,
USB_DIR_OUT | USB_TYPE_VENDOR,
0, offset + i * 4, usb->data,
- sizeof(__le32));
+ sizeof(u32));
if (ret < 0)
break;
}
--
1.9.3
^ permalink raw reply related
* -Wsometimes-uninitialized warning after 8b97b055dc9db09b48d5a9a37d847900dd00d3cc
From: Nathan Chancellor @ 2019-07-02 18:18 UTC (permalink / raw)
To: Miaoqing Pan, Kalle Valo
Cc: ath10k, linux-wireless, netdev, linux-kernel, clang-built-linux
Hi all,
After commit 8b97b055dc9d ("ath10k: fix failure to set multiple fixed
rate") in -next, clang warns:
../drivers/net/wireless/ath/ath10k/mac.c:7528:7: warning: variable 'vht_pfr' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
if (!ath10k_mac_can_set_bitrate_mask(ar, band, mask,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/net/wireless/ath/ath10k/mac.c:7551:20: note: uninitialized use occurs here
arvif->vht_pfr = vht_pfr;
^~~~~~~
../drivers/net/wireless/ath/ath10k/mac.c:7528:3: note: remove the 'if' if its condition is always true
if (!ath10k_mac_can_set_bitrate_mask(ar, band, mask,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../drivers/net/wireless/ath/ath10k/mac.c:7483:12: note: initialize the variable 'vht_pfr' to silence this warning
u8 vht_pfr;
^
= '\0'
1 warning generated.
This definitely seems legitimate as the call to
ath10k_mac_can_set_bitrate_mask might fail and vht_pfr
won't be initialized. I would fix this myself but I assume
there is a sane default value for vht_pfr other than just
0 that should be used?
Please look into this when you get a chance. Thanks,
Nathan
^ permalink raw reply
* [PATCH] mac80211: fix possible memory leak in ieee80211_assign_beacon
From: Lorenzo Bianconi @ 2019-07-02 22:29 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, lorenzo.bianconi
Free new beacon_data in ieee80211_assign_beacon whenever
ieee80211_assign_beacon fails
Fixes: 8860020e0be1 ("cfg80211: restructure AP/GO mode API")
Fixes: bc847970f432 ("mac80211: support FTM responder configuration/statistic")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
net/mac80211/cfg.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/net/mac80211/cfg.c b/net/mac80211/cfg.c
index a1973a26c7fc..b8288125e05d 100644
--- a/net/mac80211/cfg.c
+++ b/net/mac80211/cfg.c
@@ -935,8 +935,10 @@ static int ieee80211_assign_beacon(struct ieee80211_sub_if_data *sdata,
err = ieee80211_set_probe_resp(sdata, params->probe_resp,
params->probe_resp_len, csa);
- if (err < 0)
+ if (err < 0) {
+ kfree(new);
return err;
+ }
if (err == 0)
changed |= BSS_CHANGED_AP_PROBE_RESP;
@@ -948,8 +950,10 @@ static int ieee80211_assign_beacon(struct ieee80211_sub_if_data *sdata,
params->civicloc,
params->civicloc_len);
- if (err < 0)
+ if (err < 0) {
+ kfree(new);
return err;
+ }
changed |= BSS_CHANGED_FTM_RESPONDER;
}
--
2.21.0
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Chris Chiu @ 2019-07-03 3:25 UTC (permalink / raw)
To: Jes Sorensen
Cc: Kalle Valo, David Miller, linux-wireless, netdev, Linux Kernel,
Linux Upstreaming Team
In-Reply-To: <31f59db2-0e04-447b-48f8-66ea53ebfa7d@gmail.com>
On Tue, Jul 2, 2019 at 8:44 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
>
> On 6/27/19 5:52 AM, Chris Chiu wrote:
> > The WiFi tx power of RTL8723BU is extremely low after booting. So
> > the WiFi scan gives very limited AP list and it always fails to
> > connect to the selected AP. This module only supports 1x1 antenna
> > and the antenna is switched to bluetooth due to some incorrect
> > register settings.
> >
> > This commit hand over the antenna control to PTA, the wifi signal
> > will be back to normal and the bluetooth scan can also work at the
> > same time. However, the btcoexist still needs to be handled under
> > different circumstances. If there's a BT connection established,
> > the wifi still fails to connect until disconneting the BT.
> >
> > Signed-off-by: Chris Chiu <chiu@endlessm.com>
> > ---
> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c | 9 ++++++---
> > drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c | 3 ++-
> > 2 files changed, 8 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > index 3adb1d3d47ac..6c3c70d93ac1 100644
> > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8723b.c
> > @@ -1525,7 +1525,7 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> > /*
> > * WLAN action by PTA
> > */
> > - rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x04);
> > + rtl8xxxu_write8(priv, REG_WLAN_ACT_CONTROL_8723B, 0x0c);
> >
> > /*
> > * BT select S0/S1 controlled by WiFi
> > @@ -1568,9 +1568,12 @@ static void rtl8723b_enable_rf(struct rtl8xxxu_priv *priv)
> > rtl8xxxu_gen2_h2c_cmd(priv, &h2c, sizeof(h2c.ant_sel_rsv));
> >
> > /*
> > - * 0x280, 0x00, 0x200, 0x80 - not clear
> > + * Different settings per different antenna position.
> > + * Antenna switch to BT: 0x280, 0x00 (inverse)
> > + * Antenna switch to WiFi: 0x0, 0x280 (inverse)
> > + * Antenna controlled by PTA: 0x200, 0x80 (inverse)
> > */
> > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
> >
> > /*
> > * Software control, antenna at WiFi side
> > diff --git a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > index 8136e268b4e6..87b2179a769e 100644
> > --- a/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > +++ b/drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_core.c
> > @@ -3891,12 +3891,13 @@ static int rtl8xxxu_init_device(struct ieee80211_hw *hw)
> >
> > /* Check if MAC is already powered on */
> > val8 = rtl8xxxu_read8(priv, REG_CR);
> > + val16 = rtl8xxxu_read16(priv, REG_SYS_CLKR);
> >
> > /*
> > * Fix 92DU-VC S3 hang with the reason is that secondary mac is not
> > * initialized. First MAC returns 0xea, second MAC returns 0x00
> > */
> > - if (val8 == 0xea)
> > + if (val8 == 0xea || !(val16 & BIT(11)))
> > macpower = false;
> > else
> > macpower = true;
>
> This part I would like to ask you take a good look at the other chips to
> make sure you don't break support for 8192cu, 8723au, 8188eu with this.
>
> Cheers,
> Jes
I checked the vendor code of 8192cu and 8188eu, they don't have this part
of code to check the REG_CR before power on sequence. I can only find
similar code in rtl8723be.
if (tmp_u1b != 0 && tmp_u1b !=0xea)
rtlhal->mac_func_enable = true;
By definition, the BIT(11) of REG_SYS_CLKR in rtl8xxxu_regs.h is
SYS_CLK_MAC_CLK_ENABLE. It seems to make sense to check this value
for macpower no matter what chip it is. I think I can make it more
self-expressive
as down below.
if (val8 == 0xea || !(val16 & SYS_CLK_MAC_CLK_ENABLE))
And per the comment, this code is for 92DU-VC S3 hang problem and I think an
OR check for SYS_CLK_MAC_CLK_ENABLE is still safe for this.
Chris
^ permalink raw reply
* [PATCH 0/3] Move voltage regulator config to driver private data
From: Govind Singh @ 2019-07-03 3:57 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, linux-arm-msm, devicetree, Govind Singh
WCN3990 voltage regulator config is varying b/w different MSM platforms ex: SDM845/
QCS404. In order to have scalable config, move regulator config to driver
private data.
Tested HW: WCN3990(SDM845/QCS404)
Tested FW: WLAN.HL.3.1-01040-QCAHLSWMTPLZ-1
Govind Singh (3):
dt: bindings: update compatible dt properties for WCN3990 wifi node
ath10k: Move regulator config to driver private data
arm64: dts: qcom: qcs404: Modify wifi dt node for SDM845/QCS404
devices
.../bindings/net/wireless/qcom,ath10k.txt | 2 +
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 3 ++
arch/arm64/boot/dts/qcom/qcs404.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
drivers/net/wireless/ath/ath10k/snoc.c | 38 +++++++++++++++----
drivers/net/wireless/ath/ath10k/snoc.h | 23 ++++++-----
6 files changed, 51 insertions(+), 19 deletions(-)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH 1/3] dt: bindings: update compatible dt properties for WCN3990 wifi node
From: Govind Singh @ 2019-07-03 3:57 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, linux-arm-msm, devicetree, Govind Singh
In-Reply-To: <20190703035711.25592-1-govinds@codeaurora.org>
update compatible dt properties for WCN3990 wifi node to be
compatible across different MSM platforms.
Signed-off-by: Govind Singh <govinds@codeaurora.org>
---
Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index ae661e65354e..baaa3f32ae44 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -5,6 +5,8 @@ Required properties:
* "qcom,ath10k"
* "qcom,ipq4019-wifi"
* "qcom,wcn3990-wifi"
+ * "qcom,sdm845-wcn39xx-wifi"
+ * "qcom,qcs40x-wcn39xx-wifi"
PCI based devices uses compatible string "qcom,ath10k" and takes calibration
data along with board specific data via "qcom,ath10k-calibration-data".
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 2/3] ath10k: Move regulator config to driver private data
From: Govind Singh @ 2019-07-03 3:57 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, linux-arm-msm, devicetree, Govind Singh
In-Reply-To: <20190703035711.25592-1-govinds@codeaurora.org>
WCN3990 Regulator config is varying b/w different MSM platforms.
In order to have scalable config, move regulator config to driver
private data.
Signed-off-by: Govind Singh <govinds@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/snoc.c | 38 +++++++++++++++++++++-----
drivers/net/wireless/ath/ath10k/snoc.h | 23 +++++++++-------
2 files changed, 44 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/snoc.c b/drivers/net/wireless/ath/ath10k/snoc.c
index ca1186ec4129..bd7d97924fe0 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.c
+++ b/drivers/net/wireless/ath/ath10k/snoc.c
@@ -36,13 +36,20 @@ static char *const ce_name[] = {
"WLAN_CE_11",
};
-static struct ath10k_vreg_info vreg_cfg[] = {
+static struct ath10k_vreg_info sdm845_reg_cfg[] = {
{NULL, "vdd-0.8-cx-mx", 800000, 850000, 0, 0, false},
{NULL, "vdd-1.8-xo", 1800000, 1850000, 0, 0, false},
{NULL, "vdd-1.3-rfa", 1300000, 1350000, 0, 0, false},
{NULL, "vdd-3.3-ch0", 3300000, 3350000, 0, 0, false},
};
+static struct ath10k_vreg_info qcs40x_reg_cfg[] = {
+ {NULL, "vdd-0.8-cx-mx", 1224000, 1224000, 0, 0, false},
+ {NULL, "vdd-1.8-xo", 1800000, 1850000, 0, 0, false},
+ {NULL, "vdd-1.3-rfa", 1300000, 1350000, 0, 0, false},
+ {NULL, "vdd-3.3-ch0", 3300000, 3350000, 0, 0, false},
+};
+
static struct ath10k_clk_info clk_cfg[] = {
{NULL, "cxo_ref_clk_pin", 0, false},
};
@@ -54,10 +61,20 @@ static void ath10k_snoc_htt_rx_cb(struct ath10k_ce_pipe *ce_state);
static void ath10k_snoc_htt_htc_rx_cb(struct ath10k_ce_pipe *ce_state);
static void ath10k_snoc_pktlog_rx_cb(struct ath10k_ce_pipe *ce_state);
-static const struct ath10k_snoc_drv_priv drv_priv = {
+static const struct ath10k_snoc_drv_priv sdm845_wcn39xx_drv_priv = {
+ .hw_rev = ATH10K_HW_WCN3990,
+ .dma_mask = DMA_BIT_MASK(35),
+ .msa_size = 0x100000,
+ .vreg_cfg = sdm845_reg_cfg,
+ .vreg_count = ARRAY_SIZE(sdm845_reg_cfg),
+};
+
+static const struct ath10k_snoc_drv_priv qcs40x_wcn39xx_drv_priv = {
.hw_rev = ATH10K_HW_WCN3990,
.dma_mask = DMA_BIT_MASK(35),
.msa_size = 0x100000,
+ .vreg_cfg = qcs40x_reg_cfg,
+ .vreg_count = ARRAY_SIZE(qcs40x_reg_cfg),
};
#define WCN3990_SRC_WR_IDX_OFFSET 0x3C
@@ -1465,7 +1482,7 @@ static int ath10k_snoc_vreg_on(struct ath10k *ar)
int ret = 0;
int i;
- for (i = 0; i < ARRAY_SIZE(vreg_cfg); i++) {
+ for (i = 0; i < ar_snoc->vreg_count; i++) {
vreg_info = &ar_snoc->vreg[i];
if (!vreg_info->reg)
@@ -1498,7 +1515,7 @@ static int ath10k_snoc_vreg_off(struct ath10k *ar)
int ret = 0;
int i;
- for (i = ARRAY_SIZE(vreg_cfg) - 1; i >= 0; i--) {
+ for (i = ar_snoc->vreg_count - 1; i >= 0; i--) {
vreg_info = &ar_snoc->vreg[i];
if (!vreg_info->reg)
@@ -1616,7 +1633,13 @@ static int ath10k_hw_power_off(struct ath10k *ar)
static const struct of_device_id ath10k_snoc_dt_match[] = {
{ .compatible = "qcom,wcn3990-wifi",
- .data = &drv_priv,
+ .data = &sdm845_wcn39xx_drv_priv,
+ },
+ { .compatible = "qcom,sdm845-wcn39xx-wifi",
+ .data = &sdm845_wcn39xx_drv_priv,
+ },
+ { .compatible = "qcom,qcs40x-wcn39xx-wifi",
+ .data = &qcs40x_wcn39xx_drv_priv,
},
{ }
};
@@ -1680,8 +1703,9 @@ static int ath10k_snoc_probe(struct platform_device *pdev)
goto err_release_resource;
}
- ar_snoc->vreg = vreg_cfg;
- for (i = 0; i < ARRAY_SIZE(vreg_cfg); i++) {
+ ar_snoc->vreg = drv_data->vreg_cfg;
+ ar_snoc->vreg_count = drv_data->vreg_count;
+ for (i = 0; i < ar_snoc->vreg_count; i++) {
ret = ath10k_get_vreg_info(ar, dev, &ar_snoc->vreg[i]);
if (ret)
goto err_free_irq;
diff --git a/drivers/net/wireless/ath/ath10k/snoc.h b/drivers/net/wireless/ath/ath10k/snoc.h
index d62f53501fbb..0bdada11985c 100644
--- a/drivers/net/wireless/ath/ath10k/snoc.h
+++ b/drivers/net/wireless/ath/ath10k/snoc.h
@@ -10,10 +10,22 @@
#include "ce.h"
#include "qmi.h"
+struct ath10k_vreg_info {
+ struct regulator *reg;
+ const char *name;
+ u32 min_v;
+ u32 max_v;
+ u32 load_ua;
+ unsigned long settle_delay;
+ bool required;
+};
+
struct ath10k_snoc_drv_priv {
enum ath10k_hw_rev hw_rev;
u64 dma_mask;
u32 msa_size;
+ struct ath10k_vreg_info *vreg_cfg;
+ u8 vreg_count;
};
struct snoc_state {
@@ -42,16 +54,6 @@ struct ath10k_snoc_ce_irq {
u32 irq_line;
};
-struct ath10k_vreg_info {
- struct regulator *reg;
- const char *name;
- u32 min_v;
- u32 max_v;
- u32 load_ua;
- unsigned long settle_delay;
- bool required;
-};
-
struct ath10k_clk_info {
struct clk *handle;
const char *name;
@@ -77,6 +79,7 @@ struct ath10k_snoc {
struct ath10k_ce ce;
struct timer_list rx_post_retry;
struct ath10k_vreg_info *vreg;
+ u8 vreg_count;
struct ath10k_clk_info *clk;
struct ath10k_qmi *qmi;
unsigned long flags;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH 3/3] arm64: dts: qcom: qcs404: Modify wifi dt node for SDM845/QCS404 devices
From: Govind Singh @ 2019-07-03 3:57 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, linux-arm-msm, devicetree, Govind Singh
In-Reply-To: <20190703035711.25592-1-govinds@codeaurora.org>
Modify the compatible string of wifi node for SDM845/QCS404 devices.
Add wifi regulators in qcs404 dt node for proxy vote. Proxy votes are
required for handling driver recovery scenarios to prevent
un-clocked register access during driver recovery.
Signed-off-by: Govind Singh <govinds@codeaurora.org>
---
arch/arm64/boot/dts/qcom/qcs404-evb.dtsi | 3 +++
arch/arm64/boot/dts/qcom/qcs404.dtsi | 2 +-
arch/arm64/boot/dts/qcom/sdm845.dtsi | 2 +-
3 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
index 50b3589c7f15..ff81b9c5b057 100644
--- a/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404-evb.dtsi
@@ -190,6 +190,9 @@
&wifi {
status = "okay";
+ vdd-0.8-cx-mx-supply = <&vreg_l2_1p275>;
+ vdd-1.8-xo-supply = <&vreg_l5_1p8>;
+ vdd-1.3-rfa-supply = <&vreg_l1_1p3>;
};
/* PINCTRL - additions to nodes defined in qcs404.dtsi */
diff --git a/arch/arm64/boot/dts/qcom/qcs404.dtsi b/arch/arm64/boot/dts/qcom/qcs404.dtsi
index e8fd26633d57..d9e2173cd3e9 100644
--- a/arch/arm64/boot/dts/qcom/qcs404.dtsi
+++ b/arch/arm64/boot/dts/qcom/qcs404.dtsi
@@ -480,7 +480,7 @@
};
wifi: wifi@a000000 {
- compatible = "qcom,wcn3990-wifi";
+ compatible = "qcom,qcs40x-wcn39xx-wifi";
reg = <0xa000000 0x800000>;
reg-names = "membase";
memory-region = <&wlan_msa_mem>;
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi b/arch/arm64/boot/dts/qcom/sdm845.dtsi
index 5308f1671824..fdb5fcd814f4 100644
--- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
@@ -2235,7 +2235,7 @@
};
wifi: wifi@18800000 {
- compatible = "qcom,wcn3990-wifi";
+ compatible = "qcom,sdm845-wcn39xx-wifi";
status = "disabled";
reg = <0 0x18800000 0 0x800000>;
reg-names = "membase";
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply related
* [PATCH] rt2x00: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2019-07-03 6:56 UTC (permalink / raw)
To: Stanislaw Gruszka, Helmut Schaa, Kalle Valo
Cc: David S. Miller, linux-wireless, netdev
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Because we don't need to save the individual debugfs files and
directories, remove the local storage of them and just remove the entire
debugfs directory in a single call, making things a lot simpler.
Cc: Stanislaw Gruszka <sgruszka@redhat.com>
Cc: Helmut Schaa <helmut.schaa@googlemail.com>
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
.../net/wireless/ralink/rt2x00/rt2x00debug.c | 100 ++++--------------
1 file changed, 23 insertions(+), 77 deletions(-)
diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
index aac3aae7afaa..7103904de28a 100644
--- a/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
+++ b/drivers/net/wireless/ralink/rt2x00/rt2x00debug.c
@@ -64,25 +64,6 @@ struct rt2x00debug_intf {
* - crypto stats file
*/
struct dentry *driver_folder;
- struct dentry *driver_entry;
- struct dentry *chipset_entry;
- struct dentry *dev_flags;
- struct dentry *cap_flags;
- struct dentry *register_folder;
- struct dentry *csr_off_entry;
- struct dentry *csr_val_entry;
- struct dentry *eeprom_off_entry;
- struct dentry *eeprom_val_entry;
- struct dentry *bbp_off_entry;
- struct dentry *bbp_val_entry;
- struct dentry *rf_off_entry;
- struct dentry *rf_val_entry;
- struct dentry *rfcsr_off_entry;
- struct dentry *rfcsr_val_entry;
- struct dentry *queue_folder;
- struct dentry *queue_frame_dump_entry;
- struct dentry *queue_stats_entry;
- struct dentry *crypto_stats_entry;
/*
* The frame dump file only allows a single reader,
@@ -631,6 +612,8 @@ void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
{
const struct rt2x00debug *debug = rt2x00dev->ops->debugfs;
struct rt2x00debug_intf *intf;
+ struct dentry *queue_folder;
+ struct dentry *register_folder;
intf = kzalloc(sizeof(struct rt2x00debug_intf), GFP_KERNEL);
if (!intf) {
@@ -646,39 +629,28 @@ void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
debugfs_create_dir(intf->rt2x00dev->ops->name,
rt2x00dev->hw->wiphy->debugfsdir);
- intf->driver_entry =
- rt2x00debug_create_file_driver("driver", intf, &intf->driver_blob);
+ rt2x00debug_create_file_driver("driver", intf, &intf->driver_blob);
- intf->chipset_entry =
- rt2x00debug_create_file_chipset("chipset",
- intf, &intf->chipset_blob);
+ rt2x00debug_create_file_chipset("chipset", intf, &intf->chipset_blob);
- intf->dev_flags = debugfs_create_file("dev_flags", 0400,
- intf->driver_folder, intf,
- &rt2x00debug_fop_dev_flags);
+ debugfs_create_file("dev_flags", 0400, intf->driver_folder, intf,
+ &rt2x00debug_fop_dev_flags);
- intf->cap_flags = debugfs_create_file("cap_flags", 0400,
- intf->driver_folder, intf,
- &rt2x00debug_fop_cap_flags);
+ debugfs_create_file("cap_flags", 0400, intf->driver_folder, intf,
+ &rt2x00debug_fop_cap_flags);
- intf->register_folder =
- debugfs_create_dir("register", intf->driver_folder);
+ register_folder = debugfs_create_dir("register", intf->driver_folder);
#define RT2X00DEBUGFS_CREATE_REGISTER_ENTRY(__intf, __name) \
({ \
if (debug->__name.read) { \
- (__intf)->__name##_off_entry = \
- debugfs_create_u32(__stringify(__name) "_offset", \
- 0600, \
- (__intf)->register_folder, \
- &(__intf)->offset_##__name); \
+ debugfs_create_u32(__stringify(__name) "_offset", 0600, \
+ register_folder, \
+ &(__intf)->offset_##__name); \
\
- (__intf)->__name##_val_entry = \
- debugfs_create_file(__stringify(__name) "_value", \
- 0600, \
- (__intf)->register_folder, \
- (__intf), \
- &rt2x00debug_fop_##__name); \
+ debugfs_create_file(__stringify(__name) "_value", 0600, \
+ register_folder, (__intf), \
+ &rt2x00debug_fop_##__name); \
} \
})
@@ -690,26 +662,21 @@ void rt2x00debug_register(struct rt2x00_dev *rt2x00dev)
#undef RT2X00DEBUGFS_CREATE_REGISTER_ENTRY
- intf->queue_folder =
- debugfs_create_dir("queue", intf->driver_folder);
+ queue_folder = debugfs_create_dir("queue", intf->driver_folder);
- intf->queue_frame_dump_entry =
- debugfs_create_file("dump", 0400, intf->queue_folder,
- intf, &rt2x00debug_fop_queue_dump);
+ debugfs_create_file("dump", 0400, queue_folder, intf,
+ &rt2x00debug_fop_queue_dump);
skb_queue_head_init(&intf->frame_dump_skbqueue);
init_waitqueue_head(&intf->frame_dump_waitqueue);
- intf->queue_stats_entry =
- debugfs_create_file("queue", 0400, intf->queue_folder,
- intf, &rt2x00debug_fop_queue_stats);
+ debugfs_create_file("queue", 0400, queue_folder, intf,
+ &rt2x00debug_fop_queue_stats);
#ifdef CONFIG_RT2X00_LIB_CRYPTO
if (rt2x00_has_cap_hw_crypto(rt2x00dev))
- intf->crypto_stats_entry =
- debugfs_create_file("crypto", 0444, intf->queue_folder,
- intf,
- &rt2x00debug_fop_crypto_stats);
+ debugfs_create_file("crypto", 0444, queue_folder, intf,
+ &rt2x00debug_fop_crypto_stats);
#endif
return;
@@ -724,28 +691,7 @@ void rt2x00debug_deregister(struct rt2x00_dev *rt2x00dev)
skb_queue_purge(&intf->frame_dump_skbqueue);
-#ifdef CONFIG_RT2X00_LIB_CRYPTO
- debugfs_remove(intf->crypto_stats_entry);
-#endif
- debugfs_remove(intf->queue_stats_entry);
- debugfs_remove(intf->queue_frame_dump_entry);
- debugfs_remove(intf->queue_folder);
- debugfs_remove(intf->rfcsr_val_entry);
- debugfs_remove(intf->rfcsr_off_entry);
- debugfs_remove(intf->rf_val_entry);
- debugfs_remove(intf->rf_off_entry);
- debugfs_remove(intf->bbp_val_entry);
- debugfs_remove(intf->bbp_off_entry);
- debugfs_remove(intf->eeprom_val_entry);
- debugfs_remove(intf->eeprom_off_entry);
- debugfs_remove(intf->csr_val_entry);
- debugfs_remove(intf->csr_off_entry);
- debugfs_remove(intf->register_folder);
- debugfs_remove(intf->dev_flags);
- debugfs_remove(intf->cap_flags);
- debugfs_remove(intf->chipset_entry);
- debugfs_remove(intf->driver_entry);
- debugfs_remove(intf->driver_folder);
+ debugfs_remove_recursive(intf->driver_folder);
kfree(intf->chipset_blob.data);
kfree(intf->driver_blob.data);
kfree(intf);
--
2.22.0
^ permalink raw reply related
* [PATCH] wireless: core: no need to check return value of debugfs_create functions
From: Greg Kroah-Hartman @ 2019-07-03 7:01 UTC (permalink / raw)
To: Johannes Berg, David S. Miller; +Cc: linux-wireless, netdev
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
never do something different based on this.
Cc: Johannes Berg <johannes@sipsolutions.net>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: linux-wireless@vger.kernel.org
Cc: netdev@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/wireless/core.c | 17 ++++++-----------
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/net/wireless/core.c b/net/wireless/core.c
index 037816163e70..339b0ccb3241 100644
--- a/net/wireless/core.c
+++ b/net/wireless/core.c
@@ -142,12 +142,10 @@ int cfg80211_dev_rename(struct cfg80211_registered_device *rdev,
if (result)
return result;
- if (rdev->wiphy.debugfsdir &&
- !debugfs_rename(rdev->wiphy.debugfsdir->d_parent,
- rdev->wiphy.debugfsdir,
- rdev->wiphy.debugfsdir->d_parent,
- newname))
- pr_err("failed to rename debugfs dir to %s!\n", newname);
+ if (rdev->wiphy.debugfsdir)
+ debugfs_rename(rdev->wiphy.debugfsdir->d_parent,
+ rdev->wiphy.debugfsdir,
+ rdev->wiphy.debugfsdir->d_parent, newname);
nl80211_notify_wiphy(rdev, NL80211_CMD_NEW_WIPHY);
@@ -886,11 +884,8 @@ int wiphy_register(struct wiphy *wiphy)
cfg80211_rdev_list_generation++;
/* add to debugfs */
- rdev->wiphy.debugfsdir =
- debugfs_create_dir(wiphy_name(&rdev->wiphy),
- ieee80211_debugfs_dir);
- if (IS_ERR(rdev->wiphy.debugfsdir))
- rdev->wiphy.debugfsdir = NULL;
+ rdev->wiphy.debugfsdir = debugfs_create_dir(wiphy_name(&rdev->wiphy),
+ ieee80211_debugfs_dir);
cfg80211_debugfs_rdev_add(rdev);
nl80211_notify_wiphy(rdev, NL80211_CMD_NEW_WIPHY);
--
2.22.0
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Daniel Drake @ 2019-07-03 7:42 UTC (permalink / raw)
To: Jes Sorensen
Cc: Chris Chiu, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team, Larry Finger
In-Reply-To: <4c99866e-55b7-8852-c078-6b31dce21ee4@gmail.com>
On Tue, Jul 2, 2019 at 8:42 PM Jes Sorensen <jes.sorensen@gmail.com> wrote:
> We definitely don't want to bring over the vendor code, since it's a
> pile of spaghetti, but we probably need to get something sorted. This
> went down the drain when the bluetooth driver was added without taking
> it into account - long after this driver was merged.
Yeah, I didn't mean bring over quite so literally.. Chris is studying
it and figuring out the neatest way to reimplement the required bits.
As for the relationship with bluetooth.. actually the bug that Chris
is working on here is that the rtl8xxxu wifi signal is totally
unusable *until* the bluetooth driver is loaded.
Once the bluetooth driver is loaded, at the point of bluetooth
firmware upload, the rtl8xxxu signal magiaclly strength becomes good.
I think this is consistent with other rtl8xxxu problem reports that we
saw lying around, although they had not been diagnosed in so much
detail.
The rtl8723bu vendor driver does not suffer this problem, it works
fine with or without the bluetooth driver in place.
Daniel
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: Fix wifi low signal strength issue of RTL8723BU
From: Daniel Drake @ 2019-07-03 7:51 UTC (permalink / raw)
To: Chris Chiu
Cc: Jes Sorensen, Kalle Valo, David Miller, linux-wireless, netdev,
Linux Kernel, Linux Upstreaming Team, Larry Finger
In-Reply-To: <CAB4CAwcVoWffpK8xR_UbXaGyHh8ZrrX_9vvzjAkWGKXQotpmYA@mail.gmail.com>
On Tue, Jul 2, 2019 at 4:01 PM Chris Chiu <chiu@endlessm.com> wrote:
> When the vendor driver invokes rtw_btcoex_HAL_Initialize, which will then
> call halbtc8723b1ant_SetAntPath to configure the registers in this patch.
> From the code, the registers will have different register settings per the
> antenna position and the phase. If the driver is in the InitHwConfig phase,
> the register value is identical to what rtl8xxxu driver does in enable_rf().
> However, the vendor driver will do halbtc8723b1ant_PsTdma() twice by
> halbtc8723b1ant_ActionWifiNotConnected() with the type argument 8 for
> PTA control about 200ms after InitHwConfig. The _ActionWifiNotConnected
> is invoked by the BTCOEXIST. I keep seeing the halbtc8723b1ant_PsTdma
> with type 8 been called every 2 seconds.
I see. So this is a measured step towards consistency with the vendor
driver. Maybe you can mention these details in the commit message.
> Yes, it ends up with 0x0c not matter what antenna position type is. Unless
> it's configured wifi only.
Also worth mentioning in the commit message then, that the 0xc
ACT_CONTROL value is effectively what the working vendor driver uses.
> > > - * 0x280, 0x00, 0x200, 0x80 - not clear
> > > + * Different settings per different antenna position.
> > > + * Antenna switch to BT: 0x280, 0x00 (inverse)
> > > + * Antenna switch to WiFi: 0x0, 0x280 (inverse)
> > > + * Antenna controlled by PTA: 0x200, 0x80 (inverse)
> > > */
> > > - rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x00);
> > > + rtl8xxxu_write32(priv, REG_S0S1_PATH_SWITCH, 0x80);
> >
> > I don't quite follow the comment here. Why are there 2 values listed
> > for each possibility, what do you mean by inverse? You say the
> > register settings were incorrect, but the previous value was 0x00
> > which you now document as "antenna switch to wifi" which sounds like
> > it was already correct?
> >
> > Which value does the vendor driver use?
> >
> The first column means the value for normal antenna installation, wifi
> on the main port. The second column is the value for inverse antenna
> installation. So if I want to manually switch the antenna for BT use,
> and the antenna installation is inverse, I need to set to 0x280. So 0x80
> means I want to switch to PTA and the antenna installation in inverse.
Still not quite clear what you mean by "inverse" here, but maybe I
just don't know anything about antennas. Is it that an antenna
connector has two pins and this one swaps the meaning of each pin?
Does the new value of 0x80 reflect what the vendor driver does in practice?
Thanks
Daniel
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox