[PATCH v4 2/2] drivers: remove force dma flag from buses
With each bus implementing its own DMA configuration callback,
there is no need for bus to explicitly have force_dma in its
global structure. This patch modifies of_dma_configure API to
accept an input parameter which specifies if implicit DMA
configuration is required even when it is not described by the
firmware.
Signed-off-by: Nipun Gupta
Acked-by: Bjorn Helgaas # PCI parts
---
Changes in v2:
- This is a new change suggested by Robin and Christoph
and is added to the series.
Changes in v3:
- Rebase and changes corresponding to the changes in patch 1/2
Changes in v4:
- Rebased on top of 4.17-rc2
drivers/amba/bus.c| 1 -
drivers/base/platform.c | 3 +--
drivers/bcma/main.c | 2 +-
drivers/dma/qcom/hidma_mgmt.c | 2 +-
drivers/gpu/host1x/bus.c | 5 ++---
drivers/of/device.c | 6 --
drivers/of/of_reserved_mem.c | 2 +-
drivers/pci/pci-driver.c | 3 +--
include/linux/device.h| 4
include/linux/of_device.h | 8 ++--
10 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 867dc2b..abe73c4 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -199,7 +199,6 @@ struct bus_type amba_bustype = {
.uevent = amba_uevent,
.dma_configure = platform_dma_configure,
.pm = &amba_pm,
- .force_dma = true,
};
static int __init amba_init(void)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 638d42e..c0ff1e7 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1136,7 +1136,7 @@ int platform_dma_configure(struct device *dev)
int ret = 0;
if (dev->of_node) {
- ret = of_dma_configure(dev, dev->of_node);
+ ret = of_dma_configure(dev, dev->of_node, true);
} else if (has_acpi_companion(dev)) {
attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
if (attr != DEV_DMA_NOT_SUPPORTED)
@@ -1159,7 +1159,6 @@ struct bus_type platform_bus_type = {
.uevent = platform_uevent,
.dma_configure = platform_dma_configure,
.pm = &platform_dev_pm_ops,
- .force_dma = true,
};
EXPORT_SYMBOL_GPL(platform_bus_type);
diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
index e6986c7..fc1f4ac 100644
--- a/drivers/bcma/main.c
+++ b/drivers/bcma/main.c
@@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
core->irq = bcma_of_get_irq(parent, core, 0);
- of_dma_configure(&core->dev, node);
+ of_dma_configure(&core->dev, node, false);
}
unsigned int bcma_core_irq(struct bcma_device *core, int num)
diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
index 000c7019..d64edeb 100644
--- a/drivers/dma/qcom/hidma_mgmt.c
+++ b/drivers/dma/qcom/hidma_mgmt.c
@@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct
device_node *np)
}
of_node_get(child);
new_pdev->dev.of_node = child;
- of_dma_configure(&new_pdev->dev, child);
+ of_dma_configure(&new_pdev->dev, child, true);
/*
* It is assumed that calling of_msi_configure is safe on
* platforms with or without MSI support.
diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
index a9ec99d..b39c1e9 100644
--- a/drivers/gpu/host1x/bus.c
+++ b/drivers/gpu/host1x/bus.c
@@ -317,7 +317,7 @@ static int host1x_device_match(struct device *dev, struct
device_driver *drv)
static int host1x_dma_configure(struct device *dev)
{
if (dev->of_node)
- return of_dma_configure(dev, dev->of_node);
+ return of_dma_configure(dev, dev->of_node, true);
return 0;
}
@@ -335,7 +335,6 @@ struct bus_type host1x_bus_type = {
.match = host1x_device_match,
.dma_configure = host1x_dma_configure,
.pm = &host1x_device_pm_ops,
- .force_dma = true,
};
static void __host1x_device_del(struct host1x_device *device)
@@ -424,7 +423,7 @@ static int host1x_device_add(struct host1x *host1x,
device->dev.bus = &host1x_bus_type;
device->dev.parent = host1x->dev;
- of_dma_configure(&device->dev, host1x->dev->of_node);
+ of_dma_configure(&device->dev, host1x->dev->of_node, true);
err = host1x_device_parse_dt(device, driver);
if (err < 0) {
diff --git a/drivers/of/device.c b/drivers/of/device.c
index 064c818..33d8551 100644
--- a/drivers/of/device.c
+++ b/drivers/of/device.c
@@ -76,6 +76,8 @@ int of_device_add(struct platform_device *ofdev)
* of_dma_configure - Setup DMA configuration
* @dev: Device to apply DMA configuration
* @np:Pointer to OF node having DMA configuration
+ * @force_dma: Whether device is to be set up by of_dma_configure() even if
+ * DMA capability is not e
[PATCH v4 1/2] dma-mapping: move dma configuration to bus infrastructure
It is bus specific aspect to map a given device on the bus and
relevant firmware description of its DMA configuration.
So, this change introduces 'dma_configure' as bus callback
giving flexibility to busses for implementing its own dma
configuration function.
The change eases the addition of new busses w.r.t. adding the dma
configuration functionality.
This patch also updates the PCI, Platform, ACPI and host1x bus to
use new introduced callbacks.
Suggested-by: Christoph Hellwig
Signed-off-by: Nipun Gupta
Reviewed-by: Greg Kroah-Hartman
Acked-by: Bjorn Helgaas # PCI parts
---
- The patches are based on the comments on:
https://patchwork.kernel.org/patch/10259087/
Changes in v2:
- Do not have dma_deconfigure callback
- Have '/dma_common_configure/' API to provide a common DMA
configuration which can be used by busses if it suits them.
- Platform and ACPI bus to use '/dma_common_configure/' in
'/dma_configure/' callback.
- Updated commit message
- Updated pci_dma_configure API with changes suggested by Robin
Changes in v3:
- Move dma_common_configure() within platform_dma_configure() and
reuse platofrm_dma_configure() for AMBA bus too
- Declare 'attr' in pci_dma_configure() inside the else statement
where it is used.
Changes in v4:
- Rebased on top of 4.17-rc2
drivers/amba/bus.c | 4
drivers/base/dma-mapping.c | 31 ---
drivers/base/platform.c | 17 +
drivers/gpu/host1x/bus.c| 8
drivers/pci/pci-driver.c| 32
include/linux/device.h | 4
include/linux/platform_device.h | 2 ++
7 files changed, 71 insertions(+), 27 deletions(-)
diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
index 594c228..867dc2b 100644
--- a/drivers/amba/bus.c
+++ b/drivers/amba/bus.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
@@ -188,12 +189,15 @@ static int amba_pm_runtime_resume(struct device *dev)
/*
* Primecells are part of the Advanced Microcontroller Bus Architecture,
* so we call the bus "amba".
+ * DMA configuration for platform and AMBA bus is same. So here we reuse
+ * platform's DMA config routine.
*/
struct bus_type amba_bustype = {
.name = "amba",
.dev_groups = amba_dev_groups,
.match = amba_match,
.uevent = amba_uevent,
+ .dma_configure = platform_dma_configure,
.pm = &amba_pm,
.force_dma = true,
};
diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
index d82566d..f831a58 100644
--- a/drivers/base/dma-mapping.c
+++ b/drivers/base/dma-mapping.c
@@ -329,36 +329,13 @@ void dma_common_free_remap(void *cpu_addr, size_t size,
unsigned long vm_flags)
#endif
/*
- * Common configuration to enable DMA API use for a device
+ * enables DMA API use for a device
*/
-#include
-
int dma_configure(struct device *dev)
{
- struct device *bridge = NULL, *dma_dev = dev;
- enum dev_dma_attr attr;
- int ret = 0;
-
- if (dev_is_pci(dev)) {
- bridge = pci_get_host_bridge_device(to_pci_dev(dev));
- dma_dev = bridge;
- if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
- dma_dev->parent->of_node)
- dma_dev = dma_dev->parent;
- }
-
- if (dma_dev->of_node) {
- ret = of_dma_configure(dev, dma_dev->of_node);
- } else if (has_acpi_companion(dma_dev)) {
- attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
- if (attr != DEV_DMA_NOT_SUPPORTED)
- ret = acpi_dma_configure(dev, attr);
- }
-
- if (bridge)
- pci_put_host_bridge_device(bridge);
-
- return ret;
+ if (dev->bus->dma_configure)
+ return dev->bus->dma_configure(dev);
+ return 0;
}
void dma_deconfigure(struct device *dev)
diff --git a/drivers/base/platform.c b/drivers/base/platform.c
index 8075ddc..638d42e 100644
--- a/drivers/base/platform.c
+++ b/drivers/base/platform.c
@@ -1130,6 +1130,22 @@ int platform_pm_restore(struct device *dev)
#endif /* CONFIG_HIBERNATE_CALLBACKS */
+int platform_dma_configure(struct device *dev)
+{
+ enum dev_dma_attr attr;
+ int ret = 0;
+
+ if (dev->of_node) {
+ ret = of_dma_configure(dev, dev->of_node);
+ } else if (has_acpi_companion(dev)) {
+ attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
+ if (attr != DEV_DMA_NOT_SUPPORTED)
+ ret = acpi_dma_configure(dev, attr);
+ }
+
+ return ret;
+}
+
static const struct dev_pm_ops platform_dev_pm_ops = {
.runtime_suspend = pm_generic_runtime_suspend,
.runtime_resume = pm_generic_runtime_resume,
@@ -1141,6 +1157,7 @@ struct bus_type platform_bus_type = {
.dev_groups
[PATCH] nl80211: Reject disconnect commands except from conn_owner
Reject NL80211_CMD_DISCONNECT, NL80211_CMD_DISASSOCIATE, NL80211_CMD_DEAUTHENTICATE and NL80211_CMD_ASSOCIATE commands from clients other than the connection owner set in the connect, authenticate or associate commands, if it was set. The main point of this check is to prevent chaos when two processes try to use nl80211 at the same time, it's not a security measure. The same thing should possibly be done for JOIN_IBSS/LEAVE_IBSS and START_AP/STOP_AP. --- net/wireless/nl80211.c | 16 1 file changed, 16 insertions(+) diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c index a910150f81..92ddc7d88f 100644 --- a/net/wireless/nl80211.c +++ b/net/wireless/nl80211.c @@ -8303,6 +8303,10 @@ static int nl80211_associate(struct sk_buff *skb, struct genl_info *info) const u8 *bssid, *ssid; int err, ssid_len = 0; + if (dev->ieee80211_ptr->conn_owner_nlportid && + dev->ieee80211_ptr->conn_owner_nlportid != info->snd_portid) + return -EPERM; + if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE])) return -EINVAL; @@ -8425,6 +8429,10 @@ static int nl80211_deauthenticate(struct sk_buff *skb, struct genl_info *info) u16 reason_code; bool local_state_change; + if (dev->ieee80211_ptr->conn_owner_nlportid && + dev->ieee80211_ptr->conn_owner_nlportid != info->snd_portid) + return -EPERM; + if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE])) return -EINVAL; @@ -8472,6 +8480,10 @@ static int nl80211_disassociate(struct sk_buff *skb, struct genl_info *info) u16 reason_code; bool local_state_change; + if (dev->ieee80211_ptr->conn_owner_nlportid && + dev->ieee80211_ptr->conn_owner_nlportid != info->snd_portid) + return -EPERM; + if (!is_valid_ie_attr(info->attrs[NL80211_ATTR_IE])) return -EINVAL; @@ -9234,6 +9246,10 @@ static int nl80211_disconnect(struct sk_buff *skb, struct genl_info *info) u16 reason; int ret; + if (dev->ieee80211_ptr->conn_owner_nlportid && + dev->ieee80211_ptr->conn_owner_nlportid != info->snd_portid) + return -EPERM; + if (!info->attrs[NL80211_ATTR_REASON_CODE]) reason = WLAN_REASON_DEAUTH_LEAVING; else -- 2.14.1
[PATCH v4] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter
From: Sebastian Gottschall
current handling of peer_bw_rxnss_override parameter is based on guessing the
VHT160/8080 capability by rx rate. this is wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is required since
VHT160 operation mode only supports 2x2 chainmasks in addition the original code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the parameter by
minimum nss which is suggested by QCA as temporary workaround according
to the QCA sourcecodes.
Signed-off-by: Sebastian Gottschall
v2: remove debug messages
v3: apply some cosmetics, update documentation
v4: fix compile warning and truncate nss to maximum of 2x2 since current
chipsets only support 2x2 at vht160
---
drivers/net/wireless/ath/ath10k/mac.c | 44 ++-
drivers/net/wireless/ath/ath10k/wmi.c | 7 +
drivers/net/wireless/ath/ath10k/wmi.h | 14 -
3 files changed, 43 insertions(+), 22 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..de8a099c9f5a 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2528,23 +2528,37 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
__le16_to_cpu(vht_cap->vht_mcs.tx_highest);
arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
+ arg->peer_bw_rxnss_override = 0;
+
+ if (arg->peer_num_spatial_streams) {
+ int nss160 = arg->peer_num_spatial_streams;
+ /* truncate vht160 nss value to 2x2 since all known chipsets do
not support more than 2x2 in vht160 modes */
+ if (nss160 > 2)
+ nss160 = 2;
+ /* in case if peer is connected with vht160 or vht80+80, we
need to properly adjust rxnss parameters */
+ switch(arg->peer_phymode) {
+ case MODE_11AC_VHT80_80:
+ arg->peer_bw_rxnss_override =
BW_NSS_FWCONF_80_80(nss160);
+ /* fall through */
+ case MODE_11AC_VHT160:
+ arg->peer_bw_rxnss_override |=
BW_NSS_FWCONF_160(nss160);
+ break;
+ default:
+ break;
+ }
+ }
- ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags
0x%x\n",
- sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+ /* in case peer has no nss properties for some reasons, we set local
nss to minimum (1x1) to avoid a
+* firmware assert / crash. this applies only to VHT160 or VHT80+80 and
is a WAR for clients breaking
+* the spec.
+*/
- if (arg->peer_vht_rates.rx_max_rate &&
- (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
- switch (arg->peer_vht_rates.rx_max_rate) {
- case 1560:
- /* Must be 2x2 at 160Mhz is all it can do. */
- arg->peer_bw_rxnss_override = 2;
- break;
- case 780:
- /* Can only do 1x1 at 160Mhz (Long Guard Interval) */
- arg->peer_bw_rxnss_override = 1;
- break;
- }
+ if (!arg->peer_num_spatial_streams && (arg->peer_phymode ==
MODE_11AC_VHT80_80 || arg->peer_phymode == MODE_11AC_VHT160)) {
+ arg->peer_bw_rxnss_override = BW_NSS_FWCONF_MAP_ENABLE;
}
+
+ ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags
0x%x\n",
+ sta->addr, arg->peer_max_mpdu, arg->peer_flags);
}
static void ath10k_peer_assoc_h_qos(struct ath10k *ar,
@@ -2696,9 +2710,9 @@ static int ath10k_peer_assoc_prepare(struct ath10k *ar,
ath10k_peer_assoc_h_crypto(ar, vif, sta, arg);
ath10k_peer_assoc_h_rates(ar, vif, sta, arg);
ath10k_peer_assoc_h_ht(ar, vif, sta, arg);
+ ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
ath10k_peer_assoc_h_qos(ar, vif, sta, arg);
- ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
return 0;
}
diff --git a/drivers/net/wireless/ath/ath10k/wmi.c
b/drivers/net/wireless/ath/ath10k/wmi.c
index 2c36256a441d..3797dca317ff 100644
--- a/drivers/net/wireless/ath/ath10k/wmi.c
+++ b/drivers/net/wireless/ath/ath10k/wmi.c
@@ -7211,12 +7211,7 @@ ath10k_wmi_peer_assoc_fill_10_4(struct ath10k *ar, void
*buf,
struct wmi_10_4_peer_assoc_complete_cmd *cmd = buf;
ath10k_wmi_peer_assoc_fill_10_2(ar, buf, arg);
- if (arg->peer_bw_rxnss_override)
- cmd->peer_bw_rxnss_override =
- __cpu_to_le32((arg->peer_bw_rxnss_overri
Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter
I did some testing with the patch below.
i mean you tested your own patch here but i dont see results for mine.
i tested my patch in the same way, just not on firmware side
but i logged the values for rxnss_override and the looked correct all
the time
The CHAIMASK_ERR is a debug log from FW that I added to help make sure
the patch is
acting as desired. The first hex is an identifier, second is the
value passed in,
third is phymode, 4th is the tx-chain-mask for 160Mhz frames.
On station side, when associating a 4x4 9984 station to 9984
configured for nss4, 160Mhz, I see:
[86376.620303] ath10k_pci :04:00.0: NIC rx-max-rate: 1560
calculated-max: 1560 rxnss_override: 0x8009 nss160: 2
spatial-streams: 4
ath10k-fw: ts: 15229 args: 4 RATE_CTRL(19) vid: 255
CHAINMASK_ERR(03) 0x00af 0x8009 0x000f 0x0003
On station side, when associating a 4x4 9984 station with chain-mask
of 0x3 (2x2) to 9984 configured for nss4, 160Mhz, I see:
[86147.569319] ath10k_pci :04:00.0: NIC rx-max-rate: 1560
calculated-max: 780 rxnss_override: 0x8000 nss160: 1
spatial-streams: 2
ath10k-fw: ts: 6807 args: 4 RATE_CTRL(19) vid: 255 CHAINMASK_ERR(03)
0x00af 0x8000 0x000f 0x0001
On AP side, when associating a 4x4 9984 station to 9984 configured for
160Mhz, I see:
[11167.635324] ath10k_pci :04:00.0: NIC rx-max-rate: 1560
calculated-max: 1560 rxnss_override: 0x8009 nss160: 2
spatial-streams: 4
ath10k-fw: ts: 72917 args: 4 RATE_CTRL(19) vid: 255
CHAINMASK_ERR(03) 0x00af 0x8009 0x000f 0x0003
On AP side, when associating a 4x4 9984 station with chain-mask of 0x3
(2x2) to 9984 configured for nss4, 160Mhz, I see:
[11422.887181] ath10k_pci :04:00.0: NIC rx-max-rate: 1560
calculated-max: 780 rxnss_override: 0x8000 nss160: 1
spatial-streams: 2
ath10k-fw: ts: 334266 args: 4 RATE_CTRL(19) vid: 255
CHAINMASK_ERR(03) 0x00af 0x8000 0x000f 0x0001
On AP side, when associating a 4x4 9984 station configured for 80Mhz
instead of 160,
then logging from firmware indicates full 4x4 rates are supported for
80Mhz and below,
and the rxnss_override does not have the (1<<31) bit set:
ath10k-fw: ts: 519211 args: 4 RATE_CTRL(19) vid: 255
CHAINMASK_ERR(03) 0x00af 0x 0x000a 0x0001
So, I think this might be a better fix for this problem (included
inline for discussion,
probably white-space damaged by email client:
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index e1ad983..8bce916 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2860,18 +2860,39 @@ static void ath10k_peer_assoc_h_vht(struct
ath10k *ar,
arg->peer_vht_rates.rx_max_rate,
arg->peer_vht_rates.rx_mcs_set,
arg->peer_vht_rates.tx_max_rate,
arg->peer_vht_rates.tx_mcs_set);
- if (arg->peer_vht_rates.rx_max_rate &&
- (sta->vht_cap.cap & IEEE80211_VHT_CAP_SUPP_CHAN_WIDTH_MASK)) {
- switch (arg->peer_vht_rates.rx_max_rate) {
+ if (arg->peer_phymode == MODE_11AC_VHT80_80 ||
+ arg->peer_phymode == MODE_11AC_VHT160) {
+ int nss160;
+ int rx = arg->peer_vht_rates.rx_max_rate;
+ /* Deal with cases where chainmask has been decreased.
+ * All known chips that support 160Mhz can do only 1/2 of
+ * the available chains at 160Mhz.
+ */
+ rx = min((int)(arg->peer_num_spatial_streams * 390), rx);
+
+ switch (rx) {
+ /* When a NIC shows up that can do 4x4 at 160Mhz, its
+ * max-rate should be higher, and we can set nss160
+ * to 4 here.
+ */
case 1560:
/* Must be 2x2 at 160Mhz is all it can do. */
- arg->peer_bw_rxnss_override = 2;
+ nss160 = 2;
break;
- case 780:
- /* Can only do 1x1 at 160Mhz (Long Guard Interval) */
- arg->peer_bw_rxnss_override = 1;
+ default:
+ /* Assume we can only do 1x1 at 160Mhz */
+ nss160 = 1;
break;
}
+
+ arg->peer_bw_rxnss_override = ((nss160 - 1) | /* 160Mhz nss */
+ ((nss160 - 1) << 3) | /* 80+80 nss */
+ BIT(PEER_BW_RXNSS_OVERRIDE_OFFSET));
+
+ ath10k_warn(ar, "NIC rx-max-rate: %d calculated-max: %d
rxnss_override: 0x%x nss160: %d spatial-streams: %d\n",
+ arg->peer_vht_rates.rx_max_rate, rx,
+ arg->peer_bw_rxnss_override, nss160,
+ arg->peer_num_spatial_streams);
}
}
@@ -3115,9 +3136,9 @@ static int ath10k_peer_assoc_prepare(struct
ath10k *ar,
ath10k_peer_assoc_h_crypto(ar, vif, sta, arg);
ath10k_peer_assoc_h_rates(ar, vif, sta, arg);
ath10k_peer_assoc_h_ht(ar, vif, sta, arg);
+ ath10k_peer_assoc_h_phymode(ar, vif, sta, arg);
ath10k_peer_assoc_h_vht(ar, vif, sta, arg);
ath10k_p
Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter
Am 27.04.2018 um 23:57 schrieb Ben Greear:
On 04/27/2018 11:54 AM, Sebastian Gottschall wrote:
Am 27.04.2018 um 18:07 schrieb Ben Greear:
On 04/26/2018 09:40 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 22:35 schrieb Ben Greear:
On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 17:30 schrieb Ben Greear:
On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:
From: Sebastian Gottschall
current handling of peer_bw_rxnss_override parameter is based
on guessing the VHT160/8080 capability by rx rate. this is
wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is
required since VHT160 operation mode only supports 2x2
chainmasks in addition the original
code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for
correct initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the
parameter by minimum nss which is suggested by QCA as temporary
workaround according
to the QCA sourcecodes.
Signed-off-by: Sebastian Gottschall
v2: remove debug messages
---
drivers/net/wireless/ath/ath10k/mac.c | 36
+++
drivers/net/wireless/ath/ath10k/wmi.c | 4 +---
drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
3 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void
ath10k_peer_assoc_h_vht(struct ath10k *ar,
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
arg->peer_flags |= ar->wmi.peer_flags->bw80;
- if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+ if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
arg->peer_flags |= ar->wmi.peer_flags->bw160;
+ }
/* Calculate peer NSS capability from VHT capabilities if STA
* supports VHT.
@@ -2529,22 +2530,25 @@ static void
ath10k_peer_assoc_h_vht(struct ath10k *ar,
arg->peer_vht_rates.tx_mcs_set =
ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
- ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu
%d flags 0x%x\n",
- sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+ if (arg->peer_num_spatial_streams && (arg->peer_phymode ==
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+ arg->peer_bw_rxnss_override =
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);
+ }
So, an 80Mhz peer could be 4x4 and could connect to a VHT-160
AP. From what I can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case,
but if peer is VHT-160,
then of course it can only talk at 2x2.
So, I don't think you can just look at the
peer_num_spatial_streams here.
no? rxnss_override is only taked if peer phymode is vht160 or
vht80_80. vht80 is not considered in that code PEER phy_mode, not
HOST phy_mode
this parameter is a assoc per peer parameter as far as i can say
here.
consider that the firmware will accept anything except 0 for
peer_bw_rxnss_override in vht160 operation mode
if a peer is 80 mhz, the code will be skipped here.
From what I can tell, this feature is supposed to configure the
rate-ctrl in the firmware to know that
it can only send 1x1 or 2x2 when sending at 160Mhz, but that it
can send at higher NSS if it sends
at 80Mhz or lower.
right. but thats exactly what it should does in case that a peer is
connecting with vht160 / 80_80
and the peer itself does also send his own nss capabilities which
is used if available. if not ,it uses the fallback.
If a 2x2 peer connects to the AP, will it have
peer_num_spatial_streams set to 2?
yes. i had some debug code in my initial early versions. the peer
does transmit his own nss capabilities.
If so,
then your code will configure the peer_bw_rxnss_override to
indicate it can send at 160Mhz
2x2 as well, right? And if so, then that is incorrect.
no. since nss_override is only set if peer phymode is 160 mhz as well
The peer can run at 2x2 80Mhz and 1x1 160Mhz at the same time, so it
can advertise
2x2 nss and phy-mode of 160Mhz when associating to the 160Mhz AP,
but the peer can only do 1x1 at 160Mhz. There
is no standard way I know of for the peer to tell you specifically
that it can only do
1x1 at 160Mhz and also 2x2 at 80Mhz in this case.
per specification the peer is able to provide max nss to the ap. the
rx_nss property is calculated
from the mcs rateset provided by the peer by mac80211. this is mcs
set provided on on assoc is mandatory.
so there is a way the peer can tell you what it supports and this is
what is used.
if a peer does not provide the mcs rateset (which i have seen for a
single marvell client)
the fallback mechanism will still work, but just with 1x1. the
problem is anything else will crash the
Re: [PATCH v3 00/19] rtlwifi: halmac: Add new module halmac
On Fri, Apr 27, 2018 at 05:44:16AM +, Pkshih wrote: > > The registers reside in driver causes error frequently, because MAC register > is maintained by Realtek's MAC team so they create this module to avoid > mistakes. > Another benefit is to make it possible to become a thin driver, because many > common functions are provided, so duplicate code will be reduced. How is it possible to create a thin driver by adding lots more code and layers of indirection ??? and writing it in a way that it won't compile without the code for every type of bus interface even though most modules only use one ? It's a horrible pile of garbage slapped together by an inexperienced programmer. Its a major deterrent for anyone looking at working on one of the latest realtek drivers.
Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter
On 04/27/2018 11:54 AM, Sebastian Gottschall wrote:
Am 27.04.2018 um 18:07 schrieb Ben Greear:
On 04/26/2018 09:40 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 22:35 schrieb Ben Greear:
On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 17:30 schrieb Ben Greear:
On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:
From: Sebastian Gottschall
current handling of peer_bw_rxnss_override parameter is based on guessing the
VHT160/8080 capability by rx rate. this is wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is required since
VHT160 operation mode only supports 2x2 chainmasks in addition the original
code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the parameter by
minimum nss which is suggested by QCA as temporary workaround according
to the QCA sourcecodes.
Signed-off-by: Sebastian Gottschall
v2: remove debug messages
---
drivers/net/wireless/ath/ath10k/mac.c | 36 +++
drivers/net/wireless/ath/ath10k/wmi.c | 4 +---
drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
3 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
arg->peer_flags |= ar->wmi.peer_flags->bw80;
-if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
arg->peer_flags |= ar->wmi.peer_flags->bw160;
+}
/* Calculate peer NSS capability from VHT capabilities if STA
* supports VHT.
@@ -2529,22 +2530,25 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
-ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 0x%x\n",
- sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+if (arg->peer_num_spatial_streams && (arg->peer_phymode == MODE_11AC_VHT160
|| arg->peer_phymode == MODE_11AC_VHT80_80)) {
+arg->peer_bw_rxnss_override =
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);
+}
So, an 80Mhz peer could be 4x4 and could connect to a VHT-160 AP. From what I
can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case, but if peer is
VHT-160,
then of course it can only talk at 2x2.
So, I don't think you can just look at the peer_num_spatial_streams here.
no? rxnss_override is only taked if peer phymode is vht160 or vht80_80. vht80
is not considered in that code PEER phy_mode, not HOST phy_mode
this parameter is a assoc per peer parameter as far as i can say here.
consider that the firmware will accept anything except 0 for
peer_bw_rxnss_override in vht160 operation mode
if a peer is 80 mhz, the code will be skipped here.
From what I can tell, this feature is supposed to configure the rate-ctrl in
the firmware to know that
it can only send 1x1 or 2x2 when sending at 160Mhz, but that it can send at
higher NSS if it sends
at 80Mhz or lower.
right. but thats exactly what it should does in case that a peer is connecting
with vht160 / 80_80
and the peer itself does also send his own nss capabilities which is used if
available. if not ,it uses the fallback.
If a 2x2 peer connects to the AP, will it have peer_num_spatial_streams set to
2?
yes. i had some debug code in my initial early versions. the peer does transmit
his own nss capabilities.
If so,
then your code will configure the peer_bw_rxnss_override to indicate it can
send at 160Mhz
2x2 as well, right? And if so, then that is incorrect.
no. since nss_override is only set if peer phymode is 160 mhz as well
The peer can run at 2x2 80Mhz and 1x1 160Mhz at the same time, so it can
advertise
2x2 nss and phy-mode of 160Mhz when associating to the 160Mhz AP, but the peer
can only do 1x1 at 160Mhz. There
is no standard way I know of for the peer to tell you specifically that it can
only do
1x1 at 160Mhz and also 2x2 at 80Mhz in this case.
per specification the peer is able to provide max nss to the ap. the rx_nss
property is calculated
from the mcs rateset provided by the peer by mac80211. this is mcs set provided
on on assoc is mandatory.
so there is a way the peer can tell you what it supports and this is what is
used.
if a peer does not provide the mcs rateset (which i have seen for a single
marvell client)
the fallback mechanism will still work, but just with 1x1. the problem is
anything else will crash the firmware.
we have to deal with that.
That is why this
Re: wil6210: low level sector API
Thanks so much for your information. I tried to use this command and set "triggers" and "long_term_enable" to 0. Actually, in the definition of the triggers, there is no 0x00 but it could be set. After calling this WMI command, it returned 0 which looks like correct. But when I checked the station bf info, it still changed. I am wondering whether I can do anything to verify that. Thank you. Regards, David On Sun, Apr 22, 2018 at 10:29 AM, Dedy Lansky wrote: > >> From: linux-wireless-ow...@vger.kernel.org >> [mailto:linux-wireless-ow...@vger.kernel.org] On Behalf Of David Dean Zhang >> Sent: Wednesday, April 18, 2018 9:01 PM > >> I updated the firmware and tried to call some low level functions, like >> WMI_PRIO_TX_SECTORS_NUMBER_CMDID and WMI_SET_RF_SECTOR_ON_CMDID . >> The previous errors have gone but it still has errors: >> wil6210 :03:00.0 wlp3s0: wmi_event_handle: Unhandled event 0x19a5 >> wil6210 :03:00.0 wlp3s0: wmi_call: wmi_call(0x09a6->0x19a6) timeout 2000 >> msec >> So I am wondering whether it is because the chipset does not support these >> wmi commands. I just want to know how to use these commands and how to >> disable TXSS. I appreciate if anyone could provide some suggestions. Thanks. > > This is a bug in FW that upon WMI_PRIO_TX_SECTORS_NUMBER_CMDID, wrong event > is returned. Most likely that the WMI_PRIO_TX_SECTORS_NUMBER_CMDID was > handled successfully. The bug is not critical - event 0x19a5 is returned > instead of 0x19a6 (as can be seen in dmesg). > > Another option for disabling TXSS/BRP and hopefully to keep the sector locked > is by using WMI_BF_CONTROL_CMDID. Setting "triggers" and "long_term_enable" > to 0 should disable BF completely. > > Thanks, > Dedy. > > > >
[PATCH] mesh: don't process mesh channel switch unless csa ie provided
From: Peter Oh There is no meaning to call ieee80211_mesh_process_chnswitch without CSA IE provided, since the function will always return error. Signed-off-by: Peter Oh --- net/mac80211/mesh.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/net/mac80211/mesh.c b/net/mac80211/mesh.c index d51da26e9c18..8ced757dff8d 100644 --- a/net/mac80211/mesh.c +++ b/net/mac80211/mesh.c @@ -1196,7 +1196,7 @@ static void ieee80211_mesh_rx_bcn_presp(struct ieee80211_sub_if_data *sdata, stype, mgmt, &elems, rx_status); if (ifmsh->csa_role != IEEE80211_MESH_CSA_ROLE_INIT && - !sdata->vif.csa_active) + !sdata->vif.csa_active && elems.ch_switch_ie) ieee80211_mesh_process_chnswitch(sdata, &elems, true); } -- 2.11.0 (Apple Git-81)
Re: [PATCH v3] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter
Hi Sebastian,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on ath6kl/ath-next]
[also build test WARNING on v4.17-rc2 next-20180426]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/s-gottschall-dd-wrt-com/ath10k-fix-crash-in-recent-3-5-3-9984-firmware-due-wrong-handling-of-peer_bw_rxnss_override-parameter/20180427-234051
base: https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git ath-next
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All warnings (new ones prefixed by >>):
drivers/net/wireless/ath/ath10k/mac.c: In function 'ath10k_peer_assoc_h_vht':
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11A' not handled in switch [-Wswitch]
switch(arg->peer_phymode) {
^~
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11G' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11B' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11GONLY' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11NA_HT20' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11NG_HT20' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11NA_HT40' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11NG_HT40' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11AC_VHT20' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11AC_VHT40' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11AC_VHT80' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11AC_VHT20_2G' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11AC_VHT40_2G' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_11AC_VHT80_2G' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_UNKNOWN' not handled in switch [-Wswitch]
>> drivers/net/wireless/ath/ath10k/mac.c:2534:3: warning: enumeration value
>> 'MODE_MAX' not handled in switch [-Wswitch]
vim +/MODE_11A +2534 drivers/net/wireless/ath/ath10k/mac.c
2457
2458 static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
2459 struct ieee80211_vif *vif,
2460 struct ieee80211_sta *sta,
2461 struct wmi_peer_assoc_complete_arg
*arg)
2462 {
2463 const struct ieee80211_sta_vht_cap *vht_cap = &sta->vht_cap;
2464 struct ath10k_vif *arvif = (void *)vif->drv_priv;
2465 struct cfg80211_chan_def def;
2466 enum nl80211_band band;
2467 const u16 *vht_mcs_mask;
2468 u8 ampdu_factor;
2469 u8 max_nss, vht_mcs;
2470 int i;
2471
2472 if (WARN_ON(ath10k_mac_vif_chan(vif, &def)))
2473 return;
2474
2475 if (!vht_cap->vht_supported)
2476 return;
2477
2478 band = def.chan->band;
2479 vht_mcs_mask = arvif->bitrate_mask.control[band].vht_mcs;
2480
2481 if (ath10k_peer_assoc_h_vht_masked(vht_mcs_mask))
2482 return;
2483
2484 arg->peer_flags |= ar->wmi.peer_flags->vht;
2485
2486 if (def.chan->band == NL80211_BAND_2GHZ)
2487 arg->peer_flags |= ar->wmi.peer_flags->vht_2g;
2488
2489 arg->peer_vht_caps = vht_cap->cap;
2490
2491 ampdu_factor = (vht_cap->cap &
2492
IEEE80211_VHT_CAP_MAX_A_MPDU_LENGTH_EXPONENT_MASK) >>
2493
IEEE80211_VH
Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter
Am 27.04.2018 um 18:07 schrieb Ben Greear:
On 04/26/2018 09:40 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 22:35 schrieb Ben Greear:
On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 17:30 schrieb Ben Greear:
On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:
From: Sebastian Gottschall
current handling of peer_bw_rxnss_override parameter is based on
guessing the VHT160/8080 capability by rx rate. this is wrong and
may lead
to a non initialized peer_bw_rxnss_override parameter which is
required since VHT160 operation mode only supports 2x2 chainmasks
in addition the original code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for
correct initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the
parameter by minimum nss which is suggested by QCA as temporary
workaround according
to the QCA sourcecodes.
Signed-off-by: Sebastian Gottschall
v2: remove debug messages
---
drivers/net/wireless/ath/ath10k/mac.c | 36
+++
drivers/net/wireless/ath/ath10k/wmi.c | 4 +---
drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
3 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct
ath10k *ar,
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
arg->peer_flags |= ar->wmi.peer_flags->bw80;
- if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+ if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
arg->peer_flags |= ar->wmi.peer_flags->bw160;
+ }
/* Calculate peer NSS capability from VHT capabilities if STA
* supports VHT.
@@ -2529,22 +2530,25 @@ static void
ath10k_peer_assoc_h_vht(struct ath10k *ar,
arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
- ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d
flags 0x%x\n",
- sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+ if (arg->peer_num_spatial_streams && (arg->peer_phymode ==
MODE_11AC_VHT160 || arg->peer_phymode == MODE_11AC_VHT80_80)) {
+ arg->peer_bw_rxnss_override =
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);
+ }
So, an 80Mhz peer could be 4x4 and could connect to a VHT-160 AP.
From what I can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case, but
if peer is VHT-160,
then of course it can only talk at 2x2.
So, I don't think you can just look at the
peer_num_spatial_streams here.
no? rxnss_override is only taked if peer phymode is vht160 or
vht80_80. vht80 is not considered in that code PEER phy_mode, not
HOST phy_mode
this parameter is a assoc per peer parameter as far as i can say here.
consider that the firmware will accept anything except 0 for
peer_bw_rxnss_override in vht160 operation mode
if a peer is 80 mhz, the code will be skipped here.
From what I can tell, this feature is supposed to configure the
rate-ctrl in the firmware to know that
it can only send 1x1 or 2x2 when sending at 160Mhz, but that it can
send at higher NSS if it sends
at 80Mhz or lower.
right. but thats exactly what it should does in case that a peer is
connecting with vht160 / 80_80
and the peer itself does also send his own nss capabilities which is
used if available. if not ,it uses the fallback.
If a 2x2 peer connects to the AP, will it have
peer_num_spatial_streams set to 2?
yes. i had some debug code in my initial early versions. the peer
does transmit his own nss capabilities.
If so,
then your code will configure the peer_bw_rxnss_override to indicate
it can send at 160Mhz
2x2 as well, right? And if so, then that is incorrect.
no. since nss_override is only set if peer phymode is 160 mhz as well
The peer can run at 2x2 80Mhz and 1x1 160Mhz at the same time, so it
can advertise
2x2 nss and phy-mode of 160Mhz when associating to the 160Mhz AP, but
the peer can only do 1x1 at 160Mhz. There
is no standard way I know of for the peer to tell you specifically
that it can only do
1x1 at 160Mhz and also 2x2 at 80Mhz in this case.
per specification the peer is able to provide max nss to the ap. the
rx_nss property is calculated
from the mcs rateset provided by the peer by mac80211. this is mcs set
provided on on assoc is mandatory.
so there is a way the peer can tell you what it supports and this is
what is used.
if a peer does not provide the mcs rateset (which i have seen for a
single marvell client)
the fallback mechanism will still work, but just with 1x1. the problem
is anything else will crash the firmware.
we have to deal with that.
That is why this rxnns_override exists, to hack a
Re: pull-request: wireless-drivers 2018-04-26
From: Kalle Valo Date: Thu, 26 Apr 2018 13:12:54 +0300 > here's a pull request to net tree, more info below. Please let me know > if you have any problems. Pulled, thanks Kalle.
Re: [PATCH] ath6kl: use WMI to set RSN capabilities
On Fri, Apr 27, 2018 at 9:57 AM Alfonso Sanchez-Beato <
alfonso.sanchez-be...@canonical.com> wrote:
> Hi Steve,
> On Fri, Apr 27, 2018 at 5:47 PM, Steve deRosier
wrote:
> > Hi Alfonso,
> >
> > On Thu, Apr 12, 2018 at 8:42 AM Alfonso Sánchez-Beato <
> > alfonso.sanchez-be...@canonical.com> wrote:
> >
> >> This fixes AP mode when the ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE flag
> >> is not present in the FW. The id of some WMI commands is also fixed
> >> (there was an error in the enum order), and a function to set RSN caps
> >> is added.
> >
> >> Signed-off-by: Alfonso Sánchez-Beato <
alfonso.sanchez-be...@canonical.com>
> >> ---
> >> drivers/net/wireless/ath/ath6kl/cfg80211.c | 21 ++---
> >> drivers/net/wireless/ath/ath6kl/main.c | 10 +++---
> >> drivers/net/wireless/ath/ath6kl/wmi.c | 23
+++
> >> drivers/net/wireless/ath/ath6kl/wmi.h | 15 +++
> >> 4 files changed, 43 insertions(+), 26 deletions(-)
> >
> >> diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
> > b/drivers/net/wireless/ath/ath6kl/cfg80211.c
> >> index 2ba8cf3f38af..1b89c53d47e7 100644
> >> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
> >> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
> >> @@ -2933,13 +2933,11 @@ static int ath6kl_start_ap(struct wiphy *wiphy,
> > struct net_device *dev,
> >> * advertise the same in beacon/probe response. Send
> >> * the complete RSN IE capability field to firmware
> >> */
> >> - if (!ath6kl_get_rsn_capab(&info->beacon, (u8 *) &rsn_capab) &&
> >> - test_bit(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE,
> >> -ar->fw_capabilities)) {
> >> - res = ath6kl_wmi_set_ie_cmd(ar->wmi, vif->fw_vif_idx,
> >> - WLAN_EID_RSN,
WMI_RSN_IE_CAPB,
> >> - (const u8 *) &rsn_capab,
> >> - sizeof(rsn_capab));
> >> + if (!ath6kl_get_rsn_capab(&info->beacon, (u8 *)&rsn_capab)) {
> >> + ath6kl_dbg(ATH6KL_DBG_WLAN_CFG, "RSN caps %d\n",
> > rsn_capab);
> >> +
> >> + res = ath6kl_wmi_set_rsn_cap(ar->wmi, vif->fw_vif_idx,
> >> +rsn_capab);
> >> vif->rsn_capab = rsn_capab;
> >> if (res < 0)
> >> return res;
> >
> > So, let me see if I understand this correctly. Original flow was:
> >
> > 1. get RSN capable from the beacon if one
> > 2. if the firmware is capable of the override, set the IE else don't do
> > anything
> >
> > New flow:
> > 1. get RSN capable from the beacon if one
> > 2. unconditionally send the rsn_cap WMI down
> >
> > So, what happens on a firmware that _does_ have the rsn-cap-override
flag
> > set? I'm guessing nothing good. Admittedly I haven't tried your patch
on
> > my platform.
> >
> > I think that simply ignoring the flag and using a WMI instead of setting
> > the IE on all devices AR6002..AR6004 is likely going to cause problems
for
> > everyone else.
> Admittedly, I have not a wide range of devices to test. This patch was
> mostly an RFC to see if the issue is only for a particular fw revision
> and to expose it for people that might find it useful. Note that I am
> not the first person to hit this, see for instance
> http://www.spinics.net/lists/linux-wireless/msg115085.html
Fair enough. However, breaking it for the rest of the devices out there
isn't good. I welcome the fixing of it, but it has to be done across the
spectrum of the supported chips.
> >
> >
> >> @@ -3918,14 +3916,7 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
> >> return -EINVAL;
> >> }
> >
> >> - /*
> >> -* Even if the fw has HT support, advertise HT cap only when
> >> -* the firmware has support to override RSN capability,
otherwise
> >> -* 4-way handshake would fail.
> >> -*/
> >> - if (!(ht &&
> >> - test_bit(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE,
> >> - ar->fw_capabilities))) {
> >> + if (!ht) {
> >
> > Perhaps the comment isn't relevant if we're using the RSN WMI command
on a
> > device with the flag, but I'm willing to bet you neither tested it nor
that
> > the assumption is true. I'm guessing this change just broke the 4-way
> > handshake for the majority of devices.
> >
> >> ath6kl_band_2ghz.ht_cap.cap = 0;
> >> ath6kl_band_2ghz.ht_cap.ht_supported = false;
> >> ath6kl_band_5ghz.ht_cap.cap = 0;
> >> diff --git a/drivers/net/wireless/ath/ath6kl/main.c
> > b/drivers/net/wireless/ath/ath6kl/main.c
> >> index db95f85751e3..4e186f8b3950 100644
> >> --- a/drivers/net/wireless/ath/ath6kl/main.c
> >> +++ b/drivers/net/wireless/ath/ath6kl/main.c
> >> @@ -579,13 +579,9 @@ static int ath6kl_commit_ch_switch(struct
ath6kl_vif
> > *vif, u16 channel)
> >>
RE: [PATCH v3 1/2] dma-mapping: move dma configuration to bus infrastructure
> -Original Message- > From: Christoph Hellwig [mailto:h...@lst.de] > Sent: Monday, April 23, 2018 6:27 PM > To: Nipun Gupta > Cc: robin.mur...@arm.com; h...@lst.de; li...@armlinux.org.uk; > gre...@linuxfoundation.org; m.szyprow...@samsung.com; > bhelg...@google.com; zaj...@gmail.com; andy.gr...@linaro.org; > david.br...@linaro.org; dan.j.willi...@intel.com; vinod.k...@intel.com; > thierry.red...@gmail.com; robh...@kernel.org; frowand.l...@gmail.com; > jarkko.sakki...@linux.intel.com; rafael.j.wyso...@intel.com; > dmitry.torok...@gmail.com; jo...@kernel.org; msucha...@suse.de; linux- > ker...@vger.kernel.org; io...@lists.linux-foundation.org; linux- > wirel...@vger.kernel.org; linux-arm-...@vger.kernel.org; linux- > s...@vger.kernel.org; dmaeng...@vger.kernel.org; dri- > de...@lists.freedesktop.org; linux-te...@vger.kernel.org; > devicet...@vger.kernel.org; linux-...@vger.kernel.org; Bharat Bhushan > ; Leo Li > Subject: Re: [PATCH v3 1/2] dma-mapping: move dma configuration to bus > infrastructure > > Can you resend your changes against Linux 4.17-rc2? There are a lot > of conflicts as-is. Sure.. I will send it soon.. Regards, Nipun
Re: [PATCH] ath6kl: use WMI to set RSN capabilities
Hi Steve,
On Fri, Apr 27, 2018 at 5:47 PM, Steve deRosier wrote:
> Hi Alfonso,
>
> On Thu, Apr 12, 2018 at 8:42 AM Alfonso Sánchez-Beato <
> alfonso.sanchez-be...@canonical.com> wrote:
>
>> This fixes AP mode when the ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE flag
>> is not present in the FW. The id of some WMI commands is also fixed
>> (there was an error in the enum order), and a function to set RSN caps
>> is added.
>
>> Signed-off-by: Alfonso Sánchez-Beato
>> ---
>> drivers/net/wireless/ath/ath6kl/cfg80211.c | 21 ++---
>> drivers/net/wireless/ath/ath6kl/main.c | 10 +++---
>> drivers/net/wireless/ath/ath6kl/wmi.c | 23 +++
>> drivers/net/wireless/ath/ath6kl/wmi.h | 15 +++
>> 4 files changed, 43 insertions(+), 26 deletions(-)
>
>> diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
> b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> index 2ba8cf3f38af..1b89c53d47e7 100644
>> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
>> @@ -2933,13 +2933,11 @@ static int ath6kl_start_ap(struct wiphy *wiphy,
> struct net_device *dev,
>> * advertise the same in beacon/probe response. Send
>> * the complete RSN IE capability field to firmware
>> */
>> - if (!ath6kl_get_rsn_capab(&info->beacon, (u8 *) &rsn_capab) &&
>> - test_bit(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE,
>> -ar->fw_capabilities)) {
>> - res = ath6kl_wmi_set_ie_cmd(ar->wmi, vif->fw_vif_idx,
>> - WLAN_EID_RSN, WMI_RSN_IE_CAPB,
>> - (const u8 *) &rsn_capab,
>> - sizeof(rsn_capab));
>> + if (!ath6kl_get_rsn_capab(&info->beacon, (u8 *)&rsn_capab)) {
>> + ath6kl_dbg(ATH6KL_DBG_WLAN_CFG, "RSN caps %d\n",
> rsn_capab);
>> +
>> + res = ath6kl_wmi_set_rsn_cap(ar->wmi, vif->fw_vif_idx,
>> +rsn_capab);
>> vif->rsn_capab = rsn_capab;
>> if (res < 0)
>> return res;
>
> So, let me see if I understand this correctly. Original flow was:
>
> 1. get RSN capable from the beacon if one
> 2. if the firmware is capable of the override, set the IE else don't do
> anything
>
> New flow:
> 1. get RSN capable from the beacon if one
> 2. unconditionally send the rsn_cap WMI down
>
> So, what happens on a firmware that _does_ have the rsn-cap-override flag
> set? I'm guessing nothing good. Admittedly I haven't tried your patch on
> my platform.
>
> I think that simply ignoring the flag and using a WMI instead of setting
> the IE on all devices AR6002..AR6004 is likely going to cause problems for
> everyone else.
Admittedly, I have not a wide range of devices to test. This patch was
mostly an RFC to see if the issue is only for a particular fw revision
and to expose it for people that might find it useful. Note that I am
not the first person to hit this, see for instance
http://www.spinics.net/lists/linux-wireless/msg115085.html
>
>
>> @@ -3918,14 +3916,7 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
>> return -EINVAL;
>> }
>
>> - /*
>> -* Even if the fw has HT support, advertise HT cap only when
>> -* the firmware has support to override RSN capability, otherwise
>> -* 4-way handshake would fail.
>> -*/
>> - if (!(ht &&
>> - test_bit(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE,
>> - ar->fw_capabilities))) {
>> + if (!ht) {
>
> Perhaps the comment isn't relevant if we're using the RSN WMI command on a
> device with the flag, but I'm willing to bet you neither tested it nor that
> the assumption is true. I'm guessing this change just broke the 4-way
> handshake for the majority of devices.
>
>> ath6kl_band_2ghz.ht_cap.cap = 0;
>> ath6kl_band_2ghz.ht_cap.ht_supported = false;
>> ath6kl_band_5ghz.ht_cap.cap = 0;
>> diff --git a/drivers/net/wireless/ath/ath6kl/main.c
> b/drivers/net/wireless/ath/ath6kl/main.c
>> index db95f85751e3..4e186f8b3950 100644
>> --- a/drivers/net/wireless/ath/ath6kl/main.c
>> +++ b/drivers/net/wireless/ath/ath6kl/main.c
>> @@ -579,13 +579,9 @@ static int ath6kl_commit_ch_switch(struct ath6kl_vif
> *vif, u16 channel)
>> * reconfigure any saved RSN IE capabilites in the beacon
> /
>> * probe response to stay in sync with the supplicant.
>> */
>> - if (vif->rsn_capab &&
>> - test_bit(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE,
>> -ar->fw_capabilities))
>> - ath6kl_wmi_set_ie_cmd(ar->wmi, vif->fw_vif_idx,
>> - WLAN_EID_RSN,
> WMI_RSN_IE_CAPB,
>> -
Re: [PATCH v2] ath10k: fix crash in recent 3.5.3 9984 firmware due wrong handling of peer_bw_rxnss_override parameter
On 04/26/2018 09:40 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 22:35 schrieb Ben Greear:
On 04/26/2018 01:21 PM, Sebastian Gottschall wrote:
Am 26.04.2018 um 17:30 schrieb Ben Greear:
On 04/26/2018 02:28 AM, s.gottsch...@dd-wrt.com wrote:
From: Sebastian Gottschall
current handling of peer_bw_rxnss_override parameter is based on guessing the
VHT160/8080 capability by rx rate. this is wrong and may lead
to a non initialized peer_bw_rxnss_override parameter which is required since
VHT160 operation mode only supports 2x2 chainmasks in addition the original code
initialized the parameter with wrong masked values.
This patch uses the peer phymode and peer nss information for correct
initialisation of the peer_bw_rxnss_override parameter.
if this peer information is not available, we initialize the parameter by
minimum nss which is suggested by QCA as temporary workaround according
to the QCA sourcecodes.
Signed-off-by: Sebastian Gottschall
v2: remove debug messages
---
drivers/net/wireless/ath/ath10k/mac.c | 36 +++
drivers/net/wireless/ath/ath10k/wmi.c | 4 +---
drivers/net/wireless/ath/ath10k/wmi.h | 14 +-
3 files changed, 34 insertions(+), 20 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c
b/drivers/net/wireless/ath/ath10k/mac.c
index 5be6386ede8f..df79af89ee71 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -2505,8 +2505,9 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
if (sta->bandwidth == IEEE80211_STA_RX_BW_80)
arg->peer_flags |= ar->wmi.peer_flags->bw80;
-if (sta->bandwidth == IEEE80211_STA_RX_BW_160)
+if (sta->bandwidth == IEEE80211_STA_RX_BW_160) {
arg->peer_flags |= ar->wmi.peer_flags->bw160;
+}
/* Calculate peer NSS capability from VHT capabilities if STA
* supports VHT.
@@ -2529,22 +2530,25 @@ static void ath10k_peer_assoc_h_vht(struct ath10k *ar,
arg->peer_vht_rates.tx_mcs_set = ath10k_peer_assoc_h_vht_limit(
__le16_to_cpu(vht_cap->vht_mcs.tx_mcs_map), vht_mcs_mask);
-ath10k_dbg(ar, ATH10K_DBG_MAC, "mac vht peer %pM max_mpdu %d flags 0x%x\n",
- sta->addr, arg->peer_max_mpdu, arg->peer_flags);
+if (arg->peer_num_spatial_streams && (arg->peer_phymode == MODE_11AC_VHT160
|| arg->peer_phymode == MODE_11AC_VHT80_80)) {
+arg->peer_bw_rxnss_override =
BW_NSS_FWCONF_160(arg->peer_num_spatial_streams);
+}
So, an 80Mhz peer could be 4x4 and could connect to a VHT-160 AP. From what I
can tell,
the VHT-160 AP can talk 4x4 @ 80Mhz to the peer in this case, but if peer is
VHT-160,
then of course it can only talk at 2x2.
So, I don't think you can just look at the peer_num_spatial_streams here.
no? rxnss_override is only taked if peer phymode is vht160 or vht80_80. vht80
is not considered in that code PEER phy_mode, not HOST phy_mode
this parameter is a assoc per peer parameter as far as i can say here.
consider that the firmware will accept anything except 0 for
peer_bw_rxnss_override in vht160 operation mode
if a peer is 80 mhz, the code will be skipped here.
From what I can tell, this feature is supposed to configure the rate-ctrl in
the firmware to know that
it can only send 1x1 or 2x2 when sending at 160Mhz, but that it can send at
higher NSS if it sends
at 80Mhz or lower.
right. but thats exactly what it should does in case that a peer is connecting
with vht160 / 80_80
and the peer itself does also send his own nss capabilities which is used if
available. if not ,it uses the fallback.
If a 2x2 peer connects to the AP, will it have peer_num_spatial_streams set to
2?
yes. i had some debug code in my initial early versions. the peer does transmit
his own nss capabilities.
If so,
then your code will configure the peer_bw_rxnss_override to indicate it can
send at 160Mhz
2x2 as well, right? And if so, then that is incorrect.
no. since nss_override is only set if peer phymode is 160 mhz as well
The peer can run at 2x2 80Mhz and 1x1 160Mhz at the same time, so it can
advertise
2x2 nss and phy-mode of 160Mhz when associating to the 160Mhz AP, but the peer
can only do 1x1 at 160Mhz. There
is no standard way I know of for the peer to tell you specifically that it can
only do
1x1 at 160Mhz and also 2x2 at 80Mhz in this case.
That is why this rxnns_override exists, to hack around this problem.
Your patch is going to break in this case as far as I can tell.
Thanks,
Ben
--
Ben Greear
Candela Technologies Inc http://www.candelatech.com
Re: [PATCH] ath6kl: use WMI to set RSN capabilities
Hi Alfonso,
On Thu, Apr 12, 2018 at 8:42 AM Alfonso Sánchez-Beato <
alfonso.sanchez-be...@canonical.com> wrote:
> This fixes AP mode when the ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE flag
> is not present in the FW. The id of some WMI commands is also fixed
> (there was an error in the enum order), and a function to set RSN caps
> is added.
> Signed-off-by: Alfonso Sánchez-Beato
> ---
> drivers/net/wireless/ath/ath6kl/cfg80211.c | 21 ++---
> drivers/net/wireless/ath/ath6kl/main.c | 10 +++---
> drivers/net/wireless/ath/ath6kl/wmi.c | 23 +++
> drivers/net/wireless/ath/ath6kl/wmi.h | 15 +++
> 4 files changed, 43 insertions(+), 26 deletions(-)
> diff --git a/drivers/net/wireless/ath/ath6kl/cfg80211.c
b/drivers/net/wireless/ath/ath6kl/cfg80211.c
> index 2ba8cf3f38af..1b89c53d47e7 100644
> --- a/drivers/net/wireless/ath/ath6kl/cfg80211.c
> +++ b/drivers/net/wireless/ath/ath6kl/cfg80211.c
> @@ -2933,13 +2933,11 @@ static int ath6kl_start_ap(struct wiphy *wiphy,
struct net_device *dev,
> * advertise the same in beacon/probe response. Send
> * the complete RSN IE capability field to firmware
> */
> - if (!ath6kl_get_rsn_capab(&info->beacon, (u8 *) &rsn_capab) &&
> - test_bit(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE,
> -ar->fw_capabilities)) {
> - res = ath6kl_wmi_set_ie_cmd(ar->wmi, vif->fw_vif_idx,
> - WLAN_EID_RSN, WMI_RSN_IE_CAPB,
> - (const u8 *) &rsn_capab,
> - sizeof(rsn_capab));
> + if (!ath6kl_get_rsn_capab(&info->beacon, (u8 *)&rsn_capab)) {
> + ath6kl_dbg(ATH6KL_DBG_WLAN_CFG, "RSN caps %d\n",
rsn_capab);
> +
> + res = ath6kl_wmi_set_rsn_cap(ar->wmi, vif->fw_vif_idx,
> +rsn_capab);
> vif->rsn_capab = rsn_capab;
> if (res < 0)
> return res;
So, let me see if I understand this correctly. Original flow was:
1. get RSN capable from the beacon if one
2. if the firmware is capable of the override, set the IE else don't do
anything
New flow:
1. get RSN capable from the beacon if one
2. unconditionally send the rsn_cap WMI down
So, what happens on a firmware that _does_ have the rsn-cap-override flag
set? I'm guessing nothing good. Admittedly I haven't tried your patch on
my platform.
I think that simply ignoring the flag and using a WMI instead of setting
the IE on all devices AR6002..AR6004 is likely going to cause problems for
everyone else.
> @@ -3918,14 +3916,7 @@ int ath6kl_cfg80211_init(struct ath6kl *ar)
> return -EINVAL;
> }
> - /*
> -* Even if the fw has HT support, advertise HT cap only when
> -* the firmware has support to override RSN capability, otherwise
> -* 4-way handshake would fail.
> -*/
> - if (!(ht &&
> - test_bit(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE,
> - ar->fw_capabilities))) {
> + if (!ht) {
Perhaps the comment isn't relevant if we're using the RSN WMI command on a
device with the flag, but I'm willing to bet you neither tested it nor that
the assumption is true. I'm guessing this change just broke the 4-way
handshake for the majority of devices.
> ath6kl_band_2ghz.ht_cap.cap = 0;
> ath6kl_band_2ghz.ht_cap.ht_supported = false;
> ath6kl_band_5ghz.ht_cap.cap = 0;
> diff --git a/drivers/net/wireless/ath/ath6kl/main.c
b/drivers/net/wireless/ath/ath6kl/main.c
> index db95f85751e3..4e186f8b3950 100644
> --- a/drivers/net/wireless/ath/ath6kl/main.c
> +++ b/drivers/net/wireless/ath/ath6kl/main.c
> @@ -579,13 +579,9 @@ static int ath6kl_commit_ch_switch(struct ath6kl_vif
*vif, u16 channel)
> * reconfigure any saved RSN IE capabilites in the beacon
/
> * probe response to stay in sync with the supplicant.
> */
> - if (vif->rsn_capab &&
> - test_bit(ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE,
> -ar->fw_capabilities))
> - ath6kl_wmi_set_ie_cmd(ar->wmi, vif->fw_vif_idx,
> - WLAN_EID_RSN,
WMI_RSN_IE_CAPB,
> - (const u8 *)
&vif->rsn_capab,
> - sizeof(vif->rsn_capab));
> + if (vif->rsn_capab)
> + ath6kl_wmi_set_rsn_cap(ar->wmi, vif->fw_vif_idx,
> + vif->rsn_capab);
So, basically same comment as the first one.
> return ath6kl_wmi_ap_profile_commit(ar->wmi,
vif->fw_vif_idx,
> &vif->profile);
> diff --git a/drivers/n
Re: [PATCH] rsi: fix a bug in rsi_hal_key_config()
Hi Dan, On 04/27/2018 06:44 AM, Dan Carpenter wrote: On Fri, Apr 27, 2018 at 02:32:20PM +0300, Kalle Valo wrote: Gustavo submitted an identical patch also for this one :) https://patchwork.kernel.org/patch/10365997/ Hey Gustavo, We keep on sending duplicate patches. Most of the static checker people CC kernel-janit...@vger.kernel.org so we can see what's already been sent. Oh, I didn't know that. I'll start CCing that list then. Thanks for letting me know. -- Gustavo
Re: [PATCH] rsi: Uninitialized return value in rsi_reset_card()
Dan Carpenter writes:
> If rsi_usb_master_reg_write() fails then "ret" hasn't been initialized.
>
> Fixes: 16d3bb7b2f37 ("rsi: disable fw watchdog timer during reset")
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/net/wireless/rsi/rsi_91x_usb.c
> b/drivers/net/wireless/rsi/rsi_91x_usb.c
> index b065438f51b2..6ce6b754df12 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_usb.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_usb.c
> @@ -687,9 +687,10 @@ static int rsi_reset_card(struct rsi_hw *adapter)
>*/
> msleep(100);
>
> - if (rsi_usb_master_reg_write(adapter, SWBL_REGOUT,
> - RSI_FW_WDT_DISABLE_REQ,
> - RSI_COMMON_REG_SIZE) < 0) {
> + ret = rsi_usb_master_reg_write(adapter, SWBL_REGOUT,
> +RSI_FW_WDT_DISABLE_REQ,
> +RSI_COMMON_REG_SIZE);
> + if (ret < 0) {
Odd, I thought I replied to this one already but I don't see my mail on
patchwork. Anyway, Gustavo already submitted an identical patch:
https://patchwork.kernel.org/patch/10365985/
--
Kalle Valo
Re: [PATCH] rsi: fix a bug in rsi_hal_key_config()
On Fri, Apr 27, 2018 at 02:32:20PM +0300, Kalle Valo wrote: > > Gustavo submitted an identical patch also for this one :) > > https://patchwork.kernel.org/patch/10365997/ > Hey Gustavo, We keep on sending duplicate patches. Most of the static checker people CC kernel-janit...@vger.kernel.org so we can see what's already been sent. regards, dan carpenter
Re: ath10k: sdio: jump to correct label in error handling path
Niklas Cassel wrote:
> Jump to the correct label in error handling path.
> At this point of execution create_singlethread_workqueue() has succeeded,
> so it should be properly destroyed.
>
> Jump label was renamed in commit ec2c64e20257 ("ath10k: sdio: fix memory
> leak for probe allocations").
> However, the bug was originally introduced in commit d96db25d2025
> ("ath10k: add initial SDIO support").
>
> Fixes: d96db25d2025 ("ath10k: add initial SDIO support")
> Signed-off-by: Niklas Cassel
> Signed-off-by: Kalle Valo
Patch applied to ath-next branch of ath.git, thanks.
e60a92590187 ath10k: sdio: jump to correct label in error handling path
--
https://patchwork.kernel.org/patch/10365901/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [next] ath10k: fix spelling mistake: "servive" -> "service"
Colin Ian King wrote: > Trivial fix to spelling mistake in ath10k_warn warning message text > > Signed-off-by: Colin Ian King > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 785281342d0c ath10k: fix spelling mistake: "servive" -> "service" -- https://patchwork.kernel.org/patch/10365081/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ath6kl: fix ath6kl_data_tx()'s return type
Luc Van Oostenryck wrote: > The method ndo_start_xmit() is defined as returning an 'netdev_tx_t', > which is a typedef for an enum type, but the implementation in this > driver returns an 'int'. > > Fix this by returning 'netdev_tx_t' in this driver too. > > Signed-off-by: Luc Van Oostenryck > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 378b1d65070f ath6kl: fix ath6kl_data_tx()'s return type -- https://patchwork.kernel.org/patch/10359823/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCHv3] ath10k: fix kernel panic while reading tpc_stats
tami...@codeaurora.org wrote: > When attempt to read tpc_stats for the chipsets which support > more than 3 tx chain will trigger kernel panic(kernel stack is corrupted) > due to writing values on rate_code array out of range. > This patch changes the array size depends on the WMI_TPC_TX_N_CHAIN and > added check to avoid write values on the array if the num tx chain > get in tpc config event is greater than WMI_TPC_TX_N_CHAIN. > > Tested on QCA9984 with firmware-5.bin_10.4-3.5.3-00057 > > Kernel panic log : > > [ 323.510944] Kernel panic - not syncing: stack-protector: Kernel stack is > corrupted in: bf90c654 > [ 323.510944] > [ 323.524390] CPU: 0 PID: 1908 Comm: cat Not tainted 3.14.77 #31 > [ 323.530224] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 323.537941] [] (show_stack) from [] > (dump_stack+0x80/0xa0) > [ 323.545146] [] (dump_stack) from [] (panic+0x84/0x1e4) > [ 323.552000] [] (panic) from [] > (__stack_chk_fail+0x10/0x14) > [ 323.559350] [] (__stack_chk_fail) from [] > (ath10k_wmi_event_pdev_tpc_config+0x424/0x438 [ath10k_core]) > [ 323.570471] [] (ath10k_wmi_event_pdev_tpc_config [ath10k_core]) > from [] (ath10k_wmi_10_4_op_rx+0x2f0/0x39c [ath10k_core]) > [ 323.583047] [] (ath10k_wmi_10_4_op_rx [ath10k_core]) from > [] (ath10k_htc_rx_completion_handler+0x170/0x1a0 [ath10k_core]) > [ 323.595702] [] (ath10k_htc_rx_completion_handler [ath10k_core]) > from [] (ath10k_pci_hif_send_complete_check+0x1f0/0x220 > [ath10k_pci]) > [ 323.609421] [] (ath10k_pci_hif_send_complete_check [ath10k_pci]) > from [] (ath10k_ce_per_engine_service+0x74/0xc4 [ath10k_pci]) > [ 323.622490] [] (ath10k_ce_per_engine_service [ath10k_pci]) from > [] (ath10k_ce_per_engine_service_any+0x74/0x80 [ath10k_pci]) > [ 323.635423] [] (ath10k_ce_per_engine_service_any [ath10k_pci]) > from [] (ath10k_pci_napi_poll+0x44/0xe8 [ath10k_pci]) > [ 323.647665] [] (ath10k_pci_napi_poll [ath10k_pci]) from > [] (net_rx_action+0xac/0x160) > [ 323.657208] [] (net_rx_action) from [] > (__do_softirq+0x104/0x294) > [ 323.665017] [] (__do_softirq) from [] > (irq_exit+0x9c/0x11c) > [ 323.672314] [] (irq_exit) from [] > (handle_IRQ+0x6c/0x90) > [ 323.679341] [] (handle_IRQ) from [] > (gic_handle_irq+0x3c/0x60) > [ 323.686893] [] (gic_handle_irq) from [] > (__irq_svc+0x40/0x70) > [ 323.694349] Exception stack(0xdd489c58 to 0xdd489ca0) > [ 323.699384] 9c40: > a013 > [ 323.707547] 9c60: dc4bce40 6013 ddc1d800 dd488000 0990 > c085c800 > [ 323.715707] 9c80: dd489d44 092d dd489ca0 c026e664 c026e668 > 6013 > [ 323.723877] [] (__irq_svc) from [] > (rcu_note_context_switch+0x170/0x184) > [ 323.732298] [] (rcu_note_context_switch) from [] > (__schedule+0x50/0x4d4) > [ 323.740716] [] (__schedule) from [] > (schedule_timeout+0x148/0x178) > [ 323.748611] [] (schedule_timeout) from [] > (wait_for_common+0x114/0x154) > [ 323.756972] [] (wait_for_common) from [] > (ath10k_tpc_stats_open+0xc8/0x340 [ath10k_core]) > [ 323.766873] [] (ath10k_tpc_stats_open [ath10k_core]) from > [] (do_dentry_open+0x1ac/0x274) > [ 323.776741] [] (do_dentry_open) from [] > (do_last+0x8c0/0xb08) > [ 323.784201] [] (do_last) from [] > (path_openat+0x210/0x598) > [ 323.791408] [] (path_openat) from [] > (do_filp_open+0x2c/0x78) > [ 323.798873] [] (do_filp_open) from [] > (do_sys_open+0x114/0x1b4) > [ 323.806509] [] (do_sys_open) from [] > (ret_fast_syscall+0x0/0x44) > [ 323.814241] CPU1: stopping > [ 323.816927] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 3.14.77 #31 > [ 323.823008] [] (unwind_backtrace) from [] > (show_stack+0x10/0x14) > [ 323.830731] [] (show_stack) from [] > (dump_stack+0x80/0xa0) > [ 323.837934] [] (dump_stack) from [] > (handle_IPI+0xb8/0x140) > [ 323.845224] [] (handle_IPI) from [] > (gic_handle_irq+0x58/0x60) > [ 323.852774] [] (gic_handle_irq) from [] > (__irq_svc+0x40/0x70) > [ 323.860233] Exception stack(0xdd499fa0 to 0xdd499fe8) > [ 323.865273] 9fa0: ffed 1d3c9000 dd498000 dd498030 > 10c0387d c08b62c8 > [ 323.873432] 9fc0: 4220406a 512f04d0 0001 dd499fe8 > c021838c c0218390 > [ 323.881588] 9fe0: 6013 > [ 323.885070] [] (__irq_svc) from [] > (arch_cpu_idle+0x30/0x50) > [ 323.892454] [] (arch_cpu_idle) from [] > (cpu_startup_entry+0xa4/0x108) > [ 323.900690] [] (cpu_startup_entry) from [<422085a4>] (0x422085a4) > > Signed-off-by: Tamizh chelvam > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 4b190675ad06 ath10k: fix kernel panic while reading tpc_stats -- https://patchwork.kernel.org/patch/10356155/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: [PATCH] rsi: fix a bug in rsi_hal_key_config()
Dan Carpenter writes:
> Smatch complains that the end of this function is dead code. I'm pretty
> sure that this return needs to be changed to only return on error.
>
> Fixes: 4fd6c4762f37 ("rsi: roaming enhancements")
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> index 766d874cc6e2..80e7f4f4f188 100644
> --- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> +++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
> @@ -911,14 +911,14 @@ static int rsi_hal_key_config(struct ieee80211_hw *hw,
> }
> }
>
> - return rsi_hal_load_key(adapter->priv,
> - key->key,
> - key->keylen,
> - key_type,
> - key->keyidx,
> - key->cipher,
> - sta_id,
> - vif);
> + status = rsi_hal_load_key(adapter->priv,
> + key->key,
> + key->keylen,
> + key_type,
> + key->keyidx,
> + key->cipher,
> + sta_id,
> + vif);
Gustavo submitted an identical patch also for this one :)
https://patchwork.kernel.org/patch/10365997/
--
Kalle Valo
Re: ath10k: fix information leak in debugfs
Venkateswara Naralasetty wrote: > During write to some of debugfs in ath10k, few variables exposing stack > data when process user input. which leads to possible information leak. > > This patch fix this issue by initializing buffer and checks > the return valure of 'simple_write_to_buffer'. > > Signed-off-by: Venkateswara Naralasetty > Signed-off-by: Kalle Valo Patch applied to ath-next branch of ath.git, thanks. 2f177c1628c3 ath10k: fix information leak in debugfs -- https://patchwork.kernel.org/patch/10227751/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
Re: ath6kl: use WMI to set RSN capabilities
Alfonso Sánchez-Beato wrote: > This fixes AP mode when the ATH6KL_FW_CAPABILITY_RSN_CAP_OVERRIDE flag > is not present in the FW. The id of some WMI commands is also fixed > (there was an error in the enum order), and a function to set RSN caps > is added. > > Signed-off-by: Alfonso Sánchez-Beato > Signed-off-by: Kalle Valo Steve, what do you think of this? -- https://patchwork.kernel.org/patch/10338903/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
[PATCH] rsi: fix a bug in rsi_hal_key_config()
Smatch complains that the end of this function is dead code. I'm pretty
sure that this return needs to be changed to only return on error.
Fixes: 4fd6c4762f37 ("rsi: roaming enhancements")
Signed-off-by: Dan Carpenter
diff --git a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
index 766d874cc6e2..80e7f4f4f188 100644
--- a/drivers/net/wireless/rsi/rsi_91x_mac80211.c
+++ b/drivers/net/wireless/rsi/rsi_91x_mac80211.c
@@ -911,14 +911,14 @@ static int rsi_hal_key_config(struct ieee80211_hw *hw,
}
}
- return rsi_hal_load_key(adapter->priv,
- key->key,
- key->keylen,
- key_type,
- key->keyidx,
- key->cipher,
- sta_id,
- vif);
+ status = rsi_hal_load_key(adapter->priv,
+ key->key,
+ key->keylen,
+ key_type,
+ key->keyidx,
+ key->cipher,
+ sta_id,
+ vif);
if (status)
return status;
