* Re: Two rtlwifi drivers?
From: Greg Kroah-Hartman @ 2017-10-11 13:13 UTC (permalink / raw)
To: Kalle Valo
Cc: Larry Finger, Dan Carpenter, Ping-Ke Shih, Yan-Hsuan Chuang,
Johannes Berg, Souptick Joarder, devel, linux-wireless,
kernel-janitors
In-Reply-To: <87k202qcjr.fsf@kamboji.qca.qualcomm.com>
On Wed, Oct 11, 2017 at 12:06:00PM +0300, Kalle Valo wrote:
> (Sorry for taking so long with the reply, I wanted first to check what
> the rtlwifi in staging contains.)
>
> Larry Finger <Larry.Finger@lwfinger.net> writes:
>
> > On 08/24/2017 07:14 AM, Kalle Valo wrote:
> >> Dan Carpenter <dan.carpenter@oracle.com> writes:
> >>
> >>> Smatch is distrustful of the "capab" value and marks it as user
> >>> controlled. I think it actually comes from the firmware? Anyway, I
> >>> looked at other drivers and they added a bounds check and it seems like
> >>> a harmless thing to have so I have added it here as well.
> >>>
> >>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >>>
> >>> diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
> >>> index f7f207cbaee3..a30b928d5ee1 100644
> >>> --- a/drivers/staging/rtlwifi/base.c
> >>> +++ b/drivers/staging/rtlwifi/base.c
> >>
> >> I'm getting slightly annoyed that we now apparently have two duplicate
> >> rtlwifi drivers (with the same name!) and I'm being spammed by staging
> >> patches. Was this really a smart thing to do? And what will be the
> >> future of these two drivers?
> >>
> >> (Of course this is not directed to Dan, he is just fixing bugs found by
> >> smatch, but more like a general question.)
> >
> > That was the decision that you and Greg made. The version in
> > wireless-drivers needs many patches to handle the new device. The
> > progress in applying these to wireless-drivers was very slow for many
> > reasons. Keeping a single version of that code would have required
> > coordination between you and Greg, which was discouraged.
>
> I don't recall deciding anything, all I did was asking for more info
> about the new code. I was against the idea since I first saw your mail
> but I tried to be diplomatic and not shot it down immeadiately. Shows
> that diplomacy is not really my thing...
>
> We always take extra measures to avoid forking code, why is it now all
> of sudden ok? Also this gives the wrong message to Realtek, and other
> vendors, that they can just fork the driver and push all sort of crap to
> staging.
>
> So just to make clear to everyone: I think forking drivers like this is
> a HORRIBLE idea and I do not want to have anything to do with that. If
> schedule goes over quality then a much better approach is to move to the
> whole driver to staging than to have duplicated drivers like we have
> now.
I think it's horrid too. But, if no one is able to do the real work
here, we hurt users who just need to use their hardware to get things
done.
And it seems like the company isn't willing to do the real work, so
dumping this in staging is the best we can do at the moment.
However, if this causes you problems, that's not good at all either.
Getting "real" support for this hardware is key, and hopefully can
happen somehow. But fixing up the staging driver is almost never the
way to do it, as you know :)
So what to do? Any ideas? What makes your life easier? You can just
ignore the staging tree, as it should not affect your portion of the
kernel at all, right?
thanks,
greg k-h
^ permalink raw reply
* RE: [PATCH] rtl8xxxu: mark expected switch fall-throughs
From: David Laight @ 2017-10-11 12:54 UTC (permalink / raw)
To: 'Joe Perches', Gustavo A. R. Silva, Jes Sorensen,
Kalle Valo
Cc: linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, Arnaldo Carvalho de Melo
In-Reply-To: <1507717237.3552.48.camel@perches.com>
From: Joe Perches
> Sent: 11 October 2017 11:21
> On Tue, 2017-10-10 at 14:30 -0500, Gustavo A. R. Silva wrote:
> > In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> > where we are expecting to fall through.
>
> perhaps use Arnaldo's idea:
>
> https://lkml.org/lkml/2017/2/9/845
> https://lkml.org/lkml/2017/2/10/485
gah, that is even uglier and requires a chase through
headers to find out what it means.
David
^ permalink raw reply
* pull-request: mac80211-next 2017-10-11
From: Johannes Berg @ 2017-10-11 12:36 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-wireless
Hi Dave,
Here's a -next pull request. The only bigger thing here is the
addition of the regulatory database as firmware, which will
allow us to - over time - get rid of CRDA, as well as having
the option of adding more fields to the database where needed,
this would've been extremely complex with CRDA because it had
not been built with extensibility in mind.
Please pull and let me know if there's any problem.
Thanks,
johannes
The following changes since commit cc71b7b071192ac1c288e272fdc3f3877eb96663:
net/ipv6: remove unused err variable on icmpv6_push_pending_frames (2017-10-05 21:56:26 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next.git tags/mac80211-next-for-davem-2017-10-11
for you to fetch changes up to 90a53e4432b12288316efaa5f308adafb8d304b0:
cfg80211: implement regdb signature checking (2017-10-11 14:24:24 +0200)
----------------------------------------------------------------
Work continues in various areas:
* port authorized event for 4-way-HS offload (Avi)
* enable MFP optional for such devices (Emmanuel)
* Kees's timer setup patch for mac80211 mesh
(the part that isn't trivially scripted)
* improve VLAN vs. TXQ handling (myself)
* load regulatory database as firmware file (myself)
* with various other small improvements and cleanups
I merged net-next once in the meantime to allow Kees's
timer setup patch to go in.
----------------------------------------------------------------
Avraham Stern (2):
ieee80211: Add WFA TPC report element OUI type
cfg80211/nl80211: add a port authorized event
Emmanuel Grumbach (1):
nl80211: add an option to allow MFP without requiring it
Gregory Greenman (1):
mac80211: recalculate some sta parameters after insertion
Ilan peer (1):
mac80211: Simplify locking in ieee80211_sta_tear_down_BA_sessions()
Johannes Berg (12):
mac80211: avoid allocating TXQs that won't be used
mac80211: simplify and clarify IE splitting
mac80211: use offsetofend()
cfg80211: remove unused function ieee80211_data_from_8023()
Merge remote-tracking branch 'net-next/master' into mac80211-next
MAINTAINERS: update Johannes Berg's entries
fq: support filtering a given tin
mac80211: only remove AP VLAN frames from TXQ
cfg80211: support loading regulatory database as firmware file
cfg80211: support reloading regulatory database
cfg80211: reg: remove support for built-in regdb
cfg80211: implement regdb signature checking
Kees Cook (1):
net/mac80211/mesh_plink: Convert timers to use timer_setup()
Liad Kaufman (1):
mac80211: extend ieee80211_ie_split to support EXTENSION
Lubomir Rintel (1):
mac80211_hwsim: use dyndbg for debug messages
Luca Coelho (1):
mac80211: add documentation to ieee80211_rx_ba_offl()
Manikanta Pubbisetty (1):
mac80211: fix bandwidth computation for TDLS peers
Richard Schütz (1):
wireless: set correct mandatory rate flags
Roee Zamir (2):
nl80211: add OCE scan and capability flags
mac80211: oce: enable receiving of bcast probe resp
Stanislaw Gruszka (1):
mac80211: fix STA_SLOW_THRESHOLD htmldocs failure
Tova Mussai (1):
nl80211: return error for invalid center_freq in 40 MHz
Xiang Gao (1):
mac80211: aead api to reduce redundancy
Documentation/driver-api/80211/cfg80211.rst | 3 -
Documentation/networking/regulatory.txt | 30 +-
MAINTAINERS | 13 +-
drivers/net/wireless/mac80211_hwsim.c | 192 ++++++------
include/linux/ieee80211.h | 1 +
include/net/cfg80211.h | 40 +--
include/net/fq.h | 7 +
include/net/fq_impl.h | 72 ++++-
include/net/mac80211.h | 8 +-
include/uapi/linux/nl80211.h | 82 +++--
net/mac80211/Makefile | 3 +-
net/mac80211/{aes_ccm.c => aead_api.c} | 40 +--
net/mac80211/aead_api.h | 27 ++
net/mac80211/aes_ccm.h | 42 ++-
net/mac80211/aes_gcm.c | 109 -------
net/mac80211/aes_gcm.h | 38 ++-
net/mac80211/agg-rx.c | 4 +-
net/mac80211/ht.c | 12 +-
net/mac80211/ieee80211_i.h | 2 +
net/mac80211/iface.c | 29 +-
net/mac80211/mesh.c | 3 +-
net/mac80211/mesh.h | 1 +
net/mac80211/mesh_hwmp.c | 8 +-
net/mac80211/mesh_plink.c | 13 +-
net/mac80211/mlme.c | 19 +-
net/mac80211/scan.c | 37 ++-
net/mac80211/sta_info.c | 61 ++--
net/mac80211/sta_info.h | 4 +-
net/mac80211/tx.c | 34 +++
net/mac80211/util.c | 25 +-
net/mac80211/vht.c | 10 +
net/mac80211/wpa.c | 4 +-
net/wireless/.gitignore | 3 +-
net/wireless/Kconfig | 58 ++--
net/wireless/Makefile | 24 +-
net/wireless/certs/sforshee.x509 | Bin 0 -> 680 bytes
net/wireless/core.c | 2 +-
net/wireless/core.h | 5 +
net/wireless/db.txt | 17 --
net/wireless/genregdb.awk | 158 ----------
net/wireless/nl80211.c | 199 ++++++++----
net/wireless/nl80211.h | 2 +
net/wireless/reg.c | 452 +++++++++++++++++++++++++---
net/wireless/reg.h | 14 +
net/wireless/regdb.h | 23 --
net/wireless/sme.c | 45 ++-
net/wireless/util.c | 202 ++++---------
47 files changed, 1278 insertions(+), 899 deletions(-)
rename net/mac80211/{aes_ccm.c => aead_api.c} (67%)
create mode 100644 net/mac80211/aead_api.h
delete mode 100644 net/mac80211/aes_gcm.c
create mode 100644 net/wireless/certs/sforshee.x509
delete mode 100644 net/wireless/db.txt
delete mode 100644 net/wireless/genregdb.awk
delete mode 100644 net/wireless/regdb.h
^ permalink raw reply
* Re: [PATCH V5 1/5] mac80211: Enable TDLS peer buffer STA feature
From: Johannes Berg @ 2017-10-11 11:07 UTC (permalink / raw)
To: yintang, ath10k; +Cc: linux-wireless
In-Reply-To: <1507623080-9311-2-git-send-email-yintang@qti.qualcomm.com>
> +++ b/include/net/cfg80211.h
> @@ -3249,6 +3249,8 @@ struct cfg80211_ops {
> * beaconing mode (AP, IBSS, Mesh, ...).
> * @WIPHY_FLAG_HAS_STATIC_WEP: The device supports static WEP key
> installation
> * before connection.
> + * @WIPHY_FLAG_SUPPORT_TDLS_BUFFER_ST: Device support buffer STA
> when TDLS is
> + * established.
There's a typo (missing A) here.
However, I don't see a reason for this to be a WIPHY flag rather than a
mac80211 hw flag (enum ieee80211_hw_flags) since you only use it in
mac80211.
In reality, adding WIPHY flags should be really rare - only if
*cfg80211* needs to know something, but *userspace* doesn't...
If cfg80211 doesn't care, add to mac80211. If userspace cares, add to
extended nl80211 flags instead :)
johannes
^ permalink raw reply
* [PATCH] [net-next]NFC: Convert timers to use timer_setup()
From: Allen Pais @ 2017-10-11 10:33 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, Allen Pais
Switch to using the new timer_setup() and from_timer()
for net/nfc/*
Signed-off-by: Allen Pais <allen.pais@oracle.com>
---
---
net/nfc/core.c | 8 +++-----
net/nfc/hci/core.c | 7 +++----
net/nfc/hci/llc_shdlc.c | 23 +++++++++--------------
net/nfc/llcp_core.c | 14 ++++++--------
4 files changed, 21 insertions(+), 31 deletions(-)
diff --git a/net/nfc/core.c b/net/nfc/core.c
index e5e23c2..56e5467 100644
--- a/net/nfc/core.c
+++ b/net/nfc/core.c
@@ -1015,9 +1015,9 @@ static void nfc_check_pres_work(struct work_struct *work)
device_unlock(&dev->dev);
}
-static void nfc_check_pres_timeout(unsigned long data)
+static void nfc_check_pres_timeout(struct timer_list *t)
{
- struct nfc_dev *dev = (struct nfc_dev *)data;
+ struct nfc_dev *dev = from_timer(dev, t, check_pres_timer);
schedule_work(&dev->check_pres_work);
}
@@ -1094,9 +1094,7 @@ struct nfc_dev *nfc_allocate_device(struct nfc_ops *ops,
dev->targets_generation = 1;
if (ops->check_presence) {
- setup_timer(&dev->check_pres_timer, nfc_check_pres_timeout,
- (unsigned long)dev);
-
+ timer_setup(&dev->check_pres_timer, nfc_check_pres_timeout, 0);
INIT_WORK(&dev->check_pres_work, nfc_check_pres_work);
}
diff --git a/net/nfc/hci/core.c b/net/nfc/hci/core.c
index a8a6e78..ac8030c4 100644
--- a/net/nfc/hci/core.c
+++ b/net/nfc/hci/core.c
@@ -428,9 +428,9 @@ void nfc_hci_event_received(struct nfc_hci_dev *hdev, u8 pipe, u8 event,
nfc_hci_driver_failure(hdev, r);
}
-static void nfc_hci_cmd_timeout(unsigned long data)
+static void nfc_hci_cmd_timeout(struct timer_list *t)
{
- struct nfc_hci_dev *hdev = (struct nfc_hci_dev *)data;
+ struct nfc_hci_dev *hdev = from_timer(hdev, t, cmd_timer);
schedule_work(&hdev->msg_tx_work);
}
@@ -1004,8 +1004,7 @@ int nfc_hci_register_device(struct nfc_hci_dev *hdev)
INIT_WORK(&hdev->msg_tx_work, nfc_hci_msg_tx_work);
- setup_timer(&hdev->cmd_timer, nfc_hci_cmd_timeout,
- (unsigned long)hdev);
+ timer_setup(&hdev->cmd_timer, nfc_hci_cmd_timeout, 0);
skb_queue_head_init(&hdev->rx_hcp_frags);
diff --git a/net/nfc/hci/llc_shdlc.c b/net/nfc/hci/llc_shdlc.c
index 58df37e..fe98893 100644
--- a/net/nfc/hci/llc_shdlc.c
+++ b/net/nfc/hci/llc_shdlc.c
@@ -580,27 +580,27 @@ static void llc_shdlc_handle_send_queue(struct llc_shdlc *shdlc)
}
}
-static void llc_shdlc_connect_timeout(unsigned long data)
+static void llc_shdlc_connect_timeout(struct timer_list *t)
{
- struct llc_shdlc *shdlc = (struct llc_shdlc *)data;
+ struct llc_shdlc *shdlc = from_timer(shdlc, t, connect_timer);
pr_debug("\n");
schedule_work(&shdlc->sm_work);
}
-static void llc_shdlc_t1_timeout(unsigned long data)
+static void llc_shdlc_t1_timeout(struct timer_list *t)
{
- struct llc_shdlc *shdlc = (struct llc_shdlc *)data;
+ struct llc_shdlc *shdlc = from_timer(shdlc, t, t1_timer);
pr_debug("SoftIRQ: need to send ack\n");
schedule_work(&shdlc->sm_work);
}
-static void llc_shdlc_t2_timeout(unsigned long data)
+static void llc_shdlc_t2_timeout(struct timer_list *t)
{
- struct llc_shdlc *shdlc = (struct llc_shdlc *)data;
+ struct llc_shdlc *shdlc = from_timer(shdlc, t, t2_timer);
pr_debug("SoftIRQ: need to retransmit\n");
@@ -763,14 +763,9 @@ static void *llc_shdlc_init(struct nfc_hci_dev *hdev, xmit_to_drv_t xmit_to_drv,
mutex_init(&shdlc->state_mutex);
shdlc->state = SHDLC_DISCONNECTED;
- setup_timer(&shdlc->connect_timer, llc_shdlc_connect_timeout,
- (unsigned long)shdlc);
-
- setup_timer(&shdlc->t1_timer, llc_shdlc_t1_timeout,
- (unsigned long)shdlc);
-
- setup_timer(&shdlc->t2_timer, llc_shdlc_t2_timeout,
- (unsigned long)shdlc);
+ timer_setup(&shdlc->connect_timer, llc_shdlc_connect_timeout, 0);
+ timer_setup(&shdlc->t1_timer, llc_shdlc_t1_timeout, 0);
+ timer_setup(&shdlc->t2_timer, llc_shdlc_t2_timeout, 0);
shdlc->w = SHDLC_MAX_WINDOW;
shdlc->srej_support = SHDLC_SREJ_SUPPORT;
diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
index 7988185..ef4026a 100644
--- a/net/nfc/llcp_core.c
+++ b/net/nfc/llcp_core.c
@@ -242,9 +242,9 @@ static void nfc_llcp_timeout_work(struct work_struct *work)
nfc_dep_link_down(local->dev);
}
-static void nfc_llcp_symm_timer(unsigned long data)
+static void nfc_llcp_symm_timer(struct timer_list *t)
{
- struct nfc_llcp_local *local = (struct nfc_llcp_local *) data;
+ struct nfc_llcp_local *local = from_timer(local, t, link_timer);
pr_err("SYMM timeout\n");
@@ -285,9 +285,9 @@ static void nfc_llcp_sdreq_timeout_work(struct work_struct *work)
nfc_genl_llc_send_sdres(local->dev, &nl_sdres_list);
}
-static void nfc_llcp_sdreq_timer(unsigned long data)
+static void nfc_llcp_sdreq_timer(struct timer_list *t)
{
- struct nfc_llcp_local *local = (struct nfc_llcp_local *) data;
+ struct nfc_llcp_local *local = from_timer(local, t, sdreq_timer);
schedule_work(&local->sdreq_timeout_work);
}
@@ -1573,8 +1573,7 @@ int nfc_llcp_register_device(struct nfc_dev *ndev)
INIT_LIST_HEAD(&local->list);
kref_init(&local->ref);
mutex_init(&local->sdp_lock);
- setup_timer(&local->link_timer, nfc_llcp_symm_timer,
- (unsigned long)local);
+ timer_setup(&local->link_timer, nfc_llcp_symm_timer, 0);
skb_queue_head_init(&local->tx_queue);
INIT_WORK(&local->tx_work, nfc_llcp_tx_work);
@@ -1600,8 +1599,7 @@ int nfc_llcp_register_device(struct nfc_dev *ndev)
mutex_init(&local->sdreq_lock);
INIT_HLIST_HEAD(&local->pending_sdreqs);
- setup_timer(&local->sdreq_timer, nfc_llcp_sdreq_timer,
- (unsigned long)local);
+ timer_setup(&local->sdreq_timer, nfc_llcp_sdreq_timer, 0);
INIT_WORK(&local->sdreq_timeout_work, nfc_llcp_sdreq_timeout_work);
list_add(&local->list, &llcp_devices);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs
From: Joe Perches @ 2017-10-11 10:20 UTC (permalink / raw)
To: Gustavo A. R. Silva, Jes Sorensen, Kalle Valo
Cc: linux-wireless, netdev, linux-kernel, Arnaldo Carvalho de Melo
In-Reply-To: <20171010193027.GA23108@embeddedor.com>
On Tue, 2017-10-10 at 14:30 -0500, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
perhaps use Arnaldo's idea:
https://lkml.org/lkml/2017/2/9/845
https://lkml.org/lkml/2017/2/10/485
^ permalink raw reply
* Re: [PATCH 12/13] kthread: Convert callback to use from_timer()
From: Petr Mladek @ 2017-10-11 10:20 UTC (permalink / raw)
To: Kees Cook
Cc: Thomas Gleixner, Andrew Morton, Tejun Heo, Oleg Nesterov,
Arnd Bergmann, Benjamin Herrenschmidt, Chris Metcalf,
Geert Uytterhoeven, Greg Kroah-Hartman, Guenter Roeck,
Harish Patil, Heiko Carstens, James E.J. Bottomley, John Stultz,
Julian Wiedmann, Kalle Valo, Lai Jiangshan, Len Brown,
Manish Chopra, Mark Gross, Martin K. Petersen, Martin Schwidefsky,
Michael Ellerman, Michael Reed, netdev, Paul Mackerras,
Pavel Machek, Rafael J. Wysocki, Ralf Baechle, Sebastian Reichel,
Stefan Richter, Stephen Boyd, Sudip Mukherjee, Ursula Braun,
Viresh Kumar, Wim Van Sebroeck, linux1394-devel, linux-mips,
linux-pm, linuxppc-dev, linux-s390, linux-scsi, linux-watchdog,
linux-wireless, linux-kernel
In-Reply-To: <1507159627-127660-13-git-send-email-keescook@chromium.org>
On Wed 2017-10-04 16:27:06, Kees Cook wrote:
> In preparation for unconditionally passing the struct timer_list pointer
> to all timer callbacks, switch kthread to use from_timer() and pass the
> timer pointer explicitly.
>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Petr Mladek <pmladek@suse.com>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Oleg Nesterov <oleg@redhat.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Best Regards,
Petr
^ permalink raw reply
* [PATCH v2] ath9k: add MSI support
From: Russell Hu @ 2017-10-11 10:18 UTC (permalink / raw)
To: linux-wireless; +Cc: rhu, ryanhsu, rwchang, aeolus, kvalo
On new Intel platforms like ApolloLake, legacy interrupt mechanism
(INTx) is not supported, so WLAN modules are not working because
interrupts are missing, therefore this patch is to add MSI support to
ath9k. With module paremeter "use_msi=1", ath9k driver would try to
use MSI instead of INTx.
Signed-off-by: Russell Hu <rhu@qti.qualcomm.com>
---
drivers/net/wireless/ath/ath9k/hw.c | 33 ++++++++++++++++++------
drivers/net/wireless/ath/ath9k/hw.h | 3 +++
drivers/net/wireless/ath/ath9k/init.c | 4 +++
drivers/net/wireless/ath/ath9k/mac.c | 47 +++++++++++++++++++++++++++++++++++
drivers/net/wireless/ath/ath9k/pci.c | 21 +++++++++++++++-
drivers/net/wireless/ath/ath9k/reg.h | 15 +++++++++++
6 files changed, 115 insertions(+), 8 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/hw.c b/drivers/net/wireless/ath/ath9k/hw.c
index 8c5c2dd8fa7f..cd0f023ccf77 100644
--- a/drivers/net/wireless/ath/ath9k/hw.c
+++ b/drivers/net/wireless/ath/ath9k/hw.c
@@ -922,6 +922,7 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw *ah,
AR_IMR_RXERR |
AR_IMR_RXORN |
AR_IMR_BCNMISC;
+ u32 msi_cfg = 0;
if (AR_SREV_9340(ah) || AR_SREV_9550(ah) || AR_SREV_9531(ah) ||
AR_SREV_9561(ah))
@@ -929,22 +930,30 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw *ah,
if (AR_SREV_9300_20_OR_LATER(ah)) {
imr_reg |= AR_IMR_RXOK_HP;
- if (ah->config.rx_intr_mitigation)
+ if (ah->config.rx_intr_mitigation) {
imr_reg |= AR_IMR_RXINTM | AR_IMR_RXMINTR;
- else
+ msi_cfg |= AR_INTCFG_MSI_RXINTM | AR_INTCFG_MSI_RXMINTR;
+ } else {
imr_reg |= AR_IMR_RXOK_LP;
-
+ msi_cfg |= AR_INTCFG_MSI_RXOK;
+ }
} else {
- if (ah->config.rx_intr_mitigation)
+ if (ah->config.rx_intr_mitigation) {
imr_reg |= AR_IMR_RXINTM | AR_IMR_RXMINTR;
- else
+ msi_cfg |= AR_INTCFG_MSI_RXINTM | AR_INTCFG_MSI_RXMINTR;
+ } else {
imr_reg |= AR_IMR_RXOK;
+ msi_cfg |= AR_INTCFG_MSI_RXOK;
+ }
}
- if (ah->config.tx_intr_mitigation)
+ if (ah->config.tx_intr_mitigation) {
imr_reg |= AR_IMR_TXINTM | AR_IMR_TXMINTR;
- else
+ msi_cfg |= AR_INTCFG_MSI_TXINTM | AR_INTCFG_MSI_TXMINTR;
+ } else {
imr_reg |= AR_IMR_TXOK;
+ msi_cfg |= AR_INTCFG_MSI_TXOK;
+ }
ENABLE_REGWRITE_BUFFER(ah);
@@ -952,6 +961,16 @@ static void ath9k_hw_init_interrupt_masks(struct ath_hw *ah,
ah->imrs2_reg |= AR_IMR_S2_GTT;
REG_WRITE(ah, AR_IMR_S2, ah->imrs2_reg);
+ if (ah->msi_enabled) {
+ ah->msi_reg = REG_READ(ah, AR_PCIE_MSI);
+ ah->msi_reg |= AR_PCIE_MSI_HW_DBI_WR_EN;
+ ah->msi_reg &= AR_PCIE_MSI_HW_INT_PENDING_ADDR_MSI_64;
+ REG_WRITE(ah, AR_INTCFG, msi_cfg);
+ ath_dbg(ath9k_hw_common(ah), ANY,
+ "value of AR_INTCFG=0x%X, msi_cfg=0x%X\n",
+ REG_READ(ah, AR_INTCFG), msi_cfg);
+ }
+
if (!AR_SREV_9100(ah)) {
REG_WRITE(ah, AR_INTR_SYNC_CAUSE, 0xFFFFFFFF);
REG_WRITE(ah, AR_INTR_SYNC_ENABLE, sync_default);
diff --git a/drivers/net/wireless/ath/ath9k/hw.h b/drivers/net/wireless/ath/ath9k/hw.h
index 4ac70827d142..0d6c07c77372 100644
--- a/drivers/net/wireless/ath/ath9k/hw.h
+++ b/drivers/net/wireless/ath/ath9k/hw.h
@@ -977,6 +977,9 @@ struct ath_hw {
bool tpc_enabled;
u8 tx_power[Ar5416RateSize];
u8 tx_power_stbc[Ar5416RateSize];
+ bool msi_enabled;
+ u32 msi_mask;
+ u32 msi_reg;
};
struct ath_bus_ops {
diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c
index bb7936090b91..b6b7a353fea4 100644
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -75,6 +75,10 @@ MODULE_PARM_DESC(use_chanctx, "Enable channel context for concurrency");
#endif /* CONFIG_ATH9K_CHANNEL_CONTEXT */
+int ath9k_use_msi;
+module_param_named(use_msi, ath9k_use_msi, int, 0444);
+MODULE_PARM_DESC(use_msi, "Use MSI instead of INTx if possible");
+
bool is_ath9k_unloaded;
#ifdef CONFIG_MAC80211_LEDS
diff --git a/drivers/net/wireless/ath/ath9k/mac.c b/drivers/net/wireless/ath/ath9k/mac.c
index 77c94f9e7b61..58d02c19b6d0 100644
--- a/drivers/net/wireless/ath/ath9k/mac.c
+++ b/drivers/net/wireless/ath/ath9k/mac.c
@@ -832,6 +832,43 @@ static void __ath9k_hw_enable_interrupts(struct ath_hw *ah)
}
ath_dbg(common, INTERRUPT, "AR_IMR 0x%x IER 0x%x\n",
REG_READ(ah, AR_IMR), REG_READ(ah, AR_IER));
+
+ if (ah->msi_enabled) {
+ u32 _msi_reg = 0;
+ u32 i = 0;
+ u32 msi_pend_addr_mask = AR_PCIE_MSI_HW_INT_PENDING_ADDR_MSI_64;
+
+ ath_dbg(ath9k_hw_common(ah), INTERRUPT,
+ "Enabling MSI, msi_mask=0x%X\n", ah->msi_mask);
+
+ REG_WRITE(ah, AR_INTR_PRIO_ASYNC_ENABLE, ah->msi_mask);
+ REG_WRITE(ah, AR_INTR_PRIO_ASYNC_MASK, ah->msi_mask);
+ ath_dbg(ath9k_hw_common(ah), INTERRUPT,
+ "AR_INTR_PRIO_ASYNC_ENABLE=0x%X, AR_INTR_PRIO_ASYNC_MASK=0x%X\n",
+ REG_READ(ah, AR_INTR_PRIO_ASYNC_ENABLE),
+ REG_READ(ah, AR_INTR_PRIO_ASYNC_MASK));
+
+ if (ah->msi_reg == 0)
+ ah->msi_reg = REG_READ(ah, AR_PCIE_MSI);
+
+ ath_dbg(ath9k_hw_common(ah), INTERRUPT,
+ "AR_PCIE_MSI=0x%X, ah->msi_reg = 0x%X\n",
+ AR_PCIE_MSI, ah->msi_reg);
+
+ i = 0;
+ do {
+ REG_WRITE(ah, AR_PCIE_MSI,
+ (ah->msi_reg | AR_PCIE_MSI_ENABLE)
+ & msi_pend_addr_mask);
+ _msi_reg = REG_READ(ah, AR_PCIE_MSI);
+ i++;
+ } while ((_msi_reg & AR_PCIE_MSI_ENABLE) == 0 && i < 200);
+
+ if (i >= 200)
+ ath_err(ath9k_hw_common(ah),
+ "%s: _msi_reg = 0x%X\n",
+ __func__, _msi_reg);
+ }
}
void ath9k_hw_resume_interrupts(struct ath_hw *ah)
@@ -878,12 +915,21 @@ void ath9k_hw_set_interrupts(struct ath_hw *ah)
if (!(ints & ATH9K_INT_GLOBAL))
ath9k_hw_disable_interrupts(ah);
+ if (ah->msi_enabled) {
+ ath_dbg(common, INTERRUPT, "Clearing AR_INTR_PRIO_ASYNC_ENABLE\n");
+
+ REG_WRITE(ah, AR_INTR_PRIO_ASYNC_ENABLE, 0);
+ REG_READ(ah, AR_INTR_PRIO_ASYNC_ENABLE);
+ }
+
ath_dbg(common, INTERRUPT, "New interrupt mask 0x%x\n", ints);
mask = ints & ATH9K_INT_COMMON;
mask2 = 0;
+ ah->msi_mask = 0;
if (ints & ATH9K_INT_TX) {
+ ah->msi_mask |= AR_INTR_PRIO_TX;
if (ah->config.tx_intr_mitigation)
mask |= AR_IMR_TXMINTR | AR_IMR_TXINTM;
else {
@@ -898,6 +944,7 @@ void ath9k_hw_set_interrupts(struct ath_hw *ah)
mask |= AR_IMR_TXEOL;
}
if (ints & ATH9K_INT_RX) {
+ ah->msi_mask |= AR_INTR_PRIO_RXLP | AR_INTR_PRIO_RXHP;
if (AR_SREV_9300_20_OR_LATER(ah)) {
mask |= AR_IMR_RXERR | AR_IMR_RXOK_HP;
if (ah->config.rx_intr_mitigation) {
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 223606311261..645f0fbd9179 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -22,6 +22,8 @@
#include <linux/module.h>
#include "ath9k.h"
+extern int ath9k_use_msi;
+
static const struct pci_device_id ath_pci_id_table[] = {
{ PCI_VDEVICE(ATHEROS, 0x0023) }, /* PCI */
{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
@@ -889,6 +891,7 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
u32 val;
int ret = 0;
char hw_name[64];
+ int msi_enabled = 0;
if (pcim_enable_device(pdev))
return -EIO;
@@ -960,7 +963,20 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
sc->mem = pcim_iomap_table(pdev)[0];
sc->driver_data = id->driver_data;
- ret = request_irq(pdev->irq, ath_isr, IRQF_SHARED, "ath9k", sc);
+ if (ath9k_use_msi) {
+ if (pci_enable_msi(pdev) == 0) {
+ msi_enabled = 1;
+ dev_err(&pdev->dev, "Using MSI\n");
+ } else {
+ dev_err(&pdev->dev, "Using INTx\n");
+ }
+ }
+
+ if (!msi_enabled)
+ ret = request_irq(pdev->irq, ath_isr, IRQF_SHARED, "ath9k", sc);
+ else
+ ret = request_irq(pdev->irq, ath_isr, 0, "ath9k", sc);
+
if (ret) {
dev_err(&pdev->dev, "request_irq failed\n");
goto err_irq;
@@ -974,6 +990,9 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
goto err_init;
}
+ sc->sc_ah->msi_enabled = msi_enabled;
+ sc->sc_ah->msi_reg = 0;
+
ath9k_hw_name(sc->sc_ah, hw_name, sizeof(hw_name));
wiphy_info(hw->wiphy, "%s mem=0x%lx, irq=%d\n",
hw_name, (unsigned long)sc->mem, pdev->irq);
diff --git a/drivers/net/wireless/ath/ath9k/reg.h b/drivers/net/wireless/ath/ath9k/reg.h
index 80ff69f99229..653e79611830 100644
--- a/drivers/net/wireless/ath/ath9k/reg.h
+++ b/drivers/net/wireless/ath/ath9k/reg.h
@@ -146,6 +146,14 @@
#define AR_MACMISC_MISC_OBS_BUS_MSB_S 15
#define AR_MACMISC_MISC_OBS_BUS_1 1
+#define AR_INTCFG 0x005C
+#define AR_INTCFG_MSI_RXOK 0x00000000
+#define AR_INTCFG_MSI_RXINTM 0x00000004
+#define AR_INTCFG_MSI_RXMINTR 0x00000006
+#define AR_INTCFG_MSI_TXOK 0x00000000
+#define AR_INTCFG_MSI_TXINTM 0x00000010
+#define AR_INTCFG_MSI_TXMINTR 0x00000018
+
#define AR_DATABUF_SIZE 0x0060
#define AR_DATABUF_SIZE_MASK 0x00000FFF
@@ -1256,6 +1264,13 @@ enum {
#define AR_PCIE_MSI (AR_SREV_9340(ah) ? 0x40d8 : \
(AR_SREV_9300_20_OR_LATER(ah) ? 0x40a4 : 0x4094))
#define AR_PCIE_MSI_ENABLE 0x00000001
+#define AR_PCIE_MSI_HW_DBI_WR_EN 0x02000000
+#define AR_PCIE_MSI_HW_INT_PENDING_ADDR 0xFFA0C1FF /* bits 8..11: value must be 0x5060 */
+#define AR_PCIE_MSI_HW_INT_PENDING_ADDR_MSI_64 0xFFA0C9FF /* bits 8..11: value must be 0x5064 */
+
+#define AR_INTR_PRIO_TX 0x00000001
+#define AR_INTR_PRIO_RXLP 0x00000002
+#define AR_INTR_PRIO_RXHP 0x00000004
#define AR_INTR_PRIO_SYNC_ENABLE (AR_SREV_9340(ah) ? 0x4088 : 0x40c4)
#define AR_INTR_PRIO_ASYNC_MASK (AR_SREV_9340(ah) ? 0x408c : 0x40c8)
--
2.11.0
^ permalink raw reply related
* Re: [PATCH 11/13] timer: Remove expires argument from __TIMER_INITIALIZER()
From: Petr Mladek @ 2017-10-11 10:15 UTC (permalink / raw)
To: Kees Cook
Cc: Thomas Gleixner, Andrew Morton, Arnd Bergmann,
Benjamin Herrenschmidt, Chris Metcalf, Geert Uytterhoeven,
Greg Kroah-Hartman, Guenter Roeck, Harish Patil, Heiko Carstens,
James E.J. Bottomley, John Stultz, Julian Wiedmann, Kalle Valo,
Lai Jiangshan, Len Brown, Manish Chopra, Mark Gross,
Martin K. Petersen, Martin Schwidefsky, Michael Ellerman,
Michael Reed, netdev, Oleg Nesterov, Paul Mackerras, Pavel Machek,
Rafael J. Wysocki, Ralf Baechle, Sebastian Reichel,
Stefan Richter, Stephen Boyd, Sudip Mukherjee, Tejun Heo,
Ursula Braun, Viresh Kumar, Wim Van Sebroeck, linux1394-devel,
linux-mips, linux-pm, linuxppc-dev, linux-s390, linux-scsi,
linux-watchdog, linux-wireless, linux-kernel
In-Reply-To: <1507159627-127660-12-git-send-email-keescook@chromium.org>
On Wed 2017-10-04 16:27:05, Kees Cook wrote:
> The expires field is normally initialized during the first mod_timer()
> call. It was unused by all callers, so remove it from the macro.
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> include/linux/kthread.h | 2 +-
> include/linux/timer.h | 5 ++---
> include/linux/workqueue.h | 2 +-
> 3 files changed, 4 insertions(+), 5 deletions(-)
I was primary interested into the change in kthread.h. But the entire
patch is simple and looks fine:
Reviewed-by: Petr Mladek <pmladek@suse.cz>
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH 2/3] rsi: sdio: Add WOWLAN support for S4 hibernate state
From: Kalle Valo @ 2017-10-11 9:24 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi,
Karun Eagalapati
In-Reply-To: <CAEhWJF=NusRJmdhQ7W9OPVjGG=XYAWU-+gnu_mYck2BsAOK+pg@mail.gmail.com>
Amitkumar Karwar <amitkarwar@gmail.com> writes:
> On Tue, Sep 26, 2017 at 3:27 PM, Kalle Valo <kvalo@codeaurora.org> wrote:
>> Amitkumar Karwar <amitkarwar@gmail.com> writes:
>>
>>> From: Karun Eagalapati <karun256@gmail.com>
>>>
>>> We are disabling of interrupts from firmware in freeze handler.
>>> Also setting power management capability KEEP_MMC_POWER to make
>>> device wakeup for WoWLAN trigger.
>>> At restore, we observed a device reset on some platforms. Hence
>>> reloading of firmware and device initialization is performed.
>>
>> With "reloading of firmware and device initialization" you mean calling
>> rsi_mac80211_detach()?
>
> After rsi_mac80211_detach, we have a call for rsi_hal_device_init() in
> which reloading of firmware happens.
>
>>
>> void rsi_mac80211_detach(struct rsi_hw *adapter)
>> {
>> struct ieee80211_hw *hw = adapter->hw;
>> enum nl80211_band band;
>>
>> if (hw) {
>> ieee80211_stop_queues(hw);
>> ieee80211_unregister_hw(hw);
>> ieee80211_free_hw(hw);
>> }
>>
>> That looks like a quite heavy sledgehammer workaround to a resume
>> problem. Is it really the best way to handle this?
>
> I agree with you. I will appreciate if someone propose a better
> solution. Following are details about the problem.
>
> Connection remain alive after suspend(S4 state). System is resumed
> from S4 through GPIO pin after receiving magic packet. But SDIO
> doesn't work after this. We need to do perform SDIO reset and
> redownload the firmware. Mac80211 is under impression that connection
> is alive. We keep on getting mac80211 handler calls and data while
> firmware re-download is in progress. This leads to different race
> issues and occasionally kernel crashes. detaching from mac80211 solves
> the problem here.
So what I think is the right approach is that the firmare is restarted
behind the scenes and user space doesn't even notice it, for example
that's what ath10k does. There's ieee80211_restart_hw() even for just
that.
We discussed about this also on one of mwifiex patches from Brian Norris
and there it was concluded that for cfg80211 driver it's ok to delete
the whole interface when restarting the firmware. But mac80211 drivers
can do better.
>> And even if that would be the right approach it needs to be properly
>> described in the commit log, a vague sentence in the end of a commit log
>> is not enough.
>
> Understood. I will add detailed description and send updated version
> if the patch is fine.
Not sure if this is fine or not. I think what you do here is ugly but I
guess it's better than nothing?
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 4/8] rsi: handle peer connection and disconnection in p2p mode
From: Kalle Valo @ 2017-10-11 9:13 UTC (permalink / raw)
To: Amitkumar Karwar
Cc: linux-wireless, Amitkumar Karwar, Prameela Rani Garnepudi
In-Reply-To: <1504085908-2163-5-git-send-email-amitkarwar@gmail.com>
Amitkumar Karwar <amitkarwar@gmail.com> writes:
> From: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
>
> Parameter 'vif' is passed to inform_bss_status function to
> check the type of vif and to get vap_id.
>
> Signed-off-by: Prameela Rani Garnepudi <prameela.j04cs@gmail.com>
> Signed-off-by: Amitkumar Karwar <amit.karwar@redpinesignals.com>
Kbuild bot reported that this added a new warning, I suspect this is from sparse:
>> drivers/net//wireless/rsi/rsi_91x_hal.c:136:3: note: in expansion of
>> macro 'cpu_to_le16'
cpu_to_le16((tx_params->vap_id << RSI_DESC_VAP_ID_OFST) &
Please fix.
--
Kalle Valo
^ permalink raw reply
* Re: Two rtlwifi drivers?
From: Kalle Valo @ 2017-10-11 9:06 UTC (permalink / raw)
To: Larry Finger
Cc: Dan Carpenter, Greg Kroah-Hartman, Ping-Ke Shih, Yan-Hsuan Chuang,
Johannes Berg, Souptick Joarder, devel, linux-wireless,
kernel-janitors
In-Reply-To: <652d42ad-a077-530b-743f-d38ddf3ff677@lwfinger.net>
(Sorry for taking so long with the reply, I wanted first to check what
the rtlwifi in staging contains.)
Larry Finger <Larry.Finger@lwfinger.net> writes:
> On 08/24/2017 07:14 AM, Kalle Valo wrote:
>> Dan Carpenter <dan.carpenter@oracle.com> writes:
>>
>>> Smatch is distrustful of the "capab" value and marks it as user
>>> controlled. I think it actually comes from the firmware? Anyway, I
>>> looked at other drivers and they added a bounds check and it seems like
>>> a harmless thing to have so I have added it here as well.
>>>
>>> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>>>
>>> diff --git a/drivers/staging/rtlwifi/base.c b/drivers/staging/rtlwifi/base.c
>>> index f7f207cbaee3..a30b928d5ee1 100644
>>> --- a/drivers/staging/rtlwifi/base.c
>>> +++ b/drivers/staging/rtlwifi/base.c
>>
>> I'm getting slightly annoyed that we now apparently have two duplicate
>> rtlwifi drivers (with the same name!) and I'm being spammed by staging
>> patches. Was this really a smart thing to do? And what will be the
>> future of these two drivers?
>>
>> (Of course this is not directed to Dan, he is just fixing bugs found by
>> smatch, but more like a general question.)
>
> That was the decision that you and Greg made. The version in
> wireless-drivers needs many patches to handle the new device. The
> progress in applying these to wireless-drivers was very slow for many
> reasons. Keeping a single version of that code would have required
> coordination between you and Greg, which was discouraged.
I don't recall deciding anything, all I did was asking for more info
about the new code. I was against the idea since I first saw your mail
but I tried to be diplomatic and not shot it down immeadiately. Shows
that diplomacy is not really my thing...
We always take extra measures to avoid forking code, why is it now all
of sudden ok? Also this gives the wrong message to Realtek, and other
vendors, that they can just fork the driver and push all sort of crap to
staging.
So just to make clear to everyone: I think forking drivers like this is
a HORRIBLE idea and I do not want to have anything to do with that. If
schedule goes over quality then a much better approach is to move to the
whole driver to staging than to have duplicated drivers like we have
now.
> The future, as stated in the TODO in staging, is to merge all the
> changes in the support drivers into wireless-drivers, and then move
> the new RTL8822BE driver out of staging.
And how many years will that take? (If that will ever happen) Also I see
that multiple patches are applied to staging version of rtlwifi which is
not in net version of rtlwifi. That all should be synced somehow, the
bigger the delta becomes the more difficult everything is.
> I'm sorry about the fallout affecting you, and I probably should have
> changed the directory names. In any case, ignore any patches that
> belong in staging. If I see any that do not include GregKH in the "To"
> list, I will NACK them and request proper routing.
Thanks, but that doesn't really help as I apply patches from patchwork
and it doesn't show the To field. I'll try to be extra careful and not
apply patches the staging version of rtlwifi patches, but mistakes
always happen.
--
Kalle Valo
^ permalink raw reply
* Re: [RFC] mac80211: Add airtime fairness accounting
From: Johannes Berg @ 2017-10-11 8:55 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
In-Reply-To: <87376sqda9.fsf@toke.dk>
On Mon, 2017-10-09 at 22:25 +0200, Toke Høiland-Jørgensen wrote:
> > Well, the case that we did find is that sometimes U-APSD kills
> > aggregation, so then you'd have a lot of single frames and
> > significantly under-estimate air-time usage in this case. Thus,
> > this
> > station would get far more than its fair share of air time, because
> > of
> > a bug that makes it not use aggregation... That doesn't sound very
> > good to me.
> >
> > Perhaps at least taking aggregation into account would be doable -
> > we _should_ know this, at least partially.
>
> Yeah, ath9k certainly gets that as part of the RX information from
> the chip.
Yeah, though there are more complex cases, e.g. with hardware A-MSDU
deaggregation like in ath10k.
> Well, some of the tests I did while porting ath9k to the iTXQs
> indicated that for voice-like traffic we can get very close to the
> same actual end-to-end latency for BE-marked traffic that we do with
> VO-marked traffic. This is in part because the FQ sparse flow
> prioritisation makes sure that such flows get queueing priority.
That really depends on medium saturation - if that's low, then yeah,
the difference is in the EDCA parameters and the minimum backoff, which
isn't a huge difference if you measure end-to-end.
Given saturation/congestion though, and I think we have to take this
into account since not everyone will be using this code, there are
measurable advantages to using VO - like in the test I mentioned where
you can block out BE "forever".
> Now obviously, there are going to be tradeoffs, and scenarios where
> latency will suffer. But I would at least like to be able to explore
> this, and I think with the API we are currently discussing that will
> be possible.
I'm not sure how you envision this working with the API, since you
still have to pull from multiple TXQs, but I have no objection to the
API as is - I'm just not convinced that actually demoting traffic is a
good idea :)
> Another thing I want to explore is doing soft admission
> control; i.e., if someone sends bulk traffic marked as VO, it will be
> automatically demoted to BE traffic rather than locking everyone else
> out. We've tested that with some success in the Cake scheduler, and
> it may be applicable to WiFi as well.
It seems pretty strange to do that at this level - we control what TID
(and AC) is selected for the traffic? So why not just change at that
level for this type of thing?
You can probably even already do that with TC by re-marking the traffic
depending on type or throughput or whatever else TC can classify on.
johannes
^ permalink raw reply
* Re: [RFC 1/3] mac80211: Add TXQ scheduling API
From: Johannes Berg @ 2017-10-11 8:46 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
In-Reply-To: <87k2027uxp.fsf@toke.dk>
On Tue, 2017-10-10 at 19:51 +0200, Toke Høiland-Jørgensen wrote:
> > > + struct list_head active_txqs;
> > > + spinlock_t active_txq_lock;
> >
> > Is there much point in having a separate lock? We probably need the
> > fq lock in most places related to this anyway?
>
> Well, once the scheduler gets a bit smarter it may be necessary to
> much with the order of TXQs on there without touching any of the
> queues (e.g., when calculating airtime usage on TX and RX
> completion). Not sure if that is enough to warrant a separate lock,
> though; I hadn't thought about just grabbing fq->lock...
Ok, dunno. It seemed sort of related but perhaps it's not really.
> > Also maybe you should only do that if the TXQ isn't *empty*, so the
> > driver could call this unconditionally?
>
> There can be cases where the driver wants the queue to be scheduled
> even though it looks empty from mac80211's point of view. For ath9k,
> the driver keeps its retry queue in the drv_priv part of the txq
> structure, so it will check if that is empty before deciding to call
> the schedule function.
>
> This is also related to the PS behaviour, so guess this could be
> changed once that is all TXQ-based...
Interesting. I guess scheduling an empty queue doesn't really matter
for mac80211 anyway though - just some extra work if we try to get
frames from it.
johannes
^ permalink raw reply
* Re: [RFC 1/3] mac80211: Add TXQ scheduling API
From: Johannes Berg @ 2017-10-11 8:44 UTC (permalink / raw)
To: Toke Høiland-Jørgensen, make-wifi-fast, linux-wireless
In-Reply-To: <87fuaq7ubo.fsf@toke.dk>
> Well I was trying to do The Right Thing(tm), obviously ;)
:-)
> The driver_buffered field comes from the previous behaviour of ath9k:
> It would basically set the station_buffered flag if there was
> something in the retry queue at the time it goes to sleep. And on
> wakeup, it will reschedule the txq if it has anything in the retry
> queue. And, well, it just seemed odd that there was this duplicated
> logic in the driver and mac80211, if the driver could just signal to
> mac80211 to reschedule for it...
Ok. I'm not sure what ath9k does, but mac80211 makes a distinction
between "do I have something buffered" and "does the driver have
something buffered".
When the station wakes up it's pretty easy, we tell the driver and it
just has to send its own frames first.
But when we get a PS-Poll/U-APSD it's more complicated, and we have to
tell the driver "please release N frames you have buffered" or we may
have to tell it "please allow me to send N frames that I have buffered"
which is why we need the distinction of whether or not the driver has
something buffered.
Ultimately, with TXQs, I hope this distinction can go away because the
driver wouldn't buffer all by itself.
> But I guess I was really just getting ahead of myself there; so the
> right thing to do for now is to keep the old behaviour, and then fix
> it properly afterwards?
I guess that'd be easier.
> Yes, this makes sense. Each sleep period is pretty short, right?
Not necessarily.
> I.e., we don't need to deal with interactions between CoDel and the
> queue being stopped for a long period of time?
I don't know enough about the possible interactions to answer that.
Sleep periods may be long, though typically if there's traffic for
stations then they want to retrieve that and will wake up relatively
soon, but "relatively soon" may still be on the order of hundreds of
milliseconds (or even seconds) because sometimes clients will only
listen to DTIM beacons (DTIM period * beacon interval), and e.g. with
WNM sleep mode it becomes even longer.
> > For the deliver-while-sleeping (PS-Poll/U-APSD) scenario, I think
> > the
> > driver should still pull frames, after calling something like
> > drv_release_buffered_frames(). We want this to be scheduled pretty
> > much
> > immediately, so we shouldn't just put the TXQ into the normal
> > rotation,
> > but otherwise it should work similarly - except limited to a
> > certain
> > number of frames [**].
> > In this case the driver probably needs to pull the frames using a
> > different function so that we can
> > a) tag the packets properly (more-data, EOSP)
> > b) generate nulldata as EOSP container where needed
> > Thus, it seems likely that we'll want a separate function, "pull
> > for PS
> > delivery" rather than the normal ieee80211_tx_dequeue().
>
> I was envisioning that next_txq() could also make those kinds of
> decisions (i.e., preempt the normal scheduling algorithm when a
> "special" TXQ needs to be scheduled immediately). But not sure if
> that is enough for this case?
Hmm, not sure. We really want this to be scheduled pretty much
immediately because the other side will be waiting for the frames, and
if we don't get an answer out quickly it'll have to assume we're
broken. I don't know what the limit here is for our firmware, but we
should really get this out as soon as possible in this case.
johannes
^ permalink raw reply
* Re: [PATCH] rtl8xxxu: mark expected switch fall-throughs
From: Kalle Valo @ 2017-10-11 8:41 UTC (permalink / raw)
To: Jes Sorensen; +Cc: Gustavo A. R. Silva, linux-wireless, netdev, linux-kernel
In-Reply-To: <5f5f0f54-d901-90be-9025-0a1c4b909368@gmail.com>
Jes Sorensen <jes.sorensen@gmail.com> writes:
> On 10/10/2017 03:30 PM, Gustavo A. R. Silva wrote:
>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>> where we are expecting to fall through.
>
> While this isn't harmful, to me this looks like pointless patch churn
> for zero gain and it's just ugly.
In general I find it useful to mark fall through cases. And it's just a
comment with two words, so they cannot hurt your eyes that much.
--
Kalle Valo
^ permalink raw reply
* Re: pull-request: iwlwifi-next 2017-10-06-2
From: Kalle Valo @ 2017-10-11 8:38 UTC (permalink / raw)
To: Luca Coelho; +Cc: linux-wireless, linuxwifi
In-Reply-To: <1507293175.908.134.camel@coelho.fi>
Luca Coelho <luca@coelho.fi> writes:
> Here's the second version of my first pull-request intended for
> v4.15. It contains the last two patch sets I sent out with v2 of the
> pci dump patch.
>
> In v2 we have fixed a potential kernel oops when our driver is used
> with qemu, for instance. In that case, the root port is NULL and we
> were trying to access it without checing.
>
> I have sent this out before and kbuildbot reported success.
>
> Please let me know if there are any issues.
>
> Cheers,
> Luca.
>
>
> The following changes since commit a7c9acc452b21b56c99dd7dfe0ab542f7baa6563:
>
> brcmfmac: Delete redundant length check (2017-10-02 17:07:00 +0300)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-next.git tags/iwlwifi-next-for-kalle-2017-10-06-2
>
> for you to fetch changes up to f2abcfa6c86e503b352846ace9d6ab9b02ade0ab:
>
> iwlwifi: remove dflt_pwr_limit from the transport (2017-10-06 15:22:34 +0300)
>
> ----------------------------------------------------------------
> First batch of iwlwifi patches for 4.15 (v2)
>
> * Cleanups: - remove an unused value that we read from the NVM;
> - remove link quality measurement code that was never used;
> * One FW command API update;
> * A fix and an addition for PCI devices for the A000 family;
> * Tiny refactor of ref/unref code used by runtime-PM;
> * Some debugging improvements;
> * Implementation of a more flexible way to define command queue sizes;
> * ACPI code refactoring;
> * Some coding-style fixes;
> * Avoid redundant command to the firmware;
> * Add a struct with the format of one FW command;
> * Change an error log to a warning when the FW API is not aligned with
> the driver (important during development);
> * Change a WARN_ON to WARN_ONCE to make it more descriptive and less
> noisy (i.e. no repeated warnings on a firmware triggered error);
> * Dump PCI registers when an error occurs, to make it easier to debug;
>
> ----------------------------------------------------------------
Pulled, thanks.
--
Kalle Valo
^ permalink raw reply
* [PATCH v4.9] nl80211: Define policy for packet pattern attributes
From: Johannes Berg @ 2017-10-11 8:32 UTC (permalink / raw)
To: linux-wireless, stable; +Cc: Peng Xu, Jouni Malinen
From: Peng Xu <pxu@qti.qualcomm.com>
Upstream commit ad670233c9e1d5feb365d870e30083ef1b889177.
Define a policy for packet pattern attributes in order to fix a
potential read over the end of the buffer during nla_get_u32()
of the NL80211_PKTPAT_OFFSET attribute.
Note that the data there can always be read due to SKB allocation
(with alignment and struct skb_shared_info at the end), but the
data might be uninitialized. This could be used to leak some data
from uninitialized vmalloc() memory, but most drivers don't allow
an offset (so you'd just get -EINVAL if the data is non-zero) or
just allow it with a fixed value - 100 or 128 bytes, so anything
above that would get -EINVAL. With brcmfmac the limit is 1500 so
(at least) one byte could be obtained.
Cc: stable@kernel.org
Signed-off-by: Peng Xu <pxu@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
[rewrite description based on SKB allocation knowledge]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index ece0fbc08607..c626f679e1c8 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -541,6 +541,14 @@ nl80211_nan_srf_policy[NL80211_NAN_SRF_ATTR_MAX + 1] = {
[NL80211_NAN_SRF_MAC_ADDRS] = { .type = NLA_NESTED },
};
+/* policy for packet pattern attributes */
+static const struct nla_policy
+nl80211_packet_pattern_policy[MAX_NL80211_PKTPAT + 1] = {
+ [NL80211_PKTPAT_MASK] = { .type = NLA_BINARY, },
+ [NL80211_PKTPAT_PATTERN] = { .type = NLA_BINARY, },
+ [NL80211_PKTPAT_OFFSET] = { .type = NLA_U32 },
+};
+
static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
struct netlink_callback *cb,
struct cfg80211_registered_device **rdev,
@@ -10009,7 +10017,7 @@ static int nl80211_set_wowlan(struct sk_buff *skb, struct genl_info *info)
u8 *mask_pat;
nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
- nla_len(pat), NULL);
+ nla_len(pat), nl80211_packet_pattern_policy);
err = -EINVAL;
if (!pat_tb[NL80211_PKTPAT_MASK] ||
!pat_tb[NL80211_PKTPAT_PATTERN])
@@ -10259,7 +10267,7 @@ static int nl80211_parse_coalesce_rule(struct cfg80211_registered_device *rdev,
u8 *mask_pat;
nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
- nla_len(pat), NULL);
+ nla_len(pat), nl80211_packet_pattern_policy);
if (!pat_tb[NL80211_PKTPAT_MASK] ||
!pat_tb[NL80211_PKTPAT_PATTERN])
return -EINVAL;
--
2.14.2
^ permalink raw reply related
* [PATCH v4.4] nl80211: Define policy for packet pattern attributes
From: Johannes Berg @ 2017-10-11 8:29 UTC (permalink / raw)
To: linux-wireless, stable; +Cc: Peng Xu, Jouni Malinen
From: Peng Xu <pxu@qti.qualcomm.com>
Upstream commit ad670233c9e1d5feb365d870e30083ef1b889177.
Define a policy for packet pattern attributes in order to fix a
potential read over the end of the buffer during nla_get_u32()
of the NL80211_PKTPAT_OFFSET attribute.
Note that the data there can always be read due to SKB allocation
(with alignment and struct skb_shared_info at the end), but the
data might be uninitialized. This could be used to leak some data
from uninitialized vmalloc() memory, but most drivers don't allow
an offset (so you'd just get -EINVAL if the data is non-zero) or
just allow it with a fixed value - 100 or 128 bytes, so anything
above that would get -EINVAL. With brcmfmac the limit is 1500 so
(at least) one byte could be obtained.
Cc: stable@kernel.org
Signed-off-by: Peng Xu <pxu@qti.qualcomm.com>
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
[rewrite description based on SKB allocation knowledge]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
---
net/wireless/nl80211.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 8ece212aa3d2..7950506395a8 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -485,6 +485,14 @@ nl80211_plan_policy[NL80211_SCHED_SCAN_PLAN_MAX + 1] = {
[NL80211_SCHED_SCAN_PLAN_ITERATIONS] = { .type = NLA_U32 },
};
+/* policy for packet pattern attributes */
+static const struct nla_policy
+nl80211_packet_pattern_policy[MAX_NL80211_PKTPAT + 1] = {
+ [NL80211_PKTPAT_MASK] = { .type = NLA_BINARY, },
+ [NL80211_PKTPAT_PATTERN] = { .type = NLA_BINARY, },
+ [NL80211_PKTPAT_OFFSET] = { .type = NLA_U32 },
+};
+
static int nl80211_prepare_wdev_dump(struct sk_buff *skb,
struct netlink_callback *cb,
struct cfg80211_registered_device **rdev,
@@ -9410,7 +9418,7 @@ static int nl80211_set_wowlan(struct sk_buff *skb, struct genl_info *info)
u8 *mask_pat;
nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
- nla_len(pat), NULL);
+ nla_len(pat), nl80211_packet_pattern_policy);
err = -EINVAL;
if (!pat_tb[NL80211_PKTPAT_MASK] ||
!pat_tb[NL80211_PKTPAT_PATTERN])
@@ -9660,7 +9668,7 @@ static int nl80211_parse_coalesce_rule(struct cfg80211_registered_device *rdev,
u8 *mask_pat;
nla_parse(pat_tb, MAX_NL80211_PKTPAT, nla_data(pat),
- nla_len(pat), NULL);
+ nla_len(pat), nl80211_packet_pattern_policy);
if (!pat_tb[NL80211_PKTPAT_MASK] ||
!pat_tb[NL80211_PKTPAT_PATTERN])
return -EINVAL;
--
2.14.2
^ permalink raw reply related
* Re: [PATCH] wcn36xx: Remove unnecessary rcu_read_unlock in wcn36xx_bss_info_changed
From: Kalle Valo @ 2017-10-11 8:28 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Jia-Ju Bai, k.eugene.e@gmail.com, wcn36xx@lists.infradead.org,
linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <20171011065445.GP1165@minitux>
Bjorn Andersson <bjorn.andersson@linaro.org> writes:
> On Sun 08 Oct 06:06 PDT 2017, Jia-Ju Bai wrote:
>
>> No rcu_read_lock is called, but rcu_read_unlock is still called.
>> Thus rcu_read_unlock should be removed.
>>=20
>
> Thanks, not sure how I could miss that one. Kalle can you please include
> this in a v4.14-rc pull request?
>
>
> :
>
> Fixes: 39efc7cc7ccf ("wcn36xx: Introduce mutual exclusion of fw configura=
tion")
>
>> Signed-off-by: Jia-Ju Bai <baijiaju1990@163.com>
>
> Acked-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Ok, I'll queue this to 4.14.
--=20
Kalle Valo=
^ permalink raw reply
* Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable"
From: Johannes Berg @ 2017-10-11 8:07 UTC (permalink / raw)
To: Ben Greear, linux-wireless@vger.kernel.org, ath10k, kirtika,
Johannes Berg
In-Reply-To: <1507708948.1998.15.camel@sipsolutions.net>
On Wed, 2017-10-11 at 10:02 +0200, Johannes Berg wrote:
> Overall, this isn't very well defined for AP mode...
No, that's not really correct. It *is* well defined (set the rate for
all clients to the same fixed rate), but that definition isn't very
good because if that rate isn't a basic rate, clients can connect that
don't support this rate...
johannes
^ permalink raw reply
* Re: iwlwifi: ToF usage
From: Luca Coelho @ 2017-10-11 8:05 UTC (permalink / raw)
To: Joel Bjurström, linux-wireless, assaf.krauss, johannes.berg,
emmanuel.grumbach
Cc: linuxwifi
In-Reply-To: <1507092741.908.56.camel@intel.com>
On Wed, 2017-10-04 at 07:52 +0300, Luciano Coelho wrote:
> Hi Joel,
>
> Unfortunately we don't have full support for ToF on the mainline
> kernel
> yet. But you can try to use one of our Core releases (which is a
> backports-based tree) that you can find here:
>
> You could try the release/Core30 branch, for example.
Johannes has also created a patch on top of the latest iw tool, adding
the commands for ToF. Please see my comment in this bugzilla entry if
you want to try that:
https://bugzilla.kernel.org/show_bug.cgi?id=197187#c1
Also, if you have any problems, please add it to bugzilla so we can
track this all in a single place.
--
Cheers,
Luca.
^ permalink raw reply
* Re: Setting single rate in ath10k broken by "reject/clear user rate mask if not usable"
From: Johannes Berg @ 2017-10-11 8:02 UTC (permalink / raw)
To: Ben Greear, linux-wireless@vger.kernel.org, ath10k, kirtika,
Johannes Berg
In-Reply-To: <13895fa0-3685-dd2b-583d-2d6469d23cfe@candelatech.com>
Hi,
> #iw dev vap206 set bitrates legacy-5 ht-mcs-5 0 vht-mcs-5
> command failed: Invalid argument (-22)
>
> But, it actually *does* successfully set the rate in the driver
> first, which is confusing at best.
Huh?
> So, I think we should relax this check, at least for ath10k.
Well, yes and no. I don't think we should make ath10k special here, and
this fixes a real problem - namely that you can set up the system so
that you have no usable rates at all, and then you just get a WARN_ON
and start using the lowest possible rate...
> commit e8e4f5280ddd0a7b43a795f90a0758e3c99df6a6
> Author: Johannes Berg <johannes.berg@intel.com>
> Date: Wed Mar 8 11:12:10 2017 +0100
>
> mac80211: reject/clear user rate mask if not usable
>
> If the user rate mask results in no (basic) rates being usable,
> clear it. Also, if we're already operating when it's set, reject
> it instead.
>
> Technically, selecting basic rates as the criterion is a bit too
> restrictive, but calculating the usable rates over all stations
> (e.g. in AP mode) is harder, and all stations must support the
> basic rates. Similarly, in client mode, the basic rates will be
> used anyway for control frames.
I guess you could implement this part? I.e. iterating the clients and
checking that they all support the rate that is set. However, then you
also need to implement that this gets reset when a new client that
doesn't support this rate connects.
Overall, this isn't very well defined for AP mode...
Perhaps it'd be better - as you pointed out in the other thread - to
have API to force a rate per station? We already have that for iwlwifi
in debugfs, so perhaps that'd be something to consider for this too,
I'm not sure there would be a real need to have it in nl80211?
johannes
^ permalink raw reply
* Re: [PATCH v3] mac80211: aead api to reduce redundancy
From: Johannes Berg @ 2017-10-11 7:48 UTC (permalink / raw)
To: Xiang Gao, davem, linux-kernel, linux-wireless, netdev
In-Reply-To: <20171011023149.18021-1-qasdfgtyuiop@gmail.com>
On Tue, 2017-10-10 at 22:31 -0400, Xiang Gao wrote:
> Currently, the aes_ccm.c and aes_gcm.c are almost line by line copy
> of
> each other. This patch reduce code redundancy by moving the code in
> these
> two files to crypto/aead_api.c to make it a higher level aead api.
> The
> file aes_ccm.c and aes_gcm.c are removed and all the functions there
> are
> now implemented in their headers using the newly added aead api.
Applied. FWIW, the sta_dynamic_down_up test that the robot complained
about, and the PSK tests that heavily use CCMP all pass.
johannes
^ permalink raw reply
* Re: 4.14.0-rc3 iwlwifi: Hardware became unavailable during restart
From: Luca Coelho @ 2017-10-11 7:47 UTC (permalink / raw)
To: Seraphime Kirkovski, linux-wireless; +Cc: linux-kernel
In-Reply-To: <20171010074414.x3uqv27prkqov45v@macchiaveli>
On Tue, 2017-10-10 at 09:44 +0200, Seraphime Kirkovski wrote:
> Hello,
Hi Seraphime,
> I've got this splat after a couple of suspend-resume cycles on my
> HP-laptop. I haven't had the time to bisect or test other rcs for now.
> Pasting some logs before the actual WARN_ON, as they may be relevant.
> Just after the splat the connection is successfully reestablished.
>
> [14293.758404] iwlwifi 0000:24:00.0: Error sending REPLY_SCAN_ABORT_CMD:
> time out after 2000ms.
> [14293.758429] iwlwifi 0000:24:00.0: Current CMD queue read_ptr 67 write_ptr 68
> [14293.758518] iwlwifi 0000:24:00.0: Loaded firmware version: 18.168.6.1
This seems to be a DVM device (iwldvm). What is the exact device
model? And you have never noticed this problem before?
Unfortunately this is a very old device and we don't support it
actively anymore. Hopefully this will turn out to be a trivial fix in
the driver side, so we can get it solved for you.
The best way to track this is to report it in
https://bugzilla.kernel.org.
--
Cheers,
Luca.
^ 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