* Re: [PATCH 11/11] rtw88: debug: dump tx power indexes in use
From: Joe Perches @ 2019-06-01 22:51 UTC (permalink / raw)
To: yhchuang, kvalo; +Cc: linux-wireless
In-Reply-To: <1559116487-5244-12-git-send-email-yhchuang@realtek.com>
On Wed, 2019-05-29 at 15:54 +0800, yhchuang@realtek.com wrote:
> From: Zong-Zhe Yang <kevin_yang@realtek.com>
>
> Add a read entry in debugfs to dump current tx power
> indexes in use for each path and each rate section.
> The corresponding power bases, power by rate, and
> power limit are also included.
>
> Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
> Signed-off-by: Yan-Hsuan Chuang <yhchuang@realtek.com>
> ---
> drivers/net/wireless/realtek/rtw88/debug.c | 112 +++++++++++++++++++++++++++++
> 1 file changed, 112 insertions(+)
>
> diff --git a/drivers/net/wireless/realtek/rtw88/debug.c b/drivers/net/wireless/realtek/rtw88/debug.c
> index f0ae260..ee2937c2 100644
> --- a/drivers/net/wireless/realtek/rtw88/debug.c
> +++ b/drivers/net/wireless/realtek/rtw88/debug.c
> @@ -8,6 +8,7 @@
> #include "sec.h"
> #include "fw.h"
> #include "debug.h"
> +#include "phy.h"
>
> #ifdef CONFIG_RTW88_DEBUGFS
>
> @@ -460,6 +461,112 @@ static int rtw_debug_get_rf_dump(struct seq_file *m, void *v)
> return 0;
> }
>
> +static void rtw_print_cck_rate_txt(struct seq_file *m, u8 rate)
> +{
> + static const char * const
> + cck_rate[] = {"1M", "2M", "5.5M", "11M"};
> + u8 idx = rate - DESC_RATE1M;
> +
> + seq_printf(m, "%5s%-5s", "CCK_", cck_rate[idx]);
Why use %5s instead of just embedding the prefix directly?
Also why use %5s at all when the length is 4?
I think it'd be more sensible as:
seq_printf(m, " CCK_%-5s", cck_rate[idx]);
> +}
> +
> +static void rtw_print_ofdm_rate_txt(struct seq_file *m, u8 rate)
> +{
> + static const char * const
> + ofdm_rate[] = {"6M", "9M", "12M", "18M", "24M", "36M", "48M", "54M"};
> + u8 idx = rate - DESC_RATE6M;
> +
> + seq_printf(m, "%6s%-4s", "OFDM_", ofdm_rate[idx]);
here too
> +}
> +
> +static void rtw_print_ht_rate_txt(struct seq_file *m, u8 rate)
> +{
> + u8 mcs_n = rate - DESC_RATEMCS0;
> +
> + seq_printf(m, "%4s%-6u", "MCS", mcs_n);
and here, etc...
^ permalink raw reply
* RE: [EXT] Re: [PATCH] mwifiex: check for null return from skb_copy
From: Ganapathi Bhat @ 2019-06-02 1:56 UTC (permalink / raw)
To: Dan Carpenter
Cc: Colin King, Amitkumar Karwar, Nishant Sarmukadam, Xinming Hu,
Kalle Valo, David S . Miller, linux-wireless@vger.kernel.org,
netdev@vger.kernel.org, kernel-janitors@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20190601210858.GG31203@kadam>
Hi Dan,
> > > > if (is_multicast_ether_addr(ra)) {
> > > > skb_uap = skb_copy(skb, GFP_ATOMIC);
> > > > + if (!skb_uap)
> > > > + return -ENOMEM;
> > >
> > > I think we would want to free dev_kfree_skb_any(skb) before returning.
> > I think if the pointer is NULL, no need to free it;
>
> You're misreading skb vs skb_uap. "skb_uap" is NULL but "skb" is non-NULL
> and I'm pretty sure we should free it.
Oh, right. I missed it; Yes you are correct.
Regards,
Ganapathi
^ permalink raw reply
* [PATCH] carl9170: Fix misuse of device driver API
From: Christian Lamparter @ 2019-06-02 9:06 UTC (permalink / raw)
To: linux-wireless; +Cc: Kalle Valo, Alan Stern, USB list
This patch follows Alan Stern's recent patch:
"p54: Fix race between disconnect and firmware loading"
that overhauled carl9170 buggy firmware loading and driver
unbinding procedures.
Since the carl9170 code was adapted from p54 it uses the
same functions and is likely to have the same problem, but
it's just that the syzbot hasn't reproduce them (yet).
a summary from the changes (copied from the p54 patch):
* Call usb_driver_release_interface() rather than
device_release_driver().
* Lock udev (the interface's parent) before unbinding the
driver instead of locking udev->parent.
* During the firmware loading process, take a reference
to the USB interface instead of the USB device.
* Don't take an unnecessary reference to the device during
probe (and then don't drop it during disconnect).
and
* Make sure to prevent use-after-free bugs by explicitly
setting the driver context to NULL after signaling the
completion.
Cc: <stable@vger.kernel.org>
Cc: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
---
drivers/net/wireless/ath/carl9170/usb.c | 26 ++++++++++++-------------
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c
index e7c3f3b8457d..297a7b877d31 100644
--- a/drivers/net/wireless/ath/carl9170/usb.c
+++ b/drivers/net/wireless/ath/carl9170/usb.c
@@ -128,6 +128,8 @@ static const struct usb_device_id carl9170_usb_ids[] = {
};
MODULE_DEVICE_TABLE(usb, carl9170_usb_ids);
+static struct usb_driver carl9170_driver;
+
static void carl9170_usb_submit_data_urb(struct ar9170 *ar)
{
struct urb *urb;
@@ -966,7 +968,7 @@ static int carl9170_usb_init_device(struct ar9170 *ar)
static void carl9170_usb_firmware_failed(struct ar9170 *ar)
{
- struct device *parent = ar->udev->dev.parent;
+ struct usb_interface *intf = ar->intf;
struct usb_device *udev;
/*
@@ -978,16 +980,15 @@ static void carl9170_usb_firmware_failed(struct ar9170 *ar)
udev = ar->udev;
complete(&ar->fw_load_wait);
+ /* at this point 'ar' could be already freed. Don't use it anymore */
+ ar = NULL;
/* unbind anything failed */
- if (parent)
- device_lock(parent);
-
- device_release_driver(&udev->dev);
- if (parent)
- device_unlock(parent);
+ usb_lock_device(udev);
+ usb_driver_release_interface(&carl9170_driver, intf);
+ usb_unlock_device(udev);
- usb_put_dev(udev);
+ usb_put_intf(intf);
}
static void carl9170_usb_firmware_finish(struct ar9170 *ar)
@@ -1009,7 +1010,7 @@ static void carl9170_usb_firmware_finish(struct ar9170 *ar)
goto err_unrx;
complete(&ar->fw_load_wait);
- usb_put_dev(ar->udev);
+ usb_put_intf(ar->intf);
return;
err_unrx:
@@ -1052,7 +1053,6 @@ static int carl9170_usb_probe(struct usb_interface *intf,
return PTR_ERR(ar);
udev = interface_to_usbdev(intf);
- usb_get_dev(udev);
ar->udev = udev;
ar->intf = intf;
ar->features = id->driver_info;
@@ -1094,15 +1094,14 @@ static int carl9170_usb_probe(struct usb_interface *intf,
atomic_set(&ar->rx_anch_urbs, 0);
atomic_set(&ar->rx_pool_urbs, 0);
- usb_get_dev(ar->udev);
+ usb_get_intf(intf);
carl9170_set_state(ar, CARL9170_STOPPED);
err = request_firmware_nowait(THIS_MODULE, 1, CARL9170FW_NAME,
&ar->udev->dev, GFP_KERNEL, ar, carl9170_usb_firmware_step2);
if (err) {
- usb_put_dev(udev);
- usb_put_dev(udev);
+ usb_put_intf(intf);
carl9170_free(ar);
}
return err;
@@ -1131,7 +1130,6 @@ static void carl9170_usb_disconnect(struct usb_interface *intf)
carl9170_release_firmware(ar);
carl9170_free(ar);
- usb_put_dev(udev);
}
#ifdef CONFIG_PM
--
2.20.1
^ permalink raw reply related
* [RFC PATCH] ath9k: integrate AR92XX pci fixup code
From: Christian Lamparter @ 2019-06-02 10:21 UTC (permalink / raw)
To: QCA ath9k Development, linux-wireless; +Cc: Hauke Mehrtens, Martin Blumenstingl
Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
need to be able to initialize the PCIe wifi device. Normally, this is done
during the early stages of booting linux, because the necessary init code
is read from the memory mapped SPI and passed to pci_enable_ath9k_fixup.
However, this isn't possible for devices which have the init code for the
Atheros chip stored on NAND in an UBI volume. Hence, this module can be
used to initialize the chip when the user-space is ready to extract the
init code.
Martin Blumenstingl prodived the following fixes:
owl-loader: add support for OWL emulation PCI devices
owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
owl-loader: use dev_* instead of pr_* logging functions
owl-loader: auto-generate the eeprom filename as fallback
owl-loader: add a debug message when swapping the eeprom data
owl-loader: add missing newlines in log messages
Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
drivers/net/wireless/ath/ath9k/Kconfig | 15 ++
drivers/net/wireless/ath/ath9k/ath9k.h | 1 +
drivers/net/wireless/ath/ath9k/pci.c | 252 ++++++++++++++++++++++++-
3 files changed, 266 insertions(+), 2 deletions(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index a1ef8769983a..25b791389816 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -157,6 +157,21 @@ config ATH9K_PCOEM
depends on ATH9K
default y
+config ATH9K_PCI_NO_EEPROM
+ bool "Atheros ath9k support for EEPROM-less chips"
+ depends on ATH9K_PCI
+ default n
+ help
+ Say Y to support AR92XX-generation of ath9k PCI(e) WiFi chips, which
+ have their initialization data (which contains the PCI Device ID!)
+ stored together with the calibration data out of reach for the ath9k
+ chip.
+
+ These devices are usually various network appliances, routers or
+ access Points and such.
+
+ If unsure say N.
+
config ATH9K_HTC
tristate "Atheros HTC based wireless cards support"
depends on USB && MAC80211
diff --git a/drivers/net/wireless/ath/ath9k/ath9k.h b/drivers/net/wireless/ath/ath9k/ath9k.h
index a412b352182c..ec649446421b 100644
--- a/drivers/net/wireless/ath/ath9k/ath9k.h
+++ b/drivers/net/wireless/ath/ath9k/ath9k.h
@@ -959,6 +959,7 @@ void ath_ant_comb_scan(struct ath_softc *sc, struct ath_rx_status *rs);
#define ATH9K_PCI_NO_PLL_PWRSAVE 0x0200
#define ATH9K_PCI_KILLER 0x0400
#define ATH9K_PCI_LED_ACT_HI 0x0800
+#define ATH9K_PCI_NO_EEPROM 0x1000
/*
* Default cache line size, in bytes.
diff --git a/drivers/net/wireless/ath/ath9k/pci.c b/drivers/net/wireless/ath/ath9k/pci.c
index 92b2dd396436..53a16e961055 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -19,7 +19,11 @@
#include <linux/nl80211.h>
#include <linux/pci.h>
#include <linux/module.h>
+#include <linux/firmware.h>
+#include <linux/completion.h>
+#include <linux/ath9k_platform.h>
#include "ath9k.h"
+#include "eeprom.h"
extern int ath9k_use_msi;
@@ -774,6 +778,17 @@ static const struct pci_device_id ath_pci_id_table[] = {
.driver_data = ATH9K_PCI_BT_ANT_DIV },
#endif
+#ifdef CONFIG_ATH9K_PCI_NO_EEPROM
+ /* If a physical EEPROM or OTP is not used (such as for an integrated
+ * access point), the device responds to bus probing with default
+ * hardware deviceID and subvendorDeviceID information.
+ */
+ { PCI_VDEVICE(ATHEROS, 0xff1c),
+ .driver_data = ATH9K_PCI_NO_EEPROM }, /* PCIe */
+ { PCI_VDEVICE(ATHEROS, 0xff1d),
+ .driver_data = ATH9K_PCI_NO_EEPROM }, /* PCI */
+#endif /* CONFIG_ATH9K_PCI_NO_EEPROM */
+
{ 0 }
};
@@ -882,6 +897,228 @@ static const struct ath_bus_ops ath_pci_bus_ops = {
.aspm_init = ath_pci_aspm_init,
};
+#ifdef CONFIG_ATH9K_PCI_NO_EEPROM
+
+struct ath_pci_fixup_ctx {
+ struct completion eeprom_load;
+};
+
+#define EEPROM_FILENAME_LEN 100
+/* AR5416_EEPROM_MAGIC changes depending on target endian */
+#define ATH_PCI_FIXUP_MAGIC 0xa55a
+
+static int ath_pci_fixup(struct pci_dev *pdev, const u16 *cal_data,
+ size_t cal_len)
+{
+ void __iomem *mem;
+ const void *cal_end = (void *)cal_data + cal_len;
+ const struct {
+ u16 reg;
+ u16 low_val;
+ u16 high_val;
+ } __packed * data;
+ u16 cmd;
+ u32 bar0;
+ bool swap_needed = false;
+
+ if (*cal_data != ATH_PCI_FIXUP_MAGIC) {
+ if (*cal_data != swab16(ATH_PCI_FIXUP_MAGIC)) {
+ dev_err(&pdev->dev, "invalid calibration data\n");
+ return -EINVAL;
+ }
+
+ dev_dbg(&pdev->dev, "calibration data needs swapping\n");
+ swap_needed = true;
+ }
+
+ dev_info(&pdev->dev, "fixup device configuration\n");
+
+ mem = pcim_iomap(pdev, 0, 0);
+ if (!mem) {
+ dev_err(&pdev->dev, "ioremap error\n");
+ return -EINVAL;
+ }
+
+ pci_read_config_dword(pdev, PCI_BASE_ADDRESS_0, &bar0);
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0,
+ pci_resource_start(pdev, 0));
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd |= PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY;
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ /* set pointer to first reg address */
+ for (data = (const void *)(cal_data + 3);
+ (const void *)data <= cal_end && data->reg != (u16)~0;
+ data++) {
+ u32 val;
+ u16 reg;
+
+ reg = data->reg;
+ val = data->low_val;
+ val |= ((u32)data->high_val) << 16;
+
+ if (swap_needed) {
+ reg = swab16(reg);
+ val = swahb32(val);
+ }
+
+ __raw_writel(val, mem + reg);
+ usleep_range(100, 120);
+ }
+
+ pci_read_config_word(pdev, PCI_COMMAND, &cmd);
+ cmd &= ~(PCI_COMMAND_MASTER | PCI_COMMAND_MEMORY);
+ pci_write_config_word(pdev, PCI_COMMAND, cmd);
+
+ pci_write_config_dword(pdev, PCI_BASE_ADDRESS_0, bar0);
+ pcim_iounmap(pdev, mem);
+
+ pci_disable_device(pdev);
+
+ return 0;
+}
+
+static void ath_pci_fixup_fw_cb(const struct firmware *fw, void *context)
+{
+ struct pci_dev *pdev = (struct pci_dev *)context;
+ struct ath_pci_fixup_ctx *ctx;
+ struct ath9k_platform_data *pdata = dev_get_platdata(&pdev->dev);
+ struct pci_bus *bus;
+
+ ctx = (struct ath_pci_fixup_ctx *)pci_get_drvdata(pdev);
+ complete(&ctx->eeprom_load);
+
+ if (!fw) {
+ dev_err(&pdev->dev, "no eeprom data received.\n");
+ goto release;
+ }
+
+ /* also note that we are doing *u16 operations on the file */
+ if (fw->size > sizeof(pdata->eeprom_data) || fw->size < 0x200 ||
+ (fw->size & 1) == 1) {
+ dev_err(&pdev->dev, "eeprom file has an invalid size.\n");
+ goto release;
+ }
+
+ if (pdata) {
+ memcpy(pdata->eeprom_data, fw->data, fw->size);
+
+ /* eeprom has been successfully loaded - pass the data to ath9k
+ * but remove the eeprom_name, so it doesn't try to load it too.
+ */
+ pdata->eeprom_name = NULL;
+ }
+
+ if (ath_pci_fixup(pdev, (const u16 *)fw->data, fw->size))
+ goto release;
+
+ pci_lock_rescan_remove();
+ bus = pdev->bus;
+ pci_stop_and_remove_bus_device(pdev);
+ /* the device should come back with the proper
+ * ProductId. But we have to initiate a rescan.
+ */
+ pci_rescan_bus(bus);
+ pci_unlock_rescan_remove();
+
+release:
+ release_firmware(fw);
+}
+
+static const char *ath_pci_fixup_get_eeprom_name(struct pci_dev *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct ath9k_platform_data *pdata;
+ char *eeprom_name;
+
+ /* try the existing platform data first */
+ pdata = dev_get_platdata(dev);
+ if (pdata && pdata->eeprom_name)
+ return pdata->eeprom_name;
+
+ dev_dbg(dev, "using auto-generated eeprom filename\n");
+
+ eeprom_name = devm_kzalloc(dev, EEPROM_FILENAME_LEN, GFP_KERNEL);
+ if (!eeprom_name)
+ return NULL;
+
+ /* this should match the pattern used in init.c */
+ scnprintf(eeprom_name, EEPROM_FILENAME_LEN, "ath9k-eeprom-pci-%s.bin",
+ dev_name(dev));
+
+ return eeprom_name;
+}
+
+static int ath_pci_fixup_probe(struct pci_dev *pdev,
+ const struct pci_device_id *id)
+{
+ struct ath_pci_fixup_ctx *ctx;
+ const char *eeprom_name;
+ int err = 0;
+
+ /* only handle devices that do not have a support EEPROM */
+ if (!(id->driver_data & ATH9K_PCI_NO_EEPROM))
+ return 0;
+
+ pcim_pin_device(pdev);
+
+ eeprom_name = ath_pci_fixup_get_eeprom_name(pdev);
+ if (!eeprom_name) {
+ dev_err(&pdev->dev, "no eeprom filename found.\n");
+ return -ENODEV;
+ }
+
+ ctx = devm_kzalloc(&pdev->dev, sizeof(*ctx), GFP_KERNEL);
+ if (!ctx)
+ return -ENOMEM;
+
+ init_completion(&ctx->eeprom_load);
+
+ pci_set_drvdata(pdev, ctx);
+ err = request_firmware_nowait(THIS_MODULE, true, eeprom_name,
+ &pdev->dev, GFP_KERNEL, pdev,
+ ath_pci_fixup_fw_cb);
+ if (err)
+ dev_err(&pdev->dev, "failed to request caldata (%d).\n", err);
+
+ /* Use the return code "1" as a way to tell the ath_pci_probe()
+ * function that we will be taking an alternative code-path from
+ * now on. Once the device has the proper ProductIDs it will
+ * go through ath_pci_probe() again.
+ */
+ return err < 0 ? err : 1;
+}
+
+static bool ath_pci_fixup_remove(struct pci_dev *pdev)
+{
+ const struct pci_device_id *id;
+ struct ath_pci_fixup_ctx *ctx;
+
+ id = pci_match_id(ath_pci_id_table, pdev);
+ if (!id || !(id->driver_data & ATH9K_PCI_NO_EEPROM))
+ return false;
+
+ ctx = pci_get_drvdata(pdev);
+ if (ctx) {
+ wait_for_completion(&ctx->eeprom_load);
+ pci_set_drvdata(pdev, NULL);
+ }
+
+ return true;
+}
+#else
+static int ath_pci_fixup_probe(struct pci_dev __maybe_unused *pdev,
+ const struct pci_device_id __maybe_unused *id)
+{
+ return 0;
+}
+
+static bool ath_pci_fixup_remove(struct pci_dev __maybe_unused *pdev)
+{
+ return false;
+}
+#endif /* CONFIG_ATH9K_PCI_NO_EEPROM */
+
static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
{
struct ath_softc *sc;
@@ -895,6 +1132,12 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
if (pcim_enable_device(pdev))
return -EIO;
+ ret = ath_pci_fixup_probe(pdev, id);
+ if (ret < 0)
+ return ret;
+ if (ret == 1)
+ return 0; /* ath_pci_fixup_probe took over */
+
ret = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
if (ret) {
pr_err("32-bit DMA not available\n");
@@ -1007,9 +1250,14 @@ static int ath_pci_probe(struct pci_dev *pdev, const struct pci_device_id *id)
static void ath_pci_remove(struct pci_dev *pdev)
{
- struct ieee80211_hw *hw = pci_get_drvdata(pdev);
- struct ath_softc *sc = hw->priv;
+ struct ieee80211_hw *hw;
+ struct ath_softc *sc;
+ if (ath_pci_fixup_remove(pdev))
+ return;
+
+ hw = pci_get_drvdata(pdev);
+ sc = hw->priv;
if (!is_ath9k_unloaded)
sc->sc_ah->ah_flags |= AH_UNPLUGGED;
ath9k_deinit_device(sc);
--
2.20.1
^ permalink raw reply related
* Re: [RFC PATCH] ath9k: integrate AR92XX pci fixup code
From: Julian Calaby @ 2019-06-02 11:43 UTC (permalink / raw)
To: Christian Lamparter
Cc: QCA ath9k Development, linux-wireless, Hauke Mehrtens,
Martin Blumenstingl
In-Reply-To: <20190602102144.17360-1-chunkeey@gmail.com>
Hi Christian,
On Sun, Jun 2, 2019 at 8:24 PM Christian Lamparter <chunkeey@gmail.com> wrote:
>
> Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
> need to be able to initialize the PCIe wifi device. Normally, this is done
> during the early stages of booting linux, because the necessary init code
> is read from the memory mapped SPI and passed to pci_enable_ath9k_fixup.
> However, this isn't possible for devices which have the init code for the
> Atheros chip stored on NAND in an UBI volume. Hence, this module can be
> used to initialize the chip when the user-space is ready to extract the
> init code.
>
> Martin Blumenstingl prodived the following fixes:
> owl-loader: add support for OWL emulation PCI devices
> owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> owl-loader: use dev_* instead of pr_* logging functions
> owl-loader: auto-generate the eeprom filename as fallback
> owl-loader: add a debug message when swapping the eeprom data
> owl-loader: add missing newlines in log messages
>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Two questions:
1. This seems complicated enough that the functions introduced should
probably go into a separate .c file, maybe "noeeprom.c", with a header
file with all the ifdef / config magic in it.
2. This smells almost like a completely separate PCI(e) driver for
cards in a "weird" state. Is there anything you're using from ath9k
other than the eeprom file naming? and is that really useful? Won't
the eeprom files be device specific and therefore could always use the
device name fallback?
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [RFC PATCH] ath9k: integrate AR92XX pci fixup code
From: Christian Lamparter @ 2019-06-02 13:14 UTC (permalink / raw)
To: Julian Calaby
Cc: QCA ath9k Development, linux-wireless, Hauke Mehrtens,
Martin Blumenstingl
In-Reply-To: <CAGRGNgXqB=5oi1Nq4ZNSk3csOEr4A6WgN8QymKMriTcevnKUQw@mail.gmail.com>
Hello Julian,
On Sunday, June 2, 2019 1:43:52 PM CEST Julian Calaby wrote:
> On Sun, Jun 2, 2019 at 8:24 PM Christian Lamparter <chunkeey@gmail.com> wrote:
> >
> > Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
> > need to be able to initialize the PCIe wifi device. Normally, this is done
> > during the early stages of booting linux, because the necessary init code
> > is read from the memory mapped SPI and passed to pci_enable_ath9k_fixup.
> > However, this isn't possible for devices which have the init code for the
> > Atheros chip stored on NAND in an UBI volume. Hence, this module can be
> > used to initialize the chip when the user-space is ready to extract the
> > init code.
> >
> > Martin Blumenstingl prodived the following fixes:
> > owl-loader: add support for OWL emulation PCI devices
> > owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> > owl-loader: use dev_* instead of pr_* logging functions
> > owl-loader: auto-generate the eeprom filename as fallback
> > owl-loader: add a debug message when swapping the eeprom data
> > owl-loader: add missing newlines in log messages
> >
> > Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
>
> Two questions:
>
> 1. This seems complicated enough that the functions introduced should
> probably go into a separate .c file, maybe "noeeprom.c", with a header
> file with all the ifdef / config magic in it.
In openwrt we called it owl-loader.c and it's a separate module there.
But I don't think that noeeprom.c is that great since ath9k also supports
AHB and htc_usb, so from this perspective it would mean:
pci_init_noeeprom.c ? (As AR5008, AR9160 and AR92XX seem to be affected).
> 2. This smells almost like a completely separate PCI(e) driver for
> cards in a "weird" state.
It's in the Datasheet that the device initializes into this state. See
AR9280 6.1.2 DEVICE_ID. "... if the EEPROM content is not valid, a
value of 0XFF1C returns when read from the register". This would also
mean that this routine can be used to resurrect aging AR9280 cards
that have a failed eeprom or are from APPLE, see this thread:
<https://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg03918.html>
"does anyone know whether 168c:ff1c can be supported by the current ath9k
driver? It isn't listed with the PCI IDs in the source. I bought it off
eBay as "Apple" AR5008. It is a PCI Express card with 3 Antenna
connectors and lots of Apple stampings on it. lspci says:"
> Is there anything you're using from ath9k
> other than the eeprom file naming? and is that really useful? Won't
> the eeprom files be device specific and therefore could always use the
> device name fallback?
Please take a look at the commit message. Unfortunately the Z1 stores
its calibration data in a ubi volume, these can't be easily read
without interfacing with either ubi or the vfs. In the future, simpler
devices that have it on SPI-NOR in a mtd partition can setup a nvmem
provider and the code can have a nvmem-consumer. (see attached patch).
Note: There are also devices with mutliple ath9k pci(e) chips
(usually one 2.4Ghz and one 5GHz), so a generic "ath9k" name is too
short and the pciids of both are the same. That's why the pci-bus
location is currently used for the eeprom name identifier.
Regards,
Christian
---
Note: nvmem dts is not finalized. See
commit 517f14d9cf3533d5ab4fded195ab6f80a92e378f
Author: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Date: Fri Nov 30 11:53:25 2018 +0000
nvmem: add new config option
for details why adding something like this unfinished patch
just does not makes sense (yet).
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -21,6 +21,7 @@
#include <linux/module.h>
#include <linux/firmware.h>
#include <linux/completion.h>
+#include <linux/nvmem-consumer.h>
#include <linux/ath9k_platform.h>
#include "ath9k.h"
#include "eeprom.h"
@@ -1053,6 +1054,7 @@ static int ath_pci_fixup_probe(struct pci_dev *pdev,
const struct pci_device_id *id)
{
struct ath_pci_fixup_ctx *ctx;
+ struct nvmem_cell *cell;
const char *eeprom_name;
int err = 0;
@@ -1062,6 +1064,21 @@ static int ath_pci_fixup_probe(struct pci_dev *pdev,
pcim_pin_device(pdev);
+ cell = nvmem_cell_get(&pdev->dev, "caldata");
+ if (!IS_ERR(cell)) {
+ void *value;
+ size_t len;
+
+ value = nvmem_cell_read(cell, &len);
+ if (!IS_ERR(value)) {
+ err = ath_pci_fixup(pdev, value, len);
+ kfree(value);
+ } else
+ err = -EINVAL;
+ nvmem_cell_put(cell);
+ return err;
+ }
+
eeprom_name = ath_pci_fixup_get_eeprom_name(pdev);
if (!eeprom_name) {
dev_err(&pdev->dev, "no eeprom filename found.\n");
^ permalink raw reply
* Re: iwl_mvm_add_new_dqa_stream_wk BUG in lib/list_debug.c:56
From: Marc Haber @ 2019-06-02 13:48 UTC (permalink / raw)
To: linux-kernel, linux-wireless, netdev
In-Reply-To: <20190530081257.GA26133@torres.zugschlus.de>
On Thu, May 30, 2019 at 10:12:57AM +0200, Marc Haber wrote:
> on my primary notebook, a Lenovo X260, with an Intel Wireless 8260
> (8086:24f3), running Debian unstable, I have started to see network
> hangs since upgrading to kernel 5.1. In this situation, I cannot
> restart Network-Manager (the call just hangs), I can log out of X, but
> the system does not cleanly shut down and I need to Magic SysRq myself
> out of the running system. This happens about once every two days.
The issue is also present in 5.1.5 and 5.1.6.
Greetings
Marc
--
-----------------------------------------------------------------------------
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany | lose things." Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
^ permalink raw reply
* Re: [RFC PATCH] ath9k: integrate AR92XX pci fixup code
From: Julian Calaby @ 2019-06-02 14:11 UTC (permalink / raw)
To: Christian Lamparter
Cc: QCA ath9k Development, linux-wireless, Hauke Mehrtens,
Martin Blumenstingl
In-Reply-To: <2349614.IEgcWBM518@debian64>
Hi Christian,
On Sun, Jun 2, 2019 at 11:14 PM Christian Lamparter <chunkeey@gmail.com> wrote:
>
> Hello Julian,
>
> On Sunday, June 2, 2019 1:43:52 PM CEST Julian Calaby wrote:
> > On Sun, Jun 2, 2019 at 8:24 PM Christian Lamparter <chunkeey@gmail.com> wrote:
> > >
> > > Some devices (like the Cisco Meraki Z1 Cloud Managed Teleworker Gateway)
> > > need to be able to initialize the PCIe wifi device. Normally, this is done
> > > during the early stages of booting linux, because the necessary init code
> > > is read from the memory mapped SPI and passed to pci_enable_ath9k_fixup.
> > > However, this isn't possible for devices which have the init code for the
> > > Atheros chip stored on NAND in an UBI volume. Hence, this module can be
> > > used to initialize the chip when the user-space is ready to extract the
> > > init code.
> > >
> > > Martin Blumenstingl prodived the following fixes:
> > > owl-loader: add support for OWL emulation PCI devices
> > > owl-loader: don't re-scan the bus when ath9k_pci_fixup failed
> > > owl-loader: use dev_* instead of pr_* logging functions
> > > owl-loader: auto-generate the eeprom filename as fallback
> > > owl-loader: add a debug message when swapping the eeprom data
> > > owl-loader: add missing newlines in log messages
> > >
> > > Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> > > Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> >
> > Two questions:
> >
> > 1. This seems complicated enough that the functions introduced should
> > probably go into a separate .c file, maybe "noeeprom.c", with a header
> > file with all the ifdef / config magic in it.
>
> In openwrt we called it owl-loader.c and it's a separate module there.
> But I don't think that noeeprom.c is that great since ath9k also supports
> AHB and htc_usb, so from this perspective it would mean:
> pci_init_noeeprom.c ? (As AR5008, AR9160 and AR92XX seem to be affected).
Fair enough, I hadn't thought of the other buses.
> > 2. This smells almost like a completely separate PCI(e) driver for
> > cards in a "weird" state.
> It's in the Datasheet that the device initializes into this state. See
> AR9280 6.1.2 DEVICE_ID. "... if the EEPROM content is not valid, a
> value of 0XFF1C returns when read from the register". This would also
> mean that this routine can be used to resurrect aging AR9280 cards
> that have a failed eeprom or are from APPLE, see this thread:
>
> <https://www.mail-archive.com/ath9k-devel@lists.ath9k.org/msg03918.html>
>
> "does anyone know whether 168c:ff1c can be supported by the current ath9k
> driver? It isn't listed with the PCI IDs in the source. I bought it off
> eBay as "Apple" AR5008. It is a PCI Express card with 3 Antenna
> connectors and lots of Apple stampings on it. lspci says:"
I'm asking because (I think) Ath3k Bluetooth devices initialise with
one device ID when they don't have firmware, then initialise with a
different one once they do. These two states are handled using
different drivers. This seems like almost identical behaviour and
looks like it could be handled the same way. The code here looks like
it's just using the common boilerplate pci device initialisation code
from ath9k before doing it's own completely separate thing including
having PCI driver data in a different format to the rest of the ath9k
driver.
> > Is there anything you're using from ath9k
> > other than the eeprom file naming? and is that really useful? Won't
> > the eeprom files be device specific and therefore could always use the
> > device name fallback?
> Please take a look at the commit message. Unfortunately the Z1 stores
> its calibration data in a ubi volume, these can't be easily read
> without interfacing with either ubi or the vfs. In the future, simpler
> devices that have it on SPI-NOR in a mtd partition can setup a nvmem
> provider and the code can have a nvmem-consumer. (see attached patch).
Fair enough, I was reading the code as-is, not looking forward to
other possibilities.
> Note: There are also devices with mutliple ath9k pci(e) chips
> (usually one 2.4Ghz and one 5GHz), so a generic "ath9k" name is too
> short and the pciids of both are the same. That's why the pci-bus
> location is currently used for the eeprom name identifier.
I've finally worked out what was bothering me about the code: you look
at the platform data expecting it to be in the ath9k_platform_data
structure, however as far as I can tell, the platform data is only
ever set by reading the eeprom, which doesn't happen when there isn't
one, therefore the eeprom name retrieval will always fall back to
dev_name(). I'm assuming that dev_name() returns something
sufficiently unique to identify multiple different cards in a system.
Thanks,
--
Julian Calaby
Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
^ permalink raw reply
* Re: [PATCH v2 1/2] mt76: mt7615: enable support for mesh
From: Ryder Lee @ 2019-06-02 14:36 UTC (permalink / raw)
To: Felix Fietkau
Cc: Lorenzo Bianconi, Roy Luo, YF Luo, Yiwei Chung, Sean Wang,
Chih-Min Chen, linux-wireless, linux-mediatek, linux-kernel
In-Reply-To: <e459fbc79154da9e0e6e098d2c49a9b17e842f47.1559301203.git.ryder.lee@mediatek.com>
On Fri, 2019-05-31 at 22:09 +0800, Ryder Lee wrote:
> Enable NL80211_IFTYPE_MESH_POINT and update its path.
>
> Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
> ---
> Changes since v2 - remove unused definitions
> ---
> drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
> drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 5 ++++-
> drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 ------
> 4 files changed, 11 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> index 59f604f3161f..f860af6a42da 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
> @@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
> {
> .max = MT7615_MAX_INTERFACES,
> .types = BIT(NL80211_IFTYPE_AP) |
> +#ifdef CONFIG_MAC80211_MESH
> + BIT(NL80211_IFTYPE_MESH_POINT) |
> +#endif
> BIT(NL80211_IFTYPE_STATION)
> }
> };
> @@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
> dev->mt76.antenna_mask = 0xf;
>
> wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
> +#ifdef CONFIG_MAC80211_MESH
> + BIT(NL80211_IFTYPE_MESH_POINT) |
> +#endif
> BIT(NL80211_IFTYPE_AP);
>
> ret = mt76_register_device(&dev->mt76, true, mt7615_rates,
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> index b0bb7cc12385..585e67fa2728 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
> @@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
>
> switch (type) {
> case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_MESH_POINT:
> /* ap use hw bssid 0 and ext bssid */
> if (~mask & BIT(HW_BSSID_0))
> return HW_BSSID_0;
> diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> index 43f70195244c..8b8db526cb16 100644
> --- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> +++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
> @@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
>
> switch (vif->type) {
> case NL80211_IFTYPE_AP:
> + case NL80211_IFTYPE_MESH_POINT:
> tx_wlan_idx = mvif->sta.wcid.idx;
> conn_type = CONNECTION_INFRA_AP;
> break;
> @@ -968,7 +969,8 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
> .rx_wtbl = {
> .tag = cpu_to_le16(WTBL_RX),
> .len = cpu_to_le16(sizeof(struct wtbl_rx)),
> - .rca1 = vif->type != NL80211_IFTYPE_AP,
> + .rca1 = vif->type != (NL80211_IFTYPE_AP ||
> + NL80211_IFTYPE_MESH_POINT),
Oops, this expression is wrong. I will fix it in v3.
Sorry for the inconvenience.
Ryder
^ permalink raw reply
* Re: [EXT] INFO: trying to register non-static key in del_timer_sync (2)
From: Dmitry Vyukov @ 2019-06-03 5:20 UTC (permalink / raw)
To: Ganapathi Bhat
Cc: syzbot, amitkarwar@gmail.com, andreyknvl@google.com,
davem@davemloft.net, huxinming820@gmail.com, kvalo@codeaurora.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
nishants@marvell.com, syzkaller-bugs@googlegroups.com
In-Reply-To: <MN2PR18MB263783F52CAD4A335FD8BB34A01A0@MN2PR18MB2637.namprd18.prod.outlook.com>
On Sat, Jun 1, 2019 at 7:52 PM Ganapathi Bhat <gbhat@marvell.com> wrote:
>
> Hi syzbot,
>
> >
> > syzbot found the following crash on:
> >
> As per the link(https://syzkaller.appspot.com/bug?extid=dc4127f950da51639216), the issue is fixed; Is it OK? Let us know if we need to do something?
Hi Ganapathi,
The "fixed" status relates to the similar past bug that was reported
and fixed more than a year ago:
https://groups.google.com/forum/#!msg/syzkaller-bugs/3YnGX1chF2w/jeQjeihtBAAJ
https://syzkaller.appspot.com/bug?id=b4b5c74c57c4b69f4fff86131abb799106182749
This one is still well alive and kicking, with 1200+ crashes and the
last one happened less then 30min ago.
^ permalink raw reply
* [PATCH v3 2/2] mt76: mt7615: fix slow performance when enable encryption
From: Ryder Lee @ 2019-06-03 6:08 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, Chih-Min Chen,
linux-wireless, linux-mediatek, linux-kernel, Ryder Lee
In-Reply-To: <a1ff446dfc06e2443552e7ec2d754099aacce7df.1559541944.git.ryder.lee@mediatek.com>
Fix wrong WCID assignment and add RKV (RX Key of this entry is valid)
flag to check if peer uses the same configuration with previous
handshaking.
If the configuration is mismatch, WTBL indicates a “cipher mismatch”
to stop SEC decryption to prevent the packet from damage.
Suggested-by: YF Luo <yf.luo@mediatek.com>
Suggested-by: Yiwei Chung <yiwei.chung@mediatek.com>
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
Changes since v3 - none
Changes since v2 - none
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 16 ++++++++++------
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 2 +-
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 1 +
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index f860af6a42da..b3e08154ccbe 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -62,16 +62,11 @@ static void mt7615_mac_init(struct mt7615_dev *dev)
MT_AGG_ARCR_RATE_DOWN_RATIO_EN |
FIELD_PREP(MT_AGG_ARCR_RATE_DOWN_RATIO, 1) |
FIELD_PREP(MT_AGG_ARCR_RATE_UP_EXTRA_TH, 4)));
-
- dev->mt76.global_wcid.idx = MT7615_WTBL_RESERVED;
- dev->mt76.global_wcid.hw_key_idx = -1;
- rcu_assign_pointer(dev->mt76.wcid[MT7615_WTBL_RESERVED],
- &dev->mt76.global_wcid);
}
static int mt7615_init_hardware(struct mt7615_dev *dev)
{
- int ret;
+ int ret, idx;
mt76_wr(dev, MT_INT_SOURCE_CSR, ~0);
@@ -98,6 +93,15 @@ static int mt7615_init_hardware(struct mt7615_dev *dev)
mt7615_mcu_ctrl_pm_state(dev, 0);
mt7615_mcu_del_wtbl_all(dev);
+ /* Beacon and mgmt frames should occupy wcid 0 */
+ idx = mt76_wcid_alloc(dev->mt76.wcid_mask, MT7615_WTBL_STA - 1);
+ if (idx)
+ return -ENOSPC;
+
+ dev->mt76.global_wcid.idx = idx;
+ dev->mt76.global_wcid.hw_key_idx = -1;
+ rcu_assign_pointer(dev->mt76.wcid[idx], &dev->mt76.global_wcid);
+
return 0;
}
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index 585e67fa2728..2cdd339453c8 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -95,7 +95,7 @@ static int mt7615_add_interface(struct ieee80211_hw *hw,
dev->vif_mask |= BIT(mvif->idx);
dev->omac_mask |= BIT(mvif->omac_idx);
- idx = MT7615_WTBL_RESERVED - 1 - mvif->idx;
+ idx = MT7615_WTBL_RESERVED - mvif->idx;
mvif->sta.wcid.idx = idx;
mvif->sta.wcid.hw_key_idx = -1;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index e82297048449..b3802f18b37b 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -882,6 +882,7 @@ int mt7615_mcu_set_wtbl_key(struct mt7615_dev *dev, int wcid,
if (cipher == MT_CIPHER_NONE && key)
return -EOPNOTSUPP;
+ req.key.rkv = 1;
req.key.cipher_id = cipher;
req.key.key_id = key->keyidx;
req.key.key_len = key->keylen;
--
2.18.0
^ permalink raw reply related
* [PATCH v3 1/2] mt76: mt7615: enable support for mesh
From: Ryder Lee @ 2019-06-03 6:08 UTC (permalink / raw)
To: Felix Fietkau, Lorenzo Bianconi
Cc: Roy Luo, YF Luo, Yiwei Chung, Sean Wang, Chih-Min Chen,
linux-wireless, linux-mediatek, linux-kernel, Ryder Lee
Enable NL80211_IFTYPE_MESH_POINT and update its path.
Signed-off-by: Ryder Lee <ryder.lee@mediatek.com>
---
Changes since v3 - fix a wrong expression
Changes since v2 - remove unused definitions
---
drivers/net/wireless/mediatek/mt76/mt7615/init.c | 6 ++++++
drivers/net/wireless/mediatek/mt76/mt7615/main.c | 1 +
drivers/net/wireless/mediatek/mt76/mt7615/mcu.c | 4 +++-
drivers/net/wireless/mediatek/mt76/mt7615/mcu.h | 6 ------
4 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/init.c b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
index 59f604f3161f..f860af6a42da 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/init.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/init.c
@@ -133,6 +133,9 @@ static const struct ieee80211_iface_limit if_limits[] = {
{
.max = MT7615_MAX_INTERFACES,
.types = BIT(NL80211_IFTYPE_AP) |
+#ifdef CONFIG_MAC80211_MESH
+ BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
BIT(NL80211_IFTYPE_STATION)
}
};
@@ -195,6 +198,9 @@ int mt7615_register_device(struct mt7615_dev *dev)
dev->mt76.antenna_mask = 0xf;
wiphy->interface_modes = BIT(NL80211_IFTYPE_STATION) |
+#ifdef CONFIG_MAC80211_MESH
+ BIT(NL80211_IFTYPE_MESH_POINT) |
+#endif
BIT(NL80211_IFTYPE_AP);
ret = mt76_register_device(&dev->mt76, true, mt7615_rates,
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/main.c b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
index b0bb7cc12385..585e67fa2728 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/main.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/main.c
@@ -37,6 +37,7 @@ static int get_omac_idx(enum nl80211_iftype type, u32 mask)
switch (type) {
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
/* ap use hw bssid 0 and ext bssid */
if (~mask & BIT(HW_BSSID_0))
return HW_BSSID_0;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
index 43f70195244c..e82297048449 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.c
@@ -754,6 +754,7 @@ int mt7615_mcu_set_bss_info(struct mt7615_dev *dev,
switch (vif->type) {
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
tx_wlan_idx = mvif->sta.wcid.idx;
conn_type = CONNECTION_INFRA_AP;
break;
@@ -968,7 +969,7 @@ int mt7615_mcu_add_wtbl(struct mt7615_dev *dev, struct ieee80211_vif *vif,
.rx_wtbl = {
.tag = cpu_to_le16(WTBL_RX),
.len = cpu_to_le16(sizeof(struct wtbl_rx)),
- .rca1 = vif->type != NL80211_IFTYPE_AP,
+ .rca1 = vif->type == NL80211_IFTYPE_STATION,
.rca2 = 1,
.rv = 1,
},
@@ -1042,6 +1043,7 @@ static void sta_rec_convert_vif_type(enum nl80211_iftype type, u32 *conn_type)
{
switch (type) {
case NL80211_IFTYPE_AP:
+ case NL80211_IFTYPE_MESH_POINT:
if (conn_type)
*conn_type = CONNECTION_INFRA_STA;
break;
diff --git a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
index e96efb13fa4d..0915cb735699 100644
--- a/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
+++ b/drivers/net/wireless/mediatek/mt76/mt7615/mcu.h
@@ -105,25 +105,19 @@ enum {
#define STA_TYPE_STA BIT(0)
#define STA_TYPE_AP BIT(1)
#define STA_TYPE_ADHOC BIT(2)
-#define STA_TYPE_TDLS BIT(3)
#define STA_TYPE_WDS BIT(4)
#define STA_TYPE_BC BIT(5)
#define NETWORK_INFRA BIT(16)
#define NETWORK_P2P BIT(17)
#define NETWORK_IBSS BIT(18)
-#define NETWORK_MESH BIT(19)
-#define NETWORK_BOW BIT(20)
#define NETWORK_WDS BIT(21)
#define CONNECTION_INFRA_STA (STA_TYPE_STA | NETWORK_INFRA)
#define CONNECTION_INFRA_AP (STA_TYPE_AP | NETWORK_INFRA)
#define CONNECTION_P2P_GC (STA_TYPE_STA | NETWORK_P2P)
#define CONNECTION_P2P_GO (STA_TYPE_AP | NETWORK_P2P)
-#define CONNECTION_MESH_STA (STA_TYPE_STA | NETWORK_MESH)
-#define CONNECTION_MESH_AP (STA_TYPE_AP | NETWORK_MESH)
#define CONNECTION_IBSS_ADHOC (STA_TYPE_ADHOC | NETWORK_IBSS)
-#define CONNECTION_TDLS (STA_TYPE_STA | NETWORK_INFRA | STA_TYPE_TDLS)
#define CONNECTION_WDS (STA_TYPE_WDS | NETWORK_WDS)
#define CONNECTION_INFRA_BC (STA_TYPE_BC | NETWORK_INFRA)
--
2.18.0
^ permalink raw reply related
* RE: [EXT] INFO: trying to register non-static key in del_timer_sync (2)
From: Ganapathi Bhat @ 2019-06-03 8:41 UTC (permalink / raw)
To: Dmitry Vyukov
Cc: syzbot, amitkarwar@gmail.com, andreyknvl@google.com,
davem@davemloft.net, huxinming820@gmail.com, kvalo@codeaurora.org,
linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-wireless@vger.kernel.org, netdev@vger.kernel.org,
nishants@marvell.com, syzkaller-bugs@googlegroups.com
In-Reply-To: <CACT4Y+aQzBkAq86Hx4jNFnAUzjXnq8cS2NZKfeCaFrZa__g-cg@mail.gmail.com>
Hi Dmitry,
> The "fixed" status relates to the similar past bug that was reported and fixed
> more than a year ago:
Oh OK; We understood the issue, working on a change to fix this;
Thanks,
Ganapathi
^ permalink raw reply
* In A Nutshell
From: Emissary @ 2019-05-30 21:23 UTC (permalink / raw)
To: linux-wireless
Hello,
We have a private business proposition for you,contact me for more details.
Thank you,
Datuk.
5.30.19/135p/28wwe.5
^ permalink raw reply
* Re: [RFC 0/8] nl80211: add 6GHz band support
From: Arend Van Spriel @ 2019-06-03 10:39 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless
In-Reply-To: <9ba78df6-18a3-5c1c-6c57-3fa71531b460@broadcom.com>
On 5/27/2019 10:46 PM, Arend Van Spriel wrote:
> On 5/24/2019 8:38 PM, Arend Van Spriel wrote:
>> On May 24, 2019 1:56:43 PM Johannes Berg <johannes@sipsolutions.net>
>> wrote:
>>
>>> Hi Arend,
>>>
>>> On Mon, 2019-05-20 at 14:00 +0200, Arend van Spriel wrote:
>>>> In 802.11ax D4.0 a new band has been proposed. This series contains
>>>> changes to cfg80211 for supporting this band. With 2GHz and 5GHz there
>>>> was no overlap in channel number. However, this new band has channel
>>>> numbers with a range from 1 up to 253.
>>>
>>> At the wireless workshop in Prague, we looked at this and sort of
>>> decided that it'd be better to put all the 6 GHz channels into the 5 GHz
>>> "band" in nl80211, to avoid all the "5 || 6" since they're really the
>>> same except for very specific places like scanning.
>>
>> Would have liked to be there, but attending is no longer an option for
>> me. We now have two autistic, non-verbal children and I am the primary
>> caregiver for the oldest because my wife can't handle him. Guess I
>> should have checked the workshop notes before working on this :-) Do
>> you have URL?
>
> Found the netdev wifi workshop page and looked over the slides quickly,
> but the notes page is pretty empty ;-)
>
>> Agree that most functional requirements for 6 GHz are same as 5 GHz.
>> There are some 6 GHz specifics about beaconing as well.
>
> This came up in discussion with my colleagues today and I would say from
> mac80211 perspective there is more to it than just scanning. In short
> the 6GHz band is for HE-only operation so for example only HE rates may
> be used. As the bitrates are in ieee80211_supported_band having a
> separate 6GHz band seems to have a (slight?) advantage.
Hi, Johannes
Any thoughts on this?
Regards,
Arend
^ permalink raw reply
* [PATCH] Revert "cfg80211: fix processing world regdomain when non modular"
From: Hodaszi, Robert @ 2019-06-03 11:41 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless@vger.kernel.org
This reverts commit 96cce12ff6e0bc9d9fcb2235e08b7fc150f96fd2.
Re-triggering a reg_process_hint with the last request on all events,
can make the regulatory domain fail in case of multiple WiFi modules. On
slower boards (espacially with mdev), enumeration of the WiFi modules
can end up in an intersected regulatory domain, and user cannot set it
with 'iw reg set' anymore.
This is happening, because:
- 1st module enumerates, queues up a regulatory request
- request gets processed by __reg_process_hint_driver():
- checks if previous was set by CORE -> yes
- checks if regulator domain changed -> yes, from '00' to e.g. 'US'
-> sends request to the 'crda'
- 2nd module enumerates, queues up a regulator request (which triggers
the reg_todo() work)
- reg_todo() -> reg_process_pending_hints() sees, that the last request
is not processed yet, so it tries to process it again.
__reg_process_hint driver() will run again, and:
- checks if the last request's initiator was the core -> no, it was
the driver (1st WiFi module)
- checks, if the previous initiator was the driver -> yes
- checks if the regulator domain changed -> yes, it was '00' (set by
core, and crda call did not return yet), and should be changed to 'US'
------> __reg_process_hint_driver calls an intersect
Besides, the reg_process_hint call with the last request is meaningless
since the crda call has a timeout work. If that timeout expires, the
first module's request will lost.
Signed-off-by: Robert Hodaszi <robert.hodaszi@digi.com>
---
net/wireless/reg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index 4831ad745f91..b00ebf6fc696 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2788,7 +2788,7 @@ static void reg_process_pending_hints(void)
/* When last_request->processed becomes true this will be rescheduled */
if (lr && !lr->processed) {
- reg_process_hint(lr);
+ REG_DBG_PRINT("Pending regulatory request, waiting for it to be processed...\n");
return;
}
^ permalink raw reply related
* INFO: trying to register non-static key in mwifiex_unregister_dev
From: syzbot @ 2019-06-03 13:31 UTC (permalink / raw)
To: amitkarwar, andreyknvl, davem, gbhat, huxinming820, kvalo,
linux-kernel, linux-usb, linux-wireless, netdev, nishants,
syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 69bbe8c7 usb-fuzzer: main usb gadget fuzzer driver
git tree: https://github.com/google/kasan.git usb-fuzzer
console output: https://syzkaller.appspot.com/x/log.txt?x=1448d0f2a00000
kernel config: https://syzkaller.appspot.com/x/.config?x=193d8457178b3229
dashboard link: https://syzkaller.appspot.com/bug?extid=373e6719b49912399d21
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16e57ca6a00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1106eda2a00000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+373e6719b49912399d21@syzkaller.appspotmail.com
usb 1-1: Using ep0 maxpacket: 8
usb 1-1: config 0 has an invalid interface number: 182 but max is 0
usb 1-1: config 0 has no interface number 0
usb 1-1: New USB device found, idVendor=1286, idProduct=2052,
bcdDevice=61.43
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
usb 1-1: Direct firmware load for mrvl/usbusb8997_combo_v4.bin failed with
error -2
usb 1-1: Failed to get firmware mrvl/usbusb8997_combo_v4.bin
usb 1-1: info: _mwifiex_fw_dpc: unregister device
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.2.0-rc1+ #10
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Workqueue: events request_firmware_work_func
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0xca/0x13e lib/dump_stack.c:113
assign_lock_key kernel/locking/lockdep.c:774 [inline]
register_lock_class+0x11ae/0x1240 kernel/locking/lockdep.c:1083
__lock_acquire+0x11d/0x5340 kernel/locking/lockdep.c:3673
lock_acquire+0x100/0x2b0 kernel/locking/lockdep.c:4302
del_timer_sync+0x3a/0x130 kernel/time/timer.c:1277
mwifiex_usb_cleanup_tx_aggr
drivers/net/wireless/marvell/mwifiex/usb.c:1358 [inline]
mwifiex_unregister_dev+0x416/0x690
drivers/net/wireless/marvell/mwifiex/usb.c:1370
_mwifiex_fw_dpc+0x577/0xda0 drivers/net/wireless/marvell/mwifiex/main.c:651
request_firmware_work_func+0x126/0x242
drivers/base/firmware_loader/main.c:785
process_one_work+0x905/0x1570 kernel/workqueue.c:2268
worker_thread+0x96/0xe20 kernel/workqueue.c:2414
kthread+0x30b/0x410 kernel/kthread.c:254
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
------------[ cut here ]------------
ODEBUG: assert_init not available (active state 0) object type: timer_list
hint: 0x0
WARNING: CPU: 1 PID: 21 at lib/debugobjects.c:325
debug_print_object+0x160/0x250 lib/debugobjects.c:325
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* Re: [PATCH] carl9170: Fix misuse of device driver API
From: Alan Stern @ 2019-06-03 14:10 UTC (permalink / raw)
To: Christian Lamparter; +Cc: linux-wireless, Kalle Valo, USB list
In-Reply-To: <20190602090622.13656-1-chunkeey@gmail.com>
On Sun, 2 Jun 2019, Christian Lamparter wrote:
> This patch follows Alan Stern's recent patch:
> "p54: Fix race between disconnect and firmware loading"
>
> that overhauled carl9170 buggy firmware loading and driver
> unbinding procedures.
>
> Since the carl9170 code was adapted from p54 it uses the
> same functions and is likely to have the same problem, but
> it's just that the syzbot hasn't reproduce them (yet).
>
> a summary from the changes (copied from the p54 patch):
> * Call usb_driver_release_interface() rather than
> device_release_driver().
>
> * Lock udev (the interface's parent) before unbinding the
> driver instead of locking udev->parent.
>
> * During the firmware loading process, take a reference
> to the USB interface instead of the USB device.
>
> * Don't take an unnecessary reference to the device during
> probe (and then don't drop it during disconnect).
>
> and
>
> * Make sure to prevent use-after-free bugs by explicitly
> setting the driver context to NULL after signaling the
> completion.
>
> Cc: <stable@vger.kernel.org>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
This basically looks right. However...
> ---
> drivers/net/wireless/ath/carl9170/usb.c | 26 ++++++++++++-------------
> 1 file changed, 12 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/net/wireless/ath/carl9170/usb.c b/drivers/net/wireless/ath/carl9170/usb.c
> index e7c3f3b8457d..297a7b877d31 100644
> --- a/drivers/net/wireless/ath/carl9170/usb.c
> +++ b/drivers/net/wireless/ath/carl9170/usb.c
> @@ -128,6 +128,8 @@ static const struct usb_device_id carl9170_usb_ids[] = {
> };
> MODULE_DEVICE_TABLE(usb, carl9170_usb_ids);
>
> +static struct usb_driver carl9170_driver;
> +
> static void carl9170_usb_submit_data_urb(struct ar9170 *ar)
> {
> struct urb *urb;
> @@ -966,7 +968,7 @@ static int carl9170_usb_init_device(struct ar9170 *ar)
>
> static void carl9170_usb_firmware_failed(struct ar9170 *ar)
> {
> - struct device *parent = ar->udev->dev.parent;
> + struct usb_interface *intf = ar->intf;
> struct usb_device *udev;
It looks a little strange to initialize intf in the definition but to
initialize udev afterward. Nothing wrong with it, just odd.
>
> /*
> @@ -978,16 +980,15 @@ static void carl9170_usb_firmware_failed(struct ar9170 *ar)
> udev = ar->udev;
>
> complete(&ar->fw_load_wait);
> + /* at this point 'ar' could be already freed. Don't use it anymore */
> + ar = NULL;
>
> /* unbind anything failed */
> - if (parent)
> - device_lock(parent);
> -
> - device_release_driver(&udev->dev);
> - if (parent)
> - device_unlock(parent);
> + usb_lock_device(udev);
> + usb_driver_release_interface(&carl9170_driver, intf);
> + usb_unlock_device(udev);
>
> - usb_put_dev(udev);
> + usb_put_intf(intf);
> }
>
> static void carl9170_usb_firmware_finish(struct ar9170 *ar)
> @@ -1009,7 +1010,7 @@ static void carl9170_usb_firmware_finish(struct ar9170 *ar)
> goto err_unrx;
>
> complete(&ar->fw_load_wait);
> - usb_put_dev(ar->udev);
> + usb_put_intf(ar->intf);
But this could be a problem. As soon as the complete() call runs, ar
might be deallocated. The code should copy ar->intf before calling
complete().
Alan Stern
> return;
>
> err_unrx:
> @@ -1052,7 +1053,6 @@ static int carl9170_usb_probe(struct usb_interface *intf,
> return PTR_ERR(ar);
>
> udev = interface_to_usbdev(intf);
> - usb_get_dev(udev);
> ar->udev = udev;
> ar->intf = intf;
> ar->features = id->driver_info;
> @@ -1094,15 +1094,14 @@ static int carl9170_usb_probe(struct usb_interface *intf,
> atomic_set(&ar->rx_anch_urbs, 0);
> atomic_set(&ar->rx_pool_urbs, 0);
>
> - usb_get_dev(ar->udev);
> + usb_get_intf(intf);
>
> carl9170_set_state(ar, CARL9170_STOPPED);
>
> err = request_firmware_nowait(THIS_MODULE, 1, CARL9170FW_NAME,
> &ar->udev->dev, GFP_KERNEL, ar, carl9170_usb_firmware_step2);
> if (err) {
> - usb_put_dev(udev);
> - usb_put_dev(udev);
> + usb_put_intf(intf);
> carl9170_free(ar);
> }
> return err;
> @@ -1131,7 +1130,6 @@ static void carl9170_usb_disconnect(struct usb_interface *intf)
>
> carl9170_release_firmware(ar);
> carl9170_free(ar);
> - usb_put_dev(udev);
> }
>
> #ifdef CONFIG_PM
>
^ permalink raw reply
* Re: INFO: trying to register non-static key in mwifiex_unregister_dev
From: Andrey Konovalov @ 2019-06-03 14:31 UTC (permalink / raw)
To: syzbot
Cc: amitkarwar, David S. Miller, gbhat, huxinming820, Kalle Valo,
LKML, USB list, linux-wireless, netdev, nishants, syzkaller-bugs
In-Reply-To: <00000000000044cec9058a6b6003@google.com>
On Mon, Jun 3, 2019 at 3:31 PM syzbot
<syzbot+373e6719b49912399d21@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit: 69bbe8c7 usb-fuzzer: main usb gadget fuzzer driver
> git tree: https://github.com/google/kasan.git usb-fuzzer
> console output: https://syzkaller.appspot.com/x/log.txt?x=1448d0f2a00000
> kernel config: https://syzkaller.appspot.com/x/.config?x=193d8457178b3229
> dashboard link: https://syzkaller.appspot.com/bug?extid=373e6719b49912399d21
> compiler: gcc (GCC) 9.0.0 20181231 (experimental)
> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=16e57ca6a00000
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=1106eda2a00000
>
> IMPORTANT: if you fix the bug, please add the following tag to the commit:
> Reported-by: syzbot+373e6719b49912399d21@syzkaller.appspotmail.com
>
> usb 1-1: Using ep0 maxpacket: 8
> usb 1-1: config 0 has an invalid interface number: 182 but max is 0
> usb 1-1: config 0 has no interface number 0
> usb 1-1: New USB device found, idVendor=1286, idProduct=2052,
> bcdDevice=61.43
> usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
> usb 1-1: config 0 descriptor??
> usb 1-1: Direct firmware load for mrvl/usbusb8997_combo_v4.bin failed with
> error -2
> usb 1-1: Failed to get firmware mrvl/usbusb8997_combo_v4.bin
> usb 1-1: info: _mwifiex_fw_dpc: unregister device
> INFO: trying to register non-static key.
> the code is fine but needs lockdep annotation.
> turning off the locking correctness validator.
> CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.2.0-rc1+ #10
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> Workqueue: events request_firmware_work_func
> Call Trace:
> __dump_stack lib/dump_stack.c:77 [inline]
> dump_stack+0xca/0x13e lib/dump_stack.c:113
> assign_lock_key kernel/locking/lockdep.c:774 [inline]
> register_lock_class+0x11ae/0x1240 kernel/locking/lockdep.c:1083
> __lock_acquire+0x11d/0x5340 kernel/locking/lockdep.c:3673
> lock_acquire+0x100/0x2b0 kernel/locking/lockdep.c:4302
> del_timer_sync+0x3a/0x130 kernel/time/timer.c:1277
> mwifiex_usb_cleanup_tx_aggr
> drivers/net/wireless/marvell/mwifiex/usb.c:1358 [inline]
> mwifiex_unregister_dev+0x416/0x690
> drivers/net/wireless/marvell/mwifiex/usb.c:1370
> _mwifiex_fw_dpc+0x577/0xda0 drivers/net/wireless/marvell/mwifiex/main.c:651
> request_firmware_work_func+0x126/0x242
> drivers/base/firmware_loader/main.c:785
> process_one_work+0x905/0x1570 kernel/workqueue.c:2268
> worker_thread+0x96/0xe20 kernel/workqueue.c:2414
> kthread+0x30b/0x410 kernel/kthread.c:254
> ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
> ------------[ cut here ]------------
> ODEBUG: assert_init not available (active state 0) object type: timer_list
> hint: 0x0
> WARNING: CPU: 1 PID: 21 at lib/debugobjects.c:325
> debug_print_object+0x160/0x250 lib/debugobjects.c:325
>
>
> ---
> This bug is generated by a bot. It may contain errors.
> See https://goo.gl/tpsmEJ for more information about syzbot.
> syzbot engineers can be reached at syzkaller@googlegroups.com.
>
> syzbot will keep track of this bug report. See:
> https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
> syzbot can test patches for this bug, for details see:
> https://goo.gl/tpsmEJ#testing-patches
#syz dup: INFO: trying to register non-static key in del_timer_sync (2)
^ permalink raw reply
* Re: [PATCH] ath10k: avoid leaving .bss_info_changed prematurely
From: Kalle Valo @ 2019-06-03 14:48 UTC (permalink / raw)
To: Sven Eckelmann; +Cc: ath10k, linux-wireless, Sven Eckelmann, Sriram R
In-Reply-To: <20190311083107.311-1-sven@narfation.org>
Sven Eckelmann <sven@narfation.org> writes:
> From: Sven Eckelmann <seckelmann@datto.com>
>
> ath10k_bss_info_changed() handles various events from the upper layers. It
> parses the changed bitfield and then configures the driver/firmware
> accordingly. Each detected event is handled in a separate scope which is
> independent of each other - but in the same function.
>
> The commit f279294e9ee2 ("ath10k: add support for configuring management
> packet rate") changed this behavior by returning from this function
> prematurely when some precondition was not fulfilled. All new event
> handlers added after the BSS_CHANGED_BASIC_RATES event handler would then
> also be skipped.
>
> Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
> ---
> Cc: Kalle Valo <kvalo@codeaurora.org>
> Cc: Sriram R <srirrama@codeaurora.org>
>
> Only compile tested
Unfortunately doesn't apply anymore, please rebase.
Applying: ath10k: avoid leaving .bss_info_changed prematurely
Using index info to reconstruct a base tree...
M drivers/net/wireless/ath/ath10k/mac.c
Falling back to patching base and 3-way merge...
Auto-merging drivers/net/wireless/ath/ath10k/mac.c
CONFLICT (content): Merge conflict in drivers/net/wireless/ath/ath10k/mac.c
Recorded preimage for 'drivers/net/wireless/ath/ath10k/mac.c'
error: Failed to merge in the changes.
Patch failed at 0001 ath10k: avoid leaving .bss_info_changed prematurely
--
Kalle Valo
^ permalink raw reply
* [PATCH v2] ath10k: avoid leaving .bss_info_changed prematurely
From: Sven Eckelmann @ 2019-06-03 15:25 UTC (permalink / raw)
To: ath10k; +Cc: linux-wireless, Sven Eckelmann, Kalle Valo, Sriram R
From: Sven Eckelmann <seckelmann@datto.com>
ath10k_bss_info_changed() handles various events from the upper layers. It
parses the changed bitfield and then configures the driver/firmware
accordingly. Each detected event is handled in a separate scope which is
independent of each other - but in the same function.
The commit f279294e9ee2 ("ath10k: add support for configuring management
packet rate") changed this behavior by returning from this function
prematurely when some precondition was not fulfilled. All new event
handlers added after the BSS_CHANGED_BASIC_RATES event handler would then
also be skipped.
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
---
Cc: Kalle Valo <kvalo@codeaurora.org>
Cc: Sriram R <srirrama@codeaurora.org>
Only compile tested
v2:
* rebased on top of commit 9e7251fa3897 ("ath10k: Check tx_stats before
use it")
drivers/net/wireless/ath/ath10k/mac.c | 64 ++++++++++++++++-----------
1 file changed, 38 insertions(+), 26 deletions(-)
diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 98a7842e09b1..90f59117a04d 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -5582,6 +5582,40 @@ static void ath10k_configure_filter(struct ieee80211_hw *hw,
mutex_unlock(&ar->conf_mutex);
}
+static void ath10k_recalculate_mgmt_rate(struct ath10k *ar,
+ struct ieee80211_vif *vif)
+{
+ struct ath10k_vif *arvif = (void *)vif->drv_priv;
+ const struct ieee80211_supported_band *sband;
+ struct cfg80211_chan_def def;
+ u8 basic_rate_idx;
+ int hw_rate_code;
+ u32 vdev_param;
+ u16 bitrate;
+ int ret;
+
+ lockdep_assert_held(&ar->conf_mutex);
+
+ if (WARN_ON(ath10k_mac_vif_chan(vif, &def)))
+ return;
+
+ sband = ar->hw->wiphy->bands[def.chan->band];
+ basic_rate_idx = ffs(vif->bss_conf.basic_rates) - 1;
+ bitrate = sband->bitrates[basic_rate_idx].bitrate;
+
+ hw_rate_code = ath10k_mac_get_rate_hw_value(bitrate);
+ if (hw_rate_code < 0) {
+ ath10k_warn(ar, "bitrate not supported %d\n", bitrate);
+ return;
+ }
+
+ vdev_param = ar->wmi.vdev_param->mgmt_rate;
+ ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
+ hw_rate_code);
+ if (ret)
+ ath10k_warn(ar, "failed to set mgmt tx rate %d\n", ret);
+}
+
static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
struct ieee80211_vif *vif,
struct ieee80211_bss_conf *info,
@@ -5592,10 +5626,9 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
struct cfg80211_chan_def def;
u32 vdev_param, pdev_param, slottime, preamble;
u16 bitrate, hw_value;
- u8 rate, basic_rate_idx, rateidx;
- int ret = 0, hw_rate_code, mcast_rate;
+ u8 rate, rateidx;
+ int ret = 0, mcast_rate;
enum nl80211_band band;
- const struct ieee80211_supported_band *sband;
mutex_lock(&ar->conf_mutex);
@@ -5819,29 +5852,8 @@ static void ath10k_bss_info_changed(struct ieee80211_hw *hw,
arvif->vdev_id, ret);
}
- if (changed & BSS_CHANGED_BASIC_RATES) {
- if (WARN_ON(ath10k_mac_vif_chan(vif, &def))) {
- mutex_unlock(&ar->conf_mutex);
- return;
- }
-
- sband = ar->hw->wiphy->bands[def.chan->band];
- basic_rate_idx = ffs(vif->bss_conf.basic_rates) - 1;
- bitrate = sband->bitrates[basic_rate_idx].bitrate;
-
- hw_rate_code = ath10k_mac_get_rate_hw_value(bitrate);
- if (hw_rate_code < 0) {
- ath10k_warn(ar, "bitrate not supported %d\n", bitrate);
- mutex_unlock(&ar->conf_mutex);
- return;
- }
-
- vdev_param = ar->wmi.vdev_param->mgmt_rate;
- ret = ath10k_wmi_vdev_set_param(ar, arvif->vdev_id, vdev_param,
- hw_rate_code);
- if (ret)
- ath10k_warn(ar, "failed to set mgmt tx rate %d\n", ret);
- }
+ if (changed & BSS_CHANGED_BASIC_RATES)
+ ath10k_recalculate_mgmt_rate(ar, vif);
mutex_unlock(&ar->conf_mutex);
}
--
2.20.1
^ permalink raw reply related
* [PATCH v2 3/3] brcmfmac: sdio: Disable auto-tuning around commands expected to fail
From: Douglas Anderson @ 2019-06-03 18:37 UTC (permalink / raw)
To: Ulf Hansson, Kalle Valo, Adrian Hunter, Arend van Spriel
Cc: brcm80211-dev-list.pdl, linux-rockchip, Double Lo, briannorris,
linux-wireless, Naveen Gupta, Madhan Mohan R, mka, Wright Feng,
Chi-Hsien Lin, netdev, brcm80211-dev-list, Douglas Anderson,
David S. Miller, Franky Lin, linux-kernel, Hante Meuleman,
YueHaibing, Michael Trimarchi
In-Reply-To: <20190603183740.239031-1-dianders@chromium.org>
There are certain cases, notably when transitioning between sleep and
active state, when Broadcom SDIO WiFi cards will produce errors on the
SDIO bus. This is evident from the source code where you can see that
we try commands in a loop until we either get success or we've tried
too many times. The comment in the code reinforces this by saying
"just one write attempt may fail"
Unfortunately these failures sometimes end up causing an "-EILSEQ"
back to the core which triggers a retuning of the SDIO card and that
blocks all traffic to the card until it's done.
Let's disable retuning around the commands we expect might fail.
Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2: None
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 4a750838d8cd..e0cfcc078a54 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -16,6 +16,7 @@
#include <linux/mmc/sdio_ids.h>
#include <linux/mmc/sdio_func.h>
#include <linux/mmc/card.h>
+#include <linux/mmc/core.h>
#include <linux/semaphore.h>
#include <linux/firmware.h>
#include <linux/module.h>
@@ -697,6 +698,7 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
bmask = SBSDIO_FUNC1_SLEEPCSR_KSO_MASK;
}
+ mmc_expect_errors_begin(bus->sdiodev->func1->card->host);
do {
/* reliable KSO bit set/clr:
* the sdiod sleep write access is synced to PMU 32khz clk
@@ -719,6 +721,7 @@ brcmf_sdio_kso_control(struct brcmf_sdio *bus, bool on)
&err);
} while (try_cnt++ < MAX_KSO_ATTEMPTS);
+ mmc_expect_errors_end(bus->sdiodev->func1->card->host);
if (try_cnt > 2)
brcmf_dbg(SDIO, "try_cnt=%d rd_val=0x%x err=%d\n", try_cnt,
--
2.22.0.rc1.311.g5d7573a151-goog
^ permalink raw reply related
* [PATCH v2 2/3] mmc: core: API for temporarily disabling auto-retuning due to errors
From: Douglas Anderson @ 2019-06-03 18:37 UTC (permalink / raw)
To: Ulf Hansson, Kalle Valo, Adrian Hunter, Arend van Spriel
Cc: brcm80211-dev-list.pdl, linux-rockchip, Double Lo, briannorris,
linux-wireless, Naveen Gupta, Madhan Mohan R, mka, Wright Feng,
Chi-Hsien Lin, netdev, brcm80211-dev-list, Douglas Anderson,
linux-mmc, linux-kernel, Shawn Lin, Wolfram Sang, Avri Altman
In-Reply-To: <20190603183740.239031-1-dianders@chromium.org>
Normally when the MMC core sees an "-EILSEQ" error returned by a host
controller then it will trigger a retuning of the card. This is
generally a good idea.
However, if a command is expected to sometimes cause transfer errors
then these transfer errors shouldn't cause a re-tuning. This
re-tuning will be a needless waste of time. One example case where a
transfer is expected to cause errors is when transitioning between
idle (sometimes referred to as "sleep" in Broadcom code) and active
state on certain Broadcom WiFi cards. Specifically if the card was
already transitioning between states when the command was sent it
could cause an error on the SDIO bus.
Let's add an API that the SDIO card drivers can call that will
temporarily disable the auto-tuning functionality. Then we can add a
call to this in the Broadcom WiFi driver and any other driver that
might have similar needs.
NOTE: this makes the assumption that the card is already tuned well
enough that it's OK to disable the auto-retuning during one of these
error-prone situations. Presumably the driver code performing the
error-prone transfer knows how to recover / retry from errors. ...and
after we can get back to a state where transfers are no longer
error-prone then we can enable the auto-retuning again. If we truly
find ourselves in a case where the card needs to be retuned sometimes
to handle one of these error-prone transfers then we can always try a
few transfers first without auto-retuning and then re-try with
auto-retuning if the first few fail.
Without this change on rk3288-veyron-minnie I periodically see this in
the logs of a machine just sitting there idle:
dwmmc_rockchip ff0d0000.dwmmc: Successfully tuned phase to XYZ
Fixes: bd11e8bd03ca ("mmc: core: Flag re-tuning is needed on CRC errors")
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Note that are are a whole boatload of different ways that we could
provide an API for the Broadcom WiFi SDIO driver. This patch
illustrates one way but if maintainers feel strongly that this is too
ugly and have a better idea then I can give it a shot too. From a
purist point of view I kinda felt that the "expect errors" really
belonged as part of the mmc_request structure, but getting it into
there meant changing a whole pile of core SD/MMC APIs. Simply adding
it to the host seemed to match the current style better and was a less
intrusive change.
Changes in v2:
- Updated commit message to clarify based on discussion of v1.
drivers/mmc/core/core.c | 27 +++++++++++++++++++++++++--
include/linux/mmc/core.h | 2 ++
include/linux/mmc/host.h | 1 +
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 6db36dc870b5..ba4f71aa8cd9 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -144,8 +144,9 @@ void mmc_request_done(struct mmc_host *host, struct mmc_request *mrq)
int err = cmd->error;
/* Flag re-tuning needed on CRC errors */
- if ((cmd->opcode != MMC_SEND_TUNING_BLOCK &&
- cmd->opcode != MMC_SEND_TUNING_BLOCK_HS200) &&
+ if (cmd->opcode != MMC_SEND_TUNING_BLOCK &&
+ cmd->opcode != MMC_SEND_TUNING_BLOCK_HS200 &&
+ !host->expect_errors &&
(err == -EILSEQ || (mrq->sbc && mrq->sbc->error == -EILSEQ) ||
(mrq->data && mrq->data->error == -EILSEQ) ||
(mrq->stop && mrq->stop->error == -EILSEQ)))
@@ -2163,6 +2164,28 @@ int mmc_sw_reset(struct mmc_host *host)
}
EXPORT_SYMBOL(mmc_sw_reset);
+void mmc_expect_errors_begin(struct mmc_host *host)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&host->lock, flags);
+ WARN_ON(host->expect_errors);
+ host->expect_errors = true;
+ spin_unlock_irqrestore(&host->lock, flags);
+}
+EXPORT_SYMBOL_GPL(mmc_expect_errors_begin);
+
+void mmc_expect_errors_end(struct mmc_host *host)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&host->lock, flags);
+ WARN_ON(!host->expect_errors);
+ host->expect_errors = false;
+ spin_unlock_irqrestore(&host->lock, flags);
+}
+EXPORT_SYMBOL_GPL(mmc_expect_errors_end);
+
static int mmc_rescan_try_freq(struct mmc_host *host, unsigned freq)
{
host->f_init = freq;
diff --git a/include/linux/mmc/core.h b/include/linux/mmc/core.h
index 134a6483347a..02a13abf0cda 100644
--- a/include/linux/mmc/core.h
+++ b/include/linux/mmc/core.h
@@ -178,6 +178,8 @@ int mmc_wait_for_cmd(struct mmc_host *host, struct mmc_command *cmd,
int mmc_hw_reset(struct mmc_host *host);
int mmc_sw_reset(struct mmc_host *host);
+void mmc_expect_errors_begin(struct mmc_host *host);
+void mmc_expect_errors_end(struct mmc_host *host);
void mmc_set_data_timeout(struct mmc_data *data, const struct mmc_card *card);
#endif /* LINUX_MMC_CORE_H */
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 43d0f0c496f6..8d553fb8c834 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -398,6 +398,7 @@ struct mmc_host {
unsigned int retune_now:1; /* do re-tuning at next req */
unsigned int retune_paused:1; /* re-tuning is temporarily disabled */
unsigned int use_blk_mq:1; /* use blk-mq */
+ unsigned int expect_errors:1; /* don't trigger retune upon errors */
int rescan_disable; /* disable card detection */
int rescan_entered; /* used with nonremovable devices */
--
2.22.0.rc1.311.g5d7573a151-goog
^ permalink raw reply related
* [PATCH v2 1/3] Revert "brcmfmac: disable command decode in sdio_aos"
From: Douglas Anderson @ 2019-06-03 18:37 UTC (permalink / raw)
To: Ulf Hansson, Kalle Valo, Adrian Hunter, Arend van Spriel
Cc: brcm80211-dev-list.pdl, linux-rockchip, Double Lo, briannorris,
linux-wireless, Naveen Gupta, Madhan Mohan R, mka, Wright Feng,
Chi-Hsien Lin, netdev, brcm80211-dev-list, Douglas Anderson,
Franky Lin, linux-kernel, Hans de Goede, Hante Meuleman,
YueHaibing, David S. Miller
In-Reply-To: <20190603183740.239031-1-dianders@chromium.org>
This reverts commit 29f6589140a10ece8c1d73f58043ea5b3473ab3e.
After that patch landed I find that my kernel log on
rk3288-veyron-minnie and rk3288-veyron-speedy is filled with:
brcmfmac: brcmf_sdio_bus_sleep: error while changing bus sleep state -110
This seems to happen every time the Broadcom WiFi transitions out of
sleep mode. Reverting the commit fixes the problem for me, so that's
what this patch does.
Note that, in general, the justification in the original commit seemed
a little weak. It looked like someone was testing on a SD card
controller that would sometimes die if there were CRC errors on the
bus. This used to happen back in early days of dw_mmc (the controller
on my boards), but we fixed it. Disabling a feature on all boards
just because one SD card controller is broken seems bad.
Fixes: 29f6589140a1 ("brcmfmac: disable command decode in sdio_aos")
Cc: Wright Feng <wright.feng@cypress.com>
Cc: Double Lo <double.lo@cypress.com>
Cc: Madhan Mohan R <madhanmohan.r@cypress.com>
Cc: Chi-Hsien Lin <chi-hsien.lin@cypress.com>
Signed-off-by: Douglas Anderson <dianders@chromium.org>
---
Changes in v2:
- A full revert, not just a partial one (Arend). ...with explicit Cc.
drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
index 4e15ea57d4f5..4a750838d8cd 100644
--- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c
@@ -3364,11 +3364,7 @@ static int brcmf_sdio_download_firmware(struct brcmf_sdio *bus,
static bool brcmf_sdio_aos_no_decode(struct brcmf_sdio *bus)
{
- if (bus->ci->chip == CY_CC_43012_CHIP_ID ||
- bus->ci->chip == CY_CC_4373_CHIP_ID ||
- bus->ci->chip == BRCM_CC_4339_CHIP_ID ||
- bus->ci->chip == BRCM_CC_4345_CHIP_ID ||
- bus->ci->chip == BRCM_CC_4354_CHIP_ID)
+ if (bus->ci->chip == CY_CC_43012_CHIP_ID)
return true;
else
return false;
--
2.22.0.rc1.311.g5d7573a151-goog
^ permalink raw reply related
* [PATCH v2 0/3] brcmfmac: sdio: Deal better w/ transmission errors waking from idle
From: Douglas Anderson @ 2019-06-03 18:37 UTC (permalink / raw)
To: Ulf Hansson, Kalle Valo, Adrian Hunter, Arend van Spriel
Cc: brcm80211-dev-list.pdl, linux-rockchip, Double Lo, briannorris,
linux-wireless, Naveen Gupta, Madhan Mohan R, mka, Wright Feng,
Chi-Hsien Lin, netdev, brcm80211-dev-list, Douglas Anderson,
linux-mmc, Shawn Lin, YueHaibing, Hans de Goede, Hante Meuleman,
Michael Trimarchi, Wolfram Sang, Franky Lin, David S. Miller,
linux-kernel, Avri Altman
This series attempts to deal better with the expected transmission
errors that we get when waking up (from idle) the SDIO-based WiFi on
rk3288-veyron-minnie, rk3288-veyron-speedy, and rk3288-veyron-mickey.
Some details about those errors can be found in
<https://crbug.com/960222>, but to summarize it here: if we try to
send the wakeup command to the WiFi card at the same time it has
decided to wake up itself then it will behave badly on the SDIO bus.
This can cause timeouts or CRC errors.
When I tested on 4.19 and 4.20 these CRC errors can be seen to cause
re-tuning. Since I am currently developing on 4.19 this was the
original problem I attempted to solve.
On mainline it turns out that you don't see the retuning errors but
you see tons of spam about timeouts trying to wakeup from sleep. I
tracked down the commit that was causing that and have partially
reverted it here. I have no real knowledge about Broadcom WiFi, but
the commit that was causing problems sounds (from the descriptioin) to
be a hack commit penalizing all Broadcom WiFi users because of a bug
in a Cypress SD controller. I will let others comment if this is
truly the case and, if so, what the right solution should be.
There wasn't a good resolution on v1 and it's been a while, so I'm
sending out a v2. Other than changing patch #1 to a full revert, the
only other changes here are just to the patch descriptions.
Changes in v2:
- A full revert, not just a partial one (Arend). ...with explicit Cc.
- Updated commit message to clarify based on discussion of v1.
Douglas Anderson (3):
Revert "brcmfmac: disable command decode in sdio_aos"
mmc: core: API for temporarily disabling auto-retuning due to errors
brcmfmac: sdio: Disable auto-tuning around commands expected to fail
drivers/mmc/core/core.c | 27 +++++++++++++++++--
.../broadcom/brcm80211/brcmfmac/sdio.c | 9 +++----
include/linux/mmc/core.h | 2 ++
include/linux/mmc/host.h | 1 +
4 files changed, 32 insertions(+), 7 deletions(-)
--
2.22.0.rc1.311.g5d7573a151-goog
^ 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