* Re: [PATCH] brcmsmac: remove three set but not used variables
From: Kalle Valo @ 2019-08-06 12:38 UTC (permalink / raw)
To: YueHaibing
Cc: arend.vanspriel, franky.lin, hante.meuleman, chi-hsien.lin,
wright.feng, linux-kernel, netdev, linux-wireless,
brcm80211-dev-list.pdl, brcm80211-dev-list, YueHaibing
In-Reply-To: <20190726141535.33212-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c: In function 'brcms_c_set_gmode':
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5257:7: warning: variable 'preamble_restrict' set but not used [-Wunused-but-set-variable]
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5256:6: warning: variable 'preamble' set but not used [-Wunused-but-set-variable]
> drivers/net/wireless/broadcom/brcm80211/brcmsmac/main.c:5251:7: warning: variable 'shortslot_restrict' set but not used [-Wunused-but-set-variable]
>
> They are never used so can be removed.
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
de019a3bdd6e brcmsmac: remove three set but not used variables
--
https://patchwork.kernel.org/patch/11061171/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rtw88: pci: remove set but not used variable 'ip_sel'
From: Kalle Valo @ 2019-08-06 12:39 UTC (permalink / raw)
To: YueHaibing; +Cc: yhchuang, linux-kernel, netdev, linux-wireless, YueHaibing
In-Reply-To: <20190726142018.20792-1-yuehaibing@huawei.com>
YueHaibing <yuehaibing@huawei.com> wrote:
> Fixes gcc '-Wunused-but-set-variable' warning:
>
> drivers/net/wireless/realtek/rtw88/pci.c: In function 'rtw_pci_phy_cfg':
> drivers/net/wireless/realtek/rtw88/pci.c:993:6: warning:
> variable 'ip_sel' set but not used [-Wunused-but-set-variable]
>
> Reported-by: Hulk Robot <hulkci@huawei.com>
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Patch applied to wireless-drivers-next.git, thanks.
d1b68c118238 rtw88: pci: remove set but not used variable 'ip_sel'
--
https://patchwork.kernel.org/patch/11061177/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH net-next] rt2800usb: Add new rt2800usb device PLANEX GW-USMicroN
From: Kalle Valo @ 2019-08-06 12:40 UTC (permalink / raw)
To: Masanari Iida
Cc: sgruszka, helmut.schaa, davem, linux-wireless, netdev,
linux-kernel, Masanari Iida
In-Reply-To: <20190728140742.3280-1-standby24x7@gmail.com>
Masanari Iida <standby24x7@gmail.com> wrote:
> This patch add a device ID for PLANEX GW-USMicroN.
> Without this patch, I had to echo the device IDs in order to
> recognize the device.
>
> # lsusb |grep PLANEX
> Bus 002 Device 005: ID 2019:ed14 PLANEX GW-USMicroN
>
> Signed-off-by: Masanari Iida <standby24x7@gmail.com>
> Acked-by: Stanislaw Gruszka <sgruszka@redhat.com>
Patch applied to wireless-drivers-next.git, thanks.
706f0182b1ad rt2800usb: Add new rt2800usb device PLANEX GW-USMicroN
--
https://patchwork.kernel.org/patch/11062963/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] rsi: return explicit error values
From: Kalle Valo @ 2019-08-06 12:41 UTC (permalink / raw)
To: Enrico Weigelt, metux IT consult
Cc: linux-kernel, amitkarwar, siva8118, linux-wireless, netdev
In-Reply-To: <1564413872-10720-1-git-send-email-info@metux.net>
"Enrico Weigelt, metux IT consult" <info@metux.net> wrote:
> From: Enrico Weigelt <info@metux.net>
>
> Explicitly return constants instead of variable (and rely on
> it to be explicitly initialized), if the value is supposed
> to be fixed anyways. Align it with the rest of the driver,
> which does it the same way.
>
> Signed-off-by: Enrico Weigelt <info@metux.net>
Patch applied to wireless-drivers-next.git, thanks.
706f0182b1ad rt2800usb: Add new rt2800usb device PLANEX GW-USMicroN
--
https://patchwork.kernel.org/patch/11064039/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/5] rtlwifi: rtl8188ee: Remove unused GET_XXX and SET_XXX descriptor macros
From: Kalle Valo @ 2019-08-06 12:42 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190731003304.14377-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> As the first step in converting from macros that get/set information
> in the RX and TX descriptors, unused macros are being removed.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
5 patches applied to wireless-drivers-next.git, thanks.
b97494f48d5a rtlwifi: rtl8188ee: Remove unused GET_XXX and SET_XXX descriptor macros
66b2b064ee54 rtlwifi: rtl88188ee: Replace local bit manipulation macros
36eda7568f2e rtlwifi: rtl8188ee: Convert macros that set descriptor
e53e30ba15da rtlwifi: rtl8188ee: Convert inline routines to little-endian words
d1d1a96bdb44 rtlwifi: rtl8188ee: Remove local configuration variable
--
https://patchwork.kernel.org/patch/11066963/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH v3 1/3] rtw88: allow c2h operation in irq context
From: Kalle Valo @ 2019-08-06 12:42 UTC (permalink / raw)
To: yhchuang; +Cc: linux-wireless, briannorris, sgruszka
In-Reply-To: <1564575767-27557-2-git-send-email-yhchuang@realtek.com>
<yhchuang@realtek.com> wrote:
> From: Yan-Hsuan Chuang <yhchuang@realtek.com>
>
> Some of the c2h operations are small and can be done
> under interrupt context. For the rest that requires
> more operations or can go sleep, enqueue onto c2h queue.
>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
3 patches applied to wireless-drivers-next.git, thanks.
0d762f031d70 rtw88: allow c2h operation in irq context
713a30de45a2 rtw88: enclose c2h cmd handle with mutex
4136214f7c46 rtw88: add BT co-existence support
--
https://patchwork.kernel.org/patch/11067657/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 1/4] rtlwifi: rtl8192ce: Remove unused GET_XXX and SET_XXX
From: Kalle Valo @ 2019-08-06 12:43 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, pkshih, Larry Finger
In-Reply-To: <20190802012102.7945-2-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> As the first step in converting from macros that get/set information
> in the RX and TX descriptors, unused macros are being removed.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
4 patches applied to wireless-drivers-next.git, thanks.
49a52d05a3c7 rtlwifi: rtl8192ce: Remove unused GET_XXX and SET_XXX
a246b9291433 rtlwifi: rtl8192ce: Replace local bit manipulation macros
98fd8db59a00 rtlwifi: rtl8192ce: Convert macros that set descriptor
c85a63766738 rtlwifi: rtl8192ce: Convert inline routines to little-endian words
--
https://patchwork.kernel.org/patch/11071637/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH] Revert "mwifiex: fix system hang problem after resume"
From: Kalle Valo @ 2019-08-06 12:43 UTC (permalink / raw)
To: Brian Norris
Cc: Amitkumar Karwar, Nishant Sarmukadam, Ganapathi Bhat, Xinming Hu,
linux-wireless, linux-kernel, Dmitry Torokhov, Doug Anderson,
Matthias Kaehlcke, Brian Norris, Amitkumar Karwar
In-Reply-To: <20190805171504.48122-1-briannorris@chromium.org>
Brian Norris <briannorris@chromium.org> wrote:
> This reverts commit 437322ea2a36d112e20aa7282c869bf924b3a836.
>
> This above-mentioned "fix" does not actually do anything to prevent a
> race condition. It simply papers over it so that the issue doesn't
> appear.
>
> If this is a real problem, it should be explained better than the above
> commit does, and an alternative, non-racy solution should be found.
>
> For further reason to revert this: there's no reason we can't try
> resetting the card when it's *actually* stuck in host-sleep mode. So
> instead, this is unnecessarily creating scenarios where we can't recover
> Wifi (and in fact, I'm fielding reports of Chromebooks that can't
> recover after the aforementioned commit).
>
> Note that this was proposed in 2017 and Ack'ed then, but due to my
> marking as RFC, it never went anywhere:
>
> https://patchwork.kernel.org/patch/9657277/
> [RFC] Revert "mwifiex: fix system hang problem after resume"
>
> Cc: Amitkumar Karwar <akarwar@marvell.com>
> Signed-off-by: Brian Norris <briannorris@chromium.org>
> Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Acked-by: Amitkumar Karwar <amitkarwar@gmail.com>
> Tested-by: Matthias Kaehlcke <mka@chromium.org>
Patch applied to wireless-drivers-next.git, thanks.
654026df2635 Revert "mwifiex: fix system hang problem after resume"
--
https://patchwork.kernel.org/patch/11077645/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH V2] b43legacy: Remove pointless cond_resched() wrapper
From: Kalle Valo @ 2019-08-06 12:44 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: linux-wireless, Larry Finger, b43-dev
In-Reply-To: <alpine.DEB.2.21.1908021353190.3924@nanos.tec.linutronix.de>
Thomas Gleixner <tglx@linutronix.de> wrote:
> cond_resched() can be used unconditionally. If CONFIG_PREEMPT is set, it
> becomes a NOP scheduler wise.
>
> Also the B43_BUG_ON() in that wrapper is a homebrewn variant of
> __might_sleep() which is part of cond_resched() already.
>
> Remove the cruft and invoke cond_resched() directly.
>
> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
> Reviewed-by: Larry Finger <Larry.Finger@lwfinger.net>
> Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Patch applied to wireless-drivers-next.git, thanks.
6004cf298a41 b43legacy: Remove pointless cond_resched() wrapper
--
https://patchwork.kernel.org/patch/11073225/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
^ permalink raw reply
* Re: [PATCH 3/6] staging: wilc1000: remove unused members
From: Dan Carpenter @ 2019-08-06 12:46 UTC (permalink / raw)
To: Adham.Abozaeid; +Cc: linux-wireless, devel, gregkh, johannes, Ajay.Kathat
In-Reply-To: <20190725213125.2810-4-adham.abozaeid@microchip.com>
On Thu, Jul 25, 2019 at 09:31:34PM +0000, Adham.Abozaeid@microchip.com wrote:
> From: Adham Abozaeid <adham.abozaeid@microchip.com>
>
> remove obtaining_ip from struct wilc_vif
>
How is this "unused"? It looks like it is used to me.
regards,
dan carpenter
^ permalink raw reply
* Re: Regression with the latest iwlwifi-9260-*-46.ucode
From: Takashi Iwai @ 2019-08-06 13:04 UTC (permalink / raw)
To: Luca Coelho
Cc: dor.shaish, Josh Boyer, Johannes Berg, Emmanuel Grumbach,
linux-wireless, linux-kernel
In-Reply-To: <a394850acbe0f05d6428ce466ecac1cfaefadd59.camel@coelho.fi>
On Mon, 05 Aug 2019 14:03:55 +0200,
Luca Coelho wrote:
>
> On Mon, 2019-08-05 at 13:10 +0300, Luca Coelho wrote:
> > On Mon, 2019-08-05 at 12:05 +0200, Takashi Iwai wrote:
> > > On Mon, 05 Aug 2019 11:53:33 +0200,
> > > Luca Coelho wrote:
> > > > On Mon, 2019-08-05 at 12:48 +0300, Luca Coelho wrote:
> > > > > On Sun, 2019-07-21 at 18:43 +0200, Takashi Iwai wrote:
> > > > > > On Sat, 20 Jul 2019 22:49:33 +0200,
> > > > > > Luca Coelho wrote:
> > > > > > > On Sat, 2019-07-20 at 22:42 +0200, Takashi Iwai wrote:
> > > > > > > > On Fri, 19 Jul 2019 20:07:46 +0200,
> > > > > > > > Takashi Iwai wrote:
> > > > > > > > > On Fri, 19 Jul 2019 18:36:53 +0200,
> > > > > > > > > Luciano Coelho wrote:
> > > > > > > > > > Adding Dor.
> > > > > > > > > >
> > > > > > > > > > Hi Takashi,
> > > > > > > > > >
> > > > > > > > > > Do you have full logs of the crash? We can't see much from the log
> > > > > > > > > > snippet pasted in the bug report.
> > > > > > > > >
> > > > > > > > > OK, I'll ask reporters. If you have a SUSE/openSUSE bugzilla account,
> > > > > > > > > feel free to join there.
> > > > > > > >
> > > > > > > > FYI, the dmesg's have been uploaded to the same bugzilla entry:
> > > > > > > > https://bugzilla.opensuse.org/show_bug.cgi?id=1142128
> > > > > > > >
> > > > > > >
> > > > > > > Thanks!
> > > > > > >
> > > > > > > BTW, I pushed new firmwares to our firmware tree in git.kernel.org
> > > > > > > today. This is the patch:
> > > > > > >
> > > > > > > https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/commit/?id=b5f09bb4f816abace0227d0f4e749859364cef6b
> > > > > > >
> > > > > > > It would be great if you can try it out and let us know whether the problem is gone or not.
> > > > > >
> > > > > > I created a test package and asked for testing.
> > > > > > The test result seems negative, showing the same error,
> > > > > > unfortunately.
> > > > > >
> > > > > > The dmesg was uploaded on the bugzilla entry.
> > > > >
> > > > > Thanks Takashi! We will look into them as soon as possible (sorry for
> > > > > the late reply, I just came back from vacations).
> > > >
> > > > Actually, I just noticed that your bugzilla is closed as "RESOLVED
> > > > FIXED". Is this still an issue?
> > >
> > > It's "closed" because our package contains the revert.
> > >
> > > > This seems like a mismatch between the WiFi and BT firmwares... And
> > > > most likely the same issue as this:
> > > >
> > > > https://bugzilla.kernel.org/show_bug.cgi?id=202163
> > >
> > > OK, so we need the update of the whole linux-firmware.
> > > I'll refresh the package and ask for testing.
> >
> > I'm not sure the new BT firmware is in linux-firmware yet, since I
> > don't handle BT stuff. I hope it is.
>
> I just double-checked this and got confirmation that the latest BT
> firmware in linux-firmware.git is compatible with the latest WiFi
> firmware there as well.
>
> The only caveat is that the machine needs to be cold-booted for it to
> work....
>
> But we are taking steps to make sure this will not happen next time
> (i.e. for future hardware), by syncing our BT and WiFi firmware
> releases.
Now we got a feedback from the latest linux-firmware (20190726) and
surprising the result was negative. The dmesg after the cold boot is
found at:
https://bugzilla.suse.com/show_bug.cgi?id=1142128#c26
The kernel is 5.2.3, so it should be new enough.
If anything else needed (or something missing), let us know.
thanks,
Takashi
^ permalink raw reply
* [bug report] iwlwifi: Add support for SAR South Korea limitation
From: Dan Carpenter @ 2019-08-06 14:24 UTC (permalink / raw)
To: haim.dreyfuss; +Cc: linux-wireless
Hello Haim Dreyfuss,
The patch 0c3d7282233c: "iwlwifi: Add support for SAR South Korea
limitation" from Feb 27, 2019, leads to the following static checker
warning:
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:166 iwl_acpi_get_mcc()
warn: passing a valid pointer to 'PTR_ERR'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c
153 int iwl_acpi_get_mcc(struct device *dev, char *mcc)
154 {
155 union acpi_object *wifi_pkg, *data;
156 u32 mcc_val;
157 int ret, tbl_rev;
158
159 data = iwl_acpi_get_object(dev, ACPI_WRDD_METHOD);
160 if (IS_ERR(data))
161 return PTR_ERR(data);
162
163 wifi_pkg = iwl_acpi_get_wifi_pkg(dev, data, ACPI_WRDD_WIFI_DATA_SIZE,
164 &tbl_rev);
165 if (IS_ERR(wifi_pkg) || tbl_rev != 0) {
^^^^^^^^^^^^
wifi_pkg is not a valid error code. Also it feels like it might be more
future proof to blacklist rev 1 instead of whitelisting rev 0.
166 ret = PTR_ERR(wifi_pkg);
167 goto out_free;
168 }
169
170 if (wifi_pkg->package.elements[1].type != ACPI_TYPE_INTEGER) {
171 ret = -EINVAL;
172 goto out_free;
173 }
174
175 mcc_val = wifi_pkg->package.elements[1].integer.value;
176
177 mcc[0] = (mcc_val >> 8) & 0xff;
178 mcc[1] = mcc_val & 0xff;
179 mcc[2] = '\0';
180
181 ret = 0;
182 out_free:
183 kfree(data);
184 return ret;
185 }
regards,
dan carpenter
^ permalink raw reply
* Re: [bug report] iwlwifi: Add support for SAR South Korea limitation
From: Dan Carpenter @ 2019-08-06 14:30 UTC (permalink / raw)
To: haim.dreyfuss; +Cc: linux-wireless
In-Reply-To: <20190806142435.GA13072@mwanda>
Oops. There are a couple other related warnings as well.
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:166 iwl_acpi_get_mcc() warn: passing a valid pointer to 'PTR_ERR'
drivers/net/wireless/intel/iwlwifi/fw/acpi.c:228 iwl_acpi_get_eckv() warn: passing a valid pointer to 'PTR_ERR'
drivers/net/wireless/intel/iwlwifi/mvm/fw.c:696 iwl_mvm_sar_get_wrds_table() warn: passing a valid pointer to 'PTR_ERR'
drivers/net/wireless/intel/iwlwifi/mvm/fw.c:733 iwl_mvm_sar_get_ewrd_table() warn: passing a valid pointer to 'PTR_ERR'
drivers/net/wireless/intel/iwlwifi/mvm/fw.c:793 iwl_mvm_sar_get_wgds_table() warn: passing a valid pointer to 'PTR_ERR'
regards,
dan carpenter
^ permalink raw reply
* Realtek r8822be wireless card fails to work with new rtw88 kernel module
From: 고준 @ 2019-08-06 14:31 UTC (permalink / raw)
To: linux-wireless, netdev, linux-kernel
Hello,
I recently reported a bug to Ubuntu regarding a regression in wireless
driver support for the Realtek r8822be wireless chipset. The issue
link on launchpad is:
https://bugs.launchpad.net/bugs/1838133
After Canonical developers triaged the bug they determined that the
problem lies upstream, and instructed me to send mails to the relevant
kernel module maintainers at Realtek and to the general kernel.org
mailing list.
I built kernel 5.3.0-rc1+ with the latest realtek drivers from
wireless-drivers-next but my Realtek r8822be doesn't work with
rtw88/rtwpci kernel modules.
Please let me know if there is any additional information I can
provide that would help in debugging this issue.
Best regards,
Jun
Link to GPG Public Key:
https://keybase.io/gojun077#show-public
Backup link:
https://keys.openpgp.org/vks/v1/by-fingerprint/79F173A93EB3623D32F86309A56930CF7235138D
^ permalink raw reply
* [PATCH] mt76: move mt76_tx_tasklet in mt76 module
From: Lorenzo Bianconi @ 2019-08-06 17:31 UTC (permalink / raw)
To: nbd; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
Move mt76{15,03}_tx_tasklet in mt76 module since it is shared between
mt7615 and mt7603 drivers
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/wireless/mediatek/mt76/mt76.h | 1 +
drivers/net/wireless/mediatek/mt76/mt7603/dma.c | 11 ++---------
drivers/net/wireless/mediatek/mt76/mt7615/dma.c | 9 +--------
drivers/net/wireless/mediatek/mt76/tx.c | 8 ++++++++
4 files changed, 12 insertions(+), 17 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt76.h b/drivers/net/wireless/mediatek/mt76/mt76.h
index c755b5ad5e2a..dd9fbb1f79a9 100644
--- a/drivers/net/wireless/mediatek/mt76/mt76.h
+++ b/drivers/net/wireless/mediatek/mt76/mt76.h
@@ -722,6 +722,7 @@ void mt76_stop_tx_queues(struct mt76_dev *dev, struct ieee80211_sta *sta,
bool send_bar);
void mt76_txq_schedule(struct mt76_dev *dev, enum mt76_txq_id qid);
void mt76_txq_schedule_all(struct mt76_dev *dev);
+void mt76_tx_tasklet(unsigned long data);
void mt76_release_buffered_frames(struct ieee80211_hw *hw,
struct ieee80211_sta *sta,
u16 tids, int nframes,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7603/dma.c b/drivers/net/wireless/mediatek/mt76/mt7603/dma.c
index 58dc511f93c5..d13cf1ca1671 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7603/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7603/dma.c
@@ -135,14 +135,6 @@ mt7603_init_rx_queue(struct mt7603_dev *dev, struct mt76_queue *q,
return 0;
}
-static void
-mt7603_tx_tasklet(unsigned long data)
-{
- struct mt7603_dev *dev = (struct mt7603_dev *)data;
-
- mt76_txq_schedule_all(&dev->mt76);
-}
-
static int mt7603_poll_tx(struct napi_struct *napi, int budget)
{
struct mt7603_dev *dev;
@@ -181,7 +173,8 @@ int mt7603_dma_init(struct mt7603_dev *dev)
init_waitqueue_head(&dev->mt76.mmio.mcu.wait);
skb_queue_head_init(&dev->mt76.mmio.mcu.res_q);
- tasklet_init(&dev->mt76.tx_tasklet, mt7603_tx_tasklet, (unsigned long)dev);
+ tasklet_init(&dev->mt76.tx_tasklet, mt76_tx_tasklet,
+ (unsigned long)dev);
mt76_clear(dev, MT_WPDMA_GLO_CFG,
MT_WPDMA_GLO_CFG_TX_DMA_EN |
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/dma.c b/drivers/net/wireless/mediatek/mt76/mt7615/dma.c
index 3fe24d92d4fa..2321128b2a69 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/dma.c
@@ -90,13 +90,6 @@ void mt7615_queue_rx_skb(struct mt76_dev *mdev, enum mt76_rxq_id q,
}
}
-static void mt7615_tx_tasklet(unsigned long data)
-{
- struct mt7615_dev *dev = (struct mt7615_dev *)data;
-
- mt76_txq_schedule_all(&dev->mt76);
-}
-
static int mt7615_poll_tx(struct napi_struct *napi, int budget)
{
static const u8 queue_map[] = {
@@ -128,7 +121,7 @@ int mt7615_dma_init(struct mt7615_dev *dev)
mt76_dma_attach(&dev->mt76);
- tasklet_init(&dev->mt76.tx_tasklet, mt7615_tx_tasklet,
+ tasklet_init(&dev->mt76.tx_tasklet, mt76_tx_tasklet,
(unsigned long)dev);
mt76_wr(dev, MT_WPDMA_GLO_CFG,
diff --git a/drivers/net/wireless/mediatek/mt76/tx.c b/drivers/net/wireless/mediatek/mt76/tx.c
index 5397827668b9..05ec1f4665e3 100644
--- a/drivers/net/wireless/mediatek/mt76/tx.c
+++ b/drivers/net/wireless/mediatek/mt76/tx.c
@@ -568,6 +568,14 @@ void mt76_txq_schedule_all(struct mt76_dev *dev)
}
EXPORT_SYMBOL_GPL(mt76_txq_schedule_all);
+void mt76_tx_tasklet(unsigned long data)
+{
+ struct mt76_dev *dev = (struct mt76_dev *)data;
+
+ mt76_txq_schedule_all(dev);
+}
+EXPORT_SYMBOL_GPL(mt76_tx_tasklet);
+
void mt76_stop_tx_queues(struct mt76_dev *dev, struct ieee80211_sta *sta,
bool send_bar)
{
--
2.21.0
^ permalink raw reply related
* Re: pull-request: wireless-drivers 2019-08-06
From: David Miller @ 2019-08-06 18:49 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87h86ufs89.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 06 Aug 2019 14:28:22 +0300
> here's a pull request to net tree for v5.3, more information below.
> Please let me know if there are any problems.
Pulled, thanks Kalle.
^ permalink raw reply
* Re: [PATCH 3/6] staging: wilc1000: remove unused members
From: Adham.Abozaeid @ 2019-08-06 19:32 UTC (permalink / raw)
To: dan.carpenter; +Cc: linux-wireless, devel, gregkh, johannes, Ajay.Kathat
In-Reply-To: <20190806124656.GH1974@kadam>
Hi Dan
On 8/6/19 5:46 AM, Dan Carpenter wrote:
> External E-Mail
>
>
> On Thu, Jul 25, 2019 at 09:31:34PM +0000, Adham.Abozaeid@microchip.com wrote:
>> From: Adham Abozaeid <adham.abozaeid@microchip.com>
>>
>> remove obtaining_ip from struct wilc_vif
>>
> How is this "unused"? It looks like it is used to me.
The main usage of obtaining_ip was to track the inetadd_notifier status.
After removing the notifier and ip address timeout timer in the first and second patch,
the remaining usage became meaningless, and could be removed.
> regards,
> dan carpenter
>
>
^ permalink raw reply
* Re: [PATCH -next] iwlwifi: dbg: work around clang bug by marking debug strings static
From: Nick Desaulniers @ 2019-08-06 22:37 UTC (permalink / raw)
To: Johannes Berg
Cc: Michael Ellerman, Kalle Valo, Luca Coelho, Arnd Bergmann,
Nathan Chancellor, Emmanuel Grumbach, Intel Linux Wireless,
David S. Miller, Shahar S Matityahu, Sara Sharon, linux-wireless,
netdev, LKML, clang-built-linux
In-Reply-To: <3a2b6d4f9356d54ab8e83fbf25ba9c5f50181f0d.camel@sipsolutions.net>
On Thu, Aug 1, 2019 at 12:11 AM Johannes Berg <johannes@sipsolutions.net> wrote:
>
>
> > Luca, you said this was already fixed in your internal tree, and the fix
> > would appear soon in next, but I don't see anything in linux-next?
>
> Luca is still on vacation, but I just sent out a version of the patch we
> had applied internally.
>
> Also turns out it wasn't actually _fixed_, just _moved_, so those
> internal patches wouldn't have helped anyway.
Thanks for the report. Do you have a link?
I'll rebase my patch then.
--
Thanks,
~Nick Desaulniers
^ permalink raw reply
* Re: Realtek r8822be wireless card fails to work with new rtw88 kernel module
From: Brian Norris @ 2019-08-07 0:30 UTC (permalink / raw)
To: 고준
Cc: linux-wireless, <netdev@vger.kernel.org>, Linux Kernel,
Tony Chuang
In-Reply-To: <CAH040W7fdd-ND4-QG3DwGpFAPTMGB4zzuXYohMdfoSejV6XE_Q@mail.gmail.com>
+ yhchuang
On Tue, Aug 6, 2019 at 7:32 AM 고준 <gojun077@gmail.com> wrote:
>
> Hello,
>
> I recently reported a bug to Ubuntu regarding a regression in wireless
> driver support for the Realtek r8822be wireless chipset. The issue
> link on launchpad is:
>
> https://bugs.launchpad.net/bugs/1838133
>
> After Canonical developers triaged the bug they determined that the
> problem lies upstream, and instructed me to send mails to the relevant
> kernel module maintainers at Realtek and to the general kernel.org
> mailing list.
>
> I built kernel 5.3.0-rc1+ with the latest realtek drivers from
> wireless-drivers-next but my Realtek r8822be doesn't work with
> rtw88/rtwpci kernel modules.
>
> Please let me know if there is any additional information I can
> provide that would help in debugging this issue.
Any chance this would help you?
https://patchwork.kernel.org/patch/11065631/
Somebody else was complaining about 8822be regressions that were fixed
with that.
Brian
^ permalink raw reply
* RE: Realtek r8822be wireless card fails to work with new rtw88 kernel module
From: Tony Chuang @ 2019-08-07 2:33 UTC (permalink / raw)
To: Brian Norris, 고준
Cc: linux-wireless, <netdev@vger.kernel.org>, Linux Kernel
In-Reply-To: <CA+ASDXM6Jz7YY9XUj6QKv5VJCED-BnQ5K1UZHNApB9p6qTWtgg@mail.gmail.com>
> + yhchuang
>
> On Tue, Aug 6, 2019 at 7:32 AM 고준 <gojun077@gmail.com> wrote:
> >
> > Hello,
> >
> > I recently reported a bug to Ubuntu regarding a regression in wireless
> > driver support for the Realtek r8822be wireless chipset. The issue
> > link on launchpad is:
> >
> > https://bugs.launchpad.net/bugs/1838133
> >
> > After Canonical developers triaged the bug they determined that the
> > problem lies upstream, and instructed me to send mails to the relevant
> > kernel module maintainers at Realtek and to the general kernel.org
> > mailing list.
> >
> > I built kernel 5.3.0-rc1+ with the latest realtek drivers from
> > wireless-drivers-next but my Realtek r8822be doesn't work with
> > rtw88/rtwpci kernel modules.
> >
> > Please let me know if there is any additional information I can
> > provide that would help in debugging this issue.
>
> Any chance this would help you?
>
> https://patchwork.kernel.org/patch/11065631/
>
> Somebody else was complaining about 8822be regressions that were fixed
> with that.
>
I hope it could fix it.
And as "r8822be" was dropped, it is preferred to use "rtw88" instead.
I have received two kinds of failures that cause driver stop working.
One is the MSI interrupt should be enabled on certain platforms.
Another is the RFE type of the card, could you send more dmesg to me?
Yan-Hsuan
^ permalink raw reply
* Re: [PATCH -next] iwlwifi: dbg: work around clang bug by marking debug strings static
From: Nathan Chancellor @ 2019-08-07 5:15 UTC (permalink / raw)
To: Nick Desaulniers
Cc: Johannes Berg, Michael Ellerman, Kalle Valo, Luca Coelho,
Arnd Bergmann, Emmanuel Grumbach, Intel Linux Wireless,
David S. Miller, Shahar S Matityahu, Sara Sharon, linux-wireless,
netdev, LKML, clang-built-linux
In-Reply-To: <CAKwvOdmBeB1BezsGh=cK=U9m8goKzZnngDRzNM7B1voZfh8yWg@mail.gmail.com>
On Tue, Aug 06, 2019 at 03:37:42PM -0700, Nick Desaulniers wrote:
> On Thu, Aug 1, 2019 at 12:11 AM Johannes Berg <johannes@sipsolutions.net> wrote:
> >
> >
> > > Luca, you said this was already fixed in your internal tree, and the fix
> > > would appear soon in next, but I don't see anything in linux-next?
> >
> > Luca is still on vacation, but I just sent out a version of the patch we
> > had applied internally.
> >
> > Also turns out it wasn't actually _fixed_, just _moved_, so those
> > internal patches wouldn't have helped anyway.
>
> Thanks for the report. Do you have a link?
> I'll rebase my patch then.
> --
> Thanks,
> ~Nick Desaulniers
Just for everyone else (since I commented on our issue tracker), this is
now fixed in Linus's tree as of commit 1f6607250331 ("iwlwifi: dbg_ini:
fix compile time assert build errors").
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH -next] iwlwifi: dbg: work around clang bug by marking debug strings static
From: Luciano Coelho @ 2019-08-07 5:24 UTC (permalink / raw)
To: Nathan Chancellor, Nick Desaulniers
Cc: Johannes Berg, Michael Ellerman, Kalle Valo, Arnd Bergmann,
Emmanuel Grumbach, Intel Linux Wireless, David S. Miller,
Shahar S Matityahu, Sara Sharon, linux-wireless, netdev, LKML,
clang-built-linux
In-Reply-To: <20190807051516.GA117639@archlinux-threadripper>
On Tue, 2019-08-06 at 22:15 -0700, Nathan Chancellor wrote:
> On Tue, Aug 06, 2019 at 03:37:42PM -0700, Nick Desaulniers wrote:
> > On Thu, Aug 1, 2019 at 12:11 AM Johannes Berg <johannes@sipsolutions.net> wrote:
> > >
> > > > Luca, you said this was already fixed in your internal tree, and the fix
> > > > would appear soon in next, but I don't see anything in linux-next?
> > >
> > > Luca is still on vacation, but I just sent out a version of the patch we
> > > had applied internally.
> > >
> > > Also turns out it wasn't actually _fixed_, just _moved_, so those
> > > internal patches wouldn't have helped anyway.
> >
> > Thanks for the report. Do you have a link?
> > I'll rebase my patch then.
> > --
> > Thanks,
> > ~Nick Desaulniers
>
> Just for everyone else (since I commented on our issue tracker), this is
> now fixed in Linus's tree as of commit 1f6607250331 ("iwlwifi: dbg_ini:
> fix compile time assert build errors").
Yes, thanks Nathan! I was just digging for this patch to reply to you,
I'm still catching up with what happened during my vacations.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] mt76: move mt76_tx_tasklet in mt76 module
From: Felix Fietkau @ 2019-08-07 6:57 UTC (permalink / raw)
To: Lorenzo Bianconi; +Cc: lorenzo.bianconi, linux-wireless, ryder.lee, royluo
In-Reply-To: <527fdc4e453cbc1408500625c0080d9c59d9e1dd.1565112514.git.lorenzo@kernel.org>
On 2019-08-06 19:31, Lorenzo Bianconi wrote:
> Move mt76{15,03}_tx_tasklet in mt76 module since it is shared between
> mt7615 and mt7603 drivers
>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
I think it would be nice to get rid of the EXPORT_SYMBOL_GPL for
mt76_tx_tasklet by moving the tasklet_init call to mt76_alloc_device().
That way, dev->mt76.tx_tasklet will be set to mt76_tx_tasklet by
default, but automatically overwritten for drivers that have custom
implementations (76x02 / usb).
- Felix
^ permalink raw reply
* [PATCH 1/4] mac80211: fix TX legacy rate reporting when tx_status_ext is used
From: John Crispin @ 2019-08-07 7:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
The RX Radiotap header length was not calculated properly when reporting
legacy rates using tx_status_ext.
fixes commit 3d07ffcaf320 ("mac80211: add struct ieee80211_tx_status
support to ieee80211_add_tx_radiotap_header")
Signed-off-by: John Crispin <john@phrozen.org>
---
net/mac80211/status.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index f03aa8924d23..f984943cdabd 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -260,9 +260,15 @@ static int ieee80211_tx_radiotap_len(struct ieee80211_tx_info *info,
int len = sizeof(struct ieee80211_radiotap_header);
/* IEEE80211_RADIOTAP_RATE rate */
- if (info->status.rates[0].idx >= 0 &&
- !(info->status.rates[0].flags & (IEEE80211_TX_RC_MCS |
- IEEE80211_TX_RC_VHT_MCS)))
+ if (status && status->rate && !(status->rate->flags &
+ (RATE_INFO_FLAGS_MCS |
+ RATE_INFO_FLAGS_60G |
+ RATE_INFO_FLAGS_VHT_MCS |
+ RATE_INFO_FLAGS_HE_MCS)))
+ len += 2;
+ else if (info->status.rates[0].idx >= 0 &&
+ !(info->status.rates[0].flags &
+ (IEEE80211_TX_RC_MCS | IEEE80211_TX_RC_VHT_MCS)))
len += 2;
/* IEEE80211_RADIOTAP_TX_FLAGS */
--
2.20.1
^ permalink raw reply related
* [PATCH 2/4] mac80211: fix bad guard when reporting legacy rates
From: John Crispin @ 2019-08-07 7:59 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, John Crispin
In-Reply-To: <20190807075949.32414-1-john@phrozen.org>
When reporting legacy rates inside the TX Radiotap header we need to split
the check u between "uses tx_statua_ext" and "is legacy rate". Not doing so
would make the code drop into the !tx_status_ext path.
fixes commit 3d07ffcaf320 ("mac80211: add struct ieee80211_tx_status
support to ieee80211_add_tx_radiotap_header")
Signed-off-by: John Crispin <john@phrozen.org>
---
net/mac80211/status.c | 15 ++++++++-------
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index f984943cdabd..eaea07db83e7 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -327,13 +327,14 @@ ieee80211_add_tx_radiotap_header(struct ieee80211_local *local,
/* IEEE80211_RADIOTAP_RATE */
- if (status && status->rate && !(status->rate->flags &
- (RATE_INFO_FLAGS_MCS |
- RATE_INFO_FLAGS_60G |
- RATE_INFO_FLAGS_VHT_MCS |
- RATE_INFO_FLAGS_HE_MCS)))
- legacy_rate = status->rate->legacy;
- else if (info->status.rates[0].idx >= 0 &&
+ if (status && status->rate) {
+ if (!(status->rate->flags &
+ (RATE_INFO_FLAGS_MCS |
+ RATE_INFO_FLAGS_60G |
+ RATE_INFO_FLAGS_VHT_MCS |
+ RATE_INFO_FLAGS_HE_MCS)))
+ legacy_rate = status->rate->legacy;
+ } else if (info->status.rates[0].idx >= 0 &&
!(info->status.rates[0].flags & (IEEE80211_TX_RC_MCS |
IEEE80211_TX_RC_VHT_MCS)))
legacy_rate =
--
2.20.1
^ permalink raw reply related
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