* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Toke Høiland-Jørgensen @ 2019-04-17 9:09 UTC (permalink / raw)
To: Herbert Xu
Cc: Johannes Berg, Arend Van Spriel, Felix Fietkau, linux-wireless,
Eric Dumazet, netdev
In-Reply-To: <20190417033834.ep6t7r6ttvjek5g7@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Tue, Apr 16, 2019 at 02:18:36PM +0100, Toke Høiland-Jørgensen wrote:
>>
>> > The congestion control happens at two levels. You are right that the
>> > socket buffer acts as one limit. However, other applications may also
>> > rely on the TX queue being full as the throttle (by setting a
>> > sufficiently large socket buffer size).
>>
>> Do you happen to have an example of an application that does this that
>> could be used for testing? :)
>
> Have a look at
>
> commit 6ce9e7b5fe3195d1ae6e3a0753d4ddcac5cd699e
> Author: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Wed Sep 2 18:05:33 2009 -0700
>
> ip: Report qdisc packet drops
>
> You should be able to do a UDP flood while setting IP_RECVERR to
> detect the packet drop due to a full queue which AFAICS will never
> happen with the current mac80211 setup.
Yup, got that part. Was just wondering if you know of any applications
that already do this, that I could test without having to write my
own... :)
-Toke
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Toke Høiland-Jørgensen @ 2019-04-17 8:28 UTC (permalink / raw)
To: Herbert Xu
Cc: Johannes Berg, Arend Van Spriel, Felix Fietkau, linux-wireless,
Eric Dumazet, netdev
In-Reply-To: <20190417021101.5a32gox2ivbcgsbp@gondor.apana.org.au>
Herbert Xu <herbert@gondor.apana.org.au> writes:
> On Tue, Apr 16, 2019 at 11:02:50AM +0100, Toke Høiland-Jørgensen wrote:
>>
>> As explained at great length here:
>> https://www.usenix.org/conference/atc17/technical-sessions/presentation/hoilan-jorgesen
>> (you already know that of course, Johannes)
>
> I can understand that wireless needs its own queueing scheme, but it
> still seems wrong to place that under net/mac80211 as opposed to
> having it as a first-class citizen under net/sched.
This is because we need to resolve the MAC-layer destination station (or
rather, TID) and tie the queueing to that, because of aggregation. We
also use the queueing structure for scheduling stations to achieve
airtime fairness. Both of these would be decidedly non-trivial to pull
up to the qdisc layer. Rather, having them in mac80211 means drivers
don't need to do their own ad-hoc queueing (which was the case before,
leading extra bufferbloat).
Most of the actual queueing structure code lives in
include/net/fq_impl.h, though, so it's not actually that
mac80211-specific. I've been thinking about porting the relevant qdiscs
to use the same code, but I'm not sure that it's worth the trouble.
-Toke
^ permalink raw reply
* [PATCH 3/3] ath10k: Add wmi tlv service map for mesh 11s
From: Surabhi Vishnoi @ 2019-04-17 8:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Surabhi Vishnoi
In-Reply-To: <1555489907-30117-1-git-send-email-svishnoi@codeaurora.org>
WCN3990 firmware advertises the service WMI_TLV_SERVICE_MESH_11S
for mesh 11s. Map this wmi tlv service to enable mesh 11s
for WCN3990.
Tested HW: WCN3990
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index 55da01f..bc3198b 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -1567,6 +1567,8 @@ enum wmi_tlv_service {
WMI_SERVICE_SAP_AUTH_OFFLOAD, len);
SVCMAP(WMI_TLV_SERVICE_MGMT_TX_WMI,
WMI_SERVICE_MGMT_TX_WMI, len);
+ SVCMAP(WMI_TLV_SERVICE_MESH_11S,
+ WMI_SERVICE_MESH_11S, len);
}
static inline void
--
1.9.1
^ permalink raw reply related
* [PATCH 1/3] ath10k: Add wmi tlv vdev subtype for mesh in WCN3990
From: Surabhi Vishnoi @ 2019-04-17 8:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Surabhi Vishnoi
In-Reply-To: <1555489907-30117-1-git-send-email-svishnoi@codeaurora.org>
There is a disparity in wmi and wmi tlv vdev subtype
enum for WMI_VDEV_SUBTYPE_MESH_11S.
Add different enum for wmi tlv vdev subtype to support
vdev of subtype mesh 11s for WCN3990.
Tested HW: WCN3990
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 24 +++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 10 ++++++++++
2 files changed, 33 insertions(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.c b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
index 582fb11..a19f7e2 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.c
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.c
@@ -1905,6 +1905,28 @@ static struct sk_buff *ath10k_wmi_tlv_op_gen_init(struct ath10k *ar)
return skb;
}
+static int ath10k_wmi_tlv_op_get_vdev_subtype(struct ath10k *ar,
+ enum wmi_vdev_subtype subtype)
+{
+ switch (subtype) {
+ case WMI_VDEV_SUBTYPE_NONE:
+ return WMI_TLV_VDEV_SUBTYPE_NONE;
+ case WMI_VDEV_SUBTYPE_P2P_DEVICE:
+ return WMI_TLV_VDEV_SUBTYPE_P2P_DEV;
+ case WMI_VDEV_SUBTYPE_P2P_CLIENT:
+ return WMI_TLV_VDEV_SUBTYPE_P2P_CLI;
+ case WMI_VDEV_SUBTYPE_P2P_GO:
+ return WMI_TLV_VDEV_SUBTYPE_P2P_GO;
+ case WMI_VDEV_SUBTYPE_PROXY_STA:
+ return WMI_TLV_VDEV_SUBTYPE_PROXY_STA;
+ case WMI_VDEV_SUBTYPE_MESH_11S:
+ return WMI_TLV_VDEV_SUBTYPE_MESH_11S;
+ case WMI_VDEV_SUBTYPE_MESH_NON_11S:
+ return -ENOTSUPP;
+ }
+ return -ENOTSUPP;
+}
+
static struct sk_buff *
ath10k_wmi_tlv_op_gen_vdev_create(struct ath10k *ar,
u32 vdev_id,
@@ -4305,7 +4327,7 @@ static struct sk_buff *ath10k_wmi_tlv_op_gen_config_pno_stop(struct ath10k *ar,
.gen_tdls_peer_update = ath10k_wmi_tlv_op_gen_tdls_peer_update,
.gen_adaptive_qcs = ath10k_wmi_tlv_op_gen_adaptive_qcs,
.fw_stats_fill = ath10k_wmi_main_op_fw_stats_fill,
- .get_vdev_subtype = ath10k_wmi_op_get_vdev_subtype,
+ .get_vdev_subtype = ath10k_wmi_tlv_op_get_vdev_subtype,
.gen_echo = ath10k_wmi_tlv_op_gen_echo,
.gen_vdev_spectral_conf = ath10k_wmi_tlv_op_gen_vdev_spectral_conf,
.gen_vdev_spectral_enable = ath10k_wmi_tlv_op_gen_vdev_spectral_enable,
diff --git a/drivers/net/wireless/ath/ath10k/wmi-tlv.h b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
index 65e6aa5..55da01f 100644
--- a/drivers/net/wireless/ath/ath10k/wmi-tlv.h
+++ b/drivers/net/wireless/ath/ath10k/wmi-tlv.h
@@ -1775,6 +1775,16 @@ struct wmi_tlv_start_scan_cmd {
struct wmi_mac_addr mac_mask;
} __packed;
+enum wmi_tlv_vdev_subtype {
+ WMI_TLV_VDEV_SUBTYPE_NONE = 0,
+ WMI_TLV_VDEV_SUBTYPE_P2P_DEV = 1,
+ WMI_TLV_VDEV_SUBTYPE_P2P_CLI = 2,
+ WMI_TLV_VDEV_SUBTYPE_P2P_GO = 3,
+ WMI_TLV_VDEV_SUBTYPE_PROXY_STA = 4,
+ WMI_TLV_VDEV_SUBTYPE_MESH = 5,
+ WMI_TLV_VDEV_SUBTYPE_MESH_11S = 6,
+};
+
struct wmi_tlv_vdev_start_cmd {
__le32 vdev_id;
__le32 requestor_id;
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] ath10k: Do not send probe response template for mesh
From: Surabhi Vishnoi @ 2019-04-17 8:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Surabhi Vishnoi
In-Reply-To: <1555489907-30117-1-git-send-email-svishnoi@codeaurora.org>
Currently mac80211 do not support probe response template for
mesh point. When WMI_SERVICE_BEACON_OFFLOAD is enabled, host
driver tries to configure probe response template for mesh, but
it fails because the interface type is not NL80211_IFTYPE_AP but
NL80211_IFTYPE_MESH_POINT.
To avoid this failure, skip sending probe response template to
firmware for mesh point.
Tested HW: WCN3990/QCA6174/QCA9984
Signed-off-by: Surabhi Vishnoi <svishnoi@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index b73c23d..3eceb67 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -1630,6 +1630,10 @@ static int ath10k_mac_setup_prb_tmpl(struct ath10k_vif *arvif)
if (arvif->vdev_type != WMI_VDEV_TYPE_AP)
return 0;
+ /* For mesh, probe response and beacon share the same template */
+ if (ieee80211_vif_is_mesh(vif))
+ return 0;
+
prb = ieee80211_proberesp_get(hw, vif);
if (!prb) {
ath10k_warn(ar, "failed to get probe resp template from mac80211\n");
--
1.9.1
^ permalink raw reply related
* [PATCH 0/3] Add support for MESH 11S for WCN3990
From: Surabhi Vishnoi @ 2019-04-17 8:31 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Surabhi Vishnoi
Currently, mesh 11s is not supported for WCN3990.
This patchset add the changes to enable the mesh for WCN3990.
Surabhi Vishnoi (3):
ath10k: Add wmi tlv vdev subtype for mesh in WCN3990
ath10k: Do not send probe response template for mesh
ath10k: Add wmi tlv service map for mesh 11s
drivers/net/wireless/ath/ath10k/mac.c | 4 ++++
drivers/net/wireless/ath/ath10k/wmi-tlv.c | 24 +++++++++++++++++++++++-
drivers/net/wireless/ath/ath10k/wmi-tlv.h | 12 ++++++++++++
3 files changed, 39 insertions(+), 1 deletion(-)
--
1.9.1
^ permalink raw reply
* [PATCH v2] ath10k: fix different tx duration output
From: Lei Wang @ 2019-04-17 8:17 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Lei Wang
TX duration output of tx_stats in debugfs and station dump had big
difference because they got tx duration value from different statistic
data. We should use the same statistic data.
Tested: QCA988X with firmware ver 10.2.4-1.0-00043
Signed-off-by: Lei Wang <leiwa@codeaurora.org>
---
drivers/net/wireless/ath/ath10k/mac.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index b73c23d..5414169 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -7977,6 +7977,11 @@ static void ath10k_sta_statistics(struct ieee80211_hw *hw,
sinfo->rx_duration = arsta->rx_duration;
sinfo->filled |= BIT_ULL(NL80211_STA_INFO_RX_DURATION);
+ if (arsta->tx_stats && ath10k_debug_is_extd_tx_stats_enabled(ar)) {
+ sinfo->tx_duration = arsta->tx_stats->tx_duration;
+ sinfo->filled |= 1ULL << NL80211_STA_INFO_TX_DURATION;
+ }
+
if (!arsta->txrate.legacy && !arsta->txrate.nss)
return;
--
1.9.1
^ permalink raw reply related
* [PATCH] iwlwifi: don't panic in error path on non-msix systems
From: Luca Coelho @ 2019-04-17 7:35 UTC (permalink / raw)
To: kvalo, johannes, emmanuel.grumbach, linuxwifi
Cc: linux-kernel, linux-wireless, Shahar S Matityahu, Michal Hocko,
Luca Coelho
In-Reply-To: <748205b02961167b0926d4afe8d9ad9cb37bf6ef.camel@coelho.fi>
From: Shahar S Matityahu <shahar.s.matityahu@intel.com>
The driver uses msix causes-register to handle both msix and non msix
interrupts when performing sync nmi. On devices that do not support
msix this register is unmapped and accessing it causes a kernel panic.
Solve this by differentiating the two cases and accessing the proper
causes-register in each case.
Reported-by: Michal Hocko <mhocko@kernel.org>
Signed-off-by: Shahar S Matityahu <shahar.s.matityahu@intel.com>
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
.../net/wireless/intel/iwlwifi/pcie/trans.c | 19 +++++++++++++------
1 file changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
index 79c1dc05f948..c4375b868901 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/trans.c
@@ -3644,20 +3644,27 @@ struct iwl_trans *iwl_trans_pcie_alloc(struct pci_dev *pdev,
void iwl_trans_pcie_sync_nmi(struct iwl_trans *trans)
{
+ struct iwl_trans_pcie *trans_pcie = IWL_TRANS_GET_PCIE_TRANS(trans);
unsigned long timeout = jiffies + IWL_TRANS_NMI_TIMEOUT;
+ u32 inta_addr, sw_err_bit;
+
+ if (trans_pcie->msix_enabled) {
+ inta_addr = CSR_MSIX_HW_INT_CAUSES_AD;
+ sw_err_bit = MSIX_HW_INT_CAUSES_REG_SW_ERR;
+ } else {
+ inta_addr = CSR_INT;
+ sw_err_bit = CSR_INT_BIT_SW_ERR;
+ }
iwl_disable_interrupts(trans);
iwl_force_nmi(trans);
while (time_after(timeout, jiffies)) {
- u32 inta_hw = iwl_read32(trans,
- CSR_MSIX_HW_INT_CAUSES_AD);
+ u32 inta_hw = iwl_read32(trans, inta_addr);
/* Error detected by uCode */
- if (inta_hw & MSIX_HW_INT_CAUSES_REG_SW_ERR) {
+ if (inta_hw & sw_err_bit) {
/* Clear causes register */
- iwl_write32(trans, CSR_MSIX_HW_INT_CAUSES_AD,
- inta_hw &
- MSIX_HW_INT_CAUSES_REG_SW_ERR);
+ iwl_write32(trans, inta_addr, inta_hw & sw_err_bit);
break;
}
--
2.20.1
^ permalink raw reply related
* Re: iwlwifi: BUG: unable to handle kernel paging request at ffffc90000e1c808
From: Luca Coelho @ 2019-04-17 7:33 UTC (permalink / raw)
To: Michal Hocko, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, linux-wireless
Cc: LKML
In-Reply-To: <20190416183634.GB655@dhcp22.suse.cz>
On Tue, 2019-04-16 at 20:36 +0200, Michal Hocko wrote:
> On Fri 12-04-19 11:49:08, Michal Hocko wrote:
> > On Thu 11-04-19 23:07:20, Michal Hocko wrote:
> > > Hi,
> > > I have just encountered the following splat with 5.1-rc4. Is this
> > > a
> > > known problem? Greping throug older logs show that "Error sending
> > > SCAN_CFG_CMD"
> > > is not new. In older kernels it was followed by "Start IWL Error
> > > Log Dump:"
> > > but it oopsed now. I was running 5.0 previously. Let me know if
> > > you need
> > > more information.
> >
> > FTR It happened again with 5.1.0-rc2-00001-ga3ac7917b730
>
> Is there anything more I can provide to help with this issue. I had
> to
> go back to 5.0 because the system is not really usable after the
> oops.
Michal, thanks for reporting and all the data. We have a fix for it
and I'm going to send it out in a second. Please try it out and let us
know whether it works for you.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] iwlwifi: Use correct channel_profile iniwl_get_nvm
From: Luciano Coelho @ 2019-04-17 7:14 UTC (permalink / raw)
To: Yue Haibing, johannes.berg, emmanuel.grumbach, linuxwifi, kvalo
Cc: linux-kernel, netdev, linux-wireless, davem
In-Reply-To: <20190417032409.23924-1-yuehaibing@huawei.com>
On Wed, 2019-04-17 at 11:24 +0800, Yue Haibing wrote:
> From: YueHaibing <yuehaibing@huawei.com>
>
> commit 2785ce008e3b ("iwlwifi: support new NVM response API")
> seems forgot use correct channel_profile in iwl_get_nvm when call
> iwl_init_sbands().
>
> Fixes: 2785ce008e3b ("iwlwifi: support new NVM response API")
> Signed-off-by: YueHaibing <yuehaibing@huawei.com>
> ---
> drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
> b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
> index 40985dc..d87a6bb 100644
> --- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
> +++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
> @@ -1496,7 +1496,7 @@ struct iwl_nvm_data *iwl_get_nvm(struct
> iwl_trans *trans,
> (void *)rsp_v3->regulatory.channel_profile;
>
> iwl_init_sbands(trans->dev, trans->cfg, nvm,
> - rsp->regulatory.channel_profile,
> + channel_profile,
> nvm->valid_tx_ant & fw->valid_tx_ant,
> nvm->valid_rx_ant & fw->valid_rx_ant,
> sbands_flags, v4);
Thanks!
This was a rebase damage I made when sending this upstream. I've
applied this directly to our upstream feeding tree because it's not
wrong in our internal tree.
--
Cheers,
Luca.
^ permalink raw reply
* Re: [PATCH] iwlwifi: properly check debugfs dentry before using it
From: Luca Coelho @ 2019-04-17 7:02 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Laura Abbott, linux-kernel, Johannes Berg, Emmanuel Grumbach,
Intel Linux Wireless, Kalle Valo, linux-wireless, stable
In-Reply-To: <20190330093152.GB14300@kroah.com>
On Sat, 2019-03-30 at 10:31 +0100, Greg Kroah-Hartman wrote:
> debugfs can now report an error code if something went wrong instead
> of
> just NULL. So if the return value is to be used as a "real" dentry,
> it
> needs to be checked if it is an error before dereferencing it.
>
> This is now happening because of ff9fb72bc077 ("debugfs: return error
> values, not NULL"). If multiple iwlwifi devices are in the system,
> this
> can cause problems when the driver attempts to create the main
> debugfs
> directory again. Later on in the code we fail horribly by trying to
> dereference a pointer that is an error value.
>
> Reported-by: Laura Abbott <labbott@redhat.com>
> Cc: Johannes Berg <johannes.berg@intel.com>
> Cc: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
> Cc: Luca Coelho <luciano.coelho@intel.com>
> Cc: Intel Linux Wireless <linuxwifi@intel.com>
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: stable <stable@vger.kernel.org> # 5.0
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
> b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
> index 2453ceabf00d..6925527d8457 100644
> --- a/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
> +++ b/drivers/net/wireless/intel/iwlwifi/mvm/debugfs-vif.c
> @@ -774,8 +774,7 @@ void iwl_mvm_vif_dbgfs_register(struct iwl_mvm
> *mvm, struct ieee80211_vif *vif)
> return;
>
> mvmvif->dbgfs_dir = debugfs_create_dir("iwlmvm", dbgfs_dir);
> -
> - if (!mvmvif->dbgfs_dir) {
> + if (IS_ERR_OR_NULL(mvmvif->dbgfs_dir)) {
> IWL_ERR(mvm, "Failed to create debugfs directory under
> %pd\n",
> dbgfs_dir);
> return;
Thanks! I've applied this internally and will send upstream for v5.1-
rc* following our normal upstreaming process.
I added the other Reported-by that Laura asked for and added "mvm:" to
the subject.
--
Cheers,
Luca.
^ permalink raw reply
* [PATCH v2 03/11] nl80211: do a struct assignment to radar_chandef instead of memcpy()
From: Luca Coelho @ 2019-04-17 6:34 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, Luca Coelho
In-Reply-To: <35f813d89f2d0eed572fe9ceb6530ab42d081aa2.camel@sipsolutions.net>
From: Luca Coelho <luciano.coelho@intel.com>
We are copying one entire structure to another of the same type in
nl80211_notify_radar_detection, so it's simpler and safer to do a
struct assignment instead of memcpy().
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
---
net/wireless/nl80211.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 846d25d2dc82..64af8309f397 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -8182,7 +8182,7 @@ static int nl80211_notify_radar_detection(struct sk_buff *skb,
cfg80211_sched_dfs_chan_update(rdev);
- memcpy(&rdev->radar_chandef, &chandef, sizeof(chandef));
+ rdev->radar_chandef = chandef;
/* Propagate this notification to other radios as well */
queue_work(cfg80211_wq, &rdev->propagate_radar_detect_wk);
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] ath10k: reset chip after supported check
From: Tom Psyborg @ 2019-04-17 3:52 UTC (permalink / raw)
To: linux-wireless; +Cc: openwrt-devel, Ben Greear, Michał Kazior, Kalle Valo
In-Reply-To: <3337086.qEUs9xMCTV@debian64>
These replies never reached my inbox. Anyway scraped conversation off
the mailing list archive and CCing relevant people.
>> >>> Can you elaborate more a bit? What kind of crashes are you seeing?
>> >>> What does the bootloop look like? Do you have uart connected to
>> >>> diagnose?
>> >>>
>> >>> Didn't C7 v1 have the old QCA9880 hw v1 which isn't really supported
>> >>> by ath10k? I recall the v1 chip was really buggy and required
>> >>> hammering registers sometimes to get things working.
>> >>
>> >> The crash is related to the v1 chip. Is there a good way to detect
>> >> that this is the chip in question and only apply this work-around
>> >> for the problem chip?
yes there is. but the provided solution should be enough. which device
really depend on reset to probe sueccesfully? that device need other
fixes!
>> >
>> > I don't know of any good way to do that.
>> >
>> > You could consider device-tree but that would be no different from
>> > having a module blacklist in the C7v1 build recipe, or to not build
>> > the module at all. That is unless you actually want to make v1 chip
>> > work with ath10k at which point there's more fun to be had before it
>> > can actually work.
this is also intention. can it work with v2.0 fw?
>>
>> I remember v1, and I have no interest in trying to make it work :)
>>
>> If we could blacklist certain pci slots in the ath10k driver, I guess
>> that would work?
>>
>> I think the goal is to not use the v1 chip, but allow users to add a
>> v2 NIC to the platform, so driver still needs to load.
>
>That makes sense, but I don't see how blacklisting pci slots would
>help someone putting v2 nic into C7v1 mobo? Won't the slot be the same
>regardless what nic is put?
>
>The best thing I can come up with is something like this:
>
>--- a/drivers/net/wireless/ath/ath10k/pci.c
>+++ b/drivers/net/wireless/ath/ath10k/pci.c
>@@ -3629,6 +3629,19 @@ static int ath10k_pci_probe(struct pci_dev *pdev,
> goto err_deinit_irq;
> }
>
>+ if (hw_rev == ATH10K_HW_QCA988X) {
>+ /* v1 can crash the system on chip_reset()
>+ * so all we can do is keep our fingers
>+ * crossed v2 never reports 0 without a
>+ * chip_reset()
>+ */
>+ if (ath10k_pci_soc_read32(ar, SOC_CHIP_ID_ADDRESS) == 0) {
>+ ath10k_err(ar, "qca9880 v1 is chip not supported");
>+ ret = -ENOTSUP;
>+ goto err_free_irq;
>+ }
>+ }
>+
> ret = ath10k_pci_chip_reset(ar);
> if (ret) {
> ath10k_err(ar, "failed to reset chip: %d\n", ret);
>
>I didn't test it. Someone needs to compile and test and make sure v2
>doesn't regress when fw hangs and cold & warm host cpu resets are
>mixed in.
>
>
>Michał
this doesn't even fix the bootloop with v1
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Herbert Xu @ 2019-04-17 3:38 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Johannes Berg, Arend Van Spriel, Felix Fietkau, linux-wireless,
Eric Dumazet, netdev
In-Reply-To: <87wojut7f7.fsf@toke.dk>
On Tue, Apr 16, 2019 at 02:18:36PM +0100, Toke Høiland-Jørgensen wrote:
>
> > The congestion control happens at two levels. You are right that the
> > socket buffer acts as one limit. However, other applications may also
> > rely on the TX queue being full as the throttle (by setting a
> > sufficiently large socket buffer size).
>
> Do you happen to have an example of an application that does this that
> could be used for testing? :)
Have a look at
commit 6ce9e7b5fe3195d1ae6e3a0753d4ddcac5cd699e
Author: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed Sep 2 18:05:33 2009 -0700
ip: Report qdisc packet drops
You should be able to do a UDP flood while setting IP_RECVERR to
detect the packet drop due to a full queue which AFAICS will never
happen with the current mac80211 setup.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] iwlwifi: Use correct channel_profile iniwl_get_nvm
From: Yue Haibing @ 2019-04-17 3:24 UTC (permalink / raw)
To: johannes.berg, emmanuel.grumbach, luciano.coelho, linuxwifi,
kvalo
Cc: linux-kernel, netdev, linux-wireless, davem, YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
commit 2785ce008e3b ("iwlwifi: support new NVM response API")
seems forgot use correct channel_profile in iwl_get_nvm when call
iwl_init_sbands().
Fixes: 2785ce008e3b ("iwlwifi: support new NVM response API")
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
index 40985dc..d87a6bb 100644
--- a/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
+++ b/drivers/net/wireless/intel/iwlwifi/iwl-nvm-parse.c
@@ -1496,7 +1496,7 @@ struct iwl_nvm_data *iwl_get_nvm(struct iwl_trans *trans,
(void *)rsp_v3->regulatory.channel_profile;
iwl_init_sbands(trans->dev, trans->cfg, nvm,
- rsp->regulatory.channel_profile,
+ channel_profile,
nvm->valid_tx_ant & fw->valid_tx_ant,
nvm->valid_rx_ant & fw->valid_rx_ant,
sbands_flags, v4);
--
2.7.0
^ permalink raw reply related
* [PATCH] ath9k: Remove some set but not used variables
From: Yue Haibing @ 2019-04-17 2:57 UTC (permalink / raw)
To: kvalo; +Cc: linux-kernel, netdev, linux-wireless, ath9k-devel, davem,
YueHaibing
From: YueHaibing <yuehaibing@huawei.com>
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/net/wireless/ath/ath9k/xmit.c: In function 'ath_tx_count_frames':
drivers/net/wireless/ath/ath9k/xmit.c:413:25: warning: variable 'fi' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/ath/ath9k/xmit.c: In function 'ath_tx_complete_aggr':
drivers/net/wireless/ath/ath9k/xmit.c:449:24: warning: variable 'hdr' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/ath/ath9k/xmit.c: In function 'ath_tx_start':
drivers/net/wireless/ath/ath9k/xmit.c:2274:18: warning: variable 'avp' set but not used [-Wunused-but-set-variable]
drivers/net/wireless/ath/ath9k/xmit.c:2269:24: warning: variable 'hdr' set but not used [-Wunused-but-set-variable]
These variables are not used any more
and can be removed.
Signed-off-by: YueHaibing <yuehaibing@huawei.com>
---
drivers/net/wireless/ath/ath9k/xmit.c | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/xmit.c b/drivers/net/wireless/ath/ath9k/xmit.c
index b17e1ca..59c3ab7 100644
--- a/drivers/net/wireless/ath/ath9k/xmit.c
+++ b/drivers/net/wireless/ath/ath9k/xmit.c
@@ -410,7 +410,6 @@ static void ath_tx_count_frames(struct ath_softc *sc, struct ath_buf *bf,
struct ath_tx_status *ts, int txok,
int *nframes, int *nbad)
{
- struct ath_frame_info *fi;
u16 seq_st = 0;
u32 ba[WME_BA_BMP_SIZE >> 5];
int ba_index;
@@ -426,7 +425,6 @@ static void ath_tx_count_frames(struct ath_softc *sc, struct ath_buf *bf,
}
while (bf) {
- fi = get_frame_info(bf->bf_mpdu);
ba_index = ATH_BA_INDEX(seq_st, bf->bf_state.seqno);
(*nframes)++;
@@ -446,7 +444,6 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
{
struct ath_node *an = NULL;
struct sk_buff *skb;
- struct ieee80211_hdr *hdr;
struct ieee80211_tx_info *tx_info;
struct ath_buf *bf_next, *bf_last = bf->bf_lastbf;
struct list_head bf_head;
@@ -463,8 +460,6 @@ static void ath_tx_complete_aggr(struct ath_softc *sc, struct ath_txq *txq,
int bar_index = -1;
skb = bf->bf_mpdu;
- hdr = (struct ieee80211_hdr *)skb->data;
-
tx_info = IEEE80211_SKB_CB(skb);
memcpy(rates, bf->rates, sizeof(rates));
@@ -2269,12 +2264,10 @@ static int ath_tx_prepare(struct ieee80211_hw *hw, struct sk_buff *skb,
int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff *skb,
struct ath_tx_control *txctl)
{
- struct ieee80211_hdr *hdr;
struct ieee80211_tx_info *info = IEEE80211_SKB_CB(skb);
struct ieee80211_sta *sta = txctl->sta;
struct ieee80211_vif *vif = info->control.vif;
struct ath_frame_info *fi = get_frame_info(skb);
- struct ath_vif *avp = NULL;
struct ath_softc *sc = hw->priv;
struct ath_txq *txq = txctl->txq;
struct ath_atx_tid *tid = NULL;
@@ -2283,16 +2276,12 @@ int ath_tx_start(struct ieee80211_hw *hw, struct sk_buff *skb,
bool ps_resp;
int q, ret;
- if (vif)
- avp = (void *)vif->drv_priv;
-
ps_resp = !!(info->control.flags & IEEE80211_TX_CTRL_PS_RESPONSE);
ret = ath_tx_prepare(hw, skb, txctl);
if (ret)
return ret;
- hdr = (struct ieee80211_hdr *) skb->data;
/*
* At this point, the vif, hw_key and sta pointers in the tx control
* info are no longer valid (overwritten by the ath_frame_info data.
--
2.7.0
^ permalink raw reply related
* Re: [PATCH] rtlwifi: rtl8188ee: Remove extraneous file
From: Kalle Valo @ 2019-04-17 2:55 UTC (permalink / raw)
To: Larry Finger; +Cc: linux-wireless, pkshih, Andrew Morton
In-Reply-To: <20190417003547.26271-1-Larry.Finger@lwfinger.net>
Larry Finger <Larry.Finger@lwfinger.net> writes:
> Somehow file drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej was
> incorporated into the sources. Obviously, it can be removed.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Reported-by: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> Andrew,
>
> Thanks.
>
> Larry
> ---
> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej | 10 ----------
> 1 file changed, 10 deletions(-)
> delete mode 100644 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
> b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
> deleted file mode 100644
> index aa03d4605d8c..000000000000
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
> +++ /dev/null
What tree is this? On wireless-drivers I can't find this file:
$ ls drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
/bin/ls: cannot access 'drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej': No such file or directory
$
Actually I cannot find any .rej files:
$ find -name '*.rej'
$
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Herbert Xu @ 2019-04-17 2:13 UTC (permalink / raw)
To: Johannes Berg
Cc: Toke Høiland-Jørgensen, Arend Van Spriel, Felix Fietkau,
linux-wireless, Eric Dumazet, netdev
In-Reply-To: <8678e1a4eb816878867f71878e8fe7c225f1b7f7.camel@sipsolutions.net>
On Tue, Apr 16, 2019 at 09:13:16PM +0200, Johannes Berg wrote:
>
> I'm not sure how they'd even realize this, other than packets getting
> dropped? Which of course we do here as well, we didn't invent something
> that let's us expand memory arbitrarily ;-)
They rely on the queueing mechanism providing feedback via an
error return value when the queue becomes full. From my cursory
look at net/mac80211 you seem to be always returning success in
ieee80211_subif_start_xmit.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH 5/5] mac80211: set NETIF_F_LLTX when using intermediate tx queues
From: Herbert Xu @ 2019-04-17 2:11 UTC (permalink / raw)
To: Toke Høiland-Jørgensen
Cc: Johannes Berg, Arend Van Spriel, Felix Fietkau, linux-wireless,
Eric Dumazet, netdev
In-Reply-To: <8736miuv1x.fsf@toke.dk>
On Tue, Apr 16, 2019 at 11:02:50AM +0100, Toke Høiland-Jørgensen wrote:
>
> As explained at great length here:
> https://www.usenix.org/conference/atc17/technical-sessions/presentation/hoilan-jorgesen
> (you already know that of course, Johannes)
I can understand that wireless needs its own queueing scheme, but
it still seems wrong to place that under net/mac80211 as opposed
to having it as a first-class citizen under net/sched.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH] rtlwifi: rtl8188ee: Remove extraneous file
From: Pkshih @ 2019-04-17 1:34 UTC (permalink / raw)
To: kvalo@codeaurora.org, Larry.Finger@lwfinger.net
Cc: linux-wireless@vger.kernel.org, akpm@linux-foundation.org
In-Reply-To: <20190417003547.26271-1-Larry.Finger@lwfinger.net>
On Tue, 2019-04-16 at 19:35 -0500, Larry Finger wrote:
> Somehow file drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej was
> incorporated into the sources. Obviously, it can be removed.
>
> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
> Reported-by: Andrew Morton <akpm@linux-foundation.org>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
> Andrew,
>
> Thanks.
>
> Larry
> ---
> drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej | 10 ----------
> 1 file changed, 10 deletions(-)
> delete mode 100644 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
>
> diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
> b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
> deleted file mode 100644
> index aa03d4605d8c..000000000000
> --- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
> +++ /dev/null
> @@ -1,10 +0,0 @@
> ---- drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
> -+++ drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
> -@@ -373,6 +373,7 @@ bool rtl88ee_rx_query_desc(struct ieee80211_hw *hw,
> - struct rx_fwinfo_88e *p_drvinfo;
> - struct ieee80211_hdr *hdr;
> - u32 phystatus = GET_RX_DESC_PHYST(pdesc);
> -+ u8 wake_match;
> -
> - status->packet_report_type = (u8)GET_RX_STATUS_DESC_RPT_SEL(pdesc);
> - if (status->packet_report_type == TX_REPORT2)
The change of trx.c seems not belong to this patch, right?
^ permalink raw reply
* [PATCH] rtlwifi: rtl8188ee: Remove extraneous file
From: Larry Finger @ 2019-04-17 0:35 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, pkshih, Larry Finger, Andrew Morton
Somehow file drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej was
incorporated into the sources. Obviously, it can be removed.
Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net>
Reported-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
---
Andrew,
Thanks.
Larry
---
drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej | 10 ----------
1 file changed, 10 deletions(-)
delete mode 100644 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
deleted file mode 100644
index aa03d4605d8c..000000000000
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c.rej
+++ /dev/null
@@ -1,10 +0,0 @@
---- drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
-+++ drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
-@@ -373,6 +373,7 @@ bool rtl88ee_rx_query_desc(struct ieee80211_hw *hw,
- struct rx_fwinfo_88e *p_drvinfo;
- struct ieee80211_hdr *hdr;
- u32 phystatus = GET_RX_DESC_PHYST(pdesc);
-+ u8 wake_match;
-
- status->packet_report_type = (u8)GET_RX_STATUS_DESC_RPT_SEL(pdesc);
- if (status->packet_report_type == TX_REPORT2)
--
2.16.4
^ permalink raw reply related
* [PATCH] staging: wilc1000: Avoid GFP_KERNEL allocation from atomic context
From: Adham.Abozaeid @ 2019-04-16 23:17 UTC (permalink / raw)
To: linux-wireless; +Cc: devel, gregkh, johannes, Ajay.Kathat, Adham.Abozaeid
From: Adham Abozaeid <adham.abozaeid@microchip.com>
txq_add_mgmt_pkt allocates memory while being called from atomic context
so needs to use GFP_ATOMIC
Signed-off-by: Adham Abozaeid <adham.abozaeid@microchip.com>
---
drivers/staging/wilc1000/wilc_wlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/wilc1000/wilc_wlan.c b/drivers/staging/wilc1000/wilc_wlan.c
index 2b309c8a8fb2..0a713409ea98 100644
--- a/drivers/staging/wilc1000/wilc_wlan.c
+++ b/drivers/staging/wilc1000/wilc_wlan.c
@@ -316,7 +316,7 @@ int wilc_wlan_txq_add_mgmt_pkt(struct net_device *dev, void *priv, u8 *buffer,
if (wilc->quit)
return 0;
- tqe = kmalloc(sizeof(*tqe), GFP_KERNEL);
+ tqe = kmalloc(sizeof(*tqe), GFP_ATOMIC);
if (!tqe)
return 0;
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v3 00/26] compat_ioctl: cleanups
From: Douglas Gilbert @ 2019-04-16 22:33 UTC (permalink / raw)
To: Arnd Bergmann, Alexander Viro
Cc: linux-fsdevel, y2038, linux-kernel, David S. Miller,
Greg Kroah-Hartman, Karsten Keil, James E.J. Bottomley,
Martin K. Petersen, Marcel Holtmann, netdev, devel,
linux-integrity, qat-linux, linux-crypto, linux-media, dri-devel,
linux1394-devel, amd-gfx, linux-input, linux-usb,
linux-arm-kernel, linux-ide, linux-iio, linux-rdma, linuxppc-dev,
linux-mtd, linux-ppp, linux-nvme, platform-driver-x86,
linux-remoteproc, linux-rtc, linux-s390, sparclinux, linux-scsi,
linux-fbdev, linux-btrfs, ceph-devel, linux-bluetooth,
linux-wireless, alsa-devel
In-Reply-To: <20190416202013.4034148-1-arnd@arndb.de>
On 2019-04-16 4:19 p.m., Arnd Bergmann wrote:
> Hi Al,
>
> It took me way longer than I had hoped to revisit this series, see
> https://lore.kernel.org/lkml/20180912150142.157913-1-arnd@arndb.de/
> for the previously posted version.
>
> I've come to the point where all conversion handlers and most
> COMPATIBLE_IOCTL() entries are gone from this file, but for
> now, this series only has the parts that have either been reviewed
> previously, or that are simple enough to include.
>
> The main missing piece is the SG_IO/SG_GET_REQUEST_TABLE conversion.
> I'll post the patches I made for that later, as they need more
> testing and review from the scsi maintainers.
Perhaps you could look at the document in this url:
http://sg.danny.cz/sg/sg_v40.html
It is work-in-progress to modernize the SCSI generic driver. It
extends ioctl(sg_fd, SG_IO, &pt_obj) to additionally accept the sg v4
interface as defined in include/uapi/linux/bsg.h . Currently only the
bsg driver uses the sg v4 interface. Since struct sg_io_v4 is all
explicitly sized integers, I'm guessing it is immune "compat" problems.
[I can see no reference to bsg nor struct sg_io_v4 in the current
fs/compat_ioctl.c file.]
Other additions described in the that document are these new ioctls:
- SG_IOSUBMIT ultimately to replace write(sg_fd, ...)
- SG_IORECEIVE to replace read(sg_fd, ...)
- SG_IOABORT abort SCSI cmd in progress; new functionality
- SG_SET_GET_EXTENDED has associated struct sg_extended_info
The first three take a pointer to a struct sg_io_hdr (v3 interface) or
a struct sg_io_v4 object. Both objects start with a 32 bit integer:
'S' identifies the v3 interface while 'Q' identifies the v4 interface.
The SG_SET_GET_EXTENDED ioctl takes a pointer to a struct
sg_extended_info object which contains explicitly sized integers so it
may also be immune from "compat" problems. The ioctls section (13) of
that document referenced above has a table showing how many "sets and
gets" are hiding in the SG_SET_GET_EXTENDED ioctl.
BTW No change is proposed for this case:
ioctl(normal_block_device, SG_IO, &sg_v3_obj)
which is handled by block/scsi_ioctl.c
This would be a good time for me to address any "compat" concerns in the
proposed sg driver update.
Doug Gilbert
> I hope you can still take these for the coming merge window, unless
> new problems come up.
>
> Arnd
>
> Arnd Bergmann (26):
> compat_ioctl: pppoe: fix PPPOEIOCSFWD handling
> compat_ioctl: move simple ppp command handling into driver
> compat_ioctl: avoid unused function warning for do_ioctl
> compat_ioctl: move PPPIOCSCOMPRESS32 to ppp-generic.c
> compat_ioctl: move PPPIOCSPASS32/PPPIOCSACTIVE32 to ppp_generic.c
> compat_ioctl: handle PPPIOCGIDLE for 64-bit time_t
> compat_ioctl: move rtc handling into rtc-dev.c
> compat_ioctl: add compat_ptr_ioctl()
> compat_ioctl: move drivers to compat_ptr_ioctl
> compat_ioctl: use correct compat_ptr() translation in drivers
> ceph: fix compat_ioctl for ceph_dir_operations
> compat_ioctl: move more drivers to compat_ptr_ioctl
> compat_ioctl: move tape handling into drivers
> compat_ioctl: move ATYFB_CLK handling to atyfb driver
> compat_ioctl: move isdn/capi ioctl translation into driver
> compat_ioctl: move rfcomm handlers into driver
> compat_ioctl: move hci_sock handlers into driver
> compat_ioctl: remove HCIUART handling
> compat_ioctl: remove HIDIO translation
> compat_ioctl: remove translation for sound ioctls
> compat_ioctl: remove IGNORE_IOCTL()
> compat_ioctl: remove /dev/random commands
> compat_ioctl: remove joystick ioctl translation
> compat_ioctl: remove PCI ioctl translation
> compat_ioctl: remove /dev/raw ioctl translation
> compat_ioctl: remove last RAID handling code
>
> Documentation/networking/ppp_generic.txt | 2 +
> arch/um/drivers/hostaudio_kern.c | 1 +
> drivers/android/binder.c | 2 +-
> drivers/char/ppdev.c | 12 +-
> drivers/char/random.c | 1 +
> drivers/char/tpm/tpm_vtpm_proxy.c | 12 +-
> drivers/crypto/qat/qat_common/adf_ctl_drv.c | 2 +-
> drivers/dma-buf/dma-buf.c | 4 +-
> drivers/dma-buf/sw_sync.c | 2 +-
> drivers/dma-buf/sync_file.c | 2 +-
> drivers/firewire/core-cdev.c | 12 +-
> drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 2 +-
> drivers/hid/hidraw.c | 4 +-
> drivers/hid/usbhid/hiddev.c | 11 +-
> drivers/hwtracing/stm/core.c | 12 +-
> drivers/ide/ide-tape.c | 31 +-
> drivers/iio/industrialio-core.c | 2 +-
> drivers/infiniband/core/uverbs_main.c | 4 +-
> drivers/isdn/capi/capi.c | 31 +
> drivers/isdn/i4l/isdn_ppp.c | 14 +-
> drivers/media/rc/lirc_dev.c | 4 +-
> drivers/mfd/cros_ec_dev.c | 4 +-
> drivers/misc/cxl/flash.c | 8 +-
> drivers/misc/genwqe/card_dev.c | 23 +-
> drivers/misc/mei/main.c | 22 +-
> drivers/misc/vmw_vmci/vmci_host.c | 2 +-
> drivers/mtd/ubi/cdev.c | 36 +-
> drivers/net/ppp/ppp_generic.c | 99 +++-
> drivers/net/ppp/pppoe.c | 7 +
> drivers/net/ppp/pptp.c | 3 +
> drivers/net/tap.c | 12 +-
> drivers/nvdimm/bus.c | 4 +-
> drivers/nvme/host/core.c | 2 +-
> drivers/pci/switch/switchtec.c | 2 +-
> drivers/platform/x86/wmi.c | 2 +-
> drivers/rpmsg/rpmsg_char.c | 4 +-
> drivers/rtc/dev.c | 13 +-
> drivers/rtc/rtc-vr41xx.c | 10 +
> drivers/s390/char/tape_char.c | 41 +-
> drivers/sbus/char/display7seg.c | 2 +-
> drivers/sbus/char/envctrl.c | 4 +-
> drivers/scsi/3w-xxxx.c | 4 +-
> drivers/scsi/cxlflash/main.c | 2 +-
> drivers/scsi/esas2r/esas2r_main.c | 2 +-
> drivers/scsi/megaraid/megaraid_mm.c | 28 +-
> drivers/scsi/osst.c | 34 +-
> drivers/scsi/pmcraid.c | 4 +-
> drivers/scsi/st.c | 35 +-
> drivers/staging/android/ion/ion.c | 4 +-
> drivers/staging/pi433/pi433_if.c | 12 +-
> drivers/staging/vme/devices/vme_user.c | 2 +-
> drivers/tee/tee_core.c | 2 +-
> drivers/usb/class/cdc-wdm.c | 2 +-
> drivers/usb/class/usbtmc.c | 4 +-
> drivers/usb/core/devio.c | 16 +-
> drivers/usb/gadget/function/f_fs.c | 12 +-
> drivers/vfio/vfio.c | 39 +-
> drivers/vhost/net.c | 12 +-
> drivers/vhost/scsi.c | 12 +-
> drivers/vhost/test.c | 12 +-
> drivers/vhost/vsock.c | 12 +-
> drivers/video/fbdev/aty/atyfb_base.c | 12 +-
> drivers/virt/fsl_hypervisor.c | 2 +-
> fs/btrfs/super.c | 2 +-
> fs/ceph/dir.c | 1 +
> fs/ceph/file.c | 2 +-
> fs/compat_ioctl.c | 602 +-------------------
> fs/fat/file.c | 13 +-
> fs/fuse/dev.c | 2 +-
> fs/notify/fanotify/fanotify_user.c | 2 +-
> fs/userfaultfd.c | 2 +-
> include/linux/fs.h | 7 +
> include/linux/if_pppox.h | 2 +
> include/linux/mtio.h | 58 ++
> include/uapi/linux/ppp-ioctl.h | 2 +
> include/uapi/linux/ppp_defs.h | 14 +
> net/bluetooth/hci_sock.c | 21 +-
> net/bluetooth/rfcomm/sock.c | 14 +-
> net/l2tp/l2tp_ppp.c | 3 +
> net/rfkill/core.c | 2 +-
> sound/core/oss/pcm_oss.c | 4 +
> sound/oss/dmasound/dmasound_core.c | 2 +
> 82 files changed, 452 insertions(+), 1034 deletions(-)
> create mode 100644 include/linux/mtio.h
>
^ permalink raw reply
* Re: [RFC PATCH v3 07/12] iwlwifi: Extended Key ID support (NATIVE)
From: Alexander Wetzel @ 2019-04-16 21:32 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <08b4769ff83eb9b098fee8915ca25666f29512c7.camel@sipsolutions.net>
Am 16.04.19 um 21:11 schrieb Johannes Berg:
> On Tue, 2019-04-16 at 20:28 +0200, Alexander Wetzel wrote:
>
>> They can enable the mode when a key with IEEE80211_KEY_FLAG_NO_AUTO_TX
>> set
>
> This I agree with.
>
>> and quiet it again as soon as they get a MPDU using the new KeyID.
>
> This isn't true, afaict. You need to be sure that no MPDUs remain using
> the old key ID, not just that the new key ID showed up.
>
Hm, you are right. There is no grantee that after the first frame with
the new keyID all frames after that will also use the new keyID when
using different priority classes, I assume..
But each TID should have a clean cut over, shouldn't it?
But then that would only help us with cards able to control the A-MPDU
size per TID...
Short of sending a dummy MPDU to each TID from mac80211 as key border
and the driver waiting for all of them I can't think of anything right
now. I really hope we can find something better...
>> Since switching back to normal doesn't have to be done immediately a
>> asyc call from Tx path or even a worker should do the job just fine.
>
> Sure.
>
>> Btw:
>> This also means we'll have to update the merged mac80211 Extended Key ID
>> support: We can only enable it for cards without HW crypto when they do
>> not set AMPDU_AGGREGATION. With the updated userspace these cards will
>> start using Extended Key ID with the already merged patches.
>
> I was going to say this is fine, but no, of course not ... we shouldn't
> use different key id in the same A-MPDU.
>
> That said, I'd be very surprised if there are any such drivers, except
> in corner cases (like loading some drivers like ath9k or iwlwifi with
> swcrypto=1 or so)
>
These should be no problem. The drivers still implement set_key and
mac80211 will not enable Extended Key ID for them. Enabling Extended Key
ID with SW crypto for drivers implementing set_key is only possible by
patching either mac80211 or the driver.
Btw:
That was the main use case I added the mac80211 module parameter
ieee80211_extended_key_id for. But looks like that was of too little use
and cut out.
>> Of those only hwsim and brcmsmac seems to support AMPDU and only
>> brcmsmac relly needs the fix to not lose some packets when rekeying.
>
> I can't believe that brcmsmac has no HW crypto support?
I've just greped the drivers, brcmsmac has ampdu_action in its
implementation of struct ieee80211_ops but no set_key.
So it really looks like SW crypto only to me...
>
> Anyway, a patch - even if it serves mostly as documentation - would be
> most welcome.
I'll prepare something. Looks really trivial to fix that.
>> I assume we still have to wait till the API is in mainline (probably
>> 5.2) to ask hostapd/wpa_supplicant to merge the patches?
>
> No, mac80211-next is (usually?) good enough.
Good to know:-)
Alexander
^ permalink raw reply
* Re: rtlwifi-new v0.6 and dkms failures
From: David R. Bergstein @ 2019-04-16 21:19 UTC (permalink / raw)
To: Larry Finger, Tony Chuang
Cc: Pkshih, linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <60509a60-d0ea-d17f-8b79-e51c374717ba@gmail.com>
Larry,
As it tuns out, I was able to create a new dkms.conf file which works on
my system. Below is copy of the content from that file:
PACKAGE_NAME="rtlwifi-new"
PACKAGE_VERSION=0.6
MAKE="make -C $kernel_source_dir
M=$dkms_tree/$PACKAGE_NAME/$PACKAGE_VERSION/build"
CLEAN="make -C $kernel_source_dir clean"
BUILT_MODULE_NAME[0]="rtw88"
BUILT_MODULE_NAME[1]="rtwpci"
DEST_MODULE_LOCATION[0]="/updates"
DEST_MODULE_LOCATION[1]="/updates"
REMAKE_INITRD=no
AUTOINSTALL=yes
This also had the benefit of module signing by the version of dkms in
Ubuntu 19.04, so I am now also back on secure boot.
No action on your part is requested at this time. Feel free to use the
new dkms.conf content if it is useful to you.
Regards,
David R. Bergstein
On 4/14/19 5:39 PM, David R. Bergstein wrote:
> Larry,
>
> Thanks for your prior assistance with the rtw88 module. Since manually
> compiling and installing works correctly, I have been working to
> register the software in dkms, but am running into some difficulties.
> Below are some snippets from a terminal session to illustrate the issue:
>
> udo dkms install rtlwifi-new/0.6
>
> Creating symlink /var/lib/dkms/rtlwifi-new/0.6/source ->
> /usr/src/rtlwifi-new-0.6
>
> DKMS: add completed.
>
> Kernel preparation unnecessary for this kernel. Skipping...
>
> Building module:
> cleaning build area....(bad exit status: 2)
> make -j12 KERNELRELEASE=5.0.0-11-lowlatency -C
> /lib/modules/5.0.0-11-lowlatency/build
> M=/var/lib/dkms/rtlwifi-new/0.6/build....
> ERROR (dkms apport): binary package for rtlwifi-new: 0.6 not found
> Error! Build of rtl_pci.ko failed for: 5.0.0-11-lowlatency (x86_64)
> Consult the make.log in the build directory
> /var/lib/dkms/rtlwifi-new/0.6/build/ for more information.
>
> Below is the make.log contents referenced above:
>
> DKMS make.log for rtlwifi-new-0.6 for kernel 5.0.0-11-lowlatency (x86_64)
> Sun 14 Apr 2019 05:25:37 PM EDT
> make: Entering directory '/usr/src/linux-headers-5.0.0-11-lowlatency'
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/main.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/mac80211.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/util.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/debug.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/tx.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/rx.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/mac.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/phy.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/efuse.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/fw.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/ps.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/sec.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/regd.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/rtw8822b.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/rtw8822b_table.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/rtw8822c.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/rtw8822c_table.o
> CC [M] /var/lib/dkms/rtlwifi-new/0.6/build/pci.o
> LD [M] /var/lib/dkms/rtlwifi-new/0.6/build/rtwpci.o
> LD [M] /var/lib/dkms/rtlwifi-new/0.6/build/rtw88.o
> Building modules, stage 2.
> MODPOST 2 modules
> CC /var/lib/dkms/rtlwifi-new/0.6/build/rtw88.mod.o
> CC /var/lib/dkms/rtlwifi-new/0.6/build/rtwpci.mod.o
> LD [M] /var/lib/dkms/rtlwifi-new/0.6/build/rtw88.ko
> LD [M] /var/lib/dkms/rtlwifi-new/0.6/build/rtwpci.ko
> make: Leaving directory '/usr/src/linux-headers-5.0.0-11-lowlatency'
>
> As you can see, the make log does not show any errors, which is baffling
> to me. Any insight you have on resolving this issue would be appreciated.
>
> Sincerely,
>
> David R. Bergstein
>
>
^ 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